CUBE - some calls connect with "a=inactive" from ITSP

[TONY SMITH]

Hi,

The installation is CUCM 11.5 with CUBE gateways to ITSP services.  Signalling is SIP delayed offer CUCM->CUBE, early offer to the ITSP.   This has been in place for some time, the only significant recent change was upgrade CUCM from 9.1 to 11.5.

Recently there are reports of some outgoing calls that connect with no audio.   Looking at the SIP debugs the ITSP's "OK" when the call connects has "a=inactive" in the SDP.  That gets relayed onto CUCM and the call connects without audio.   Shortly afterwards the ITSP sends an Re-Invite, this time with normal SDP "a=sendrcv".  The CUBE responds with Trying followed by 200 OK, but nothing is forwarded to CUCM to indicate that the call is no longer inactive.  In the example I looked at this was repeated, a second Re-Invite also responded to by the CUBE with no signalling to CUCM.   Shortly after this CUCM sent Bye as the caller hung up.

Does that sequence sound correct on the ITSP side?  Superficially it looks as if the CUBE has correctly responded to both the original inactive OK and the later Re-Invite, but that then begs the question why the ISTP sent a second Re-Invite.

On the CUCM side it doesn't look right intuitively.  CUBE has correctly connected the call with "a=inactive" but not updated with "a=sendrcv".

Any ideas as to whether I should be looking at the CUBE, the ITSP or the CUCM to CUBE signalling?

Thanks,

Tony S

[bichacko]

Hi,

Would you be able to paste the complete output here with calling and called number information?
Also, check the output of 'show voip rtp conn'.

Apart from that, if you are sure that the provider sends out a=inactive, which usually is when you use hold or features of that sort, then yeah you can check with them the reason for sending inactive media attribute.

<snippet from RFC>
A UA
may, if desired, initiate hold by offering "a=inactive" attribute if
it does not intend to transmit any media while in hold status
</snippet>



Thanks,
Bijo

[TONY SMITH]

I'm not sure I should show customer specific information on a public forum, however here is the SIP debug in full but with specifics masked, for example the actually dialled number replaced with **CALLED-NUMBER**.  Similarly IP addresses replaced with functional names like **CUBE-OUT-IP**

Also a signalling diagram, the column with the first received INVITE is CUCM<->CUBE, the column with the first outgoing INVITE is CUBE<->ITSP, as is the next column with the incoming Re-INVITE.   Not sure why it displays like that,  something do whether debugs show source/destination as customer domain or as IP.

[Jinto Alakkal]

Hi there you may try to apply this to your SIP profile 

voice class sip-profiles 1
request REINVITE sdp-header Audio-Attribute modify "inactive" "sendrecv"
request REINVITE sdp-header Audio-Attribute modify "recvonly" "sendrecv"
request REINVITE sdp-header Audio-Attribute modify "sendonly" "sendrecv"

for example

dial-peer voice 1 voip
description Outbound dial-peer
voice-class sip-profile 1

voice service voip
sip
sip-profile 1

[Ariel.heredia]

Hello Tony Smith, 

I'm having this issue, migrated from 9.5 to 12.5 and have the same symptoms

Did you find a solution?

[TONY SMITH]

I did indeed.  The culprit was the configuration line "midcall-signaling passthru media-change" which was needed to work around a problem of calls dropping when put on hold, and which I'd applied at global level.  To fix this side effect we disabled this at dial-peer level, applied to the outside dial-peer for CUBE/ITSP leg.   Looking back at my SIP diagram, with this fix in place the re-Invite passes through to the CUBE/CUCM leg to set media to sendrcv.

I expect the suggested SIP profile would have done the trick, but I didn't try it.

I had a another issue with a new deployment with at first glance the same symptoms, calls connecting with "a=inactive".  That turned out to be a firewall error which was completely unexpected, almost as if the signalling showed inactive because it knew the firewall would block RTP.