I think from the proxy perspective the initial forked INVITE can not have different from-tags, as they have to keep the same from header as is received from the i/c side.
For B2BUA case this is not the case they can generate there own from-header, so if the B2BUA had different tags in the forked INVITE it may be ok. But for proxy case the from-tags have to be same. I agree with Paul's response for forking at proxy. Thanks everyone for discussion and clarification. Regards, Indresh K Singh -----Original Message----- From: Singh, Indresh (SNL US) Sent: Thursday, March 15, 2007 2:32 PM To: 'Paul Kyzivat' Cc: 'varun'; '[email protected]'; Chaney, Charles (SNL US) Subject: RE: [Sip-implementors] Sip Registration and Invite forking I Agree. I think it is our internal handling where we generate different from-tags for the forked call in B2BUA ( probably the forked call on o/g side is again our internal term and may be not really be the forking as described for proxies) implementation to support multiple contacts. and keep the same call-id as session identifier. Responses ofcourse are going to come with different to-tags which results in separate dialogs for each forked request. Paul: Could you help clairfy why the from-tags should be kept same and if they are kept different does it go against the definition of forking ? Thanks, Indresh K Singh -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:12 AM To: Singh, Indresh (SNL US) Cc: varun; [email protected] Subject: Re: [Sip-implementors] Sip Registration and Invite forking Singh, Indresh (SNL US) wrote: > > As indicated in the previous response the forked requests create > multiple dialog for the same session at the proxy and the dialogs can be > identifed from each other based on the from-tag of the INVITE requets > which are forked. They are distinguished based on the to-tag. The from-tag will be the same for both. (The from-tag is assigned by the UAC, and the to-tag assigned by the UAS.) Paul > Below is one reference regarding forking concept from RFC-3261 Section > 19.3 > > "The forking of > SIP requests means that multiple dialogs can be established from a > single request. This also explains the need for the two-sided dialog > identifier; without a contribution from the recipients, the > originator could not disambiguate the multiple dialogs established > from a single request. ......." > > Regards, > > Indresh K Singh > > -----Original Message----- > From: varun [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 14, 2007 11:23 PM > To: Singh, Indresh (SNL US); [email protected] > Subject: RE: [Sip-implementors] Sip Registration and Invite forking > > Hi, > Lets say Proxy srever gets an invite and it forks the > Request( since user is registered at multiple places). > I think the forked requests will have the same From,To > and call-id header fields. > So how do you distinguish them? > > > Thanks > Varun > > --- "Singh, Indresh (SNL US)" > <[EMAIL PROTECTED]> wrote: > >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf Of varun >> Sent: Wednesday, March 14, 2007 2:19 PM >> To: [email protected] >> Subject: [Sip-implementors] Sip Registration and >> Invite forking >> >> Hi, >> Is contact header mandatory in SIP Registration. >> >> No >> The TO header field being the address of record is >> mapped to Contact address in Registrar when a >> registration request is received. >> In case, contact is optional then how is the mapping >> done in Registrar? >> >> >> No mapping is done in this case. A registration >> request can be received >> to fetch the existing binding information ( It is >> called query like new >> registeration, refresh, un-register, there is a >> query registration when >> a REGISTER method is received without any contact >> information ) >> >> >> Another question is about Invite forking.How are the >> forked Invite requests distinguished from each other >> or rather their responses. >> >> >> Forking requests are identified by the >> dialog-identifiers ( the from and >> to tags ). For the case where there are multiple >> bindigns associated >> with a DN and the call is forked by proxy/B2BUA, the >> call-id/session >> identifier remains same, but the dialog-ids ( >> from-tag is populated >> differently in the initial invite ). >> >> Now the responding UAS will populate different >> to-tag for each forked >> INVITE request received by them. But the proxy/B2BUA >> based on the >> call-id and tags can still figure out which session >> these responses are >> associated with and in that session which dialog >> that response is >> associated with. >> >> >> >> Thanks >> Varun >> >> >> >> >> > ________________________________________________________________________ >> ____________ >> TV dinner still cooling? >> Check out "Tonight's Picks" on Yahoo! TV. >> http://tv.yahoo.com/ >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> > > > > > ________________________________________________________________________ > ____________ > Looking for earth-friendly autos? > Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. > http://autos.yahoo.com/green_center/ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
