[SR-Users] RTPProxy and bridging IPv4/IPv6 with parallel forking

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 13 15:55:24 CEST 2011


Hello,

On 4/13/11 2:10 PM, Dan-Cristian Bogos wrote:
> Hey Guys,
>
> I was recently playing with gateway-ing IPv4-IPv6 and hit the
> following scenario:
>   * AOR having contacts on both ipv4 and ipv6 and I wanted to do
> parallel forking.
>
> RTPProxy bridging works without any issue on a normal setup, however
> the problem shows up when needing to make calls toward rtpproxy to
> return both sides of bridge or only one (ee and ie combinations). Did
> any of you experiment with this scenario?
>
> EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6.
> The branch route looks the right place to call rtpproxy but when
> calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about
> which ports are we trying to cancel? One more issue would be with
> re-invite which must go out with the same ip of rtpproxy as original
> INVITE. Here we could store the bridge direction in some route
> parameter but unfortunately adding route params is not possible in
> branches.
>
> So what do u think?
interesting setup, indeed, but for sure to become very common in the 
near future, personally I haven't got to this scenario yet :-)

If does not work with one instance, I would use branch flags to mark the 
branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy 
for it. You can run two rtpproxy-es on the same server, in different sets:
http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059
http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496

So the branch doing ipv4-ipv6 will have a flag set and use a particular 
rtpproxy. On the 200ok, you can check the branch flag and engage again 
the proper rtpproxy.

Cheers,
Daniel

>
> DanB
>
> PS: The "normal" setup of forking calls only ipv4 or only ipv6 works
> smooth, so support of ipv6 in kamailio or rtpproxy is not
> questionable.

-- 
Daniel-Constantin Mierla
http://www.asipto.com




More information about the sr-users mailing list