Hello,
RFC 3966 defines a phone-context attribute that can be appended to a tel URI like:
tel:1234;phone-context=munich.example.com
How do set set/read such URI with Asterisk 20 ?
Best regards
Hello,
RFC 3966 defines a phone-context attribute that can be appended to a tel URI like:
tel:1234;phone-context=munich.example.com
How do set set/read such URI with Asterisk 20 ?
Best regards
At least for SIP: URIs, user_eq_phone. However I cannot think why this would be needed with tel: URIs, a they are always phone numbers.
As to reading, I’ve never had cause to investigate that. Technically it is part of the URI, so it might be included in the URI, when you read that with the CHANNEL function. Again, it should be redundant for tel: URIs.
I think PJSIP_HEADER or CHANNEL should give access to full URI values, leaving you the duty to parse them as needed.
The question in fact mostly concerns writing such local, target, From or To URIs.
What user_eq_phone does once for all, for a given endpoint, could be ideally be generalized to support adding a single custom string such as “phone-context=munich.example.com” or “phone-context=munich.example.com;user=phone;foo=bar”, on a call by call basis.
I’m asking this phone-context attribute question because it seems to become a requirement here for Stir/Shaken with some domestic numbers (emergency, special-toll, …) that theoretically, cannot be written as E164 numbers.
Completing my last message, it seems Stir/Shaken introduction triggered a review of decades old SIP practices during which every took adhoc measures around usual SIP corner cases without any guidance or enforced standard.
Now, adding “phone-context” to SIP or TEL URIs becomes both urgent and mandatory after decades of silence on how to properly reach some specific numbers.
For To and request URI, I believe the value of contact, in the type=aor section, does include all the URI parameters.
Replying to myself, I think asking for custom attributes like “phone-context=munich.example.com;user=phone;foo=bar” is asking too much.
A more desirable goal would be to be able to just set the (single) value that fills the phone-context attribute.
To me, one of Asterisk’s strength is to understand SIP, to hide some protocol details.
Adding such phone-context may have consequences when computing an Identity header, so its best to have the building of this specific phone-context being supervised by Asterisk.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.