Hello,
This is in regard to the requirement to enter DIDs in E.164 for SMS following the ~18u6 update. While QAing this, we discovered a possible issue that may effect some inbound forwarded calls. Is there another way this should be configured or is the below behavior by design?
The below example shows a caller dialing a 3rd party phone number. The recipient uses their system to establish call forwarding to the 3CX system in question with the DID hosted by Flowroute. Prior to the E.164 requirment, the trunk would be configured with inbound parameter mapping: "CalledNum" --> "Request Line URI : User Part". The invite in the below example, however, doesn't provide the DID in E.164 and changing the mapping to "CalledNum" --> "To : User Part" does not resolve the issue as, in the below example, the To header provides the number originally dialed by the caller before the call was forwarded.
Example:
In this example, the caller ($CID) dials $DEST. The call is then forwarded from $DEST to $FWD
We have found, while $FWD begins with the country code, it is not being sent in E.164 format.
===
09/12/2023 9:14:17 AM - [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification: Invite-UNK Recv Req INVITE from <REDACTED>:5060 tid=<REDACTED> Call-ID=<REDACTED>: INVITE sip:$FWD@<REDACTED> SIP/2.0 Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Max-Forwards: 66 Record-Route: <sip:<REDACTED>;lr> Record-Route: <sip:<REDACTED>;lr> Contact: <sip:+1$CID@<REDACTED>:5060> To: <sip:+1$[email protected]> From: "<REDACTED>" <sip:+1$[email protected]>;tag=<REDACTED> Call-ID: <REDACTED>@<REDACTED> CSeq: <REDACTED> INVITE Session-Expires: 21600 Min-SE: 90 Content-Type: application/sdp Supported: timer P-Asserted-Identity: "<REDACTED>" <sip:+1$CID;verstat=[email protected]> Diversion: <sip:+1$DEST@fl.gg>;reason=unknown;screen=yes;privacy=off Alias: <REDACTED> Content-Length: 228 v=0 o=- <REDACTED> IN IP4 <REDACTED> s=- c=IN IP4 <REDACTED> t=0 0 m=audio 41294 RTP/AVP 0 8 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:<REDACTED> telephone-event/8000 a=fmtp:<REDACTED> 0-15 a=maxptime:20
===
In the above example, the forwarded destination is only included in the request line URI and is not provided in E.164. As the number is forwarded from a 3rd party we have no control to adjust formatting. The To field only includes $DEST (the number originally dialed by the caller before the call was forwarded) thus that DID does not exist on this 3CX system.
We, so far, can only work around the issue by 1.) changing the SIP trunk mapping to "CalledNum" --> "Request Line URI : User Part" and not entering the DID in E.164. While SMS could be used with this configuration in prior versions, the current requirement for E.164 means this work around now breaks SMS. Additionally, though non-E.164 formatted DIDs can be entered in the admin console, errors are shown in the web client.
Would there be another way to address this issue 1.) retaining SMS functionality and 2.) avoiding the errors shown in the web client or, to receive the example inbound forwarded call, is the only option to disable SMS on that DID by configuring the trunk to inspect Request Line URI and not entering the DID in E.164 format?
Thank you for your help on this.
This is in regard to the requirement to enter DIDs in E.164 for SMS following the ~18u6 update. While QAing this, we discovered a possible issue that may effect some inbound forwarded calls. Is there another way this should be configured or is the below behavior by design?
The below example shows a caller dialing a 3rd party phone number. The recipient uses their system to establish call forwarding to the 3CX system in question with the DID hosted by Flowroute. Prior to the E.164 requirment, the trunk would be configured with inbound parameter mapping: "CalledNum" --> "Request Line URI : User Part". The invite in the below example, however, doesn't provide the DID in E.164 and changing the mapping to "CalledNum" --> "To : User Part" does not resolve the issue as, in the below example, the To header provides the number originally dialed by the caller before the call was forwarded.
Example:
In this example, the caller ($CID) dials $DEST. The call is then forwarded from $DEST to $FWD
We have found, while $FWD begins with the country code, it is not being sent in E.164 format.
===
09/12/2023 9:14:17 AM - [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification: Invite-UNK Recv Req INVITE from <REDACTED>:5060 tid=<REDACTED> Call-ID=<REDACTED>: INVITE sip:$FWD@<REDACTED> SIP/2.0 Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Via: SIP/2.0/UDP <REDACTED>:5060;branch=<REDACTED> Max-Forwards: 66 Record-Route: <sip:<REDACTED>;lr> Record-Route: <sip:<REDACTED>;lr> Contact: <sip:+1$CID@<REDACTED>:5060> To: <sip:+1$[email protected]> From: "<REDACTED>" <sip:+1$[email protected]>;tag=<REDACTED> Call-ID: <REDACTED>@<REDACTED> CSeq: <REDACTED> INVITE Session-Expires: 21600 Min-SE: 90 Content-Type: application/sdp Supported: timer P-Asserted-Identity: "<REDACTED>" <sip:+1$CID;verstat=[email protected]> Diversion: <sip:+1$DEST@fl.gg>;reason=unknown;screen=yes;privacy=off Alias: <REDACTED> Content-Length: 228 v=0 o=- <REDACTED> IN IP4 <REDACTED> s=- c=IN IP4 <REDACTED> t=0 0 m=audio 41294 RTP/AVP 0 8 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:<REDACTED> telephone-event/8000 a=fmtp:<REDACTED> 0-15 a=maxptime:20
===
In the above example, the forwarded destination is only included in the request line URI and is not provided in E.164. As the number is forwarded from a 3rd party we have no control to adjust formatting. The To field only includes $DEST (the number originally dialed by the caller before the call was forwarded) thus that DID does not exist on this 3CX system.
We, so far, can only work around the issue by 1.) changing the SIP trunk mapping to "CalledNum" --> "Request Line URI : User Part" and not entering the DID in E.164. While SMS could be used with this configuration in prior versions, the current requirement for E.164 means this work around now breaks SMS. Additionally, though non-E.164 formatted DIDs can be entered in the admin console, errors are shown in the web client.
Would there be another way to address this issue 1.) retaining SMS functionality and 2.) avoiding the errors shown in the web client or, to receive the example inbound forwarded call, is the only option to disable SMS on that DID by configuring the trunk to inspect Request Line URI and not entering the DID in E.164 format?
Thank you for your help on this.
