исходящие линии

Добрый день. Прошу направить в правильном направлении.

Есть FreePBX 2.11.

Есть три рабочих транка от одного провайдера.

Настроена исходящая маршрутизация в которой указаны эти три номера.

Проблема в том, что если первый номер занят то не происходит переключение на следующую линию а пользователь слышит линия занята, что это может быть и куда капать.

ЗЫ: для любителей посылать в ТП, ТП уже 3 недели игнорирует данный вопрос, а проблему нужно решать.

UPD: результат sip debug на внутреннем номере(через ZOIPER) с которого пытаюсь звонить

XXX.XXX.0.XXX это IP АТС

[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c:
ÿ<--- SIP read from UDP:XXX.XXX.0.33:42143 --->
ÿSUBSCRIBE sip:601@XXX.XXX.0.XXX;transport=UDP SIP/2.0
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-63f341675de23499-1---d8754z-
ÿMax-Forwards: 70
ÿContact: <sip:601@XXX.XXX.0.33:42143;transport=UDP>
ÿTo: <sip:601@XXX.XXX.0.XXX;transport=UDP>
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=6c260740
ÿCall-ID: OGQ1OWVhMjA0ZTUzMGE3NDUyNGNiZDQ5Yjg3NDY3Nzc.
ÿCSeq: 2 SUBSCRIBE
ÿExpires: 600
ÿAccept: application/watcherinfo+xml
ÿAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
ÿSupported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
ÿUser-Agent: Z 3.6.25251 r25476
ÿAuthorization: Digest username="601",realm="asterisk",nonce="2500024e",uri="sip:601@XXX.XXX.0.XXX;transport=UDP",response="e3e742c15822bf1c776004b7051bb0d0",algorithm=MD5
ÿEvent: presence.winfo
ÿAllow-Events: presence, kpml
ÿContent-Length: 0
ÿ
ÿ<------------->
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: --- (17 headers 0 lines) ---
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: Creating new subscription
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: Sending to XXX.XXX.0.33:42143 (NAT)
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: Found peer '601' for '601' from XXX.XXX.0.33:42143
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c:
ÿ<--- Transmitting (NAT) to XXX.XXX.0.33:42143 --->
ÿSIP/2.0 489 Bad Event
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-63f341675de23499-1---d8754z-;received=XXX.XXX.0.33;rport=42143
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=6c260740
ÿTo: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=as2631e083
ÿCall-ID: OGQ1OWVhMjA0ZTUzMGE3NDUyNGNiZDQ5Yjg3NDY3Nzc.
ÿCSeq: 2 SUBSCRIBE
ÿServer: FPBX-2.11.0(11.6)
ÿAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
ÿSupported: replaces, timer
ÿContent-Length: 0
ÿ
ÿ
ÿ<------------>
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: Really destroying SIP dialog 'OGQ1OWVhMjA0ZTUzMGE3NDUyNGNiZDQ5Yjg3NDY3Nzc.' Method: SUBSCRIBE
[2014-10-09 11:58:58] NOTICE[9802][C-0000201b] chan_sip.c: Call to peer '7863310XXXX' rejected due to usage limit of 1
[2014-10-09 11:58:58] WARNING[9802][C-0000201b] translate.c: no samples for ulawtolin
[2014-10-09 11:58:58] VERBOSE[9802][C-0000201b] chan_sip.c:
ÿ<--- Reliably Transmitting (NAT) to XXX.XXX.0.33:42143 --->
ÿSIP/2.0 486 Busy Here
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-4a3870a173a1d170-1---d8754z-;received=XXX.XXX.0.33;rport=42143
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=1b45b571
ÿTo: <sip:8905430XXXX@XXX.XXX.0.XXX;transport=UDP>;tag=as57552d9b
ÿCall-ID: ZjI3ZTliY2JiMjRjZmY2ZTAzYjJiN2NiZmZjM2I2OTE.
ÿCSeq: 2 INVITE
ÿServer: FPBX-2.11.0(11.6)
ÿAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
ÿSupported: replaces, timer
ÿSession-Expires: 1800;refresher=uas
ÿX-Asterisk-HangupCause: User busy
ÿX-Asterisk-HangupCauseCode: 17
ÿContent-Length: 0
ÿ
ÿ
ÿ<------------>
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c:
ÿ<--- SIP read from UDP:XXX.XXX.0.33:42143 --->
ÿACK sip:8905430XXXX@XXX.XXX.0.XXX;transport=UDP SIP/2.0
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-4a3870a173a1d170-1---d8754z-
ÿMax-Forwards: 70
ÿTo: <sip:8905430XXXX@XXX.XXX.0.XXX;transport=UDP>;tag=as57552d9b
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=1b45b571
ÿCall-ID: ZjI3ZTliY2JiMjRjZmY2ZTAzYjJiN2NiZmZjM2I2OTE.
ÿCSeq: 2 ACK
ÿContent-Length: 0
ÿ
ÿ<------------->
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: --- (8 headers 0 lines) ---
[2014-10-09 11:58:58] VERBOSE[6430] chan_sip.c: Really destroying SIP dialog 'ZjI3ZTliY2JiMjRjZmY2ZTAzYjJiN2NiZmZjM2I2OTE.' Method: ACK
[2014-10-09 11:58:59] VERBOSE[6430] chan_sip.c:
ÿ<--- SIP read from UDP:XXX.XXX.0.33:42143 --->
ÿPUBLISH sip:601@XXX.XXX.0.XXX;transport=UDP SIP/2.0
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-5ef967cbd1b13cca-1---d8754z-
ÿMax-Forwards: 70
ÿContact: <sip:601@XXX.XXX.0.33:42143;transport=UDP>
ÿTo: <sip:601@XXX.XXX.0.XXX;transport=UDP>
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=5549a604
ÿCall-ID: MzQ1MDc3ZTU3YWNhZDc3ZjgwMDU2NDllOGQzYTRhOWE.
ÿCSeq: 1 PUBLISH
ÿExpires: 600
ÿAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
ÿContent-Type: application/pidf+xml
ÿSupported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
ÿUser-Agent: Z 3.6.25251 r25476
ÿEvent: presence
ÿAllow-Events: presence, kpml
ÿContent-Length: 258
ÿ
ÿ<?xml version="1.0" encoding="UTF-8"?>
ÿ<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:601@XXX.XXX.0.XXX;transport=UDP"> <tuple id="601" > <status><basic>open</basic></status> <note>Online</note> </tuple>
ÿ</presence>
ÿ<------------->
[2014-10-09 11:58:59] VERBOSE[6430] chan_sip.c: --- (16 headers 3 lines) ---
[2014-10-09 11:58:59] VERBOSE[6430] chan_sip.c: Sending to XXX.XXX.0.33:42143 (NAT)
[2014-10-09 11:58:59] VERBOSE[6430] chan_sip.c:
ÿ<--- Transmitting (NAT) to XXX.XXX.0.33:42143 --->
ÿSIP/2.0 489 Bad Event
ÿVia: SIP/2.0/UDP XXX.XXX.0.33:42143;branch=z9hG4bK-d8754z-5ef967cbd1b13cca-1---d8754z-;received=XXX.XXX.0.33;rport=42143
ÿFrom: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=5549a604
ÿTo: <sip:601@XXX.XXX.0.XXX;transport=UDP>;tag=as577a957c
ÿCall-ID: MzQ1MDc3ZTU3YWNhZDc3ZjgwMDU2NDllOGQzYTRhOWE.
ÿCSeq: 1 PUBLISH
ÿServer: FPBX-2.11.0(11.6)
ÿAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
ÿSupported: replaces, timer
ÿContent-Length: 0

На что смотреть как я понимаю линия занята приходит от оператора. Или этот тот сигнал занято который слышит звонящий?

Настройка транков

PEER

username=310XXXX
type=friend
secret=XXXXXXXX
qualify=yes
host=188.187.XXX.XX
fromuser=7863310XXXX
fromdomain=188.187.XXX.XX
disallow=all
context=from-pstn
allow=alaw&g729
insecure=port,invite
canreinvite=yes
callerid=3100XXX
call-limit=1

USER

type=friend
registertimeout=180
qualify=yes
nat=yes
insecure=port
host=188.187.XXX.XXX
disallow=all
allow=alaw&g729
context=from-pstn

Все три настроены одинаково

Вопрос решен, спасибо Venomel(если бы ответил не в дискуссии поставил бы +), твой пост навел меня на решение, оно оказалось очень банальным в настройках транка нужно было поставить галочку в

Continue if Busy: Check to always try next trunk

и все пошло как должно быть. Большое спасибо за помощь.