Доброго времени суток. Может кто сталкивался или тыкнет где почитать? Проблема:
Имеем CS1000 - rel.4.5 в точке А. В точке Б подключаем i2004 - он конектится, спрашивает node id, tn - вбиваем, ок - сервер анричибл. На сигналенге видим что фон региться, за тем - терминал такой-то - connection lost. Ага, пингуем с сигналинга телефон - 536мс, со словами "а что же вы хотите?" радостно потираем ручки. Но! При этих же условиях софтфон нормально региться и даже можно разговаривать(729 кодек), правда с искажениями и задержкой.
Вопрос:а)хардовые телефоны более критичны к задержкам?
б)где почитать о требовниях к транспорту, а то я что-то не нашёл, или глаз к вечеру замылился :)

В EM на ноде 802.1q галочка стоит?

Stanislav пишет
Доброго времени суток. Может кто сталкивался или тыкнет где почитать? Проблема:
Имеем CS1000 - rel.4.5 в точке А. В точке Б подключаем i2004 - он конектится, спрашивает node id, tn - вбиваем, ок - сервер анричибл. На сигналенге видим что фон региться, за тем - терминал такой-то - connection lost. Ага, пингуем с сигналинга телефон - 536мс, со словами "а что же вы хотите?" радостно потираем ручки. Но! При этих же условиях софтфон нормально региться и даже можно разговаривать(729 кодек), правда с искажениями и задержкой.
Вопрос:а)хардовые телефоны более критичны к задержкам?
б)где почитать о требовниях к транспорту, а то я что-то не нашёл, или глаз к вечеру замылился :)
Могу посмотреть на снеффер трейсы.
Нет - настройки RUDP соединения у всех одинаковые, и в 4.5 могут меняться в любую сторону через usi* команды в PDT на SS

Но раз сет норально проходит CSV (порт 4100) то возможно у вас в сети есть ограничения на TPS (port 7300) или VTM (5100)/UFTP (5105) - все эти порты показаны в isetShow, если что :)
Пинг к RUDP отношение имеет весьма опосредованное. Это ICMP а не UDP соединение на конкретный порт,
Есть документ, который описывает требования к файрволлам
Data Networking for Voice over IP
Document Number: 553-3001-160
Document Release: Standard 2.00
Date: September 2004

И

Converging the Data Network with VoIP
Document Number: 553-3001-160
Document Release: Standard 3.00
Date: August 2005

2TheRam - да
2Lexad - ок, спасибо, буду читать и проверять.

Если нет уверенности, что всё сетевое на пути пакетов поддерживает эту фичу - лучше галку то убрать...

Кстати помимо настроек RUDP на телефоне
pdt> help usi
usi
UNISTIM related commands:

usiSetPhoneRudpRetries Set RUDP Max Retries Count for IP sets
usiGetPhoneRudpRetries Get RUDP Max Retries Count for IP sets
usiSetPhoneRudpTimeout Set RUDP Timeout value (in msecs) for IP sets
usiGetPhoneRudpTimeout Get RUDP Timeout value (in msecs) for IP sets
pdt>
В природе есть патч который делает аналогичные вещи для части RUDP не на стороне сета.
Номер не скажу, он вроде в Limited доступе

Но для того, чтобы понять зачем оно надо надо затянуться распечаткой этой
http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol страницы
Ну или ссыльной с неё вот этой.
http://www.javvin.com/protocolRUDP.html

И посмотреть, что же происходить с RUDP частью.
500ms - это не очень хорошо, но терпимо.
То что 729 кодек вещает - ни оч чем не говорит - дестинейшн для RTP может быть в том же хабе, да и G.* кодеки как результат потери пакетов могут только портить звук, да ябедить на QoS .
Сетку смотреть надо. Не в телефонах дело.

Для фазы два есть
pdt> help RID
RID
remote iset diagnostics commands:

rPing Request IP set to ping a IP address
rPingStop Request IP set to stop pinging a IP address
rTraceRoute Request IP set to trace route a IP address
rTraceRouteStop Request IP set to stop tracing route a IP address
RUDPStatShow Show RUDP/UNIStim statistics for a IP set
eStatShow Show Ethernet statistics for a IP set
isetInfoShow Show DHCP configurations and iset information for a IP set
RTPStatShow Show most recent RTCP statistics information
RTPTraceShow Show RTCP statistics information periodically for number of polling period
RTPTraceStop Stop previous issued RTPTraceShow command for a IP set