Subject: [Sip] RE: SDP hold

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 1 Aug 2001 02:21:33 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 3:10 PM
> To: [email-masked]; mmusic; Colin Perkins; Jonathan Rosemberg
> Subject: SDP hold
> 
> 
> 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.

Just to be clear, you do not need a new attribute for hold. In the current
usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is
the appropriate way to replace this functionality.

There is also a need, I think, to indicate that a media stream is
temporarily disabled (in which case there is neither RTP or RTCP in either
direction). But, this is not needed for hold.

-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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 01 Aug 2001 18:07:35 +0300

Hello,

> the appropriate way to replace this functionality.

Yes, sendonly  works if A puts B on hold in a sendrecv stream. However,
if you have a recvonly stream and you want to put it on hold, you need
the neither-send-nor-receive tag.  

> direction). But, this is not needed for hold.

OK, we can call the "on hold" scenario I just described as a
"temporarily disabled media" (the latter is probably more accurate).
Anyway, we still need the new tag. I do not really care if we call it
neithersendnorrecv, nomedia or inactive. However, as Christer suggested,
in order to be consistent with other protocols we can use "inactive".

Anyway, my question is: Colin, do you think that such a tag should be
included in SDPnew? Otherwise we can write a half-page draft defining
this attribute.

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: Colin Perkins <[email-masked]>
Date: Sun, 05 Aug 2001 20:42:27 +0100

>included in SDPnew? Otherwise we can write a half-page draft defining

I don't see the need for a new draft, so if there's consensus on this, send
me some suggested wording.

Colin

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 15 Aug 2001 00:14:54 +0300

Hello Colin,

> me some suggested wording.

In page 25 of:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.txt

we have to add the following attribute:

a=inactive
    This specifies that the tools should be started in inactive
    mode.  This is necessary for interactive conferences where users can
put other users on hold. No media is sent over an inactive media stream.
It can be either a session or media attribute, and is not dependent on
charset.

When you make the change let us know, since RFC2543bis will have to be
updated as well.

Best regards,

Gonzalo

Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 Aug 2001 10:30:23 +0100

I've made the change to my working copy, and will try to submit a revision
in the next couple of weeks (there are a few other changes in progress).

Colin