Summary:ASTERISK-14080: [patch] NT over PtMP for BRI
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2009-05-07 07:34:16Date Closed:2009-10-23 14:55:21
Versions:Frequency of
Environment:Attachments:( 0) _bri_net_log
( 1) _bri_net_ptmp_log
( 2) call_to_bristuff_ast_ok
( 3) chan_dahdi_nt_ptmp_v1.patch
( 4) chan_dahdi_nt_ptmp_v5.patch
( 5) libpri_nt_ptmp_v3.patch
( 6) libpri_workaround_endless_loop.patch
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
Comments:By: Kristijan Vrban (vrban) 2009-05-07 07:52:03

My first goal i want to achieve, is to make calls from chan_dahdi to the isdn device. The feature to connect multiple isdn devices i less important at the first stage, because in real world setups you mostly need the NT over PtMP only to connect one device, like a ISDN/analog adapter to link one or two analog fax machines, or to link an existing small PBX that has door opener features or so. The case that users really need to link multiple isdn device to one isdn port is rare.

about the jump to the s-Extension, just use overlapdial = yes. Thx to tzafrir for the hint.

By: Kristijan Vrban (vrban) 2009-05-07 12:04:41

i will need some day to read in chan_dadhi, to make a call from chan_dadhi to the isdn device. I think at the first step it's ok simply to use static TEI 127 for a broadcast message. what hopfully should reach the isdn device to make it answer.

By: Kristijan Vrban (vrban) 2009-05-07 15:29:00

when i try to make an outgoing call in bri_net_ptmp, the furthest i reach seems q931_setup in libpri, see bri_net_ptmp_log.

By: Tzafrir Cohen (tzafrir) 2009-05-07 17:40:00

I'm trying a loopback. I can call from the TE to the NT, but a call from the NT to the TE fails: the SETUP message just never shows up as recieved in the pri debug log.

By: Tzafrir Cohen (tzafrir) 2009-05-10 01:58:25

OTOH, I just tried two ISDN phones. At least basic dialing works.

By: Tzafrir Cohen (tzafrir) 2009-05-10 05:10:32

Err... correction:

I can call from the ISDN phone to Asterisk, but not from Asterisk to the ISDN phone. So it's the same as in the loopback

By: Kristijan Vrban (vrban) 2009-05-11 19:38:41

small update: outgoing calls stops in q921_transmit_iframe/q921.c because pri->q921_state is 0. hope tomorrow i notice why. step by step i get what's going on in libpri.

By: Kristijan Vrban (vrban) 2009-05-15 14:09:29

when a second nt-ptmp call arrives in libpri, then a endless loop is starting:
in q921.c line: /*! \todo XXX Error:  The following loop never terminates! */
changeset: rmudgett: branch 1.4 r782 is from May 1, seems that rmudgett is already working on nt_ptmp?

i added the libpri_workaround_endless_loop.patch for this issue. Until it's sure what the  while(sub->subchannel) actually should do, instead of being a endless loop.

By: Kristijan Vrban (vrban) 2009-05-18 14:23:05

check attached file REJ_reject_after_CONNECT ACKNOWLEDGE,

thus far i can call to the isdn device, but i get REJ (reject) from it when libpri
send the CONNECT ACKNOWLEDGE. And i dont know why?

...please ignore the pri_error's, just my debug flags.

By: Kristijan Vrban (vrban) 2009-05-18 15:50:38

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)

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:

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.

By: Kristijan Vrban (vrban) 2009-05-21 20:09:04

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.

By: Kristijan Vrban (vrban) 2009-05-22 19:34:20

the no audio matter is in relation with:

without the: "patch_trunk_183progress_klaus3000.txt" i get audio from between

By: Alec Davis (alecdavis) 2009-07-10 05:05:31

The no audio matter should be fixed in chan_dahdi refer to, committed today.

By: Digium Subversion (svnbot) 2009-10-23 14:55:18

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