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

From: "Francois Audet" <[email-masked]>
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.  

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.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Nov 2002 12:22:53 +0200

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

>          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