![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
![]()
Сообщение
#1
|
|
Участник ![]() ![]() Группа: Участники Сообщений: 10 Регистрация: 2.3.2011 Пользователь №: 15555 ![]() |
Доброго дня.
Увязал ipLdk-100 с астериском по h323, все работает хорошо, однако со стороны станции, вместе с АОНом, в поле CallerID name, прилетает LDKVOIB, астер толкует это как "LDKVOIB" <NNN> и вся эта конструкция отображается на экранах Ip-фонов. Можно ли как-то сменить этот идентификатор на что-то более вразумительное, скажем имя филиала, или отключить выдачу совсем? |
|
|
![]() |
![]()
Сообщение
#2
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Доброго дня. Увязал ipLdk-100 с астериском по h323, все работает хорошо, однако со стороны станции, вместе с АОНом, в поле CallerID name, прилетает LDKVOIB, астер толкует это как "LDKVOIB" <NNN> и вся эта конструкция отображается на экранах Ip-фонов. Можно ли как-то сменить этот идентификатор на что-то более вразумительное, скажем имя филиала, или отключить выдачу совсем? Нет. Со стороны LDK это в настоящее время изменить нельзя. LDK в протоколе Q.931 отправляет это сообщение (LDKVOIB и + MAC-адрес) в поле Display. А уже в протоколе H.225 cтанция нормально отправляет Сalling Party/Connected Party. Попробуйте настроить Астериск, чтобы он брал информацию из Н.225, а не из Q.931. А поводу использования элемента Display в Q.931 в станциях LDK, то мы только собираемся писать запрос в Корею, чтобы они подправили это. Но, увы, пока до этого руки не дошли... -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#3
|
|
![]() Продвинутый пользователь ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 169 Регистрация: 31.5.2010 Из: Default City Пользователь №: 14690 ![]() |
Нет. Со стороны LDK это в настоящее время изменить нельзя. LDK в протоколе Q.931 отправляет это сообщение (LDKVOIB и + MAC-адрес) в поле Display. А уже в протоколе H.225 cтанция нормально отправляет Сalling Party/Connected Party. Попробуйте настроить Астериск, чтобы он брал информацию из Н.225, а не из Q.931. А поводу использования элемента Display в Q.931 в станциях LDK, то мы только собираемся писать запрос в Корею, чтобы они подправили это. Но, увы, пока до этого руки не дошли... Что то как то в одну кучу все смешались :-) Q.931 в H.323 нет. Есть H.225.0 В H.225 Display IE LDK как раз и шлет LDKVOIB. Нормальное имя идет в H.450.1 в составе H.225.0, присутствует в ALERTING, CONNECT, SETUP и т.д. Поэтому если есть прям таки непреодолимое желание заставить понимать имя от LDK в сторону астерикса, надо брать его H.323-стек (там вроде OpenH323) и пилить на предмет декодирования H.450.1 APDU Базовые механизмы там есть, в принципе написать на ASN.1 интерпретатор, имя под рукой сниффы не так уж и сложно. -------------------- The sum of intelligence on the planet is a constant; the population is growing.
|
|
|
![]()
Сообщение
#4
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
Что то как то в одну кучу все смешались :-) Q.931 в H.323 нет. Есть H.225.0 В H.225 Display IE LDK как раз и шлет LDKVOIB. Нормальное имя идет в H.450.1 в составе H.225.0, присутствует в ALERTING, CONNECT, SETUP и т.д. Поэтому если есть прям таки непреодолимое желание заставить понимать имя от LDK в сторону астерикса, надо брать его H.323-стек (там вроде OpenH323) и пилить на предмет декодирования H.450.1 APDU Базовые механизмы там есть, в принципе написать на ASN.1 интерпретатор, имя под рукой сниффы не так уж и сложно. Почему же "всё в кучу"?? Я, конечно, не спец по Н.323, но насколько я понимаю: - H.225 - это протокол управления соединением, включая RAS. - Н.225 включает в себя сообщения протокола Q.931 практически в чистом виде, что и видно с помощью сниффера. Т.е. Q.931 - это часть Н.225. Сигнальные сообщения (Setup/Connect и т.д.) присутствуют в пакете H.225 дважды (что и видно с помощью сниффера): в "чистом виде" в сообщении протокола Q.931 и собственно в протоколе H.225.0 в информациии UserInformation. - H.450 - это протокол ДВО (дополнительного сервиса по обслуживания вызова: Hold/Transfer/Forward и пр.). В базовых сообщениях (H.225.0) используется передача Имени абонента в формате, соотвествующем Н.450, а также испотзование Facility тоже определяется рекомендациям Н.450. Пока пользователь не запрашивает функции ДВО, то собственно сообщений протокола Н.450 и не передается. Это всё ИМХО. Так вот, что я имел в виду, когда писал выше: уже были жалобы на то, что при ответе на входящий вызов LDK в сообщении Connect, в Q.931 выдает инф. элемент Display, в котором содержится "LDK" или "LDK VOIB" (Display information: LGE). При этом в Q.931 отсутствует элемент Connected Party (исходно в Q.931 этот элемент действительно не предусмотрен, в отличии от ETSI). Поэтому на вызывающем терминале вместо отображениея номера/имени ответившего абонента отображается текстовое сообщение "LDK" (LDK VOIB). А номер ответившего абонента присутствует в другом поле, в Н.225 в UserInformation: connectedAddress: dialedDigits: 495712100 Вот собственно об этом и собирались запрашивать корейцев, чтобы в сообщении Connect: - убрать элемент Display из поля Q.931 - добавить элемент Connected Party в поле Q.931. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#5
|
|
![]() Продвинутый пользователь ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 169 Регистрация: 31.5.2010 Из: Default City Пользователь №: 14690 ![]() |
Почему же "всё в кучу"?? Я, конечно, не большой спец по Н.323, но насколько я знаю: - H.225 - это протокол управления соединением, включая RAS. - Н.225 включает в себя сообщения протокола Q.931 практически в чистом виде, что и видно с помощью сниффера. Т.е. Q.931 - это часть Н.225. Сигнальные сообщения (Setup/Connect и т.д.) присутствуют в пакете H.225 дважды (что и видно с помощью сниффера): в "чистом виде" в сообщении протокола Q.931 и собственно в протоколе H.225.0 в информациии UserInformation. H.225.0 - RAS и call control. H.225.0 действительно основан на Q.931, но имеет ряд модификаций. То, что пишет сниффер, скорее всего связано с представлением сообщения в стеке H.323 и эквиваленте Q.931 (для понятности). "отдельно h.225" и "отдельно Q.931" протоколом не предусмотрено. Это видно из описания сообщений H.225 в ASN.1 синтаксисе. Сюда не вешаю - codebox не отрабатывает. - H.450 - это протокол ДВО (дополнительного сервиса по обслуживания вызова: Hold/Transfer/Forward и пр.). В базовых сообщениях (H.225.0) используется передача Имени абонента в формате, соотвествующем Н.450, а также испотзование Facility тоже определяется рекомендациям Н.450. Пока пользователь не запрашивает функции ДВО, то собственно сообщений протокола Н.450 и не передается. Там этих H.450.ХХ вагон и маленькая тележка. Остановимся собственно на H.450.1 Передается он через user-user information element в сообщениях h.225.0, например в facility или setup. В h.450.1 можно передавать в принципе все что душе угодно, в том числе и имя абонента, как отражая поле Display из H.225 идентичным с точки зрения ASN.1 образом, так и произвольным образом. Соответственно, h.450.1 является необязательным по отношению к h.225.0. То есть, правильнее с точки зрения стандартов и совместимости базово использовать h.225 для имени и h.450.1 для имени с legacy-станциями LG. Насчет "по запросу" - в настройках NET ? ИМХО. Так вот, что я имел в виду, когда писал писал выше: уже были жалобы на то, что при ответе на входящий вызов LDK в сообщении Connect, в Q.931 выдает инф. элемент Display, в котором содержится "LDK" или "LDK VOIB" (Display information: LGE). При этом в Q.931 отсутствует элемент Connected Party (исходно в Q.931 этот элемент действительно не предусмотрен, в отличии от ETSI). Поэтому на вызывающем терминале вместо отображениея номера/имени ответившего абонента отображается текстовое сообщение "LDK" (LDK VOIB). А номер ответившего абонента присутствует в другом поле, в Н.225 в UserInformation: connectedAddress: dialedDigits: 495712100 Вот собственно об этом и собирались запрашивать корейцев, чтобы в сообщении Connect: - убрать элемент Display из поля Q.931 - добавить элемент Connected Party в поле Q.931. Мне все же кажется, что немного не так. 1. Заполнять и интерпретировать Display IE в сообщениях ALERTING, CALL PROCEEDING, SETUP, CONNECT, PROGRESS (как минимум, ИМХО). По-хорошему, с учетом того, что имя может приехать и так и так, необходимо ввести приоритет полей, или явным образом указывать, откуда брать имя. 2. Для совместимости с предыдущими версиями прошивок VoIP плат обеспечить перенос полей из H.225.0 в H.450.1 3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.225 Как то так в общем :-) -------------------- The sum of intelligence on the planet is a constant; the population is growing.
|
|
|
![]()
Сообщение
#6
|
|
![]() ГУРУ ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 ![]() |
H.225.0 - RAS и call control. H.225.0 действительно основан на Q.931, но имеет ряд модификаций. То, что пишет сниффер, скорее всего связано с представлением сообщения в стеке H.323 и эквиваленте Q.931 (для понятности). "отдельно h.225" и "отдельно Q.931" протоколом не предусмотрено. Это видно из описания сообщений H.225 в ASN.1 синтаксисе. Сюда не вешаю - codebox не отрабатывает. Я не говорил про "отдельно h.225" и "отдельно Q.931"... Я говорил, что Q.931 (в "чистом виде") является частью более развернутого протокола Н.225.0. Сигнальные сообщения Q.931 Сниффер (WireShark) выдает побайтный дамр пакета. Сообщения протокола Q.931 выделены дискриминатором протокола = 08'h. Эти сообщения полностью соответствуют формату протокола Q.931, используемого как основа ISDN. В отличии от ISDN, протокол Q.931, применяемый в H.323 (Н.225), имеет небольшие отличия (часть сообщений не применяется, протокол обмена сообщениями немного изменен), но формат сообщений тот же!! Но эти же сообщения дублируются уже в другом формате, который принят только для Н.225 . Там этих H.450.ХХ вагон и маленькая тележка. Остановимся собственно на H.450.1 Передается он через user-user information element в сообщениях h.225.0, например в facility или setup. В h.450.1 можно передавать в принципе все что душе угодно, в том числе и имя абонента, как отражая поле Display из H.225 идентичным с точки зрения ASN.1 образом, так и произвольным образом. Соответственно, h.450.1 является необязательным по отношению к h.225.0. То есть, правильнее с точки зрения стандартов и совместимости базово использовать h.225 для имени и h.450.1 для имени с legacy-станциями LG. Насчет "по запросу" - в настройках NET ? Да, но LDK поддерживает передачу имени абонента только для QSIG. H.450 - это как QSIG на линиях ISDN. Поэтому если используется сетевой план нумерации (линии NET, нумерация NET), то LDK передает имя вызывающего абонента в сообщении протокола Н.450.1 - SupplementaryService: serviceApdu: ARG-callingName Мне все же кажется, что немного не так. 1. Заполнять и интерпретировать Display IE в сообщениях ALERTING, CALL PROCEEDING, SETUP, CONNECT, PROGRESS (как минимум, ИМХО). По-хорошему, с учетом того, что имя может приехать и так и так, необходимо ввести приоритет полей, или явным образом указывать, откуда брать имя. 2. Для совместимости с предыдущими версиями прошивок VoIP плат обеспечить перенос полей из H.225.0 в H.450.1 3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.225 Как то так в общем :-) Не думаю, что IE Display настолько актуальны. Поскольку LDK уже старая станция, то врядли корейцы возьмутся развивать ее возможности. Возможны только какие-то минимальные изменения софта. Поэтому мы хотели ограничиться сообщением Сonnect (как я уже писал именно на это были жалобы): - убрать IE Display из Q.931 (поскольку именно это, как я понял, выводится на дисплей вызывающего терминала других производителей); - "3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.225" -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
![]()
Сообщение
#7
|
|
![]() Продвинутый пользователь ![]() ![]() ![]() ![]() Группа: Участники Сообщений: 169 Регистрация: 31.5.2010 Из: Default City Пользователь №: 14690 ![]() |
Я не говорил про "отдельно h.225" и "отдельно Q.931"... Я говорил, что Q.931 (в "чистом виде") является частью более развернутого протокола Н.225.0. Сигнальные сообщения Q.931 Сниффер (WireShark) выдает побайтный дамр пакета. Сообщения протокола Q.931 выделены дискриминатором протокола = 08'h. Эти сообщения полностью соответствуют формату протокола Q.931, используемого как основа ISDN. В отличии от ISDN, протокол Q.931, применяемый в H.323 (Н.225), имеет небольшие отличия (часть сообщений не применяется, протокол обмена сообщениями немного изменен), но формат сообщений тот же!! Но эти же сообщения дублируются уже в другом формате, который принят только для Н.225 . Хорошо, если брать пакет от протокол дискриминатора до h323-uu-pdu, его можно считать Q.931 с оговорками опять-таки. Лично я все-таки стараюсь придерживаться больше VoIP-терминологии и говорить H.225 вместо Q.931 :-) Но я не могу понять, про какое дублирование Вы говорите. Возьмем для примера пакет H.225.0 SETUP и посмотрим, из чего он состоит: 1. Q.931 - тут все ясно. 2. H323-UserInformation - состит из: 2.1 h323-uu-pdu в свою очередь состоит из: 2.1.1 h323-message-body - дополнительная информация к основному сообщению Q.931, типа h245Address, conferenceGoal, fastStart и т.д 2.1.2 nonStandardData - вендорские примочки 2.1.2 h4501SupplementaryService - H.450.1 APDU 2.1.3 h245Tunneling - признак туннелирования 245 через 225. 2.1.4 h245Control - туннелируемые H.245 PDU 2.1.5 nonStandardControl - вендорские примочки 2.1.5 callLinkage - что-то экзотическое 2.1.6 tunnelledSignallingMessage - туннелирование сигнализации end-to-end 2.1.7 provisionalRespToH245Tunneling - имеет онтошение к туннелированию h.245 2.1.8 stimulusControl - резерв 2.1.9 genericData - все, что угодно 2.2 user-data - состит из: 2.2.1 protocol-discriminator - в соответствии с таблицей 4-26/Q.931 2.2.2 user-information - поле кодируется в соответствии с разделом 4.5.30/Q.931 (межпользовательская информация, не интерпретируемая сетью) Я, если честно, дублирования не вижу. Да, но LDK поддерживает передачу имени абонента только для QSIG. H.450 - это как QSIG на линиях ISDN. Поэтому если используется сетевой план нумерации (линии NET, нумерация NET), то LDK передает имя вызывающего абонента в сообщении протокола Н.450.1 - SupplementaryService: serviceApdu: ARG-callingName Полностью с Вами согласен. Есть выход - допилить OpenH323 для разбора этого APDU. Соответственно, все, кто сидит на этом стеке, включая астерикса, смогут видеть имена от LG. Хочу попробовать сам тако сделать, как время появится свободное. Не думаю, что IE Display настолько актуальны. Поскольку LDK уже старая станция, то врядли корейцы возьмутся развивать ее возможности. Возможны только какие-то минимальные изменения софта. Поэтому мы хотели ограничиться сообщением Сonnect (как я уже писал именно на это были жалобы): - убрать IE Display из Q.931 (поскольку именно это, как я понял, выводится на дисплей вызывающего терминала других производителей); - "3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.225" Лично я надеюсь, что в MG это все-таки впилят :-) -------------------- The sum of intelligence on the planet is a constant; the population is growing.
|
|
|
![]() ![]() |
Текстовая версия | Сейчас: 16.7.2025, 2:42 |