Subject: [Sip] new I-D on early media

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 15:29:25 -0400

Folks,

I've just submitted an I-D on early media. As we agreed upon previously, the
concept of early media would be done as an extension, where it could be
handled properly. The draft proposal fixes all of the known problems with
early media, I believe, and is also nicely backwards compatible with the
existing early media approaches. 

Until it appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-early-media-00.txt

Thanks,
Jonathan R.

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

_______________________________________________
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: Mon, 23 Jul 2001 18:06:11 +0300

Hi,

I had a quick look at the draft, and here are some comments. Most of
them cosmetic, but still...

First, I agree that Solution 1 seems to be the way to go. It doesn't
require much extensions (new methods etc), it is (in theory, at
least...) backward compatible.

...and it gives us a reason to spend bandwith and CPU power on PRACK
transactions :)

The questions:

Chapter 4.1 UAC Behaviour

Q1. The text says: "If the UAS wishes to refuse the early media stream,
it SHOULD set the port number for each media stream in the answer to
zero"

- I guess it shall be "If the UAC wishes...."? A spelling error, I
assume.

- Why is it "SHOULD set the port..."? Doesn't it have to be MUST to make
it work?

- I read about setting port numbers set to zero... Does this work with
ATM too?

Q2. Later, the text says: "If the UAS wishes to accept the early media
stream, it generates..."

Again, I guess it shall be "If the UAC wishes to accept..."?

Q3. Later, the text says: "In that case, it MUST continue to be prepared
to receive media according to the information in the SDP in the original
INVITE"

The reason for this is, of course, that a UAS may not send 1xx. Instead
it sends 200, and media to the address/port given in the INVITE.
However, I think it should be written that IF a UAS sends 1xx, AND the
UAC sends a NEW address/port in the PRACK, that that specific UAS MUST
send the early media to the address/port given in the PRACK, and nowhere
else. That may sound obvious, but I think it should be there for
clarification...

Here we still do have a small problem, though. If multiple UAS nodes
send 200, they may also start sending media at the same time. This means
that the UAC may receive, even if for a short while (until the unwanted
legs have been ACK/BYEed), a mix of media streams on the same
port/address. I guess this is something we have to live with, though...

Q4. Later, the text says that, if multiple legs are established, the UAC
can choose to reject early media from one or more of them. I know it
doesn't belong to this discussion, but this brings my thoughts back to
the discussion we had some weeks ago about being able to CANCEL a
specific call-leg. For example, if the UAC knows it will not accept a
specific call-leg, should it refuse the early media, wait for the 200,
and then ACK/BYE the call - instead of CANCEL it right away?

Q5. If a UAC refuses to accept early media from a UAS, the UAS may
choose to not accept the call setup. Should we specify (or at least
recommend) which response code to use in this case?

Q6. This is related to the re-INVITEs.

Assume that UAC sends an INVITE, and then receives 1xx (including
Contact).

Now, the UAC may (for any reason) want to change the media parameters
for that specific leg, so it sends a re-INVITE with the new parameters,
to the address received in the Contact. Nothing strange here.

However, the UAC may (for any reason) want to change the media
parameters for ALL possible receivers, even if it has received 1xx from
one or more servers. In this case it would send a re-INVITE, WITHOUT
using any Contact, or any tag (since we want the re-INVITE to be
handled/forked in the same way as the original INVITE). I guess this
would not cause any major problems either, but do you think it should be
mentioned in the draft?

A more complicated case is when the UAC receives 1xx from a UAS. It may
provide new media parameters in the PRACK, BUT again it may also want to
(for any reason) send a re-INVITE to all possible receivers (ie by not
using Contact and tags) - EXCEPT to the UAS it has sent the PRACK to.
Again, I guess this is only one of thousands of different scenarios that
we can come up with, and we can't describe them all. However, this
specific case could be solved using the don't-fork-to feature
(Reject-Contact header) in the caller preferences, so maybe it would be
cool to include...

Chapter 4.2 UAS Behaviour

Q7. The text says: "The provisional response MUST contain a Require
header with the "em" and "100rel".

This is just a detail, but do we MUST put "em" in Require? Can't
Supported be used instead?

That's all for this time...

Regards,

Christer Holmberg
Ericsson Finland