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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Nov 2002 13:33:28 -0500

William Marshall wrote:
> 
> Paul wrote:
> > .... When offering to begin sending, why shouldn't the
> > offerer wait for the answer before beginning to send? The offerer always
> > gets a form of confirmation with the answer. And it is possible that the
> > answer will say inactive.
> 
> While this approach makes it easy for the endpoint to set up the
> data paths through DSPs, etc, it causes a huge problem with post-pickup
> delay.  The problem is the extra offer/answer exchange needed after
> the destination answers.
> 
> Typical scenario goes like this:
>         called party:   answer phone, say "Hello"
>                         hear nothing, hangup
>                         (and is upset about a telemarketer calling)
> 
>         calling party:  hear ringback, then silence
>                         then call disconnects
>                         (and is upset about being billed for completed call)
> All because the media for the "Hello" wasn't sent because the offer/answer
> exchange had not completed in time.  And it is the calling party's UA that
> goofed.

Look at what I wrote in my earlier message. It doesn't behave at all like the above.

Assuming the calling party sent an offer in the invite with SENDRECV or RECVONLY (this would be the normal case I think), the calling party should immediately begin listening, and presumably playing out what is received, subject to interactions with ringback - a separate issue. But it doesn't enable sending until it receives the answer. This is no big deal. The caller will hear the "Hello", and the answer should normally be received in time so that the caller's response to the hello can be sent.

Meanwhile, the called party starts sending and receiving when it sends the answer, which is plenty soon to send the "Hello" and receive the response.

In all cases both ends are operating in a way consistent with the SDP they are exchanging.

> 
> There is already a race between the start of media packets and the 200-OK.
> It is likely in most cases that the media will arrive first, since it
> has fewer processing hops along the way.  Adding another round-trip
> signaling exchange makes the post-pickup delay problem far worse.

There are only extra round trips for more complex call flows, such as ones that explicitly set the stream inactive initially. This is presumably done for cause, so why second guess it?

	Paul
_______________________________________________
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: "Yadavalli, Satyamurthy" <[email-masked]>
Date: Tue, 26 Nov 2002 14:48:33 -0500

please see below.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 2:12 PM
To: 'Gonzalo Camarillo'
Cc: [email-masked]'; [email-masked]'
Subject: [Sipping] RE: Early media draft

Gonzallo, 

You are missing my main point. See below. 

> Having a stream set up in sendrecv mode indicates that you 
> intend to send media. Otherwise, you would have set it up in 
> inactive mode. Therefore, if you intend to send media, and 
> the session has not been established, you will be sending 
> early media... 

Having a stream set up in sendrecv modes indicates that you 
intend to send media: I agree with that. It does not however 
indicate exactly when it will occur, and it does NOT indicate 
that you will necessary provide in-band ringing. 

What I really disagree with is the recommendation in point 2 
of section 3 for the pots-like UA. It basically says that it 
is all right to ignore the 180 if there is a sendrecv (or 
recvonly) and NOT provide an alerting indication. 

This is against the loosely-coupled mechanism that you are proposing 
(which I agree with). The sendrecv tag should have no impact on 
the meaning of 180. There are totally unrelated. 

If a phone manufacturer follows the recommendation in the draft, it 
will end-up with phones that don't ring most of the time when a call is 
made to a PSTN gateway. The reason is as follows: 

Contrary to what is mentioned in the draft, there is not 
normally a tight coupling in the traditional PSTN between 
ringback and media. The use of in-band ringback is determined 
normally by the far end of the call, not the originating PSTN 
gateway. If a SIP UA makes a call through a PSTN gateway, the 
PSTN does not know right away if the far end will use out-of-band 
ringing or in-band ringing. It will cut-through the media as soon 
as possible because there COULD be some in-band ringing. This 
will result in sendrecv stream. However, the far end switch may 
decide to send or not in-band ringing, and it will provide an 
indication of which option it is choosing (it depends on if it is 
interworking with an analog trunk or not, and other critierias). 
But the point is that there will be an out-of-band indication 
of wether or not an out-of-band alerting should be provided to the 
user. If it does NOT send in-band media (because there is no 
analog trunk interworking), the user will get silence on the line 
if his phone manufacture followed this draft. 

This would be very bad. And I can assure you that this is exactly 
what will happen. 

I am just saying that the paragraph that states: 

        2. If the callee is being alerted and there are no audio 
           streams in sendrecv or recvonly mode, play a locally- 
           generated ringback tone to the user. 

