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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 6 Dec 2002 19:26:53 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 3:02 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
> Subject: Re: [Sipping] Re: Meaning of status codes
> 
> 
> 
> On Thursday, December 5, 2002, at 05:16 PM, Peterson, Jon wrote:
> 
[snip]
> >
> 
> Jon,  what you are describing is a general problem of early media and 
> forking. 

Yes, exactly. One that Mr. Marshall did not seem to be considering, hence I
was trying to bring it to his attention.

> 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.  

A lot of this thread has been about whether or not there is any 'extra
semantic data' that is made available by sending a 180 vs. a 183. I happen
to agree that it is better to use 180 when you know alerting is occurring.
However, the hard cases that motivate early media are ones in which the
gateway does not know what sort tone is being played in the provisional
phase; ringing, a busy signal, an announcement - all can show up the same
way to the gateway in ISUP signaling in some cases.

I mean, if the gateway does know that what's happening in the media stream
is alerting, it should just send a 180. The media associated with that
alerting isn't immensely valuable to the UAC. Mr. Marshall (and others) have
suggested that it is worth sending media in every case (whatever provisional
status code you return) in order to prevent clipping, since it seems to do
know harm. I've been responding that there are cases in which it does more
harm than good, namely forking cases. I also think it is unSIPlike for a
number of reasons to send that ringing media, but I'll detail that in
another (longer) note.

> 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
> 

Also, just because one gateway is aware that there is ringing on the line
(and hence sends a 180), and another gateway is not (and hence sends a 183),
why is it more plausible, from the perspective of preventing clipping, that
the 180 responder will actually be the place where the user picks up? I
don't think it is. I don't think this prioritization necessarily grants us
any additional leverage in figuring out how to prevent clipping.

> if I get more than one media stream in the same category, I need to 
> just pick one of those steams to represent the category.  

As I said in other mails (and this was the point of my whole thread with Mr.
Marshall), this does not in fact give you any additional leverage on the
problem of clipping - "just pick one" does not guarantee that you'll be
listening to the one that will be picked up. Clipping prevention is being
presented as an argument for "just play it".

> Note that you 
> need to do something like this *anyway* if you deal with 
> multiple 183s.
> 

I have argued elsewhere in this thread that media in the offer/answer
context of a dialog prior to 200 OK is an aberrant and avoidable case that
we should eliminate in native SIP interactions (there are much better ways
to provide that functionality), so I'm not sure there are valuable 'anyway'
cases.

> Also, note that parallel forking an INVITE to more than one PSTN 
> gateway is a stupid thing to do anyway, so this is really just handling 
> an error case in a robust fashion.
> 

Well, it isn't at all clear how a forking proxy will know that a given
contact address points to a PSTN gateway - I mean, in some cases it could be
explicit and obvious, but in other cases it won't be. Even an individual
ISUP gateway might, for some calls, be able to tell when there is alerting
in the media streams, but for other calls be unable to do so. Of course,
some sorts of gateways might never be able to give you status information
out-of-band, and it might be nice (looking ahead to mechanism for a moment)
to be able to identify such gateways to UACs or forking proxies.

I do agree this is an error case - but I think the 'error' lies in that some
PSTN networks express their status in-band. I agree that the problem of
early media is to a large degree about handling this error case in a robust
fashion.

