Signal in Gespräch einblenden

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Habe natürlich das ganze auch schon mal mit debug level 10 durchlaufen lassen. Relevanter Log-Ausschnitt anbei. Da finden sich dann ab 16:34:58 die besagten 15 Sekunden, in denen die Verbindung steht. Ab 16:35:13 wird die Verbindung dann einfach so abgebaut. Warum das so ist, ist zumindest für mich nicht ersichtlich. Der einzige Zusammenhang den ich momentan ableiten kann, sind eben diese 15 Sekunden, was genau der Zeit bis zum ersten Signal entspricht.
Bin ratlos...
Tjareson.

Edit Guard-X: Bitte Code-Tags verwenden!

Code: 
Nov 23 16:34:47 DEBUG[28971]: pbx.c:1677 pbx_extension_helper: Launching 'Set'
    -- Executing Set("SIP/dus.net-0818d078", "LIMIT_WARNING_FILE=beep") in new stack
Nov 23 16:34:47 DEBUG[28971]: pbx.c:1677 pbx_extension_helper: Launching 'Set'
    -- Executing Set("SIP/dus.net-0818d078", "LIMIT_CONNECT_FILE=beep") in new stack
Nov 23 16:34:47 DEBUG[28971]: pbx.c:1677 pbx_extension_helper: Launching 'Dial'
    -- Executing Dial("SIP/dus.net-0818d078", "SIP/000xxxxxxxxxxx/030xxxxxxxx|60|L(60000:45000:5000)") in new stack
    -- Limit Data for this call:
    -- - timelimit     = 60000
    -- - play_warning  = 45000
    -- - play_to_caller= yes
    -- - play_to_callee= no
    -- - warning_freq  = 5000
    -- - start_sound   = beep
    -- - warning_sound = beep
    -- - end_sound     = UNDEF
Nov 23 16:34:47 DEBUG[28971]: chan_sip.c:3168 sip_alloc: Allocating new SIP dialog for (No Call-ID) - INVITE (With RTP)
Nov 23 16:34:47 DEBUG[28971]: chan_sip.c:1885 create_addr_from_peer: Setting NAT on RTP to 0
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-102#-4.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable LIMIT_CONNECT_FILE.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-102#-3.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable LIMIT_WARNING_FILE.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-102#-2.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable PLAYBACKSTATUS.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-102#-1.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-telco-5.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-telco-4.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-i-2.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable STACK-confcenter-i-1.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable INVALID_EXTEN.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable SIPCALLID.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable SIPUSERAGENT.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable SIPDOMAIN.
Nov 23 16:34:47 DEBUG[28971]: channel.c:2902 ast_channel_inherit_variables: Not copying variable SIPURI.
Nov 23 16:34:47 DEBUG[28971]: chan_sip.c:2079 sip_call: Outgoing Call for 030xxxxxxxx
Nov 23 16:34:47 DEBUG[28971]: chan_sip.c:2217 update_call_counter: Updating call counter for outgoing call
    -- Called 000387803425/030xxxxxxxx
Nov 23 16:34:48 DEBUG[28848]: chan_sip.c:1209 retrans_pkt: ** SIP timers: Rescheduling retransmission 2 to 1000 ms (t1 500 ms (Retrans id #55))
Nov 23 16:34:49 DEBUG[28848]: chan_sip.c:1209 retrans_pkt: ** SIP timers: Rescheduling retransmission 3 to 2000 ms (t1 500 ms (Retrans id #55))
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:3216 find_call: = Found Their Call ID: [email][email protected][/email] Their Tag  Our tag: as6369e192
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:1390 __sip_ack: Acked pending invite 102
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:1412 __sip_ack: Stopping retransmission on '[email protected]' of Request 102: Match Found
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:9642 handle_response_invite: SIP response 407 to standard invite
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:9081 do_proxy_auth: Auth attempt 1 on INVITE
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:3216 find_call: = Found Their Call ID: [email][email protected][/email] Their Tag  Our tag: as6369e192
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:1465 __sip_semi_ack: (Provisional) Stopping retransmission (but retaining packet) on '[email protected]' Request 103: Found
Nov 23 16:34:50 DEBUG[28848]: chan_sip.c:9642 handle_response_invite: SIP response 100 to standard invite
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:3216 find_call: = Found Their Call ID: [email][email protected][/email] Their Tag  Our tag: as6369e192
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:1465 __sip_semi_ack: (Provisional) Stopping retransmission (but retaining packet) on '[email protected]' Request 103: Found
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:9642 handle_response_invite: SIP response 180 to standard invite
Nov 23 16:34:56 DEBUG[28841]: chan_sip.c:11767 sip_devicestate: Checking device state for peer 000387803425
Nov 23 16:34:56 DEBUG[28841]: devicestate.c:187 do_state_change: Changing state for SIP/000xxxxxxxxxxx - state 6 (Ringing)
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:3216 find_call: = Found Their Call ID: [email][email protected][/email] Their Tag as345d0813 Our tag: as6369e192
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:1465 __sip_semi_ack: (Provisional) Stopping retransmission (but retaining packet) on '[email protected]' Request 103: Found
Nov 23 16:34:56 DEBUG[28848]: chan_sip.c:9642 handle_response_invite: SIP response 183 to standard invite
    -- SIP/000xxxxxxxxxxx-081954d8 is ringing
Nov 23 16:34:56 DEBUG[28971]: channel.c:2088 ast_indicate: Driver for channel 'SIP/dus.net-0818d078' does not support indication 3, emulating it
Nov 23 16:34:56 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format slin
    -- SIP/000xxxxxxxxxxx-081954d8 is making progress passing it to SIP/dus.net-0818d078
Nov 23 16:34:56 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format ulaw
Nov 23 16:34:56 DEBUG[28992]: app_queue.c:500 changethread: Device 'SIP/000xxxxxxxxxxx' changed to state '6' (Ringing) but we don't care because they're not a member of any queue.
Nov 23 16:34:56 DEBUG[28971]: rtp.c:1359 ast_rtp_write: Ooh, format changed from unknown to ulaw
Nov 23 16:34:58 DEBUG[28848]: chan_sip.c:3216 find_call: = Found Their Call ID: [email][email protected][/email] Their Tag as345d0813 Our tag: as6369e192
Nov 23 16:34:58 DEBUG[28848]: chan_sip.c:1390 __sip_ack: Acked pending invite 103
Nov 23 16:34:58 DEBUG[28848]: chan_sip.c:1412 __sip_ack: Stopping retransmission on '[email protected]' of Request 103: Match Found
Nov 23 16:34:58 DEBUG[28848]: chan_sip.c:9642 handle_response_invite: SIP response 200 to standard invite
Nov 23 16:34:58 DEBUG[28848]: chan_sip.c:6194 build_route: build_route: Contact hop: <sip:[email protected]>
Nov 23 16:34:58 DEBUG[28841]: chan_sip.c:11767 sip_devicestate: Checking device state for peer 000387803425
Nov 23 16:34:58 DEBUG[28841]: channel.c:777 channel_find_locked: Avoiding initial deadlock for 'SIP/000xxxxxxxxxxx-081954d8'
    -- SIP/000xxxxxxxxxxx-081954d8 answered SIP/dus.net-0818d078
Nov 23 16:34:58 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format gsm
    -- Playing 'beep' (language 'en')
Nov 23 16:34:58 DEBUG[28841]: devicestate.c:187 do_state_change: Changing state for SIP/000xxxxxxxxxxx - state 2 (In use)
Nov 23 16:34:58 DEBUG[28993]: app_queue.c:500 changethread: Device 'SIP/000xxxxxxxxxxx' changed to state '2' (In use) but we don't care because they're not a member of any queue.
Nov 23 16:34:58 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format ulaw
Nov 23 16:35:13 DEBUG[28971]: channel.c:3662 ast_channel_bridge: Bridge stops bridging channels SIP/dus.net-0818d078 and SIP/000xxxxxxxxxxx-081954d8
Nov 23 16:35:13 DEBUG[28971]: channel.c:1373 ast_hangup: Hanging up channel 'SIP/000xxxxxxxxxxx-081954d8'
Nov 23 16:35:13 DEBUG[28971]: chan_sip.c:2427 sip_hangup: Hangup call SIP/000xxxxxxxxxxx-081954d8, SIP callid [email][email protected][/email])
Nov 23 16:35:13 DEBUG[28971]: chan_sip.c:2435 sip_hangup: update_call_counter(030xxxxxxxx) - decrement call limit counter
Nov 23 16:35:13 DEBUG[28971]: chan_sip.c:2217 update_call_counter: Updating call counter for outgoing call
Nov 23 16:35:13 DEBUG[28841]: chan_sip.c:11767 sip_devicestate: Checking device state for peer 000387803425
Nov 23 16:35:13 DEBUG[28841]: devicestate.c:187 do_state_change: Changing state for SIP/000xxxxxxxxxxx - state 1 (Not in use)
Nov 23 16:35:13 DEBUG[28971]: app_dial.c:1635 dial_exec_full: Exiting with DIALSTATUS=ANSWER.
 
Hey tjaerson und alle Anderen natürlich auch,

ich frag mal ganz doof - der normale DIAL wird aber von Erfolg gekrönt, richtig ?

Ich habe gerade mal Deine bisherigen Threads überflogen, alles konstellierte da mit "Anruf bricht nach x ab" "Voicemail legt nach 1 Minute auf" ...

Nur so eine Frage und ggf. der erste Ansatzpunkt.

Ansonsten sind CLI Ausgaben und ggf. eine aussagekräftige Signatur was Du da eigentlich gebaut hast ein Mittel des Erfolges.

Grüsse, Stefan
 
Da haben wir zwei uns überschnitten, der sip debug ist - denke ich mal - ein wenig viel info ;)

Hast Du das mit den Codecs gelesen ?

Code: 
Nov 23 16:34:56 DEBUG[28971]: channel.c:2088 ast_indicate: Driver for channel 'SIP/dus.net-0818d078' does not support indication 3, emulating it
Nov 23 16:34:56 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format slin
    -- SIP/000xxxxxxxxxxx-081954d8 is making progress passing it to SIP/dus.net-0818d078
Nov 23 16:34:56 DEBUG[28971]: channel.c:2409 set_format: Set channel SIP/dus.net-0818d078 to write format ulaw
Dann wieder gsm für das abzuspielende File ...
Code: 
Nov 23 16:34:56 DEBUG[28971]: rtp.c:1359 ast_rtp_write: Ooh, format changed from unknown to ulaw

Usw Usf.

Wenn ich hier in die falsche Richtung gehe - dann bitte ich um Verzeihung - mein Gedanke wäre nun doch mal um die entsprechenden stellen der sip.conf zu bitten...

Anbei - warum 15 Sekunden , die Limits sind doch 60000 (1 Min) , 45000(45sek) und 5000 (5 sek.) - was doch wenn ich heute abend nicht ein brett vor dem kopf habe heisst , spiele nach 45 sekunden, alle 5 sekunden dies und das..

Grüsse, Stefan
 
@HobbyStern:
Kurz zum angeführten Thread Anrufbeantworter bricht ab: das ist eine ganz andere Problemstellung, da asterisk während der Nachrichtenaufzeichnung default-mäßig wohl keinen rtp-Datenstrom sendet. Manche Provider schalten einem dann nach 1 Minute die Verbindung ab. (steht auch weiter unten im Thread) Konnte ich aber zwischenzeitlich lösen - Details dazu im betr. Thread.

Was meine Config anbelangt, wie oben angegeben, nichts besonderes:
Ich nutze Asterisk Version 1.2.13 auf debian, Verbindungen alle über SIP.

Was die Parametrisierung des L-Attributs betrifft, die Doku sagt dazu:
"... warning when y milliseconds are left and...", d.h. also übrig sind, also Restzeit. Bei 60 Sekunden Gesamtzeit mit erster Benachrichtigung bei 45 Sekunden Restzeit kommt man dann auf 15 Sekunden. Dann genau bricht eben auch die Verbindung ab.
Das es ein Codec-Problem ist, kann ich mir ehrlich gesagt nicht vorstellen. In den von Dir zitierten Logfile-Ausschnitten wird der Codec ja letztlich erkannt. Zudem ist die Verbindung selbst kein Problem. Alle verstehen sich, die eingespielten Files sind auch zu hören. (Das System macht nebenbei auch eine Menge mehr einwandfrei, Konferenzen, IVR-Menus etc.)
Nur wird diese besagte Verbindung eben nach dem ersten Interval beendet. (Sie bricht übrigens auch nicht wirklich ab, dem Logfile nach, beendet Asterisk in der channel.c innerhalb von ast_channel_bridge ganz geplant.
Ich habe zwischenzeitlich mal die Fehlerdatenbank im Developer-Bereich von asterisk.org detailliert durchgesehen, da scheint es noch weitere Probleme mit der Zeitberechnung für Dial-Limits in V 1.2.13 zu geben. (bspw. wenn Gesamtzeit und erstes Timeout gleich sind)
Mich würde interessieren, ob das bei jemandem wirklich läuft und welche asterisk-Version das dann ist. Falls das jemand im Einsatz hat, könnte er mir mal seine channel.c-Source schicken.

Beste Grüße.
Tjareson
 
Hi Tjaerson,

...bisherigen Threads überflogen...
Zum Vergrößern anklicken....


Nimm´s mir nicht übel, aber Probleme sind meistens da wo man sie nicht vermutet, daher meine etwas "einfachere" Gegenfrage.

Aber ich machs wieder gut :

Folgendes Testszenario :

Code: 
exten => 9908,1,Set(LIMIT_WARNING_FILE=<audiofile alle 5 sekunden>)
exten => 9908,2,Set(LIMIT_CONNECT_FILE=<audiofile verbunden)               
exten => 9908,3,Dial(SIP/pbx1/02088480499,,L(60000:45000:5000))
exten => 9908,4,Verbose(Hey ich leg jetzt auf)
exten => 9908,5,Hangup


Das Szenario läuft einwandfrei durch, s.h. erst audiofile verbunden, dann nach 15 sekunden (du hattest recht, bist im vorteil - konntest lesen :lach: ) das "5 sekunden file".

Dial legt allerdings insofern auf das n+101 nutzt und nicht der priorität folgt.

Asterisk Version etc. siehe Signatur.

Grüsse, Stefan
 
Codecs sind auch insofern ok - jedoch hatte ich mich gewundert - und das wollte ich mit dem auszug aus deiner sip.conf gerne nachsehen - welche codecs du nutzt.

Bei meinem Versuchsaufbau war ausschliesslich alaw zugelassen, im debugmode konnte ich dem selben verhalten wie bei deinem debug folgen, jedoch sprang er nicht so häufig zwischen den formaten hin und her, aber wie du schon sagst - das ist hier nicht von relevanz.

Kurz und Knapp : Es läuft.
 
Hätte gerne auch mal geholfen, habe es aber leider zu spät gelesen
 
Bei Asterisk 1.2.13 funktioniert das Beispiel in der Tat nicht.
 
Es gibt lt. changelog nur zwei Änderungen die sich mit DIAL befassen :

2006-09-28 16:37 +0000 [r43897] BJ Weschke <[email protected]>

* apps/app_queue.c: app_queue is comparing the device names
incorrectly while checking their statuses. It's internal list of
interfaces includes the dial string, while the argument passed to
this function does not have the dial string (/n for a local
channel). This causes it to ignore the device state changes
because it thinks it belongs to none of its members. (#8040
reported and patch by tim_ringenbach)
Zum Vergrößern anklicken....

und

2006-09-19 16:21 +0000 [r43269] Matt O'Gorman <[email protected]>

* pbx/pbx_gtkconsole.c, apps/app_dial.c, channels/chan_sip.c,
apps/app_macro.c, asterisk.c, config.c, apps/app_queue.c, pbx.c:
fixes some verbose vs debug issues. patch from bug 2617
Zum Vergrößern anklicken....

Die Änderungen an den SIP Channeln lasse ich mal aussen vor - denn nachvollziehen kann man es eh so ohne weiteres nicht was genau getan wurde.

Wer es haben möchte, das betreffende Stück changelog hängt im Anhang. (1.2.12.1 --> 1.2.13)

Ich denke das ganze ist ein Fall für den Bugtracker (bugs.digium.com)

Grüsse, Stefan
 

Anhänge

  • chnagelog-teil.txt
    16.5 KB · Aufrufe: 0
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 611 (Mitglieder: 6, Gäste: 605)

Neueste Beiträge

Statistik des Forums

Themen
244,872
Beiträge
2,219,909
Mitglieder
371,594
Neuestes Mitglied
AA-Idealbau
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück