Snom 370: "Not acceptable here"

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
G

groundhog

Neuer User
Mitglied seit
22 Jun 2005
Beiträge
28
Punkte für Reaktionen
0
Punkte
1
Mein bislang problemlos an Asterisk funktionierendes Snom 370 spinnt seit gestern indem es bei jeder von mir gewählten Nummer die Meldung

Not acceptable here xxxx

quittiert, wobei xxx für die gewählte Nummer steht. Sonst keine Funktion.

Es muss am Snom liegen, denn es gibt keine Meldungen im Asterisk. Ankommende Rufe werden signalisiert, eine Sprachverbindung kommt jedoch nicht zu stande.

Das Gerät hatte Softwarestand 7.1.33 und ich habe auf 7.3.10a upgedatet sowie alle Werte zurückgesetzt und neu eingegeben, ohne Ergebnis.

Hat jemand eine Idee?

Viele Grüße,
Axel
 
SIP Trace vom Telefon ?
 
Sip Protokoll:
Code: 
Sent to udp:10.0.0.180:5060 at 16/1/2009 10:45:21:851 (1066 bytes):

INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-8rlyh8latdka;rport
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:1039>;reg-id=1
P-Key-Flags: resolution="31x13", keys="4"
User-Agent: snom370/7.3.10a
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 372

v=0
o=root 2105507761 2105507761 IN IP4 10.000.131.10
s=call
c=IN IP4 10.000.131.10
t=0 0
m=audio 52484 RTP/AVP 8 0 9 99 3 18 4 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Received from udp:10.0.0.180:5060 at 16/1/2009 10:45:21:895 (478 bytes):

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-8rlyh8latdka;received=10.0.131.10;rport=1039
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>;tag=as3c7c9ed8
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1d276e47"
Content-Length: 0

Sent to udp:10.0.0.180:5060 at 16/1/2009 10:45:21:903 (341 bytes):

ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-8rlyh8latdka;rport
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>;tag=as3c7c9ed8
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 1 ACK
Max-Forwards: 70
Contact: <sip:[email protected]:1039>;reg-id=1
Content-Length: 0

Sent to udp:10.0.0.180:5060 at 16/1/2009 10:45:21:915 (1238 bytes):

INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-x5lq1cr1dkmi;rport
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 2 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:1039>;reg-id=1
P-Key-Flags: resolution="31x13", keys="4"
User-Agent: snom370/7.3.10a
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600;refresher=uas
Min-SE: 90
Proxy-Authorization: Digest username="110",realm="asterisk",nonce="1d276e47",uri="sip:[email protected];user=phone",response="177a2a5a5897327793baac34ff778d3f",algorithm=MD5
Content-Type: application/sdp
Content-Length: 372

v=0
o=root 2105507761 2105507761 IN IP4 10.000.131.10
s=call
c=IN IP4 10.000.131.10
t=0 0
m=audio 52484 RTP/AVP 8 0 9 99 3 18 4 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Received from udp:10.0.0.180:5060 at 16/1/2009 10:45:21:977 (390 bytes):

SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-x5lq1cr1dkmi;received=10.0.131.10;rport=1039
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>;tag=as3c7c9ed8
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Sent to udp:10.0.0.180:5060 at 16/1/2009 10:45:21:986 (341 bytes):

ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.131.10:1039;branch=z9hG4bK-x5lq1cr1dkmi;rport
From: <sip:[email protected]>;tag=940wskwzns
To: <sip:[email protected];user=phone>;tag=as3c7c9ed8
Call-ID: 3c267dd78474-8ahisu69w6hg
CSeq: 2 ACK
Max-Forwards: 70
Contact: <sip:[email protected]:1039>;reg-id=1
Content-Length: 0

Gruß,
Axel
 
Zuletzt bearbeitet:
Nein. bitte den Trace erst löschen und dann den Testanruf machen der besagte Fehlermeldung bringt. Dann den SIP Trace kopieren.
 
Sorry, habe meinen Post korrigiert.

Danke,
Axel
 
Hi,

da fehlt das Trace vom Telefon welches angerufen wird, ich vermute aber das es am Codec liegt, dass das angerufene Telefon den Codec nicht kann welcher verlangt wird, ich zumindest kenne diese Meldung davon.

Grüße
Timm
 
Timmbos These kann ich bestätigen. Ich habe den selben Effekt "Not acceptable here ..." in Verbindung mit meinem Snom320 und AskoziaPBX, wenn ich den G722 verwenden möchte. Halte ich mich hingegen an G711u gibt es keine Probleme.
 
Snom 320: "Not acceptable here"

Ich habe das gleiche Problem: snom320 8.7.5.17 (neueste Firmware) an Asterisk, wähle ich eine beliebige Nummer (intern oder extern) kommt immer im Display:
Code: 
"Not acceptable here"

Asterisk meldet :
Code: 
"WARNING[2243]: chan_sip.c:9187 process_sdp: We are requesting SRTP, but they responded without it!"

SIP Protokoll des snom320:
Code: 
Sent to udp:192.168.3.40:5060 at Jul 29 22:44:13 (1002 bytes):

INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-y2gm6ae7uqz8;rport
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snom320/8.7.5.17
Contact: <sip:[email protected]:5060>;reg-id=1
X-Serialnumber: 0004133594BC
P-Key-Flags: keys="3"
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Content-Type: application/sdp
Content-Length: 274

v=0
o=root 1629308898 1629308898 IN IP4 192.168.3.154
s=call
c=IN IP4 192.168.3.154
t=0 0
m=audio 64966 RTP/AVP 8 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:89LfllU/jXTCrrhUkJB+ByxgtCBW6onBwN1Y2Fnv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv

Received from udp:192.168.3.151:5060 at Jul 29 22:44:13 (551 bytes):

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-y2gm6ae7uqz8;received=192.168.3.154;rport=5060
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>;tag=as2d735ef7
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 1 INVITE
Server: Asterisk PBX 1.8.13.1~dfsg1-3+deb7u3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1f7df19d"
Content-Length: 0

Sent to udp:192.168.3.40:5060 at Jul 29 22:44:13 (400 bytes):

ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-y2gm6ae7uqz8;rport
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>;tag=as2d735ef7
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snom320/8.7.5.17
Contact: <sip:[email protected]:5060>;reg-id=1
Content-Length: 0

Sent to udp:192.168.3.40:5060 at Jul 29 22:44:13 (1168 bytes):

INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-4d0pukyhiyao;rport
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snom320/8.7.5.17
Contact: <sip:[email protected]:5060>;reg-id=1
X-Serialnumber: 0004133594BC
P-Key-Flags: keys="3"
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Authorization: Digest username="32",realm="asterisk",nonce="1f7df19d",uri="sip:[email protected];user=phone",response="376a12a1910b187116553e51ae0d3a61",algorithm=MD5
Content-Type: application/sdp
Content-Length: 274

v=0
o=root 1629308898 1629308898 IN IP4 192.168.3.154
s=call
c=IN IP4 192.168.3.154
t=0 0
m=audio 64966 RTP/AVP 8 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:89LfllU/jXTCrrhUkJB+ByxgtCBW6onBwN1Y2Fnv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv

Received from udp:192.168.3.151:5060 at Jul 29 22:44:13 (482 bytes):

SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-4d0pukyhiyao;received=192.168.3.154;rport=5060
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>;tag=as2d735ef7
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.13.1~dfsg1-3+deb7u3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent to udp:192.168.3.40:5060 at Jul 29 22:44:13 (400 bytes):

ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.3.154:5060;branch=z9hG4bK-4d0pukyhiyao;rport
From: "32" <sip:[email protected]>;tag=ekpdaql4uv
To: <sip:[email protected];user=phone>;tag=as2d735ef7
Call-ID: 313433383230323635313231323135-rahdricb48me
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: snom320/8.7.5.17
Contact: <sip:[email protected]:5060>;reg-id=1
Content-Length: 0
 
Zuletzt bearbeitet:
Nein, Du hast nicht das gleiche Problem ;-)

We are requesting SRTP, but they responded without it!
Zum Vergrößern anklicken....

ist ja ziemlich eindeutig, die SRTP Einstellungen passen nicht zusammen. In Asterisk sip.conf ist das encryption=yes/no und im Snom etwas versteckt in den Identity Einstellungen. Entweder auf beiden Seiten ein, oder auf beiden Seiten aus.
 
Die IP-Telefone bzw. ATAs sind ja alles ziemliche Konfigurations-Monster, da verirrt sich ein IP-Anfänger schon mal bzw. sieht den Wald vor lauter Bäumen nicht mehr (zumal die Parameter bei einem SNOM 320 wieder anders heissen als bei einem Cisco SPA112).

Vielen Dank, jetzt geht's einwandfrei.
 
kurze halb-OT Anekdote:
Ich finde, die Konfigurationen sind nicht das Problem, wenn man sich die Zeit nimmt und Seite für Seite alle Einstellungen der Reihe nach durch geht. Was mir viel mehr zu schaffen macht sind die sich ändernden Standards, wie auch in diesem Beispiel. Bis FW 7.?? war SRTP per default aus, seit 8.?? ist es an. Aktualisiert man gleichzeitig auf Asterisk 11 hat man Glück, weil da nämlich encryption=yes auch neu Standard ist. Bleibt aber Asterisk bei 1.8 und man aktualisiert (so wie ich damals) die Firmware, gibt es plötzlich Probleme, also SRTP in den Telefonen ausgeschaltet. Danach Asterisk erneuert und wieder Probleme, gesucht und gefunden (dachte ich) in den Telefonen SRTP wieder an, damits zu Asterisk passt. Leider spielte das Patton Smartnode da aber nicht mit, deshalb ist SRTP entgegen allen Standards jetzt überall per Konfig aus.

Aber Du hast schon irgenwo Recht, ich bin ja auch nur eine Freizeit-VoIP-Bastlerin, also auch nicht immer auf dem neuesten Stand der Dinge, da kann man sich schon mal einen Wolf suchen wenn unerwartet irgendwas nicht klappt.
 
Moins

Wenn im Asterisk encryption=yes gesetzt ist,
kann ich zwar HD SRTP von PhonerLite zum SNOM 320 machen,
aber umgekehrt nicht.
Die SNOMs machen da irgendwas anders. :noidea:

Soll heissen:
PhonerLite HD SRTP --> SNOM = OK
SNOM HD SRTP --> PhonerLite = Not acceptable here

Als Codecs sind aLAW, uLAW und G.722 angegeben.

Deswegen bleibt encryption=yes aber hab es erstmal in den SNOMs deaktiviert.
Registrierungen bleiben davon verschont, und Unverschlüsselt geht trotzdem.
 
Hi,

gleiches Problem, wie bei lagerschaden (ebenfalls Askozia):

habe hier auch encryption=yes
SRTP beim Snom 360 aktiv: Rausrufen -> Not acceptable, Reinrufen kein Problem.

Aber es ist doch auf beiden Seiten aktiv :confused:

Das mit den Codecs (722/711) hat bei mir leider nicht funktioniert.


Gruß
Fabian
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 564 (Mitglieder: 11, Gäste: 553)

Neueste Beiträge

Statistik des Forums

Themen
246,274
Beiträge
2,249,293
Mitglieder
373,863
Neuestes Mitglied
RuthBeatty
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück