Transferring an internal call to external number sends to incoming IP instead of Outbound

[cyberdemon]

Hello, I have run into an issue configuring one of our phone systems. Currently, they use an unsupported SIP Trunk, VoIP Innovations. We are having issues when a call comes in and they need to speak to someone from their cell phone. A call will come in, someone in the office answers it without issue. They ask for someone who is out of the office but has their cell phone. The in-office user transfers the call to the external number, but it can sometimes take in excess of 30 seconds before it starts ringing. I've reached out to the SIP provider and they have confirmed that these calls are being sent to their Inbound IP address instead of the Outbound IP Address. I have made changes to the SIP configuration for the Outbound Parameters to resolve this issue but it only applies to calls originating from within the system. If the call comes in from an external line and needs to be transferred, it appears that it will not send using these Outbound Parameters and instead tries to connect over the Inbound IP, which our SIP provider states is causing the massive delay for making this transfer. I've been working on this issue for quite a while now but only recently we have gotten to this point. Let me know what additional information I can provide to get me some help.

 

[NicholasP_3CX]

When you create a SIP Trunk configuration, please use the Generic template provided. This will allow you to define an outbound proxy to connect to.

Do not use an existing providers template and modify that.

 

[cyberdemon]

Hey Nicholas,
So when I create a new SIP Trunk using the generic template, I fill in the info for the Outbound Proxy. However, when dialing out from the phone system, the call is not using the outbound proxy unless I specifically edit the SIP Trunk settings to use "OutHostPort" instead of "GWHostPort" for the outbound parameters. I've had a thread recently in the SIP Trunk subforum about this and that was the fix provided to me to resolve this issue. Currently when we call outbound, it is using the outbound proxy because of this change. When a call comes in and we transfer to an external number, it sends the outbound call across the Inbound IP instead of the Outbound Proxy.

 

[cyberdemon]

bump

 

[NicholasP_3CX]

OK, just to clarify...

• Does this happen on an attended, or blind transfer? Can you try with both to see the behaviour?
• Can you also try, as a test, to forward the call to an extension which has a mobile number defined, and set it to away and forward to this mobile from the forwarding rule?

With this information in hand, I woul suggest opening a ticket with these findings, even if it is an unsupported provider, as this is not the expected behaviour.

 

[cyberdemon]

It appears this happens during Blind Transfers. I made a call into the system with our Office Phone, worked with the client to perform an attended transfer, she dialed my personal cell number and after connecting hit transfer. The call went straight through and she said it only rang 3 times when dialing my cell number. I have reached out to the carrier to confirm the IP address but it appears to be correct. I have not confirmed the other tests yet.

 

[cyberdemon]

VoIP Innovations has been emailing me back and forth and has claimed that the issue they noticed is
"Please verify you are passing a valid P-Asserted-Identity or Remote-Party-ID that conforms with RFC rules. Your provided PCAP does not show what you are sending to our switch, only internal to your network, however, based on what I see in your signaling the PAID header is not a valid URI and is missing the host:.
P-Asserted-Identity: "+1CLIENTPHONENUMBER"

Additionally, the Remote-Party-ID contains an reserved URI character "," within the user value: "Test,%20Test"
Remote-Party-ID: "Test, Test";party=calling

You will need to correct the malformed SIP URIs to prevent calls from being rejected with invalid ANI."

Test, Test is the name on an extension I have been using for testing. This is what they responded with when I asked about the call I made described above, they did confirm the IP came across correctly though. Do I need to start a new thread for this issue?