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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 12 Dec 2002 04:14:25 -0500

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2002 10:17 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: Meaning of status codes
> 
> 
> 
> On Wednesday, December 11, 2002, at 01:39 AM, Peterson, Jon wrote:
[snip]
> >
> > 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.
> 
> which we can address with an UPDATE to shut these up.

True, but it is better to recommend a UAS behavior that does not require the
UAC to go to this trouble. UPDATE should be used as a last resort when UASs
are (hopefully out of necessity) sending pre-answer media, but it is better
still to allow the UAC to manage its acquisition of optional early media
more easily.

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

Yes, this is essentially what I've been suggesting.

> 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

Might be tough to know whether or not you're going to receive early media
from more than one source. One source might send first, then another after a
delay, etc.

You could, of course, just opt to play the first such media you receive, and
ignore subsequent media, but then it would essentially be random in forking
cases whether or not clipping is prevented - but who knows, perhaps that
this is the best option.

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

Agreed. Must also accomodate the (backwards compatibility) case in which
multiple early media streams arrive without early SDP answers, or perhaps
the more common case in which this media arrives, but beats the early SDP
answer to the UAC. Also must take into account the fact that the early SDP
answer must contain source information if it is reliably to be used to
differentiate media streams. There are also still some issues with early SDP
answers that we need to resolve (following the earlier thread on the meaning
of 'active' and 'inactive').

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

Again, I'm still not sure how the status code prioritization actually
improves these chances. The important priority issue seems to be whether the
UAS can express status in-band or out-of-band. The jitter buffer solution is
also complicated, I suspect.

[snip]
> >
> > 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?
[snip]
> 
> 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 source information in the SDP, okay, it could help - but we
would still need to answer the questions about the issues surrounding the
semantics of 'active' (which will probably amount to this being some sort of
'special behavior'). 

Middleboxes today would presumably have to open a 'half port' (anything
going to the address and port advertised in the offer is allowed), and we
could just stick with that behavior. Preserving middlebox functionality is
not one of my priorities in this matter, though.

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

I hadn't thought about connection-oriented media in this context. Arguably,
since this is largely a telephony gatewaying issue, we're should only be
concerned with traditional RTP here. But I suppose it's fair to consider
this case. That much said, I really don't have any opinion about its
applicability one way or the other.

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

Both of these two above are possible even if there is no SDP answer - based
on the aforementioned RFC3261 language that you have to be ready to receive
media on an offered stream before you receive an answer. Therefore clipping
prevention is not, as far as I can tell, predicated on receiving an early
SDP answer.

[snip] 
_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Thu, 12 Dec 2002 11:54:03 +0200

Hi,

A few comments.

> >>have some difficulty playing any of them if there are bandwidth
> >>constraints, etc.

[CHH] I agree on this. Of course a UAC MAY send UPDATE if it wants, but it may
also choose to simply use some kind of
RTP "filter", to mix everything, or not to pass anything before 200 OK. I guess
that is all based on local policy and capabilities.

However, IF the UAC sends UPDATE, we have to remember that another UPDATE must
also be sent when the call is answered (I assume "an UPDATE to shut these up"
mean you mean changing the mode to "inactive"?). And, I guess it's the UAS who
would have to send that UPDATE (I think that is at least what has been
proposed), but can we really assume that will happend? Or, do we assume that the
node which sends to first UPDATE (to stop early media) will also send the second
UPDATE (to allow it) when it receives 200 OK? In any case, however, we once
again come to the issue of clipping, and what "inactive" really means.

> >>is only sent when ANM is received by the gateway) if the user picks the UAS
> >>useful for other reasons).
> >

[CHH] Just to clarify, what do you mean by "with answer". Assume the UAS has
already sent an answer. Do you mean that it now would send the same SDP (a copy
of the answer) as some kind of indicator, or? I think we shall remember that the
gateway may recieve multiple ISUP messages, mapped into 18x. Does your
suggestion only affects the first 18x sent, or?

> cases whether or not clipping is prevented - but who knows, perhaps that

[CHH] At least it is the easiest (and most backward compatible, I would assume)
option.

> of 'active' and 'inactive').

[CHH] Didn't you earlier say that sending UPDATE should be used as "last
resort", so I think it should be MAY instead of SHOULD. Also, the UAC may not
reserve different ports for every early stream, it may simply change the stream
to "inactive" (in which case either party also needs, as described earlier, to
put the stream back to "sendrecv" when the call has been answered).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Dec 2002 14:25:12 -0500

> still to allow the UAC to manage its acquisition of optional early media

I *think* Rohan is proposing to use UPDATE to move the media stream for 
each dialog to a unique port. And presumably telling one to shut up is 
by setting the media stream to inactive. (Or sendonly from the UAC's POV.)

I'm not sure if Rohan is proposing to do this preemptively when the 
dialog is first established, or only if the UAC begins to get into 
trouble. I suspect that waiting until there is trouble is problematic.

If this is done preemptively, then the rules Jon is proposing don't help 
to minimize the need. The UAS will want to establish the media stream in 
advance of the 200, perhaps in a 180, as a way to avoid eventual 
clipping, even though it doesn't intend to send media until the 200 is 
sent. But the UAC doesn't know this, and will be inclined to use UPDATE 
to put these on separate ports without knowing that media won't be coming.

To realize benefit from Jon's proposal, the muting shouldn't happen 
until it is discovered that data is actually being received from 
multiple sources. This suggests that as soon as the 2nd dialog is 
established, UPDATE should be used to put each dialog on a separate 
port. And then, *if* it is discovered that media is being received on 
more than one port, additional UPDATEs be sent to mute all but one of those.

And then, once a 200 is received, if that stream is muted, another 
UPDATE must be sent by the UAC, following the ACK, to enable it.

Sure is a lot of burden on the UAC to support forking. :-(

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 12 Dec 2002 13:00:28 -0800

On Thursday, December 12, 2002, at 11:25 AM, Paul Kyzivat wrote:

> I *think* Rohan is proposing to use UPDATE to move the media stream 
> for each dialog to a unique port. And presumably telling one to shut 
> up is by setting the media stream to inactive. (Or sendonly from the 
> UAC's POV.)

yes

> trouble. I suspect that waiting until there is trouble is problematic.

preemptively.

> If this is done preemptively, then the rules Jon is proposing don't 
> help to minimize the need. The UAS will want to establish the media 
> stream in advance of the 200, perhaps in a 180, as a way to avoid 
> eventual clipping, even though it doesn't intend to send media until 
> the 200 is sent. But the UAC doesn't know this, and will be inclined 
> to use UPDATE to put these on separate ports without knowing that 
> media won't be coming.
>

yes, but there it is.

thanks,
-rohan