|Summary:||Message tokens, sent timestamps for SIP message channels|
|Product:||Telepathy||Reporter:||Mikhail Zabaluev <mikhail.zabaluev>|
|Component:||rakia||Assignee:||Mikhail Zabaluev <mikhail.zabaluev>|
|Status:||RESOLVED FIXED||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
Description Mikhail Zabaluev 2010-12-23 07:16:56 UTC
The proposed branch adds "message-token" headers to incoming SIP messages, as well as "message-sent" timestamps. The token is synthesized from SIP headers Call-ID and CSeq and is considered to be reasonably unique per message with well-behaved senders. The "message-sent" timestamp is obtained from the Date header. There was some concern about usage of "message-token", but now that its uniqueness is agreed to be on the best effort basis, I think the implementation fits it quite well.
Comment 1 Simon McVittie 2011-01-03 05:06:46 UTC
> + assert now - 10 < msg['message-received'] < now + 10 > + assert now - 10 < msg['message-sent'] < now + 10 I can see that this is the best you can do for message-received, but for message-sent, I'd prefer to hard-code a target value in the past here... > + msg.addHeader('date', time.strftime("%a, %d %b %Y %H:%M:%S GMT", time.gmtime())) ... and use a corresponding date here.
Comment 2 Simon McVittie 2011-01-03 05:07:20 UTC
It might be worth noting in NEWS that if this version is backported to Maemo 5, it'll break the logger unless message-token is removed.
Comment 3 Mikhail Zabaluev 2011-01-03 06:24:29 UTC
(In reply to comment #1) > I'd prefer to hard-code a target value in the past here... Good point, will do. (In reply to comment #2) > It might be worth noting in NEWS that if this version is backported to Maemo 5, > it'll break the logger unless message-token is removed. Please remind me on the breakage condition: will the mere presence of tokens that are unique break it? I think Call-ID + CSeq is bulletproof in all good implementations, but there might be some rogue endpoints, of course.
Comment 4 Simon McVittie 2011-01-03 06:55:47 UTC
(In reply to comment #3) > Please remind me on the breakage condition: will the mere presence of tokens > that are unique break it? I think Call-ID + CSeq is bulletproof in all good > implementations, but there might be some rogue endpoints, of course. The Maemo 5 logger assumes that the same message-token implies the same message, so if an endpoint is rubbish (or malicious), it can cause earlier messages with the same (Call-ID, CSeq) tuple to be overwritten.
Comment 5 Mikhail Zabaluev 2011-01-03 08:30:43 UTC
I have merged a recent master head and addressed the points raised in comment #1 and comment #2.
Comment 6 Simon McVittie 2011-01-03 09:18:51 UTC
Comment 7 Mikhail Zabaluev 2011-01-03 09:47:15 UTC
Thanks, merged to master (commit 9eb2013).