1. Section 6.6, "ICE Interaction" says:
If ICE is not being used, then there is potential for a bad
interaction with SBCs via "latching", as described in [I-D.ietf-
mmusic-media-path-middleboxes]. In order to avoid this issue, if ICE
is not being used, then the passive side MUST do a single
^^^^^^^^^^^^
This would be clearer if it said something like "the side using
'setup:actpass'" (rather than "the passive side"), because with the current
draft neither side is using "setup:passive".
unauthenticad STUN [I-D.ietf-behave-rfc3489bis] connectivity check in
^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Connectivity checks are defined in ICE, not in rfc3489bis, so the reference
should be made to ICE. (Also, unauthenticated is misspelled.)
However, I do not believe ICE defines an unauthenticated connectivity check;
rather, ICE defines only an authenticated connectivity check.
order to open up the appropriate pinhole. All implementations MUST
be prepared to answer this request during the handshake period even
if they do not otherwise do ICE.
Do we need a full STUN transaction (STUN request/response) to fix the latching
problem described in ietf-mmusic-media-path-middleboxes? I expect sending a
STUN indication with exponential backoff until receipt of a DTLS-SRTP
ClientHello may well be sufficient? Afterall, something on the path might
interfere with the connectivity check (drop it, for example) and there isn't
much need to continue re-transmitting the STUN request (following STUN's
retransmission rules) if the DTLS-SRTP handshake is proceeding. This wouldn't
interfere with DTLS's state machine; rather, the code already needed to
demultiplex STUN/RTP/DTLS could tickle STUN to cease
One more related question: if we are behind an SBC and have the latching
problem described in ietf-mmusic-media-path-middleboxes, and the call forked,
do we need to send STUN requests (as the draft currently states) or STUN
indications (as I am suggesting) to each fork??
2. Section 8.1:
OLD:
Answerers SHOULD send use this UPDATE mechanisms.
NEW:
Answerers SHOULD use this UPDATE mechanisms.
3. Section A.7, R-ACT-ACT
Do we want to say anything about E.164 namespace, and what the DTLS-SRTP
framework can reasonably provide in conjunction with RFC4474?
-d
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
