Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • Mantis ID:
      15048
    • Regression:
      No

      Description

      Ok, this patch is a naive test i made, but very very limited a bit is allready working. You can call from one connected ISDN device (i used a ISDN/analog adapter DeTeWe TA33) into chan_dadhi. That's all, nothing more. You can't call from chan_dadi to the ISDN device or connect multiple isdn devices.

      Also chan_dadi jumps directly to the s-Extension when you lift up the phone. And dont give you dial tone or wait for digits. But i was pleasantly surprised that NT-ptmp is working anyway.

      Let's start to work on this, to finally ditch bristuff and chan_misdn

      1. bri_net_log
        2 kB
      2. bri_net_ptmp_log
        1 kB
      3. call_to_bristuff_ast_ok
        5 kB
      4. chan_dahdi_nt_ptmp_v1.patch
        0.8 kB
        Kristijan Vrban
      5. chan_dahdi_nt_ptmp_v5.patch
        1 kB
        Kristijan Vrban
      6. libpri_nt_ptmp_v3.patch
        12 kB
        Kristijan Vrban
      7. libpri_workaround_endless_loop.patch
        0.6 kB
        Kristijan Vrban
      8. REJ_reject_after_CONNECT ACKNOWLEDGE
        4 kB

        Activity

        Hide
        Kristijan Vrban added a comment -

        check attached file call_to_bristuff_ast_ok

        The log when i call to an bristuffed *1.4 is working, and looks a bit diffrent:
        the CONNECT ACKNOWLEDGE message we send now looks:
        > Informational frame:
        > SAPI: 63 C/R: 1 EA: 0 <---- SAPI should be 0? 63 is for TEI management
        > TEI: 064 EA: 1
        > N(S): 003 0: 0 <---- What function this line have?
        > N(R): 005 P: 0 <---- What function this line have?
        > 4 bytes of data
        Stopping T_203 timer
        Starting T_200 timer
        – Restarting T200 timer
        > Protocol Discriminator: Q.931 (8) len=4
        > Call Ref: len= 1 (reference 3/0x3) (Originator)
        > Message Type: CONNECT ACKNOWLEDGE (15)

        And the call to mISDNuser:
        > Informational frame:
        > SAPI: 00 C/R: 1 EA: 0 <---- SAPI 0 here is good
        > TEI: 064 EA: 1
        > N(S): 000 0: 0 <---- What function this line have?
        > N(R): 000 P: 0 <---- What function this line have?
        > 4 bytes of data
        Stopping T_203 timer
        Starting T_200 timer
        – Restarting T200 timer
        > Protocol Discriminator: Q.931 (8) len=4
        > Call Ref: len= 1 (reference 2/0x2) (Originator)
        > Message Type: CONNECT ACKNOWLEDGE (15)

        Update:
        ok, i answer my self, because i found it's for the flow control, and libpri as
        the one who receipt need to enumerate it. But it mixed something with the pri->subchannel.

        For the germans which read along here, check:
        http://de.wikibooks.org/wiki/ISDN-Technik (Flusskontrolle)
        and also this pdf:
        http://www.informatik.hu-berlin.de/~goeller/isdn/DerISDNDKanal.pdf

        Update2:
        N(S) and N(R) are consecutive number for all frames between a the NT and the
        Terminal (Identifier) first i thought this number is only increment between a SETUP and the DISCONNECT/RELEASE but it's incremented up to 127 (and then start again with 0) as long as the specific TEI existed.

        Show
        Kristijan Vrban added a comment - check attached file call_to_bristuff_ast_ok The log when i call to an bristuffed *1.4 is working, and looks a bit diffrent: the CONNECT ACKNOWLEDGE message we send now looks: > Informational frame: > SAPI: 63 C/R: 1 EA: 0 <---- SAPI should be 0? 63 is for TEI management > TEI: 064 EA: 1 > N(S): 003 0: 0 <---- What function this line have? > N(R): 005 P: 0 <---- What function this line have? > 4 bytes of data Stopping T_203 timer Starting T_200 timer – Restarting T200 timer > Protocol Discriminator: Q.931 (8) len=4 > Call Ref: len= 1 (reference 3/0x3) (Originator) > Message Type: CONNECT ACKNOWLEDGE (15) And the call to mISDNuser: > Informational frame: > SAPI: 00 C/R: 1 EA: 0 <---- SAPI 0 here is good > TEI: 064 EA: 1 > N(S): 000 0: 0 <---- What function this line have? > N(R): 000 P: 0 <---- What function this line have? > 4 bytes of data Stopping T_203 timer Starting T_200 timer – Restarting T200 timer > Protocol Discriminator: Q.931 (8) len=4 > Call Ref: len= 1 (reference 2/0x2) (Originator) > Message Type: CONNECT ACKNOWLEDGE (15) Update: ok, i answer my self, because i found it's for the flow control, and libpri as the one who receipt need to enumerate it. But it mixed something with the pri->subchannel. For the germans which read along here, check: http://de.wikibooks.org/wiki/ISDN-Technik (Flusskontrolle) and also this pdf: http://www.informatik.hu-berlin.de/~goeller/isdn/DerISDNDKanal.pdf Update2: N(S) and N(R) are consecutive number for all frames between a the NT and the Terminal (Identifier) first i thought this number is only increment between a SETUP and the DISCONNECT/RELEASE but it's incremented up to 127 (and then start again with 0) as long as the specific TEI existed.
        Hide
        Kristijan Vrban added a comment -

        i attached libpri_nt_ptmp_v3.patch and chan_dahdi_nt_ptmp_v5.patch, a highly experimental hack to add NT-PTMP mode into libpri.

        You can call from chan_dahdi to one isdn device, it get a TEI and
        it ring, but if you lift up the isdn device, chan_dahdi dont transport audio:

        DEBUG[22402]: chan_dahdi.c:7068 dahdi_write: Dropping frame since I'm still dialing on DAHDI/1-1...

        But audio basically is arriving from the isdn device. When i set a MixMonitor before Dial, i can hear my voice from the isdn device in the recorded file.

        The main work it need, is the pri->subchannel, we need a subchannel for every TEI, and if a call from a specific TEI is incoming, we need to use the subchannel for this TEI. Now in the hack, i just use only one subchannel for every TEI, this work only if only one device is attached.

        And second, we need to spot, why chan_dahdi dont transport the audio(the p->dialing is still activ) after libpri get CONNECT and send the CONNECT ACKNOWLEDGE.

        Show
        Kristijan Vrban added a comment - i attached libpri_nt_ptmp_v3.patch and chan_dahdi_nt_ptmp_v5.patch, a highly experimental hack to add NT-PTMP mode into libpri. You can call from chan_dahdi to one isdn device, it get a TEI and it ring, but if you lift up the isdn device, chan_dahdi dont transport audio: DEBUG [22402] : chan_dahdi.c:7068 dahdi_write: Dropping frame since I'm still dialing on DAHDI/1-1... But audio basically is arriving from the isdn device. When i set a MixMonitor before Dial, i can hear my voice from the isdn device in the recorded file. The main work it need, is the pri->subchannel, we need a subchannel for every TEI, and if a call from a specific TEI is incoming, we need to use the subchannel for this TEI. Now in the hack, i just use only one subchannel for every TEI, this work only if only one device is attached. And second, we need to spot, why chan_dahdi dont transport the audio(the p->dialing is still activ) after libpri get CONNECT and send the CONNECT ACKNOWLEDGE.
        Hide
        Kristijan Vrban added a comment -

        the no audio matter is in relation with:
        https://issues.asterisk.org/view.php?id=13034

        without the: "patch_trunk_183progress_klaus3000.txt" i get audio from between
        chan_sip<>chan_dahdi<>libpri_nt_ptmp<->isdn_device

        Show
        Kristijan Vrban added a comment - the no audio matter is in relation with: https://issues.asterisk.org/view.php?id=13034 without the: "patch_trunk_183progress_klaus3000.txt" i get audio from between chan_sip< >chan_dahdi< >libpri_nt_ptmp<->isdn_device
        Hide
        Alec Davis added a comment -

        The no audio matter should be fixed in chan_dahdi refer to, committed today.
        https://issues.asterisk.org/view.php?id=15389

        Show
        Alec Davis added a comment - The no audio matter should be fixed in chan_dahdi refer to, committed today. https://issues.asterisk.org/view.php?id=15389
        Hide
        Digium Subversion added a comment -

        Repository: libpri
        Revision: 1242

        U branches/1.4/libpri.h
        U branches/1.4/pri.c
        U branches/1.4/pri_facility.c
        U branches/1.4/pri_facility.h
        U branches/1.4/pri_internal.h
        U branches/1.4/pri_q921.h
        U branches/1.4/pri_q931.h
        U branches/1.4/q921.c
        U branches/1.4/q931.c

        ------------------------------------------------------------------------
        r1242 | rmudgett | 2009-10-23 14:55:17 -0500 (Fri, 23 Oct 2009) | 16 lines

        Add BRI PTMP NT mode, HOLD/RETRIEVE, Call rerouting/deflection, and keypad facility support.

        • Added support for BRI PTMP NT mode. (Overlap dialing NT -> TE not supported.)
        • Added handling of received HOLD/RETRIEVE messages and the optional ability
          to transfer a held call on disconnect similar to an analog phone.
        • Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP.
          Will reroute/deflect an outgoing call when receive the message.
          Can use the DAHDISendCallreroutingFacility to send the message for the
          supported switches.
        • Added ability to send/receive keypad digits in the SETUP message.
          Send keypad digits in SETUP message: Dial(DAHDI/g1[/K<keypad_digits>][/extension])
          Access any received keypad digits in SETUP message by: $ {CHANNEL(keypad_digits)}

        (closes issue ASTERISK-14080)
        Tested by: rmudgett, mattf

        ------------------------------------------------------------------------

        http://svn.digium.com/view/libpri?view=rev&revision=1242

        Show
        Digium Subversion added a comment - Repository: libpri Revision: 1242 U branches/1.4/libpri.h U branches/1.4/pri.c U branches/1.4/pri_facility.c U branches/1.4/pri_facility.h U branches/1.4/pri_internal.h U branches/1.4/pri_q921.h U branches/1.4/pri_q931.h U branches/1.4/q921.c U branches/1.4/q931.c ------------------------------------------------------------------------ r1242 | rmudgett | 2009-10-23 14:55:17 -0500 (Fri, 23 Oct 2009) | 16 lines Add BRI PTMP NT mode, HOLD/RETRIEVE, Call rerouting/deflection, and keypad facility support. Added support for BRI PTMP NT mode. (Overlap dialing NT -> TE not supported.) Added handling of received HOLD/RETRIEVE messages and the optional ability to transfer a held call on disconnect similar to an analog phone. Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP. Will reroute/deflect an outgoing call when receive the message. Can use the DAHDISendCallreroutingFacility to send the message for the supported switches. Added ability to send/receive keypad digits in the SETUP message. Send keypad digits in SETUP message: Dial(DAHDI/g1 [/K<keypad_digits>] [/extension] ) Access any received keypad digits in SETUP message by: $ {CHANNEL(keypad_digits)} (closes issue ASTERISK-14080 ) Tested by: rmudgett, mattf ------------------------------------------------------------------------ http://svn.digium.com/view/libpri?view=rev&revision=1242

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development