[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