Subject: [SIP] Early media replacement.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 6 Jan 2001 17:26:16 -0800

Hi all,

I was reading the open issues from the last IETF BoF and was wondering what
people had in mind to replace early media:

Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
:

---
2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What about post-dial delays? Reasons for wanting early media:
Billing issue for PSTN interworking. Not cutting off voice. QoS negotiation
(doing PRACK). If don't care about QoS negotiation, no need to do 183s.
...
Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. Requires bi-directional media. 200Ok means bi-directional
media path has been established. It doesn't mean the call has been answered.
For bi-directional, send a 280.

--

[280?? I assume this is meant to say 180]

Ok 200 OK really simply means that session is active. However, for a long
time we have been conceptually/implicitly equatign this to mean that the
remote client/phone/person/terminal has "answered". Which is not necessarily
true. [This reminds of a discussion along time ago about a SIP alarm clock
which is an automated SIP device.] 

When the SIP is being used for establishing live communications channels (eg
session to a "terminal") rather than just as a session initiation protocol
(eg gaming servers), then is there a need to indicate the remote terminal
state? 

This seems to me to be the missing link in why it is so difficult to kick
the early media for VoIP (et al) applications - because there is no way to
differentiate session state from terminal state.

In the above suggestion where a one-way session is established and then a
re-INVITE is used to negiotiate the two-way session when the terminal
answers, SIP provides no mechanism (that I can see) for communicating what
is actually going on with the terminal, eg when to start billing. You could
say that you start billing when there is a two-way media stream but is this
the best way to go about it (ie, tied to media level info)? I don't think
so. For instance, you may want to start billing only when the remote
terminal user answers.

[This whole issue is obviously tied to billing but the solution should not
be aimed be at solving only that sub-space of the problem (IMO). I think the
terminal state information should provide the billing information and not
the other way around!]

Is this the right approach, ie, to separate SIP session establishment state
from implied terminal state?
Is this beyond the scope of the WG? [Since SIP is currently primarily used
for terminal based  communications, perhaps not.]
Is there already a "package" for describing generic terminal status that we
can use for SIP?

I'll be interested to hear what people think.

Regards,

Robert.

-- My opinions are my own and do not necessarily represent those of Nuera
Communications, Inc. --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 8 Jan 2001 02:23:46 -0500

-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
>Sent: Saturday, January 06, 2001 8:26 PM
>To: 'SIP List'
>Subject: [SIP] Early media replacement.
>
>
>
>
>Hi all, 
people had in 
>mind to replace early media: 
>
>Excerpt of
>2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What 
>about post-dial delays? Reasons for wanting early media: Billing issue for
PSTN 
>interworking. Not cutting off voice. QoS negotiation (doing PRACK). If
don't care about QoS 
>negotiation, no need to do 183s.
>... 
officially up. 
>Requires bi-directional media. 200Ok means bi-directional media path has
been established. 
>It doesn't mean the call has been answered. For bi-directional, send a 280.
>-- 
time we have been 
>conceptually/implicitly equatign this to mean that the remote
client/phone/person/terminal 
>has "answered". Which is not necessarily true. [This reminds of a
discussion along time ago 
>about a SIP alarm clock which is an automated SIP device.] 

Nothing radical was agreed upon at this discussion. Let me clarify.

We discussed the whole early media issue, and were concerned about the
increasing complexity it was causing. We discussed the possibility of
recommending you always send a 200 OK when you want to establish a session
(independently of whether the phone was answered or not), but there are
simply too many serious issues with this, many of which were visited during
the old DCS discussions surrounding the two phase invite. The billing and
interop issues you mention are among them.

So, all that was agreed upon was to simplify life for the minimal rfc2543
client. All the stuff regarding signaling support for early media (handling
of 183, dealing with SDP in 183, the resulting needed for provisional
response reliability, preconditions, etc.) would not be in the base spec.
Now, that doesn't mean that a UA doesn't need to support early media.
Rather, an rfc2543-only UA would have to be prepared to receive and play
media immediately after sending INVITE. If it wanted enhanced security
services, QoS for that early media, bidirectional early media, and so on, it
would have to support some of the extensions. 

So, that old 183 draft which has expired will be revived, and in it will be
the stuff for handling basic early media at the SDP/SIP level.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 7 Jan 2001 23:59:48 -0800

> the stuff for handling basic early media at the SDP/SIP level.

There are other problems with deprecating early media by using re-INVITE.
Consider the case where an INVITE request is forked by a proxy to both a SIP
desktop client and a PSTn gateway. If the gateway immediately sends a 200 OK
on receipt of an INVUITE (with a one-way SDP body to relay the remote
ringback) then the desktop client will never get a chance to answer the
call. Between two PSTN gateways you will have a race condition.

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

---

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 8 Jan 2001 15:58:09 -0600

I'd like to make a few comments on this subject.

First, I agree that 183 is useful.  However, I don't see it as 
a mapping to an ACM message.  180 serves that 
purpose, I believe I've seen it documented in some ISUP 
interworking I-Ds.  What I do see 183 useful for is to stop 
local ringback at the UAC.  The UAS (PSTN GW) can 
provide remote ringback without sending a 183 (since the 
UAC should be prepared to receive and render media after 
sending the INVITE) but the user experience may be 
strange (hearing two sources of ringback).  183 has other 
uses I suppose as Alan points out but I wouldn't use it to 
establish a two-way media session because my 
applications can separate start of billing from a particular 
200.  But I'm just thinking of my own applications at this 
point.

I too would like to see a complete list of issues before 
any changes are made to what's currently specified.  I 
remember one complaint of a SIP phone displaying 
ringing but the user could hear busy tone.  If the UAS 
sent a 183 prior to sending busy tone that problem lies 
with the UAC and not the 183 or early media.  I can also 
see the possibility of RTP endpoints needing address and 
port information to exchange session attributes to get 
even the one-way media to be processed and rendered at 
the UAC but this is an additional requirement on the UAS 
if needed.

Regards,
Bert

> From: Alan Johnston [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 2:39 PM
> To: Christian Huitema
> Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; SIP List
> Subject: Re: [SIP] Early media replacement.
> 
> 
> Christian,
> 
> I disagree that the 183 itself is the hack.  It is an 
> important and useful
> provisional response.  However, using the 183 to establish a 
> two-way early
> media session is problematic, and I think it is a good idea 
> to move the
> complexity of this situation to a separate I-D which will 
> probably have a
> Require extension defined to indicate that a UA is ready to 
> deal with the
> complexity.  As Jonathan says, the base spec will still 
> include 183, and
> require a UA to listen for one-way early media packets as 
> soon as it sends
> an INVITE.
> 
> In my mind, the primary argument against getting rid of the 
> 183 entirely
> (which would force SIP/PSTN Gateways to map an Address 
> Complete (ACM) or
> Alerting message to a 200 OK) is that once you do so, you 
> lose the ability
> to indicate in a final response why a call failed.  Consider 
> the case where
> a call to the PSTN results in a Forward Don't Answer to 
> another  number  in
> the PSTN which is busy.  This could result in the following 
> responses being
> generated by the PSTN Gateway: a 183 Session Progress 
> (indicating inband
> alerting), a 181 Call Has Been Forwarded, followed by a 486 
> Busy Here final
> response.  This lets the SIP Phone know exactly what happened 
> to the call.
> If we get rid of the 183, the PSTN Gateway would be forced to 
> send a 200 OK
> as soon as ringing took place.  Since this is a final response, no
> indication of forwarding and busy could be sent besides the 
> inband tones.
> The busy tone would result in a BYE being sent - not very 
> informative to the
> SIP Phone.
> 
> In summary, I think this consensus on 183 and early media is 
> a good one.  It
> will allow any base SIP spec compliant UA to complete calls 
> to the PSTN
> through a Gateway without having to deal with the complexity 
> of two-way
> early media.
> 
> Also, the billing fraud issue you mention is not an issue in 
> the PSTN.  You
> can open up a two-way session on the IP side, but the PSTN 
> Gateway will not
> cut the PSTN trunk through in both directions until an answer 
> has occurred
> in the PSTN. Your audio path is still blocked in the PSTN.
> 
> Thanks,
> Alan.
> 
> 
> Christian Huitema wrote:
> 
> > >There are other problems with deprecating early media by using
> > >re-INVITE. Consider the case where an INVITE request is
> > >forked by a proxy to both a SIP desktop client and a PSTn gateway.
> > >If the gateway immediately sends a 200 OK on receipt of an INVUITE
> > >(with a one-way SDP body to relay the remote ringback) then the
> > >desktop client will never get a chance to answer the call.
> > >Between two PSTN gateways you will have a race condition.
> >
> > Robert,
> >
> > It would be nice to collect a complete list of issues, so 
> that we can
> > really understand what is the rationale for the 183 
> extensions. Frankly,
> > our main objective right now should be to keep SIP simple; from an
> > architecture point of view, it is very desirable to use a single
> > mechanism for many purposes (i.e. re-INVITE) rather than invent a
> > specific hack for every specific problem (i.e. 183).
> >
> > Your "race condition" argument is not terribly convincing. 
> The PSTN vs
> > desktop case that you describe is not different from the possible
> > race condition between a desktop and an answering machine, or, for
> > that matter, of the possible race condition between two 
> PSTN gateways.
> > Forking an INVITE inherently creates a race condition: the first
> > leg that responds with a 200-OK gets the call. Early media 
> just makes
> > the matter more confusing. Imagine a call forked to two 
> PSTN gateways,
> > one sending an early media that says "please dial 1 for an immediate
> > connection, dial 2 for voice mail" and another that says "this is
> > a protected line, please enter your PIN number." How exactly does
> > 183 help in this case?
> >
> > In fact, the billing argument is not very convincing either. If we
> > create a 183 response, we effectively create another way to 
> establish
> > a call. So, I can program my desktop to always answer with a 183
> > response, a courtesy to my callers who won't be billed. Sure, the
> > PSTN will time out eventually, but the time out is rather long --
> > I will need to check, but it is at least 30 seconds, sufficient for
> > most "answering machine" conditions. Besides, I can still send the
> > 200 OK if the call lasts longer than the timer...
> >
> > -- Christian Huitema
> >

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Jan 2001 15:19:52 -0800

One thing is to provide a notification of partial call completion, and
another is establish a two-ways circuit. There is no need of carrying an
SDP field in a provisional response in order to provide audio feedback:
sending RTP packets to the address advertised in the INVITE ought to be
sufficient. A lot of the complexity cause by the proposed 183 disappears
if that response does not carry an SDP payload.

On the other hand, if one allows an SDP payload in a provisional
response, for example for collecting DTMF digits or voice commands, then
the PSTN gateway must open a two ways circuit, and the billing fraud is
enabled.

-- Christian Huitema

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Jan 2001 01:34:26 -0500

> From: Rick Dean [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 11:20 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg wrote:
> > In practice, I doubt calls to PSTN numbers will fork anyway. 
> 
> Then why do you oppose me?  

Because I do not believe forking is the only aspect of this issue.
> 
> PSTN interoperability is paramount to me.  
> Unfortunately, my calls need to work better 
> than 99% of the time.  
> 
> If gateways "need to send media 
> in the reverse direction without knowing what 
> it is", then they should send a 200 OK because
> the forking won't work anyway.  Why else
> should early media persist if not for
> forking? 

Because always sending a 200 OK has implications
for services on the SIP side. For example, it completely
eliminates the possibility of a call forward busy or 
call forward no answer. This is the reason why the two
phase INVITE in the original DCS proposal was so disliked - 
it changed the fundamental notion of what sending a 200 OK
meant. 

>  Hopefully, the gateway builders will 
> do the right thing.

Its not a question of lazy implementations. Its a question of not having
enough
information to send anything but early media.

> Let's depreciate early media.

Lets stop making broad, sweeping statements about the directions to go in,
and rather analyze the problem so we can arrive at a proper conclusion.

-Jonathan R.

---