Zwei+ Sipgateämter - keine Trennung der Ämter

[DOCURA]

Ich bin bei meinen Tests auf einen interessantes Problem gestoßen.

Wenn ich zwei unterschiedliche Sipgate Zugänge unter Ämtern einrichte, werden diese zwar sauber eingerichtet. Rufe ich die beiden Ämter jetzt an, sind auch beide Nummern erreichbar, aber ich habe hier keine Möglichkeit diese über die Einstellungen bei *Eingehende Rufe *zu unterscheiden.

Jetzt habe ich hier mal versucht dem Problem auf den Grund zu gehen und habe folgenden Fehler gefunden.

SIPGATE Infos:

Nummer 1: Tel: 00492XXXXXXX90 ID: 77XXXX7
Nummer 2: Tel: 00492XXXXXXX29 ID: 48XXXX6

Wenn ein eingehender Anruf kommt scheint Astrisk das Problem zu haben diese Beiden Zugänge zu trennen.

s. Log

== Manager ‘phpasm’ logged off from 127.0.0.1
– Executing Set(“SIP/48XXXX6-bXXXXX18”, “MDC_DN=<sip:00492XXXXXXX90@sipgate.de>”) in new stack
– Executing Set(“SIP/48XXXX6-bXXXXX18”, “MDC_DN=00492XXXXXXX90@sipgate.de>”) in new stack
– Executing Set(“SIP/48XXXX6-bXXXXX18”, “MDC_DN=00492XXXXXXX90”) in new stack
– Executing Goto(“SIP/48XXXX6-bXXXXX18”, “mdc_trunk-6|90|1”) in new stack
.
.
.
– SIP/test-081dada0 is ringing
– SIP/test-081dada0 is ringing
– SIP/test-081dada0 is ringing
== Spawn extension (mdc_main-60-ext, 60, 1) exited non-zero on ‘SIP/48XXXX6-bXXXXX18’
– Executing Macro(“SIP/48XXXX6-bXXXXX18”, “hangup||CANCEL|”) in new stack
– Executing NoOp(“SIP/48XXXX6-bXXXXX18”, ">>>macro-hangup:: EXTEN: DIALSTATUS: CANCEL QUEUESTATUS: ") in new stack

Neue Einwahl:
– Executing Set(“SIP/48XXXX6-bXXXXX78”, “MDC_DN=<sip:00492XXXXXXX29@sipgate.de>”) in new stack
– Executing Set(“SIP/48XXXX6-bXXXXX78”, “MDC_DN=00492XXXXXXX29@sipgate.de>”) in new stack
– Executing Set(“SIP/48XXXX6-bXXXXX78”, “MDC_DN=00492XXXXXXX29”) in new stack
– Executing Goto(“SIP/48XXXX6-bXXXXX78”, “mdc_trunk-6|29|1”) in new stack
.
.
.
– SIP/HeitzerV-081dada0 is ringing
– SIP/HeitzerV-081dada0 is ringing
– SIP/HeitzerV-081dada0 is ringing
– SIP/HeitzerV-081dada0 is ringing
– Stopped music on hold on SIP/48XXXX6-bXXXXX78
== Spawn extension (mdc_main-800-ext, 800, 2) exited non-zero on ‘SIP/48XXXX6-bXXXXX78’
– Executing Macro(“SIP/48XXXX6-bXXXXX78”, “hangup|||”) in new stack
– Executing NoOp(“SIP/48XXXX6-bXXXXX78”, ">>>macro-hangup:: EXTEN: DIALSTATUS: QUEUESTATUS: ") in new stack

Bei dem ersten Anruf der über Amt ID: 77XXXX7 kommt, kann man sehen das hier trotzdem die ID von Amt zwei ausgegeben wird. Ich denke das ist eigentlich nicht so richtig!?

Ich habe hier zwar eine Möglichkeit gefunden über die Zielnummer bei den Rufeingängen, aber dies ist glaube ich auch keine richtige Lösung.

Noch als letzten Punkt: es wird immer die Sipgate ID genutzt, von der das Amt als letztes angelegt worden ist.

Ich hoffe ich habe jetzt nicht all zu viel Kauderwelsch geschrieben, und es kann noch jemand verstehen!!

Gruß Volker

[Mathias]

Hallo Volker,

ja, das ist leider ein allgemeines Asterisk Problem. Vorweg: Man kann es lösen, ist aber etwas komplizierter zu verstehen ;-). Ich versuche mich mal an der Erklärung. Eine Asterisk-Peer-Registrierung sieht z.B. so aus:

sip show peers

sipgateid1              217.10.79.9        D          5060     OK (17 ms)
sipgateid2              217.10.79.9        D          5060     OK (20 ms)

Asterisk kann diese peers bei einem eingehenden Anruf also anhand des Username, der IP und des Ports unterscheiden. Da es sich in beiden Fällen um Sipgate handelt sind IP und Port, logischer weise, gleich.

Bleibt also der Username. Das Peer muss also sagen “ich bin sipgateid1” und Asterisk kann das dann unterscheiden. Handelt es sich bei dem Peer um ein Telefon macht das das auch, sagt z.B: “ich bin mmuster” und Asterisk kann das zuordnen.

Ist das Peer aber ein Provider sagt der, je nach Anrufer, “ich bin 09912700699” oder “ich bin 01744444”.

Damit Asterisk trotzdem einen Anruf dieses Peers nimmt gibt es den Schalter “insecure=invite”. Das bedeutet: Uns ist egal ob der Username übereinstimmt akzeptiere den Anruf sobald IP und Port übereinstimmen.

Und da !!! das Disaster: IP und Port sind bei beiden Sipgate peers gleich.

Dann nimmt Asterisk einfach das erste der beiden Peers in der Liste; glücklicherweise immer. Das erste der Peers ist also eine Art “Sammeleingang”. Also einfach alle Eingangsregeln auf das erste Peer legen, dann klappts, hat sonst keine weiteren Seiteneffekte.

Aber Vorsicht, die Reihenfolge von “sip show peers” entscheidet nicht die vom MobyDick oder der /etc/asterisk/sip.conf.mdc.

Nochwas zu dem insecure Parameter. Oft liest man “insecure=very”. Das bedeutet “insecure=port” und insecure=invite", dann ist bei der Entscheidungsfindung auch noch der Port egal.

Hoffe das einigermaßen verständlich erklärt zu haben.

LG
Mathias

[DOCURA]

JAP hast du!!

Also ist der Workaround, den ich oben beschrieben habe also schon die Lösung unseres Problems, und es gibt hier keine andere.

Das ist zwar nicht ganz so nett, aber absolut zu verkraften!! g

Für alle die diesen Tread evtl. noch brauchen. Die Eingangsregeln im MobyDick alle auf den ersten (in meinem Fall) Sipgate Pree einstellen, und bei Ziel die letzten zwei Ziffern der von Sipgate vergebenen Nummer eintragen.

Ab dem Punkt kann man wie gewohnt mit den Regeln weiterarbeiten, und z.B. zu einer Durchwahlnummer weiterleiten.

Danke & Gruß

Volker