Should be changed to: 

        2. If the calles is being alerted, play a locally- 
         generated ringback tone to the user. 

This would introduce a lot of consistency with the graphical 
UI recommendation. 

The logic would be very simple: 

1. sendrecv -> play the media 
2. 180 -> play the alerting (in-band or or not, depending on terminal
design) 

[Satyamurthy Yadavalli] 

I don't believe its appropriate to use 180 response to decide. If the UA-B
which is sending the early media doesn't want to send any more early media
(including a remote ring back tone) it just sends an UPDATE with appropriate
direction attributes (recvonly or inactive; update may be sent before or
after 180 doesn't matter). UA-A based on this UPDATE realizes that there is
no  more remote early media and may choose to start a local ring if it
already received a 180 or wait until it receives a 180 to start off local
ring back or not even care about the 180. That's a local policy of the UA.
180 is an optional response anyway.

-satya

The rest of my original email simply pointed out that if this followed, 
there would be less of a need to use the "inactive" tags every 
single time a call is made to a PSTN gateway.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Nov 2002 15:14:41 -0800

> Hi Francois,
> 
> One small clarification: does your proposal mean that IF the 
> PSTN network provides remote ringback there would be no 180 
> ringing? Assuming the stream mode is sendrecv, you would 
> simply pass the early media with the remote ringback? You 
> would not indicate on the SIP signalling level that the 
> called PSTN user has been alerted?

Hi Christer,

No it wouldn't mean that IF the PSTN network provides remote
ringback, there would NECESSARILY be no 180 ringing. In my view,
those two things are independent. But it certainly COULD happen.

The sendrecv would mean that there might be some media to listen
to. The 180 would mean that the user is being alerted. Those two
things are independent.

1. The case you point out, i.e., where there is a sendrecv and no
180 would certainly happen in the real world when the call goes through
a PSTN gateway and terminates on an analogue interface. There could 
not be any 180 in that case because there is no means of knowing that
the user is alerted (could be busy, reorder tone, etc.). 

2. But in certain cases, the gateway DOES know that the far end
is being alerted AND that in-band media is available. In that case
it can send both the sendrecv and the 180. This will cause no harm.
The phone can just do whatever it is supposed to do when receiving
a 180 (i.e., text indication, or providing local ringback overriding
any in-band voice). 

3. And finally there is the last case (the one that doesn't work if you
turn off the normal treatment of 180, as per the example in the draft). 
This case is when there is a 180 and a sendrecv but NO inband ringing. This 
will happen often when a PSTN gateway makes a call on an ISDN interface and
stays ISDN end-to-end (because in that case, many implementations will 
behave like "normal" SIP and will NOT provide in-band ringing). 

I believe that Gonzallo's draft addresses the first two cases, but not
case 3 (because case 2 and 3 are indistinguishable).

I think this will proposal will take care of all cases.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Nov 2002 15:36:29 -0800

> I don't believe its appropriate to use 180 response to decide. If the UA-B
which is sending the 
> early media doesn't want to send any more early media (including a remote
ring back tone) it just 
> sends an UPDATE with appropriate direction attributes (recvonly or
inactive; update may be sent 
> before or after 180 doesn't matter). UA-A based on this UPDATE realizes
that there is no  more 
> remote early media and may choose to start a local ring if it already
received a 180 or wait until
> it receives a 180 to start off local ring back or not even care about the
180. That's a local 
> policy of the UA.  180 is an optional response anyway. 

As stated before, UA-B can not know for sure if there is ringback being sent
from the far end, but it does not if the call terminates elsewhere in the
PSTN.

Of course, UA-A can decide NOT to provide in-band ringing based on 180. That
is indeed a local 
policy. But we shall not tell people who will be implementing SIP phones by
the million that
if there is a sendrecv stream it means that there will be in-band ringing.

I think a lot of people would be very unpleasantly surprise with their new
pots-phone-that-doesn't 
ring...

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 27 Nov 2002 06:27:47 -0600

I good example I remember we were wrestling with is calling certain
airline info system and getting voice prompts before the call with the
regular IVR is established, such as American Airlines. Has there been a
similar experience, and how was it solved?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of William Marshall
> Sent: Tuesday, November 26, 2002 8:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: Early media draft
> 
> 
> Gonzalo,
> 
> > I know that coming from the PSTN world is difficult to digest this 
> > concept, but this is the way it is. SIP is not the PSTN.
> 
> You missed the whole point.  That is exactly what I was 
> saying. Nothing in my comment was addressing the PSTN.  It is 
> purely a synchronization problem in SIP, which comes about 
> because of the loose coupling between the media description 
> passed in the signaling and the media itself; it is not a 
> problem at all in the PSTN. However, customer expectations 
> that their media will not be clipped are independent of the 
> mechanism, whether it is being carried over 
> IP or PSTN or FedEx.
> 
> The conclusion is that maintaining an accurate coupling 
> between the signaling and the media has significant 
> complications in common use cases, that are just not worth 
> the effort.  We need to deal with the inconsistent cases in 
> SIP for short periods, at least, and by doing so we solve the 
> general case as well.
> 
> > >  Also note that due to
> > > possibilities of collision of offers, and random retry intervals, 
> > > the case of playing out media on an inactive stream may 
> last a long 
> > > time.
> > 
> > When you think of a long time, which order of magnitude are you 
> > thinking of? Some hundreds miliseconds?... one second?... if you 
> > cannot tolerate that, you should use a tightly coupled architecture 
> > like the one provided by ISUP.
> 
> Just like the backoff problem with 802.3, the distribution 
> has a long tail.  The point is that the UA needs to deal with 
> it, and any sort of intelligent 
> "play-media-for-only-a-little-while-on-inactive-channel"
> isn't going to work.  Again, the UA needs to deal with the 
> inconsistency between signalled media characteristics (SDP) 
> and the actual media.
> 
> While I don't doubt that having direction attributes would be 
> useful information to drive a GUI, I think it can be better 
> determined locally by what is actually being received, than 
> by putting a load on the signaling entities.  Leaving the 
> decision to re-offer up to local policy means the receiver 
> can't depend on it, so needs the alternate indication if it 
> wants to present such a GUI.
> 
> > However, your proposal does not address when to generate local 
> > ringback.
> 
> I was addressing pure SIP IP-to-IP issues, not PSTN 
> interworking. Local ringback is (or should be) dealt with in 
> the PSTN interworking drafts.  Hopefully it was for ISUP.
> 
> Bill Marshall
> [email-masked]
> 
> -----original message-----
> Date: Tue, 26 Nov 2002 15:57:46 +0200
> From: Gonzalo Camarillo <[email-masked]>
> To: William Marshall <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Sipping] Re: Early media draft
> 
> Bill,
> 
> inline:
> 
> William Marshall wrote:
> > 
> > The key statement in the Early media draft is made in 
> section 2.3, in 
> > recognizing that race conditions happen and need to be handled:
> >         ... If the remote UA receives the first packets of 
> audio before
> >         receiving the new offer, it will consider those 
> audio packets as
> >         arriving over an inactive stream.  To avoid this 
> situation, it is
> >         recommended that UAs accept media over inactive and sendonly
> >         streams.
> > 
> > I know I've said this before, but it is worth repeating 
> (over and over)
> >                 Clipping is BAD
> > 
> > Whether it be early media, regular media, inband ringback, inband 
> > announcements, __Clipping is BAD__
> > 
> > I believe that statement at the end of section 2.3 should be raised 
> > several levels in requirement-eese, to a MUST.
> 
> So far this is an informational document, so there is no room 
> for MUSTs, SHOULDs, MAYs, etc... if we decide in the future 
> to make it a BCP or a PS effort we will take care of the 
> strength of the requirements.
> 
> So far, that paragraph addresses you issue (i.e., media clipping).
> 
> > 
> > Given that a UA behaves according to this rule, I really see no 
> > utility in whether the SDP has a line "a=inactive" or "a=sendonly" 
> > versus "a=sendrecv".  In all cases if media is received, it 
> is played.
> > 
> > It seems the only reason to re-offer changing a=inactive to 
> a=sendrecv 
> > is to make the "paperwork" match reality.  Though we all do this 
> > frequently, I doubt if anyone considers it worthwhile effort.
> 
> What you call "paperwork matching reality", is a product of 
> the loosly coupled architecture that SIP uses. In the PSTN 
> you do not have this problem, because signalling and media 
> are tightly coupled.
> 
> I know that coming from the PSTN world is difficult to digest 
> this concept, but this is the way it is. SIP is not the PSTN.
> 
> You have the same "problem" with initial INVITEs. You have to 
> listen to RTP even before you receive any SIP response.
> 
> >  Also note that due to
> > possibilities of collision of offers, and random retry 
> intervals, the 
> > case of playing out media on an inactive stream may last a 
> long time.
> 
> When you think of a long time, which order of magnitude are 
> you thinking of? Some hundreds miliseconds?... one second?... 
> if you cannot tolerate that, you should use a tightly coupled 
> architecture like the one provided by ISUP.
> 
>  
> > A natural consequence of trying to make the SDP match the 
> media flow 
> > is to re-offer every time the mute button is pressed on the phone.
> 
> Having the direction attributes matching what you inted to do 
> is useful when the other end might be using this information 
> to drive GUIs. This is the case when the session is being 
> established (i.e., early dialogs). If in the middle of a 
> session you believe that the remote user might find useful to 
> know that you have pressed the mute button, you should 
> certainly send a new offer. If you believe that this 
> information is not useful, you can save the offer/answer exchange.
> 
>  
> > For the sake of simplicity, I vote for just putting "a=sendrecv" in 
> > the SDP, and rendering all media received.
> 
> 
> We have more direction attributes than sendrecv because 
> people find it useful knowing the current status of a stream.
> 
> However, your proposal does not address when to generate 
> local ringback. How do you know that the other end does not 
> intend to send in-band rinback tones?... I guess I know the 
> answer. You will use 183 and 180 status codes to convey this 
> information. Such proposal is very much PSTN oriented, and it 
> does not follow the SIP way of doing things.
> 
> Thanks for the comments,
> 
> Gonzalo
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: William Marshall <[email-masked]>
Date: Wed, 27 Nov 2002 09:31:00 -0500 (EST)

