Subject: RE: [SIP] Early media

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Mar 2001 02:32:18 -0500

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, February 27, 2001 8:10 AM
To: 'Dean Willis'; Mark Watson; sip
Subject: RE: [SIP] Early media

>Hi,
>
>Perhaps I'm missing something. The notes seemed to indicate that SDP SHOULD
NOT be sent 
>backwards before the 200 OK, but you are indicating that the ability to
have *backwards* 
>media path is still available before the 200 OK.

Let me clarify.

We identified two different things. One, is the need for a media path to be
"open" from the UAS to UAC before the 200 OK, in order not to clip the first
seconds of media traffic. This is not EARLY media, in the sense that media
is sent before the call is answered by the user, its media that just happens
to beat the 200 OK back to the UAC.

As a separate issue, is whether the UAS can send "early" media, such as
announcements, ringtones, and the like, before the call is answered with a
200 OK. On this issue, we said there are no capabilities for this in
rfc2543. An extension would need to handle this, and that extension would
define the 183s and whatever else is needed. Thus, a server could not handle
a manyfolks scenario unless the client supported the early media extension.
I think thats reasonable.

Now, it turns out that since you have a reverse media channel to handle
clipping, early media may work anyway, but there are many conditions under
which it won't work:

  a. forking
  b. need for forward media channel
  c. reservations (ala manyfolks)
  d. ability to hold/modify early media

For these, we discussed some possible solutions. All of them, of course,
require some kind of messaging that sends around some more SDP. One
possibility is 183/PRACK, as is discussed now. A more radical idea that is
growing on me, was to use an INVITE in the reverse direction, to treat the
early media stream as a new session in and of itself, just linked in some
way with the original call. This actually solves lots of problems and makes
things consistent - INVITE is the only thing that you use to establish media
streams. Whether that is right or even workable requires a lot more
discussion.

-Jonathan R.

>
>I know that in many scenarios, the backwards SDP is not required in order
to allow 
>backwards media, but we are surely not making this a blanket assumption ?
What about when 
>there is QoS reservation going on, does the manyfolks mechanism provide a
way of sending 
>the SDP backwards which is not subject to the SHOULD NOT discussed at the
meeting ?
>
>Apologies if I've just misunderstood ?
>
>Regards,
>
>Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 16 February 2001 17:11
To: Watson, Mark [MAIFP:EP11-M:EXCH]; sip
Subject: Re: [SIP] Early media

Gee, I HOPE not.

Real world scenarios -- my office uses only SIP phones with a PSTN gateway
for outside communications. The first "hello" is almost universally clipped.
Most annoying.

My recollection of recent discussion of basic call flows (no special "early
media") is that the UAC SHOULD be ready to receive media at the time the
INVITE is transmitted. It SHOULD not send media until after it has sent ACK
in response to a 200 OK.

--
Dean

----- Original Message ----- 
From: Mark Watson 
To: sip 
Sent: Friday, February 16, 2001 9:57 AM
Subject: [SIP] Early media

All, 
The notes from the meeting earlier this month seem to indicate an agreement
to deprecate early media i.e. to include a SHOULD NOT in respect of media
before the 200 OK of the INVITE.
Is this a correct understanding of what was agreed ? 
I seem to remember this issue being discussed extensively on this list late
last year and there were strong feelings expressed against changing the
semantics of the 200 response to the INVITE. Presently it corresponds to
called party answer, but the change above would alter this.
Was a solution to these concerns also identified at the meeting ? 
Does this deprecation apply to the setting up of the media path before 200
OK for QoS assurance, or just when the intention is to play the backwards
media to the caller ?
Regards, 
Mark Watson 
Nortel Networks 
> -----Original Message----- 
> From: Kevin Summers [mailto:[email-masked]] 
> Sent: 16 February 2001 14:45 
> To: Jacco de Kraker (ELN); sip 
> Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue) 
> 
> 
> 
> http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html 
> 
> -----Original Message----- 
> From: Jacco de Kraker (ELN) [mailto:[email-masked]] 
> Sent: Friday, February 16, 2001 8:32 AM 
> To: [email-masked]' 
> Subject: [SIP] transcripts interim meeting? (esp. REFER issue) 
> 
> 
> Hi all, 
> 
> Are any transcripts of the interim meeting of last week available 
> somewhere on the Internet? I assumed some of the discussed issues 
> would show up on this list, but I haven't seen anything about it. 
> I'm especially interested in any decisions/clarifications/new problems 
> related to the REFER issue. 
> 
> If anybody knows where I can find transcripts of the 8-9 February 
> meeting, please tell the list. I'm sure I'm not the only one 
> interested. 
> 
> Regards, 
> 
> /Jacco 
> 

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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor'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" in the body.