[PROBLEM] Snom 320/360 NAT bzw. STUN Probleme

[IEEE]

Hallo,

Folgendes Problem habe ich neuerdings mit einem Snom 320 und ein Kollege von mir hat exakt das gleiche Problem mit einem Snom 360. Es scheint auf einmal Probleme mit NAT Situationen zu geben, die ich mir schlicht nicht erklären kann.

Das ganze läuft so:
Snom (hinter einem NAT Router) ist übers WAN an einer Asterisk Anlage angemeldet. Am Snom ist ein STUN-Server eingetragen, am Asterisk ist nat=yes für den Account eingestellt. Zusätzlich wird am NAT-Router der 5060 Port direkt auf das Telefon forgewarded (Network Identity Port am Telefon auf 5060 fixiert). Ich bin mir auch ziemlich sicher, dass das alles schon funktioniert hat.

Seit kurzem fällt folgendes auf:
Bei eingehenden Anrufen zu dem Telefon klingelt es, wenn man abnimmt meint das Snom verbunden zu sein (Gesprächszeit läuft), beim Gegenüber läutet es aber nach wie vor (unendlich).
Bei ausgehenden Gesprächen funktioniert hingegen alles bestens.

Ich hab jetzt schon alles mögliche probiert, verschiedene STUN Server getestet, weitere Portforwardings eingestellt, auf STUN Server verzichtet, alles ohne Erfolg.

Besonders interessant finde ich die Traces.

Hier vom Telefon:

Received from udp:IP_ADRESSE_DES_ASTERISK:5060 at 1/9/2008 13:37:24:454 (806 bytes):

INVITE sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060 SIP/2.0
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK225a0367;rport
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as0bc3bcec
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>
Contact: <sip:10@IP_ADRESSE_DES_ASTERISK>
Call-ID: 52a1aed25cb6524134c47b007e1180d1@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
User-Agent: Cokomm CPBX
Max-Forwards: 70
Date: Mon, 01 Sep 2008 11:37:24 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 298

v=0
o=root 12257 12257 IN IP4 IP_ADRESSE_DES_ASTERISK
s=session
c=IN IP4 IP_ADRESSE_DES_ASTERISK
t=0 0
m=audio 18504 RTP/AVP 8 0 111 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

Sent to udp:IP_ADRESSE_DES_ASTERISK:5060 at 1/9/2008 13:37:24:488 (476 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK225a0367;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as0bc3bcec
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=vngun7kooi
Call-ID: 52a1aed25cb6524134c47b007e1180d1@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0

Sent to udp:IP_ADRESSE_DES_ASTERISK:5060 at 1/9/2008 13:37:24:692 (830 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK225a0367;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as0bc3bcec
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=vngun7kooi
Call-ID: 52a1aed25cb6524134c47b007e1180d1@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
User-Agent: snom320/7.1.35
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
Content-Type: application/sdp
Content-Length: 251

v=0
o=root 926361114 926361115 IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
s=call
c=IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
t=0 0
m=audio 10044 RTP/AVP 8 0 3 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Sent to udp:IP_ADRESSE_DES_ASTERISK:5060 at 1/9/2008 13:37:25:196 (830 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK225a0367;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as0bc3bcec
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=vngun7kooi
Call-ID: 52a1aed25cb6524134c47b007e1180d1@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
User-Agent: snom320/7.1.35
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
Content-Type: application/sdp
Content-Length: 251

v=0
o=root 926361114 926361115 IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
s=call
c=IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
t=0 0
m=audio 10044 RTP/AVP 8 0 3 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Sent to udp:IP_ADRESSE_DES_ASTERISK:5060 at 1/9/2008 13:37:26:197 (830 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK225a0367;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as0bc3bcec
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=vngun7kooi
Call-ID: 52a1aed25cb6524134c47b007e1180d1@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
User-Agent: snom320/7.1.35
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
Content-Type: application/sdp
Content-Length: 251

v=0
o=root 926361114 926361115 IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
s=call
c=IN IP4 EXTERNE_IP_DES_TELEFONS(NAT)
t=0 0
m=audio 10044 RTP/AVP 8 0 3 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

wie man sieht, schickt das Telefon immer wieder das OK, wenn abgehoben wird. Dieses kommt aber bei der Anlage nicht an.
Weil wenn man sich den Trace von der Anlage ansieht, sieht man das diese nach dem RINGING nichts mehr bekommt (letztendlich bis zum Abbruch wenn der Versuch beendet wird):

SIP Debugging Enabled for IP: EXTERNE_IP_DES_TELEFONS(NAT):5060

<-- SIP read from EXTERNE_IP_DES_TELEFONS(NAT):5060: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=x79og3noog
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


?--- (10 headers 0 lines) ---
?
<-- SIP read from EXTERNE_IP_DES_TELEFONS(NAT):5060: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=x79og3noog
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


?--- (10 headers 0 lines) ---
?
<-- SIP read from EXTERNE_IP_DES_TELEFONS(NAT):5060: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=x79og3noog
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


?--- (10 headers 0 lines) ---
?
<-- SIP read from EXTERNE_IP_DES_TELEFONS(NAT):5060: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=x79og3noog
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


?--- (10 headers 0 lines) ---
?
<-- SIP read from EXTERNE_IP_DES_TELEFONS(NAT):5060: 
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport=5060
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>;tag=x79og3noog
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 INVITE
Contact: <sip:112@INTERNE_IP_DES_TELEFONS(NAT):5060>;flow-id=1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


?--- (10 headers 0 lines) ---
?Scheduling destruction of call '1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK' in 32000 ms
Reliably Transmitting (NAT) to EXTERNE_IP_DES_TELEFONS(NAT):5060:
CANCEL sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060 SIP/2.0
Via: SIP/2.0/UDP IP_ADRESSE_DES_ASTERISK:5060;branch=z9hG4bK2ff4b4c1;rport
From: "michael" <sip:10@IP_ADRESSE_DES_ASTERISK>;tag=as7dfb8e96
To: <sip:112@EXTERNE_IP_DES_TELEFONS(NAT):5060>
Call-ID: 1955b24e5a140bed379dd30809fd85e7@IP_ADRESSE_DES_ASTERISK
CSeq: 102 CANCEL
User-Agent: Cokomm CPBX
Max-Forwards: 70
Content-Length: 0

Zu erwähnen wäre noch, dass die Anlage ansonsten bestens funktioniert.

Hat jemand eine Idee, woran das liegen könnte - bzw. hatte jemand schon einmal ein ähnliches Problem?

 

[IEEE]

Wollte noch ergänzen: Wird in besagtem privaten Netz das Snom durch ein Siemens oder ein Softphone ersetzt, funktioniert alles bestens.

 

[Ottone]

Entweder nat=yes entfernen (mein Rat), oder im SNOM die Unterstützung für STUN abschalten, beides zusammen ist nicht gut.

Ich vermute Du und Dein Kollege, ihr habt jeweils einen eigenen NAT Router - wenn nicht, wenn Ihr also mit dem selben arbeitet, dann muss eines Eurer Telefone auf z.B. port 5061 umgestellt werden zusammen mit einem passenden port forward.

Generell: Hast Du das SNOM auf seinem dynamischen SIP port gelassen, oder als "Netzwerkidentität (port)" manuell 5060 eingetragen?

 

[IEEE]

Hallo,

Ich hab das wohl schlecht formuliert - mein Kollege sitzt nicht hier neben mir, er ist an einem gänzlich anderen Standort und hat dort das selbe Problem.

Das Snom hab ich fix auf Network Identiy 5060 eingestellt.

Werde jetzt mal die verschiedenen Kombinationen aus nat=yes und Stun am Snom ausprobieren.

Danke!

 

[Timmbo]

Hi,

hast Du mal versucht "Almoststun" zu ändern?
Expertenmenü--Sonstiges.

Grüße
Timm

 

[IEEE]

Davor werd ich mich hüten, wenn ich das mache, funkt der Asterisk auf einmal auch mit seiner internen IP in der Gegend rum, was mir vermutlich dutzende Probleme mit anderen Gegenstellen (speziell den Providern) einbringen würde.

 

[IEEE]

Seit eben funktioniert es übriges. Ich habe spaßeshalber mal das Snom via Network Identity Port auf 5061 umgestelltn. stunserver ist nach wie vor eingetragen, nat=yes am Server ist auch noch aktiv (Portforwarding am Router hab ich ebenfalls auf 5061 geändert).
Seit dieser Umstellung auf 5061 funktioniert alles.

Ist mir ein Rätsel und befriedigt mich auch nur als Zwischenlösung. Es gib nämlich aus meiner Sicht schlicht keinen Grund, warum es nicht mit dem Standardport funktioniert (tut es ja mit dem siemens auch).

Sehr strange.

 

[Timmbo]

Hi,

also hast Du ihn aktiviert.
Das stimmt nicht immer, denn es gibt router die als SIP-proxy arbeiten, da muss Almoststun deaktivert sein. Ich hatte schon Fälle da musste es deaktiviert werden damit z.B. ENUM gefunzt hat.
Das mit port 5061 kann eigentlich nur den Grund haben, dass der Router 5060 für sich selbst reserviert. Hat der Router einen Telefonanschluss?

Grüße
Timm

 

[IEEE]

Der Router ist ein Lancom-1721 (ohne jegliche Voip Funktionen). Ich denke zudem nicht, dass dieser in den Verkehr auf Port 5060 eingreift, weil dann würde ja die Signalisierung (Telefon bimmelt ja) an sich schon nicht funktionieren. Zudem funktioniert es ja mit einem Softphone bzw. mit einem Siemens auch mit dem Standard Port.

Wie gesagt, erklären kann ich es mir nicht.

Witziges Detail noch zu meinen Sip-Traces oben:
Wie man sieht, kann die Anlage das OK vom Telefon wenn der Teilnehmer abhebt, nicht empfangen. Wenn aber eben dieser Teilnehmer dann genug vom Testen hat und das klingeln mit der Cancel Taste beendet, dann bekommt die Anlage die CANCEL Nachricht durchaus und der Anrufer bekommt das typische Besetzt-Zeichen wie wenn man halt weggedrückt wird.

 

[Ottone]

Beachte meinen ersten Satz in Beitrag #3 - dass es z.T. mit beiden settings funktioniert heisst nicht dass dies eine gute Idee ist. ;-)

 

[IEEE]

Hallo nochmal,

Jetzt kommt nochmal Schwung in die Sache:

Wie berichtet habe ich das Problem mit dem umstellen auf Port 5061 ja bereits als gelöst betrachtet. Ich habe das 20 mal durchgetestet und zwar in dem ich das Telefon via Webinterface auf "Auto Answer" gestellt habe (weil das dortige Büro grade nicht besetzt war) und beobachtet habe, ob die Verbindung zustande kommt - und das kam sie letztendlich. Damit war ich zufrieden.

Nun ist das Büro wieder besetzt und es zeigt sich, dass das Verhalten das selbe ist wie vorher, wenn ein Mensch abhebt.

Sprich:
- Ohne aktiviertes Auto-Answer: Ich rufe an, der Anrufer hebt ab, die Gesprächszeit beginnt bei ihm zu laufen. Er hört nichts und bei mir klingelt es ewig weiter (das CANCEL wenn es ihm dann reicht kriege ich witzigerweise).

- Mit aktiviertem Auto-Answer: Ich rufe an, das Telefon hebt sofort ab, ich höre die Bürogeräusche. Mitarbeiter nimmt den Hörer ab und wir können sprechen.

- Der umgekehrte Weg (das betreffene Büro ruft mich an) funktioniert problemlos.

Ist doch strange, oder?

Der Vollständigkeit halber sei gesagt, dass an dem Telefon ein Headset hängt. Das Verhalten zeigte sich beim Testen aber sowohl beim abheben mittels Headset und OK Taste als auch bei Abheben mittels Telefonhörer gleich.

Da ich mir gedacht habe, dass vielleicht irgendeine Einstellung verstellt ist, habe ich einen Factory-Reset auf dem Telefon gemacht und alles nochmal von vorn eingestellt. Ohne Erfolg.

 

[DrSnyder]

Problem mit Snom 320hinter NAT an Asterisk hinter anderem NAT

Hallo,

ich habe ein ziemlich ähnliches, bzw. das gleiche Problem dass hier im Thread angesprochen wird. Deshalb würde es mich interessieren, ob es mittlerweile eine Lösung dafür gibt.

Meine Anlage sieht folgendermaßen aus:

Zuhause: FBF7170 an ISDN Anschluss. Darauf läuft ein Asterisk der meine ISDN Leitungen über Sip extern verfügbar macht.

Büro: Aus dem Büro Netz versuche ich mit Voip Geräten auf meinen Asterisk über Dyndns zuzugreifen

1. Mit einer Fritz!box Fon, alles funktioniert. Ich kann anrufen und angerufen werden. Sprache und Signale werden einwandfrei übertragen

2. mit einem Snom 320, Anrufen funktioniert. Ankommende anrufe werden Signalisiert. Wenn ich den Hörer abnehme bleibt die Leitung tot. Der Anrufende hat weiterhin ein Freizeichen. Lege ich am Snom auf, erhält der Anrufende ein Besetztzeichen.

Da ich Asterisk auf der Fritzbox verwende, verwende ich untypische Ports, d.h. anstelle von UDP 5060 verwende ich 5061, und für RTP verwende ich UDP 9078-9097. Diese sind in der Fritz!box auch alle entsprechend weitergeleitet. Da sowohl die externe Verbindung mit der zweiten Fritz!box, als auch mit Phoner funktioniert, gehe ich davon aus, dass mein Problem über einstellungen am Snom zu lösen sein sollte.

Meine Konfiguration sieht folgendermaßen aus:

;
; RTP Configuration
;
[general]
;
; RTP start and RTP end configure start and end addresses
;
; Defaults are rtpstart=5000 and rtpend=31000
; fritzbox voipd uses 7078-7097 (see ar7.cfg)
rtpstart=9078
rtpend=9097
;
; Whether to enable or disable UDP checksums on RTP traffic
;
;rtpchecksums=no
;
; The amount of time a DTMF digit with no 'end' marker should be
; allowed to continue (in 'samples', 1/8000 of a second)
;
;dtmftimeout=3000

[general]
context=default
bindport=5061
bindaddr=0.0.0.0
externhost=meinrechner.dyndns.net
;externip=meinrechner.dyndns.net
externrefresh=10
;rtcachefriends=yes

srvlookup=yes                        ; Enable DNS SRV lookups on outbound calls
language=de
localnet=192.168.0.0/255.255.255.0

;canreinvite=no
disallow=all
allow=alaw
rtpkeepalive=5   ; alle 5 Sekunden Keep-Alive-Pakete senden

; --------------------------------------------------------------------
;
; hier kommen die Anmeldekontexte für die SIP Endgeraete 30-39
;

[30]
callerid=Snom <30>
host=dynamic
domain=meinrechner.dyndns.net
user=30
secret=streng_geheim
type=friend
mailbox=30
nat=yes
qualify=no
canreinvite=no

Vielen Dank für hilfreiche Tips

 

[DrSnyder]

Hallo,
leider bin ich mit meinem Problem bisher nicht wirklich weitergekommen. Mir ist mittlerweile aufgefallten, dass mein Snom versucht Daten an Port 5060 meines servers zu schicken. Leider Landen die Daten dann aber in der Fritzbox und nicht auf meinem Asterisk, der auf Port 5061 lauscht.

zur verdeutlichung ein paar schnipsel meines Sip-Protokolls:

Erfolgreiche Anmeldung des Telefons am Asterisk über Port 5061

Sent to udp:asterisk_ip:5061 at 31/1/2010 14:32:31:878 (796 bytes):

REGISTER sip:asterisk.dyndns.net:5061 SIP/2.0
Via: SIP/2.0/UDP snom_ip:5063;branch=z9hG4bK-bwbv62eagfdp;rport
From: "30" <sip:[email protected]:5061>;tag=szl294ujqj
To: "30" <sip:[email protected]:5061>
Call-ID: 3c2670798f22-a2ddd4es2wk1
CSeq: 465 REGISTER
Max-Forwards: 70
Contact: <sip:30@snom_ip:5063>;reg-id=1;q=1.0;audio;mobility="fixed";duplex="full";description="snom320";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom320/7.3.30
Allow-Events: dialog
X-Real-IP: 192.168.0.30
Authorization: Digest username="30",realm="asterisk",nonce="597c0587",uri="sip:asterisk.dyndns.net:5061",response="4bbc83beb2e5f6581596c06112184109",algorithm=MD5
Expires: 30
Content-Length: 0

Received from udp:snom_ip:5061 at 31/1/2010 14:32:32:179 (538 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP snom_ip:5063;branch=z9hG4bK-bwbv62eagfdp;received=snom_ip;rport=5063
From: "30" <sip:[email protected]:5061>;tag=szl294ujqj
To: "30" <sip:[email protected]:5061>;tag=as413dfcee
Call-ID: 3c2670798f22-a2ddd4es2wk1
CSeq: 465 REGISTER
User-Agent: Asterisk PBX 1.6.0.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Expires: 60
Contact: <sip:30@snom_ip:5063>;expires=60
Date: Sun, 31 Jan 2010 13:32:31 GMT
Content-Length: 0

Danach der erfolglose Versuch den Status an den Asterisken zu melden. Diesmal an Port 5060

Sent to udp:Asterisk_ip:5060 at 31/1/2010 14:32:33:431 (572 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP Asterisk_ip:0;branch=z9hG4bK3eab9a30;rport=5061
From: "asterisk" <sip:asterisk@Asterisk_ip:5061>;tag=as5fb01af7
To: <sip:30@Asterisk_ip:5063>
Call-ID: 6359e4d91aad483974ff23ea2be72439@Asterisk_ip
CSeq: 102 OPTIONS
Contact: <sip:[email protected]:5063>;reg-id=1
User-Agent: snom320/7.3.30
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Content-Length: 0

Wenn ich mit dem Snom Anrufe funktioniert nach wie vor alles wunderbar. Bei eingehenden Anrufen besteht das Problem, das das Snom wieder versucht über Port 5060 zu kommunizieren.

Ich finde einfach nicht die Einstellung, wo ich dem Snom das abgewöhnen könnte.

Ich hoffe weiterhin auf einen Guten Ratschlag

 

[Ottone]

Prüfe folgendes:

- im SNOM unter register "fritz.dyn.org" und unter proxy "fritz.dyn.org:5061" eintragen
- wenn das nicht hilft: im SNOM stun bzw. ICE abschalten sofern nicht bereits geschehen

Übrigens: Asterisk sollte besser auf 5062 UDP lauschen, denn die ungeraden ports wie 5061 sind eigentlich für SIP über TCP gedacht (hat aber nichts mit Deinem Problem hier zu tun).

Hinweis: Phoner hat explizit Toleranz gegenüber dem nicht völlig korrektem Verhalten des SIP Proxy/Registrar der Fritz!Box eingebaut

 

[DrSnyder]

Hallo Ottone,

danke für deine Vorschläge.

Ich hatte bisher unter register "fritz.dyn.org:5061" und unter proxy "fritz.dyn.org:5061" eingetragen. Ich habe das jetzt entsprechend deinem Hinweis angepasst. Leider ändert sich dadurch nichts.
Ebenso habe ich bisher keinen Unterschied feststellen können wenn Ich einen Stun Server eingetragen hatte (stun.gmx.net) oder nicht.

Ich werde auch mal ausprobieren den Asterisk auf Port 5062 "umzuziehen", auf 5061 liegt er weil das hier in den meisten tutorials so vorgeschlagen wurde.

Deinen Hinweis verstehe ich nicht ganz, denn eigentlich hat mein asterisk ja gar nichts mit dem SIP Proxy/Registrar der Fritz!Box zu tun, ausser dass ich auf einen anderen Port ausweichen muss.

 

[Ottone]

Dann probiere einmal "fritz.dyn.org" durch die IP zu ersetzen. Ist nicht schön und verkompliziert die Sache, könnte aber durchaus helfen.

Zu port 5061: Ich schrieb oben "hat aber nichts mit Deinem Problem hier zu tun".

Des log snippet oben mit dem OPTIONS Paket ist nicht vollständig, Du solltest auf jeden Fall die vorhergehende Anfrage Deines Asterisk mit hinzufügen.

Schliesslich: Wenn von Deiner IP aus mehrere Geräte an Deinem Asterisk angemeldet sind, dann könnte dies der Grund für das Durcheinander sein (Stichwort "match on IP not username". Sorge in diesem Fall dafür, dass nur das SNOM aktiv ist.

 

[DrSnyder]

Hallo Ottone,

der vollständige "dialog" sieht so aus:

Received from udp:Asterisk_ip:5061 at 31/1/2010 19:08:53:967 (526 bytes):

OPTIONS sip:[email protected]:5063 SIP/2.0
Via: SIP/2.0/UDP Asterisk_ip:0;branch=z9hG4bK43490fce;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@Asterisk_ip:5061>;tag=as604a75fe
To: <sip:[email protected]:5063>
Contact: <sip:asterisk@Asterisk_ip:5061>
Call-ID: 1063e2c041ce015d46fee3235fd20125@Asterisk_ip
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.6.0.1
Date: Sun, 31 Jan 2010 18:08:53 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0

Sent to udp:Asterisk_ip:5060 at 31/1/2010 19:08:53:978 (572 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP Asterisk_ip:0;branch=z9hG4bK43490fce;rport=5061
From: "asterisk" <sip:asterisk@Asterisk_ip:5061>;tag=as604a75fe
To: <sip:[email protected]:5063>
Call-ID: 1063e2c041ce015d46fee3235fd20125@Asterisk_ip
CSeq: 102 OPTIONS
Contact: <sip:[email protected]:5063>;reg-id=1
User-Agent: snom320/7.3.30
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Content-Length: 0

ich habe versucht die dyndns Adresse durch die externe ip zu ersetzen. Das hat nichts gebracht. Des weiteren habe ich dafür gesorgt, dass sich das Snom als einziges Gerät anmeldet, leider hat auch das nichts gebracht.

Zum Scluss habe ich das Snom an der internen ip des Asterisk angemeldet. das funktioniert . Jetzt versucht das Snom auch nicht mehr Daten an Port 5060 zu senden. Leider bringt mir das nicht viel, da ich das Snom ja eigentlich von ausserhalb nutzen will.

Zu deinem Port 5061 Hinweis: ich hatte schon gelesen, dass du geschrieben hast, das habe nichts mit meinem Problem zu tun. Dennoch werde ich das ändern. Wenn es da eine Regel gibt kann man sich da ja dran halten.

 

[DrSnyder]

Hallo Ottone,

es scheint als würde es jetzt funktionieren.
Ich habe in der sip.conf
externhost=asterisk.dyndns.org:5062
eingetragen. Vorher hatte ich den Port nur bei Bindport = 5062 angegeben.

Ich habe den Port auch auf 5062 geändert, was natürlich wie von dir vorhergesehen nichts gebracht hat.

Wenn ich mir auf der Asterisk Konsole mit "Sip show peer 30" meinen Peer ansehe gibt es die Zeile:

Defaddr->IP : 0.0.0.0 Port 5060
kann man das über die Sip.conf beeinflussen bzw. was heisst das? Google bringt einen zur Ausgabe von "sip show peer" leider gar nicht weiter.

Auf jedenfall bisher danke für deine Hilfe.

 

[Ottone]

Also Dein SNOM ist gar nicht "weit weg", sondern im gleichen LAN wie der Asterisk und Du testest aber mit der öffentlichen IP? Das ist keine gute Voraussetzung und nicht aussagekräftig, der SIP Registrar der Fritz!Box ist da recht eigen - und über die Konfiguration und das Routing des embedded Asterisk kann ich nichts sagen.

Also: Deine Testumgebung mag ein Teil des Problems sein.

 

[Ottone]

Ja, nur "bindport=" reicht hier nicht aus.

Die "default ip" ist nicht wirklich wichtig für Dich, sie hat eine etwas andere Funktion als Du denkst, stark verkürzt: "Ist der host nicht auffindbar, dann versuche es hier".

Schliesslich: Es ist aus verschiedenen Gründen nicht klug das snom "30" zu nennen. Mindestens das erste Zeichen sollte ein Buchstabe sein.