H323. LDKVOIB в поле CallerID name Опции

[EugeneT]

Доброго дня.
Увязал ipLdk-100 с астериском по h323, все работает хорошо, однако со стороны станции, вместе с АОНом, в поле CallerID name, прилетает LDKVOIB, астер толкует это как "LDKVOIB" <NNN> и вся эта конструкция отображается на экранах Ip-фонов. Можно ли как-то сменить этот идентификатор на что-то более вразумительное, скажем имя филиала, или отключить выдачу совсем?

[harris]

Доброго дня.
Увязал 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, то мы только собираемся писать запрос в Корею, чтобы они подправили это. Но, увы, пока до этого руки не дошли...

[exzerodivide]

Нет. Со стороны 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 интерпретатор, имя под рукой сниффы не так уж и сложно.

[harris]

Что то как то в одну кучу все смешались :-)
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.

[exzerodivide]

Почему же "всё в кучу"?? Я, конечно, не большой спец по Н.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

Как то так в общем :-)

[harris]

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"

[exzerodivide]

Я не говорил про "отдельно 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 это все-таки впилят :-)

[All is not what ...]

Есть выход - допилить OpenH323 для разбора этого APDU. Соответственно, все, кто сидит на этом стеке, включая астерикса, смогут видеть имена от LG. Хочу попробовать сам тако сделать, как время появится свободное.

Вместо допиливания, замерзшиго в 2007, OpenH323 попробуйте написать девелоперам Opal, который развивается.
Кстати начать с того что посмотреть на работу Opal-based канала.

[EugeneT]

Вместо допиливания, замерзшиго в 2007, OpenH323 попробуйте написать девелоперам Opal, который развивается.
Кстати начать с того что посмотреть на работу Opal-based канала.

С другой стороны ooh323 имеет место быть в репозитории дигиума для всех версий астера и худо-бедно работает, а прикручивание опала все же процедура нетривиальная и чревата всякими глюками.