[sr-dev] Re: Inconsistencies in SIP Parsing with Embedded tel: URIs and Documentation Issues

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-leave(a)lists.kamailio.org