On 3/21/12 3:36 PM, Bob Penfield wrote:
> I see your point, but even in the scenario you describe, there is a re-INVITE
> that would convey to the UA updated capabilities. It is OK for this stuff to
> change during the dialog, but the UAs have to rely on those changes being
> communicated in signaling. Otherwise, there is no point at looking at things
> like the Allow header.
In some cases the updated info may be reported to the extent that it is
known. But I suspect there will be many cases where that doesn't work
out well. (For one, the new UA may not report something at all - no
Accept, Supports, ... In that case, the B2BUA has no new value to send
to the other end.)
I'd (personally, not necessarily as sipcore chair) be interested in
having a discussion on how we might improve on this situation. But I
expect there aren't a lot who care that much about it.
Thanks,
Paul
> cheers,
> (-:bob
>
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Paul
> Kyzivat
> Sent: Wednesday, March 21, 2012 12:06 PM
> To: [email protected]
> Subject: Re: [Sip-implementors] 405 response for UPDATE
>
> Ahh, you found an old email of mine. :-)
>
> There are many of these things in sip where support for *something* is
> declared somewhere. For the most part there is no guarantee how long
> this support is promised to remain, or in what scopes they hold.
>
> We could *try* to tighten these up, but doing so would break some things.
>
> The use case I usually use to identify such issues is 3pcc - where there
> is a B2BUA call controller between a caller and a callee. The controller
> may usually try to act like a proxy - relaying requests to the other
> end. But this means it has to reflect the capabilities and limitations
> of one end to the other, because otherwise it may be asked to do
> something that it can't forward and can't emulate. The controller can
> then do a transfer, replacing one of the endpoints with a new one. The
> other end doesn't see this as a transfer, just a reinvite. But once this
> is done, the new endpoint might not have the same capabilities and
> restrictions as the old one. So the controller may have to report the
> change. To the unchanged endpoint this will appear as a mid-dialog
> change of its peer's capabilities. It could show up as a 405.
>
> Thanks,
> Paul
>
> On 3/21/12 10:06 AM, harbhanu sahai wrote:
>> Also, as per 3261 the Allow header present in provisional is valid untill
>> the dialog is in early state.
>>
>> Header fields present in a provisional
>> response are applicable as long as the dialog is in the early state
>> (for example, an Allow header field in a provisional response
>> contains the methods that can be used in the dialog while this is in
>> the early state).
>>
>> On the other hand for Allow present in 2xx, lists methods supported for the
>> "duration of call"
>>
>> A 2xx response to an INVITE SHOULD contain the Allow header field and
>> the Supported header field, and MAY contain the Accept header field.
>> Including these header fields allows the UAC to determine the
>> features and extensions supported by the UAS for the duration of the
>> call, without probing.
>>
>> Found an old archive which underscores the point that the Allow header
>> content can be updated within a dialog.
>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020143.html
>>
>>
>> But now what's confusing is this --
>> "The scope of these things is very unclear. About all you can
>> ***reliably **assume
>> is that they are true at the time they are conveyed***. "
>>
>> Regards,
>> Harbhanu
>>
>> On Wed, Mar 21, 2012 at 6:55 PM, Bob Penfield<[email protected]>wrote:
>>
>>> I guess that depends on your interpretation of integral to the usage. If
>>> the UA is using UPDATE which includes SDP to modify the session parameters,
>>> it is important for that session. What is the UA supposed to do? It was
>>> told that it could use UPDATE, so it did. Is it supposed to try UPDATE and
>>> then if that fails use INVITE? Why would UPDATE be OK at the beginning of
>>> the session and then not be OK later? If there were no other transactions
>>> that included an Allow header, how is the UA supposed to know that it is
>>> not OK now? If that is the case, then the Allow header is useless.
>>>
>>> It just does not make sense.
>>>
>>>
>>> cheers,
>>> (-:bob
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Brett Tate [mailto:[email protected]]
>>> Sent: Wednesday, March 21, 2012 8:52 AM
>>> To: Bob Penfield; Kashif Husain; [email protected]
>>> Subject: RE: [Sip-implementors] 405 response for UPDATE
>>>
>>> If UPDATE was integral to the INVITE usage, it would have been defined
>>> within RFC 3261.
>>>
>>>> -----Original Message-----
>>>> From: Bob Penfield [mailto:[email protected]]
>>>> Sent: Wednesday, March 21, 2012 8:50 AM
>>>> To: Brett Tate; Kashif Husain; [email protected]
>>>> Subject: RE: [Sip-implementors] 405 response for UPDATE
>>>>
>>>> Then does that mean the RFC 5057 is incorrect when it says:
>>>>
>>>> (3) 405 Method Not Allowed:
>>>>
>>>> 501 Not Implemented:
>>>>
>>>> Either of these responses would be aberrant in our example
>>>> scenario since support for the NOTIFY method is required by the
>>>> usage. In this case, the UA knows the condition is unrecoverable
>>>> and should stop sending NOTIFYs on the usage. Any refresh
>>>> subscriptions should be rejected. In general, these errors will
>>>> affect at most the usage. If the request was not integral to the
>>>> usage (it used an unknown method, or was an INFO inside an INVITE
>>>> usage, for example), only the transaction will be affected.
>>>>
>>>> Typically UPDATE is integral to the INVITE usage.
>>>>
>>>>
>>>> cheers,
>>>> (-:bob
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:sip-
>>>> [email protected]] On Behalf Of Brett Tate
>>>> Sent: Wednesday, March 21, 2012 8:46 AM
>>>> To: Kashif Husain; [email protected]
>>>> Subject: Re: [Sip-implementors] 405 response for UPDATE
>>>>
>>>>> Is this a valid behavior?
>>>>> Is it allowed to send 405 in this scenario?
>>>>
>>>> Yes; the behavior is valid. Just because UPDATE was allowed, it
>>>> doesn't mean that it must continue to be allowed.
>>>>
>>>> However, the behavior that you are describing is more prevent with
>>>> B2BUAs reconnecting dialogs that do and don't support UPDATE.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> 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
