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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 11 Dec 2002 04:39:43 -0500

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 5:22 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
> Subject: Re: [Sipping] Re: Meaning of status codes
> 

[snip]
> > 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.
> 
> 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.
> 

As an aside, if you receive ten such media streams, your client would have
some difficulty playing any of them if there are bandwidth constraints, etc.

But primarily, if you ignore the media from the 180, you will not be
preventing clipping (even assuming the more modest proposal that media is
only sent when ANM is received by the gateway) if the user picks the UAS
that sent the 180. That is the subject at hand in this thread.
Prioritization seems unrelated to this particular issue (though it is useful
for other reasons).

[snip]
> >
> > 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".
> 
> I think you misunderstand Bill's point.  The UAS sending an early 
> answer in a 180 help prevent clipping.  

RFC3261 has provisions for playing media received over an offered stream
regardless of whether or not an answer has yet been received. How does the
answer in 180 itself help to prevent clipping? If Bill is only concerned
with media that is sent when the remote side has picked up the phone (i.e.
simultaneous with transmission of 200 OK), what additional leverage do we
get from having the answer in the 180 instead of the 200? This also raises
concerns that have been discussed in this thread about sending an answer
with an 'active' media stream when you don't intend to play any media.

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

I do not yet understand how prioritization helps with clipping. But nor do I
see a need to be putting forward any mechanism just yet - agreeing on the
problem is the most important thing now, I think.

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

Well, this may be part of a solution, but this 'channel changer' UAC
behavior strikes me as something non-trivial. Merely receiving the early
media from multiple sources simultaneously might be problematic on
bandwidth-constrianed links, etc. 

Again, I'd be happy if we could just agree on the problem at this stage,
irrespective of potential mechanisms to address it.

> hope this makes more sense.
> thanks,
> -rohan
> 
> 
> >> 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: Wed, 11 Dec 2002 10:17:06 -0800

> some difficulty playing any of them if there are bandwidth 

which we can address with an UPDATE to shut these up.

> Prioritization seems unrelated to this particular issue (though it is 

Correct.  You are doing the best possible thing you can automatically 
do to play some reasonable media, and *whenever possible* prevent 
clipping.

Gateway side (UAS for the INVITE)
1. If the GW knows that the PSTN is alerting, it should send a 180 with 
and answer, *but send no media* until it sends a 200 or 183.
2. If the GW does not know the semantics or some early media, it should 
send a 183 with an answer and send that media.

SIP side (UAC for the INVITE)
1. The UAC should in general play any early media that it receives from 
a single stream/source.  This  ensures that users can hear potentially 
important inband messages from the PSTN, and prevents clipping if media 
arrives before a 200 or 183
2. If the UAC receives multiple early answers (this is not an error), 
it should send an UPDATE (new offer) for each of them to cause them to 
arrive on different RTP ports so that they can be individually 
distinguished and controlled if necessary.
3. If the UAC receives multiple streams of early media (this is 
arguably an error) it should prioritize them in some reasonable fashion 
to improve the chances that the user will lose the least amount of 
potentially useful information. Note that this prioritization may be to 
the detriment of preventing clipping or it may not.  However, by 
maintaining a jitter buffer (where bandwidth and CPU allows) and 
performing any middlebox traversal for each answer, you reduce the 
amount of clipping delay for de-prioritized streams/answers.

> with an 'active' media stream when you don't intend to play any media.

without any special behavior on the having the answer in the 180 allows 
me to prime an address restricted NAT or FW, to prevent clipping

if there is connection-oriented media in the offer/answer, getting the 
answer early allows me to setup that connection, or for 
connection-oriented RTP, to prime a symmetric or port restricted NAT or 
FW, to prevent clipping.

if the 180 has a session description, it allows me to play early media 
from a subsequent 183 without clipping.  (I have locally-generated 
ringback, but then I hear "The mobile subscriber is unavailable."  
without clipping.

if the 180 is for sendrecv media, you are preventing clipping at the 
answering end.  in other words, if I hear "Hello", I can start talking 
immediately, even if the 200 is delayed.

> problem is the most important thing now, I think.

I agree that no new protocol mechanism is necessary.  Just best 
practices, or clarification of the use of existing mechanisms.

> bandwidth-constrianed links, etc.

agreed on both points.

thanks,
-rohan