[FRAGE] Quelle und Ziel eines Anrufs ändern

[anhalter42]

Uuups - natürlich: Ihr spracht ja weiter oben von "call answered elsewhere". Pardon.

Trotzdem meine Frage: wie komme ich - entweder im Dialplan oder im Manager Interface oder was weiß ich - an die Call-ID heran?

Ich finde Deine Arbeit um den Patch ehrenwert, möchte aber, da ich schonmal mit bristuff gepatcht habe, bei unserem System nicht noch einen zweiten Patch draufsetzen - bei produktiven Systemen bin ich da erzkonservativ. Das ist eigentlich der ganze Grund, das "parallel" zu betreiben.

Zu den Updates des Display im Gespräch erhielt ich von Snom-Support die Nachricht, dass es mit der kommenden Firmware-Version, die Mitte/Ende April kommen soll, gehen soll. Das irritiert mich ein wenig, denn mit Asterisk-1.2.20.4-bristuffed (0.3.0-PRE-1y-w) geht das Display-Update bei einem Transfer schon mit der 7.1.39 Firmware prima.

 

[potc]

Hallo,
damit sollte es auch mit 1.6.0.14 gehen

peter

 

[speedy1980]

Hast Du den Patch schon mal auf der Asterisk-Developer Mailingliste oder im Bugtracker gepostet? Da haben doch sicher viele Leute Interesse dran.

 

[potc]

Nein habe ich nicht.

Da es ja gerüchtweise mit 1.6.2 gehen soll und diese patches nun wirklich nicht unbekannt sind (immerhin ist bripatch die Basis und die sind hinlänglich bekannt) sehe ich da keinen Sinn darin.

Btw. kann derzeit auch nur das Vermittlungsziel upgedatet werden die Information über den vermittelten habe ich leider nicht, dieser bekommt nur die alte Nummer angezeigt und von daher ist die Lösung nicht vollkommen befriedigend

 

[pwalker]

Da es ja gerüchtweise mit 1.6.2 gehen soll und diese patches nun wirklich nicht unbekannt sind (immerhin ist bripatch die Basis und die sind hinlänglich bekannt) sehe ich da keinen Sinn darin.

Habe extra noch den trunk und 1.6.2 aus SVN geholt, und dazu finde ich nichts.

Btw. kann derzeit auch nur das Vermittlungsziel upgedatet werden die Information über den vermittelten habe ich leider nicht, dieser bekommt nur die alte Nummer angezeigt und von daher ist die Lösung nicht vollkommen befriedigend

??? Kapiere ich nicht ganz. Könnte es evtl. sein, dass Du da etwas durcheinander bringst bzw. mit dem Pickup-Patch verwechselst?

Gruss,
Philipp

 

[potc]

??? Kapiere ich nicht ganz. Könnte es evtl. sein, dass Du da etwas durcheinander bringst bzw. mit dem Pickup-Patch verwechselst?

Ich kann nur die Nummer beim Vermittlungsziel ändern, nicht bei der Quelle da wir nur die Nummer des Anrufers haben aber nicht die Nummer des angerufenen, warum auch immer.

Also A ruft B an B verbindet auf C.
C Bekommt Nummer von A angezeigt aber A nicht Nummer von C da mir diese Info fehlt

peter

 

[pwalker]

Also A ruft B an B verbindet auf C.
C Bekommt Nummer von A angezeigt aber A nicht Nummer von C da mir diese Info fehlt

Ach so, nun kapiere auch ich das. Das habe ich aber bisher auch noch nie so gesehen bzw. sehe das Bedürfnis dafür nicht. Finde das Verhalten wie beschrieben prima.
...und weitere spontane Gründe dagegen:
- speziell wenn A ein externer Anrufer ist, geht das i.d.R. gar nicht
- ist evtl. gar nicht gewollt, dass der Anrufende (A) die Nummer von C sieht
- Bei einer Weiterleitung (Call Forward) wird die Nummer (bei A) ja auch nicht aktualisiert.
Kurz: A soll - meiner Ansicht nach - immer die von ihm gewählte Nummer sehen. Punkt.

 

