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:
Hello,
On 12/15/11 11:26 AM, Andreas Granig wrote:
On 12/15/2011 11:10 AM, Andreas Granig wrote:
On 12/15/2011 10:19 AM, Daniel-Constantin Mierla wrote:
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?
is it failing over all or is the request forwarded?
It's failing overall with "478 Unresolvable destination (478/TM)".
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.
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