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:bo...@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