> thanks,
> -rohan
> 
> 
> > UACs have no way to know which one of these UASs may, eventually,
> > answer and begin sending 'real' media from the callee. So 
> which media
> > stream(s) are rendered to the user in order to prevent 
> clipping? What 
> > if
> > some of these media streams containing ringing, some busy 
> signal, some
> > announcements, and the gateway cannot differentiate between these? 
> > Once we
> > have to take this into account, there is no longer such a simple 
> > answer to
> > the problem. And I'm afraid we do have to take this into 
> account. The 
> > PSTN
> > can make the facilitating assumption that only one destination is 
> > reached by
> > the call - SIP cannot make that assumption.
> >
> > This is why what looks like the easiest case (naive use of 
> provisional 
> > media
> > with in-band ringback to prevent clipping) is actually the 
> one of the
> > hardest.
> >
> > In any event, it isn't clear to me why we should conflate 
> continuous 
> > and
> > disjointed media based on your analysis below. I maintain that the
> > distinction between the two is valuable. The "just play it" 
> philosophy
> > doesn't help with the fact that disjointed media 
> requirement that an 
> > entity
> > other than a UAS that is a target of the call can source the media.
> > Continuous media (provisional media that transitions 
> seamlessly into 
> > 'final'
> > media) should always be an exception case that is only caused by
> > interworking. Disjointed media should be a normal part of SIP, and 
> > should be
> > handled with the tools best suited to its needs (which does 
> not mean 
> > 180
> > with SDP, I suspect).
> >
> > Jon Peterson
> > NeuStar, Inc.
> >
> >> -----Original Message-----
> >> From: William Marshall [mailto:[email-masked]]
> >> Sent: Thursday, December 05, 2002 2:40 PM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> Subject: RE: [Sipping] Re: Meaning of status codes
> >>
> >>
> >> Jon,
> >>
> >>> I think Mr. Camarillo is talking about something else in
> >> the passage below,
> >>> a case in which there is some disjointed media (media
> >> unrelated to the call,
> >>> like an announcement or service message) that is played
> >> before the actual
> >>> media for the call is cut-through. While your scenario is
> >> also valid, I
> >>> think we need to consider these two scenarios separately.
> >> He's talking about
> >>> a case where some disjointed media (not the callee
> >> answering the phone) is
> >>> sent before any audio media from the actual callee - your
> >> case is where
> >>> media from the callee arrives before the 200 OK.
> >>
> >> Agree completely that they are different scenarios.  But I think
> >> there is an advantage to considering them together.
> >>
> >> If we drop Gonzalo's request for "focus" for a moment, and 
> look at a
> >> slightly different and fuzzier problem --
> >>
> >> One of the practical aspects of the UAC is how it needs to react to
> >> receipt of media prior to the 200-OK.  My claim is that it doesn't
> >> know what is happening, and that is an advantage to us.  
> Just thinking
> >> in terms of keeping the UAC simple and predictable....
> >>
> >> If the UAC needs to play received media (after a 180) to
> >> avoid clipping,
> >> and if the UAC needs to play received media (after any 
> 1xx) to avoid
> >> clipping, then this fact goes a long way toward solving 
> lots of other
> >> early media problems.
> >>   In-band ringback - whether preceeded by a 183 or a 180, 
> will still
> >> play the in-band ringback (although possibly with an 
> initial locally-
> >> generated ringback from the 180, which is not real nice)
> >>   Announcement prior to ringback - 183 then send media 
> then send 180
> >> (although the timing of sending the 180 is not simple) will handle
> >> the "I'm insulating the attic right now" message.
> >>   Mid-ring announcement - 180, delay - send the announcement - then
> >> another 180.
> >>
> >> But in restoring (my) focus --- just don't clip.
> >>
> >> Bill Marshall
> >> [email-masked]
> >>
> >> -----original message-----
> >> From: "Peterson, Jon" <[email-masked]>
> >> To: "'William Marshall'" <[email-masked]>, [email-masked]
> >> Subject: RE: [Sipping] Re: Meaning of status codes
> >> Date: Thu, 5 Dec 2002 16:05:25 -0500
> >>
> >> I think Mr. Camarillo is talking about something else in the
> >> passage below,
> >> a case in which there is some disjointed media (media
> >> unrelated to the call,
> >> like an announcement or service message) that is played
> >> before the actual
> >> media for the call is cut-through. While your scenario is
> >> also valid, I
> >> think we need to consider these two scenarios separately.
> >> He's talking about
> >> a case where some disjointed media (not the callee answering
> >> the phone) is
> >> sent before any audio media from the actual callee - your
> >> case is where
> >> media from the callee arrives before the 200 OK.
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> >>> -----Original Message-----
> >>> From: William Marshall [mailto:[email-masked]]
> >>> Sent: Thursday, December 05, 2002 9:24 AM
> >>> To: [email-masked]
> >>> Subject: [Sipping] Re: Meaning of status codes
> >>>
> >>>
> >>> (I've lost track of who said what):
> >>>>> However, as I said above, early media
> >>>>> through gateways (the problem we are considering) is a
> >>> case in which the
> >>>>> media stream is used to describe the status of the call.
> >>> This is not a
> >>>>> 'normal' SIP condition - native SIP should never do this.
> >>> This is an
> >>>>> aberrant condition that occurs only in gateway interworking.
> >>>>
> >>>> I believe that we are almost in agreement about
> >> everything but this
> >>>> part. You believe that a vanilla SIP UAS will never send
> >> early media
> >>>> with a 180, and I believe it MAY.
> >>>>
> >>>
> >>> After a vanilla SIP UAS sends a 200 (after sending a 180),
> >> the UAC may
> >>> (and in many cases likely will) see the media before it
> >> sees the 200.
> >>> To avoid clipping te first part of the "hello", the UAC should
> >>> preempt the local ringback and play the media.
> >>>
> >>> So from the UAC point of view, it doesn't really know whether
> >>> this media
> >>> is "early media" or not.  It shouldn't matter.  Just play it.
> >>>
> >>> Bill Marshall
> >>> [email-masked]
> >>
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

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

On Friday, December 6, 2002, at 04:26 PM, Peterson, Jon wrote:

> status code you return) in order to prevent clipping,

