[Home]

Summary:ASTERISK-02418: Including a 'w' in the dial string on a PRI trunk breaks calling number in Q.931 frame?
Reporter:kb1_kanobe2 (kb1_kanobe2)Labels:
Date Opened:2004-09-16 01:09:09Date Closed:2004-09-25 02:01:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dial-PRI-wbug.txt
Description:When a pause is included in the dial string, thus:
exten => s,3,Dial(zap/g1/w${ARG1},15)
the Calling Number is all zeros in the SETUP frame, thus:
> [6c 0c 21 81 00 00 00 00 00 00 00 00 00 00]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number passed network screening (1) '' ]

This occurs for all values of CallingPres(), also with usecallingpres=no, hidecallerid=yes/no and for switchtype=national or switchtype=dms100. Other combinations not tested.

Output of 'pri debug span 1' under both conditions attached.

This may have non-trivial implications for users doing an in-place upgrade from cT1 to PRI with an established working dialplan.

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

Problem environment is Asterisk 'CVS-HEAD-09/12/04' running against a Nortel Norstar MICS 4.1 w/PRI enabled.

All calls out from NS to Ast were working fine but 100% of calls from Ast to NS were failing with congestion/circuit-busy from chan_zap. Specifically, the call was being rejected with:

...
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
<                  Ext: 1  Cause: Invalid information element contents (100), class = Protocol Error (6) ]
...

It appears the Norstar considers an all-zeros CallerID number invalid and thus is rejecting the call.
Comments:By: Brian West (bkw918) 2004-09-16 08:07:56

Not a major bug
By: Mark Spencer (markster) 2004-09-16 08:57:06

That's not a bug, you can't send "w" as part of the number, so Asterisk breaks the number where you put the "w" and sends the part before the "w", then outpulses the remaining portion after the line has been answered by the other side.
By: kb1_kanobe2 (kb1_kanobe2) 2004-09-16 15:52:31

Ok, I'll admit it's not a Major bug for everyone - just a Major source of work for me, so better described as minor from a world view.

Given that I had obviously had developed square eyes by that point and didn't notice the called number was dissapearing then that was probably the source of indigestion to the Norstar. I will try to produce a trivial/feature patch to add debug verbiage to the 'outpulse after connect on wait on pri dial' condition.

However, the question remains; Why does the Calling Number go from a valid ten digit string to ten nulls? Should not the Calling Number be provided in both cases demonstrated, regardless of the Called Number? Likewise, I assume Q.931 doesn't expect nulls in that element...

> [6c 0c 21 81 31 32 33 34 35 36 31 32 33 34]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number passed network screening (1) '1234561234' ]
> [70 05 c1 36 31 30 31]
> Called Number (len= 7) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '6101' ]


> [6c 0c 21 81 00 00 00 00 00 00 00 00 00 00]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number passed network screening (1) '' ]
> [70 01 c1]
> Called Number (len= 3) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '' ]
By: Mark Spencer (markster) 2004-09-16 16:34:41

Actually, there *was* a bug in sending of the *calling* number in which it would copy the field only if the *called* number was non-zero, so you're probably the only person who would ever have seen it, but it is now fixed, so you won't have the 0's...