исходящие работают нормально, а входящие при поднятии трубки обрываются.
http://pastebin.com/D6dJRgFg
вот конфиг http://pastebin.com/kFRZzvRE
Phonerlite работает нормально http://pastebin.com/WJDHYn4X
Писал в техподдрежку вот что ответили:
[Показать] Спойлер:
Проблема в том, что от вас приходят сообщения по SIP-у с нарушением RFC (см. прилагаемый дамп). Сначала приходит ОК:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 195.239.174.100:5060;rport=5060;received=195.239.174.100;branch=z9hG4bKg3Zqkv7io85t59wjvthgswt4cdjxqnu7j
Record-Route: <sip:195.239.174.100;transport=udp;lr>
Call-ID: BW1722015642707162027969332@10.64.248.6
From: "9657083150 9657083150" <sip:+79657083150@mpbx.sip.beeline.ru;user=phone>;tag=h7g4Esbg_309633853-1469629321564-
To: "9682637958 9682637958" <sip:9682637958@mpbx.sip.beeline.ru>;tag=i10FVKw4T7dbnBGlKpRW4x.iWvZw2O1.;cscf
CSeq: 375253167 INVITE
Server: FPBX-13.0.163(13.9.1)
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER, REFER
Contact: <sip:88.215.165.57:5060>
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1801;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 36136438 3 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 88.215.165.57
t=0 0
m=audio 19534 RTP/AVP 8 98
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=maxptime:150
a=recvonly
Обращаем внимание на a=recvonly
Далее от нас идет реинвайт, на который вы отвечаете ОК:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 195.239.174.100:5060;rport=5060;received=195.239.174.100;branch=z9hG4bKg3Zqkv7ivxmfdeq4qqumej17tvg33i46g
Call-ID: BW1722015642707162027969332@10.64.248.6
From: "9657083150 9657083150" <sip:+79657083150@mpbx.sip.beeline.ru;user=phone>;tag=h7g4Esbg_309633853-1469629321564-
To: "9682637958 9682637958" <sip:9682637958@mpbx.sip.beeline.ru>;tag=i10FVKw4T7dbnBGlKpRW4x.iWvZw2O1.;cscf
CSeq: 375253168 INVITE
Session-Expires: 1801;refresher=uac
Require: timer
Contact: <sip:88.215.165.57:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-13.0.163(13.9.1)
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 36136438 3 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 88.215.165.57
t=0 0
m=audio 19534 RTP/AVP 8 98
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
Обращаем внимание на a=sendrecv. Но при этом версия сессии осталась неизменной! А это противоречит RFC.
http://tools.ietf.org/html/rfc3264#section-6
8 Modifying the Session
At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session. It is fundamental to
the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters
of an existing session.
The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous
SDP". If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different. If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section
6.
О version, можно прочитать тут:
[RFC4566 /SDP: Session Description Protocol/ 5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 195.239.174.100:5060;rport=5060;received=195.239.174.100;branch=z9hG4bKg3Zqkv7io85t59wjvthgswt4cdjxqnu7j
Record-Route: <sip:195.239.174.100;transport=udp;lr>
Call-ID: BW1722015642707162027969332@10.64.248.6
From: "9657083150 9657083150" <sip:+79657083150@mpbx.sip.beeline.ru;user=phone>;tag=h7g4Esbg_309633853-1469629321564-
To: "9682637958 9682637958" <sip:9682637958@mpbx.sip.beeline.ru>;tag=i10FVKw4T7dbnBGlKpRW4x.iWvZw2O1.;cscf
CSeq: 375253167 INVITE
Server: FPBX-13.0.163(13.9.1)
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER, REFER
Contact: <sip:88.215.165.57:5060>
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1801;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 36136438 3 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 88.215.165.57
t=0 0
m=audio 19534 RTP/AVP 8 98
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=maxptime:150
a=recvonly
Обращаем внимание на a=recvonly
Далее от нас идет реинвайт, на который вы отвечаете ОК:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 195.239.174.100:5060;rport=5060;received=195.239.174.100;branch=z9hG4bKg3Zqkv7ivxmfdeq4qqumej17tvg33i46g
Call-ID: BW1722015642707162027969332@10.64.248.6
From: "9657083150 9657083150" <sip:+79657083150@mpbx.sip.beeline.ru;user=phone>;tag=h7g4Esbg_309633853-1469629321564-
To: "9682637958 9682637958" <sip:9682637958@mpbx.sip.beeline.ru>;tag=i10FVKw4T7dbnBGlKpRW4x.iWvZw2O1.;cscf
CSeq: 375253168 INVITE
Session-Expires: 1801;refresher=uac
Require: timer
Contact: <sip:88.215.165.57:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-13.0.163(13.9.1)
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 36136438 3 IN IP4 192.168.1.5
s=Asterisk
c=IN IP4 88.215.165.57
t=0 0
m=audio 19534 RTP/AVP 8 98
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
Обращаем внимание на a=sendrecv. Но при этом версия сессии осталась неизменной! А это противоречит RFC.
http://tools.ietf.org/html/rfc3264#section-6
8 Modifying the Session
At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session. It is fundamental to
the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters
of an existing session.
The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous
SDP". If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different. If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section
6.
О version, можно прочитать тут:
[RFC4566 /SDP: Session Description Protocol/ 5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
Пожалуйста помогите разобраться!
