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

Hi,

Based on the feedback, my suggestion would be to move forward with ALT #2.

Now, as I said earlier, that still doesn’t prevent protocols from specifying an MIT transport, which is used as default candidate (read: ALT #1).

Regarding documentation, I guess it would at least have impact on ICE-SDP. The question is whether something is needed for 3264?

Chairs?

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 13 January 2017 21:09
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer

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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
The subject shall be ICE-SDP: Verify decision made…

From: mmusic <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Date: Friday 13 January 2017 at 13:32
To: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic