Q.931 Called Party Number interpreted as empty

Home » Asterisk Users » Q.931 Called Party Number interpreted as empty
Asterisk Users 6 Comments

Il 02/11/2011 15.06, Philippe Sultan ha scritto:
> PRI Span: 1 < [70 13 a1 00 34 34 39 39 30 30 32 30 33 36 31 35 38 39 34
> 32 35]

Yes, like you guessed the third bit (wich is part of the called number
i.e.) is a NUL… but Q.931 allows any IA5 (ISO 646) character so it’s a
bug in libpri not in your telco side.

70|01110000 I-Element: Called party number
13|00010011 Length = 19
a1|0——- Extension Bit = with extension
|-001—- Type of number: international number
|—-0001 Numbering Plan: ISDN/telephony
00|0——- Spare
|-0000000 Number digits: NUL
34|0——- Spare
|-0110100 Number digits: 4
34|0——- Spare
|-0110100 Number digits: 4
39|0——- Spare
|-0111001 Number digits: 9
39|0——- Spare
|-0111001 Number digits: 9
30|0——- Spare
|-0110000 Number digits: 0
[…]

> a hack to solve that issue.

Why not an ‘s’ in your incoming context to workaround the issue?

6 thoughts on - Q.931 Called Party Number interpreted as empty

  • 2011/11/2 giovanni.v

    PRI Span: 1 < [70 13 a1 00 34 34 39 39 30 30 32 30 33 36 31 35 38 39 34 32
    35]

    1. As the above line comes from libpri, how can one be certain the telco
    side didn’t send the weird NUL byte ?
    (I don’t imply I disagree : I’m only curious to know how you can conclude).

    2. Anyway, as Q.931 allows any IA5 (ISO 646) character, libpri should
    notify sysadmin for every non-IA5 character received.

  • No, obviously you missed none… but I prefer to route an incoming call
    to a generic destination instead of missing it. 😉

    Thanks, please post a pointer to the issue after that done.

  • On 02/11/2011 18.45, Olivier wroteo:

    Assuming libpri debug doesn’t mess nothing is quite sure the NUL come in
    from the telco.

    But NUL is an IA5 character, so I think must be handled like any other one.
    http://skew.org/iso-ir-001/

  • 2011/11/2 giovanni.v

    So, would you still rate this as a libpri bug or a Telco issue ?
    I would say “if this is confirmed to come from the Telco network, then this
    is a Telco issue”.

    Then, how should such a “valid but unuseful” character, if I may rate it as
    such, be handed, then ?
    To me:
    A. we should not expect any called number to include any character but
    those in the 0 to 9 range.
    B. we should notify sysadmin anytime an “unuseful” character is received
    (to let him, for instance, ask telco do whatever is needed for this to
    stop).

  • Oliver, I partially agree with you but especially when standards are
    involved need to play more like devil’s advocate.

    About A:
    1 – Q.931 is not only isdn (gsm, ss7…), usually a specification are
    built to plug-in and play together with other specifications. If a
    standard says to accept IA-5 that must be done, else we may break
    something else.
    2 – Maybe the telco switch violate some other specification about the
    called number format but:
    2a) because of 1) discarding the whole data isn’t the right solution.
    2b) I don’t know if a country specific rule allow for that format.

    So totally agree in B from you and the solution suggested by Mudgett:
    discard chars that we can’t handle log the event so the admin will be
    able to do further investigations.

    p.s.: sorry for my /Spaghetti-English-language/.