Jump to content
Калькуляторы

Помогите настроить YATE для SS7 Проблема с настройкой роутинга для SS7

Разбираюсь с Yate, в частности с SS7.

В целях изучения проекта соединил два Yate, но не через карточку E1, а через сокет. То есть пакеты уровня MTP2 идут через сокет.

 

Соединение по MTP2 проходит.

Но когда посылаеться ISUP-сообщение UPT (user part test) не отыскиваеться "Route" и сообщение никуда не отправляеться.

 

Вопрос: каким способом задаються маршруты для уровня MTP3?

 

Share this post


Link to post
Share on other sites
Разбираюсь с Yate, в частности с SS7.

В целях изучения проекта соединил два Yate, но не через карточку E1, а через сокет. То есть пакеты уровня MTP2 идут через сокет.

 

Соединение по MTP2 проходит.

Но когда посылаеться ISUP-сообщение UPT (user part test) не отыскиваеться "Route" и сообщение никуда не отправляеться.

 

Вопрос: каким способом задаються маршруты для уровня MTP3?

 

Я чего-то не могу себе представить "пакеты уровня MTP2 идут через сокет" кроме как via SIGTRAN.

 

http://yate.null.ro/pmwiki/index.php?n=Main.Routing

 

По идее routing от channel's зависеть не должен. Попробуйте сделать SIP trunk между вашими Yate в тестовых целях, потом перевести на SS7.

Если не поможет, то боюсь что тут только либо смотреть в source, либо просить помочь в рассылке.

 

.

 

 

 

Share this post


Link to post
Share on other sites
Я чего-то не могу себе представить "пакеты уровня MTP2 идут через сокет" кроме как via SIGTRAN.
Представлять надо так: Есть 2 Yate, пакеты уровня MTP2 должны отдаваться драйверу карточки (записываться в файл устройства, например /dev/w1g1). Приниматься MTP2-пакеты тоже должны от драйвера карточки. Вместо этого MTP2-пакеты шлються через TCP соединение другому яте. Для этого немного изменен интерфейс к драйверу карточки (файл wpcard.cpp).

 

Здесь про маршрутизация звонка, а меня онтересует маршрутизация в сигнальной сети ОКСа (уровень MTP3).

 

По идее routing от channel's зависеть не должен. Попробуйте сделать SIP trunk между вашими Yate в тестовых целях, потом перевести на SS7.

Если не поможет, то боюсь что тут только либо смотреть в source, либо просить помочь в рассылке.

Не вижу как настройка SIP может приблизить меня к пониманию настройки ОКСа :).

Исходники Yate изучаю вдоль и поперек, но так и не удалось разобраться.

Например, при старте уровня MTP3, в функции SS7Layer3::buildRoutes() патаеться прочитаться с конфига параметр по имени "route", однако в примерах конфигов в файле ysigchan.conf нет никакого "route".

 

Народ, кто разбирался с Yate, помогите плиз!!!

 

 

 

Share this post


Link to post
Share on other sites

Все, разобрался.

 

По непонятным причинам у меня в примере файла ysigchan.conf присутствовали не все параметры.

В частности совсем ничего не упоминальсь об "netind2pctype" и "route".

Более полное описание уонфига нашел здесь: http://yate.null.ro/pmwiki/index.php?n=Main.Ysigchan

 

Share this post


Link to post
Share on other sites

поделитесь плз конфигами yate+ss7 - чой-то не получается на сангоме настроить - в форумах на null.ro тема всплывала, но так ни разу и не доходила до конца - как собственно и многое по yate - вроде по архитектуре и идеологии классная штука, а вот как добиться конкретного результата хрен разберешь....

Share this post


Link to post
Share on other sites

Проблемы которые я имел с настройкой SS7 на яте сводились к настройке конфигов. Для этого хорошенько разбирался с исходниками чтобы понять какое значение дать тому или иному параметру.

 

Также много ответов на http://yate.null.ro/.

Там же есть примеры конфигов.

Не думаю что мой конфиг Вам поможет.

Лучше объясните в чем проблема, постараюсь помочь :-)

 

 

Share this post


Link to post
Share on other sites

сенкс за реакцию, но

 

>>> Проблемы которые я имел с настройкой SS7 на яте сводились к настройке конфигов.

 

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

 

>>> Также много ответов на http://yate.null.ro/.

>>> Там же есть примеры конфигов.

 

ответов по SS7 там НЕТУ НИКАКИХ - кроме общих слов, что это работает во всех вариантах и темплейтов СТАНДАРТНЫХ конфигов - без конкретики настроек...

 

в форумах тема SS7 упоминалась типа 3-4 раза - всегда заканчивалась словами обращавшегося "ну вот - сделал как сказали разработчики, но все равно не работает - что дальше" и мольбой "дайте ж пример ПОЛНОГО РАБОТАЮЩЕГО конфига для данной ситуации" - на этом ветка затихала...

 

