вторник, 2 февраля 2010 г.

Asterisk (TrixBox) и SIP-trunk до VoIP от Сибирьтелеком в Кемерово

Начнём с того, что Сибирьтелеком - крупнейший оператор фиксированной связи в СФО в Кемерово предоставляет VoIP с сигнализацией SIP только для абонентов подключенных по ETTH (оптика). Та ещё песня получить такое соединение. Однако здесь опишу опыт настройки SIP-транка между Asterisk из коробки TrixBox и их чудесным железом, которое называется IskraTel SI3000.

Входящие вызовы оказалось настроить проще. Изначально конфиг SIP-peer содержит следующее:
host=10.0.25.2
type=peer
nat=no

disallow=all
allow=alaw
context=from-trunk
А чтобы звонки приходили естественно необходимо зарегистрировать свой номер на своём IP-адресе у провайдера. Для этого надо достать бумажный конверт с паролем доступа к SIP! (Да, да чтобы получить доступ к защищённой по всем статьям услуге надо съездить в офис и получить бумажные конверты на каждый городской номер :-) и указать строку регистрации:
[гор_номер]:[пароль]@10.0.25.2/[гор_номер]
где здесь и далее: [гор_номер]:[пароль] данные из бумажного конверта. Второй раз после "/" [гор_номер] обязателен, иначе у провайдера регистрируется экстеншн "s", что не есть правильно с точки зрения дальнейшей маршрутизации вызова внутри Asterisk. По всей видимости этого достаточно чтобы входящие из города стали попадать на IP вашего Asterisk, но этого недостаточно чтобы он их принял! Ведь peer (то есть провайдер) не регистриться у вас, как вы у него, поэтому надо в настройках SIP-peer добавить строку:

insecure=invite

После этого Asterisk без вопросов принимает входящие вызовы.

Исходящие вызовы
настраить удалось после нескольких опытов.
Опыт 1. С приведённым выше конфигом на наши INVITE сервер отпинывает следующим:
SIP/2.0 480 Temporarily Unavailable
Звоним провайдеру и он говорит: "вот мы сравниваем ваш INVITE с тем, который нормально обрабатывается и видим отличие". В ваших пакетах приходит какой-то короткий номер 2395 в строке:
From: "2395" ;tag=as55eb5
Давайте его уберём.
Не вопрос, дорогой провайдер, сделаем это следующим способом (для FreePBX в TrixBox) укажем Outbound Caller ID в настройках SIP-trunk в виде:
Outbound Caller ID <[гор_номер]>
либо в sip.conf строка:

callerid=[гор_номер]

Опыт 2.

После указанных изменений вновь делаем попытку позвонить на городской номер, наши INVITE сервер отпинывает следующим:
SIP/2.0 480 Temporarily Unavailable
Звоним провайдеру и он говорит: "вот мы сравниваем ваш INVITE с тем, который нормально обрабатывается и видим отличие. В ваших пакетах приходит какой-то странный атрибут "a=fmtp:101 0-16":

INVITE sip:316544@10.0.25.2 SIP/2.0
[skipped]
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 266

v=0
o=root 529554116 529554116 IN IP4 10.25.0.50
s=Asterisk PBX 1.6.0.9-samy-r27
c=IN IP4 10.25.0.50
t=0 0
m=audio 10258 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Давайте его уберём."
И вновь "
Не вопрос, дорогой провайдер" сделаем это следующим способом. Достаточно в настройках SIP-peer указать тип передачи DTMF в виде:
dtmfmode=info
После этого второй "не медийный" поток с кодом кодека "101 telephone-event/8000" не направляется к этому пиру. Это я узнал из RFC-3261 и как оказалось позже роли не играет!..

Опыт 3.
После указанных изменений вновь делаем попытку позвонить на городской номер, наши INVITE сервер отпинывает следующим:
SIP/2.0 480 Temporarily Unavailable
И в третий раз Звоним провайдеру и он говорит: "вот мы сравниваем ваш INVITE с тем, который нормально обрабатывается и видим отличие. В ваших пакетах приходит какой-то неправильный атрибут
"o=root 529554116 529554116 IN IP4 10..."
(см. INVITE выше). У других наших клиентов в этом поле приходит [гор_номер].

Должно быть как у всех".

читаем маны, доки, форумы и т.д. ищем как это сделать в Asterisk. И находим что это рулится только в секции [general] файла sip.conf обычного Asterisk, то есть для всех SIP-пиров и юзеров параметром:
sdpowner=-
в файле sip_general_custom.conf в TrixBox (точнее в FreePBX). Указываем именно "-", т.к. в стандарте (RFC http://tools.ietf.org/html/rfc4566#section-5.2) должен быть указан владелец (owner), либо "-" если система не поддерживает идентификаторы. Указать [гор_номер] как "советует" провайдер не возможно, в силу указанной выше причины (секция [general]).

Опыт 4.
После указанных изменений вновь делаем попытку позвонить на городской номер, наши INVITE сервер отпинывает следующим:
SIP/2.0 480 Temporarily Unavailable
И в четвёрный раз Звоним провайдеру и он говорит: "вот мы сравниваем ваш INVITE с тем, который нормально обрабатывается и видим отличие. В поле "From:" после @ вы указываете свой IP-адрес, а в вызовах которые нормально обрабатываются нашей АТС приходит IP-адрес НАШЕЙ АТС (!) 10.0.25.2 . Что делать? Опять гуглим, маним, и т.д. и т.п. и находим ещё один параметр конфигурации SIP-пиров отвечающий как раз за этот адрес в поле "From:" - fromdomain:
fromdomain (peer)

(This allows you to set the domain in the From: field of the SIP header. It may be
required by some providers for authentication:
fromdomain=my.hostname.tld -- врезка из Книги "Asterisk The Future of Telephony")
Как раз то, что требует от нас уважаемый провайдер! прописываем на каждом SIP-пире этот параметр и.. внимание!!!... (барабанная дробь!!!) ЗАРАБОТАЛО!!!!

На всё-про-всё у меня ушло 3 рабочих дня, практически без отвлечения на другие задачи. Ну да, эту запись в блог я тоже в процессе поисков записывал :-)

ИТОГО
Оказалось что изменения в "Опыт 2" не играют роли для исходящих вызовов, т.е. строка

dtmfmode=info
Важна только для DTMF. Таким образом у меня в настройках SIP-пира получилось следующее:

host=10.0.25.2
type=peer
nat=no
disallow=all
allow=alaw
context=from-trunk
insecure=invite
fromdomain=10.0.25.2
и обязательно нужно выставлять Caller ID именно городской номер (см. Опыт 1), иначе Asterisk выдаёт туда местный номер, что не есть правильно :-).

PS: для работы DTMF надо добавить
dtmfmode=inband
Другие варианты передачи DTMF SI3000 не понимает.

Комментариев нет:

Постоянные читатели