Subject: RE: [Sipping] Re: Early media draft

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Nov 2002 07:52:49 -0500

I had the opportunity to read the early media draft tonight, and I have a
few notes.

- I think the informational scope of the draft is perhaps a little too
narrow. Ideally, this draft should address the requirements that people tend
to raise about early media by showing how to apply existing standards, and
also (if necessary) provide any new mechanisms that are necessary to satisfy
the requirements. I would be cautious about ruling out anything out of scope
a priori - at this stage, I think people still want to talk about
requirements.

- I am surprised that the draft today does not discourage the use of early
media. SIP already has a very rich way of communicating provisional status
information (through response codes, and especially the reason phrase that
follows a response code). This begs the question of why people should use
early media at all. Vanity applications, like playing some kind of custom
in-band ringtone, should be severely discouraged. The only cases that I am
aware of in which early media is necessary to provide status information is
when SIP is interworking with another protocol (presumably in the PSTN) and
gateways are unable to determine the status of the call. What is the value
of generalizing early media beyond PSTN-SIP interworking today?

- The draft focuses quite a bit on early media for ringback, but not so much
on other forms of in-band status, notably busy signals or other failures. It
is important to note that some early media will never transition to a 200
OK, and that early media can express something other than a provisional
condition.

- The draft offers no account of forking. This is a critical part of the
early media story, and I think a source of numerous requirements. There are
reasons why out-of-band notifications of status (response codes) are
preferable to in-band indications of status (early media), and forking is
one of them. If I send a request that is forked to ten endpoints, and all of
them start transmitting early media to me at the same time, I may have at
least two problems: first, I may run into bandwidth constraints; second, I
have to sift through all of these media streams in order to differentiate
those that are merely providing ringing from those that are providing more
important status information. If I have ten remote ringbacks to choose from,
it is also somewhat unlikely that early media will prevent clipping - in
fact, the potential for clipping only becomes worse (since I can't listen to
all ten at once). It would be very useful to document how offer/answer could
interact with forking.

- The draft (and Gonzalo's text in the note below) explicitly considers two
factors in the signaling of early media: the status code and offer/answer. I
think there are at least two other factors that play a part in this:

o When the actual media is sent. Obviously, in the 'naive' early media case,
media can be received before any offer is answered. Similarly, the draft
suggests that even when a stream is set to 'inactive', there may be cases in
which media will be received (and accepted) for that inactive stream. Even
when an offer/answer exchange has completed, just because I accept an offer
with a 'sendonly' response does not mean that I am going to begin sending
media immediately. I think that a more detailed account needs to be given of
the relationship between making/accepting an offer for a stream and playing
media for that stream.

o When received media is played. If I make an offer with a 'sendrecv' or
'recvonly' stream, does that necessarily commit me to play (render to the
user) any media received over that stream? Are there cases in which a user
agent will drop that media on the floor (like the mute button case described
earlier in the thread)? PSTN gateways could, for example, choose to discard
all forward media until they receive an ANM even if they initially accept a
sendrecv offer in order to minimize clipping. Is that part of a solution for
forward clipping?

- The 'media clipping' section needs to differentiate between forward and
backward clipping, and explain what risks are associated with each of these.
When risks of backward clipping (audio from the callee is lost) are greater,
forward clipping is also a problem. 

- The draft currently makes no mention of middleboxes. As much as we may
dislike them, the role of middleboxes in early media is frequently a topic
of discussion and no small confusion. If a middlebox refuses to open
pinholes until certain offers and/or answers are sent, this would complicate
the early media guidance given by the draft. While we don't necessarily need
a solution to this yet (we need to define early media before we start
figuring out how middleboxes interact with it), at least the draft could
explain what the problem is.

- The Security Considerations of this draft will be tricky.

Some other notes inline (especially the note on the semantics of 180).

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 12:10 AM
> To: William Marshall
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: Early media draft
> 
> 
> Bill,
> 
> > What won't work, in my comment above, is any attempt by a UA to assume
> > the media being received over an inactive stream will only last a short
> > period of time.  The distribution has a long tail, and "short" could be
> > many seconds.  I'd consider that essentially forever, since it is not
> > just a few RTP packets.
> 
> You are talking about a problem that has always been present in SIP, and
> that has been already discussed several times in MMUSIC. It is not at
> all related with the early media draft. 

From a sheer process perspective, I'm not sure this is the right philosophy
to approach this draft. In fact, I think the SIPPING early media draft
should provide some guidance about these sorts of issues. We need a draft
that sets the record straight, regardless of whose problem it is. Even if
we're only reiterating conclusions that have been reached in other lists,
just documenting that in this draft would be immensely valuable, I think.
This issue undoubtedly spans several WGs. If we uncover requirements for
MMUSIC in the course of this work, they will of course have to go to MMUSIC,
but I don't think that means we can't ascertain those needs here.

[snip]
> 
>  
> > I think a response code of 180 means generate local ringback,
independent
> > of whether media streams are a=sendrecv or a=inactive.  The de-coupling
> > is good, and there is no reason to break it here.
> 
> No. As it has been pointed out literaly millions of times already, a 180
> response only means that the remote user is being alerted. It does not
> say anything about ringing, remote or local.
> 

Actually, RFC3261 21.1.2 has this to say about the 180 status code:

   The UA receiving the INVITE is trying to alert the user.  This
   response MAY be used to initiate local ringback.

So it does say something about local ringback. This is critically important.

When a callee sends a 180 status code, it is a matter of user interface and
local policy (as you have rightly asserted) whether or not any audible
ringtone is generated. What this means, however, is that the callee has no
way of knowing whether or not the caller's UA will generate local ringback
when a 180 (without answer) is sent. This is part of the early media
problem, and it should not be glossed over.

Even if 180 with SDP answer is sent, does that mean that audio media will
immediately commence in the backwards direction? What if it doesn't
commence? Should local ringtone then be generated? The point is that in this
case offer/answer doesn't actually resolve the question of whether or not
you should generate local ringback; it just manages media streams.
Generating ringback is a matter of local policy that is virtually orthogonal
to offer/answer.

> Here you have a brief review of the contents of the draft, so that we
> are clear about what the decoupling means.
> 
> Your UA has two sources of information:
> 
> 1) status of session establishment (status codes)
> 2) presence or absence of incoming media (SDP direction attributes)
> 
> With these two pieces of information, you make the decision about
> whether or not generating ringback tone, graphical alterting, or
> whatever, based on your local policy.
> 
> And if you want to have a large network where all the elements behave in
> the same, expectable way, you should standardize the local policy for
> all the elements in the network.
> 
> Thanks,
> 
> Gonzalo
> _______________________________________________
> 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: Henry Sinnreich <[email-masked]>
Date: Wed, 27 Nov 2002 18:11:35 -0600

