Subject: Re: [Sip] Two SDP issues

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
> alternative without sacrificing backwards compatibility.

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]

_______________________________________________
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, 03 Jul 2001 15:30:36 -0400

I also am in favor of a=neithersendnorrecv (or perhaps a=hold would read
better). 

This differs from c=0.0.0.0 or a special port (I think port zero means
something else. I have seen port 9 suggested for this.) The a= approach
modifies how the transport(s) are used, but doesn't alter their
assignment, while changing c= or the port implies changes in assignment.
In the case of UDP this may not matter much, but in the case of
connection oriented media it can be very important. In the case of a
connection oriented media session, specifying c=0.0.0.0 could require
establishing a different connection to continue communication in the
other direction, or it could make it impossible to continue
communication in the other direction.

So, I think specifying a=sendonly or a=neithersendnorrecv should be
sufficient and recommended as the way to put oneself on hold. Messing
with the c= or the port should be considered an optional change that an
endpoint can make when it is consistent with the form of communication
being negotiated.

	Paul Kyzivat
	Cisco Systems

> Mark Watson wrote:
> 
> All,
> 
> I like the option of using just a=sendonly to put an existing two-way
> session on hold - it makes much more sense than c=0.0.0.0 for all the
> reasons given in this thread. Is there any difference (for a two-way
> media stream) between 'held' state and 'sendonly' state ? I'm sure SIP
> will not save us from crappy 'music' on hold, so there may still be
> media in the other direction.
> 
> Also, in a multi-media session I might want to put one media stream on
> hold whilst still receiving another. I can only really listen to one
> person at a time, but I can see multiple video sessions on my PC
> screen. So I might put the audio of a videocall on hold whilst I make
> a consultation call to another party.
> 
> In the case of a one-way session, putting this on hold basically
> temporarily cancels the media stream altogether. As someone suggested,
> it would be nice to have an a=neithersendnorrecv to complete the
> possibilities of sendonly, recvonly, sendrecv, but would another
> alternative in this case would be to set the port to zero ?
> 
> Regards,
> 
> Mark Watson
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: 02 July 2001 20:43
> > To: Jonathan Rosenberg
> > Cc: 'Paul Kyzivat'; Christer Holmberg; [email-masked]; mmusic
> > Subject: Re: [Sip] Two SDP issues
> >
> >
> > Hello Jonathan,
> >

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 4 Jul 2001 12:16:40 +0100

All,

I like the option of using just a=sendonly to put an existing two-way
session on hold - it makes much more sense than c=0.0.0.0 for all the
reasons given in this thread. Is there any difference (for a two-way media
stream) between 'held' state and 'sendonly' state ? I'm sure SIP will not
save us from crappy 'music' on hold, so there may still be media in the
other direction.

Also, in a multi-media session I might want to put one media stream on hold
whilst still receiving another. I can only really listen to one person at a
time, but I can see multiple video sessions on my PC screen. So I might put
the audio of a videocall on hold whilst I make a consultation call to
another party.

In the case of a one-way session, putting this on hold basically temporarily
cancels the media stream altogether. As someone suggested, it would be nice
to have an a=neithersendnorrecv to complete the possibilities of sendonly,
recvonly, sendrecv, but would another alternative in this case would be to
set the port to zero ?

Regards,

Mark Watson