Re: [Sip] 199: Staus and open issues after Dublin - support indicator

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi Brett,

>>>If UAC does not support 199, sending it might cause more harm than
good.
>> 
>>A UAC should discard what it doesn't support.
>
>RFC 3261 section 8.1.3.2: "A UAC MUST treat any provisional response
different than 100 that it does not recognize as 183 (Session
Progress)."
>
>The above requirement adds complication for devices (not supporting
199) only maintaining a limited number of early dialogs or using latest
1xx to recognize most likely active early dialog.
>
>The 199 could trigger them to forgot or not prefer a useful early
dialog for the one associated with 199.

Wouldn't that mean that, if the UAC does not insert the indicator,
proxies are not allowed to insert it either? Because, if they do, and
receive 199 I guess they will simply forward the 199 towards the UAC,
and you end up in the same situation. An intermediate B2BUA could of
course terminate the 199, and not forward it towards a UAC not
supporting it, but I don't think we want to define such behavior for
normal proxies.

>>>If no proxy steals another's To tag for originating a final INVITE 
>>>response, I agree.  I don't recall what rfc3261 and invfix recommend 
>>>concerning the abnormal situation from proxy and UAC perspectives.
>>>I was mainly just asking for conceptual reasons based upon the 
>>>paragraph prior to my question.
>>>If it occurs, should the originator of 199 tag X process the 2xx tag 
>>>X like a UAC or proxy?
>> 
>>
>><snip>
>>
>>Maybe it could steal a tag when sending an error response, but in that

>>case I guess it doesn't matter very much. I guess the UAC could simply

>>ACK it.
>
>Yes, my question was mainly concerning situation caused by proxies that
incorrectly use another's early dialog To tag when originating a failure
INVITE response like 487 when no final INVITE 
>response has been received.  Hopefully there are no longer proxies that
actually do it. :) If the 199 originator uses such a tag to send 199 and
INVITE 200 received using the same tag, I was 
>curious how the 199 originator should behave (as proxy or UAC).  If it
proxies the INVITE 200, the call might actually get established and stay
up when UAC does not support 199 or
>199 was dropped.

In this case I guess the UAC could simply send ACK + BYE. It may not be
the desired behavior, but could be the result of badly "tag stealing"
behaving proxies.

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip