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

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

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]

-----original message-----
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]>
Subject: Re: [Sipping] Re: Early media draft

Hi Francois,

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:
> > 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.
>
> Bill Marshall also wrote in another message:
> > 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: Michael Hammer <[email-masked]>
Date: Wed, 27 Nov 2002 10:48:30 -0500

Bill,

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