Wie rtp audio direkt zwischen den voip Adaptern ?

Adm

Neuer User
Mitglied seit
9 Aug 2005
Beiträge
67
Punkte für Reaktionen
0
Punkte
6
Hallo,

folgende Situation :
ich telefoniere zwischen linksys spa-3102 und grandstream 488, als sip proxy nutze ich web.de . Dabei kann ich leider nicht die low-bitrate Codecs benutzen, da es ansheinend web.de nur iLBC davon unterstützt, und spa iLBC nicht kann.
Aber spa kann g.723 und g.729, grandstream kennt auch diese Codecs. Nur leider wird anscheinend rtp audio über web.de geleitet, und nicht direkt zwischen den Adaptern.
Und web.de kann nur das:
m=audio 10866 RTP/AVP 8 0 2 3 97 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
Wie schaffe ich es, das Audio direkt zwischen den Adaptern
übertragen wird, damit ich die low-bitrate Codecs nutzen
kann ?
 
Auf der SPA3k Seite: answer / make calls without registration: yes
IP dialling: yes

Danach wählst du userid@ip-gs488:port, und userid@ip-spa3k:5060. Je nachdem ob die Geräte im selben Netz stehen kannst du die internen IPs verwenden, ansonsten brauchts die öffentliche IP und ein Mapping der entsprechenden Ports für SIP & RTP.
 
Vielen Dank für die Antwort.

also es geht nur mit direkt IP call ? Es wird schwierig, da mindestens an einer Seite die IP dynamisch ist. Oder, wenn ich an beiden Seiten portforwarding einrichte klappt es auch ?
Jetzt hat grandstream externe Adresse und sipura ist hinter
Restricted Cone NAT.
 
Es gibt ja auch dyndns, damit wird jede dynamische IP "statisch". Da die Geräte nicht im gleichen Netz stehen, braucht es portforwarding auf beiden Seiten, plus dyndns oder ein ähnlicher Service.
 
auf der Seite wo grandstream eine externe Adresse hat, braucht man bestimmt kein Portforwarding. Und auf
den anderen Seite wird soviel ich es verstanden habe NAT
per STUN richtig configuriert. Ich kann ja via proxy telefonieren, es sollte also auch direkt laufen mit NAT. Vielleicht liegt es an web.de (oder am Vater Staat, der alle Anrufe abhören will und deshalb audio über voip provider geleitet wird), oder man muss etwas anders die ATAs configurieren.

Mit dyndns ist es nicht so einfach, da ATAs kein dyndns können.
Normalerweise muss ja über den Provider nur die Initialisierung des Anrufs ablaufen, und rtp direkt zwischen beiden ATAs laufen. Oder irre ich mich ?
 
Zuletzt bearbeitet:
Wenn die Grandstream Box direkt im Netz hängt wird die Sache ein bisschen einfacher.

Dann brauchst du nur auf der SPA3k Seite die Ports richtig zu routen, und der Router auf der Seite muss halt dann dyndns unterstützen.. das tun ja mittlerweile die meisten Dinger aus den Geizmärkten.

Ob RTP direkt geht hängt vom Provider ab: Ohne Outbound Proxy hast du recht, da brauchst die ganze Einstellungen gar nicht (angenommen ihr seit beide beim gleichen Provider, oder bei Provider die miteinander ein Peering haben damit die Anrufe direkt via IP rübergehen).. das sollte ohne jegliche Einstellungen so funktionieren. Wenn du fürs Telefonieren aber einen Outbound Proxy brauchst, geht der RTP Strom immer zuerst von dir auf den proxy.. da musst du dann doch einen Direktanruf machen ohne über den Provider zu gehen.
 
Vielen Dank für die Antwort.

habe jetzt von web.de Antwort bekommen, dass bei denen
Audio immer über ihre Server läuft.
Kennt jemand einen Anbieter, bei dem es nicht so ist und wo man keine Grundgebühr zahlen soll ?

Alternativ werde ich wohl eigenes Asterix einrichten müssen.
 
Zuletzt bearbeitet:
Bei Netvoip.ch brauchts keinen Outbound Proxy.. deutsche Anbieter kenne ich kaum, aber sipgate.de hat nen OB, sipcall.de ebenfalls.
Ich bin mir allerdings nicht sicher ob der OB auch wirklich immer nötig ist.. das kannst du unter Umständen mal testen.. der OB wird ja nur für NAT Traversal verwendet. Der Test ist ganz einfach: OB rausnehmen, einmal aufs Mobiltelefon anrufen und checken ob der Sprachkanal noch bidirektional funktioniert, danach dasselbe in umgekehrter Richtung. Wenns geht ist alles gut, wenn nicht brauchst du nen anderen Provider.

sipgate.de gibt aber auch STUN an, und da OB und STUN nicht beide nötig sind, gehts vielleicht auch ohne OB und dafür mit STUN (ich betreibe meinen sipgate.de Account mit OB aber ohne STUN). Da ist jetzt halt leider ein bisschen pröbeln angesagt.

Die andere Lösung mit dem Port Forwarding geht aber auf jeden Fall auch.
 
ich benutze outbound proxy nicht. Nur STUN. Dabei wird rtp audio trotzem via sip proxy von web.de geleitet. Es ist wohl so bei web.de configuriert.
Die Frage ist also nicht ob jeweiliger Provider oupbound proxy hat oder nicht hat, sondern ob rtp audio immer über sip proxy geleitet wird oder nicht.
Und portwordwarding hilft überhaupt nicht, wenn sip proxy so configuriert ist,
dass audio immer nur über proxy geleitet wird (wahrscheinlich wegen Abhörmöglichkeit). Nur wenn ich den Provider nicht benutze, sondern direct ip call machen werde brauche ich PF. Dann kann ich aber nicht mehr ins Festnetz telefonieren. Zumindest mit Grandstream nicht. Die beste Lösung ist wohl eigenes Asterix ...
 
Dabei wird rtp audio trotzem via sip proxy von web.de geleitet. Es ist wohl so bei web.de configuriert.
Bist du dir auch ganz sicher? Hast du den Traffic an deinem WAN Port mal gesnifft? Als media proxy zu agieren macht ja nur mehr Traffic und eigentlich nicht viel Sinn.

Nur wenn ich den Provider nicht benutze, sondern direct ip call machen werde brauche ich PF. Dann kann ich aber nicht mehr ins Festnetz telefonieren.
Wieso denn nicht? Du kannst auf dem SPA3k ganz einfach ein weiteres DP Element einfügen wie oben schon erwähnt.. z.B. <**1|userid@dyndnsip-grandstream:port> .. damit erreichst du durch die Wahl von **1 direkt die Grandstream box, alle anderen Nummern gehen nach wie vor über web.de. Wie das beim Grandstream mit DPs aussieht weiss ich nicht, aber die werden doch hoffentlich auch url dialling unterstützen.

Als Beispiel: ich hab nen SIP Proxy am laufen (SPA9k)... daran ein SPA3k dass den Übergang zur Ascotel ISDN Anlage macht. Wenn ich auf meinen Phones die 9 wähle, baut das Phone eine Direktverbindung zum SPA3k auf, obwohl die Phones am Proxy registriert sind.. uri dialling ist eine Möglichkeit wie man den Proxy umgehen und eine Direktverbindung aufbauen kann.
 
ssteiner schrieb:
Bist du dir auch ganz sicher? Hast du den Traffic an deinem WAN Port mal gesnifft? Als media proxy zu agieren macht ja nur mehr Traffic und eigentlich nicht viel Sinn.
gesnifft habe ich den traffic nicht, aber ich habe die Logs von SPA angesehen -
web.de handelt die codecs zwischen sich und SPA aus und startet dann audio zwischen sich und SPA. Nicht zwischen den ATAs. Support von web.de hat mir es auch bestätigt.

Wieso denn nicht? Du kannst auf dem SPA3k ganz einfach ein weiteres DP Element einfügen wie oben schon erwähnt.. z.B. <**1|userid@dyndnsip-grandstream:port> .. damit erreichst du durch die Wahl von **1 direkt die Grandstream box, alle anderen Nummern gehen nach wie vor über web.de.
Wie das beim Grandstream mit DPs aussieht weiss ich nicht, aber die werden doch hoffentlich auch url dialling unterstützen.
werde mal überprüfen, wie ich es am besten mache ...

Vielen Dank für die Hilfe :)

Würde SPA iLBC nur unterstützen ....


p.s. es sieht so aus, dass grandstream URL dial nicht unterstützt, nur direkt IP dial, dabei muss keine sip proxy configuriert sein.
 
Zuletzt bearbeitet:
so mittlerweile habe ich es geschafft, sipura-> grandstream
per URL dial von dem Telefon der an SPA angeschlossen ist
mit G.723 zu telefonieren (call type 1)
URL als quick dial 4 eingetragen, und dann wähle ich
*017234 (*01723 - g.723 als preffered auswählen)

aber wenn ich von PSTN es so versuche (call type 3) klappt es nicht.
Weiss jemand, wie man per call von PSTN aus den Codec auswählen kann ?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.