[potc]

Kurz: A soll - meiner Ansicht nach - immer die von ihm gewählte Nummer sehen. Punkt.

Das ist Geschmackssache. Das es nach extern nicht geht hängt nur am Provider.
Intern ist das wieder was ganz anderes da wir eine große Firma sind und dort auch andauernd weiterverbunden wird ist es intern doch ganz Nett die richtige Nummer zu sehen.

Ich kenne auch Projekte wo dieses eine ganz wichtige Sache ist das Quelle und Ziel immer richtig dargestellt werden müssen...

peter

 

[jackfritt]

Kurze Frage, für 1.6.2.0-rc6 gibs jede Menge rejects.

patch -p1 < ../SIP_ID.patch
patching file channels/chan_sip.c
Hunk #1 FAILED at 1001.
Hunk #2 succeeded at 2293 with fuzz 1 (offset 545 lines).
Hunk #3 succeeded at 11833 (offset 1736 lines).
Hunk #4 succeeded at 16045 with fuzz 1 (offset 2112 lines).
Hunk #5 succeeded at 18882 (offset 2205 lines).
Hunk #6 FAILED at 23244.
Hunk #7 FAILED at 23727.
Hunk #8 FAILED at 24221.
4 out of 8 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej

Hat dafür schon jemand eine Lösung ?

Gruss,

Jörg

 

[pwalker]

Kurze Frage, für 1.6.2.0-rc6 gibs jede Menge rejects.

patch -p1 < ../SIP_ID.patch

Welcher Patch ist das? Die hier im Forum sind - wenn ich nichts übersehen habe- für 1.2 bzw. 1.6.0, nicht für 1.6.2. Da wundern mich die vielen rejects überhaupt nicht...

 

[jackfritt]

Ein Versuch war es wert (Dateiname ist natürlich nur geändert. Original von hier patch.asterisk-1.6.0.14.txt)

Gruss,

Jörg

 

[stäubel]

Hallo zusammen

Beschäftige mich zur Zeit auch intensiv mit diesem Thema
und habe auch Asterisk 1.6.2.0-rc6 im Einsatz.

Da es ja gerüchtweise mit 1.6.2 gehen soll ...

Gibt es da wirklich Gerüchte die besagen, dass es mit 1.6.2 funktioniert?

Ich bringe es einfach nicht hin.

Hat das jemand geschafft?

Gruss Stäubel

 

[pwalker]

Gibt es da wirklich Gerüchte die besagen, dass es mit 1.6.2 funktioniert?
Ich bringe es einfach nicht hin.
Hat das jemand geschafft?

Siehe Post #25:

Habe extra noch den trunk und 1.6.2 aus SVN geholt, und dazu finde ich nichts.

Mindestens Stand 31.8. war käumlichst was dazu drin. Das ist doch das Schöne an OpenSource-Software: Jeder kann in den Sourcen (hier z.B. im SVN) nachschauen, ob der entsprechende Code drin ist oder nicht...

 

[jackfritt]

Habe gestern noch gelesen das dieses feature ab 1.8+ drin sein wird. Ich glaube 3-4Q 2010. Also warten oder selbst mit rumspielen. Dieser Codeschnipsel soll wohl dafür verantwortlich sein.
Entsprechender Bug Report

Gruss,

Jörg

 

[stäubel]

Hallo zusammen

Habe es nun mal versucht auf einem Asterisk 1.2.24 auszuprobieren,
ob ich es mit folgendem Patch hinkriege:

...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)

Das patchen war erfolgreich. Aber es funktioniert nicht.
Da ist aber noch die Rede von einem call answererd elsewhere"-Patch.
Braucht man den auch, wo findet man den am Besten für 1.2.24?

Habe mit Google nur viele verschiedene Codeschnipsel gefunden

Viele Grüsse

Stäubel

 

[pwalker]

Hm.. Der Patch müsste eigentlich funktionieren... Kann sein, dass die Zeilennummern nicht 100%ig stimmen, aber der Patch scheint ja zu applyen (Zeilen könnten wegen dem "call answererd elsewhere"-Patch, den ich bereits vor diesem Patch reingemacht habe, leicht verschoben sein, deshalb die Aussage wegen den Offsets).
Einen "call answererd elsewhere"-Patch brauchst Du dafür nicht.
Und um das nochmals klarzustellen, was der Patch macht:
- Funktioniert (wahrscheinlich) nur mit snom-Telefonen, müsste mit FW 6.5 und 7.1 funktionieren (mit 7.3 und 8.x nicht getestet)
- Ablauf:

1. A ruft B an (möchte aber eigentlich mit C reden)
2. B ruft C an, um zu vermitteln
3. C nimmt das Gespräch an, bei C wird CallerID von B angezeigt
4. B vermittelt (Transfer)
5. A und C sind miteinander verbunden, bei C wird CallerID von A angezeigt

Mehr macht der Patch nicht.
Kontrollfragen:

• Asterisk neu compiliert (make)?
• Asterisk neu installiert (make install)?
• Asterisk neu gestartet (z.B. asterisk -rx 'restart when convenient')?
• calleridupdate=info hast Du in sip.conf drin?

 

[stäubel]

Hey pwalker

Danke vielmals für deine Antwort.

Einen "call answererd elsewhere"-Patch brauchst Du dafür nicht.

Hmm, in diesem Fall müsste es erst recht funktionieren.

Und um das nochmals klarzustellen, was der Patch macht:
- Funktioniert (wahrscheinlich) nur mit snom-Telefonen, müsste mit FW 6.5 und 7.1 funktionieren (mit 7.3 und 8.x nicht getestet)

Habe es jetzt nochmals intensiv mit zwei SNOMs 360 getestet
FW 7.1.35 und 7.3.27. Aber es will einfach noch nicht ganz.
*Aber ein kleines Erfolgserlebnis gabs.

- Ablauf:

• A ruft B an (möchte aber eigentlich mit C reden)
• B ruft C an, um zu vermitteln

durch drücken der HOLD Taste?

• C nimmt das Gespräch an, bei C wird CallerID von B angezeigt
• B vermittelt (Transfer)
• A und C sind miteinander verbunden, bei C wird CallerID von A angezeigt

Bei mir wird bei C immer noch Nummer von B angezeigt.

*Wenn ich allerding Transfer klicke bevor C abhebt, funktioniert es.

Kennst du das Problem?
Ist vielleicht noch eine spezielle SNOM Konfiguration nötig?

Bei genauem hinschauen sieht man jedoch,
dass im Display ganz kurz etwas aufblitzt,
wenn C abhebt und ich anschliessend bei B Transfer drücke.
Die Nummer bleibt aber unverändert.

Man sieht allerindgs nicht was genau aufblitzt.

Kontrollfragen:

• Asterisk neu compiliert (make)?
• Asterisk neu installiert (make install)?
• Asterisk neu gestartet (z.B. asterisk -rx 'restart when convenient')?
• calleridupdate=info hast Du in sip.conf drin?

Diese Punkte hatte ich alle beachtet.

Viele Grüsse Stäubel

 

[pwalker]

durch drücken der HOLD Taste?

Ja, zum Beispiel. Hold, Nummer wählen Hacken-Taste. Oder mittels BLF-Taste usw.

Bei mir wird bei C immer noch Nummer von B angezeigt.
*Wenn ich allerding Transfer klicke bevor C abhebt, funktioniert es.
Kennst du das Problem?

