Audio nur in eine Richtung

[ceicke]

Hallo!

Ich habe folgendes Problem: bei eingehenden Anrufen kann ich den Anrufer nicht hören, der Anrufer kann mich aber hören, bei Telefonaten die ich beginne können beide Seiten sich gegenseitig hören. Das ganze läuft über SIP bei sipgate.de mit einem Asterisk 1.0.8
Ich dachte mir zuerst, das dies ja ein klassisches Firewall Problem ist, das die RTP Ports von außen blockiert sind. Ein schneller Blick auf iptables sagt aber folgendes:

gateway / # iptables -vL
Chain INPUT (policy ACCEPT 649K packets, 367M bytes)
 pkts bytes target     prot opt in     out     source               destination
 186K   21M ACCEPT     all  --  lo     any     anywhere             anywhere
  11M 8662M ACCEPT     all  --  eth1   any     192.168.126.0/24     anywhere
 129K   17M ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:5060
 703K  139M ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpts:10000:20000
 4233  793K ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:4569
 240K  284M ACCEPT     all  --  eth1   any     anywhere             anywhere            state ESTABLISHED
 640K   68M REJECT     all  --  eth1   any     anywhere             anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 4632 packets, 3433K bytes)
 pkts bytes target     prot opt in     out     source               destination
3705K 3268M ACCEPT     all  --  eth1   any     anywhere             192.168.126.0/24
2892K  248M ACCEPT     all  --  eth1   any     192.168.126.0/24     anywhere

Chain OUTPUT (policy ACCEPT 14M packets, 5311M bytes)
 pkts bytes target     prot opt in     out     source               destination

Also sollten eigentlich die RTP Ports offen sein. Der Asterisk Server sitzt in der DMZ von meinem LAN. Die Registrierung bei sipgate.de klappt auch wunderbar. Habe ich irgendwas übersehen?

Danke,
Christoph

 

[Guard-X]

Ein Blick auf deine sip.conf wäre sinvoll...

 

[zoo]

und ein tcpdump auf dem gateway wäre auch sinnvoll.
Klar müssen die RTP-Ports zum Asterisk offen sein.

 

[ceicke]

Stimmt, ist 'ne gute Idee, hier ist sie also die sip.conf

[general]
port = 5060
bindaddr = 0.0.0.0
context = default
register => 4319836:[email protected]/4319836

[4319836]
type=peer
username=4319836
fromuser=4319836
secret=passwort
context=default
host=sipgate.de
fromdomain=sipgate.de
insecure=very
caninvite=no
canreinvite=no
nat=no
disallow=all
allow=ulaw
allow=alaw

[sipgate_de_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=incoming
disallow=all
allow=ulaw
allow=alaw

[30]
type = friend
secret = 30
mailbox = 30
host = dynamic
context = default
canreinvite = yes

und hier noch mal der relevante Ausschnitt aus der extensions.conf

[default]
exten => _0.,1,NoOp(call via sipgate.de)
exten => _0.,2,Ringing
exten => _0.,3,SetCallerID(Christoph Eicke)
exten => _0.,4,Dial(SIP/${EXTEN:1}@4319836,60)
exten => _0.,5,Hangup

[incoming]
exten => 4319836,1,NoOp(Incoming call on sipgate.de)
exten => 4319836,2,Ringing
exten => 4319836,3,SetCallerID(${CALLERID})
exten => 4319836,4,Dial(SIP/30,20)
exten => 4319836,5,VoiceMail(su30)
exten => 4319836,6,Hangup

Das Setup ist so, dass ich an dem Asterisk Server ein Grandstream ATA386 dran habe, welches auf der anderen Seite ein altes W48 dran hat. Wenn ein Anruf über sipgate.de reinkommt, wird dieser also an die 30 (ATA386) weitergeleitet. Andersherum geht wie gesagt alles wunderbar.

Ein tcpdump habe ich auch gemacht, anscheinend kommen keine RTP Pakete an, die gehen nur raus. Das war auch der Grund warum ich darauf geschlossen habe, dass es ein iptables Problem ist, aber wenn alle Einträge aus iptables raus sind und der Asterisk in der DMZ hängt dürfte das ja eigentlich nicht passieren. Ich kann mir kaum vorstellen das sipgate.de Probleme hat, dann wäre hier im Forum sicher die Hölle los ;-)

Für jegliche weitere Gedankenanstöße bin ich sehr dankbar!

Gruß,
Christoph

 

[ceicke]

Es scheint das Problem zu sein, das Asterisk die Daten über SIP nicht weiterschickt die es empfängt. Als ich nicht da war, hat mir jemand erfolgreich auf die Mailbox sprechen können, die Person hat auch meine Ansage gehört.
Irgendwelche Ideen?

Gruß,
Christoph

 

[frankjung]

hi ceicke,
hast du dein problem gelöst? ich habe das gleiche problem.
ich habe zusätzlich noch ein isdn telefon an einer karte im
nt mode. mit dem telefon klappt es in beide richtungen.
ansonsten das gleiche problem.
gruss frank

 

[Hupe]

Du benutzt den Sip-Client (ATA386) also im lokalen Netz? dann würde ich erstmal "canreinvite = no" setzen.
Außerdem würde ein direktes Port-Forwarding auf den Asterisk mach (also die Ports, die Asterisk auch wirklich braucht). Das mit dem DMZ-gedönse hat schon öfters mal Probleme gemacht.

 

[ceicke]

reinvite=yes war das Problem. Asterisk hat sich beim Zustandekommen der Verbindung natürlich aus dem Datenstrom ausgeklinkt und da der ATA386 natürlich nur im internen Netz stand, war er nicht von außen erreichbar.
Danke für die Hilfe. DMZ funktioniert allerdings tadellos.

Gruß,
Christoph

 

[frankjung]

@Hupe
@ceicke
reinvite=yes war bei mir auch das problem. mit dem isdn-telefon
funktionierte alles. es waren beide teilnehmer zu hören. klar,
da die ganze kommunikation bei der version über den asterisk-server
laufen muss! vielen dank für den tip!!!
gruss frank

 

[blauerpeti]

..jetzt muss ich aber mal frgane..wie kommt ihr auf:
reinvite=yes
ich finde diesen eintrag nirgends, oder meint ihr
caninvite=no
canreinvite=no
nur wie hab ihr das dann gesetzt, steht ja mal auf yes und mal auf no

 

[Hupe]

So wie ich das seher gibt es sowieso nur die option "canreinvite". Der rest ist wirkungslos.

 

[frankjung]

@blauerpeti
das gibt nur die option canreinvite=yes/no. wir meinten natürlich canreinvite!
durch den schalter =no wird verhindert, dass asterisk sich aus der kommunikation ausklingt. sprich, nach aufbau der signal-session (sip), wird der weitere ablauf (rtp) nicht dem client übergeben. deswegen war die funktion mit
dem isdn-telefon auch gegeben, trotz canreinvite=yes! die kommunikation kann nur über den asterisk laufen, da ein isdn-telefon per netzwerkprotokoll nicht erreichbar ist. hfc---asterisk---hfc. wir werden uns das nächste mal genauer ausdrücken! sorry. für das missverständnis!
gruss frank

 

[eggman]

Auch wenn das Problem gelöst zu sein scheint, ich hatte die Tage bei einem Kunden ein ähnliches Problem:

Da der Asterisk-Server hinter einer NAT-Firewall steht, hatte ich in die /etc/hosts eingetragen

<interne IP> <dynamischer DNS-Name>

so dass der Rechner sich mit seinem dyndns-Namen auch selbst ansprechen kann. Dies hatte allerdings zur Folge, dass bei einer SIP-Verbindung nur noch Stimme in eine Richtung zu hören war.

Vielleicht hilft es ja jemand, der das gleiche Problem hat und über diesen Thread stolpert.

Frohe Weihnachten,

eggman

 

[Hupe]

Auch wenn das Problem gelöst zu sein scheint, ich hatte die Tage bei einem Kunden ein ähnliches Problem:

Da der Asterisk-Server hinter einer NAT-Firewall steht, hatte ich in die /etc/hosts eingetragen

<interne IP> <dynamischer DNS-Name>

so dass der Rechner sich mit seinem dyndns-Namen auch selbst ansprechen kann. Dies hatte allerdings zur Folge, dass bei einer SIP-Verbindung nur noch Stimme in eine Richtung zu hören war.

Vielleicht hilft es ja jemand, der das gleiche Problem hat und über diesen Thread stolpert.

Frohe Weihnachten,

eggman

Also, Asterisk übermittelt die externe Ip (bzw den Dyndns-Namen und die daraus resultierende IP) an das gegenüber. Wenn Du die interne Ip mit dem dyndns-Namen in der hosts-Datei verknüpfst, dann teilst Du Deinem Gengenüber Deine interne IP als die Adresse mit, unter der man Dich erreichen kann. Kann man aber eben von extern nicht. Da sind die internen Ips nicht gültig. In Folge dessen schickst Du die Sprachpakete ins Nirvana.