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.
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
