Subject: Re: [Sip] Open Issue #150: too many ways of saying "don't send me media"

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 16:58:58 -0500

Beyond Keiths objection at IETF52 to discussing this in the sip group at 
all (I have cc'd mmusic), consensus on this proposal at the meeting was 
that as long as there were well defined semantics for all of these, 
there is no reason to prevent someone from using them.

The semantics are:

c=0.0.0.0: will cease reception of RTP and RTCP, no longer the 
recommended way to do hold, has issues with SRTP keying, ipv6, 
connection oriented media, etc. Generally bad.

a=inactive/sendonly - stops only RTP

port 0: turns of media streams - safe to unload codecs, etc.

bw=0: will turn off reception of RTP and RTCP

Thanks,
Jonathan R.

Drage, Keith (Keith) wrote:

> Given that all SDP has now been removed from the bis draft, I am not sure
> how this remains a SIP WG open issue.
> 
> Surely this issue has now transferred to the MMUSIC documentation.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked]
> 
> 
>>----------
>>From: 	Jonathan Rosenberg[SMTP:[email-masked]]
>>Sent: 	06 December 2001 5:41
>>To: 	[email-masked]'
>>Subject: 	[Sip] Open Issue #150: too many ways of saying "don't send
>>me media"
>>
>>Issue:
>>
>>There are a bunch of ways to say "don't send me media":
>>
>>c=0.0.0.0
>>a=inactive,sendonly
>>zero port
>>bw=0
>>
>>What do these all mean, and do we need them all?
>>
>>Discussion: We've agreed on most of this already. The only real issue is
>>to
>>say that bw=0 is never used. So, the proposal is:
>>
>>c=0.0.0.0          DEPRECATED
>>a=inactive,sendly  PREFERRED
>>zero port:         disables media stream
>>bw=0               DONT USE
>>
>>-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://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
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.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: Flemming Andreasen <[email-masked]>
Date: Thu, 20 Dec 2001 22:46:52 -0500

> bw=0: will turn off reception of RTP and RTCP

Do we really need the "bw" one ? It seems like a misuse to me. After all, you
wouldn't start sending every other packet if the allowable bandwidth was cut in
half. Also, if we head down this path, why not have a zero maxptime to do the
same ? Unless there is a real need for this, it should rather be forbidden to
do these kinds of silly things IMO.

-- Flemming

> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 17:04:34 -0500

Flemming Andreasen wrote:

> Do we really need the "bw" one ?

No, its not really NEEDED. The point Henning had made at IETF is that 
the treatment for any bandwidth number is well defined; in that case, 
disallowing zero is a special case. I see no reason to disallow it as a 
special case when it has defined meaning for all values.

-Jonathan R.