Разберём один случай, с которым столкнулись инженеры из ТАС: пользователь пожаловался, что после того, как он перенастроил подключение к PSTN сети с PRI транка на BRI, вызываемый номер от IP телефона через U1911 проходит на PSTN без первой цифры.
Телефонный номер: 346XXXXX05
Вызываемый номер: 384XXX06
Посмотрим по собранной информации, где же закралась ошибка, для этого нам нужно собрать следующую информацию:
- вывод команды show prefix dn 3847972
- вывод команды showprefix
- файл data.bin
- входящее сообщение SETUPSS7 c BRI интефейса
- исходящий INVITESIP реквест на IP телефон
INVITE выглядел следующим образом:
INVITE sip:206@172.31.116.6:5060;user=phoneSIP/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 сигнализирует:
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
По предоставленной информации видно, что номер полный на стороне ISDN (356XXXXX05) и без первой цифры (465XXXX05) в хэдере SIP INVITE сообщения.
Посмотрим на вывод информации префикса:
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 собираем логи всех модулей и смотрим, что же в них творится интересное. А в них мы видим то, что первая цифра вызываемого номера никак не влияет на звонок, он прерывается из-за DISCONNECTION(рисунок 1, рисунок 2).
Рисунок 1. LMT + DISCONNECTION
Рисунок 2. DISCONNECTION
Нормальный сигнал должен выглядеть как указано в документации (рисунок 3).
Рисунок 3. Пример из документации(Мануала)
Все эти выделенные синим данные от 6С до 35 принадлежат номеру Calling party. Он должен содержать 4 байта протокольного заголовка, как картинке ниже, соответственно 33 будет переопределено как строка ext.1 и как таковая часть номера 33 будет занята одной цифрой.
Если сообщение SETUP содержит нормальную информацию, номер показываемый на экране будет в порядке – U1900 просто проследует согласно протоколу и обработает данные.
Когда U1900 будет обрабатывать пакет, то он будет считать их последовательно: сначала 1 часть, затем 2 и так далее.
Но так как 3а* – это опциональный байт мы не можем заставить оператора корректно изменить эту информацию в SETUP. Собственно, в этом и оказалась проблема: U1900 не смог корректно обработать информацию от оператора из-за этого опционального байта. Из-за того что данная проблема – это системная ошибка, то полного решения проблемы можно будет дождаться только в свежих релизах U1900, а до этого пользоваться косвенным вариантом решения проблемы в виде адаптации оператором информации передаваемой в SETUP сообщении.
