forum.technoforward.ru

Wireshark чем и удобен, что можно не только увидеть пакеты, но и раскрыть содержимое, сделать соответствующие сортировки.
Если рассматривать SIP протокол, то на запрос INVITE должен прийти ответ 100 (Trying) далее 180 (Ringing) и 200 (OK), в теле которого (Message Body) сообщается адрес для передачи голоса. Только после этого сообщения от SV8100 пойдут голосовые пакеты. В это время могут быть запросы ASK и ответы на него 200 OK (не путать с OK на ответ Invite).

Вот Message Body на городской

Message Body на сотовый

может вам файлы скинуть трассировок?

Видимо нерешаемая проблема. Мне вот лично отличия трассировок ни о чем не говорят, что нужно в конфигурации изменить.

В принципе, все корректно. Так от Sl1000 не идут вообще RTP (UDP) пакеты после получения OK? Проверьте 84-14 (по умолчанию) и 84-13-28 (G.711), 84-13-01- 20ms, 02 - выключен, 03 - a-law (также можно сделать все по умолчанию).
А при входящей с мобильников есть голос?

В общем ситуация такая:
1. При звонке на городской сначало идет запрос ACK, потом запрос INVITE, в ответ идет 100 Auth trying и ответ 100 Trying(все в последовательности как написал). После этого сразу начинают идти UDP-пакеты от прокси сервера SIP-провайдера? от SL1000 в ответ ничего нет, но после пакета 180 Ringing, еще до ответа на него начинают идти пакеты уже в обе стороны(и от SL1000 и к ней), потом приходит ответ 200 OK, после него также UDP-пакеты в обе стороны идут.
2. При звонке на сотовый несколько другая последовательность. Сначала идет запрос INVITE, в ответ идет 100 Auth trying, потом 407 Proxy Authentification Required, потом также как на городской(ACK, потом запрос INVITE, в ответ идет 100 Auth trying и ответ 100 Trying), но в отличае от городского, сразу после этих пакетов не идут UDP/RTP-пакеты, а идет 180 Ringing. После него начинают идти RTP-пакеты в сторону SL1000, после ответа 200 OK пакеты также идут в одну сторону, далее такая последовательность продолжается несколько раз(ответ 200 OK и RTP пакеты в сторону SL1000, видимо оборудование SIP-провайдера думает что пакет потерялся с ответом ОК и пытается отправлять их снова и снова, пакетов от SL1000 вообще при этом никаких не посылается).

Входящие с сотового есть, голос идет.
Настройки у меня 84-13-28 (only G.711), 84-13-01- 20ms, 02 - выключен, 03 - a-law.
В 84-14, я менял только настройку 06 - вместо 5060, выставил порт 5068 и в настройке 07 поставил 1800, остальное не трогал.

Можно посмотреть название сервера в ответе 180 или 200 (OK). Была проблема, когда не проходила регистрация на Asterisk, если в названии присутствовали скобки без пробела. Например: Server: Asterisk(1.. Но все было в порядке, когда был пробел перед скобками: Server: Asterisk (1..
Но в данном случае почему все же через другого оператора все работает. Может стоит оставить собственный порт станции в 84-14-06 5060, а у оператора 5068. Или оператор и вам должен слать сообщения на 5068 (входящая связь)?

серверы у меня прописаны все по IP-адресами. А вот поменял порт на 5060 в 84-14-06 и все нормально стало, СПАСИБО ОГРОМНОЕ!!!!

хотя сейчас нет нет, да все равно на сотовый проскакивает та же ситуация, с самого начала было где то раз из 10 звонков, сейчас почаще.

Связался с тех.поддержкой SIP-оператора, отослал трассировку ему, вот что он ответил:
"Видно ошибку в дампе. Соединение даже не установилось правильно. Узел 192.168.0.10 игнорирует сигнал снятия трубки (sip-сообщение ОК). ip-пакеты №428,455,512.
Уточните у разработчика АТС чем это вызвано. Может из-за символа # в поле Contact сообщения OK ? Перешлите дамп неудачного вызова разработчику АТС."

Может и из-за символа #. Только, когда проходит звонок через другого оператора, этот символ отсутствует? Также получается, что иногда вызовы проходят через данного оператора, или звонят на другой номер, где # отсутствует.
Используете последнюю версию Sl1000?

когда удачно соединение проходит, то Contact выглядит так: <sip:89041600666@80.75.130.154:5060;transport=udp>
а когда неудачно, то так: <sip:01#79041600666@109.107.176.42:5061>
Тех.поддержка оператора ответила, что этот символ разрешен для данного поля, но встречается редко.
Ну и как видно, соединения успешно проходят с сервера IP-адреса 80.75.130.154:5060, а неудачно с 109.107.176.42:5061. Раньше просто городские соединялись с одного адреса, а сотовые с другого, сейчас и сотовые с обоими случайным образом стали соединяться.
Может Вам прислать трассировки для наглядности? Или тут написать какие либо моменты из них?

Если необходимо, чтобы Эдванс направил запрос производителю, то необходимо связаться с менеджером, а дальше по обстоятельствам (трассировки, конфигурация, дополнительные испытания).
Хотелось бы узнать, как было у старого оператора? Там же все соединения проходили.
Небольшие замечания по порту 5061:
The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP (RFC 3261).
В SL1000 для SIP выбирается либо UDP, либо TCP (одновременно не поддерживается). Если идет ответ по порту 5061, не используется ли там TCP.