Francois,

We're almost in complete agreement here.  But I do worry about
the amount of "local policy" in here.  It is certainly local policy
whether to follow a standard or not, so in that sense all these
decisions of what to do are "local policy".  But there are certain
expectations of the customers (like receiving ringback signals)
that should be the default case in the specifications.  Other
endpoints should be able to depend on the UAC behavior, to do things
like offer destination-based services.  There really needs to be
enough of the UAC behavior specified to enable these services.

Specifically to your item #3 below, remember there is a race condition
between the 200-OK and the first media from the called party, which
the UAC sees as an audio stream being received while the user is
getting a locally-generated ringback.  To avoid clipping, I believe
this statement needs to be a MUST play out the received media.

Bill Marshall
[email-masked]

-----original message-----
From: "Francois Audet" <[email-masked]>
To: "'William Marshall'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [Sipping] Re: Early media draft
Date: Tue, 26 Nov 2002 17:22:51 -0800

Bill Marshall wrote:
> 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.  So even if the media says a=sendrecv, you 
> generate a local ringback on 180... then preempt it when any 
> media arrives.  I think this case just follows directly from 
> your previous argument about playing all media.  

Hi Bill, 

We are almost saying the same thing. 180 means generate local
ringback (if that is your policy in a pots set for example).

I do have somewhat of a different opinion on prempting it when
media does arrive. I would argue that another implementation
is to NOT preempt the locally generated tone. The media overrides
local ringing assumes that some media processing is required (to 
detect real media from silence for example, if desired). The 
other approach is for the local ringing to override in-band
media (which may be simpler to implement). The first approach
means that you'll get the far-end ringing pattern (like when
you dial from one continent to another on a PSTN line), and
the second approach means that you'll get the local ringing
pattern (like you would get on any SIP call with no in-band 
media).

