Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

SIP Trunk Disconnect Problem

Having an interesting issue with an IP Trunk pilot,
Users are being disconnected when certain tones are heard on a call. We can recreate this problem anytime by playing the Blackberry default ringer while a call is in progress. According to the carrier  they are set up for mid-call  codec renegotiation when fax tone is heard on a call. The CUCM rejects the codec renegotiation and the carrier  disconnects.
TAC  provided an option for the CUBE which is supposed to pass the codec renegotiation rejection message from Call Manager to the SBC but this has had no effect on resolving the problem.
voice service voip
  header-passing error-passthru
This error response applies to the following
    4xx - request failure responses
    5xx - server failure responses
    6xx - global failure responses
This command should pass the error received along both call legs.
While this could be useful feature at times I was wondering if anyone else has run into this and has a fix.
Cisco Employee

Re: SIP Trunk Disconnect Problem

Hello Steve,

That's interesting one for sure.

Though 'header-passing error-passthru' is a good catch but the thing is that CUBE/CME IP-to-IP code does not forward 488 response to the other call leg.

Instead 500 is sent and call is terminated.

There was an internal discussion about that issue and as far as I know this behaviour will be changed in 15M train.

If you want to know details you can contact your Cisco Account team and they will shed some light here.

Some things to consider/possible workaround:

- this behaviour will only happen in case CME/CUBE will forward T.38 re-INVITE between IP call legs and CUCM or other call agent will

reply with 488 message.

- as far as I understand this is conf call so no parties are able to terminate FAX call. You can define dial-peers so that no FAX capabilities

configured on CUBE for that call flow and 488 will be sent by CUBE itself and not forwarded by CUCM

- even if 488 response will be sent to the Service Provider - it's up to them how to treat that call further - whether they have a g711 fallback for such

calls or not

- the underlying problem behind this behaviour is that SIP does not have T.38 capabilities negotiation as H.323 does and thus any side can initial

switchover at any time during the call . With H.323 if there was no T.38 capabilities received during H.245 negotiation the party will not initiate switchover.

That's different with SIP and can't be changed but we have 488 response and party which receive it may process it so the call is not terminated.



New Member

Re: SIP Trunk Disconnect Problem

Thanks for the feedback, what would be the best way to define dial-peers so that there are no FAX capabilities? I can give that a try.

Cisco Employee

Re: SIP Trunk Disconnect Problem

Hello Steve,

To implement this change you will need:

1. disable FAX support on system level

voice service voip

fax proto none

2. disable FAX on dial-peers where it's not required

dial-peer voice X voip

fax proto none

3. enable FAX on dial-peers where it required

dial-peer voice Y voip

fax proto t38



CreatePlease to create content