[Home]

Summary:ASTERISK-03375: [branch] adds support for SERVice maintenance messages
Reporter:cmaj (cmaj)Labels:
Date Opened:2005-01-28 14:22:36.000-0600Date Closed:2009-04-14 10:56:21
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap_service.diff2
( 1) chan_zap_service.diff5.txt
( 2) chan_zap_service.diff6.txt
( 3) chan_zap_service.diff7.txt
( 4) chan_zap_service.diff8.txt
( 5) chan_zap_service.patch1
( 6) first_run.txt
( 7) jere042105_otm6_asterick_124.txt
( 8) libpri_service.diff2
( 9) libpri_service.diff3.txt
(10) libpri_service.diff4.txt
(11) libpri_service.diff5.txt
(12) libpri_service.diff6.txt
(13) libpri_service.diff7.txt
(14) libpri_service.patch1
(15) number2.txt
(16) chan_zap_service.diff10.txt
(17) chan_zap_service.diff11.txt
(18) chan_zap_service.diff12.txt
(19) chan_zap_service.diff9.txt
(20) libpri_service.diff8.txt
(21) libpri_service.diff9.txt
Description:From my email to ast-dev list:

> I'm trying to add better support to libpri for maintenance
> protocol SERVice and SERVice ACKnowledgement messages.  The
> code is marked in q931.c as being a 'KLUDGE' and should be
> ripe by now for fixing.
>-
> Things work great on my test machine with a T400 and a loop
> back cable.  B-Channels are able to go in and out of
> service, and the state is stored in chan_zap.c so that
> channels out of service are immediately skipped when
> attempting a call on them (similar to Do Not Disturb.)
>-
> Problem is, I can't get it to work in the real world.  And
> given that this is a non-ITU message type, I'm not sure if
> it's me or the switch that doesn't want to play nice.  As
> best I can tell, these SERVice messages are defined in ANSI
> T1.607 with a list price of $360 -- no 3 freebie downloads
> like the ITU specs.  Thus, I've scoured various other web
> resources to cobble together the implementation.
>-
> If I'm correct in my assumptions so far, these NFAS/CCS
> SERVice messages are required for proper operation of backup
> D-Channels, in addition to maintenance of B-Channels.
> Currently, it appears although * supports the use of a
> backup D-Channel, it is not able to initiate a backup
> procedure -- only follow what the far-end switch does.
>-
> I'm attaching a patch of what I have so far, but what I
> could really, really use from some kind soul is a PRI trace
> of a proper SERV exchange for maintenance on a B-Channel.
> If you want to try the patch, it adds CLI commands:
> "zap service enable|disable|loop channel <chan num>"
> (Very similar to the Cisco IOS Dial Technologies command:
> "isdn service <chan num> state 0|1|2")
Comments:By: cmaj (cmaj) 2005-01-28 14:23:31.000-0600

Disclaimer is on file.
By: Paul Cadach (pcadach) 2005-01-28 14:50:55.000-0600

One suggestion: to not change too much of code just treat msgtype argument (which is int, i.e. 32 bit, but msgtype is a single byte within Q.931 header) as combination of protocol type and protocol-related message code. For example, t1607_maintenance_service() function will finish with
return send_message(pri, c, (T1607_MAINTENANCE_PROTOCOL_DISCRIMINATOR << 8) | T1607_MAINTENANCE_SERVICE, maintenance_service_ies);
instead of
return send_message(pri, c, T1607_MAINTENANCE_SERVICE, maintenance_service_ies, T1607_MAINTENANCE_PROTOCOL_DISCRIMINATOR);
By: Paul Cadach (pcadach) 2005-01-28 14:58:22.000-0600

Also, chan_zap_service.patch1 really is tar.gz, not regular text file.
By: cmaj (cmaj) 2005-01-28 15:48:05.000-0600

Thank you for the suggestions.  I have incorporated them into the diff2 patches.  Although there's still a lot of whitespace moving around, I was unsure about breaking the maintenance stuff out into a separate file.
By: Paul Cadach (pcadach) 2005-01-28 16:10:10.000-0600