I really think that it is a design decision on which method
should be used. However, in full agreement with you, if you do
decide to have media override local ringing, it should be
based on actual media, not the presence of sendrecv.

I would thus propose that we change the offending paragraphs 1
and 2 in sections 3 and 5) to the following (or something similar):

      1. If there is at least one audio stream being received
         play it out to the user. This imply that RTP packets
         are being received and has nothing to do with the
         sendrecv or recvonly tags. 

	2. If the callee is being alerted (i.e., 180 is received), 
         a locally-generated ringback tone can be played to 
         the user.

      3. In the case where both an audio stream being received
         and the user is alerted, it is a matter of local policy
         which tone will override the other.
_______________________________________________
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: William Marshall <[email-masked]>
Date: Wed, 27 Nov 2002 10:15:36 -0500 (EST)

> similar experience, and how was it solved?

I do worry that all this "local policy" in the caller will lead to
two types of UA's - those that can call American Airlines, and those
that can't.  Not a good situation.

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 27 Nov 2002 06:27:47 -0600
From: Henry Sinnreich <[email-masked]>
Subject: RE: [Sipping] Re: Early media draft
To: "'William Marshall'" <[email-masked]>,
        [email-masked]
Cc: [email-masked]

Thanks, Henry

---

From: William Marshall <[email-masked]>
Date: Wed, 27 Nov 2002 10:28:04 -0500 (EST)

