Hi,
Is it possible to use force_send_socket() with an IPv6 address in Kamailio 3.1? I get the error
ERROR: fix_actions: force_send_socket: could not resolve X:X:X:X:X:X:X:X:5060
where X:X:X:X:X:X:X:X is my IPv6 address.
Another problem (not sure if it's a real problem but looks weird) is when I use X::X:X:X:X:X which is actually X:0:0:X:X:X:X:X, then when starting kamailio, the "Listening on" message on stdout expands it correctly, but the error message for force_send_socket drops a 0, so it says that it can't resolve 'X:0:X:X:X:X:X' which is not a valid IPv6 address, right?
Andreas
Hello,
is the ipv6 address in between square brackets (can you give exact usage of the foce_send_socket())? It should work as the bridging ipv4-ipv6 is using the same mechanism -- may be an issue with the exported function to config, though. Can you try to set $fs as alternative to force_send_socket()?
Cheers, Daniel
On 12/14/11 5:19 PM, Andreas Granig wrote:
Hey Daniel,
On 12/14/2011 06:00 PM, Daniel-Constantin Mierla wrote:
I tried both ways, like force_send_socket(x::x:5060); and force_send_socket([x::x]:5060); - both resulting in the same error.
However, doing $fs="[x::x]:5060"; works perfectly fine, thanks for the hint!
A fix for force_send_socket would maybe still be good to not confuse people.
Thanks, Andreas
Hey,
One more thing related to outbound routing. Maybe this question is stupid, but I still have to learn a lot regarding IPv6 :)
So my Jitsi registered fine, the contact in location table looks like this:
contact: sip:testuser1@[x::x]:5060;transport=udp;registering_acc=192_168_51_133
When I call this AoR (from an IPv4 subscriber, but that shouldn't matter), it's being loaded into R-URI, I select my IPv6 socket using $fs, then do the relay. However, I get this error in my logs (first line is my log message before t_relay):
INFO: <script>: Relaying request, fs='udp:[x::y]:5060' - M=INVITE R=sip:testuser1@[2a00:4600:1:0:18fc:aeff:fea0:e6af]:5060;transport=udp;registering_acc=192_168_51_133
ERROR: tm [ut.h:295]: ERROR: uri2dst: failed to resolve "[x::x]" :unresolvable A or AAAA request (-7)
Is there something I haven't considered yet? Why would it try a DNS lookup for this R-URI?
Andreas
On 12/14/2011 06:28 PM, Andreas Granig wrote:
Hello,
On 12/14/11 7:12 PM, Andreas Granig wrote:
is it failing over all or is the request forwarded?
Might be an wrong condition to detect it's ip -- the sources have to be checked.
Cheers, Daniel
On 12/15/2011 11:10 AM, Andreas Granig wrote:
Actually I get two messages back from the outbound load-balancer towards the proxy for the same INVITE, one right after the other:
U 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL).
U 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 478 Unresolvable destination (478/TM).
The scenario is this:
[v4user]-(ipv4)->[lb]-(ipv4)->[proxy]-(ipv4)->[lb]-(ipv6)->[v6user]
The problem appears on the last lb hop, so it never sends anything over IPv6 to the v6user, but passes back the two errors from above to the proxy. I'm trying to dig deeper later today.
Andreas
Hello,
On 12/15/11 11:26 AM, Andreas Granig wrote:
trying to figure out the modules involved -- does the INVITE arrive with double Route headers on second [lb] or is the [lb] selecting an ipv6 destination?
Cheers, Daniel
Hi,
Here is the full sip trace of the hop proxy->lb (SDP snipped), this should help getting an idea what's going on. What the lb does it taking the value from P-R-Uri and tries to send it to that destination (no $du will get set on the lb):
U 2011/12/15 11:45:34.357000 127.0.0.1:5080 -> 127.0.0.1:5060 INVITE sip:b2b-testuser1@[2a00:4600:1:0:d4cd:21ff:fe2a:695d]:5060;transport=udp;registering_acc=192_168_51_133 SIP/2.0. Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKy.LraaHZ;rport. From: "4311003" sip:4311003@192.168.51.133;tag=3FADD5A0-4EE9CFCE000571AD-9B869700. To: sip:testuser1@192.168.51.133. CSeq: 10 INVITE. Call-ID: bvdvcfdkaygsiao@voyager_b2b-1. Contact: sip:127.0.0.1:5080. Route: sip:lb@127.0.0.1;lr;lr. P-Asserted-Identity: sip:4311003@192.168.51.133. P-R-Uri: sip:testuser1@[2a00:4600:1:0:d4cd:21ff:fe2a:695d]:5060;transport=udp;registering_acc=192_168_51_133. P-D-Uri: sip:lb@127.0.0.1;lr. Supported: timer. Session-Expires: 300. Min-SE: 90. Content-Type: application/sdp. Content-Length: 376.
# U 2011/12/15 11:45:34.357975 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL). Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKy.LraaHZ;rport=5080. From: "4311003" sip:4311003@192.168.51.133;tag=3FADD5A0-4EE9CFCE000571AD-9B869700. To: sip:testuser1@192.168.51.133;tag=3b8fef9b15259f395e1783c57c397cb0.7ec7. CSeq: 10 INVITE. Call-ID: bvdvcfdkaygsiao@voyager_b2b-1. Server: Sipwise NGCP LB 2.X. Content-Length: 0.
# U 2011/12/15 11:45:34.358020 127.0.0.1:5060 -> 127.0.0.1:5080 SIP/2.0 478 Unresolvable destination (478/TM). Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKy.LraaHZ;rport=5080. From: "4311003" sip:4311003@192.168.51.133;tag=3FADD5A0-4EE9CFCE000571AD-9B869700. To: sip:testuser1@192.168.51.133;tag=a0d405ce9b8237d1940aaf5f4894f8b6-7ec7. CSeq: 10 INVITE. Call-ID: bvdvcfdkaygsiao@voyager_b2b-1. Server: Sipwise NGCP LB 2.X. Content-Length: 0.
The lines in the log are:
INFO: <script>: Relaying request, du='<null>', fs='udp:[2A00:4600:0:0:2089:2FF:FE6F:B0CC]:5060' - M=INVITE R=sip:testuser1@[2a00:4600:1:0:d4cd:21ff:fe2a:695d]:5060;transport=udp;registering_acc=192_168_51_133 F=sip:4311003@192.168.51.133 T=sip:testuser1@192.168.51.133 IP=127.0.0.1:5080 ID=bvdvcfdkaygsiao@voyager_b2b-1
ERROR: tm [ut.h:295]: ERROR: uri2dst: failed to resolve "[2a00:4600:1:0:d4cd:21ff:fe2a:695d]" :unresolvable A or AAAA request (-7) ERROR: tm [t_fwd.c:1536]: ERROR: t_forward_nonack: failure to add branches ERROR: <script>: Failed to relay request - M=INVITE R=sip:testuser1@[2a00:4600:1:0:d4cd:21ff:fe2a:695d]:5060;transport=udp;registering_acc=192_168_51_133 F=sip:4311003@192.168.51.133 T=sip:testuser1@192.168.51.133 IP=127.0.0.1:5080 ID=bvdvcfdkaygsiao@voyager_b2b-1 ERROR: sl [sl_funcs.c:282]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)
This at least explains where the 500 comes from, because I have this in my config for t_relay:
xlog("L_INFO", "Relaying request, du='$du', fs='$fs' - M=$rm R=$ru F=$fu T=$tu IP=$si:$sp ID=$ci\n"); if(!t_relay_to("0x01")) { xlog("L_ERR", "Failed to relay request - M=$rm R=$ru F=$fu T=$tu IP=$si:$sp ID=$ci\n"); sl_reply_error(); }
It doesn't give a hint though why it tries to resolve my R-URI via DNS.
Andreas
On 12/15/2011 11:40 AM, Daniel-Constantin Mierla wrote:
So, to sum it up:
If you want to use IPv6, use $fs instead of force_send_socket() (or maybe multihoming, haven't tried that yet), and set dns_try_ipv6=yes.
Andreas
On 12/15/2011 06:33 PM, Andreas Granig wrote:
Hello,
I have attached an improved version (uses inet_pton instead of manually parsing the address) of the str2ip6 function that was failing initially. Can you test it against force_send_socket() with an IP address in the form [ipv6_address]:port (the [] are mandatory) ?
Thanks, Marius (in the sip-router/ directory run patch< d.patch to apply the patch)
Hi Marius,
On 12/15/2011 05:47 PM, marius zbihlei wrote:
I'm running 3.1.5 at the moment (and switched to mhomed due to increased complexity in the config when doing both IPv6 and TLS, which gets a pain when forcing a socket manually for multiple interfaces), but I'll try to test your patch with trunk later this week.
Andreas
Hello,
On 12/14/11 6:28 PM, Andreas Granig wrote:
ok.
A fix for force_send_socket would maybe still be good to not confuse people.
I will look over it soon.
Cheers, Daniel
On 12/14/2011 07:28 PM, Andreas Granig wrote:
Hello,
Actually, looking at the code I've observed some weird behavior : for example to fix the force_send_socket IPv6 address, a call to str2ip6() (from resolve.h) is done (via resolvehost()). The function tries to manually parse the IP address, so it makes me wonder why not use a library function like inet_pton(AF_INET6... to get the correct structure.
A possible bug is that with the current code, IPv4 mapped to IPv6 (x:x:x:x:x:x:d.d.d.d) will not be parsed correctly.
Why don't we use inet_pton(AF_INET6 ... . Any reasons?
Cheers Marius
Hello,
On 12/15/11 1:18 PM, marius zbihlei wrote:
have you checked if inet_pton() doesn't break the internal ip_addr structure and the use of it? If all is ok, I guess inet_pton() is portable enough through most unix/linux distro's to make use of it.
Cheers, Daniel
On 12/15/2011 04:41 PM, Daniel-Constantin Mierla wrote:
Hello,
Even if inet_pton() can't use our existing structure, but it can use an in6_addr structure (size is 16 bytes) that can be easily converted into our internal representation (keep in mind endianess and other constraints).
I will have a look when I implement it and will test the changes.
Cheers, Marius
-
Andreas Granig -
Daniel-Constantin Mierla -
marius zbihlei