[Gelöst] Seltsames Verhalten bei G722 und A430Go IP & Asterisk

[Krystman]

Hallo Zusammen!

Ich habe ein seltsames Phänomen an meiner Asterisk TK und steige nicht durch.

Ich habe mehrere Snom860 so wie ein Gigaset C430A IP an dem ich ein SL400H betreibe. Sowohl an den Snoms und auch am Gigaset sind
die Codecs G722,ulaw und alaw in dieser Reihenfolge eingestellt. Telefonate mit den Snoms funktionieren wie es soll einwandfrei. Bei einer Verbindung mit G722 am Snom zu einem Anschluss der ulaw verwendet, gibt die Asterisk CLI folgendes aus:

== Using SIP RTP CoS mark 5
    -- Called SIP/XXXX@ext-Telekom
    -- SIP/ext-Telekom-000000cd is ringing
       > 0x4099b728 -- Probation passed - setting RTP source address to 217.0.4.XXX:26606
    -- SIP/ext-Telekom-000000cd answered SIP/301-000000cc
    -- Channel SIP/ext-Telekom-000000cd joined 'simple_bridge' basic-bridge <aca017df-b315-4cc1-b117-0598d04cbc7f>
    -- Channel SIP/301-000000cc joined 'simple_bridge' basic-bridge <aca017df-b315-4cc1-b117-0598d04cbc7f>
       > Bridge aca017df-b315-4cc1-b117-0598d04cbc7f: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'SIP/301-000000cc' and 'SIP/ext-Telekom-000000cd' in stack
       > Locally RTP bridged 'SIP/301-000000cc' and 'SIP/ext-Telekom-000000cd' in stack
       > 0x4099b728 -- Probation passed - setting RTP source address to 217.0.4.XXX:26606
       > 0x4093b6a0 -- Probation passed - setting RTP source address to 192.168.20.12:30808
    -- Channel SIP/301-000000cc left 'native_rtp' basic-bridge <aca017df-b315-4cc1-b117-0598d04cbc7f>
    -- Channel SIP/ext-Telekom-000000cd left 'native_rtp' basic-bridge <aca017df-b315-4cc1-b117-0598d04cbc7f>
  == Spawn extension (meineTelefone, 2971, 3) exited non-zero on 'SIP/301-000000cc'

Audio funktioniert einwandfrei.

Bei einem Gespräch zum selben Anschluss mit dem Gigaset ist kein Audio zu hören. Die CLI zeigt folgendes:

 == Using SIP RTP CoS mark 5
    -- Called SIP/XXXX@ext-Telekom
    -- SIP/ext-Telekom-000000cf is ringing
       > 0x4099b728 -- Probation passed - setting RTP source address to 217.0.5.XX:27098
    -- SIP/ext-Telekom-000000cf answered SIP/303-000000ce
    -- Channel SIP/ext-Telekom-000000cf joined 'simple_bridge' basic-bridge <2492b1c7-9870-4c90-9445-616638363c05>
    -- Channel SIP/303-000000ce joined 'simple_bridge' basic-bridge <2492b1c7-9870-4c90-9445-616638363c05>
       > Bridge 2492b1c7-9870-4c90-9445-616638363c05: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > 0x4099b728 -- Probation passed - setting RTP source address to 217.0.5.XX:27098
       > 0x4093b6a0 -- Probation passed - setting RTP source address to 192.168.20.3:30254
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > 0x4093b6a0 -- Probation passed - setting RTP source address to 192.168.20.3:30254
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
       > Locally RTP bridged 'SIP/303-000000ce' and 'SIP/ext-Telekom-000000cf' in stack
    -- Channel SIP/303-000000ce left 'native_rtp' basic-bridge <2492b1c7-9870-4c90-9445-616638363c05>
  == Spawn extension (meineTelefone, 2971, 3) exited non-zero on 'SIP/303-000000ce'
    -- Channel SIP/ext-Telekom-000000cf left 'native_rtp' basic-bridge <2492b1c7-9870-4c90-9445-616638363c05>
[Aug 16 18:45:57] WARNING[1267]: chan_sip.c:4009 retrans_pkt: Retransmission timeout reached on transmission 479007929@192_168_20_3 for seqno 17 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Sobald der Angerufene abhebt, ist die Leitung stumm.

Entferne ich G722 aus den möglichen Codecs des Gigaset, funktioniert dies einwandfrei.

Das verwunderliche ist nur, dass in der sip.conf beide Geräte identische contexte haben. Die Firewall möchte ich fast ausschließen.


Zuerst einmal meine Einstellungen:

[general]
bindport = 5060    
allowguest = no      
context = ankommend
alwaysauthreject = yes
maxexpiry = 3600
defaultexpiry = 1800
srvlookup = yes
localnet = 192.168.20.0/255.255.255.0
localnet = 192.168.1.0/255.255.255.0
localnet = 10.8.0.0/255.255.255.0
externhost = meine DynDns
externrefresh = 300
encryption = no
session-timers = refuse
canreinvite = no
allowsubscribe=yes
notifyringing = yes
notifyhold = yes
limitonpeers = yes
checkmwi=5
subscribemwi=yes
cos_sip=3
cos_audio=5
cos_video=4
directmedia=no

[301] ; Snom 821 Büro
type=friend 
context=meineTelefone
secret=XXX
host=dynamic
mailbox=301@default
deny=0.0.0.0/0.0.0.0                   ; Keine IP-Adresse darf sich registrieren...
permit=192.168.20.0/255.255.255.0       ; ... bis auf Geräte im Bereich 
permit=10.0.8.0/255.255.255.0
subscribecontext = meineTelefone
call-limit = 10
callgroup = 2
pickupgroup = 2
qualify=yes
disallow=all
allow = g722
allow = ulaw
allow = alaw
allow = gsm 

[303] ; Gigaset SL400h
type=friend
context=meineTelefone
secret=XXX 
mailbox=301@default
host=dynamic
deny=0.0.0.0/0.0.0.0                   ; Keine IP-Adresse darf sich registrieren...
permit=192.168.20.0/255.255.255.0 
permit=10.0.8.0/255.255.255.0      ; ... bis auf Geräte im Bereich 
subscribecontext = meineTelefone
call-limit = 10
callgroup = 2
pickupgroup = 2
qualify=yes
disallow = all
allow = g722
allow = ulaw
allow = alaw

Wo könnte der Fehler liegen? Gerne liefere ich weitere Infos zur Anlage.

Danke vorab für die Unterstützung!

Christoph

 

[thtomate12]

Wenn der andere Anschluss ulaw verwendet, ist er (so wie deiner) fehlerhaft konfiguriert.

 

[Krystman]

Das Problem wurde nun behoben. Weitere Infos findet ihr hier: http://community.freepbx.org/t/fpbx13-rc-g722-and-1-way-audio-even-to-voicemail/31042/40

In Kürze: Es ist eine fehlerhafte Firmware im Gigaset gewesen. Die Lösung: Im Gigaset ausschließlich G722 in die Liste der verfügbaren Codecs packen. Sobald G711 ebenfalls verfügbar ist, funktioniert bei G722 nur one-way-audio. Seltsam.