[SOLVED] У Cisco SPA-502 срывает крышу

[anonymous]

Коллеги, прошу помощи.

У клиента прошло удачное тестирование на софтфоне 3СХ, несколько экстеншенов, клиент сидит за натом, full-cone, сервер в ВЦ, не в сети клиента. По окончании тестов решили поставить аппараты, выбор пал на SPA-502.

Поставили новейшую прошивку, сделали provisioning через 3CX, но как только число зарегистрированных телефонов превышает два (а может и один), начинается не пойми что: все телефоны начинают бесконечную регистрацию с частотой до 2 раз в секунду. И, конечно же, становятся недоступными для SIP-сообщений. По одиночки все они работают нормально.

Пришлось вернуться на софтфоны, с которыми такого не происходит.

Встречался ли кто-нибудь с подобной ситуацией? Спасибо заранее!

 

[anonymous]

Напишите пожалуйста Ваше сообщение на английском языке. Существует ненулевая вероятность, что тогда Вас поймут. ;-)

 

[anonymous]

@ilya wrote:Напишите пожалуйста Ваше сообщение на английском языке.
Правильно ли я Вас понял, что написать следует не в русскоязычный форум?

 

[anonymous]

Если много телефонов работают за одним и тем же NAT, то в их конфигурации укажите разные "локальные" порты для SIP, а не 5060, который у них по умолчанию прописан. Например, первый 5060, второй 6060, третий 7060 и т.д.
Другой вариант, попробуйте поставить SIP/RTP прокси в удалённой сети и подключить его к PBX. В этом случае, все телефоны настроить на работу через прокси. Cisco телефоны через него должны нормально работать.
И вообще, я рекомендую использовать либо SIP/RTP tunneling proxy, либо VPN для подключения удалённых офисов к PBX.

P.S. Свежайшая прошивка Cisco телефонов - 7.4.9... Cisco предоставляет техническую поддержку пользователям. Спрашивайте у них напрямую и не стесняйтесь делать это.
Если предоставите дополнительную (и полную) информацию на этом форуме, то мы попробуем сами (при участии Cisco) разобраться в ситуации.

 

[anonymous]

Всем большое спасибо за помощь. Теперь нам стало ясно почему мы не смогли справиться с проблемой сами:

1. среда, в которой мы тестировали аппараты Циско была закрыта NАТом с SipAlg, и мы не увидели проблем.
2. софтоны 3СХ используют динамические порты, всвязи с чем проблема в продукционной среде (без SipAlg) не проявлялась.

Нам не хотелось отказываться от provisioning и мы не могли в данном случае использовать Proxy Manager, а потому мы решили проблему следующим образом:

мы написали небольшой aspx-скрипт, который "динамизировал" шаблоны, подготовленные сервером и заменял порты со стандартных на новые. Таким образом мы получали полную автоматизацию и независимость от НАТа.

Скрипт выглядит, кому интересно, так (указан не полностью):

Regex rx = new Regex("^[a-fA-F0-9]{12}$");
String MAC = Request.QueryString["ma"];
if(!rx.IsMatch(MAC)) throw new HttpException(401, "Invalid Argument");

String path = Path.GetDirectoryName(Request.PhysicalPath);
ocument document = ocument.Load(path + "\" + MAC + ".xml");
XElement root = document.XPathSelectElement("/flat-profile");
String ext = document.XPathSelectElement("/flat-profile/User_ID_1_").Value;

int basePort = ports[ext];

document.XPathSelectElement("/flat-profile/SIP_Port_1_").Value = basePort.ToString();
root.Add(new XElement("EXT_RTP_Port_Min", new XAttribute("group", "SIP/NAT_Support_Parameters"), basePort+2));
root.Add(new XElement("RTP_Port_Min", new XAttribute("group", "SIP/RTP_Parameters"), basePort+2));
root.Add(new XElement("RTP_Port_Max", new XAttribute("group", "SIP/RTP_Parameters"), basePort+40));

Response.Write(document.ToString());

После этого мы заменили URL для автоконфигурации в шаблоне с /provisioning/$MA.xml на /provisioning/cisco.aspx?ma?$MA и все заработало как часы.