ticket summary component version milestone type owner status created modified _description _reporter 362 Окончание FxS не реагирует на изменение СУВ any 1 очередь баг anatoly assigned 2021-04-05T11:22:56+05:00 2021-06-08T17:58:25+05:00 "1. Создал на плате VE-02 окончание FxS 1. Со стороны коммутатора TDM изменяю значение СУВа для таймслота соответствующего окончанию с 1 на 0. 1. Ожидаю, что окончание перейдёт из состояния Idle в Dialtone, однако этого не происходит. Посмотреть на это можно в блоке 192.168.1.104, VE-02 в слоте 5, окончание FXS в канале 2. Ревизия ПО VE-02 - 24" san 441 Инверсия СУВ в окончании FXO any 1 очередь задача alx new 2024-09-11T15:40:39+05:00 2024-09-13T14:33:49+05:00 "У наших пользователей довольно часто встречается стыковка нашего оборудования с TDM каналом FxO приходящим от аппаратуры производства RAD. Ранее схема стыковки выглядела так: {{{ FXO(RAD) <-> E1 <-> FS-08 }}} Особенность аппаратуры RAD в том, что активное состояние СУВ в ней передаётся не нолём, а единицей(толи это нельзя изменить в конфигурации, толи никто не умеет, но вот так оно есть). В связи с этой особенностью для успешной стыковки нам потребовалось: 1. В плате FS-08 добавить возможность инверсии СУВ 2. При инверсии наблюдается один негативный эффект - при обрыве линии E1, в сторону FS-08 будет сформирован сигнал AIS, который интерпретируется как активный СУВ и все телефоны начинают ложно звонить. В связи с этим, Толя решил добавить условие при включенной настройке инверсии - если все 4 входящих СУВ = 1, это считается неактивным СУВ. Это решило проблему ложных звонков при обрыве линии (один из СУВ, со стороны RAD всегда передаётся нолём, а при AIS вместо него передаётся 1, кажется это ""СУВ c""). Это всё была предыстория :) Теперь к теме тиета: В связи с постепенным переходом сервисов пользователей в IP, у пользователей изменилась схема связи, теперь она выглядит так: {{{ FXO(RAD) <-> E1 <-> VE-01(окончание FxO) <-> IPАТС }}} И теперь в окончание FXO платы VE-01(и VE-02) тоже требуется добавить возможность стыковки через TDM с аппаратурой RAD - инверсию СУВа с ""защитой"" от ложного вызова при сигнале AIS." san 159 Snmp падает после запроса VE-02 1 очередь баг alx new 2016-03-25T11:55:03+05:00 2016-03-25T16:14:53+05:00 Get Bulk 1.3.6.1.4.1.2021.11.62.0 san 257 Падение при невалидном сертификате any 1 очередь баг alx new 2017-11-24T17:39:11+05:00 2018-12-12T18:50:35+05:00 "Пару раз после изменения конфигурации платы VE-01 sip_ua падал со следующим выводом: {{{ sip_ua[4378]: poller.cpp:771: ===> command globalconf received sip_ua[4355]: adase.cpp:197: ---> ts=120, state=Idle: Channel settings, ts=-1, flags=0001, data=0 sip_ua[4355]: fxo.cpp:336: ---> ts=124, state=Idle: Channel settings, ts=-1, flags=0001, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=125, state=Idle: Channel settings, ts=-1, flags=0001, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=126, state=Idle: Channel settings, ts=-1, flags=0001, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=127, state=Idle: Channel settings, ts=-1, flags=0001, data=0 sip_ua[4355]: adase.cpp:197: ---> ts=120, state=Idle: Channel settings, ts=-1, flags=0002, data=0 sip_ua[4355]: fxo.cpp:336: ---> ts=124, state=Idle: Channel settings, ts=-1, flags=0002, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=125, state=Idle: Channel settings, ts=-1, flags=0002, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=126, state=Idle: Channel settings, ts=-1, flags=0002, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=127, state=Idle: Channel settings, ts=-1, flags=0002, data=0 sip_ua[4378]: poller.cpp:771: ===> command callgroups received sip_ua[4378]: poller.cpp:771: ===> command routes received sip_ua[4378]: poller.cpp:771: ===> command userlist received sip_ua[4378]: user_agent.cpp:182: User directory updated sip_ua[4355]: adase.cpp:197: ---> ts=120, state=Idle: Channel settings, ts=120, flags=0000, data=0 sip_ua[4355]: fxo.cpp:336: ---> ts=124, state=Idle: Channel settings, ts=124, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=125, state=Idle: Channel settings, ts=125, flags=0000, data=0 sip_ua[4355]: adase.cpp:197: ---> ts=120, state=Idle: Channel settings, ts=120, flags=0000, data=0 sip_ua[4355]: fxo.cpp:336: ---> ts=124, state=Idle: Channel settings, ts=124, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=125, state=Idle: Channel settings, ts=125, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=126, state=Idle: Channel settings, ts=126, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=127, state=Idle: Channel settings, ts=127, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=126, state=Idle: Channel settings, ts=126, flags=0000, data=0 sip_ua[4355]: fxs.cpp:419: ---> ts=127, state=Idle: Channel settings, ts=127, flags=0000, data=0 sip_ua[4378]: poller.cpp:771: ===> command sslapply received WARNING | 20171124-122101.524 | repro | RESIP:TRANSACTION | 14350 | TransactionController.cxx:67 | On shutdown, there are Client TransactionS tates remaining! WARNING | 20171124-122101.526 | repro | RESIP:TRANSACTION | 14350 | TransactionController.cxx:72 | On shutdown, there are Server TransactionS tates remaining! sip_ua[4378]: repro.cpp:1023: ----> MyReproRunner::addTransports() called ERR | 20171124-122101.605 | repro | RESIP | 14350 | ssl/Security.cxx:432 | Could not load X509 cert from '-----BEGIN CERTIFICATE----- MIIDfjCCAmagAwIBAgIJAIQpzhHWwDIBMA0GCSqGSIb3DQEBBQUAMB8xDzANBgNV BAMTBkFEQyBDQTEMMAoGA1UEChMDQURDMB4XDTE0MDkyNTEyNDgwNFoXDTIwMDky MzEyNDgwNFowJTEVMBMGA1UEAxMMMTkyLjE2OC4wLjY5MQwwCgYDVQQKEwNBREMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFAo7IzjEjiJ7wZ+4a7Mv QsSiqbM0HaDMIVhWkvSxA6gyJiZH20mNoUhrsIHXVzgUMKUbchYAuLqHe0qmdtc6 HgfA8j2R57SbuK/mF/IWA8VFyG5O7+6EShFfBChFc1Hjoh58QLflupoXkituObj3 LwcPskY4PeMnwAUQIDFmQ2KXYP5bXBDqBUfp5VvymgztY1Zfwtd5MKAPv50V47gk ZFunamC1Xc28YLp5lGfVGtnPhgPsM0BZGkWgfhF6yd1l4NfZ1ZbGWHJtneTtDAGu G3n7qc1JD7ksmxCy5D0muYuppbDLAWjjZ3Yd73CdZ8aBCirlm5QMMjMxUK6kWEln AgMBAAGjgbYwgbMwHQYJYIZIAYb4QgENBBAWDkZTIFNlcnZlciBDZXJ0MAkGA1Ud EwQCMAAwHQYDVR0OBBYEFPG2aFjId5Om11BHJmFjI5T96FzkME8GA1UdIwRIMEaA FPQr1ut115S5is4Os2+BviaEva6HoSOkITAfMQ8wDQYDVQQDEwZBREMgQ0ExDDAK BgNVBAoTA0FEQ4IJAKXfuWVq/z5WMBcGA1UdEQQQMA6CDDE5Mi4xNjguMC42OTAN BgkqhkiG9w0BAQUFAAOCAQEAdS/' Likely a port is already in use sip_ua[4378]: poller.cpp:771: ===> command ctime received sip_ua[4378]: poller.cpp:771: ===> command callgroups received sip_ua[4378]: poller.cpp:771: ===> command routes received root@comcerto:/# }}} Здесь сразу две проблемы: * непонятно почему файл сертификата оказался не полным; * sip_ua упал. Надо, как минимум, устранить падения при неполном файле сертификата. Предлагается проверять его валидность прежде чем пробовать пересоздать транспорт SSL." alx 282 "Избавиться от передачи данных как ""хэш в хэше""" any 1 очередь баг alx new 2018-10-17T13:58:41+05:00 2018-10-17T13:58:41+05:00 "Сейчас некоторые конфигурационные данные передаются от SW-01 в VE-01 в форме ""хэш в хэше"" с двойным кодированием, то есть один хэш (JSON-объект) кодируется в строку и помещается в другой хэш как строка. В настоящее время так передаются список групп вызова и маршруты SIP. Такое двойное кодирование плохо тем, что внутренний хэш содержит кавычки (""), которые дополняются обратным слэшем при кодировании внешнего хэша, что увеличивает размер строки и может привести к тому, что результат не поместится в пакет для передачи плате. В результате VE-01 не получит список групп вызова и/или маршрутов. Предлагается изменить способ передачи плате VE-01 подобных списков: передавать список по элементам, предполагая, что один элемент (одна группа вызова и/или один маршрут) гарантированно поместятся в один пакет. Для определения начала и конца списка передаваемый хэш дополняется ключами ""start"" или ""end"" (подобно тому, как это делается при передаче списка пользователей). Для обратной совместимости (старая прошивка SW-01 и новая прошивка VE-01) плата VE-01 должна проверять ключ ""data"", наличие которого будет говорить о том, что данные передаются старым способом. Для прямой совместимости (старая прошивка VE-01 и новая прошивка SW-01) SW-01 должна проверять, поддерживает ли VE-01 новый метод передачи списков. Сделать это можно: - проверкой флага FEATURES (но нужна гарантия, что эти флаги будут получены платой SW-01); - проверкой наличия какой-то переменной в MIB платы VE-01 после его получения; - чтением какой-то переменной (например ревизии прошивки); - запросом ревизии прошивки сообщением типа 3 командой 1. В качсетве workaround уменьшить максимальный размер передаваемого фрагмента данных с 900 до 450 байт - такой фрагмент должен поместиться в буфер пакета даже если он целиком состоит из кавычек, и поэтому перед каждым символом будет добавлен ""\""." alx 284 Нет отбоя у вызывающего после включения DHCP VE-02 1 очередь баг alx new 2018-10-23T17:17:12+05:00 2019-11-01T13:16:47+05:00 "При использовании платы VE-02 замечена следующая закономерность: 1. Переводим плату из режима DHCP в режим статического адреса, адрес при этом не меняем (был 192.168.0.125). 1. Перезагружаем плату. 1. Включаем режим DHCP. При этом запускается udhcpc и получает в аренду от сервера тот же адрес, что и был установлен статически, то есть адрес не меняется. После этого при вызове одним канальным окончанием FS01 другого FS01 вызов проходит, абоненты слышат друг друга, но когда вызываемый кладет трубку, вызывающий не получает отбой и остается в состоянии Connected. Нормальная работа восстанавливается после перезагрузка платы." alx 442 Неудачный вызов от окончания FS01 any 1 очередь баг alx new 2024-09-19T10:22:20+05:00 2024-09-19T12:35:57+05:00 "Окончание FS01 платы VE-02 зарегистрировано на АТС Элтекс. Вызовы Элтекс -> FS01 проходят нормально, связь есть. Но при попытке вызова FS01 -> Элтекс происходит какая-то странность: общение в sip заканчивается сообщением 180 ringing со стороны Элтекса, удалённый телефон звонит, но при этом на FS01 отображается состояние busy, а абонент FS01 слышит в трубке короткие гудки. Удалённый телефон продолжает звонить до тех пор пока Элтекс не отобьет его по тайм-ауту или абонент не возьмет трубку. IP Дамп вызова FS01 -> Элтекс и конфиг VE-02 прилагаю." san 329 Добавить ввод инвентаризационного номера any 1 очередь задача alx new 2019-10-31T13:23:17+05:00 2020-01-14T16:51:41+05:00 "1. Добавить ввод инвентаризационного номера в процесс программирования платы VE-01/02 и блока MC04-VIP. (номер вводит работник производства, с этикетки на плате) 1. Для блока MC04-VIP отображать номер в веб-интерфейсе блока. 1. Для VE-01/02 Хранить номер в переменной платы согласно договорённостям в sw:#400 " san 223 Дополнительный режим ГБ VE-02 1 очередь улучшение anatoly assigned 2017-05-22T10:27:52+05:00 2017-06-07T17:20:58+05:00 "Предлагается добавить режим ГБ, где сигнал на реле будет подаваться не постоянно а интервалами. Миша предлагает такие временные интервалы: 1 сек. замкнуто, 3 сек. разомкнуто. Выбор режима предлагается осуществлять чекбоксом в веб-интерфейсе" san 224 В веб-интерфейсе сделать конфигурацию IPv6 VE-02 1 очередь улучшение alx new 2017-05-31T17:29:58+05:00 2019-09-06T17:31:41+05:00 В r1181 появилась поддержка IPv6. Надо сделать конфигурацию IPv6 через веб-интерфейс. alx 299 FXS: удалять старое соединение после передачи вызова конференции any 1 очередь улучшение alx new 2018-12-12T13:08:58+05:00 2018-12-14T18:26:11+05:00 "При передачи вызова конференции методом ""REFER абонентам"" канальное окончание FXS предполагает, что UA, которому был передан REFER, выполнив переключение на указанного абонента, самостоятельно отобьет старое соединение. Некоторые телефоны, например Polycom IP-500, не отбивают старое соединение, вместо этого посылают REFER обратно инициатору трансфера. В результате у телефона продолжает ""висеть"" удерживаемое соединение с инициатором трансфера, с которым ничего нельзя сделать... Флаг hangup_after_refer в данном случае не помогает, так как сразу после передачи REFER абонентам дескрипторы активного и удерживаемого соединений очищаются, и активное соединение устанавливается на конференцию. Когда приходит финальный NOTIFY, окончание FXS уже не помнит идентификаторы исходных соединений, а помнит только CID фокуса конференции. Предлагается очистку дескрипторов соединений выполнять не в момент передачи REFER абонентам, а после завершения трансфера абонентов в конференцию (после получения финальных NOTIFY). Когда приходит финальный NOTIFY активного соединения, проверять наличие conference_call_id, и если он не отрицательный, заменять активное соединение конференцией. Это должно обеспечить гарантированный отбой" alx 314 FS01: добавить состояние инициализации модуля VE-02 1 очередь улучшение alx new 2019-03-18T12:34:19+05:00 2019-03-18T12:34:19+05:00 "Сегодня возникла ситуация, когда модуль FS01 не мог инициализироваться (из регистра все время читалось неверное значение), но в веб-интерфейсе при этом состояние канального окончания было Idle, и о наличии проблемы можно было узнать только посмотрел лог. Предлагается добавить канальному окончанию FS01 состояние ""Инициализация"", в котором оно будет находиться до тех пор, пока модуль FS01 не будет инициализирован." alx 356 U-boot: возвращать дифференцированный статус ошибки активации прошивки any 1 очередь улучшение alx new 2021-01-20T18:09:19+05:00 2026-02-10T15:21:48+05:00 "При активации прошивки в процессе обновления прошивки протокол мониторинга в ответ на запрос активации предусматривает только два варианта ответа: успешно (0) или ошибка (1). Предполагалось, что активация будет заключаться лишь в физическом копировании уже загруженной и проверенной прошивки в ПЗУ. Однако в платах VE-01 и VE-02 активация прошивки состоит из множества действий: именно на этом этапе загрузчик выполняет реальную загрузку и проверку прошивки, причем сама прошивка состоит из трех разных файлов. Каждое из выполняемых действий может закончиться неуспешно, что в результате приводит к ответу со статусом 1 на запрос активации прошивки. Как результат, статус завершения активации оказывается малоинформативен и не позволяет установить причину проблемы. Предлагается расширить протокол обновления прошивки так, чтобы в случае ошибки активации прошивки допускался ответ с любым отличным от нуля статусом. На практике плата SW-01 и так уже трактует любой ненулевой статус как ошибку активации, и даже выводит этот статус в журнал. Предлагается модифицировать загрузчик плат VE-01/VE-02 таким образом, чтобы при неупешном завершении активации прошивки в поле статуса передавался номер строки скрипта обновления, при выполнении которой возникла ошибка. Это позволит по имеющемуся в логе платы SW-01 статусу определить, какая именно операция завершилась ошибкой, и облегчить поиск причины." alx 402 Определение URI вызывающего при поиске маршрута any 1 очередь улучшение alx new 2023-01-27T15:37:22+05:00 2023-01-27T15:37:22+05:00 "Сейчас при поиске маршрутов SIP может учитываться вызывающий абонент. Это реализовано путем сравнения URI поля From с регулярным выражением маршрута. Однако не всегда номер вызывающего содержится в поле From. Сейчас параметр ""Принимать Caller-ID"" позволяет доставать имя/номер вызывающего из трех источников - поля From, поля P-Asserted-Identity и Remote-Party-ID. Если номер вызывающего находится в одном из двух последних перечисленных полей, а не в поле From, регулярное выражение from URI становится бесполезным, так как не позволяет различать источник вызова... **Предлагается** использовать настройку ""Принимать Caller-ID"" и/или ""Передавать Caller-ID"" (пока непонятно, как лучше и правильнее их учитывать), или сделать дополнительную настройку специально для маршрутов, и в зависимости от настройки сравнивать с регулярным выражением либо URI поля From, либо значения полей P-Asserted-Identity / Remote-Party-ID." alx 467 Добавить настройку списка доверенных IP адресов any 1 очередь улучшение alx new 2025-11-26T12:34:19+05:00 2025-11-26T12:34:19+05:00 "Пользователю иногда требуется, чтобы вызовы, от определённых хостов проходили без аутентификации. Предлагаю добавить настройку списка ""доверенных"" IP адресов в настройки платы. Обсуждали [ticket:466#comment:25 тут]." san 154 Кодировать символ ':' в файле users.txt VE-02 2 очередь баг alx new 2015-12-09T18:37:18+05:00 2015-12-09T18:37:18+05:00 "Сейчас поля в файл users.txt пишутся как есть, то есть без какого-либо кодирования. При этом разделителем полей является символ ':'. Если такой символ встретится в поле имени или пароля, последующий парсинг записи даст неверный результат. Предлагается при записи кодировать/декодировать символ ':', как минимум, в поле пароля (в имени пользователя такого символа быть не может)." alx 190 MFC R2: нет слышимости при соединении двух СЛ друг на друга VE-01 2 очередь баг alx new 2016-09-27T19:09:56+05:00 2016-09-27T19:09:56+05:00 "Создаем 2 СЛ MFC R2. Соединяем из в TDM маппере друг на друга. Делаем вызов через эти две СЛ. Вызываемый снимает трубку, но никто никого не слышит." alx 243 Фокусы конференций всегда имеют домен в виде адреса IPv4 any 2 очередь баг alx new 2017-09-20T17:41:30+05:00 2021-11-11T10:59:29+05:00 "Получается, что даже если запрос к conference-factory приходит по IPv6, создается фокус конференции с контактом вида `;isfocus`. В результате IPv6-only UAC не могут работать с такими конференциями. Надо каким-то образом ""подстраивать"" семейство адресов в контакте под получателя." alx 260 Односторонний отбой канального окончания 1IND any 2 очередь баг alx new 2017-12-22T18:10:18+05:00 2017-12-22T18:10:18+05:00 "Если одно окончание 1IND передает другому номер, начинаюцийся с префикса межгорода, то передающее номер окончание занимает канал коротким сигналом, давая понять другой стороне, что занятие междугородное. После такого занятие удаленная сторона передает отбой длинным сигналом (ДС) вместо отбойного сигнала (ОС) и ожидает встречного отбоя. Но наше окончание не реализует на ДС в состоянии Connected, интерпретируя его как переход в предответное состояние, который у нас не поддерживается! Надо при передаче междугородного занятия запоминать факт, что занятие было междугородным, и по сигналу ДС, если занятие было междугородным, выполнять отбой." alx 113 Групповые настройки для окончаний any 19 2 очередь задача alx new 2015-05-19T11:55:13+05:00 2015-05-19T11:55:13+05:00 Если нужно сменить настройки многих окончаний одновременно(например IP в SIP uri, префикс межгорода, рег. выражение итд.) неудобно открывать настройки каждого окончания отдельно и изменять нужные параметры. Хочется возможность применять определённые настройки для группы окончаний. san 396 Workaround для прокси-серверов, не уважающих Route any 2 очередь задача alx new 2022-07-14T18:05:36+05:00 2022-07-15T11:35:14+05:00 "== Введение == Платы VE-01 и VE-02 содержат в себе SIP UA и SIP прокси. UA для сетевой коммуникации (приема/передачи сообщений SIP) использует адрес/порт 127.0.0.1:6060 и, таким образом, недоступен из-за пределов платы. Вся коммуникация с UA может производиться только через прокси-сервер, имеющий доступные из внешней сети транспорты. Для того чтобы запросы SIP всегда передавались через прокси-сервер, в них используется заголовок `Route`. Пример обмена сообщениями двух UA через два прокси-сервера как он должен происходить: {{{#!PlantUml @startuml skinparam ParticipantPadding 60 participant UAC participant ""Proxy 1"" as P1 participant ""Proxy 2"" as P2 participant UAS UAC -> P1: INVITE P1 -> P2: INVITE\nRecord-Route: P1 P2 -> UAS: INVITE\nRecord-Route: P2\nRecord-Route: P1 UAS -> P2: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 P2 -> P1: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 P1 -> UAC: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 UAS -> P2: 200 OK\nRecord-Route: P2\nRecord-Route: P1 P2 -> P1: 200 OK\nRecord-Route: P2\nRecord-Route: P1 P1 -> UAC: 200 OK\nRecord-Route: P2\nRecord-Route: P1 UAC -> P1: ACK\nRoute: P1\nRoute: P2 P1 -> P2: ACK\nRoute: P2 P2 -> UAS: ACK @enduml }}} == Проблема == За период производства плат со встроенным прокси-сервером (около 7 лет) стало известно о нескольких случаях неправильной работы внешних прокси-серверов, с которыми столкнулись потребители. Последний из таких случаев заключался в том, что прокси-сервер, работающий в сети пользователя, выбрасывал из запросов SIP заголовки `Route` и пытался передать сообщение так, как будто никакого маршрута в нем не было, то есть пытался доставить сообщение непосредственно адресату из Request-URI: {{{#!PlantUml @startuml skinparam ParticipantPadding 50 participant UAC participant ""Proxy 1\n(проблемный)"" as P1 box ""VE-01"" participant ""Proxy 2"" as P2 participant UAS end box UAC -> P1: INVITE P1 -> P2: INVITE\nRecord-Route: P1 P2 -> UAS: INVITE\nRecord-Route: P2\nRecord-Route: P1 UAS -> P2: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 P2 -> P1: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 P1 -> UAC: 180 Ringing\nRecord-Route: P2\nRecord-Route: P1 UAS -> P2: 200 OK\nRecord-Route: P2\nRecord-Route: P1 P2 -> P1: 200 OK\nRecord-Route: P2\nRecord-Route: P1 P1 -> UAC: 200 OK\nRecord-Route: P2\nRecord-Route: P1 UAC -> P1: ACK\nRoute: P1\nRoute: P2 P1 ->x P1 : ACK на адрес 127.0.0.1 @enduml }}} Так как в случае платы VE-01 UAS имеет адрес 127.0.0.1, недостижимый напрямую из внешней сети, запрос ACK не достигает получателя. == Задача == Предлагается рассмотреть и обсудить варианты обхода описанной выше проблемы. Варианты будем добавлять в комментарии к этому тикету." alx 121 Добавить конфигурацию имени домена для SIP-пользователей any 2 очередь улучшение alx new 2015-06-04T10:21:21+05:00 2023-12-04T10:33:23+05:00 Сейчас SIP-пользователи могут использовать только IP адрес платы в качестве домена. Надо добавить глобальный конфигурационный параметр для установки имени домена. На это имя будет проверяться домен всех входящих запросов (INVITE, REGISTER). alx 142 Зацикленная переадресация any 2 очередь улучшение alx new 2015-08-20T15:16:20+05:00 2016-09-01T11:58:16+05:00 Сейчас в случае зацикленной переадресации (когда абонент А переадресует на абонента Б, а абонент Б - на абонента А), вызов может закончиться только по таймауту (если он установлен, да и то это не проверялось). Предлагается запоминать список вызывавшихсЯ URI и при каждом новом форварда проверять на зацикливание. alx 184 В некоторых случаях необходимо передавать нажатия Flash из FxS в FxO any 2 очередь улучшение alx new 2016-08-04T14:30:56+05:00 2016-08-04T16:49:02+05:00 san 194 В плату SW-01 не передаются категории абонентов VE-01 2 очередь улучшение alx new 2016-10-27T16:20:36+05:00 2016-10-27T16:20:36+05:00 При формировании CDR в ней отсутствуют категории абонентов. Надо сделать. alx 207 Сделать конфигурируемым длительность session-timer'а для виртуальных каналов any 2 очередь улучшение alx new 2016-11-16T14:35:07+05:00 2016-11-16T14:35:07+05:00 Сабж. Наверное глобального параметра будет достаточно alx 235 Добавить в CDR информацию об использованном кодеке VE-01 2 очередь улучшение alx new 2017-09-14T09:56:32+05:00 2017-09-14T09:56:32+05:00 "Добавить в CDR, передаваемую плату SW-01, поле ""codec"". Чтобы не усложнять CDR в случае, когда кодек менялся в процессе соединения, указывать только кодек, использовавшийся последним." alx 238 Продолжать разговор после неудачного трансфера any 2 очередь улучшение alx new 2017-09-15T12:22:15+05:00 2018-12-12T16:04:11+05:00 Сейчас окончание FXS, получив уведомление об окончании трансфера, разрывает соединение независимо от результата трансфера. Если трансфер инициировался опусканием трубки, никаких других вариантов у абонента все равно нет. Но если трансфер инициирован комбинацией Flash+цифра, есть возможность дать инициатору трансфера знать о результате, и при неудачном трансфере вернуться к разговору. alx 251 Использовать MONITOR_TDM_SIGNALING вместо мониторинга СУВ средствами ПЛИС any 2 очередь улучшение alx new 2017-10-04T16:53:52+05:00 2021-11-07T11:54:08+05:00 "Сейчас при деактивированном канале FXS мониторинг активности СУВ осуществляется средствами ПЛИС. При этом мониторится только СУВ А. Оказывается, MSP имеет команду MONITOR_TDM_SIGNALING, которой можно включить мониторинг СУВ канала. Надо попробовать использовать ее вместо опроса ПЛИС." alx 331 Сохранять в CDR не успешные вызовы any 2 очередь улучшение alx new 2019-11-01T18:27:51+05:00 2019-11-05T11:42:02+05:00 "В нашем оборудовании есть функция CDR, предназначенная для тарификации звонков. Исходя из предназначения, в CDR хранятся только успешные вызовы, когда разговор состоялся. Некоторые заказчики используют эту функцию не совсем по назначению, а для целей контроля телефонной связи в корпоративной АТС, и от них поступают предложения добавить в CDR и неуспешные вызовы, с указанием причины(busy, нет ответа и т.д.). (Например чтобы увидеть что Вася действительно звонил Диспетчеру 5 раз и не получил ответа, а не сочиняет) Добавил в тикет причастных к теме, прошу высказать мнение по поводу предложения. " san 332 Поддержка BLF для абонентских окончаний any 2 очередь улучшение alx new 2019-11-14T17:32:44+05:00 2019-11-19T10:06:55+05:00 "Один из пользователей высказал предложение реализовать поддержку функции BLF (Busy Lamp Field) для абонентских окончаний нашего шлюза. Мне это предложение показалось полезным. Например, довольно часто шлюз устанавливается в схеме применения, где Диспетчеру(с Sip телефона с панелью расширения с кучей кнопочек) нужно вызывать удалённых абонентов подключенных через наши окончания FxS и АДАСЭ. Думаю что отображение статуса линии удалённого абонента на телефоне диспетчера повысило бы удобство пользования системой. " san 439 Сериализовать транзакции REGISTER any 2 очередь улучшение alx new 2024-08-12T12:34:46+05:00 2024-08-12T13:49:30+05:00 "Сейчас канальные окончания SIP могут захотеть перерегистрироваться в любой произвольным момент времени (например при изменении настроек или IP адреса платы). Перерегистрация заключается в вызове `ua_unregister()`, отправляющей запрос разрегистрации, и последующем вызове `ua_register()`. Может так получиться, что на момент вызова `ua_unregister()` еще не завершена предыдущая транзакция, и тогда ibeXosip возвращает OSIP_WRONG_STATE. **Предлагается** реализовать механизм подобный тому, который был реализован для транзакций SUBSCRIBE - для каждой регистрации помнить ее состояние, и если ua_unregister() вызывается в момент незавершенной транзакции, устанавливать какой-то флаг необходимости разрегистрироваться, и посылать новый запрос после завершения текущей транзакции. Заодно запоминать там же ts канального окончания, инициировавшего регистрацию, заменив массив ts2rid (чтобы регистрироваться могли и виртуальные канальные окончания)." alx 440 Настройки SIP и медиа для статических конференций any 2 очередь улучшение alx new 2024-08-16T13:34:06+05:00 2024-08-16T13:34:06+05:00 "В платах VE-01 и VE-02 помимо обычных канальных окончаний, которые создаются при конфигурации, есть виртуальные каналы, например конференции. При настройке обычных канальных окончаний пользователь имеет возможность настроить параметры медиа, но для конференций таких настроек не предусмотрено, поэтому они всегда работают с дефолтными настройками. **Предлагается** расширить настройки статических конференций, добавив туда все основные настройки SIP (как в большинстве канальных окончаний) и настройки медиа. Также **предлагается** добавить настройки динамических конференций (одни общие на всех)." alx 300 PRI: не передается CALL PROCEEDING при OVERLAP DIALING any 1 очередь баг alx new 2018-12-24T18:55:35+05:00 2018-12-24T18:55:35+05:00 "После завершения приема номера вызываемого абонанта (по наличию ""Sending Complete"" или по таймауту набора) в сеть IP преедается INVITE, но вызывающему не передается CALL PROCEEDING. Надо сделать передачу CALL PROCEEDING непосредственно перед вызовом dial_out()." alx 124 Запрет call forwarding если входящее соединение пришло позже исходящего any 19 2 очередь улучшение alx reopened 2015-06-18T11:14:30+05:00 2015-06-19T10:36:29+05:00 "Сейчас в режиме ДВО ""Только flash"" если любое из двух имеющихся соединений исходящее, при опускании трубки выполняется call forwarding. В случае, если исходящий вызов был сделан до поступления входящего, это нелогично. Предлагается добавить проверку и выполнять forwarding только если входящее соединение поступило раньше, чем ьыло установлено исходящее." alx 162 Добавить настройку qvalue при регистрации шлюза на внешнем сервере any 2 очередь улучшение alx new 2016-03-30T19:16:26+05:00 2016-03-30T19:16:26+05:00 Добавить настройку qvalue при регистрации шлюза на внешнем сервере. alx 301 FXS, 1IND: Реализовать overlap dialing через IP any 2 очередь улучшение alx new 2018-12-25T10:18:08+05:00 2019-11-08T15:19:49+05:00 "По опыту замены нашей аппаратурой старых координатных АТС с использованием сигнализации индуктивным кодом операторами отмечалось, что время соединения становится больше. Это объясняется тем, что старые координатные АТС, приняв первую цифру номера, сразу занимали соединительную линию и начинали трансляцию последующих цифр в эту соединительную линию в процессе набора номера абонентом. В отличие от этого, плата VE-01 сначала накапливает у себя полный номер, и только после окончания набора номера вызывающим абонентом занимает соединительную линию и начинает передавать туда номер. Как результат, суммарное время набора увеличивается. Предлагается реализовать функцию overlap dialing через SIP примерно по следующему сценарию: {{{#!plantuml @startuml skinparam sequenceMessageAlign center participant FXS as A participant 1IND as B participant ""АТС"" as C -> A: Снятие трубки -> A: Набор ""1"" -> A: Набор ""2"" A --> B: INVITE 12@domain.org B --> A: 100 Trying B -> C: Занятие B -> C: Набор ""1"" B -> C: Набор ""2"" B --> A: 183 Session Progress B <-[#blue]-> A: //медиапоток// -> A: Набор ""3"" A --> B: INVITE 123@domain.org\nReplaces: 12@domain.org B --> A: 100 Trying B --> A: 484 Address Incomplete (на 12@domain.org) B -> C: Набор ""3"" B --> A: 183 Session Progress B <-[#blue]-> A: //медиапоток// ... note over C: прием номера завершен ... C -> B: Ответ B --> A: 200 OK A <-[#blue]> C: //разговорное состояние// note over A, C: абоненты ведут разговор @enduml }}} 1. Абонент FXS снимает трубку и начинает набирать номер. 1. Как только абонент набрал первые цифры, достаточные для определения направления (допустим, это ""12""), канальное окончание FXS отправляет INVITE c этими двумя цифрами (12@domain.org). 1. INVITE принимается канальным окончанием 1IND, который занимает соединиртельную линию и начинает передавать в нее цифры ""1"" и ""2"" обычным образом. 1. Абонент канального окончания FXS продолжает набор - и набирает третью цифру. Пусть это будет цифра ""3"". Канальное окончание FXS отправляет в сеть новое сообщение INVITE, на этот раз на URI 123@domain.org, содержащее поле Replaces с указанием реквизитов ранее установленного диалога. 1. Канальное окончание 1IND, уже занятое предыдущим вызовом, принимает новый, убирает из ""123"" уже переданные цифры ""1"" и ""2"" и передает в СЛ цифру ""3"". На ранее принятый INVITE канальное окончание отвечает ""484 Address Incomplete"". 1. Так повторяется, пока абонент FXS продолжает набор. 1. Когда из СЛ придет ответ, канальное окончание 1IND даст ответ ""200 OK"", и соединение перейдет в состояние разговора. Насколько я понимаю, для работы такого сценария требуется, чтобы цифр номера в самом первом INVITE было достаточно для правильной маршрутизации вызова, так как, один раз послав INVITE одному окончанию, мы вряд ли сможем потом ""передумать"" и работать с другим (а если первое сразу ответит ""Busy""?). Поэтому предлагается конфигурационный параметр, устанавливающий минимальную длину префикса, после набота которого разрешается overlap dialing (в приведенном выше примере это 2). Прошу комментировать и критиковать." alx 321 Обновление VE-02-no-PoE VE-02 2 очередь улучшение alx new 2019-09-06T11:42:39+05:00 2020-02-26T09:54:40+05:00 "Предлагаю: 1. Создать отдельную ветку '''пакетного''' репозитория на repo.adc-line.ru для VE-02-no-PoE 2. В веб-интерфейсе VE-02-no-PoE при нажатии кнопки ""Проверить обновления"" при пустой строке адреса, проверять обновления из ветки VE-02-no-PoE repo.adc-line.ru" san 37 Переадресация на плохой uri any баг alx new 2014-04-10T11:04:01+06:00 2014-10-01T18:34:38+06:00 "Если при исходящем вызове вызываемый абонент отвечает ""180 Ringing"", а затем делает переадресоцаю в виде ""302 Moved Temporarily"" с плохим uri в поле Contact, то переадресации не происходит, libeXosip выдает событие EXOSIP_CALL_RELEASED, но вызывающий абонент продолжает слышать КПВ. Надо при получении события EXOSIP_CALL_RELEASED передавать endpoint'у событие eDisconnectEvent." alx