Arunachalam Venkatraman (arunvenk) wrote:
> The sequence of processing a received message at a SIP UA ia to identify
> the call, then the dialog within the call and then the transaction
> within the dialog.
> If the call is found, then an existing dialog must be found. If the
> from-tag is changed, that would not occur.
> The UA should reject the INVITE.
That may be the way you do it, but AFAIK there is no normative language
in 3261 relative to a "call". The closest I recall is a recommendation
to preserve the call-id on retries of a call attempt, such as after a
3xx or 401 response. But its not necessary to retain any state that is
keyed by the call-id, especially for *incoming* calls.
Thanks,
Paul
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Scott Lawrence
> Sent: Wednesday, October 29, 2008 11:39 AM
> To: KASTURI Narayanan (kasnaray)
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Call-id Use ( Re-use/Misuse)
>
>
> On Wed, 2008-10-29 at 08:07 -0700, KASTURI Narayanan (kasnaray) wrote:
>> Hi ,
>>
>> I have a question on a specific behavior seen with a Proxy, the
>> behavior is as follows.
>>
>> UAC Proxy
>> |---Invite(req-URI:A, callid:1, Ftag=1)----->|
>> | | <----Invite(URI:B,
>> |callid:1,ftag=2)---------|
>>
>> And the Proxy Record-Routes as well retaining the Original Contact.
>>
>> In this specific case the UAC on seeing a call-id which it generated
>> with a different From Tag is failing the Invite Request.
>>
>> Question is whether it is a correct behavior on the Proxy to change
>> the
>> >From Tag retaining the same call-id in the above case.
>
> No. It is not acting as a proxy if it's messing with the tags.
>
>> I would also like opinion on what shld be the behavior of UAC in this
>> case. The UAC is assuming that Call-id is globally unique and is able
>> to detect that this call-id belongs to itself and since the From tag
>> is not matching with what it generated it is failing the request.
>
> Do you expect to be able to call yourself (which appears to be what's
> happening above)? If so, you shouldn't care and should accept the call.
> You can't know that the call didn't go through a B2BUA that changed only
> the tag and not the callid (bad practice, but it happens) - that looks
> like what you've got.
>
>
> _______________________________________________
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
