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

From: "Hearty, John" <[email-masked]>
Date: Fri, 6 Dec 2002 17:10:34 -0700

inline.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 4: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:
> 
> >
> > 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?
> 
> 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
> 

How do we associate received media streams with the different responses?  Remember that the IP address and port present in the answer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the answerer.

> 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,
> > 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
> 
_______________________________________________
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 16:55:59 -0800

On Friday, December 6, 2002, at 04:10 PM, Hearty, John wrote:

> How do we associate received media streams with the different 
> responses?  Remember that the IP address and port present in the 
> answer indicate nothing about the source IP address and source port of 
> RTP and RTCP packets that will be sent by the answerer.

Once you get more than one early answer you need to send an UPDATE (or 
PRACK if the 18x was sent reliably) with a new offer with a new target 
address and port.  You need to do this anyway to avoid the early media 
collision problem.  It is not unique to this problem.

thanks,
-rohan