Hello,
in RFC 3261 (sec. 8.1.1.6) it states about the Max-Forwards header field:
A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70.
Source: https://datatracker.ietf.org/doc/html/rfc3261#section-8.1.1.6
When Kamailio sends its OPTIONS keep-alive requests (from the nathelper module I believe), Max-Forwards is missing:
OPTIONS sip:alice@example.com:61266 SIP/2.0 Via: SIP/2.0/UDP aa.bb.cc.dd:5060;branch=z9hG4bK5124450 From: sip:pinger@sip.example.com;tag=uloc-6550aa14-7456-2461-6390f173-5fdb4667 To: sip:alice@example.com:61266 Call-ID: aba25282-2ca72be1-9d1fd53@aa.bb.cc.dd CSeq: 1 OPTIONS Content-Length: 0
The user agent library I'm using (libre from baresip) rejects these requests with a "400 Bad Request" response, I looked at the sources and it denies these requests because of the missing Max-Forwards header.
Of course this suffices for the keep-alive logic because all that's needed is any traffic in both directions to keep both (potential) NATs open. However you might agree that it does look a bit confusing at first, and the RFC is clear about that.
So it's not a bug, but is this behavior intended?
Thanks, also thanks for all the great work that has been put into Kamailio.
Christian
Hi Christian,
you are right, it is missing in the generated OPTIONS from nathelper. It needs to be added in the respective code part probably.
Cheers,
Henning Westerholt
Hi Christian,
You can try the following patch. I don't use OPTIONS pings, so I haven't tested it.
Best regards, Kristian Høgh
On Friday, 24 November 2023 09.11.28 CET Henning Westerholt via sr-users wrote:
Hi Christian,
you are right, it is missing in the generated OPTIONS from nathelper. It needs to be added in the respective code part probably.
Cheers,
Henning Westerholt
-----Original Message----- From: Christian Schnell via sr-users sr-users@lists.kamailio.org Sent: Donnerstag, 23. November 2023 13:41 To: sr-users@lists.kamailio.org Cc: Christian Schnell cs@rekoba.de Subject: [SR-Users] Max-Forwards header missing in OPTIONS keep-alive messages
Hello,
in RFC 3261 (sec. 8.1.1.6) it states about the Max-Forwards header field:
A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70.
Source: https://datatracker.ietf.org/doc/html/rfc3261#section-8.1.1.6
When Kamailio sends its OPTIONS keep-alive requests (from the nathelper module I believe), Max-Forwards is missing:
OPTIONS sip:alice@example.com:61266 SIP/2.0 Via: SIP/2.0/UDP aa.bb.cc.dd:5060;branch=z9hG4bK5124450 From: sip:pinger@sip.example.com;tag=uloc-6550aa14-7456-2461-6390f173-
5fdb46
67 To: sip:alice@example.com:61266 Call-ID: aba25282-2ca72be1-9d1fd53@aa.bb.cc.dd CSeq: 1 OPTIONS Content-Length: 0
The user agent library I'm using (libre from baresip) rejects these requests with a "400 Bad Request" response, I looked at the sources and it denies these requests because of the missing Max-Forwards header.
Of course this suffices for the keep-alive logic because all that's needed is any traffic in both directions to keep both (potential) NATs open. However you might agree that it does look a bit confusing at first, and the RFC is clear about that.
So it's not a bug, but is this behavior intended?
Thanks, also thanks for all the great work that has been put into Kamailio.
Christian
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Hi Kristian and Henning,
thanks to both of you for the quick responses.
I can confirm that patch "max-forwards.patch" fixes this minor issue. Tested in a fresh Debian 12 "bookworm" VM and the github master as of half an hour ago. Here's a request-response pair I captured with a patched kamailio:
OPTIONS sip:alice@10.0.0.19:59785 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.43:5060;branch=z9hG4bK4167962 From: sip:pinger@kamailio.org;tag=uloc-6560c94c-5603-1-6390f173-a08c4ca6 To: sip:alice@10.0.0.19:59785 Call-ID: e5986357-2b4af814-c1f7ab@10.0.0.43 CSeq: 1 OPTIONS Max-Forwards: 70 Content-Length: 0
SIP/2.0 501 Not Implemented Via: SIP/2.0/UDP 10.0.0.43:5060;branch=z9hG4bK4167962 From: sip:pinger@kamailio.org;tag=uloc-6560c94c-5603-1-6390f173-a08c4ca6 To: sip:alice@10.0.0.19:59785;tag=5a9cb42bcb01e90d Call-ID: e5986357-2b4af814-c1f7ab@10.0.0.43 CSeq: 1 OPTIONS Server: re Content-Length: 0
Two remarks:
1) I followed the "linux" build instructions from INSTALL, and two apt package names seem out of date (which you probably already know about):
- "libmysqlclient-dev" is now "default-libmysqlclient-dev" - "libradiusclient-ng-dev" is now "libradcli-dev"
2) This patch has a little side-effect in the SIP stack that I'm using which I hadn't considered before. This stack (libre from baresip) has a callback for unhandled incoming SIP requests and it fires now each time this OPTIONS request is received, which it hadn't before because the request was denied for syntactical reasons before ever reaching that callback. I will have to add code to ignore this "new" request, others might have to do the same which is why I make this remark.
Again, thanks for the great support! Christian
Am 24.11.2023 um 11:01 schrieb Kristian Frederik Høgh:
Hi Christian,
You can try the following patch. I don't use OPTIONS pings, so I haven't tested it.
Best regards, Kristian Høgh
On Friday, 24 November 2023 09.11.28 CET Henning Westerholt via sr-users wrote:
Hi Christian,
you are right, it is missing in the generated OPTIONS from nathelper. It needs to be added in the respective code part probably.
Cheers,
Henning Westerholt
-----Original Message----- From: Christian Schnell via sr-users sr-users@lists.kamailio.org Sent: Donnerstag, 23. November 2023 13:41 To: sr-users@lists.kamailio.org Cc: Christian Schnell cs@rekoba.de Subject: [SR-Users] Max-Forwards header missing in OPTIONS keep-alive messages
Hello,
in RFC 3261 (sec. 8.1.1.6) it states about the Max-Forwards header field:
A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70.
Source: https://datatracker.ietf.org/doc/html/rfc3261#section-8.1.1.6
When Kamailio sends its OPTIONS keep-alive requests (from the nathelper module I believe), Max-Forwards is missing:
OPTIONS sip:alice@example.com:61266 SIP/2.0 Via: SIP/2.0/UDP aa.bb.cc.dd:5060;branch=z9hG4bK5124450 From: sip:pinger@sip.example.com;tag=uloc-6550aa14-7456-2461-6390f173-
5fdb46
67 To: sip:alice@example.com:61266 Call-ID: aba25282-2ca72be1-9d1fd53@aa.bb.cc.dd CSeq: 1 OPTIONS Content-Length: 0
The user agent library I'm using (libre from baresip) rejects these requests with a "400 Bad Request" response, I looked at the sources and it denies these requests because of the missing Max-Forwards header.
Of course this suffices for the keep-alive logic because all that's needed is any traffic in both directions to keep both (potential) NATs open. However you might agree that it does look a bit confusing at first, and the RFC is clear about that.
So it's not a bug, but is this behavior intended?
Thanks, also thanks for all the great work that has been put into Kamailio.
Christian
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
-
Christian Schnell -
Henning Westerholt -
Kristian Frederik Høgh