Hi I see that when kamailio adds rport to the Via header field of a request that has two Via values on the same line (comma-separated, of course), it adds the rport (and received) to the wrong value.
I have this test kamailio.cfg for demonstration.
children=1 loadmodule "sl" loadmodule "textops" loadmodule "nathelper" request_route { force_rport(); sl_send_reply(200, "OK"); }
I send this OPTIONS (truncated) and get this response (truncated). The rport should be on the first Via value, not the second.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 From: sip:client;tag=LeonhardEuler To: sip:server
SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport=53805;received=127.0.0.1 From: sip:client;tag=LeonhardEuler To: sip:server;tag=9dd61ff61e802d8e2bef5f14621ef3c2.49678e65 Server: kamailio (6.0.0-pre0 (x86_64/linux))
I've tested this with the latest commit (c994fb8) from kamailio. I can't think how this can be anything other than a bug. Should I log a bug report for this?
James
Hello,
can you try with latest git master branch? I have just pushed a commit for it.
As per code, it happened for generated replies when no rport was in incoming request first via and there were many via bodies in the same header.
Cheers, Daniel
On 21.01.25 17:36, James Browne via sr-users wrote:
Hi I see that when kamailio adds rport to the Via header field of a request that has two Via values on the same line (comma-separated, of course), it adds the rport (and received) to the wrong value.
I have this test kamailio.cfg for demonstration.
children=1 loadmodule "sl" loadmodule "textops" loadmodule "nathelper" request_route { force_rport(); sl_send_reply(200, "OK"); }
I send this OPTIONS (truncated) and get this response (truncated). The rport should be on the first Via value, not the second.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 From: sip:client;tag=LeonhardEuler To: sip:server
SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport=53805;received=127.0.0.1 From: sip:client;tag=LeonhardEuler To: sip:server;tag=9dd61ff61e802d8e2bef5f14621ef3c2.49678e65 Server: kamailio (6.0.0-pre0 (x86_64/linux))
I've tested this with the latest commit (c994fb8) from kamailio. I can't think how this can be anything other than a bug. Should I log a bug report for this?
James __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Thanks, Daniel. I've not fully tested yet (multiple combinations of transport protocols, rport in the request, etc), but testing with *exactly* the same SIP message now has the rport in the correct place.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=34321,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;received=127.0.0.1
Although the rport is now in the correct Via value, the received parameter is still attached to the second Via value. I expect I'm still going to have a problem with this. Is this also possible to get fixed? As always, I appreciate the quick responses for this sort of thing.
James
On Tue, 21 Jan 2025 at 18:48, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you try with latest git master branch? I have just pushed a commit for it.
As per code, it happened for generated replies when no rport was in incoming request first via and there were many via bodies in the same header.
Cheers, Daniel
On 21.01.25 17:36, James Browne via sr-users wrote:
Hi I see that when kamailio adds rport to the Via header field of a request that has two Via values on the same line (comma-separated, of course), it adds the rport (and received) to the wrong value.
I have this test kamailio.cfg for demonstration.
children=1 loadmodule "sl" loadmodule "textops" loadmodule "nathelper" request_route { force_rport(); sl_send_reply(200, "OK"); }
I send this OPTIONS (truncated) and get this response (truncated). The rport should be on the first Via value, not the second.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 From: sip:client;tag=LeonhardEuler To: sip:server
SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport=53805;received=127.0.0.1 From: sip:client;tag=LeonhardEuler To: sip:server;tag=9dd61ff61e802d8e2bef5f14621ef3c2.49678e65 Server: kamailio (6.0.0-pre0 (x86_64/linux))
I've tested this with the latest commit (c994fb8) from kamailio. I can't think how this can be anything other than a bug. Should I log a bug report for this?
James __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
Can you fetch the latest git and try again? First time I haven't noticed where received was added.
Cheers, Daniel
On 21.01.25 21:03, James Browne wrote:
Thanks, Daniel. I've not fully tested yet (multiple combinations of transport protocols, rport in the request, etc), but testing with *exactly* the same SIP message now has the rport in the correct place.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=34321,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;received=127.0.0.1
Although the rport is now in the correct Via value, the received parameter is still attached to the second Via value. I expect I'm still going to have a problem with this. Is this also possible to get fixed? As always, I appreciate the quick responses for this sort of thing.
James
On Tue, 21 Jan 2025 at 18:48, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you try with latest git master branch? I have just pushed a commit for it.
As per code, it happened for generated replies when no rport was in incoming request first via and there were many via bodies in the same header.
Cheers, Daniel
On 21.01.25 17:36, James Browne via sr-users wrote:
Hi I see that when kamailio adds rport to the Via header field of a request that has two Via values on the same line (comma-separated, of course), it adds the rport (and received) to the wrong value.
I have this test kamailio.cfg for demonstration.
children=1 loadmodule "sl" loadmodule "textops" loadmodule "nathelper" request_route { force_rport(); sl_send_reply(200, "OK"); }
I send this OPTIONS (truncated) and get this response (truncated). The rport should be on the first Via value, not the second.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 From: sip:client;tag=LeonhardEuler To: sip:server
SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport=53805;received=127.0.0.1 From: sip:client;tag=LeonhardEuler To: sip:server;tag=9dd61ff61e802d8e2bef5f14621ef3c2.49678e65 Server: kamailio (6.0.0-pre0 (x86_64/linux))
I've tested this with the latest commit (c994fb8) from kamailio. I can't think how this can be anything other than a bug. Should I log a bug report for this?
James __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
Thanks, Daniel. I tested with commit d613f30 and it looks all good now. I made tests over UDP and TCP with different combinations of Via rport in the request. Sometime later, I'll do more-detailed checks that end-to-end relayed requests and responses are still ok; they were already working before I sent the first email (only the SIP-100 response had the wrong value in it).
James
Here are some UDP tests. In each paragraph, I include the first three lines of the request and response for separate tests. I used the same kamailio.cfg file.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=5060;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=5060;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;rport;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;rport=5060;received=192.168.0.1;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=5060;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;rport;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;rport=5060;received=192.168.0.1;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060
Here are some tests I made over TCP.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089;rport,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=59684;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/TCP 3.9.4.2:5060;rport;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/TCP 3.9.4.2:5060;rport=59684;received=192.168.0.1;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=59684;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 Via: SIP/2.0/TCP 1.4.5.6:5060
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060 SIP/2.0 200 OK Via: SIP/2.0/TCP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=59684;received=192.168.0.1,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport Via: SIP/2.0/TCP 1.4.5.6:5060
On Tue, 21 Jan 2025 at 20:45, Daniel-Constantin Mierla miconda@gmail.com wrote:
Can you fetch the latest git and try again? First time I haven't noticed where received was added.
Cheers, Daniel
On 21.01.25 21:03, James Browne wrote:
Thanks, Daniel. I've not fully tested yet (multiple combinations of transport protocols, rport in the request, etc), but testing with *exactly* the same SIP message now has the rport in the correct place.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089;rport=34321,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;received=127.0.0.1
Although the rport is now in the correct Via value, the received parameter is still attached to the second Via value. I expect I'm still going to have a problem with this. Is this also possible to get fixed? As always, I appreciate the quick responses for this sort of thing.
James
On Tue, 21 Jan 2025 at 18:48, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you try with latest git master branch? I have just pushed a commit for it.
As per code, it happened for generated replies when no rport was in incoming request first via and there were many via bodies in the same header.
Cheers, Daniel
On 21.01.25 17:36, James Browne via sr-users wrote:
Hi I see that when kamailio adds rport to the Via header field of a request that has two Via values on the same line (comma-separated, of course), it adds the rport (and received) to the wrong value.
I have this test kamailio.cfg for demonstration.
children=1 loadmodule "sl" loadmodule "textops" loadmodule "nathelper" request_route { force_rport(); sl_send_reply(200, "OK"); }
I send this OPTIONS (truncated) and get this response (truncated). The rport should be on the first Via value, not the second.
OPTIONS sip:server SIP/2.0 Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059 From: sip:client;tag=LeonhardEuler To: sip:server
SIP/2.0 200 OK Via: SIP/2.0/UDP 3.9.4.2:5060;branch=z9hG4bK503983089,SIP/2.0/UDP 1.3.4.1:5060;branch=z9hG4bK53805983059;rport=53805;received=127.0.0.1 From: sip:client;tag=LeonhardEuler To: sip:server;tag=9dd61ff61e802d8e2bef5f14621ef3c2.49678e65 Server: kamailio (6.0.0-pre0 (x86_64/linux))
I've tested this with the latest commit (c994fb8) from kamailio. I can't think how this can be anything other than a bug. Should I log a bug report for this?
James __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
-
Daniel-Constantin Mierla -
James Browne