а проблема простая - в МСК есть ящик на котором Asterisk 1.6.1.10 вместе с chan_ss7-1.2.1 через сангому состыкованы с AXE10 по SS7 (сначала пробовал через libss7, но не устроило по некоторым требованиям telco) - все в принципе работает, но а) все равно есть глюки и dicea ничо внятного не говорит б) есть желание перенести этот линк на циску 5400 под управлением yate.

 

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

 

настройки yate для SS7 взяты отсюда - токи другие пойнткоды -

 

http://yate.null.ro/archive/?action=show_msg&actionargs[]=46&actionargs[]=61

 

ошибка выдается аналогичная тому что в последнем мессаге ветки - про linkset2 - соответственно совсем непонятно правилен ли конфиг в принципе и чего в нем не хватает...

 

Очень бы хотелось как то все завести - и выложить ПОЛНЫЕ КОНФИГИ куда-нить для обчества - чтобы не приходилось выдергивать по кусочкам инфу типа "какую максимальную версию wanpipe держит yate", как ПРАВИЛЬНО настроить сангому для yate и пр. - даже на сайте у сангомы конкретики по yate существенно больше, но там тоже нет ничего про SS7 - токи про аналог и PRI...

 

Нюхом чую что yate суперская штука, но конфигов и хау-ту там катастрофически не хватает - куча народа побъется лбом об стену месяцок другой да и отваливает - под мудрые советы разработчиков типа "For Yate it's enough to configure ciscosm and ysig chan. Just take a look in the config files." - это ВСЕ СЛОВА про настройку yate вместо PGW2200 - чуть ли не главной рекламируемой фичи последней версии...

Edited by acheck

Share this post


Link to post
Share on other sites

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

 

По моему, Вы погорячились :-)

Зачастую "коммуникационную софтину или железяку" надо тщательно допилить:

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

 

ПРО КОНФИГИ:

 

Как я понимаю на работу SS7 влияют слудующие конфиги:

1) wpcard.conf - здесь конфигуряться интерфейс к карточке Е1, я именно к картам wanpipe;

2) ysigchan.conf - здесь непосредственно конфигуриться SS7;

3) regexroute.conf - здесь вся маршрутизация, но этот файл начнет влиять когда пойдут звонки, так что пока его не рассматриваю.

 

То есть для успешного старта ОКСа Вам надо правильно настроить конфиги 1) и 2)

Оговорюсь, я использую карточку не winpipe, а несколько иную (wormpipe), поэтому работа с карточкой у меня отличается, хотя и схожа с winepipe.

 

Мой файл ysigchan.conf:

 

[general]

 

debuglevel=10,10,10,10,10

 

[link1]

type=ss7-isup

sig=wormpipe1

strategy=lowest

numplan=isdn

numtype=subscriber

pointcodetype=ITU

pointcode=2-3-1

remotepointcode=2-3-2

netind2pctype=ITU,ITU,ITU,ITU

route=ITU,2-3-2,0

debuglevel=10,10,10,10,10

 

В конфиге по ссылке есть секции [linkset3] и [linkset2] - откуда они?

Не нашел никокого упоминания о них ни в примерах конфигов, ни в исходниках.

Я использую версию Yate 2.0.0 1

 

Чтобы понять что не нравиться яте надо:

- выставить в конфиге debuglevel=10,10,10,10,10 (это максимум)

- запускать с ключами для отладки: yate -Do -vvvv

 

Посмотрите что пишет яте - может прояснит ситуащию. Если непонятно - конфиг и лог работы в студию :-)

 

Share this post


Link to post
Share on other sites

To acheck:

Проблема решилась?

Если Да, то в чем было дело, ежели не секрет? :-)

Share this post


Link to post
Share on other sites

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

 

Как только все заведется - все детально распишу- нюансов действительно много - особенно в сравнении с asterisk + libss7 или chan_ss7.

 

В процессе бодания еще раз убедился, что yate это крайне необычно - народ там все делает не снизу вверх, как большинство других, а сверху вниз. Есть стандарт на протокол SS7 - так он кодируется В ПОЛНОМ ОБЪЕМЕ - по крайней мере структуры данных. Соответственно нет проблем получить доступ к ЛЮБОМУ параметру ЛЮБОГО мессага ЛЮБОГО уровня протокола SS7 - причем доступ делается на человеческом языке - типа sig.ForwardCallIndicators = international,isdn-orig,isup-path; sig.callerscreening = user-provided-passed. В других реализациях SS7 с которыми сталкивался (libss7 и chan_ss7) все эти параметры были закодированы внутри - причем в основном типа как 0x0261 - и лишь к нескольким были функции осмысленного доступа к ним из API. Тут же ВСЕ поля ВСЕХ типов протокольных сообщений расписаны и доступны как именованные объекты...

 

 

 

 

Share this post


Link to post
Share on other sites

окончательно разобрался - полные конфиги тут - http://pastebin.ca/1724630

 

основные моменты

 

/etc/wanpipe/wanpipe1.conf

 

[interfaces]

w1g1 = wanpipe1, , API, Comment

w1g2 = wanpipe1, , API, Comment

 

[w1g1]

HDLC_STREAMING = YES

ACTIVE_CH = 1

DATA_MUX = NO

TDMV_HWEC = NO

 

[w1g2]

HDLC_STREAMING = NO

ACTIVE_CH = 2-31

IDLE_FLAG = 0x7E

DATA_MUX = YES

TDMV_HWEC = NO

 

 

/usr/local/etc/yate/wpcard.conf

[general]

bitswap=enable

idlevalue=255

buflen=160

hwrepeatcapable=true

dumpevents=yes

 

[wanpipe1]

type=E1

readonly=no

siggroup=w1g1

voicegroup=w1g2

voicechans=2-31

;offset=0

increment=32

samples=50

errormask=255

echocancel=false

dtmfdetect=true

bitswap=false

 

/usr/local/etc/yate/ysigchan.conf

[general]

debuglevel=9,9,9,9,9

debuglevel_engine=9,9,9,9,9

enable=yes

dtmfinband=true

 

[link1]

enable=yes

type=ss7-isup

pointcodetype=ITU

pointcode=2-251-7

defaultpointcode=2-251-7

remotepointcode=2-121-0

lockgroup=yes

earlyacm=yes

sig=wanpipe1

voice=wanpipe1

strategy=increment

strategy-restrict=even

channelsync=1000

numplan=isdn

numtype=international

presentation=allowed

screening=user-provided

format=alaw

print-messages=yes

extended-debug=yes

; International = 0x00, SpareInternational = 0x40, National = 0x80, ReservedNational = 0xc0

netindicator=0x00

 

[linkset3]

type=ss7-mtp3

netind2pctype=ITU

route=ITU,2-121-0,0

autostart=yes

link=link1

link1.sig=wanpipe1

 

[link1]

type=ss7-mtp2

autostart=yes

emergency=no

filllink=no

rxunderrun=0

 

/usr/local/etc/yateregexroute.conf

[default]

; 111.222.111.222

${address}^111\.222\.111\.222\:=goto authorized

 

; тут задаем индикаторы ответа на входящий вызов с SS7

${module}^sig$=;message-oprefix=osig.

${module}^sig$=;osig.BackwardCallIndicators=charge,called-free,called-ordinary,isup-path,isdn-end,echodev

${module}^sig$=sip/sip:${called}@111.222.111.222

 

.*=-;error=forbidden;reason=Protocol not allowed

 

[authorized]

 

; тут задаем индикаторы на исходящий выхов в SS7

^[1-9][0-9]\{10,\}$=; sig.ForwardCallIndicators = international,isdn-orig,isup-path;

^[1-9][0-9]\{10,\}$=; sig.callerscreening = user-provided-passed;

^[1-9][0-9]\{10,\}$=; sig.TransmissionMediumRequirement = 3.1khz-audio; sig.inn = 0; caller = ${caller}

^[1-9][0-9]\{10,\}$= sig/${called}.; link = link1;

 

.*=return

 

Основной затык был с формированием различных индикаторов и служебных полей в сообщениях SS7 на входящих и исходящих вызовах в соответствии с требованиями оператора. Оказалось все просто - АБСОЛЮТНО все поля доступны по именам. Это очень радует потому как в asterisk и в случае libss7 и chan_ss7 многие вещи закодированы внутри и недоступны для установки из диалплана - приходилось патчить сорсы...

 

Имена полей и их значений в протокольных мессагах SS7 смотрится в сорсах в libs/yate.cpp - вот пример того как это выглядит для поля Forward Call Indicators:

 

// Forward Call Indicators (Q.763 3.23)

