Hi,
I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong.
Example: inbound Contact: sip:bob@192.168.8.132
outbound Contact: sip:bob@1234:1234:0:1234:0:0:0:2
The correct way of transforming the Contact URI would be: Contact: sip:bob@[1234:1234:0:1234:0:0:0:2]
This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI:
Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI
Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong?
Best Regards, Sebastian
Sounds like a bug.
Anyway, as fix_nated_contact is not standard conform, it is better to use handle_ruri_alias() and add_contact_alias() (see the Kamailio default config file). Maybe they handle also IPv6 correct.
regards Klaus
On 22.01.2015 16:26, Sebastian Damm wrote:
Hi,
I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong.
Example: inbound Contact: <sip:bob@192.168.8.132 mailto:sip%3Abob@192.168.8.132>
outbound Contact: sip:bob@1234:1234:0:1234:0:0:0:2
The correct way of transforming the Contact URI would be: Contact: sip:bob@[1234:1234:0:1234:0:0:0:2]
This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI:
Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI
Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong?
Best Regards, Sebastian
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Couple of remarks:
1) I guess the initial author know there is no nat in ipv6, so he didn't bother with. I just pushed a patch for it in master (814c08f3), if tested and reported to work ok, it can be backported
2) the contact uri example in the first email is perhaps not properly reflecting the contact uri that was generated, because it should have been with the ip address and the port. It seems to be only the ip address. If there was an omission, that's ok, because I expect the uri parsing error is due to hostpart having the port following the ipv6 address -- that requires the ipv6 between []. If the port was missing, that can be another issue, but the code shows the port is always added and it wouldn't worked at all so far without it.
3) use set_contact_alias() if use modules that need the new contact (like dialog, presence, ...) for later usage. The *contact_alias() function don't change the host/port part, they just add a new parameter, so it would have been safe with or without []. Anyhow, the code adds [] if the address is ipv6
Cheers, Daniel
On 22/01/15 16:43, Klaus Darilion wrote:
Sounds like a bug.
Anyway, as fix_nated_contact is not standard conform, it is better to use handle_ruri_alias() and add_contact_alias() (see the Kamailio default config file). Maybe they handle also IPv6 correct.
regards Klaus
On 22.01.2015 16:26, Sebastian Damm wrote:
Hi,
I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong.
Example: inbound Contact: <sip:bob@192.168.8.132 mailto:sip%3Abob@192.168.8.132>
outbound Contact: sip:bob@1234:1234:0:1234:0:0:0:2
The correct way of transforming the Contact URI would be: Contact: sip:bob@[1234:1234:0:1234:0:0:0:2]
This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI:
Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI
Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong?
Best Regards, Sebastian
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel, Hi Klaus,
On Thu, Jan 22, 2015 at 10:48 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
- I guess the initial author know there is no nat in ipv6, so he didn't
bother with. I just pushed a patch for it in master (814c08f3), if tested and reported to work ok, it can be backported
Thanks for the patch, I just patched our 4.1.3 with it, and now the Contact IP is surrounded by square brackets. So I guess it can be backported.
- the contact uri example in the first email is perhaps not properly
reflecting the contact uri that was generated, because it should have been with the ip address and the port. It seems to be only the ip address. If there was an omission, that's ok, because I expect the uri parsing error is due to hostpart having the port following the ipv6 address -- that requires the ipv6 between []. If the port was missing, that can be another issue, but the code shows the port is always added and it wouldn't worked at all so far without it.
Sorry, that was my mistake. The request came in from an odd port, so I removed it while adjusting the line for the mailing list. Of course, after fix_nated_contact the port is appended.
3) use set_contact_alias() if use modules that need the new contact
(like dialog, presence, ...) for later usage. The *contact_alias() function don't change the host/port part, they just add a new parameter, so it would have been safe with or without []. Anyhow, the code adds [] if the address is ipv6
I have had a look into these functions, and they seem a lot more appropriate (and do work with IPv6). Guess they haven't been there, when we originally built that part of our configuration back in 2007. I think we will use those functions now.
Thanks for the quick help.
Best Regards, Sebastian
fix_contact from NAT Traversal Module has the same issue.
2015-01-23 10:24 GMT+01:00 Sebastian Damm damm@sipgate.de:
Hi Daniel, Hi Klaus,
On Thu, Jan 22, 2015 at 10:48 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
- I guess the initial author know there is no nat in ipv6, so he didn't
bother with. I just pushed a patch for it in master (814c08f3), if tested and reported to work ok, it can be backported
Thanks for the patch, I just patched our 4.1.3 with it, and now the Contact IP is surrounded by square brackets. So I guess it can be backported.
- the contact uri example in the first email is perhaps not properly
reflecting the contact uri that was generated, because it should have been with the ip address and the port. It seems to be only the ip address. If there was an omission, that's ok, because I expect the uri parsing error is due to hostpart having the port following the ipv6 address -- that requires the ipv6 between []. If the port was missing, that can be another issue, but the code shows the port is always added and it wouldn't worked at all so far without it.
Sorry, that was my mistake. The request came in from an odd port, so I removed it while adjusting the line for the mailing list. Of course, after fix_nated_contact the port is appended.
- use set_contact_alias() if use modules that need the new contact
(like dialog, presence, ...) for later usage. The *contact_alias() function don't change the host/port part, they just add a new parameter, so it would have been safe with or without []. Anyhow, the code adds [] if the address is ipv6
I have had a look into these functions, and they seem a lot more appropriate (and do work with IPv6). Guess they haven't been there, when we originally built that part of our configuration back in 2007. I think we will use those functions now.
Thanks for the quick help.
Best Regards, Sebastian
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users