I don't think that is what Bill Marshall proposed.  I think he proposed 
that the UAS send an answer so that the moment it sends a 200 OK it can 
start to send media (typically without clipping).  I don't think he 
actually proposed sending inband ringing with the 180.

> since it seems to do
> don't think it is.

this prioritization is useful because you *know* that the ringing can 
be ignored if something else happens.  the 183 could be ringing, an 
error, a progress message, or a first-stage IVR (like fedex or american 
airlines).  you don't know enough to know if you can ignore this, so 
you ignore the one you know you can.

> I don't think this prioritization necessarily grants us

only insofar as it allows you to prevent clipping *most of the time* 
when you only receive a single answer in serial.

> presented as an argument for "just play it".

I think you misunderstand Bill's point.  The UAS sending an early 
answer in a 180 help prevent clipping.  Just play it in the more common 
serial forking case also helps prevent clipping.  Just play it (with 
priority) also provides you with something reasonable to do when you 
have multiple streams of inbound media.

Note finally that even if you just play the media from a 183 and the 
180 dialog actually answers, this is still better from a clipping 
perspective than if the UAS waited to send an answer in the 200, 
because the UAC can still maintain a jitter buffer for the stream 
associated with the 180 even if it discards the output in favor of the 
183.  This means when it receives the 200, it can start playing from 
the beginning of the jitter buffer instead of waiting for the buffer to 
fill.

hope this makes more sense.
thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Dec 2002 10:03:24 -0500

Jon and Bill,

Why do you consider this to be an error case?

It *might* be an error case if you fork to two gateways in an attempt to 
reach a *single* phone number in the PSTN. But it could as well be a 
normal forking case attempting to reach either of two distinct 
addresses, both of which happen to be PSTN phone numbers.

And of course the forking proxy may have no way to know this is the 
situation. The addresses being forked to may both appear to it as sip 
AORs, that are routed to gateways further downstream.

	Paul

William Marshall wrote:
 >
 > I continue to believe that proxy that forks a request to send it to
 > two PSTN gateways is inherently broken. (Recall my earlier example
 > about one inband-ringing, two voicemails, and three fast-busys, and
 > the voicemail always wins being the first to send 200-OK.) So I have
 > considered this, and consider it a non-problem. Are thee really valid
 > cases for forking a request to multiple PSTN gateways simultaneously?
 > I just don't see them.