Subject: RE: [Sip] Two SDP issues

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 15:35:45 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, June 29, 2001 9:58 AM
> To: Christer Holmberg
> Cc: Jonathan Rosenberg; 'Gonzalo Camarillo'; [email-masked]; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Since this seems to be turning into a discussion of problems with the
> existing means of representing Hold, let me add one more:
> 
> The c=0.0.0.0 mechanism for specifying hold doesn't work right for
> connection oriented media (the comedia I-P.) In reality it is another
> manifestation of the problem here with RTCP.

Right, good point.

> 
> Seems to me that if we were in a sendrecv session and I want 
> to put you
> on hold I should send SDP containing a:sendonly. If you 
> receive that and
> are happy with it then you should return a:recvonly. With 
> some kinds of
> transports it may be possible to also specify c=0.0.0.0 in 
> order to free
> up my transport resources for some other purpose, but that varies from
> case to case.
> 
> The situation is a little more complicated if the session is already
> oneway and the receiver wants to go on hold. I haven't worked that out
> yet.

I think that you need to have a hold attribute in addition to the sendonly
attribute since, as you say, the session may already be one way.

If we could ignore backwards compatibility, my preferred approach would be
to have an a=held attribute. If you want to put the stream on hold, you
re-INVITE with the sendonly attribute and add the a=held attribute to that
media. But, thats not going to be backwards compatible.

The only backwards compatible approach is to set the connection IP to
0.0.0.0, but include a held attribute that contains the actual IP address to
use:

a=hold 1.2.3.4

This will cause all the problems to be fixed when both sides support the new
attribute. When the answerer doesn't, you end up falling back to the current
hold mechanism. Ugly, and not my preference, but I see no other viable
alternative without sacrificing backwards compatibility.

-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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Jul 2001 22:42:34 +0300

Hello Jonathan,

> Ugly, and not my preference, but I see no other viable

In this situation, I believe we should have a clear idea of what we
understand by backwards compatibility. When a new feature is added, it
usually means that the addition of the new feature does not break all
the implementations that already work properly (but do not provide the
new feature).

However, in this scenario, there cannot be any implementation that works
properly right now. They just cannot send RTCP properly. Therefore, in
this situation, an elegant brand new mechanism might be acceptable. I do
not think that it would be a big deal to "break" current implementations
that do not work properly anyway.

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]