Rework contact generation, add validation & enforce contact_user even for requests taking Contact from server_address

[vladpaiu]

Summary
Rework contact generation, add validation & enforce contact_user even for requests taking Contact from server_address

Details
Due to server_address potentially containing PVARs, validate the server_address before usage
Enforce contact_user modparam even for requests that generate the Contact from server_address

Thanks to Voicenter for reporting it & helping troubleshoot.

[github-actions]

Any updates here? No progress has been made in the last 30 days, marking as stale.

[bogdan-iancu]

There are couple of things not right here :

• parsing the generated URI (based on server_address_pve) is an unnecessary burn - as script writer you need to be sure you configuration is correct and not to expect OpenSIPS to parse it (for each message) just to be sure you are right - eventually you can do a dummy test at startup, to see if the pve generates a valid URI
• the replacement of the username part (if contact_user is on) in the generated URI (based on server_address_pve) does not look right - you do not actually replace the username part, but build a completely new URI based on the username and socket - so if my server_address_pve was pushing some URI params or anything else, it will be lost. Normally you should have here a sctrict username replacement into the local_contact parsed URI - this may be simply done with 3 memcpy's .

[vladpaiu]

There are couple of things not right here :

• parsing the generated URI (based on server_address_pve) is an unnecessary burn - as script writer you need to be sure you configuration is correct and not to expect OpenSIPS to parse it (for each message) just to be sure you are right - eventually you can do a dummy test at startup, to see if the pve generates a valid URI

Don't agree with the above ... OpenSIPS should validate the server address upon building, in order to avoid sending broken messages ( due to the script writer's fault, indeed ). Can't be validated at startup, since it might contain pvars which can be only evaluated in the SIP message context.

• the replacement of the username part (if contact_user is on) in the generated URI (based on server_address_pve) does not look right - you do not actually replace the username part, but build a completely new URI based on the username and socket - so if my server_address_pve was pushing some URI params or anything else, it will be lost. Normally you should have here a sctrict username replacement into the local_contact parsed URI - this may be simply done with 3 memcpy's .

This is indeed an issue - my use case didn't have uri params so I lost track of this. Needs correcting.

[bogdan-iancu]

There are couple of things not right here :

• parsing the generated URI (based on server_address_pve) is an unnecessary burn - as script writer you need to be sure you configuration is correct and not to expect OpenSIPS to parse it (for each message) just to be sure you are right - eventually you can do a dummy test at startup, to see if the pve generates a valid URI

Don't agree with the above ... OpenSIPS should validate the server address upon building, in order to avoid sending broken messages ( due to the script writer's fault, indeed ). Can't be validated at startup, since it might contain pvars which can be only evaluated in the SIP message context.

yes, the contact must be correct, but opensips should not continuously check if the configured data is correct or not. Like we do not check if the received AVP (in registrar) is a valid info, and so one. It is the duty of the script writer to be sure the configured data is correct.

• the replacement of the username part (if contact_user is on) in the generated URI (based on server_address_pve) does not look right - you do not actually replace the username part, but build a completely new URI based on the username and socket - so if my server_address_pve was pushing some URI params or anything else, it will be lost. Normally you should have here a sctrict username replacement into the local_contact parsed URI - this may be simply done with 3 memcpy's .

This is indeed an issue - my use case didn't have uri params so I lost track of this. Needs correcting.

LEt me know if you plan to change this, we have only 2 days left to the release

[vladpaiu]

did not have time to prioritize this, since it's labeled as a bug, maybe we can hotfix & backport later.