Gonzalo wrote:
> 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.

There is a third source of information, which you are ignoring.

3) actual presence or absence of incoming media

Unfortunately the race conditions already discussed force this to
be one of the items involved in the "local policy", whether this
information is made available to the signaling layer in a UA or 
not.  The one simple "local policy" (which I still believe should
be a MUST-strength requirement) is to always play the received media.

My claim still is that with (3), any use of (2) is irrelevent.

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 27 Nov 2002 10:09:59 +0200
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
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. The general problem is:

I send a re-INVITE with a new offer. When can the UAs start using the
new session parameters (e.g., codecs, IP addresses, port numbers...)?

If the UAC is unable to continue using the old parameters, it will
probably start using new parameters right away, and if the re-INVITE
fails, it will terminate the session.

Does the UAS need to wait for the ACK before using the new parameters?
What about if it is an UPDATE?

As you can see, these are issues that are caused by the loose coupling
SIP uses.

If you have some proposals to resolve them, they belong to the
offer/answer work (MMUSIC) or maybe to the main SIP spec (SIP). The
early media draft is informational in nature, and uses mechanisms
defined elsewhere. Therefore, I do not think yours is a problem related
to the early media draft. You are speaking about a general SIP problem.

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

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Nov 2002 15:12:53 -0500

In the case in which a request is forked, and two media streams are returned
to the UAC from different UASs, which media stream MUST the UAC play?

Jon Peterson
NeuStar, Inc.

