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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 20:16:24 -0500

While I think I understand your analysis below, I think it is to a large
degree undermined by the fact that SIP requests can fork, and that multiple
UASs may wish to share early media with an end-user. I've brought up this
point several times now in connection with your "just play it" philosophy.
If four UASs send media to the UAC, how does "just play it" help us with
clipping? 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

---

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

On Thursday, December 5, 2002, at 05:16 PM, Peterson, Jon wrote:

> clipping?

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

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.  Note that you 
need to do something like this *anyway* if you deal with multiple 183s.

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.

thanks,
-rohan

> UACs have no way to know which one of these UASs may, eventually,