Call Abbruch

[patricio_ktn]

Hallo liebe Gemeinschaft,

Habe ein Problem und hoffe auf euren Input

Ein aktiver Call bricht mit folgender Fehlermeldung nach ca. 5-10 sec. ab !
Wo kann das Problem liegen ?

[Sep 24 10:38:31] WARNING[5166]: chan_sip.c:1981 retrans_pkt: Maximum retries exceeded on transmission SDfu94601-43aa667cc4ebfbc21dc4ac0bfb8deff7-06a1450 for seqno 1235 (Critical Response) -- See doc/sip-retransmit.txt.
[Sep 24 10:38:31] WARNING[5166]: chan_sip.c:2003 retrans_pkt: Hanging up call SDfu94601-43aa667cc4ebfbc21dc4ac0bfb8deff7-06a1450 - no reply to our critical packet (see doc/sip-retransmit.txt).

danke
patricio

 

[Thomas007]

Hast Du da mal wie vorgeschlagen reingeschaut und einen SIP debug gemacht?
doc/sip-retransmit.txt
Ich rate mal: Du benutzt einen kaputten SIP Proxy oder eine kaputte Firewall.

 

[patricio_ktn]

Hi,

Firewall ist keine dabei. Der Router übernimmt das NAT. SIP debug zeigt mir eben diesen outpunt ! Nach 20 sec ist schluss. Call disconnect !

 

[Thomas007]

Das was Du gepostest hast sieht aus wie aus dem log. SIP DEBUG sieht anders aus.

 

[patricio_ktn]

Du meinst das vielleicht ? Ich hab auch alle Varianten des NAT probiert - kein Erfolg. Kann meiner Meinung auch nicht sein ...


--- (11 headers 10 lines) ---
[Sep 27 10:07:23] WARNING[3684]: chan_sip.c:1981 retrans_pkt: Maximum retries exceeded on transmission SD8ebk501-9da84818b7667a93596473192b70ea1b-06a1450 for seqno 1235 (Critical Response) -- See doc/sip-retransmit.txt.
[Sep 27 10:07:23] WARNING[3684]: chan_sip.c:2003 retrans_pkt: Hanging up call SD8ebk501-9da84818b7667a93596473192b70ea1b-06a1450 - no reply to our critical packet (see doc/sip-retransmit.txt).
Scheduling destruction of SIP dialog '[email protected]' in 6528 ms (Method: INVITE)
set_destination: Parsing <sip:[email protected]:1927;rinstance=8b821441701cfebb> for address/port to send to
set_destination: set destination to 10.229.190.128, port 1927
Reliably Transmitting (NAT) to 10.229.190.128:1927:
BYE sip:[email protected]:1927;rinstance=8b821441701cfebb SIP/2.0
Via: SIP/2.0/UDP 10.229.190.211:5060;branch=z9hG4bK60c7f2b0;rport
From: "05066420745" <sip:[email protected]>;tag=as2613b407
To: <sip:[email protected]:1927;rinstance=8b821441701cfebb>;tag=d65fde45
Call-ID: [email protected]
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

 

[IEEE]

Ist das wieder die Centrex?

 

[patricio_ktn]

Ja so ist es !

 

[IEEE]

Ich weiß Du wolltest das schon in einem anderen Thread nicht hören. Ich sags auch zum letzten Mal, dann lass ich Dich in Ruhe damit ;-)

Ich glaube das Deine Chancen sehr schlecht sind hier eine saubere Anbindung zusammen zu kriegen. Wie in dem anderen Thread erwähnt haben wir uns (und zwar unterstützt von 2 Telekom Technikern wo einer sogar SIP Trace auf der Centrex mitgeschaut hat) über 2 Termine mit je etwa 8 Stunden hinweg versucht das hinzukriegen - ohne Erfolg. Es gar so gut wie alle Phänomene die man sich vorstellen kann, Gesprächsabbrüche, Probleme bei der Sip Authentifizierung, Durchwahlen konnten nicht signalisiert werden, und und und.

Mir wurde damals auch gesagt (das könnte sich aber mittlerweile geändert haben, ist schon etwa 6-8 Monate her) das das Produkt eigentlich nur mit Patton Abschluss (auf ISDN Ports) verkauft wird und offiziell nicht für die direkte Anbindung einer eigenen IP-PBX vorgesehen ist.

Witzigerweise läuft das Produkt jetzt mit einem Patton als Abschluss recht gut. Wir mussten dazu halt den Asterisk dann mittels ISDN Karte anbinden.

 

[patricio_ktn]

Hallo,

Danke dir für deinen Input. Ja ich kämpfe auch mit diesem Thema und hatte auch schon die entsprechenden Techniker am Rohr. Trotzdem Interessiert es mich, warum genau nach 20 sec. jedesmal schluss ist ..... Am SIP Trunk kann es nicht liegen, denn wenn ich 2 Calls mache - wird nur der eine nach 20 sec abgebrochen, der andere bleibt aufrecht (bis eben auch 20 sec. vorbei sind)

lg

 

[patricio_ktn]

Problem konnte gelöst werden. Beim Call Disconnect nach 20 Sec handelt es sich definitiv um ein NAT Problem. Nicht am Asterisk Server - sondern am Access-Router muss das NAT richtig konfiguriert sein !
Thread kann geschlossen werden