> > > > To avoid this clipping, we would need > > > draft-ietf-sip-dtls-srtp-framework > > > to require the SDP answer be sent reliably before 200 Okay > > -- perhaps > > > using a technique similar to what ICE does to send SDP reliably > > > in 18x messages. For DTLS-SRTP, this would mean re-transmitting > > > the 18x with the SDP answer until a DTLS Client Hello is > > seen. Would > > > that be acceptable? > > > > Sending the SDP answer in the first provisional response is a > > good idea and helps in the middlebox scenario. But this is > > not an alternative to allowing the receiver of the offer to > > take the passive role, but an addition. The receiver of the > > offer must have the passive role if he re-transmits "the 18x > > with the SDP answer until a DTLS Client Hello is seen", right? > > 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.) Peter _______________________________________________ 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
