IP Office SIP Trunk call forward or twinning no audio - Sundance Business VOIP Telephone Help

We did a deep-dive on this issue that crops up from time to time. It turns out a very specific set of circumstances between the IPO and some SIP providers cause the IPO to completely neglect sending any outgoing audio. Here are the steps to duplicate the issue on R11.0.4.7 (although we believe it exists on many other versions as well).

Code

SCENARIO 1
1. Setup an inbound call route with an external phone number in the destination. Your shortcodes should send the call over the same SIP trunk the call arrived on.
2. Call the inbound call route DID from a 3rd party external number.
3. Verify no audio is heard in either direction.
4. Mobile twinning would likely exhibit the same behavior.

Code

SCENARIO 2
Here is a quick workaround for the above scenario:
1. Setup an auto attendant with a 1 second timeout.
2. Setup an inbound call route with the new AA in the destination and your external phone number in the fallback field.
3. Call the inbound call route DID from a 3rd party external number.
4. Verify audio is heard in both directions.

Code

SCENARIO 3
Here is a more clunky workaround for scenario 1:
1. Change the LAN1 or LAN2>VoIP>Keepalives>Scope to RTP-RTCP and VoIP>Keepalives>Periodic Timeout to 1.
2. Setup an inbound call route with an external phone number in the destination. Your shortcodes should send the call over the same SIP trunk the call arrived on.
3. Call the inbound call route DID from a 3rd party external number.
4. Verify audio is heard in both directions after 2 seconds.

Code

SCENARIO 4
Here yet another workaround for scenario 1:
1. Create a 2nd SIP line that is an exact duplicate of the first.
2. Change the only allowed CODEC for the 2nd SIP line to be something different than the first, also change the outgoing group ID to something different than SIP line 1.
3. Setup an inbound call route with an external phone number in the destination. The call should arrive via your first SIP line and shortcodes should send the forwarded call over the 2nd SIP line you just setup.
3. Call the inbound call route DID from a 3rd party external number.
4. Verify audio is heard in both directions. This would use a VCM channel since the IPO is transcoding the audio.

The root of the issue is that the IP Office does not send any initial RTP audio packets as the call is being established. If it did, 2 things would be accomplished: 1 - a pinhole would be opened in the firewall allowing RTP audio back from the SIP provider, and 2 - the SIP provider would see incoming audio which in turn might kick them into gear as far as sending audio back.

This is the sequence of events upon inspection of the SIP & RTP packets during a no-audio call with our specific SIP provider:
1. The call arrives at the IPO, it sends a 180 Ringing back.
2. The IPO generates a 2nd call to the forwarding number, the SIP provider sends 100 Trying.
3. The SIP provider begins sending RTP Comfort Noise packets. These will only make it through to the IPO if port forwarding on the RTP ports is enabled, but this doesn't make a difference to the outcome of the call.
4. The SIP provider sends a 200 OK with SDP when the forwarding number answers.
5. The IPO immediately sends a 200 OK with SDP on the initial leg of the call.
6. The SIP provider immediately begins sending RTP Comfort Noise packets on the initial leg of the call.
7. The call exists until 1 side hangs up, but the IPO never sends a single outgoing RTP audio packet.

FINAL NOTES:
- The LAN1 or LAN2>VoIP>Keepalives>Scope>Enabled and Initial keepalives>Enabled settings *SHOULD* resolve this issue, but they do not.
- Routing briefly through an AA is a workaround because it begins the flow of RTP audio prior to the 2nd leg of the call being placed.
- Some SIP providers do not wait to see audio from the IPO before they begin sending it; to the best of our knowledge this prevents the issue.