13 Nov
2012
13 Nov
'12
10:43 p.m.
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
14 Nov
14 Nov
12:17 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
10:58 a.m.
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
11:55 a.m.
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?
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
12:04 p.m.
14 nov 2012 kl. 10:55 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
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(a)edvina.net
* Kamailio & SIP Masterclass Miami FL December 2012
* http://edvina.net/training/
1:03 p.m.
On 11/14/2012 11:04 AM, Olle E. Johansson wrote:
14 nov 2012 kl. 10:55 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
Hello Olle,
Got that, thanks.
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
Will do, thanks for the link.
Regards,
Jeremy
Cheers,
/O
------
--
* Olle E. Johansson - oej(a)edvina.net
* Kamailio & SIP Masterclass Miami FL December 2012
* http://edvina.net/training/
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:59 p.m.
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
4391
days inactive
4392
days old
6 comments
3 participants
participants (3)
-
Jeremy Jongepier -
Olle E. Johansson -
Peter Dunkley