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

Reply via email to