From the shared experience manifested on list, if we can document some
practical call flows, such as the one discussed when calling the
American Airlines IVR, the draft would be productive.

It is the good habit of giving frequent practical examples that have
made SIP drafts a success. Please help keep it this way.

Without examples, the credibility of the draft would not be very high.

Thanks, Henry 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Peterson, Jon
> Sent: Wednesday, November 27, 2002 6:53 AM
> To: 'Gonzalo Camarillo'
> Cc: [email-masked]
> Subject: RE: [Sipping] Re: Early media draft
> 
> 
> 
> I had the opportunity to read the early media draft tonight, 
> and I have a few notes.
> 
> - I think the informational scope of the draft is perhaps a 
> little too narrow. Ideally, this draft should address the 
> requirements that people tend to raise about early media by 
> showing how to apply existing standards, and also (if 
> necessary) provide any new mechanisms that are necessary to 
> satisfy the requirements. I would be cautious about ruling 
> out anything out of scope a priori - at this stage, I think 
> people still want to talk about requirements.
> 
> - I am surprised that the draft today does not discourage the 
> use of early media. SIP already has a very rich way of 
> communicating provisional status information (through 
> response codes, and especially the reason phrase that follows 
> a response code). This begs the question of why people should 
> use early media at all. Vanity applications, like playing 
> some kind of custom in-band ringtone, should be severely 
> discouraged. The only cases that I am aware of in which early 
> media is necessary to provide status information is when SIP 
> is interworking with another protocol (presumably in the 
> PSTN) and gateways are unable to determine the status of the 
> call. What is the value of generalizing early media beyond 
> PSTN-SIP interworking today?
> 
> - The draft focuses quite a bit on early media for ringback, 
> but not so much on other forms of in-band status, notably 
> busy signals or other failures. It is important to note that 
> some early media will never transition to a 200 OK, and that 
> early media can express something other than a provisional condition.
> 
> - The draft offers no account of forking. This is a critical 
> part of the early media story, and I think a source of 
> numerous requirements. There are reasons why out-of-band 
> notifications of status (response codes) are preferable to 
> in-band indications of status (early media), and forking is 
> one of them. If I send a request that is forked to ten 
> endpoints, and all of them start transmitting early media to 
> me at the same time, I may have at least two problems: first, 
> I may run into bandwidth constraints; second, I have to sift 
> through all of these media streams in order to differentiate 
> those that are merely providing ringing from those that are 
> providing more important status information. If I have ten 
> remote ringbacks to choose from, it is also somewhat unlikely 
> that early media will prevent clipping - in fact, the 
> potential for clipping only becomes worse (since I can't 
> listen to all ten at once). It would be very useful to 
> document how offer/answer could interact with forking.
> 
> - The draft (and Gonzalo's text in the note below) explicitly 
> considers two factors in the signaling of early media: the 
> status code and offer/answer. I think there are at least two 
> other factors that play a part in this:
> 
> o When the actual media is sent. Obviously, in the 'naive' 
> early media case, media can be received before any offer is 
> answered. Similarly, the draft suggests that even when a 
> stream is set to 'inactive', there may be cases in which 
> media will be received (and accepted) for that inactive 
> stream. Even when an offer/answer exchange has completed, 
> just because I accept an offer with a 'sendonly' response 
> does not mean that I am going to begin sending media 
> immediately. I think that a more detailed account needs to be 
> given of the relationship between making/accepting an offer 
> for a stream and playing media for that stream.
> 
> o When received media is played. If I make an offer with a 
> 'sendrecv' or 'recvonly' stream, does that necessarily commit 
> me to play (render to the
> user) any media received over that stream? Are there cases in 
> which a user agent will drop that media on the floor (like 
> the mute button case described earlier in the thread)? PSTN 
> gateways could, for example, choose to discard all forward 
> media until they receive an ANM even if they initially accept 
> a sendrecv offer in order to minimize clipping. Is that part 
> of a solution for forward clipping?
> 
> - The 'media clipping' section needs to differentiate between 
> forward and backward clipping, and explain what risks are 
> associated with each of these. When risks of backward 
> clipping (audio from the callee is lost) are greater, forward 
> clipping is also a problem. 
> 
> - The draft currently makes no mention of middleboxes. As 
> much as we may dislike them, the role of middleboxes in early 
> media is frequently a topic of discussion and no small 
> confusion. If a middlebox refuses to open pinholes until 
> certain offers and/or answers are sent, this would complicate 
> the early media guidance given by the draft. While we don't 
> necessarily need a solution to this yet (we need to define 
> early media before we start figuring out how middleboxes 
> interact with it), at least the draft could explain what the 
> problem is.
> 
> > > What won't work, in my comment above, is any attempt by a UA to 
> > > assume the media being received over an inactive stream will only 
> > > last a short period of time.  The distribution has a long 
> tail, and 
> > > "short" could be many seconds.  I'd consider that essentially 
> > > forever, since it is not just a few RTP packets.
> > 
> > You are talking about a problem that has always been 
> present in SIP, 
> > and that has been already discussed several times in 
> MMUSIC. It is not 
> > at all related with the early media draft.
> 
> From a sheer process perspective, I'm not sure this is the 
> right philosophy to approach this draft. In fact, I think the 
> SIPPING early media draft should provide some guidance about 
> these sorts of issues. We need a draft that sets the record 
> straight, regardless of whose problem it is. Even if we're 
> only reiterating conclusions that have been reached in other 
> lists, just documenting that in this draft would be immensely 
> valuable, I think. This issue undoubtedly spans several WGs. 
> If we uncover requirements for MMUSIC in the course of this 
> work, they will of course have to go to MMUSIC, but I don't 
> think that means we can't ascertain those needs here.
> 
> [snip]
> > 
> >  
> > > of whether media streams are a=sendrecv or a=inactive.  The 
> > > de-coupling is good, and there is no reason to break it here.
> > 
> > No. As it has been pointed out literaly millions of times 
> already, a 
> > 180 response only means that the remote user is being 
> alerted. It does 
> > not say anything about ringing, remote or local.
> > 
> 
> When a callee sends a 180 status code, it is a matter of user 
> interface and local policy (as you have rightly asserted) 
> whether or not any audible ringtone is generated. What this 
> means, however, is that the callee has no way of knowing 
> whether or not the caller's UA will generate local ringback 
> when a 180 (without answer) is sent. This is part of the 
> early media problem, and it should not be glossed over.
> 
> Even if 180 with SDP answer is sent, does that mean that 
> audio media will immediately commence in the backwards 
> direction? What if it doesn't commence? Should local ringtone 
> then be generated? The point is that in this case 
> offer/answer doesn't actually resolve the question of whether 
> or not you should generate local ringback; it just manages 
> media streams. Generating ringback is a matter of local 
> policy that is virtually orthogonal to offer/answer.
> 
> > And if you want to have a large network where all the 
> elements behave 
> > in the same, expectable way, you should standardize the 
> local policy 
> > for all the elements in the network.
> > 
> > Thanks,
> > 
> > Gonzalo
> > 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
> > 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>