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

10 Oct 2024

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/ba6ab04e06b0dfd66874749e0…
  *   notification_peer.c (line
432)<https://github.com/kamailio/kamailio/blob/ba6ab04e06b0dfd66874749e0…

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