There is something non-verificable after
pri_message("Sending facility event (%s/%s)\n", pri...
line... Check formatting rules, please.

Also, I see you had included my patch from ASTERISK-3372 - this could make problems to apply our patches together.
By: cmaj (cmaj) 2005-01-28 16:49:37.000-0600

I'm not sure what you mean about non-verificable, but I pulled that ifdef out anyhow for good measure.  Also, that patch just got applied and I wanted to keep my stuff up with current.
By: Paul Cadach (pcadach) 2005-01-28 17:53:42.000-0600

Under "non-verificable" I mean I can't compare changes "on-the-fly" at diff-file. There is many pieces of sequential deletion and addition - good change to miss something.
By: cmaj (cmaj) 2005-01-28 18:22:05.000-0600

diff4 was done with -w option to diff so all whitespace was removed.
By: cmaj (cmaj) 2005-01-28 18:44:29.000-0600

It's probably best just to ignore the Codeset 7 stuff, that was how I first implemented it but I don't think it's necessary.  That's one of the problems with not having a good spec I guess.
By: Paul Cadach (pcadach) 2005-01-29 00:43:54.000-0600

Last patch looks more fancy than previous ones.
By: Mark Spencer (markster) 2005-02-03 00:26:12.000-0600

So is this patch ready for merger?  Has it actually been show to be operational?
By: cmaj (cmaj) 2005-02-04 13:44:10.000-0600

It works with a loop back cable between two spans on a T400 in my test machine, but AFAIK it has yet to work with an outside PRI implementation.  I've tried it, but the switch jockey on the far-end I was working with couldn't take B-Channels out with his equipment either, so I kind of got stuck.  I asked the dev list for help with a D-Channel trace, but that didn't go anywhere, either.  The worst case scenario if this patch is applied is that somebody complains B-Channel SERVice messages don't work properly -- plus side of that is then I've got somebody who can give me a trace so it will work correctly.  Also, the handling of these messages was kind of a hack before, and if my bits are found not to b correctly ordered, at least they are closer to being in the right place than before.

Anyhow, I've updated diff5 to patch against current CVS.
By: Matthew Fredrickson (mattf) 2005-04-12 12:28:23

Any new progress on this?
By: Matthew Fredrickson (mattf) 2005-04-20 11:00:32

No Ack.
By: cmaj (cmaj) 2005-04-21 08:49:16

Updated patch due to 2 users expressing interest in this functionality -- and testing it -- on the dev-list.
By: cmaj (cmaj) 2005-04-21 09:26:02

The two diff6 patches are against current CVS HEAD.
By: drmac (drmac) 2005-04-21 14:23:57

my "first_run" with this patch is posted.

How can I turn on pri debugging immediatly?
By: cmaj (cmaj) 2005-04-21 14:55:46

diff6 ???  I just checked and it still applies clean to HEAD, maybe try a fresh CVS checkout into a new directory...
By: drmac (drmac) 2005-04-21 16:18:13

ok. CVS-HEAD patched with no probs. I was using libpri and zaptel HEAD but not asterisk. wierd.

anyway. take a peek at number2.txt. Alot of stuff flew across and I wasn't capturing. I had just previously done a "load chan_zap.so"
By: drmac (drmac) 2005-04-21 16:34:00

CLI>zap service disable channel 2
CLI>

meaning, nothing happened. Another tech was monitoring the b-channel status and he said nothing happened either.

When I used channel numbers 24 and 48 I got "Unable to find given channel 24". 24 and 48 are my D-Channels; as are 72 and 96

all other channels gave same "nothing happened" result as above.

what do you need me to do? HTH.
By: drmac (drmac) 2005-04-21 16:57:35

check out "jere042105_otm6_asterick_124.txt" for some PRI debug stuff from our switch.

somewhere during this debug I did the following commands:

zap service disable channel 1
zap service disable channel 2
zap service disable channel 3
zap service disable channel 4
zap service disable channel 5
zap service enable channel 1
zap service enable channel 2
zap service enable channel 3
zap service enable channel 4
zap service enable channel 5

hope that helps some.
By: cmaj (cmaj) 2005-04-22 18:37:44

diff7 fixes the couple of bits that were screwed up in previous diffs, thanks for the traces to help nail that down.  Also, diff7 adds support for servicing d-channels, a la "zap service disable channel 24" should bring down span 1.  It doesn't stay down right now -- I'm just trying to get it to take down something besides my loop back cables on the t400p.
By: drmac (drmac) 2005-04-22 23:49:48

this is gonna suck, but we "let go" our switch operator today so I won't be able to provide you as great of details (from the switch side) as I could before..at least not until i read the manual and do it myself.

i should still be able to get you pri dumps from asterisk.

will try new patch this weekend.
By: cmaj (cmaj) 2005-04-23 12:30:43

I think you patched STABLE and not HEAD.
By: cmaj (cmaj) 2005-04-23 14:19:25

hmm...

chris@spira:~/dev/asterisk/cvs/head$ mkdir fresh
chris@spira:~/dev/asterisk/cvs/head$ cd fresh
chris@spira:~/dev/asterisk/cvs/head/fresh$ export CVSROOT=:pserver:anoncvs@cvs.digium.com:/usr/cvsroot
chris@spira:~/dev/asterisk/cvs/head/fresh$ cvs co -r HEAD libpri
cvs server: Updating libpri
U libpri/.cvsignore
U libpri/ChangeLog
U libpri/LICENSE
U libpri/Makefile
U libpri/README
U libpri/TODO
U libpri/compat.h
U libpri/libpri.h
U libpri/mkdep
U libpri/pri.c
U libpri/pri_facility.c
U libpri/pri_facility.h
U libpri/pri_internal.h
U libpri/pri_q921.h
U libpri/pri_q931.h
U libpri/pri_timers.h
U libpri/pridump.c
U libpri/prisched.c
U libpri/pritest.c
U libpri/q921.c
U libpri/q931.c
U libpri/testprilib.c
chris@spira:~/dev/asterisk/cvs/head/fresh$ cd libpri/
chris@spira:~/dev/asterisk/cvs/head/fresh/libpri$ patch -p0 < ../../patches/libpri_service.diff7.txt
patching file libpri.h
patching file pri.c
patching file pri_internal.h
patching file pri_q921.h
patching file pri_q931.h
patching file q921.c
patching file q931.c
chris@spira:~/dev/asterisk/cvs/head/fresh/libpri$
By: cmaj (cmaj) 2005-04-23 14:23:00

Can you upload your current libpri.h ?  Or maybe one of the reject files ?
By: cmaj (cmaj) 2005-04-26 12:14:19

diff8 (chan_zap only as of right now, libpri is still fine I think) should fix that conflict, and it adds the unregisters.  Thanks.
By: drmac (drmac) 2005-04-27 19:41:26

patches applying like champs now.

i will try and get more debug stuff for you sometime this week.

is asterisk pri debugging suffecient? or does it help to have the debug stuff from our switch as well?
By: cmaj (cmaj) 2005-04-27 20:17:56

There's a new debug pri to file command in HEAD, which works quite nice.

pri set debug file SOMEFILE
pri intense debug span 1

(zap service stuff here)

That SOMEFILE would be super.  I guess having that is half the battle.  Both sides (network/cpe) are nice, like last week, but something is sure better than nothing.
By: drmac (drmac) 2005-04-27 21:17:46

i'll get you both; but it will take me a bit to get the switch side cause i gotta learn how to do that since our tech is gone.
By: drmac (drmac) 2005-05-04 16:15:59

the newest version of libpri has some problems in it so I have to wait for them to be resolved before I can continue testing this. But from the testing that I have done, it looks great.

If I use libpri after April 22, 2005 then I cannot complete calls. I have to use: cvs co libpri -D "April 21, 2005".
By: drmac (drmac) 2005-05-04 16:22:06

n/m..it seems your patch applys fine to the 4/21 release of libpri.

continuing to test...
By: Matthew Fredrickson (mattf) 2005-05-06 10:12:52

So is this tested and working on a real switch now?
By: drmac (drmac) 2005-05-06 11:56:25

It's compiled against libpri version 04/21/05 as the version on 04/22 doesn't allow me to make calls.

I can't seem to take down an entire span by disabling the D-Chan.

Matt, since you are the libpri creator, do you need anything to compare/confirm/etc with this patch? I can get debugs from both asterisk and our switch.
By: cmaj (cmaj) 2005-05-06 12:18:35

I would like to see some more debug, if possible, from both sides.  How are you confirming that it's taking the channels down ?  Does the other switch respond to asterisk with SERV ACK ?
By: cmaj (cmaj) 2005-05-06 12:19:29

Also, could you maybe post some debug when you try to take down a whole span ?
By: Michael Jerris (mikej) 2005-05-06 12:30:53

At least on several other switches I have taking down a D Chan and taking down a span are very different, especially when using nfas for backup d channels.  The ability to bounce a span individually would be very nice as well.
By: cmaj (cmaj) 2005-05-09 11:32:25

To clarify, taking down a span means tearing down all the B-channels, whereas taking down a D-channel would only cause rollover to the backup D-channel ?

If that's the case, then I'm just trying to get the code to take down a D-channel, first.  I think the bits are a little out of whack for doing that.  Also, there isn't really this distinction yet made between span and D-channel operations on the CLI, so I'm kind of feeling my way thru that, too.
By: Matthew Fredrickson (mattf) 2005-06-23 13:35:58

Did you guys ever find out if this works?
By: drmac (drmac) 2005-06-27 21:38:04

needs to be brought up to date with current CVS..
By: Matthew Fredrickson (mattf) 2005-07-06 11:19:28

I haven't heard that this actually works yet on real hardware and there is no activitiy.  Reopen if there is anymore activitiy.
By: Serge Vecher (serge-v) 2006-09-22 11:09:36

cmaj has requested this bug to be reopened and will post a patch updated to current trunk sooon.
By: cmaj (cmaj) 2006-09-22 13:46:36

Patches updated to trunk but need testing.
By: cmaj (cmaj) 2006-09-22 13:48:02

Commands changed names from "zap service ..." to "pri service ..."
By: cmaj (cmaj) 2006-09-22 14:06:05

Minor mod in chan_zap diff 10 prevents core dump when no PRIs.
By: Steve Murphy (murf) 2006-11-02 08:18:25.000-0600

This has been simmering and bubbling for a long while. Is it ready to serve yet?
By: Serge Vecher (serge-v) 2006-11-08 16:08:30.000-0600

I think this is waiting for some testing results. Cmaj: can you please find some testers and get them to report on the results of testing your patch?
By: Serge Vecher (serge-v) 2007-01-09 12:57:55.000-0600

cmaj: are you still interested in this? I hope your efforts do not go in vain ...
By: Serge Vecher (serge-v) 2007-02-26 16:10:05.000-0600

happy 2-year anniversary
By: Paulo Mendes da Silva (kanelbullar) 2007-03-22 11:31:08

We are experiencing a problem with an NFAS connection that appears to be the same. We are using a dual pri card, with a primary D channel and a backup D channel. NFAS configuration parameters appear to be correct and follow the guidelines that can be found on the web. However, no B-channels come up and D-channels also appear not to come up properly, as the following message is displayed when we attempt to make calls:

Mar 19 15:33:58 WARNING[3322] chan_zap.c: No D-channels available!  Using Primary channel 24 as D-channel anyway!

When we look into 'pri intense debug span', we can see that maintenance messages are being exchanged (Protocol Discriminator: AT&T Maintenance (3)), but due to the 'KLUDGE' that was mentioned in the description of this bug, responses are the same as requests, appart from a bit that is changed.

This is what we see:

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 004   0: 0
< N(R): 005   P: 0
< 10 bytes of data
-- ACKing all packets from 4 to (but not including) 5
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: AT&T Maintenance (3)  len=10
< Call Ref: len= 1 (reference 0/0x0) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
< [01 01 c0]
< IE: Change Status (len = 3)
< [18 01 ac]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 1
<                        ChanSel: As indicated in following octets
                        ]

