Singh, Indresh (SNL US) wrote:
> 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
> ?
My answer was predicated on forking by a *proxy*. It has no business
messing with the from-tag.
If you replace the proxy with a B2BUA, then it can do what it wants on
the downstream side. But on the upstream side it will have to honor the
from-tag of the UAC.
Paul
> 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
