Subject: [Sip] Early media draft

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 Aug 2001 18:47:00 +0300

Hello Jonathan,

I have read the early media draft again. I will give my opinion on some
of the open questions that you have placed in the draft and I will make
a proposal.

The current mechanism effectively "trashes" the SDP contained in the
first INVITE (and the SDP contained in re-INVITEs). Even if we are using
a Require header and there would not be any backward compatibility
problems, I do not like that.

The current draft considers that when I add a media stream to the early
media it means that I would like to have the same media stream added to
the final media (media after the 200 OK). I would like to differentiate
between early media and final media. That is, I can send you an INVITE
with an audio media stream and a video media stream. You send me early
media that consists of audio only. However, when you finally answer with
a 200 OK, I want you to answer my original proposal (video+audio), not
to renegotiate the parameters that we were using for early media.

My proposal is that negotiation of final media and negotiation of early
media are kept separate. That is, the SDP in the 200 OK will always be
the answer to the SDP in the INVITE. Regardless of whether we are using
early media or not (I believe that this is more consistent with bis).

This would avoid media clipping when the 200 OK finally arrives, since
the UAS can send media without waiting for the ACK.

The process of changing early media parameters would have to be changed.
Right now the UAC issues a re-INVITE. The SDP in this re-INVITE is
effectively ignored (the real SDP exchange is 1xx-PRACK). My proposal is
that the SDP in the re-INVITE is an update (or a refresh) of the SDP
that was contained in the first INVITE. 

In short, I want the "INVITE-200 OK" SDP exchange to be independent of
the "1xx-PRACK" SDP exchange.

I believe that keeping both negotiations separate (early media
parameters and final media parameters) is a powerful tool. I can update
my final media SDP without updating my early media SDP and vice versa
(or update both at the same time, of course).

Opinions?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 03 Aug 2001 12:39:27 +0300

Hi,

I agree with Gonzalo. Since early-media is something some nodes don't
support, or care about, let's keep it separate from the "final-media".

For example, if we don't keep early-media and final-media separate we
MAY come with something like the following: In a forking scenario, the
UAC may have an early-media "discussion" with UAS_1, but it may receive
a 200 OK from another UAS, UAS_2, and for any reason the UAC chooses to
start the session with UAS_2. The UAS_2 doesn't know anything about our
messages with UAS_1, so it uses the SDP in the INVITE to generate the
SDP in the 200.

I would also - once again - like to raise the issue about canceling
specific legs. If we, in a forking scenario, receive 18x from multiple
UAS (all of them may, for example, offer early media), and we choose one
of the legs, shouldn't we be able to CANCEL/BYE the other legs right
away? If we have to wait for a final response  it means that we have to
send PRACKs to the other UASs as well. I KNOW this we have had (too)
many discussions about this, and I KNOW about the problems related to
it, but I really think it's an important part of the whole forking
discussion, ESPECIALLY when early-media is involved.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 3 Aug 2001 09:46:55 -0400

> discussion, ESPECIALLY when early-media is involved.
In section 6 of bis-04, it says:

   A BYE request SHOULD NOT be sent to terminate a pending call
   request which has not generated either a final response or a
   provisional response containing a To tag.

Which implies that we are allowed to BYE a specific call-leg using the To
tag from a 1xx response. I think this is the right way to do it mainly
because we have complete UAC-to-UAS call-leg, it just has not been answered
yet. CANCELs should always match the original request and apply to the whole
request (although the cancel would not apply to answered (200-OK)
call-legs).

I think we need to add some text stating that the way to terminate a
"provisional call-leg" (one for which we have received a 1xx with a To-tag),
is to send BYE with the To-tag.

Also, do we need to have both a To-tag and a Contact from the 1xx, or would
we always get the To-tag with a Contact?

(-:bob

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Aug 2001 23:53:05 +0300

Hello,

I sent the mail below some time ago and we had some discussion. I would
like to discuss this issue in depth now, in order to get the early media
draft stable.

Comments are welcome.

Regards,

Gonzalo

Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip