cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
535
Views
0
Helpful
4
Replies

Cube not passing 200 OK to calling party

Tony Tran
Level 1
Level 1

Call Flow: Saas Solution > CUBE > SME > CUCM > PSTN Gateway

When a call is initiated from the Saas product, the called party rings and answers, but only gets dead air and calling party still hears ring back.

in the attached image, you'll see 19:51:06 is when the called party answers and SME sends 200 OK (101 INVITE) to CUBE. but cube never passes that back to the calling party. 

Please help

4 Replies 4

TechLvr
Spotlight
Spotlight

You did not share any logs but based on your ladder diagram, I see two issues.

Issue #1:
Your CUBE receives the initial invite from Saas on its inside interface but responds to the invite from its outside interface. You can fix this issue by adding the sip bind interface command under the incoming dial peer facing Saas. Note: You need to use the inside interface of the CUBE in your sip bind command since that’s where Saas is pointing to.

Please see example below.

dial-peer voice 1 voip
voice-class sip bind all source-interface fastethernet0/0 (this needs to be the inside interface of your CUBE)

Issue #2
Saas does not send a PRACK to the CUBE in response to the 183 Session Progress message and so the CUBE send a 504 Gateway Timeout. You can fix this in the CUBE by replacing the “rel1xx required 100rel” command with “rel1xx supported 100rel” under the global configs or the “voice-class sip rel1xx require 100rel” command with “voice-class sip rel1xx supported 100rel” under the incoming dial peer facing Saas.

Examples:
Under global configs

voice service voip
sip
rel1xx supported 100rel

Under a dial peer

dial-peer voice 1 voip
voice-class sip rel1xx supported100rel

#1 - tried adding that to the dial-peer and made no difference.

#2 - this command is already in the global configs

Looking at the PCAP the Saas provider sent to me from their end, it shows my cube continually sending them 183 Session Progress SDP. Shouldn't it be something on their end missing with the lack of response to the 183 message?

It is possible the the provider SBCs do not accept 183 with SDP (early media offer).

There are a few things you can try but before I make any further suggestions, could you please share the latest sip logs from your CUBE (after you made changes)? You can use Notepad++ to mask sensitive info like public addresses and phone numbers.