SIP Trunk Disconnect Problem

Unanswered Question
Jan 28th, 2010
User Badges:
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
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Vladimir Savostin Mon, 02/01/2010 - 12:50
User Badges:
  • Cisco Employee,

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 Tue, 02/02/2010 - 12:07
User Badges:

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 Tue, 02/02/2010 - 13:43
User Badges:
  • Cisco Employee,

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.

Actions

This Discussion