> [ 00 01 0a 0a 03 01 00 07 01 01 c0 18 01 ac ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 005   0: 0
> N(R): 005   P: 0
> 10 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: AT&T Maintenance (3)  len=10
> Call Ref: len= 1 (reference 0/0x0) (Originator)
> Message type: CONNECT (7)
> [01 01 c0]
> IE: Change Status (len = 3)
> [18 01 ac]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 1
>                        ChanSel: As indicated in following octets
                        ]
                       
This message exchage is repeated once in a while, but no calls can be made, since there are in fact no B-Channels available.

Do you think our problem could be solved by using this patch? Has anyone seen these messages being exchanged with no success?

Thanks in advance.
By: cmaj (cmaj) 2007-03-26 06:47:15

kanelbullar, I don't know if this patch will solve your problem completely, but it will get a lot closer than any other patch that I've seen.  If you could try  libpri_service.diff8.txt and chan_zap_service.diff11.txt, they should both apply cleanly to the latest asterisk 1.4.2 & libpri 1.4.0

Once you apply the patches, please run on the asterisk CLI commands like "pri service enable channel 1" and others, and post the log output.  (Ideally, that command would bring up your first B-Channel.)
By: cmaj (cmaj) 2007-03-27 15:27:52

I got a really helpful switch jockey on the phone today while fixing some other problem, and eventually we got into testing the service channel messages.  He said this will probably not work on "national" switch types because those follow the bellcore spec.  Those following the ANSI spec, this will work, like 4ess, 5ess, dms100, dms250, at&t custom.  Currently, to the best of my reading of libpri, there really isn't much difference in the way libpri handles these switch types other than letting you write something different in the zapata.conf

