23 Nov
2023
23 Nov
'23
7:40 a.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