Не получается подключить АТС по SIP-транку

[censor]

Доброго времени суток!
Не работает входящая и исходящая связь. При входящем звонке слышны гудки «занято», при исходящем звонке длинный гудок, при это я делал вызов на номер 105, Ваш тестовый, и всё работает корректно. Связывали Ваш сервис с нашей станцией Mitel – регистрация пройдена о чём говорит список подключенных устройств в личном кабинете.

При просмотре трейсов при исходящем вызове со станции на городской вот что видно в трейсе:

2012-07-06 17:36:38 SSP STS->Network Level = 3 Unique Id = 0
INVITE sip:74959742274@sip.comtube.ru:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1518524144-328690662
Route: <sip:10.25.187.49:5060;transport=udp;lr>,<sip:sip.comtube.ru:5060;transport=udp;lr>
Max-Forwards: 26
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Supported: timer,replaces
From: "701186" <sip:701186@10.25.187.45>;tag=0_1518524144-328690663
To: <sip:74959742274@sip.comtube.ru>
Call-ID: 1518524144-328690661
CSeq: 1 INVITE
Min-SE: 90
Session-Expires: 90;Refresher=uas
Contact: "701186" <sip:701186@10.25.187.45:5060;transport=udp>
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 11.0.1.26
Content-Length: 244

v=0
o=- 5200 5200 IN IP4 10.25.187.62
s=-
c=IN IP4 10.25.187.62
t=0 0
m=audio 30152 RTP/AVP 8 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-mitel-dtmf-type: std mitel inband


2012-07-06 17:36:38 SSP Network->STS Level = 3 Unique Id = 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1518524144-328690662
To: <sip:74959742274@sip.comtube.ru>
From: "701186" <sip:701186@10.25.187.45>;tag=0_1518524144-328690663
Call-ID: 1518524144-328690661
CSeq: 1 INVITE
Date: Fri, 06 Jul 2012 13:36:38 GMT
User-Agent: Mitel Border GW/4.3.0.15
Content-Length: 0



2012-07-06 17:36:38 SSP SSP->App Level = 3 Unique Id = 0
Event Type : CallInProgress
Call Object Id : 205
Session Id : 0x3165bc70, Application ID : 3, Unique ID : 0UA :
Request Type : 0
Reason Cause: 0
Reason Phrase :

Privacy : UndefinedType
Preferred Identity :
Reliable Provisional Response : NO
From Change : 0
Response Code : 100
Update?: 0 Subscribe?: 0


2012-07-06 17:36:38 SSP Network->STS Level = 3 Unique Id = 0
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1518524144-328690662
Record-Route: <sip:10.25.187.49:5060>
To: <sip:74959742274@sip.comtube.ru>;tag=e385ad108f5b4309bab3920a9fd91355.7c16
From: "701186" <sip:701186@10.25.187.45>;tag=0_1518524144-328690663
Call-ID: 1518524144-328690661
CSeq: 1 INVITE
Date: Fri, 06 Jul 2012 13:36:38 GMT
User-Agent: Mitel Border GW/4.3.0.15
Content-Length: 0



2012-07-06 17:36:38 SSP SSP->App Level = 3 Unique Id = 0

Event Type : ClientErrResp
Call Object Id : 205
Session Id : 0x3165bc70, Application ID : 3, Unique ID : 0UA :
Request Type : 6
Reason Cause: 0
Reason Phrase :
Response Code : 403
Warning Code : 0 Warning Text :
Authentication Indicator : UndefinedTypeSecAgree Indicator : SecAgreeNoneSecurity Indicator : SecurityNone100rel Indicator : 100relNone
Min-Expires: 0Count: 0

[censor]

Если сделать вызов на тест 105 то вот что видно в трейсе:

2012-07-06 17:42:41 SSP STS->Network Level = 3 Unique Id = 0
INVITE sip:105@sip.comtube.ru:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1882084144-328690727
Route: <sip:10.25.187.49:5060;transport=udp;lr>,<sip:sip.comtube.ru:5060;transport=udp;lr>
Max-Forwards: 26
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Supported: timer,replaces
From: "701186" <sip:701186@10.25.187.45>;tag=0_1882084144-328690728
To: <sip:105@sip.comtube.ru>
Call-ID: 1882084144-328690726
CSeq: 1 INVITE
Min-SE: 90
Session-Expires: 90;Refresher=uas
Contact: "701186" <sip:701186@10.25.187.45:5060;transport=udp>
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 11.0.1.26
Content-Length: 244

v=0
o=- 8200 8200 IN IP4 10.25.187.62
s=-
c=IN IP4 10.25.187.62
t=0 0
m=audio 30164 RTP/AVP 8 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-mitel-dtmf-type: std mitel inband


