Вопрос про собственный домен
- В этой теме 42 ответа, 2 участника, последнее обновление 9 лет, 5 месяцев назад сделано
.
-
Сообщения
-
Попробуйте поменять команду диала на своём Asterisk типа такого:
exten => s,n,Set(_SIPFROMDOMAIN=вашдомен)
exten => s,n,Dial(SIP/${EXTEN}@вашдомен,60,rtS(1800))т.е. использовать SIPURI dial
Мой тест с другого сервера прошёл успешно. Напишите, получилось ли?Благодарю. ближе к вечеру смогу попробовать (сейчас нет доступа к конфигурированию астериска).
Так-то у меня набор через внешние транки сделан на macro-trunkdial, которому аргументом передаётся строка типа SIP/talk37/${EXTEN}. Когда я менял эту строку на SIP/talk37/${EXTEN}@домен , набор переставал проходить сюда, на сервис. Хотя по идее должен был бы. Видимо, астериск напрямую ломился на домен, а там была тишина.О чём ещё подумалось: жаль, что для входящих нельзя задать правило замены номера, как у исходящих. Т.е. чтобы если адресат скажем 5%, то переходить на 5%@домен. Одно такое правило могло бы вполне успешно решить проблему.
В общем, попробовал, результат аналогичен предыдущим попыткам: в трубке – тишина, вызываемый телефон не звонит, в истории на Talk37 ничего нет.
А в истории Asterisk вот такая запись:Record 1284, ID: 1431709846.1382 (Outbound call)
Timestamps: 2015-05-15 20:10:46, , 2015-05-15 20:10:57
Durations: 0:00:11, 0:00:00
Disposition/AMA flags: NO ANSWER / DOCUMENTATION
CallerID: “StrogVideo” <6004> Source: 6004 Destination: 5002
Source Channel: SIP/6004-41709bd0
Destination Channel: SIP/<домен>-002dd3b0
Context: DLPN_DialPlan1 Application: Dial Data: SIP/talk37/5002@<домен>||wWВ то время как при звонках без указания домена Destination Channel указывался как talk37. Т.е. похоже, что по-прежнему астериск пытается звонить напрямую на домен…
Вместо Dial Data: SIP/talk37/5002@<домен>||wW
нужно указать: Dial(SIP/5002@<домен>
т.е. убрать указание пира. Это uri dial
чтобы это работало, скорей всего нужно ещё включить srvlookup=yesP.S. Замену во входящих сделаю. Только найду чуть времени на это… тяжёлая неделька выдалась.
Да, действительно я не совсем по примеру пробовал. Теперь полностью скопировал Ваш пример:
Record 1287, ID: 1431712399.1405 (Outbound call)
Timestamps: 2015-05-15 20:53:19, 2015-05-15 20:53:21, 2015-05-15 20:53:45
Durations: 0:00:26, 0:00:24
Disposition/AMA flags: ANSWERED / DOCUMENTATION
CallerID: “” <6002> Source: 6002 Destination: 5002
Source Channel: SIP/6002-41714ce0
Destination Channel: SIP/<домен>-002dae28
Context: DLPN_DialPlan1 Application: Dial Data: SIP/5002@<домен>|60|rtS(1800)Теперь в трубке появился КПВ (3CX пишет “Ringing”), статистика почему-то говорит, что звонок ANSWERED. Но звонок по-прежнему не доходит до сервиса…
Включённый srvlookup, помнится, приводил к полному падению астериска при отключении интернета, из-за чего не очень бы хотелось его снова включать…
Замена во входящих кстати есть (невнимательно смотрел!), но в данном случае она почему-то не работает. Возможно потому, что входящие правила почему-то всегда проверяются для номера 5001@домен, независимо от того, на какой именно номер звонят? Да ещё и этот номер больше не опознаётся, как мой. Вот если бы это починить, было бы здорово.
В принципе есть ещё один более-менее рабочий вариант: назначить всем устройствам внутренние номера, например 5001 – 001, 5002 – 002, и на астериске прописать правило убирать первую цифру номера на этом направлении. При этом звонки со шлюза на внутренние проходят, но есть одна беда – при исходящих на шлюз начинают определяться не назначенные номера (5001, 5002), а внутренние трёхзначки. Хотя в настройках этих линий и указаны соответствующие исходящие номера (5ххх@домен).Включил ради любопытства srvlookup=yes, теперь на вызывающей стороне проходит один гудочек и потом мой Asterisk радостно сообщает, что номер не подключён (сообщение, которое возникает при наборе несуществующих номеров). Внутренний номер 5002@домен, на который звоним, молчит. Но в статистике появляется стандартная запись о неудавшемся входящем звонке, точно такая же, как когда звоним просто на 5002 без указания домена. Чертовщина какая-то.
Теперь ещё беда: с внутреннего 5003, на котором принудительно включён G729, теперь никуда не позвонить, даже на внутренние! Пишет 488 Not acceptable here. Причём этих звонков нет в истории, даже как неудачных! Хотя регистрация на сервере проходит успешно.
Вчера с теми же самыми настройками работало нормально.Что-то пропустил эти ответы в теме 🙁
srvlookup=yes необязательно включать, т.к. хост сервера (talk37.ru) соответствует физически машине, на которой стоит SIP сервер.
Очень хотелось бы увидеть логи звонка с “чертовщиной какой-то”.
А так же с кодеком G729. Судя по логам последним сегодняшним звонком с Вашим устройством с кодеком g729… принимающая сторона выдавала BUSY через 5 секунд после начала звонка.
В сервисе немало устройств и шлюзов с этим кодеком. Давно никто не жаловался на проблемы с ним.
@Dominique, если возможно, свяжитесь со мной любым удобным способом по icq, jabber, skype: https://talk37.ru/about/
в том числе попытаемся разобраться и с 500-ой ошибкой.Дело в том, что в логах как раз отображены успешные звонки, которые проходили при выключении кодека g729 в настройках учётной записи… с включённым кодеком ничего не работало и в истории записи не появлялись.
Свяжусь, спасибо.
Реализовал возможность сохранения исходного номера адресата при входящих через внешние учётные записи.
для этого нужно отключить “Адресат при входящих” в настройках внешней учётной записи (блок “Правила трансформации CallerID”). И в этом случае появляется строка с правилами трансформации строки “to” (адресата).Я настроил в Вашей внешней учётной записи правила трансформации: /^5(\d{3}$/=$1@домен
Это должно помочь.Хм… теперь входящие с транка проходят, НО:
1) не передаётся номер вызывающего абонента, вместо него идёт мой номер в сервисе
2) перестали проходить исходящие на этот транк!:((
Так, пардон, п. 2) снимается, остаётся только п. 1).
Нельзя ли как-нибудь сделать корректную передачу номера, сообщаемого астериском?Прошу ещё разок попробовать разные направления и пути прохождения, проверить CallerID.
По поводу звонков в skype, набора номера skype#логин. Проблема именно в том, что при звонках с устройств прибавляется к адресату домен.
Хочется убрать правило.. что при звонках с устройства, в котором в номере исходящего стоит свой домен к каждому номеру добавлять этот же домен. Лучше для устройства указывать правила преобразования номера адресата (как для шлюза). Для этого добавил такую настройку у устройств. Но пока не поддержал эту настройку. Надо ещё обдумать это…Спасибо большое за потраченное время и вообще за всё. Значит, отчитываюсь:
1) Звонок с внутренних на шлюз проходит отлично
2) Звонок со шлюза на внутренние также проходит отлично, вызывающий номер определяется корректно
но:
3) Теперь перестали работать звонки между внутренними :(( Просто не проходят и всё, сообщений об ошибках нет. В истории звонков всё вроде выглядит нормально, непонятно в чём может быть дело.Что касается скайпа и прочего: думается, многие вопросы удалось бы снять, если бы правила Исходящих были едиными, т.е. можно было создавать их в том числе для внутренних звонков. В этом случае можно было бы соорудить простой и понятный диалплан, например:
– если номер начинается на 5, добавляем к нему домен и это внутренний звонок
– если номер начинается на 6 и он из 4 цифр, это звонок на шлюз
– все остальные номера – это внешние звонкиКак-то так.
Update на 13:25:
Внутренние звонки заработали. Звонки со шлюза проходят, номера определяются. Звонки на шлюз тоже проходят, НО: только на номера 6ххх. Правило /^7(\d{3})$/ больше не срабатывает, при проверке номера пишется"Нашли! Номер соответствует шаблону '%'Направление: "Все публичные"."
Пробовал также заменить его на /^7(\d{3})$/@домен, всё равно не работает.И ещё раз проверяем.
Сейчас именно так и настроил. Должно работать.
В том числе и скайп должен работать.
- Для ответа в этой теме необходимо авторизоваться.