Правила набора

Тема в разделе 'Настройки', создана пользователем LiberalVoip, 15 окт 2011.

Страница 1 из 5

  1. LiberalVoip Guest

    Настройка правил набора, преобразование номеров, маршрутизация вызовов на разных провайдеров. Одна из основных возможностей нашего сервиса – выбор провайдера для исходящих звонков в зависимости от направления. Для управления этими возможностью предназначен раздел настроек «Правила набора», который Вы можете выбрать в меню. Перед тем как приступить к настройке, Вам необходимо завести как минимум одного провайдера. Подробнее [...]

    Читать дальше...
    LiberalVoip, 15 окт 2011
    #1

  2. Ana New Member

    Завершил настройки, но не пойму почему не проходит звонок с сип-линии наружу. Провайдер индицирован как зарегистрированный. Проверка диал-плана - проходит правильно, в требуемом формате и на требуемого провайдера. В статистике вижу звонок: "Вх. номер - ххххххххх" "Откуда - моя сип-линия", дальше все пусто. На трубе, само собой - занято.
    Ana, 2 дек 2011
    #2

  3. Bell Developer

    Линии, с которой Вы звоните назначен план набора Default, а в нем нет ни одного префикса.
    Мы не до конца описали процесс настройки, исправимся.
    Сейчас сделайте следующее - удалите все планы набора, кроме Default, а в нем создайте все нужные правила-префиксы - 7,79,7495,7499
    Bell, 2 дек 2011
    #3

  4. Ana New Member

    ОК, теперь понятно. Привязка идет отдельно к каждой сип-линии. Т.е. это не общее правило. Плавно пробую переезжать с voxalot. Кстати, voxalot не поддерживал Т.38. А у вас как?
    Ana, 2 дек 2011
    #4

  5. Bell Developer

    T.38 должен поддерживать Ваш провайдер, с нашей стороны никаких препятствий нет.
    В ближайшее время в тестовом режиме будет запущена конвертация факсов G.711T.38
    Bell, 2 дек 2011
    #5

  6. Ana New Member

    Спасибо за ответ. все передалано и работает. Конечно оффтоп, ну уж для завершения беседы: полезно было бы ввести в персональные настройки установку часового пояса пользователя. А то статистика по мировому времени не всегда удобна
    Ana, 2 дек 2011
    #6

  7. Bell Developer

    Это пожелание нам уже высказывали неоднократно, сделаем в ближайшем обновлении.
    Bell, 2 дек 2011
    #7

  8. Lazy Badger New Member

    Спрошу в этой теме, чтобы не плодить сущностей
    1. То ли не читал, то ли не понял, то ли забыл. Какая политика обработки паттернов в плане: any match, more specific, last hit? Т.е могу ли я логически разделять обработку по паттернам для номера (810 отрезать отдельным правилом, оператора выбрать следующим - пример)
    2. Порядок паттернов (показываемый == реальный ?) в плане может учитываться/учитывается? Catch-all % надо ли переносить в хвост?
    3. Совсем не понял, как просто определить паттерны (если надо) для набора локальных либеровоипных (хотя бы своих) СИП-линий, так то они уходят на стандартный транк наружу. Пять правил, где паттерн - полный номер линии, а destination - сама линия, не предлагать: это нетехнично
    4. Паттернами могут быть куски sip-uri? Надо бы иметь такую возможность
    Lazy Badger, 4 дек 2011
    #8

  9. Bell Developer

    В настоящее время логика такая.
    Если номер полностью совпадает с номером какой либо линии - вызов считается внутрисетевым и уходит на sip-линию. Дополнительно ничего прописывать не надо. Если уходит на транк - это ошибка, нужно проверять.
    В противном случае задействуется поиск маршрутизации. По номеру вызывающей линии ищется план набора. В нем ищется первый максимально совпадающий префикс, те самый длинный, и в соответствии с ним определяется провайдер. % используется, если другие префиксы не найдены. Порядок правил не важен, приоритет определяется именно длиной.
    По поводу п.4 - не понял, поясни, пожалуйста.
    Bell, 4 дек 2011
    #9

  10. Lazy Badger New Member

    Внутренние звонки проверил - и точно, работают, это в проверке диалплана оно показывало мне внешний вызов.
    По sip-uri: наверняка не скажу новость, если вспомню, что в полном виде адрес в СИПе - не чистые только цифры, а полноценный URI localpart@domainpart, где и localpart и domainpart - алфавитноцифровые, что использование URI иногда нужно (а возможно - всегда) и что софтфоны и некоторые железнофоны SIP-URI набирать позволяют. Так вот в некоторых вычурных случаях в диалплане здесь возникает потребность использовать нецифры в префиксе (пример - для гейтования в скайп через сипнетовский гейт вызывается , skypename@skype просится прямо в префиксы), о возможности такой и спрашиваю
    Lazy Badger, 5 дек 2011
    #10

  11. Bell Developer

    Проверку диалплана - проверим. Возможно, что есть ошибка и внутренние номера не учитываются.
    А вот вычурных случаев преобразования ivan@skype в , да еще и в промышленных масштабах, пока представить не могу. Но обещаю подумать.
    Bell, 5 дек 2011
    #11

  12. Lazy Badger New Member

    Да преобразования и не надо (даже простого). Надо просто поддерживать возможность использования букв в префиксе, чтобы:
    • префикс "user@skype" работал для вызова (этого же юзера user) через скайп-гейт нужного провайдера (частный случай);
    • при использовании полного SIP-uri (с буквами в логине и наличием @ в адресе) можно завернуть в диалплане такой префикс на требуемого провайдера (не все позволяют вызовы внешних URI, приходится это учитывать) - более общий вариант, вспоминаем, что сип-операторов много, разных, у всех иметь акки (чтобы выховы были локальными) глупо и просто не нужно
    Lazy Badger, 5 дек 2011
    #12

  13. Bell Developer

    Буквы в префиксе использовать можно, мы не против.
    Создаем правило префикс user@skype , набирать как , провайдер sip-uri. Профит.
    По поводу разницы между звонком на sip-uri и звонком через провайдера я уже писал в другой теме.
    Технически они отличаются только авторизацией.
    Вызываемый абонент всегда формируется аналогично email: user@host
    Соответственно, мы даем две возможности
    1. Звонок через провайдера. Берется вызываемый user, в нему добавляется host из настроек провайдера и вызов идет на user@host. Используется станартная для SIP digest авторизация, если провайдер ее запросит.
    2. Если заведомо известно, что провайдер принимает звонки без авторизации - можно применить упрощенную схему, без заведения провайдера.
    В этом случае сразу указывается user@host. Все. Если авторизация будет запрошена - вызов не состоится.

    Те авторизация на сервере провайдера либо нужна, либо не нужна.
    Из твоих объяснений я понял, что хочется получить что-то типа user@
    Так не бывает.
    Точнее бывает, в случае существования нескольких доменов на одном host. Но, как и в случае с email, это решается DNS. Те все домены должны иметь либо A запись, либо SRV для sip(аналог mx для email).
    Если есть провайдер, не удовлетворяющий этим требованиям - готов его посмотреть
    Bell, 5 дек 2011
    #13

  14. Lazy Badger New Member

    Ясно, я этого просто не знал, и в примерах префиксов не видел. Раз полный sip-uri можно, жить значительно легче

    Значит невнятно объяснял. Нет, для скайп-гейтования нужен нормальный URI | в моем случае
    Lazy Badger, 5 дек 2011
    #14

  15. Bell Developer

    А откуда берется URI ?
    Bell, 5 дек 2011
    #15

  16. Lazy Badger New Member

    Передается с клиента, если я правильно понял вопрос. А в общем случае - зная логин скайповый, пользователь(человек) строит URL по правилам гейта, по формату все равно получается sip-uri
    Lazy Badger, 5 дек 2011
    #16

  17. Bell Developer

    Такой URI не может передаваться с клиента. Все, что я написал про формирование URI для исходящих от LiberalVoip вызовов, верно и для входящих от клиента к LiberalVoip.
    Те приходит запрос с полем To в котором те же самые user@host. Только в этом случае host - liberalvoip.net или IP адрес. Неоткуда взяться на нашем сервере.
    Bell, 5 дек 2011
    #17

  18. Lazy Badger New Member

    Как "не может"? Если я сам при вызове набираю вызываемого в виде (или выбираю из адресбуки) в виде SIP-URI?!
    Lazy Badger, 5 дек 2011
    #18

  19. Bell Developer

    Опять возвращаемся к разговору о sip-uri вида user@
    SIP-клиент, при наборе sip-uri должен сделать следующее.
    1. По домену определить сервер. Обычно сначала делается попытка определить SRV запись в DNS вида _sip._udp.domain или _sip.tcp.domain. Такая запись возвращает информацию о sip-серверах обслуживающих данный домен. Например
    Код: 
    ivan$ nslookup -q=srv _sip._udp.liberalvoip.net