> From: William Marshall [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 7:28 AM

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Nov 2002 15:29:32 -0500

I hope we can all agree that sending comfort noise over RTP is not a
practice we should not recommend for native SIP. Comfort noise should be
generated by the UAC when it deems necessary (perhaps when there is any
provisional response, even a 100). Although the PSTN may attempt to inflict
provisional comfort noise on a SIP network, I would hope for the sake of
conserving bandwidth alone that a PSTN gateway would weed out comfort noise
with silence suppression rather than sending it over RTP.

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 7:49 AM
> To: William Marshall
> Cc: [email-masked]; [email-masked];
> [email-masked]
> You have touched on one element that I had not seen before, 
> the possibility 
> of comfort noise.  It seems that there are several "factors" 
> to the local 
> decision on when to inject ring-back:
> 
> 180 or 18x received:  for 180 MAY inject, for 18x don't inject
> 
> encapsulated ISUP:  might indicate alerting, and optionally 
> might indicate 
> that ring-back is inband (present when PSTN GW is used)
> 
> SDP status:  backward path might have been offered, and might 
> have been 
> accepted
> 
> RTP status:  3 possibilities:  1) no RTP being received, 2) RPT with 
> ring-back or some type of announcement, 3) comfort noise
> 
> Unless there is some type of requirement to NOT send comfort 
> noise prior to 
> Answer, then the reliance of receipt of RTP without actually 
> analyzing it 
> to detect some type of ring-tone, is unreliable, given the 
> different types 
> used around the world is problematic.
> 
> As evidenced by this email thread, basing decisions on SDP 
> status leads to 
> potential clipping problems.
> 
> Relying on ISUP, while more explicit, should not be the basis 
> of general 
> rules for all of SIP.
> 
> That leaves 180 as the only real indicator left.  As Jon 
> pointed out, that 
> is the preferred mechanism for signaling the ringback, due to forking 
> problems.  And as others have pointed out the call and media 
> are loosely 
> coupled.  And as you can see, I prefer explicit signals rather than 
> inferences from media.
> 
> This discussion seems to go around in circles, but hopefully, 
> the pros and 
> cons of each possible indication will be spelled out for the 
> GW or phone 
> implementors to take into consideration.
> 
> Mike
> 
> 
> At 09:52 AM 11/27/2002 -0500, William Marshall wrote:
> >Christer,
> >
> >you wrote (in part, full message below):
> > > Now, what happens if the early media stops? Should I 
> start generating
> > > local ringback again? How long should I wait before I 
> start doing it
> > > (there may be long pauses also in early media)?
> >
> >While I would tend to agree this is a good decision to leave as local
> >policy, there are a couple of additional considerations to make.
> >
> >The UAC really can't distinguish between "early" media and 
> "first part
> >of regular" media, due to the race between RTP and 200-OK.  If the
> >regular media includes silence suppression (one of the variations
> >what doesn't say to play comfort noise), then the UAC may fill
> >the silence with local ringback.  Please try to avoid this.
> >Another 180 certainly clarifies any confusion; perhaps that should
> >be recommended for a UAS that intentionally stops sending 
> early media.
> >
> >Bill Marshall
> >[email-masked]
> >
> >Date: Wed, 27 Nov 2002 12:22:53 +0200
> >From: Christer Holmberg <[email-masked]>
> >To: Francois Audet <[email-masked]>
> >Cc: "'William Marshall'" <[email-masked]>,
> >         "[email-masked]'" 
> > <[email-masked]>,
> >         "[email-masked]'" <[email-masked]>
> >Based on your proposal, assume I receive 180 and start 
> generating local
> >ringback. Then I start receiving early media. Now I make the 
> decission
> >(based on local policy if you like) to stop generating the local
> >ringback, and play the early media.
> >
> >Now, what happens if the early media stops? Should I start generating
> >local ringback again? How long should I wait before I start doing it
> >(there may be long pauses also in early media)?
> >
> >There may be cases where I actually should start generating local
> >ringback again (the B2BUA who generated the early media contacts the
> >UAS, which will not generate early media, for example), but 
> how will I
> >know? Local policy? Another 180 "resets" the early media 
> handling, and
> >again I may start generating local ringback until I receive possible
> >early media again?
> >
> >Regards,
> >
> >Christer Holmberg
> >Ericsson Finland
> >
> >
> >Francois Audet wrote:
> >
> > >
> > >
> > > Bill Marshall wrote:
> > > Bill Marshall also wrote in another message:

---

From: Michael Hammer <[email-masked]>
Date: Wed, 27 Nov 2002 16:34:28 -0500

Jon,

Taking this a step further.  When using silence suppression, I was under 
the impression  that a periodic RTP was sent indicating suppression.  When 
making reference to receiving early media RTP streams, and stopping local 
ringing to play media, I assume that such RTP receipt is not applicable.

Mike

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 14:06:09 -0800

> > regular IVR is established, such as American Airlines. Has 
> there been 
> > a similar experience, and how was it solved?
> 
> I do worry that all this "local policy" in the caller will 
> lead to two types of UA's - those that can call American 
> Airlines, and those that can't.  Not a good situation.

Right. American Airlines should send a 183 with SDP in that case. Every
UA should support this. It can not send a 180 because nobody is being
alerted.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 14:07:42 -0800

> Unfortunately the race conditions already discussed force 
> this to be one of the items involved in the "local policy", 
> whether this information is made available to the signaling 
> layer in a UA or 
> not.  The one simple "local policy" (which I still believe 
> should be a MUST-strength requirement) is to always play the 
> received media.
> 

Couldn't agree more. In fact, (2) is very misleading and
will often result in silence when ringing is expected by the 
user.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 14:17:02 -0800

Right, I'm also confused by Jon's comment.

When silence suppression is used, you definitively need to send periodic 
comfort noise frames. This is how it works.

Jon, are you just saying that you don't recommend sending comfort noise as
the
first packets of an audio stream? (i.e., don't send silence until you have
started
sending non-silence packet).

> Sent: Wednesday, November 27, 2002 1:34 PM
> To: Peterson, Jon
> Cc: William Marshall; [email-masked]; 
> [email-masked]; Audet, Francois [SC100:4K02:EXCH]

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 14:52:06 -0800

> generating local ringback. Then I start receiving early 
> media. Now I make the decission (based on local policy if you 
> like) to stop generating the local ringback, and play the early media.
> 
> Now, what happens if the early media stops? Should I start 
> generating local ringback again? How long should I wait 
> before I start doing it (there may be long pauses also in 
> early media)?

My personal view is that since my 180-induced locally-generated tone
will override the in-band media, it will never have stopped playing.

> There may be cases where I actually should start generating 
> local ringback again (the B2BUA who generated the early media 
> contacts the UAS, which will not generate early media, for 
> example), but how will I know? Local policy? Another 180 
> "resets" the early media handling, and again I may start 
> generating local ringback until I receive possible early media again?

Again, my view is that if I wanted to go from alerting to in-band media,
I could send a 180 followed by 183). The 183 changes the status from
alerting
to progress (and if there is in-band media, it will be played). Yes, I do
recognize
that under certain situation this may cause clipping (but to be honest, I
haven't 
witness the problem so far).

