Asterisk 1.2.4 und Zaptel 1.2.3 released

[schef4711]

Könntest du das bitte mit einem anschaulichen Beispiel erklärend untermauern? Schwerpunkt möge bitte auf Routing liegen.

gerne,

Generell gilt mal z.B. Client (Protokoll egal) baut Verbindung zu einem * Server auf bzw. dieser Baut eine andere Verbindung weiter auf :

beispiel SIP/IAX2 (ohne SRV) :

SIP/IAX2 Verbindung (z.B. peer) mit einer IP-Adresse bzw. Namen zu einem anderen Server welcher auf normalen DNS-Service (Namensaufloesung) basiert. Somit waere, wenn ein Routingfehler vorliegt diese Verbindung nicht erreichbar.

beispiel SIP/IAX2 (mit SRV) :

SIP/IAX2 Verbindung (z.B. provider) mit einem fixen Namen zu einem anderen Server welcher aber im DNS-Service auch "IN SRV" Records eingetragen hat. Somit waere theoretisch die Moeglichkeit da, wenn eine Route davon probleme basiert, dass er aufgrund der Gewichtigkeit automatisch zu einem anderen Server/IP-Adresse weitergeleitet wird.


Somit ist es gerade bei SIP/IAX2 sinnvoll, wenn man auf 2 oder mehrere unterschiedliche Routen/Servern basiert die Erreichbarkeit wesentlich zu erhoehen, da sich um das Routing dann das "IN SRV" kuemmert und automatisch die Route verfolgt welche halt erreichbar ist.

Beispiel im DNS (SRV) :

domainname.xx.        IN A 100.100.100.100
sec                       IN A 200.200.200.200
_sip._udp               IN SRV  20 0 5060       domainname.xx.
_sip._udp               IN SRV  30 0 5060       sec.domainname.xx.

hier wuerde somit wenn die Route 20 (hoechste Wichtigkeit) nicht erreichbar ist automatisch die Route 30 (niedrigere Wichtigkeit) zu tragen kommen. Somit kann man, wenn man mehrere Verbindungen hat (was fuer einen zentralen Asterisk wichtig ist) somit ohne Trouble auf einen Backup umschalten ohne das der Client/Kunde etwas davon merkt.

Wichtig ist halt nur, das auch dann die DNS via unterschiedlichen Seiten erreichbar sind weil sonst hat das ganze eher weniger Sinn *gg*

Weitere Angaben (in english) findet man unter http://www.voip-info.org/wiki/view/DNS+SRV wo noch weitere Erklaerungen drinnen sind. Moeglich ist dieses SRV auch fuer STUN-Server nach dem gleichen Prinzip.

Viele vergessen halt leider IAX und STUN auch einzutragen bzw. sehr viele kennen diese Moeglichkeit ueberhaupt nicht. Problem ist eben, das SIP meistens auf eine SIP-URI zugreift und somit die Problematik enstehen kann wenn eine Route nicht da ist. IAX basiert halt nur auf einen Namen oder IP im Background.

Sollten noch Fragen sein einfach Fragen

Gruss
Alex

 

[schef4711]

Aja,

noch vergessen. Mit dem ganzen kann man auch sehr schoen ein LoadBalancing machen. Siehe hierzu den Link den ich angegeben hab, dort ist ein Beispiel samt Erklaerung drinnen.

Gruss
Alex

 

[ramazz0tti]

moin,

hier auch soweit unfallfrei von 1.2.3 auf 1.2.4 vorerst aufm testsystem (+) geupdatet.

edit:
bidirektionaler oralflatulenztransfer iax->sip und sip->iax sowie beides an misdn unproblematisch, transparente datenverbindungen (X.75) per misdn auch.

eher noch schlimmer als vorher, statt /etc/init.d/misdn-init restart ist jetzt der oefteren ein kompletter reboot faellig.

btw, was mir noch aufgefallen ist mit einem eeh ELink310/343:

misdn:
at\d9
Pruefe auf Protokoll 1TR6 .... keine Antwort.
Pruefe auf Protokoll EDSS1 ... keine Antwort.
Fehler in Diagnosefunktion. Default ist EDSS-1.

sirrix PCI4S0:
at\d9
Pruefe auf Protokoll 1TR6 .... keine Antwort.
Pruefe auf Protokoll EDSS1 ... OK.

scheint also doch, dass da tatsaechlich noch "extrem sehr viel zeit" gebraucht wird bei misdn ...

analog-alaw mit usr v.evt oder elsa ml56k per pa186v-ata an ein zyxel 2864ID an misdn schmeisst immer noch jede menge dsp-kernelmeldungen und "P[ 1] Misdn Jitterbuffer Overflow." - aber dies scheint eh noch ein gebiet separater optimierungen zu sein, zumal ich das ganze mit dem sirrix channeltreiber auf dem produktivsystem (*) noch nicht getestet hab ...

 

[betateilchen]

SIP baut im Endeffekt die Verbindung zum Teilnehmer anders auf als IAX2 und somit kanns schon sein das dann gewisse Routen nicht funktionieren aber andere dann wieder schon.

Der Unterschied zwischen IAX und SIP war mir schon klar Aber Deine (recht gute) Erklärung paßt trotzdem nicht zu dem Problem, das bei mir vorlag - es war schlichtweg ein Hardwareproblem im Rechenzentrum.

 

[schef4711]

Der Unterschied zwischen IAX und SIP war mir schon klar Aber Deine (recht gute) Erklärung paßt trotzdem nicht zu dem Problem, das bei mir vorlag - es war schlichtweg ein Hardwareproblem im Rechenzentrum.

Also wenn es ein Hardwareproblem war dann geht ganz sicher beides davon nicht - es sei denn, so wie erklaert, dass IAX ueber "Hardware funkt" und SIP ueber "Hardware defekt" gelaufen ist - wodurch wir wieder beim Routing-Thema waeren

Gruss
Alex