Subject: RE: 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 17:05:20 -0500

Since a lot of this discussion of backwards media is conflated with early
media mechanisms that have been proposed in the past, as well as the
offer/answer model, there is plenty of room for confusion. Just to be clear,
no issue has yet been raised in this discussion around 18x to my knowledge
that requires correction in sipping-isup-05 other than Bill Marshall's race
condition. I have not personally endorsed any solution for sipping-isup-06
in which an SDP offer or answer is present in any 180 or 183 - I think that
would be the purpose of a fully-featured early media system, which is not in
the scope of sipping-isup-0x. In my proposal I have consistently discussed
180 and 183 without SDP.

I think 180 Ringing takes care of ACM with 'subscriber free' as well as CPG
with 'out-of-band'. The other case, CPG 'in-band' or ACM with 'interworking
encountered' could be taken care of by 183. A gateway can even send 183 when
it receives an early ACM with 'no indication', because 183 does NOT mean
that the gateway is about to start sending early media (it is useful for
ISUP encapsulation, however, among other things); if a subsequent CPG with
'out-of-band' arrives, the gateway could even provide a subsequent 180. I
base this proposal on one distinction between 180 and 183 - that 180 will
probably create ringing in a SIP phone, and 183 probably won't. That is the
only salient fact in whether or not this race condition arises, as far as I
can tell. As a further deterrent to the race condition I also suggested that
a gateway (that supports no fully-featured early media system) should start
sending backwards media before sending a 18x code when in-band information
is available. This text would clarify the text of 7.2.6, and provide
clarification to the second and third paragraphs. Some ramifications on the
other direction (8.2.3) would also be explored.

Would it be possible with extensions, offers/answers in 18xs, and so on to
create a better way of doing early media? Yes. Does the method that I
propose resolve the race condition that Bill Marshall described? I think it
does. Is there more work to be done in a fully-featured early media system?
Assuredly. Will that early media system be proposed in sipping-isup-06? No.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 2:28 PM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: Re: 180 MAY ring? (was RE: [Sipping] new
> draft-ietf-sipping-isup-05 ( to Mike Hammer))
> 
> 
> 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
> 
> 
> At 04:00 PM 8/15/2002 -0400, Peterson, Jon wrote:
> >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: Christer Holmberg <[email-masked]>
Date: Fri, 16 Aug 2002 09:37:04 +0300

Hi,

I think the important thing is that the offer/answer mechanism is separated from
the early media issue, and I think that is what both Jon and Michael suggest.

Like I've said before, a SIP node is currently FORCED (because of the
offer/answer mechanism) to send SDP in certain messages (eg in the first 18x
when PRACK is used). Now, if the local ringback decission is based on that SDP,
the media mode indicator (sendrecv/inactive etc) in that SDP would have to set
depending on if early media will be sent or not, to prevent the risk of mixing
of local ringback and remote early media. And, if there is no early media, an
UPDATE would have to be sent, to set the mode to sendrecv, when the called party
answers the phone. However, no matter if we accept that sending UPDATE at the
same time as 200 OK is no problem (will not cause delays etc), I think the
reality is that many SIP phones today set the mode to sendrecv already in the
first answer (which, again, may be sent in the first 18x provisional response),
no matter if they are going to send early media or not. So, the problem would
remain: how does the gateway know if to generate local ringback or not.

Now, according to Jon's proposal, if a gateway receives 180, it would generate
local ringback - no matter if there is also an SPD/sendrecv body in the message.

And, if the gateway receives 183, it would not generate local ringback - no
matter if there is an SDP/inactive body in the message (the caller probably
won't hear anything, but it won't be that gateway's "fault"). Of course, a
gateway may choose to check the SDP, and still generate local ringback in this
case, but that's a local application issue which does not need to be described
in any IETF document.

Also, if a gateway receives 180, and before that has received 183 with
SDP/sendrecv, it would still generate local ringback, because if the remote
party sends 183 and DOES intend (like Jon said, it's not a MUST to send early
media even if 183 is sent)  to send early media it would NOT send 180 later.
And, if the remote party is sending early media, and still sends 180, the
gateway would stop forwarding the media to the caller, and generate the local
ringback instead.

Am I correct?

Regards,

Christer Holmberg
Ericsson Finland