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.
> + 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.
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.
(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.
(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.
I have merged a recent master head and addressed the points raised in comment #1 and comment #2.
Looks good.
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.