Subject: [Sip] Re: [Sipping] Requirement for a Transaction ID in each SIP message?

From: Jiri Kuthan <[email-masked]>
Date: Thu, 20 Dec 2001 01:12:42 +0100

Cullen,

few inline nits:

At 08:05 AM 12/18/2001, Jonathan Rosenberg wrote:
>Cullen Jennings wrote:
>
>>Should we add an optional field somewhere in every SIP message that can
>>hold
>>a transaction ID?
>
>Yes. Its called the branch ID. THis was open issue #144, and it was agreed during the sip meeting that bis should specify construction of the branch ID in such a way to allow it to be used as a transaction idedntifier.

>>This would be an identifier that the proxy that sent a request could use
>>to
>>track responses to it. 

Request-response matching using "MPLS-ized SIP" is easy and requires no 
standardization. This is about request-request matching.

>>An element that received a transaction ID in a
>>request, would put the same id into the response. 

I think the transaction ID in inbound and outbound requests passed through
a proxy will be rather different. Specifically, if we use branches as T-ID, 
they will be different whenever R-URIs change because then branches change
too.

Note that INV/CANCEL/ACKs will have the same branch value -- that means you can
easily link both of them together (while looking at the method too). 

Replies for INV/CANCELs will also have the same branch value (because the
original requests had them so). That means you'd have to parse Cseq too to 
look-up correct t-context (INV/CANCEL are separate transactions). I don't see 
now any way around parsing CSeq as topmost Via-s in replies to INV/CANCEL 
are same and cannot be used to distinguish both transactions.

So what needs to be done is
- recommending usage of unique branches for all kinds of UACs
- defining uniquiness for UASs (people seem to want src_ip or sent_by
  as part of its definition too to avoid collisions with upstream
  UACs generating branches that are not "well unique") 
- aggreeing on a uniquiness cookie (be it the "h323" or "jdr" in
  memory of the proponent ;-)

-Jiri

ps -- I changed to sip from sipping as this is about the spec.

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip