cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6865
Views
0
Helpful
1
Replies

Re: CUCM Sends BYE "Reason: Q.850; cause=47"

carlos_y_lopez
Level 1
Level 1

Hello,

We support several contact centers and we have quite a few of Failed Transfers from our IVR to the Agents using Cisco IP Communicator.

We see that this error of Q 850;cause=47 on all of these failed transfers, however the problem occurs intermittently.

The agents are for the most part able to answer calls but every now and then, they cannot and the traces show this same error.

If this was caused by a codec mismatch - shouldn't all the calls fails all the time?

Why does the problem occur intermittently?

Sample of the error below:

INVITE sip:3120071234@10.xx.xx.xx:5060 SIP/2.0
Via: SIP/2.0/UDP 10.xx.xx.xx;rport;branch=z9hG4bK07K9r711mBHpa
Max-Forwards: 70
From: "2178726368" <sip:2178726368@10.xx.xx.xx>;tag=568XQmcX9H4Ug
To: <sip:3120071234@10.xx.xx.xx:5060>
Call-ID: 2cba5015-9ce5-1236-33ab-afa51587d093
CSeq: 119890382 INVITE
Contact: <sip:mod_sofia@10.xx.xx.xx:5060>
User-Agent: FreeSWITCH-mod_sofia/1.4.14~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 270
X-FS-Support: update_display,send_info
Remote-Party-ID: "2178726368" <sip:2178726368@10.xx.xx.xx>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1520427640 1520427641 IN IP4 10.xx.xx.xx
s=FreeSWITCH
c=IN IP4 10.xx.xx.xx
t=0 0
m=audio 25252 RTP/AVP 0 8 3 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.xx.xx.xx;rport;branch=z9hG4bK07K9r711mBHpa
From: "2178726368" <sip:2178726368@10.xx.xx.xx>;tag=568XQmcX9H4Ug
To: <sip:3120071234@10.xx.xx.xx:5060>
Date: Wed, 07 Mar 2018 20:01:33 GMT
Call-ID: 2cba5015-9ce5-1236-33ab-afa51587d093
CSeq: 119890382 INVITE
Allow-Events: presence
Content-Length: 0


SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.xx.xx.xx;rport;branch=z9hG4bK07K9r711mBHpa
From: "2178726368" <sip:2178726368@10.xx.xx.xx>;tag=568XQmcX9H4Ug
To: <sip:3120071234@10.xx.xx.xx:5060>;tag=4384558~768947d5-0088-4cb8-84fe-d58eabc723ab-39501555
Date: Wed, 07 Mar 2018 20:01:33 GMT
Call-ID: 2cba5015-9ce5-1236-33ab-afa51587d093
CSeq: 119890382 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: "CCE9_Agent-PDN" <sip:3120071234@10.xx.xx.xx>
Remote-Party-ID: "CCE9_Agent-PDN" <sip:3120071234@10.xx.xx.xx>;party=called;screen=yes;privacy=off
Contact: <sip:3120071234@10.xx.xx.xx:5060>
Content-Length: 0


SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.xx.xx.xx;rport;branch=z9hG4bK07K9r711mBHpa
From: "2178726368" <sip:2178726368@10.xx.xx.xx>;tag=568XQmcX9H4Ug
To: <sip:3120071234@10.xx.xx.xx:5060>;tag=4384558~768947d5-0088-4cb8-84fe-d58eabc723ab-39501555
Date: Wed, 07 Mar 2018 20:01:33 GMT
Call-ID: 2cba5015-9ce5-1236-33ab-afa51587d093
CSeq: 119890382 INVITE
Allow-Events: presence
Reason: Q.850;cause=47
Server: Cisco-CUCM10.5
Content-Length: 0


ACK sip:3120071234@10.xx.xx.xx:5060 SIP/2.0
Via: SIP/2.0/UDP 10.xx.xx.xx;rport;branch=z9hG4bK07K9r711mBHpa
Max-Forwards: 70
From: "2178726368" <sip:2178726368@10.xx.xx.xx>;tag=568XQmcX9H4Ug
To: <sip:3120071234@10.xx.xx.xx:5060>;tag=4384558~768947d5-0088-4cb8-84fe-d58eabc723ab-39501555
Call-ID: 2cba5015-9ce5-1236-33ab-afa51587d093
CSeq: 119890382 ACK
Content-Length: 0

1 Reply 1

dstaudt
Cisco Employee
Cisco Employee

(Creating a new conversation for this question)

Q.850 cause=47 references a general 'resource unavailable' situation - some resource in the system is unavailable/exhausted at the time.  As this is happening at answer time, it's very likely due to running out of transcoding resources (codec mismatch), MTPs for DTMF-translation, or some similar issue.

You (likely with the help of TAC) may need to look into the CUCM logs to understand exactly what resource is running out, so you can steps to avoid.