Transfer / Hold mit Asterisk 1.8 und snomD375/8.9.3.46 funktioniert nicht
S
Sebastian Denz
started a topic
about 2 years ago
Hallo zusammen,
bei unserem Kunden kommt es bei einem neuen Snom D375 in Kombination mit Asterisk 1.8.20.1 zu Problemen bei Hold/Transfer.
Sobald der Anwender Hold/Transfer drueckt, wird das Gespraech vom Snom beendet.
SDP vom Re-Invite des Snoms:
v=0
o=root 1439571536 1439571538 IN IP4 172.16.23.122
s=call
c=IN IP4 172.16.23.122
t=0 0
m=audio 55164 RTP/AVP 9 8 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendonly
m=video 0 RTP/AVP 34 98
SDP vom 200 OK der Asterisk:
v=0
o=root 783617859 783617860 IN IP4 172.16.23.10
s=Asterisk PBX 1.8.20.1
c=IN IP4 172.16.23.10
t=0 0
m=audio 11632 RTP/AVP 8 9 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=recvonly
Danach schickt das Snom ein ACK und ein BYE...
Im Log des Snoms findet sich zum entsprechenden Zeitpunkt folgendes:
Dec 20 11:15:57.592 [NOTICE] PHN: TPL: Socket 66 idle/connect timeout
Dec 20 11:16:03.134 [NOTICE] MEDIA: MediaIpc::rtpClose: RP10
Dec 20 11:16:03.134 [NOTICE] MEDIA: MediaIpc::rtpClose: RC10
Dec 20 11:16:03.151 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce
Dec 20 11:16:03.151 [NOTICE] SIP: process auth: Match challenge for user=jm, realm=asterisk
Dec 20 11:16:04.434 [NOTICE] MEDIA: onRtpClose: RP10
Dec 20 11:16:04.435 [ERROR ] MEDIA: StopCall: failed to stop 2682254417
Dec 20 11:16:04.435 [NOTICE] MEDIA: onRtpClose: RC10
Dec 20 11:16:05.342 [NOTICE] PHN: Fetching URL: snom://mb_exit/?...
Dec 20 11:16:05.355 [NOTICE] CSTA: csta_cid = 7 phone_cid7
Die Codes habe ich soweit moeglich eingeschraenkt und die Parameter auf dem Snom und der Asterisk geprueft.
Soweit kann ich dort keine Unstimmigkeit entdecken?!
Mangels weiterfuehrender Informationen gehe ich aktuell von einem FW-Bug des Snoms aus?!
Ueber Hinweise, Fixes wuerde ich mich freuen!
Vielen Dank und Viele Gruesse,
Sebastian Denz
PS: Ein Changelog zum FW-Update des D375 waere hilfreich! ;)
Best Answer
P
Pietro Bertera
said
about 2 years ago
Dear Sebastian,
please don't mind if I'm answering you in English.
the issue you reported is a known Asterisk bug:
As you can see the phone sends the re-INVITE containing the "m=video 0 RTP/AVP 34 98" SDP media line (probably this is an incoming call from with video media in the offer).
Then Asterisk accepts the re-INVITE with a 200 OK which is not containing this media line. By RFC the PBX should report all the media line contained in the SDP offer. This is the reason of the BYE from the phone.
Here you have some options:
1) remove the video codec from the Asterisk peer definition (this will not hurt, since Snom doesn't support video).
2) update Asterisk to a more recent version (the issue is already fixed)
please don't mind if I'm answering you in English.
the issue you reported is a known Asterisk bug:
As you can see the phone sends the re-INVITE containing the "m=video 0 RTP/AVP 34 98" SDP media line (probably this is an incoming call from with video media in the offer).
Then Asterisk accepts the re-INVITE with a 200 OK which is not containing this media line. By RFC the PBX should report all the media line contained in the SDP offer. This is the reason of the BYE from the phone.
Here you have some options:
1) remove the video codec from the Asterisk peer definition (this will not hurt, since Snom doesn't support video).
2) update Asterisk to a more recent version (the issue is already fixed)
Sebastian Denz
Hallo zusammen,
bei unserem Kunden kommt es bei einem neuen Snom D375 in Kombination mit Asterisk 1.8.20.1 zu Problemen bei Hold/Transfer.
Sobald der Anwender Hold/Transfer drueckt, wird das Gespraech vom Snom beendet.
SDP vom Re-Invite des Snoms:
v=0
o=root 1439571536 1439571538 IN IP4 172.16.23.122
s=call
c=IN IP4 172.16.23.122
t=0 0
m=audio 55164 RTP/AVP 9 8 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendonly
m=video 0 RTP/AVP 34 98
SDP vom 200 OK der Asterisk:
v=0
o=root 783617859 783617860 IN IP4 172.16.23.10
s=Asterisk PBX 1.8.20.1
c=IN IP4 172.16.23.10
t=0 0
m=audio 11632 RTP/AVP 8 9 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=recvonly
Danach schickt das Snom ein ACK und ein BYE...
Im Log des Snoms findet sich zum entsprechenden Zeitpunkt folgendes:
Dec 20 11:15:57.592 [NOTICE] PHN: TPL: Socket 66 idle/connect timeout
Dec 20 11:16:03.134 [NOTICE] MEDIA: MediaIpc::rtpClose: RP10
Dec 20 11:16:03.134 [NOTICE] MEDIA: MediaIpc::rtpClose: RC10
Dec 20 11:16:03.151 [WARN ] SIP: process_registrar_packet: 401 needs 128 bit nonce
Dec 20 11:16:03.151 [NOTICE] SIP: process auth: Match challenge for user=jm, realm=asterisk
Dec 20 11:16:04.434 [NOTICE] MEDIA: onRtpClose: RP10
Dec 20 11:16:04.435 [ERROR ] MEDIA: StopCall: failed to stop 2682254417
Dec 20 11:16:04.435 [NOTICE] MEDIA: onRtpClose: RC10
Dec 20 11:16:05.342 [NOTICE] PHN: Fetching URL: snom://mb_exit/?...
Dec 20 11:16:05.355 [NOTICE] CSTA: csta_cid = 7 phone_cid7
Die Codes habe ich soweit moeglich eingeschraenkt und die Parameter auf dem Snom und der Asterisk geprueft.
Soweit kann ich dort keine Unstimmigkeit entdecken?!
Mangels weiterfuehrender Informationen gehe ich aktuell von einem FW-Bug des Snoms aus?!
Ueber Hinweise, Fixes wuerde ich mich freuen!
Vielen Dank und Viele Gruesse,
Sebastian Denz
PS: Ein Changelog zum FW-Update des D375 waere hilfreich! ;)
Dear Sebastian,
please don't mind if I'm answering you in English.
the issue you reported is a known Asterisk bug:
As you can see the phone sends the re-INVITE containing the "m=video 0 RTP/AVP 34 98" SDP media line (probably this is an incoming call from with video media in the offer).
Then Asterisk accepts the re-INVITE with a 200 OK which is not containing this media line. By RFC the PBX should report all the media line contained in the SDP offer. This is the reason of the BYE from the phone.
Here you have some options:
1) remove the video codec from the Asterisk peer definition (this will not hurt, since Snom doesn't support video).
2) update Asterisk to a more recent version (the issue is already fixed)
3) enable this parameter on the phone: http://wiki.snom.com/Settings/allow_mismatched_sdp_answers
Actually i would discurage the 3): this can create some "confusion" on the media handling on the phone.
Thanks and best regards,
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstPietro Bertera
Dear Sebastian,
please don't mind if I'm answering you in English.
the issue you reported is a known Asterisk bug:
As you can see the phone sends the re-INVITE containing the "m=video 0 RTP/AVP 34 98" SDP media line (probably this is an incoming call from with video media in the offer).
Then Asterisk accepts the re-INVITE with a 200 OK which is not containing this media line. By RFC the PBX should report all the media line contained in the SDP offer. This is the reason of the BYE from the phone.
Here you have some options:
1) remove the video codec from the Asterisk peer definition (this will not hurt, since Snom doesn't support video).
2) update Asterisk to a more recent version (the issue is already fixed)
3) enable this parameter on the phone: http://wiki.snom.com/Settings/allow_mismatched_sdp_answers
Actually i would discurage the 3): this can create some "confusion" on the media handling on the phone.
Thanks and best regards,
Sebastian Denz
Thank you very much for your fast and helpful reply!
videosupport=no did the trick! :)
-
LDAP and country code
-
Settings are changed when user logs on
-
USB Bluetooth compatibility for D725
-
Low volume with Plantronics Headset
-
Change Log for FW 8.8.3.32
-
Subscriptions failing after time since upgrade to 8.7.5.28
-
SNOM 870 - INBAND DTMF
-
SNOM 320 + Headset Plantronics CS540A with Snom EHS
-
Configure Settings - Set all to Read Only
-
Can't enter "+" sign in directory via WUI
See all 506 topics