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
On 11/13/2012 11:17 PM, Peter Dunkley wrote:
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:
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/
-
Jeremy Jongepier -
Olle E. Johansson -
Peter Dunkley