[asterisk-bugs] [JIRA] (PRI-183) Garbage character in the received connected line number from a Lucent 5ESS switch.

[Richard Mudgett (JIRA)]

     [ https://issues.asterisk.org/jira/browse/PRI-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett closed PRI-183.
-------------------------------

    Resolution: Fixed

> Garbage character in the received connected line number from a Lucent 5ESS switch.
> ----------------------------------------------------------------------------------
>
>                 Key: PRI-183
>                 URL: https://issues.asterisk.org/jira/browse/PRI-183
>             Project: LibPRI
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>    Affects Versions: 1.5.0
>            Reporter: Richard Mudgett
>            Assignee: Richard Mudgett
>         Attachments: 0001-q931.c-Lucent-switch-implementation-bug-workaround.patch
>
>
> {noformat}
> PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 595/0x253) (Sent to originator)
> PRI Span: 1 < Message Type: CONNECT (7)
> PRI Span: 1 < [4c 0d 80 80 3x 3x 3x 3x 3x 3x 3x 3x 3x 3x 3x]
> PRI Span: 1 < Connected Number (len=15) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '€xxxxxxxxxxx' ]
> PRI Span: 1 Received message for call 0xde606f8 on link 0xa35b62c TEI/SAPI 0/0
> PRI Span: 1 -- Processing IE 76 (cs0, Connected Number)
> PRI Span: 1 q931.c:8764 post_handle_q931_message: Call 33363 enters state 8 (Connect Request).  Hold state: Idle
> {noformat}
> The Lucent 5ESS/4ESS PRI telco equipment is miscoding the Connected Number information element.  The third octet should be 0x00 and not 0x80.  The bit they are erroneously setting indicates that there is no optional octet 3a in the ie even though they are providing one.
> {noformat}
> Octet/Value/Comment
> 1/4c/Connected Number information element code
> 2/0d/Length
> 3/80/Extension-bit(1), Type-of-number(0), and numbering plan(0) fields
> 3a/80/Extension-bit(1), Presentation indicator(0), and screening indicator(0) fields
> 4/31/First digit of the number
> {noformat}
> Octet 3a can only be present if octet 3 extension bit is 0.  Since they are setting that bit there is no octet 3a and thus it is interpreted as octet 4 (The first digit in the connected number).  Voila, we get our garbage digit in the connected line number.
> Reference Q.931 Section 4.5.1 information element coding rules and Q.951 Section 5.4.1 for the connected number information element encoding.
> The attached patch works around the broken Lucent switch implementation and will display that it is doing so as shown below:
> {noformat}
> PRI Span: 1 < Protocol Discriminator: Q.931 (8)  len=20
> PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 3/0x3) (Sent to originator)
> PRI Span: 1 < Message Type: CONNECT (7)
> PRI Span: 1 < [4c 0d 80 80 31 36 31 39 36 34 36 36 31 36 36]
> PRI Span: 1 < Connected Number (len=15) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
> PRI Span: 1 <                             Switch bug workaround.
> PRI Span: 1 <                             Assuming octet 3a is present.
> PRI Span: 1 <                             Ext: 1  Presentation: Presentation allowed, User-provided, not screened (0)  '16196466166' ]
> PRI Span: 1 Received message for call 0xb3b8b988 on link 0xb430fa7c TEI/SAPI 0/0
> PRI Span: 1 -- Processing IE 76 (cs0, Connected Number)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)