楼主

STD28/Q.931协议中的一个疑问 STD28/Q.931协议中，当做主叫时，CC Connect不管被叫如何都会发送，因此，主叫流程中无法得到任何被叫有回应或摘机的消息。我不知道这两个协议设计之初的本意是怎样的，为何要如此设计？

	第2楼

在Q.931协议中，Connect代表 'This message is sent by the called user to the network and by the network to the calling user, to indicate call acceptance by the called user.  ' 因此被叫不回应或摘机是无法得到Connect消息的.   在RCRSTD28协议中，Connect代表 'This message is sent from the destination PS to CS, or from the CS to the origination PS, to report the This message is transmitted from CS to the destination PS to report that the call was provided. Also, for fact that the destination PS received a call.'因此被叫不回应或摘机也是无法得到Connect消息的.

----------------------------------------------

	第3楼

在朗讯网络中，如果被叫不摘机则主叫侧亦无CC Connect，下面流程为被叫振铃未摘机的主叫流程，请参阅。其中多了一项CC Prog，不知是何意？ --- Date/Time[03.06.08/10:53:18] (0)[CS-ID:80C20103300] / [PS-ID:2580070] ||       0.00000||0 CS<-PS Link cha. request:SCCH[0102010C00][ 80]dBuV ||     187.50250||0 CS->PS Link cha. assig. :SCCH[0106033700][ 55]dBuV Relative Slot[4]/Carrier No.[55]/Contr.Slot.No.[1]/Commu.Slot.No[4] ||     236.87625||0 CS<-PS TCH syn. burst   :Sync[0000000000][ 78]dBuV ||     244.37667||0 CS->PS TCH syn. burst   :Sync[0000000000][ 78]dBuV ||     246.88292||0 --<< Sync off ||     261.68792||0 -<- Idle TCH [8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF] ||     264.18917||0 -->> Sync off ||     264.18917||0 ->- Idle TCH [80000000000000000000000000000000000000000000] ||     286.68708||0 :<F10:U(3F) SABM [P=1] [] ||     291.68708||0 :<S10:U(3F) SABM [P=1] [] ||     294.18917||0 :>F10:U(73) UA   [F=1] [] ||     304.18958||0 :>S10:U(73) UA   [F=1] [] ||     326.68667||0 <<F10:I(00) I    [N(R)=0 P=0 N(S)=0] [450101050403808CA46C0C008035373832] ||     331.68708||0 :<F10:I(12) I    [N(R)=0 P=1 N(S)=1] [35383030373070088032373930303031] ||     331.68708||0 <[45010105] <CC SETUP  CC [Bearer Capability:0403808CA4]  CC [Calling Party number:6C0C008035373832353830303730]  CC [Called  Party number:70088032373930303031] ||     349.18917||0 :>F10:S(51) RR   [N(R)=2 F=1] [] ||     399.18958||0 :>F11:I(50) I    [N(R)=2 P=1 N(S)=0] [45018102] ||     399.18958||0 >[45018102] >CC CALL PROC ||     411.68708||0 :<F11:S(31) RR   [N(R)=1 F=1] [] ||     416.68708||0 :<F10:I(34) I    [N(R)=1 P=1 N(S)=2] [430181] ||     416.68708||0 <[4301]     <RT DIRq  RT [Definition Info.Req.:81] ||     429.18917||0 :>F10:S(71) RR   [N(R)=3 F=1] [] ||     444.18958||0 :>F11:I(72) I    [N(R)=3 P=1 N(S)=1] [430201423C39422C6005] ||     444.18958||0 >[4302]     >RT DIRs  RT [Area Info.:01423C39422C6005] ||     456.68708||0 :<F11:S(51) RR   [N(R)=2 F=1] [] ||     461.68667||0 :<F10:I(56) I    [N(R)=2 P=1 N(S)=3] [43040910001517C0] ||     461.68667||0 <[4304]     <RT FRq  RT [Encryption:091000]  RT [TCH Reassign:1517]  RT [Zone Info.Indicat.Func.:C0] ||     474.18917||0 :>F10:S(91) RR   [N(R)=4 F=1] [] ||     529.18917||0 :>F11:I(94) I    [N(R)=4 P=1 N(S)=2] [43050910001517C0] ||     529.18917||0 >[4305]     >RT FRs  RT [Encryption:091000]  RT [TCH Reassign:1517]  RT [Zone Info.Indicat.Func.:C0] ||     536.68667||0 :<F11:S(71) RR   [N(R)=3 F=1] [] ||     546.68667||0 :<F10:I(78) I    [N(R)=3 P=1 N(S)=4] [43030D02810F] ||     546.68667||0 <[4303]     <RT EKS  RT [Encryption Key Set:0D02810F] ||     559.18917||0 :>F10:S(B1) RR   [N(R)=5 F=1] [] ||     904.18958||0 :>F11:I(B6) I    [N(R)=5 P=1 N(S)=3] [44010601070871F015ADA2172A80] ||     904.18958||0 >[4401]     >MM ARq  MM [Authentication Type:0601]  MM [Authentication Random Pattern:070871F015ADA2172A80] ||     916.68708||0 :<F11:S(91) RR   [N(R)=4 F=1] [] ||     931.68708||0 :<F10:I(9A) I    [N(R)=4 P=1 N(S)=5] [44020508901D42D5DEC7220F] ||     931.68708||0 <[4402]     <MM ARs  MM [Active Chipherring Pattern:0508901D42D5DEC7220F] ||     944.18958||0 :>F10:S(D1) RR   [N(R)=6 F=1] [] ||     959.18958||0 :>F11:U(53) DISC [P=1] [] ||     966.68708||0 :<F11:U(73) UA   [F=1] [] ||    1844.18917||0 >>S11:I(00) I    [N(R)=0 P=0 N(S)=0] [4501] ||    1854.18917||0 >>S11:I(02) I    [N(R)=0 P=0 N(S)=1] [8103] ||    1864.18917||0 >>S11:I(04) I    [N(R)=0 P=0 N(S)=2] [1E02] ||    1874.18875||0 :>S11:I(16) I    [N(R)=0 P=1 N(S)=3] [8281] ||    1874.18875||0 >[45018103] >CC PROG  CC [Progress Indicator:1E028281] ||    1886.68667||0 :<S11:S(91) RR   [N(R)=4 F=1] [] ||    8639.18792||0 >>S11:I(08) I    [N(R)=0 P=0 N(S)=4] [4501] ||    8649.18792||0 >>S11:I(0A) I    [N(R)=0 P=0 N(S)=5] [8145] ||    8659.18792||0 >>S11:I(0C) I    [N(R)=0 P=0 N(S)=6] [0802] ||    8669.18792||0 >>S11:I(0E) I    [N(R)=0 P=0 N(S)=7] [829F] ||    8679.18750||0 >>S11:I(00) I    [N(R)=0 P=0 N(S)=0] [1E02] ||    8689.18792||0 :>S11:I(12) I    [N(R)=0 P=1 N(S)=1] [8288] ||    8689.18792||0 >[45018145] >CC DISC  CC [Cause:0802829F]  CC [Progress Indicator:1E028288] ||    8701.68542||0 :<S11:S(51) RR   [N(R)=2 F=1] [] ||   10211.68500||0 :<S10:S(51) RR   [N(R)=2 P=1] [] ||   10224.18750||0 :>S10:S(11) RR   [N(R)=0 F=1] [] ||   18724.18542||0 :>S11:S(11) RR   [N(R)=0 P=1] [] ||   18736.68292||0 :<S11:S(51) RR   [N(R)=2 F=1] [] ||   18749.18542||0 >>S11:I(04) I    [N(R)=0 P=0 N(S)=2] [4501] ||   18759.18542||0 :>S11:I(16) I    [N(R)=0 P=1 N(S)=3] [814D] ||   18759.18542||0 >[4501814D] >CC REL ||   18771.68292||0 :<S11:S(91) RR   [N(R)=4 F=1] [] ||   18781.68292||0 <<S10:I(80) I    [N(R)=4 P=0 N(S)=0] [4501] ||   18791.68292||0 :<S10:I(92) I    [N(R)=4 P=1 N(S)=1] [015A] ||   18791.68292||0 <[4501015A] <CC REL COMP ||   18814.18542||0 :>S10:S(51) RR   [N(R)=2 F=1] [] ||   18836.68292||0 :<S10:U(53) DISC [P=1] [] ||   18854.18542||0 :>S10:U(73) UA   [F=1] [] ||   18864.18542||0 :>F11:U(03) UI   [P=0] [432206800880C2010330000E25800700] ||   18864.18542||0 >[4322]     >RT RDi  RT [Cause:0680]  RT [CS Ident.:0880C201033000]  RT [PS Ident.:0E25800700] ||   18876.68292||0 :<F10:U(03) UI   [P=0] [43230880C2010330000E25800700] ||   18876.68292||0 <[4323]     <RT RDiC  RT [CS Ident.:0880C201033000]  RT [PS Ident.:0E25800700] ||   18994.37792||0 ->>< TX off --[Wait for a Link Channel Request]--  [CrNo:28]

	第4楼

这是个好问题。实际上，CC是按照Q.931设计的。因此，虽然RCR STD28中没有详细的说明，我们却可以从Q.931中得到相关的提示。   首先由于被叫没有摘机，主叫自然无法得到Connect消息.   Progress顾名思义，表示呼叫进程，主要用在不同网络联通，如ISDN与非ISDN网络联通。Progress Indicator在许多消息中都会出现，如这里CC DISC中的CC [Progress Indicator:1E028288]，表示当前可以得到带内信息，换句话说，这时主叫可以听到催挂音之类的提示音。   第一个CC PROG表示呼叫已经从ISDN网络进入PSTN网络，可以得到呼叫进程进一步的带内信息。换句话说，呼叫正在被叫网络处理。   [此贴子已经被作者于2003-8-19 8:29:58编辑过]

----------------------------------------------

	第5楼

不知朗讯网络与UT网络的区别何在，造成空中流程中当被叫振铃未摘机时，一个会送CC connect消息，一个只是CC Prog？

	第6楼

那是因为PAS网络中用的是RT,采用接入网结构，因此交换机认为只要呼叫到达接入网，就算用户可达了。

----------------------------------------------

	第7楼

可是斑竹，在iPAS/mSwitch网络中主叫的呼叫流程也同样如此啊！ 另外，现在mSwitch网络有一个新版本，加入了手机摘机后通话时间显示（与G网类似，而与C网不同），此时，CC Connect消息需要等寻呼响应后才会发，不过流程我还没得到！不知其中的奥妙何在？

	第8楼

这个我来回答吧，   深圳在加入这个功能时是按正常呼叫流程来设计的，当汇接局发送ACM后才能发Alerting消息到手机侧，但后来CSC中的T_alerting timer 太短，所以流程改掉了，不论收没收到汇接局发送的ACM,都先发Alerting消息，只有在收到ANM消息后才发送Connect消息

	第9楼

Kongdrag，你的意思是，主叫侧的connect消息触发条件是ANM消息，也即被叫侧摘机消息，而不是被叫侧寻呼响应消息？或者说，被叫侧的connect消息将先于主叫侧的connect消息？

	第10楼

Erry，   在新的mSwittch和CSC版本中，的确像你所说   换句话说，将来的主叫接通率实际上等于现在的主被叫成功率的乘积，呵呵   所以曾经在个别地区版本升级后出现主叫接通率大幅下降，呵呵，   正如斑竹所说，原来的Connect发送是“因为PAS网络中用的是RT,采用接入网结构，因此交换机认为只要呼叫到达接入网，就算用户可达了”，现在我们的GW已经不同于RT了   Erry，我记得好像给你打过电话说过这件事的，忘了么