[FRAGE] Quelle und Ziel eines Anrufs ändern

[stäubel]

Hallo pwalker

Hmmmm. cid_name ist leer?! Evtl. Müsste noch (im Dialplan, nicht in chan_sip.c) cid_name = cid_num gesetzt werden, falls cid_name nix ist. Oder am snom die Anzeige von Nummer statt Name konfiguriert werden (mindestens zum Testen).

Habe jetzt im Dialplan mal Name und Nummer auf
den gleichen Wert gesetzt:

exten => _1234567,1,SetCIDNum(${CALLERID})  
exten => _1234567,n,SetCIDName(${CALLERID}) 
exten => _1234567,n,Dial(SIP/50,60,TtrHhWwo)             
exten => _1234567,n,Hangup()

Die SIP Meldung sieht nun so aus

Received from udp:192.168.7.4:5060 at 7/12/2009 11:40:13:890 (449 bytes):

INFO sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.4:5060;branch=z9hG4bK7941fa09;rport
From: "Lumpi" <sip:[email protected]>;tag=as214eb2c3
To: <sip:[email protected]:5060>;tag=s648jr82fj
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 104 INFO
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Type: message/sipfrag
Content-Length: 51

From: "Lumpi" <50>
To: "0441234567" <0441234567>

Das Problem besteht jedoch beim SNOM 360
FW 7.1.35 und 7.3.27 weiterhin.

Die richtige Nummer blitzt beim Transfer ganz
kurz auf (nicht mal eine Sekunde)
und es erscheint gleich wieder die interne Nummer.

Scheint als hätte da SNOM wiedermal
einen Fehler eingebaut, denn beim SNOM 320 FW 7.3.27
scheint es nach der Dialplan-Änderung zu funktionieren.
Wenigstens ein kleiner Erfolg.

- Ist das beim semi-attended-Transfer auch so?
Nehme an; A = 0441234567 , B = 50 und C = 80

Was genau meinst du mit semi-attended-Transfer?

Ich kenne irgendwie nur: Attended Transfer (mit Rückfragen)
und Blind Transfer (direkt ohne Rückfragen)

Aber ich glaube ich gebe es nun langsam auf.
Wird doch langsam zu aufwendig.
Und alle SNOMs zu downgraden habe ich irgendwie auch keine Lust

Vielen Dank für deine Hilfe!!!

Grüsse

Stäubel

 

[stäubel]

Hey jetzt gehts doch plötzlich irgendwie.

Habe mal das SNOM 320 aus dem Verkehr genommen,
denn ich hatte meistens von extern auf das 320 angerufen und von
dort weiter vebunden. Das SNOM 320 scheint aber irgend
etwas falsch zu machen.

Nun rufe ich auf ein SNOM 360 und leite es von dort
wieder auf ein SNOM 360 weiter. Und siehe da plötzlich funktionierts.

Bei mir läuft es nun allerdings so ab:

A ruft B an (möchte aber eigentlich mit C reden)
B ruft C an, um zu vermitteln
C nimmt das Gespräch an, bei C wird CallerID von B angezeigt

B vermittelt drückt (Transfer)
C hört nun Musik, bis B das Gespräch mit auflegen endgültig vermittelt

A und C sind miteinander verbunden, bei C wird CallerID CallerName von A angezeigt

Schade ist, dass die Telefonnummer nicht im Menu "Angenommene Anrufe auftaucht".

Aber ich bin jetzt mal wieder recht Happy, denn ich wollte es bald aufgeben

Jetzt muss ich einfach mal schauen was mit dem Weiterverbinden
noch falsch läuft. Oder ist das bei euch auch so?

Grüsse Stäubel

 

[stäubel]

Hallo zusammen

Hier eine mögliche Erklärung wieso die richtige Nummer
manchmal nur kurz aufblitzte.
So wie es aussieht, ist es mit diesem Patch nicht möglich
ohne die Transfer Taste die externe Nummer weiter zu geben.

Wie schon erwähnt funktionierts so:

A ruft B an (möchte aber eigentlich mit C reden)
B ruft C an, um zu vermitteln
C nimmt das Gespräch an, bei C wird CallerID von B angezeigt
B drückt (Transfer)
C hört nun Musik, bis B das Gespräch mit auflegen endgültig vermittelt

