Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Односторонняя слышимость. Исходящие на моб.Билайн. Провайдер Вымпелком.
АРТКОМ Форум > Форумы для специалистов > Техническая поддержка iPECS-MG & iPECS-eMG800
Scroudge
Добрый день.

имеем:
ipecs-mg 192.168.90.18
voib8 192.168.90.20
локальн.IP роутера 192.168.90.1
внешний.IP 192.168.92.18
шлюз провайдера 192.168.92.17
проброс портов
1720 TCP 192.168.90.18 всем H.323
5588 UDP 192.168.90.18 всем IPKTS_Phontage
7000-7015 UDP 192.168.90.18 всем VOIU
7500-7599 UDP 192.168.90.20 всем VOIB8
5060 TCP и UDP 192.168.90.18 всем SIP

версии ПО:
iPECS-MG/GS55MxB.5Dg MAY/15
Boot Version-1.1Ab AUG/11
OS Version-1.1Ad MAY/13
прошивки всех плат - последние.

наблюдаем:
при исходящем на Билайн нет звука на стороне абонента АТС (вызывающая сторона)
звоним на других - всё нормально..
прилагаю сниф ..
в снифе голос вроде есть с обеих сторон..
при разборе всё что нашёл из отличий (с нормальным звонком):

в 2015 году была похожая проблема.
тогда не проходили звонки с мтс.
вот часть переписки с техподдержкой провайдера (2015 год):
RAD> Я знаком с Вашей ситуацией.
RAD> Проблема, действительно, похоже в услуге MLPP, которая из сети МТС
RAD> прозрачно транслируется в SIP в виде поля
RAD> Resource-Priority: q735.4 в Message Header сообщения Invite.
RAD> Ваша АТС по какой то причине "не кушает" это сообщение.
RAD> Попытаюсь настроить SIP Profile конкретно под Вас, с изменением
RAD> заголовков SIP. Получится или нет, пока сказать не могу.
RAD> Большая просьба, параллельно посмотреть, что можно сделать у вас на АТС.
.................

тогда проблема решилась новой версией прошивки атс.
сейчас шить нечем (всё самое новое зашито).
провайдер говорит что на его участке всё норм.
действительно, в снифе голос с обеих сторон.

по сегодняшней ситуации..
сравнивал снифы увидел такие отличия с нормальным звонком:
в инвайте нашел поля, которых нет в нормальном снифе.
это поля:
Organization: Iskratel
User-Agent: SI3000

кроме того, видим, что номер там вместо 89635510003
имеет вид 8107963551003

имеет ли это значение - не знаю..

сниф прилагаю.
конфиг станции тоже.
логин: 1
пароль: 1

Пожалуйста, помогите разобраться..
Dron
Цитата(Scroudge @ 21.3.2018, 15:12) *
Добрый день.

имеем:
ipecs-mg 192.168.90.18
voib8 192.168.90.18
локальн.IP роутера 192.168.90.1
внешний.IP 192.168.92.18
шлюз провайдера 192.168.92.17
проброс портов
1720 TCP 192.168.90.18 всем H.323
5588 UDP 192.168.90.18 всем IPKTS_Phontage
7000-7015 UDP 192.168.90.18 всем VOIU
7500-7599 UDP 192.168.90.20 всем VOIB8
5060 TCP и UDP 192.168.90.18 всем SIP

версии ПО:
iPECS-MG/GS55MxB.5Dg MAY/15
Boot Version-1.1Ab AUG/11
OS Version-1.1Ad MAY/13
прошивки всех плат - последние.

наблюдаем:
при исходящем на Билайн нет звука на стороне абонента АТС (вызывающая сторона)
звоним на других - всё нормально..
прилагаю сниф ..
в снифе голос вроде есть с обеих сторон..
при разборе всё что нашёл из отличий (с нормальным звонком):

в 2015 году была похожая проблема.
тогда не проходили звонки с мтс.
вот часть переписки с техподдержкой провайдера (2015 год):
RAD> Я знаком с Вашей ситуацией.
RAD> Проблема, действительно, похоже в услуге MLPP, которая из сети МТС
RAD> прозрачно транслируется в SIP в виде поля
RAD> Resource-Priority: q735.4 в Message Header сообщения Invite.
RAD> Ваша АТС по какой то причине "не кушает" это сообщение.
RAD> Попытаюсь настроить SIP Profile конкретно под Вас, с изменением
RAD> заголовков SIP. Получится или нет, пока сказать не могу.
RAD> Большая просьба, параллельно посмотреть, что можно сделать у вас на АТС.
.................

тогда проблема решилась новой версией прошивки атс.
сейчас шить нечем (всё самое новое зашито).
провайдер говорит что на его участке всё норм.
действительно, в снифе голос с обеих сторон.

по сегодняшней ситуации..
сравнивал снифы увидел такие отличия с нормальным звонком:
в инвайте нашел поля, которых нет в нормальном снифе.
это поля:
Organization: Iskratel
User-Agent: SI3000

кроме того, видим, что номер там вместо 89635510003
имеет вид 8107963551003

имеет ли это значение - не знаю..

сниф прилагаю.
конфиг станции тоже.
логин: 1
пароль: 1

Пожалуйста, помогите разобраться..

При вызове абонента Билайн провом для голоса указан адрес 10.208.76.16. Вот на него АТС должна слать RTP. Но в снифе не видно никаких пакетов ни с этого адреса, ни на него. Там файрволом у вас он не заблокирован ли?
Scroudge
Цитата(Dron @ 21.3.2018, 16:42) *
При вызове абонента Билайн провом для голоса указан адрес 10.208.76.16. Вот на него АТС должна слать RTP. Но в снифе не видно никаких пакетов ни с этого адреса, ни на него. Там файрволом у вас он не заблокирован ли?


ничего не заблокировано. пинги нормально идут..
Dron
Цитата(Scroudge @ 21.3.2018, 16:04) *
ничего не заблокировано. пинги нормально идут..

Пинговали с АТС?
Scroudge
Цитата(Dron @ 21.3.2018, 17:07) *
Пинговали с АТС?


есссно
Ping Test IP Address is 10.208.76.16 and Timeout is 5

Ping Result is Success


прошу также обратить внимание на текст в первом посте касаемо инвайтов.
Dron
Цитата(Scroudge @ 21.3.2018, 16:11) *
есссно
Ping Test IP Address is 10.208.76.16 and Timeout is 5

Ping Result is Success


прошу также обратить внимание на текст в первом посте касаемо инвайтов.

Дык, нет RTP пакетов и с адреса 10.208.76.16. Уточним, кто кого не слышит? Абонент АТС вызываемого, вызываемый абонента АТС или никто никого не слышит?
Но, смущает, что нет никаких пакетов с этого адреса. А пров то шлет , вообще, с него что то?
Scroudge
Цитата(Dron @ 21.3.2018, 17:23) *
Дык, нет RTP пакетов и с адреса 10.208.76.16. Уточним, кто кого не слышит? Абонент АТС вызываемого, вызываемый абонента АТС или никто никого не слышит?
Но, смущает, что нет никаких пакетов с этого адреса. А пров то шлет , вообще, с него что то?


1) не слышат на стороне АТС.
2) на стороне вызываемого абонента - всё слышно
3) при вызове с мобильного на АТС - слышно и там, и там.

последний вопрос не понял.
ещё раз намекаю на поля в заголовках инвайтов...
Dron
Цитата(Scroudge @ 21.3.2018, 16:26) *
1) не слышат на стороне АТС.
2) на стороне вызываемого абонента - всё слышно
3) при вызове с мобильного на АТС - слышно и там, и там.

последний вопрос не понял.
ещё раз намекаю на поля в заголовках инвайтов...

Прикольно, а сейчас вдруг в снифе все увидел...
Т.е., в снифе, в общем то, все так же, как и при вызове другого номера. За исключением этого вот адреса.
Scroudge
Цитата(Dron @ 21.3.2018, 17:29) *
Прикольно, а сейчас вдруг в снифе все увидел...
Т.е., в снифе, в общем то, все так же, как и при вызове другого номера. За исключением этого вот адреса.


