netzwerkzusammenbruch nach User-User-Telefonat

[Artimis]

Moin Leute,

ich habe ein merkwürdiges Problem:
Wenn ich über meinen Asterisk (1.4, eingerichtet mit Asterisk-GUI) mit dem "Server" telefoniere (VoiceMenu, Mailbox), klappt alles wunderbar.

Wenn ich aber mit einem Menschen telefoniere, egal, ob über Trunk oder direkt per SIP, ob eingehen oder ausgehend, klingelt es zwar, das Gespräch kann angenommen werden, die Endgeräte melden, dass die Verbindung steht, es wird aber kein Pieps übertragen und nach wenigen Sekunden bricht das Ganze zusammen.
Der Witz: Danach ist der komplette vServer absolut nicht erreichbar. Kein Protokoll, nicht mal SSH. Und nach ca. 30min geht alles wieder, der eine Benutzer ist jedoch dauerhaft als "Busy" gemeldet.
Ich habe schon alles versucht, sogar das System Wind00f-Dummi-like geplättet: Keine Chance.
Der Witz: Früher ging alles wunderbar.

Die CLI sagt dazu:

[Jan 14 15:48:10] WARNING[13533]: app_dial.c:1202 dial_exec_full: Unable to create channel of type 'IAX2' (cause 3 - No route to destination)
    -- SIP/1000-08a5c230 is ringing
    -- SIP/1000-08a5c230 answered SIP/1001-08a4c360
    -- Packet2Packet bridging SIP/1001-08a4c360 and SIP/1000-08a5c230
[Jan 14 15:48:30] WARNING[27025]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission ZmUzODViNGNhY2VhMzJhYTYzNDhkZTU1ZDA3Yjc1Y2U. for seqno 2 (Critical Response)
[Jan 14 15:48:30] WARNING[27025]: chan_sip.c:1972 retrans_pkt: Hanging up call ZmUzODViNGNhY2VhMzJhYTYzNDhkZTU1ZDA3Yjc1Y2U. - no reply to our critical packet.
  == Spawn extension (DLPN_Extern, 1000, 1) exited non-zero on 'SIP/1001-08a4c360'

nach dem Bridging ist Sense mit dem Server:

    -- Packet2Packet bridging SIP/1001-08a4c360 and SIP/1000-08a5c230

Bitte! Kann mir da wer helfen?

 

[Ralph*]

Woher kommt denn:

Unable to create channel of type 'IAX2'

Eigentlich geht es doch um SIP?

 

[Artimis]

Hi Ralph,
danke für die Antwort.

Das hat nichts zu sagen.
Der User ist so angelegt, dass sowohl SIP als auch IAX akzeptiert und eben auch probiert werden.

Ist nur ein IAX-Gerät angemeldet, kommt das gleiche mit "SIP".
Ist beides angemeldet, kommt nichts.
Ist keines angemeldet, kommt beides.



Ich habe eben noch was in der /var/log/asterisk/messages gefunden:

[Jan 15 02:01:10] WARNING[2216] chan_sip.c: Maximum retries exceeded on transmission 3470220388@192_168_0_12 for seqno 3 (Critical Response) -- See doc/sip-retransmit.txt.
[Jan 15 02:01:10] WARNING[2216] chan_sip.c: Hanging up call 3470220388@192_168_0_12 - no reply to our critical packet (see doc/sip-retransmit.txt).

Der Verweis auf das Doc stellt sich aber als fiese heraus:
Ein Lehrtext, was SIP überhaupt ist, nichts wirklich Hilfreiches.

Kennt da vielleicht wer den Fehler?


Edit: Mir fällt gerade auf, dass in der Transmissions-ID die Netzwerk-interne IP des Telefons angezeigt wird. Die Telefonie sollte aber durchs Netz gehen.
"Denkt" Asterisk vielleicht, er solle die 182.168.0.12 anwählen statt der externen IP meines Internetanschlusses?
Wie kann ich das Lösen? STUN?

 

[Ralph*]

Ist nur ein IAX-Gerät angemeldet, kommt das gleiche mit "SIP".

Verstehe...

Ich habe zwar nicht wirklich eine Idee, aber such doch mal nach "Maximum retries exceeded"

Ich habe im Forum etwas gefunden... vielleicht passt es ja für Dich?

Wie hast Du denn reinvite konfiguriert?

Ralph

 

[Artimis]

Hallo Ralph,

ich bin inzwischen weite gekommen.
Anscheinent liegt das doch am Endgerät: Siemens Gigaset C475IP.
Wenn ich es deaktiviere, kann ich mit X-Lite und meinem Sipgate-Traunk problemlos telefonieren.
Von meinem vServer-Betreiber habe ich den Tip bekommen, dass die Firewall bei ungültigen Packeten eine temporäre Sperre verhängt, daher wohl die Nichterreichbarkeit des Servers nach einem Telefonat.
Ich schätze, das ungültige Packet ist falsch Adressiert, da ja an die interne IP.

Ich habe mal "sip set debug peer 1000" in die CLI gehämmert:

<--- SIP read from UDP://87.122.169.32:32768 --->



<------------->

<--- SIP read from UDP://87.122.169.32:32768 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 78.46.117.97:5060;branch=z9hG4bK56342ea9;rport=5060
From: "Christopher Kleen" <sip:[email protected]>;tag=as46370635
To: <sip:[email protected]:32768>;tag=3802069377
Call-ID: [email protected]
CSeq: 102 INVITE
Contact: <sip:[email protected]:32768>
Supported: replaces
Allow-Events: message-summary, refer
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 200

v=0
o=1000 34722 14 IN IP4 87.122.169.32
s=Mapping
c=IN IP4 87.122.169.32
t=0 0
m=audio 34722 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

<------------->
--- (12 headers 10 lines) ---
Found RTP audio format 0
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - 0x6 (gsm|ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 87.122.169.32:34722
list_route: hop: <sip:[email protected]:32768>
set_destination: Parsing <sip:[email protected]:32768> for address/port to send to
set_destination: set destination to 87.122.169.32, port 32768
Transmitting (NAT) to 87.122.169.32:32768:
ACK sip:[email protected]:32768 SIP/2.0
Via: SIP/2.0/UDP 78.46.117.97:5060;branch=z9hG4bK790653b6;rport
Max-Forwards: 70
From: "Christopher Kleen" <sip:[email protected]>;tag=as46370635
To: <sip:[email protected]:32768>;tag=3802069377
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.0.20
Content-Length: 0


---
    -- SIP/1000-00000007 answered SIP/1001-00000006
    -- Packet2Packet bridging SIP/1001-00000006 and SIP/1000-00000007

Reinvite habe ich momentan auf "off". Mit "on" ist es aber das selbe.

Danke für den Tip mit dem anderen Threat. Das klingt ähnlich, ich werde es gleich mal druchsehen.

 

[Ralph*]

daher wohl die Nichterreichbarkeit des Servers nach einem Telefonat.

Klingt logisch!

Viel Erfolg bei der Problemlösung...

Ralph

 

[Artimis]

Cool^^

Ich habe eben einfach mal, einer Eingebung folgend, folgendes in der Shell meines Servers gemacht:

ping 192.168.0.12

=> Netztrennung
Da scheint iwie die Firewall bei Ping auf Class-C-Netzwerke eine Sperre des gesamten Traffics reinzuhauen :blonk:

Mal sehen, was die da vom Support treiben.


Ooookay.
Dann folgt das nächste Problem, rasultierend darauf:

Wie kriege ich mein Siemens C475IP dazu, dem Server nicht die interne IP des Heimnetzwerkes sondern die externe IP desselben mitzuteilen?