Conference not working after last weeks changes about chan-sccp HOT 10 CLOSED

@marcelloceschia Can you check this with asterisk-trunk.
asterisk-1.8 scheint ok zu sein.

from chan-sccp.

Dies ist der grund das der conference mit asterisk-10 und hoher fehl schlagt :

[Feb 24 17:02:16] DEBUG[10961] res_rtp_asterisk.c: Setting RTCP address on RTP instance '0x7fddf80102a8'
[Feb 24 17:02:16] DEBUG[10979] channel.c: Didn't get a frame from channel: TMP/SCCP/98041-00000001
[Feb 24 17:02:16] DEBUG[10996] bridging.c: Joining bridge channel 0x7fdda80021b8 to bridge 0x7fddf801bae8
[Feb 24 17:02:16] DEBUG[10996] bridging.c: Added channel SCCP/98041-00000001(0x7fddf8020478) to bridge array on 0x7fddf801bae8, new count is 1
[Feb 24 17:02:16] DEBUG[10996] bridging.c: Bridge technology softmix wants to read any of formats (slin) but channel has alaw
[Feb 24 17:02:16] VERBOSE[10961] conference/sccp_conference10.c: -- SCCPCONF/0100: Resuming conference.
[Feb 24 17:02:16] VERBOSE[10961] sccp_channel.c: -- SEP001EF72925B0: Set calledPartyNumber '98051' calledPartyName 'PHONE4'
[Feb 24 17:02:16] VERBOSE[10961] conference/sccp_conference10.c: -- SCCPCONF/0100: Creating new conference-participant 2
[Feb 24 17:02:16] VERBOSE[10961] conference/sccp_conference10.c: -- SCCPCONF/0100: Creating new conference-participant 3
[Feb 24 17:02:16] VERBOSE[10961] conference/sccp_conference10.c: > SCCPCONF/0100: Adding participant 3 (Channel SCCP/98051-00000004)
[Feb 24 17:02:16] DEBUG[10961] channel.c: Planning to masquerade channel SCCP/98031-00000003 into the structure of TMP/SCCP/98031-00000003
[Feb 24 17:02:16] DEBUG[10961] channel.c: Done planning to masquerade channel SCCP/98031-00000003 into the structure of TMP/SCCP/98031-00000003
[Feb 24 17:02:16] DEBUG[10961] channel.c: Putting channel SCCP/98031-00000003 in alaw/alaw formats
[Feb 24 17:02:16] VERBOSE[10961] pbx_impl/ast/ast110.c: -- SCCP: we got a fixup request for SCCP/98031-00000003
[Feb 24 17:02:16] DEBUG[10961] channel.c: Done Masquerading SCCP/98031-00000003 (6)
[Feb 24 17:02:16] VERBOSE[10961] conference/sccp_conference10.c: > SCCPCONF/0100: Added Participant 3 (Channel: SCCP/98031-00000003)
[Feb 24 17:02:16] DEBUG[10988] rtp_engine.c: rtp-engine-local-bridge: Oooh, formats changed, backing out
[Feb 24 17:02:16] VERBOSE[10988] pbx_impl/ast/ast110.c: SCCP: Bridge chan TMP/SCCP/98031-00000003 and chan SCCP/98051-00000004: Failed NoWarn

Werend der masquerade andern sich die read/write formats von slin zuruck auf alaw. In Asterisk-1.8 lauft das ok.Was konnte ich machen:

• Alle conference channels als slin definieren
• Alle conference channels as alaw definieren

Ich glaube ast_bridge mag slin besser (aber die telefone eigentlich alaw). Es muss aber sowieso gemixed werden, also ist das egal.

Wir konnte ich der codec 100% festlegen, damit er sich nicht mehr anders kann, bevor ich denn masquerade mache ?

from chan-sccp.

@dkgroot kann das auch mit dem channel namen zu tun haben?
Asterisk macht einige lookups über den channel identifier (SCCP)

from chan-sccp.

Der code involved:

            /* If the underlying formats have changed force this bridge to break */
            if ((ast_format_cmp(&c0->rawreadformat, &c1->rawwriteformat) == AST_FORMAT_CMP_NOT_EQUAL) ||
                    (ast_format_cmp(&c1->rawreadformat, &c0->rawwriteformat) == AST_FORMAT_CMP_NOT_EQUAL)) {
                    ast_debug(1, "rtp-engine-local-bridge: Oooh, formats changed, backing out\n");
                    res = AST_BRIDGE_FAILED_NOWARN;
                    break;
            }

Also hier werden nur rawformats mit einander verglichen. Der rest hatt er da schon gefunden. Ich glaube nicht das das mit den namen zu tun hatt. Es hatt auch functioniert fur ast110.c und astTrunk.c vor ein paar wochen. Es ist nur das da ein paar sachen geandert worden sind (auch mit codec handling), was dieses problem hervorruft. Die channel namen waren dann auch schon so.

from chan-sccp.

dann muss es eine revision geben mit der es unter ast 11 funktioniert.
woher kommt c0 und c1?

from chan-sccp.

rtp_engine.c : local_bridge_loop(struct ast_channel *c0, struct ast_channel *c1,....)

Soll ich zuruck steigen in alte revisions to find the spot. ?

from chan-sccp.

denke ich ist die schnellere lösung

from chan-sccp.

Bin Dabei.

Weiss aber nicht mehr wie weit ich gehen muss. Bin jetzt bei 4150 aber
da geht wieder was anderes schieft (der bridge geht da aber teilweise :-))

Diederik

On 02/24/2013 06:12 PM, marcelloceschia wrote:

denke ich ist die schnellere lösung

—
Reply to this email directly or view it on GitHub
#44 (comment).

from chan-sccp.

Habe danach auch gleich die anderung von Kevin Vandenberg per hand
ubernommen, damit jetzt alle cli/ami messages einem format folgen
sollten. Er wird das morgen durch ein ami parser schmeissen und gucken
ob alles interpretierbar ist.

Diederik

On 02/24/2013 06:12 PM, marcelloceschia wrote:

denke ich ist die schnellere lösung

—
Reply to this email directly or view it on GitHub
#44 (comment).

from chan-sccp.

Refcount has been fixed

from chan-sccp.