- Beitrag abonnieren
- Beitrag stummschalten
- Beitrag als ungelesen kennzeichnen
- Beitrag als gelesen kennzeichnen
Digibox bricht ausgehendes Telefonat nach 15 Minuten ab
26.09.2019 14:55
Hallo zusammen,
Ich weiß die Frage kam schon des öfteren hier im Forum vor, aber ich konnte unser Problem leider nicht lösen.
Seit dem Update auf die neuste Firmware der Digibox Premium brechen alle ausgehenden Telefonate nach 900 Sekunden ab.
Wir haben unsere Box mittlerweile seit 1-2 Jahren und hatten vorher nie solche Probleme.
Auch an der Verkabelung oder den Einstellungen hat sich nichts geändert.
Ich habe hier mal 2 SIP Logdateien von einem ausgehendem und einem ankommendem Gespräch.
Beim dem ausgehendem Gespräch bekomme ich nach 15 Minuten eine SIP BYE-Meldung mit dem Grund "480 - Refresh response failure".
2019-09-26 12:32:15.578 INFO sip_timer.c( 339) : add tpl msg status, time 0 ms, type 1 2019-09-26 12:32:15.578 INFO tal.c( 734) : tal_set_state(): TA[114209,trying,0,in,REGISTER,udp:10.0.0.172:5060,39000000] ==> completed 2019-09-26 12:32:15.578 INFO sip_timer.c( 339) : add Timer J, time 32000 ms, type 1 2019-09-26 12:32:15.578 INFO tal.c(1552) : srv_noninvite_out(): TA[114209,completed,0,in,REGISTER,udp:10.0.0.172:5060,39000000] end 2019-09-26 12:32:15.578 INFO tal.c(1490) : srv_noninvite_inc(): TA[114209,completed,0,in,REGISTER,udp:10.0.0.172:5060,39000000] end 2019-09-26 12:32:15.578 INFO tal.c( 528) : tal_status_cb(114209, 230524) TPL_MSG_SEND 2019-09-26 12:32:16.711 INFO tpl.c(1020) : tcp:217.0.27.160:26437,30010001 (44/0/0) data event 2019-09-26 12:32:16.711 INFO tpl.c(1030) : tcp:217.0.27.160:26437,30010001 (44/0/0) data event read 2019-09-26 12:32:16.711 INFO tpl.c( 923) : tcp:217.0.27.160:26437,30010001 (44/0) 642 bytes from 217.0.27.160:5060,30010001 in state CONNECTED 2019-09-26 12:32:16.711 MESSAGE tpl.c( 965) : --> from <217.0.27.160:5060;transport=tcp> BYE sip:+49XXXXXXX@93.193.134.119:5060;transport=tcp;line=8EAD16180EC33710BF42339017400844 SIP/2.0 Max-Forwards: 68 Via: SIP/2.0/TCP 217.0.27.160:5060;branch=z9hG4bKg3Zqkv7ibx7828nfpsit56xvggg53jel6 To: <sip:+49XXXXXXX@tel.t-online.de;user=phone>;tag=9E2B55FABDC3371083B8339017400844 From: <sip:YYYYYYY@tel.t-online.de>;tag=h7g4Esbg_p65557t1569493019m701917c148350226s1_300595200-1611713536 Call-ID: 4E2B55FABDC3371083B7339017400844 CSeq: 4 BYE Reason: SIP;cause=480;text="Refresh response failure" Content-Length: 0 Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, PUBLISH, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE
Beim ankommendem Telefonat wird jedoch eine SIP Update-Meldung mit dem Grund "sending UPDATE due to session timer expired" gesendet.
2019-09-26 11:56:56.529 INFO sip_timer.c( 339) : add tpl msg status, time 0 ms, type 1 2019-09-26 11:56:56.529 INFO tal.c( 734) : tal_set_state(): TA[113834,trying,0,in,REGISTER,udp:10.0.0.172:5060,39000000] ==> completed 2019-09-26 11:56:56.529 INFO sip_timer.c( 339) : add Timer J, time 32000 ms, type 1 2019-09-26 11:56:56.529 INFO tal.c(1552) : srv_noninvite_out(): TA[113834,completed,0,in,REGISTER,udp:10.0.0.172:5060,39000000] end 2019-09-26 11:56:56.529 INFO tal.c(1490) : srv_noninvite_inc(): TA[113834,completed,0,in,REGISTER,udp:10.0.0.172:5060,39000000] end 2019-09-26 11:56:56.529 INFO tal.c( 528) : tal_status_cb(113834, 229744) TPL_MSG_SEND 2019-09-26 11:56:57.400 INFO tu_proxy.c(5827) : session timer expired for dialog=0x03354C70 2019-09-26 11:56:57.400 INFO sip_dns.c( 214) : delete: 217.0.27.160, ifindex=0, state=resolved 2019-09-26 11:56:57.400 INFO tu_proxy.c(2819) : resolved address for host=217.0.27.160: 217.0.27.160:5060 2019-09-26 11:56:57.400 INFO tu_proxy.c(3169) : sending UPDATE due to session timer expired for dialog=0x03354C70 2019-09-26 11:56:57.400 INFO tal_message.c( 111) : TAL: tal msg 229745 created 2019-09-26 11:56:57.400 INFO tal.c(3627) : tal_store_ta(): TA[113835,idle,0,out,UPDATE,tcp:217.0.27.160:5060,30010001] added 2019-09-26 11:56:57.400 INFO tal.c(3629) : TA 113835: added, now active TAs=5 2019-09-26 11:56:57.400 INFO tpl.c(2332) : by local addr 00000000 2019-09-26 11:56:57.401 INFO tpl.c(2336) : by local default tcp:0.0.0.0:5060 2019-09-26 11:56:57.401 INFO tu_proxy.c(6032) : use local Contact address 93.193.134.119:5060 2019-09-26 11:56:57.401 INFO tal.c(1864) : cli_noninvite_out(): TA[113835,idle,0,out,UPDATE,tcp:217.0.27.160:5060,30010001] start 2019-09-26 11:56:57.401 INFO sip_timer.c( 339) : add Timer F, time 32000 ms, type 1 2019-09-26 11:56:57.401 INFO tal.c( 734) : tal_set_state(): TA[113835,idle,0,out,UPDATE,tcp:217.0.27.160:5060,30010001] ==> trying 2019-09-26 11:56:57.401 INFO tpl.c(1729) : tcp:0.0.0.0:5060 (10/0/0) copy sock 2019-09-26 11:56:57.402 INFO tpl.c(1771) : tcp:217.0.27.160:5060,30010001 (-1/0/0) copied sock 2019-09-26 11:56:57.402 INFO tpl.c(1178) : Success set tos 195 2019-09-26 11:56:57.402 INFO tpl.c( 312) : tcp:217.0.27.160:5060,30010001 CREATED -> IDLE 2019-09-26 11:56:57.402 INFO sip_api.c(7771) : tcp:217.0.27.160:5060,30010001 IDLE 2019-09-26 11:56:57.402 INFO tpl.c(1992) : tcp:217.0.27.160:5060,30010001 (34/0/0) start new 2019-09-26 11:56:57.402 INFO tpl.c( 312) : tcp:217.0.27.160:5060,30010001 IDLE -> CONNECTING 2019-09-26 11:56:57.403 INFO sip_api.c(7771) : tcp:217.0.27.160:5060,30010001 CONNECTING 2019-09-26 11:56:57.403 INFO tal.c(1894) : cli_noninvite_out(): TA[113835,trying,0,out,UPDATE,tcp:217.0.27.160:5060,30010001] end 2019-09-26 11:56:57.422 INFO tpl.c(1365) : tcp:217.0.27.160:5060,30010001 (34/1/0) tcp connect event 2019-09-26 11:56:57.423 INFO tpl.c(1148) : Success set keepalive to 900 seconds 2019-09-26 11:56:57.423 INFO tpl.c( 312) : tcp:217.0.27.160:5060,30010001 CONNECTING -> CONNECTED 2019-09-26 11:56:57.423 INFO sip_api.c(7771) : tcp:217.0.27.160:5060,30010001 CONNECTED 2019-09-26 11:56:57.423 INFO sip_timer.c( 339) : add tcp:217.0.27.160:5060,30010001, time 60000 ms, type 2 2019-09-26 11:56:57.423 INFO tpl.c(1020) : tcp:217.0.27.160:5060,30010001 (34/1/0) data event 2019-09-26 11:56:57.423 INFO tpl.c(1044) : tcp:217.0.27.160:5060,30010001 (34/1/0) data event write 2019-09-26 11:56:57.423 INFO tpl.c( 681) : tcp:217.0.27.160:5060,30010001 (34/1/0) data write 2019-09-26 11:56:57.424 INFO tpl.c( 729) : send via fd 34, key tcp:217.0.27.160:5060,30010001, len 819 -> 217.0.27.160:5060,30010001 2019-09-26 11:56:57.424 MESSAGE tpl.c( 739) : <-- to <217.0.27.160:5060;transport=tcp> UPDATE sip:sgc_c@217.0.27.160;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 93.193.134.119:5060;branch=z9hG4bKF4CC682EBBC337108376339017400844;rport Route: <sip:217.0.27.160;transport=tcp;lr> From: <sip:+49XXXXXX@hmbsx001.ngn.vodafone.de;user=phone>;tag=74811B03B9C337108342339017400844 To: <sip:YYYYYYYYY@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65557t1569490886m595663c148137667s1_2462464080-899784126 Call-ID: p65557t1569490886m595663c148137667s2 CSeq: 32 UPDATE Contact: <sip:+49XXXXXXXXX@93.193.134.119:5060;transport=tcp;line=8EAD16180EC33710BF42339017400844> Max-Forwards: 70 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, MESSAGE, SUBSCRIBE, UPDATE, PRACK, REFER Supported: 100rel, replaces, timer User-Agent: Digitalisierungsbox Premium 11.01.02.101, PBX Session-Expires: 1800 Content-Length: 0
Vielleicht könnt ihr mir sagen welche Einstellungen ich ändern muss, damit auch ausgehende Telefonate wieder länger als 15 Minuten geführt werden können.
Danke und beste Grüße,
Florian Fuchs
Gelöst! Gehe zu Lösung.
Angeblich wurde das Problem mal durch die Umstellung des Transportprotokolls von TCP nach UDP gelöst. Kannst Du ja mal probieren.
Angeblich wurde das Problem mal durch die Umstellung des Transportprotokolls von TCP nach UDP gelöst. Kannst Du ja mal probieren.
26.09.2019 16:17
Hallo @Metallbau Fuchs ,
hast du einen kompletten nur SIP-Trace von einer eingehenden/abgehenden Verbindung?
Gerne auch per PN an mich, die Rufnummern vergesse ich.
26.09.2019 23:09
Könnte daran liegen, dass der Refresher von der über den SIP-Dialog ausgehandelten Partei (UA Client oder UA Server) nicht in der Zeit nach 15 Minuten kommt und die Seite, welche das Update eigentlich nur empfangen sollte darum ein Update schickt, damit die Session aufrecht erhalten werden kann und das schlägt offensichtlich fehl. Da hilft nur ein Blick in den Trace der SIP-Signalisierung, wer den Vertrag nicht einhält
Warum wird Transport TCP für einen Consumer-Voip-As MSN der Telekom (tel.t-online.de) verwendet, wo doch UDP (noch) der Standard ist (wird auch noch via NAPTR als höchste Prio zur Auflösung ermittelt) - kann man natürlich machen, aber warum?
27.09.2019 12:21
Danke für eure Tipps @Micknik und @NPS011172
Die Umstellung von TCP auf UDP hat den gewünschten Erfolg gebracht. Wieso TCP eingestellt war kann ich ich euch leider nicht beantworten, das weiß ich nicht.
Auch Danke an @wari1957 für deine angebotene Hilfe!
Wünsche allen ein entspanntes Wochenende.
Grüße,
Florian Fuchs