On Fri, Aug 22, 2008 at 8:37 AM, Dan Wing <[EMAIL PROTECTED]> wrote: > >> >> I have an idea for another approach, which might even be better >> >> than what is in the document right now: leave the DTLS >> client/server >> >> roles as described in draft-ietf-sip-dtls-srtp-framework-02, and >> >> when the offerer gets the 200 Ok, the offerer sends a DTLS >> >> HelloRequest. This will open NAT bindings and cause an SBC >> >> to 'latch' -- just like an ICE connectivity check would. >> >> >> >> (If there are no middleboxes interfering with the media path, >> >> the answerer would have initiated DTLS-SRTP by its own accord >> >> by sending ClientHello message(s).) >> >> >> > >> > A good idea. I'd say, the offerer should send this >> HelloRequest as soon >> > as he gets the SDP answer, if he hasn't got the ClientHello >> before. And >> > the answerer should send the answer as soon as possible, >> e.g. in an 18x, >> > even if PRACK is not used. (The HelloRequest lets the >> answerer know that >> > the answer has reached its destination.) >> >> When we discussed the latching issue before, this >> HelloRequest technique >> was considered and rejected in favor of the current STUN check based >> technique. Among the reasons was that we should have one set of >> NAT traversal mechanisms, namely those based on STUN and ICE. > > Considering Peter's proposal, though, is it more disruprive to > swap DTLS client/server roles, or more disruprive to keep them > the same (offerer is always DTLS server) and use HelloRequest?
I don't see a problem with the roles being variable, as long as the offerer is prepared to take on either role. -Ekr _______________________________________________ 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
