[fixed] Über chan_sccp keine Anrufe von IP zu PSTN möglich

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
elektropopper

elektropopper

Neuer User
Mitglied seit
16 Sep 2006
Beiträge
36
Punkte für Reaktionen
0
Punkte
0
Seit neustem ist es nicht mehr möglich über mein Cisco 7960 Anrufe ins PSTN zu initialisieren.
IP zu IP Verbindungen sind problemlos möglich, ebenso Verbindungen aus dem PSTN.

Bei einem Anrufversuch z.B. auf mein Handy, klingelt dies einmal und danach wird die Verbindung vom Asterisk getrennt.
Auf der CLI erscheint folgende Meldung die auf ein Codec Problem deuten lässt:

Jul 18 16:43:21 WARNING[15638]: sccp_pbx.c:331 sccp_pbx_write: SEP0003E334XXXX: Asked to transmit frame type 0, while native formats is 4 (read/write = 4/4)
Jul 18 16:43:21 WARNING[15638]: channel.c:2241 ast_prod: Prodding channel 'SCCP/6000-00000006' failed

sip.conf & sccp.conf
disallow=all
allow=ulaw
allow=alaw

Asterisk 1.2.22
chan_sccp-20060408

Kann jemand hierzu einen Tipp geben?
 
Zuletzt bearbeitet:
Asterisk 1.2.22
Zum Vergrößern anklicken....

Du solltest mit dem Update Deines Asterisk auf 1.2.22 besser warten, bis bestätigt ist, daß der chan_sccp auch auf dieser neuen Version läuft. Vermutlich gab es in channel.c einige Änderungen, zu denen chan_sccp noch nicht kompatibel ist.
 
Ja, dass war das Problemchen.
Da war ich mal wieder zu schnell.

Bin wieder auf 1.2.18 runter und es funktioniert wie gehabt.

Danke!

bis bestätigt ist
Zum Vergrößern anklicken....
Von wem wird dies bestätigt?
 
Zuletzt bearbeitet:
naja, vielleicht wird ja hier im Forum demnächst berichtet, daß es einen Patch gibt, mit dem man chan_sccp unter 1.2.22 zum Laufen bringt :mrgreen:

Alternativ müßtest Du Dir den Sourcecode selbst vornehmen ;)
 
ich schau bei Gelegenheit mal drauf.
Denke das es kein grosses problem ist
 
Hier der selbe Fehler allerdings mit einem Asterisk 1.4.9. Jemand zufällig Erfahrungen damit gemacht?
 
Habe gerade die 1.4.9 getestet, keine Problem mit misdn und chan_sccp.
Über sip habe ich es noch nicht probiert, werde ich gleich mal versuchen - Test: Erfolgreich.
Die 1.2.22 kann ich z.Z. nicht probieren

@ck84,

welche version hast du?
 
chan_sccp-20070429 bzw 2007-07-12_chan_sccp-Version1.4.7

geht mit beiden nicht
 
die Version hab ich auch.
kannst du ein sccp debug machen?
 
Komisch.

Ich habe nichts getan ausser eine Nacht zu warten und nun geht es auf einmal ohne das ich etwas verändert habe. Sehr komisch.

EDIT: nun taucht der Fehler wieder auf. Hier mal das Debug log

