Subject: Re: [SIP] Early media replacement.

From: Rick Dean <[email-masked]>
Date: Tue, 16 Jan 2001 10:59:05 -0600

----- Forwarded message from Rick Dean <[email-masked]> -----

Date: Tue, 16 Jan 2001 10:58:05 -0600
From: Rick Dean <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Subject: Re: [SIP] Early media replacement.
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Jan 16, 2001 at 01:34:26AM -0500

On Tue, Jan 16, 2001 at 01:34:26AM -0500, Jonathan Rosenberg wrote:
> 
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:[email-masked]]
> > Sent: Tuesday, January 09, 2001 11:20 AM
> > To: Jonathan Rosenberg
> > Cc: [email-masked]
> > Subject: Re: [SIP] Early media replacement.
> > 
> > 
> > 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.

Unspecified aspects?  

> > 
> > 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. 

Sure, if a gateway knows the far end is busy, it should send
a 486 busy -- no debate.  If the gateway has unknown progress media 
which might be busy-tone, ringback, or voice prompting; sending 200 
OK helps manage the audio channel.   Do you expect the human to 
hit a key on busy tone so his UA sends a CANCEL?  or should 
he just know to wait?

I regret the 200 OK notion.  With audio, I argue a session
is established.  As a call originating UA, how to I suspend or 
redirect the early media if my INVITE won't complete?

Sorry to be such as pain on this subject.

--
Rick
[email-masked]

> 
> >  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.
> 
> ---
> 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

----- End forwarded message -----

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body"

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 17 Jan 2001 17:07:17 -0500

Why no middle ground:

200 OK :  The call is established, everyone's happy
183 :     Something's going on that I understand; here it is...
184 :     Something's going on that I don't understand; here's the audio

This gets around just about all of the issues raised:

1. Either a call is established (200) or it's in the process of being
established (18x).  Established calls have the audio path established.
Calls not established (181, 182, 183, et. al.) don't have the audio path
established, except for the case of 184.

2. If there's a billing policy that needs to police media cut-through, it
can trigger off the 184 message.

3. It's forward compatible: as we get a truly digital GSTN, the dependence
on audio cut-through for human call progress analysis will go away.  By not
overloading 183, we make life much easier.

> In-Reply-To:
> <[email-masked]
> om>; from [email-masked] on Tue, Jan 16, 2001 at 01:34:26AM -0500
>
[snip]
> > > Unfortunately, my calls need to work better
[snip]
> Sorry to be such as pain on this subject.
[snip]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.