Anyhow, after changing their SONUS setup from ni2 (national) to 5ess, we tested taking B-Channels in and out of service, and he said it looks good.  The "pri service disable/enable channel N" commands are working!

There is a problem with the D-Channel service handling.  I will fix that in an updated patch very shortly.  I think it's just a bad interface id value.  But again, servicing a D-Channel isn't much good unless you are in an NFAS situation with 2 or more PRIs -- than disabling one D-Channel will cause the other D-Channel to come up on the other PRI.  So, I still do not have that kind of setup, having only one PRI with this provider, but it will be interesting to see what happens.

Also, if you are using NFAS, then it is a requirement that these service messages bring up your D-Channel.  My guess is a lot of network switches will let you get away with not using service messages to do it.  But according to the guy I talked to, the correct according to spec way is with service messages.
By: cmaj (cmaj) 2007-03-29 00:16:45

The last two patches fix a minor problem with B-channel disabling and add support for D-channel servicing.

I am now able to take B-channels in and out of service with both Asterisk and the far-end switch acknowledging the change status.  For example, when there are no calls up, I disable B-channel 1, then dial a DID, and the call comes in from the switch on B-channel 2.

I added support to specify the DS1 interface ID on D-channel servicing in the form "pri service disable channel 24 0" where 0 is the interface ID.  This accounts for the cases where the far-end switch assigns an interface ID.  I'm not able to prove it works tho because I don't have access to NFAS for testing.
By: seb7 (seb7) 2007-03-29 07:56:24

