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

Daniel-Constantin Mierla miconda at gmail.com
Thu Apr 14 17:00:46 CEST 2011



On 4/14/11 11:23 AM, Klaus Darilion wrote:
>
> Am 14.04.2011 09:55, schrieb Olle E. Johansson:
>> 14 apr 2011 kl. 09.48 skrev Klaus Darilion:
>>
>>>
>>> Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
>>>> 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.
>>> That's a nice idea. Some time ago I tried the same setup and
>>> failed. Are there some easy methods to find out if a target is IPv4
>>> or IPv6, e.g. something like
>>>
>>> if ( is_ipv6("$rd") ) { ... }
>>>
>> Now you have opened a can of worms. Let me start :-)
>>
>> If I have a dual stack UA and registers with an IPv4 address - how do
>> you know that I'm dual stack? I really don't need an RTP proxy.
> Maybe the rtpproxy is used anyway (NAT traversal, legal intercept ...)
>
>> The IETF thinks we should use SIP outbound and register twice.
>> Kamailio doesn't support this as far as I remember and won't see that
>> we have two locations for the very same UA.
>>
>> Now, if you have a URI like "sip:board at kamailio.org" and that URI's
>> domain has two priority levels of SRV records. The first level is
>> only IPv4 and the second level includes IPv6 to indicate a preference
>> to receive calls in IPv4 and an ability to receive them in IPv6 if
>> that's preferred by the caller. Would Kamailio understand this?
> No. Because in branch route you only see the domain, you will not know
> if the request will be forwarded via IPv4 or IPv6.
When dealing with domains, yes, since it is before the dns lookup. For 
the case of location records, you have the received ip/port/af stored so 
you can check it.

Now, since Kamailio is a lot about flexibility, of course there are 
workarounds, coming now to my mind:
- you don't know if destination is IPv4 or IPv6, so you can create two 
branches for same domain, one will use rtpproxy for ipv4, the second for 
ipv6. Then based on the reply, you complete the rtp relaying session 
with the proper rtpproxy
- second, assuming you try first ipv4 and the destination is ipv6 and 
cannot relay media to ipv4, I expect it will return quickly a specific 
reply code that can be handled in failure_route and create a new branch 
and use rtpproxy for ipv6 now.

Tricks with current version, for the future a dns resolver function can 
be used in the confing, considering we have internal caching for dns, 
that can be handy to avoid double queries to dns server for same record 
and same call.

Now, if the result is having both ipv4 and ipv6, then the higher 
priority will be used. Again, this is more like inter-domain peering, 
rather than calls through location service.

Cheers,
Daniel
>
> But to be pragmatic: for a service provider without "open SIP
> connectivity" it does not matter as the customers will use IP addresses
> and not domains for there clients.
>
> regards
> Klaus
>
>> There is work to be done here. /O
>>
>>
>> _______________________________________________ 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
> _______________________________________________
> 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

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




More information about the sr-users mailing list