Hello Daniel, thanks. A NAPTR query should be done when no port is given, correct. I think this is also the logic that is used e.g. from tm t_relay(). When a port is given, we could default to the logic mentioned below. It is only a SHOULD in the standard, though.
But I agree that changing the parser could have side effects. We maybe could add a comment to the relevant parser code section. Cheers, Henning From: Daniel-Constantin Mierla via sr-dev <[email protected]> Sent: Montag, 22. Dezember 2025 12:18 To: Kamailio (SER) - Development Mailing List <[email protected]> Cc: Xenofon Karamanos <[email protected]>; Daniel-Constantin Mierla <[email protected]> Subject: [sr-dev] Re: Issue with ds_is_from_list() and default transport handling in dispatcher Hello, it should be fixed in the dispatcher module, a change in the core/parser can have side effects -- iirc, when a no transport is explicitly set and the URI has a FQDN, then naptr/srv queries have to be done. If an explicit transport is given, then the protocol does not have to be discovered via dns. Cheers, Daniel On 22.12.25 12:04, Xenofon Karamanos via sr-dev wrote: Hello all, While working with the dispatcher module, an issue was noticed with ds_is_from_list() when matching entries that do not explicitly specify a transport in the dispatcher list file. The dispatcher list contains SIP URIs where some entries do not have a ;transport= parameter, e.g. sip:host.example.com:5060. According to RFC 3261 (section 19.1.1 and related text) and RFC 3263, for sip: URIs the default transport should be UDP if the transport parameter is absent. (it slight differs if host is numeric vs non-numeric case, see 3263 4.1) However, ds_is_from_list() in mode 1 (ignore port) does not match such entries against incoming requests that use UDP, even though the transport parameter is omitted in the dispatcher file. From debugging, it appears the problem originates in parse_uri.c: when the transport URI parameter is missing, the proto field is left as PROTO_NONE. The dispatcher module then reads the entries from the file with this PROTO_NONE value. When an incoming URI with transport=udp is compared against a stored URI that has PROTO_NONE, the protocols differ and the match fails. Given RFC 3261/3263, a URI without a transport parameter for sip: should effectively behave as UDP. The current behaviour breaks that expectation when using ds_is_from_list(). Two possible fixes come to mind: Adjust the core URI parser (parse_uri.c) to assign the appropriate default protocol (e.g. UDP for sip: URIs) instead of PROTO_NONE when the transport parameter is missing, aligning with RFC 3261 section 19.1.1 and the default transport rules. This would be the most standard-compliant approach, but it may have implications for other modules that rely on proto == PROTO_NONE to mean “transport not explicitly set”. Alternatively, handle this case inside the dispatcher module: when processing URIs from the list file or comparing them in ds_is_from_list(), treat PROTO_NONE as UDP for sip: schemes, so entries without an explicit transport still match incoming UDP traffic. Before preparing a patch, feedback would be appreciated on whether the preferred fix is in the core parser or localized to the dispatcher module and any thoughts or ideas for improvemtn. Best regards, Xenofon _______________________________________________ Kamailio - Development Mailing List -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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 Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com
_______________________________________________ Kamailio - Development Mailing List -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
