CUBE - New Deployment Issue - No media after HoldResume

[StewieGriffin]

Hello,

Scheme:

Cisco SCCP-based IP Phone > CUCM 9.1 w/ SIP Trunk > CUBE (28XX, 151-4.M7) > SIP ITSP

CUCM Active Call Proc. Node IP: 10.10.10.9
CUBE Inside Interface IP: 10.10.10.10
CUBE Outside Interface IP: 20.20.20.20
Cisco IP Phone: 10.10.10.8
ITSP SBC IP: 30.30.30.30 [sbc.itsp.domain]
ITSP SIP domain: itsp.domain
Calling Pty: 9017654321 (translated in CUCM's route pattern which addresses CUBE)
Called Pty: 9011234567

Symptom:

After outbound call is connected calling party (IP Phone) place call on hold.
Then after resume there is no audio for both sides (call remains active) although before hold all was fine.

Thoughts:

None.

Question:

Please, advice, how this can be fixed.

[Ayodeji Okanlawon]

To understand where the problem is occurring we need to understand how call-hold/resume work in SIP with CUCM/CUBE. Here are the steps that happens when a call is put on hold or transferred.

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path
2. CUCM sends a Delayed offer to insert MOH or to resume Media stream
3. CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to drop call will drop)
4. CUCM sends an ACK with sendonly to the 200 OK
5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to ocmplete transfer)
6. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

++++Here is the analysis of your logs++++

Here is a DO re-invite to CUBE to insert MOH, which CUBE sent to your ITSP (step 2 above)

Received:
INVITE sip:00019011234567@10.10.10.10:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.9:5060;branch=z9hG4bKf317a71eccad9
From:  <sip:79017654321@10.10.10.9>;tag=1230280~e7a88f34-6357-445a-a3f4-0cff26e7d816-35401728
To: <sip:00019011234567@10.10.10.10>;tag=1652C7D4-16EC
Date: Tue, 10 Feb 2015 16:34:49 GMT
Call-ID: aace2d80-4da13310-c6e1c-15520c0a@10.10.10.9

+++Here is CUBE sending out the DO to ITSP+++++

Sent:
INVITE sip:79011234567@30.30.30.30:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKD61EBD
From: <sip:79017654321@itsp.domain>;tag=1652C61C-1A26
To: <sip:79011234567@itsp.domain>;tag=986B324631353641C1A16100
Date: Tue, 10 Feb 2015 16:34:49 GMT
Call-ID: 821C33E4-B07911E4-82F1E759-B8B0000E@20.20.20.20

++++Here is the 200 OK from your ITSP (this is step 3 above, ITSP needs to send a send-recv)++++
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKD61EBD
From: <sip:79017654321@itsp.domain>;tag=1652C61C-1A26
To: <sip:79011234567@itsp.domain>;tag=986B324631353641C1A16100
Call-ID: 821C33E4-B07911E4-82F1E759-B8B0000E@20.20.20.20

--

c=IN IP4 30.30.30.30
t=0 0
m=audio 10320 RTP/AVP 8
b=AS:64
a=inactive
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:20

++++++++

As you can see ITSP is sending a=inactive, Hence the call is unable to resume as the media path remain inactive.

Suggestions/Solutions

1. We can try a feature called mid-call INVITE/Update consumption. With this feature the re-INVITE is not sent to ITSP by CUBE and hopefully this should resolve it. To configure this do the following

voice service voip

sip

mid-call signaling passthru media-change

2. You can also use MTP required on the sip trunk. This will also stop the re-INVITE going out to your ITSP. This should be the last resort though!

[StewieGriffin]

Ayodeji,

Seems 1st solution with 'mid-call signaling passthru media-change' is supported only for ISR G2 (I have ISR 2821). ISR supports feature 'Cisco Unified Border Element (formally Multiservice IP-to-IP Gateway) with Media Flow-Around' only up to 15.1* IOS.

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/cube-midcall-reinvite.html#GUID-BF9F3746-2700-4E76-A5A1-31E733CE5198

I have only the following type of this CLI:

#sh ver | i bin
System image file is "flash:c2800nm-adventerprisek9-mz.151-4.M7.bin"

(conf-serv-sip)#midcall-signaling ?
  passthru  Passthrough SIP messages from one IP leg to another IP leg
(conf-serv-sip)#midcall-signaling passthru ?
  <cr>

2nd solution with MTP required which is set for the trunk works like a charm :) Is it somehow non-optimal?

[Ayodeji Okanlawon · Accepted solution]

Using an MTP for all your calls over the sip trunk is not optimal because CUCM is not designed to terminate media. You have two options,

1. Use software based MTP on your CUBE gateway and assign the MTP to your sip trunk MRG

2. Upgrade your IOS to 15.2 so that you can use the midcall feature on CUBE

[StewieGriffin]

 Ayodeji,

After I've checked 'Media Termination Point Required' under CUCM's CUBE trunk all is working.

The only strange things are the following:

1. I do not have CUBE XCD registered with CUCM, only with itself. I mean CUCM theoretically cannot access this media resource.
2. I monitor via RTMT performance counters that non CUBE software MTP (IP VMS based) is not utilized at all.
3. I see that XCD is utilized per sucessfull call as xcode resource while both of legs are using g711a.

The situation when it's not clear why it is working but the fact is operable is all right :)

[Gary Parker]

Sorry for the thread-necro, but I just wanted to say thank you for this solution.

We're part way through migrating users from CUCM to MS Teams Voice and are routing calls out to our ITSP via CUBEs, who then hosts the Direct Routing trunk to our Teams tenancies. We were seeing exactly this problem with calls from CUCM to Teams that were put on hold either directly or as part of an attended transfer. It didn't affect calls from CUCM to the PSTN, though.

Adding the 'mid-call signaling passthru media-change' command to our CUBEs fixed the issue.