Standortkopplung VOIP

[SunSeb]

Moin!

Ich habe mich mal an einer Kopplung zweier Standorte per VOIP versucht. Die beiden sind jeweils mit 1722 über VPN miteinander verbunden.

1. Szenario: Peer to Peer. Hierbei kann ich im Callrouter verfolgen, dass der Ruf an die andere Domäne geleitet wird - es kommt aber leider keine Signalisierung durch. (Registrierung SIP-PBX ist im LanMonitor erfolgreich)

2. Szenario: Anmeldung eines VOIP-Telefones am 1722 der Gegenstelle. Das funktioniert in soweit, dass die Signalisierung funktioniert. Es kommt aber im Folgenden kein Gespräch zu stande.

Bevor ich irgendwelche wilden SIP-Traces poste, wollte ich erstmal fragen, welche Erfahrungen in diesem Bereich gemacht werden (bisher kein Posting).

Gruß,
SEBastian

[tunichtgut]

Hi,

ich hab hier solches VPN Szenario problemlos am laufen, zwei 1722, PBX Leitungen über Kreuz, jeweils eineAgfeo TK am NT, daran Systemtelefone, dazu verschiedene Software Clients und Voip Telefone in den Netzen...

Vergiss nicht eine DNS Weiterleitung der VOIP Domäne der Gegenseite auf die VPN Gegenstelle einzurichten. Auf die SIP Nummern der gegeseite jeweils Call Routern anlegen, damit die rufe per PBX rausgehen.

[SunSeb]

Moin!

Ich habe nochmal ein wenig konfiguriert. Der Callmanager bricht aber dann mit folgender Fehlermeldung ab:

[Callmanager] 2006/03/20 15:45:33,400
From: 201@sipbeuel
To : 100@sipesm
Info: Bandwidth reservation (Tx=80kBit/s, Rx=80kBit/s) succeeded

[Callmanager] 2006/03/20 15:45:33,410

Disconnect: 100@sipesm Cause:3

Vielleicht könnte jemand den Cause:3 erläutern...

Gruß+Danke,
SEBastian

[SunSeb]

Moin!

Wollte mich nochmal kurz melden und ganz herzlich bedanken...

Nun funktioniert es einwandfrei! Super, super, super!

Vergiss nicht eine DNS Weiterleitung der VOIP Domäne der Gegenseite auf die VPN Gegenstelle einzurichten.

Genau das war der richtige Hinweis.

Gruß,
SEBastian

[SunSeb]

Moin!

Habe momentan mit der 6.11 Probleme mit der P2P Verbindung der beiden 1722 über VPN. Der Verbindung lief bisher stabil und problemlos.

Nach dem Update waren im LanMonitor die beiden PBX-Gegenstellen nicht zu erreichen (rotes Ausrufezeichen). Ich habe dann als Registrar die Gegenstelle bei der jeweiligen SIP-PBX-Definition eingetragen. Danach schien die Gegenstelle lt. LanMonitor zu funktionieren.

Telefonieren ist dennoch z.Z. P2P über die VPN-Verbindung nicht möglich. Der SIP-Trace zeigt das Problem. Die INVITE-Message wird an 0.0.0.0:5060 in die ewigen Jagdgründe geschickt? Warum?

Gruß,
SEBastian

[tunichtgut]

Ich habe dann als Registrar die Gegenstelle bei der jeweiligen SIP-PBX-Definition eingetragen.
Telefonieren ist dennoch z.Z. P2P über die VPN-Verbindung nicht möglich. Der SIP-Trace zeigt das Problem. Die INVITE-Message wird an 0.0.0.0:5060 in die ewigen Jagdgründe geschickt? Warum?

Hi,

bei mir funktioniert das wie gehabt. Statt der SIP Domäne der Gegenstelle die Gegenstelle selbst einzutragen ist natürlich grober Unfug. Eine DNS Anfrage auf den Gegenstellennamen kann nur 0.0.0.0 zurückgeben.

[SunSeb]

Moin,

bei mir funktioniert das wie gehabt. Statt der SIP Domäne der Gegenstelle die Gegenstelle selbst einzutragen ist natürlich grober Unfug. Eine DNS Anfrage auf den Gegenstellennamen kann nur 0.0.0.0 zurückgeben.

Gut - habe mich ein wenig ungenau ausgedrückt - meinte schon die SIPDomäne der Gegenstelle. Habe diese wieder herausgenommen und wieder folgende Eintragungen gemacht

Code: Alles auswählen

root@Mimas:/Setup/Voice-Call-Manager/Line/SIP-PBX
> l pbx

Name               Domain                                                            Rtg-Tag
                Registrar                                                         Outb-proxy
                            Cln-Prefix  Line-Prefix   Codecs    Codec-Order  Active  Kommentar

----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
-----------------------------
PBXBEUEL           sipbeuel                                                          0

                                                      00000000  Unchanged    ja

und

Code: Alles auswählen

root@Mimas:/Setup/DNS/DNS-Weiterleitungen
> l

Domainname                                                        Gegenstelle
----------------------------------------------------------------------------------
*.sipbeuel                                                        10.1.1.3

Die Gegenstelle ist exact entsprechend konfiguriert. Diese Einstellungen funktionieren unter der 6.06. Unter der 6.10 kommt: Ziel nicht erreichbar mit besetzt.

Danke für die Mühe,
SEBastian

[tunichtgut]

Hi,

aha. Da hört sich schon anders an, also wird die DNS Anfrage auf die SIP domain der Gegenseite nicht beantwortet.

Trag in die PBX Leitung zunächst wieder die SIP domäne der Gegenstelle ein, denn die gehört da rein. In die DNS Weiterleitung trägt du dann auch genau diese Domäne ein und die Gegenstelle über die sie erreichbar ist, nicht irgendeine IP im remote Netz. Wenn immer noch 0.0.0.0 zurückgeliefert wird mach mal auf beiden Seiten einen DNS trace, damit wir sehen was aus der DNS Anfrage wird.

Du machst nicht zufällig loadbalancing ?

[SunSeb]

So,

tut mir leid, daß das ein wenig zäh läuft...

Habe die Eintragungen genauso vorgenommen. Dabei ist mir folgendes bei der DNS-Weiterleitung aufgefallen:
Trage ich die Gegenstelle (hier: BEUEL) ein, so wird der Name nicht aufgelöst bzw. erhalte ich keine Antwort. Trage ich aber die IP-Adresse des 1722 (10.1.1.3) im anderen Netz ein, so wird der Service so aufgelöst:

Code: Alles auswählen

[DNS] 2006/05/22 12:56:05,400
DNS Rx (intern): Src-IP 10.10.1.1
Name Query: SRV for _sip._udp.sipbeuel
DnsGetDest: Match found: forwarding _sip._udp.sipbeuel to route 10.1.1.3
Not found in local DNS database => forward to next server
NameQuery: Forward to server 10.1.1.3

[...]

[DNS] 2006/05/22 12:56:05,520
DNS Rx (BEUEL): Src-IP 10.1.1.3
Name Response:
SRV for _sip._udp.sipbeuel resolved to Elara.intern:5060 - Sending request

SEBastian

[tunichtgut]

Hi,

so kommen wir nicht weiter. Schick mal die Configs.