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] > To unsubscribe send an email to [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!
