ARTCOM LOGO

Здравствуйте, гость ( Вход | Регистрация )

7 страниц V   1 2 3 > » 

exzerodivide
Отправлено: 13.3.2013, 17:59


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


1. На наличие sending complete ей пофиг, на интерфейсе нет команды isdn overlap-receiving. Соответственно, шлет ли его лыжа или нет - с точки зрения цыски ни на что не влияет. Если бы даже и была - опять-таки, пир без Т, номер достаточен для маршрутизации и ждать нечего.
2.По-умолчанию цыска шлет setup без sending complete, соответственно лик и начинал тупить, ожидая интердиджит таймер. Лечится добавлением isdn sending-complete на интерфейс Serial0/0/1:15.

Вот и все.
  Форум: Техническая поддержка iPECS-LIK & iPECS-UCP · Просмотр сообщения: #75673 · Ответов: 40 · Просмотров: 22737

exzerodivide
Отправлено: 13.3.2013, 15:21


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


С учетом того, что конфига цыски не было, предположить, как она себя поведет, получив setup без sending complete сложно.
Но следует помнить следующее:
1. Прием цифр оверлапом управляется командой isdn overlap-receiving. В отсутствии этой команды маршрутизация начинается немедленно, после получения сетапа, вне зависимости от наличия sending complete. При наличии команды isdn overlap-receiving И подходящего диал-пира с T-терминатором, цыска ждет таймер T.302 (10 сек по умолчанию) или получения sending complete, после чего начинает маршрутизацию. Если пира с T-терминаторм нет, то маршрутизация начинается после того КАК БУДЕТ СОБРАНО необходимое для маршрутизации количество цифр ( произойдет матчинг диал-пира), и в пир уедут собранные, а не набранные цифры.
2. Принудительная отправка sending complete при исходящем звонке на интерфейсе управляется командой isdn sending-complete. По умолчанию - выключено.
  Форум: Техническая поддержка iPECS-LIK & iPECS-UCP · Просмотр сообщения: #75669 · Ответов: 40 · Просмотров: 22737

exzerodivide
Отправлено: 16.11.2012, 15:40


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Уточняющий вопрос - а после каких действий пользователя на 8002 его линия начинает отображаться у других абонентов как занятая ?
  Форум: Техническая поддержка iPECS-LIK & iPECS-UCP · Просмотр сообщения: #71886 · Ответов: 6 · Просмотров: 3514

exzerodivide
Отправлено: 31.10.2012, 13:55


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(Alexey A. Astashov @ 29.10.2012, 18:36) *
1. Действительно для нормального сетевого плана по SIP ipLDK не годится, нужен минимум iPECS.
2. Имена да, действительно на SIP работают в один конец sad.gif это минус.

Все трансферы и форварды работают нормально по SIP.
Нормально также работет IVR и распределеие звонков через IVR на любой офис. Есть нюанс, все LG станции между собой свзязаны по H.323, и все звонки между Asterisk шлюзами и ipLDK разруливает iPECS-MG, вот тут и вышло его прекрасное дополнение. А так при необходимости с телефонного аппарата можно сделать Transfer вызова на любую станцию включая Asterisk абонентов и наоборот.

Рекомендую посмотреть на занятие VOIB каналов при трасфере на MG когда оба плеча на сипе.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #71243 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 29.10.2012, 11:36


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(Alexey A. Astashov @ 29.10.2012, 9:21) *
Я и не говорил что работать не будет, работать будет, но пляски с бубном обеспечены smile.gif H.323 очень специфический протокол и разные вендоры его реализуют хрен пойми как в отличии от SIP, с которым тоже проблемы есть но гораздо меньшие. smile.gif

Использование SIP на лыже дает 2 существенных ограничения:
1. Невозможность использования сетевого плана в том виде, как это предусмотрено разработчиками.
2. Имена абонентов пропадают.

H.323 ни разу не специфичный, в отличие от сипа он базируется на Q.931 и жестко стандартизирован, чего не скажешь о сипе, где каждый лепит что может, кладя на RFC огромный болт. Для общего развития рекомендую посмотреть что с сипом сделала МС в линке, а так же зоопарк с шифрованием.
То, что конкретно в вашем случае в меньшей степени повезло с h.323 и в большей - с сипом - заслуга сугубо Ваша и астера.
Основные косяки лыжного h.323-стека изъезжены вдоль и поперек, способы обхода описаны, как мной так и Иваном, и работало это как в связке, описанной мной (причем базовый функционал был поднят за 2 дня), так и в связке с астером у Ивана.
Пользуясь случаем хотел спросить - как у Вас на сипе работает трансфер и форвард когда оба плеча на voip ? :-)
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #71147 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 28.10.2012, 10:43


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(Alexey A. Astashov @ 26.10.2012, 21:40) *
Сейчас скажу оффтопом:
НИКОГДА, НИКОГДА не используйте H.323 протокол для связки LG с обордованием отличным от LG, иначе будут прекрасные танцы с бубном smile.gif проще всего использовать протокол SIP, и еще лучше связать данные станции через промежуточный Asterisk учстановленный гденибудь на виртуалке. Кстати панас с Астером по H.323 вроде живет нормально, LG вроде тоже работает, но есть проблемы, результат - перевели все на SIP.

Ничего подобного. У меня в связке через 2821 работали: CUCM 6, ipLDK-300 и MG-100 по h.323 с сетевым планом. Единственное, что потребовало доработки - имена абонентов между лыжей и не-лыжей.
Так что - дорогу осилит идущий, все проблемы решаемы, тем более - при наличии опенсорсного астера.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #71132 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 22.10.2012, 10:53


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(ЛыЖник @ 22.10.2012, 11:25) *
Дак я и не спорю. Вы можете интернет по Е1 шпилить. Имеется ввиду не как весь канал передачи организован, а последнюю милю.

Осмелюсь спросить - а какое это имеет значение в данном случае ?
Оптика/релейка/телепатический канал и т.д.
Пров отдал E1. Точка. Все остальное абоненту до лампочки.
  Форум: Техническая поддержка iPECS-LIK & iPECS-UCP · Просмотр сообщения: #70895 · Ответов: 33 · Просмотров: 16446

exzerodivide
Отправлено: 22.10.2012, 9:57


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(ЛыЖник @ 22.10.2012, 9:19) *
Оппаньки! Аффтар жжот нипадецки! Я пацстол! Бугага! Вы сами-то поняли...?

Как вылезешь из-под стола, прочти еще раз ВНИМАТЕЛЬНО пост Стаса. Топикстартер описал вполне реальную ситуацию.
  Форум: Техническая поддержка iPECS-LIK & iPECS-UCP · Просмотр сообщения: #70891 · Ответов: 33 · Просмотров: 16446

exzerodivide
Отправлено: 8.10.2012, 17:45


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


[GS55H17Ai.rom] Html V File Extract Success![745]
[HtmlExtractProcess]extract end
Thu Jun 30 14:45:00 UTC 2011
[SYSLOG ][11/06/30 14:45:38]

[SYSLOG ][11/06/30 14:45:38] ===== START iPECS-MG_SYSTEM =====
[SYSLOG ][11/06/30 14:45:38] Version : iPECS-MG 55M-1.7Ai
[SYSLOG ][11/06/30 14:45:38] Release Date : MAR/11
[SYSLOG ][11/06/30 14:45:38] Working Dir : /
[SYSLOG ][11/06/30 14:45:38] Process ID : (PID 81)
[SYSLOG ][11/06/30 14:45:38] First Main Act2 Init-Complete Ver(1.1)
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70556 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 4.10.2012, 16:11


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Нашел кстати в закромах родины дамп.
172.16.18.1 - Cisco 2821, инициатор
172.16.18.250 - транслятор имен Display IE <-> H.450
172.16.20.100 - MG 100
Делал год назад примерно.
Что примечательно:
1. Цыска шлет SETUP без SENDING COMPLETE, но с h225.canOverlapSend = FALSE
2. MG присылает SetupAck, но цыска не ругается Status'ом.
3. Цыска инициирует H.245 до коннекта, при этом процедура корректно отрабатывается MG.
4. Единственный баг - на факсе MG переключается с G.729 на G.711 вместо T.38

Так что early h.245 раньше прекрасно работал, сломали где-то по пути.


Прикрепленные файлы
Прикрепленный файл  1341_5207_tun_on_fs_on_fax_g711.pcap.zip ( 3,81 килобайт ) Кол-во скачиваний: 3
 
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70449 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 4.10.2012, 15:10


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Ты прям для сабжевого панаса написал ?
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70438 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 4.10.2012, 14:38


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Я бы для начала убедился что в настройках у порнослоника действительно стоит en bloc.
Все гайды пишут что у него по дефолту overlap, а при включенном наборе en bloc ом нужно добавлять #.

ИМХО это особо на ситуацию не влияет, но потренироваться можно.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70431 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 4.10.2012, 13:02


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Вердикт в двух словах: партнеру незамедлительно выправить руки, особенно сетевикам-затейникам.
Теперь развернуто:
1.Мы видим классический состоявшийся FS между панасом и ликом.
2. По завершению процедуры FS, исходя из того, что у обоих сторон стоит h225.h245Tunnelling = FALSE, панас в соответствии с требованиями стандарта, параграф 8.2.3 Switching to a separate H.245 connection
Код
When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. In order to facilitate initiation of the separate H.245 connection by either endpoint, each endpoint may include h245Address in any Q.931 message it sends during the call. If, at the time an endpoint deems it necessary to initiate the separate H.245 connection, it finds that it has not yet received the h245Address of the other endpoint, the endpoint shall transmit a Facility message with a FacilityReason of startH245 and provide its H.245 address in the h245Address element. An endpoint receiving a Facility message with a facilityReason of startH245 which has not already independently initiated the separate H.245 channel shall open the H.245 channel using the h245Address specified. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

отправляет facility (пакет номер 81 в дампе) с reason:startH245, при этом поле ipAddress = 192.168.0.103, но адрес, с которого на самом деле шлет панас - 80.69.147.250.
Далее LIK, в соответствии с вышеуказанным параграфом:
Код
An endpoint receiving a Facility message with a facilityReason of startH245 which has not already independently initiated the separate H.245 channel shall open the H.245 channel using the h245Address specified. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

отправляет TCP SYN с адреса 61.41.111.85 на адрес 192.168.0.103 порт 10109 (пакет номер 83 в дампе).
Разумеется, это ни к чему не приводит, что подтверждается отсутствием ACKов.
С учетом того, что стандарт не содержит указаний, что делать в таких случаях, панас замирает в таком состоянии и не реагирует на запросы LIK об открытии H.245 (см Connect LIKа).

Так что вывод простой: панас ПЫТАЕТСЯ вести себя, как и в предыдущих снифах, но кривые настройки сети (NAT и т.д.) мешают ему это сделать.

UPD: Если возвращаться к началу разговора то видно, что между панасом и МГ H.245 нормально открывается (startH245->SYN->SYN,ACK->ACK), панас отправляет TCS и MSD, но МГ отвечает только на MSD, TCS игнорирует, что и приводит к обрыву звонка.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70411 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 3.10.2012, 21:33


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(harris @ 3.10.2012, 20:09) *
В данном случае я прислал снифер вызова от другого клиента (с Панаса на ipLDK), но на котором точно такая же проблема при его стыковке с MG.
Но есть и другая трассировка именно с того же Панаса на разные направления: MG, Avaya (то, что я уже выложил) и на iPECS LIK. Так вот трассировки LIK и ipLDK одинаковые.


Выложите пож. одинаковые(одна и та же станция при неизменных настройках) с Avaya, Cisco и LIK/ipLDK.
А то разные станции (а их видно по версиям и фирмварям) немного смущают.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70349 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 3.10.2012, 17:03


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(harris @ 3.10.2012, 16:13) *
OK. Я понял, почему Панас может запрашивать TCS, даже при FS.
Непонятно, почему он тогда не запрашивает это при вызове на ipLDK/LIK.

А точно настройки на панасе одинаковые везде ? DTMF и факс могут влиять на наличие H.245
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70343 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 3.10.2012, 16:46


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(harris @ 3.10.2012, 15:28) *
Вы в чем меня хотите убедить, что MG не отвечает на TCS?? - Так я это вижу.
Я же Вам пытаюсь пояснить, почему она не отвечает на TCS. От Панаса был запрос на FS, вот она и отвечает тоже Fast Start'ом.

Дампы?? Пожалуйста: http://rusfolder.com/32941464 Пароль: panas-mg

Panasonic - MG
Panasonic - Avaya
Panasonic- iPECS LDK (cм. 1-й вызов)

Обратите внимание:
LDK (и LIK) не запрашивает след. цифры номера (не отвечает с SetupAck), а сразу дает Call_Proc с Fast Start. И Панасоник нормально работает по FS, и не запрашивает TSC (!!!). Т.е. здесь нормальный рабочий процесс установления соединения по FS.
Avaya также, как и MG отвечает с Fast Start'ом, но во втором (!!) сообщении (MG - в Call_Proc, а Avaya - в Alert). И именно это "не нравится" Панасу. Получив первое ответное сообщение без FS, Панас переходит на запрос TCS (переходит на Early H.245). Причем Панас переходит на процедуру открытия Н.245 уже после получения ответа с FS во втором сообщении от вызываемой стороны.
Правда, надо признать, что Avaya отвечает на TCS, а MG - нет. MG продолжает работать с по FS.
Вопрос: а ответ на FS станция MG обязательно должна была дать в первом ответном сообщении?? Или же в любом??
Что там по стандарту?

Ну вот, пошел конструктив на одном языке :-)

В общем, по мнению-консенсу с Иваном (случай Panas-MG)
1. Панас присылает setup с canOverlapSend = FALSE и без Sending Complete, что означает неспособность работать оверлапом. Sending Complete согласно параграфу 5.2.1 Q.931 Reccomendations является опициональным:
Код
If en bloc receiving is used, the SETUP message shall contain all the information required by the
called user to process the call. In this case, the SETUP message may contain the Sending complete
information element.


2. MG присылает в ответ Setup Ask, чем изрядно удивляет панас, в ответ он шлет Status.
3. С учетом того, что панас прислал SETUP c OLC, а MG ответил CallProc с OLC, процедуру FS можно считать состоявшейся.
4. Принимая во внимание пункт 3(процедура FS состоялась), панас начинает процедуру H.245, отправляя TCS и MSD, запуская таймеры T101 и T106, MG не отвечает на указанные сообщения до истечения таймера, звонок рвется.

Что касается ответа на FS - стандарт говорит следующее:
Параграф 8.1.7

Код
When the called endpoint desires to proceed with the Fast Connect procedure, it sends a Q.931 message (Call Proceeding, Progress, Alerting, or Connect) containing a fastStart element selecting from amongst the OpenLogicalChannel proposals offered by the calling endpoint. The calling endpoint shall process each of these messages until it determines that Fast Connect is accepted or refused. Although the calling endpoint may receive the fastStart element in a Facility message sent by a Gatekeeper, the called endpoint shall not use the Facility message to send fastStart. Channels thus accepted are considered opened as though the usual H.245 openLogicalChannel and openLogicalChannelAck procedure had been followed. The called endpoint shall not include a fastStart element in any Q.931 message sent after the Connect message and shall not include fastStart in any Q.931 message unless the Setup message contained a fastStart element.


То есть, ответ может прийти в любом пакете, включая коннект.

В общем, проблем со стороны MG видится две:
1. Setup Ask в ответ на Setup со сброшенным canOverlapSend. Насколько это повлияло на общую картину - сложно сказать, но это в любом случае неправильно.
2. Игнорирование H.245-процедур до коннекта.

В качестве воркэраунда я бы посоветовал:
1. Уйти от FS и parallel (Early) H.245 на обоих станциях.
или для проверки:
1. На обоих сторонах dtmf поставить в in-band
2. T.38 выключить, факс поверх g.711alaw (ulaw)

Как-то так.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70342 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 3.10.2012, 12:38


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(harris @ 3.10.2012, 11:23) *
С чего Вы это взяли?? Такие же возможности, как и в TCS.
Отвечать на TCS обязательно для открытия H.245, но при FS канал H.245 как таковой не открывается:
With the use of Fast Connect, there is no need to open an H.245 channel, as long as all needed media can be negotiated via Fast Connect.

Давайте не будем читать обзорные презентации по протоколу с packetizer.com (да-да, страницы 110-112 презентации), а обратимся к официальному описанию протокола H.323 v4
Код
8.1.7   Fast connect procedure
H.323 endpoints may establish media channels in a call using either the procedures defined in Recommendation H.245 or the "Fast Connect" procedure described in this subclause. The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection.
The calling endpoint initiates the Fast Connect procedure by sending a Setup message containing the fastStart element to the called endpoint. The fastStart element consists of a sequence of OpenLogicalChannel structures describing media channels which the calling endpoint proposes to send and receive, including all of the parameters necessary to immediately open and begin transferring media on the channels. Details of the content and usage of the fastStart element are discussed below.


Поясняю мысль - в элементе fastStart содержатся структуры OpenLogicalChannel вида:

Код
OpenLogicalChannel    ::=SEQUENCE
{
    forwardLogicalChannelNumber    LogicalChannelNumber,

    forwardLogicalChannelParameters    SEQUENCE
    {
        portNumber    INTEGER (0..65535) OPTIONAL,
        dataType    DataType,
        multiplexParameters    CHOICE
        {
            h222LogicalChannelParameters    H222LogicalChannelParameters,
            h223LogicalChannelParameters    H223LogicalChannelParameters,
            v76LogicalChannelParameters    V76LogicalChannelParameters,
            ...,
            h2250LogicalChannelParameters    H2250LogicalChannelParameters,
            none    NULL  -- for use with Separate Stack when
                  -- multiplexParameters are not required
                  -- or appropriate

        },
        ...,
        forwardLogicalChannelDependency    LogicalChannelNumber OPTIONAL,
            -- also used to refer to the primary logical channel when using video redundancy coding
        replacementFor    LogicalChannelNumber OPTIONAL

    },


где DataType это:

Код
DataType        ::=CHOICE
{
    nonStandard    NonStandardParameter,
    nullData    NULL,
    videoData    VideoCapability,    
    audioData    AudioCapability,
    data        DataApplicationCapability,
    encryptionData    EncryptionMode,
    ...,
    h235Control    NonStandardParameter,
    h235Media    H235Media,
    multiplexedStream    MultiplexedStreamParameter
}


А теперь TCS: (документ H.245 v.4)

Код
B.2.2.1 Capability Table
A TerminalCapabilitySet may contain zero or more CapabilityTableEntrys. At the start, no table entries are defined. When a CapabilityTableEntry is received, it replaces the previously received CapabilityTableEntry with the same CapabilityTableEntryNumber. A CapabilityTableEntry without a Capability may be used to remove the previously received CapabilityTableEntry with the same CapabilityTableEntryNumber.

B.2.2.2    Capability Descriptors
CapabilityDescriptors are used to indicate a terminal's capability to transmit and receive. Each CapabilityDescriptor provides an independent statement about the terminal's capabilities.

B.2.2.3    Capability
The choices receiveVideoCapability, receiveAudioCapability, receiveDataApplicationCapability, receiveUserInputCapability and receiveMultiplexedStreamCapability indicate the capability to receive according to the respective VideoCapability, AudioCapability, DataApplicationCapability, UserInputCapability and MultiplexedStreamCapability.
The choices transmitVideoCapability, transmitAudioCapability, transmitDataApplicationCapability, transmitUserInputCapability and transmitMultiplexedStreamCapability indicate the capability to transmit according to the respective VideoCapability, AudioCapability, DataApplicationCapability UserInputCapability and MultiplexedStreamCapability.
The choices receiveAndTransmitVideoCapability, receiveAndTransmitAudioCapability, receiveAndTransmitDataApplicationCapability, receiveAndTransmitUserInputCapability and receiveAndTransmitMultiplexedStreamCapability indicate the capability to receive and transmit symmetrically according to the respective VideoCapability, AudioCapability, DataApplicationCapability and UserInputCapability and MultiplexedStreamCapability. These code points may be useful for indicating that the receive and transmit capabilities are not independent

Capability        ::=CHOICE
{
    nonStandard    NonStandardParameter,

    receiveVideoCapability    VideoCapability,
    transmitVideoCapability    VideoCapability,
    receiveAndTransmitVideoCapability    VideoCapability,

    receiveAudioCapability    AudioCapability,
    transmitAudioCapability    AudioCapability,
    receiveAndTransmitAudioCapability    AudioCapability,

    receiveDataApplicationCapability    DataApplicationCapability,
    transmitDataApplicationCapability    DataApplicationCapability,
    receiveAndTransmitDataApplicationCapability    DataApplicationCapability,

    h233EncryptionTransmitCapability    BOOLEAN,
    h233EncryptionReceiveCapability    SEQUENCE
    {
        h233IVResponseTime    INTEGER (0..255),    -- units milliseconds    
        ...
    },
    ...,
    conferenceCapability    ConferenceCapability,
    h235SecurityCapability    H235SecurityCapability,
    maxPendingReplacementFor    INTEGER (0..255),
    receiveUserInputCapability    UserInputCapability,
    transmitUserInputCapability    UserInputCapability,
    receiveAndTransmitUserInputCapability    UserInputCapability,

    genericControlCapability    GenericCapability,
    receiveMultiplexedStreamCapability    MultiplexedStreamCapability,
    transmitMultiplexedStreamCapability    MultiplexedStreamCapability,
    receiveAndTransmitMultiplexedStreamCapability    MultiplexedStreamCapability,
    receiveRTPAudioTelephonyEventCapability    AudioTelephonyEventCapability,
    receiveRTPAudioToneCapability    AudioToneCapability
}


Разница в полях OLC в FS и структурах TCS надеюсь понятна стала ?

Насчет того, что при FS H.245 "как таковой не открывается" - это опять-таки заблуждение. Если кто-то из сторон хочет процедуру (как например панас) - она запускается.

Код
8.1.7.2    Switching to H.245 procedures
After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call using tunneling as described in 8.2.1 (if h245Tunneling remains enabled). An H.323 Version 4 or higher entity that uses Fast Connect in a call shall use H.245 tunneling when an H.245 Control Channel is required and shall always set the h245Tunneling field to TRUE. The process for switching to a separate H.245 connection is described in 8.2.3 and may be used by Version 3 or older entities or by newer H.323 entities when communicating with Version 3 or older entities for the purpose of maintaining backward compatibility.
When a call is established using the Fast Connect procedure, both endpoints shall keep the Q.931 Call Signalling Channel open until either the call is terminated or, for compatibility with older endpoints, until a separate H.245 connection is established.
When H.245 procedures are activated, all mandatory procedures of H.245 that normally occur upon initiation of an H.245 connection shall be completed prior to initiation of any additional H.245 procedures. The media channels that were established in the Fast Connect procedure are "inherited" as though they had been opened using normal H.245 openLogicalChannel and openLogicalChannelAck procedures. In order for such "inheritance" to succeed, media sessions opened during the Fast Connect procedure shall use only well-known sessionID values defined in Recommendation H.245.
.......SKIP......
However, an endpoint may exchange the terminalCapabilitySet message and the masterSlaveDetermination message in the Setup message as described in section 8.2.4. Such an exchange constitutes the opening of the H.245 Control Channel, but does not preclude either endpoint from proceeding with Fast Connect.


Цитата
Вся проблема, видимо, в том, что MG отвечает сообщением SetupAck без FS. Но MG в этот момент не знает, сможет ли она принять вызов, т.к не было Sending_Complete, и возможно не все цифры номера получены.
И видимо, поэтому Панас более не реагирует на поля FS, которые MG включает уже в след. сообщения (в Call_Proc).

Поделитесь с нами дампом, нам тоже интересно :-)

Цитата
2 exzerodivide:
Значит мы по-разному понимаем стандарты. Вы наблюдаете за дождем, а мы - за ротой красноармейцев. И неизвестно, что в данном случае важнее.

Игорь, не нужно мне приписывать того, что я не делаю. Я же Вам не приписываю того, чего Вы не делаете.

Цитата
Еще раз перечитал доки... Early H.245 вовсе не является дополнением к Fast Start. Это вполне самостоятельный метод.

Я это сказал в контексте связки FS и parallel H.245 в сообщениях панаса.

Цитата
Оба практически преследуют одни и те же цели - возможность передачи RTP до установления соединения (до Connect).

Опять-таки, это не совсем так. Посмотрите на структуры OLC и TCS.

Цитата
Но при Early H.245, лог. канал H.245 действительно открывается до Connect'а, а при FS стороны обмениваются необходимой информацией в сообщениях, аналогичных H.245, но без открытия Н.245 как такового.

B где-же там аналогичные сообщения ? Приведите примеры что-ли.

Цитата
Впрочем, на глубокие знания данного предмета я не претендую.. smile.gif

На глубокие знания тут никто не претендует. Достаточно читать стандарты и делать выводы.

Цитата
И давайте по-спокойнее... Корейцы, по крайней мере, пытаются найти решение, а не занимаются отписками, как обычно поступает Панас.


Да мы в общем-то и не волнуемся. К слову все забываю спросить - МГ перестала валится при получении в Setup с FS более 3(или 4) кодеков ? :-)
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70316 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 2.10.2012, 21:56


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Категорически приветствую!

Цитата(harris @ 2.10.2012, 18:29) *
Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии B.0De. Но проблема исходно, ИМХО, вовсе не в MG, а в Панасе!! Не стоит считать Панас "безгрешным". Посмотрите внимательнее, Панас ведь работает кривовато!!

Ну если сравнивать "радиус кривизны" то лыжа панас явно обогнала.
Цитата
Мне присылали трассировку аналогичного вызова. Там видно, что:
- Панас инициирует вызов как с использованием Fast Start, так и с Early H.245.

И правильно делает. Early H.245 к слову - изобретение корейцев. В стандарте это называется "Initiating H.245 tunneling in parallel with fast connect"
Цитата
- в станции MG корейцы отказались от поддержки Early H.245, поскольку Fast Start стал более распространенным методом, ИМХО

За окном шел дождь и рота красноармейцев. Early H.245 и FastStart взаимодополняют друг друга. Читай h.323 v.4 параграф 8.2.4 Лучше бы стандарт соблюдали, а не самодеятельностью занимались.
Цитата
- Вот MG и отвечает тоже с использованием Fast Start (открывает лог. канал OLC)
- Только далее оказывется, что почему-то Панас не хочет работать по FS и начинает запрашивать TCS. Почему, зачем??

