[Diskussion] [HOWTO] Asterisk mit dem Snom-Pickup-Patch patchen

[moshman]

Hi,

noch eine Ergänzung zu meinen vorhergehenden Beitrag.
Ich habe das Ganze jetzt auch mit 3 verschiedenen Rechnern (P4, Athlon XP, jeweils Lenny und Squeeze)jeweils mit der AVM B1 und C2 getestet.
Jedesmal auch ein Speicherzugriffsfehler wie beschrieben. Liegt wohl doch an der AVM + chan_capi.

Hat noch jemand dieses Problem?

Grüsse
Thomas

 

[elzoido]

Hi dehpeh,

@elzoido
Welche ISDN-Anbindung hast Du? Karte, Gateway?

Nur Gateways: Sipgate, Betamax, PBX-Network (IAX Protokoll)

 

[dehpeh]

moshman: Hol dir doch bei eBay eine alte Teledat ISDN Karte mit dem Cologne-Chip. Sowas bekommst du meist unter 10 EUR. Dann kannst du das System mit dahdi (zaphfc) laufen lassen.

 

[moshman]

Hi,

die Ursache des Absturzes war notifycid in der sip.conf. Nachdem ich es rausgenommen hatte, ist alles ok. BLF geht, Pickup mit korrekter Anzeige der Caller-ID natürlich nicht (siehe auch hier).

Grüsse
Thomas

 

[pwalker]

Pickup-Patch - mal wieder (net-performer-Patch mit Asterisk 1.4.29)

Hat schon jemand versucht, den Patch von Tweety ("net-performer-Patch"; asterisk-1.4.22-pickup-by-call-id.patch) auf den aktuell aktuellesten 1.4er-Asterisk (1.4.29) zu applizieren?
Der Patch applyt soweit auch, mit einzelnen Offsets und fuzz aber kein failed. Der Quellcode von channels/chan_sip.c sieht soweit eigentlich auch gut aus, doch die Übernahme von Gesprächen an den snom-Telefonen (7.1.39 und 7.3.30) will nicht klappen...
Kurz vor dem Verzeweifeln also mal ein Asterisk 1.4.21.1 runtergeladen, gepatcht und kompiliert: Und siehe da - es klappt! (selbe Konfiguration von Telefonen und Asterisk)
Die versendeten NOTIFYs und INVITEs mit Replaces sehen auf den ersten Blick soweit auch vergleichbar aus mit beiden Asterisk-Versionen...
Deshalb mein grausiger Verdacht: Hat sich in Asterisk 1.4 zwischen 1.4.21 und .29 etwas geändert in der Replaces-Verarbeitung?
Werde wohl nachher noch die SIP-Traces/-Debugs und den Asterisk noch im Detail auf Unterschiede zwischen den beiden Versionen untersuchen, aber wenn jemand einen heissen Tipp hat, was da wo und wann geschehen ist, würde das evtl. meine Suche beschleunigen... Vielen Dank schon im Voraus!

 

[Tweety]

Interessant Müsste mir scheinbar mal wieder den 1.4er Asterisk anschauen...!

Zeig uns bitte mal die SIP Traces, sowohl vom Notify, als auch vom späteren Invite.

 

[pwalker]

Zeig uns bitte mal die SIP Traces, sowohl vom Notify, als auch vom späteren Invite.

Aber gerne doch, hier der vom 1.4.21.1 (gepatcht):
NOTIFY:

NOTIFY sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK7548db0b;rport
From: <sip:[email protected]>;tag=as4b6c1be1
To: <sip:[email protected]>;tag=35rp9m6914
Contact: <sip:[email protected]>
Call-ID: 3c26a012c187-go30c7x4jy8a
CSeq: 109 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: dialog
Content-Type: application/dialog-info+xml
Subscription-State: active
Content-Length: 496

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="7" state="full" entity="sip:[email protected]">
<dialog id="10012" call-id="[email protected]" direction="recipient">
<local><identity display="10012">10012</identity><target uri="sip:[email protected]"/></local>
<remote><identity display="Test3">sip:[email protected]</identity><target uri="sip:[email protected]"/></remote>
<state>early</state>
</dialog>
</dialog-info>

