《 空中接口学园 》
>>   PHS技术
>>>>  STD28/Q.931协议中的一个疑问
--  作者：erry
--  发布时间：2003-08-17 22:52:55
STD28/Q.931协议中，当做主叫时，CC Connect不管被叫如何都会发送，因此，主叫流程中无法得到任何被叫有回应或摘机的消息。我不知道这两个协议设计之初的本意是怎样的，为何要如此设计？
--  作者：tom
--  发布时间：2003-08-18 09:32:49
在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消息的.
--  作者：erry
--  发布时间：2003-08-18 18:53:10
在朗讯网络中，如果被叫不摘机则主叫侧亦无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]
--  作者：tom
--  发布时间：2003-08-18 20:09:17
这是个好问题。实际上，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编辑过]
--  作者：erry
--  发布时间：2003-08-19 10:47:28
不知朗讯网络与UT网络的区别何在，造成空中流程中当被叫振铃未摘机时，一个会送CC connect消息，一个只是CC Prog？
--  作者：tom
--  发布时间：2003-08-20 15:54:45
那是因为PAS网络中用的是RT,采用接入网结构，因此交换机认为只要呼叫到达接入网，就算用户可达了。
--  作者：erry
--  发布时间：2003-08-20 18:57:00
可是斑竹，在iPAS/mSwitch网络中主叫的呼叫流程也同样如此啊！
另外，现在mSwitch网络有一个新版本，加入了手机摘机后通话时间显示（与G网类似，而与C网不同），此时，CC Connect消息需要等寻呼响应后才会发，不过流程我还没得到！不知其中的奥妙何在？
--  作者：kongdrag
--  发布时间：2003-09-03 10:14:56
这个我来回答吧，
  深圳在加入这个功能时是按正常呼叫流程来设计的，当汇接局发送ACM后才能发Alerting消息到手机侧，但后来CSC中的T_alerting timer 太短，所以流程改掉了，不论收没收到汇接局发送的ACM,都先发Alerting消息，只有在收到ANM消息后才发送Connect消息
--  作者：erry
--  发布时间：2003-09-03 12:31:57
Kongdrag，你的意思是，主叫侧的connect消息触发条件是ANM消息，也即被叫侧摘机消息，而不是被叫侧寻呼响应消息？或者说，被叫侧的connect消息将先于主叫侧的connect消息？
--  作者：Jerry
--  发布时间：2003-09-06 15:00:13
Erry，
  在新的mSwittch和CSC版本中，的确像你所说
  换句话说，将来的主叫接通率实际上等于现在的主被叫成功率的乘积，呵呵
  所以曾经在个别地区版本升级后出现主叫接通率大幅下降，呵呵，
  正如斑竹所说，原来的Connect发送是“因为PAS网络中用的是RT,采用接入网结构，因此交换机认为只要呼叫到达接入网，就算用户可达了”，现在我们的GW已经不同于RT了
  Erry，我记得好像给你打过电话说过这件事的，忘了么
--  作者：mapleliu
--  发布时间：2005-02-14 11:23:33
各位，解释结实ANM，ACM是什么，起什么作用？
谢谢了。
--  作者：tom
--  发布时间：2005-02-16 10:23:06
ISUP协议中的内容，看来你还需要了解一些SS7信令。
  ACM是地址全信号，表示对方已经振铃。
  ANM是一个应答信号，表示对方已经摘机。
目前已经有12条评论    >>> 发表你的见解

Powered by：Old version
Copyright ©2002 - 2019空中接口学园 , 页面执行时间：62.500毫秒