OOH323 не хочет слать dtmf в h245signal.

[starterx]

Или все-таки метод выбирается из доступных в tcs ремотной стороны и метод указанный в конфиге игнорируем ?

[amateur]

Или все-таки метод выбирается из доступных в tcs ремотной стороны и метод указанный в конфиге игнорируем ?

TCS - это набор возможностей терминала. Очевидно, что у другого терминала набор возможностей может отличаться. Выбор метода передачи DTMF осуществляется из набора ОБЩИХ возможностей обоих терминалов. Поэтому, если удаленная сторона не заявила о возможности принимать h245alphanumeric, то нет смысла передавать DTMF в ее сторону этим методом.

У Вас есть сомнение в правильности сделанного драйвером выбора? Для проверки нужно видеть TCS удаленной стороны. Если там заявлен h245alphanumeric, то это ошибка. Если не заявлен, то все правильно.

[starterx]

У Вас есть сомнение в правильности сделанного драйвером выбора? Для проверки нужно видеть TCS удаленной стороны. Если там заявлен h245alphanumeric, то это ошибка. Если не заявлен, то все правильно.

нет, я доволен
Просто may, в предыдущих постах, написал что метод выбираем исключительно руководствуясь настройкой пира не взирая на TCS.
А с точки зрения протокола, конечно так вернее.
Имеет смысл отразить в документации, что dtmfmode это не жестко заданный метод, а preferred из доступных на пире.

Кстати как поведет себя канал если не будет совместимых ? Будем слать то, как указано в dtfmmode или в дефолтном rfc2833 ?

[amateur]

Кстати как поведет себя канал если не будет совместимых ? Будем слать то, как указано в dtfmmode или в дефолтном rfc2833 ?

Код: Выделить всё

               else {
                  ooQ931SendDTMFAsKeyPadIE(pCall, (const char*)cmd.param2);
               }

Сами разберетесь?

[may]

У Вас есть сомнение в правильности сделанного драйвером выбора? Для проверки нужно видеть TCS удаленной стороны. Если там заявлен h245alphanumeric, то это ошибка. Если не заявлен, то все правильно.

нет, я доволен
Просто may, в предыдущих постах, написал что метод выбираем исключительно руководствуясь настройкой пира не взирая на TCS.
А с точки зрения протокола, конечно так вернее.
Имеет смысл отразить в документации, что dtmfmode это не жестко заданный метод, а preferred из доступных на пире.

Кстати как поведет себя канал если не будет совместимых ? Будем слать то, как указано в dtfmmode или в дефолтном rfc2833 ?

Я несколько освежил в памяти, как там на самом деле происходит Со стороны ooh323 в TCS выдаются все возможные варианты, выбирается для передачи совместимый
метод. Если отвечающая сторона их дает несколько, то по приоритету - rfc2833, h245alpha, h245signal. Если совместимого метода нет, то используется Q.931 info.

[starterx]

Вполне.
Спасибо за помощь. Думаю тему можно считать закрытой.

[tma]

Поэтому, если удаленная сторона не заявила о возможности принимать h245alphanumeric, то нет смысла передавать DTMF в ее сторону этим методом.

Как показывает практика, это не всегда так. На самом деле принудительно выставлять метод полезно с крупными операторами, у которых, как обычно, стоит что-то дорогое и особо кривое, которое может объявлять один метод, а ждать DTMF в другом, не объявленным.
Это ремарка и довольно-таки частный случай.

[may]

Поэтому, если удаленная сторона не заявила о возможности принимать h245alphanumeric, то нет смысла передавать DTMF в ее сторону этим методом.

Как показывает практика, это не всегда так. На самом деле принудительно выставлять метод полезно с крупными операторами, у которых, как обычно, стоит что-то дорогое и особо кривое, которое может объявлять один метод, а ждать DTMF в другом, не объявленным.
Это ремарка и довольно-таки частный случай.

Да, бывает такое. Но по опыту эти кривые приборы, как правило, понимают Q.931 Indication.
Можно конечно сделать параметр forcedmtfmode, но пока необходимости не вижу.

Патч, обсуждаемый здесь, закоммичен в svn во все версии, от 1.8 до trunk, кроме 10. Она закрыта совсем.

[starterx]

На прошлой неделе в процессе настройки выловил еще одну багу с roundtrip. Забыл отписать сразу.
При включенном roundtrip с периодом 1с рвались звонки через 256с.
Сниф как всегда помог.
Счетчик sequence number для roundtrip типа байт. И после sequence number=255 следующий пакет отправляем с sequence number=0, и по получению response от удаленной стороны с sequence number=0 делаем release complete c cause =102.

[amateur]

Как показывает практика, это не всегда так. На самом деле принудительно выставлять метод полезно с крупными операторами, у которых, как обычно, стоит что-то дорогое и особо кривое, которое может объявлять один метод, а ждать DTMF в другом, не объявленным.

Не понял суть Вашего предложения. Как можно его охарактеризовать? "Нашел ошибку, допусти еще одну" ?