[asterisk-dev] libpri - q931.c assumes only T1 uses slot maps

Mon Nov 22 22:37:11 CST 2010

Richard,

Thanks your reply - it clarified things. However, now I have a bigger
problem with libpri, the following :

Normally, with most providers, I get a q931 RESTART message when I restart
my application ( here FreeSWITCH ) - this RESTART message contains the
message to reset a single DS1 facility. Things work fine here.

However, with this one provider, ,I get a q931 RESTART message containing
the following :

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < Informational frame:

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < SAPI: 00  C/R: 1 EA:
0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <  TEI: 000        EA:
1

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < N(S): 000   0: 0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < N(R): 000   P: 0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < 42 bytes of data

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < Protocol
Discriminator: Q.931 (8)  len=42

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < TEI=0 Call Ref: len=
2 (reference 0/0x0) (Sent from originator)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < Message Type:
RESTART (70)

2010-11-23 02:18:12.161997 [ERR] ftmod_libpri.c:131 len: 37 ie->ie : 24

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < [18 20 a9 83 01 02
03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 11 12 13 14 15 16 17 18 19 1a 1b 1c
1d 1e 9f]
2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < Channel ID (len=34)
[ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  ChanSel: As indicated in following octets

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 1  Coding: 0  Number Specified  Channel Type: 3

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 1 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 2 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 3 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 4 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 5 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 6 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 7 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 8 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 9 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 10 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 11 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 12 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 13 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 14 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 15 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 17 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 18 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 19 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 20 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 21 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 22 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 23 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 24 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 25 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 26 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 27 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 28 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 29 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 0  Channel: 30 Type: CPE

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 <
  Ext: 1  Channel: 31 Type: CPE]

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < [79 01 80]

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 < Restart Indentifier
(len= 3) [ Ext: 1  Spare: 0  Resetting Indicated Channel (0) ]

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 -- Making new call for
cref 0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 Received message for
call 0xddcb80 on 0xdb25b0 TEI/SAPI 0/0, call->pri is 0xdb25b0 TEI/SAPI 0/0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 -- Processing Q.931
Restart

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 XXXX Beginning IE
handling: len = 37, step = 34

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 XXX Processing IEs:
cur_codeset = 0, IE 24. Switchtype: 5

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 -- Processing IE 24
(cs0, Channel Identification)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 XXX Processing IEs:
cur_codeset = 0, IE 121. Switchtype: 5

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 -- Processing IE 121
(cs0, Restart Indicator)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 q931.c:6863
post_handle_q931_message: Call 0 enters state 62 (Restart).  Hold state:
Idle
2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 q931.c:4363
restart_ack: Call 0 enters state 0 (Null).  Hold state: Idle

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > DL-DATA request

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > Protocol
Discriminator: Q.931 (8)  len=13

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > TEI=0 Call Ref: len=
2 (reference 0/0x0) (Sent to originator)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > Message Type:
RESTART ACKNOWLEDGE (78)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 TEI=0 Transmitting
N(S)=0, window is open V(A)=0 K=7

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > TEI: 0 State
7(Multi-frame established)

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > V(A)=0, V(S)=0,
V(R)=1

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > K=7, RC=0,
l3initiated=0, reject_except=0, ack_pend=0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > T200_id=0, N200=3,
T203_id=1

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > [ 00 01 00 02 08 02
80 00 4e 18 03 a9 83 81 79 01 80 ]

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > Informational frame:

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > SAPI: 00  C/R: 0 EA:
0

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 >  TEI: 000        EA:
1

2010-11-23 02:18:12.161997 [DEBUG] ftmod_libpri.c:149 > N(S): 000   0: 0

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > N(R): 001   P: 0

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > 13 bytes of data

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > Protocol
Discriminator: Q.931 (8)  len=13

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > TEI=0 Call Ref: len=
2 (reference 0/0x0) (Sent to originator)

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > Message Type:
RESTART ACKNOWLEDGE (78)

2010-11-23 02:18:12.163006 [ERR] ftmod_libpri.c:131 len: 8 ie->ie : 24

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > [18 03 a9 83 81]

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 > Channel ID (len= 5)
[ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 >
  ChanSel: As indicated in following octets

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 >
  Ext: 1  Coding: 0  Number Specified  Channel Type: 3

2010-11-23 02:18:12.163006 [DEBUG] ftmod_libpri.c:149 >
  Ext: 1  Channel: 1 Type: CPE]

As can be seen above, the RESTART message contains a message with all the
channels Number Specified ( as opposed to slot map specified, I think ? ).
However, the RESTART ACKNOWLEDGE for this message only shows one channel
being restarted.

Shouldn't all the channels specified by the RESTART message be RESTARTED ?

If I'm not mistaken, this is causing the rest of my channels to not accept
calls at all, and post an application restart, only the first channel of
every span(line) takes calls - the rest just hangup and get a RELEASE
ACKNOWLEDGE.

How to fix this ?

Thanks for your help,
Abhinav

On Tue, Nov 23, 2010 at 1:56 AM, Richard Mudgett <rmudgett at digium.com>wrote:

>
>
> ----- Original Message -----
> > Hi,
> >
> >
> > As mentioned in q931.c, (line 892 onwards in 1.4.11.4) in the
> > comments, the code assumes that only T1 uses slot maps. However, I'm
> > using an E1 Line. I have a few questions regarding this :
> >
> >
> > 1. How does it assume T1 ? Does the and-ing of data[pos] with 0x10
> > imply that ?
>
> No.  That is a test to see if the following octets are a slot map.
>
> > 2. How can I expand this to E1 ?
>
> The assumption made about the slot map is the number of octets the slot map
> contains.  For T1, the slot map will contain 3 octets.  For E1, the slot map
> will contain 4 octets.  The other bit of ambiguity with E1 slot maps is in
> the treatment of time slots 0 and 16.  Are they included in the slot map or
> does the slot map only represent logical channels?  See the
> chan_mapping_logical option.
>
> Also libpri does not actually decode the slot map to figure out what
> channel is requested.  It just stores it and assumes the channel was not
> specified.  Libpri will only send a slot map if the upper layer has not
> picked a channel and a slot map was previously received.  In practice,
> libpri will not send the slot map because the upper layer would not know
> what the channel is.
>
> Richard
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101123/dbaea9e8/attachment-0001.htm 