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
