TC300 gibt 482 "Loop detected" zurück

[winschrott]

Hallo zusammen,

ich habe ein kleines Problem mit dem Tc300 (FW Arcor 99c) am Asterisk (v1.4.12) angebucht: in unregelmässigen Abständen läutet das Phone bei einem Anruf drauf an. Wenn ich abhebe höre ich evtl ganz kurz Audio, dann ist stille, der Anruftimer läuft weiter. Am Asterisken zeigt das Log einen 482 loop detected angeblich von Telefon zurückgesendet woraufhin der Asterisk den Anruf beendet, das TC300 davon aber scheints gar nicht mehr in Kenntnis setzt?!?
Wer von Euch hat so ein TC300 am Ast angebucht und ähnliche Probs gehant / hat sie? Irgendwie bring ich das nicht weg, vermute allerdings u.U. doch ein Konfigprob dahinter.

Schönen Abend,

Michael

 

[woprr]

sip.conf:

[201]
...
canreinvite=no

 

[winschrott]

canreinvite ist no. Kurz meine sip.conf, ist das Gerät 2002:

[general]
port = 5060
bindaddr = 192.168.aa.bb
externip = xx.xx.xx.xx
localnet = 192.168.cc.dd/255.255.252.0
context = sonstige
allow = all
dtmfmode=auto
rtpkeepalive=10
language=de
pedantic = yes

register => xxxxxxxx:[email protected]/zzzzzzzz
register => xxxxxxxx:[email protected]/zzzzzzzz

[2001]
type=friend
context=weissbach
secret=tttttttt
username=2001
host=dynamic
nat=yes
canreinvite=no
caninvite=no
dtmfmode=inband

[2002]
type=friend
context=meine-telefone
secret=tttttttt
username=2002
host=dynamic
nat=no
canreinvite=no
caninvite=no

[2003]
disallow=all
allow=alaw
type=friend
context=meine-telefone
secret=ttttttttttt
username=2003
host=dynamic
nat=yes
canreinvite=no
caninvite=no

[2004]
type=friend
context=meine-telefone
secret=ttttttttttt
username=2004
host=dynamic
nat=no
canreinvite=no
caninvite=no

[sipgate]
type=friend
context=sipgate-in
username=xxxxxxxx
fromuser=xxxxxxxx
secret=yyyyyyyy
host=sipgate.de
fromdomain=sipgate.de
qualify=yes
insecure=very
nat=yes

[sipgate_at]
type=friend
context=sipgate-in
username=xxxxxxxx
fromuser=xxxxxxxx
secret=yyyyyyyy
host=sipgate.at
fromdomain=sipgate.at
qualify=yes
insecure=very
nat=yes

Ich hab schon so weit fast alles durchprobiert - ohne Erfolg. Scheinbar meldet das TC den Loop Detected an den Ast. Die Konfig im TC ist auch wie hier irgendwo beschrieben: Register-Srv, kein Proxy,... Hmpf, werde nun versuchen, den Fehler in der extensions.conf mal abzufangen und evtl zu umgehen oder entsprechende Rückmeldungen mittels vorgeschaltetem SER in Richtung dev0 schicken...
Ausser es hat noch jemand eine Idee.

 

[woprr]

wozu caninvite=no ?
und wozu nat=yes und externip? digium kann eh kein stun, ahso sipgate BCM.
wenn die * kiste das WAN inteface hat, würd ich bindaddress weglassen.

http://www.ip-phone-forum.de/showthread.php?t=143691

und proxy brauchste im tc300 aber outbound server leer lassen!

naja, vielleicht guggt betateilchen sich das mal an.

was sagt sip debug (ip/peer)?

 

[winschrott]

Folgendes meint der *:

-- Executing [2002@meine-telefone:1] Dial("SIP/2004-081bce00", "SIP/2002|20|g") in new stack
-- Called 2002
-- SIP/2002-081fa808 is ringing
-- SIP/2002-081fa808 answered SIP/2004-081bce00
-- Got SIP response 482 "Loop Detected" back from 192.168.60.101
-- Executing [2002@meine-telefone:2] VoiceMail("SIP/2004-081bce00", "2002") in new stack
-- <SIP/2004-081bce00> Playing 'vm-intro' (language 'de')
== Spawn extension (meine-telefone, 2002, 2) exited non-zero on 'SIP/2004-081bce00'

Naja, die vbox geht ran weil ich testweise ,g drin hab um im Dialplan weiterzulaufen nach dem Fehler - möchte ja versuchen, diesen abzufangen...

Im TC hab ich nachgesehen:
Proxy Server ist leer, hat aber auch voll nicht gefunzt. Der Rest wohl OK.

Zwecks der sip.conf:
Nein, der * hat kein WAN-If. caninvite=no weil ab und an Abstürze bei native bridges auftraten.

sip debug werd ich heute abend mal probieren und hier rein posten.

LG

 

[woprr]

Im TC hab ich nachgesehen:
Proxy Server ist leer, hat aber auch voll nicht gefunzt. Der Rest wohl OK.

Zwecks der sip.conf:
Nein, der * hat kein WAN-If. caninvite=no weil ab und an Abstürze bei native bridges auftraten.

- ich sagte proxy voll und outbound leer

- :lach: fixt digium mal wieder keine bugs? nimm CallWeaver 1.2 RC5 oder 1.2 stable SVN branch

 

[betateilchen]

SIP 482 hat nicht wirklich was mit den INVITES zu tun.

Du solltest mal meinen Asterisk Kurs hier im Forum durcharbeiten, damit Du wenigstens ansatzweise verstehst, was Du da eigentlich tust. Dann klappts auch mit dem Telefonieren.

 

[winschrott]

Hallo Betateilchen,
ich hatte auch nich angenommen, dass die invites etwas mit SIP482 zu tun haben. Eher war der Ansatz, die Fehlermeldungen bei Native-Bridges zu unterdrücken. Und das tut es. Nun kurz ein Debug-Log von * und TC300:

<------------->
--- (9 headers 0 lines) ---
-- SIP/2002-08205ca0 is ringing
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK473b539c;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 INVITE
Contact: sip:[email protected]:5060
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---

<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK473b539c;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 INVITE
Contact: sip:[email protected]:5060
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
-- SIP/2002-08205ca0 is ringing
-- SIP/2002-08205ca0 is ringing
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK473b539c;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 INVITE
Contact: sip:[email protected]:5060
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
-- SIP/2002-08205ca0 is ringing
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK473b539c;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 INVITE
Supported: timer,100rel,replaces
Session-Expires: 1800;refresher=uas
Min-SE: 90
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 164

v=0
o=Arcor 0 1 IN IP4 192.168.63.191
s=Arcor
c=IN IP4 192.168.63.191
t=0 0
m=audio 30000 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
<------------->
--- (13 headers 9 lines) ---
Found RTP audio format 8
Found RTP audio format 0
Peer audio RTP is at port 192.168.63.191:30000
Found description format PCMA for ID 8
Found description format PCMU for ID 0
Capabilities: us - 0x3f1fff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|g726aal2|g722|jpeg|png|h261|h263|h263p|h264), peer - audio=0xc (ulaw|alaw)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 192.168.63.191:30000
list_route: hop: <sip:[email protected]:5060>
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 192.168.63.191, port 5060
Transmitting (no NAT) to 192.168.63.191:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK7a96ab60;rport
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


---
-- SIP/2002-08205ca0 answered SIP/2001-081fc230
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK473b539c;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 INVITE
Supported: timer,100rel,replaces
Session-Expires: 1800;refresher=uas
Min-SE: 90
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 164

v=0
o=Arcor 0 1 IN IP4 192.168.63.191
s=Arcor
c=IN IP4 192.168.63.191
t=0 0
m=audio 30000 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
<------------->
--- (13 headers 9 lines) ---
Found RTP audio format 8
Found RTP audio format 0
Peer audio RTP is at port 192.168.63.191:30000
Found description format PCMA for ID 8
Found description format PCMU for ID 0
Capabilities: us - 0x3f1fff (g723|gsm|ulaw|alaw|g726|adpcm|slin|lpc10|g729|speex|ilbc|g726aal2|g722|jpeg|png|h261|h263|h263p|h264), peer - audio=0xc (ulaw|alaw)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 192.168.63.191:30000
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 192.168.63.191, port 5060
Transmitting (no NAT) to 192.168.63.191:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK6e343a75;rport
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


---
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
SIP/2.0 482 Loop Detected
Via: SIP/2.0/UDP 192.168.61.4:5060;branch=z9hG4bK6e343a75;received=192.168.61.4;rport=5060
From: "2001" <sip:[email protected]>;tag=as048a6e6c
To: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 102 ACK
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
-- Got SIP response 482 "Loop Detected" back from 192.168.63.191
-- Executing [2002@weissbach:2] VoiceMail("SIP/2001-081fc230", "2002") in new stack
-- <SIP/2001-081fc230> Playing 'vm-intro' (language 'de')
Really destroying SIP dialog '[email protected]' Method: INVITE
asterisk*CLI>
<--- SIP read from 192.168.63.191:5060 --->
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.63.191:5060;branch=z9hG4bK1798879294
To: <sip:[email protected]>;tag=as048a6e6c
From: <sip:[email protected]:5060>;tag=1-3391317840
Call-ID: [email protected]
User-Agent: Arcor D910.0.3.99c FS_D910.0.2.81_ACR
CSeq: 3 BYE
Max-Forwards: 70
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---

<--- Transmitting (no NAT) to 192.168.63.191:5060 --->
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 192.168.63.191:5060;branch=z9hG4bK1798879294;received=192.168.63.191
From: <sip:[email protected]:5060>;tag=1-3391317840
To: <sip:[email protected]>;tag=as048a6e6c
Call-ID: [email protected]
CSeq: 3 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


Hinzuzusagen wäre: das TC300 hat die IP 192.168.63.191, das andere Fon ist auch im 63er Subnetz - also jetzt eben zumindest. Die Netze von 60-63 sind dem Asterisken als lokale Netze bekannt, kein NAT o.ä. drin. Der 482 tritt sporadisch auf. Konfigs am TC300 in verschiedenen Varianten getestet. Mal mit/ohne Proxy-Server,... Das Ergebnis ist immer gleich...
Zusatzinfo: das Problem tritt ausschliesslich mit den 2 TC300 mit selbiger Firmware auf beim Angerufen-werden. Nicht mit anderen Geräten (Linksys VoIP-Phones (=Sipura), Gigaset C450IP).

 

[Mathias-R]

Den Fehler kann ich auch nachvollziehen. Exakt bei jedem zweiten eingehenden Gespräch gibt das TC300 (Firmware Arcor 99.c, Asterisk 1.4.16.2) im Moment des Abhebens ein Loop detected zurück.

Dieser Fehler tritt so auch nur beim TC300 auf, alle anderen mir bekannten Endgeräte (Snom, Siemens, Nokia, Fritz...) laufen in der gleichen Konstellation absolut stabil.

Ich werde mal die 99.d testen - vielleicht hilft das ja.

 

[winschrott]

Hallo Mathias-R,

ich habe das Problem noch immer nicht gelöst bekommen. Inzwischen hab ich folgendes herausbekommen:

- neue Asterisk-Installation (1.2) mit anderen conf's -> gleicher Fehler
- TC300 mit 3.99c an Shamrock Cactus -> gleicher Fehler
- TC300 an Webcalldirect (Betamax) - SIP-Account -> kein Problem

Witzigerweise kommen die Loops seltener vor wenn das TC300 am Asterisken hängend von einem VoIP-Fon aus angerufen wird. Über ISDN passiert der Fehler häufiger. Wollte jetzt auch mal die 3.99d bzw 3.91 (älter) probieren ob damit der Fehler zu beheben ist.

LG

winschrott

 

[winschrott]

Hallo Mathias-R,

evtl sollten wir mal unsere conf's durchgucken ob nicht evtl der gleiche Fehler vorliegt. Scheints hat ja sonst niemand ein solches Problem.
Frage: hat Du mehrere Subnetze? Wenn ja, was routet da dazwischen?

LG

winschrott

 

[Mathias-R]

Hallo winschrott,

meine Asterisk's laufen mit öffentlicher IP. Das TC-300 habe ich mit und ohne STUN, mit und ohne RPORT im NAT betrieben - immer mit dem gleichen Ergebnis. In den gleichen WLAN-Netzen laufen beispielsweise Nokia E90 und Siemens Gigaset WLAN problemlos -mit den gleichen Settings in der sip.conf

Gehende Gespräche funktionieren jederzeit einwandfrei.

Btw. - am alten Asterisk (1.2) besteht das Problem auch und ein Update auf die 99.d hat auch nichts gebracht.

 

[woprr]

Wollte jetzt auch mal die 3.99d bzw 3.91 (älter) probieren ob damit der Fehler zu beheben ist.

reine zeitverschwendung, ging und geht hier mit CallWeaver und 3.99c/d ohne LOOP fehler.
das handy ist i.O oder sag uns wie das zu reproduzieren ist.

checkt eure configs und wenns nicht geht meldet es an den Asterisk bugtracker bei Digium.
nicht alle hersteller machen workarounds für Asterisk bugs in die firmware, pirelli schon gar nicht.

gibt aber gerüchte, dass Arcor eine neue offensichtlich auf eigene services angepasste 3.99c vertreibt.

 

[Mathias-R]

Jetzt habe ich noch mehr Zeit verschwendet und das Telefon am CallWeaver angemeldet:

Dec 26 21:59:11 WARNING[3057372080]: chan_sip.c:12299 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
    -- Got SIP response 482 "Loop Detected" back from 192.168.178.24
  == Spawn extension (default, 789, 1) exited non-zero on 'SIP/49123456789-d107'

Das war offenbar noch nicht die Lösung des Problems.

@woprr:
Hast Du denn bei Dir G.729 und ILBC im CallWeaver installieren können? Eine vernünftige Doku dazu habe ich weder bei Callweaver, noch bei Digium gefunden.

 

[winschrott]

Hallo zusammen,

ich habe mich jetzt mit einigen Firmware-Versionen versucht. Nur kurz anzumerken ist, dass vor Auftreten des Loop-Detects eine teils ganz kurze Audioübertragung stattfindet (mit FW 3.99c), so ca. 0,5 sek.

ACR3.99c : Loop detected jeden 2. Anruf wie oben beschrieben
ACR3.91 : kein Loop, aber Audio-TX am TC300 bricht immer nach ca. 0,5sek ab
PIR3.99d : Loops scheinbar etwas seltener

Generell: Ausgehende Telefonate sind nie ein Problem. Egal welches Ziel (Voip/ISDN).

Mathias-R: wie sieht Deine extensions.conf aus wenn Du das TC anfunkst? Ich habe noch immer das "Problem", dass bei mir der Loop an sich nur bei ISDN -> Ast -> TC300 auftritt. (Voip) -> Ast -> TC300 geht störungsfrei.
In meiner extensions steht nur
1. Dial(SIP/xxx)
2. Hangup

woprr: Vielleicht kannst Du mal Deine confs bereitstellen (extensions, sip, rtp).

LG

winschrott

 

[Mathias-R]

Hallo,

mit der PIR3.99d sind die Loops auch bei mir etwas seltener. Weder am Asterisk, noch am CallWeaver habe ich ISDN. Daher treten die Probleme bei mir bei SIP-Anrufen kommen auf. Gehende Anrufe funktionieren immer problemlos.
SIP.conf:

[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
maxexpiry=3600
language=de
dtmfmode=auto
nat=yes
canreinvite=no
pedantic=yes		; ermöglicht die Wahl von #

[49123456789]
type=friend
secret=<GEHEIM>
host=dynamic
rtpkeepalive=25

Die extensions.conf beinhaltet lediglich ein

exten => 789,1,Dial(SIP/49123456789|120|T)

SIP-Einstellungen:
Anwendername: 49123456789
Passwort: <GEHEIM>
Auth.-Name, Anzeigename, Domainname/REALM, Proxy-Server, Outbound-Server: alle leer
Register Server: sip.meinserver.de
Register Port: 5060
Register Period: 180
RTP Audio Port: 9000

NAT-Einstellungen:
alle getestet (mit / ohne RPORT, mit/ohne STUN)
STUN Serveradresse: stun.meinserver.de
STUN Portnummer: 3478
STUN Affrischzyklus: 180

In dieser Konstellation laufen alle anderen Endgeräte incl. Nokia E-Serie problemlos.

 

[winschrott]

Hallo zusammen,

also ich habe nun heute erstmalig den Loop auch bei Voip -> Voip bekommen. So recht werde ich auch nicht schlau daraus. Mathias-R hat seine conf-Auszüge ja eingestellt, scheinbar ja ganz OK. Mag sich evtl mal jemand, bei dem das TC300 sauber am * läuft diesem Thread annehmen? Vielleicht gibt es ja eine Option die wir beide nicht oder zu viel gesetzt haben...
Aber ich habe einen eventuellen Workaround gefunden:
in der extensions habe ich den Wählbefehl um D(ww) erweitert, sieht dann so aus

exten => 12345,2,Dial(SIP/****,,D(ww))

Das führt dazu, dass der * nach dem Abheben 1 sek Pause in den angerufenen Channel schickt bevor er die Audio-Streams zusammenschaltet. Der Loop kommt i.A. bereits nach 0.5sek, also in der Pausenzeit. Somit zeigt er den Loop zwar an, trotzdem klappt es dann mit dem Zusammschalten der Audiostreams. Mathias-R, bitte mal prüfen ob dem auch bei Dir so ist...

Edit: Eine kleine Nebenwirkung hat der Workaround schon. Wenn auf der anrufenden Seite der Call beendet wird bekommt dies das angerufene TC300 nicht mehr mit und hält den Anruf aufrecht. Also selbst auflegen ist angesagt. Wenn man am angerufenen TC300 auflegt geht das Call-Ende auch an das anrufende Telefon -> korrektes Auflegen. Aber wenns nur das ist.

LG

winschrott

 

[Mathias-R]

Funktioniert ausgezeichnet:

    -- Executing [49123456789@interndial:55] Dial("SIP/49123456789-08341ef0", "SIP/49123456789|120|D(ww)") in new stack
    -- Called 49123456789
    -- SIP/49123456789-08383fd0 is ringing
    -- SIP/49123456789-08383fd0 answered SIP/49123456788-08341ef0
    -- Sending DTMF 'ww' to the called party.
    -- Got SIP response 482 "Loop Detected" back from 192.168.178.24
  == Spawn extension (c080, 49123456789, 55) exited non-zero on 'SIP/49123456788-08341ef0'

Das "Loop Detected" tritt zwar noch auf, aber das Gespräch kommt dennoch zustande.

Das Problem mit dem Auflegen gab es auch vorher schon - wurde auch hier schon mal diskutiert.

Damit kann man zunächst mal provisorisch leben - bis eine fehlerärmere Firmware kommt.

 

[winschrott]

Hallo Mathias-R,

das mit dem Auflegen hatte ich ganz verdrängt. Hat logisch nix mit dem Loop zu tun. Hatte jetzt eben den Fall, dass sich der komplette Stack im TC300 so gehängt hatte das nur noch aus/einschalten geholfen hat. Aber das hatte ich ganz vergessen dass "normal" ist nachdem ich wegen des Loop-Problems die VoIP-Funktion lange nicht genutzt hatte ;-)

LG

winschrott

 

[woprr]

setz RTP pkt. Period = 40 dann passierts ned.