Server:        10.0.1.1
Address:    10.0.1.1#53

Non-authoritative answer:
_sip._udp.liberalvoip.net    service = 1 1 5060 liberalvoip.net.
    Из результата видно, что сервер - liberalvoip.net , порт 5060
    Если такие записи не найдены, клиент пробует найти A запись по имени домена
    Код: 
    ivan$ nslookup -q=a liberalvoip.net
Server:        10.0.1.1
Address:    10.0.1.1#53

Non-authoritative answer:
Name:    liberalvoip.net
Address: 213.133.98.3
    После этого клиент и отправляет на найденный сервер Invite с полем To user@domain
    Принимающий сервер должен обработать этот инвайт, "узнать" свой domain и определить, что сделать с вызовом.
    Но, главное, никакого отношения к серверу, на котором этот клиент зарегистрирован с какими то учетными записями, такой вызов отношения не имеет.

    Вкратце, упрощенно, но как то так.

    Дополню все таки.
    Есть еще механизм sip-proxy. Аналогично HTTP-прокси, он должен принять от клиента запрос, обработать его каким либо способом и отправить вызов по назначению. Тогда да, описанный выше механизм не работает на стороне клиента, со всей логикой обработки доменов разбирается прокси-сервер. Но тут многое зависит от реализации клиента. Он может "правильно" отправить To user@domain, а может и user@ip, поэтому мы на такой механизм никогда особо не рассчитывали.
    Bell, 5 дек 2011
    #19

  20. Lazy Badger New Member

    Возможно я туплю нещадно, но как это связано с вызовом SIP-абонента с доменной частью @skype.sipnet.ru? @ в localpart использовать все равно нельзя по закону
    Lazy Badger, 6 дек 2011
    #20
Страница 1 из 5

Поделиться этой страницей

Tweet