static const SignallingFlags s_flags_fwcallind[] = {

{ 0x0001, 0x0000, "national" }, // National/international call indicator

{ 0x0001, 0x0001, "international" },

{ 0x0006, 0x0000, "e2e-none" }, // End-to-end method indicator (none available: only link-by-link)

{ 0x0006, 0x0002, "e2e-pass" }, // Pass along method available

{ 0x0006, 0x0004, "e2e-sccp" }, // SCCP along method available

{ 0x0006, 0x0006, "e2e-pass-sccp" }, // Pass along and SCCP method available

{ 0x0008, 0x0008, "interworking" }, // Interworking indicator (0: SS7 all the way)

{ 0x0010, 0x0010, "e2e-info" }, // End-to-end information available

{ 0x0020, 0x0020, "isup-path" }, // ISUP indicator (ISUP used all the way)

{ 0x00c0, 0x0000, "isup-pref" }, // ISUP preference indicator: preferred all the way

{ 0x00c0, 0x0040, "isup-notreq" }, // not required all the way

{ 0x00c0, 0x0080, "isup-req" }, // required all the way

{ 0x0100, 0x0100, "isdn-orig" }, // Originating from ISDN

{ 0x0600, 0x0000, "sccp-none" }, // SCCP method indicator: no indication

{ 0x0600, 0x0200, "sccp-less" }, // connectionless method available

{ 0x0600, 0x0400, "sccp-conn" }, // connection oriented method available

{ 0x0600, 0x0600, "sccp-less-conn" }, // connectionless and connection oriented methods available

{ 0, 0, 0 } };

 

а вот так их показывает wireshark - соответствие находится легко

 

Forward Call Indicators: 0x2101

Mandatory Parameter: 7 (Forward call indicators)

.... ...1 .... .... = National/international call indicator: Call to be treated as international call

.... .00. .... .... = End-to-end method indicator: No End-to-end method available (only link-by-link method available) (0x0000)

.... 0... .... .... = Interworking indicator: no interworking encountered (No.7 signalling all the way)

...0 .... .... .... = End-to-end information indicator: no end-to-end information available

..1. .... .... .... = ISDN user part indicator: ISDN user part used all the way

00.. .... .... .... = ISDN user part preference indicator: ISDN user part prefered all the way (0x0000)

.... .... .... ...1 = ISDN access indicator: originating access ISDN

.... .... .... .00. = SCCP method indicator: No indication (0x0000)

.... .... ...0 .... = Ported number translation indicator: number not translated

.... .... ..0. .... = Query on Release attempt indicator: no QoR routing attempt in progress

 

Еще одна непонятка была с формированием Stop Sending после последней цифры номера - делается добавлением точки - sig/${called}.;

 

Так что в целом yate приятно порадовал - он закодирован сверху вниз - вот есть SS7 - для него сначала закодированы ВСЕ объекты данных, описанные в соответствующих разделах стандарта, а потом уже расписаны методы работы с этими объектами. К примеру в * протокольные сообщения формируются на двоичном уровне - практически все значения зашиты в код - пример из chan_ss7

 

isup_msg_init(msg, sizeof(msg), variant(pvt), this_host->opc, peerpc(pvt), pvt->cic, ISUP_CON, &current);

param[0] = 0x16; /* Subscriber free, ordinary subscriber, no end-to-end, charge=2 */

param[1] = 0x14; /* No interworking, no end-to-end, ISDN all the way, no

hold, terminating access ISDN, no echo control */

isup_msg_add_fixed(msg, sizeof(msg), &current, param, 2);

isup_msg_start_variable_part(msg, sizeof(msg), &varptr, &current, 0, 1);

 

В yate такого в принципе быть не может - у него есть матрица соответствия полей и их кодеров/декодеров - соответственно сообщение формируется как объект, а поля сообщения заполняются исходя из свойств данного объекта и присвоенных им значений.

 

 

Так что в целом все завелось, но проблемы остались - нету детектирования DTMF со стороны SS7 - сильно сдается что для этого на сангоме нету софтового решения - требуется карточка с аппаратным эхоподавлением - она обрабатывает DTMF аппаратно...

Edited by acheck

Share this post


Link to post
Share on other sites

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

 

Есть только одна проблема. Надо уметь из этого пластилина что-то лепить, и доками этому не научишь. Нужно именно понимать как оно работает изнутри. Тогда такие вещи воротить можно...

Share this post


Link to post
Share on other sites

Господа,

в продолжении темы хочу спросить как обстоят сейчас дела с Yate+SS7?

Sangoma выпускает свое решение: SMG (Sangoma Media Gateway), позволяющая SS7 преобразовать сразу в SIP. Только софт стоит 3200 USD + 825 USD обязательное годовое обслуживание (видимо свои ошибки чистить за наш счет).

Скачал с тестовой лицензию - это их наработки libsng-ss7 + FreeSWITCH (вроде для FreeTDM?). В чем выражается их продукт (SMG) пока не понял.

С Yate дело имел, но только в качестве конвертера SIP-H323 с нагрузкой в 60 каналов.

 

P.S. Ссылка в сообщении 11 не работает (устарела). Можно попросить выложить свежую ссылку?

Edited by tma

Share this post


Link to post
Share on other sites

Коллеги,

 

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

использовать на Cisco 5350(XM) протокол ОКС-7, выступая в качестве Call Agent'а.

 

К сожалению какой-либо более подробной информации, на это счёт я не нашёл.

Может кто-то уже реализовывал подобное? Поделитесь опытом, пожалуйста.

Edited by 2life

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this