Are these new features expected to work with the EuroISDN switchtype?
By: cmaj (cmaj) 2007-03-29 09:45:11

I don't think it will work on EuroISDN.  It is only going to work on ISDN protocols that follow the ANSI standard, and ANSI is an American group.  No harm in trying it tho, to confirm.
By: Matthew Fredrickson (mattf) 2007-10-20 14:43:58

Cmaj, I know that you have been working on this for a long time.  I was hesitant to add it until it was tested, but going back in the comments it looks like you have had some success with this.  Would you like to have this feature merged in?  If so, you'll need to make sure the patch merges cleanly and functions with trunk libpri (svn co http://svn.digium.com/svn/libpri/trunk), then give me an `svn diff` for the diff.  I will start reviewing it for inclusion then.
By: Tilghman Lesher (tilghman) 2007-12-05 10:28:09.000-0600

cmaj:  ping
By: Dwayne Hubbard (dhubbard) 2008-05-02 11:39:09

I merged chan_zap_service.diff12.txt and libpri_service.diff9.txt into the following branches, respectively:

http://svn.digium.com/svn/asterisk/team/group/issue3450
http://svn.digium.com/svn/libpri/team/dhubbard/issue3450

The patches did not apply cleanly and I made a best effort attempt at a manual merge.  Everything compiles and runs as is, but I am not able to reproduce the functionality using and TE405 with 4ESS against a Dialogic card.  I don't have a live line to test with either, so I really need some testing feedback from someone.

This issue is very old and I am willing to dedicate some time moving it forward, but I will need help so if anyone is interested in contributing feedback please do.
By: Dwayne Hubbard (dhubbard) 2008-05-12 10:15:14

I'm continuing to play with this issue when I have time.  It currently looks like "pri service disable channel 10" (or any B channel number) will take down the D channel.  This shouldn't happen and I'm not sure if this is due to my manual merge of the patch or the patch itself.  I'm continuing to investigate this...  If anyone would like to try my branches on a real line and provide valuable feedback it would be greatly appreciated.
By: Dwayne Hubbard (dhubbard) 2008-06-02 10:25:11

I'm still working on this issue but recently located a minor bug in the output of 'pri intense debug span <eep>'.  The 'ChanSel' output of the Channel ID information element is printed incorrectly.  This is an output only bug and does not affect functionality.  Once I fix the 'pri intense debug' bug I will return focus to the purpose of this issue.


By: Dwayne Hubbard (dhubbard) 2008-06-09 11:12:10

The minor bug in the output of 'pri intense debug span <eep>' has been fixed in the following revisions:

trunk - 563
1.4 - 562
1.2 - 561

I'm reviewing TR41459 and will have some code commits to the related development branches soon.
By: Dwayne Hubbard (dhubbard) 2008-06-13 11:40:55

