Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

From: [email-masked]
Date: Thu, 4 Oct 2001 00:24:01 +0530

Hi Christer,

Thanks for your mail. Please find some more text inline.

<snip>
>> Precisely. I agree. The UAC MUST NOT make a proposal
>> for media in the ACK in any case (!) Whether it is to
>> add a new stream or any other modification, if the
>> modification is not proposed in the INVITE, it MUST
>> NOT be proposed in the ACK.
>
> That sounds very fine to me, IF the SDP in the ACK
> MUST be the same as the original SDP. BUT, can someone
> then give a case where this is really needed? If the
> UAC isn't able to send the original SDP in the re-INVITE,
> how can it suddenly then be able to send it in the
> ACK??????????????? I mean, if it MUST send the original
> SDP, it doesn't matter what it receives in the 200
> response to the re-INVITE...
</snip>

The ACK to re-INVITE need not have EXACTLY the same SDP
as the original INVITE (please see comment below the next
snip)

As Jonathan had pointed out in an earlier mail, a
re-INVITE without SDP is useful in some 3pcc cases.

Also, if not anything else, the re-INVITE without SDP
can be taken to mean "no change, keep whatever you
already have established with me". Perhaps not of a lot
of use, but definitely not a protocol error (!)
Disallowing the re-INVITE would make it a protocol
error, and I don't see why this is a must. Do you?

HOWEVER, as we discussed what the UAC MUST NOT be allowed
to do is to add streams in the ACK to this re-INVITE
when he did not mention this addition in the re-INVITE's
SDP. I can't think of a scenario in which THIS situation
for stream addition would need to be done in the ACK.

Perhaps, someone else should point it out immediately if
at all it exists :) The general offer/answer model of
SIP seems to work just fine. Offer in ACK seems like a
no-no to me, for one.

<snip>
> However, my understanding was that the UAC should be
> able to modify the existing streams in the ACK SDP
> (but not add new streams). Is that wrong?
</snip>

Yes, you are right. As I understood the recent thread
on re-INVITE SDP, modifying existing streams IS allowed.

In the ACK to the re-INVITE (w/o SDP) that we are
talking about, the UAC is allowed to change parameters
like IP and port of the existing "originally in use"
streams.

I'll take a try to sum it up as of now.
=======================================

As Jonathan and others had already pointed out...
1. Re-INVITES w/o SDP are useful in some scenarios.
2. Since INVITEs w/o SDP are allowed, so should re-INVITEs

So re-INVITEs w/o SDP ARE allowed.

On reception of such a re-INVITE w/o SDP, the UAS MUST
respond to the re-INVITE with the already negotiated
session parameters if it remembers them (That is, it has
not crashed since the session establishment. If the UAS
has crashed, then it treats the INVITE as a new INVITE
and responds with its entire set of capabilities since
this is the best it can do, anyways).

The UAC (3PCC or otherwise) MUST not use this mechanism
of re-INVITEs w/o SDP to get all capabilities of the UAS.

Also, the UAC MUST not propose a superset of the SDP
that it received (in the 200 OK to the re-INVITE) in
ACK that it sends across. This is in line with the
general offer/answer model of SIP. The UAC is, however,
free to modify parameters like IP or port for any of
the "streams in use already".

Does this sound fine to everyone?

Regards,
Siddharth

=================================
Siddharth Toshniwal
Software Engineer
Hughes Software Systems, Bangalore
http://www.hssworld.com

_______________________________________________
Sip mailing list  http://www1.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: Thu, 04 Oct 2001 08:20:15 +0300

Hi,

>re-INVITE without SDP is useful in some 3pcc cases.

I do agree, if the ACK SDP doesn't have to be the same as in the
original (or, previous) INVITE.

>error, and I don't see why this is a must. Do you?

No. I never said that we shouldn't allow re-INVITE without SDP :)
 
>for stream addition would need to be done in the ACK.

Good :)

>I'll take a try to sum it up as of now.

I agree. So far, so good :)
 
>this is the best it can do, anyways).

Well, well, well... This has been discussed before. Since the re-INVITE
has a To-tag, the UAS will know it is not an initial INVITE - even if it
doesn't have any state for the call - so it may also return 481.
 
>Does this sound fine to everyone?

It sounds pretty fine to me. There still is, however, the risk that the
UAS will not (or can not) accept the new SDP in the ACK.

