[SR-Users] IPv4, IPv6, RTPProxy and Kamailio

Mark Zeman mark.zeman at students.fhnw.ch
Wed Dec 4 08:42:21 CET 2013


As it turns out, we did, in fact set the flags wrong: We didn't set them
at all!

In route[NATMANAGE] we were missing a crucial 'b' in
isBflagset(FLBV4V6), leading to the RTPProxy flags never being set to
FAIE or FAEI.

A diff (shame on us for not trying it first) revealed the mistake, and
now all is well.
On 12/03/2013 05:17 PM, Mark Zeman wrote:
> The SIP packets are fine - we are able to establish SIP session with a 
> secured control channel as easily as with an unsecured one.
> As long as the RTPProxy doesn't get involved (i.e. as long as it's 
> IPvX-IPvX and not IPv4-IPv6) everything works!
> With the RTPProxy, the connection gets established (SIP still works) 
> but RTP only comes from one side, the caller, and even that is not 
> relayed.
>
> It appears that Kamailio doesn't even enter the route[IPV4V6] part of 
> its config, for example...
>
> I will be able to send logs tomorrow, but I can show you our config, if 
> that might help.
>
>
>
>
>
> On Tue 03 Dec 2013 03:27:55 PM CET, Klaus Darilion wrote:
>> On 03.12.2013 14:23, Mark Zeman wrote:
>>> Hello all,
>>>
>>> The subject says most of it, I think.
>>>
>>> We set up our Kamailio and RTPProxy according to
>>> http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6
>>> with the addition of an alias (siplab.ch), and the DNS to go with it, as
>>> well as TLS and SRTP.
>>>
>>> However, we only get working calls IPv4-IPv4 and IPv6-IPv6! IPv4-IPv6 we
>>> get a proper connection,
>>> secured with SRTP, but no audio. Looking at the network, RTP packets go
>>> from the caller to the server,
>>> but nothing leaves the server and no RTP packets go from callee to
>>> server.
>>>
>>> Do you have any idea how to fix this?
>> Before fixing you need to find the problem. Probably the SDP get
>> rewritten incorrect. To debug this issue, you have to inspect the ip
>> address and ports in the received and sent SDPs if they are correct
>> (e.g. IPv4 and IPv6 address of the rtpproxy).
>>
>> You mentioned TLS - thus it is difficult to inspect the raw SIP
>> packets. Is such cases you can either:
>> - adding lots of xlog("$mb, ...") to your config and watch syslog
>> - use the sipcapture module to write every incoming and outgoing SIP
>> message to the DB, and analyze the packets in the DB
>> - Disable TLS. Use TCP. If it fails with TCP it will also fail with
>> TLS. Once it works over TCP, it will also work over TLS.
>> - If you really have a problem with TLS only, you could enable the
>> NULL cipher to have a unencrypted TLS connection, or use Wireshark's
>> TLS decoding capabilities
>> - Configure rtpproxy to communicate via UDP socket instead TCP socket.
>> Then you can also capture the communication between Kamailio and
>> rtpproxy.
>>
>> It seems you just call the rtpproxy functions with some wrong flags.
>> Make sure properly detect the direction (4to6 or 6to4) an set the i
>> and e flags accordingly.
>>
>> regards
>> Klaus
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131204/782389a4/attachment.html>


More information about the sr-users mailing list