KX-TDE200 + KX-TDE100 + sip

[Scorp]

Доброго времени суток Уважаемые форумчане!
Есть KX-TDE200 в центральном офисе и KX-TDE100 в филиале. АТСки связаны между собой по SIP двумя транками ( пока на каждой только 4 лицензии но уже заказали дополнительные на каждую). В филиале купили 3 внешних линии по SIP - пока настроил только 2 (по кол-ву лицензий). И вот тут собственно подкралась проблема:
1) В филиале KX-TDE100 п. 10.1 для виртуальных линий прописаны названия:
слот1 порт1 TDE200Основной группа 2
слот1 порт2 TDE200Резерв группа2
слот1 порт3 Внешн1 группа3
слот1 порт4 Внешн2 группа3

В 4.1.4 на системном телефоне прописываем :
1 одиночная CO линия TDE200Основной
2 одиночная CO линия TDE200Резерв
3 одиночная CO линия Внешн1
4 одиночная CO линия Внешн2

Прописали в обеих АТС внутринние диапазоны номеров (2.6.1)
При звонке из центрального офиса в филиал на системный телефон при ручном вводе номера с апарата (номер 710) должна высвечиваться линия TDE200Основной или TDE200Резерв но высвечивается Внешн2
При звонке на внешнюю линию филиала на системном телефоне высвечивается тоже Внешнн2 при этом нельзя позвонить паралельно на Внешнюю линию 1 филиала .
Где может быть подвох в настройках ? получается АТС считает любую свою SIP линию как Внешн2.

[Mike_K]

Извените за глуппый вопрос, Вы спецификацию SIP хоть раз читали?
SIP изначально заявлен как протокол сервер-абонент (читать как конечный пользователь).
С чего Вы взяли, что при этом будет полноценное объединение двух АТС.

[НачШтаба]

Я так думаю, что это всеобщая сипо-мания и сипо-зомбирование. "Протокол", который как бы не является протоколом телефонии (во всяком случае официальным, принятым Международным Комитетом Связи) суют куда угодно и для чего угодно.
Майк_К верно заметил, SIP это клиент-серверное приложение. То есть есть "сервер" - "вышестоящея" IP АТС, и есть клиент - абонент, "выраженный" софтфоном, IP-телефоном или IP-СО-портом. Если ещё как-то можно "осознать" режим работы SIP-точек в режиме P-2-P, (телефоны с МБ, ну те, у которых сбоку крутишь ручку и говоришь "Барышня, Смольный!" тоже можно соединить напрямую друг без всяких АТС), то как-то не очень понятно, при работе двух серверов кто из обоих тянет на себя одеяло? (Линию с городской АТС как ни соединяй с другой линией тоже от городской АТС, всё равно ничего не работает).
Что-то я разошёлся. Короче, нахер SIP, мочите H.323, каким бы он вам сложным не показался бы.

[Scorp]

Извените за глуппый вопрос, Вы спецификацию SIP хоть раз читали?
SIP изначально заявлен как протокол сервер-абонент (читать как конечный пользователь).
С чего Вы взяли, что при этом будет полноценное объединение двух АТС.

Sip был выбран именно из-за того, что АТС центрального офиса и филиала находятся за NAT, при этом доступ к портам SIP разрешен только с определенных IP. В такой конфигурации АТСки не висят попами в интернет и не ждут пока какой-нить хацкер туда че-нить вставит C h.323 прохождение NAT проблематично, но и тут есть вариант - только прийдется схему обьединения филиальных АТС поправить ...

[Mike_K]

Не знаю, на чём у Вас NAT и почему сложнее H.323 пробросить.
Несколько десятков TDE сейчас работают за NAT по Н.323, нет проблем.
Да, NAT на Kerio организован.

[Scorp]

Не знаю, на чём у Вас NAT и почему сложнее H.323 пробросить.
Несколько десятков TDE сейчас работают за NAT по Н.323, нет проблем.
Да, NAT на Kerio организован.

На самом деле, проблема не в выборе ядра, на котором будет работать NAT (хотя мне слабо верится в сетевую безопасность компании, в которой попами в интернет смотрят windows-серверы c Kerio на борту). Основная проблема в самом протоколе Н.323 и способе его прохождения через маршрутизаторы и NAT ( это со стороны системного администратора). Проблемы H.323 с NAT - невозможность NAT-а 'предсказать' порты для UDP потоков на стоящее за NAT железо по TCP сигнализации. Т.е для того, чтоб H.323 заработал с NATом мы должны иметь на сервере с NAT 'активный`модуль,который должен уметь декодировать H.323 в реальном времени и получать информацию о портах UDP потоков. Все это конечно можно реализовать, но ворос время/деньги. В случае с SIP все гораздо веселей - в АТС в свойствах виртуальной платы включается NAT и пробрасываются порты на АТС.

[Mike_K]

Если NAT, не на коленке создан, это так отступление,
то обязательно будет инспектор протокола (или, что-то ему подобное),
что позволит безопасно, корректно и правильно обрабатывать конкретный протокол.

[Scorp]

Если NAT, не на коленке создан, это так отступление,
то обязательно будет инспектор протокола (или, что-то ему подобное),
что позволит безопасно, корректно и правильно обрабатывать конкретный протокол.

Все это конечно хорошо и можно циски покупать для этой задачи (при этом существенно возрастают затраты на телефонию), но тогда вопрос или покупать циску или использовать SIP протокол. Тем более, что сейчас гораздо легче получить внешнюю городскую линию по SIP а сама АТС работает только или по H.323 или по SIP (или тут я че-то путаю?)

[Mike_K]

Забирайте от города линии как Вам удобно, как обычные аналоговые, по SIP, H.323 или EDSS1, не об этом разговор.
Вы не получите полноценного объединения АТС, если будите использовать для этого SIP.
SIP не является симметричным и не поддерживает межстанционные сетевые функции.
SIP, исначально был разработан для организации связи между клиентом, желающим получить услугу связи и провайдером, эту услугу предоставляющим.

[НачШтаба]

Одного не понимаю, если там всякие NAT-ы, которые умеют сделать так, чтобы "доступ к портам SIP разрешен только с определенных IP", то.. ни хера не понимаю.. Конторы разные? Разные юр-лица? Типа и тупо VPN юзать вообще совсем не за чем?.. На Микротиках, если жаба жрёт на циську. Зато это полценное решение, а не "соевое мясо".