Не работают исходящие Elastix

[jacuba]

Добрый день, использую elastix 2.4
астер выступает в качестве прокси для АТС провайдера. То есть короткие номера на АТС провайдера я подключаю, как внешние транки на астериске.
На астере были зарегистрированы 10 номеров от провайдера, сейчас закупили еще 5, хочу подключить их по такой же схеме.

Когда делаю все настройки, как в уже рабочих транках и пытаюсь позвонить, используя новый номер, то АТС провайдера меня посылает, хотя если этот же номер зарегистрировать в каком-нибудь софт-фоне, то звонить с него можно.

sip show peers показывает, что номер зарегистрирован.

Вот звонок с рабочего транка:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

INVITE sip:8922363ХХХХ@192.168.0.222 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.25:5060;branch=z9hG4bK-fc5f8727
From: 126 <sip:126@192.168.0.222>;tag=13ec7de1b61ca517o0
To: <sip:8922363ХХХХ@192.168.0.222>
Remote-Party-ID: 126 <sip:126@192.168.0.222>;screen=yes;party=calling
Call-ID: d4463d29-d838ae6f@192.168.0.25
CSeq: 101 INVITE
Max-Forwards: 70
Contact: 126 <sip:126@192.168.0.25:5060>
Expires: 240
User-Agent: Linksys/SPA2102-3.3.6
Content-Length: 446
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura
Content-Type: application/sdp

А вот с нерабочего:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

<--- SIP read from UDP:192.168.0.114:5060 --->
INVITE sip:8922363ХХХХ@192.168.0.222 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.114;branch=z9hG4bKc0a800720000004f53f585a8000026470000001f;rport
From: "unknown" <sip:300@192.168.0.222>;tag=1a8b6ce9c4
To: <sip:8922363ХХХХ@192.168.0.222>
Contact: <sip:300@192.168.0.114>
Call-ID: 2895E020CC2F47F68170FF3D94E01F350xc0a80072
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 368
Content-Type: application/sdp
Supported: replaces,norefersub,timer

Может ли АТС провайдера меня посылать, если в поле FROM стоит "unknown"? (во втором примере)

Так же, когда меня отбивает АТС провайдера в консоле появляется надпись:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

NoOp("SIP/300-00001e71", "Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 21") in new stack
-- Executing [s@macro-dialout-trunk:21] Goto("SIP/300-00001e71", "s-BUSY,1") in new stack
-- Goto (macro-dialout-trunk,s-BUSY,1)
-- Executing [s-BUSY@macro-dialout-trunk:1] NoOp("SIP/300-00001e71", "Dial failed due to trunk reporting BUSY - giving up") in new stack
-- Executing [s-BUSY@macro-dialout-trunk:2] PlayTones("SIP/300-00001e71", "busy") in new stack
-- Executing [s-BUSY@macro-dialout-trunk:3] Busy("SIP/300-00001e71", "20") in new stack

По какой причине может такое получаться?

[ded]

Пройдите по схеме:

Провайдер может отбивать из-за неправильного From
Cause No. 21 - call rejected.
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.

[jacuba]

Набор номера назначения верный,
Как проверить формат исходящего номера?

Набираю свой номер, звонок уходит в транк, но после этого "отлуп" от провайдера.

Правильно ли я понимаю, что под инвайтом понимается следующая строка:
INVITE sip:8922363ХХХХ@188.187.255.6 SIP/2.0

После этой строки идут следующие
SIP/2.0 100 Trying
SIP/2.0 180 Ringing
SIP/2.0 603 Disconnect code from RADIUS

Поле FROM уже определяется нормально

[ded]

Как проверить формат исходящего номера?
Вставить проверку
NoOp(Caller ID = ${CALLERID(all)})
За остальным - обращайтесь к провайдеру. Он вам даёт отлуп 21

This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.

Судя по вашим строчкам - там ещё и Radius!

[Vlad1983]

From: "unknown" <sip:300@192.168.0.222>;tag=1a8b6ce9c4
вот там должен быть ваш номер в нужном оператору формате

[jacuba]

Проблема, действительно, оказалась в провайдере. Звонил им до обращения сюда, сказали, что всё ок на их стороне, позвонил им после обращения сюда, сказали, что проблема действительно есть и исправили её.
Спасибо, всем ответившим.