не из той же оперы?
http://www.artcom.ru/forum/?showtopic=12326
Dron
Цитата(Scroudge @ 21.3.2018, 16:26) *
ещё раз намекаю на поля в заголовках инвайтов...

Вы про contact? Кстати, что указано для Contact Number в SIP CO User ID Table(373)? Я никогда не трогаю и оставляю значение по-умолчанию User ID.
Dron
Цитата(Scroudge @ 21.3.2018, 16:33) *
не из той же оперы?
http://www.artcom.ru/forum/?showtopic=12326

Думаю, что нет. Вызовы ж обрабатываются. И, кстати, все же RTP пакеты в снифе присутствуют.
Scroudge
Цитата(Dron @ 21.3.2018, 17:37) *
Вы про contact? Кстати, что указано для Contact Number в SIP CO User ID Table(373)? Я никогда не трогаю и оставляю значение по-умолчанию User ID.


1) я про:
Organization: Iskratel
User-Agent: SI3000

кроме того, видим, что номер там вместо 89635510003
имеет вид 8107963551003

2) пробовал без них.. (373 userid) аналогично..
Scroudge
Цитата(Dron @ 21.3.2018, 17:39) *
Думаю, что нет. Вызовы ж обрабатываются. И, кстати, все же RTP пакеты в снифе присутствуют.


Что делать-то, товарищ майор?
все перепробовал.
и iclid разными способами посылать (кстати видно, что нормально всё уходит)
и разные порты voip использовать (c mpb и с voib8)
ничего не помогает..
повторюсь. на мтс звоним когда - то нормально всё.
проблема с билайном
и отличия в инвайтах уже уши прожужжал..
Dron
Цитата(Scroudge @ 21.3.2018, 16:43) *
1) я про:
Organization: Iskratel
User-Agent: SI3000

кроме того, видим, что номер там вместо 89635510003
имеет вид 8107963551003

2) пробовал без них.. (373 userid) аналогично..

Да, что то туплю! Тут, знаете ли, и своими делами голова забита...
Вызов несколько иначе, походу, обрабатывается. От прова инвайт приходит в обратку. В нем contact: 8107963551003. Т.е., этот же номер 89635510003, только вместо 8 имеем 8107.
Dron
Цитата(Dron @ 21.3.2018, 16:58) *
Да, что то туплю! Вызов несколько иначе, походу, обрабатывается. От прова инвайт приходит в обратку. В нем contact: 8107963551003. Т.е., это то же номер 89635510003, только вместо 8 имеем 8107.

А попробовать включить Connect RTP when Receive REINVITE в SIP CO Additional Regist.(371)?
Scroudge
Цитата(Dron @ 21.3.2018, 18:00) *
А попробовать включить Connect RTP when Receive REINVITE в SIP CO Additional Regist.(371)?


спасибо, добрый человек!

на всякий случай, попробовал с вариантами без авторизации и с авторизацией,
а также с разными вариантами посылки iclid.
всё нормально работает с включённым Connect RTP when Receive REINVITE.
Scroudge
Цитата(Dron @ 21.3.2018, 18:00) *
А попробовать включить Connect RTP when Receive REINVITE в SIP CO Additional Regist.(371)?


новое научное открытие...
если для выхода используем порты MPB - слышимость односторонняя даже с этим флагом.
на VOIB8 - всё нормально.
с отключенным флагом на voib8 тоже - односторонняя.

ещё два вопроса знатокам:

1. есть желание исключить порты MPB для использования в CO,
но оставить их для SLTM32, достаточно ли будет в PGM101 оставить тип VOIU,
а в PGM103 исключить Slot 0 из ордера, очистив соответствующее поле?

2. может, кто-то сталкивался.
почему в некоторых трейсах плейер в Wireshark нормально видит и декодирует RTP в голос,
а в некоторых - нет (вообще пакеты как бы не перехватывает и не видит, фильтры при захвате все отключены)? Зависимость понять не могу. показалось, что входящие чаще может нормально декодировать.
снимаю с зеркального порта, с кабеля, который уже к провайдеру идёт.
Scroudge
сам же и отвечу..

