Subject: RE: [Sipping] New version of the early media draft

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 29 Mar 2003 01:47:14 -0500

Yes, well, I agree the issue of how we encode things in SIP is secondary to
the issue of what we hope the encodings will accomplish. I have been trying
to flush out the requirement for this encoding for some time now.

It is clear that a UAS can send a 180, and then send RTP, right? UACs need
to accept that sequence to prevent post-answer media clipping. If there's
some mysterious property that will be provided to a SIP UAC by virtue of
receiving the 180 and then receiving RTP, nothing is preventing a UAS from
sending just that. On an unrelated point, I also happen to think that
sending early media in SIP is generally bad, and we should avoid it as often
as possible, but that's not material to this issue - clearly, early media
must be sent in some cases, and we need to decide what we do then.

My concern is that some provisional response parameter (be it in 180 or 183)
stating that media will or will not be sent is pointless given that the UAS
can just send media with any 18x. Arguments that decomposed UACs will be
more responsive to SIP-layer indications than to the receipt of RTP seem
misguided to me in light of the fact that the UAC must be prepared to
receive and appropriately handle RTP with or without any forewarning (even
granting the questionable assumption that a SIP-layer indication would
actually arrive before the RTP itself). I am totally unsympathetic to
arguments that MGCP or Megaco-based MGC UACs are unable to be SIP-compliant
in this respect, and that we should therefore install new behavior in SIP to
compensate for their inadequacy.

Another problem is the idea that SIP has some special 'alerting' state
comparable to that of ISUP, and that if 180 is not received, this 'alerting'
state will not be reached. I'm not sure what UAC behavior the advocates of
this position imagine will result from 180 that will not result from 183. If
anyone can substantiate this for me, preferably with some citation from
RFC3261, that would go a long way towards putting this issue to rest.

