Willkommen in der Business Community

Die Telekom Community für Geschäftskunden

Aktueller Hinweis

Digibox bricht ausgehendes Telefonat nach 15 Minuten ab

Gelöst

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. Fröhlich

 

Danke und beste Grüße,

Florian Fuchs

 

1 AKZEPTIERTE LÖSUNG
Lösung

@Metallbau Fuchs 

Angeblich wurde das Problem mal durch die Umstellung des Transportprotokolls von TCP nach UDP gelöst. Kannst Du ja mal probieren.

Lösung in ursprünglichem Beitrag anzeigen  

Lösung

@Metallbau Fuchs 

Angeblich wurde das Problem mal durch die Umstellung des Transportprotokolls von TCP nach UDP gelöst. Kannst Du ja mal probieren.

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.

 

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 Fröhlich

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?

Danke für eure Tipps @Micknik und @NPS011172 Fröhlich

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