Subject: RE: [Sipping] Re: Meaning of status codes

From: "Francois Audet" <[email-masked]>
Date: Fri, 6 Dec 2002 16:58:30 -0800

> Jon,  what you are describing is a general problem of early media and 
> forking.  The "just play it" philosophy and the extra semantic data 
> provided by sending a 180 instead of a 183 is actually a benefit to 
> resolving the problem.  The problem is solved simply by setting a 
> priority scheme for the sources of incoming audio.  Note that most 
> other types of media do not have this problem so I will focus 
> on audio 
> only.
> 
> media from connected dialog
> media from early dialog with 183
> media from early dialog with 182
> media from early dialog with 181
> media from early dialog with 180
> inband alerting

I assume that the last line should read "local alerting with 180" instead?
And that this list is in
reverse-order priority?

If this is the case I am not sure I agree with the order of the priorities
you give. It would produce 
things like "The number you you have dial is invalid, please hang-up"
followed by somebody
answering.

Also, if there are many forks, you may have multiple 183 with early dialog,
and the early media will
not be terribly useful.

I believe that as soon as you know that there is forking, early media
becomes useless and you would
be much better instead to rely on purely functional messages to generate
your user interface
signals (display, locally-generated audible ringing, etc.). In that context,
the highest priority 
seems to be a 180 because it is the most important from a user's point of
view (somebody's phone is
ringing). The others don't really say much.

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 17:32:47 -0800

On Friday, December 6, 2002, at 04:58 PM, Francois Audet wrote:

> I assume that the last line should read "local alerting with 180" 
> instead? And that this list is in
> reverse-order priority?

yes, sorry.

> If this is the case I am not sure I agree with the order of the 
> priorities you give. It would produce

yes.  it could also cause someone to hear that error message and then 
receive a message that the request failed.  if you did something else 
the user might hear ringback and then "click".

> Also, if there are many forks, you may have multiple 183 with early 
> dialog, and the early media will
> not be terribly useful.

yes, but probably more useful than doing nothing at all.  as I said 
before, parallel forking to gateways is basically an error case.  I am 
proposing a "best we can do" type of approach to that error case.  
short of running a tone analyzer and ASR on each each early media 
stream, I don't see how we can do any better.

> be much better instead to rely on purely functional messages to 
> generate your user interface
> signals (display, locally-generated audible ringing, etc.). In that 
> context, the highest priority
> seems to be a 180 because it is the most important from a user's point 
> of view (somebody's phone is

the problem is that the others could say something very important or 
very unimportant and we can't predict which.

thx,
-r