AASBC: Calls failing with shuffling re-invite with no SDP

Doc ID    SOLN295138
Version:    7.0
Status:    Published
Published date:    17 Mar 2026
Created Date:    19 Aug 2016
Author:   
Nilesh Yadav
 

Details

 AASBC all versions

 

Problem Clarification

Unable to establish a call from SIP phone. Call end in 3 seconds. Called Party has answered the call but there was no talk path, he hanged up. Caller has seen the call timer counting, but has not heard anything once the call has been established.

 Call Flow : Station -> SM -> CM -> SM -> SBC  ->  SIP Trunk

Carrier is sending 180 after 183

Scenario 2

Customer deployment had two network paths (A and B) to the internal phone network. The call routing was managed by a single ACM but with separate SM/SBCE paths to the Service Provider networks.

Calls would fail when routing via network path B where shuffling was occurring, but via network path A no shuffling occurred and calls would connect. Direct IP-IP Audio Connections were enabled on all the involved signaling-groups. 

Cause

 During investigation got to know CM sending Re-Invite to shuffle the call to SM. Shuffling re invite has no SDP. SM is sending same re-invite to SBC. SBC should not be sending it to service provider (SP). However it was forwarding it SP. 

 SBC was not processing re invite with no SDP correctly

Scenario 2

The primary cause of the call failures was due to the mobile carrier downstream of the Service Provider having a fault related to the handling of empty re-INVITEs.

The cause of the difference in call behavior between network path A (no shuffling) and network path B (shuffling) related to a difference in the network regions of the call path. Network path A calls were transiting two network regions where Inter-region IP-IP Direct Audio was disabled and so shuffling was not possible. Calls through network path B traveled through a single network region and so shuffling was possible - resulting in the re-INVITE being sent back to the Service Provider.
 

Solution

Configuration change in SBC  

Global Profiles – Server Interworking – SIP_BT  -> Delayed SDP Handling    Yes 

Also refer to SOLN334364 - Communication Manager:Enable special application (SA8965) - SIP Shuffling with SDP?

Scenario 2

The issue was solved by disabling the Direct IP-IP Audio Connection setting for the signaling-groups being used by the network path B. There was sufficient media resources for the customer to not need to use Direct IP-IP Audio Connection in this particular scenario.
 

Additional Relevant Phrases

Delayed SDP handling, oneway audio for transferred call to PSTN

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy