技术培训讲义mgcp技术介绍.doc

天马行空官方博客：/tmxk_docin ；QQ:1318241189；QQ群：175569632中国网通宽带电话工程技术培训教材系列 技术培训讲义MGCP技术介绍MGCP协议的基本内容l SoftSwitvh 同传统的网关的区别：MG信令语音至GK至H.323媒体控制SGWWWWWCAl SoftSwitch 中每个扮演的角色1. CA 作为所有动作和行为的控制中心，只负责信令的建立，集中了所有的智能2. 同传统信令网交互，实现互通3. 实现语音等媒体的简单变换功能，是命令的执行体，所有的动作基本上都是根据的指令来执行。l 新架构的特点1. 明确了各个部分的职责和功能，简化了维护和升级，方便了新业务的增加，2. 由于的功能简化了，负载减轻了（只负责信令），同样的资源情况下，可以增加网关容量，可解决扩展性问题3. 可靠性增加。一个网关受多个CA控制，采取冗余机制，一个CA坏了，可用另外一个CA来接管。l 一个典型呼叫的建立CAGW1GW2EP1EP2、在SoftSwitch内部，同的关系，如同介绍人同被介绍人的关系。负责引见人，介绍需引见人的基本关系，待需引见的人认识后，相互之间自然发生联系，只是最后的情况需要同介绍人通告一声，其双方活动期间，可能介绍人要，关心询问一下双方进展情况。整个的呼叫模型同日常生活方式没有两样。以男女关系为例，来说明我们的呼叫流程假如呢，如果一个男生对某个女生产生了好感，想要结交她，又不认识对方！怎么吧？（产生打电话的念头），找第三方吧，找个双方都认识的人，或者人托人，总要找到一个认识的人，才罢休。人找到了，当然需要对中间人表示自己的意愿了，要不中间人也不知你要干什么，这个就要你打个电话，先摘个机，向中间人（）报告一下你的想法，中间人就要问你，你有那些条件，这样才好向对方开口，于是发一个创建连接的命令，要求你将你的基本情况说明一下，比如你的地址，端口号，你的语音支持能力如何等等，中间人得到你的基本情况后，就向你心仪的对方发取一个询问，通过一个创建连接命令将你的基本情况介绍给对方，对方会给你回个自己的要求，比如自己要求的，带宽了啦，想要的语音支持能力啦，中间人得到对方的信息后，琢磨一下你二人有没有戏，如果你们有共同的爱好，要求有共同点的话，中间人，就将对方的要求通过修改连接命令传给你，同时附带上你的要求，表明我确实按你的要求做了。既然你们双方都知道了对方的基本情况，又彼此知道对方的联系方式，当然可以直接邀约了。这个介绍人呢，可能还时不时的询问你们的进展情况，当然也希望你们能将最终情况告知一声。下面的介绍以GW1作为主叫，当GW1上的一个人摘取电话后，GW1会向发送一个通知，表明本网关中某个人准备打电话，收到通知后，先回给发通知的网关一个叫响应的消息，表示我目前已经正式收到了统治，下面我要对你进行处理了。 CA向GW1的发送一个要求创建连接的指示。 GW1为此连接分配资源，创建连接C1，向呼叫代理发送响应。响应提供本地连接的会话描述，其中包含对端向本地连接发送分组所必要的信息，如IP地址、UDP端口以及语音编解码参数等。 CA向GW2的EP2发送CreateConnection消息。消息中带有连接C1的会话描述。 GW2为此连接分配资源，创建连接C2，将C1的会话描述填入C2的远端会话描述之中，GW2进行能力匹配，向呼叫代理发送响应。响应提供连接C2的会话描述，其中包含对端向本地连接发送分组所必要的信息，如IP地址、UDP端口以及匹配后的语音编解码参数等。 CA向C1发送ModifyConnection消息，将C2的会话描述填入C1。EP1和EP2开始通讯。l 和之间的协商要让执行自己的命令，当然就需要将自己的想法明确的告诉同时要明确知道是否收到自己下发的命令，就需要给自己一个明确的答复，这就要求给自己一个响应。同时。可能也需要发给一些通知，也需要给个明确的答复，表明对方确实收到。这样协调之间的行为就通过一些命令和响应来传达。1. 命令共有以下个命令：全称简称(1) EndpointConfiguration： EPCF(2) NotificationRequest ：RQNT(3) Notify：NTFY(4) CreateConnection：CRCX(5) ModifyConnection：MDCX(6) DeleteConnection：DLCX(7) AuditEndpoint：AUEP(8) AuditConnection；AUCX(9) RestartInProgress：RSIP前面条命令是发给的，通知是发给的网关也可以发送DeleteConnection和RestartInProgress消息可以发送任一个审计命令给l 命令之间的区别MGCP有9条命令，怎样区别是那条呢？每个命令都有个命令头，命令头由命令行和参数行组成的，识别不同的命令，看第一行的前四个字符，正确的命令，其前四个字符是命令的缩写。如：MDCX 1209 aaln/1 MGCP 1.0表示修改连接命令（ModifyConnection）rqnt 1065 aaln/1 mgcp 1.0表示通知请求命令（NotificationRequest）l 命令同响应的联系前面也明确过每个命令必须有相应的响应，这样发送命令者可以明确知道自己发送了命令，以及对方是否接受。那么响应通过什么方式同命令相联系？每个响应都有一个响应头，响应是表示对方对相应命令的执行情况的报告，每个响应里面就包含了执行结果德望状态信息，是对是错，错在哪个方面等等。响应消息的第一部分，就是执行状况的报告，表明成功与否，第二不分是一个事务就是一个唯一标志符，响应同命令的联系就是通过这个唯一标志符来进行联系，表明是对那条命令的响应。顺便说一句，唯一标志符是响应取自命令的。说明：200 1065 ok第一部分200 表示执行的情况，200表明，命令执行成功第一部分 1065表示一个事务（就是一个唯一标志符），用来同命令发生联系，表明执行的是那条命令，第一部分 ok是一条注释语句，可有可无，辅助说明执行的情况l 命令请求与通知的关系前面提到了MGCP的协商是由9条命令来实现的，其中有写命令只能由MGC发给MG，有些只能由MG发给MGC，为什么会是这样的情况？我们讲过，整个MGCP的钩架中MGC 和MG 分担不同不同的角色，整个智能基本都集中在MGC侧，MG只是简单的执行MGC下达的命令。有的情况MG可以立刻执行下达的命令，通过响应传回结果，比如说询问你的一些基本情况；有的时候MGC可能要求MG做一些其他的动作，比如说要求MG检测电话是否摘机，MG会回答说好，我马上做此项工作，这个就通过响应回答MGC。接下来MG就要执行检测用户是否有摘机的动作，如果用户打电话，摘机了，MG怎么办，MG是个执行体没有权力也没有头脑来处理这件事情，他只能将此情况上报给MGC，由MGC来思考，来决定该怎么办，那么MG采取什么方式通知MGC呢？，采取响应？可前面回答MGC的命令时已经有了个响应，由于每个命令不可能有两个响应（参见后面的传输部分讲解），因此采取响应来通知MGC我MG发现一个人要打电话是不可行的！怎么办，采取命令，只能由网关发出的命令，这就是通知命令，专门负责通知MGC 我MG按你MGC的要求检测到的事件等等，因此通知命令是同通知请求想联系的，MG发出的通知都是按MGC的要求来做的。那么一个MGC要发那么多的通知请求，同时可能又有许多来自MG的统治要报该MGC，那怎样才能知道那条通知对应MGC发的那条通知请求呢？如果没有对应会发生什么情况？假设我们的通知同通知请求没有对应关系，那有可能出现如此情况，当正在通话时， 你的电话突然MGC接到另外的一个挂机统治，那他不加区分的认为是正在通话的人发出的结束通话通知，就将正在通话的链路中断，那可能将引起很多麻烦。因此通知必须要同通知请求相对应起来，避免乱套。请注意同其他地方的联系（呼叫ID），另外呼叫ID还有其他作用。那么通知怎样同通知请求相对应起来？这就要用道一个唯一标志符叫请求ID，通过这个唯一标志符，将通知和通知请求想联系起来，因此发送通知请求命令时必须带这个唯一标志符，这样通知好获得这个标志，便于将来进行关联。l 怎样区别不同的会话MGC在为不同的人建立会话链路时，可能有很多人在同时等着MGC为他们建立链路，从前面的“呼叫的建立”图中我们知道，整个链路的建立和撤消要经过多个命令和响应的来回，怎样保证MGC和 MG为我和你通话进行协定的消息不会发给其他人，同时也保证其他不相干的协商消息不影响我？这就需要一个区别建立不同会话的唯一标志符（呼叫ID），通过呼叫ID），可以区别目前进行协商的命令是属于哪个会话的，如果没有这个唯一标志符（呼叫ID），那有可能你正在通话时，别人挂机，MGC把它当作你要结束会话来处理。因此凡属于一个会话的都需要一个呼叫ID来保证，也就是说在进行会话建立过程中，每个命令都应带这个唯一标志符。l 怎样保证我打的电话顺利的到达我想到的地方 当用户拿起电话，呼叫对方时，需要的是你拨电话号码，MG将你拨的号码传给MGC，MGC根据你的号码，然后解析出你要呼叫的对方的目的地，然后将相应的命令发给对方，同时附带上你的基本消息。这里有个问题，用户拨的是电话号码，怎样才能解析出你的目的地址，同样对方的MG怎么就知道是你发出的呼叫。这些问题都被一个叫“端点标志的”来解决。“端点标志” （EndPointId）包含域名，本地名，每个“端点标志”同电话号码相对应，在进行会话协商时，通过这个“端点标志”来标志命令的执行体。通过域名部分，知道该消息来自哪个域，从本地名可以知道是哪个网关的，还有具体是哪个端口执行。这样MGC 就能得到很多消息，便于采取相应的动作，比如说回应请求，发送请求啦。l 命令响、应消息的传送MGCP在UDP上传送的，由于路由的不同和网络的拥塞，将导致包的丢失，采取了一些机智来保证消息的顺利到达。、 采取重传机制，就是我发一个消息，当在我自己规定的一定时间内未收到你的回应，我可以认为次消息已经被丢失了。因此我需要在发一次同样的消息，直到我手到你的回应，或者直到我认为，我到你那里的网络链路断了。、 有时候我收到你的命令，可是我同时还收到了很多其他人的命令，我很忙，大家都在排队等候，没办法你也得排队，可等我处理到你那里时，你可能已经等得不耐烦了，不断的给我重发消息，把你也累得够呛，如果大伙都这样，那网络上不都塞满了数据，总的想个办法减少这种情况发生，那就发个临时响应吧，表示我在处理你的消息，你不用着急再发给我。这样就要求当处理来不急时通过发临时响应，来控制网络流量。、 消息在网上传输，由于路由的原因，同样的出发地和同样的目的地，可能这个消息走的非常顺利，不必绕多远就到了，有的呢可能饶很远，甚至永远都到不了。由于有命令重发的可能，因此同样的命令在目的地就要避免执行多次，你不可能在同样的端口上创建多次振铃吧，如果用户拿起了听筒你还在振铃，肯定会恼火，以为电话坏了。因此要保证同样的命令只能执行一次，怎样保证，通过唯一的标志符（事务），通过它来区别命令的相同与否，但是网络传送的原因，你必须保证你的唯一的标志符保存在那里，直到认为所有的同样的命令能到的都到了，这样每个唯一的标志符就要有个生存周期。、 同样如果你回了一个响应表明了你的执行情况，可对方有可能为收到，这时他还要发命令，如果你处理了的话，就知道哦，原来我发给他的响应现在还未收到，可能丢了，那就再重发一次吧，我不可能再执行一次后将结果告诉他，这样我就不可避免的将先前处理的结果保存起来，如果需要的话，我找出来将同样的结果再发一次就行了。、 有时候，有写人想节约一点内存，干脆采取三次握手的方式，如果你收到了我的处理结果麻烦你再吱一声，让我知道你收到了结果，我也知道你再也不会询问我“是否处理了某条命令，请将结果告诉我”，这样我就不用再保存将先前为你的询问而保存的响应了。这样可以节约点内存资源。、 这个地方有个需思考的问题！请仔细考虑l 一个具体的信令流程Step 1 - Notify (ntfy) 摘机从 rgw1到 ca下面的“ntfy”是摘机产生的一个通知，我们假设以前发送过一个通知请求给RGW1，它的请求ID（RequestId ）是445678944 ，要求MG 检测摘机事件。 ntfy 12 aaln/1 mgcp 1.0 o: l/hd x: 445678944 MGC 收到通知后发回一个响应 200 12 ok Step 2 MGC 发给MG一个通知请求，要求检测用户挂机和按号码表拨号 rqnt 1057 aaln/1 mgcp 1.0 r: l/hu(n), d/0-9#*T(d) s: l/dl x: 445678945 d: 5xxx MG收到命令后发回一个响应 200 1057 ok Step 3 用户拨完号后，MG将号码通过“Notify”命令报给MGC ntfy 13 aaln/1 mgcp 1.0 o: d/5, d/0, d/0, d/1 x: 445678945MGC收到此命令后回个响应表示已经收到 200 13 ok Step 4 MGC 发送个通知请求（Request Notification (rqnt)） 给MG 要求MG检测挂机事件 rqnt 1058 aaln/1 mgcp 1.0 r: l/hu(n) x: 445678946 MG收到后回个响应表明收到 200 1058 ok Step 5 - MGC向MG 发出一个创建连接的命令，要求MG 给出自己的能力情况 crcx 1059 aaln/1 mgcp 1.0 c: 9876543210abcdef l: p:20, a:PCMU m: recvonly MG 收到此命令后就将自己的能力情况报给MGC 200 1059 ok i: 456789fedcba5 v=0 o=- 23456789 98765432 IN IP4 s=- c=IN IP4 t=0 0 m=audio 6058 RTP/AVP 0 Step 6 MGC获得了主叫方的能力情况后，将此信息通过创建连接命令发给被叫方，要求被叫也将它的信息报上来。 crcx 2052 aaln/1 mgcp 1.0 c: 9876543210abcdef l: p:20, a:PCMU m: sendrecv v=0 o=- 23456789 98765432 IN IP4 s=- c=IN IP4 t=0 0 m=audio 6058 RTP/AVP 0 被叫MG 收到命令后，就将自己的支持能力报给MGC 200 2052 ok i: 67890af54c9 v=0 o=- 23456889 98865432 IN IP4 s=- c=IN IP4 t=0 0 m=audio 6166 RTP/AVP 0 Step 7 MGC 收到被叫的能力情况后，将主叫和被叫的能力相比较，发相两者的能力可以相匹配，能进行通话，然后就将主叫和被叫的共同能力选出一个发给主叫，修改主叫的当前能力。 mdcx 1060 aaln/1 mgcp 1.0 c: 9876543210abcdef i: 456789fedcba5 l: p:20, a:PCMU M: recvonly v=0 o=- 23456889 98865432 IN IP4 s=- c=IN IP4 t=0 0 m=audio 6166 RTP/AVP 0 主叫MG 收到命令后回个响应 200 1060 ok Step 8 MGC 向主叫发通知请求要求放回铃音，同时要求检测挂机