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

["Krishna Prasad Kalluri" <[e-mail]>]

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:[e-mail]] 
Sent: den 7 oktober 2008 22:12
To: Bob Gilman; Krishna Prasad Kalluri
Cc: [e-mail]; [e-mail]; Dan Wing
Subject: RE: [MMUSIC] Last
Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
CapabilityNegotiation) to Proposed Standard

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.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Bob Gilman
> Sent: Monday, October 06, 2008 11:50 AM
> To: 'Krishna Prasad Kalluri'
> Cc: [e-mail]; [e-mail]; Dan Wing
> Subject: Re: [MMUSIC] Last Call:draft-ietf-mmusic-sdp-capability-
> negotiation (SDP CapabilityNegotiation) to Proposed Standard
> 
> 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        [e-mail]      [phone]
> 
> Dan Wing wrote:
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Krishna Prasad
> Kalluri
> >> Sent: Sunday, October 05, 2008 10:54 AM
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> Subject: Re: [MMUSIC] Last
> >> Call:draft-ietf-mmusic-sdp-capability-negotiation (SDP
> >> CapabilityNegotiation) to Proposed Standard
> >>
> >> 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.
> >
> > 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
> >
> >> 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: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of The IESG
> >> Sent: den 29 september 2008 18:11
> >> To: IETF-Announce
> >> Cc: [e-mail]
> >> 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 [e-mail] mailing lists by 2008-10-13. Exceptionally,
> comments may
> >> be sent to [e-mail] 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-capa
> > bility-neg
> >> otiation-09.txt
> >>
> >>
> >> IESG discussion can be tracked via
> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> > w_id&dTag=
> >> 15573&rfc_flag=0
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic