Subject: [Sip] SDP hold

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Jul 2001 22:09:54 +0300

Hello,

I am sending this mail to SIP and MMUSIC because both groups are
interested in this issue. Sorry if somebody receives it twice.

We have already agreed that the SDP 0.0.0.0 mechanism for putting the
other party on hold does not work because it does not provide an address
for RTCP. Therefore, we need a new mechanism for putting on hold.

It seems that the best proposal is to use the direction tag (sendonly,
sendrecv, recvonly) to do this. It has been proposed to define a new
direction tag value that would mean that the media stream will not carry
media (neither-send-nor-receive). This could be encoded as a=nomedia,
for instance.

The first question is, do we all agree that this is the mechanism that
should be used? If so, is it appropriate to add this new tag value to
SDPnew (Colin?) ?

We also have to think about the current SDP 0.0.0.0 mechanism. While it
does not work for putting UAs in hold, it is useful in 3pcc scenarios,
where the controller does not have an IP address to provide to the
callee. Do we want to still use SDP 0.0.0.0 in this scenario?

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: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jul 2001 17:21:53 -0400

> callee. Do we want to still use SDP 0.0.0.0 in this scenario?

I know I will remember eventually, but can you remind me of such a
scenario? I think I recall some cases where you invite on hold, and then
reinvite. But when would this be used rather than inviting without SDP?
Where this isn't sufficient, it might be better to simply invite without
any media sessions at all, just to establish a signalling relationship.
(But I don't believe that is technically legal at the moment.)

One thing to keep in mind is that these should be mechanisms that work
with transports other than RTP and UDP. The connection oriented
transports introduce new problems. The c=0.0.0.0 for hold is one of the
things that don't work there either. The direction tag is much better.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 01 Aug 2001 00:51:27 +0300

Hello,

> reinvite. But when would this be used rather than inviting without SDP?

Actually you INVITE without SDP and get an SDP in the 200 OK. Now you
MUST send an SDP in the ACK.

You MAY try to send an INVITE with the SDP just obtained to the other
party and expect the 200 OK to arrive quickly enough. That is, before
the fist party gets tired of retransmitting the 200 OK without getting
an ACK.

Luckily you have another option. When you receive the 200 OK from your
first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then
you INVITE the other party and get his SDP. Now you can re-INVITE the
first party.

> (But I don't believe that is technically legal at the moment.)

You INVITE without any media description. The thing is that since you
will get media description in the 200 OK, you MUST send an SDP in your
ACK.

> things that don't work there either. The direction tag is much better.

Yes, the direction tag is the way to go (as I proposed in my previous
mail). I was just saying that the direction tag resolves 95% of the
scenarios, but not all of them.

Regards,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jul 2001 18:33:42 -0400

> you INVITE the other party and get his SDP. Now you can re-INVITE the

OK, that makes some sense. But it is problematic unless it can be
depended upon to work all the time, with any type of media. (The 3pcc
may not understand the media being used by the endpoints.) I am not sure
this is the case.

Also, isn't there a potential problem with this technique? 
After you re-INVITE the first party with the SDP from the other party,
the SDP you get back may not be the same as it was in the first invite.
If not, then you have to reinvite the other party again. This process
may never terminate. 

Seems like it would be better to count on turning around the invite to
the other party before the first party times out. It takes a long time
to timeout, so this shouldn't usually be a problem.

> will get media description in the 200 OK, you MUST send an SDP in your

What I meant was that you might invite with the intent of establishing a
call that has no media sessions. It isn't straightforward to do, since
if you offer SDP that contains no m= lines it is like offering no SDP.
You can probably do it by offering an SDP with "m=xxx 0 ...", but
probably most UAs would reject this as useless. And in any case it
wouldn't serve your purpose.

	Paul