Hallo liebes Forum,
wir haben ein Problem bei eingehenden Anrufen auf eine skriptgesteuerte Durchwahl. Dabei wird die Verbindung vom eingehenden Teilnehmer vorzeitig beendet.
folgende Kostellation: Unser Skript nimmt den Anruf entgegen. Nach einer PIN Eingabe findet per Loop ein Frage-/Antwortspiel statt. Die Antworten werden nach Zustimmung des Teilnehmers aufgezeichnet. Es wird per Playpack eine Frage gestellt, dann der Monitor zur Aufzeichnung gestartet. Anschließend warte ich per Waitexten auf eine Tasteneingabe des Anrufers. Wir benötigen ca 17 Minuten Sprachmaterial, um dieses anschließend auszuwerten. D.h. bei der ersten Antwort setze ich bei WaitExten einen Timeout vom 1020 Sekunden. Es werden die Extensions 0=Frage wiederholen, #=Frage beantwortet, i=ungültige Taste, t=Timeout, h=Hangup mit entsprechenden Aktionen ausgewertet. Nach jeder #-Taste wird der Monitor gestoppt, eine neue Frage gestellt und der Timeout abzuglich der Antwortzeit neu gesetzt.
Mein Problem ist nun, daß die Anlage des Anrufers bei diesen hohen Timeouts (max 1020 Sekunden) keinen RTP Traffic mehr von unserer Seite registriert und die Verbindung beendet. Dies wurde mir von unserem Provider auch so bestätigt. Das Problem tritt übigens nicht bei normalen Festnetzanschlüssen oder Mobilfunkanrufen auf.
Nun habe ich versucht, durch den Parameter rtpkeepalive=10 in der sip.conf dem Gegenüber zu signalisieren, daß wir “noch da” sind. Der Parameter hat dieses Problem aber nicht beseitigt, zumal, wenn ich es richtig verstanden habe, dieser Parameter nur bei NAT funktioniert und wir aber kein NAT haben.
Ich suche nun nach einer Möglichkeit, künstlich RTP Traffic zu erzeugen. Ein erster Versuch war, WaitExten immer nur max. 30 Sekunden Timeout zu geben und dann in der t-Extension per Playback einen “Beep” zu senden, um dann wieder zum WaitExten zu springen. Bei dieser Lösung wurde aber der Anrufer durch den “Beep” während der Fragenbeantwortung so irretiert, daß unsere Kunden diese Lösung nicht akzeptiert haben.
Bei der Vielzahl unserer Kunden möchten wir auch vermeiden, daß eine Lösung des Problems immer nur durch den Kunden durch evtl. Umparametrierung der Kundentimeouts durchgeführt wird. D.h. ich suche eine generelle Lösung die wir konfigurieren können und die dadurch bei jedem Kunden zum Erfolg führt.
Ich bin für jeden Lösungsansatz dankbar. Dies ist mein erster Beitrag, ich bitte um Nachsicht bei evtl. Fehlern und Unzulänglichkeiten meiner Anfrage.
Besten Dank und Grüße an die Leser
Henry Ott
mobydick: 7.13.04,
gehostet bei R-KOM in Regensburg
host:nonat.voip.r-kom.net
options:
nat=no
canreinvite=no
disallow=all
allow=alaw
allow=ulaw
allow=gsm
qualify=yes
fromdomain=nonat.voip.r-kom.net
insecure=invite,port
fromuser=xxxx
sip.conf:
device-options
type=friend
context=mdc_location-0
host=dynamic
subscribecontext=internal
call-limit=99
device-voicebox
subscribemwi=yes
vmexten=*104
[general]
udpbindaddr=0.0.0.0
transport=udp
context=no-auth-in
notifyringing=yes
port=5060
rtpholdtimeout=1200
rtptimeout=1200
srvlookup=yes
callevents=yes
allowsubscribe=yes
notifyhold=yes
limitonpeers=yes
callcounter=yes
notifycid=ignore-context
qualify=yes
pedantic=no
useclientcode=yes
defaultexpiry=600
tos_sip=cs3
tos_audio=ef
tos_video=af41
tos_text=cs3
dtmfmode=rfc2833
language=de
allowguest=yes
videosupport=no
disallow=all
allow=alaw
allow=ulaw
allow=gsm
allow=h264
canreinvite=no
rtpkeepalive=10
#include mdc_sip_register.conf
#include mdc_sip_ipdevice.conf
#include mdc_sip_trunk.conf
#include mdc_sip_gw.conf