Приветствую!
Имеется схема ipldk 60 - h323 - nortel Meridian (gatekeeper) - h323 - cisco 2911 - e1 - nortel Meridian 11
Проблема в том, что когда звонок идет с лыжи на Меридиан 11, подключенный через циско, то во время вызова нет КПВ. В другую сторону все работает нормально. Если отключить Fast Start, то КПВ появляется, но такое ощущение что стороны как то некорректно договариваются о кодеках и идет сильный шум в разговоре.

Если же на место 60 лыжи поставить lg ipecs 100, то все работает нормально. Кто нибудь, кто дружил лыжи с циской, сталкивался с подобной траблой?

Решали проблему с на больших LDK с FastStart при звонке на cisco, но это кажется, судя по вашему описанию, не ваш случай. Покажите снифер.

Цитата harris®-а
В ПГМ340 включены ли:
- Early H.245??
Если нет, то включите.

Включил, результатов никаких.



Сниффер чуть позже выложу.

А вообще на каких кодеках лучше всего лыжу и циску дружить?

Вопрос какой-то странный... Кодаки стандартные, выбор зависит от пропускной способности сети.
Что значит "дружить" кодаками.... "Дружат" протоколом сигнализации..

Ну что то мне не очень, допустим понятно, какой именно в лыжи g723.1, и сходу так в документации этого не нашел. В циске их несколько вариантов
g723ar53
g723ar63
g723r53
g723r63

Я подозреваю, что это g723r53 5300bps

??? По стандарту кодек G.723.1 поддерживает оба режима работы: 6.3 Кбит/с (кадр имеет размер 189 битов, дополненных до 24 байтов) и 5,3 Кбит/с (кадр имеет размер 158 битов, дополненных до 20 байтов). Режим работы может меняться динамически от кадра к кадру. Оба режима обязательны для реализации.

ITU-T G.723.1:
This coder has two bit rates associated with it. These are 5.3 and 6.3 kbit/s. The higher bit rate has greater quality. The
lower bit rate gives good quality and provides system designers with additional flexibility. Both rates are a mandatory
part of the encoder and decoder. It is possible to switch between the two rates at any 30 ms frame boundary.

Что там подразумевает под обозначениями - g723ar53, g723ar63, g723r53, g723r63 - это нужно смотреть в доке на саму Cisco.

ну вот у меня получилось завести только с одним из.

Ладно, у когонить есть рабочий конфиг для cisco при связке ее с ip ldk 60 по h323 ??

так пробовали ?:

dial-peer voice XXX voip
description 46XX on ipLDK
destination-pattern 46..
progress_ind setup enable 3
voice-class codec 10
session target ipv4:IP
dtmf-relay cisco-rtp h245-alphanumeric h245-signal rtp-nte

2exzerodivide
Начал говорить - так договаривай

g723ar53 annex a 5.3kbps
g723ar63 annex a 6.3kbps
g723r53 5.3kbps
g723r63 6.3kbps
цыска поддерживает все режимы для g.723, однако в OLC и TCS это будут разные капабилити и указание только лишь g.723 не означает появления всех его разновидностей автоматически в OLC и TCS. Про это коллега ars3n_d и спрашивал.

"это наше секретное оружие, мы про него никому не скажем" :-)
для начала человеку с индикаторами разобраться надо

а как fast start и h245 tunnel ? включить или выключить?

fast
early h.245 off
h245tunn on

ОК. А как это полагается делать по стандарту???

до кучи:
1. версия fw на воибе актуальная ?
2. снифф звонка с фастстартом и отсутствием кпв не помешал бы

примерно так

6.2.5 Audio codec
All H.323 terminals shall have an audio codec. All H.323 terminals shall be capable of encoding and decoding speech according to Recommendation G.711. All terminals shall be capable of transmitting and receiving A-law and *-law. A terminal may optionally be capable of encoding and decoding speech using other audio codecs which can be signalled via H.245 negotiation. The audio algorithm used by the encoder shall be derived during the capability exchange using H.245. The H.323 terminal should be capable of asymmetric operation for all audio capabilities it has declared within the same capability set, e.g. it should be able to send G.711 and receive G.728 if it is capable of both.
If G.723.1 audio is provided, the audio codec shall be capable of encoding and decoding according to both the 5.3 kbit/s mode and the 6.3 kbit/s mode.

то есть, парами, видимо. цыска примерно так и делает, только в разговоре переключать не умеет:

G.723.1 Codec Issues

There are two versions of G.723.1 called Annex-A and non Annex-A. These versions do not interoperate. G.723.1 Annex-A includes a built-in IETF VAD algorithm and CNG.

Also, in Cisco IOS Software Release 12.0(5)T and later, the G.723.1 codec is supported with a 5.3 kbps and 6.3 kbps rate. When a Cisco VoIP gateway sets up a call between devices that use G723.1, it is concerned only that the far-end uses G.723.1. Neither side is concerned with the 5.3 kbps or 6.3 kbps rate that is supported by the other side. This means that, while it is beneficial to have both sides support the same rate, it is possible that one side transmits at 5.3 kbps and the reverse direction transmits at 6.3 kbps. The speed that is used is viewed with the show call active voice brief command as shown here:

Cisco-router# show call active voice brief
47 : 494514hs.1 +473 pid:0 Answer active
tx:210/5040 rx:219/4380
IP 5.5.0.1:16534 rtt:3ms pl:890/0ms lost:0/0/0 delay:70/70/70ms g723r63
47 : 494514hs.2 +473 pid:1 Originate 4750001 active
TX:230/1840 rx:230/8280
Tele 2/0:0 (35): TX:6870/2290/0ms g723r63

!--- In this example the G.723.1 is operating at 6.3 kbps.

noise:0 acom:0 i/0:-79/-5 dBm
The G.723.1 standard allow stations to change rates between 6.3 kbps and 5.3 kbps during a call to adjust to network traffic loads. The Cisco VoIP gateways do not support this functionality. But they do understand if the remote device (such as a Cisco IP Phone) transmits at a different rate than was originally negotiated.

These G.723.1 codec combinations interoperate:

G.723.1 (5.3 kbps) and G.723.1 (6.3 kbps)

G.723.1 (5.3 kbps) and G.723.1 (5.3 kbps)

G.723.1 (6.3 kbps) and G.723.1 (6.3 kbps)

G.723.1 Annex-A (5.3 kbps) and G.723.1 Annex-A (6.3 kbps)

G.723.1 Annex-A (5.3 kbps) and G.723.1 Annex-A (5.3 kbps)

G.723.1 Annex-A (6.3 kbps) and G.723.1 Annex-A (6.3 kbps)

Так, сделал по вашим настройкам, КПВ появился но теперь другая трабла. При звонке с лыжи на станцию проключенную через ciscо не идет голос. Такое ощущение, что не договорилсь о кодеках. Хотя в обратную сторону все норм. На диал пире циско жесток стоит codec g711alaw, на лыжи то же default codec g711alaw.
Сейчас попробую поснифить это дело.

На лыже Version : GS88H-B.3Bd

напоминает анекдот про горбачева и молоко :-)
ждем шнифы

боюсь спросить - а почему alaw ? у вас между цыской и меридианом alaw ?

Да, везде alaw

Вот звонок с лыжи на меридиан, подключенный через cisco, при котором не ходит голос.

забавно.
0. Голос не идет в одну сторону или в обе ?
1. Крайне желателен pcap-файл и топология того, как все построено с адресами
2. gk на меридиане - стоит "в разрыв" или итоговое соединение идет все-же между лыжей и цыской ?
3. что произойдет если при прочих равных сейчас на лыже поставить start - normal, tunn - on ?

0. При звонке с лыжи голос с лыжи не слышен вообще, а с меридиана 11 периодически проскакивает, но так редко, что можно сказать что не слышен вообще.
1. http://ifolder.ru/24405173 файлик вайершарка
2. Лыжа (172.30.0.22) и циска (172.30.0.40) работают по h323 и зарегены на Меридиановской гейткипере (172.30.0.10). Но непосредственно сам траффик идет между ними напрямую.
3. tunneling сейчас стоит в ON. Fast Star на лыже включен и на циске включен, но циска его, судя по данному логу, как то странно отрабатывает. Попробую поиграться с этими параметрами, позже напишу.

Сниф снят с порта лыжи.

Класс, вырубил fast start на лыжи, стал нормально проходить звонок с лыжи на Мередиан через циско, но появилась еще более занятная проблема. При обратном звонке у лыжи отваливается voip карточка и лечится это только ребутом 0_о

У вас очень похоже что именно таже самая проблем что и у меня. Для проверки зайдите на майтененс порт платы VOIB, включите трасировку событий h323 и выложите получившийся лог.

эээ... а не напомните как это сделать?)) давно очень это делал, и уже подзабыл как.

Вам лог первого варианта звонка, или когда плата отваливается7

Нашел обсуждение такой же проблемы как у меня среди цискарей
http://www.certification.ru/cgi-bin/forum....ad&id=31403

к сожалению, они так ни к чему и не пришли(((

Вам нужна версия более новая для VOIB.

Я поленился туда отписатся про то как порешилась проблема

Если уваж. All is not what it seems имеет в виду проблему с полем reverseLogicalChannelParameters, в котором Cisco указывает адрес LDK, и LDK после этого пытается направить RTP поток сама на себя, то эта проблема решена на версии модуля VOIM B[2].3Da. В этом случае LDK попросту игнорирует информацию, полученную в поле reverseLogicalChannelParameter.
Версия VOIM B[2].3Da - тестовая, в официальную версию это исправление еще не включено. Могу выслать этот софт для проверки. Возможно, эта версия решит проблему.

Было бы очень интересно попробовать. arsen sobaka mkb.ru

Отправил. Сообщите по получении.

Так, рапортую о проверке новой прошивки.
1. Теперь получается дозваниваться с лыжи на cisco, и голос стал нормально ходить.
2. Обнаружился глюк (не знаю с новой прошивкой или это уже было), при звонке на мобильный который допустим выключен, не слышно голосовое сообщение "Абонент вне зоны действия сети и т.д.", а вместо этого проходит какое то время и идет сигнал после которого надо записать голосовое сообщение. То же самое если отбить с мобильного вызов. Должна быть фраза о предложении оставить сообщение после сигнал. Так вот ее не слышно, а после просто идет сигнал о начале записи. Вообще не понимаю как такое может быть.
3. Звонки с лыжи на основной Меридиан невозможно перевести. Точнее сам перевод проходит, но во вновь установившемся соединении не ходит голос. Грешил сначала на меридиан, но такая проблема только с лыжей. Допустим если делать такой же перевод абонента, подключенного через cisco, то все норм.

Ради интереса вернулся на старую прошивку - такая же фигня.

Значит все-таки эта версия софта решила проблему (игнорируется reverseLogicalChannelParameters)??
Уже хорошо.

А все остальное - это уже другая задача.

Рвется через один и тот же промежуток времени - во всех случаях? Если так - через какой?

Тут по ходу даже дело не в том, что рвется, а в том, что после перевода не ходит голос...




Да, но по ходу такая схема построения не живая. Слишком много косяков уже всплыло, и возможно еще всплывет((. Сейчас пробую какую нить другую схему сделать. Может быть даже через SIP попробывать.

Вы думаете, что здесь на форуме мы в курсе всей схемы вашей связи??
Вы хоть опишите подробно, какой абонент звонит на мобильный, какой стык с городской сетью (или оператором сотовой связи).
Вы не слышите реч. сообщение, поскольку оно выдается внутриполосно (In-band) без установления соедининея (без состояния Connect). А далее все зависит от сети: выдается ли Progress_Ind, проключается ли голосовой тракт (до Connect'а) и т.п.
Судя по всему, Вы хотите построить систему связи, в которой используется конвертация сигнализации (Н.323- ISDN и т.п.), а в этом случае будет множество нюансов!!! И вовсе неочевидно, что ipLDK обязана уметь "выгребать" все проблемы, которые наворочены в сети, т.е. в вашей системе связи в целом!!
А чтобы попытаться найти причину проблем - нужно трассировки снять. А без них - бесполезное занятие.

С SIP'ом будет еще сложнее...

2. Звонок lg->(h.323)->cisco->(TDM)->nortel ? Если да - попробуйте на потсовом пире цыски сказать вот это:
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8

если не поможет - в глобальном режиме voice call send-alert
апосля курите доки про PI
3. Сниффы фстудию. Как выполнен стык лыжа-цыска ? (NET/PSTN) Что с лицензиями ? Как настроен трансфер на лыже ?

PS на кошке глобально voice rtp send-recv скажите заодно

Схему я в первом посте описал. ipldk 60 - h323 - nortel Meridian (gatekeeper) - h323 - cisco 2911 - e1 - nortel Meridian 11
К городу подключены по потоку через основной Меридиан (gatekeeper).

Просто рядом стоит другая железка, подключенная так же по h323 к меридиану гейткиперу и сообщение о недоступности абонента выдается нормально. Значит дело точно в лыже. Трассировку сниму чуть позже, сейчас пробую немного другую схему, в которой хочу исключить h323 транзит. Насколько я понимаю, все косяки именно из за него.

Арсен, чтобы быть на 100% уверенным, что это лыжа - проверьте пожалуйста сниффером, что кошка до коннекта в сторону лыжы в rtp шлет голосовое сообщение.
По поводу трансфера с лыжи в h.323 - имейте в виду, что полноценный h450-based трансфер работать не будет. Только тромбон, по 2 канала на форворженный звонок. Это особенность реализации трансфера на лыже.

эээ, вы так и не посмотрели мое сообще о схеме сети. Циска никаким боком не участвует в городском соединении там схема pldk 60 - h323 - nortel Meridian (gatekeeper) - Е1 - город. Сниффер выложу чуть позже, я сейчас схемку разобрал.

из Вашей схемы никак не следует, что выход в город у лыжи идет через меридиан, к слову.
Тогда смотрите настройки меридиана по h.323 - стеку. Желательно остаться на старом варианте - fast+tunn
Снимайте снифф, чтобы было видно, что меридиан до коннекта шлет сообщение.

1) Знаете, разговоры о том, что здесь работает, а там не работает, значит LG виновата - это как-то, пардон, примитивно.. У Вас система построена на оборудовании разных производителей. Почему Вы думаете, что это все будет работать без нюансов??? Были бы две LDK - проблемы бы не было.
Использование стандартных протоколов ни о чем не говорит. Производитеь может понимать эти стандарты по-своему. И здесь ошибки в Циски и в Меридиане встречаются ничуть не реже, чем в LG.
Но, кстати, LG куда быстрее, чем более знаменитые бренды, вносит исправления (иногда и такие, которые вовсе не обязана делать, а только из-за того, что например, Нортел (Меридиан) не желает ничего у себя исправлять).
2) Станции LG не поддерживают QSIG, соотвествующий рекомендациям ECMA, а использует свой протокол. Поэтому не стоит рассчитывать на применение QSIG/H.450 между LDK и Meridian (или Cisco).

Согласен. Нужно трассировку смотреть.
Сообщение шлет оператор сотовой связи, а Меридиан должен переслать Progress-индикатор в (Alerting или в Call Proceeding или просто в отдельном сообщении Progress) и обеспечить прозрачную передачу голосового сигнала (проключить канал). Т.е. Меридиан должен начать передачу RTP до Connect'а.

Да просто забавно, что из 5 тем, что я тут создавал 3 решились с помощью "тестовых неофициальных прошивочек"))) Даже не знаю, хорошо это или плохо. С одной стороны много косяков, когда думаешь, что это твои кривые руки, а в итоге то получается, что просто нужная соответствующая прошика. С другой стороны корейцы дествительно очень быстро их клепают)))

Вот еще давно назрел вопрос - можно ли в Лыже как то ограничить то количество кодеков, что он посылает при вызове? Или только задать дефолтовый, который будет идти в списке первым, и все?

зачем?

зачем - это долго объяснять. В кратце - на меридиане то же есть проблемка с ограничением кодеков, и выбирается не всегда то, что нужно (разные направления, разные каналы, разные кодеки). Поэтому думаю как бы зарезать выбор. На IPECS, к примеру, можно сделать, что бы он только один кодек использовал. Интересует, есть ли возможность сделать такое в ipldk... но что то предвижу, что нельзя?

а засунуть лыжу в отдельный регион и задать например внутрирегональный и межрегиональный кодек строго g711alaw нельзя ?