Subject: RE: [Sip] Local vs Remote ringback on 180

From: [email-masked]
Date: Fri, 21 Jun 2002 08:39:55 -0600

Christer,

 A question about all this.  Is this possibility of switching from far end
generated ringback(or other tones/announcements) to near end generated
ringback just theorectical, or do you know of an actual implementation or
planned implementation?

 I'd have to agree with Bob, there are defined mechanisms for changing early
media, and it may not be wise to special case ringback.  Those mechanisms
define what to do entirely based on signaling, no awareness is required of
what media may or may not be flowing.

 I suppose you do have a point though that if media from the UAS stops, a
concrete way to signal the UAC to begin locally generated ringback may be
useful.  If there is such a need, I suggest you write a draft for it.

John Hearty
Level3

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, June 21, 2002 4:42 AM
> To: Bob Penfield
> Cc: Jonathan Rosenberg; Flemming Andreasen; Mark Watson; [email-masked]
> Subject: Re: [Sip] Local vs Remote ringback on 180
> 
> 
> 
> Hi,
> 
> Bob Penfield wrote:
> 
> > ----- Original Message -----
> > From: "Christer Holmberg" <[email-masked]>
> > >
> > > Hi,
> > >
> > > > ----- Original Message -----
> > > > From: "Christer Holmberg" <[email-masked]>
> > > > <snip>
> > > > >
> > > > > I am not sure how it will work on the PSTN side, but 
> let's assume the
> > > > > following SIP scenario.
> > > > >
> > > > > I try to call my boss. I reach the company "switch" 
> (which, I guess,
> > in
> > > > this
> > > > > case has be implemented as some kind of SIP B2BUA) 
> which sends me a
> > 183
> > > > (with
> > > > > SDP) and start transmitting early media telling me 
> that I have now
> > reached
> > > > > this company, please wait, press this button for 
> this, press that
> > button
> > > > for
> > > > > that etc etc etc. Then, the switch "forwards" the 
> INVITE to the actual
> > SIP
> > > > > phone I'm calling to. Now, this SIP phone is not able 
> to generate any
> > > > early
> > > > > media at all, so it sends a 180 (without SDP). Now I 
> assume the switch
> > > > could
> > > > > only forward the 180 to the caller (via the PSTN GW), stop
> > transmitting
> > > > the
> > > > > early media, and expect the PSTN GW to generate a 
> local ringback tone,
> > > > since
> > > > > the called party has been reached.
> > > > >
> > > > > Now, one can argue that this is a complicated 
> scenario, which has
> > nothing
> > > > to
> > > > > do with the basic SIP etc etc. BUT, from the caller's 
> point of view
> > this
> > > > is a
> > > > > normal session setup. It receives the 183 (with SDP) 
> and 180 (without
> > SDP)
> > > > > within the same dialog, and has no idea what is 
> happening at the
> > remote
> > > > site.
> > > > >
> > > > The RTP session is controlled by SDP offers and 
> answers. If a session is
> > > > established, there would need to be a new offer/answer 
> exchange to
> > change
> > > > it. Stopping the RTP flow because the 180 does not have 
> SDP is the wrong
> > > > thing to do. Scenarios like this can be done with the 
> UPDATE method
> > which
> > > > allow the UAS to change the session. The UAS is 
> explicitly forbidden
> > from
> > > > sending subsequent offers in 18x responses (bis-09 line 
> 2119), but it
> > could
> > > > send them in UPDATE requests.
> > >
> > > First, I agree that the UAS is forbidden from sending a 
> subsequent offer
> > in a
> > > 18x, and I also think that using something like
> > > UPDATE for this purpose is too "expensive".
> > >
> > > However, let's assume the following thing: we do NOT 
> update the session.
> > >
> > > So, if the UAC receives a 183 with SDP an early session can be
> > established, and
> > > there MAY be early media - nobody says there MUST be 
> early media. Then,
> > when the
> > > UAS sends 180 without SDP the session still exists from a 
> signalling point
> > of
> > > view, but the UAS indicates that I will stop sending 
> early media and wants
> > the
> > > UAC to generate a local ringback tone. I don't think this 
> idea would break
> > any
> > > rule, would it (the session still exist, but the UAS 
> simply indicates it
> > won't
> > > send any early media - even if it would be "allowed" to 
> do so from a SIP
> > point
> > > of view).
> >
> > How does the UAS tell the UAC that it will stop sending 
> media without
> > updating the session description? A 180 does not mean that 
> the UAS will stop
> > sending media.
> 
> It DOES indicate that the UAC may/should/whatever generate 
> local ringback, so my
> proposal was that it at the same time shoud indicate that the 
> UAS is not sending
> early media -. again, even if the session on a SIGNALLING 
> level remains
> unchanged.
> 
> > What you are proposing would require that the meaning of 
> 180 change and then
> > the UAC would be required generate local ringback (it MAY
> > now).
> 
> The UAC would not be required to play ringback. The text bis 
> can still remain as
> "MAY play ringback tone". That would be an implementation 
> issue (also, the
> decission can be based what kind of node the UAC is, where in 
> the network it is
> situated etc etc etc), but the main point is that the UAC 
> would be aware that
> remote early media/ringback is NOT sent.
> 
> > Or are you proposing that there will be additional info in 
> the response that
> > will tell the UAC the media will stop? Either way it is not
> > backward compatible with either 2543 or bis-09. Also, there 
> would be two
> > mechisms to do the same thing.
> 
> My original question WAS if the SDP is a good way to indicate 
> local/remote
> ringback in the first place, but that is really not related 
> to my proposal above
> (where I do assume that the SDP is still used as a ringback 
> indicator).
> 
> > >Then, if the UAS for whatever reason is going to start 
> transmitting early
> > >media again, it could send eg a new 183, with the same SDP 
> as in the previous
> >
> > >183. Again, this SDP would not be a new offer, simply an 
> indication that the
> > GW
> > >should stop generating local ringback, and start "passing" 
> the RTP media
> > >to the PSTN side again (in general, eg in a PSTN GW case, 
> even if we have an
> > >early media session established between the GW and the 
> UAS, the GW may still,
> >
> > >for whatever reason, choose NOT to send any media to the 
> PSTN side...).
> > >
> > > How does this sound?
> >
> >
> > I'm sorry, I really do not like it because it changes the 
> way session state
> > is maintained. I think is is much cleaner to do session 
> state maintenance in
> > a consistent way with SDP offers and answers.
> 
> I don't think it changes the session state. The session still 
> remains (like I
> said earlier, just because we have a session it doesn't mean 
> that media MUST be
> sent). The UAC would simply choose not to forward any 
> possible media received
> (if the UAS, even if it sent 180 without SDP still for 
> whatever reason sends
> media) to the listener (to the PSTN network in the case of a GW).
> 
> > I don't agree that using UPDATE is too expensive. The 2 
> extra messages would
> > only happen in scenarios
> > where you need to stop or change the media.
> 
> I still don't understand why I would have to update the 
> signalling session state
> just because I choose not to send early media at some stage...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Jun 2002 13:00:43 +0300

Hi,

> ringback just theorectical, or do you know of an actual implementation or

Like I wrote earlier, this "switch" is very unlikely to take place if the remote
side consists of a single SIP node. I did give a scenario, where the remote side
consists of a "system" of SIP nodes, where this switch DID take place.

I guess I'm the wrong person to say if a scenario like that, or similar, is only
theoretical or not. I would be very interested in hearing the operators point of
view on this.

> what media may or may not be flowing.

Again, I am NOT proposing any change in the early media mechanism. I see it more
as CLARIFYING what IS already written (in bis-09 and the ISUP/SIP drafts).

> useful.  If there is such a need, I suggest you write a draft for it.

Again, that was my original question: can we really use the current
180-with/without-SDP mechanism for this (with the SDP simply as a ringback
indicator), or DO we need to define something new? :)

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland