[snowsam]

Hello,

We are about 15 days into our new phone system setup, using a Patton 4960 with a PRI and 3CX 10 and Yealink phones. So far, the transition has been quite positive.

At times, one of the alert emails that 3cx sends me is:

-----Original Message-----
Sent: Tuesday, July 12, 2011 1:18 PM
To: Sam Snow
Subject: 3CX Phone System Email Notification - ID 12294

(0) Doubletalk.tjsnow.local 7/12/2011 1:18:14 PM

Call to 13342866471@(Ln.10000@Patton 4960 PRI #1) has failed. [ V4 172.18.9.12:5060 UDP target domain=unspecified mFlowKey=796 ] replied: 486 Busy Here; from

IP:172.18.9.12:5060

This seems to happen when you call someone else and there is a standard busy signal on the other end pf the phone.

Instead of playing you the standard busy, you are shown the "486 Busy Here" message on your phone. Is this normal for 3cx/patton? Or is there something that can be configured to give a standard response to the user?

Thanks,
Sam



Here is the debug from 3CX:

ACK sip:13342866471@172.18.9.12:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.9.6:5060;branch=z9hG4bK-d8754z-61029020ec078a5a-1---d8754z-;rport
Max-Forwards: 70
To: <sip:13342866471@172.18.9.12:5060>;tag=2640323745
From: "Tom Snow"<sip:4233083165@172.18.9.6:5060>;tag=4228ac37
Call-ID: MGFhYjRhMjM1ODQ1YTcyMzBmYzc1MjU2YjE3ZDMzMGM.
CSeq: 1 ACK
Content-Length: 0


13:18:14.801|.\Transport.cxx(213)|Debug8|Resip|::ResipLogger:Adding message to tx buffer to: [ V4 172.18.9.12:5060 UDP target domain=172.18.9.12 mFlowKey=0 ]
13:18:14.801|.\DnsResult.cxx(206)|Debug8|Resip|::ResipLogger:Whitelisting 172.18.9.12(1): 172.18.9.12
13:18:14.801|.\dns\RRVip.cxx(129)|Debug8|Resip|::ResipLogger:updating an existing vip: 172.18.9.12 with 172.18.9.12
13:18:14.801|.\TransactionState.cxx(2112)|Debug8|Resip|::ResipLogger:Send to TU: TU: DialogUsageManager size=0

SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 172.18.9.6:5060;branch=z9hG4bK-d8754z-61029020ec078a5a-1---d8754z-;rport=5060;received=172.18.9.6
To: <sip:13342866471@172.18.9.12:5060>;tag=2640323745
From: "Tom Snow"<sip:4233083165@172.18.9.6:5060>;tag=4228ac37
Call-ID: MGFhYjRhMjM1ODQ1YTcyMzBmYzc1MjU2YjE3ZDMzMGM.
CSeq: 1 INVITE
Server: Patton SN4960 1E24V 00A0BA067FD5 R5.7 2011-05-13 H323 RBS SIP M5T SIP Stack/4.0.30.30
Content-Length: 0


13:18:14.801|.\DialogUsageManager.cxx(1333)|Trace5|Resip|::ResipLogger:Got: SipResp: 486 tid=61029020ec078a5a cseq=INVITE / 1 from(wire)
13:18:14.801|.\DialogUsageManager.cxx(1841)|Debug8|Resip|::ResipLogger:DialogUsageManager::processResponse:

SipResp: 486 tid=61029020ec078a5a cseq=INVITE / 1 from(wire)
13:18:14.801|.\UserProfile.cxx(158)|Debug8|Resip|::ResipLogger:Found credential for realm: realm=3CXPhoneSystem user=100003CXPhoneSystem
13:18:14.801|.\DialogId.cxx(50)|Debug8|Resip|::ResipLogger:DialogId::DialogId: MGFhYjRhMjM1ODQ1YTcyMzBmYzc1MjU2YjE3ZDMzMGM.-4228ac37-2640323745
13:18:14.802|.\DialogSet.cxx(484)|Debug8|Resip|::ResipLogger:Found matching dialog mClientSubscriptions(0), mServerSubscriptions(0) for

SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 172.18.9.6:5060;branch=z9hG4bK-d8754z-61029020ec078a5a-1---d8754z-;rport=5060;received=172.18.9.6
To: <sip:13342866471@172.18.9.12:5060>;tag=2640323745
From: "Tom Snow"<sip:4233083165@172.18.9.6:5060>;tag=4228ac37
Call-ID: MGFhYjRhMjM1ODQ1YTcyMzBmYzc1MjU2YjE3ZDMzMGM.
CSeq: 1 INVITE
Server: Patton SN4960 1E24V 00A0BA067FD5 R5.7 2011-05-13 H323 RBS SIP M5T SIP Stack/4.0.30.30
Content-Length: 0

and here is the debug from the patton:

Welcome!
172.18.9.12>enable
172.18.9.12#configure
172.18.9.12(cfg)#debug ccisdn error
172.18.9.12(cfg)#debug ccisdn signaling
172.18.9.12(cfg)#debug isdn error
172.18.9.12(cfg)#15:42:25 ICC > [IF_ISDN_0] Added endpoint IF_ISDN_0-00b69828
15:42:25 ICC > [IF_ISDN_0] NEW CALL. Allocated Endpoint IF_ISDN_0-00b69828
15:42:25 ICC > [EP IF_ISDN_0-00b69828] do not reroute because: no endpoint wi

th call key: YmE4NWRjZjhmZmZkN2Y3ZTAwOTNmZGFiN2U5ZTEyY2M.
15:42:25 ICC > [EP IF_ISDN_0-00b69828] AOC-S User << Call Setup
15:42:25 ICC > [EP IF_ISDN_0-00b69828] AOC-D User << Call Setup
15:42:25 ICC > [EP IF_ISDN_0-00b69828] AOC-E User << Call Setup
15:42:25 ICC > [EP IF_ISDN_0-00b69828] CNIP << Name Request
15:42:25 ICC > [EP IF_ISDN_0-00b69828] >> [080005]
SETUP (NI2 User)
[04039090A2]
Bearer capability : 3.1kHz Audio - CCITT
circuit mode - 64kBit/s - G.711 U-law
[1C139FA1100201010201008008546F6D20536E6F77]
Facility : Invoke : invokeid: 00000001
global operation
invoke {
present = 1
local = 0
argumentnamePresentationAllowedSimple = 'Tom Snow'
}
[1E028583]
Progress indicator : origination address is non-ISDN
private network serving remote user - CCITT
[6C0C008034323333303833313635]
Calling party number : 4233083165
unknown number - unknown numbering plan
presentation allowed - user provided not screened
[700C803133333432383636343731]
Called party number : 13342866471
unknown number - unknown numbering plan

15:42:25 ICC > [EP IF_ISDN_0-00b69828] Set state to CALL INITIATED
15:42:25 ICC > [EP IF_ISDN_0-00b69828] State: CALL INITIATED, Event: PEER CON

NECTED
15:42:25 ICC > [EP IF_ISDN_0-00b69828] Hold State: IDLE, Hold Event: PEER CON

NECTED
15:42:25 ICC > [IF_ISDN_0] << Message: primitive=43
15:42:25 ICC > [EP IF_ISDN_0-00b69828] << [080002]
CALL PROCEEDING (NI2 User)
[1803A98381]
Channel id : 1 - exclusive
other interface - is not d-channel - CCITT - b-channel units

15:42:25 ICC > [EP IF_ISDN_0-00b69828] State: CALL INITIATED, Event: TERMINAL

PROCEEDING IND
15:42:25 ICC > [EP IF_ISDN_0-00b69828] Set state to OUTGOING PROCEEDING
15:42:26 ICC > [IF_ISDN_0] << Message: primitive=34
15:42:26 ICC > [EP IF_ISDN_0-00b69828] << [080045]
DISCONNECT (NI2 User)
[08028491]
Cause : user busy
public network serving remote user - CCITT - Q.931

15:42:26 ICC > [EP IF_ISDN_0-00b69828] State: OUTGOING PROCEEDING, Event: TER

MINAL DISCONNECT IND
15:42:26 ICC > [EP IF_ISDN_0-00b69828] Set state to DISCONNECT INDICATION
15:42:26 ICC > [EP IF_ISDN_0-00b69828] Hold State: IDLE, Hold Event: PEER REL

EASED
15:42:26 ICC > [EP IF_ISDN_0-00b69828] State: DISCONNECT INDICATION, Event: P

EER RELEASED
15:42:26 ICC > [EP IF_ISDN_0-00b69828] Set state to RELEASE REQUEST
15:42:26 ICC > [EP IF_ISDN_0-00b69828] AOC-S User << Call Clearing
15:42:26 ICC > [EP IF_ISDN_0-00b69828] AOC-D User << Call Clearing
15:42:26 ICC > [EP IF_ISDN_0-00b69828] AOC-E User << Call Clearing
15:42:26 ICC > [EP IF_ISDN_0-00b69828] >> [08004D]
RELEASE (NI2 User)

15:42:26 ICC > [IF_ISDN_0] << Message: primitive=48
15:42:26 ICC > [EP IF_ISDN_0-00b69828] << [08005A]
RELEASE COMPLETE (NI2 User)

15:42:26 ICC > [EP IF_ISDN_0-00b69828] State: RELEASE REQUEST, Event: TERMINA

L RELEASE CONF
15:42:26 ICC > [EP IF_ISDN_0-00b69828] Set state to NULL
15:42:26 ICC > [IF_ISDN_0] CLEARING CALL IF_ISDN_0-00b69828
15:42:26 ICC > [IF_ISDN_0] Removed endpoint IF_ISDN_0-00b69828
15:42:26 ICC > [IF_ISDN_0] Destroying finished calls.
15:42:26 ICC > [IF_ISDN_0] Destroyed endpoint IF_ISDN_0-00b69828

edit: title updated

[willow]

This is probably how the phone is programmed to handle this message, I would suggest logging into the web portal of the phone and checking and seeing if there is a setting that can change this behavior.

[snowsam]

I don't think it is the phone, since I am getting the first "3CX Phone System Email Notification" email straight from 3CX. I think it is something about how the Patton and 3CX talk each other and deal with this busy condition.

Anyone else seen this?

[Raf Wenger]

I am experiencing the same problem, our Yealink T22 phones displaying a 'Busy Here' error message instead of playing a busy tune when calling a busy phone.
3CX is emailing the error right away.
I could not find anything on the Yealink web GUI to modify this behaviour.

We're using a VOIP provider, so no Patton gateway for us, but same problem.

Anyone?

[snowsam]

OK, I changed the posting title to reflect that we now think this is a yealink issue and not an issue coming from the Patton side.

Anyone have any more ideas?

We are using Yealink T22P, 26P, 28P phones with the most recent (Jun.23 2011) firmwares.

My biggest challenge in troubleshooting the problem is finding a phone number that I can call that will give me a busy signal every time!!

[snowsam]

I've gotten confirmation from 3CX support that the "486 busy here" messages are normal.

In order to no longer receive the alert email every time someone dials, go to the following path:
3CX Phone System > Settings > Advanced > Custom Parameters

Search for RESPONSE_ERROR_CODES and remove the 486 from the Value field.

I hope that helps other people!