One case of immediate fast busy

This is an issue that occurred early in Lync Pilot stage but was one inherited from the OCS 2007 R2 infrastructure.  Symptom: When a user makes a MOC/Lync call it sometimes goes to an immediate fast busy.  Common experiences from users are below:

·         Users were able to make the call on a typical desk phone immediately after failure.

·         Peers were able to call the number successfully immediately after a failure.

·         Call fails with 5 digit or 10 digit dialing.

·         Intermittent issue in all cases and  difficult or impossible to duplicate.

·         Users with OCS desk phones and headsets experienced the issue.

All client ucc logs contained the highlighted text in this excerpt:

Aug 12 14:56:53 10.1.137.98 (122-124-138) CC -APP|ACU_CLEAR_IN   |   0:61:   1#68:hungup,cause 41h=65=Bearer capability not implemented 00 00 00 00 00 00 00 00 68 41 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 ff ff 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00

Aug 12 14:56:53 10.1.137.98 (   lgr_psbrdex)(6136914   )  pstn recv <-- CALL_DISCONNECTED Trunk:0 Conn:1 RetCause:104 NetCause:65 [Time: 19:56:53]

Aug 12 14:56:53 10.1.137.98 (121-122-138) DIT-PHD|PH_IT_XMIT_IN  |   0: 0:   0|4: 00 01 01 c6

Aug 12 14:56:53 10.1.137.98 (   lgr_psbrdif)(6136915   )  Abnormal Disconnect cause:65#GWAPP_BC_NOT_IMPLEMENTED Trunk:0 Conn:1 [Time: 19:56:53]

Bearer capability not implemented can be caused by one of the following occurrences:

•You need to change the PCM Type value to the setting appropriate for your country. This is the most common cause, especially in countries where G.711 A-law companding is the standard. If your gateway is configured for µ-law and the service provider or PBX is expecting A-law, you will see calls disconnected with this cause code.

•The central office (CO) does not understand an information element in the setup message.

•You are connected to a PBX and you are sending out a network type number when the switch accepts only Unknown or National.

•You are selecting European PRI and you have the progress indicators turned on when they should be off. 

None of the above were applicable in our case.

The AudioCodes M2K gateway logs showed the following: 

Good call setup message notice the mu-law>

0:   1|40:               Q.931:  PD=8 CR=30228(0x7614,Orig) SETUP(05):                                               Bc(04):  3.1kHz-Audio/64k/mu-law                90 90 a2                                                ChanId(18):        B10/excl(PRI)     a9 83 8a                                                CallingNb(6c):                type:natl,plan:ISDN "6153340986"            a1 36 31 35 33 34 33 30 39 38 36                                   CalledNb(70):                type:unknown,plan:unknown "99475224"            80 39 39 34 37 35 32 32 34...          Hex dump: 08 02 76 14 05 04 03 90 90 a2 18 03 a9 83 8a 6c 0b a1 36 31 35 33 34 33 30 39 38 36 70 09 80 39 39 34 37 35 32 32 34 a1

Nov  1 05:40:29 10.1.137.98 (122-123-138) DLD-PHD|PH_DA_RQ       |   0: 0:   0|44:I[52,122]p0 tei=0  02 01 68 f4 08 02 76 14 05 04 03 90 90 a2 18 03 a9 83 8a 6c 0b a1 36 31 35 33 34 33 30 39 38 36 70 09 80 39 39 34 37 35 32 32 34 a1

Nov  1 05:40:29 10.1.137.98 (122-123-138) NS -MNS|MNS_EVENT_IN   |   0: 0

------------------------------------------------------------------------------------------------------------

Bad call with A-law>

0:   1|40:               Q.931:  PD=8 CR=17691(0x451b,Orig) SETUP(05):                                               Bc(04):  3.1kHz-Audio/64k/A-law                90 90 a3                                                ChanId(18):        B15/excl(PRI)     a9 83 8f                                                 CallingNb(6c):                type:natl,plan:ISDN "6158579738"            a1 36 31 35 38 37 35 39 37 33 38                                   CalledNb(70):                type:unknown,plan:unknown "92922426"            80 39 32 39 32 32 34 32 36...          Hex dump: 08 02 45 1b 05 04 03 90 90 a3 18 03 a9 83 8f 6c 0b a1 36 31 35 38 37 35 39 37 33 38 70 09 80 39 32 39 32 32 34 32 36 a1

Cause(08):          cause 41h=65=Bearer capability not implemented            81 c1 04                Hex dump: 08 02 c5 1b 45 08 03 81 c1 04

----------------------------------------------------------------------------------------------------------

Using the A-law causes the bearer capability problem and the call with fail.

Normal calls should have been using mu-law (used for North America and Japan) but on the failed immediate fast busy calls they were trying to use A-law (European coding). 

After changing a bit in the AudioCodes gateway on the outbound call to use mu-law, the failed behavior continued. 

AudiCodes Support was engaged and a firmware patch was developed for this case. 

The "Bearer capability not implemented" error has not returned since the firmware upgrade.