23 Nov
2023
23 Nov
'23
1:40 p.m.
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(a)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
24 Nov
24 Nov
9:11 a.m.
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
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: Christian Schnell via sr-users <sr-users(a)lists.kamailio.org>
Sent: Donnerstag, 23. November 2023 13:41
To: sr-users(a)lists.kamailio.org
Cc: Christian Schnell <cs(a)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.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe: 
11:01 a.m.
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(a)lists.kamailio.org>
Sent: Donnerstag, 23. November 2023 13:41
To: sr-users(a)lists.kamailio.org
Cc: Christian Schnell <cs(a)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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
A UAC MUST insert a Max-Forwards header field
into each request it
originates with a value that SHOULD be 70.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
5:31 p.m.
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(a)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(a)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(a)lists.kamailio.org>
Sent: Donnerstag, 23. November 2023 13:41
To: sr-users(a)lists.kamailio.org
Cc: Christian Schnell <cs(a)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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
A UAC MUST insert a Max-Forwards header field
into each request it
originates with a value that SHOULD be 70.
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(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
178
days inactive
179
days old
3 comments
3 participants
participants (3)
-
Christian Schnell -
Henning Westerholt -
Kristian Frederik Høgh