Yes, you are right - it does say that. Indeed the case is illegal.
My point is tht I don't understand why one would keep state of *calls*
independently of *dialogs* when there is no useful correlation between
different dialogs that share the same callid?
BUT, for whatever reason, I guess you are entitled to do so.
If this is then detected as an error, you have to figure out what error
code to return. I don't see anything suitable other than 400 or 500. And
if you think it is the message that is at fault then I guess you would
prefer 400.
This just points out the interop problems that arise because people play
fast and loose with these globally unique ids. Some say "I can use the
same callid because the tags will make it unique" and others say "I can
use the same tag because the callid will make it unique".
Thanks,
Paul
Arunachalam Venkatraman (arunvenk) wrote:
> RFC 3261 does say the call-id has to be spatially and temporally unique.
> How can we draw the inference from the RFC that a UA must accept a
> call-id, for a new INVITE from another UA, that could only be generated
> by it ?
>
>
> -----Original Message-----
> From: Kanumuri, Sreeram [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2008 1:20 PM
> To: Paul Kyzivat (pkyzivat); Arunachalam Venkatraman (arunvenk)
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: RE: [Sip-implementors] Call-id Use ( Re-use/Misuse)
>
> I agree with Paul
> I think the call must not be rejected.
>
> As per 3261 we identify incoming message to be part of the existing Call
> with the dialog-id. But not with the Call-id.
>
> There can be some implementations which might use Call-id as the handle
> f billing/monitoring purposes. It's up to the implementations.
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Paul Kyzivat
> Sent: Wednesday, October 29, 2008 10:53 AM
> To: Arunachalam Venkatraman (arunvenk)
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Call-id Use ( Re-use/Misuse)
>
>
>
> 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: sip-implementors@lists.cs.columbia.edu
>> 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
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
