ICE How-To

classic Classic list List threaded Threaded
10 messages Options
bll
Reply | Threaded
Open this post in threaded view
|

ICE How-To

bll
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)"

It is enough to have these settings?
The rest will be done by MediaProxy and OpenSIPs automatically?

Thank you,
Liviu


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

Saúl Ibarra Corretgé
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
bll
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

bll
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é <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

Saúl Ibarra Corretgé
Hi,

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.
>

I'd add a 3rd test case: 2 clients behind the same NAT (symmetric, for example), media should go peer-to-peer without using a relay.

> 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?
>

Yes. In the media trace section, CDRTool will tell you if ICE was chosen and thus there is no media trace. Blink (on the Mac version) will also show you detailed information about the ICE negotiation in the RTP tab in the log window.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
bll
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

bll
Hi Saul,

Thanks for the answers, now it is clear the How-To for ICE.
Liviu


From: Saúl Ibarra Corretgé <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
Sent: Thu, June 23, 2011 12:34:57 PM
Subject: Re: [OpenSIPS-Users] ICE How-To

Hi,

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.
>

I'd add a 3rd test case: 2 clients behind the same NAT (symmetric, for example), media should go peer-to-peer without using a relay.

> 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?
>

Yes. In the media trace section, CDRTool will tell you if ICE was chosen and thus there is no media trace. Blink (on the Mac version) will also show you detailed information about the ICE negotiation in the RTP tab in the log window.


Regards,

--
Saúl Ibarra Corretgé
AG Projects




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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

Adrian Georgescu
In reply to this post by bll
<base href="x-msg://86/">For testing ICE you can use on Mac, Linux or Windows this command line client:


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

Output of RTP statistics and ICE negotiation results on console is now activated
Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' via <a href="sip:81.23.228.150:5060;transport=udp">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é <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
bll
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

bll
Hello,

This seems a big shortcut related to install FreeRadius and CDRTool.

Thank you,
Liviu


From: Adrian Georgescu <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
Sent: Thu, June 23, 2011 5:11:42 PM
Subject: Re: [OpenSIPS-Users] ICE How-To

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


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

Output of RTP statistics and ICE negotiation results on console is now activated
Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' 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é <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
bll
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

bll
In reply to this post by Adrian Georgescu
Hello,

We were doing as suggested below and we got:

2011-06-24 17:50:17 Registered contact "sip:fmwkphsx@192.168.6.100:37289" for sip:[hidden email] at 80.97.X.X:5060;transport=udp (expires in 600 seconds).
Detected NAT type: Blocked
[hidden email]> /rtp
Output of RTP statistics and ICE negotiation results on console is now activated
[hidden email]> /audio [hidden email]
Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' via sip:80.97.X.X:5060;transport=udp...
Audio session established using "G722" codec at 16000Hz
Audio RTP endpoints 192.168.6.100:50000 <-> 80.97.X.X:50006
Remote SIP User Agent is "Bria 3 release 3.2.1 stamp 62387"
2011-06-24 17:51:18 RTP statistics: RTT=0 ms, packet loss=0.0%, jitter RX/TX=0/0 ms
SIP session with sip:[hidden email] ended by remote party
Session duration was 10 seconds

From this is missing the ICE negotiation as you pasted below, this means that we do not have a working ICE?

We have the following settings for mediaproxy module:
modparam("mediaproxy", "mediaproxy_socket", "/tmp/dispatcher.sock")
modparam("mediaproxy", "mediaproxy_timeout", 500)
modparam("mediaproxy", "signaling_ip_avp", "$avp(s:nat_ip)")
modparam("mediaproxy", "media_relay_avp", "$avp(s:media_relay)")
modparam("mediaproxy", "ice_candidate", "low-priority")



Thank you,
Liviu



From: Adrian Georgescu <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
Sent: Thu, June 23, 2011 5:11:42 PM
Subject: Re: [OpenSIPS-Users] ICE How-To

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


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

Output of RTP statistics and ICE negotiation results on console is now activated
Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' 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é <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

Saúl Ibarra Corretgé
Hi,

On Jun 24, 2011, at 5:01 PM, Barsan Liviu wrote:

> Hello,
>
> We were doing as suggested below and we got:
>
> 2011-06-24 17:50:17 Registered contact "sip:fmwkphsx@192.168.6.100:37289" for sip:[hidden email] at 80.97.X.X:5060;transport=udp (expires in 600 seconds).
> Detected NAT type: Blocked
> [hidden email]> /rtp
> Output of RTP statistics and ICE negotiation results on console is now activated
> [hidden email]> /audio [hidden email]
> Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' via sip:80.97.X.X:5060;transport=udp...
> Audio session established using "G722" codec at 16000Hz
> Audio RTP endpoints 192.168.6.100:50000 <-> 80.97.X.X:50006
> Remote SIP User Agent is "Bria 3 release 3.2.1 stamp 62387"
> 2011-06-24 17:51:18 RTP statistics: RTT=0 ms, packet loss=0.0%, jitter RX/TX=0/0 ms
> SIP session with sip:[hidden email] ended by remote party
> Session duration was 10 seconds
>
> From this is missing the ICE negotiation as you pasted below, this means that we do not have a working ICE?
>

Did you enable ICE on the account you are using from sip-session? You need to use the sip-settings script for that.

Also check the SIP trace and see if the SDP contains ICE data.

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
bll
Reply | Threaded
Open this post in threaded view
|

Re: ICE How-To

bll
Hi Saul,

After enabling ICE for the account it worked.

Thanks,
Liviu


From: Saúl Ibarra Corretgé <[hidden email]>
To: OpenSIPS users mailling list <[hidden email]>
Sent: Fri, June 24, 2011 6:06:21 PM
Subject: Re: [OpenSIPS-Users] ICE How-To

Hi,

On Jun 24, 2011, at 5:01 PM, Barsan Liviu wrote:

> Hello,
>
> We were doing as suggested below and we got:
>
> 2011-06-24 17:50:17 Registered contact "sip:fmwkphsx@192.168.6.100:37289" for sip:[hidden email] at 80.97.X.X:5060;transport=udp (expires in 600 seconds).
> Detected NAT type: Blocked
> [hidden email]> /rtp
> Output of RTP statistics and ICE negotiation results on console is now activated
> [hidden email]> /audio [hidden email]
> Initiating SIP session from 'sip:[hidden email]' to 'sip:[hidden email]' via sip:80.97.X.X:5060;transport=udp...
> Audio session established using "G722" codec at 16000Hz
> Audio RTP endpoints 192.168.6.100:50000 <-> 80.97.X.X:50006
> Remote SIP User Agent is "Bria 3 release 3.2.1 stamp 62387"
> 2011-06-24 17:51:18 RTP statistics: RTT=0 ms, packet loss=0.0%, jitter RX/TX=0/0 ms
> SIP session with sip:[hidden email] ended by remote party
> Session duration was 10 seconds
>
> From this is missing the ICE negotiation as you pasted below, this means that we do not have a working ICE?
>

Did you enable ICE on the account you are using from sip-session? You need to use the sip-settings script for that.

Also check the SIP trace and see if the SDP contains ICE data.

--
Saúl Ibarra Corretgé
AG Projects




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

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