wenn B die Transfer Taste auslässt und einfach aufhängt, blitzt beim
Telefon C die externe Nummer nur kurz auf und es erscheint sofort wieder
die interne Nummer von Telefon B.

Grund ist folgender:

Der Patch schickt eine SIP Info Message, die dem Telefon sagt,
es solle die Nummer jetzt durch die externe Nummer ersetzen.

Wenn man mit der Transfer Taste verbindet klappt dies problemlos.

Wenn B allerdings einfach auflegt, schickt der Patch zwar trotzdem
völlig richtig die SIP Info Message.
ABER, Asterisk schickt darauf wieder ein INVITE an das Telefon,
in dem wieder die interne Nummer steht.
Die externe Nummer wird dann also sofort von der internen
Nummer wieder überschrieben.

Das erklärt dann das kurze aufblitzen.

So wie es aussieht ist es also zwingen notwendig auch die Transfer Taste zu drücken.
Die SNOM Einstellung unter Verhalten -> "Transferieren durch Auflegen: An",
hilft da auch nicht weiter. Da bin ich reingefallen!! Wieso es jedoch mit meinem
SNOM 320 nicht funktionierte kann ich noch nicht sagen.

Grüsse Stäubel

 

[pwalker]

Morgen! Ich mal wieder.

Versuche mich gerade im Patchen von Asterisk 1.4 latest (.29) und da ist mir noch folgendes aufgefallen:
Ab Asterisk 1.4.26 ist die Definition des/der Flags SIP_PAGE2_CID_* mit "<< 30" nciht mehr "zulässig"! Seit .26 gibt's nämlich das Flag
#define SIP_PAGE2_RPORT_PRESENT (1 << 30)
seit .27 zusätzlich auch noch
#define SIP_PAGE2_CONSTANT_SSRC (1 << 31)
Auch in den neueren Versionen von Bristuff (solche, die einen neueren Asterisk verwenden) wird dies falschlicherweise nicht beachtet!

Bei patch.asterisk-1.6.0.14.txt ist das etwas anders, da dort "<< 11" verwendet wird. Aber auch das scheint mir nicht ganz lupenrein zu sein, mindestens bei einigen 1.6.x-er-Versionen scheinen mir auch da Flags/Bits doppelt verwendet zu werden!
Übrigens: Ist derselbe Patch wie hier: http://gforge.willwebhosting.de/gf/...ew=markup&sortby=date&sortdir=down&pathrev=98

 

[potc]

Hallo,
die Flags werden in neueren Versionen zum Teil durch neue Features verwendet.
Ich habe IMHO dies aber in meinem 1.6er patch bisher beachtet und die Bits 11 u. 12 sind im 1.6 er noch frei !
Das muss aber nicht beim 1.4er passen.
Wenigstens gibt es bei uns mit dem aktuellen 1.6.0.21 keine Probleme......

peter

 

[pwalker]

"from-change" RFC 4916

