Subject: Re: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-capability-negotiation (SDP Capability Negotiation) to Proposed Standard

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Sun, 5 Oct 2008 19:53:33 +0200

Hi,

I have been reading sdp-capability-negotiation document.
This document currently describes methods to negotiate different RTP
profiles (transport capabilities)

Is there any method to negotiate different components in 'c' line. Did
you consider this during the design of SDP capability negotiation?
How about different IP version negotiation?
If I understand it's possible to have dual IP stacks. Is there any way
to negotiate which version of IP to use.

There can be middle boxes to provide gatewaying different versions of IP
or tunneling. I am wondering about the end to end negotiation
mechanisms. 

Regards
Krishna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of The IESG
Sent: den 29 september 2008 18:11
To: IETF-Announce
Cc: [email-masked]
Subject: [MMUSIC] Last Call:
draft-ietf-mmusic-sdp-capability-negotiation (SDP Capability
Negotiation) to Proposed Standard

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:

- 'SDP Capability Negotiation '
   <draft-ietf-mmusic-sdp-capability-negotiation-09.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-10-13. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-neg
otiation-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15573&rfc_flag=0

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Oct 2008 10:16:51 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Krishna Prasad Kalluri
> Sent: Sunday, October 05, 2008 10:54 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Last 
> Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP 
> CapabilityNegotiation) to Proposed Standard
> 
> Hi,
> 

ICE provides for negotiation of IP version of the media path,
with a significant advantage:  using the IP version that *works*.

For SIP, it is described in draft-ietf-sipping-v6-transition-07.txt and 
I expect a similar technique could be used for RTSP 2.0.

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of The IESG

---

From: Bob Gilman <[email-masked]>
Date: Mon, 06 Oct 2008 11:49:38 -0600

Krishna-
Work is also underway on a SDP capabilities draft to include a "ccap"
attribute to do what you want.  The primary motivator was to handle the
circuit option originally described in draft-garcia-mmusic-sdp-cs.
As Dan points out, ICE provides/requires the ability to test the options
and use the one that works, rather than being required to negotiate one
option before responding.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 7 Oct 2008 14:12:03 -0600

Krishna,

   Thank you for bringing your comments on the mmusic list.  

   Here is some more context about what the working group has considered
during the work on SDP cap neg to add to what Dan and Bob wrote.

1. Requirements for SDP cap neg
Prior to defining a solution for SDP cap neg, Flemming and the design
team assembled a few requirements
(http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation
-reqts-01). As you will notice, most of the requirements were around
media description and transport.  And if you look at page 10, it says:
"  o  Support for negotiation of unicast and multicast addresses as
      alternatives. It was suggested as a requirement initially, but
      subsequent discussion led to its removal.

   o  Support for negotiation of IPv4 and IPv6 addresses as
      alternatives. It was suggested as a requirement initially, but
      subsequent discussion led to its removal.
"

2. SDP and alternative network address types
This was first addressed by ANAT (http://tools.ietf.org/html/rfc4091);
ICE is deprecating ANAT.

Hope this helps.

Jean-Francois
MMUSIC co-chair.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bob Gilman
> Sent: Monday, October 06, 2008 11:50 AM
> To: 'Krishna Prasad Kalluri'
> Cc: [email-masked]; [email-masked]; Dan Wing
> Subject: Re: [MMUSIC] Last Call:draft-ietf-mmusic-sdp-capability-
> negotiation (SDP CapabilityNegotiation) to Proposed Standard
> 
> Krishna-

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Wed, 8 Oct 2008 14:43:52 +0200

Jean-Francois,

Thanks for the information.

At the end of page 6 the document mentions about -- "Extension for other
capabilities ... "
Is it possible to add a statement some thing like "alternative network
address types can be negotiated with the mechanisms described in ICE"

Thanks
Krishna

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: den 7 oktober 2008 22:12
To: Bob Gilman; Krishna Prasad Kalluri
Cc: [email-masked]; [email-masked]; Dan Wing
Subject: RE: [MMUSIC] Last

Krishna,

2. SDP and alternative network address types This was first addressed by
ANAT (http://tools.ietf.org/html/rfc4091);
ICE is deprecating ANAT.

Hope this helps.

Jean-Francois
MMUSIC co-chair.

> attribute to do what you want.  The primary motivator was to handle 
> the circuit option originally described in draft-garcia-mmusic-sdp-cs.
> As Dan points out, ICE provides/requires the ability to test the 
> options and use the one that works, rather than being required to 
> negotiate one option before responding.
> -Bob
> > ICE provides for negotiation of IP version of the media path, with a

> > significant advantage:  using the IP version that *works*.
> >
> >> There can be middle boxes to provide gatewaying different versions 
> >> of IP or tunneling. I am wondering about the end to end negotiation

> >> [mailto:[email-masked]] On Behalf Of The IESG
> >> final comments on this action.  Please send substantive comments to

> >> the [email-masked] mailing lists by 2008-10-13. Exceptionally,
> comments may