Дуже дякую, Артем! Ще таке питання: а щось (переваги) кардинально поміняється з SIP-адресацією та/або резольвінгом, якщо замість виключно VoIP-викликів передбачатимуться і аудіовідео-виклики? Типу, відеотелефонія та відеоконференцзв"язок (як "точка-точка", так і "многоточка"). Ну і може хто знає - як там зараз справи з реалізацією протоколу H.460.18/.19 (це якраз для забезпечення firewall/NAT traversal)? Реально його вендори (Tandberg, Polycom, Huawei etc) підтримують? Бо заявляють, що ага. Але як воно насправді? 16 травня 2008 р. 22:13 Artem Naluzhnyy написав:

On 5/16/08, Oleh Hrynchuk wrote:

...

Конкретно, як зараз задовольняються (вирішуються) вимоги, пов"язані з проблемами стиковки enterprise-клієнтської LAN та операторської IP/MPLS-мережі: 1) Всякі там питання NAT/Firewall Traversal 2) Стиковка/узгодження Enterprise QoS з QoS policy операторської мережі (тут, пам"ятаю, був чудовий документ від Cisco, з рекомендацією по маркуванню трафіку для переходу в MPLS-мережу оператора, але я його загубив :-( ) 3) SIP-адресація та резольвінг

???

Самий простий приклад:

1. Сервіс-провайдер має 2 клієнти - ентерпрайзи А та Б. 2. Ініціюється VoIP-дзвінок з LAN одного ентерпрайза в LAN другого ентерпрайза (типа директор одного ентерпрайзу захотів подзвонити та поспілкуватися з директором іншого). 3. SIP- та DNS-сервери належать і знаходяться на площадці сервіс-провайдера. 4. Кожен з ентерпрайзів А та Б має в себе NAT та Firewall.

То як для реалізації цього дзвінка оператор вирішує питання 1)-2)-3) ? Як це зараз правильно робиться?

Для NAT/Firewall bypass краще за все використовувати рішення з RTP proxy-сервером на стороні оператора.

Найбільш зручний для споживача варіант адресації - використання E.164. SIP Request-URI буде виглядати якось так: sip:380123456789@sip.operator.com

Переваги: * споживач звик до числових телефонних номерів * споживач може використовувати для дзвінків звичайний телефонний апарат, що під'єднаний до SIP-адаптера * споживач зможе отримувати вхідні дзвінки з PSTN на свій VoIP телефон * для маршрутизації таких дзвінків DNS взагалі не потрібен (окрім резолвінгу імені sip.operator.com, в принципі і його можна уникнути)

-- Artem Naluzhnyy

-- Regards, /oleh

16 травня 2008 р. 23:37 Artem Naluzhnyy написав:

On 5/16/08, Oleh Hrynchuk wrote:

...

Ще таке питання: а щось (переваги) кардинально поміняється з SIP-адресацією та/або резольвінгом, якщо замість виключно VoIP-викликів передбачатимуться і аудіовідео-виклики? Типу, відеотелефонія та відеоконференцзв"язок (як "точка-точка", так і "многоточка").

Ні. Адресація абонентів характерна для сигналізації, якій байдуже кількість та характеристики медіа-потоків.

Ага... ну ясно, дякую.

...

Ну і може хто знає - як там зараз справи з реалізацією протоколу H.460.18/.19 (це якраз для забезпечення firewall/NAT traversal)? Реально його вендори (Tandberg, Polycom, Huawei etc) підтримують? Бо заявляють, що ага. Але як воно насправді?

Хіба H.460.17-.19 не для стеку H.323? В мережі будуть співіснувати SIP та H.323?

Для стеку. Принаймі ось чувак один каже *"The ITU (International Telecommunications Union – a United Nations Agency) has ratified a new set of recommendations (standards to most people) that promises to make NAT-firewall traversal between vendors' videoconferencing equipment and different end user organizations much easier in the future. The new recommendations are H.460.18 (edited by TANDBERG) that enables H.323 video endpoints to exchange signaling information, and H.460.19 (edited by RADVISION) that defines the NAT-firewall mechanism for media. The two standards obviously work together closely, but by keeping them separate, the architecture will enable cleaner upgrades and enhancements in the future, perhaps similar to the ISO 7-layer stack model for network protocols. (Don't ask us whatever happened to H.460.1 through H.460.17, which like MPEG 3, 5, and 6 shall forever remain a mystery.) H.460 takes NAT-firewall traversal into the area of the service provider or network cloud as well as the enterprise. Until now, any organization could implement its own method or solution for NAT-firewall traversal, but when it came time for inter-enterprise H.323-based voice/video communications, there was no standard to handle the situation. Now, this barrier disappears, providing a MAJOR capability for IP communications between organizations. Yes, things are getting better. Easier that is, when people understand how to register to session border controllers, and when session border controllers know how to neighbor. Where the rubber meets the road, in terms of actual deployment, H.460 will require two things. The first is client software running behind the firewall - typically inside the videoconferencing endpoints themselves, or a gatekeeper substitute for non-compliant endpoints (see below). The second implementation element is a device (session border controller) in the network cloud, typically provided by the network service provider. If this sounds familiar to you, it may be because you remember TANDBERG's announcement of its Expressway product line (WRB Vol 6 #05, Feb 7), a product based on technology the company acquired with its Ridgeway acquisition. In fact, H.460 is based on Expressway, but has some minor modifications in the registration packet handling protocol (not minor if you are a registration packet protocol software engineer perhaps)."* Поки-що не знаю чи буде разом з SIP співіснувати і Н.323. А SIP-based інфраструктура як вирішує питання з Firewall Traversal? Через proxy, чи якось іншим чином? -- Regards, /oleh

Щиро вдячний, Артеме, за консультацію! Більш не буду "доставати", бо твоєї консультації повністю вистачило, щоби знайти всі потрібні доки :))). Наприклад ось: http://www.sipcenter.com/sip.nsf/html/SIP%20Firewall%20and%20NAT%20Traversal 17 травня 2008 р. 00:50 Artem Naluzhnyy написав:

On 5/17/08, Oleh Hrynchuk wrote:

...

16 травня 2008 р. 23:37 Artem Naluzhnyy написав:

...

On 5/16/08, Oleh Hrynchuk wrote:

...

Ну і може хто знає - як там зараз справи з реалізацією протоколу H.460.18/.19 (це якраз для забезпечення firewall/NAT traversal)? Реально його вендори (Tandberg, Polycom, Huawei etc) підтримують? Бо заявляють, що ага. Але як воно насправді?

Хіба H.460.17-.19 не для стеку H.323? В мережі будуть співіснувати SIP

та H.323?

...

[skip] Поки-що не знаю чи буде разом з SIP співіснувати і Н.323.

Може краще дати Н.323 спокійно померти? ;) Ну, може ще деякий час використовувати SIP-H.323 конвертори для спілкування зі "старими" операторами, що вже вклалися в H.323 мережі.

...

А SIP-based інфраструктура як вирішує питання з Firewall Traversal? Через proxy, чи якось іншим чином?

Комбінацією COMEDIA, STUN та RTP-proxy. В принципі можна спробувати обійтися чимось одним. За технічними подробицями можеш стукати в IM/email.

-- Artem Naluzhnyy

-- Regards, /oleh