[OpenSIPS-Users] Mediaproxy ICE negotiations

[Saúl Ibarra Corretgé]

Hi,

On Mar 2, 2012, at 10:41 AM, John Quick wrote:

> Using Blink and other ICE compatible clients with Mediaproxy 2.x and
> OpenSIPS 1.7.x, I have been looking at some packet captures and reading RFC
> 5245. I would like to get a deeper understanding of how ICE works and the
> roles OpenSIPS and Mediaproxy play.
> 
> With Mediaproxy as a low priority "ice_candidate" (set using modparam) I can
> see that OpenSIPS adds the address of the Mediaproxy to the list of ICE
> candidates in the SDP. It sets the type to 'relay'. Devices that support ICE
> are required to sort and select potential candidates then test connectivity
> - one of the connectivity tests uses STUN requests. In my packet captures, I
> could see the UAC sending STUN requests to candidates of type "host", but
> did not see any sent to the Mediaproxy (this might have been because the
> other candidates were higher priority). I wondered how Mediaproxy is able to
> handle the STUN requests used during connectivity tests. Does it respond to
> them directly or is it somehow able to relay the requests in the same way as
> it would relay the RTP? Or should it never receive them because it is a
> relay?
> 

MediaPRoxy will relay STUN packets in userland until it receives one RTP packet from each endpoint. If the MediaProxy candidate was not chosen (no STUN binding request with flag set was received) it will do nothing, just bail out. If MediaPRoxy candidate was chose, a conntrack rule will be added and relaying will begin in kernel.

> Is there any documentation I may have missed that explains this?
> 

Have a look at these:

http://mediaproxy-ng.org/wiki/ICE
http://www.slideshare.net/saghul/ice-4414037


Regards,

--
Saúl Ibarra Corretgé
AG Projects