Yehuda_Panzer

2Aleck_K : Спасибо за примеры. 2leveler : Киев, это видно из "подписи" софтсвича в трейсе. Еще раз повторю, что трейс снимался с телефона. который и является проблемой/темой данной темы. Вызов приходит именно на него : GXV3140, ip address : zzz.zzz.zzz.zzz:5060 Схема, приведенная ранее, сейчас уточняется : исходя из трейса, я не совсем уверен, что Softswitch и SBC (Session Border Controller) не надо бы поменять местами. Я этот момент сейчас уточняю. Видео, в данном случае - не первоочередная задача. Каюсь, когда снимался дамп - камера была отключена (есть отдельная кнопка). Включение камеры - не вносит изменений в поведение телефона. Естественно, в 200 Ок добавляется описание видео-сессии в SDP. Вопрос этого топика : почему телефон, на нормальную, с точки зрения протокола, сессию отвечает не 180 + звонок, а НЕ звенит и отвечает 183 (это не шлюз между сетями). Или я чего-то аномального не вижу в конфигурации, что лежит у меня перед носом.

Гм ... Как бы перепутал early media с другим механизмом. Пардон, бывает в конце трудного трудового будня. Ничто в цепочке не блокирует early media, конечно же. Однако, картину это не меняет. Не знаю, что дало уважаемому Aleck_K повод решить, что трейс был снят со стороны "некий видео-телефон", но я то знаю откуда я его снимал :))) Трейс был снят вмонтированным снифером телефона GXV3140 (№ 121). Скажите мне другое, коллеги. Я перерыл кучу информации и нигде не нашел иных примеров возникновения ответа 183, кроме как в примерах звонков VoIP ---> PSTN (к примеру RFC3666). Да в своей практике я только там и встречал этот ответ. Здесь же, по отношению к телефону GXV : -- сессия входящая -- телефон эту сессию никуда форвардить не настроен. Он должен просто ее терминировать. -- сессия VoIP-VoIP Буду благодарен, если поделитесь еще какими-нибудь примерами, когда этот ответ появляется.

Вы правы, ответ 183 - обычно это ответ на, к примеру, INVITE при включенном early media. Но при early media UAC-инициатор звонка шлет на UAS каждый набранный диджит в отдельном пакете INVITE. Если бы где то по цепочке эта опция и пропускалась бы, то на принимающей стороне в трейсе это было бы видно. Диалог, который я привел в первом посте - не усечен, он так и выглядит. Более того, SBC early media не пропускает - обычная практика превентивной защиты. Может ли на это влиять видео-поток ?

Early media - disabled на обоих энд-поинтах.

Доброго времени суток ! Борюсь с проблемой странного поведения видео-телефона Grandstream GXV3140 в публичной сети оператора IP-телефонии. Сессия SIP проходит (примерно) по следующей цепочке : [некий видео-телефон (5963050)] ----> [sBC (ip: xxx.xxx.xxx.xxx)] ----> [softSwitch : Cisco BTS10200 (ip: yyy.yyy.yyy.yyy)] -----> [Grandstream GXV3140 (121) (ip:zzz.zzz.zzz.zzz)] Звонок инициируется удаленным видео-телефоном, проходит по вышеуказанной цепочке и достигает видеотелефон Grandstream. Последний не звонит, но на его мониторе отображается информация о входящем звонке. Однако в трубке - тишина и видео-поток не поднимается. Если телефон Grandstream , без изменения конфигурации, переносится на лабораторный стенд, где нет SBC, а роль софтсвича играет Астериск - все работает как часы, включая видео. К сожалению тяжеловато получить трассировку на каждом участке перехода схемы, но под рукой есть трассер порта телефона GXV (у него свой собственный, вмонтированный, трассировщик). Из этого трасера видно следующее : 1. Верхний уровень (формат pcap) : 21 6.414179 yyy.yyy.yyy.yyy zzz.zzz.zzz.zzz SIP/SDP Request: INVITE sip:121@zzz.zzz.zzz.zzz;user=phone, with session description 22 6.452196 zzz.zzz.zzz.zzz yyy.yyy.yyy.yyy SIP Status: 100 Trying 26 7.234596 zzz.zzz.zzz.zzz yyy.yyy.yyy.yyy SIP/SDP Status: 183 Session Progress, with session description 27 7.235827 zzz.zzz.zzz.zzz yyy.yyy.yyy.yyy SIP/SDP Status: 183 Session Progress, with session description 32 7.492277 zzz.zzz.zzz.zzz yyy.yyy.yyy.yyy SIP/SDP Status: 200 OK, with session description (здесь входящий звонок увидели, а не услышали, и подняли трубку) 35 7.536628 yyy.yyy.yyy.yyy zzz.zzz.zzz.zzz SIP Request: ACK sip:121@zzz.zzz.zzz.zzz:5060;transport=udp Трассировка RTP показывает, что поток идет только в одну сторону : от телефона GXV к софтсвичу. Ответнов - не следует. 2. Уровень раскрытия SIP & SDP - шаги сессии, указанные в п.1, смотреть в приатаченном файле раскройку черепа сессии выложить здесь в читабельном виде не удалось, поэтому смотрите вордовский файл Из трассировки видно, что телефон вместо "традиционного" ответа 180 Ringing, отвечает : 183 Session Progress. При этом этого не происходит в лаборатории, там, как говорится. все согласно протокола. Это наталкивает меня на мысль, что причина такого поведения телефона кроется не в его настройках, а в "общении" с окружением. Может я слишком долго смотрю на этот трассер, но я не вижу практически ничего крамольного. На уровне UDP и IP - все Ок. Возможно кто-нибудь сталкивался с подобным демоном и победил его ? GXV3140_issue.doc