Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06

From: Flemming Andreasen <[email-masked]>
Date: Tue, 01 Feb 2011 17:28:40 -0500

Seems reasonable to me as well. Is this a request to adopt it as a WG 
item ?

A few quick draft comments:
- I'm a little confused by the examples in Section 6. Why is "*" used as 
the media format ?
- Section 6.2: Why is the media type changed from 6.1 ? Why is the 
connection shown as "new" ? Please add a note explaining why the port 
changes to 9 in the answer.
- IANA Considerations: I believe you are defining both "SCTP" and 
"SCTP/DTLS" for IANA registration.
- NAT considerations: In lieu of the amount of effort we have put into 
NAT traversal, I think it would be useful to add a section around this.
- Multihoming: It would be worthwhile discussing the current re-INVITE 
approach compared to an actual listing of the different addresses (refer 
to James Polk/Randy Stewart's MMUSIC message of March 18, 2009)

Thanks

-- Flemming

On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
>
> Folks,
>
> [as an individual]
>
> the following draft allows offer/answer exchanges to establish streams
> that are transported by SCTP.
>
> http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
>
> We need to decide what to do with the draft, whether to let it die or to
> progress it. The ability to describe SCTP-based streams seems useful
> even though, as we all know, SCTP is not nearly as widely deployed as
> UDP or TCP. Does anybody see any reason why the offer/answer model
> should not support SCTP-based streams?
>
> Your comments are appreciated.
>
> Thanks,
>
> Gonzalo
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 2 Feb 2011 09:46:39 +0200

Hi Flemming,

> Seems reasonable to me as well. Is this a request to adopt it as a WG

yes, that would be the next natural step given that people seem to think
it is a reasonable thing to specify.

Thanks,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Feb 2011 11:55:22 -0800

> - I'm a little confused by the examples in Section 6. Why is "*" used
> as the media format ?

On that topic, do we want draft-loreto-mmusic-sctp-sdp to include the 
ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally 
necessary to traverse non-SCTP-aware firewalls and NATs.  But tunneling
SCTP over UDP brings with it other issues, including bifurcating SCTP
itself.

(*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps

-d

> approach compared to an actual listing of the different addresses
> (refer to James Polk/Randy Stewart's MMUSIC message of March 18, 2009)
> 
> Thanks
> 
> -- Flemming
> 
> 
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 3 Feb 2011 09:19:21 +0200

Hi Dan,

good point. It all depends on what we want to do in the NAT traversal
area. If we want to define how to use ICE to establish SCTP streams,
then we should include UDP encapsulation as well. Something like what
RFC 5770 did for HIP.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 3 Feb 2011 07:57:42 -0800

> then we should include UDP encapsulation as well.

ICE should be discussed, but SCTP doesn't need to be tunneled over
UDP to do that.

A problem we (the industry) have with migrating from HTTP-over-TCP
to HTTP-over-<fancy_new_transport> is that we have nothing like SDP's
"m=" line.  And, as you know, SDP's "m=" line doesn't really allow
negotiating different transports, which is where ICE and/or SDP Capability
Negotiation come in.

For SDP to offer SCTP but also provide fallback to plain UDP or offer
fallback to plain TCP, I think ICE needs to be considered.

But, as for SCTP-over-UDP tunneling, I am really hoping we can just
not do it.  It further complicates things.  However, everyone should
be aware of it and make that decision themselves for the scope of
the MMUSIC document.

-d

> Something like what

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 4 Feb 2011 10:42:46 +0200

Hi Dan,

yes, it is a scope question: whether we want ICE to only use SCTP over
IP candidates or we want ICE to use SCTP over UDP candidates as well. In
HIP, the hosts negotiate whether they support (and are willing to use)
UDP encapsulation in their base exchange. If both support it and are
willing to use it, they can include ESP over UDP candidates in their
"offers" and "answers". Otherwise, they only include ESP over IP candidates.

In this way, any implementation is free not to support UDP encapsulation
at all. On the other hand, implementations concerned with NATs can
support it and use it between them to increase the likelihood of
establishing associations successfully.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Feb 2011 08:15:30 -0800

Another factor is that while HIP-over-UDP is RFC'd (I didn't
say standard or experimental), SCTP-over-UDP is only an 
individual document.

-d

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Friday, February 04, 2011 12:43 AM
> To: Dan Wing
> Cc: 'Flemming Andreasen'; 'mmusic'
> Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
> 
> Hi Dan,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Feb 2011 11:43:27 -0500

Considering that we are likely looking at a lot of end-user endpoints 
here when considering SCTP media streams in SDP, it would seem to 
greatly facilitate the practical deployment aspects if we included 
SCTP-over-UDP (assuming SCTP-over-UDP continues to move forward).

-- Flemming