某地ETC失败问题 分析说明

第1章             问题原因

1.1   问题描述

2011-07-01日发现某地ETC失败。经抓取trace发现，scp发向某地软交换的correlationid,某地软交换发向IP的correlationid不一致。

 

某地	8166699390	a50617	050617	失败
		a83926	083926	失败
		a16546	016546	失败
		bf7994	bA7994	失败
		a05371	005371	失败
		a47038	047038	失败
		a67477	067477	失败
		a16994	016994	失败
		ab6155	0b6155	失败
		a75016	075016	失败

 

我们发现某地软交换把a转成了0,将f转成了a。

 

测试中的AA软交换、BB软交换透传correlationid,它们的ETC都是成功的。

AA	2886747464	a96477	A96477	正常
		a16273	A16273	正常
		a01417	A01417	正常
		a60180	A60180	正常
		a30187	A30187	正常
		bb2433	Bb2433	正常
		bf6683	bF6683	正常
		b56644	B56644	正常
		bf3320	bF3320	正常
		b86160	B86160	正常

 

BB	8382310240	a70774	A70774	成功
		a70156	A70156	成功
		be1965	bE1965	成功
		b73639	B73639	成功

 

1.2   问题分析

对于SCP，SSP，IP交互过程 ITU-T Q.1218对其描述如下：

Q.1218 第16(4)页：

  

可以看出ssp需要支持传输correlationinformation

 

Q.1218 3.1.2.5.1 第146(134)页 开始详细介绍了 SRF connect procedures过程

3.1.3.5.1 SRF connect procedures

3.1.3.5.1.1 SRF connect physical procedures

Several procedures are required for different physical scenarios. The cases to be covered are described below and

illustrated in Figure 26:

i) the IP is integrated into the SSP, or directly attached to the SSP, that is interacting with the SCP but

the SCP’s operations to the IP are relayed via the SSP which performs any needed protocol conversion;

ii) the IP is directly attached to the SSP that is interacting with the SCP but the SCP’s operations to the IP

are sent directly to the IP without SSP relaying involved;

iii) the IP is integrated into another SSP, or directly attached to another SSP, than the one that is interacting

with the SCP but the SCP’s operations to the IP are relayed via the second SSP (called the “Assist”

method), and on completion of the user interaction, control is returned to the first SSP;

iv) the IP is directly attached to a node other than the SSP that is interacting with the SCP but the SCP’s

operations to the IP are sent directly to the IP without SSP relaying involved (called the “Assist” method,

but with a variation on the physical connectivity of the entities involved), and on completion of the user

interaction, control is returned to the first SSP; and

v) the IP is attached to another SSP and on completion of the user interaction, control of the call is retained

at that SSP (called the “Handoff” approach).

In each of the above cases, the operations between the SCP and the SSP may be SS No. 7 TCAP-based; the messaging

between the SSP and the IP when the SSP does relaying may be DSS 1 using the facility IE (in this case, the SSP would

have to do protocol conversion from SS No. 7 TCAP to DSS-1 facility IE for the operations and responses it relayed

between the SCP and the IP); the direct messaging between the SCP and the IP may be SS No. 7 TCAP based; and

bearer control signalling may be any system.

Each of the scenarios will now be examined using arrow diagrams.

Case i) is illustrated in Figure 27. Note that for the integrated IP/SSP, the internal activities of the node can still be

modelled in this way, but the details of how this is achieved are left to the implementor. This approach makes it

unnecessary for the SCP to distinguish between integrated and external but directly connected IPs. See also a note on the

possibility of concatenating the first user interaction operation with the ConnectToResource operation discussed in the

subclause on user interaction below. The establishment of the SCF-SRF relationship in this case is implicit.

Case ii) requires that the IP indicate to the SCP that it is ready to receive operations (see Figure 28). The establishment

of the SCF-SRF relationship is explicit. Note that it is necessary to convey a correlation ID to ensure that the transaction

established between the SCP and the IP can be correlated to the bearer connection set-up as a result of the SCP’s

preceding operation to the SSP.

Case iii) requires that a transaction be opened with the assisting SSP so that it may relay operations from the SCP to

the IP (integrated or external). Once the bearer control signalling has reached the assisting SSP, it triggers on the identity

of the called facility, and initiates an interaction with the SCP that has requested the assistance. It would also be possible

to trigger on other IEs such as the incoming address. The bearer control signalling must contain information to identify

the SCP requesting the assistance, and a correlation ID. This information may be hidden in the address information in

such a way that non-message based signalling systems may also be used to establish the bearer connection to the

assisting SSP. After the AssistRequestInstructions are received by the SCP, the procedures are the same as in case i).

Figure 29 illustrates the preamble involved.

Case iv) does not require the establishment of a second transaction from the assisting exchange, hence it need not be

an SSP. This then becomes a preamble to the procedure shown in Figure 28 as shown in Figure 30.

Case v) merely requires the sending of an operation to the first SSP to route the call to the handed-off SSP, and then

Figure 27 applies at handed-off SSP. This is shown in Figure 31. Note that the activity at handed-off SSP represents a

new interaction with the SCP and “AssistRequestInstructions” is used. Once the bearer control signalling has reached the

assisting SSP, it triggers on the identity of the called facility, and initiates an interaction with the SCP that has requested

the assistance. It would also be possible to trigger on other IEs such as the incoming address. The bearer control

signalling must contain information to identify the SCP requesting the assistance, and a correlation ID. This information

may be hidden in the address information in such a way that non-message based signalling systems may also be used to

establish the bearer connection to the assisting SSP.

 

彩铃的处理应该是case iii ,其中我们可以看到需要ssp对correlation进行透传，这样ip scp ssp 三者可以连接起来。

  

ITU-T Q.763   对correlation id的解释

 

Q.1218 58(46)页

 

CorrelationID ::= Digits

-- used by SCF forcorrelation with a previous operation. Refer to clause 3 for a description ofthe

-- procedures associated with this parameter.

 

-- The following parameters should use Generic Number:

-- CorrelationID for AssistRequestInstructions, AssistingSSPIPRoutingAddress for

-- EstablishTemporaryConnection, calledAddressValue for all occurrences, callingAddressValue for all

-- occurrences. The following parameters should use Generic Digits: prefix, all

-- other CorrelationID occurrences, dialledNumber filtering criteria, callingLineID filtering criteria, lineID

-- for ResourceID type, digitResponse for ReceivedInformationArg.

 

 可以看出在ETC中，correlationid编码规则是Generic digis.

Q.763对Generic Digits的解释为：

 

 

从下面的trace：

[23:26:05] FSM 925, 75 bytes, Received fromSS7 ( TC-Begin ):

0    00 0B 01 29 B9 4F 0D 81  0C 05 4386 03 16 0C 00   ...).O....C.....

16   FF 08 03 A3 7D 01 01 01  00 00 23FF 00 05 43 29   ..........#...C)

32   14 16 0C 38 A0 29 B9 4F  0D FF 0140 86 07 00 13   ...8.).O...@....

48   38 24 91 40 56 87 0A 81  10 1B 0081 27 58 01 69   8$.@V.......'X.i

64   03 88 0A 83 10 80 52 81  27 FF00                  ......R.'..

 

TC-Begin.Ind:

 QualityOfService = { ReturnOption:81, SequenceControl:0C }

 DestinationAddress

   PC = 8782614

   SSN = 12

 ApplicationContextName = 03 A3 7D 01 01 01 00 00

 OriginatingAddress

   PC = 2692118

   SSN = 12

 DialogueID = 700010253

 ComponentsPresent = Present

 

[23:26:05] FSM 925, 86 bytes, Received fromSS7 ( TC-Invoke ):

0    00 0B 10 29 B9 4F 0D 29  B9 4F 0DFF 01 FF 00 00   ...).O.).O......

16   FF FF 03 A3 7D 00 3F 30  3D 80 0200 EF 82 07 01   ......?0=.......

32    10 3B 21 24 43 10 83 08  83 10 20 88 71 01 90 09   .;!$C..... .q...

48    85 01 0A 87 01 00 88 02  01 3E 89 01 01 AB 03 80   .........>......

64    01 00 8C 07 03 00 18 66  96 39 09 9C 01 0C 9D 06   .......f.9......

80   81 10 66 99 93 00                                  ..f...

 

[23:26:05] FSM 925, Received TC-Invoke Ind( 0 )

TC-Invoke.Ind:

 DialogueID = 700010253

 InvokeID = 01

 OperationID = 0

 LastComponent = Last

MsgID[ 0]

+---c[   30]

   +---p[    80]       2      00 EF

    +---p[   82]       7       01 10 3B 21 24 43 10

    +---p[   83]       8       83 10 20 88 71 01 90 09

    +---p[   85]       1       0A

    +---p[   87]       1       00

    +---p[   88]       2       01 3E

    +---p[   89]       1       01

    +---c[   AB]

    |   \---p[   80]       1       00

   +---p[    8C]       7      03 00 18 66 96 39 09

   +---p[    9C]       1      0C

   \---p[    9D]       6      81 10 66 99 93 00

 

###START:start(925-700010253,tcInvoke_0)...ret(1,0),next[ ]Check_NumFormat

###Check_NumFormat:Branch(925-700010253,NULL)...ret(3,0),next[ ]beijiao

###beijiao:Algorithm(925-700010253,NULL)...ret(1,0),next[ ]chaxun

###chaxun:ExecSQL(925-700010253,NULL)...[23:26:05]FSM 925, DB[sdp@sc5_sdp2], ecSelect:

select newnumber , usertype , calltimes ,calldate from change_nbr_user where oldnumber = '081666993

90' and endTime >= '20110701232605'

 

[23:26:05] FSM 925, Select Result:rowNum=1, fieldNum=4

 newnumber   usertype  calltimes  calldate

  (CHAR20)   (CHAR23)   (CHAR23)   (CHAR8)

15378238840          1         73  20110701

 

 

ret(1,0), next[ ]Edprequest1

###Edprequest1:Xmlsib(925-700010253,NULL)...[23:26:05]FSM 925, Send TC-Invoke Req( 23 )

TC-Invoke.Req:

 DialogueID = 700010253

 OperationType=2

 InvokeID = 81

 OperationID = 23

 Timeout = 100

RequestReportBCSMEvent-os:

\---RequestReportBCSMEventArg

   \---bcsmEvents

       +---eventTypeBCSM       1   09

       +---monitorMode         1   01

       \---legID

           \---sendingSideID       1   01

       +---eventTypeBCSM       1   0A

       \---monitorMode         1   01

 

[23:26:05] FSM 925, 48 bytes, Send to SS7 (TC-Invoke ):

0    00 01 10 29 B9 4F 0D 29  B9 4F 0D02 81 FF 00 17   ...).O.).O......

16   FF 00 00 00 64 00 19 30  17 A0 1530 0B 80 01 09   ....d..0...0....

32   81 01 01 A2 03 80 01 01  30 06 8001 0A 81 01 01   ........0.......

 

ret(1,0), next[ ]PA_Sound

###PA_Sound:Algorithm(925-700010253,2)...ret(1,0),next[ ]SspnameBan1

###SspnameBan1:Branch(925-700010253,NULL)...ret(10,0),next[ ]To_ETC

###To_ETC:UI(925-700010253,NULL)...[23:26:05]FSM 925, Send TC-Invoke.Req( EstablishTemporaryConnect

ion )

 

TC-Invoke.Req:

  DialogueID = 700010253

  OperationType=2

 InvokeID = 82

 OperationID = 17

 Timeout = 100

assistingSSPIPRoutingAddress="419711"

correlationID="ab0925"

NOT PRESENT

scfID=NOT PRESENT

serviceInteractionIndicators=NOT PRESENT

 

[23:26:05] FSM 925, 39 bytes, Send to SS7 (TC-Invoke ):

0    00 01 10 29 B9 4F 0D 29  B9 4F 0D02 82 FF 00 11   ...).O.).O......

16    FF 00 00 00 64 00 10 30  0E 80 06 01 02 10 14 79   ....d..0.......y

32    11 81 04 00 BA 9052                              ......R

 

TC-Continue1.Req:

  QualityOfService = {ReturnOption:81, SequenceControl:0C }

 OriginatingAddress

   PC = 8456214

    SSN = 240

  ApplicationContextName = 03 A3 7D 01 01 01 0000

  DialogueID = 700010253

                  

我们SCP在实际下发ETC时，correlationid是符合Q.763标准的。

第2章             解决说明

 

解决现网问题有如下方案：

请某地交换透传correlationid，不要讲a转成0,将f转成a。