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

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

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

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

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

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

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

Что то как то в одну кучу все смешались :-)
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 интерпретатор, имя под рукой сниффы не так уж и сложно.

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

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

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

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

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.ХХ вагон и маленькая тележка.
Остановимся собственно на 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 ?


Мне все же кажется, что немного не так.
1. Заполнять и интерпретировать Display IE в сообщениях ALERTING, CALL PROCEEDING, SETUP, CONNECT, PROGRESS (как минимум, ИМХО). По-хорошему, с учетом того, что имя может приехать и так и так, необходимо ввести приоритет полей, или явным образом указывать, откуда брать имя.
2. Для совместимости с предыдущими версиями прошивок VoIP плат обеспечить перенос полей из H.225.0 в H.450.1
3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.225

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

Я не говорил про "отдельно 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 .

Да, но LDK поддерживает передачу имени абонента только для QSIG.
H.450 - это как QSIG на линиях ISDN. Поэтому если используется сетевой план нумерации (линии NET, нумерация NET), то LDK передает имя вызывающего абонента в сообщении протокола Н.450.1 - SupplementaryService: serviceApdu: ARG-callingName


Не думаю, что IE Display настолько актуальны. Поскольку LDK уже старая станция, то врядли корейцы возьмутся развивать ее возможности. Возможны только какие-то минимальные изменения софта.
Поэтому мы хотели ограничиться сообщением Сonnect (как я уже писал именно на это были жалобы):
- убрать IE Display из Q.931 (поскольку именно это, как я понял, выводится на дисплей вызывающего терминала других производителей);
- "3. Обеспечить корректное заполнение Connected Number IE сообщения CONNECT H.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 (межпользовательская информация, не интерпретируемая сетью)
Я, если честно, дублирования не вижу.


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


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

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

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

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

Вот что гласит стандарт(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 я активно способствую :-)

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

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

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

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

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

виноват, наследника openh323 - h323plus имел в виду.
На самом деле, хочу попробовать сам и начать с gnugk, заставив его переносить поля.

Почему h323plus?
С gnugk вообще не понял замысла.

ну во-первых он удобнее для экспериментов.
Во-вторых, как чисто H.323-маршрутизатор он мне более интересен, нежели астер.
h323plus - openh323 фактически помер в своем дальнейшем развитии. Его дело продолжил h323plus, к тому же gnugk собирается как раз с openh323/h323plus

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

Вы хотели сказать худо-бедно="ровно на половину", тоесть только в одну сторону?
А работать с опалом в астериске я и не предлогал.

В обе, если не считать небольшой косяк с callerID name

А почему, кстати? Думаю, что астер ставится на предприятиях все больше и больше, причины разные могут быть, у меня началось с необходимости организации конференций и уж потом подтянулась подключение филиалов и удаленных точек. Так что, человеческий и нормально документированный способ соединения ipLDK и астера совсем не помешал бы.

Коллеги, обладающие девелоперским инсайдом, к вам возникла пара вопросов (в процессе перепиливания gnugk):
1. Что означают первые 2 байта в имени в H.450.1 ? ( например 13 октетов, 00 50 55 72 6d 61 6e 56 42 5f 46 61 78 .PUrmanVB_Fax )
Можно ли их безболезненно отбросить ? При формировании имени в сторону LDK как они должны вычисляться ?
2. Как определять, что "с той стороны" станция LG ? Есть варианты через:
nonStandardData = {
nonStandardIdentifier = h221NonStandard {
t35CountryCode = 97
t35Extension = 0
manufacturerCode = 1112
}
data = 14 octets {
4c 47 20 45 6c 65 63 74 72 6f 6e 69 63 73 LG Electronics
Вопрос: является ли manufacturerCode и значение data одинаковыми для ipLDK, LIK и MG ?

А 30 секундное ограничение длительности звонка из астериска на LDK как побороли?

Убрал Н245Tunneling и H.323 Fast Start из настроек на обоих сторонах. Сидел две минуты, разговаривал сам с собой - не рвалось

gnugk в одну сторону запилен (LG->GK)
Имя нормально подменяется, при отсутствии имени из H.450, Display IE затирается, что бы не видеть мусор.
Вопрос по поводу 2 первых октетов имени от LG остается открытым.
Что успел увидеть:
1. Это функция от только длины имени
2. Что видно сейчас:
Длина_имени_побайтно(dec) Первые_2_октета (hex)
1 00 00
2 00 08
3 00 10
4 00 18
5 00 20
6 00 28
7 00 30
8 00 38
9 00 40
10 00 48
11 00 50
12 00 58

Вопрос: так как же они, эти 2 байта, считаются ?
PS Это нужно для допиливания второй части (формирование имени в сторону LG)

Сам спросил - сам отвечу.
параметр длины LG рассчитывается так: y=8*(x-1)
В общем, есть допиленная мной версия gnugk 2.3.4
Умеет следующее:
1. Формировать и отправлять в setup имя в h.450.1. iPEKS-MG его принимает и отображает. Первое происходит всегда, но по-хорошему это должно регулироваться конфигом (to-do)
2. Обнаруживать, что звонит LG, на основании этого:
2.1 Затирать имя в Q.931 и вставлять правильное из H.450.1. Если в последнем пусто - имя не передавать.
2.2 Добавлять ко всем сообщениям в сторону LG H.450.1 с именем звонящего.

Готов выложить скомпиленный бинарь(debug-версия), тестовый конфиг и сорцы (проект в VS 2010).
Есть заинтересованные пощупать ?
Смысл проекта - интеграционная платформа между LG и Cisco&Avaya.
PS Если кто-то возьмется потестировать с LIK и ipLDK - был бы признателен. Все что нужно - виндовая машина.