Bug 32607 - Message tokens, sent timestamps for SIP message channels
Summary: Message tokens, sent timestamps for SIP message channels
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: rakia (show other bugs)
Version: git master
Hardware: Other All
: medium enhancement
Assignee: Mikhail Zabaluev
QA Contact: Telepathy bugs list
URL:
Whiteboard: review+
Keywords: patch
Depends on:
Blocks:
 
Reported: 2010-12-23 07:16 UTC by Mikhail Zabaluev
Modified: 2011-01-03 09:47 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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[0]['message-received'] < now + 10
> +    assert now - 10 < msg[0]['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
Looks good.
Comment 7 Mikhail Zabaluev 2011-01-03 09:47:15 UTC
Thanks, merged to master (commit 9eb2013).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.