Re: [rtcweb] SRTP not mandatory-to-use

["Olle E. Johansson" <[e-mail]>]

4 jan 2012 kl. 01:28 skrev Bernard Aboba:

> 
> Ted Hardie said: 
> 
> > I'm a little lost. In a gateway implemented in a back-to-back user
> > agent, won't you end up with the same illusion?
> > 
> > The case I think you're talking about is this:
> > 
> > UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2
> > 
> > Do you expect that the gateway would be refuse to use SRTP on one side
> > if it intended not to use it on the other? 
> 
> 
> [BA] If the SBC needed to enable communication with a legacy endpoint, then it
> might want to negotiate security compatible with that endpoint. 
> 
> Today there are PSTN gateways that support SRTP with SDES, but interop is 
> frequently an issue (I've had to debug interop issues countless times), so 
> I've often had to advise customers to turn SRTP off until an issue was resolved. 

Interoperability with SRTP has been an issue at several SIPits. But we do see a change,
we see huge improvements in the number of successful interoperability tests.

From the summary of the latest SIPit:

"** SRTP

All implementations supported SDES for SRTP key exchange.

Good interop with many different combinations of endpoints.

Some calls were left up for an extended period so that sequence number wrapping and roc increments were tested. Once the roc had changed the call was put on hold and resumed with success. In this situation new RTP streams with different SSRCs were created and the sequence number/roc combination re-generated thus proving that support for multiple SRTP contexts exists.

Debate surrounding how to signal 'best-effort crypto' continues. Some implementations choose to advertise RTP/AVP with a=crypto attributes and then go crypto if answer also has them and non-crypto if they do not. RTP/SAVP is used to signal the desire for mandatory crypto. Another approach observed was to repeat the same media line twice, once for crypto and once for non-crypto and rely on the receiving end to only accept one of them and port reject the other. In this case both m-lines had the same port number and payload number descriptions so if a receiving end accepted both then the originator would have no clue as to whether it was receiving crypto or non-crypto traffic."

https://www.sipit.net/SIPit29_summary

The first time I personally tested SRTP at SIpit we couldn't get any calls through across vendor boundaries...

We will have to bring Webrtc to SIPit for testing :-)

/O