18 Apr
2011
18 Apr
'11
9:21 a.m.
Hey there Daniel,
Many thanks for so fast reply!
I will test the scenario recommended in our labs and come back to you asap.
The only thing which is still not clear to me is how to "store" the
used rtp set, so I can re-use it with INVITEs. The thing which I have
experienced is that on INVITE it is easy to spot the right
configuration since I know the address family of both originator(af
param) and destination(based on location), however on re-invite it
will help to have the setup loaded from somewhere. My idea was route
parameters, but impossible to set them in branches right now. Another
option will be to decide based on origination/termination address
family, but the termination one is right now available only in onsend
routes where the rtpproxy functions are not in.
Ta,
DanB
On Wed, Apr 13, 2011 at 3:55 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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