[SR-Users] mistakenly detected NAT in IPv6 setup

Daniel-Constantin Mierla miconda at gmail.com
Fri Jan 23 12:55:59 CET 2015


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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150123/94cdd56a/attachment.html>


More information about the sr-users mailing list