2012-07-06 17:42:41 SSP Network->STS Level = 3 Unique Id = 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1882084144-328690727
To: <sip:105@sip.comtube.ru>
From: "701186" <sip:701186@10.25.187.45>;tag=0_1882084144-328690728
Call-ID: 1882084144-328690726
CSeq: 1 INVITE
Date: Fri, 06 Jul 2012 13:42:42 GMT
User-Agent: Mitel Border GW/4.3.0.15
Content-Length: 0



2012-07-06 17:42:41 SSP SSP->App Level = 3 Unique Id = 0
Event Type : CallInProgress
Call Object Id : 228
Session Id : 0x3165cd08, Application ID : 3, Unique ID : 0UA :
Request Type : 0
Reason Cause: 0
Reason Phrase :

Privacy : UndefinedType
Preferred Identity :
Reliable Provisional Response : NO
From Change : 0
Response Code : 100
Update?: 0 Subscribe?: 0


2012-07-06 17:42:41 SSP Network->STS Level = 3 Unique Id = 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.25.187.45:5060;branch=z9hG4bK1882084144-328690727
Record-Route: <sip:10.25.187.49:5060>
Contact: "701186" <sip:701186@10.25.187.49:5060;transport=UDP>
To: <sip:105@sip.comtube.ru>;tag=F17A30303530393200027286
From: "701186" <sip:701186@10.25.187.45>;tag=0_1882084144-328690728
Call-ID: 1882084144-328690726
CSeq: 1 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY
Content-Type: application/sdp
Date: Fri, 06 Jul 2012 13:42:43 GMT
User-Agent: Mitel Border GW/4.3.0.15
Content-Length: 177

v=0
o=tb640 5 1 IN IP4 10.25.187.49
s=-
c=IN IP4 10.25.187.49
t=0 0
m=audio 20230 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=nortpproxy:yes


2012-07-06 17:42:41 SSP SSP->App Level = 3 Unique Id = 0
Event Type : AcceptRequest
Call Object Id : 228
Session Id : 0x3165cd08, Application ID : 3, Unique ID : 0UA :
Content Type : application/sdp
Disposition :
Encoding :
Language :
Length : 177
v=0
o=tb640 5 1 IN IP4 10.25.187.49
s=-
c=IN IP4 10.25.187.49
t=0 0
m=audio 20230 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=nortpproxy:yes

В чём может быть причина, почему станция получает Forbidden на свой запрос?

[sd]

Я полагаю, что проблема в этой строке:

Код: Выделить всё

From: "701186" <sip:701186@10.25.187.45>;tag=0_1518524144-328690663

После @ указан ваш IP адрес, а наша станция требует, чтобы там было sip.comtube.ru или sip.comtube.com.

[censor]

А почему это никак не влияет на механику тестового звонка?

[sd]

А почему это никак не влияет на механику тестового звонка?

Потому, что это наш номер, то есть вызов не уходит на сторону. В этом случае, мы не авторизуем вызов. Сделано для того, чтобы можно было принимать вызовы на наши номера от анонимов.


P.S. В следующий раз по возможности присылайте трассировку, сделанную с помощью tcpdump'а. Мне в ней проще ориентироваться, отсюда и проблему смогу быстрее найти.

[censor]

Настроил, заработала входящая и исходящая связь, спасибо! Но при звонке на виртуальный номер качество связи не очень хорошее, периодически секундная "тишина" наблюдается (причём глухая). Что можете подсказать по этому вопросу?

UPD: и задержка примерно секунда-полторы. Это можно как-нибудь поправить?

[sd]

Настроил, заработала входящая и исходящая связь, спасибо! Но при звонке на виртуальный номер качество связи не очень хорошее, периодически секундная "тишина" наблюдается (причём глухая). Что можете подсказать по этому вопросу?

UPD: и задержка примерно секунда-полторы. Это можно как-нибудь поправить?

Так, а пингануть пробовали (надо подержать минуты 2)? Какое там мин/среднее/макс время? Какой процент потерь?
А если звонить вам на 6-значный номер через номер доступа, то как связь?

[censor]

Пинги смотрел, потерь нет, время отклика 2-3ms, максимум 5 ms было - это на 315 пакетов. При этом если звонить на ваш номер (и попадать на внутренние телефоны) - то качество связи впринципе нормальное, а если звонить с наших внутренних телефонов - то провалы в голосе каждую секунду. А при звонке на мобильные номера нет голоса в обе стороны (проверял так, звонил на 8-495 и 8-800 номера - голос есть, но качество ужасное. Звонил на 8-916, тишина в трубке на обоих концах). Что можете подсказать? Настройки SDP какие-нибудь специфические например?
UDP. после проведения ряда исходящих на мобильные телефоны - выяснил что бывает соединение проходит и даже слышно без постороннего шума. Но от чего это зависит так и не удалось выяснить.

[sd]

Пинги смотрел, потерь нет, время отклика 2-3ms, максимум 5 ms было - это на 315 пакетов.

Да, пинг замечательный. Значит, вы в сети нашего провайдера. А сколько хопов? Можете их показать?

