Subject: 180 MAY ring? (was RE: [Sipping] new draft-ietf-sipping-isup-05 ( to Mike Hammer))

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Aug 2002 16:00:00 -0400

I think your analysis below is largely sound. As I suggested in my last
mail, we need to completely decouple our thinking about indicators for:

- whether or not in-band alerting should be generated
- whether or not early media will be sent

And as you say:

> So the question boils down to does 180 infer only that alerting is 
> occurring somewhere, or is it intended to indicate that alerting needs to 
> be injected in-band?  I understand that Alert-Infor can indicate that for 
> some cases, but perhaps not all.
> 

Agreed, this is an important question. So why does RFC3261 say that a UAC
MAY generate local ringback when 180 is received; why is it ambiguous at
all? For a number of reasons, most of which fall out of the fact that
RFC3261 is not about IP telephony. There are a number of sessions that might
be set up with SIP that are unrelated to telephony. There are also
telephony-oriented UACs, like some softphones, that have no reason to
generate any audible alerting - some textual alert in a display is more
appropriate. The term "local ringback" is specific to a SIP phone that has
roughly the same form factor and usage as black phones today - but SIP is
not specific to those sorts of devices. That goes a long way towards
explaining why this is a MAY.

That much said, for IP telephony cases, the text of RFC3261 suggests that
UACs supply locally-generated ringback when 180 is supplied. I don't think
there is much disagreement here among implementers - when a SIP "black"
phone receives a 180, it generates local ringback (any implementers here
disagree?). The fact that this happens is actually the basis of Bill's
concern - if it didn't happen, there would be no race condition. In my
opinion, nothing we say about SIP phones in sipping-isup-06 can supersede
the guidance given in RFC3261 - what we do must work with vanilla RFC3261
SIP phones if we want gateways to be usable by any old SIP device (which we
do). We need to figure out a way to work with the guidance given in RFC3261
to get the best system we can.

And agreed that Alert-Info does not make 180 any more or less explicit in
this regard. The suggestion that Alert-Info should be used to generate
'silence' or something is not realistic, I think. 

> It has been suggested that a 180 with no backward media cut-through means 
> inject ringing.   

Bill's argument is that a 180 with a backward media cut-through is
self-contradictory, or that it creates a race condition. I feel the right
way to address this is to discourage the simultaneous use of 180 and
backward media.

So how do we decide whether or not to send a 180 from a gateway? My
suggestion is that we don't send a 180 when the PSTN tells us that in-band
status information is available. As far as I can tell this solves Bill's
problem. Is there another problem here?

> In that case, I would expect ringing to continue to be 
> injected until the 200 OK is received, independent of any subsequent 
> Offer/Answers that occur subsequent to start of ringing. If that is not 
> desirable, then one must create some explicit signaling indication prior
to 
> the 200 OK that tells me to stop ringing.

Right, like a 183 containing an SDP offer for early media if some early
media extension were invented, or something like that. That point is that if
the initial ACM received from the PSTN suggests that no in-band status info
is available, and a subsequent CPG says that in-band status info actually IS
available, then maybe SIP should follow the PSTN and transition from local
alerting to backwards media in this case (this would be the rare case in
which this happens in the PSTN already). However, I think that circumstance
should be out of scope of sipping-isup-06, and rather be something that a
more fully-featured early media system might tackle.

Jon Peterson
NeuStar, Inc.

>  Again, I don't 
> want to assume 
> anything about a potential N media streams.  I don't want to get into 
> reading tea leaves.  That is a waste of resources at the MGC.
> 
> In general, I agree with Bill Marshall's assessment of this.
> 
> Mike
> 
> 
> At 01:14 PM 8/14/2002 +0300, Gonzalo Camarillo wrote:
> >Christer,
> >
> > > One thing there seems to be some disagreements on if sendrecv, 
> > indicating we have
> > > a two-way media path, means that there REALLY WILL be 
> early media (eg 
> > remote
> > > ringback).
> >
> >There is no disagreements. If a media stream is sendrecv, you may
> >receive media at any moment.
> >
> >All the proposals I hear try to change the meaning of the 
> offer/answer
> >exchange using a flag, a header field, or whatever... The 
> offer/answer
> >exchange is intended to give the current picture of the session,
> >regardless of whether it is an early dialog or a fully 
> established one.
> >
> >In all your proposals, a header field or flag says that what 
> you see in
> >the offer/answer is not really valid... but it will be valid when a
> >certain event happens (namely, the reception of a 200 OK), in the
> >future. I do not like this coupling.
> >
> >
> >In addition, you seems to be very worried about sending an 
> UPDATE/200 OK
> >to make the stream sendrecv at the same time you send the 
> 200 OK for the
> >INVITE... in the first place, why did you establish early 
> media if you
> >did not want to send anything? One possible reason is 
> manyfolks, where
> >you can request sendrecv QoS for an inactive stream, and then make it
> >sendrecv when you send the 200 OK for the INVITE. Do you 
> have any other
> >scenario in mind?
> >
> >Anyway, the extra UPDATE/200 OK is the price you pay for 
> having in synch
> >the actual media plane and your view of it (offer/answer exchange) at
> >every momment.
> >
> >What you are proposing is telling the other end what will 
> happen in the
> >future, so I can skip sending signalling messages when that event
> >occurs, and that is not a good idea.
> >
> >I guess that your way of implementing calls on hold would be 
> to send a
> >re-INVITE with your flag on, saying: "Now I make the stream inactive,
> >but when you receive an RTP packet, it will mean that the 
> call is not on
> >hold anymore, so act as if you had received a re-INVITE making the
> >stream sendrecv again", and you will save sending the second
> >re-INVITE... as I said, this seems like a bad idea to me.
> >
> >I would suggest folks think of general solution for general problems,
> >rather than thinking of "optimizations" for particular problems.
> >
> >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
> 

_______________________________________________
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: Thu, 15 Aug 2002 17:28:08 -0400

Jon,

One of the problems I have with the early media discussion is that the 
setup of the media path via the Offer/Answer exchange may be independent of 
the decision to actually put content into that media path.  So it is 
sometimes not clear which is being talked about.

In general, I do not like the idea of propagating a protocol element based 
on media turn-on or turn-off.  That is not the same as saying that receipt 
of a protocol element might cause media changes.  To do otherwise couples 
the call signaling and media in restrictive ways as you noted.

There are actually three cases here that need to be identified:
1) ACM/CPG with "no indication"
2) CPG indicating ringing in-band
3) CPG indicating ringing out-of-band (to be injected)

Let us say that 180 takes care of case 3)

Now, both 1) CPG/no indication, and 2) CPG/subscriber free map to 183.  On 
the egress side 183 maps to CPG/no indication.  So, what protocol element 
do I rely on to trigger indication of "subscriber free" instead of "no 
indication" in the outgoing CPG message?

If 180 takes care of 2) and 3) then I need a protocol element to 
distinguish the two.

Either way I am missing an indicator.

Mike