Asterisk und RTP-Stream

Mit "#" nicht. Aber mit Features die in VoiP-Geräte eingebaut sind doch. Solche Features sind Geräte-spezifisch. z.B. mit einem IAXy oder ein Zaptel port, einfach Flash machen.
 
Hi John,

moment heisst dass das dieses t bzw. T die Einschränkung nur auf die in features.conf stehenden "Befehle" wirksam ist?
Also ein Transfer oder Att.Transfer auf dem GXP2000 trotzdem in beide Richtungen funktioniert?



Thx

Grüße

Timm
 
T und t in Dial heißt Asterisk bleibt in der Verbindung, lauscht auf die bits, sucht die Codes in features.conf, und reagiert darauf.

Hat ein Endgerät eigene Transfer-funktionen, oder benutzt man Switchhookflash bei einem Zap analog port, dann spielen T und t keine Rolle in einem Transfer.

Kommst Du zu meinem halbtägigen Asterisk Kurs in Nürnberg am 20.4.?
 
Hi John,


ich bin noch am überlegen, da es doch eine längere Anfahrt ist.
Müsste ganz früh raus, da ich mindestens 3 std fahre.


Grüße

Timm
 
Transfer / Weiterleiten ... was mache ich falsch?

Sagt mal, wenn Ihr Euch bei den Transfers so gut auskennt, so habe ich ein paar kleine Fragen.
Wenn ich solche Features bei mir einsetzen wollte, was passiert mit meiner hangup option im Dial Statement ...,h ? Bisher ist es ja so, wenn ich ein * drücke, dann hänge ich ein. Es muss bei mir nicht zwingend ein Sternchen sein, aber brauchen tue ich diese Option sehr häufig.

So, und dann habe ich ein weiteres Problem mit Transfers. Wenn ich zB bei einer Behörde oder Firma anrufe und in der Zentrale lande, dann können die mich nicht intern weiterverbinden. Ich fliege einfach raus. Dabei sagt mir dann nachher die Partei, die ich angerufen habe, dass sie mich hätten hören können. Ich bekomme davon allerdings nichts mit. Also, da läuft doch irgendetwas schräg im RTP Stream.... oder wo? und noch wichtiger: wie kann ich das korregieren? Übrigens: ich habe immer und überall CANREINVITE auf NO gesetzt.

besten Dank für ein oder zwei hilfreiche Hinweise.

Chris
 
noch ein RTP-Problem

Hallo Forum,

Bitte verzeiht mein ungeniertes eindringen, aber ich denke ich muss nicht unbedingt einen neuen Thread aufmachen nur damit dass hier jemand liest.

Mein problem: ein an den * angeschlossenes SIP-Gateway hat probleme eine RTP-Verbindung aufzubauen. das wirkt sich folgendermassen aus(canreinvite=no):
In beide Richtungen (SIP->GW->GSM & GSM->GW->SIP) wird der Anruf einwandfrei signalisiert und aufgebaut, nur nach dem Abheben ist keine Sprache (auch kein Rauschen ->kein RTP) zu hören.
Nun der Clou: wenn ich den Anruf am Asterisk on-hold lege, höre ich am Handy die Musik, nehm ich ihn dann wieder auf wird die Sprache einwandfrei übertragen (auch hier gleiches Verhalten in beide Richtungen).

Ich habe mich erstmal mit dem Herstellersupport in Verbindung gesetzt, nach einigen Updates und einem Trace der Verbindung SIP Phone-Gateway sind sie der Meinung dass Asterisk wie ein RTP Proxy verhält.
Gibt es einen Weg wie ich * komplett aus der RTP Session raushalten kann?
oder ist es ein Hinweis auf eine Mißkonfiguration?

Ich weiß dass so etwas aus der Ferne schwer zu beurteilen ist, ich denke den Trace hier anzuhängen ist kein schlechte Idee (mit whireshark 0.99.4 als .pcap gespeichert)

An dieser Stelle schonmal Danke für eure Hilfe

lg
Chris
 

Anhänge

  • gsmgateway_tcptrace.zip
    504.5 KB · Aufrufe: 2
Hast Du es schon mal mit

rtptimeout=270 ;; default: "0" -- no limit // www.voip-info.org/wiki/index.php?page=Asterisk+config+sip.conf
rtpholdtimeout=270 ;; default: "0" -- no limit
;rtpkeepalive=120 ;; default: "0" -- no RTP Packet will be send

in Deinem sip.conf ausprobiert? Ausserdem im Dial-Commando im extensions.conf habe ich ein "r" in die Optionen eingefügt. Ich verstehe zwar nicht wieso es nun bei mir mit dem Vermitteln klappt, aber immerhin klappt es. Es scheint mir, als ob Du Dir auch mal den Dial-Befehl im voip-info.org genau ansehen solltest. Vielleicht hilft Dir einer der vielen Optionen weiter.

gruss Chris
 
mit rtpkeepalive scheint es zu klappen, allerdings erst nach 1 sekunde...

im Dialbefehlt hab ich neben "r" auch "t" und "T", aber das umgeht meines wissens nur das canreinvite=yes, dh dass der * immer in der Leitung bleibt.

Genau genommen hab ich jetzt das genaue Gegenteil von dem was ich eigentlich wollte: jetzt rennt ja theoretisch aller RTP über * oder?

Aber danke schonmal für den Hinweis, jetzt hab ich wenigstens einen workaround...

lg
Chris
 
sorry, dass ich nicht genau gelesen resp. gecheck hatte, was Du genau wolltest. Aber ja, bei mir läuft auch der gesamte RTP Traffic über den * . Meines Erachtens ist das auch besser so. Wie sonst könnte * in den Prozess eingreifen und zB Hintergrundsmusi oder Anrufweiterleitung anbieten. Oder sonst all die anderen so netten Dinge. Ansonsten kann es Dir nämlich auch passieren, dass Du zwar die anderen hörst, sie Dich aber nicht hören können, da dann nämlich der RTP Verkehr anders geroutet wird. Hatte ich auch schon alles. Daher gibts bei mir nur noch "canreinvite=no". Seitdem habe ich auch keinerlei Probleme mehr mit dem RTP Zeugs.

aehm... noch was. Du schreibst:
Nun der Clou: wenn ich den Anruf am Asterisk on-hold lege, höre ich am Handy die Musik, nehm ich ihn dann wieder auf wird die Sprache einwandfrei übertragen (auch hier gleiches Verhalten in beide Richtungen).
... und später stellst Du die Frage, ob sich * komplett aus dem RTP Stream raushalten solle.


das ist ein Widerspruch... * kann ja nur diese Dienste anbieten, wenn es weiss wann es dies tun soll. Mit anderen Worten: * muss dazu auch mithören können.... naja. * ist dafür bekannt, dass es noch nie gepetzt hat. Also: Deine Gespräche sind in guter Gesellschaft :)

Alles Gute, Chris
 
Zuletzt bearbeitet:
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.