[sr-dev] RTPEngine in reINVITE/on-hold use case

Richard Fuchs rfuchs at sipwise.com
Thu Jul 17 19:05:43 CEST 2014


On 07/17/14 12:48, Waite, Hugh wrote:
> Hi,
> 
> I am using rtpengine to convert SRTP to RTP for audio and video and I am
> also doing this for reINVITEs.
> 
> At the moment I am using Chrome on the SRTP side and Linphone on the RTP
> side. So far, Linphone has been the most stable for sending and
> receiving VP8 video calls.
> 
>  
> 
> Linphone does not do ICE, but Chrome does. I need to force all traffic
> through rtpengine (to encrypt/decrypt) so I use the “ICE=force” flag in
> both directions.
> 
>  
> 
> I’ve put the SDP content of an on-hold scenario at the end of this email.
> 
>  
> 
> When Linphone puts the call on hold, it sets the connection to
> “c=0.0.0.0” and the direction to “a=sendonly” in the reINVITE. However,
> it does keep the same valid port numbers on the m= lines.
> 
> RTPEngine processes this and sends SDP to Chrome that has “c=0.0.0.0”,
> “a=ice-lite” and “a=inactive”. The port numbers are set to 0
> (disabled/rejected)
> 
> Chrome does some other interesting stuff with that, so I am investigating.
> 
>  
> 
> RFC5245 (ICE) §9 is all about subsequent offer-answer exchanges. In this
> ‘on-hold’ scenario, I don’t believe there is any need to restart the ICE
> processing.
> 
> From §9.1.1.1
> 
>    These rules imply that setting the IP address in the c line to
> 
>    0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
> 
>    MUST NOT utilize this mechanism for call hold, and instead MUST use
> 
>    a=inactive and a=sendonly as described in [RFC3264 <http://tools.ietf.org/html/rfc3264>].
> 
> In a lite implementation, I think that the “a=ice-ufrag” and “a=ice-pwd”
> attributes need to be included (with the same values) and also the
> currently selected (active) candidate §9.1.1.1 & §9.1.3.2.
> 
>  
> 
> RTPEngine appears to have disabled the two media streams, rather than
> putting them on hold. Is this a deliberate choice or the best choice
> given the multiple possibilities of client implementations? And can this
> behaviour be improved?
> 
> If the call is taken off-hold later, I would prefer not to have to do
> the full ICE restart, including TURN, DTLS handshakes etc. etc. if it
> can be avoided.


This is one of those cases where no matter what you do, it's always
gonna be wrong for somebody. :)

There was a recent commit [1] which slightly changed the behaviour when
putting a call on hold in this manner, I suspect your build is older
than this. I'm not sure if it would fix your particular issue though.

Rtpengine could translate a null c= address into the respective
attributes (and leave a valid c= address), but then you run into the
problem of breaking compatibility with clients which don't support or
misunderstand this type of signalling.

So yes, there's definitely room for improvement (there always is), it's
just a matter of figuring out what the Right Thing[tm] to do is. :)

cheers

[1]
https://github.com/sipwise/rtpengine/commit/a7784f5ca3437d1c7b58308022ef0e06cfa4d745



More information about the sr-dev mailing list