Элтекс

Здравствуйте, вопросы по SMG-1016M

- поддерживает ли он опции: ISUP optimal routing и другие уровни SS7 (TCAP\MAP). В частности, умеет ли убирать петли при заворачивании входящего звонка обратно в E1 поток после рутинга?
- может ли он во внешнюю базу лезть за роутинговой информацией?
- как к нему прикрутить RBT (ring back tone) \ IVR (как опциональные сервисы) - можно ли обойтись без софтсвича типа FreeSWITCH\Asterisk для этого?

+ еще вопрос: как я понял транскодинг звука у вас там сделан аппаратно на субмодуле VoIP(SM-VP-M300) и один субмодуль справляется с одновременным транскодингом скольки? 62 каналов G.729 (согласно http://www.pbxware.ru/static/files/SMG1016M_0.pdf стр.13)? Или это цифра для пасстру?
Не совсем понятно: если этот модуль, согласно той же таблице, умеет обрабатывать 160 G.711 сессий, то что будет при необходимости все эти телефонные разговоры транскодить в 729 для перевода их по SIP в VoIP сеть? Будут задействованы 62 транскодера, а остальные 98 потоков куда денутся? Получат Servce Not available и reorder tone?
Как обстоят дела с самой лицензией для G.729?

Ждем вашего ответа.

danx писал(а):Здравствуйте, вопросы по SMG-1016M

- поддерживает ли он опции: ISUP optimal routing и другие уровни SS7 (TCAP\MAP). В частности, умеет ли убирать петли при заворачивании входящего звонка обратно в E1 поток после рутинга?

НА SMG1016M не реализован ISUP optimal routing и уровни TCAP/MAP

- может ли он во внешнюю базу лезть за роутинговой информацией?

Нет, такой функционал то же не реализован. Я так понимаю это операция routingrequest сообщения MAP?

- как к нему прикрутить RBT (ring back tone) \ IVR (как опциональные сервисы) - можно ли обойтись без софтсвича типа FreeSWITCH\Asterisk для этого?

Описанное выше в данный момент можно реализовать только посредством стороннего ПО (softswitch), который будет генерить информационное сообщение, а SMG транзитить это сообщение абоненту. SMG1016M в свою очередь может только генерить обычный сигнал КПВ SIP абоненту.
Но задача на дополнение ДВО на SMG1016m стоит. Идет обсуждение на дополнение шлюза нужными функциями. Так что, возможно, это и появится.

+ еще вопрос: как я понял транскодинг звука у вас там сделан аппаратно на субмодуле VoIP(SM-VP-M300) и один субмодуль справляется с одновременным транскодингом скольки? 62 каналов G.729 (согласно http://www.pbxware.ru/static/files/SMG1016M_0.pdf стр.13)? Или это цифра для пасстру?
Не совсем понятно: если этот модуль, согласно той же таблице, умеет обрабатывать 160 G.711 сессий, то что будет при необходимости все эти телефонные разговоры транскодить в 729 для перевода их по SIP в VoIP сеть? Будут задействованы 62 транскодера, а остальные 98 потоков куда денутся? Получат Servce Not available и reorder tone?

Каждая разговорная сессия по SIP, будь то соединение SIP-SIP, TDM-SIP, SIP-TDM занимает определенное количество разговорных каналов на субмодуле MSP. Количество занимаемых каналов определяется используемым кодеком для разговорной сессии.
К примеру при звонке TDM-SIP и использовании по SIP кодека G711 на MSP будет занят один канал из 128 возможных (128 а не 160 потому что идет ограничение на шлюзе по TDM каналам. В документации это сказано).
При вызове по схеме SIP-SIP по кодеку G711 будет занято 2 канала.

Тут еще нужно учитывать что на 0м MSP 3 канала заняты под служебные цели.

Как обстоят дела с самой лицензией для G.729?

А что именно Вас интересует по лицензии?
В России алгоритмы и компьютерные программы не патентуются, по этой причине кодек G.729 на территории РФ полностью бесплатен

Ждем вашего ответа.

Evgeniy писал(а):
danx писал(а):Здравствуйте, вопросы по SMG-1016M
НА SMG1016M не реализован ISUP optimal routing и уровни TCAP/MAP

то есть, если у меня входящий звонок идет по E1 каналу, и на SMG1016М у меня настроен роутинг (переадресация) этого звонка (по номеру вызывающего например) обратно в E1 (т.е. TDM-TDM), то оба канала E1 так и будут заняты этим разговором?
Пример: все звонки от Васи идут к Пете. Звонит Вася, мы смотрим его номер телефона, и делаем редирект обратно в ТФОП. Вопрос: будут ли Вася с Петей разговаривать МИНУЯ вашу железку, или голос так и будет идти от Васи на железку и от железки к Пете?

Evgeniy писал(а):
danx писал(а):Здравствуйте, вопросы по SMG-1016M
Нет, такой функционал то же не реализован. Я так понимаю это операция routingrequest сообщения MAP?

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

В том же FreeSWITCH обработка правил роутинга возможна на языке JavaScript, а у вас с этим как?

Evgeniy писал(а):НА SMG1016M не реализован ISUP optimal routing и уровни TCAP/MAP

Евгений, я переформулирую вопрос (ISUP optimal routing это из мира сотовых сетей, для случая TDM это называется по другому) ->

Поддерживает ли ваш шлюз SS7 ISUP Release-to-Pivot (RTP) алгоритм? По идее должен поддерживать?

см
http://www.ifast.org/files/IFAST15_008_ ... bution.pdf

Вкратце:
Если входящий транк пришел от шлюза, умеющего Release to Pivot, то в сигнальных данных для этого транка будет спец. код в SS7 ISUP
IAM call setup message. Ваш шлюз должен обрабатывать его и действовать по стандарту для такого кода: сбросить хвонок с указанием правильного номера редиректа. Тогда оригинирующий шлюз тот же самый звонок перепроложит уже в обход вашего шлюза на новый номер.

Cтоит начать с того, что переадресацию SMG сам делать пока не умеет. то есть " если у меня входящий звонок идет по E1 каналу, и на SMG1016М у меня настроен роутинг (переадресация) этого звонка" не совсем корректно.
SMG в нынешнем его функционале поддерживает только возможность переадресации через него.
Иными словами, когда происходит звонок через SMG с абонента А на абонента В и на абоненте В стоит переадресация, то абонент А получит уведомление с redirect information (SMG протранзитит от абонента В) только в случае разрешения 302 на сип -профиле, который назначен на абоненте В.

Алгоритм RTPvt не поддержан (поскольку SMG - транковый шлюз и работает транзитом, собственный функционал пока поддерживает только разрешение переадресации через себя). В каком варианте на SMG реализовано сейчас, шлюз А, получив информацию о переадресации должен разорвать старое соединение и по своему dialplan попытаться установить новое. Повторный звонок так же может идти на SMG "Тогда оригинирующий шлюз тот же самый звонок перепроложит уже в обход вашего шлюза на новый номер". Куда поступит звонок - прероготива dialplan originating equipment

У Вас еще был вопрос:

>>Смотрите. Если у вас на железке можно писать скрипты, которые >>обрабатывают входящий звонок, разбирают параметры звонка - >>например, анализируют номер входящего и если эти скрипты умеют >>лезть в интернет за информацией, на какой именно номер >>перенаправить звонок, то этого могло бы хватить.

>>В том же FreeSWITCH обработка правил роутинга возможна на языке >>JavaScript, а у вас с этим как?

На SMG1016M другой функционал, нежели во всемдоступном Freeswitch.
Функционал устройства в любом случае разбирает пришедшее сообщение по параметрам и начинает его обработку. Если вызов попал на SMG, то он уже точно пойдет через него. При входящем вызове по номеру В начинается поиск зарегестрированных абонентов на устройстве, если никаких совпадений не найдено, то анализ входящего вызова переходит на план нумерации, где по номеру А или В входящего вызова должно быть найдено совпадение. При наличии совпадения вызов уходит через транковую группу на направление SIP/TDM, при отсутсвии совпадении, то есть при ненахождении дальнейшего пути маршрутизации вызова происходит отбой.

Я так понимаю Вам необходима возможность переадресации на самом SMG? Необходимость этого функционала на SMG как-то связано с структурой Вашей сети или оконечные оборудования не поддерживают этот функционал?

Evgeniy писал(а):Я так понимаю Вам необходима возможность переадресации на самом SMG? Необходимость этого функционала на SMG как-то связано с структурой Вашей сети или оконечные оборудования не поддерживают этот функционал?

Мы исследовали вариант реализации телефонии только на основе SMG (например, нам нужен безусловный редирект входящих звонков обратно в E1/ТФОП в зависимости от префикса входящего номера ABC), но, почитав вас, я понимаю что так не получится. Скорее всего нам придется ставить FreeSWITCH за SMG, и всю логику маршрутизации выносить на фрисвич.

danx писал(а): нам нужен безусловный редирект входящих звонков обратно в E1/ТФОП в зависимости от префикса входящего номера ABC

Если не требуется в дальнейший вызов передавать информацию о переадресации, то конкретно эту задачу можно решить средствами модификатора на входящей связи.

Элтекс

Вопросы по SMG-1016M

Вопросы по SMG-1016M

Re: Вопросы по SMG-1016M

Re: Вопросы по SMG-1016M

Re: Вопросы по SMG-1016M