- Mitglied seit
- 8 Sep 2010
- Beiträge
- 3,880
- Punkte für Reaktionen
- 749
- Punkte
- 113
Moin,
hat jemand einen Vorschlag, wie ich einen bis Freitag normal arbeitenden OpenAttendant wieder in Gang setze?
Ich sehe im Trace, dass ein DTMF Event - inkl. korrekter Ziffer - erkannt wird, und dass die korrekte Aktion ausgewählt wird (Weiterverbinden auf externe Rufnummer), dann legt die Anlage einfach auf. Über einen Whireshark Trace kann ich sehen, dass die Anlage gar nicht erst versucht einen Ruf für das Weitervermitteln abzusetzen.
Die Anlage ist über insg. zwei Anschlüsse angebunden. "Normales" Telekom SIP für ein- und ausgehende Anrufe während der Bürozeiten, zusätzlich ein Telekom SIP Trunk mit ClipNoScreening nur für den OpenAttendant (Ansage Notdienst mit Weitervermittlung), damit Rückrufe an den ursprünglichen Anrufer möglich sind.
Bis Freitag lief der OpenAttendant (eingehend über den normalen SIP Anschluss, ausgehend über den SIP Trunk) ohne Probleme. Am Freitag wurde die Zeitsteuerung erweitert und im OpenAttendant Systeme und Menüs angepasst.
Richte ich den OpenAttendant so ein, dass über den normalen Anschluss weitervermittelt wird, funktioniert es ohne Probleme.
Richte ich ein virtuelles Gerät ein (Eingehend normales SIP, ausgehend über SIP Trunk), auch kein Problem. An der Telekom liegt es also definitiv nicht.
System: Mitel 104, 12.1 SP5 HF3
Angebunden über:
1. Telekom DeutschlandLAN (alt Mehrgeräte ISDN) (Leitweg Kennzahl 0)
2. Telekom DeutschlandLAN Sip Trunk (Leitweg Kennzahl 900)
OpenAttendant über Leitweg 0: z.B. 001711234567 -> normale Funktion
OpenAttendant über Leitweg 900: z.B. 90001711234567 -> Fehler wie oben.
Virtuelles Gerät 80 an 90001711234567 -> normale Funktion
Es wurde bereits ein Backup von vorletztem Sonntag wieder eingespielt, aber der Fehler bleibt.
Jemand eine Idee?
hat jemand einen Vorschlag, wie ich einen bis Freitag normal arbeitenden OpenAttendant wieder in Gang setze?
Ich sehe im Trace, dass ein DTMF Event - inkl. korrekter Ziffer - erkannt wird, und dass die korrekte Aktion ausgewählt wird (Weiterverbinden auf externe Rufnummer), dann legt die Anlage einfach auf. Über einen Whireshark Trace kann ich sehen, dass die Anlage gar nicht erst versucht einen Ruf für das Weitervermitteln abzusetzen.
Die Anlage ist über insg. zwei Anschlüsse angebunden. "Normales" Telekom SIP für ein- und ausgehende Anrufe während der Bürozeiten, zusätzlich ein Telekom SIP Trunk mit ClipNoScreening nur für den OpenAttendant (Ansage Notdienst mit Weitervermittlung), damit Rückrufe an den ursprünglichen Anrufer möglich sind.
Bis Freitag lief der OpenAttendant (eingehend über den normalen SIP Anschluss, ausgehend über den SIP Trunk) ohne Probleme. Am Freitag wurde die Zeitsteuerung erweitert und im OpenAttendant Systeme und Menüs angepasst.
Richte ich den OpenAttendant so ein, dass über den normalen Anschluss weitervermittelt wird, funktioniert es ohne Probleme.
Richte ich ein virtuelles Gerät ein (Eingehend normales SIP, ausgehend über SIP Trunk), auch kein Problem. An der Telekom liegt es also definitiv nicht.
System: Mitel 104, 12.1 SP5 HF3
Angebunden über:
1. Telekom DeutschlandLAN (alt Mehrgeräte ISDN) (Leitweg Kennzahl 0)
2. Telekom DeutschlandLAN Sip Trunk (Leitweg Kennzahl 900)
OpenAttendant über Leitweg 0: z.B. 001711234567 -> normale Funktion
OpenAttendant über Leitweg 900: z.B. 90001711234567 -> Fehler wie oben.
Virtuelles Gerät 80 an 90001711234567 -> normale Funktion
Es wurde bereits ein Backup von vorletztem Sonntag wieder eingespielt, aber der Fehler bleibt.
Jemand eine Idee?
Code:
10:04:51.44 ZGS_SIP: 1 4733-Event empfangen!
10:04:51.44 ZGS_SIP: 1.4733-Event: Duration: 70, Event: 7
Code:
10:04:51.44 CI: ID: 0xAD (CS_OE_ID_DIV_CD_REQ) Len: 0x90
10:04:51.44 CI: Port: CI Entity-ID: 0x0001
10:04:51.44 CI: Deflected Adr.:
10:04:51.45 CI: Type: UNKNOWN Plan: UNKNOWN
10:04:51.45 CI: Presentation-Ind: ALLOWED Screening-Ind: USER_NOT_SCREENED
10:04:51.45 CI: Reason: UNKNOWN
10:04:51.45 CI: Number: 90001711234567
10:04:51.45 CI: Deflected Sub-Adr.:
10:04:51.45 CI: AAS-Tr-Handle : 82
10:04:51.45 CI: AAS-Hdl valid until Connect: No
10:04:51.45 CI: IdentificationOfCharge:
10:04:51.45 CI: DestAdr: Undef
10:04:51.45 CI: ---CI--25052021-10:04:51.452-------------------------------------------------------------
10:04:51.45 CI: Disconnect: Port:11, Channel:0, Handle: 67505(0x000107B1) <-> Port:10, Channel:0, Handle:67503(0x000107AF)
Code:
10:04:51.82 CI: ---CI--25052021-10:04:51.829-------------------------------------------------------------
10:04:51.83 CI: Prim:RLC(0xA102) 0x01004A(ZGS_SIP) ZGS(15:Line-SIP-PP)->CI(T0) Id:0000 Idx:0 Trid:CI/0x0455
10:04:51.83 CI: opt. Elemente: 0
10:04:51.83 CI: Cause: #101 (Message not compatible with call state)
10:04:51.83 CI: Location: Priv. Local
10:04:51.83 CI: TEI: 0x00
10:04:51.95 ZGS_SIP: <10:04:51.954>-RX(489 Bytes)--SIP--UDP-IP:217.0.28.160----Dest:10695-Src:5060---
10:04:51.95 ZGS_SIP: SIP/2.0 200 OK
10:04:51.95 ZGS_SIP: Via: SIP/2.0/UDP 192.168.100.240:10695;received=217.82.190.133;rport=10695;branch=z9hG4bK33117_BYE
10:04:51.95 ZGS_SIP: To: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65554t1621929888m616363c82575s1_4208
10:04:51.95 ZGS_SIP: 782432-38013022
10:04:51.95 ZGS_SIP: From: <sip:[email protected];user=phone>;tag=9fxced24924sl
10:04:51.95 ZGS_SIP: Call-ID: p65554t1621929888m616363c82575s2
10:04:51.95 ZGS_SIP: CSeq: 33117 BYE
10:04:51.95 ZGS_SIP: Content-Length: 0
10:04:51.95 ZGS_SIP: Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, MESSAGE, INFO, PRACK, INVITE, ACK, OPTIONS, CANCE
10:04:51.95 ZGS_SIP: L, BYE
10:04:51.95 ZGS_SIP: sipte_release_conf() State:12 Callid:265 Trid:10/0xFFEA