Здравствуйте! Проблема в следующем:
Есть главный офис, стоит MFIM600, IP и DECT аппараты.
Есть удаленный офис, который соединен с главным по site-to-site VPN, т.е. трафик между сетями маршрутизируется, NAT'а нет.
Происходит следующая ситуация:
В главном офисе все ip-телефоны (LIP-8002e) работают без проблем. Привезли такие же аппараты в удаленный офис, подключили, регистрация прошла, номер получили.
Звонок на них проходит, но звук идет только в одну сторону (из удаленного в главный, обратно тишина).
Самое интересное, что между собой у них все нормально и если звонить из удаленного офиса на городские и мобильные номера, тоже все нормально.
Проблема возникает только при звонке с внутреннего главного на внутренний удаленный или в обратном направлении.

Прошивка телефонов: GS99P-10Cf, Bootrom Ver: 1.1.4
Прошивка MFIM:
MFIM/GS97M-5.5Gt MAY/12
Boot Version-1.0Bf MAY/10
Kernel Version-5.5Dd
H/W issue-3

Потом в целях эксперимента подключил старую iPECS MG и попробовал зарегистрировать на ней по одному телефону в главном и удаленном офисах и чудо свершилось голос пошел в обе стороны (Через тот же VPN-канал).

А как прописались аппараты в удаленном офисе? Local или Remote?

Пробовал и Local и Remote - ничего не меняется, параметр Same LAN with MFIM стоит YES

Для режима Remote опция Same LAN with MFIM не имеет значения.
Для режима Local:
Same LAN with MFIM = On - устройство физически в одной сетке с MFIM
Same LAN with MFIM = Off - устройство в другой сетке, которая прозрачно маршрутизируется с сеткой MFIM (Non-NAT роутер). Вот это и есть режим, называемый Local-Remote, он отображается в ПГМ102-103 как LO (вместо L).
И судя по всему, у Вас как раз этот случай. И в телефоне нужно указать Local=Yes, Same LAN= No.

Я где то в руководстве видел Local=Yes, Same LAN= Yes если в одном свитче абонент и MFIM, а за свитчем: Local=Yes, Same LAN= No, я так и делаю у себя..
Работают из за свитча и Local=Yes, Same LAN= Yes, но неустойчиво, периодически отваливаются.. у нас последовательно шесть (и более) свитчей при гигабитных магистралях - не очень хорошо..

По умолчанию PtP трафик идет Local-Local или Remote-Remote, во всех остальных случаях тебуются каналы для RTP Relay.

Удаленные надо Local / Same Lan ... - NO

или если не поможет то возможно так же все девайсы перевести в Remote.

Если и так голос не пойдет то проверяйте туннель.

Прошу прощения, посмотрел не в тот профиль. Актуальные настройки удаленных аппаратов на данный момент:
LOCAL и LAN with MFIM стоит NO


Удаленные аппараты отображаются так:
LIP-8002E 207 b40edcb8e06e 192.168.XXX.XXX LO ON Unicast 1.0Cf SC14452

Ок. Найди это место в руководстве. Где ты это видел по поводу одного свитча??

А что может быть с туннелем, если

?
Т.е. те же аппараты зарегистрированы через тот же VPN туннель на старую станцию и все работает...

Удал. аб. - > лок. аб. - голос есть
удал. аб. <- лок. аб. - тишина
Так??

В этом случае можно снять снифер на стороне станции, и посмотреть на какой адрес лок. абонент отсылает RTP трафик.

Туннель там обычный IPSec с маршрутизацией между двумя подсетями без ограничений и NAT и соотв-но никакие порты не прокидывал.



Да, т.е. я в главном офисе их слышу, а они меня нет.

Но при этом если удаленный абонент звонит в город через "9", то у него все нормально. А в город они же должны через LIK выходить, правильно?

Сниффером попробую посмотреть.

А какой у Вас стык с городом??

SIP и E1

Да, трафик идет через станцию: от телефона на VOIP/VOIM (SIP) или на PRIM (E1)

Попробуете в ПГМ 132 на каждый Sequense number телефонов прописать Router Ip adress . Для локальных свой , для удаленных свой .

Для удаленных телефонов Same LAN with MFIM - NO и Local mode

Не поможет. Это поле в ПГМ132 только для слотов VOIM.

У него так и стоит. См. сообщение #7 в этой ветке.

При регистрации на iPECS модулей и оконечных устройств назначается номер шлюза, который отражает порядок регистрации. Кроме того, в зависимости от типа элемента системы (CO/IP шлюз, оконечное устройство, шлюз MISC/VSF/WTIM), система назначает номер логической последовательности. Таким образом, последовательные номера для модулей шлюзов CO/VOIM, оконечных устройств и шлюзов MISC/VSF назначаются взаимонезависимо по типу шлюза. Эти последовательные номера используются для обеспечения взаимодействий между физическим MAC адресом и логическим номером порта элемента системы.

Для RSGM, порту СО-линии назначается последовательный номер CO/IP-шлюза, а iPECS фону и порту аналогового телефона - назначается номер последовательности оконечных устройств.

Система может назначить по умолчанию персональный IP адрес каждому последовательному номеру. Если есть необходимость, эта программа может быть использована для преобразования назначенного IP адреса каждому модулю шлюза и iPECS фону.

Каждый локальный модуль шлюза и оконечное устройство могут быть назначены для прямой посылки. При активации прямой посылки система будет использовать МАС адрес Ethernet, свитч 2-го уровня при необходимости устранения потерь IP-трафика уменьшением общего трафика LAN.

Система обычно использует протокол множественной IP посылки для ответа на запрос регистрации от модулей шлюза или оконечных устройств. При нахождении элемента системы за маршрутизатором, система может использовать протокол монопосылки IP. Это устанавливается назначением «локального девайса». При деактивации (Off), система будет посылать монопосылку IP сообщения девайсу в ответ на запрос регистрации.

Включены последовательно несколько свитчей, которые запоминают маршрут, но только до выключения.. После обесточивания (что у нас нередко) память свитчей сбрасывается (тех моделей, что у нас стоят). Без пинка мульти посылку они не посылают для поиска, поэтому для принудительной мультипосылки надо включать REMOTE на оконечных устройствах..

Официальный перевод:
Для ответа на регистрационный запрос от локального модуля или терминала система обычно использует IP-протокол многоадресной (групповой) передачи (Multi-cast). Однако, если регистрируемое устройство отделено от системы маршрутизатором, и, следовательно, находится в другой локальной сети, система должна использовать IP-протокол одноадресной передачи (Uni-cast), что достигается установкой режима локального устройства (ПК 1–4, см. таблицу ниже). Когда режим установлен в состояние OFF, в ответ на регистрационный запрос от устройства система отошлет ему IP-сообщение одноадресной передачи.
И что??
1) Это проблема твоей локал. сети! Это частный случай, ИМХО, который не имеет отношения к общему случаю. Сетки разделяются маршрутизатором, а не коммутатором.
2) Упомянутая опция {Режим локального устройства/Local Device} в настоящее время ликвидирована (начиная с ver. 5.0) На ее месте сейчас есть только Индикатор режима устройства (L/LO/R/RNAT/RNAPT), без возможности устанавливать режим вручную. Это все делает станция автоматически. Значение имеет только только исходная настройка устройства и ее местоположение в сети (за роутером или в одной сети).

Стас! При установке режима Remote на устройстве никакой речи о "мультипосылки" вообще не может быть, тем более о "принудительной" (как собственно точно также и при установке режима Local=Yes & Same LAN=No).

Я уже заметил это в твоей предыдущей цитате.. ремот устанавливал на версии 5.5 Gt - в Local IP телефоны отваливались, про маршрутизаторы сегодня уточнил еще раз у админов - только свитчи.. то было мое предположение.. теперь не знаю - почему в моей сети без Remote корректно не работает.. другая подсеть за маршрутизатором голос пропускала только после программирования зон принудительного RTP Relay..

В сети главного офиса (где стоит MFIM) трафик от аппарата идет только на адрес MFIM если звонить на стационарный аппарат.
Если звонить на трубку DECT, то обмен идет с MFIM и WTIM8.

Видимо если аппараты стоят в режиме Local, то работают через MFIM, если в режиме Remote, то напрямую. Так получается?

Нет. Станция автоматически применяет след. правила для маршрутизации RTP трафика:
Local <-> Local - напрямую
Remote <-> Remote - напрямую
Local <-> Remote - через RTP Relay (каналы VOIP на VOIM или на MFIM).

В вашем случае телефоны регистрируются как LO (разные подсетки, но в одной коммутируемой сети, т.е. соединенные Non-NAT роутером). Устройства LO (режим local-remote) с точки зрения трафика RTP обслуживаются точно также, как и устройства в режиме L (local), только через шлюз.
Непонятно, почему с лок. телефонов RTP идет на MFIM, тем более что у вас MFIM600, на нем нет встроенных каналов VOIP.

А адрес шлюза не забыли прописать для MFIM в ПГМ102 ??

Практически Local <-> Remote и Same LAN удобно использовать в случае с двумя подсетями.. если подсетей больше: то групп больше.. и уже понадобится функция с зонами..436-441

< Local Mode Device >

* Location
- On the same local network with MFIM (in other words, under the same L3 router).

* IP Address
- Use of private IP address is possible.

* Multicast
- Multicast signaling (for auto-configuration) and multicast RTP (for Paging, MOH) are used.

* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed only for the calls with Remote devices.

* Configuration
- Auto-configuration & registration (Plug-and-Play).


< Remote Mode Device >

* Location
- Any place routable to MFIM (e.g. inside/outside of local router, over the Internet).
- Can be placed behind NAPT router.

* IP Address
- Basically, public IP address is assumed.
- But, if installed behind NAPT router, private IP address can be used (because it will be anyway translated into public IP address).

* Multicast
- Multicast is not used for both signaling and RTP.

* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed for the calls with Local device, Local-Remote device, and Remote device that is installed behind NAPT router.
- But, not needed for the calls established between two Remote devices installed behind non-NAPT routers.

* Configuration
- Manual configuration of IP address, subnet mask, etc.


< Local-Remote Mode Device>

* Location
- Within the same administrative zone with MFIM (e.g. Corporate Intranet).
- Cannot be placed behind NAPT router.
- In other words, may be installed beyond the local router within the administrative zone, but should be routable without address translation (e.g. NAT, NAPT, etc.).

* IP Address
- The IP address (private or public) should be routable at least within the administrative zone (e.g. Corporate Intranet).
- Once Local-Remote devices are introduced, all the IP addresses assigned to both Local and Local-Remote devices should be routable at least within the administrative zone.
- And also, router (gateway) address should be configured for all the Local and Local-Remote devices.

* Multicast
- Only multicast RTP (for Paging, MOH) is assumed and used.
- Multicast signaling may also be used, but is not required.
- Local routers should support IGMP protocol in order for the multicast packets to be properly routed within the administrative zone.

* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed only for the calls with Remote devices.

* Configuration
- Manual configuration of IP address, subnet mask, etc.

????
В данном случае под Local <-> Remote подразумевалось связь между локальными и удаленными устройствами iPECS, а вовсе не режим устройства, названный корейцами "Local-Remote" (LO).
Что именно ты хотел сказать???
Причем здесь Same LAN ?? Same LAN влияет только на ARP и на регистрацию Unicast/Multicast.
В чем проблема-то?? Хоть все устройства могут быть в одной группе, если сетка прозрачная.

Значит:
или: прозрачная она только по словам администраторов..если при установке Local рано или поздно ip фон отваливается.. Только что звонил админу - он подтвердил прозрачность..
или:
В англ. тексте указано: "under the same L3 router"..что между ip фоном и MFIM нет роутера L3 - значит Local нельзя и в прозрачной сети..

1) Стас! Честно говоря, мне уже надоело писать про одно и то же.
Понимай сам, как знаешь.
2) Ты же вывалил комментарий (на англ.)?? Вот и изучай!! Кстати, зачем нужно было этот комментарий вываливать??

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

Ты своей варкой в собственном соку всех остальных уже почти довел до кипения...

Никто не дискутирует..на этом форуме только вы с Андреем и можете подискутировать..
В пятницу с Иваном созванивался.. Он сказал, что на Циско более оживленное комьюнити..на пару порядков увлеченных людей больше.. Это к слову..
У нас тут тоже все об автомабилях и рыбалке..работой не интересуются..футбол и женщины еще..в других специальностях..чем мы от такжиков отличаемся?

- Ты, видимо, забыл, в какой стране мы живем?? У нас тут форум - не место для дискуссий !!
- Тебе не кажется, что оживленное коммьюнити, видимо, напрямую связано с более широкой распространенностью Cisco?? Вот когда iPECS будет столь же популярен, как Киска, тогда, может быть, и будет оживление... Тогда и будем дискутировать "глубоко" (если не утоним)...
- Что касается тем для оффтопика, то, ИМХО, ты сам и являешь самым злостным зачинчиком словоблудия, уводящего в сторону от основной темы. Сусанин ты, короче.. И данная ветка не исключение.

Хотелось бы отметить..
Из слов Ивана я понял, что само оборудование Циско по функционалу и по удобству не впереди LIK, и что дело как раз в его распространенности.. Искренне жалко E-LG по поводу такой недооценки ее.. Бренду нужно имя, а имя ему делают поп хиты среди шумных гаджетов (побоюсь этого слова - (шепотом) смартфоны)..

Стас! Скажу прямо: твоё нытьё по поводу сматрфонов уже достало!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
А что, Cisco еще не выпускает смартфоны?? Так давай поднимай эту тему на форуме Cisco!!
Опять увел ветку далеко в сторону. Стас! Почаще читай свою подпись под сообщениями

Сейчас смотрю трафик на свиче в удаленном офисе. Ситуация следующая:
При звонке с удаленного аппарата на удаленный весь трафик идет между телефонами.
При звонке с удаленного аппарата на телефон центрального офиса трафик тоже идет напрямую в телефон.
А по идее удаленный телефон должен звонить на станцию, правильно?

В ПГМ 102 адрес прописан.

ip фоны Remote с ip фонами Local напрямую?

< Local Mode Device >
* Location
- On the same local network with MFIM (in other words, under the same L3 router).
* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed only for the calls with Remote devices.


< Remote Mode Device >
* Location
- Any place routable to MFIM (e.g. inside/outside of local router, over the Internet).
- Can be placed behind NAPT router.
* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed for the calls with Local device, Local-Remote device, and Remote device that is installed behind NAPT router.
- But, not needed for the calls established between two Remote devices installed behind non-NAPT routers.


< Local-Remote Mode Device>
* Location
- Within the same administrative zone with MFIM (e.g. Corporate Intranet).
- Cannot be placed behind NAPT router.
- In other words, may be installed beyond the local router within the administrative zone, but should be routable without address translation (e.g. NAT, NAPT, etc.).
* Packet Relay (by VOIM or VoIP channels in MFIM)
- Needed only for the calls with Remote devices.

Да


Я правильно понимаю, что если у меня между центральным офисом и филиалом прозрачный туннель, то для удаленных аппаратов должен стоять режим Local-Remote (т.е. Same LAN - NO и Remote), а для локальных - режим Local (Same LAN - YES и Local)??

НЕТ!
Для VPN туннеля SAME LAN=NO, и режим LOCAL.

Прошу прощения, ошибся. У меня так и установлено на удаленных абонентах.
И при таких настройках удаленный аппарат отправляет голос напрямую аппарату в центральном офисе.
А аппарат в центральном офисе в ответ отправляет голос через MFIM, который в конечном итоге не доходит до удаленного аппарата.

Как проверить, работает ли RTP Relay на MFIM?

Забейте VOIB линии на системнике все - и увидите занятие их на системнике..

На MFIM адрес шлюза забит?

Да

1) Пардон, а о каком "RTP Relay на MFIM" может вообще идти речь, если у вас MFIM600, на котором в принципе НЕТ встроенных VOIP каналов. В случае LIK600 для использования RTP Relay в станции должен быть еще модуль VOIM (VOIM8 или VOIM24).
2) Но так как у вас "прозрачная сетка", то должно все работать напрямую, без RTP Relay. Т.е. RTP-трафик должен идти непосредственно между абонентами.
Исходя из п.п. 1 и 2 никакого RTP-трафика между телефонами и MFIM не может быть в принципе.
3) Покажите трассировку пакетов (снифер), где вы обнаружили, что локал. телефон отправляет голос (RTP трафик ) на MFIM.
4) Покажите файл конфига.
5) Все "удаленные" телефоны отображаются в ПГМ102-103 как LO ??
6) У вас только один удаленный офис или несколько? Т.е. через VPN связаны только 2 сетки или несколько??

1. VOIM24 установлена
3,4 Ок, сделаю
5. Да, и все шлют трафик напрямую в локальный аппарат
6. Пока удаленный офис один. Но планируем расширяться.

На VOIM адрес шлюза назначен?

В целом тут разбираться нужно не с VOIM (не c RTP Relay), а с тем почему не идет RTP напрямую от локальных устройств в VPN. В данной схеме сети не требуется Relay.

Проблема частично решена.
Аппараты получали IP по DHCP, вместе с IP назначался шлюз, не знающий маршрута в удаленную подсеть.
Прописал на этом шлюзе статический маршрут и все пошло. Точнее с локальных LIP-8002 трафик пошел напрямую удаленному абоненту и соответственно голос теперь идет в обе стороны.

Осталась проблема с DECTами: на WTIM8 IP назначен статически, шлюз установлен 0.0.0.0
Меняю на нужный, применяю, ребутаю WTIM - шлюз опять 0.0.0.0
Соответственно с DECT-аппаратов голос к удаленному аппарату опять не проходит.