Dale,
I'm fine with spinning it this way. It avoids using the *term* B2BUA,
but it still is talking about a B2BUA since it is talking about a UA
that has received a response from downstream of itself. So we are
playing political correctness gavmes. But I'm ok with that.
Thanks,
Paul
[EMAIL PROTECTED] wrote:
> From: Paul Kyzivat <[EMAIL PROTECTED]>
>
> Well, the specification could be abstracted to remove the mention of the
> B2BUA while still having the same effect. It would have to say something
> about a UAS should send a 199 if it knows the dialog will be terminated
> before it can send the final response. But I think we would still need
> to include an example of a B2BUA in order for anybody to have a clue
> what we were talking about.
>
> I think the situation is simpler than people are making it out to be.
>
> The situations in which having an agent generate and send a 199 is
> useful are when all of the following are true:
>
> - the agent knows that an early dialog has been created because it
> transmitted a 1xx response (either that it generated, or that it
> received from downstream) (And as Rocksun pointed out, "1xx"
> explicitly excludes both "100" and "199".), and
>
> - the agent knows that the early dialog has been terminated due to
> receiving a failure final response which includes the early dialog
> (which was from the downstream leg from which the 1xx came), and
>
> - the agent has not transmitted a 199 response to terminate the early
> dialog, and
>
> - the agent will not be immediately sending a failure final response
> (which would indicate the termination of the early dialog)
>
> It turns out that an ordinary UAS never is in this situation (because
> it only generates one early dialog for an INVITE, and only ends the
> early dialog when it sends a failure final response), so by
> implication, an ordinary UAS never should send a 199.
>
> If we enumerate the above criteria, we don't have to describe the
> various cases of UA vs. B2BUA, etc., because they're all covered. And
> by making the criteria explicit, we increase the probability of useful
> and effective implementations.
>
> Dale
> _______________________________________________
> 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
>
_______________________________________________
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
