Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Jan 2017 12:00:37 +0000

The subject shall be ICE-SDP: Verify decision made…

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday 13 January 2017 at 13:32
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

Hi,

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.

The associated slides can be found here:

https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.pdf

The issue (slides 4-6) was when an answerer receives an offer with a m- line transport that it doesn’t support. The current O/A rules say that the transport in the answer must match the transport in the offer.

However, if ICE is used, there may be transports (offered using ICE candidates) that the answerer DOES support.

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.

Does anyone object to Alt#2?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Jan 2017 14:08:49 -0500

As I have mentioned before, I think ALT#1 is a better option: If we propose
mandatory to implement UDP based protocol for each transport family, only
use the mandatory to implement protocol for the default candidate, and the
transport mismatch problem will never occur.

As a bit of background, this issue appeared because of TCP/BFCP, which was
assumed to be the default protocol for BFCP with ICE. Since then, I think
we have decided that TCP/BFCP is not going to be used with ICE. For all the
other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF,
UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based
protocol should be used for backwards compatibility. I also do not see a
use case which will require that only tcp based candidates would be
included in the offer or the answer. Because of this, I think mandatory to
implement transport is a better approach.

This also have additional benefits of:

1. Providing m= and c= line information which will not cause the ICE
mismatch with older implementations
2. Not supplying any on the path signaling devices with bogus address
information required in ALT#2 answer
3. Improves general chances of negotiation succeeding with end points not
supporting ICE by picking the protocol more likely to succeed (chance of
TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP).

Regards,

_____________
Roman Shpount

On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg <
[email-masked]> wrote:

> From: mmusic <[email-masked]> on behalf of Christer Holmberg <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding
> non-supported transport in m- line of answer
>
> Hi,
>
> 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.
>
> The issue (slides 4-6) was when an answerer receives an offer with a m-
> line transport that it doesn’t support. The current O/A rules say that the
> transport in the answer must match the transport in the offer.
>
> However, if ICE is used, there may be transports (offered using ICE
> candidates) that the answerer DOES support.
>
> 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.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>