[asterisk-bugs] [JIRA] (ASTERISK-27342) ARI: Error building JSON for PRI calls with Calling Party Subaddress Type NSAP

[Marin Odrljin (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239362#comment-239362 ] 

Marin Odrljin commented on ASTERISK-27342:
------------------------------------------

And I don't need to store this extra octet somewhere? What will happen if this subaddress IE has to be forwarded to a new call (I'm not so famliliar with libpri so I'm just guessing)? Without this octet data it is not the same anymore and in q931.c:transmit_subaddr_helper() it won't included.

> ARI: Error building JSON for PRI calls with Calling Party Subaddress Type NSAP
> ------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27342
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27342
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_stasis
>    Affects Versions: 13.11.2
>         Environment: Debian 8
>            Reporter: Marin Odrljin
>         Attachments: debug_log_subaddr-nok.txt
>
>
> There is a problem with starting Stasis application for incoming calls via PRI interface when there is Subaddress IE in Q.931 SETUP message.
> I'm not sure if the problem is in libpri, dahdi or asterisk source.
> I have attached a debug log 'debug_log_subaddr-nok.txt'.
> Please, check rows 19 and 20 where is 'Calling Party Subaddress'. If you check Q.931 specification [Q.931|https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.931-199805-I!!PDF-E&type=items] page 71-72 (4.5.11), you'll see how octet 4 should be decoded. Spec says if type of subaddress (octet 3) is NSAP ITU-T X.213 and ISO/IEC 8348, address shall be formatted as specified by octet 4 which contains Authority and Format Identifier (AFI). When you check octet 3 from my debug log [6d 0c 01 83 30 37 38 36 31 34 34 33 34 31] it is 01 what means it is NSAP type so octet 4 must be skipped in address information (or better to say treated differently), but unfortunately this is not a case in provided example. You can see that byte 83 is taken into subaddress information and result is decoded address 'ƒ0786144341'. I believe this is the root of errors that are happening later in code when building JSON in stasis_channels.c, json.c, res_stasis.c and other classes. The error message is quite logical 'Error building JSON from {s: ...} Invalid UTF-8 string'. Since JSON can't be created and it is needed for Stasis application, call never goes there (row 60-64 from debug log: 'res_stasis.c:159 stasis_start_to_json: Failed to pack JSON for StasisStart message') and it is disconnected after. 
> The same problem probably exists with SETUP IE 'Called Party Subaddress' (Q.931 spec 4.5.9, page 68-69) and also in CONNECT IE 'Connected Subaddress'.
> I have checked class [q931.c|https://github.com/asterisk/libpri/blob/master/q931.c] in libpri and saw that in the function 'receive_subaddr_helper' which is called by 'receive_calling_party_subaddr' and 2 others, all bytes from octet 4 are always copied into q931_subbaddres->data. It would be easy to skip octet 4 if type is NSAP, but I'm not sure that this is correct place to make changes because this one byte is then lost in structure and in the case of transmitting to other channel it will bring problems. Maybe this can be prevented if we add new field  'char afi' into 'q931_party_subaddress' struct and when type is NSAP to remove first byte from 'data' into it.
> If this is not the solution, then this byte must be removed when data is copied into asterisk objects when building json for Stasis, but I have no idea where is this and that's why not sure where the correction should be done, in libpri or somehere in asterisk.



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