Hm. Kapiere ich nun nicht ganz. Müsste doch eigentlich mehr oder weniger dasselbe sein,, vom Ablauf her, einfach mit anderem Timing... (Attended vs.

Ist vielleicht noch eine spezielle SNOM Konfiguration nötig?

Nicht dass ich wüsste.

Bei genauem hinschauen sieht man jedoch,
dass im Display ganz kurz etwas aufblitzt,
wenn C abhebt und ich anschliessend bei B Transfer drücke.
Die Nummer bleibt aber unverändert.
Man sieht allerindgs nicht was genau aufblitzt.

Hm. Du könntest sonst mal - wenn Du Dich einigermassen sicher fühlst im Hacken von chan_sip.c - noch eine Debug-Ausgabe reinmachen in den Code im Bereich
add_header( .. "message/sipfrag");
ast_build_string( .. "From: \"%s\" <%s>\r\n" ..);
ast_build_string( .. "To: \"%s\" <%s>\r\n" .. );
um zu sehen, ob er da wirklich reinkommt.
Oder evtl. steht im Log des snom etwas? (evtl. Log-Level erhöhen.) Sonst auch noch im SIP Trace schauen, ob die SIP INFO message ankommt.

Grüsse nach ennet dem Klausen,
Philipp

 

[stäubel]

Ja, zum Beispiel. Hold, Nummer wählen Hacken-Taste. Oder mittels BLF-Taste usw.

Okay ist in diesem Fall auch richtig.

Hm. Du könntest sonst mal - wenn Du Dich einigermassen sicher fühlst im Hacken von chan_sip.c - noch eine Debug-Ausgabe reinmachen in den Code im Bereich
add_header( .. "message/sipfrag");
ast_build_string( .. "From: \"%s\" <%s>\r\n" ..);
ast_build_string( .. "To: \"%s\" <%s>\r\n" .. );
um zu sehen, ob er da wirklich reinkommt.
Oder evtl. steht im Log des snom etwas? (evtl. Log-Level erhöhen.) Sonst auch noch im SIP Trace schauen, ob die SIP INFO message ankommt.

Das habe ich nun mal gemacht, sieht gut aus.
Hier die Log Ausgabe:

   -- [B]Executing Dial("SIP/50-081d94e0", "SIP/88|40|fo")[/B] in new stack
    -- Called 88
    -- SIP/88-08200e48 is ringing
 Extension Changed 88 new state Ringing for Notify User 50
    -- SIP/88-08200e48 is ringing
    -- SIP/88-08200e48 is ringing
    -- SIP/88-08200e48 answered SIP/50-081d94e0
    -- Attempting native bridge of SIP/50-081d94e0 and SIP/88-08200e48
 Extension Changed 88 new state InUse for Notify User 50
    -- Stopped music on hold on CAPI/EICON/6879081-1
[B]Dec  4 14:05:15 NOTICE[15941]: chan_sip.c:10573 attempt_transfer: Bin ich drin oder was!!!!!!!!!!!!!!!!!!!!![/B]
  == Spawn extension (incoming, 6879081, 3) exited non-zero on 'SIP/50-081d94e0<ZOMBIE>'
 Extension Changed 88 new state Idle for Notify User 50
  == Spawn extension (default, 88, 1) exited non-zero on 'CAPI/EICON/6879081-1'
  == EICON: CAPI Hangingup
       > CAPI INFO 0x3490: Normal call clearing

Ich habe so das komische Gefühl, das Telefon schnallt das nicht.

Jetzt habe ich mal noch ein SNOM 320 als Telefon C probiert,
bei dem erscheint nach dem Transfer (null) im Display.

Wenn ich das Log auf dem Telefon anschaue sieht das so aus:

Received from udp:192.168.7.4:5060 at 4/12/2009 14:31:01:179 (475 bytes):

INFO sip:[email protected]:2048;line=znbigluw SIP/2.0
Via: SIP/2.0/UDP 192.168.7.4:5060;branch=z9hG4bK75f54093;rport
From: "Lumpi" <sip:[email protected]>;tag=as06782de4
To: <sip:[email protected]:2048;line=znbigluw>;tag=5t3xzf99nz
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 104 INFO
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Type: message/sipfrag
Content-Length: 47

From: "Lumpi" <50>
To: "(null)" <0441234567>

Es kommt also an, aber vielleicht ist einfach das (null)
was irgendwie stört.

Viele Grüsse aus dem
düsteren Kanton SZ

Stäubel

 

[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).
- Ist das beim semi-attended-Transfer auch so?
Nehme an; A = 0441234567 , B = 50 und C = 80