revision 571 of https://origsvn.digium.com/svn/libpri/team/dhubbard/issue3450 should now send caller identification information elements when changing the status on a b-chan using 'pri service disable channel <chan>'

If anyone can test this branch and provide feedback with a trace it would be greatly appreciated.

[ EDITS TO THIS COMMENT ARE BELOW ]

Please test the libpri branch above using revision 122598 of branch: https://origsvn.digium.com/svn/asterisk/team/group/issue3450


By: Dwayne Hubbard (dhubbard) 2008-06-13 17:26:28

...as of revision 122765 of http://svn.digium.com/svn/asterisk/team/group/issue3450 DAHDI is required
By: Dwayne Hubbard (dhubbard) 2008-07-17 18:30:45

This branch continues to improve.  Revision 131904 includes a fix that prevents calls from reaching a disabled b-channel.  Disabled b-channels will reject incoming calls with 'CONGESTION'.  Enabling the b-channel will result in calls successfully reaching a b-channel.

I have now verified that SERVICE and SERVICE ACK messages are sent/received as expected.  The contents of the messages looks correct, although some real world testing would be a great verification method (hint hint).

The next steps include verification that RESTART requests are correctly ACKNOWLEDGED with a reference to the channel status.  I have to review the spec for this, so my terminology may not be 100% correct.

After verification of RESTART and RESTART ACK message contents, I will be moving on to the persistence of channel state with AstDB.

[ EDIT: s/requests and correctly/requests are correctly ]


By: Dwayne Hubbard (dhubbard) 2008-07-18 21:10:45

More progress in revision 132276 - a disabled b-channel will reject SETUP messages with cause 44, "requested channel not available" according to AT&T TR41459 Section 3.13.5 Maintenance Procedures.

If anyone wants to help move this issue forward, please try testing the following branches and provide feedback.

http://svn.digium.com/svn/asterisk/team/group/issue3450
http://svn.digium.com/svn/libpri/team/dhubbard/issue3450
By: Dwayne Hubbard (dhubbard) 2008-08-07 18:14:04

Revision 136717 of the branches listed below now support persistent storage of the service state.  This means you can disable a b-channel and your b-channel will be continue to be out-of-service across Asterisk restarts and system reboots.

http://svn.digium.com/svn/asterisk/team/group/issue3450
http://svn.digium.com/svn/libpri/team/dhubbard/issue3450

The following CLI commands were stripped out of this branch because we are getting extremely close to merging into trunk and I wanted to lock down the changes to the functionality that I've actually confirmed to work in my environment.

[ EDITS - ADDED THE STRIPPED CLI COMMANDS ]

 pri service loop channel <blah>
 pri service continuity channel <blah>
 pri service shutdown channel <blah>

[ END EDIT ]

I'm still waiting for some real world feedback on this functionality, so if anyone is reading this message....PLEASE test my branches and provide feedback.


By: Dwayne Hubbard (dhubbard) 2008-08-25 10:27:30

The libpri branch has changed to the URL below.  This is ready for committing, pending some test results:

libpri - http://svn.digium.com/svn/libpri/team/dhubbard/issue3450_to_commit

The Asterisk branch has not changed and also ready for committing pending some test results:

Asterisk - http://svn.digium.com/svn/asterisk/team/group/issue3450
By: Leif Madsen (lmadsen) 2008-11-20 09:19:37.000-0600

Pinging again for some feedback on this issue...

Bueller? Bueller?

Reviewboard?
By: Dwayne Hubbard (dhubbard) 2008-11-20 10:48:39.000-0600

Probably not a bad idea, but this code is not yet ready for committing:

1.  Libpri was based off libpri/trunk, not libpri/1.4.  This should be an easy change that I can do soon.

2.  This currently has issues with NFAS and should not yet be tested in NFAS configurations.
By: Leif Madsen (lmadsen) 2008-11-20 16:08:29.000-0600

Ahhhh... the infamous libpri/1.4 is newer than libpri/trunk fiasco.

Thanks for the update!
By: Dwayne Hubbard (dhubbard) 2008-11-20 16:40:53.000-0600

I've updated the asterisk development branch (http://svn.digium.com/svn/asterisk/team/group/issue3450) with the latest revisions and also enabled automerge.

The new libpri development branch based off libpri/branches/1.4 is now available at https://origsvn.digium.com/svn/libpri/team/dhubbard/servicemessages but does NOT YET include the service message support.  I will get this in asap and post a message indicating that it is ready.  Should be available by Monday, Nov 24.
By: Leif Madsen (lmadsen) 2008-11-21 09:04:13.000-0600