При этом если звонить на ваш номер (и попадать на внутренние телефоны) - то качество связи впринципе нормальное, а если звонить с наших внутренних телефонов - то провалы в голосе каждую секунду. А при звонке на мобильные номера нет голоса в обе стороны (проверял так, звонил на 8-495 и 8-800 номера - голос есть, но качество ужасное. Звонил на 8-916, тишина в трубке на обоих концах). Что можете подсказать? Настройки SDP какие-нибудь специфические например?

То есть, при входящих вызовах через наш номер доступа все хорошо, а при исходящих плохое?
С учетом того, что вызовы на номера +7495 и +7800 у вас проходят с плохим качеством, то явно где-то проблема при прохождении UDP трафика от вас к нам. Дело в том, что выход на указанные направления идут прямо в городскую сеть (то есть, не через интернет, а по ISDN). Тут качество должно быть замечательным, но могут быть исключения - это если номера +7495 и +7800, на которые вы звонили, виртуальные и за ними идет переадресация по SIPу уже с плохим качеством.
Попробуйте использовать не G711 кодек, а, например, G729 или GSM. В этом случае пропадание голоса будет?
У меня дома с моим Акадо проблема похожая - канал 16 мбит/с, пинг 4 мс, но при использовании кодека G711 - постоянные пропадания голоса. А вот при G729 - все отлично. А в офисе у нас провайдер подключен по радиоканалу (radio-ethernet), пинг 50 мс, но при этом G711 работает отлично. Поэтому грешу на какой-то промежуточный шлюз в Акадо, где и происходит затык.

UDP. после проведения ряда исходящих на мобильные телефоны - выяснил что бывает соединение проходит и даже слышно без постороннего шума. Но от чего это зависит так и не удалось выяснить.

Вот тут трудно сказатб, мне нужна информация о вызовах - дата/время МСК, номер телефона.

[censor]

Пинги смотрел, потерь нет, время отклика 2-3ms, максимум 5 ms было - это на 315 пакетов.

Да, пинг замечательный. Значит, вы в сети нашего провайдера. А сколько хопов? Можете их показать?

При этом если звонить на ваш номер (и попадать на внутренние телефоны) - то качество связи впринципе нормальное, а если звонить с наших внутренних телефонов - то провалы в голосе каждую секунду. А при звонке на мобильные номера нет голоса в обе стороны (проверял так, звонил на 8-495 и 8-800 номера - голос есть, но качество ужасное. Звонил на 8-916, тишина в трубке на обоих концах). Что можете подсказать? Настройки SDP какие-нибудь специфические например?

То есть, при входящих вызовах через наш номер доступа все хорошо, а при исходящих плохое?
С учетом того, что вызовы на номера +7495 и +7800 у вас проходят с плохим качеством, то явно где-то проблема при прохождении UDP трафика от вас к нам. Дело в том, что выход на указанные направления идут прямо в городскую сеть (то есть, не через интернет, а по ISDN). Тут качество должно быть замечательным, но могут быть исключения - это если номера +7495 и +7800, на которые вы звонили, виртуальные и за ними идет переадресация по SIPу уже с плохим качеством.
Попробуйте использовать не G711 кодек, а, например, G729 или GSM. В этом случае пропадание голоса будет?
У меня дома с моим Акадо проблема похожая - канал 16 мбит/с, пинг 4 мс, но при использовании кодека G711 - постоянные пропадания голоса. А вот при G729 - все отлично. А в офисе у нас провайдер подключен по радиоканалу (radio-ethernet), пинг 50 мс, но при этом G711 работает отлично. Поэтому грешу на какой-то промежуточный шлюз в Акадо, где и происходит затык.

UDP. после проведения ряда исходящих на мобильные телефоны - выяснил что бывает соединение проходит и даже слышно без постороннего шума. Но от чего это зависит так и не удалось выяснить.

Вот тут трудно сказатб, мне нужна информация о вызовах - дата/время МСК, номер телефона.

За кодеки спасибо, поковыряю станцию. А закон компандирования играет роль?
А звонки были с часу ночи до 2:30 примерно, звонил на номер 89175851010 несколько раз. Вы в логах можете посмотреть?А вот traceroute:
[root@mbg ~]# traceroute sip.comtube.ru
traceroute to sip.comtube.ru (62.117.120.98), 30 hops max, 40 byte packets
1 pc-00001.labdtk.croc.ru (10.25.187.1) 0.906 ms 0.852 ms 0.931 ms
2 c2-81-23-11-254.elastic.cloud.croc.ru (81.23.11.254) 3.549 ms 3.523 ms 3.441 ms
3 * * *
4 213.33.129.209 (213.33.129.209) 3.167 ms 3.102 ms 3.063 ms
5 194.186.178.66 (194.186.178.66) 6.117 ms 6.829 ms 6.749 ms
6 vlad-asr.comcor.ru (62.117.100.201) 3.471 ms 3.414 ms 3.373 ms
7 sip.comtube.com (62.117.120.98) 4.783 ms 3.713 ms 3.826 ms