Personally, I would be happy to compromise on the details of this encoding
if I understood why people want it in the first place.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Friday, March 28, 2003 5:04 PM
> To: Al Varney; Peterson, Jon; [email-masked]
> Subject: RE: [Sipping] New version of the early media draft
> 
> 
> For information, I think pretty well all the proponents of 
> needing to distinguish three different cases of information 
> provision do not really care how the coding distinguishes 
> those three cases. 
> 
> The main person who keeps returning the discussion to 
> particular encodings is Jon Peterson, who consistently argues 
> that there are not three cases.
> 
> And yes we do need to agree codings at the end, but one step 
> at a time.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: Al Varney [mailto:[email-masked]]
> > Sent: 28 March 2003 03:05
> > To: Peterson, Jon; [email-masked]
> > Subject: RE: [Sipping] New version of the early media draft
> > 
> > 
> > I haven't seen any "results" from the Early-Media Ad-Hoc (if 
> > it was held), 
> > so I'll toss out something I would have stated had I been there....
> > 
> > At 04:50 PM 3/14/03 -0500, Peterson, Jon wrote:
> > >They are proverbially out of luck in the CAS interworking 
> > case, no? Again,
> > >it's not our fault that ISUP doesn't present its status accurately
> > >out-of-band.
> > 
> >     Absolutely true.  Even more so for MF or DP trunks off a SIP 
> > gateway.  You can't fix the past, but you do have to worry 
> > about embedded base.
> > 
> > >Anyway, this is speaking to a pair of separable issues. 
> > Whether or not we
> > >send pre-answer media with a 180 is separable from whether 
> > or not we need
> > >some SIP-layer indication that we are doing so. Personally, 
> > I think we're in
> > >a bad position to deal with cases where ISUP provides 
> > valuable in-band
> > >information but doesn't tell us so in the encoding of an 
> > ACM, and I don't
> > >think it is reasonable for us to always send pre-answer 
> > media on receipt of
> > >ACM. But this is a separate issue.
> > >
> > >If we send 180, and subsequently send media, we could very 
> > well be deceiving
> > >a deaf user (or a user whose UA simply doesn't render 
> > pre-answer media) into
> > >thinking that 'alerting' tells the whole story. But if 
> > 'alerting' told the
> > >whole story, there'd be no need to send any pre-answer media 
> > to accompany
> > >it. This is the paradox I keep hearing - people want to see 
> > an indicator
> > >that says "alerting" and play early media, but they simultaneously
> > >acknowledge that the reason they want the early media is because it
> > >qualifies the alerting state in some fashion.  How valuable is the
> > >"alerting" state at the UAC, then?
> > 
> >     OK -- so folks want "alerting" and early media (as in ISUP), 
> > particularly for cases when interworking with the old PSTN.  
> > Then why add a 
> > SIP-early-media indicator to 180?  Instead, why not add an 
> "alerting" 
> > indicator to 183 -- which maps rather well to ISUP ACM 
> > practice (ACM always 
> > implies in-band media in the backward direction, and it 
> > sometimes indicates 
> > 'user free'/alerting).  It also maps to/from ISDN in an 
> > obvious manner.
> > 
> >     This leaves 180 untarnished as an explicit "alerting and 
> > no intended 
> > early media" indicator, and local ringback could always be 
> > generated.  Any 
> > pre-200 media could be assumed to have gotten ahead of SIP 
> > messaging, and 
> > it could be cut through to the caller either immediately or 
> > after a short 
> > delay.
> > 
> >     Adding a new indicator to 183 for "user being alerted" is 
> > backward 
> > compatible, since RTP media would be there even if the new 
> > indicator was 
> > ignored.  And for cases where the indicator WAS recognized, a 
> > display or 
> > forking treatment similar to that for 180 could be used.  
> > Some UA could 
> > even generate local ringback if it really, really wanted to do so.
> > 
> >     The major advantage would be better compatibility with SIP-ISUP 
> > gateways for interworking, and the preservation of 180 for 
> > cases where 
> > SIP-aware signaling was used end-to-end.  Or where gateways 
> > that could 
> > distinguish true alerting cases (a gateway with 
> > directly-connected lines, 
> > for example, always knows the true alerting state of a 
> > terminal).  Over 
> > time, SIP-to-SIP calls would all tend to use 180, and the old 
> > PSTN behavior 
> > would be contained within 183 handling (where it already has 
> > to exist).
> > 
> >     (While adding indicators to 183, would it also be useful 
> > to have a "SIP 
> > not used all-the-way" indicator that indicates interworking 
> > to non-SIP 
> > protocols?   Or would a UA always behave the same for 
> > gateways sending 183 
> > and called-UAs sending 183?)
> > 
> >     View this as a comment thrown out into a late-night 
> > Ad-Hoc session.
> > 
> > Al Varney
> > 
> > >I would be more sympathetic to this view if the 'alerting' 
> > state had some
> > >specific semantics at the UAC pointed out in RFC3261 that 
> > differentiated
> > >'180 received' from '183 received' or other provisional 
> > states - but it
> > >doesn't. There's nothing magical about receiving a 180 
> > response. It's been
> > >suggested that this is valuable for forking composition, but in my
> > >estimation, if there's in-band media associated with a 
> > provisional branch of
> > >a fork, you need to evaluate that media, not the status 
> code (again,
> > >otherwise, why send the media at all?). Some sort of 180 
> > indicator that
> > >suppresses local ringback doesn't help you either way with 
> > any of these
> > >problems.
> > >
> > >Jon Peterson
> > >NeuStar, Inc.
> > >
> > > > -----Original Message-----
> > > > From: Michael Hammer [mailto:[email-masked]]
> > > > Sent: Friday, March 14, 2003 12:51 PM
> > > > To: Peterson, Jon
> > > > Cc: 'Drage, Keith (Keith)'; 'Elwell, John'; 'Mark Watson';
> > > > [email-masked]'
> > > > Subject: RE: [Sipping] New version of the early media draft
> > > >
> > > >
> > > > Jon,
> > > >
> > > > Doesn't the possibility of deaf users preclude the use of 183
> > > > from being
> > > > used, as has been suggested, since they won't hear the
> > > > locally injected
> > > > ringback or the inband media?
> > > >
> > > > Mike
> > > >
> > > >
> > > > At 05:52 AM 3/14/2003 -0500, Peterson, Jon wrote:
> > > >
> > > > >Below.
> > > > >
> > > > >Jon Peterson
> > > > >NeuStar, Inc.
> > > >
> > >_______________________________________________
> > >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: "Bob Penfield" <[email-masked]>
Date: Sat, 29 Mar 2003 10:42:41 -0500

----- Original Message -----
From: "Peterson, Jon" <[email-masked]>
<snip>
> RFC3261, that would go a long way towards putting this issue to rest.

Even the RFC 3261 definition of 180 uses the term "alert".
180 is not the same as 183 and UAs (e.g. SIP Phones) do treat them
differently in order to provide the best user experience.

RFC 3261 defines 180 as:

    The UA receiving the INVITE is trying to alert the user.
    This response MAY be used to initiate local ringback.

where 183 is defined as:

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.

I'm not saying that 180 means exactly the same thing as alerting in ISUP,
but when the UAC receives a 180, it can reasonably believe that the call has
progressed to the point that it can render "Ringing" to the user whether
that is by displaying something on a screen (with or without inband media),
flash a light, or playing local ringback in the absence of inband media. No
such assumption can be made when a 183 response is received.

