For testing ICE you can use on Mac, Linux or Windows this command line client:

http://sipsimpleclient.com/wiki/sip_session

type /rtp and you can see the whole ICE negotiating results:

[email protected]> /rtp
Output of RTP statistics and ICE negotiation results on console is now activated
[email protected]> /audio [email protected]
Initiating SIP session from 'sip:[email protected]' to 'sip:[email protected]' via 
sip:81.23.228.150:5060;transport=udp...
 
ICE negotiation succeeded in 0s:644
 
Local ICE candidates:
(RTP)    95.97.50.27:55656               type srflx
(RTP)    192.168.1.122:55656             type host
(RTP)    10.211.55.2:55656               type host
(RTP)    10.37.129.2:55656               type host
(RTCP)   95.97.50.27:55890               type srflx
(RTCP)   192.168.1.122:55890             type host
(RTCP)   10.211.55.2:55890               type host
(RTCP)   10.37.129.2:55890               type host
(RTP)    81.23.228.150:51782             type prflx
(RTCP)   81.23.228.150:51783             type prflx
 
Remote ICE candidates:
(RTP)    81.23.228.150:51780             type relay
(RTCP)   81.23.228.150:51781             type relay
(RTP)    95.97.50.27:55876               type srflx
(RTP)    192.168.1.122:55876             type host
(RTP)    10.211.55.2:55876               type host
(RTP)    10.37.129.2:55876               type host
(RTCP)   95.97.50.27:54037               type srflx
(RTCP)   192.168.1.122:54037             type host
(RTCP)   10.211.55.2:54037               type host
(RTCP)   10.37.129.2:54037               type host
 
ICE connectivity check results:
(RTP)    192.168.1.122:55656 <--> 192.168.1.122:55876   Succeeded
(RTP)    10.211.55.2:55656 <--> 10.211.55.2:55876       Succeeded
(RTP)    10.37.129.2:55656 <--> 10.37.129.2:55876       Succeeded
(RTCP)   192.168.1.122:55890 <--> 192.168.1.122:54037   Succeeded
(RTCP)   10.211.55.2:55890 <--> 10.211.55.2:54037       Succeeded
(RTCP)   10.37.129.2:55890 <--> 10.37.129.2:54037       Succeeded
(RTP)    95.97.50.27:55656 <--> 95.97.50.27:55876       Succeeded
(RTCP)   95.97.50.27:55890 <--> 95.97.50.27:54037       Succeeded
(RTP)    81.23.228.150:51782 <--> 81.23.228.150:51780   Succeeded
(RTCP)   81.23.228.150:51783 <--> 81.23.228.150:51781   Succeeded
 
Audio session established using "G722" codec at 16000Hz
Audio RTP endpoints 192.168.1.122:55656 (ICE type host) <-> 192.168.1.122:55876 
(ICE type host)

On Jun 23, 2011, at 11:23 AM, Barsan Liviu wrote:

> Hi Saul,
> 
> I mean by 'the rest' that I don't have to write code in the opensips.cfg to 
> have ICE ( e.g. see which kind of NAT it is etc.), just to set the parameters 
> for the mediaproxy as written below.
> I think I understood from your answer what I have to do.
> 
> In the same time I'm thinking how to test ICE, do you think a proper way is 
> to make two tests:
> 1. Two clients behind a router that does not have symmetric nat (e.g. conic 
> nat) and server with public IP, in this case the media stream should follow 
> the STUN way (not via relay).
> 2. Two clients behind a router with symmetric nat, in this case media stream 
> should go via relay (mediaproxy).
> Obviously we should have clients with ICE support, we use Bria 3.2, 2.5.4 or 
> Blink.
> 
> And to follow the media streams I have to install CDRTool and FreeRadius 
> server.
> Do you think this scenario is suitable to prove the ICE capability of the 
> server?
> 
> Thanks,
> Liviu
> 
> From: Saúl Ibarra Corretgé <[email protected]>
> To: OpenSIPS users mailling list <[email protected]>
> Sent: Thu, June 23, 2011 10:20:47 AM
> Subject: Re: [OpenSIPS-Users] ICE How-To
> 
> Hi,
> 
> On Jun 22, 2011, at 5:35 PM, Barsan Liviu wrote:
> 
> > Hello,
> > 
> > We have built until now an OpenSIPs-MediaProxy server which knows far end 
> > NAT traversal, Messaging and Presence (basic), it works reliable.
> > Now we would like to add ICE capability to this solution and we are not 
> > sure on How-To. According to http://mediaproxy-ng.org/wiki/ICE, we 
> > understood that is enough to set the mediaproxy modules parameters as 
> > written in the site, something like:
> > 
> > ice_candidate="high-priority"
> > ice_candidate_avp="$avp(s:ice_priority)"
> > 
> 
> The AVP is meant to be used for fine grained control, the ice_candidate 
> module parameter should be enough in most cases.
> 
> > It is enough to have these settings?
> > The rest will be done by MediaProxy and OpenSIPs automatically?
> > 
> 
> What do you mean by 'the rest' ? If you client is offering ICE and 
> OpenSIPS/MediaProxy are mangling the signaling, that setting will make 
> MediaProxy modify the SDP in such a way that ICE is not broken.
> 
> If you want to really test ICE you'll want to set the ice_candidate parameter 
> to low-priority, otherwise chances are MediaPRoxy will always be used.
> 
> 
> Regards,
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to