| Summary: | ASTERISK-14974: Lenth of called number send in enblock | ||
| Reporter: | Maciej Krajewski (jamicque) | Labels: | |
| Date Opened: | 2009-10-12 04:36:26 | Date Closed: | 2011-07-27 09:19:30 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_dahdi |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) full.log | |
| Description: | According to recommendation ETSI ETS 300 102-1 in chapter 4.5.8 there is a statement that there are 23 octets for called number, where octets from 4-23 are for send digits. According to that numbers longer than 19 should by send in overlapped mode. Now asterisk sends whole number in one en-block what is wrong, and in result the other side equipment can reject the ISDN frame or take only digits from 4 to 23 octet in a frame. In attachment there is a log where asterisk sends number 123412341234123412341234 in one enblock | ||
| Comments: | By: Birger "WIMPy" Harzenetter (wimpy) 2010-12-20 22:11:40.000-0600 Allegedly some equipment can only chew even smaller chunks. That's why LCR has a configuration parameter for the max number of digits sent per message. Might be a good idea for chan_dahdi / libpri as well. Just found ion Q.931: "The maximum length of this information element is network dependent." By: Russell Bryant (russell) 2011-07-27 09:19:24.956-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks! | ||