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!
