Maximum retries exceeded on transmission

[VOIPdani]

Hallo!

Folgendes Warning taucht bei mir in den Logs auf:

Feb 23 09:16:35 VERBOSE[26506] logger.c:     -- Accepting voice call from '66480xxxxxx' to '9144' on channel 0/1, span 2
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Executing Macro("Zap/4-1", "SIPisdnamt|WahW")
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Executing SetCallerID("Zap/4-1", "0066480xxxxxx") in new stack
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Executing Dial("Zap/4-1", "SIP/WahW|60|tr") in new stack
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Called WahW
Feb 23 09:16:35 WARNING[26521] chan_sip.c: [B]Maximum retries exceeded on transmission [email protected] for seqno 102 (Critical Request)
Feb 23 09:16:35 WARNING[26521] chan_sip.c: Hanging up call [email protected] - no reply to our critical packet.[/B]
Feb 23 09:16:35 VERBOSE[30164] logger.c:   == No one is available to answer at this time (1:0/0/0)
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Executing Goto("Zap/4-1", "r-NOANSWER|1") in new stack
Feb 23 09:16:35 VERBOSE[30164] logger.c:     -- Goto (macro-SIPisdnamt,r-NOANSWER,1)
Feb 23 09:16:35 NOTICE[26521] sched.c: Attempted to delete nonexistent schedule entry 19178!

Der fett markierte Teil führt dazu dass der Anruf zwar durchgestellt wird, aber ein Telefonat dann nicht möglich ist.

Hat jemand von euch eine Idee wie dieses Warning zustande gekommen ist?

lg Dani

 

[VOIPdani]

Kennt denn niemand dieses Warning?

Bei meinem * tritt dieser Fehler immer noch auf und ich weiß absolut keine Lösung dafür.

Wie kann ich dieses Problem beheben??

 

[speedy1980]

Ein paar Infos über den Netzwerkaufbau wären hilfreich. Testsystem oder Produktivsystem bei Dir? Was für ein SIP-Telefon wird verwendet? Gibt es eine Firewall zwischen Telefon und Asterisk? Was sagt "sip show peers" auf der Asterisk-CLI?

 

[VOIPdani]

1) SIP-Telefon: SJPhone
2) Nein
3) Sip show peer zeigt

asterisk*CLI> sip show peer WahW
asterisk*CLI>

  * Name       : WahW
  Secret       : <Set>
  MD5Secret    : <Not set>
  Context      : FIRMAINTERN
  Subscr.Cont. : <Not set>
  Language     : de
  AMA flags    : Unknown
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup    :
  Pickupgroup  :
  Mailbox      :
  VM Extension : asterisk
  LastMsgsSent : -1
  Call limit   : 0
  Dynamic      : Yes
  Callerid     : "WahW" <9144>
  Expire       : 35684
  Insecure     : no
  Nat          : Always
  ACL          : No
  CanReinvite  : Yes
  PromiscRedir : No
  User=Phone   : No
  Trust RPID   : No
  Send RPID    : No
  DTMFmode     : rfc2833
  LastMsg      : 0
  ToHost       :
  Addr->IP     : 172.21.1.105 Port 5060
  Defaddr->IP  : 0.0.0.0 Port 5060
  Def. Username: WahW
  SIP Options  : (none)
  Codecs       : 0xc (ulaw|alaw)
  Codec Order  : (alaw,ulaw)
  Status       : OK (1 ms)
  Useragent    : SJphone/1.60.289a (SJ Labs)
  Reg. Contact : sip:[email protected]:5060

Kannst du mir mit diesen Infos vielleicht weiterhelfen?

lg Dani

 

[speedy1980]

Hmmmmm - SJPhone ist auch bei mir schon ein problematischer Kandidat gewesen. Sieht soweit alles gut aus, aber SJPhone reagiert nicht richtig auf den einkommenden Anruf. Ist vielleicht eine Firewall auf dem SJPhone Rechner drauf? WinXP Firewall, Zonealarm oder unter Linux irgendetwas? Ansonsten kannst Du mal "qualify=no" in der sip.conf für den SJPhone Account setzen (danach "sip reload" nicht vergessen). Ein anderes Softphone geht sicherlich ohne Probleme. Kennst Du X-Lite?
Wenn das nicht hilft, dann kommen wir nur mit einem SIP-Debug weiter.
"sip debug peer WahW", und dann die Ausgaben hier rein.

 

[VOIPdani]

Danke für deine Antwort. Ich werd mal ein anderes Softphone ausprobieren und schaun was passiert.

lg Dani

 

[speedy1980]

http://www.xten.com/index.php?menu=download

 

[HobbyStern]

Was macht die Diagnose ?

Stolpere zZt. über exakt den selben Fehler, habe auch keine Begründung, allerdings bei Hardphones - Snom 320.

chan_sip.c:1210 retrans_pkt: Maximum retries exceeded on transmission

geschlossener Bug bei Digium - aber nur für Cisco (und da auch nur ein FW Bug)
http://bugs.digium.com/view.php?id=5336

Ansonsten nix relevantes.

Hat jemand nähere Hilfe?

 

[HobbyStern]

Hat niemand eine Idee oder ähnliches erlebt ?

Dieser Fehler tritt eigentlich recht häufig auf, wie die Auswirkungen auf das Telefonat nach dem Update von *,Zap und mISDN sind weiss ich nun nicht, weg ist der Fehler aber keinesfalls :-(

CLI Output sieht so aus :

Ausgehendes Gespräch (SIP)

    -- SIP/pbx1-2256 answered SIP/41-0de2
    -- Attempting native bridge of SIP/41-0de2 and SIP/pbx1-2256
Apr  3 14:34:34 WARNING[2505]: chan_sip.c:1210 retrans_pkt: Maximum retries exceeded on transmission 3c2783d172bf-0ubijuwmg5aa@snom320-000413240C5B for seqno 2 (Critical Response)

 

[VOIPdani]

Also bei mir ist die Fehlermeldung verschwunden als ich die Dialplan Hints aus meiner extensions.conf entfernt habe. Ich weiß nicht ob das ein generelles Problem der Dialplan Hints ist, oder ob es nur bei mir eins war.

Vielleicht hilft dir das weiter?!

 

[HobbyStern]

Danke erstmal für Deine Antwort,

nun ja, das wäre natürlich eine Lösungsidee, hätte nur den Nachteil das ich dann auf meinen Snoms nicht mehr verfolgen kann was und wo klingelt .

Ich meine wenigstens das die hints elementar waren (alls ich mir das mal zusammen geschrieben habe)

Welche Endgeräte hast Du im Einsatz ?

Interessant wäre ja auch : WAS für ein WARNING ist das ?


Beste Grüße,

Stefan

 

[VOIPdani]

Welche Endgeräte hast Du im Einsatz ?

Ich benutze das Softphone SJPhone.

Interessant wäre ja auch : WAS für ein WARNING ist das ?

Das würde mich auch mal interessieren...aber bei mir ist es halt so: tritt das Warning nicht mehr auf, dann kümmere ich mich auch nicht mehr darum, weil in der Zwischenzeit sicher wieder ein neues Warning aufgetreten ist um das ich mich kümmern muss...

 

[HobbyStern]

tritt das Warning nicht mehr auf, dann kümmere ich mich auch nicht mehr darum, weil in der Zwischenzeit sicher wieder ein neues Warning aufgetreten ist um das ich mich kümmern muss...:wink:

:meinemei: und Recht haste !

 

[olaf_TT]

Moin,

ich habe an einer Maschine auch immer diesen tollen Fehler:

    -- Called 66
Sep  8 17:34:56 WARNING[2888]: chan_sip.c:1294 retrans_pkt: Maximum retries exceeded on transmission [email protected] for seqno 102 (Critical Request)
Sep  8 17:34:56 WARNING[2888]: chan_sip.c:1311 retrans_pkt: Hanging up call [email protected] - no reply to our critical packet.
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing VoiceMail("SIP/69-09f4", "66") in new stack
    -- Playing 'vm-intro' (language 'de')

Hatte dieses Prob nie mit der 1.0.9 die bisher in der Maschine lief.
Seit Update auf 1.2.7.1-BRIstuffed-0.3.0-PRE-1p sind diese Fehler sporadisch da.
Als Client haben wir auch SJPhone.
Der Ruf wird auch auf dem Phone signalisiert und geht dann sofort in die Mailbox.

Was kann das sein?
Habt ihr es gelöst?

Hints habe ich keine.

Gruß
Olaf

 

[HobbyStern]

Problem immer noch : Ja, Häufigkeit : 1-2mal am Tag.
Problem konnte auch nicht reproduziert werden, hat aber bei mir mW keine Auswirkungen auf die Qualität oder das Verhalten eines Anrufers.

Daher als belanglos abgetan.


Beste Grüße,

Stefan

 

[olaf_TT]

Danke für deine Antwort, aber so ganz belanglos ist das bei mir leider nicht, da ich vor meinem Rechner sitze, sehe das ein Ruf reinkommt, und dieser durch den Fehler direkt auf die Mailbox geleitet wird...
Und das ist unschön, da der Anrufer ja nun denkt das ich nicht da bin!

Gruß
Olaf

 

[HobbyStern]

Google spuckt einiges dazu aus , zB :

In Verbindung mit Cisco Telefonen :
http://bugs.digium.com/view.php?id=5336


Weiter zu einer (alten?) Problematik in 1.2
http://bugs.digium.com/view.php?id=7376


Hier ein gelöster Ansatz mit einem Fehler im Netzwerk (für mich belanglos)
http://www.ip-phone-forum.de/showthread.php?t=105547

Mehr bei GOOGLE (4 Seiten)

Ansonsten :

Beschreib doch mal was bei Dir los ist - s.h. configs - netzwerkaufbau - versionen usw usf

ggf. kann man das ganze ein wenig eingrenzen ?

Grüsse, Stefan

 

[HobbyStern]

Ein Reply auf ein sehr altes Thema.

Aber ich habe eine gute Lösung für mich gefunden :

 The specific change that causes this problem is in sip_answer() in
chan_sip.c:

res = transmit_response_with_sdp(p, "200 OK", &p->initreq, 2);

Changing the 2 to a 1 will probably fix it.  Note that this is NOT a bug in
* but improper implementations--either caused by latency, or a software bug
(not sending an ACK).  Perhaps it might be beneficial to have an option in
sip.conf to change how * handles not receiving an ACK?  I know... it's
someone else's problem, but might help those of us stuck with buggy
implementations in production environments. :)

Ich hoffe das hilft anderen weiter die vor dem Problem stehen.

Bei mir ist es SOLVED.

Grüsse, Stefan

 

[wooper]

Also ich benutze asterisk-1.4.17
und habe auch diesen Fehler.

Bei mir steht da:

res = transmit_response_with_sdp(p, "200 OK", &p->initreq, XMIT_CRITICAL);

wobei:

enum xmittype {
	XMIT_CRITICAL = 2,              /*!< Transmit critical SIP message reliably, with re-transmits.
                                              If it fails, it's critical and will cause a teardown of the session */
	XMIT_RELIABLE = 1,              /*!< Transmit SIP message reliably, with re-transmits */
	XMIT_UNRELIABLE = 0,            /*!< Transmit SIP message without bothering with re-transmits */
};

ich kann ja wohl nicht

XMIT_CRITICAL = 1

einfach auf 1 ändern oder

das kommt ja x-mal vor

 grep "chan_sip.c: Maximum retries exceeded on transmission" messages

[Jan 29 14:55:41] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 15:36:58] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 15:54:42] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 16:06:33] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 16:31:53] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 16:33:11] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 16:33:58] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 16:47:33] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 17:08:15] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 17:17:23] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 17:27:00] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 17:45:35] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 17:54:45] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 18:10:51] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 18:30:42] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 18:34:42] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 18:49:46] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 29 19:09:24] WARNING[3601] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 07:53:06] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 08:16:15] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 08:20:50] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 08:29:11] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 08:37:34] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:00:49] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:08:55] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:25:13] WARNING[3642] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:41:52] WARNING[3953] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:50:46] WARNING[3953] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)
[Jan 30 09:57:50] WARNING[3953] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 20 (Critical Response)

Verwende snom300 und PhonerLite

Danke für alle Tipps

 

[HobbyStern]

Hi wooper,

ich habe mir den Code von 1.4 gerade auch einmal angesehen, es scheint dort nicht mehr so umzusetzbar zu sein. Tut mir leid, aber in diesem Fall wirst Du wohl eher die Ursache finden müssen oder eine andere Art der Lösung einschlagen.

In 1.2 ist dieses Problem so zu lösen.

Schade - aber trotzdem Grüsse,

Stefan