OS7070 SIP

[Ave]

Есть станция Samsung OfficeServ7070 v4.53s, к которой ранее были подключены 5 аналоговых линий через VoIP шлюзы.
Клиент решил избавиться от них, купив лицензии на MGI каналы и SIP транки, и выведав у провайдера регистрационные данные для своих 5 линий.
Все это прекрасно вбили, вроде как даже все работает, но!
После перевода входящего звонка, как только абонент снимает трубку - пропадает звук, причем как с одной так и с другой стороны.
В 861 коде MPS Service отключен,
в 837 коде Hold Reinvite также отключен, с включенным параметром даже гудков после перевода не было слышно.
На всякий случай SS Type в этом же коде выставил PBX managed 1, чтобы уж точно reinvite не слал.

Станция стоит за роутером, порты 5060 и 30000-30015 на станцию прокинуты.
Пробовал различные комбинации параметров в 837 коде, но никакой из них не дал результатов.
Причем иногда слышимость все-таки появляется, но установить закономерность так и не смог.
Трассировка прилагается
http://ifolder.ru/28239457
Если надо, могу выложить и файл настроек самой станции.

[LionB]

После попытки трансфера (см. инвайт от IP 62.16.111.210)
UDP порт провайдера затыкается на прием. И в резальтате:

RTCP пакет 1425
Real-time Transport Control Protocol (Goodbye)
Text: session stopped
Reason string is not NULL-terminated (see RFC3550, section 6.6)

И далее ICMP пакеты от OS7070 (Destination Port Unreachable) - голосовые порты провайдера заткнулись на прием...

Вот и поговори с провайдером с этим трэйсом в руках, что им не нравится в ситуации перевода вызова на вашей стороне?

[Ave]

Спасибо, поговорим.
А как сделать так, чтобы станция вообще re-invite не слала при нажатии flash на станции?
Чтобы SIP Trunk был как обычная городская линия для станции.

[LionB]

Так у тебя Re-Invite и нету. Ты его отключил.
Сейчас у тебя новый Invite в этот момент.
А больше никак, либо Re-invite в той же сессии, либо новый инвайт с использованием тех же портов.
Ведь если ты переводишь вызов на другой внутренний, то у него и CLIP может смениться, и оператор это должен знать для того-же билинга и уметь понимать.
А, если он тупо умеет только функционал базового вызова, то обратно в каменный век на шлюз с FXS портами.

[Ave]

А можно поподробней расписать почему

UDP порт провайдера затыкается на прием.

Исходя из чего? А то я с провайдером на пару смотрю на трассировку и не понимаю.
Причем после перевода звонка и посылки инвайта от станции и ответа ask от сервера - rtp пакеты еще идут *это проявляется в том, что иногда слышно первое слово собеседника*, а потом от станции прилетает RTCP Goodbye, после чего она пытается делать ICMP запросы, при этом сервер провайдера продолжает слать RTP пакеты, а станция уже нет.

[LionB]

Он слать-то шлет (ну и что?), но отказывается их принимать и ставит UDP порты в Unreachable.
На стороне АТС ничего не остается, как попытаться несколько раз проделать ICMP и закрыть не работающее соединение.

Раз этот провайдер в принципе не знает способы передачи сессии к другому абоненту на стороне клента (Transfer) и как это отрабатывается в SIP, не знает, почему возникает такой контрольный пакет RTCP Goodbye после попытки Invite (или Re-Invite) на перенаправление сессии, то учить его этому никто не обязан. Я пока делаю вывод, что SIP сервер провайдера (или биллиговая система с которой он неразрывно связан) в принципе не поддерживает мультисессию (только базовый вызов).

P.S. Попробуй у себя в лабе соединить два OS (ну или хоть на SIPNet подключись) сделай трансфер и отошли ему трэйс. Пусть посмотрит, как оно должно отрабатываться с включенным Hold Reinvite и без него.

[Ave]

У провайдера одни SIP шлюзы стоят, только клиент станции OS7070 решил от них избавиться и завести напрямую.
Судя по трейсу и со слов провайдера у него OpenSIPS на FreeBSD, а это только proxy-сервер.

в принципе не поддерживает мультисессию (только базовый вызов).

Т.е. один аккаунт = один разговор?

[LionB]

Не так.
Один аккаунт, хоть сколько (ну или там сколько у них на шлюзе транков было) одновременных разговоров, но - Сессию (один и тот же разговор) не дает переназначить (ну не поддерживает он трансфер. Он по получению нового Invite или Reinvite с тем же номером сессии должен приостановить свой поток RTP, а он наоборот продолжает его сыпать, вот и получаем RTCP - string not NULL, и далее подтвердить этот invite и уже после этого продолжить RTP обмен, а он ничего этого не делает, а уходит в ступор).

[Ave]

Спасибо, кажется начало что-то проясняться...

[brownbear]

А какой у вас провайдер. Проблема решилась? А то у меня точно такая же ситуация.