Dear list,
I've successfully set up a Kamailio proxy build from the development trunk and configured it with the WebSockets example configuration file (adapted to my needs). I'm using sipml5 to test and if the two clients are within the same network everything works fine. As soon as one of the clients is on a different network I can initiate a call but there's no audio and video. This is probably a NAT issue so I wondered if anyone else got this working. If it's something in the Kamailio config, please let me know. If it's something in sipml5 I'll take it there. Boghe and IMSDroid aren't working either (they don't update the receive column in my location table, but that could be a Kamailio config error on my side too) so it could be related to the Doubango framework too.
Thanks in advance,
Jeremy
Hello,
If the call gets established at the signalling level then Kamailio is doing all that it can do.
Media NAT traversal for WebSockets is done using ICE and is a function of the clients - Kamailio does not have anything to do with this. I have had problems using Boghe across NAT before - I am not sure the ICE implementation in there works properly.
sipml5, however, will use the ICE implementation in the browser - which should work fine.
A good test would be to see if you can make a call between two sipml5 instances in different networks. If that works then it strongly indicates that there is a problem with the ICE implementation in Boghe/IMSDroid.
Regards,
Peter
Dear list,
I've successfully set up a Kamailio proxy build from the development trunk and configured it with the WebSockets example configuration file (adapted to my needs). I'm using sipml5 to test and if the two clients are within the same network everything works fine. As soon as one of the clients is on a different network I can initiate a call but there's no audio and video. This is probably a NAT issue so I wondered if anyone else got this working. If it's something in the Kamailio config, please let me know. If it's something in sipml5 I'll take it there. Boghe and IMSDroid aren't working either (they don't update the receive column in my location table, but that could be a Kamailio config error on my side too) so it could be related to the Doubango framework too.
Thanks in advance,
Jeremy
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 11/13/2012 11:17 PM, Peter Dunkley wrote:
Hello,
If the call gets established at the signalling level then Kamailio is doing all that it can do.
Media NAT traversal for WebSockets is done using ICE and is a function of the clients - Kamailio does not have anything to do with this. I have had problems using Boghe across NAT before - I am not sure the ICE implementation in there works properly.
sipml5, however, will use the ICE implementation in the browser - which should work fine.
A good test would be to see if you can make a call between two sipml5 instances in different networks. If that works then it strongly indicates that there is a problem with the ICE implementation in Boghe/IMSDroid.
Regards,
Peter
Hello Peter,
Calls get established at the signaling level, no matter which network or client. So I can leave Kamailio out of the equation. Also did some more testing and can make calls between two sipml5 clients on different networks. Regarding Boghe/IMSDroid, the devs at the company where I work are very familiar with that framework so we'll figure that out. I'll do some reading about ICE. No way it could be integrated like rtpproxy?
Regards,
Jeremy
No. The RTP/SAVPF media profile mandated by WebRTC is not supported by most gateways or servers.
At this point in time media must go directly between clients that support this profile.
Regards,
Peter
reading about ICE. No way it could be integrated like rtpproxy?
14 nov 2012 kl. 10:55 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
No. The RTP/SAVPF media profile mandated by WebRTC is not supported by most gateways or servers.
At this point in time media must go directly between clients that support this profile.
Regards,
Peter
reading about ICE. No way it could be integrated like rtpproxy?
The idea with ICE, if you read about it, is to have a TURN server, which eliminates the use of the RTP proxy. ICE pushes the responsibility of NAT traversal to the client, so ICE done right means that the client talks with a turn server (like a RTPproxy++) and reserves support, much like Kamailio today asks the RTP proxy for media ports.
The RTPproxy software could of course be made into a turn server with some code and a lot of energy, coming from soda drinks and cookies... :-)
If you have issues with the client handling this by itself, you can force media relays into the ICE offer on the server side, by manipulating the SDP. This of course only works when there's no protection like an electronic signature on the SDP.
If you want to learn more about ICE, please visit my presentation on slideshare: http://www.slideshare.net/oej/sip-2012-ice-nat-traversal-for-media
Cheers, /O
------
-- * Olle E. Johansson - oej@edvina.net * Kamailio & SIP Masterclass Miami FL December 2012 * http://edvina.net/training/
On 11/14/2012 11:04 AM, Olle E. Johansson wrote:
14 nov 2012 kl. 10:55 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:
No. The RTP/SAVPF media profile mandated by WebRTC is not supported by most gateways or servers.
At this point in time media must go directly between clients that support this profile.
Regards,
Peter
reading about ICE. No way it could be integrated like rtpproxy?
The idea with ICE, if you read about it, is to have a TURN server, which eliminates the use of the RTP proxy. ICE pushes the responsibility of NAT traversal to the client, so ICE done right means that the client talks with a turn server (like a RTPproxy++) and reserves support, much like Kamailio today asks the RTP proxy for media ports.
Hello Olle,
Got that, thanks.
The RTPproxy software could of course be made into a turn server with some code and a lot of energy, coming from soda drinks and cookies... :-)
If you have issues with the client handling this by itself, you can force media relays into the ICE offer on the server side, by manipulating the SDP. This of course only works when there's no protection like an electronic signature on the SDP.
If you want to learn more about ICE, please visit my presentation on slideshare: http://www.slideshare.net/oej/sip-2012-ice-nat-traversal-for-media
Will do, thanks for the link.
Regards,
Jeremy
Cheers, /O
--
- Olle E. Johansson - oej@edvina.net
- Kamailio & SIP Masterclass Miami FL December 2012
- http://edvina.net/training/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 11/14/2012 10:55 AM, Peter Dunkley wrote:
No. The RTP/SAVPF media profile mandated by WebRTC is not supported by most gateways or servers.
At this point in time media must go directly between clients that support this profile.
Regards,
Peter
Well I've got IMSDroid and Boghe to work so NAT issues seem to be resolved and I can continue testing with different clients. Thanks for all the info!
Regards,
Jeremy
-
Jeremy Jongepier -
Olle E. Johansson -
Peter Dunkley