Re: [bfcpbis] BFCP with ICE: MIT transport?

As an individual, I think Alt#2 is fine for BFCP and we do not need to define a mandatory to implement transport when using ICE.

Cheers,
Charles 

-----Original Message-----
From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Paul Kyzivat <paul.kyzivat@comcast.net>
Date: Friday, February 3, 2017 at 9:18 AM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] BFCP with ICE: MIT transport?

    On 2/3/17 8:56 AM, Christer Holmberg wrote:
    >
    > Hi,
    >
    > During the MMUSIC session in Seoul we discussed a number of issues
    > related to ICE-SDP. We made some decisions, and I got action points to
    > verify one of those on the list.
    >
    > One of those issues affect BFCP, when used with ICE.
    >
    > Example:
    >
    > BFCP client A supports both UDP and TCP, sends an SDP offer with UDP
    > proto in the SDP m- line. The TCP option is given as an ICE candidate.
    >
    > BFCP server B only supports TCP.

    When we talk about a BFCP implementation supporting TCP I think we mean 
    the BFCP that runs directly over TCP.

    But when talk about ICE over TCP I think we are talking about UDP 
    packets framed over TCP. That is really something different that the 
    BFCP implementation may or may not support.

    Its important not to conflate these.

    But I think that is mostly distinct from the question below.

    	Thanks,
    	Paul

    > The problem is that, according to RFC 3264, the m- line proto value in
    > the answer must match the value in the offer. But, server B does not
    > support UDP.
    >
    > Two alternatives were discussed:
    >
    > ALT #1: Every protocol that supports ICE must define a MIT transport.
    > That transport must always be reflected in the m- line proto (additional
    > transports are provided as ICE candidates).
    >
    > ALT #2: Allow an m- line proto value in the answer even if the answerer
    > does not support the associated transport – as long as the answerer
    > provides a candidate with the supported transport.
    >
    >
    > Based on the discussions, there was strong consensus to go for Alt#2,
    > which was allowing a transport in the m- line of the answer even if the
    > answerer doesn’t support it, as ICE candidates will be used to determine
    > the transport.
    >
    >
    > Having said that, that still does not prevent individual protocols to
    > specify a MIT transport.
    >
    >
    > So, my QUESTION is: should we specify a MIT transport for BFCP? Again,
    > this only applies to usage with ICE.
    >
    >
    > The associated slides from the meting can be found here:
    >
    >
    >
    > https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.pdf
    >
    >
    > (See slides 4-6)
    >
    >
    >
    > Regards,
    >
    >
    >
    > Christer
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > bfcpbis mailing list
    > bfcpbis@ietf.org
    > https://www.ietf.org/mailman/listinfo/bfcpbis
    >

    _______________________________________________
    bfcpbis mailing list
    bfcpbis@ietf.org
    https://www.ietf.org/mailman/listinfo/bfcpbis