Патамучта панас хочет знать UserInputIndication и RTP payload types например, а так же умеет ли шерстяной друг факс по t.38.

Цитата
Станции уже обменялись "возможностями терминала" в информ. полях FS.

Вот только не надо придумывать. "возможностями терминала" в информ. полях FS. они на FS не обменивались.

Цитата
- И зачем Панас присылает Status??? Что ему "не понравилось"?? Что его запросили об окончании набора номера (SetupAck)?? Так это согласно протоколу, Панас ведь не прислал Sending Complete.

Выложи дамп, посмотрим вместе.

Цитата
Но пока корейцы еще продолжают заниматься этой задачей (запрос по этой проблеме еще не снят).
Кстати, а у Вас есть снифер входящего вызова на MG, снятый именно на версии B.0De?? Если есть, то, пожалуйста, пришлите его срочно мне.

Лучше бы стандарт реализовывали как описано, чесслово. Или взяли тот-же openh323 если сами не могут.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #70298 · Ответов: 68 · Просмотров: 35828

exzerodivide
Отправлено: 26.7.2012, 11:32


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Павел, залогиньтесь :-)
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #67998 · Ответов: 2 · Просмотров: 3457

exzerodivide
Отправлено: 17.4.2012, 18:24


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Мое ИМХО: если ограничиваться именно поставленной задачей то оба одинаковы, будь то модификация существующего протокола(IPKTS) или надстройка над имеющимся(SIP). Принципиальной разницы нет. И в том и в другом случае телефон есть аналог некой finite state machine, со стартовой точкой в виде момента загрузки/регистрации на станции и чье состояние управляется(синхронизируется) станцией по априори выбранному протоколу.
Если предполагать использование телефонов с 3rd party PBX - то SIP предпочтительнее.
Как то так.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #63824 · Ответов: 33 · Просмотров: 10838

exzerodivide
Отправлено: 17.4.2012, 13:28


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Цитата(harris @ 16.4.2012, 18:47) *
Cisco хрен обидишь...
ИМХО, скоро весь мир будет сидеть на игле у Циско, так как он сидит (сидел) на MS smile.gif
Ну, и к тому же, видимо, у меня, как и у других сторонников "традиционной" телефонии, проявляется обычное негативное отношение к продуктам компании, пришедшей в телефонию из другой области (сетевое оборудование) и "окопавшейся" на этом рынке. smile.gif
Ведь к IP-телефонии компании-производители пришли 2 путями:
"сетевики" - осваивают функционал АТС
"связисты" - осваивают сетевые технологии...
Взаимное неприятие.... biggrin.gif

Кстати, если помнишь, то в случае цыски было еще смешнее. У них никогда не было своих PBX, только сетевое оборудование.
Но в далеком 1999 году комания Cisco купила тогдашнего инноватора рынка глосовых/видео IP-коммункаций - компанию Selsius. Это и есть разработчик нынешнего Cisco Call Manager. Изначально это была VideoPBX, но в 1997 году была добавлена возможность маршрутизации голосовых звонков. Протокол SCCP - это разработка Selsius, до сих пор в CCM имя телефона по дефолту начинается с SEP(Selsius Ethernet Phone). И купили их в итоге вместе с CCM и IP-телфонами :-)
То что мы видим сейчас - развитие той далекой Selsius Communications Manager.
Рекомендуемое чтиво по теме:
http://marknelson.us/2007/08/23/platt/
http://www.cisco.com/en/US/docs/voice_ip_c...de/cmeroad.html
http://en.wikipedia.org/wiki/Cisco_Unified...cations_Manager
Цитата
А что, вендор-специфичные сообщения - это разве не является по сути proprietary (собственным) протоколом, для которого в качестве транспорта применяется стандартный SIP?? wink.gif

Это примерно как SIP-T и H.323/GTD. Базовые протоколы стандартизованы, переносимая информация вендор-специфична или относится к другому протоколу.
Например:
https://docs.google.com/viewer?a=v&q=ca...uaLEA&pli=1

При этом, при работе со сторонней станцией ты сохраняешь все базовые возможности протокола сигнализации, то есть звонки/mwi/... без софткеев, функций администрирования и т.д.

Цитата
Да, но и потенциалы (в том числе и финансовые возможности) Cisco и LG-Ericsson (а это даже не LG Electronics) различаются в сотни раз... "Робкие" настолько, насколько хватает сил. И соревноваться здесь с Cisco бесполезно... Ну, если только по цене (??).