Gemäss oej kann snom ab 7.1.33 neben der bekannten - hier gepatchten SIP INFO Methode anscheinend auch "from-change" nach RFC 4916.
(Siehe
http://svnview.digium.com/svn/asterisk/team/oej/calleridupdate/README-calleridupdate.txt?view=markup )
Kann das jemand bestätigen? Bei snom (wiki, release Notes, Google) finde ich nichts... (Müsste in Asterisk 1.6.x eigentlich implementiert sein, glaube ich.)

 

[jackfritt]

Kann es sein das in der 1.4.x pickup und call id besser funktioniert als bei 1.6.2.x ? Oder wie oder was ? Bin gerade aus dem Urlaub wieder da. Sorry für doofe Fragen.

Siehe auch hier

 

[DonVitorio]

Hallo ich suche genau das was hier besprochen wird, dass die Rufnummer auf C angezeigt wird!

Ich habe jedoch bedenken, momentan setzen wir Elastix mit FreePbx + Asterisk 1.4.30 ein!
Gibt es für Asterisk 1.4.30 ein Patch? bzw. kann ich den 1.2 Patch einsetzen?

LG

 

[pwalker]

Gibt es für Asterisk 1.4.30 ein Patch?

Gibt's. Falls der hier nicht zu finden sein sollte, werde ich den in den nächsten Tagen mal noch hochladen.

kann ich den 1.2 Patch einsetzen?

NEEEIIIN!

 

[DonVitorio]

Gibt's. Falls der hier nicht zu finden sein sollte, werde ich den in den nächsten Tagen mal noch hochladen.

Ich habe hier im Thread gesucht aber leider nichts gefunden.

Kannst du es bitte hochladen?

LG

 

[pwalker]

Etwas weiter vorne (so ca. ab Beitrag #4) steht zwar recht detailliert, wie man sich den Patch von Hand baut, aber da ich ja so ein netter Mensch bin , hier noch der fertige Patch für Asterisk 1.4.30.

 

[Message]

...hier noch ein Patch dazu für einen "nackten" (d.h. ohne Bristuff) 1.2er-Asterisk (getestet mit Asterisk 1.2.24 mit "call answererd elsewhere"-Patch bereits drin, kann deshalb evtl. Offsets geben beim applyen

hi. eine vermutlich ganz blöde frage, aber wie binde ich den patch ein? muss ich dazu asterisk neu kompilieren (was ich nicht kann da wir eine cpbx anlage haben) oder reicht es den code in eine *.conf datei einzutragen?

 

[pwalker]

hi. eine vermutlich ganz blöde frage

"Blöde" ist übertrieben, aber... ;-)

aber wie binde ich den patch ein? muss ich dazu asterisk neu kompilieren

Genau. Patchen heisst, Patch auf Asterisk-Sourcecode anwenden ("applyen") und Asterisk neu kompilieren.

(was ich nicht kann da wir eine cpbx anlage haben)

Genau. Kannst Du nicht - Finger weg! ;-)

 

[chris-toph]

Gibt es den Patch zufällig auch für eine 1.4.39 ?

Leider gibt es hier ein Problem bei dem Patchen....

(chan_sip.c.rej)

***************
*** 813,822 ****
  #define SIP_PAGE2_RPORT_PRESENT         (1 << 30)       /*!< 30: Was rport received in the Via header? */
  #define SIP_PAGE2_CONSTANT_SSRC         (1 << 31)       /*!< 31: Don't change SSRC on reinvite */
  
  #define SIP_PAGE2_FLAGS_TO_COPY \
        (SIP_PAGE2_ALLOWSUBSCRIBE | SIP_PAGE2_ALLOWOVERLAP | SIP_PAGE2_VIDEOSUPPORT | \
        SIP_PAGE2_T38SUPPORT | SIP_PAGE2_RFC2833_COMPENSATE | SIP_PAGE2_BUGGY_MWI | \
-       SIP_PAGE2_UDPTL_DESTINATION | SIP_PAGE2_CONSTANT_SSRC)
  
  /* SIP packet flags */
  #define SIP_PKT_DEBUG         (1 << 0)        /*!< Debug this packet */
--- 813,828 ----
  #define SIP_PAGE2_RPORT_PRESENT         (1 << 30)       /*!< 30: Was rport received in the Via header? */
  #define SIP_PAGE2_CONSTANT_SSRC         (1 << 31)       /*!< 31: Don't change SSRC on reinvite */
  
+ #define SIP_PAGE2_CID_UPDATE          (3 << 7)
+ #define SIP_PAGE2_CID_UPDATE_NEVER    (0 << 7)
+ #define SIP_PAGE2_CID_UPDATE_INFO     (1 << 7)
+ #define SIP_PAGE2_CID_UPDATE_REINVITE (2 << 7)
+ 
  #define SIP_PAGE2_FLAGS_TO_COPY \
        (SIP_PAGE2_ALLOWSUBSCRIBE | SIP_PAGE2_ALLOWOVERLAP | SIP_PAGE2_VIDEOSUPPORT | \
        SIP_PAGE2_T38SUPPORT | SIP_PAGE2_RFC2833_COMPENSATE | SIP_PAGE2_BUGGY_MWI | \
+       SIP_PAGE2_UDPTL_DESTINATION | SIP_PAGE2_CONSTANT_SSRC | \
+       SIP_PAGE2_CID_UPDATE)
  
  /* SIP packet flags */
  #define SIP_PKT_DEBUG         (1 << 0)        /*!< Debug this packet */

Danke !

 

[pwalker]

Patch für 1.4.42 wäre vorhanden.