Dropping status to Confirmed until Dwayne has a chance to get the SERV stuff back into his updated branches and re-marks this as Ready For Testing.
By: Dwayne Hubbard (dhubbard) 2008-11-24 16:48:18.000-0600

libpri development branch http://svn.digium.com/svn/libpri/team/dhubbard/servicemessages is ready for testing.

This branch should only be used with FAS configurations.  NFAS has known blocking issues.

The Asterisk development branch to test this with is http://svn.digium.com/svn/asterisk/team/group/issue3450

---------------------
EDIT: Removed unwanted character from Asterisk development branch URL


By: Leif Madsen (lmadsen) 2008-11-24 16:50:44.000-0600

As per Dwayne on IRC, this issue is now READY FOR TESTING!!!
By: Leif Madsen (lmadsen) 2009-01-09 07:39:50.000-0600

You know what, I'm going to suggest you put this on reviewboard, and just get it committed.
By: Digium Subversion (svnbot) 2009-04-14 10:05:23

Repository: libpri
Revision: 732

U   branches/1.4/libpri.h
U   branches/1.4/pri.c
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

------------------------------------------------------------------------
r732 | jpeeler | 2009-04-14 10:05:22 -0500 (Tue, 14 Apr 2009) | 11 lines

Add service maintenance message support

This adds support for two new message types: Service and Service Acknowledge.
When a channel receives a service message it will either take the channel in
or out of service and then send a service acknowledgment. Although not
enforced here (enforced in chan_dahdi), the service messages are only supported
with switch types 4ess/5ess. The required Asterisk changes will be coming next.

(issue ASTERISK-3375)
Reported by: cmaj

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

http://svn.digium.com/view/libpri?view=rev&revision=732
By: Digium Subversion (svnbot) 2009-04-14 10:54:18

Repository: asterisk
Revision: 188342

U   trunk/CHANGES
U   trunk/channels/chan_dahdi.c
U   trunk/configs/chan_dahdi.conf.sample
U   trunk/configure
U   trunk/configure.ac
U   trunk/include/asterisk/autoconfig.h.in

------------------------------------------------------------------------
r188342 | jpeeler | 2009-04-14 10:54:17 -0500 (Tue, 14 Apr 2009) | 33 lines

Add service maintenance message support

This is the companion commit to libpri r732. Service messages are now supported
for switch types 4ess/5ess. A new option service_message_support has been added
to chan_dahdi.conf and is noted in the sample config file. The service message
support is turned off by default. The current implementation relies on AstDB
to keep track of channel state, which allows the statuses to be preserved
across Asterisk restarts. Below is a description of the storage format.

The state and reason for the service state are in the form <state>:<reason>,
where:
<state> ::= { 'O' }  // 'O' ?\226?\128?\147 Out Of Service
<reason> ::= { '0' | '1' | '2' | '3' }, where:
'0' ?\226?\128?\147 No reason (backwards compatibility)
'1' ?\226?\128?\147 NEAR END
'2' ?\226?\128?\147 FAR END
'3' ?\226?\128?\147 both NEAR and FAR END

The new CLI commands to handle channel service state are:
pri service disable channel <chan>
pri service enable channel <chan>

Many people contributed to the development of this functionality. Because I
entered at the very end I do not know the exact history. Special thanks to
all who moved the bug forward one way or another:
cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
and did a large portion of the work)

(closes issue ASTERISK-3375)
Reported by: cmaj


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

http://svn.digium.com/view/asterisk?view=rev&revision=188342
By: Digium Subversion (svnbot) 2009-04-14 10:55:30

Repository: asterisk
Revision: 188343

_U  branches/1.6.0/

------------------------------------------------------------------------
r188343 | jpeeler | 2009-04-14 10:55:29 -0500 (Tue, 14 Apr 2009) | 38 lines

Blocked revisions 188342 via svnmerge

