25 Mar
2013
25 Mar
'13
10:23 a.m.
Hello,
I have been doing some tests with kamailio and IPv6.
My initial setup was IPv6 only and now am I extending it to a dual-stack
environment. Well, and now I am starting to face some (interesting)
challenges.
So, the first step in the dual-stack environment was to install RTP
Proxy and configured kamailio to use it. With this setup, the UAs
locally registered were able to communicate with each-other no matter
with address family (IPv4/IPv6) they were using. So far so good.
But now I want to extend my tests a bit more ... I want to communicate
with the "outside world" (using ENUM and domain based SIP URIs). Do I
have a way to know if the "destination" is IPv4 or IPv6? Because I need
that information in order to properly bridge the calls on rtpproxy.
I tried to use the onsend_route but it didn't work. I mean, I am able to
know if the "next-hop" is IPv6 or IPv4 but it seems that it is "too
late" to use rtpproxy. BTW ... I am assuming that if the "next-hop" is
IPv6 then the final user agent will also be IPv6 (the same for IPv4)
Should I use some other approach? For example, failure route instead?
Does anyone have a similiar setup? How are you solving this issue?
- Miguel Baptista
25 Mar
25 Mar
10:46 a.m.
25 mar 2013 kl. 09:23 skrev Miguel Baptista <miguel.baptista(a)uninett.no>no>:
Hello,
I have been doing some tests with kamailio and IPv6.
My initial setup was IPv6 only and now am I extending it to a dual-stack environment.
Well, and now I am starting to face some (interesting) challenges.
So, the first step in the dual-stack environment was to install RTP Proxy and configured
kamailio to use it. With this setup, the UAs locally registered were able to communicate
with each-other no matter with address family (IPv4/IPv6) they were using. So far so
good.
But now I want to extend my tests a bit more ... I want to communicate with the
"outside world" (using ENUM and domain based SIP URIs). Do I have a way to know
if the "destination" is IPv4 or IPv6? Because I need that information in order
to properly bridge the calls on rtpproxy.
I tried to use the onsend_route but it didn't work. I mean, I am able to know if the
"next-hop" is IPv6 or IPv4 but it seems that it is "too late" to use
rtpproxy. BTW ... I am assuming that if the "next-hop" is IPv6 then the final
user agent will also be IPv6 (the same for IPv4)
Should I use some other approach? For example, failure route instead?
Does anyone have a similiar setup? How are you solving this issue?
The only way you can get an indication of the other end is to check their SRV records, but
that doesn't say anything about the devices and their media capability. The best way
moving forward is to support ICE for exactly this case.
The RFC for SIP IPv6 migration says that it's the IPv6 supporting device's
responsibility to send an offer with dual stack support, so your callers need to make sure
you have both IPv4 and IPv6 addresses in the ICE candidates in the SDP offer.
As I'm currently hacking SNMP, can you please check if there are any issues with IPv6
in the SNMPstats module?
/O
1 Apr
1 Apr
2:31 a.m.
New subject: Yet another IPv6 question related with rtpproxy ipv4/ipv6 bridging
On 3/25/2013 9:46 AM, Olle E. Johansson wrote:
25 mar 2013 kl. 09:23 skrev Miguel Baptista
<miguel.baptista(a)uninett.no <mailto:miguel.baptista@uninett.no>>:
Thanks for your feedback Olle.
Hello,
I have been doing some tests with kamailio and IPv6.
My initial setup was IPv6 only and now am I extending it to a
dual-stack environment. Well, and now I am starting to face some
(interesting) challenges.
So, the first step in the dual-stack environment was to install RTP
Proxy and configured kamailio to use it. With this setup, the UAs
locally registered were able to communicate with each-other no matter
with address family (IPv4/IPv6) they were using. So far so good.
But now I want to extend my tests a bit more ... I want to
communicate with the "outside world" (using ENUM and domain based SIP
URIs). Do I have a way to know if the "destination" is IPv4 or IPv6?
Because I need that information in order to properly bridge the calls
on rtpproxy.
I tried to use the onsend_route but it didn't work. I mean, I am able
to know if the "next-hop" is IPv6 or IPv4 but it seems that it is
"too late" to use rtpproxy. BTW ... I am assuming that if the
"next-hop" is IPv6 then the final user agent will also be IPv6 (the
same for IPv4)
Should I use some other approach? For example, failure route instead?
Does anyone have a similiar setup? How are you solving this issue?
The only way you can get an indication of the other end is to check
their SRV records, but that doesn't say anything about the devices and
their media capability. The best way moving forward is to support ICE
for exactly this case.
The RFC for SIP IPv6 migration says that it's the IPv6 supporting
device's responsibility to send an offer with dual stack support, so
your callers need to make sure you have both IPv4 and IPv6 addresses
in the ICE candidates in the SDP offer.
As I'm currently hacking SNMP, can you please check if there are any
issues with IPv6 in the SNMPstats module?
/O
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
26 Mar
26 Mar
6:33 p.m.
New subject: Yet another IPv6 question related with rtpproxy ipv4/ipv6 bridging
Hello,
On 3/25/13 9:23 AM, Miguel Baptista wrote:
Hello,
I have been doing some tests with kamailio and IPv6.
My initial setup was IPv6 only and now am I extending it to a
dual-stack environment. Well, and now I am starting to face some
(interesting) challenges.
So, the first step in the dual-stack environment was to install RTP
Proxy and configured kamailio to use it. With this setup, the UAs
locally registered were able to communicate with each-other no matter
with address family (IPv4/IPv6) they were using. So far so good.
But now I want to extend my tests a bit more ... I want to communicate
with the "outside world" (using ENUM and domain based SIP URIs). Do I
have a way to know if the "destination" is IPv4 or IPv6? Because I
need that information in order to properly bridge the calls on rtpproxy.
I tried to use the onsend_route but it didn't work. I mean, I am able
to know if the "next-hop" is IPv6 or IPv4 but it seems that it is "too
late" to use rtpproxy. BTW ... I am assuming that if the "next-hop" is
IPv6 then the final user agent will also be IPv6 (the same for IPv4)
Should I use some other approach? For example, failure route instead?
Does anyone have a similiar setup? How are you solving this issue?
I see few
options here:
- use two outbound proxies, one for IPv4 and one for IPv6 -- from your
main proxy you can do parallel forking to the two edge proxies, one of
the branches will fail if no device/server is listening on that protocol
(or it will be dropped in onsend_route if after dns is not the expected
IP version)
- use lua or other embedded language to do dns lookup from config and
decide in branch route what to do. Alternative is to execute external
script or some web service
- export to the config the internal dns lookup function so it will be
done on demand and detect outgoing IP layer version (this requires c
coding, perhaps not much -- preferable solution, because will remove it
from my to-do)
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
1 Apr
1 Apr
2:31 a.m.
New subject: Yet another IPv6 question related with rtpproxy ipv4/ipv6 bridging
On 3/26/2013 5:33 PM, Daniel-Constantin Mierla wrote:
Hello,
On 3/25/13 9:23 AM, Miguel Baptista wrote:
Thanks for your feedback Daniel.
Hello,
I have been doing some tests with kamailio and IPv6.
My initial setup was IPv6 only and now am I extending it to a
dual-stack environment. Well, and now I am starting to face some
(interesting) challenges.
So, the first step in the dual-stack environment was to install RTP
Proxy and configured kamailio to use it. With this setup, the UAs
locally registered were able to communicate with each-other no matter
with address family (IPv4/IPv6) they were using. So far so good.
But now I want to extend my tests a bit more ... I want to
communicate with the "outside world" (using ENUM and domain based SIP
URIs). Do I have a way to know if the "destination" is IPv4 or IPv6?
Because I need that information in order to properly bridge the calls
on rtpproxy.
I tried to use the onsend_route but it didn't work. I mean, I am able
to know if the "next-hop" is IPv6 or IPv4 but it seems that it is
"too late" to use rtpproxy. BTW ... I am assuming that if the
"next-hop" is IPv6 then the final user agent will also be IPv6 (the
same for IPv4)
Should I use some other approach? For example, failure route instead?
Does anyone have a similiar setup? How are you solving this issue?
I see few
options here:
- use two outbound proxies, one for IPv4 and one for IPv6 -- from your
main proxy you can do parallel forking to the two edge proxies, one of
the branches will fail if no device/server is listening on that
protocol (or it will be dropped in onsend_route if after dns is not
the expected IP version)
- use lua or other embedded language to do dns lookup from config and
decide in branch route what to do. Alternative is to execute external
script or some web service
- export to the config the internal dns lookup function so it will be
done on demand and detect outgoing IP layer version (this requires c
coding, perhaps not much -- preferable solution, because will remove
it from my to-do)
Cheers,
Daniel
--
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4254
days inactive
4260
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Miguel Baptista -
Olle E. Johansson