...und dann das INVITE:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.10.251:5060;branch=z9hG4bK-n4bblqpoq2gw;rport
From: "Test4" <sip:[email protected]>;tag=9crd8rtqlj
To: "Test3" <sip:[email protected]>
Call-ID: 3c26a0de39da-dsmvvz9iay1h
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:5060>;reg-id=1
Replaces: [email protected]
P-Key-Flags: resolution="31x13", keys="4"
User-Agent: snom360/7.3.30
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 374

v=0
o=root 1862845967 1862845967 IN IP4 192.168.10.251
s=call
c=IN IP4 192.168.10.251
t=0 0
m=audio 63378 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

 

[Tweety]

Interessant wäre noch die 1.4.29er Version. Die 1.4.21er funktioniert ja ohne Probleme

 

[pwalker]

Interessant wäre noch die 1.4.29er Version. Die 1.4.21er funktioniert ja ohne Probleme

...kommt auch gleich...

1.4.29 gepatcht:
NOTIFY:

NOTIFY sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.10:5060;branch=z9hG4bK4bfb377d;rport
From: <sip:[email protected]>;tag=as0ca33173
To: <sip:[email protected]>;tag=rzbd6oz3ri
Contact: <sip:[email protected]>
Call-ID: 3c26a1797645-lctlwmlmqmpp
CSeq: 103 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: dialog
Content-Type: application/dialog-info+xml
Subscription-State: active
Content-Length: 496

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:[email protected]">
<dialog id="10012" call-id="[email protected]" direction="recipient">
<local><identity display="10012">10012</identity><target uri="sip:[email protected]"/></local>
<remote><identity display="Test3">sip:[email protected]</identity><target uri="sip:[email protected]"/></remote>
<state>early</state>
</dialog>
</dialog-info>

INVITE:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.10.251:5060;branch=z9hG4bK-jpgzfgjmi7p4;rport
From: "Test4" <sip:[email protected]>;tag=0d88j4py4t
To: "Test3" <sip:[email protected]>
Call-ID: 3c26a1b2e1af-432fhw2n6rwd
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:[email protected]:5060>;reg-id=1
Replaces: [email protected]
P-Key-Flags: resolution="31x13", keys="4"
User-Agent: snom360/7.3.30
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 374

v=0
o=root 1808104978 1808104978 IN IP4 192.168.10.251
s=call
c=IN IP4 192.168.10.251
t=0 0
m=audio 59596 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

 

[Tweety]

Schaut soweit auch gut aus. Bis auf das "Version" Feld ist da auch direkt kein Unterschied zu erkennen. Aber das scheint die SNOMs auch nicht weiter zu stören.

Ich lieg momentan eh mit einer kleinen Grippe im Bett... schaue mal kurz nach 1.4.29

 

[pwalker]

Habe einfach mal aus Spass an der Freude 1.4.26.3 runtergeladen, gepatcht (mit asterisk-1.4.22-pickup-by-call-id.patch) und kompiliert -> works...
1.4.27.1: worksn't!

Als Schuss aus der Hüfte verdächtige ich einfach mal die folgende Änderung an Asterisk, das Problem zu verursachen: Asterisk Issue #0015151: [patch] Deadlock On One-legged Transfer [SIP / REPLACES] (Call Pickup), SVN-Revision 219303, drin seit Release Asterisk 1.4.27-rc2

...to be continued...?

 

[Tweety]

Hab mal in den Code geschaut... hat sich eigentlich nicht so extrem viel geändert zwischen 1.4.26.3 und 1.4.29. Scheinbar wurde vor allem mal das Locking der Datenstrukturen überarbeitet, das Verhalten sollte jedoch das Alte sein. Habe jedoch 2 Vermutungen...

Kannst du mal die kompletten Logs (auch Debug!) auf Stufe 4 Posten?

 

[pwalker]

Habe jedoch 2 Vermutungen...

Ich auch - bzw. mindestens eine (siehe oben) ... und mittlerweile auch eine zweite. (Asterisk Issue#0016027: [patch] Crash on Pickup or Transfer / SVN Revision 222542)

Kannst du mal die kompletten Logs (auch Debug!) auf Stufe 4 Posten?

Wird wohl mindestens morgen werden...

Ich lieg momentan eh mit einer kleinen Grippe im Bett... schaue mal kurz nach 1.4.29

Ach ja: Gute Besserung!

 

[pwalker]

Hie mal die beiden Logs - jeweils mit Verbos von 8 und Debug 4 oder so. Aber ohne SIP Messages drin.
1.4.29 patched: http://pastebin.com/f52feae32
1.4.26.3 patched: http://pastebin.com/f4567f938
Die Logs unterscheiden sich auch nicht so massiv...

Update2: Da ist mir die wohl noch entscheidende Zeile im Log aufgefallen, im .26.3 da, im .29 fehlt sie:

SIP answering channel:

Update:
Sieht mir schwer danach aus, dass Asterisk Issue #0015151 / SVN-Revision 219303 schuld am Ganzen ist...
Gemäss dem Diff wurde da ein grosser Teil der Verarbeitung von earlyreplace / oneleggedreplace der Funktion ast_do_masquerade übertragen (ca. Zeile 19737 im Diff) oder es wurde etwas zu viel oder zu wenig unlocked in der Funktion handle_invite_replaces (etwas weiter oben).

Update 3:
Und hier noch Logs mit allem, also auch mit den SIP-Messages:
1.4.26.3 patched: http://pastebin.com/f1ee491f0
1.4.29 patched: http://pastebin.com/f31dbcee8

 

[Tweety]

Wie man sieht, werden Regressionstests generell überbewertet

Kannst du bei dir zum Testen mal bitte

ast_do_masquerade(replacecall)

durch

ast_read(replacecall)

ersetzen?

Das ist zwar keine Endgültige Lösung, jedoch kommen wir der Lösung dann etwas näher... falls es wieder klappt!

 

[pwalker]

Nix da. Klappt auch so nicht, der "fällt" nun in das

ast_log(LOG_WARNING, "Failed to perform masquerade with INVITE replaces\n");

rein...

Vielleicht sollten wir unsere Diskussion off-board weiterführen und erst wieder Resultate posten, damit dieser Thread nicht noch unübersichtlicher wird... nur bin ich dummerweise ab ungefähr bald für gut eine Woche weg vom Fenster (Fasnachts-Ferien = in DE: Fasching-Urlaub oder so...)

Update:
Uuuups: ast_read() returnt bei Erfolg nicht wie ast_do_masquerade() 0, sondern ein ast_frame, bzw. falls was schief läuft NULL... Das erklärt wohl das Verhalten, dass die Warnung geloggt wird...

 

[Tweety]

Sehr schön! Muss ich mir evtl. doch mal 1.4.29 installieren.

Wenn ich wieder fit bin, ist bei mir bis nächste Woche auch Fasching angesagt. Falls du weiter Hilfe benötigst, können wir das gerne per PM weiterführen. Evtl. kannst auch einfach einen Bugreport bei Digium öffnen.

 

[pwalker]

Falls du weiter Hilfe benötigst, können wir das gerne per PM weiterführen. Evtl. kannst auch einfach einen Bugreport bei Digium öffnen.

Danke erstmal für die Unterstützung.
Bezügl. Bugreport bei Digium habe ich ein bisschen Hemmungen, da es sich um einen gepatchten Asterisk handelt... Man müsste also wohl besser quasi einen Use Case finden, wo das auch bei einem ungepatchten auftritt...

 

[Tweety]

Man müsste also wohl besser quasi einen Use Case finden, wo das auch bei einem ungepatchten auftritt...

Ganz spontan fällt mir da nur ein: Nötige Informationen (call-id) aus dem Asterisk holen und per SIPSAK den nötigen Invite mit replaces Parameter generieren...

Der "one legged Call Pickup" ist irgendwie schon immer ein Problem. Musste da schon glaub 2 mal was fixen Scheinbar wurde der Patch auch nicht getestet.

 

[moshman]

Hi,

nur zu Info capi betreffend. Mit der neuesten chan-capi (HEAD, Rev 759) funktioniert das Pickup reibungslos

Hi,

die Ursache des Absturzes war notifycid in der sip.conf. Nachdem ich es rausgenommen hatte, ist alles ok. BLF geht, Pickup mit korrekter Anzeige der Caller-ID natürlich nicht (siehe auch hier).

Grüsse
Thomas