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

[Daniel-Constantin Mierla]

Hello,

On 4/18/11 3:21 PM, Dan-Cristian Bogos wrote:
> 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.
if it is a ipv4-to-ipv6 bridging, there should be two record-route 
headers added by kamailio, thus two Route headers in re-INVITE. You can 
use $(hdr(Route)[0/1]) to check if one of them is IPv6.
Alternative is to use htable to store per call-id the type of the call.

Cheers,
Daniel

>
> Ta,
> DanB
>
> On Wed, Apr 13, 2011 at 3:55 PM, Daniel-Constantin Mierla
> <miconda at 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
>>
>>

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