Hello,

fine for me to do some refactoring for better clarity of purpose and type of parameters. As we are going to use version 6.0.x with next major release, it should be fine if the change is more intrusive (e.g., new field for tel params or user params, maybe new field for indicating the type of uri ...) -- of course all affected components have to be updated (if it is a lot to do, can be eventually done during the devel meeting in Dusseldorf).

In case of starting to code in such direction, a PR can be proposed, so others can review/contribute.

Cheers,
Daniel

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)
• notification_peer.c (line 432)

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@lists.kamailio.org

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, October 8-10, 2024 -- asipto.com