Hi all, I’d like to bring up some development topics related to the SIP parsing logic, specifically when handling sip: with embedded tel URIs scheme. The current behaviour, particularly when user=phone is present, is leading to some inconsistencies and potential confusion, and I believe it might require some refactoring or documentation updates. Current Parsing Behavior: When a tel: URI is embedded in a sip: scheme (e.g., user=phone is present), the parser currently copies the URI parsed parameters to sip_params, then splits the user part (like 123;param=value;param2=value2) into user and all the rest tel parameters to params. This behaviour is only triggered when the global phone2tel configuration option is enabled (which is the default). Issues: 1. Inconsistent Handling of URI Parameters There’s no consistency across modules on whether they use sip_params or params to get the URI parameters. While most modules correctly use sip_params, others use params. Normally, this works fine because sip_params and params hold the same data when user=phone is not present or phone2tel is disabled. However, when user=phone is present and phone2tel is enabled, params may be empty, leading to unexpected behavior in modules relying on it. For example, the following modules are using params and many others:
* dmqnode.c (line 204)<https://github.com/kamailio/kamailio/blob/ba6ab04e06b0dfd66874749e0cb1225f2ee273ac/src/modules/dmq/dmqnode.c#L204> * notification_peer.c (line 432)<https://github.com/kamailio/kamailio/blob/ba6ab04e06b0dfd66874749e0cb1225f2ee273ac/src/modules/dmq/notification_peer.c#L432> While some may handle the differences between sip_params and params, not all of them do. 2. Unclear Intention of the phone2tel Global Parameter The current parser code is quite old, and it’s unclear what the original intention behind the phone2tel global parameter was. As far as I understand, the sip: scheme can handle tel: URIs, and this is the most widely accepted specification. The role of phone2tel seems to blur the lines between the two schemes, leading to unexpected transformations. Example of Unexpected Behavior: Consider the following header: P-Asserted-Identity: Display <sip:+1234;pname=pval@domain;user=phone>;tag=1234 If we apply the {tobody.user} transformation, the expected output should be the user part of the URI. Based on the RFC, we expected the transformation to return +1234;pname=pval. However, due to the phone2tel global configuration parameter, the parser treats it as a tel: scheme and returns only +1234. This behavior seems to be influenced by how the global parameter forces the parser to handle the URI. Proposal: To resolve these issues, I suggest the following: 1. Refactor Parameter Handling: Introduce a more explicit separation of tel_params and sip_params, and ensure all modules use the correct set of parameters based on the context. This would help enforce consistency across the codebase. 2. Update Documentation: Provide clear documentation regarding the behavior of phone2tel and how it impacts URI parsing. In particular, the transformation documentation should reflect the expected behavior depending on whether the URI is treated as sip: or tel:. 3. Review and Fix Modules: We should audit the modules that currently rely on params and ensure they are using sip_params where appropriate, especially in cases where user=phone could be present. Any guidance or feedback on these points would be greatly appreciated. If you’ve encountered any related bugs or discovered other edge cases, please let me know so we can address them. Best regards, Xenofon
_______________________________________________ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
