Giters

asterisk / asterisk

The official Asterisk Project repository.

Home Page:https://www.asterisk.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[improvement]: Document EXTEN can include options/parameters for PJSIP

jay293874 opened this issue · comments

commented

Severity

Minor

Versions

20.*

Components/Modules

chan_pjsip

Operating Environment

Linux x64

Frequency of Occurrence

Constant

Issue Description

Incoming calls having userinfo parameters in the To-header are not parsed by Asterisk.
This causes Asterisk to set the read-only channel variable EXTEN to wrong value
Example:

To: sip:+1234;bla=ble;more@example.com;transport=tcp

Relevant log output

CHANNEL(EXTEN) gets set to 

+1234;bla=ble;more

instead of

+1234

Asterisk Issue Guidelines

  • Yes, I have read the Asterisk Issue Guidelines
commented

Asterisk doesn't use the To header for the value of EXTEN. It uses the user portion of the request URI. Is there custom dialplan logic involved that accesses the To header to get such a value?

commented

Sorry, forgot to mention the request URI also contain the same value

Yes we have a custom dialplan in our config pointed from the context config parameter.
Outputting the value of EXTEN in this dialplan gives this wrong value.
If the dialed extension is not supposed to be taken from EXTEN, then what is ?

commented

I didn't say EXTEN is not supposed to be used for such a thing, I was asking for clarification as your original report did not match how Asterisk actually worked.

PJSIP itself is what handles all the parsing at a lower level than us, according to the specifications. Looking at the specifications don't show parameters in the user portion, instead it's just a username, which would explain why they are not parsed out. Looking at some mailing list posts confirm this line of thinking too.

I don't think this is a bug but could be an improvement, however changing such behaviour in releases by default could be problematic as individuals may have written custom logic in the dialplan to strip out values from it before extracting just the extension portion and sending the call on its way.

commented

If the parameters are used for something instead of just stripped out, then yes it could break stuff.
I believe the Asterisk documentation is somewhat clear on that EXTEN is supposed to be the value of the extension only. So not the same as the "user part". I am guessing this can break some of the other Asterisk functions taking extension as parameter if exten is not the extension only.
The user parameters are nevertheless available from PJSIP_PARSE_URI.

Correcting this in the next major version might be an ok solution?

commented

Actually there is already an pjsip.conf option for this: ignore_uri_user_options
Perhaps add a comment to exten in the documentation only then.

commented

You'll need to be specific about what documentation you are referring to.

commented

So you are saying the documentation about that option should be extended to also mention that it covers EXTEN?

commented

When I read the channel documentation it gives the impression that EXTEN contains the extension only.
Since it does not, I would adjust the wording to mention that it contains the entire user part by default.

commented

What documentation and wording regarding EXTEN?