SIP Trunk Disconnect Problem

s.casper_2 · ‎01-28-2010

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

sip

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.

Steve

Vladimir Savostin · ‎02-01-2010

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.

Regards,

Vladimir.

s.casper_2 · ‎02-02-2010

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.

Vladimir Savostin · ‎02-02-2010

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

Regards,

Vladimir.