........
 r188342 | jpeeler | 2009-04-14 10:54:16 -0500 (Tue, 14 Apr 2009) | 33 lines
 
 Add service maintenance message support
 
 This is the companion commit to libpri r732. Service messages are now supported
 for switch types 4ess/5ess. A new option service_message_support has been added
 to chan_dahdi.conf and is noted in the sample config file. The service message
 support is turned off by default. The current implementation relies on AstDB
 to keep track of channel state, which allows the statuses to be preserved
 across Asterisk restarts. Below is a description of the storage format.
 
 The state and reason for the service state are in the form <state>:<reason>,
 where:
 <state> ::= { 'O' }  // 'O' ?\226?\128?\147 Out Of Service
 <reason> ::= { '0' | '1' | '2' | '3' }, where:
 '0' ?\226?\128?\147 No reason (backwards compatibility)
 '1' ?\226?\128?\147 NEAR END
 '2' ?\226?\128?\147 FAR END
 '3' ?\226?\128?\147 both NEAR and FAR END
 
 The new CLI commands to handle channel service state are:
 pri service disable channel <chan>
 pri service enable channel <chan>
 
 Many people contributed to the development of this functionality. Because I
 entered at the very end I do not know the exact history. Special thanks to
 all who moved the bug forward one way or another:
 cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
 tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
 and did a large portion of the work)
 
 (closes issue ASTERISK-3375)
 Reported by: cmaj
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=188343
By: Digium Subversion (svnbot) 2009-04-14 10:55:45

Repository: asterisk
Revision: 188344

_U  branches/1.6.1/

------------------------------------------------------------------------
r188344 | jpeeler | 2009-04-14 10:55:45 -0500 (Tue, 14 Apr 2009) | 38 lines

Blocked revisions 188342 via svnmerge

........
 r188342 | jpeeler | 2009-04-14 10:54:16 -0500 (Tue, 14 Apr 2009) | 33 lines
 
 Add service maintenance message support
 
 This is the companion commit to libpri r732. Service messages are now supported
 for switch types 4ess/5ess. A new option service_message_support has been added
 to chan_dahdi.conf and is noted in the sample config file. The service message
 support is turned off by default. The current implementation relies on AstDB
 to keep track of channel state, which allows the statuses to be preserved
 across Asterisk restarts. Below is a description of the storage format.
 
 The state and reason for the service state are in the form <state>:<reason>,
 where:
 <state> ::= { 'O' }  // 'O' ?\226?\128?\147 Out Of Service
 <reason> ::= { '0' | '1' | '2' | '3' }, where:
 '0' ?\226?\128?\147 No reason (backwards compatibility)
 '1' ?\226?\128?\147 NEAR END
 '2' ?\226?\128?\147 FAR END
 '3' ?\226?\128?\147 both NEAR and FAR END
 
 The new CLI commands to handle channel service state are:
 pri service disable channel <chan>
 pri service enable channel <chan>
 
 Many people contributed to the development of this functionality. Because I
 entered at the very end I do not know the exact history. Special thanks to
 all who moved the bug forward one way or another:
 cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
 tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
 and did a large portion of the work)
 
 (closes issue ASTERISK-3375)
 Reported by: cmaj
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=188344
By: Digium Subversion (svnbot) 2009-04-14 10:56:16

Repository: asterisk
Revision: 188345

_U  branches/1.6.2/

------------------------------------------------------------------------
r188345 | jpeeler | 2009-04-14 10:56:16 -0500 (Tue, 14 Apr 2009) | 38 lines

Blocked revisions 188342 via svnmerge

........
 r188342 | jpeeler | 2009-04-14 10:54:16 -0500 (Tue, 14 Apr 2009) | 33 lines
 
 Add service maintenance message support
 
 This is the companion commit to libpri r732. Service messages are now supported
 for switch types 4ess/5ess. A new option service_message_support has been added
 to chan_dahdi.conf and is noted in the sample config file. The service message
 support is turned off by default. The current implementation relies on AstDB
 to keep track of channel state, which allows the statuses to be preserved
 across Asterisk restarts. Below is a description of the storage format.
 
 The state and reason for the service state are in the form <state>:<reason>,
 where:
 <state> ::= { 'O' }  // 'O' ?\226?\128?\147 Out Of Service
 <reason> ::= { '0' | '1' | '2' | '3' }, where:
 '0' ?\226?\128?\147 No reason (backwards compatibility)
 '1' ?\226?\128?\147 NEAR END
 '2' ?\226?\128?\147 FAR END
 '3' ?\226?\128?\147 both NEAR and FAR END
 
 The new CLI commands to handle channel service state are:
 pri service disable channel <chan>
 pri service enable channel <chan>
 
 Many people contributed to the development of this functionality. Because I
 entered at the very end I do not know the exact history. Special thanks to
 all who moved the bug forward one way or another:
 cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
 tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
 and did a large portion of the work)
 
 (closes issue ASTERISK-3375)
 Reported by: cmaj
........

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

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