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