Два sip-аккаунта одного провайдера в *
Разделение входящих звонков в разные контексты
|
Сообщений: 32
|
Два sip-аккаунта одного провайдера в *
Преамбула: имеется два логина и пароля (и соответсвенно два городских номера) у одного провайдера (хост для регистрации один и тот же)
Задача: разделить звонки в разные контексты.
Пишу в
users.conf
[provnum1]
trunkstyle = customvoip
username = username1
trunkname = trunk1
hassip = yes
hasiax = no
registersip = yes
host = provider.ru
dialformat = ${EXTEN:1}
context = context1
group =
insecure = invite
fromuser = username1
fromdomain = domain.provider.ru
secret = ******
disallow=all
allow=all
contact=dd
canreinvite=no
[provnum2]
trunkstyle = customvoip
username = username2
trunkname = trunk2
hassip = yes
hasiax = no
registersip = yes
host = provider.ru
dialformat = ${EXTEN:1}
context = context2
group =
insecure = invite
fromuser = username2
fromdomain = domain.provider.ru
secret = ******
disallow=all
allow=all
contact=dd
canreinvite=no
В результате , если звонить хоть на тот, хоть на другой номер - попадаем в один и тот же
контекст, который указан в последнем. Расскажите как разрулить?
Убедительная просьба - знаете как сделать , но есть жедание поглумиться гуглом или еще какйо нить батво - просто промолчите и не тратьте и мое и Ваше время!
|
|
Сообщений: 6521
|
Re: Два sip-аккаунта одного провайдера в *
Нужно не одна, а две регистрации
register => username1:secret1@provider.ru/username1
register => username2:secret2@provider.ru/username2
и принимать соответственно
exten => username1,1,Dial(SIP/1)
exten => username2,1,Dial(SIP/2)
|
|
Сообщений: 32
|
Re: Два sip-аккаунта одного провайдера в *
респектище!
|
|
Откуда: Уфа
Сообщений: 5856
|
Re: Два sip-аккаунта одного провайдера в *
xxor: Убедительная просьба - знаете как сделать , но есть жедание поглумиться гуглом или еще какйо нить батво - просто промолчите и не тратьте и мое и Ваше время!
зачод
|
|
Откуда: Омск
Сообщений: 478
|
Re: Два sip-аккаунта одного провайдера в *
Кстати, стоит заметить, что при такой работе с двумя провайдерами с одним из аккаунтов будут возникать проблемы: невозможность re-INVITE со стороны астериска, невозможность положить трубку со стороны астериска. Нормально будет работать только последний из содержащихся в sip.conf аккаунтов.
PS. Это я чтобы предвосхитить последующие вопросы
OpenSUSE 11.2 / Asterisk 1.6.x / Vicidial / UniMRCP
|
|
Откуда: Нижний Новгород
Сообщений: 277
|
Re: Два sip-аккаунта одного провайдера в *
IgorG: Кстати, стоит заметить, что при такой работе с двумя провайдерами с одним из аккаунтов будут возникать проблемы: невозможность re-INVITE со стороны астериска, невозможность положить трубку со стороны астериска. Нормально будет работать только последний из содержащихся в sip.conf аккаунтов.
Почему reInvite и Bye работать небудут? Там вся инфа о диалоге вроде хранится в sip_pvt который хранится в канале.
|
|
Откуда: Омск
Сообщений: 478
|
Re: Два sip-аккаунта одного провайдера в *
По-моему на данный момент ничего не поменялось и я не ошибаюсь.
1) Так как прописан insecure=invite, то при входящем INVITE авторизация не запрашивается. При этом при создании sip_pvt используется поиск среди пиров по ip-адресу и порту откуда пришел запрос. При этом всегда находится последний пир в конфигурации.
2) При каком-либо действии во время установленного диалога со стороны астериска он отправляет запрос.
3) Провайдер требует авторизации запроса и астериск берет информацию о пире, найденную во время установления соединения. Не нужно объяснять, что он получает бесконечные 401 и 403 :(
Проблема известная, пытался исправить, но в тот момент перешли на хранение объектов в astobj2, а создавать по всему chan_sip.c ещё одну хэш-таблицу для хранения пиров я не хочу.
OpenSUSE 11.2 / Asterisk 1.6.x / Vicidial / UniMRCP
|
|
Откуда: Нижний Новгород
Сообщений: 277
|
Re: Два sip-аккаунта одного провайдера в *
IgorG: По-моему на данный момент ничего не поменялось и я не ошибаюсь.
1) Так как прописан insecure=invite, то при входящем INVITE авторизация не запрашивается. При этом при создании sip_pvt используется поиск среди пиров по ip-адресу и порту откуда пришел запрос. При этом всегда находится последний пир в конфигурации.
2) При каком-либо действии во время установленного диалога со стороны астериска он отправляет запрос.
3) Провайдер требует авторизации запроса и астериск берет информацию о пире, найденную во время установления соединения. Не нужно объяснять, что он получает бесконечные 401 и 403 :(
Все верно - так все и будет - я то думал что говорим о решении который предложил ded.
Проблема известная, пытался исправить, но в тот момент перешли на хранение объектов в astobj2, а создавать по всему chan_sip.c ещё одну хэш-таблицу для хранения пиров я не хочу.
Кстати имхо врятли как-то получится решить данную проблему. Тут явно недостаточно информации чтобы однозначно определить верные username/password. Из 401/407 можно узнать только realm (иногда еще domain) и этого не достаточно чтоб понять какие username/password использовать если провайдер использует один и тот-же realm. Есдинственный способ это посылать все известные auth параметры используя множественные Authorization/Proxy-Authorization хидеры. Так как правило и делают и именно так написано в RFC. Но тут могут возникнуть проблемы с провайдером (он будет брать только первый найденный хидер) так как не все читают RFC :-) |
|