Code: 
    -- SEP001122334455: >> Got message SoftKeyEventMessage
    -- SEP001122334455: Got Softkey: Redial (1) line=0 callid=0
    -- SEP001122334455: Redial Softkey.
    -- SEP001122334455: Getting the active channel on device
    -- SEP001122334455: New channel number: 4 on line 600
    -- SEP001122334455: Set the active channel 4 on device
    -- SEP001122334455: Indicate SCCP state (OffHook) on call 600-4
    -- SEP001122334455: Clear the display notify message
    -- SEP001122334455: Clear the status prompt on line 0 and callid 0
    -- SEP001122334455: Send speaker mode 1
    -- SEP001122334455: Send lamp mode LampOn(2) on line 1
    -- SEP001122334455: Send and Set the call state OffHook(1) on call 4
    -- SEP001122334455: Display prompt on line 1, callid 4, timeout 0
    -- SEP001122334455: Send softkeyset to OffHook(4) on line 1  and call 4
    -- SEP001122334455: Send activate call plane on line 1
    -- SEP001122334455: Sending tone InsideDialTone (33)
    -- SEP001122334455: Finish to indicate state SCCP (OffHook), SKINNY (OffHook) on call 600-4
    -- SEP001122334455: Global Capabilities: 12
    -- SEP001122334455: format request: 268/8
    -- SEP001122334455: Channel SCCP/600-00000004, capabilities: DEVICE 0x10c (ulaw|alaw|g729) NATIVE 0x10c (ulaw|alaw|g729) BEST 8 (alaw)
    -- SEP001122334455: Allocated asterisk channel 600-4
    -- SEP001122334455: Set asterisk state OffHook (2) for call 4
    -- SCCP: Looking for line 600
    -- SEP001122334455: found line 600
    -- GOT data SCCP/600-00000004 (0x8180fd8)
    -- SCCP: Asterisk asked for the state (2) of the line 600
    -- GOT line 600
    -- GOT device SEP001122334455
    -- SEP001122334455: New call on line 600
    -- SEP001122334455: Set callingParty Name daheim on channel 4
    -- SEP001122334455: Set callingParty Number 600 on channel 4
    -- SEP001122334455: Dialing 01700000000 on channel 600-4
    -- SEP001122334455: Set calledParty Name 01700000000 on channel 4
    -- SEP001122334455: Set calledParty Number 01700000000 on channel 4
    -- SEP001122334455: Indicate SCCP state (Dialing) on call 600-4
    -- SEP001122334455: Stop tone on device
    -- SEP001122334455: Send the dialed number 01700000000 for Outbound channel 4
    -- SEP001122334455: Send softkeyset to DigitsFoll(6) on line 1  and call 4
    -- SEP001122334455: Clear the status prompt on line 1 and callid 4
    -- SEP001122334455: Set asterisk state Dialing (3) for call 4
    -- SCCP: Looking for line 600
    -- SEP001122334455: found line 600
    -- SEP001122334455: Finish to indicate state SCCP (Dialing), SKINNY (OffHook) on call 600-4
    -- SET Var SKINNY_PRIVATE to: disabled
    -- SCCP: Asterisk asked for the state (2) of the line 600
    -- SEP001122334455: Indicate SCCP state (Dialing) on call 600-4
    -- SEP001122334455: Stop tone on device
    -- SEP001122334455: Send the dialed number 01700000000 for Outbound channel 4
    -- SEP001122334455: Send softkeyset to DigitsFoll(6) on line 1  and call 4
    -- SEP001122334455: Clear the status prompt on line 1 and callid 4
    -- SEP001122334455: Set asterisk state Dialing (3) for call 4
    -- SEP001122334455: Finish to indicate state SCCP (Dialing), SKINNY (OffHook) on call 600-4
    -- SEP001122334455: Send and Set the call state Proceed(12) on call 4
    -- SEP001122334455: Send callinfo for Outbound channel 4
    -- SEP001122334455: Clear the status prompt on line 1 and callid 4
    -- SEP001122334455: Display prompt on line 1, callid 4, timeout 0
    -- SEP001122334455: channel 600-4 is dialing number 01700000000
    -- SEP001122334455: Set asterisk state Ring (4) for call 4
    -- SCCP: Looking for line 600
    -- SEP001122334455: found line 600
    -- SCCP: Asterisk asked for the state (2) of the line 600
    -- Executing [01700000000@home:1] NoOp("SCCP/600-00000004", "Call from cp") in new stack
    -- Executing [01700000000@home:2] GotoIf("SCCP/600-00000004", "0?ok:no") in new stack
    -- Goto (home,01700000000,20)
    -- Executing [01700000000@home:20] Dial("SCCP/600-00000004", "CAPI/ISDN1/49:01700000000/b|120|tT") in new stack
    -- Called ISDN1/49:01700000000/b
    -- CAPI/ISDN1#02/01700000000-6 is making progress passing it to SCCP/600-00000004
    -- SEP001122334455: Asterisk indicate '14' (Progress) condition on channel SCCP/600-00000004
    -- SEP001122334455: Indicate SCCP state (Proceed) on call 600-4
  == ISDN1#02: Setting up DTMF detector (PLCI=0x101, flag=1)
    -- SEP001122334455: Stop tone on device
    -- SEP001122334455: Send and Set the call state Proceed(12) on call 4
    -- SEP001122334455: Send callinfo for Outbound channel 4
    -- SEP001122334455: Display prompt on line 1, callid 4, timeout 0
    -- SEP001122334455: readformat 8, payload 2
    -- SEP001122334455: Ask the device to open a RTP port on channel 4. Codec: G.711 A-law 64k, echocancel: ON
    -- SEP001122334455: Starting RTP on channel 600-4
    -- SEP001122334455: Creating rtp server connection at 172.16.1.1
    -- SEP001122334455: Finish to indicate state SCCP (Proceed), SKINNY (Proceed) on call 600-4
    -- SEP001122334455: >> Got message OpenReceiveChannelAck
    -- SEP001122334455: Got OpenChannel ACK.  Status: 0, RemoteIP (Connection): 172.16.1.115, Port: 29730, PassThruId: 4
    -- SCCP: Looking for channel by id 4
    -- SEP001122334455: Found channel (4)
    -- SEP001122334455: Tell device to send RTP media to 172.16.1.1:30264 with codec: G.711 A-law 64k, tos 184, silencesuppression: OFF
    -- SEP001122334455: Set the RTP media address to 172.16.1.115:29730
    -- CAPI/ISDN1#02/01700000000-6 is ringing
    -- SEP001122334455: Asterisk indicate '3' (Ringing) condition on channel SCCP/600-00000004
    -- SEP001122334455: Indicate SCCP state (RingOut) on call 600-4
    -- SEP001122334455: Send and Set the call state RingOut(3) on call 4
    -- SEP001122334455: Send callinfo for Outbound channel 4
    -- SEP001122334455: Send softkeyset to RingOut(8) on line 1  and call 4
    -- SEP001122334455: Display prompt on line 1, callid 4, timeout 0
    -- SEP001122334455: Set asterisk state Ring (4) for call 4
    -- SEP001122334455: Finish to indicate state SCCP (RingOut), SKINNY (RingOut) on call 600-4
