23 Jan
2015
23 Jan
'15
10:12 p.m.
Hi,
it looks to me that Kamailio detects NAT without NAT being there, when used
in IPv6 scenarios.
I have a register, which comes in like this:
U 2015/01/23 11:42:31.013284 2a01:1234:123:1234::2:16732 ->
2001:9876:98:9876::aa01:5060
REGISTER sip:domain SIP/2.0
Via: SIP/2.0/UDP [2a01:1234:123:1234::2]:16732;branch=z9hG4bK45528eba
After it has run through Kamailio, the packet is sent out like this:
U 2015/01/23 11:42:31.015126 1.2.3.4:5060 -> 9.8.7.6:5060
REGISTER sip:domain SIP/2.0
Via: SIP/2.0/UDP
1.2.3.4;branch=z9hG4bK8d21.7fa5fb060c2acc9583f05a93b93f9873.0
Via: SIP/2.0/UDP
[2a01:1234:123:1234::2]:16732;received=2A01:1234:123:1234:0:0:0:2;branch=z9hG4bK45528eba
As far as I know, the received part should only get appended, if the source
IP of the packet differs from the IP advertised in the topmost Via header.
But to me it looks like it always gets appended. In just IPv4 scenarios,
the received parameter only gets appended if a difference is detected.
And if it gets appended, shouldn't the received parameter IP be in square
brackets, too?
Later on, we have something like this in our code:
if(method=="REGISTER") {
if (nat_uac_test("23")) {
append_hf("X-nathint: nat\r\n");
force_rport();
if (!add_path_received()) {
sl_send_reply("503", "Internal
Path
Error");
};
} else {
if (!add_path()) {
sl_send_reply("503", "Internal
Path
Error");
};
};
}
In our code, Kamailio always jumps into the add_path_received() part, so I
guess, NAT detection triggers. But why?
And then the Path header appended looks like this:
Path: <sip:1.2.3.4;lr;received=sip:2A01:1234:123:1234:0:0:0:2:16732>
The path module probably doesn't know anything about IPv6, too, so the IP
in the received parameter is not enclosed in square brackets. When using
the Path header later to send packets to the client, Kamailio complains
about a parse error for the destination URI again.
I tried looking into the path module, but I guess my C skills aren't
sufficient to submit a patch.
Best regards,
Sebastian
23 Jan
23 Jan
10:55 p.m.
Hello,
can you split your checks from nat_uac_test("23") to individual checks
(like nat_uac_test("1"), nat_uac_test("2"), ...) and see which one
fails?
Via parameter 'received' contains (always, as per spec) only the IP
address, rport is for received port. Perhaps adding [] would not harm,
but otherwise should be ok now.
For path module, I pushed a patch. Maybe you can test and report the
results for it.
Cheers,
Daniel
On 23/01/15 12:12, Sebastian Damm wrote:
Hi,
it looks to me that Kamailio detects NAT without NAT being there, when
used in IPv6 scenarios.
I have a register, which comes in like this:
U 2015/01/23 11:42:31.013284 2a01:1234:123:1234::2:16732 ->
2001:9876:98:9876::aa01:5060
REGISTER sip:domain SIP/2.0
Via: SIP/2.0/UDP [2a01:1234:123:1234::2]:16732;branch=z9hG4bK45528eba
After it has run through Kamailio, the packet is sent out like this:
U 2015/01/23 11:42:31.015126 1.2.3.4:5060 <http://1.2.3.4:5060> ->
9.8.7.6:5060 <http://9.8.7.6:5060>
REGISTER sip:domain SIP/2.0
Via: SIP/2.0/UDP
1.2.3.4;branch=z9hG4bK8d21.7fa5fb060c2acc9583f05a93b93f9873.0
Via: SIP/2.0/UDP
[2a01:1234:123:1234::2]:16732;received=2A01:1234:123:1234:0:0:0:2;branch=z9hG4bK45528eba
As far as I know, the received part should only get appended, if the
source IP of the packet differs from the IP advertised in the topmost
Via header. But to me it looks like it always gets appended. In just
IPv4 scenarios, the received parameter only gets appended if a
difference is detected.
And if it gets appended, shouldn't the received parameter IP be in
square brackets, too?
Later on, we have something like this in our code:
if(method=="REGISTER") {
if (nat_uac_test("23")) {
append_hf("X-nathint: nat\r\n");
force_rport();
if (!add_path_received()) {
sl_send_reply("503", "Internal
Path Error");
};
} else {
if (!add_path()) {
sl_send_reply("503", "Internal
Path Error");
};
};
}
In our code, Kamailio always jumps into the add_path_received() part,
so I guess, NAT detection triggers. But why?
And then the Path header appended looks like this:
Path: <sip:1.2.3.4;lr;received=sip:2A01:1234:123:1234:0:0:0:2:16732>
The path module probably doesn't know anything about IPv6, too, so the
IP in the received parameter is not enclosed in square brackets. When
using the Path header later to send packets to the client, Kamailio
complains about a parse error for the destination URI again.
I tried looking into the path module, but I guess my C skills aren't
sufficient to submit a patch.
Best regards,
Sebastian
_______________________________________________
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
24 Jan
24 Jan
12:55 a.m.
Hi Daniel,
On Fri, Jan 23, 2015 at 12:55 PM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
can you split your checks from
nat_uac_test("23") to individual checks
(like nat_uac_test("1"), nat_uac_test("2"), ...) and see which one
fails?
Yes. It's the Via check (2). And I don't see why. This is ngrep (with
changed IPs):
U 2015/01/23 14:24:22.258609 2a01:123:123:1234::2:16732 ->
2001:987:98:9876::aa01:5060
REGISTER sip:domain SIP/2.0
Via: SIP/2.0/UDP [2a01:123:123:1234::2]:16732;branch=z9hG4bK4b4ba821
The Source IP is identical to the Via IP. Except that when sending it out,
the received IP is not shortened:
Via: SIP/2.0/UDP
[2a01:123:123:1234::2]:16732;rport=16732;received=2A01:123:123:1234:0:0:0:2;branch=z9hG4bK0cda996b
Via parameter 'received' contains (always, as
per spec) only the IP
address, rport is for received port. Perhaps adding [] would not harm, but
otherwise should be ok now.
I agree.
For path module, I pushed a patch. Maybe you can test
and report the
results for it.
Thanks again. It now works as expected, even with received parameter in the
Path.
Best Regards,
Sebastian
3650
days inactive
3650
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Sebastian Damm