Цитата(Scroudge @ 22.3.2018, 11:33) *
1. есть желание исключить порты MPB для использования в CO,
но оставить их для SLTM32, достаточно ли будет в PGM101 оставить тип VOIU,
а в PGM103 исключить Slot 0 из ордера, очистив соответствующее поле?

очень похоже, что да..

Цитата(Scroudge @ 22.3.2018, 11:33) *
2. может, кто-то сталкивался.
почему в некоторых трейсах плейер в Wireshark нормально видит и декодирует RTP в голос,
а в некоторых - нет (вообще пакеты как бы не перехватывает и не видит, фильтры при захвате все отключены)? Зависимость понять не могу. показалось, что входящие чаще может нормально декодировать.
снимаю с зеркального порта, с кабеля, который уже к провайдеру идёт.

вылечилось несколькими настройками сетевой карты (у меня win7, карточка Intel Gigabit)
все пакеты стали прилетать в программу.
далее..
часть пакетов идентифицировалаь как Skype..
пришлось руками добавить правило декодирования..
ничего лучше не придумал как по порту.
заходим в Decode as..
и добавляем начиная с 7010 до 7015 для MPB (с 7000 до 7009 программа сама норм.определяет)
и у меня с 7500 до 7599 (зависит от слота куда плата воткнута) для voib
все лень было перечислять, поэтому добавлял по мере поступления пакетов в трейс.
собсно это удобнее руками в файлике decode_as_entries, если записей много,
жаль, что по маске нельзя сделать..

после этого всё ок..

итого по односторонней слышимости, на заметку:
каналы voip платы MPB ведут себя не всегда так же, как каналы платы voib.
см. пост выше..
vitalii
вот вы пишите: "имеем:
ipecs-mg 192.168.90.18
voib8 192.168.90.18"

один и тот же адрес или ошибка в вашем описании..?
Scroudge
Цитата(vitalii @ 22.3.2018, 18:20) *
вот вы пишите: "имеем:
ipecs-mg 192.168.90.18
voib8 192.168.90.18"

один и тот же адрес или ошибка в вашем описании..?


ошибка, конечно..
вечером устамший был..
voib8 192.168.90.20

чуть ниже в пробросе портов табличка уже корректная, тк
её не сам от руки писал, а через буфер обмена кинул с вебморды.

я также конфиг ipecs-mg выкладывал, там можно было увидеть, что 192.168.90.20
сейчас в посте поправлю, спасибо.
Scroudge
Цитата(Dron @ 21.3.2018, 18:00) *
А попробовать включить Connect RTP when Receive REINVITE в SIP CO Additional Regist.(371)?


Доброго дня!
как я уже сообщал: фишка помогает только на плате VOIB,
для портов MPB она не работает.

решил вывести VOIU из списка CO, исключив из индекса в pgm103
потом правда пришлось перелопатить 160, 165-167, 168.
он же у меня зараза первым в индексе стоял, и после исключения все настройки сдвинулись
на 4 позиции. ну, это ладно..

сейчас другая беда.
исключить-то исключил, но вот вынос цифровой продолжает упорно занимать порты voib8
в первую очередь (локальный трафик). и вообще не ясно занимает ли он порты voiu.
из-за этого возникает дефицит каналов для внешнего трафика.
дефекты лезут даже в локальном в виде односторонней.
подозреваю, что voiu вообще не используются.

если раньше порты voiu было видно в Trace->CO Status
то сейчас не видно (они ж из CO выкинуты).

да, ещё: в 395 указал порядок 0(mpb), 5(voib)

пока же сделал так:
в 103 вернул mpb в СО,
в 160 in/out group указал для портов mpb неиспользуемые группы.

итого, остались вопросы:
1) как заставить вынос занимать в первую очередь порты VOIU (на MPB)?
2) как увидеть, что порты voiu используются в случае, когда mpb исключена из индекса CO
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.