Subject: RE: [SIP] Early media replacement.

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 9 Jan 2001 01:25:41 -0500

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 8:01 PM
> To: [email-masked]
> Subject: Re: [SIP] Early media replacement.
> 
> 
> 
> If we keep early media, then we need to keep 
> the 183 cruft, otherwise parallel forking proxies
> can't know they have forked to two simultaneous
> streaming media locations, a no-no. 

In practice, I doubt calls to PSTN numbers will fork anyway. 
That aside, a UA can deal with the multiplicity of streams in the
standard RTP way - sort them out by SSRC, and play one and/or mix
them as it sees fit. It needs to be able to do that whether or not
the 183 message is present. 

> Early media doesn't help.  Let's kill it.

I'm afraid that this will simply not fly. 
Gateways will, far too often, need to send
media in the reverse direction without knowing
what it is. The reality is that forking will be 
problematic for PSTN interworking.
Thats a reality of PSTN interoperability.
Whining about it will not cause the problem to go 
away. 

I am unwilling to dismiss PSTN interoperability as 
an important issue for SIP. My hope is to allow a 
normal SIP UA phone or PC client to not have to
worry too much about it. The proposed solution
of receiving media after INVITE (with the caveat that
your RTP implementation needs to be correct and sort
by SSRC any media that comes), alleviates any complex
work on the side of a UA, and still pretty much
works.

-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: Christer Holmberg <[email-masked]>
Date: Tue, 09 Jan 2001 10:12:06 +0200

Hi,

A few comments on this thread.

First, a comment on the "media mixing". If you receive multiple 183
responses, with different SDPs, and from different locations - how do
you know if you shall mix all the media streams or if you shall replace
the first media stream with the other when the second 183 is received?  

And, PSTN numbers may not fork, but SIP numbers from a PSTN/SIP GW may
fork, so...

About replacing 183 with 200. Personally I don't think that is a good
idea - 183 is one for one purpose and 200 for another purpose. It does
allow us , among other things, to open a 2-way-communication when the
183 is received, but the billing would start at 200, etc.

I wouldn't mind having "provisional final responses" (which must be
ACKed), though. That will not solve this problem, but at least we
wouldn't have to play around with PRACK just to make sure we get the 183
(or any other provisional response) in the first place... :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Rick Dean <[email-masked]>
Date: Tue, 9 Jan 2001 10:20:00 -0600

> In practice, I doubt calls to PSTN numbers will fork anyway. 

Then why do you oppose me?  

> work on the side of a UA, and still pretty much

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?   Hopefully, the gateway builders will 
do the right thing.

I suppose I could omit SDP from my INVITES
and wait for the ACK so gateways have to
send me the 200 OK.  

Let's depreciate early media.

--
Rick