Здравствуйте, коллеги. Станция OXE R10.1.1 Patch 36. Звонок по SIP-транку от провайдера приходит на циску, потом транзитом передаётся на ALCATEL. Там в свою очередь есть Ext. SIP Gateway и ассоциированная с ним SIP транковая группа . Звонок прилетает на Alcatel на некий внутренний номер , который является статистическим пилотом CCD. Далее идёт примерно такая цепочка: cтатистический пилот - роутинг пилот - приветсnвие автотётьки - очередь CCD - вход в Processing Group - попадаем на живого оператора - просим его перевести звонок - звонок переводится на конечного собеседника. И вот тут жопка. Я конечного собеседника слышу, он меня нет. Через 9 секунд звонок рвётся. Трассировка на циске (там чуть поудобнее) показала следующую картину: оператор кол-центра и конечный собеседник сидят на разных GD платах. Во время всей цепочки, по которой проходит звонок, от Alcatel прилетают RE-INVITE (что закономерно) и эти реинвайты также транзитом шлются циской провайдеру. Всё хорошо до самого последнего момента. Когда звонок переведён на конечного собеседника , Alcatel присылает RE-INVITE с пустым SDP. Такой RE-INVITE отправляется провайдеру и тот его не принимает: SIP/2.0 400 No SDP in re-INVITE После чего, как я описал, слышимость от конечного собеседника ко мне есть, меня собеседник не слышит и через 9 секунд Alcatel присылает CANCEL + BYE. Есть три других городских SIP провайдера, работающих по той же схеме. Все они "кушают" RE-INVIRE без SDP и тогда всё хорошо (ведь на участке "Cisco --- SIP провайдер" ни ip адреса, ни порты RTP во время RE-INVITE не меняются). Проблема в ALCATEL или в провайдере? Куда копать?
Небольшое уточнение. После того как циска получила ответ от провайдера SIP/2.0 400 No SDP in re-INVITE , она ничего не отправляет алкателю. То есть Alcatel ждёт реакции на re-INVITE, а её нету. Ну и скорее всего по таймеру отлуп. Мысли: 1) Попросить провайдера (Ростелеком , услуга "Новая телефония") принимать re-INVITE без sdp. Письмо написал, жду ответа. 2) Заставить циску принудительно добавлять sdp при отправке re-INVITE в сторону провайдера . Гуглю. Есть подозрения, что ничего не выйдет. 3) Заставить Alcatel добавлять sdp. Жду ответа с форума Интерсист
Андрей написал: А при таком же вызове циска - ОХЕ, т.е. нетранзитном, тоже реинвайт без sdp и голос есть в обе стороны ?
Циска работает только как транзит. Одним интерфейсом смотрит в локальную сеть и там серые ip адреса. Вторым в интернет, там соответственно белые ip адреса. Это решает кучу вопросов с натом. Внутренних абонентов на циске нету.
P.S. Ростелеком ответили, что не смогут разрешить re-INVITE без SDP. Из техподдержки позвонил на редкость адекватный (для Ростелекома) специалист техподдержки. Сказал, что и рад бы помочь, но не сможет.
В общем из ситуации вышел следующим образом: В сети (локальной) есть работающий asterisk. Решил использовать его как дополнительную транзитную прокладку между Cisco и Alcatel. Задумка сработала. Asterisk красавчик, отрабатывает re-INVITE только на стороне Alcatel. В сторону Cisco ничего не шлёт (ибо там ничего и не меняется). Соответственно re-INVITE отрабатывает на том участке, где должен отрабатывать, а дальше его нет и не надо.
Косяков в этой схеме пока не заметил.
P.S. Зато теперь еще и и звонки записывать астериском можно будет.
Андрей написал: А при таком же вызове циска - ОХЕ, т.е. нетранзитном, тоже реинвайт без sdp и голос есть в обе стороны ?
Циска работает только как транзит. Одним интерфейсом смотрит в локальную сеть и там серые ip адреса. Вторым в интернет, там соответственно белые ip адреса. Это решает кучу вопросов с натом. Внутренних абонентов на циске нету.
Александр Пыхтин написал: В общем из ситуации вышел следующим образом: В сети (локальной) есть работающий asterisk. Решил использовать его как дополнительную транзитную прокладку между Cisco и Alcatel. Задумка сработала. Asterisk красавчик, отрабатывает re-INVITE только на стороне Alcatel. В сторону Cisco ничего не шлёт (ибо там ничего и не меняется). Соответственно re-INVITE отрабатывает на том участке, где должен отрабатывать, а дальше его нет и не надо.
Косяков в этой схеме пока не заметил.
P.S. Зато теперь еще и и звонки записывать астериском можно будет.
Вместо одной прокладки теперь две друг над другом, разных производителей.
Вместо одной прокладки теперь две друг над другом, разных производителей.
А что в этом криминального? Или протокол SIP под какого-то вендора написан? Циска решает вопросы с IP адресацией (NAT, Firewall и прочая безопасность) , asterisk звонки записывать будет и записи в web мордочку выкладывать (удобно очень), а Alcatel конечных абонентов обслуживает, реализует CCD и прочие вкусности. Какая разница сколько прокладок будет. Всё это в интрасети и дополнительная задержка в 1мс на голос лично меня не удручит.
Вместо одной прокладки теперь две друг над другом, разных производителей.
А что в этом криминального? Или протокол SIP под какого-то вендора написан? Циска решает вопросы с IP адресацией (NAT, Firewall и прочая безопасность) , asterisk звонки записывать будет и записи в web мордочку выкладывать (удобно очень), а Alcatel конечных абонентов обслуживает, реализует CCD и прочие вкусности. Какая разница сколько прокладок будет. Всё это в интрасети и дополнительная задержка в 1мс на голос лично меня не удручит.
SIP "написан под" извращения любого вендора, чем они и занимаются, по мере сил. У вас теперь плюс одна точка отказа, с чем вас и поздравляю.
Насколько возможно проверить 2 вещи: 1. На циске - можно ли активировать игнорирование Re_Invite с нулевым SDP( если это возможно, то такие пакеты не будут уходить дальше)? 2. В OXE - попробовать в настройках Ext. Gateway выключить опцию “Support Re-Invite without SDP”.
Андрей написал: Сейчас получается аж два "sbc" между охе и провайдером, как минимум один из которых, вероятно, не НА.
открою глаза - циска тоже не НА
если ОХЕ звонит сразу на прова значит sbc из циски и не пахнет, перезаписывает пакеты sip если ОХЕ звонит на циску, а циска звонит к прову, циска выступает в роли sbc, в этом случае собака зарыта в циске, как вариант циска уж слишком "бородатая"
Андрей написал: Сейчас получается аж два "sbc" между охе и провайдером, как минимум один из которых, вероятно, не НА.
открою глаза - циска тоже не НА
если ОХЕ звонит сразу на прова значит sbc из циски и не пахнет, перезаписывает пакеты sip если ОХЕ звонит на циску, а циска звонит к прову, циска выступает в роли sbc, в этом случае собака зарыта в циске, как вариант циска уж слишком "бородатая"
Откройте глаза и скажите, какая именно циска там стоит?
"перезаписывает пакеты sip" - это одна из функций sbc если циска стоит на границе и обеспечивает совместимость адресов публичной и локальной сети - она не может не "перезаписывать пакеты sip"
Владислав Хисамов написал: Насколько возможно проверить 2 вещи: 1. На циске - можно ли активировать игнорирование Re_Invite с нулевым SDP( если это возможно, то такие пакеты не будут уходить дальше)? 2. В OXE - попробовать в настройках Ext. Gateway выключить опцию “Support Re-Invite without SDP”.
По первому вопросу - гуглил , ничего не нашёл. Но думается , что это не выход , поскольку на re-INVITE от алкателя со стороны циски не будет никакой реакции, что аналогично нынешней ситуации и алкатель всё так же будет рвать звонок. По второму вопросу галочка "Support Re-Invite without SDP" какая-то скажем так "мистическая". В mgr её нету. В omnivista4760 , если выделяешь Ext SIP Gateway её тоже нету. А если зажав CTRL выделишь два Ext SIP Gateway, то это поле появляется и не активно.
