I'd think your goal at this point should be to simplify the config to the smallest possible config that can produce the questionable behavior, and then provide that entire config file (even better, implement this in docker compose, using something like sipp to emulate your UAs, so that the behavior can be easily reproduced by anyone). If the config is too big to reasonably present in an email, then just put the sample code on github.

Several points with the sample config you cite. This thread subject says that the error is with topoh enabled, but the code snippet presented provides neither module parameters for topoh, nor any call to topoh functions. Why are you asserting that topoh is the problem?

Your second line is a call to route(REQINIT), with no information on what happens in that route. While we can guess that it's the same as the default config file, there's no way to know for sure.

It's also not clear why the nat functions and add_path_received() are in this config as it relates to this problem.

Start removing all of this for problem isolation until you can identify where the problem is occuring. I'd also be curious if the error in question is really a result of parsing the ACK or if it's something else (trying to pull $ru off of a reply generates some kind of error like this I think).

Finally, although it's not the RURI, WHAT is with the scheme on the URIs in your To: and From: headers? 'Mailto"?

Regards, Kaufman

________________________________ From: Ale via sr-users sr-users@lists.kamailio.org Sent: Thursday, October 24, 2024 8:12 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Ale ale975@gmail.com Subject: [SR-Users] Re: Failed to parse the R-URI with topoh enabled

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Victor,

I tested 5.7.6 and 5.8.3 and got the same results. At the moment request_route is very simple.

request_route { xlog("L_INFO", ">> $ru from $fu\n");

route(REQINIT);

force_rport();

if(!ds_is_from_list()) { if( !loose_route() ) { if( !ds_select_dst(DEFAULT_ROUTE, "1") ) { drop(); } }

if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } }

add_path_received(); } record_route(); forward(); }

This is the logs of ack

DEBUG: [1 90333697 ACK ...] <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined DEBUG: [1 90333697 ACK ...] <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... DEBUG: [1 90333697 ACK ...] sl [sl_funcs.c:455]: sl_filter_ACK(): too late to be a local ACK! [137B blob data] [134B blob data] ERROR: [1 90333697 ACK ...] pv [pv_core.c:261]: pv_get_ruri(): failed to parse the R-URI DEBUG: [1 90333697 ACK ...] <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=BrQ6ZyDyQHQmN DEBUG: [1 90333697 ACK ...] <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29

Could this be a bug or did I miss something?

On Wed, Oct 23, 2024 at 4:47 PM Victor Seva via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> wrote: Hi,

I would suggest to try a more recent Kamailio version first.

On 23/10/24 14:21, Ale via sr-users wrote:

Hi All,

I think I have a problem with topoh, but I can't identify it.

Kamailio 5.6.6, used as a stateless proxy, receives a 487 from a phone and propagates it correctly. Next comes the ack that should be forwarded back to the phone, but instead it doesn't forward it and produces the following error "pv_get_ruri(): failed to parse the R-URI"

The error is generated by xlog("...$ru from $fu...\n"") as first line of request_route.

If I disable topoh everything works perfectly.Topoh is only configured with mask_key only. Furthermore, not all phones generate this problem, at the moment there are some snoms.

ACK sip:user@phone_ip:2048;line=kkqgarrj SIP/2.0 Via: SIP/2.0/UDP proxy_sip_ip;branch=z9hG4bK2ec.e7126a3134bef9d974f57dd43ebd4ea2.0 Route: sip:kamailio_ip:5060;lr;received=sip:phone_ip:2048 Max-Forwards: 66 From: <sip:111111111@sip.example.commailto:sip%3A111111111@sip.example.com <mailto:sip%3A111111111@sip.example.commailto:sip%253A111111111@sip.example.com>>;tag=pDc1BQ0B57Ujj To: <sip:user@sip.example.commailto:sip%3Auser@sip.example.com <mailto:sip%3Auser@sip.example.commailto:sip%253Auser@sip.example.com>>;tag=vslvowy4y2 Call-ID: 40a6c905-c0c8-4c20-b3f7-397b3fce58b6 CSeq: 90285584 ACK Content Length: 0

There is no difference between the ACK of the snom and other phones that work. The only difference I noticed is that the snom 487 contains Contact field in the header.

Any suggestions? Thank you

-- ----------------------------------------------------------------- | ,''`. Victor Seva | | : :' : linuxmaniac@torreviejawireless.orgmailto:linuxmaniac@torreviejawireless.org | | `. `' PGP: 8F19 CADC D42A 42D4 5563 730C 51A0 9B18 CF5A 5068 | | `- Debian Developer | ----------------------------------------------------------------- __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

If I take your example and set the ACK R-URI to match the contact of the 487 the problem looks to clear. SHOULD this be required, I'm not sure. I've never used topoh, but I'd say to check this in your real-world examples comparing working phones to non-working phones.

Regards, Kaufman

________________________________ From: Ale via sr-users sr-users@lists.kamailio.org Sent: Monday, October 28, 2024 12:05 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Ale ale975@gmail.com Subject: [SR-Users] Re: Failed to parse the R-URI with topoh enabled

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Ben,

I understand your point of view.

As suggested I created a repository, so as to recreate the problem.

https://github.com/beres/kamailio_tmp_topoh

To/From all seems normal to me, which is why I don't understand. Maybe it has nothing to do with topoh, but if active in certain cases it doesn't work. This is a copy of an ACK taken from production

``` ACK sip:rs4xe4w4@client_ip:2048;line=kkqgarrj SIP/2.0 Via: SIP/2.0/UDP proxy_ip;branch=z9hG4bKc4aa.897ab3d4c4434cc636cb12e0c390a81a.0 Route: sip:kamailio_ip:5060;lr;received=sip:client_ip:2048 Max-Forwards: 66 From: sip:phone_number@domain.tld;tag=y3QX10D10tyQH To: sip:rs4xe4w4@domain.tld;tag=31fhufhtrn Call-ID: 04b3fa08-b9b4-43fe-b04a-cbe03bd5dc2d CSeq: 90508938 ACK Content-Length: 0 ```

Thank you

On Thu, Oct 24, 2024 at 3:45 PM Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> wrote: I'd think your goal at this point should be to simplify the config to the smallest possible config that can produce the questionable behavior, and then provide that entire config file (even better, implement this in docker compose, using something like sipp to emulate your UAs, so that the behavior can be easily reproduced by anyone). If the config is too big to reasonably present in an email, then just put the sample code on github.

Several points with the sample config you cite. This thread subject says that the error is with topoh enabled, but the code snippet presented provides neither module parameters for topoh, nor any call to topoh functions. Why are you asserting that topoh is the problem?

Your second line is a call to route(REQINIT), with no information on what happens in that route. While we can guess that it's the same as the default config file, there's no way to know for sure.

It's also not clear why the nat functions and add_path_received() are in this config as it relates to this problem.

Start removing all of this for problem isolation until you can identify where the problem is occuring. I'd also be curious if the error in question is really a result of parsing the ACK or if it's something else (trying to pull $ru off of a reply generates some kind of error like this I think).

Finally, although it's not the RURI, WHAT is with the scheme on the URIs in your To: and From: headers? 'Mailto"?

Regards, Kaufman

________________________________ From: Ale via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Thursday, October 24, 2024 8:12 AM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Ale <ale975@gmail.commailto:ale975@gmail.com> Subject: [SR-Users] Re: Failed to parse the R-URI with topoh enabled

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Victor,

I tested 5.7.6 and 5.8.3 and got the same results. At the moment request_route is very simple.

request_route { xlog("L_INFO", ">> $ru from $fu\n");

route(REQINIT);

force_rport();

if(!ds_is_from_list()) { if( !loose_route() ) { if( !ds_select_dst(DEFAULT_ROUTE, "1") ) { drop(); } }

if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); } }

add_path_received(); } record_route(); forward(); }

This is the logs of ack

DEBUG: [1 90333697 ACK ...] <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined DEBUG: [1 90333697 ACK ...] <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... DEBUG: [1 90333697 ACK ...] sl [sl_funcs.c:455]: sl_filter_ACK(): too late to be a local ACK! [137B blob data] [134B blob data] ERROR: [1 90333697 ACK ...] pv [pv_core.c:261]: pv_get_ruri(): failed to parse the R-URI DEBUG: [1 90333697 ACK ...] <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=BrQ6ZyDyQHQmN DEBUG: [1 90333697 ACK ...] <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29

Could this be a bug or did I miss something?

On Wed, Oct 23, 2024 at 4:47 PM Victor Seva via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> wrote: Hi,

I would suggest to try a more recent Kamailio version first.

On 23/10/24 14:21, Ale via sr-users wrote:

Hi All,

I think I have a problem with topoh, but I can't identify it.

Kamailio 5.6.6, used as a stateless proxy, receives a 487 from a phone and propagates it correctly. Next comes the ack that should be forwarded back to the phone, but instead it doesn't forward it and produces the following error "pv_get_ruri(): failed to parse the R-URI"

The error is generated by xlog("...$ru from $fu...\n"") as first line of request_route.

If I disable topoh everything works perfectly.Topoh is only configured with mask_key only. Furthermore, not all phones generate this problem, at the moment there are some snoms.

ACK sip:user@phone_ip:2048;line=kkqgarrj SIP/2.0 Via: SIP/2.0/UDP proxy_sip_ip;branch=z9hG4bK2ec.e7126a3134bef9d974f57dd43ebd4ea2.0 Route: sip:kamailio_ip:5060;lr;received=sip:phone_ip:2048 Max-Forwards: 66 From: <sip:111111111@sip.example.commailto:sip%3A111111111@sip.example.com <mailto:sip%3A111111111@sip.example.commailto:sip%253A111111111@sip.example.com>>;tag=pDc1BQ0B57Ujj To: <sip:user@sip.example.commailto:sip%3Auser@sip.example.com <mailto:sip%3Auser@sip.example.commailto:sip%253Auser@sip.example.com>>;tag=vslvowy4y2 Call-ID: 40a6c905-c0c8-4c20-b3f7-397b3fce58b6 CSeq: 90285584 ACK Content Length: 0

There is no difference between the ACK of the snom and other phones that work. The only difference I noticed is that the snom 487 contains Contact field in the header.

Any suggestions? Thank you

-- ----------------------------------------------------------------- | ,''`. Victor Seva | | : :' : linuxmaniac@torreviejawireless.orgmailto:linuxmaniac@torreviejawireless.org | | `. `' PGP: 8F19 CADC D42A 42D4 5563 730C 51A0 9B18 CF5A 5068 | | `- Debian Developer | ----------------------------------------------------------------- __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: