ICE-SIP-SDP updates

Hello Roman and mmuscians

  Roman sent me the following things he would like to be addressed in the
ice-sip-sdp draft. I have taken a stab at incorporating them here :

https://github.com/suhasHere/ice-drafts/pull/3

Below i have tried to include responses to specific questions. ([Suhas])

1. Handling of ICE mismatch

Where is ICE mismatch currently defined? I cannot find this in either
rfc5245bis or ICE-SIP-SDP.

I think ICE mismatch should occur if address in c= line and port in m= line
do not match any of the candidates and <new>address in c= line is not dummy
address IN IP4 0.0.0.0 and port in m= line is not dummy port 9 </new>. This
is needed to match
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21#section-5.2.1 and
trickle ICE

[Suhas] ICE mismatch is discussed in 4.1.2.3,  4.1.3.1 and 11.2.2

2. Move general requirements from
https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2 into
ICE-SIP-SDP.

This section keeps repeating in protocol drafts and mostly represent
generic ICE offer/answer requirements. Key points here are:

a. any protocol running over ICE transport SHOULD implement UDP based
protocol version

b. when multiple candidates are sent in offer or answer during nomination
process UDP based candidate SHOULD be included in the candidate list and
SHOULD be selected as default candidate

c. proto value MUST match the protocol of the default candidate

d. for subsequent answer sent when ICE nomination process is not running,
default candidate and proto in m= line MUST match the nominated candidate.

[Suhas] Added the supporting text in the above PR. Also the repository has
HTML file for easy reading.

3. ICE transport tag

This is probably the most ambitious of all proposals. The idea is that
instead of specifying, for example, UDP/TLS/RTP/SAVPF, specify
ICE/TLS/RTP/SAVPF.

Using ICE tag instead of UDP serves the following purposes:

a. This indicates that ICE support is required. If remote end point does
not support ICE, negotiation for this m-line fails.

b. When ICE transport tag is used, only dummy address IN IP4 0.0.0.0 and
dummy port 9 are used in c= and m= line and they are never updated.
Transport of default or nominated candidate is irrelevant and does not
affect proto tag in the m= line. This also means that c= and m= line are
not updated when ICE nomination process completes and updated offer defined
in
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#section-4.1.5
is not sent.

[Suhas] IIRC, this topic was brought to discussion several times in the WG
and there was no consensus on defining a new ICE specific transport tag.
Personally, I feel this will be a large undertaking and we should avoid
doing this as part of this draft work. I am open to suggestions.

Please let me know your thoughts.

Cheers
Suhas

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic