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