Regardless of the type of UAS or interworking protocol, if a UAS can
determine that the call has reached a state where it (or an endpoint at the
other side of the non-SIP network) is "trying to alert the user", it should
send 180. The response codes 180, 181, and 182 do have specific meaning in
SIP and whenever a reasonable mapping from states in a interworking protocol
can be made, they should be.

BTW, I do support your position that no additional indication of the
presence or absence of early media is required in SIP signaling. If UAC
receives media, it should play it.

cheers,
(-:bob

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Mar 2003 19:55:55 +0300

Hi,

The spec currently says that "a UAC shall be able to receive media as soon as
the INVITE is sent".

Now, there may be reasons why a UAC is not able to do that. For example, it may
need the remote SDP before I starts accepting media. We have to remember that
SIP does not specify a specific bearer (unlike H.323, which uses RTP), so one
could argue the SIP spec should not contain these kind of statements in the
first place. After all, SIP is a pure signalling protocol.

But, going back to the early media discussion, my question is: should it also
include the offer/answer aspect? Now we only talk about the meaning of 180 etc,
assuming there is no need to consider the actual media part, since the UAC shall
be able to receive media at all time...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Mar 2003 10:31:17 +0300

Folks,

here you have a summary of what happened in the IETF regarding early
media.

We planned to have an ad-hoc meeting, but since we managed to get more
meeting time than expected for this issue and some of the persons
involved in the mailing list discussions were not available for an
ad-hoc meeting (some of them were not even in San Francisco), we did not
finally have the ad-hoc.

Regarding the discussions during the second SIPPING session, the main
input was slide number 3 of

http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-media.ppt

That slide does not discuss the encoding issue. It focuses on the
requirements or the gains that adding a SIP "there is media coming" (or
"don't generate local ringback") indication would bring.

The conclusion of that slide is that a message with "generate local
ringback until media arrives" should be provided by the protocol (e.g.,
MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or
not we create a "there is media coming" flag.

Therefore, assuming that the MG is in accept-media state as soon as the
INVITE is sent, the only gain that a "there is media coming" would bring
would be saving one message from the MGC to the MG every time a 180 with
a flag is received. The gain is zero for 180 responses without the flag.

The question is: are people after this optimization (saving of one
message in some circumstances) or there is somebody with something else
in mind?

In any event, the conclusion of the meeting was that I will be gathering
use cases where a "there is media coming" flag would be useful. Please,
send any use case you have in mind and I will compile them in a
document. We hope that such a document help us figure out which
requirement is missing.

We also may organize a conference call in some weeks to further discuss
the issue, if needed.

Thanks,

Gonzalo

---

From: Tom Taylor <[email-masked]>
Date: Mon, 31 Mar 2003 10:03:07 -0500

Your charts do not reflect an important difference between MGCP and Megaco/H.248. 
In MGCP, it is possible to tell the MG to automatically terminate application of 
ringing tone upon detection of incoming media.  In Megaco/H.248, the media event is 
detected on one termination, but the ringing tone is being applied to another.  This 
means that the MG has to report media detection to the MGC, and then the MGC has to 
request that ringing tone application be stopped.  It has occurred to me upon 
reflection that there might be a way around this, but for the moment that is the case.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 31 Mar 2003 10:45:09 -0500

Bob and Jon,

The only problem with this approach is that you have blurred the line 
between signaling and bearer.  If 180 means alerting, then the UAC should 
provide alerting until the 200 OK or some other signaling removes the UAC 
from that state.  But, you have the bearer stream removing the UAC from the 
alerting state based on the receipt of RTP.

If you follow that approach, it should be clarified that not just any RTP, 
but RTP with some meaningful media would be of value.  But, this puts the 
burden on the UAC to determine whether highly ambiguous media means 
something or is just noise or silence.

A 180 meaning alerting with a suppression indication to supersede local 
alerting with inband alerting, or a 183 with an explicit indication of "do 
local alerting" would be a clear SIGNALING mechanism.

The only responses I recall getting to the following scenario is "GWs 
shouldn't do that" and "in MOST cases the destination EO will supply 
ringing inband anyway":

A GW responds with 180 and backward cut-through of RTP playing dead air.
The UAC plays the dead air because it got there before the 180 (and to 
avoid clipping).
This could go on for several seconds or however long it takes the UAS to 
pick up.

But, if this were to occur, I guess that is OK for the SIP UAC user.  This 
seems to be a minor case, so don't worry about it.

Mike