No subject


Thu Jul 12 09:23:04 CDT 2007


> 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")

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0007963 NFAS primary D-channel always being mak...
====================================================================== 

---------------------------------------------------------------------- 
 dwaynemh - 07-17-08 18:30  
---------------------------------------------------------------------- 
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 and 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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-17-08 18:30  dwaynemh       Note Added: 0090427                          
======================================================================




More information about the asterisk-bugs mailing list