Opened 3 years ago
Closed 3 years ago
#384 closed улучшение (готово)
Добавить опцию "Маскарадинг Invite" — at Version 11
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | высокий | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description (last modified by )
В ходе тех поддержки выяснилось, что некоторые IP АТС(Триком, Unity) не хотят принимать sip вызовы, если в поле Contact сообщения Invite указан ip-адрес отличный от поля From.
Тестовая прошивка с заменой адреса в Contact была отправлена пользователи и он сообщил что "вызов и голос проходит".
Предлагаю для того чтобы пользователи могли состыковать нашу плату VE с этими АТС добавить опцию в настройках платы "Внешний адрес Маскарадинг поля Contact сообщения Invite", при установке которой устанавливать в поле host URI поля Contact запроса INVITE адреса внешнего интерфейса платы - дополнено alx.
Change History (11)
comment:1 by , 3 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 3 years ago
В веб-интерфейсе предполагаю использовать более краткое название опции: "Маскарадинг INVITE".
comment:3 by , 3 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
| Summary: | Добавить опцию "Указывать внешний адрес в поле Contact сообщения Invite" → Добавить опцию "Маскарадинг Invite" |
Переоткрываю тикет, так как функция реализована неправильно - меня сбило предложенное название опции "Внешний адрес...". На самом деле станция хочет видеть в поле Сontаct не адрес внешнего интерфейса платы, а совпадение доменов в полях Contact и From. Поэтому при установке данной опции надо просто копировать домен из поля From в поле Contact.
Описание тикета скорректировал.
comment:4 by , 3 years ago
Непонятно, как при реализации предложенной опции вообще может работать SIP. Возьмем в качестве примера самый простой и типичный сценарий - канальное окончание FXS регистрируется на АТС и делает исходящий звонок. Получается полная ерунда:
Как результат - односторонний отбой, так как канальное окончание не получает BYE. Та же история была бы и с любыми другими запросами от АТС в установленном диалоге...
У меня есть большие сомнения в том, что такую опцию имеет смысл релизить. Так как я собирался делать релиз в ближайшую пятницу, прошу принять решение по данному вопросу.
follow-up: 6 comment:5 by , 3 years ago
Насколько я понимаю, на месте нашей платы VE-01 не будет работать и просто телефон. С той лишь разницей, что, получив не адресованное ему сообщение BYE, телефон его просто проигнорирует. Как вообще телефоны с такой АТС могут работать?...
comment:6 by , 3 years ago
Replying to alx:
получив не адресованное ему сообщение BYE, телефон его просто проигнорирует.
Не совсем так. Вот цитата из RFC:3261 п. 8.2.2.1:
If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response.
Но результат будет тот же - односторонний отбой.
follow-ups: 8 9 comment:7 by , 3 years ago
Ближайшая рабочая пятница будет в следующем году.
имеет смысл релизить
В предложенной опции не рассматривался вариант с регистрацией окончания на чужой АТС, проблема возникала при вызове в так называемый "SIP транк", думаю что можно релизить "как есть" и просто знать что в некоторых случаях эта опция не пригодна.
Насколько я понимаю, на месте нашей платы VE-01 не будет работать и просто телефон. С той лишь разницей, что, получив не адресованное ему сообщение BYE, телефон его просто проигнорирует. Как вообще телефоны с такой АТС могут работать?...
Видимо эти "sip-транки" не расcчитывают что может быть прокси на другом конце. Если просто телефон напрямую будет отправлять инвайт тогда From и Contact будут совпадать.
follow-up: 10 comment:8 by , 3 years ago
Replying to san:
Ближайшая рабочая пятница будет в следующем году.
Я имел в виду 31 декабря. По-моему это пятница.
думаю что можно релизить "как есть"
"как есть" - имеется в виду так, как я реализовал по ошибке? С указанием внешнего адреса платы?
и просто знать что в некоторых случаях эта опция не пригодна.
Меня смущает, что эти "некоторые случаи" - самые типичные. Ведь типично телефон абонента регистрируется на АТС. Нетипично, когда каждый абонент имеет заранее известный станции статический адрес...
Как вообще телефоны с такой АТС могут работать?...
Если просто телефон напрямую будет отправлять инвайт тогда From и Contact будут совпадать.
Нет, не будут. Если телефон зарегистрирован на АТС, в поле From будет домен АТС, а в поле Contact - адрес телефона. Это как раз самый типичный случай.
comment:9 by , 3 years ago
Replying to san:
проблема возникала при вызове в так называемый "SIP транк"
Возможно, для этой АТС так называемый "SIP транк" и "просто абонент" - разные сущности, и работа с ними реализована по-разному. В том смысле, что на "просто абонентов" станция не накладывает требования совпадения хоста в From и Contact...
comment:10 by , 3 years ago
Нет, не будут. Если телефон зарегистрирован на АТС, в поле From будет домен АТС, а в поле Contact - адрес телефона. Это как раз самый типичный случай.
Точно
Возможно, для этой АТС так называемый "SIP транк" и "просто абонент" - разные сущности, и работа с ними реализована по-разному. В том смысле, что на "просто абонентов" станция не накладывает требования совпадения хоста в From и Contact...
Похоже на то.
comment:11 by , 3 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → готово |
| Status: | reopened → closed |
По результату устного обсуждения оставляю ошибочную реализацию этой опции (установку в поле host URI поля Contact запроса INVITE адреса внешнего интерфейса платы).
In 1980/sip_ua: