Bug 32607

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>
Severity:	enhancement
Priority:	medium	CC:	smcv, will
Version:	git master	Keywords:	patch
Hardware:	Other
OS:	All
Whiteboard:	review+
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[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.