Здравствуйте.
Станция CS1000E rel 6.0. CoRes.
По сип выдается странный пакет вместо invite.
Wireshark пишет
Protocol: IP
Info: Fragmented IP protocol (proto=UDP 0x11, off=1480)
Это лечится/патчится?
Никто с таким не встречался?
Какие-то дополнительные данные нужны?
Что-то не работает, или "не нравится, как показывается в вайршарке" ?
настраиваю соединение по sip c городским оператором. их платформа не отрабатывает часть функций (перевод звонка по неответу). Их технари говорят, что это из-за кривого invite, в котором нет SDP. И то, что wireshark не распознает пакет как invite приводят как аргумент в свою пользу. Эти транки с таким-же инвайтом использовались для связи с другим CS1000 и все проходило на ура.
А в какой точке снимается трейс вайршарком и как у вас с MTU на сети ?
Доп. вопрос: "не отрабатывает часть функций" - а часть отрабатывает ?
Сценарии ? Что работает, как в этом случае с трейсами ?
Клещами полную картину приходится тащить.
А в какой точке снимается трейс вайршарком и как у вас с MTU на сети ?
После свича стоит firewall, с которого поднимается туннель (IPSec) до узла оператора.
Трейс снимается на свиче, в который включен CS1000E (порт смотрящий в firewall зеркалирую).
Т.е. до точки, где снимается трасса MTU 1500. Дальше из-за туннеля конечно меньше.
Доп. вопрос: "не отрабатывает часть функций" - а часть отрабатывает ?
Сценарии ? Что работает, как в этом случае с трейсами ?
Клещами полную картину приходится тащить.
Собственно не отрабатывается переход по неответу.
В общем мобильный оператор имеет свою супер-мега-IP платформу.
Через префикс (CDP) выхожу на них и набираю внутренний номер (на моей АТС). Начинает звонить тот стационарный телефон, номер которого я набирал. Через n звонков вызов должен уйти на мобильный. А он не уходит. Их технари говорят, что из-за неправильного инвайта вызов не доходит до их платформы и потому нет редиректа на мобилку.
Если через спец. код набрать внутренний номер на моей АТС, то звонит внутренний телефон и можно нормально поговорить.
С их стороны инвайт wireshrk'ом распознается нормально.
Не понял.
"Выхожу на них" - это что такое физически ? Протокол, трейс ?
Набираю внутренний номер - DISA, или что ?
Через спец. код набираю внутренний номер - DISA, или что ?
В вашем описании непонятно, как это одни вызовы успешно проходят, а "по неответу" - нет.
И до какой-такой "их платформы" и через что не доходит инвайт. И если он не доходит до платформы при неответе, то куджа же он доходит в предыдущих случаях ?
Если вы не в состоянии полностью ответить на эти вопросы своими словами, то пришлите хотя бы ENTC, трейс д-канала, T-LAN capture с сигнальника для всех заявленных сценариев.
Не понял.
"Выхожу на них" - это что такое физически ? Протокол, трейс ?
Набираю внутренний номер - DISA, или что ?
Через спец. код набираю внутренний номер - DISA, или что ?
В вашем описании непонятно, как это одни вызовы успешно проходят, а "по неответу" - нет.
И до какой-такой "их платформы" и через что не доходит инвайт. И если он не доходит до платформы при неответе, то куджа же он доходит в предыдущих случаях ?
Выхожу на них - это набираю префикс (наружу не выдается) и DN моей атс (цифровой телефон). Протокол SIP.
Что у них за платформа не знаю.
Еще раз.
Отсылаю через SIP-транк оператору внутренний номер моей АТС (на цифровик позвонить хочу). Их платформа направляет этот вызов обратно мне и начинает звонить телефон с номером, который я набрал. Если никто не берет трубку, то начинает звонить мобилка этого человека, номер которой хранится в базе на VoIP-платформе у оператора.
Так должно быть. Фактически редирект по неответу на мобилку не происходит. Технари оператора говорят, что из-за "кривого" инвайта (в нем SDP нет) вызов до их платформы не доходит и обрабатывается шлюзом (как это может быть для меня загадка а более подробно они не объясняют).
Пример моих инвайтов во вложении пакет 1562
ip моей ноды 10.108.15.50
Без указанных трейсов опять ничего не понятно.
Вы отсылаете свой номер по SIP и "их платформа" направляет вызов обратно вам.
Значит - инвайт воспринимается ?
Значит - инвайт воспринимается ?
Значит воспринимается. Но, как оператор заявляет, обрабатывается он не сервером, а каким-то магическим шлюзом. А до платформы не доходит из-за кривого инвайта, в котором нет информации о кодеках и т.д. Как агрумент приводит мою же трассу (пакет 1562, который wireshark не декодирует).
Соответственно вопрос: почему может получаться такой invite?
Трейсы пока снять не получится. Попробую завтра.
Пакет декодируется, но в нем только часть сообщения инвайт, что нормально при фрагментации.
Возникает вопрос - где пакеты с остальными частями.
Это может быть вопрос к настройкам сетевого интерфейса на сигнальнике, к настройкам вашего L2 мутатора и т.д.
А вы у***** не снимаете capture на самом сигнальнике.
Подскажите плз где включается возможность снимать трассу пакетов на сигнальнике. А то он мне говорит, что wireshark заблокирован секурным админом, а tethereal'а нет
Порекомендуйте пожалуйста где смотреть. В имеющейся доке кроме команды как таковой ничего не нашел.
Что такое "имеющаяся дока" ?
Смотреть надо в NN43001-730.
Поделитесь пожалуйста. У себя такой не нашел (на диске нет). На сайте nortel.com тоже не нашел.
Документацию надо искать на http://support.avaya.com
Спасибо, нашел.
Видно, что нода генерит пакет ip длиной 1514 байт. За ним следует invite 793 байта.
Куда копать дальше? Не понимаю что за первый пакет большой такой?
Обычный пакет.
Просто у вас вероятно включена Media Security, в результате в SDP присутствуют атрибуты crypto, довольно крупные.
Поэтому пакет не помещается в один фрейм ethernet и фрагментируется.
Проверил в настройках SIPGw, в NRS настройки gateway. Нигде Security не включено.
Не там проверяете.
RTFM Media Security.
На транках cls MSNV
В PARM MESC OFF
все повторяется. ребутить нужно?
По идее, не нужно.
Нужно проверить, на тех ли транках MSNV.
Какой класс на абонентах, с которых делались тестовые вызовы.
Стоит ли последний деплист.
Но надо понимать, что все это не отменяет вопроса - почему в вашей сети проблемы с передачей фрагментированных IP пакетов ?
На всех транках MSNV.
Вызовы делались с другого М1. Т.е. эта cs1000e транзитная. Соединение между ними PRI SL1.
DepList 1: core Issue: 02(created: 2010-08-31 10:00:02 (est))
Но надо понимать, что все это не отменяет вопроса - почему в вашей сети проблемы с передачей фрагментированных IP пакетов ?
этим тоже занимаюсь. решил сначала со станции начать. вдруг получится сделать invite нормального размера...
этим тоже занимаюсь. решил сначала со станции начать. вдруг получится сделать invite нормального размера...
А у него нормальный размер.
Кроме того, даже если инвайт влезет в ваш MTU на ethernet, влезет ли он в MTU на туннеле ?
этим тоже занимаюсь. решил сначала со станции начать. вдруг получится сделать invite нормального размера...
Правильно jetc говорит, нужно в сети разобраться, почему в сети проблема с фрагментированными пакетами, разберитесь на более низком уровне прежде чем лезть выше.
Вроде случилось. Коммутатор не пропускал большие пакеты. Уменьшил MTU на CS1000 и пакеты проходить стали.
С наступившим!!!
А можно ли как-то уменьшить размер инвайта?
Оператор, с которым соединение идет, не умеет обрабатывать размер инвайта больше 1500.
С наступившим!!!
А можно ли как-то уменьшить размер инвайта?
Оператор, с которым соединение идет, не умеет обрабатывать размер инвайта больше 1500.
Какая прелесть.
А чем мотивируют ?
Тем, что не могут обработать инвайт.
Цитата:
"Размер вашего INVITE слишком большой, поэтому наша система его не пропускает.
Правила редактирования SIP применяются только после того, как инвайт примет наш шлюз. Но он его отбивает по размеру пакета.
Вам нужно попытаться со своей стороны максимально облегчить размер пакета, он не должен превышать 1500 байт."
При этом CS1000 уже скрещена с меровским софтсвичем по sip и работает на ура.
Тем, что не могут обработать инвайт.
Цитата:
"Размер вашего INVITE слишком большой, поэтому наша система его не пропускает.
Правила редактирования SIP применяются только после того, как инвайт примет наш шлюз. Но он его отбивает по размеру пакета.
Вам нужно попытаться со своей стороны максимально облегчить размер пакета, он не должен превышать 1500 байт."
Что характерно, ни одной ссылки на какие-либо стандарты или нормативные документы.
Совершенно непонятно, на каком основании "его отбивает по размеру пакета".
Ну вот так...
А еще в H323 у них почему-то работа с 729-м кодеком нормально не получается.
Ситуация грозит приобрести статус нерешаемой...
Так можно что-то сделать и убрать что-нить "лишнее"?
Помню на какие то древних байстеках была проблема, не пропускали фреймы больше 1500... это было ооочень давно, когда байстек был байстеком, а не аваей и тем более не нортелем :)
Какие то странные требования вашего провайдера... может он сможет какие то документы предоставить на каком основании он от вас требует invite меньше 1500 ?
Так можно что-то сделать и убрать что-нить "лишнее"?
Можно менять настройки на тему исключения из SDP крипточасти.
Но причина не в них, а в провайдере.
На провайдера надежды мало. Может когда-то в будущих релизах эта хрень и начнет работать нормально...
Крипто на транках выключил еще раньше (благодаря вашим наводкам по доке нашел см. выше).
Попробовал изменить тип звонка на E164 international. Размер invit'а немного уменьшился, но все-равно остается большим (было чуть более 2000 байт, стало 1878).
Так можно что-то сделать и убрать что-нить "лишнее"?
Думаю есть несколько вариантов:
1. На релизах 5.x и 6 были патчи которые убирали все лишнее из INVITE (например инкапсулированный в него SL1), служили они как раз для шлюзования с операторами IP телефонии. На 7ом релизе вроде патчей вроде нет, но....
2. Появился Trunk Bridging (еще иногда называют SBC Lite), в сущности это B2BUA который одним UA регится на NRS другим у провайдера, в нем еще есть NAT Traversal и он убирает все лишнее из INVITE (наверно по этому и убрали эти патчи, что бы лучше покупали Trunk Bridging :) ). Это отдельно стоящий сервер, он не может быть cores.
3. А можно поставить Asterisk (который в сущности тоже есть B2BUA), я думаю он в такой роли у многих работает.
Все это, думаю, должно уменьшить размер инвайт. :)
Предложил им включиться через промежуточный шлюз. Расстроились и обещали завтра накатить какой-то волшебный патч. Будем пробовать.
Предложил им включиться через промежуточный шлюз. Расстроились и обещали завтра накатить какой-то волшебный патч. Будем пробовать.
Кому предложили и кто расстроился?
Оператору предложили или клиенту, если клиенту... то где они возьмут патч, а если оператору, то им какая разница через чего к ним подключаются, главное что бы работало...
Оператору предложил. Оператор же и патч у себя накатывать будет.
Оператору предложил. Оператор же и патч у себя накатывать будет.
А почему тогда оператор "расстроился" когда было предложение к ним подключиться через "посредника", у них тайная страсть к Нортель и они хотя, что бы был именно он? :D
Если станции никак не стыкуются, значит их делали совсем разные китайцы :D
Если станции никак не стыкуются, значит их делали совсем разные китайцы :D
Из разных провинций, у них там и язык отличается... вот и не могут договориться. :)
По поводу "расстроились". Это я для красного словца. Уж очень быстро идея с патчем появилась :)
Дело кончилось тем, что соединились по H323 на G711 до тех порт, пока оператор не пофиксит свои проблемы с G729.