Thanks for your comments!

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Oct 2001 22:57:52 +0300

Hello Christer,

> UAS will not (or can not) accept the new SDP in the ACK.

Why would the UAS not be able to accept the SDP in the ACK?

The number of media streams is the same as the one is already in use.
The set of codecs that will be used is the same as the current set.
The only thing that can change is the IP address and the port number.

Why is this change a big deal for the UAS?

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]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 00:21:52 +0300

Hi,

>The only thing that can change is the IP address and the port number.

I thought that we agreed earlier that media streams can be replaced, ie
we can replace a m= line with a new one, including a new codec etc -
even a new media type.

For example, the t.38 draft replaces an audio stream with an image (fax)
stream. 

Or, isn't that allowd using the ACK SDP method? 

Also, even if the codec is not changed there may be some stream specific
attributes (can't think of any right now, but they may be defined in
future) added/changed to the ACK SDP, that were not included in the
original SDP, which means the UAS can't send media according to those
sets of attributes.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 05 Oct 2001 00:56:00 +0300

Christer,

> we can replace a m= line with a new one, including a new codec etc -

We have agreed that upon reception of an empty re-INVITE, the only thing
that can change in the SDP returned in the 200 OK is the port number and
the IP address (and the version number in the o field). Therefore, the
SDP sent in the ACK will be a valid answer for the offer made in the 200
OK.

So, what you are saying is the same as asking: "what happens if a UAC
sends an INVITE with SDP (offer) and then does not like the SDP in the
200 OK (answer)?". 

There are some rules that avoid this situation, namely the number of m
lines has to be the same in the answer as in the offer, the set of
codecs in the answer must have elements in common with the set in the
offer, etc...

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 00:50:34 +0300

Hi,

>lines has to be the same in the answer as in the offer,

Yes, I think we all agree on that.

>the set of codecs in the answer must have elements in common with the set in the
>offer, etc...

So, when we replace a stream with another that new stream must have the
SAME codec, the SAME attributes, and the SAME media type, and the ONLY
thing we are allowed to change is the IP address and/or the port?

Or, once again: are we allowed to change whatever information for a
stream in a re-INVITE SDP, but only the IP address and/or port in an ACK
SDP?

If that is NOT the case, the propsal of using an attribute for the call
hold will not work, since we change an attribute for an existing
stream....

And, the t.38 fax scenarios won't work, since we replace an audio type
stream with an image type stream...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 05 Oct 2001 17:51:39 +0300

Christer,

We are repeating the same things again and again in this thread.

> thing we are allowed to change is the IP address and/or the port?

If we receive a re-INVITE without SDP (this is the situation we are
talking about) this is true. The SDP in the 2xx will possibly differ
from the SDP currently used only in the port and the IP address.

Acutally if you think of the scenario it makes perfectly sense. You are
involved in a session, and you get a re-INVITE. Sonce it is not you the
one re-INVITing, you are not interested in changing anything. Therefore,
it makes sense to return the same SDP that is being used. So, you might
answer, why are we allow to change IP address and port number. Simply
because some frameworks such as Java does not allow you to change the
remote SDP without changing your port number. That is, a new ephemeral
local port number will be assigned to you when you change the remote
SDP.

I hope this clarifies things.

> SDP

Yes, you got it.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 20:11:34 +0300

Hi,

>from the SDP currently used only in the port and the IP address.

In another mail it was said that the "call-hold" attribute is also
allowed to be changed.

...and I then said that in future people may come up with other
attributes that also have to be allowed to be changed.

Also, we should specify that the port/address thing is for IP sessions
only. In ATM it may not be allowed to change the same parameters, for
example...
 
>local port number will be assigned to you when you change the remote

That may be true, and even if I still think that it may cause problems
in future I am not going to start arguing against it - as long as we
specify that it is IP specific. BUT, I still don't think that means that
we should allow a call on hold to be put un-hold - even if that is
currently done in SIP by changing the IP address.
 
>I hope this clarifies things.

The thing I am worried about is that when we start adding more media
attributes (for security, charging and who knows what) there will be a
need to also allow to change those in the 200 SDP... Like I said:
someone already wrote that we now are allowd to change the IP address
and port, AND the call-hold attribute, in the 200 response to a
re-INVITE w/o SDP...

Regards,

Christer Holmberg
Ericsson Finland