cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4310
Views
5
Helpful
14
Replies

SIP Trunk CUCM to Avaya remote = 503.

stobar1101
Level 1
Level 1

Hi guys,

 

I have a trunk from my CUCM to an Avaya, the SIP trunk was working fine, but suddenly the following error appeared, remote = 503, If I arrive by ICMP to the IP of the Avaya, I have restarted the SIP Trunk and the behavior is the same.

 

Thanks for the help.

14 Replies 14

Ratheesh Kumar
VIP Alumni
VIP Alumni
Can you try checking the MTP required in SIP Trunk and test.

Hope this helps

Cheers
Rath!

***Please rate helpful posts***


Hi Ratheesh,

I have marked MPT, and the behavior is the same, I have also tried to remove it and the behavior is the same.

Thank you

Just curious which side is having the issue. Is it Cisco to Avaya calls or vice versa.

CCM Traces will be your best bet. Also try “Early Offer support for voice and video calls (insert MTP if needed )" in your CUCM SIP Trunk’s SIP Profile.



Hope this helps

Cheers
Rath!

***Please rate helpful posts***

Priyam Acharya
Cisco Employee
Cisco Employee

Hi Stobar,

 

1) Make sure there is no changes made on Firewall in terms of port 5060 (or any other that is being used by CUCM-Avaya trunk.

2) Please send us the output of "utils dbreplication runtimestate" on Publisher of CUCM.

3) Is "Run On All Active Unified CM Nodes" option checked on the trunk configuration page?

 

Thanks,

Priyam Acharya

Hi Priachar,

1) Does not pass through any Firewall.

2) I attach the result of the command utils dbreplication runtimestate

admin:utils dbreplication runtimestate

Server Time: Sun Jun 10 20:52:34 CST 2018

Cluster Replication State: BROADCAST SYNC ended at: 2018-03-05-15-57
Sync Result: SYNC COMPLETED on 706 tables out of 706
Sync Status: All Tables are in sync
Use CLI to see detail: 'file view activelog cm/trace/dbl/20180305_155444_dbl_repl_output_Broadcast.log'

DB Version: ccm11_5_1_14900_11

Repltimeout set to: 300s
PROCESS option set to: 1


Cluster Detailed View from CUCM-CAD-PUB (2 Servers):

PING DB/RPC/ REPL. Replication REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) DbMon? QUEUE Group ID (RTMT) & Details
----------- ---------- ------ ------- ----- ----------- ------------------
CUCM-CAD-PUB 192.168.61.84 0.016 Y/Y/Y 0 (g_2) (2) Setup Completed
CUCM-CAD-SUB 192.168.61.85 0.488 Y/Y/Y 0 (g_3) (2) Setup Completed

3) If this option is checked.

Thanks for the help,

Hi, 

 

Please collect packet captures from CUCM nodes and try resetting the SIP trunk in question. 

Make sure before you collect packet captures under Device >> Device Settings >> SIP Profiles >> "Enable OPTIONS Ping to monitor destination status for Trunks with Service Type "None (Default)"  is checked.

 

Thanks,

Priyam Acharya

Dennis Mink
VIP Alumni
VIP Alumni

Because this has been working before; are you using TLS across this trunk?  If so have you checked for expired certs?

Please remember to rate useful posts, by clicking on the stars below.

.

stobar1101
Level 1
Level 1

Hello everyone,

 

They have found an inconvenience in Avaya, on that side there was the problem.

 

The weird thing is that Avaya always appeared UP.

 

Saludos,

awesome! what was it?

Please remember to rate useful posts, by clicking on the stars below.

The Avaya provider did not tell us what the problem was, but it took 4 days to restore the service.

Thanks for the help.

jairochavez
Level 1
Level 1

Problem Clarification

Case 1: SIP trunk between IP office and Call Manager.
                When there is an incoming call from CUCM to IP Office, IP Office displays 503 service unavailable, destination incompatible cause 88.

 

Case 2: Cause code 88 - Incompatible destination.

 

Solution

Case1: Cisco Call Manager is sending the invite to IP Office without SDP and IP Office is rejecting the call with 503 service unavailable.To be fixed from CUCM side.

OR

Case2: Enable the option "Allow Empty INVITE" in SIP Advanced tab, this will allow the call to be established from IP Office without SDP.

Why you answering to a post, that's already years old and also seems to solved?

jairochavez
Level 1
Level 1

Because as mentioned by stobar1101: "The Avaya provider did not tell us what the problem was, but it took 4 days to restore the service."

I had a recent situation that is similar and I wanted to post the solution applied.