locked
OCS External Voice RRS feed

  • Вопрос

  •  

    Добрый день!

     

    Запускаем OCS и столкнулись с такой проблемой: невозможно установить голосовой звонок с клиентом, находящимся за пределами корпоративной сети, подключенным к интернет. В качестве клиентов везде используется Communicator, Enterprise voice не включен. В дмз развернут a/v edge, на внешнем фаерволе есть все необходимые правила для работы OCS (разрешен HTTPS, STUN, SIP/MTLS, RTP/UDP, RTP/TCP). При этом выглядит это все довольно любопытным образом. Я, подключившись к интернету, звоню коллеге, находящемуся внутри сети. Сигнализация о звонке проходит нормально, коллега поднимает трубку, в коммуникаторе появляется сообщение Connecting Call, в ходе которого статус коллеги меняется на Busy. Но мой статус не меняется, после чего следует отбой и коммуникатор сообщает, что не смог установить аудио канал (The call was disconnected because xxx stopped recieving audio). При этом коллега утверждает, что в ходе соединения он меня слышит нормально. Я его не слышу.

     

    Пытался анализировать ситуацию. Прежде всего попробовал клиента включить в ДМЗ. Звонок проходит нормально, аудио канал устанавливается, слышимость нормальная. Т.е. похоже, что проблема во внешнем фаерволе. В качестве внешнего фаервола используем железку от Allied Telesyn.

     

    Смотрю логгинг на нем, вижу нормальный ход установления звонка, т.е. клиент сначала устанавливает соединение с edge по HTTPS, потом 2 STUN и потом 2 RTP/UDP. Т.е. ничего нигде не блокируется явно. Но аудио канал от edge до клиента (т.е. до меня) не устанавливается....

     

    Единственное что думается - вот когда смотрел подключения от клиента, включенного в ДМЗ, он устанавливал 3 RTP/UDP соединения. А из интернета устанавливаются только 2... Может здесь собака порылась?

     

    Кто нибудь сталкивался с подобными проблемами или просто ковырялся глубоко в процессе установления голосового соединения - как он должен выглядеть нормально?

     

    27 мая 2008 г. 7:11

Все ответы

  • Маршрут по умолчанию на сервере на каком интерфейсе прописан?

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

    27 мая 2008 г. 9:40
  •  

    Блин, действительно ведь...

    Шлюз прописан на другом адаптере. Т.е не на том, который используется как адрес для подключения внешних клиентов. Как правильно сделать, подскажите пожалуйста?

    Еще вопрос: будет ли в данном случае иметь значение очередность сетевых адаптеров? Я имею в виду в Network Connections -> Advanced Settings можно установить приоритетность сетевых адаптеров, у меня сейчас интерфейс с адресом для подключения снаружи стоит на втором месте.

    27 мая 2008 г. 10:06
  • стал дальше разбираться. проанализировал траффик на edge сервере. весь диалог между клиентом и сервером происходит именно с адреса, к которому клиент коннектится. т.е. гипотеза о том, что проблема в настройке шлюза по умолчанию не работает (она кстати и на практике не работает - проверил).

     

    а вот что интересного нарыл. соединение устанавливается, вижу что клиент валит на сервер RTP траффик ( что объясняет, что коллега меня слышит), а вот сервер пытается достучаться до клиента по протоколу ICMP и эта попытка не проходит - ее бодро рубит мой внешний брэндмауэр - и после этого соединение отваливается. неужели проблема в этом?

    27 мая 2008 г. 11:13
  • Скажите, а требование к тому, что на внешнем сетевом интерфейсе A/V Edge должен использоваться публичный IP адрес и не должен использоваться NAT у Вас выполняется?

     

    "The external IP address of the A/V Edge Server must be a external IP address that is directly contactable by external parties.


    To conform to the requirement of a publicly routable IP address of the A/V Edge Server, the external firewall of the perimeter network must not act as a NAT (Network Address Translator) for this IP address.
    Additionally, the internal firewall must not act as a NAT for the internal IP address of the A/V Edge Server. The internal IP address of the A/V Edge Server must be fully routable from the internal network to the internal IP address of the A/V Edge Server. "

     

    6 июня 2008 г. 13:06
  • На обоих интерфейсах A\V edge стоят реальные интернетовские IP адреса из одной IP подсети. топология DMZ - back-to-back, траффик между внутренней сетью и DMZ и между DMZ и интернетом именно маршрутизируется.

    30 июня 2008 г. 7:07
  • Буквально в пятницу вышел новый официальный документ:

     

    "Designing Your Perimeter Network for Office Communications Server 2007 White Paper"
    http://www.microsoft.com/downloads/details.aspx?FamilyID=e4a8d703-e41a-47d9-b9dd-2799f894af92&DisplayLang=en

     

    Проверьте, соответствуют ли содержащиеся в нем рекомендации и требования тому, что реализовано у Вас?

    30 июня 2008 г. 8:34
  • с документом ознакомился. если честно, особо много нового не вынес, тем не менее дока полезная, однозначно. по результатам ознакомления не нашел чего бы поменять в моей инфраструктуре... по прежнему - буду благодарен за идеи по поводу решения моей проблемы.

    30 июня 2008 г. 10:16
  • Продолжаю сражаться с проблемой невозможности позвонить с клиента, подключенного к интернет и цепляющегося к OCS через A/V Edge.

     

    Дошел до того, что попробовал заменить свой внешний маршрутизатор/брэндмауэр на бокс с Windows Server 2003, на котором поднял RRAS и настроил маршрутизацию (никакого НАТа, никакой пакетной фильтрации). Не работает - с теми же симптомами.

     

    Самое интересное состоит в том, что если на раутере поднять еще одну подсеть - тоже ДМЗ, просто другая подсетка IPшная - и выставить клиента в нее, то звонок прекрасно проходит! Т.е. с точки зрения маршрутизации трафика все настроено правильно и работает. Вот только из интернет не позвонить...

     

    У меня идей не много: 1. какой то косяк у провайдера с настройками. 2. недостатчно полосы пропускания у клиентского подключения. Сеть подключена на 100Мбит к интернет, пробовал клиентские подключения с АДСЛ и с CDMA модема. Маловероятно, конечно, но вдруг коммуникатор имеет какой то встроенный механизм оценки полосы пропускания и не работает если она ниже какого то значения. Тогда хотелось бы знать это значение.

     

    Может быть у вас будут какие то еще идеи, буду благодарен.

    8 июля 2008 г. 14:20
  •  

    1. насколько честный был эксперимент? Отключали маршрутизацию между второй дмз и внутренней подсетью

     

    2. SIP запрос на видеосоединение идет по маршруту "внутренний клиент"->"pool"->"Access Edge"->"внешний клиент", Само соединение - "внутренний клиент"->"AV Edge"->"внешний клиент". Чтоб выяснить причину отказа, нужно просмотреть журналы Sip с внутреннего и внешнего клиента и с пула. Сделать это можно встроенными средствами, а просмотреть удобно встроеенной же утилитой snooper.exe. На Edge создать журнал sip трафика, на сколько я знаю, нельзя.

    http://www.microsoft.com/downloads/details.aspx?FamilyID=407a3e40-350a-4e3d-b60e-c9505668b231&DisplayLang=en

    по ссылке на в главе 4 на странице 60 последовательность sip запросов, которая должна наблюдаться

      

    8 июля 2008 г. 19:51
  • 1. маршрутизацию между второй дмз и внутреней сетью не отключал. т.е. эксперимент не совсем честный действительно.

     

    2. с журналами буду разбираться. пока вот наблюдение - смотрю траффик на внутреннем фаерволе (ИСА) при попытке звонка - и вижу что внутренний клиент (на которого звонят) добится по RTP на внешнего клиента напрямую - и естественно получает отлуп. Т.е. помимо SSL и STUN никаких соединений с a/v edge-ем внутренний клиент и не пытается устанавливать...

     

    Вторая странность: сделал несколько попыток звонков - и увидел какие то странные номера портов, 20к, 30к, 60к... вроде бы RTP определен как 50000-59999, тогда что это за попытку установки соединений?

     

    ну и на последок - сообщение из application log с внешнего клиента о невозможности установления соединения:

     

    A SIP request made by Communicator failed in an unexpected manner (status code 0). More information is contained in the following technical data:

    RequestUri: sip:edge_dns_name:5061;transport=tls;lr;ms-route-sig=caDKEdvQsmT2cVhMfLrBLCr-HDbb0BZ7N_k9wMYAAA

    From: sip:external@domain.ru;tag=f972b85f53

    To: sip:internal@domain.ru;tag=9dc1471d98

    Call-ID: 0d37b1f070f24f7eaa143994976b4d08

    Content-type: application/sdp;call-type=audiovideo

    v=0

    o=- 0 0 IN IP4 external_ip

    s=session

    c=IN IP4 external_ip

    b=CT:95

    t=0 0

    m=audio 14464 RTP/AVP 114 111 112 115 116 4 8 0 97 101

    k=base64Stick out tonguedsUV+tJrG7LfIzgBFoyQMT3Enc9MtLI2PEzaz/9lz17SAK8sKnZeARa8F2u

    a=candidate:YD33qGOaBaZ5SEE8t1DsI56Xyb6mdaD1zwX8k2ZEHrc 1 3IlfGx3RsWAn2hg4E5C2gQ UDP 0.830 external_ip 14464

    a=candidate:YD33qGOaBaZ5SEE8t1DsI56Xyb6mdaD1zwX8k2ZEHrc 2 3IlfGx3RsWAn2hg4E5C2gQ UDP 0.830 external_ip 37760

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inlineBig SmileASjAK0JjgAf9/wl6KmjQ8X2BsF+diQH3Z0/rbBc|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:gfrosd7N1y73AzV+MjZHtYwb0ZV3h2i5aMic2EXC|2^31|1:1

    a=maxptime:200

    a=rtcp:37760

    a=rtpmap:114 x-msrta/16000

    a=fmtp:114 bitrate=29000

    a=rtpmap:111 SIREN/16000

    a=fmtp:111 bitrate=16000

    a=rtpmap:112 G7221/16000

    a=fmtp:112 bitrate=24000

    a=rtpmap:115 x-msrta/8000

    a=fmtp:115 bitrate=11800

    a=rtpmap:116 AAL2-G726-32/8000

    a=rtpmap:4 G723/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:0 PCMU/8000

    a=rtpmap:97 RED/8000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=encryptionSurpriseptional

     

    Response Data:

    180 Ringing

     

    0 (null)

    Ms-client-diagnostics: 52031; reason="Call terminated on media connectivity failure"

    Resolution:

    If this error continues to occur, please contact your network administrator. The network administrator can use a tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit in order to interpret any error codes listed above.

    Дополнительные сведения можно найти в центре справки и

    9 июля 2008 г. 6:49
  • пока будите разбираться - проверьте правильность указания сервера и порта (по умолчанию 5062) поля а/v edge servers в глобальных настройках (должен быть внутренний интерфейс сервера)

    + неплохо бы проверить, куда ещё пытается послать запросы внутренний клиент.

    9 июля 2008 г. 12:45
  • Аналогичная ситуация, и аналогичная конфигурация сети - белые ip адреса, dmz..

    Свежие идеи появились?

    У себя проверил - edge и internal связаны по internal fqdn и порту 5062 в настройке леса (на что рекомендовал обратить внимание один из участников), в противном случае возникает сообщение у клиента external calls limited.

    16 июля 2008 г. 8:59
  • Проверьте с помошью logging tool на пуле как проходит SIP сессия (sip stack). Если есть возможность выложить файл с с логом - лучиший вариант.

    Поставьте анализатор пакетов на внутреннего клиента и посмотрите если ли безуспешные попытки установить TCP сессию. Если есть - то с кем?  

    16 июля 2008 г. 10:35
  • Вопрос решен. Полезная ссылка которая мне помогла:

    http://blogs.technet.com/chlacy/archive/2007/11/26/a-v-does-not-work-externally.aspx
    16 июля 2008 г. 12:45
  • Господа, имею те же грабли. Все началось примерно 8-9 июля. Внешние сотрудники внезапно потеряли возможность общаться голосом. Ковырял EDGE роль - ничего. Логирование на isa сервере тоже ничего аномального не показала. Но, вчера выявился интересный момент: настроил клиентскую машину на реальный IP нашего провайдера (дабы имитировать внешнее подключение к edge серверу) и, коммуникатор нормально цеплялся, звонил! Обрыва связи не происходило.

    Вообщем готов сотрудничать, ибо проблему необходимо устранять..

    P. S. Последняя ссылка не помогла, в этих настройках все ОК.
    18 июля 2008 г. 6:59
  • Продолжая свои изыскания, установил в сервер 3й сетевой адаптер, включил его во внутреннюю сеть и сконфигурировал как внутренний адаптер для Edge сервера.

    Попробовал звонить - не получилось.

    Следующий шаг - хочу попробовать разнести внешние адаптеры A/V и WebConf/Access по разным физическим адаптерам - встречал в сети упомниания о том, что A/V Edge в принципе не работает если делит внешний адаптер с другими сервисами.

    24 июля 2008 г. 11:06