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

[EugeneT]

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

[Dron]

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

[stasmar]

Упс.. Игорь ответил

[harris]

Тип линий PSTN?
143 – ПК 3 - может поставить - Not used?

Это не играет роли.

[stasmar]

Это не играет роли.

Игорю!
Я надеюсь, Игорь в отпуске отдохнул, а то перед отпуском совсем уже усталый был, судя по голосу..

[harris]

Игорю!
Я надеюсь, Игорь в отпуске отдохнул, а то перед отпуском совсем уже усталый был, судя по голосу..

Ага... Отдыхал хорошо, но устал очень....

[stasmar]

Ага... Отдыхал хорошо, но устал очень....

Тогда сегодня по новому софту к LIK и Скайпу вопросов задавать не буду..
Зато в пробках не стоял каждый день..

[harris]

Тогда сегодня по новому софту к LIK и Скайпу вопросов задавать не буду..
Зато в пробках не стоял каждый день..

Задавать мне вопросы по Скайпу будет бесполезно и завтра!!

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

[EugeneT]

написал в extensions_custom.conf вот такое:

Код

[from-ldk]
exten => _.,1,Set(CALLERID(name)=DptName)
exten => _.,n,Goto(from-pstn,${EXTEN},1)

, где DptName - имя филиала.

Костыль конечно, но работает

[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 это все-таки впилят :-)

[harris]

Хорошо, если брать пакет от протокол дискриминатора до h323-uu-pdu, его можно считать Q.931 с оговорками опять-таки. Лично я все-таки стараюсь придерживаться больше VoIP-терминологии и говорить H.225 вместо Q.931 :-) Но я не могу понять, про какое дублирование Вы говорите.

Под дублированием я имел в виду, что:
- в 2.1.1 h323-message-body опять повторяется тип сообщения [Setup/Alerting/Connect и пр.]
- в sourceAddress: повторяется номер Calling Party
- в destinationAddress: повторяется номер Called Party...

Лично я надеюсь, что в MG это все-таки впилят :-)

Как это сделано в MG, я еще не проверял... Возможно, мой коллега, который непосредственно занимается MG, уже в курсе этой темы. Завтра спрошу у него...
Станции iPECS-LIK и iPECS-MG - это новые серии, поэтому корейцы готовы их развивать и по возможности удовлетворить все требования.

[exzerodivide]

Под дублированием я имел в виду, что:
- в 2.1.1 h323-message-body опять повторяется тип сообщения [Setup/Alerting/Connect и пр.]
- в sourceAddress: повторяется номер Calling Party
- в destinationAddress: повторяется номер Called Party...

Это от безблагодатности разработчиков ПО. :-)

Вот что гласит стандарт(v4):
sourceAddress – Contains the alias addresses of the source. The primary address shall be first. Note that the E.164 number of the source, if any, shall be contained within the Calling Party Number Information Element.
destinationAddress – This is the address to which the endpoint wishes to be connected. The primary address shall be first. When calling an endpoint using only a dialed digit string, this address shall be placed in the Q.931 Called Party Number IE. The destinationAddress, if available, shall be included in the Setup message by terminals compliant with version 2 or higher of this Recommendation.
Понятно, что "should not" нет - лепи что хочешь. Но есть в конце концов рекомендации. Кстати, в v5 вроде как поправили формулировку.

Короче, E.164 - в Q.931, тут либо IP, либо h323 alias, либо пусто.

Как это сделано в MG, я еще не проверял... Возможно, мой коллега, который непосредственно занимается MG, уже в курсе этой темы. Завтра спрошу у него...
Станции iPECS-LIK и iPECS-MG - это новые серии, поэтому корейцы готовы их развивать и по возможности удовлетворить все требования.

По MG я активно способствую :-)

[harris]

Это от безблагодатности разработчиков ПО. :-)

Вот что гласит стандарт(v4):
sourceAddress – Contains the alias addresses of the source. The primary address shall be first. Note that the E.164 number of the source, if any, shall be contained within the Calling Party Number Information Element.
destinationAddress – This is the address to which the endpoint wishes to be connected. The primary address shall be first. When calling an endpoint using only a dialed digit string, this address shall be placed in the Q.931 Called Party Number IE. The destinationAddress, if available, shall be included in the Setup message by terminals compliant with version 2 or higher of this Recommendation.
Понятно, что "should not" нет - лепи что хочешь. Но есть в конце концов рекомендации. Кстати, в v5 вроде как поправили формулировку.

Короче, E.164 - в Q.931, тут либо IP, либо h323 alias, либо пусто.

ОК. Вообщем все эти стандарты - "вещь в себе"... А все эти сетевые протоколы тем более...- Протокол на протоколе сидит и протоколом подгоняет.
Тем не менее все производители (по крайней мере те трассировки, которые я видел) включают Е.164 как в Q.931, так и в h323-message-body.

По MG я активно способствую :-)

ОК. Это хорошо. Мы будем Вам весьма признательны.
Но если есть предложения, пожелания, замечания, то, пожалуйста, будет лучше, если Вы их подробно опишите и пришлете либо непосредственно нам, либо в техн. отдел Арткома. Собирать замечания по форуму вообщем-то затруднительно.

[exzerodivide]

У нас весь процесс по MG в почте :-)
Харрис, хотел спросить, мне показалось, или MG на линуксе сделана ?

[harris]

У нас весь процесс по MG в почте :-)
Харрис, хотел спросить, мне показалось, или MG на линуксе сделана ?

Да. Серия iPECS - и LIK и MG- сделаны на линуксе.