cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11258
Views
0
Helpful
6
Replies

(47) Resource unavailable, unspecified disconnection cause for both side call via SIP

ccg-collab1
Level 2
Level 2

Hi All,

 

We are encountering an issue right now wherein we are getting a busy tone when calling a specific number. Upon checking the logs, the disconnection cause code is (47) Resource unavailable, unspecified for both side (calling and called party).

 

Here is the below call flow.

IP Phone-CUCM-SIP-CUBE

 

Basically, we are calling an international number and we route it to the CUBE. However, call is failing and we are getting a (47) Resource unavailable, unspecified for both side (calling and called party).

 

From the collected logs, we tried to check it using translator x and below is the call flow.

busytone call flow.jpg

CUCM IP is 10.161.249.18, CUBE IP Address is 10.161.244.146, then IP Phone has an IP of 10.169.31.37.

 

Appreciate if you can help us with this issue. Have you experienced this kind of issue? 

 

Thank you.

 

6 Replies 6

Georgios Fotiadis
VIP Alumni
VIP Alumni

Please open "debug ccsip messages" at CUBE and make the call again. Then, provide the output (as a separate file).

Georgios
Please rate if you find this helpful.

Hi Georgios,

 

Thank you very much for your response. We don't have an access from the CUBE, other team of the customer is the one who handles it. However, they also made some test call and provide this output. Kindly see attached file.

 

They said that "They found ACK to the GDS Gateways 200 OK w/ SDP, your ACK is missing SDP

thus the GDS gateway terminates the call from our CUCM."

 

From the logs and call flow (See below), Am I correct that CUCM sent a BYE (102) message because CUBE did not reply from the ACK(101) that CUCM have sent? Am I correct that they must send a reply to that ACK(101) sent by CUCM, something like RINGING reply or other?

busy tone callflow.jpg

 

Than you so much.

 

Hi Georgios,

 

The 2nd part of the image below is our 2nd test call also. I noticed that after CUBE sent a 200 OK w/ SDP (101 INVITE), CUCM sent ACK (101 ACK), followed by BYE (101 BYE), then followed by 503 Service Unavailable (101 INVITE). After the 503 Service Unavailable, CUBE sent a BYE (101 BYE) message. Please see image below and details of the logs.

busy tone call flow - 2nd call.jpg

200 OK w/ SDP (101 INVITE) sent by CUBE to CUCM:

50251166.002 |21:54:42.435 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.161.244.146 on port 5060 index 2 with 1151 bytes:
[315819997,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.161.249.18:5060;branch=z9hG4bK3b412f26df4f6b
From: "USER" <sip:+6322147923@10.161.249.18>;tag=103523402~32af1a14-ab35-7839-8a55-ff71e035a855-81781186
To: <sip:90013146798080@10.161.244.146>;tag=98369E8C-1803
Date: Mon, 11 Dec 2017 13:54:42 GMT
Call-ID: d5084280-a2e18e22-21b050-12f9a10a@10.161.249.18
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:+13146798080@10.161.244.146>;party=called;screen=no;privacy=off
Contact: <sip:90013146798080@10.161.244.146:5060;transport=tcp>
Supported: replaces
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Session-Expires: 1800;refresher=uas
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 269
v=0
o=CiscoSystemsSIP-GW-UserAgent 6113 68 IN IP4 10.161.244.146
s=SIP Call
c=IN IP4 10.97.46.91
t=0 0
m=audio 23132 RTP/AVP 0 101 19
c=IN IP4 10.97.46.91
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20


Timestamp: 3595874082435
UTC Timestamp:3595845282435
Source Filename: SDL004_100_000926.txt.gz

 

ACK (101 ACK) send by CUCM to CUBE:

50251262.001 |21:54:42.442 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.161.244.146 on port 5060 index 2
[315819998,NET]
ACK sip:90013146798080@10.161.244.146:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.161.249.18:5060;branch=z9hG4bK3b41304834aae9
From: "USER" <sip:+6322147923@10.161.249.18>;tag=103523402~32af1a14-ab35-7839-8a55-ff71e035a855-81781186
To: <sip:90013146798080@10.161.244.146>;tag=98369E8C-1803
Date: Mon, 11 Dec 2017 13:54:42 GMT
Call-ID: d5084280-a2e18e22-21b050-12f9a10a@10.161.249.18
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Length: 0

 

Timestamp: 3595874082442
UTC Timestamp:3595845282442
Source Filename: SDL004_100_000926.txt.gz

 

BYE (102 BYE) sent by CUCM to CUBE:

50251263.001 |21:54:42.442 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.161.244.146 on port 5060 index 2
[315819999,NET]
BYE sip:90013146798080@10.161.244.146:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.161.249.18:5060;branch=z9hG4bK3b413123deaa62
From: "USER" <sip:+6322147923@10.161.249.18>;tag=103523402~32af1a14-ab35-7839-8a55-ff71e035a855-81781186
To: <sip:90013146798080@10.161.244.146>;tag=98369E8C-1803
Date: Mon, 11 Dec 2017 13:54:42 GMT
Call-ID: d5084280-a2e18e22-21b050-12f9a10a@10.161.249.18
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
P-Asserted-Identity: "USER" <sip:+6322147923@10.161.249.18>
CSeq: 102 BYE
Reason: Q.850;cause=47
Content-Length: 0

 

Timestamp: 3595874082442
UTC Timestamp:3595845282442
Source Filename: SDL004_100_000926.txt.gz

 

503 Service Unavailable (101 INVITE):

50251274.001 |21:54:42.442 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.169.31.37 on port 50808 index 446925
[315820000,NET]
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 10.169.31.37:50808;branch=z9hG4bK3eb82875
From: "USER" <sip:+6322147923@10.161.249.18>;tag=84b517af2be6729a4ff9e213-743e6088
To: <sip:9@10.161.249.18>;tag=103523345~32af1a14-ab35-7839-8a55-ff71e035a855-81781185
Date: Mon, 11 Dec 2017 13:54:38 GMT
Call-ID: 84b517af-2be6013e-38a9957c-12607d97@10.169.31.37
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=47
Server: Cisco-CUCM10.5
Remote-Party-ID: <sip:90013146798080@10.161.249.18;user=phone>;party=x-cisco-original-called;privacy=off
Content-Length: 0

 

Timestamp: 3595874082442
UTC Timestamp:3595845282442
Source Filename: SDL004_100_000926.txt.gz

 

Can you check the Regions in the Device Pools of the IP Phone placing the call and the SIP Trunk?

Make sure G711 is allowed between these two Regions.

Georgios
Please rate if you find this helpful.

Hi Georgios,

 

Do we need to change the codec between the region of IP Phone and SIP Trunk (going to CUBE)?  Currently the codec they are using is G729.

 

Thank you.

Yes, can you change that to G711? Make sure that nothing else brakes; i.e. those Regions are not used somewhere else in your configuration and G729 is wanted there.

Georgios
Please rate if you find this helpful.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: