[asterisk-bugs] [JIRA] (ASTERISK-26902) Unnecessary changes to Domain Part of Request URI when setting User part

[Leo Brown (JIRA)]

Leo Brown created ASTERISK-26902:
------------------------------------

             Summary: Unnecessary changes to Domain Part of Request URI when setting User part
                 Key: ASTERISK-26902
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26902
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/Interoperability
    Affects Versions: 14.3.0
         Environment: CentOS6.7 x86_x64
            Reporter: Leo Brown
            Severity: Minor


Lets say we have a registered SIP peer, sip_123.

{{*CLI> sip show peer sip_123}}

{{Name       : sip_123}}
{{Addr->IP     : 195.95.76.61:5060}}
{{Reg. Contact : sip:sip_123 at 10.1.10.51:54547}}

As we can see the location is our serving proxy 195.95.76.61. If we dial out to this peer like:
{{Dial(SIP/sip_123)}}

We then correctly have an INVITE sent to 195.95.76.61:5060 which looks like:
{{INVITE sip:sip_123 at 10.1.10.51:54547}}

All is well. However, if we dial specifying a username part like:
{{Dial(SIP/sip_123/567)}}

Our INVITE looks like this:
{{INVITE sip:sip_123 at 195.95.76.61:5060}}

That is to say, the contact domain and port have been lost by virtue of setting the user part of the dialled contact.

If it were possible to collect all this data from Asterisk and construct a the INVITE based on the correct fields, that would be fine. However, as far as I understand there is no way to separately specify the Request URI and target IP address for a call, the assumption is that these are bound up in chan_sip’s processing.

I am sure PJSip contains more granularity over this but it’s simply not possible to switch out for PJSip at this time due to the number of bindings and new interop challenges.

I'm also aware that it's possible to change the To headers by using exclamation mark syntax in the dial string, however it is the Request URI which needs to be correct in this case.



--
This message was sent by Atlassian JIRA
(v6.2#6252)