Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
[БАГ/ЗАПРОС ФУНКЦИИ] UniFi Talk – Исходящий план набора добавляет код страны независимо от формата номера – 3 года без исправления, UniFi Talk
 
**[БАГ/ЗАПРОС ФУНКЦИИ] UniFi Talk – Исходящий план набора добавляет код страны независимо от формата номера – 3 года без исправления**

Открываю это обсуждение, чтобы привлечь внимание к критической и давней проблеме с поведением исходящего плана набора UniFi Talk, о которой сообщалось множество раз за последние три года, но Ubiquiti так и не решила её.

**Ссылки:**

- https://community.ui.com/questions/Talk-dialplan-adds-country-code-based-on-IP-how-to-disable-it/72229cc1-9917-4459-953e-29498e4be8d3
- https://community.ui.com/questions/Dial-Plans-Unifi-Talk-Feature-Request/1a5cf7dd-2b81-4877-a01c-be8e27248e43
- https://community.ui.com/questions/Unifi-Talk-Dial-Plan-For-3rd-Party-Sip/17dcfc9a-7ea1-4061-afd0-aada5f264689
- https://community.ui.com/questions/UNIFI-TALK-3rd-party-SIP-outbound-prefix/a210245f-0b21-44c8-a8e8-0bb26cb96e34

---

**Проблема**

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

При использовании стороннего SIP-транка с провайдером, который ожидает номера в формате E.164 (например, +39XXXXXXXXXX для Италии), получается двойной код страны: **3939XXXXXXXXXX** — из-за чего каждый исходящий звонок завершается ошибкой FAILED (1) на стороне провайдера.

Точно та же проблема возникает с переадресацией вызовов, настроенной в IVR: контакты, сохранённые с префиксом +39 (который сам UniFi Talk навязывает через выпадающий список), получают двойной префикс, когда IVR пытается переадресовать вызов наружу.

**Моя конфигурация:**

- UniFi Dream Machine / UniFi Talk
- Сторонний SIP-транк (итальянский провайдер, NavigaBene VoIP)
- IVR настроен в UniFi Talk с переадресацией на мобильные номера
- Страна: Италия

**Доказательства из журнала вызовов – каждая исходящая переадресация падает:**

```
Called To: 3939333XXXXXXX → FAILED (1)
Called To: 3939333XXXXXXX → FAILED (1)
```

**Чего не хватает**

Каждая серьёзная платформа PBX — Asterisk, FreeSWITCH (на котором, кстати, работает сам UniFi Talk), 3CX, FreePBX — предоставляет базовые правила исходящего плана набора: удалить цифры, добавить цифры, сопоставить по шаблону. UniFi Talk ничего из этого не даёт.

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

**Что мы просим**

Это не запрос какой-то экзотической функции. Это базовый функционал для любой интеграции SIP-транка за пределами США:

1. Опция в интерфейсе для отключения автоматического добавления кода страны
2. ИЛИ базовые правила исходящего плана набора (удалить N цифр, добавить строку, сопоставить по regex)
3. ИЛИ как минимум официальная документация о том, как безопасно и постоянно кастомизировать нижележащий план набора FreeSWITCH

Ubiquiti продвигает UniFi Talk как телефонную систему бизнес-класса. Бизнес за пределами США существует. SIP-транки за пределами США существуют. Этот баг открыт уже **три года**. Клиенты, заплатившие за это железо, заслуживают исправления — или, по крайней мере, официального признания, что это в роадмапе.

Пожалуйста, ставьте плюс, если вы тоже пострадали. Давайте шуметь.
 
ок - итак, в момент отчаяния я решил попробовать канал раннего доступа и, о чудо, - там есть опция исходящего набора номера либо в +e.164, либо в e.164 - выбор e.164 мгновенно решил проблему. Спасибо!! Ушло дней и дней на отладку, возню и тестирование, чтобы дойти до этого момента - но по крайней мере мы это сделали, и теперь у меня есть телефонная система, которой я могу пользоваться!
 
есть идеи когда? Я только что попробовал настроить сторонний sip с Spitfire здесь, в Великобритании. Всё работает, КРОМЕ исходящих звонков, потому что unifi-talk ставит '+' перед набранным номером (e164), а spitfire отвечает:SIP/2.0 416 Spitfire говорит, что в этой схеме URI допускаются только цифры.spitfire ожидает номер в формате 44xxxxxxxxxxx.Они не будут менять настройки на своей стороне, вместо этого говорят, что мне нужно изменить шаблон набора на unifi talk. Я могу подтвердить, что это так, зайдя по ssh на unifi и запустив fs_cli и вручную набрав правильный номер через:originate {origination_caller_id_number=44YYYYYYYYYY,origination_caller_id_name=Test}sofia/gateway/spitfiretsp.net.6/44XXXXXXXXXX &echo где YY — мой номер, а XX — внешний номер, который я набираю — звонок проходит нормально. С +44XX не работает.Я купил несколько телефонов и контракт со Spitfire, который теперь бесполезен. так что пожалуйста, пожалуйста, выпустите решение быстро!
 
У тебя получилось? Я пробовал кучу правок в xml, но всё без толку. Буду очень благодарен за любой совет.
 
Привет, я только что развернул unifitalk в своем офисе, после изучения обнаружил, что он работает с aussie broadband, но теперь у меня проблемы, и, похоже, дело в формате e.164, который отправляется для исходящих звонков, для входящих работает отлично, обожаю эту систему, но нужно не отправлять код страны, только номер как набран. У кого-нибудь есть мод dialplan, который я могу сделать в интерфейсе/бэкенде freeswitch, чтобы обойти это, или порекомендуйте простую настройку, чтобы пропускать звонки через что-то как обходной путь, ужасный обходной путь, но хотя бы я смогу заставить всё работать
 
Команда уже занимается этим — будем держать тебя в курсе. Спасибо за терпение!
 
@UI-Team есть новости по этому?
 
В настройках Custom Fields в разделе Third Party SIP: если добавить “extension-in-contact” со значением ‘true’ и “extension” с вашим номером телефона без +1 — это решит проблему? Также убедитесь, что DID-номера, которые вы добавляете в настройках Third Party Sip, не содержат +1. Возможный минус: все ваши заголовки CONTACT будут тем номером, который вы указали в “extension”. SBC вашего SIP-провайдера *может* перезаписать поле CONTACT номером из FROM, и таким образом, возможно, проблема решится ещё до SBC. Источник: https://community.ui.com/questions/17dcfc9a-7ea1-4061-afd0-aada5f264689?replyId=88ce46f4-dc17-4403-84f4-c705f55d5586
 
Та же история, но мне помогло переключение с PCMU на PCMA аудио.
 
Столкнулся с той же проблемой. Не знаешь, какой файл мне нужно отредактировать через SSH?
Страницы: 1
Читают тему (гостей: 1)