If your local policy is to override the locally-generated media with the
in-band media 
(to avoid clipping), this 180-183-180 case works equally well.

To me it is pretty simple: if you have media to send, send it. If you know
the user
is alerting, send a 180. If you know the status changes from alerting to
progressing,
send 183 (and vice-versa). Isn't that how it is suppose to work?

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 15:06:34 -0800

Hi Bill, in the evironment that I've seen clipping was not an issue,
but I will agree with you that in many cases, it could be an issue.
The important point to me is that real media as opposed to a sendrecv
flag is the trigger.

What about this (again sections 3 and 5 concerning POTS-like SIP phones):

1. If there is at least one audio stream being received,
   play out the audio received over that stream.

2. If the callee is being alerted (i.e., 180 is received), play a 
   locally generated ringback tone to the user.

3. If the callee is both being alerted and at least one audio stream
   is being received at the same time, it is a matter of local policy
   to determine which will override the other. In order to avoid clipping
   upond answer, it is recommended that the audio stream overrides
   the locally generated tones.

Would that be acceptable to you Bill?

Gonzallo?

> Francois,
> 
> We're almost in complete agreement here.  But I do worry 
> about the amount of "local policy" in here.  It is certainly 
> local policy whether to follow a standard or not, so in that 
> sense all these decisions of what to do are "local policy".  
> But there are certain expectations of the customers (like 
> receiving ringback signals) that should be the default case 
> in the specifications.  Other endpoints should be able to 
> depend on the UAC behavior, to do things like offer 
> destination-based services.  There really needs to be enough 
> of the UAC behavior specified to enable these services.
> 
> Specifically to your item #3 below, remember there is a race 
> condition between the 200-OK and the first media from the 
> called party, which the UAC sees as an audio stream being 
> received while the user is getting a locally-generated 
> ringback.  To avoid clipping, I believe this statement needs 
> to be a MUST play out the received media.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Nov 2002 19:33:22 -0500

My point was just that considering comfort noise as a meaningful form of
early media seems misguided to me. It would be perhaps the most degenerate
early media case - one in which some backwards media is sent that literally
has no value and expresses no status of the call. Clearly there is little
value in a client 'playing' such media if it receives it (in this point I
think Mike and I are in agreement), and therefore it would seem to be a
further caveat against the proposed "MUST play received media" wording.
Degenerate though it may be, it is definitely something that needs to be
documented in the early media draft one way or another. Maybe the wording
Francois suggests below (don't send comfort noise until after you've sent
non-silence) combined with the general sentiment expressed by Mike that a
UAC should not treat RTP comfort noise as early media that needs to be
rendered to the user would be a good start.
 
I didn't mean to argue for or against any strategy of implementing silence
suppression in RTP (RFC3389) or gateways. That much said, I do think any
bandwidth consumed by sending frames of comfort noise is wasted (and
potentially compounds the difficulty of managing the provisional phase of
dialogs at the UAC), and that this waste is avoidable. While a gateway
cannot be expected to differentiate audible busy from ring or what have you
(these have to be sent as early media), it can differentiate activity from
no activity. Playing a light volume of white noise in the UAC to let the
user know that a connection attempt is in progress should not be dependent
on the establishment of any media connection, I think. Comfort noise is
generated artificially to tell the user that the connection is still up, and
there are other means that a UA can determine that the connection is up than
receiving frames of comfort noise.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Wednesday, November 27, 2002 2:17 PM
To: 'Michael Hammer'; 'Peterson, Jon'
Cc: 'William Marshall'; [email-masked]';
[email-masked]'

> From: Michael Hammer [ mailto:[email-masked] <mailto:[email-masked]>
]

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Nov 2002 17:09:15 -0800

Perfect. I agree 100%.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2002 4:33 PM
To: Audet, Francois [SC100:4K02:EXCH]; 'Michael Hammer'
Cc: 'William Marshall'; [email-masked]';
[email-masked]'

Jon Peterson
NeuStar, Inc.