[Gelöst] GXP2200 FW 1.0.3.26 - RTP-Fehler beim Verbinden

abw1oim

Aktives Mitglied
Mitglied seit
26 Mrz 2007
Beiträge
959
Punkte für Reaktionen
4
Punkte
18
ich habe hier ein merkwürdiges Phänomen an einem GXP2200 als SIP-Client an einer Asterisk, zunächst die SIP-Daten des Telefons:

Code:
  * Name       : 13
  Description  :
  Secret       : <Set>
  MD5Secret    : <Not set>
  Remote Secret: <Not set>
  Context      : sip_phone
  Record On feature : automon
  Record Off feature : automon
  Subscr.Cont. : <Not set>
  Language     : de
  Tonezone     : <Not set>
  AMA flags    : BILLING
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  FromDomain   : geheim
  Callgroup    :
  Pickupgroup  :
  Named Callgr :
  Nam. Pickupgr:
  MOH Suggest  :
  Mailbox      :
  VM Extension : asterisk
  LastMsgsSent : 0/0
  Call limit   : 2147483647
  Max forwards : 0
  Busy level   : 2
  Dynamic      : Yes
  Callerid     : geheim
  MaxCallBR    : 384 kbps
  Expire       : 1313
  Insecure     : no
  Force rport  : No
  Symmetric RTP: No
  ACL          : No
  DirectMedACL : No
  T.38 support : No
  T.38 EC mode : Unknown
  T.38 MaxDtgrm: 400
  DirectMedia  : No
  PromiscRedir : No
  User=Phone   : Yes
  Video Support: No
  Text Support : No
  Ign SDP ver  : No
  Trust RPID   : Yes
  Send RPID    : Yes
  Subscriptions: Yes
  Overlap dial : No
  DTMFmode     : rfc2833
  Timer T1     : 500
  Timer B      : 32000
  ToHost       :
  Addr->IP     : 192.168.55.136:18284
  Defaddr->IP  : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username: 13
  SIP Options  : (none)
  Codecs       : (alaw)
  Codec Order  : (alaw:20)
  Auto-Framing :  No
  Status       : OK (1 ms)
  Useragent    : Grandstream GXP2200 1.0.3.26
  Reg. Contact : geheim
  Qualify Freq : 60000 ms
  Keepalive    : 0 ms
  Sess-Timers  : Refuse
  Sess-Refresh : uac
  Sess-Expires : 1800 secs
  Min-Sess     : 90 secs
  RTP Engine   : asterisk
  Parkinglot   :
  Use Reason   : Yes
  Encryption   : No

Folgendes Verhalten fällt beim Vermitteln auf:

Code:
[Apr 15 09:39:59] VERBOSE[10145][C-000003b9] pbx.c:     -- Executing [XXXXXXX@sip_phone:36] Dial("SIP/13-000003ae", "Capi/g1/XXXXXXX/b,30,ciHT") in new stack
[Apr 15 09:39:59] VERBOSE[10145][C-000003b9] app_dial.c:     -- Called Capi/g1/XXXXXXX/b
[Apr 15 09:40:00] VERBOSE[10145][C-000003b9] app_dial.c:     -- CAPI/ISDN1#02/XXXXXXX-6b4 is proceeding passing it to SIP/13-000003ae
[Apr 15 09:40:01] VERBOSE[10145][C-000003b9] app_dial.c:     -- CAPI/ISDN1#02/XXXXXXX-6b4 is making progress passing it to SIP/13-000003ae
[Apr 15 09:40:01] VERBOSE[10145][C-000003b9] app_dial.c:     -- CAPI/ISDN1#02/XXXXXXX-6b4 is ringing
[Apr 15 09:40:01] VERBOSE[10145][C-000003b9] res_rtp_asterisk.c:        > 0xb6f19b78 -- Probation passed - setting RTP source address to XXX.XXX.XXX.XXX:XXXXX
[Apr 15 09:40:03] VERBOSE[10145][C-000003b9] app_dial.c:     -- CAPI/ISDN1#02/XXXXXXX-6b4 answered SIP/13-000003ae
[Apr 15 09:40:15] VERBOSE[10145][C-000003b9] res_musiconhold.c:     -- Started music on hold, class 'default', on CAPI/ISDN1#02/XXXXXXX-6b4
[Apr 15 09:40:35] ERROR[10145][C-000003b9] res_rtp_asterisk.c: Received SSL traffic on RTP instance '0xb6f1566c' without an SSL session
[Apr 15 09:40:35] WARNING[10145][C-000003b9] res_rtp_asterisk.c: RTP Read error: Unspecified.  Hanging up.
[Apr 15 09:40:35] VERBOSE[10145][C-000003b9] pbx.c:     -- Executing [h@sip_phone:1] Hangup("SIP/13-000003ae", "") in new stack

Szenario also: GXP2200 wählt abgehend eien Rufnummer über CAPI (ISDN), die Verbindung kommt zustande. Danach versucht das GXP2200 den Anruf weiterzuvermitteln (was dank Asterisk-Dialoption T auch erlaubt ist), das geht aber schief. Statt jetzt DTMFs für den Vermittliungscode zu erhalten, gibt es den Fehler

Code:
res_rtp_asterisk.c: Received SSL traffic on RTP instance '0xb6f1566c' without an SSL session

Kennt jemand das Problem und weis eine Lösung ?
 
Zuletzt bearbeitet:
Hmm, der verantwortliche Code dafür in res_rtp_asterisk.c bringt diesen Fehler, wenn das eingehende Paket als SSL-Paket identifiziert wird es aber keine dazügehörige SSL session gibt. Also entweder ist der Code in der res_rtp_asterisk.c zur Identifizierung buggy, oder das Telefon sendet tatsächlich ein solches.

Müsste man sich zur weitern Analyse im wireshark ansehen.

Quickfix wäre eine Asteriskversion <11 also den letzten 10er, oder aktuellen 1.8er
 
Danke für den Tipp - ich hab' mal einen Downgrade auf eine 1.8er gemacht, mal schauen, ob sich die Teile dann anders verhalten, dann wäre es tatsächlich ein Hinweis auf einen möglichen Bug in res_rtp_asterisk.c ...


Update:
Mittlerweile steht fest, dass das Problem mit Asterisk 1.8.26 nicht auftritt. Scheinbar gabe es also tatsächlich eine Änderung in res_rtp_asterisk.c, die zumindestens für dieses Grandstream-Telefon dazu führt, dass FTMF-Frames missinterpretiert werden. Da muss ich mal schauen, ob ich mir die Zeit gebe, diesem Bug nachzuforschen ... ich hab' ihn aber erst mal im JIRA eingestellt
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.