За повече от четири години посветени на всякакви бози с войпа мислех, че нищо ново не мога да видя... до преди да се появят БТК с техните ADSL-и. (кой беше казал "Shit happens all the time")
И така, казусът е следния: Micronet SP 5002 е вързан към някаква юникс базиран NAT. Майкронета си работи перфектно с нормален ЛАН, но когато се закачи към Ди Ес Ел-а БТК се получава нещо, като НАТ зад НАТ и резултатът е, че Майкронета праща заявки за регистрация, но не възприема потвърждението за регистрация. Знам, че ако го флашна със СИП фърмуер ще заспи, но не искам да си товаря сървърите с излишни транслации и транскодирания, при положение, че това е кол-шоп и се предполага, че ще работи с максимален капацитет.
Най-странното е, че точно преди седмица пуснахме друг кол-шоп с БТК ADSL и с рутерче D-LINK и пак има NAT зад NAT, само че всичко си работи и дори мога да позвънявам обратно на телефоните в кол-шопа.
Някой има ли идея къде би могла да е бозата?

Категоричността е признак за ограниченост!

Е чак пък с домашен АДСЛ да пускате кол шоп

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Страхотно! Искрено ти благодаря, че ми предлагаш да ми продадеш нещо... Оценявам това, че си светнат на тема SP5002... и с удоволствие бих откликнал на щедрото ти предложение, ако това бяха единствените клиенти... Знаеш ли, една от причините през последните няколко години да се влоши качеството на тези комуникации е, че не се търси решение на проблема, а решенията се взимат "през глава" - да тръгне някак си, пък после ще му мислим. Знаеш ли, например, че 0.08 секунди време за SQL оторизация, на отделен разговор вече е сериозен проблем? А знаеш ли, че MERA softswitch върху Петниум на 3.2 гигахерца, при 80 едновременни разговора с транскодинг започва да кляка(особено ако става дума за G.723) и да накъсва?
По този повод, моля те, запази си предложенията, ако нямаш конкретна идея на какво се дължи това, за което искам помощ.

Категоричността е признак за ограниченост!

Предположение: Ако не си - звънни на хелп деска на бТК да ти пренасочат всички портове DMZ - за да прескочиш ADSL рутерчето;

Тия Microshits не поддържат ли STUN? Понякога помага.

Нямаш ли дебъг на енд-пойнта да видиш каде точно се прецакват нещата - както си го написал, може да е от хиляди неща... Ако нямаш - тури един лаптоп със софт-пфоне и пусни дебъг оттам. Докат не разбереш каде е шита - няма с какво да се бориш.

Забравих да ти кажа: У нас съм с ADSL 5XX и съм с ATA102/SIP, която се свързва по SIP с офиса и никога не съм имал проблем. И портовете не са пренасочени... Оригинирам и получавам обаждания он дъ флай, дет се вика?! Нема СТЪН, нема нищо... Абе тва бТК верно си е ебеТаКа...

Съдържаниет е скрито
Влезте за да го видите

Проблемът е, че искам да си остане по H323... :-)
Освен това... този кол-шоп е чак на морето (не, че не ми се ходи до там, ама точно в момента ми е невъзможно да ида

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Еми хубаво де - звънни на зеления тел. на бТК и ги накарай да пренасочат всички портове... Става за 2 мин.

пусни си пълен порт форвард на адсл-а + статик ip
в микронета укажи в ipsharing статик ip-to и работиш
така ги пусках на пампоровец зимата така сега и по морето .
ама да ти кажа на някои места като албена и златните адсл-а издиша и от време на време не става за работа

успех

Проблема (според мен) е такъв. Вътре в H.323 ASN се напъхат source / destination / call signal адрес. Та, като получава RCF от отсреща, Микронета отваря ASN пакета и гледа вътре за съвпадение. Е, логично, че там вътре стои друг адрес (който отсрещния дивайз е видял - външния адрес от който ти е дошла заявката). Затова на Микронета трябва да му укажеш, че е зад НАТ и кой всъщност му се явява външен адрес, за да може правилно да декодва ASNа.

А това с Длинка е работело, щото много рутерчета имат protocol-aware NAT (включително и за H.323).

Като излиза RRQ от устройство зад НАТа (с адрес 192.168.10.10 примерно), то рутера пренаписва вътре ASN.1 пакета като замества source адреса 192.168.10.10) генериран от Микронета, с неговия си външния. После като отговори гейткипъра/софтсвича с RCF (и вътре има сложен destination adres = външния адрес на рутера), рутера пренаписва вътре пакета и слага пак вътрешния адрес на Микронета. Микронета получава RCFа, вижда си вътре неговоти си IP и се кротва.

Та или рутера трябва да е с протоколен NAT, или да настроиш Микронета да знае, че е за НАТ.

Те това е.

Между другото, протокол (H323-SIP) транскодинга е супер неебателен откъм ресурси. Можеш да пуснеш значително количество разговори. Единствения ти проблем може да е несъвместимост с някои типове съобщения.
Конвертирането на кодеците, обаче, както сам каза - да, яде много :)