Patch 1 #862
Patch 1 #862
Conversation
Alternate approach to resolving rtcweb-wg#854 which allows for future WebRTC implementations to interop with non-WebRTC ICE users.
Fixing ambiguity about m-section versus entire SDP
|
Looks like the after the sip-sdp reference got converted into a and that is triggering the failing check. |
fixing broken <t> closing tag
I fat-fingered for -- fixed... |
| data m= sections, implementations MUST support the | ||
| <xref target="RFC5764"></xref>. Implementations MUST indicate this | ||
| profile for each media m= line they produce in an offer unless the | ||
| media section contains only TCP candidates; if all candidates use TCP as a |
There was a problem hiding this comment.
Ideally it would be a little bit more clear what this sentence translates to for trickle ICE implementations. I would expect that a trickle ICE implementation should start with "UDP/TLS/RTP/SAVPF". But I can see how someone could mis-read this in the way he/she thinks the implementation needs to wait for trickle ICE gathering to be finished to decide which protocol to use in the m= line. And thus would void the trickle ICE benefits for the purpose of obeying to this sentence.
There was a problem hiding this comment.
In the IESG review of one of my drafts, Ekr(?) indicated that one can't use "MUST...unless" wording. That triggered some discussions, but there was no outcome. I personally have no problem with it, but just to make sure Ekr is fine with it. One would assume he is, since he is listed as co-author :)
There was a problem hiding this comment.
What is a "JSEP implementation". A browser implementing the JSEP API, or a JS application using it? I understand if the profile will be included in each offer within the API, but why is it a MUST for a JS application to send it in an offer on the wire?
There was a problem hiding this comment.
I would suggest that language should be:
In the initial offer or any offer that initiates ICE restart, implementations MUST indicate "UDP/TLS/RTP/SAVPF" profile for each media m= line they produce in an offer. In the subsequent offers which do not initiate ICE restart, if all candidates for this m= section use TCP as a transport, implementations MUST indicate "TCP/DTLS/RTP/SAVPF", to allow for compatibility with non-WebRTC implementations of I-D.ietf-mmusic-ice-sip-sdp.
There was a problem hiding this comment.
Roman is correct but this is NUTS. We are doing all of this so we can support middle boxes tampering with our signalling in a way that we know won't work? Seriously ? Note all of this is fine with SBCs as they are actually in the signalling and can signal if they do ICE or not, but we are doing this for ALGs which pretty much no one uses, are a really bad idea, are not recommended by the IETF - how about we get rid of all the ALG stuff and replace it with SDP MUST be transported over a protocol that provides integrity.
There was a problem hiding this comment.
Let's consider an edge case, where a browser that has an active TCP candidate connects to a MCU with a passive TCP candidate. In this case, the browser TCP candidate is 1.2.3.4:9 - i.e., the discard port. I assume that we would then put '9' into the m= line, as usual?
There was a problem hiding this comment.
@rshpount, can you point to an example of the weird Chrome behavior with TCP candidates?
There was a problem hiding this comment.
Lastly, are we saying we would only ever do this when there were only TCP candidates offered, or also in a re-offer case when the selected candidate pair are both TCP candidates? If we go down this path, I would think we would want to do the latter.
There was a problem hiding this comment.
I ask again: what is meant by "implementation"?
Are we suggesting that a JS application using the JSEP API is required to use "UDP/TLS/RTP/SAVPF"?
There was a problem hiding this comment.
@juberti I will try to answer multiple comments in this single one.
When a browser that has an active TCP candidate connects to a MCU with a passive TCP candidate, then the browser TCP candidate is 1.2.3.4:9 - i.e., the discard port and end point puts '9' into the m= line.
According to @adamroach in https://mailarchive.ietf.org/arch/msg/mmusic/Btq1iVG_BrrvshTps1toyzyWWRs , Chrome will add UDP attribute to an offer even if ICE nomination was completed and TCP candidate was nominated. I have not verified this.
During the discussions at MMUSIC we decided that when initial or offer with ICE restart is initiated, the capabilities of the remote end point are not always known. In case of initial offer little is known about remote and ICE restart can be initiated to allow for 3rd party call control, which can change the remote end point. Because of this, since in both cases remote end point might not support ICE TCP or TCP based proto, it is safer to use UDP based proto in the offer, even when TCP candidate pair is currently being used. It was also decided that it is cleaner not to change proto during ICE nomination process, since nominated pair can change during the signaling exchange. This resulted in always using UDP for initial offer, during ICE restart or when ICE nomination is still in progress and using TCP only when ICE nomination is complete and TCP candidate was nominated.
| added, implementations should use TCP/DTLS/RTP/SAVPF as a | ||
| transport token when the candidate in question is using TCP, in | ||
| order to facilitate interactions with non-JSEP SIP/SDP | ||
| implementations, which assign meaning to the protcol field. |
There was a problem hiding this comment.
| implementations, which assign meaning to the protcol field. | |
| implementations, which assign meaning to the protocol field. |
There was a problem hiding this comment.
"Current implementations" is tricky, because "current" will be whenever someone reads the spec - today or in 2 years - and what is claimed may change over time. Therefore, I suggest using "At the time of writing this specification", or something similar.
There was a problem hiding this comment.
What does "Current implementations of JSEP" refer to? Browsers implementing the API, or applications using the API? I think we shall make a clear separation, and say that the JSEP API, nor the current applications using it, update the m= or c= lines. I also think that we should recommend that applications that are expected to interact with legacy/non-JSEP endpoints to actually update the c= and m= lines.
There was a problem hiding this comment.
yeah, this entire paragraph seems unnecessary to me. I suppose we could add a note to say why we made this change, for posterity, but I don't see the need for caveats regarding the current deployed base, given that the browsers typically move faster than the specs.
| instead driven by ICE.</t> | ||
| </list></t> | ||
|
|
||
| <t>For data m= sections, implementations MUST support the | ||
| "UDP/DTLS/SCTP" profile and MUST indicate this profile for |
There was a problem hiding this comment.
This section needs to be updated to match. It should say something like:
For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile. In the initial offer or any offer that initiates ICE restart, implementations MUST indicate "UDP/DTLS/SCTP" profile for each data m= line they produce in an offer. In the subsequent offers which do not initiate ICE restart, if all candidates for this m= section use TCP as a transport, implementations MUST indicate "TCP/DTLS/SCTP", to allow for compatibility with non-WebRTC implementations of I-D.ietf-mmusic-sctp-sdp.
There was a problem hiding this comment.
Furthermore, "TCP/DTLS/SCTP," should be added to the list of supported protocols below.
There was a problem hiding this comment.
Agree this is needed, although I think this can be written more succinctly - willing to take a shot if there is consensus on the direction.
There was a problem hiding this comment.
Couldn't we have separate sections for ice-initiating offers and other offers?
| profile for each media m= line they produce in an offer unless the | ||
| media section contains only TCP candidates; if all candidates use TCP as a | ||
| transport, implementations MUST indicate "TCP/DTLS/RTP/SAVPF," to | ||
| allow for compatibility with non-WebRTC implementations of |
There was a problem hiding this comment.
What is the comparability issue on this ? Keep in mind that if there is a single UDP candidate that will never work nd never be use but is still on the list, then it seems like this will say TCP instead of UDP. I'm not arguing against the change but this text implies that if you don't do this, it won't work with non-WebRTC stuff and I'm just quirous for a concrete example of when it does not work
There was a problem hiding this comment.
Main use case for this (or for the "fix up" offer) is monitoring. When you have a system that sits only on the signaling path between end points and works with both SIP and WebRTC end points at the same time, "fix up" offer is being used to determine the nominated candidate pair. This, in turn, is being used to troubleshoot connection issues based on actual addresses used for media and candidate type (host, relay or reflexive). It is possible to get this information from WebRTC end points using stats interface, but "fix up" offer is the only way to get this from a lot of SIP end points.
During ICE development some people mentioned firewalls which apply different port closing policies based on what they intercept in SDP, but I do not think I saw this in practice.
Also, a lot of things currently being fixed by SDP manipulation either on the client or server side. So, I would expect things not to break now, but to have some sort of SDP manipulation script to work around this when working with WebRTC.
There was a problem hiding this comment.
I am extremely skeptical about this monitoring case. People do monitoring from SBCs that understand all of ICE or if they don't support trickle, they don't pass the messages. Can someone point me at a commercially available device that is used for monitoring and actually needs these "fix up" messages? I realize we might have needed this is 2002 but I really wonder if we are just holding on to old things that are no longer really needed.
There was a problem hiding this comment.
Consider somebody running a SIP proxy which supports SIP-over-WebSockets (opensips), regular VoIP clients (pjsip based which do support ICE and DTLS SRTP), JavaScript based SIP clients (jssip or sipml), voicemail server which support ICE-TPC, and an SBC, which supports ICE-TCP, to place calls out of the system. SIP Homer ( http://sipcapture.org) is used for monitoring. Everything is mostly peer-to-peer and SBC is only used for PSTN calls out of the system, so it is on the media path for a small percentage of the calls.
There was a problem hiding this comment.
If people want to remove the "fix up" messages from ICE in general I don't think this is the correct venue for discussing that.
There was a problem hiding this comment.
"Fix up" messages are removed if "ice2" ice-option is set: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.3.4
"Fix up" offer should be automatically suppressed if new implementations are used. In any case, "fix up" is easy enough to implement via API. All application needs to do is call createOffer once ICE nomination is complete. The only thing which is required of the browser is to generate a valid session description with only nominated candidates and correct c=/m= line.
There was a problem hiding this comment.
"Fix up" messages are removed if "ice2" ice-option is set: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.3.4
"Fix up" offer should be automatically suppressed if new implementations are used. In any case, "fix up" is easy enough to implement via API. All application needs to do is call createOffer once ICE nomination is complete. The only thing which is required of the browser is to generate a valid session description with only nominated candidates and correct c=/m= line.
Correct. But, does the browser do that? If the initial offer included UDP in the c/m- line, but TCP candidates were nominated, will that be reflected in the c/m- line if the application later calls createOffer?
There was a problem hiding this comment.
This is one of the reasons why I argue browser should include a correct proto in the m= line.
| <xref target="I-D.ietf-mmusic-ice-sip-sdp"></xref>.</t> | ||
|
|
||
| <t><list style="hanging"> | ||
| <t hangText="Note:">Current implementations of JSEP do not update m= or c= lines |
There was a problem hiding this comment.
I guess the key question here is if we expect browser to change to do the extra "clean up" transaction or not. IF they are not going to chance, this seems like "YOU SHOULD BUT WE KNOW YOU WON'T" type language that is just harmful to implementations because the spec implies things will do something different than what they do
There was a problem hiding this comment.
Currently it is fairly simple to use WebRTC JavaScript API to implement something which is RFC 5245 compatible, including generation of the extra "clean up" offer. Browser does not have to force the "clean up" offer. If an application needs such offer, this offer can generated by an application when ICE nomination is complete. What we are trying to make sure here is that SDP generated in such offer is compatible with RFC 5245, i.e. includes only default ICE candidates and have address and protocol information in c=m= line that match the default candidate. What we are trying to avoid is the need to SDP patching to keep this update offer compatible with legacy RFC 5245, which only happens when TCP candidate is nominated.
| <t hangText="Note:">Current implementations of JSEP do not update m= or c= lines | ||
| after a candidate pair is selected. When these facilities are | ||
| added, implementations should use TCP/DTLS/RTP/SAVPF as a | ||
| transport token when the candidate in question is using TCP, in |
There was a problem hiding this comment.
Think need to cover the case of what happens after moving to transport X, if ICE conditions change and the transport is changed to Y. Does this all update again ?
There was a problem hiding this comment.
I think if a re-offer is ever sent, it simply includes the selected pair and protocol in c=/m.
There was a problem hiding this comment.
Unless already specified, that needs to be clear in the document.
| implementations, which assign meaning to the protcol field. | ||
| Note that in interactions with other JSEP implementations, the | ||
| use of ICE makes any syntactically valid address/port/transport | ||
| tuple in the m= and c= lines equivalent, as the signalling is |
There was a problem hiding this comment.
"equivalent" seems wrong here. I think you are trying to say that JSEP devices can write data into theses fields that my be read by non JSEP devices but the JSEP device pretty much only read the data in ICE stuff.
| data m= sections, implementations MUST support the | ||
| <xref target="RFC5764"></xref>. Implementations MUST indicate this | ||
| profile for each media m= line they produce in an offer unless the | ||
| media section contains only TCP candidates; if all candidates use TCP as a |
There was a problem hiding this comment.
Let's consider an edge case, where a browser that has an active TCP candidate connects to a MCU with a passive TCP candidate. In this case, the browser TCP candidate is 1.2.3.4:9 - i.e., the discard port. I assume that we would then put '9' into the m= line, as usual?
| data m= sections, implementations MUST support the | ||
| <xref target="RFC5764"></xref>. Implementations MUST indicate this | ||
| profile for each media m= line they produce in an offer unless the | ||
| media section contains only TCP candidates; if all candidates use TCP as a |
There was a problem hiding this comment.
@rshpount, can you point to an example of the weird Chrome behavior with TCP candidates?
| data m= sections, implementations MUST support the | ||
| <xref target="RFC5764"></xref>. Implementations MUST indicate this | ||
| profile for each media m= line they produce in an offer unless the | ||
| media section contains only TCP candidates; if all candidates use TCP as a |
There was a problem hiding this comment.
Lastly, are we saying we would only ever do this when there were only TCP candidates offered, or also in a re-offer case when the selected candidate pair are both TCP candidates? If we go down this path, I would think we would want to do the latter.
| <t hangText="Note:">Current implementations of JSEP do not update m= or c= lines | ||
| after a candidate pair is selected. When these facilities are | ||
| added, implementations should use TCP/DTLS/RTP/SAVPF as a | ||
| transport token when the candidate in question is using TCP, in |
There was a problem hiding this comment.
I think if a re-offer is ever sent, it simply includes the selected pair and protocol in c=/m.
| added, implementations should use TCP/DTLS/RTP/SAVPF as a | ||
| transport token when the candidate in question is using TCP, in | ||
| order to facilitate interactions with non-JSEP SIP/SDP | ||
| implementations, which assign meaning to the protcol field. |
There was a problem hiding this comment.
yeah, this entire paragraph seems unnecessary to me. I suppose we could add a note to say why we made this change, for posterity, but I don't see the need for caveats regarding the current deployed base, given that the browsers typically move faster than the specs.
| instead driven by ICE.</t> | ||
| </list></t> | ||
|
|
||
| <t>For data m= sections, implementations MUST support the | ||
| "UDP/DTLS/SCTP" profile and MUST indicate this profile for |
There was a problem hiding this comment.
Agree this is needed, although I think this can be written more succinctly - willing to take a shot if there is consensus on the direction.
|
Closing in favor of #863. |
Alternate approach to satisfy #854, in a way that allows for interop between future WebRTC implementations and SIP users of ICE.