Re: 199 Open Issue: UAS sending 199

Hi Brett,
 
>> 1. UAS never sends 199: 
>>
>>In this case only forking proxies/B2BUA would send 199.
>
>I prefer the goal of option 1.  B2BUA (which is a UAS) or proxy sends
>199 whenever it desires to indicate termination of a dialog and sending
a final INVITE response is not yet appropriate.  
>The subsequent INVITE final response SHOULD contain a different To tag
than those sent within 199s.  A device which does 
>not trigger more than 1 To tag (i.e. fork or simulate forking
interaction) for an INVITE, SHOULD NOT generate a 199 
>since it needs to generate subsequent final failure response with the
same To tag.

That's a good point - maybe even a new alternative #6: UAS sends 199 if
it is handling more than one early dialog.

>>Robert S also raised an issue on what Require: 199 means.
>
>It means the UAS is required to support the RFC.
>
>Depending upon RFC (working group decision), "Require: 199" means UAS
MAY, SHOULD, or MUST send 199 for early dialogs 
>containing To tags different than the INVITE's subsequent final
response To tag; I prefer MAY.
>
>Depending upon RFC (working group decision), "Require: 199" also means
UAS MAY, SHOULD, MUST, or SHOULD NOT send 199 for 
>early dialog containing To tag which is the same as the INVITE's
subsequent final response To tag; I prefer SHOULD NOT.  
>If MUST is preferred, I would desire usage of a different option-tag
such as "failure-reason" or "termination-reason".

Yes. I think the Require:199 thing would be more tricky if an UAS NEVER
sends 199.

But, in any case I agree with Robert S that it is good to clarify the
meaning of Require in the draft.

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip