Элтекс

После обновления на последнюю прошивку вышла проблема. Разъединение после 18x сообщений. Визуально в диалоге отличается CSeq. Хотя судя по RFC так и должно быть. А вот branch наверно меняться не должен.

#
U 172.16.120.252:5060 -> 89.xx.xx.14:5080
INVITE sip:429783@89.xx.xx.14:5080 SIP/2.0.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport;branch=z9hG4bK-o2612e91297I8c1414K7.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>.
Call-ID: 1416-393187-113343.
CSeq: 113362 INVITE.
User-Agent: Eltex smg_pa_sip 3.2.0.62.
Max-Forwards: 70.
Contact: <sip:421211@172.16.120.252:5060>.
Accept: multipart/mixed, application/sdp.
Allow: INVITE, ACK, BYE, CANCEL, PRACK, REGISTER, INFO, REFER, NOTIFY, OPTIONS, UPDATE.
Supported: 100rel, replaces.
Category: 10.
P-Eltex-Info: {trunk,4} 1658 <0.1614.0>.
Content-Type: application/sdp.
Content-Length: 350.
.
v=0.
o=- 1658 113724 IN IP4 172.16.120.252.
s=SMG SIP session.
c=IN IP4 172.16.120.252.
t=0 0.
m=audio 27632 RTP/AVP 8 0 18 4 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:4 G723/8000.
a=fmtp:4 annexa=no, bitrate=6.3.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:10.
a=sendrecv.

#
U 89.xx.xx.14:5080 -> 172.16.120.252:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport=5060;branch=z9hG4bK-o2612e91297I8c1414K7;received=172.16.120.252.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>.
Call-ID: 1416-393187-113343.
CSeq: 113362 INVITE.
Server: kamailio (4.2.1 (x86_64/linux)).
Content-Length: 0.
.

#
U 89.xx.xx.14:5080 -> 172.16.120.252:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 172.16.120.252:5060;received=172.16.120.252;rport=5060;branch=z9hG4bK-o2612e91297I8c1414K7.
Record-Route: <sip:89.xx.xx.14:5080;lr=on;nat=yes>.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=S3K3m2mtDXmQK.
Call-ID: 1416-393187-113343.
CSeq: 113362 INVITE.
Contact: <sip:429783@172.16.120.195:5060>.
RSeq: 913495158.
User-Agent: TAU-72 build 2.12.0 sofia-sip/1.12.10.
Accept: application/sdp, multipart/mixed, application/isup.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO.
Require: 100rel.
Supported: timer, 100rel, replaces.
Content-Length: 0.
.

#
U 172.16.120.252:5060 -> 89.xx.xx.14:5080
PRACK sip:429783@89.xx.xx.14:5080 SIP/2.0.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport;branch=z9hG4bK-o2612e91297I8c14776d.
Route: <sip:89.xx.xx.14:5080;lr=on;nat=yes>.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=S3K3m2mtDXmQK.
Call-ID: 1416-393187-113343.
CSeq: 113363 PRACK.
User-Agent: Eltex smg_pa_sip 3.2.0.62.
Max-Forwards: 70.
Contact: <sip:421211@172.16.120.252:5060>.
Allow: INVITE, ACK, BYE, CANCEL, PRACK, REGISTER, INFO, REFER, NOTIFY, OPTIONS, UPDATE.
Supported: 100rel, replaces.
Rack: 913495158 113362 INVITE.
P-Eltex-Info: {trunk,4} 1658 <0.1614.0>.
Content-Length: 0.
.

#
U 89.xx.xx.14:5080 -> 172.16.120.252:5060
SIP/2.0 404 Not here.
Via: SIP/2.0/UDP 172.16.120.252:5060;received=172.16.120.252;rport=5060;branch=z9hG4bK-o2612e91297I8c14776d.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=S3K3m2mtDXmQK.
Call-ID: 1416-393187-113343.
CSeq: 113363 PRACK.
Server: kamailio (4.2.1 (x86_64/linux)).
Content-Length: 0.
.

#
U 172.16.120.252:5060 -> 89.xx.xx.14:5080
CANCEL sip:429783@89.xx.xx.14:5080 SIP/2.0.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport;branch=z9hG4bK-o2612e91297I8c1414K7.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>.
Call-ID: 1416-393187-113343.
CSeq: 113362 CANCEL.
Max-Forwards: 70.
Content-Length: 0.
.

#
U 89.xx.xx.14:5080 -> 172.16.120.252:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport=5060;branch=z9hG4bK-o2612e91297I8c1414K7;received=172.16.120.252.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=3fa0761bc83750a350163e9051faef33-efaa.
Call-ID: 1416-393187-113343.
CSeq: 113362 CANCEL.
Server: kamailio (4.2.1 (x86_64/linux)).
Content-Length: 0.
.

#
U 89.xx.xx.14:5080 -> 172.16.120.252:5060
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP 172.16.120.252:5060;received=172.16.120.252;rport=5060;branch=z9hG4bK-o2612e91297I8c1414K7.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=S3K3m2mtDXmQK.
Call-ID: 1416-393187-113343.
CSeq: 113362 INVITE.
User-Agent: TAU-72 build 2.12.0 sofia-sip/1.12.10.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO.
Supported: timer, 100rel, replaces.
Content-Length: 0.
.

#
U 172.16.120.252:5060 -> 89.xx.xx.14:5080
ACK sip:429783@89.xx.xx.14:5080 SIP/2.0.
Via: SIP/2.0/UDP 172.16.120.252:5060;rport;branch=z9hG4bK-o2612e91297I8c1414K7.
Route: <sip:89.xx.xx.14:5080;lr=on;nat=yes>.
From: "421211" <sip:421211@172.16.120.252;user=phone>;tag=113367393187.
To: <sip:429783@89.xx.xx.14;user=phone>;tag=S3K3m2mtDXmQK.
Call-ID: 1416-393187-113343.
CSeq: 113362 ACK.
User-Agent: Eltex smg_pa_sip 3.2.0.62.
Max-Forwards: 70.
Contact: <sip:421211@172.16.120.252:5060>.
P-Eltex-Info: {trunk,4} 1658 <0.1614.0>.
Content-Length: 0.
.

а на kamailio нельзя более подробные логи снять, чтобы понять что ему не нравится?

kamailio говорит что-то вроде этого:

<core> [receive.c:298]: receive_msg(): receive_msg: cleaning up
<core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:
<core> [parser/msg_parser.c:625]: parse_msg(): method: <PRACK>
<core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:429783@89.xx.xx.14:5080>
<core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>
<core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6
<core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-o2612e9156531a49865266>; state=16
<core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5
<core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2
<core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via
<core> [receive.c:154]: receive_msg(): After parse_msg...
<core> [receive.c:197]: receive_msg(): preparing to run routing scripts...
<core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=685By4a4QpBSN
<core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29
<core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [57]; uri=[sip:429783@89.xx.xx.14;user=phone]
<core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:429783@89.xx.xx.14;user=phone>]
<core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <811703> <PRACK>
maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70
<core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0
<core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header
<core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=811707455635
<core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29
sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1
siputils [checks.c:106]: has_totag(): totag found
rr [loose.c:90]: is_preloaded(): is_preloaded: No
<core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [89.xx.xx.14] == [89.xx.xx.14]
<core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5080 (advertise 0) matches port 5080
rr [loose.c:674]: after_strict(): Next hop: 'sip:89.xx.xx.14:5080;lr=on;nat=yes' is loose router
rr [loose.c:724]: after_strict(): The last route URI: 'sip:89.xx.xx.14:5080;lr=on;nat=yes'
tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=9 , global msg id=8 , T on entrance=(nil)
tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=47949, isACK=0
tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed
tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found
tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f25ee8e57b8, callback type 1, id 0 entered
<core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: 6d2b5903370e1f716794f3136108c9d5
tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
<core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)

Хм. Ясно все с техподдержкой. Полтора года назад тоже били себя пяткой в грудь, что все у них хорошо когда я на ошибки указывал. Вопрос следующий, откатиться с 3.2.0 на 3.0.0 можно или уже нет?

mustdie писал(а):Хм. Ясно все с техподдержкой. Полтора года назад тоже били себя пяткой в грудь, что все у них хорошо когда я на ошибки указывал. Вопрос следующий, откатиться с 3.2.0 на 3.0.0 можно или уже нет?

А Вы в тех поддержку обращались? или ограничились только обращением на форуме?

branch меняться может, у Вас не осталось старых удачных дампов с 3.0.0 для сравнения?

откатится можно на 3.0.0

похоже что нашли в чем у Вас была проблема, есть исправленная версия на SMG, только она не релизная, попробуете?

Если есть, то давайте попробую.

mustdie писал(а):Если есть, то давайте попробую.

отправил в ЛС

Здравствуйте.
Можно узнать, в каких случаях проблема наблюдается?
У меня по словам техподдержки виртуальной АТС МТТ, в 200 ОК SDP часть не отправляется.
200 ОК, после 183 IN PROGRESS отправляю, возможно, что ту же проблему что и ТС схватил?
Симптомы - сброс вызова после 200 ОК.
Если да, то как прошел тест лекарства, можно получить?

У меня сброс вызова после 18x. На прошивке 3.2.1 проблемы нет.

День добрый.
Как правильно рекомендуют надо обновиться до версии 3.2.1

Забыл отписаться. Обновился, проблема решилась.
Но все равно, с нетерпением жду релиз. Ну или хотя бы версию с увеличенным числом ТГ.