Issue description
A customer reported an issue when after he changed his PSTN life from PRI to BRI trunk, the PSTN calling number was then presented by the U1911 to the IP phone without the first digit. No calling number change was configured on the intra-office prefix.
Calling number: 346XXXXX05
Called number: 384XXX06
Handling Process
In order to further troubleshoot the issue reported we requested the following information from the customer:
1. show prefix dn 3847972;
2. show prefix output command
3. data.bin file;
4. incomong SETUP SS7 message on the BRI interface;
5. outgoing INVITE SIP request message sent to the IP phone (extension under the U1900).
INVITE request message sent:
INVITE sip:206@172.31.116.6:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.31.216.10:5060;branch=z9hG4bKrqq4xxmxnnmpmuopm409mpanx
Call-ID: pa4qs043onur10r4asrmabxumqxx9n1q@172.31.216.10
From: <sip:465XXXX05@172.31.216.10;user=phone>;tag=4ss94m9a
To: <sip:206@172.31.116.6>
CSeq: 1 INVITE
Contact: <sip:465XXXX05@172.31.216.10:5060;user=phone>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,REFER,PUBLISH
Max-Forwards: 70
Content-Length: 674
Content-Type: application/sdp
ISDN signaling:
Lay 3
00001000 Protocol Discriminator: 0x8
----0001 Length of call reference value: 0x1
-0000001 Call reference value: 0x1
0------- Call reference flag: 0x0
-0000101 Message Type: SETUP
IE(s)
Bearer capability
Channel identification
Calling party number
00001011 Content Length: 11
----0000 Numbering plan identification: Unknown
-000---- Type of number: Unknown
Number digits: 346XXXXX05
Called party number
00001010 Content Length: 10
----0000 Numbering plan identification: Unknown
-000---- Type of number: Unknown
Number digits: 384XXXX06
10100001 Sending complete
Unknow IE
00000010 Content Length: 2
From the information provided, the number is complete on the ISDN side (356XXXXX05) and without the first digit (465XXXX05) in the 'From' header of the INVITE message.
Prefix
SubPBXNo Prefix CallCategory CallAttribute CustomAttribute ChargeIndex SelectOfficeCode
-------- ------- ------------ ------------- --------------- ----------- ----------------
0 3847972 basic inter null --- ---
MinLen MaxLen UseLongCLI If4PSTN WaitNextNumTimerLen PwdCallLimit CallerNumAuth
------ ------ ---------- ------- ------------------- ------------ -------------
0 10 NO YES 2000 (ms) NO No
InterOnlyCallSource VoIPFailReroute reroutecallattr reroutecus rerouteselectcode
------------------- --------------- --------------- ---------- -----------------
--- NO --- --- ---
CLDPredeal Information
CLDPredeal CLDIndex ChangeType ChangePos ChangeLen NewDn
---------- -------- ---------- --------- --------- -----
YES 2 DELETE 0 6 -
typeofusercldnumber typeofuserclinumber ischangingtrunkcldnumbertype typeoftrunkcldnumber
------------------- ------------------- ---------------------------- --------------------
--- --- YES ---
ischangingtrunkclinumbertype typeoftrunkclinumber
---------------------------- --------------------
NO
---
LMT in order to capture all modules log while issue is being reproduced.
After we have analzyed the signaling files gathered, we noticed that the first digit of the calling number does not affect the call, the call fails due to DISCONNECTION.
The normal signaling flow should look like this:
All these blue data from 6C to 35 belong to the Calling Party number. It must contain 4 bytes for the protocol header as per the following pictures, so the 33 will be redefined as the line of ext.1 and so the number part 33 will be occupied by one digit.
If the SETUP message contains normal information, the number displayed on screen will be in order. The U1900 will just follow the protocol and as such parse the data:
When the U1900 reads the data (package), it will read it in the order below (part 1, then part 2 and parse it one by one):
But since 3a* is an optional octet we cannot force the carrier to parse this information into the SETUP message.
Root cause
The root cause of this issue is because the U1900 reads the information from the SETUP message incorrectly, since an optional parameter is present - sent by the carrier.
Solution
Since this is a bug, this feature will be available in the new release for the U1900, but as a workaround. We advised that the carrier adapts the information sent in the SETUP message. Issue is related to the lack of the third octet.