[Jul 27 09:20:18] WARNING[27269]: sccp_pbx.c:350 sccp_pbx_write: SEP001122334455: Asked to transmit frame type 0, while native formats is 8 (read/write = 8/8)
[Jul 27 09:20:18] WARNING[27269]: channel.c:2732 ast_prod: Prodding channel 'SCCP/600-00000004' failed
  == ISDN1#02: CAPI Hangingup for PLCI=0x101 in state 5
  == Spawn extension (home, 01700000000, 20) exited non-zero on 'SCCP/600-00000004'
    -- Executing [h@home:1] Hangup("SCCP/600-00000004", "") in new stack
  == Spawn extension (home, h, 1) exited non-zero on 'SCCP/600-00000004'
    -- SCCP: Asterisk request to hangup channel SCCP/600-00000004
    -- SEP001122334455: Close openreceivechannel on channel 4
    -- SEP001122334455: Stopping phone media transmission on channel 600-4
    -- SEP001122334455: Stop media transmission on channel 4
    -- SEP001122334455: Requesting CallStatisticsAndClear from Phone
    -- SEP001122334455: Current channel 600-4 state RingOut(3)
    -- SEP001122334455: Getting the active channel on device
    -- SEP001122334455: Sending tone Zip (50)
    -- SEP001122334455: Indicate SCCP state (OnHook) on call 600-4
    -- SEP001122334455: Send speaker mode 2
    -- SEP001122334455: Clear the status prompt on line 1 and callid 4
    -- SEP001122334455: Send and Set the call state OnHook(2) on call 4
    -- SEP001122334455: Send softkeyset to OnHook(0) on line 1  and call 4
    -- SEP001122334455: Send lamp mode LampOff(1) on line 1
    -- SEP001122334455: Stop tone on device
    -- SEP001122334455: Send date/time
    -- SEP001122334455: Finish to indicate state SCCP (OnHook), SKINNY (OnHook) on call 600-4
    -- SEP001122334455: Deleting channel 4 from line 600
    -- SEP001122334455: Deleted channel 4 from line 600
    -- SEP001122334455: return from the startchannel on exit
    -- SCCP: Looking for line 600
    -- SEP001122334455: found line 600
    -- SCCP: Asterisk asked for the state (1) of the line 600
    -- SEP001122334455: >> Got message ConnectionStatisticsRes
    -- SEP001122334455: Statistics from 01700000000 callid: 4 Packets sent: 487 rcvd: 488 lost: 1 jitter: 3 latency: 0
    -- SEP001122334455: Clear the status prompt on line 0 and callid 0
    -- SEP001122334455: Display prompt on line 0, callid 0, timeout 0
    -- SEP001122334455: Send softkeyset to OnHook(0) on line 0  and call 0
 
Zuletzt bearbeitet:
Ah du verwendest chan_capi?
Das habe ich z.Z. nicht am laufen - verwende mISDN.
Muss mal sehn ob ich da einen test machen kann.
 
Und ich werde mal mISDN versuchen
 
@ck84

schon Erfolg gehabt?
 
Bisher leider noch keine Zeit gefunden.
 
elektropopper schrieb:
Seit neustem ist es nicht mehr möglich über mein Cisco 7960 Anrufe ins PSTN zu initialisieren.
IP zu IP Verbindungen sind problemlos möglich, ebenso Verbindungen aus dem PSTN.

Bei einem Anrufversuch z.B. auf mein Handy, klingelt dies einmal und danach wird die Verbindung vom Asterisk getrennt.
Auf der CLI erscheint folgende Meldung die auf ein Codec Problem deuten lässt:

Jul 18 16:43:21 WARNING[15638]: sccp_pbx.c:331 sccp_pbx_write: SEP0003E334XXXX: Asked to transmit frame type 0, while native formats is 4 (read/write = 4/4)
Jul 18 16:43:21 WARNING[15638]: channel.c:2241 ast_prod: Prodding channel 'SCCP/6000-00000006' failed
Zum Vergrößern anklicken....


Exakt das gleiche Verhalten habe ich auch (asterisk-1.4.9, chan-sccp 20070429 - hier aus dem Board).

Zur Analyse möchte ich Folgendes beitragen: wenn ich "core show codecs" eingebe, werden einige Codecs mit ihren INT-Werten angezeigt. Was mir auffällt ist, dass es keinen Codec mit INT=0 gibt.

Somit würde ich die obige Meldung so interpretieren, dass ein Codec vom Typ 0 angefordert wurde, zur Verfügung steht aber nur INT=4 (=ulaw G.711 u-law). Da es aber INT=0 nicht gibt, ist es offenbar ein Bug.

Frage ist nur, ob es ein Bug im chan_sccp oder in der Asterisk ist.
 
Work-around mit bandwidth. Codec-Wahl als Ursache?

Hallo.

Ich habe noch eine zweite Installation mit der gleichen Version gehabt, bei der dieses Problem nicht auftrat. Ich habe mich auf die Suche nach den Unterschieden gemacht.

Ich verwende folgendes Setup:

Code: 
Cisco-Telefon  ---sccp-->  asterisk-sccp  ---iax2-->  asterisk-telco

Auf asterisk-sccp tritt abhängig von dem Wert "bandwidth" in der Datei iax.conf folgendes Verhalten auf:

bandwidth=high

Als Codec zwischen asterisk-sccp und asterisk-telco wird ulaw ausgehandelt. Es erscheinen die Fehlermeldungen:

Code: 
[Aug  7 18:46:38] WARNING[14168]: sccp_pbx.c:350 sccp_pbx_write: SEP0016xxxxxxxx: Asked to transmit frame type 0, while native formats is 8 (read/write = 8/8)
[Aug  7 18:46:38] WARNING[14168]: channel.c:2732 ast_prod: Prodding channel 'SCCP/284-00000005' failed
[Aug  7 18:46:38] WARNING[14168]: app_dial.c:674 wait_for_answer: Unable to forward voice frame
[Aug  7 18:46:38] WARNING[14168]: app_dial.c:674 wait_for_answer: Unable to forward voice frame


bandwidth=low

Als Codec wird gsm ausgehandelt. Das Gespräch kommt ohne Fehler zu stande.
 
Zuletzt bearbeitet:
Ok, ich nehme es mal in die Liste mit auf.
Arbeite z.Z. an einer RealtimeVersion und sonstigen Kleinigkeiten.
Wer interesse hat diese zu testen sagt bescheid ;)
 
chaos2000 schrieb:
Ok, ich nehme es mal in die Liste mit auf.
Arbeite z.Z. an einer RealtimeVersion und sonstigen Kleinigkeiten.
Wer interesse hat diese zu testen sagt bescheid ;)
Zum Vergrößern anklicken....

Ja, ich habe interesse.
 
Ich mache mal heute abend eine Testversion fertig
 
Ich fand heraus, dass im channel.c eine Änderung seit neuestem zu finden ist, die zu diesem Problem führt:

Line 2780: (int ast_channel_make_compatible ())
Code: 
        if (chan->readformat == peer->writeformat && chan->writeformat
== peer->readformat) {
                /* Already compatible!  Moving on ... */
                return 0;
        }


Das scheint zunächst logisch, bei Kompatibilität der Formate die Methode ast_channel_make_compatible zu verlassen. Leider passiert weiter unten noch einiges, was offenbar von chan_sccp benötigt wird:

Code: 
        if (ast_set_read_format(chan, dst) < 0) {
...
        if (ast_set_write_format(peer, dst) < 0) {

Ich habe folgendes im obigen Fragment ergänzt, so dass der Fehler nicht mehr auftaucht:

Code: 
        if (chan->readformat == peer->writeformat && chan->writeformat
== peer->readformat) {
                /* Already compatible!  Moving on ... */
                src = peer->nativeformats;
                dst = chan->nativeformats;
                ast_translator_best_choice(&dst, &src);
                ast_set_read_format(chan, dst);
                ast_set_write_format(peer, dst);
                return 0;
        }

Ich glaube aber, dass es nicht der richtige Weg ist, den asterisk-Code zu patchen. Vielmehr sollte chan_sccp mit diesem Umstand klar kommen.

@chaos2000: Ich bin auf die Testversion gespannt.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 798 (Mitglieder: 33, Gäste: 765)

Neueste Beiträge

Statistik des Forums

Themen
246,099
Beiträge
2,246,165
Mitglieder
373,581
Neuestes Mitglied
Perry123
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück