DTMF Töne (Problem gelöst)

[barnybla]

Hallo,

ich habe eine Schrankenanlage, gesteuert über ein Siedle DCA-612 Modul. Das Modul ist über ein Linksys PAP2T angeschlossen. Wenn ich die Schranke anrufe kann ich die DTMF Töne (#61), die Schranke öffnet. Wenn ich von der Schranke angerufen werde wird durch das drücken von #61 nichts erreicht,die Schranke bleibt geschlossen.

Hier die beiden CLI Ausgaben:

Schranke wird angerufen:

] BCHAN: MGR_DELLAYER|CNF pid:96
-- Executing [139@XXX:1] Answer("SIP/123-b40451c0", "") in new stack
-- Executing [139@XXX:2] Dial("SIP/123-b40451c0", "SIP/139|30|t") in new stack
-- Called 139
-- SIP/139-0088ebf0 is ringing
-- Call on SIP/139-0088ebf0 left from hold
-- SIP/139-0088ebf0 answered SIP/123-b40451c0
== Spawn extension (XXX, 139, 2) exited non-zero on 'SIP/123-b40451c0'

Schranke ruft an:

BCHAN: MGR_DELLAYER|CNF pid:97
-- Executing [123@XXX:1] Macro("SIP/139-b404a4f0", "normal|SIP/123|123|139") in new stack
-- Executing [s@macro-normal:1] Devstate("SIP/139-b404a4f0", "123|6") in new stack
-- Executing [s@macro-normal:2] Devstate("SIP/139-b404a4f0", "139|2") in new stack
-- Executing [s@macro-normal:3] Dial("SIP/139-b404a4f0", "SIP/123|30|j") in new stack
-- Called 123
-- SIP/123-0088ebf0 is ringing
-- SIP/123-0088ebf0 is ringing
-- SIP/123-0088ebf0 is ringing
-- Call on SIP/123-0088ebf0 left from hold
-- SIP/123-0088ebf0 answered SIP/139-b404a4f0
-- Packet2Packet bridging SIP/139-b404a4f0 and SIP/123-0088ebf0
== Spawn extension (macro-normal, s, 3) exited non-zero on 'SIP/139-b404a4f0' in macro 'normal'
== Spawn extension (macro-normal, s, 3) exited non-zero on 'SIP/139-b404a4f0'

wer hat eine Idee wo das Problem liegt

Danke

 

[pemabo]

habe leider keine Ahnung vom Asterisk, aber ich denke das liegt an Deinem (ISDN) Endgerät, welches die Töne generiert. Schau da mal im Menü nach 'automatisch DTMF' oder 'Keypad'

 

[barnybla]

Danke für die Antwort,

es ist in beiden Fällen das gleich Snom320 SIP Telefon, einmal geht es einmal nicht.

Gruß
Bernd

 

[betateilchen]

-- Packet2Packet bridging SIP/139-b404a4f0 and SIP/123-0088ebf0

Du mußt darauf achten, daß in beiden SIP Contexten der Eintrag "canreinvite=no" vorhanden ist.

 

[barnybla]

Hallo Betateilchen,

Danke für die Antwort, ich konnte es erst jetzt probieren, ich habe das "canreinvite=no" noch einmal in beiden Contexten gesetzt, obwohl es schon im "general" Bereich steht. Das Problem besteht immer noch, und die Ausgabe ist die Gleiche.

-- Executing [123@BFP:1] Macro("SIP/139-b4039160", "normal|SIP/123|123|139") in new stack
-- Executing [s@macro-normal:1] Devstate("SIP/139-b4039160", "123|6") in new stack
-- Executing [s@macro-normal:2] Devstate("SIP/139-b4039160", "139|2") in new stack
-- Executing [s@macro-normal:3] Dial("SIP/139-b4039160", "SIP/123|30|j") in new stack
-- Called 123
-- SIP/123-b4060b30 is ringing
-- SIP/123-b4060b30 is ringing
-- SIP/123-b4060b30 is ringing
-- Call on SIP/123-b4060b30 left from hold
-- SIP/123-b4060b30 answered SIP/139-b4039160
-- Packet2Packet bridging SIP/139-b4039160 and SIP/123-b4060b30
== Spawn extension (macro-normal, s, 3) exited non-zero on 'SIP/139-b4039160' in macro 'normal'
== Spawn extension (macro-normal, s, 3) exited non-zero on 'SIP/139-b4039160'


hier die Bereiche aus der "sip.conf":

[123]
type=friend
username=123
secret=1234
host=dynamic
mailbox=123
callerid=XXXXX XXXXXXX <123>
context=XXX
canreinvite=no
dtmfmode=INFO
subscribecontext=XXX
callgroup=1
pickupgroup=1

[139]
type=friend
username=139
secret=1234
host=dynamic
callerid= Schranke <139>
canreinvite=no
context=XXX
dtmfmode=INFO

Gruß
Bernd

 

[polskafan]

canreinvite=no verhindert nur eine Native Bridge zwischen beiden "Telefonen". Es wird jedoch eine Packet2Packet Bridge installiert, die zwar den Audio Stream von den Telefonen immer noch durch den gleichen Rechner, aber nicht mehr durch Asterisk an sich schickt. So werden die Daten auch nicht mehr analysiert. Warum auch immer das DTMF brach legt kann ich nicht wirklich erklären, seh nur hier im SVN dass es da wohl mehrere Bugfixes zu dem Thema gegeben hat.

Ich sehe jetzt 2 Optionen das Problem zu beheben:
1. asterisk auf den allerneuesten Stand bringen und hoffen dass das Problem behoben wurde oder
2. nen weg finden, dass asterisk in der Kette bleibt. Dies müsste normalerweise damit erledigt sein, dass asterisk im entsprechenden Dial() Befehl im Context der Schranke noch ne Option mitkriegt, für die es den RTP Stream untersuchen muss, also z.B. Dial(SIP/123,,h) , dass es der Schranke erlauben würde durch ein * die Verbindung zu trennen, was nicht weiter schlimm ist, da die eh nie DTMF Codes von sich aus senden sollte. Was auch funktionieren könnte ist asterisk den Channel vor dem Dial durch ein Answer() übernehmen zu lassen.

Gruß polskafan

 

[barnybla]

Danke Polskafan,

Das Answer() war die Antwort, nachdem ich das ins Makro eingebaut habe funktioniert es.

Liebe Grüße
Bernd