Subject: [MMUSIC] Re: [Sip-implementors] updated offer/answer draft

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2002 20:19:15 -0500

Sorry to be slow commenting - I am backed up on my reading.

I have one possible nit. You have incorporated a:inactive as the
replacement for c=0.0.0.0 for hold, and indicated that use of c=0.0.0.0
is deprecated though it still must be supported by recipients.

I think it is a bit strong to say that it is deprecated. There are still
cases where it is *needed*. In particular, a B2BUA may need to offer on
hold to solicit an answer, with the intent to make a new offer later
after another offer/answer exchange with another party. In this case, it
may not desire or be capable of receiving RTCP, or of providing an
address/port to do so. The C=0.0.0.0 provides an effective solution in
this case. 

So, rather than being deprecated for all use, I think the use of
c=0.0.0.0 ought to be be more narrowly restricted.

	Paul

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I have just submitted an update to the offer/answer model draft. Until
> it appears in the archives, you can pick it up at:
> 
> http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-00.txt
> 
> This draft includes all of the changes agreed to since IETF 52 and on
> the list since then. There are no open issues that I am aware of.
> 
> Perhaps the most substantial change is the allowance of different
> payload type numbers in each direction, as per list discussion on
> mmusic. Other changes are noted in the changes section.
> 
> Thanks,
> Jonathan R.
> --
> 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-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 03:33:42 -0500

Well, technically, working group last call has ended, and I am about to
submit this draft. But, since this was easy, I incorporated your
comment. The text now reads:

RFC 2543 specified that placing a user on hold was accomplished by
setting the connection address to 0.0.0.0. Its usage for putting a
call on hold is no longer recommended, since it doesn't allow for RTCP
to be used with held streams, doesn't work with IPv6, and breaks with
connection oriented media. However, it can be useful in an initial
offer when the offerer knows it wants to use a particular set of media
streams and formats, but doesn't know the addresses and ports at the
time of the offer. An agent {\MUST} be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither RTP
nor RTCP should be sent to the peer.

Thanks,
Jonathan R.