[Home]

Summary:ASTERISK-06093: [patch][post 1.4] Add possibility to set Zap channels into hdlc mode
Reporter:crich (crich)Labels:
Date Opened:2006-01-16 02:53:54.000-0600Date Closed:2011-06-07 14:02:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap.patch.txt
( 1) chan_zap.patch-2.txt
( 2) chan_zap.patch-3.txt
( 3) chan_zap.patch-4.txt
Description:This patch adds an application ZapSetHDLC and an option to the zap channel dialstring, which allow incoming and outgoing zap channels to be setted into HDLC Mode.

The patch adds an element hldc to the zt_pvt struct. When either for incoming calls ZapSetHDLC is called or for outgoing calls the h option is given, the corresponding zap channel is set into HDLC mode via ioctl(ZT_HDLCFCSMODE) in PRI_HANGUP  the patch sets back the channel into ZT_AUDIOMODE.

Additionally in my_zt_write and zt_read it is checked at particular places if hdlc mode is set, and then the sample rate is set directly for example, rather then useing READ_SIZE and so forth.


My feature plans are adding a frame subclass AST_MODEM_HDLC. Applications or channels that need to transfer data in hdlc mode could just send with that type and the other channel driver could activate its hdlc controller.


With this construction i could make a successful data call between chan_misdn and chan_zap channel.

The Patch does NOT change anything when hdlc mode is not set, which means it will not touch current installations.

****** ADDITIONAL INFORMATION ******

Disclaimer on File
Comments:By: crich (crich) 2006-01-18 17:07:15.000-0600

*bump*
By: crich (crich) 2006-01-19 11:14:51.000-0600

Just found out that we need to change the blocksize for larger HDLC frames. The normal Blocksize with audio channels is 160. How large can HDLC Frames be on the bchannel ?

I'll resize it to 1025 now, hope thats enough.
By: crich (crich) 2006-01-19 12:12:31.000-0600

We'll need about 2048 bytes, because thats the maximum size for a hdlc frame on a data link.

I changed the buffer size of the zt_pvt structure to 2050 bytes to hold one fullsize hdlc frame.

That will of course use much more memory!! Any Ideas on how to optimize that are very welcome.

I tested that and transmitted several Megabytes through a data link between chan_misdn and chan_zap.

It works quite nice for me now.
By: kib (kibeki) 2006-01-22 12:16:29.000-0600

We successfully testet the chan_zap.patch-3.txt!

We established calls of type DIGITAL with transferring big files (2MB) over that link.


By: Matthew Fredrickson (mattf) 2006-01-24 12:44:07.000-0600

Pardon my ignorance, but I'm not sure if I'm seeing how this applies.  Can you explain better how you used this to make a data call between chan_misdn and chan_zap?  Thanks.
By: crich (crich) 2006-01-24 14:00:31.000-0600

Hi mattf,

the patch adds 2 things to chan_zap:

1. an Applikation: ZapSetHDLC
2. an Option to the dialstring h  ( dial(zap/g0h/123) )

These are used to set either an incoming->ZapSetHDLC or an outgoing h-option call into HDLC Mode. To be more precise the bchannel will be set into HDLC Mode.

Chan_misdn has similar applications/options to activate HDLC encoding/decoding on a bchannel.

Now Lets assume someone has this configuration:

  Computer1 with avm card --> BRI mISDN Card --> * --> PRI Zap Card --> PSNT --> Computer2 with avm card


which is a very common configuration for european PBXs.

I thought that it would be enough to use tranparent mode (i mean just send the data as voice data), it looked all more or less well, but there where some bits/bytes left i think, because the PRI and the BRI cards have no common timing source

so i thought the most secure way is to transport the whole  decoded HDLC Frames from chan_misdn through asterisk (at the moment with frametype == voice) into chan_zap and encode it again and then out.


thats it.

I needed to modify some bits in chan_zap to handle bigger Frames then READ_SIZE. I also plan to add a sublcass MODEM_HDLC_FRAME to AST_FRAME_MODEM. Ideas are welcome.

The dialplan looks like:

misdn.conf:

ports=1
context=bri2Zap


extensions.conf:

[bri2Zap]
exten => _X.,1,misdn_set_opt(h1)
exten => _X.,1,Dial(Zap/g0h/1234)



the other way would be:

zapata.conf:
context=zap2bri
channels=>1-15,17-31


extensions.conf:

[zap2bri]
exten => _X.,1,ZapSetHDLC()
exten => _X.,2,Dial(mISDN/g:Computer1/123/h1)



hope this clarifies it all.
By: crich (crich) 2006-01-24 14:02:30.000-0600

I need to mention that i needed to resize the buffer in the zt_pvt structure which means a lot more memory usage.

We may need to allocate an extra buffer for datacalls, or make this at compile time activateable. In Europe usually only a few calls will be HDLC. Very Seldom it will be every call.
By: crich (crich) 2006-02-04 02:37:52.000-0600

* bump *
By: crich (crich) 2006-02-10 13:50:54.000-0600

I thought about how one can test this patch without having a mISDN card:

The patch allows a Zap channel to be set into HDLC Mode, which means one can transport for example raw text over this connection. This can be done with the applikation app_pipe which is part of the app_bundle available at: http://www.beronet.com/downloads/apps/app_bundle.tar.gz

This applikation does nothing more than creatin a pipe and connceting it to a forked child, this results in attaching STDIN and STDOUT to the given application.

In the testscenario one could start app_pipe with netcat as programm sitting on port 10001  waiting for tcp connects. the receiving side would start netcat on port 10002 waiting for tcp connects.

If the calls where made in hdlc mode (originating with the h option and receiving with ZapSetHDLC) you should be able to connect with netcat on both ports and have a chat between these sockets.

the scenario would look like:


nc1 <--> nc 10001 <--> pipe <--> chan_zap pri1 <---> chan_zap pri2 <---> pipe nc 10002 <---> nc2


nc1 should be able to send text to nc2 and vice versa. I haven't tested that yet, but i'm quite sure that it'll work, since the patch works between chan_misdn and chan_zap.
By: Olle Johansson (oej) 2006-02-23 02:03:27.000-0600

Included in the test branch - test-this-branch
By: Michael Labuschke (zigman) 2006-02-23 09:49:08.000-0600

working perfectly here. Thanks crich.
setup Winbox -> quadbri NT -> quadbri -> TE -- pstn --> winbox (pcanywhere) or * (zapras)
both working. unlike without that patch.

now.. anyone willing to port iaxmodem to windows ? ;) (and using {u,a}law for transfering the (digital) data)
By: crich (crich) 2006-02-23 10:43:07.000-0600

for outgoing calls we activate the hdlc controller in zt_call instead of activating it in the first setup reply-> SETUP_ACKNOWLEDGE. This message mustn't arrived, so sometimes the hdlc controller wasn't enabled at all.

fixed in patch-4.
By: crich (crich) 2006-02-23 10:43:54.000-0600

forgot to mention that patch-4 is made against trunk revision: 10872
By: Michael Labuschke (zigman) 2006-02-23 16:31:36.000-0600

sorry i was too fast with the note. it was working woth the qozap but not wit 2 hfc-s cards ( bristuff).
[00:30:10]     -- Executing ZapSetHDLC("Zap/1-1", "") in new stack
[00:30:10] NOTICE[15386]: chan_zap.c:2428 zap_set_hdlc_exec: ZapSetHDLC called
[00:30:10]     -- Executing Dial("Zap/1-1", "zap/g2h/61389232") in new stack
[00:30:10] NOTICE[15386]: chan_zap.c:7985 zt_request: Setting Digital mode with hdlc encryption
[00:30:10]     -- Requested transfer capability: 0x08 - DIGITAL
[00:30:10] NOTICE[15386]: chan_zap.c:2428 zap_set_hdlc_exec: ZapSetHDLC called
[00:30:10]     -- Called g2h/61389232
[00:30:10]     -- Zap/4-1 is proceeding passing it to Zap/1-1
[00:30:11] WARNING[19699]: chan_zap.c:8307 zt_pri_error: 2 TEI remove TEI = 115
[00:30:11]     -- IAX2/141.48.223.56:4569-4 stopped sounds
[00:30:11]     -- IAX2/141.48.223.56:4569-4 answered Zap/2-1
[00:30:13]     -- Zap/4-1 answered Zap/1-1
[00:30:13]     -- Attempting native bridge of Zap/1-1 and Zap/4-1
[00:30:13] WARNING[15386]: chan_zap.c:1597 zt_disable_ec: Unable to disable echo cancellation on channel 1
[00:30:13] WARNING[15386]: chan_zap.c:1597 zt_disable_ec: Unable to disable echo cancellation on channel 4
[00:30:13] WARNING[15386]: chan_zap.c:1379 conf_add: Failed to add 16 to conference 9/1
[00:30:13] WARNING[15386]: chan_zap.c:1379 conf_add: Failed to add 13 to conference 9/4
[00:30:13] WARNING[15386]: chan_zap.c:1379 conf_add: Failed to add 16 to conference 9/1
[00:30:13] WARNING[15386]: chan_zap.c:4759 zt_read: Unable to set channel 4 (index 0) to linear mode.
[00:30:13] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:14] WARNING[15386]: chan_zap.c:4759 zt_read: Unable to set channel 1 (index 0) to linear mode.
[00:30:14] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:16] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:16] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:19] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:19] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:22] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:23] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:26] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:27] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:29] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:31] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:32] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:35] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:35] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:38] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 18
[00:30:39] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17
[00:30:43] NOTICE[15386]: chan_zap.c:4802 zt_read: READ: 17

is this a bristuff problem or could this be a hdlc thing.
i'm using patch 4
By: crich (crich) 2006-02-24 02:17:41.000-0600

I didn't try with bristuff, so i can't tell if it works the same or not. I can see in your logs that you are using the patch correctly. But i can also see that only READ calls occur, there should be a corresponding WRITE for each READ. This maybe because of the created bridge, I'm not sure what happens then.

Anyway I did attach a Patch with debugging enabled, i will submit a patch which has debug disabled later.

Btw. The patch is intended to make inter-channel Digital Call bridging possible. Which means if you like to send a digital call from a ZAP channel to a IAX channel, or what i test here from a mISDN channel to a Zap channel. I believe there can be problems using it with Zap to Zap bridging.

Probably you should send a bugreport to zaphfc - guys, that digital calls aren't bridged proper.
By: Serge Vecher (serge-v) 2006-06-05 10:38:27

crichL: can we get an updated patch for trunk please, so this can be considered for 1.4 beta?
By: crich (crich) 2006-06-05 14:11:25

I'm  going to make an actual patch when i have a few minutes.
By: jmls (jmls) 2006-10-31 13:33:42.000-0600

any news on that patch ;)
By: crich (crich) 2006-10-31 14:49:12.000-0600

Unfortunately i wasn't yet able to keep this patch up-to-date.
By: jmls (jmls) 2006-10-31 15:47:11.000-0600

will you be able to suppy an updated patch, or should we close this ?
By: crich (crich) 2006-11-06 10:36:43.000-0600

I think we can close this.
By: jmls (jmls) 2006-11-06 10:41:03.000-0600

closed at reporters request.
By: Digium Subversion (svnbot) 2008-01-15 16:18:43.000-0600

Repository: asterisk
Revision: 8277

U   team/crichter/0.3.0/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r8277 | crichter | 2008-01-15 16:18:42 -0600 (Tue, 15 Jan 2008) | 1 line

the ACK_HDLC Stuff needs to be activated explicitly. Datalinks between chan_misdn and chan_zap work quite sweet without it, but with the patch from ASTERISK-6093
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=8277
By: Digium Subversion (svnbot) 2008-01-15 16:56:44.000-0600

Repository: asterisk
Revision: 10763

U   team/crichter/0.3.0/channels/chan_misdn.c
U   team/crichter/0.3.0/channels/chan_zap.c
U   team/crichter/0.3.0/channels/misdn/isdn_lib.c
U   team/crichter/0.3.0/channels/misdn/isdn_msg_parser.c

------------------------------------------------------------------------
r10763 | crichter | 2008-01-15 16:56:43 -0600 (Tue, 15 Jan 2008) | 5 lines

* changed some strncpys to ast_copy_str
* added copying of some IEs (user,rate,urate) with channel vars
* added ASTERISK-6093


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

http://svn.digium.com/view/asterisk?view=rev&revision=10763
By: Digium Subversion (svnbot) 2008-01-15 16:57:05.000-0600

Repository: asterisk
Revision: 10787

U   trunk/channels/chan_misdn.c
U   trunk/channels/misdn/isdn_lib.c
U   trunk/channels/misdn/isdn_msg_parser.c

------------------------------------------------------------------------
r10787 | crichter | 2008-01-15 16:57:05 -0600 (Tue, 15 Jan 2008) | 5 lines

* changed some strncpys to ast_copy_str
* added copying of some IEs (user,rate,urate) with channel vars
* added ASTERISK-6093


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

http://svn.digium.com/view/asterisk?view=rev&revision=10787