.titleBar { margin-bottom: 5px!important; }

Telekom VoIP Gesprächsabbruch nach exakt 15 Minuten

Dieses Thema im Forum "FreePBX, TrixBox ([email protected])" wurde erstellt von magicamun, 10 Dez. 2016.

  1. magicamun

    magicamun Neuer User

    Registriert seit:
    1 Aug. 2006
    Beiträge:
    53
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo - wie im Betreff oben geschrieben habe ich Abbrüche von Gesprächen nach exakt 15 Minuten - Das ganze scheint (auch) von der Gegenstelle abhängig zu sein.

    Mein Trunk sieht so aus:
    Outgoing:
    Code:
    type=friend
    remotesecret=<passwort>
    qualify=no
    nat=force_rport,comedia
    maxexpirey=240
    insecure=port,invite
    host=tel.t-online.de
    defaultuser=<user>
    authuser=<user>
    fromdomain=tel.t-online.de
    dtmfmode=rfc2833
    defaultexpirey=240
    canreinvite=no
    realm=tel.t-online.de
    extension=<vorwahl + rufnummer>
    
    Incoming User Context ist "Rufnummer ohne Vorwahl"

    Der Register String sieht so aus:
    Code:
    <Rufnummer mit Vorwahl>:<passwort>:<[email protected]@tel.t-online.de/<rufnummer mit vorwahl>~480
    
    In den Asterisk SIP-Settings habe ich noch

    session-timers=refuse

    gesetzt - der Rest dort ist default.

    Ich habe Gegenstellen, da passiert das nicht oder selten und ich habe eine Gegenstelle, da passiert das jedesmal - Nervig.

    Der Freepbx hängt hinter einer FB und separatener Firewall und bekommt aus dem I-Net alles, was hier durch passt:

    Code:
    # Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     5060
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     5060
    # Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     5070
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     5070
    # Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     5080
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     5080
    # Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     10000,19999
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     10000,19999
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     30000,39999
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     30000,39999
    ACCEPT          dsl:217.10.0.0/13       dmz     udp     40000,49999
    ACCEPT          dsl:217.0.23.0/13       dmz     udp     40000,49999
    
     
  2. abw1oim

    abw1oim Aktives Mitglied

    Registriert seit:
    26 März 2007
    Beiträge:
    951
    Zustimmungen:
    3
    Punkte für Erfolge:
    18
    Ort:
    Bonn
    Ok, wenn's die Session-Timers nicht sind, kann es ggf. hier auch ein RTP-Timeout sein (da es qualify hier auch nicht ist).
    Schau Dir mal die RTP-Settings (Keepalive, Timeout) an und mach allenfalls mal einen RTP-Debug.
    Telekom ist leider einer der SIP-Anbieter, die im Hinblick auf Ihre "Interpretation" des SIP-protokolls wirklich nervig sind (weshalb sie bei mir auch nur noch der "Notnagel" sind und nicht wirklich zum telefonieren benutzt werden ...
     
  3. magicamun

    magicamun Neuer User

    Registriert seit:
    1 Aug. 2006
    Beiträge:
    53
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    das hier ist das zum Thema rtp:

    Code:
    [email protected]:/etc/asterisk# grep rtp *
    rtp_additional.conf:rtpstart=10000
    rtp_additional.conf:rtpend=20000
    rtp_additional.conf:rtpchecksums=yes
    rtp_additional.conf:strictrtp=yes
    rtp.conf:#include rtp_additional.conf
    rtp.conf:#include rtp_custom.conf
    sip_general_additional.conf:rtpend=20000
    sip_general_additional.conf:rtpstart=10000
    sip_general_additional.conf:rtpholdtimeout=300
    sip_general_additional.conf:rtpkeepalive=0
    sip_general_additional.conf:rtptimeout=30
    [email protected]:/etc/asterisk# 
    
    und wie mache ich einen rtp-debug?

    - - - Aktualisiert - - -


    ich hatte sip debug eingeschaltet bekommen - dann hatte ich von der Gegenstelle bei der das "immer" passiert einen Anruf - das Gespräch hielt gaz normal gute 23 Minuten, bis ich es sauber beendet habe. Habe dann dort angerufen und - nach 15Minuten ist das hier der spannende Ausschnitt aus dem Log:

    Code:
    Max-Forwards: 70
    From: "Unknown" <sip:[email protected]>;tag=as0cb4ed01
    To: <sip:[email protected]:5060>
    Contact: <sip:[email protected]:5060>
    Call-ID: [email protected]:5060
    CSeq: 102 OPTIONS
    User-Agent: FPBX-13.0.190.7(11.23.0)
    Date: Sun, 11 Dec 2016 07:56:58 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    Content-Length: 0
    
    
    ---
    Retransmitting #4 (no NAT) to 192.168.2.10:5060:
    OPTIONS sip:[email protected]:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK60685e33
    Max-Forwards: 70
    From: "Unknown" <sip:[email protected]>;tag=as0cb4ed01
    To: <sip:[email protected]:5060>
    Contact: <sip:[email protected]:5060>
    Call-ID: [email protected]:5060
    CSeq: 102 OPTIONS
    User-Agent: FPBX-13.0.190.7(11.23.0)
    Date: Sun, 11 Dec 2016 07:56:58 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    Content-Length: 0
    
    
    ---
    Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS
    
    <--- SIP read from UDP:217.0.23.4:5060 --->
    INVITE sip:<RUFNUMMER MIT VORWAHL>@192.168.2.253:5060 SIP/2.0
    Max-Forwards: 64
    Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r
    To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
    From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
    Call-ID: [email protected]
    CSeq: 107 INVITE
    Contact: <sip:[email protected];transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
    Min-Se: 900
    Session-Expires: 1800;refresher=uac
    Supported: timer
    Content-Type: application/sdp
    Content-Length: 199
    Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
    
    v=0
    o=- 63251794 506029457 IN IP4 0.0.0.0
    s=-
    t=0 0
    m=audio 0 RTP/AVP 8 101
    a=rtpmap:8 PCMA/8000
    a=fmtp:8 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=sendrecv
    a=ptime:20
    <------------->
    --- (14 headers 11 lines) ---
    Sending to 217.0.23.4:5060 (NAT)
    [2016-12-11 08:57:04] WARNING[1755][C-00000014]: chan_sip.c:9992 process_sdp: Ignoring audio media offer because port number is zero
    [2016-12-11 08:57:04] WARNING[1755][C-00000014]: chan_sip.c:10413 process_sdp: Insufficient information in SDP (c=)...
    
    <--- Reliably Transmitting (NAT) to 217.0.23.4:5060 --->
    SIP/2.0 488 Not acceptable here
    Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r;received=217.0.23.4;rport=5060
    From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
    To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
    Call-ID: [email protected]
    CSeq: 107 INVITE
    Server: FPBX-13.0.190.7(11.23.0)
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    X-Asterisk-HangupCause: Normal Clearing
    X-Asterisk-HangupCauseCode: 16
    Content-Length: 0
    
    
    <------------>
    
    <--- SIP read from UDP:217.0.23.4:5060 --->
    BYE sip:<RUFNUMMER MIT VORWAHL>@192.168.2.253:5060 SIP/2.0
    Max-Forwards: 64
    Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ip5zghuydep6o9xrz4ym2xrprl
    To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
    From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
    Call-ID: [email protected]
    CSeq: 108 BYE
    Content-Length: 0
    Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
    
    <------------->
    --- (9 headers 0 lines) ---
    
    <--- Reliably Transmitting (NAT) to 217.0.23.4:5060 --->
    SIP/2.0 487 Request Terminated
    Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r;received=217.0.23.4;rport=5060
    From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
    To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
    Call-ID: [email protected]
    CSeq: 107 INVITE
    Server: FPBX-13.0.190.7(11.23.0)
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    Content-Length: 0
    
    
    <------------>
    Sending to 217.0.23.4:5060 (NAT)
    Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: BYE)
    
    <--- Transmitting (NAT) to 217.0.23.4:5060 --->
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ip5zghuydep6o9xrz4ym2xrprl;received=217.0.23.4;rport=5060
    From: <sip:[email protected]>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
    To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
    Call-ID: [email protected]
    CSeq: 108 BYE
    Server: FPBX-13.0.190.7(11.23.0)
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    Content-Length: 0
    
    
    <------------>
        -- Executing [[email protected]:1] Macro("SIP/30-00000026", "hangupcall,") in new stack
        -- Executing [[email protected]:1] ExecIf("SIP/30-00000026", "0?Set(CDR(recordingfile)=.wav)") in new stack
        -- Executing [[email protected]:2] GotoIf("SIP/30-00000026", "1?theend") in new stack
        -- Goto (macro-hangupcall,s,4)
        -- Executing [[email protected]:4] ExecIf("SIP/30-00000026", "0?Set(CDR(recordingfile)=)") in new stack
        -- Executing [[email protected]:5] Hangup("SIP/30-00000026", "") in new stack
      == Spawn extension (macro-hangupcall, s, 5) exited non-zero on 'SIP/30-00000026' in macro 'hangupcall'
      == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/30-00000026'
      == Spawn extension (macro-dialout-trunk, s, 23) exited non-zero on 'SIP/30-00000026' in macro 'dialout-trunk'
      == Spawn extension (from-internal, <GEGENSTELLE>, 6) exited non-zero on 'SIP/30-00000026'
    Scheduling destruction of SIP dialog '[email protected]_56_190_149' in 6400 ms (Method: ACK)
    set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
    set_destination: set destination to 192.168.2.11:5060
    Reliably Transmitting (no NAT) to 192.168.2.11:5060:
    BYE sip:[email protected]:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK459feb0d;rport
    Max-Forwards: 70
    From: <sip:<GEGENSTELLE>@dmz.thielemann.intern;user=phone>;tag=as27a00ccb
    To: "Gigaset C610 IP" <sip:[email protected]>;tag=1122633120
    Call-ID: [email protected]_56_190_149
    CSeq: 102 BYE
    User-Agent: FPBX-13.0.190.7(11.23.0)
    Proxy-Authorization: Digest username="30", realm="asterisk", algorithm=MD5, uri="sip:dmz.thielemann.intern", nonce="1faa8e71", response="1cdc65d8a6c8d14cea7a23bfeefa56f2"
    X-Asterisk-HangupCause: Normal Clearing
    X-Asterisk-HangupCauseCode: 16
    Content-Length: 0
    
    
    ---
    
    <--- SIP read from UDP:192.168.2.11:5060 --->
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK459feb0d;rport=5060
    From: <sip:<GEGENSTELLE>@dmz.thielemann.intern;user=phone>;tag=as27a00ccb
    To: "Gigaset C610 IP" <sip:[email protected]>;tag=1122633120
    Call-ID: [email protected]_56_190_149
    CSeq: 102 BYE
    Contact: <sip:[email protected]:5060>
    Supported: replaces
    User-Agent: C610 IP/42.238.00.000.000
    Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
    Content-Length: 0
    
    <------------->
    --- (11 headers 0 lines) ---
    SIP Response message for INCOMING dialog BYE arrived
    Really destroying SIP dialog '[email protected]_56_190_149' Method: ACK
    Reliably Transmitting (no NAT) to 192.168.2.10:5060:
    OPTIONS sip:[email protected]:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK7f6440ab
    Max-Forwards: 70
    From: "Unknown" <sip:[email protected]>;tag=as765e324f
    To: <sip:[email protected]:5060>
    Contact: <sip:[email protected]:5060>
    Call-ID: [email protected]:5060
    CSeq: 102 OPTIONS
    User-Agent: FPBX-13.0.190.7(11.23.0)
    Date: Sun, 11 Dec 2016 07:57:12 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces
    Content-Length: 0
    
     
  4. rentier-s

    rentier-s Guest

    Das sieht so aus, als würde die Telekom das session-timers=refuse ignorieren und trotzdem nach Ablauf ein Re-Invite schicken. Das SDP enhält ungültige RTP Angaben, deshalb lehnt Asterisk es mit 488 ab und das Gespräch bricht ab.
     
  5. magicamun

    magicamun Neuer User

    Registriert seit:
    1 Aug. 2006
    Beiträge:
    53
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    und was kann ich tun? Ich habe andere gegenstellen, da passiert das nicht - das ist ja das "perverse" - Wenn ich mich auf meinem Mobilfon anrufe, hält die Verbindung "ewig" - Hilft ein anderes Sip-Modul (jsip?)
     
  6. magicamun

    magicamun Neuer User

    Registriert seit:
    1 Aug. 2006
    Beiträge:
    53
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ich muss da nochmal nachaken - macht es Sinn, bei den ***********n einen Supportfall "aufzumachen"? Hat da jemand Erfahrung?

    Was ich nicht kapiere:

    ich geh mal davon aus, dass es mehr als nur einen Nutzer des telekom-VoIP-Anschlusses gibt, und kann mir nicht vorstellen, dass Leuet die über die Speedports der TK telefonieren ebensolche Probleme haben. Frage also: was ist da prinzipiell anders? SIP machen die ja sicher auch...
     
  7. rentier-s

    rentier-s Guest

    Die Suchmaschine mit den vielen Ooooo liefert Ergebnisse aus dem Telekom Hilft Forum, wo es genau um dieses Problem geht, aber niemals eine Lösung gefunden wurde. Von daher glaube ich nicht, dass ein weiterer Support Fall allzu viel bringen wird. Allerdings kann ich Dir auch keine anderweitige Lösung bieten. PJSIP könnte vielleicht helfen, da ist so einiges modernisiert worden.
     
  8. Rangierdraht

    Rangierdraht Neuer User

    Registriert seit:
    28 März 2006
    Beiträge:
    181
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    Beruf:
    Fernmeldeelektroniker
    Ort:
    Franken
    Gibt es schon eine Lösung für das Problem?
    Ich habe eine Digibox Smart hinter meinem IPfire Router hängen. Da brechen die Gespräche nach 15min (900sek) ab. Es sind 3 Telekom Rufnummern drauf.
    Ich habe noch 2 andere Provider, einen auf nem AVM Voip Gateway und den anderen direkt auf meiner Telefonanlage, da passiert das nicht.
    Die digibox brauche ich wegen dem Clear Mode für Fernwartung.
     
  9. Kalle2006

    Kalle2006 Aktives Mitglied

    Registriert seit:
    23 Juli 2006
    Beiträge:
    2,969
    Zustimmungen:
    37
    Punkte für Erfolge:
    48
    Beruf:
    IT-Dienstleister
    Ort:
    NRW
    "Vorgeschaltetes Gerät mit NAT" in den SIP-Provider-Accountdaten aktivieren.
     
  10. gehtdoch

    gehtdoch Neuer User

    Registriert seit:
    3 Feb. 2019
    Beiträge:
    8
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Ja. Die Lösung heißt schon sehr lange chan_pjsip statt chan_sip. Zu diversen Providern klappt die 15 minütliche "Totmannschaltung" via ReInvite nicht. Mit pjsip wird statt dem ReInvite ein Update verwendet - mit dem funktioniert es (chan_sip ist zu alt und kennt die update-Methode nicht).
     
  11. Rangierdraht

    Rangierdraht Neuer User

    Registriert seit:
    28 März 2006
    Beiträge:
    181
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    Beruf:
    Fernmeldeelektroniker
    Ort:
    Franken
    Geht das bei der Digibox smart?
    Neueste Software ist drauf.
     
  12. Kalle2006

    Kalle2006 Aktives Mitglied

    Registriert seit:
    23 Juli 2006
    Beiträge:
    2,969
    Zustimmungen:
    37
    Punkte für Erfolge:
    48
    Beruf:
    IT-Dienstleister
    Ort:
    NRW
    Ja, in den SIP-Provider-Einstellungen gibt es an dieser Stelle keinen Unterschied.
     
  13. Rangierdraht

    Rangierdraht Neuer User

    Registriert seit:
    28 März 2006
    Beiträge:
    181
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    Beruf:
    Fernmeldeelektroniker
    Ort:
    Franken
    #13 Rangierdraht, 14 Apr. 2019
    Zuletzt von einem Moderator bearbeitet: 15 Apr. 2019
    Und wie ändere ich das jetzt?

    -- aktualisiert --

    Ich habe jetzt von UDP auf TCP umgestellt in den Einstellungen, damit funktioniert es jetzt.
     
  14. Kalle2006

    Kalle2006 Aktives Mitglied

    Registriert seit:
    23 Juli 2006
    Beiträge:
    2,969
    Zustimmungen:
    37
    Punkte für Erfolge:
    48
    Beruf:
    IT-Dienstleister
    Ort:
    NRW
    Die Ursache liegt an deinem IPfire Router, der hat wohl ein Problem mit UDP und es kommt zum UDP Session Timeout.
     
  15. Rangierdraht

    Rangierdraht Neuer User

    Registriert seit:
    28 März 2006
    Beiträge:
    181
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    Beruf:
    Fernmeldeelektroniker
    Ort:
    Franken
    Kann nicht sein, weil mit Sipgate und voip2gsm funktionierts auch mit UDP
    Ich denke eher daß es ein Problem bei der Telekom gibt.
     
  16. Meester Proper

    Meester Proper Neuer User

    Registriert seit:
    24 Mai 2014
    Beiträge:
    69
    Zustimmungen:
    7
    Punkte für Erfolge:
    8
    Wird denn bei Sipgate und voip2gsm überhaupt ein Session-Timer aufgesetzt?
     
  17. musagetes

    musagetes Neuer User

    Registriert seit:
    17 Apr. 2007
    Beiträge:
    4
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Ich habe das gleiche Problem wie "magicamun" im ersten Beitrag.

    Nach genau 16min habe ich Gesprächsabbrüche bei ausgehenden Telefonaten mit meinem Sinus 501 (Anrufbeantworter nicht im Betrieb). Das Mobilteil ist über Dect mit meiner eigenen Fritz&Box 6490 verbunden.
    Mein Provider ist Vodafone Kabel Deutschland.
    Wo könnte das Problem liegen?
    Ich würde mich um sachliche Problemlösungen sehr freuen!
     
  18. Meester Proper

    Meester Proper Neuer User

    Registriert seit:
    24 Mai 2014
    Beiträge:
    69
    Zustimmungen:
    7
    Punkte für Erfolge:
    8
    Du müsstest einen Paketmitschnitt erstellen (Anleitung), dann das Telefonat beginnen und auf den Abbruch warten. Dann den Mitschnitt beenden und mit bspw. Wireshark die SIP-Pakete analysieren, warum der Anruf beendet wurde. Gleichzeitig solltest du aber keine weiteren Internet-Tätigkeiten vornehmen, da ansonsten der Trace zu groß wird.
     
  19. musagetes

    musagetes Neuer User

    Registriert seit:
    17 Apr. 2007
    Beiträge:
    4
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Danke für die schnelle Antwort! Ich bin natürlich davon ausgegangen,
    dass die wahrscheinlichen Probleme bzw. die Ursachen schon bekannt sind
    und es bereits Lösungsvorschläge hierzu gibt.
     
  20. Kalle2006

    Kalle2006 Aktives Mitglied

    Registriert seit:
    23 Juli 2006
    Beiträge:
    2,969
    Zustimmungen:
    37
    Punkte für Erfolge:
    48
    Beruf:
    IT-Dienstleister
    Ort:
    NRW
    Die Wahrscheinlichkeit, das es am Router oder dem Zusammenspiel von Router und Telefon / Telefonanlage mit dem SIP - Provider liegt, schätze ich auf 95 % ein.
    Nur weil das bei anderen Anbietern nicht passiert, ist dies kein Ausschlusskriterium. Denn jeder SIP - Server verhält sich anders. 15 Minuten ist ein Zeitrahmen der sehr gut auf einen UDP Session Timeout hindeutet.