Это вопрос стратегии. Никто не заставляет пилить in-house систему с возможностями CUCM/MS Lync. Можно за основу взять опенсорц и пилить его под себя с фидбеком коммюнити, продавая апплайансы, свое endpoint-железо и поддерку. Novell/Red Hat тому примеры.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #63776 · Ответов: 33 · Просмотров: 10838

exzerodivide
Отправлено: 16.4.2012, 17:28


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Игорь, ну зачем же так обижать цыску :-)
Цитата
1) Cisco - производитель АТС??? Они только сейчас стали немного понимать, что требуется от АТС.

Это из серии "годы сжались в дни" :-) Достаточно посмотреть на ченджлоги CME 7.X и CM 7.X Функционал ядра давным давно стабилизировался, рост идет в сторону Unified Comms, где лыжа только начинает робкие шаги :-)

Цитата
2) А ты уверен, что Cisco использует стандартный SIP без каких-либо расширений???

Сам протокол, в отличие от тех-на-чьем-форуме-мы-находимся неизменен. Существующими средствами протокола передаются вендор-специфичные сообщения. Но это не расширение протокола как такового.

Цитата
А это как понимать???
Например,
Терминал Cisco 7970G: Поддержка Cisco CallManager 3.3(3) или более новая, протокол SCCP (Skinny Client Control Protocol)
IP-телефон Cisco 7941 поддерживает протокол SIP
Поддерживает протокол SCCP
ОК. "Поддерживает"... Так каким протоколом он "цепляется" к CM??

Зависит от заливки телефона и нужд кастомера. Заливка может быть SCCP, а может быть SIP. Вот пример скрещивния CP-796X и астера. http://www.voip-info.org/wiki/view/Asterisk+phone+cisco+79xx

Цитата
3) Вот объясните конкретно, чем SIP лучше, чем собственный протокол, IPKTS например???
С другой стороны, если чем-то больше нравится SIP, то и ставьте SIP-телефоны. Как говорится, флаг в руки...

Отвечает Александр Друзь: http://www.cisco.com/en/US/products/sw/voi...2156/index.html

The Cisco SIP IP Phone software allows businesses and service providers to use the Cisco 7940 and 7960 IP Phone platforms in any standard SIP network. The SIP software provides for both on-board traditional desktop services such as Caller-ID, Call Hold, Call Transfer, 3-Way Calling, and Call Waiting as well as an XML interface to allow for enhanced web based services. The XML interface allows the phone to transcend the traditional phone paradigm and become a true internet appliance. By supporting web browsing type functionality as well as allowing for application developers to directly control the user interaction on the phone and integrate tightly with the Cisco SIP phone, the Cisco SIP phone is a key enabler of enhanced and rapid application deployment in any SIP customer's network.

  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #63706 · Ответов: 33 · Просмотров: 10838

exzerodivide
Отправлено: 30.9.2011, 16:24


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


спутал с MG. На ipLDK низзя
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #55693 · Ответов: 15 · Просмотров: 5593

exzerodivide
Отправлено: 30.9.2011, 13:59


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


alex_kau
Как уже писали, кодеки со стороны ipLDK: G.711 и G.729 все остальное лесом.
Проверьте, как идет факс с ipLDK на MG при:
1. ipLDK - fast:on tunn:on, MG - fast:on, tunn:on
2. ipLDK - fast:off(normal), tunn:off, MG - fast:off, tunn:off
Я такое у себя видел, но не помню при каком сочетании параметров.
  Форум: Техническая поддержка iPECS-MG & iPECS-eMG800 · Просмотр сообщения: #55682 · Ответов: 15 · Просмотров: 5593

exzerodivide
Отправлено: 28.9.2011, 10:40


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690


Раздела Supplimentary Service -> DECT Registration у Вас в PC Admin'е еще нет ?
  Форум: Техническая поддержка ipLDK · Просмотр сообщения: #55565 · Ответов: 10 · Просмотров: 4349

7 страниц V   1 2 3 > » 

Новые сообщения  Открытая тема (есть новые ответы)
Нет новых сообщений  Открытая тема (нет новых ответов)
Популярная тема  Горячая тема (есть новые ответы)
Нет новых  Горячая тема (нет новых ответов)
Опрос  Опрос (есть новые голоса)
Нет новых голосов  Опрос (нет новых голосов)
Закрыта  Закрытая тема
Перемещена  Тема перемещена
 

Текстовая версия Сейчас: 29.3.2024, 8:25