精华内容
下载资源
问答
  • 呼叫处理的三个步骤
    千次阅读 多人点赞
    2022-05-03 14:03:57

    目录

    一、题目

    二、设计步骤以及逻辑图

    三、仿真文件


    一、题目

    图一 题目要求

    二、设计步骤以及逻辑图

            如题,要设计一个病房呼叫电路,并要在数码管中显示病房号,而且病房号的有优先级,1号优先级最大,8号优先级最小。

            先用74LS148进行编码,然后用译码器进行译码,这里我选择用15V供电的4511BD进行译码(没有用上次实验用的74LS47,其实都一样),最后将译码器的输出接上数码管。由于编码器的输出为0000H-0111H,而我需要的是0001H-1111H,所以我需要在编码器的输出端加上一个四位全加器进行调节(加一),全加器我选择74LS283。

    表一 病房呼叫电路输出测试

            

                有了测试图那么说明我的电路就算是设计完成了。

                

    图二 病房呼叫电路逻辑图

    三、仿真文件获取

            请联系qq:947470468(免费)

    更多相关内容
  • (1)分析并总结程控交换机的各部分功能需求。 (2)分析程控交换机软件系统的程序的执行过程。...(3)交换软件程序的层次结构及其实现模块,不同层次的软件模块组成,每模块完成的功能,高层软件由低层提供支持。
  • 使用 Queue,“管理”一个呼叫队列就像三个步骤一样简单: 使用拨号/队列 TwiML 组合将传入呼叫定向到队列。 (可选)您可以使用 REST 队列资源检索平均等待时间和当前队列大小等统计信息。 连接到下一个调用者是...
  • 华琪呼叫系统综述.doc

    2022-06-23 15:58:12
    华琪呼叫系统综述
  • Exchange了解入站传真邮件呼叫处理 的介绍
  • VoIP,六个步骤告诉你如何避免VoIP安全风险,Forrester公司在最近的研究中,推荐下述六个步骤来帮助IT组织避免VoIP安全风险并最终确保他
  • 参考说明书病房呼叫器.doc
  • 病床呼叫系统

    2013-12-18 18:48:27
    ,共有4房间,每间病房3床位。每一病床床头有紧急呼叫按钮及重置按钮以利病人不适时紧急...4,一旦护士看见护士站紧急呼叫闪烁灯后,须先按下护士处理按钮以取消闪烁情况,在依病房紧急呼叫顺序处理病房紧急事故。
  • 具体的处理流程经过11个步骤: 现在,我们配合SIP消息来进一步说明如何实现即时消息转发方式。 首先,Alice对Bob发送INVITE消息(F1): Bob回复180(F2) : 紧接着Bob对Alice发送 200 OK(F3): Alice对Bob发送...

    目录

    6、Transfer - Instant Messaging

    7、Call Forwarding Unconditional

    8、Call Forwarding - Busy

    9、Call Forwarding - No Answer

    10、3-Way Conference - Third Party Is Added

    11、3-Way Conference - Third Party Joins

    12、Find-Me

    13、Call Management (Incoming Call Screening)

    14、Call Management (Outgoing Call Screening)

    15、Call Park

    16、Call Pickup

    17、Automatic Redial

    18、Click to Dial


     

    在《最常用的18个SIP呼叫业务流程详解(1~5)》中介绍了三种保持(Hold)和两种转接(Transfer)的详细流程,本节继续介绍剩余的流程。

     

    6、Transfer - Instant Messaging

      Transfer - Instant Messaging,我们称之为即时消息转发。其主要的工作方式是,首先用户Alice和Bob创建了一个会话,然后Bob呼叫Carol,Bob发送即时消息给Carol,即时消息中包含一个Alice的URL和一个嵌入的Replace头。如果Carol点击这个URL链接,Carol的SIP终端会对Alice发送一个INVITE请求,并且替换了会话中的Bob。在这个示例中,其URL传递是使用的SIP MESSAGE method来实现(参考RFC3428),也可以使用其他IM即时协议来完成Bob和Carol之间的URL传递工作。具体的处理流程经过11个步骤:

      现在,我们配合SIP消息来进一步说明如何实现即时消息转发方式。

      首先,Alice对Bob发送INVITE消息(F1):

      Bob回复180(F2) :

      紧接着Bob对Alice发送 200 OK(F3):

      Alice对Bob发送Ack确认,开始RTP流(F4):

      然后Bob对Carol发送一个message call(F5),在这个即时消息中携带了Alice的URL和Replaces头。

      Carol看到以后,发送一个200 OK给Bob:

      接下来,Carol点击URL,控制这个呼叫,对Alice发送一个INVITE请求,并且替换了Bob(F7)。

      Alice对比dialog中消息和Replaces的头消息,确认以后,接受Carol的请求。Alice对Carol回复一个200 OK(F8):

      Carol对Alice回复了ACK消息(F9),并且开始RTP流。

      Alice和Carol开始通话以后,并且因为已经替换了Replaces头,所以Alice对Bob挂机处理,Alice对Bob发送BYE消息(F10):

      Bob对Alice发送200 OK(F11),到此为止,即时消息转接的流程完成。

    7、Call Forwarding Unconditional

      Call Forwarding Unconditional,我们称之为无条件呼叫前转。从字面意思,读者也可以看明白,被呼叫方会把呼叫进行无条件转移。与之对应的是忙状态呼叫前转和无应答呼叫前转。这些业务都涉及到了运营商接入业务(PSTN或者IMS),不是专门针对内网IPPBX用户之间的电话转接功能。我们会在后续的章节中分别介绍这两种呼叫的流程。这里,我们仅对无条件前转进行分析。

      这里,我们假设Alice呼叫Bob(这里没有标识Bob的流程)。Bob会把呼叫无条件前转到PSTN网络。如果实现此场景,呼叫必须经过Proxy和Gateway来实现处理。Gateway看作为另外一个Proxy的URL地址,同时支持了PSTN的接口。在以下的场景中,Alice对Bob进行呼叫,这个INVITE消息会经过Proxy,Proxy则会重写请求的URL地址,然后前转这个INVITE到Gateway地址。以上两步是前转最重要的部分,所以,我们仅针对这个部分进行深入分析,对网关侧和Bob的响应不做分析。

      这里,读者需要注意,在以上示例中的F3中,Proxy是通过返回Alice 一个181 响应消息来实现的呼叫前转处理。严格地说,在这个使用场景中,Proxy仅扮演着用户代理的角色,它不能生成non-100的临时响应回复消息。另外需要说明的是,呼叫前转的处理也可以通过redirect的方式来实现,就是通常所说302 Moved Temporarily response。以下图例是一个完整的无条件呼叫前转流程和具体的SIP消息操作。

      接下来,我们针对无条件呼叫前转的具体细节,结合请求响应消息进行分析介绍。首先,Alice对Bob发送INVITE请求,通过Proxy执行呼叫(F1):

      然后,Proxy回复Alice 一个100 trying(F2),表示正在处理这个请求,忽略了流程图。接下来,Proxy会对Alice发送一个181响应消息(181 Call is Being forwarded),执行F3流程;同时Proxy对Gateway发出一个INVITE请求(F4)。这里,Proxy对Gateway发送到INVITE请求中已经重写了请求URL地址。

      读者可以看到,Proxy和Gateway都没有做任何其他的条件判断,直接转发到下一个目的地地址。在F5中,Gateway直接对Proxy回复一个180 Ringing,然后在F6中,Proxy回复Alice一个180 Ringing。

      Gateway对Proxy发送180 Ringing以后,紧接着,Gateway对Proxy发送200 OK(F7),然后Proxy对Alice发送200 OK(F8)。

      Alice收到200 OK以后,接下来,Alice对这个INVITE请求进行确认,发送ACK消息(F9)。Proxy收到ACK消息以后,直接对Gateway发送ACK确认信息(F10)。双方RTP语音流正式创建。

      通话完成后,Alice挂机,对Proxy发送BYE消息(F11),然后Proxy对Gateway发送BYE消息(F12)。

     

      最后,Gateway对Proxy发送200 OK(F13),Proxy再对Alice发送200 OK(F14),到这里,双方的无条件呼叫前转正式结束。

    8、Call Forwarding - Busy

      Call Forwarding - Busy,我们称之为遇忙呼叫前转。简单来说,就是呼叫方通过Proxy呼叫被呼叫方时,被呼叫方此时处于忙状态,然后Proxy把呼叫再次转发到第三方用户。例如,Alice通过Proxy呼叫用户1,此时,如果用户1处于忙状态,Proxy收到用户1的回复信息,Proxy会把此呼叫通过一个INVITE再次转发到用户2终端。遇忙呼叫前转到流程图如下:

      下面,我们配合具体的SIP消息示例来进一步说明整个遇忙呼叫前转的处理过程。

      首先,Alice对Proxy发送一个INVITE请求,需要呼叫用户1(F1),Proxy

      接下来对用户1发送一个INVITE请求,通知用户1,Alice要呼叫对方。

      在处理以上流程的同时,Proxy会对Alice发送一个100 Trying(F3),Proxy告诉Alice正在处理此呼叫,忽略了100 Trying图例。经过一定时间后,用户1此时此刻正在处于电话的忙状态,不能接听此呼叫。然后用户1对Proxy发送了一个486 Buy响应消息(F4)。

      Proxy获悉用户1是处于忙状态后,对用户1发送一个ACK确认信息,表示收到了用户1的状态响应(F5)。

      为了处理用户1处于忙状态不能接听电话的问题,Proxy首先通知Alice,proxy需要进行电话前转。所以,Proxy需要对Alice发送一个180 call is Being Forwarded的消息,通知Alice,你的呼叫正在被前转。同时,Proxy再次发起一个INVITE请求,这次,对用户2发出INVITE请求进行呼叫前转。

      接下来,用户2对Proxy发送180 Ringing响应消息(F8),Proxy然后对Alice发送180 Ringing响应消息(F9),表示前转接受。

     

      发送180 Ringing以后,紧接着,用户2对Proxy发送200 OK(F10),然后Proxy对Alice发送200 OK(F11)。

      Alice收到Proxy发送的200 OK以后,发送确认消息ACK(F12)。然后Proxy对用户2发送确认消息ACK(F13)。接下来,Alice和用户2创建媒体流,双方开始正常通话。

      通话结束后,Alice对Proxy发送BYE消息(挂机,F14),然后Proxy对用户2发送BYE消息(F15)。

      最后,双方进行挂机的最终确认,首先由用户2发送200 OK到Proxy(F16),然后Proxy对Alice发送200 OK(F17)。

     

      到此为止,遇忙呼叫前转的处理流程正式结束。

    9、Call Forwarding - No Answer

      Call Forwarding-NO Answer, 我们称之为无应答前转。具体的实现过程和前面谈论忙呼叫前转的处理方式基本一致,唯一不同是,用户1是无应答,然后Proxy通过定时器检测超时,进行对第三方用户2前转处理。其余的处理流程基本和遇忙前转的处理流程一致。简单来说,Alice通过Proxy呼叫用户1,用户1在一定时间内没有应答此呼叫,然后Proxy把这个呼叫转接到用户2,对用户2进行呼叫处理。在请求超时后(F6),Proxy对用户1发送取消请求,然后通知Alice,同时对用户2再次进行INVITE请求处理,进行呼叫请求。具体的呼叫流程如下:

      接下来,笔者配合具体的SIP消息来进一步说明无应答呼叫前转的处理方式。

      首先,Alice通过Proxy对用户1发出INVITE请求,对用户1进行呼叫(F1),然后Proxy对用户1发送INVITE请求,对用户2进行呼叫请求处理。

      接下来,Proxy马上对Alice发送一个100 Trying(F3忽略),表示正在对用户1进行呼叫,通知Alice等待。用户1对Proxy发送180 Ringing(F4),Proxy也对Alice发送180 Ringing(F5)。

      这时,用户1处于振铃状态,在Proxy设定的定时器超时设置范围内,用户1终端无人接听此呼叫。因此,Proxy对用户1发送Cancel消息,通知用户1停止振铃。

      然后,用户1对Proxy发送200 OK(F7):

      接下来,用户1马上对Proxy发送一个487 响应消息,表示定时器超时,在一定振铃时间内无人应答此呼叫。

      Proxy收到超时消息以后,对用户1发送ACK确认消息,确认超时事件(F9):

      这时,Proxy需要做两件事。Proxy知道用户1是因为振铃超时,无人应答这个呼叫。接下来,Proxy重新调整呼叫流程,再次进行呼叫转接到处理。首先,Proxy先对Alice发送一个电话转接到响应消息(181 电话前转),通知Alice,你的呼叫正在被前转到其他用户终端(F10)。紧接着Proxy对用户2发送一个INVITE请求,对其进行呼叫(F11):

      然后,用户2对Proxy发送180 Ringing(F12),Proxy又对Alice发送180 Ringing(F13):

      振铃发送以后,用户2继续对Proxy发送200 OK(F14),Proxy又对Alice发送200 OK(F15):

      Alice收到200 OK以后,继续对此流程进行进一步的处理,以便开始双方的通话或RTP流。Alice马上回复Proxy ACK确认消息(F16),Proxy也马上对用户2回复ACK确认消息(F17):

     

      经过一定时间段通话以后,Alice首先挂机,对Proxy发送BYE消息(F18),Proxy再对用户2发送BYE消息(F19),通知用户2挂机:

      最后,用户2对Proxy发送最后200 OK消息(F20),然后Proxy对Alice发送最后的200 OK(F21)。到此为止,无应答呼叫前转的呼叫流程正式完成。

      这里读者一定要注意,我们讨论的呼叫前转方式方式可以通过IPPBX或者软交换的配置来实现,proxy或者媒体服务器的设置会影响振铃的时长设置,这样可能导致电话振铃问题,被呼叫方如果接听不及时的话,可能产生无应答呼叫。

      所以,在部署前转时一定要配合IPPBX或者其他的软交换来解决。另外,结合一些其他的应用需求,还有一些IPPBX可以设置为无应答或者分机随行的方式,如果终端无应答,可以转接到用户手机或者其他的终端,或者留言等方式。这些需要用户支持其他的接入方式来实现。

    10、3-Way Conference - Third Party Is Added

      3-Way Conference - Third Party Is Added,我们称之为三方会议邀请。简单来说,此呼叫业务就是一个简单的三方电话会议。通常来说,如果是两方通话,我们称之为正常呼叫业务。如果介入了第三方或者更多人的话,我们称之为三方会议或者多方会议。

      一般的三方会议至少需要一个混音处理单元。在以下的部署场景中,Alice呼叫Bob,然后双方进行通话。这时,Bob想把第三方Carol也邀请到电话会议中来一起讨论问题。当然,Bob自己本身必须具备处理第三方媒体混音的功能。然后,Bob首先对Alice发送一个re-INVITE,在INVITE中,修改了多个Contact URLs为一个URL,这个URL表示Bob的混音单元。然后,Bob对Carol发送一个INVITE请求,邀请Carol参加会议,并且使用同样的Contact URL。

      这里,读者要注意,Bob邀请的处理方式可能有所不同。Bob可以先等Carol应答以后,再对Alice发送re-INVITE。Bob也可以呼叫Carol之前,先把Alice设置为等待状态。另外,Bob邀请会议时,Bob包含了一个功能标签tag-“isfocus”,表示Bob是一个会议处理中心。"isfocus"是在规范rfc3840中定义:

      Summary of the media feature indicated by this tag: This feature tag

      indicates that the UA is a conference server, also known as a

      focus, and will mix together the media for all calls to the same

      URI [13].

      关于会议中focus的定义和规范,读者可以参考rfc4579的第三章节。以下是一个完整的会议第三方邀请处理流程。

      下面,我们通过SIP消息结合具体的流程来说明第三方会议邀请是如何进行的。

      首先,Alice对Bob发送INVITE请求,对其进行呼叫(F1):

      Bob对Alice回复180 Ringing(F2):

    11、3-Way Conference - Third Party Joins

      3-Way Conference - Third Party Joins,我们称之为三方会议加入。和上面的三方会议邀请不同的是,这里的第三方是自己主动希望加入到电话会议中,而不是由其他人邀请加入。因此,在处理三方会议时,其处理流程和前面的被邀请的方式完全不同。

      通过以上的处理流程我们来详细解释会议加入的方式是如何处理的。这里,我们假设Alice和Bob两个人正在进行双方的语音通话。Carol通过其他学习方式或者对Bob的订阅消息,例如Bob发送的其他非SIP消息或者Bob对Carol发送到NoTIFY消息,其消息中含有dialog事件包。关于dialog的事件订阅的处理,读者可以参考RFC4579中的第5.8章节和RFC4235的规范。

      这时,Carol希望加入到Alice和Bob之间的电话呼叫中。这时,Carol会对Bob发送一个INVITE请求(F5),这个请求中包含一个Join头,在这个头中,包含Alice和Bob两者之间的dialog,以此来保证Carol加入到是正确的dialog,而不是其他的会议呼叫。Bob然后对Alice发送一个re-INVITE修改了通话模式(F7),从双方谈话变成一个“isfocus”模式(rfc3840),开始支持三方会议的模式。然后,Bob才接受来自于Carol的INVITE请求,最后开始三方通话或者电话会议模式,此时,三方会议加入的处理流程彻底完成。现在,我们通过完整的SIP消息配合具体的处理流程来进一步对电话加入的方式做出详细介绍。

      首先,Alice对Bob发送INVITE请求,进行电话呼叫(F1):

      然后,Bob对Alice发送180 Ringing(F2),紧接着,Bob对Alice发送200 OK(F3):



      然后,Alice对200 OK回复ACK确认信息(F4),双方开始RTP流传输:

      这时,Carol通过Bob发送到其他的非SIP消息或者NOTIFY事件了解了Alice和Bob之间正在进行电话呼叫,Carol想加入到这个电话呼叫中。因此,Carol对Bob发送一个INVITE请求,在这个INVITE请求中(F5),包含有Join的头,这个头中含有加入他们之间还有的dialog消息内容(Join中忽略了具体的内容):

      Bob先对Carol发送一个180 Ringing(F6):

      然后,Bob再对Alice发送一个re-INVITE请求,Bob通知Alice,因为Carol要加入电话会议中,我现在需要修改通话模式,修改为“isfocus”模式来支持电话会议,需要进行媒体混音处理。

      Alice收到Bob的INVITE请求后,对其请求表示同意,然后对Bob发送200 OK(F8):

      Bob对Alice 的200 OK发送响应消息,获悉Alice同意修改为会议模式(F9):

      现在,Bob完成了和Alice的协商,获悉Alice已经准备好进行电话会议。接下来,Bob才对Carol发送200 OK,接受了其要求加入电话会议的INVITE请求,这里包括了新的Contact的会议地址。

      接下来,Carol知道Bob已经允许自己可以加入到会议中,对Bob发送最后ACK确认消息,表示正式加入会议中。此时,Carol加入到了会议室,三方会议正式开启(F11),RTP流开始工作。这里的Bob构成了一个媒体混音单元,也可能是一个会议媒体服务器功能,进行三方混音。

      这里,笔者再进一步介绍一下会议的标签isfocus tag。会议模式中的isfocus参数可以支持多种使用方式,通过SIP,它可以支持以下几种方式:

    • 创建会议
    • 加入会议
    • 邀请用户加入会议
    • 踢出会议用户
    • 支持对会议URL判断,可以检查到是否是会议URL
    • 删除会议

      会议创建的方式Ad-Hoc方式临时自组的方式来创建一个会议,也可以通过REFER方式来创建一个会议室。会议邀请的方式可以通过INVITE请求,用户可以主动呼入或者用户被呼方式来进入到会议室,也可以通过REFER的方式邀请用户进入到会议室。关于会议的管理和使用部署,RFC4579中有着非常详细的说明,同时此规范也介绍了其他的协商流程。读者可以阅读此规范进一步了解多方会议的处理流程。

      在开源媒体服务器中,Asterisk/FreePBX/FreeSWITCH也支持了强大的会议功能。用户可以创建会议室,系统通过自动拨号的形式邀请会议用户来加入到会议中,用户也可以通过语音IVR的形式进入到会议室中。会议主席也可以对会议人员实现静音或者踢出等功能。如果使用Asterisk的界面管理系统FreePBX,用户也可以通过界面来创建会议室,支持多种会议的管理功能,例如会议密码设置,最大会议用户人数设置,进入会议室播放提示,音乐等待等功能。

    12、Find-Me

      Find-Me, 我们称之为有效用户查询呼叫。简单来说,Alice通过Proxy呼叫Bob,Bob可能有几个Contact地址。Proxy会根据不同的Contact列表来逐一查询这些地址的状态,如果有可接通的地址,则对其进行呼叫;如果没有,Proxy会继续查询其他的地址,直到找到可接听呼叫的地址。一旦找到可接听通话的地址,则不再继续查询其他的地址。

      这里笔者提醒读者,在对用户状态的查询中,系统也可以使用并列查询的方式。我们刚才使用的是按序查询的方式,系统也可以使用并列查询的方式。并列查询状态下,Proxy会同时对所有Contact 列表中的地址发送查询可接听的地址,然后创建RTP语音流。以下图例中说明了两种重新的处理不同。并列查询的处理方式:

      按序查询的处理方式:

      在本章节的有效用户查询呼叫中,我们使用的方式是按序查询的方式。Proxy会通过Bob的Contact列表逐一查询地址状态,如果有效,则创建呼叫。

      下面,我们结合SIP消息和具体的流程进行分析。

      首先,Alice通过Proxy对Bob进行呼叫,发送INVITE请求给Proxy(F1),Proxy对Bob发送INVITE请求(F2):

      接下来,Proxy马上回Alice 一个100 Trying(这里忽略,F3),表示呼叫正在处理中。用户1对Proxy回一个180 Ringing(F4)。紧接着,Proxy对Alice回复一个180 Ringing,表示用户1已经振铃(F5)。

     

      但是,在一定的振铃时间内,用户1没有人接听电话呼叫,Proxy的定时器出现超时。然后,Proxy对用户1发送Cancel消息(F6)。

      用户1对Proxy回复一个200 OK(F7):

      然后,用户1对Proxy发送一个487 超时消息(F8):

      Proxy对487 回复一个ACK确认消息(F9):

      在获悉用户1呼叫超时以后,Proxy继续对Contact 列表中的用户2地址发送INVITE请求(F10):

      但是,用户2根本没有登录注册,所以,用户2回复480 消息(F11)

      Proxy对用户2回复ACK确认(F12):

      然后,Proxy继续对Bob的Contact 列表中的用户3地址发送INVITE请求消息(F13):

      但对用户3发送INVITE请求后,发现用户3处于忙状态,不能接听这个呼叫。用户3回复486 Busy Here(F14):

      紧接着,Proxy对用户3回复ACK确认消息(F15):

      接下来,Proxy继续对Bob的Contact列表中的用户4地址发送INVITE请求(F16):

      然后,用户4回复Proxy 180 Ringing(F17),Proxy再回复Alice一个180 Ringing(F18):

      紧接着,用户4对Proxy发送一个200 OK(F19),然后,Proxy又对Alice发送一个200 OK(F20):

      然后,Alice对Proxy发送一个ACK确认消息(F21),Proxy对用户4发送一个ACK确认消息(F22)。到此为止,整个有效用户查询呼叫的流程完成,双方开始语音流的互通。

      结合以上多种用户终端出现的情况,Proxy经过了Bob的4个Contact列表地址查询,第一个呼叫超时,第二个地址没有登录,第三个用户忙,到最后一个用户地址,才真正和Alice创建了RTP语音流的传输。在每一个异常状态下,终端都返回相应的响应消息,然后Proxy会对每一个响应发送ACK,然后再进行下一个有效用户的地址查询。

      通话一段时间后,用户4对Alice挂机,对Proxy首先发送BYE消息(F23), Proxy对Alice进行挂机处理,对其发送BYE消息(F24):

      然后,Alice对Proxy发送200 OK(F25),Proxy再对用户4发送200 OK(F26):

      Alice和用户4的通话正式结束。

    13、Call Management (Incoming Call Screening)

      Call Management (Incoming Call Screening),我们这里称之为呼叫筛选或呼叫过滤。在企业通信环境中,为了节省员工的时间,提高工作效率,用户可以设置一个电话筛选机制来保证不被一些不相关的电话骚扰。简单来说,如果有外部呼叫呼入到IPPBX的终端时,终端可以显示呼叫方号码,或者名称,或者通过第三方媒体发送到语音提示。此时,终端用户可以根据终端所设置的号码地址薄选择继续接听电话,拒绝,转语音邮箱,或者对呼叫方播放一个自定义的语音媒体。以上这些功能都可以通过Proxy加媒体播放服务器来实现,或者使用企业IPPBX本身的配置功能来实现。为了更加专业地表达此功能名称,我们称之为呼叫筛选或呼叫过滤,黑白名单过滤比较通俗易懂。其实,呼叫筛选和黑白名单过滤的功能要求基本类似,从功能设置的角度来说它们的功能基本相同。

      在日常生活中,我们简单称之为黑白名单过滤。因为大量的骚扰电话的问题,我们现在已经对呼叫筛选不陌生了。我们手机app所设置的骚扰电话设置或者黑名单过滤等都可以视为呼叫筛选的功能。但是,这些基于个人终端的业务支持,不是我们这里讨论的内容。

      呼叫筛选的具体流程经过了几个步骤。假设,Alice呼叫用户Bob,Bob的终端联系方式中可能已经对Alice设置为拒绝接听的地址,因此Bob拒绝接听此呼叫。拒绝接听后,Bob对Alice返回了一个消息,通知你呼叫必须通过Proxy的安全认证机制,Bob仅接受经过Proxy确认的呼叫。因此,Alice再次对Proxy发送请求,但是因为安全设置的问题,Alice没有通过Proxy的安全认证,Proxy在错误消息返回时插入了一个新的Error-info的URL地址,Alice播放这个来自于媒体服务器或者第三方声明提示等服务器的语音提示。

      这里注意,安全认证不能使用From 头来判断,必须通过Proxy的安全机制来处理。以下是一个呼叫筛选的流程图,在图例中,一般企业用户使用IPPBX本身自带的媒体播放功能对Alice实现媒体语音提示。
      接下来,我们根据SIP消息细节结合每一个处理流程来进一步说明呼叫筛选的处理过程。

      首先,Bob看到来自于Alice的呼叫,表示Alice需要和Bob通话(F1)。

      Bob拒绝了Alice的呼叫请求,要求必须通过Proxy认证才能通话。Bob对Alice发送305消息(F2):

      Alice获悉这个错误以后,对Bob发送ACK确认消息(F3):

      然后,Alice对Proxy发送INVITE请求(F4):

      然后,Proxy对Alice发送认证响应消息407(F5):

      Alice对Proxy返回确认ACK消息(F6):

      然后,Alice对Proxy发送安全认证消息(F7),携带自己的认证信息:

      Proxy经过安全认证检查以后,发现Alice没有权限直接呼叫Bob,呼叫筛选不能通过,因此对Alice返回一个失败消息(F8),并且插入了一个Error-info,带了一个URL地址。这个地址播放语音提示。

      Alice收到403 响应错误消息以后,对Proxy发送一个ACK确认消息(F9):

      为了知道Proxy对Alice发送的是什么提示,Alice会继续对这个Error-info的地址进行访问,发送一个INVITE请求(F10)这时一个媒体播放的服务器地址,其服务器会对Alice播放刚才呼叫失败的提示音:

      然后,媒体播放服务器对Alice发送200 OK消息(F11),表示可以对Alice播放语音提示。

      另外,在F11的200 OK中,媒体播放服务器对Alice增加了一个渲染功能标签,表示此服务器仅能支持自动媒体功能automaton和rendering:

      F11 200 OK Announcement Server -> Alice

      SIP/2.0 200 OK

      Via: SIP/2.0/TLS client.atlanta.example.com:5061

      ;branch=z9hG4bK74bfj

      ;received=192.0.2.103

      From: Alice ;tag=1234567

      To: Bob ;tag=234934

      Call-ID: 12345600@atlanta.example.com

      CSeq: 4 INVITE

      Contact:

      ;automaton;+sip.rendering="no"

      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY

      Content-Type: application/sdp

      Content-Length: …

      v=0

      o=annc 2890844543 2890844543 IN IP4 announce.biloxi.example.com

      s=

      c=IN IP4 announce.biloxi.example.com

      t=0 0

      m=audio 49174 RTP/AVP 0

      a=rtpmap:0 PCMU/8000

      注意,在RFC5359规范的2.13章节中,F11的处理流程可能存在表述错误。读者需要根据实际的场景来做出正确的判断。按照流程图的示意,F11应该是从媒体服务器到Alice的返回消息:

      但是,按照正常的处理规范来说,应该是媒体服务器对Alice的返回消息(200 OK)。另外一个矛盾的地方是,在具体的流程中(F11),规范又描述为媒体到Proxy 1的处理流程:

      以上讨论是笔者仅根据官方规范做的疑点做出的自己的判断,读者可以通过其他渠道和规范发布者确认最终结果。

      现在我们回到合理的处理流程中。接下来,Alice收到200 OK以后,对媒体服务器发送ACK确认消息,然后媒体播放服务器对Alice播放语音提示(F12):

      语音提示播放完成以后,媒体服务器对Alice发送BYE消息,表示媒体播放结束,断开连接(F13)。

      最后,Alice收到了媒体播放器发送到最后提示,表示断开连接,Alice发送确认消息(F14):

    14、Call Management (Outgoing Call Screening)

      Call Management (Outgoing Call Screening),我们称之为呼出呼叫筛选。此呼叫业务和上面的呼入呼叫筛选基本类似,但是处理流程更加简单。简单举例,呼叫方Alice通过Proxy呼叫Bob,但是Bob在Alice的呼叫筛选名单中,Proxy对Alice要求安全认证的验证,Alice对Proxy发送安全认证的消息,但是因为Bob在Alice的Call Screening的筛选名单中,不能对Bob进行呼叫,因此,最后,Proxy对返回403 呼叫筛选失败,最后挂机。

      现在,我们结合具体的SIP消息,配合每个呼叫流程做进一步的细节介绍。

      首先,Alice对Proxy发送INVITE请求,要求对Bob进行呼叫(F1):

      Proxy要求Alice发送安全认证消息进行验证(F2),返回407响应消息:

      Alice获悉以后,继续对Proxy发送ACK确认消息(F3):

      然后再次对Proxy发送INVITE消息,包含了安全认证的信息(F4):

      Proxy经过检查,Alice没有权限呼叫Bob,因此对Alice返回403 Screening Failure (Originating)的消息,表示不能对Bob进行呼叫(F5)。另外,在返回的消息中插入了一个Error-info 头,包含了一个媒体播放的链接,用户可以听到失败提示音。

      Alice收到403以后,获悉自己不能呼叫Bob,发送ACK给Proxy。此时,外呼筛选流程结束(F6)。

      关于呼叫筛选的功能,很多IPPBX支持了多种配置方式和功能。比较常见的处理方式包括:不在呼叫权限组,呼叫前缀不对,用户不接受其他部门呼叫,一定时间内不接受其他无关联用户呼叫,或者其他IP地址的呼叫,出差期间不接受呼叫等筛选方式。

      这里比较关键的是筛选失败以后的处理,如何对呼叫失败方进行一个比较友好的处理方式,比如,对呼叫失败方播放语音提示,转到语音留言,抓到其他的IVR流程,或者进行后期回呼处理。在Asterisk或者FreeSWITCH平台中,这些处理策略都可以通过IPPBX的拨号规则加一定的脚本来实现筛选的路由控制。具体的实现方式用户参考网上的学习资料。

    15、Call Park

      Call Park,我们称之为呼叫驻留/停靠。简单来说,呼叫驻留就是呼叫方呼叫被呼叫方时,电话被驻留在驻留服务器(一般是媒体服务器或者IPPBX)。经过一段时间后,呼叫方电话被其他第三方用户再次接听。具体的实现过程是这样的,假设Alice呼叫Bob,Bob和Alice开始通话,通话后,可能Alice想转接第三方或者Bob可能有其他事情,暂时不能继续和Alice通话,Bob通过终端按键对其通话进行电话驻留的设置。

      所以,Alice的电话被驻留在驻留服务器或者IPPBX/媒体服务器。Alice电话被驻留以后,媒体服务器会对Bob发送订阅消息,说明电话驻留状态。然后,媒体服务器对Alice发送一个INVITE请求,通知Alice,媒体服务器现在替换了Bob来对其会话进行管理。Alice获悉驻留状态后,接受此处理流程,然后,媒体服务器或者IPPBX对其播放音乐媒体提示音。接下来,Alice对Bob发送BYE消息,媒体服务器对Bob发送Bob消息,表示现在媒体服务器已经驻留了Alice的通话,Bob脱离和Alice之间的关系。第三方Carol想接听这个被驻留在媒体服务器的呼叫,因此,首先需要对媒体服务器发送订阅消息,媒体服务器接受订阅以后,获悉Carol想接听这个被驻留的呼叫,接下来Carol对Alice发送INVITE请求,并且要求替换会话中的媒体服务器。Alice收到此请求后,同意和Carol进行通话,发送协商成功的响应消息,然后双方正式开始通话,驻留处理流程完成。

      在电话驻留的流程中,几个问题需要读者注意。首先,这里的电话驻留被重新接听的是第三方的用户,当然,接听用户也可能是发起驻留电话自己本身。但是,这样的驻留方式也不符合大部分场景中的电话使用习惯。因为,大部分已经开始的通话,或者进行电话转接,或者一定时间后双方挂机,或者挂机后,双方稍晚时间后重新呼叫对方。因此,电话驻留其实也是电话转接的一种特殊方式或特殊使用场景。其次,电话驻留的方式其实也是音乐等待的一种处理方式。只是,在电话驻留服务器或者媒体服务器中,驻留处理可以分割为多个驻留空间或者slot,电话驻留基本的处理流程或原理事实上和语音等待类似。最后,电话驻留服务器开启驻留处理时也对驻留方发送了automaton,,rendering和 byeless tag标签,表示其服务器的支持能力。以下是电话驻留的处理流程:



      现在,我们结合具体的SIP消息和每一个处理的具体细节来一步步介绍整个电话驻留的处理:



      首先,Alice对Bob发送INVITE呼叫请求(F1):

      然后Bob对Alice响应180 Ringing(F2):

      紧接着,Bob对Alice发送200 OK(F3):

      Alice收到200 OK以后,对Bob发送ACK确认消息(F4),双方开始通话。

      通话后获悉,Alice可能需要被驻留,然后第三方Carol来接听。因此,Bob首先需要对Alice通话进行电话驻留处理,把Alice的呼叫停靠在驻留服务器或者媒体服务器上,Bob对服务器发送REFER消息(F5),并且通知媒体服务器在会话中使用Bob替换Alice。这里的Refer-To是Alice,Refer-By是Bob自己。注意,这里不存在Bob和媒体服务器之间的直接的会话。

      驻留服务器收到Bob的REFER以后,对Bob发送一个202 Accepted,表示接受此REFER消息(F6):

      然后,驻留服务器对Bob发送NOTIFY消息,创建一个对事件的订阅,同时提示Bob正在处理电话驻留(F7),100 Trying:

      Bob回复200表示收到订阅事件(F8):

      接下来,驻留媒体服务器对Alice发送INVITE请求,同时替换Bob(F9),增加了渲染功能的标签,表示媒体服务器的处理能力(在Contact中插入了媒体服务器的渲染功能标签:

      Contact:;automaton ;+sip.byeless;+sip.rendering="no"

      注意:以下图例中忽略了渲染功能标签

      Alice接受了媒体服务器的请求,发送200 OK(F10):

      媒体服务器对Alice发送ACK确认消息,开始媒体流处理(这里开始播放语音提示,F11):

      提示音播放开始以后,Alice对Bob发送BYE消息(F12),表示Alice已经和媒体服务器创建了新的会话关系:

      Bob获悉Alice的电话被成功驻留以后,对Alice发送一个最终的200 OK(F13):

      这时,媒体服务器再次对Bob发送NOTIFY消息,并且携带了返回的200 OK消息,表示媒体服务器成功处理了Alice的驻留(F14)。

      Bob对媒体服务器返回200 OK消息,并且确认了dialog的ID(F15),到此为止,Alice已经完全驻留在媒体服务器中。

      接下来,如果Carol想接听这个被驻留在服务器的Alice的电话时,Carol首先需要对媒体服务器发送订阅消息,否则,Carol不知道Alice电话的事件。因此,Carol对服务器发送订阅消息(F16):

      媒体服务器对Carol回复一个200 OK,获悉媒体服务器的支持能力等渲染标签(F17):

      有了新的事件以后,媒体服务器对Carol发送NOTIFY消息,通知Carol的事件具体消息内容(F18):

      Carol获悉被驻留方的地址信息后,对媒体服务器发送200 OK(F19):

      Bob通过媒体服务器发送到NOTIFY已经获得被驻留电话的地址信息,然后,为了接听Alice的驻留电话,Bob对Alice发送INVITE请求,并且要求替换媒体服务器的地址(Replaces,F20)。

      Alice接受了Carol的请求,对Carol返回200 OK(F21):

      然后,Carol对Alice继续发送一个ACK确认消息(F22),创建RTP流,双方开始正式通话,Carol接听被驻留的电话。

      然后,Alice必须对驻留服务器发送最后的通知消息(BYE,F23),表示Alice已经开始和Carol通话,驻留服务器和Alice的驻留关系释放。

      驻留服务器最后对Alice返回200 OK(F24),表示确认驻留关系释放:

      呼叫驻留到这一步,媒体服务器释放了和Alice的驻留关系,Alice通知了Bob,Carol接听了驻留电话。呼叫驻留的流程才真正完成。

      企业IPPBX基本上都支持了呼叫驻留/停靠的业务需求。IPPBX支持了多种驻留热键功能,用户可以通过热键功能来驻留呼叫或者重新被激活驻留的呼叫。在开源平台Asterisk(#72)或者FreeSWITCH(*5900)都有相应的设置,用户可以根据配置文件来实现电话驻留或重接被驻留的呼叫,另外,IPPBX用户也可以对驻留的空间进行管理,根据配置的不同,驻留空间可以支持很多个slot。还有,电话驻留的语音提示音也可以实现自定义功能,这样就可以方便地支持系统用户的操作。最后,电话驻留时长也可以通过配置文件来进行调整。FreePBX支持了电话驻留的界面配置,也支持了多种配置选项,用户可以参考其功能配置:

    16、Call Pickup

      Call Pickup, 我们称之为组内代答或者呼叫代答功能。一般情况下,如果是企业客户用户的话,每个部门的员工都有各自的分机。如果有人呼叫分机1,分机1如果没有应答的话,分机2看到分机1用户分机没有人应答,分机2用户可以通过热键来替正在振铃的分机1代接此呼叫。一般情况下,如果系统用户想替其他分机代接的话,这些分机必须在一个工作组或者根据业务类型分配的部门,同一组内用户可以互相代接其他用户的呼叫。

      组内代接的具体处理流程需要经过大概以上几个步骤。假设,Alice呼叫Bob,Bob没有应答此呼叫。和Bob同组的Bill想为Bob代接此呼叫。为了代接此呼叫,Bill首先需要对Bob发送订阅消息,通过订阅消息获取到Dialog消息内容。然后,根据获取的dialog消息内容,对Alice发送INVITE请求消息,替换Bob。Alice收到INVITE请求以后,然后对Bob分机发送一个CANCEL取消的消息,通知Bob分机停止振铃。这里读者要注意,对于F11和F12相关的顺序和200 OK(F10)它们之间是不确定的。

      在以上图例中的F7流程中,Replaces头中使用了一个新的参数“early-only”,这个参数可以防止接受一个Bob可能已经接受的INVITE请求。如果Bill已经准备从Bob那里代接此呼叫,无论Bill是否应答呼叫,参数“early-only”就将不会出现在F7的流程中。另外,读者需要注意一下Bob和Bill之间的订阅会话创建的时间问题。实际上,这个订阅会话可能已经存在于Alice呼叫Bob之前。这里的图例是为了表达方便,而显示在F3,Alice呼叫之后发生,实际上,Bob和Bill的订阅可能已经发生在Alice呼叫之前。

      另外提醒读者,根据RFC5359的描述,这里可能是拼写错误,把Bill说成了Carol。以上流程图中没有Carol。

      Also note that the subscription between Bob and Carol could have been

      established prior to Alice's call.

      关于"early-only”的规范定义,用户可以参考RFC3891,此规范完整介绍了Replaces和其参数的使用方式,以及如何检查INVITE重用。现在,我们结合具体的SIP消息,配合每一个处理流程来一步步说明组内代接:

      首先,Alice对Bob发送INVITE请求,要求和Bob进行通话(F1):

      接下来,Bob对Alice发送180 Ringing,Bob分机振铃(F2)。

      这时,因为Bob分机振铃,无人接听电话,Bill打算为Bob代接呼叫,Bill对Bob发送订阅消息来获取呼叫的dialog身份确认消息(F3):

      Bob收到Bill订阅消息,然后回复200 OK(F4):

      紧接着,Bob对Bill发送NOTIFY消息,包括了订阅消息的内容和Alice的相关消息信息(F5):

      Bill回复Bob收到了订阅的dialog消息内容(F6),准备对Alice发送INVITE请求。

      Bill对Alice发送INVITE请求,替换Bob,使用了early-only(F7):

      Replaces: 12345600@atlanta.example.com

      ;from-tag=314578;to-tag=1234567;early-only

      Alice收到Bill的INVITE请求,检查匹配Replaces头中的dialog,确认以后,接受了这个来自于Bill的INVITE,然后对Bill发送200 OK(F8):

      Alice接受了Bill的INVITE以后,Alice还要对正在振铃的Bob的分机发送一个CANCEL取消的回复,通知Bob分机停止振铃(F9):

      Bob收到CANCEL以后,停止振铃,然后对Alice回复200 OK(F10):

      然后Bob最后对Alice发送487 响应消息,表示对Bob的请求正式结束(F11):

      Alice对Bob发送最后确认消息ACK(F12),他们两个人之间的会话关系正式结束。

      Bill回复Alice发送的200 OK(F8)的ACK确认消息(F13),双方开始RTP语音流的传输,组内代接成功。

      经过一段时间通话后,Alice先挂机,对Bill发送BYE消息(F14):

      然后,Bill对Alice发送最后的200 OK(F15),双方通话结束。

      大部分的企业IPPBX都支持了组内代接功能。顾名思义,如果需要实现组内代接功能的话,用户首先需要创建一个呼叫组,组内成员则可以通过IPPBX的系统热键来代接电话。在asterisk或FreePBX平台上,用户可以按热键*8来实现代接功能。当然,其他平台也可以通过热键设置来接听代接电话。另外,用户可以通过比较灵活和人性化的设计可以支持代接成功或者失败的的语音提示,这样可以让用户获得更好的用户体验。

    17、Automatic Redial

      Automatic Redial,我们称之为自动呼叫重拨功能。简单来说,如果呼叫方呼叫被呼叫方时,对端如果处于忙状态或者其他状态,在一定时间后,呼叫方再次呼叫被呼叫方。具体的实现过程相对比较简单(查看以下图例)。

      假设,Alice呼叫Bob,这时Bob处于忙状态可能正在接听其他电话呼叫,Bob正在通话中。Alice呼叫后,对Bob发送一个订阅消息,对Bob分机状态进行订阅。当Bob处于空闲状态后,Bob对Alice发送一个提醒消息,通知Alice现在Bob分机处于空闲状态,可以对Bob分机进行呼叫。Alice收到这个提醒消息以后,结束对Bob的状态订阅,然后,Alice对Bob发送一个INVITE请求,对Bob进行呼叫,双方互相通话。

      下面,我们根据SIP消息内容,结合每一个具体的处理流程来进一步分析如何实现呼叫重拨功能。

      首先,Alice呼叫Bob,对Bob发送INVITE请求(F1):

      因为Bob此时正处于忙状态,所以,Bob回复Alice 一个486 响应消息(F2):

      Alice回复一个ACK确认消息(F3):

      为了获悉Bob分机的状态,Alice对Bob发送了一个订阅(F4),获取dialog消息内容:

      Bob回复Alice的订阅,回复200 OK(F5):

      Bob对Alice发送NOTIFY消息(F6):

      Alice回复200 OK(F7):

      Bob分机处于空闲状态,再次对Alice发送NOTIFY消息,提醒Alice现在Bob是处于空闲状态(F8)。

      Bob收到来自于Alice的提醒消息,Bob现在处于空闲状态,回复200 OK(F9):

      然后,Alice马上对Bob发送INVITE消息,进行呼叫请求(F10):

      因为Bob已经是空闲状态,所以接听了来自Alice的呼叫。对Alice返回180 振铃消息(F11):

      Alice然后返回200 OK(F12):

      紧接着,Alice对Bob发送一个ACK确认消息(F13),重拨呼叫接通。双方开始语音流传输(F13)。

      Bob再次对Alice发送NOTIFY消息(F14):

      Alice返回200 OK(F15):

      经过以上互相发送NOTIFY和确认消息,Alice已获悉对方状态,不再对Bob进行状态订阅,结束订阅,所以Alice对Bob再次发送订阅通知,结束对Bob的订阅(F16),重置Expire:0。

      Bob回复Alice 200 OK(F17):

      Bob对Alice发送NOTIFY消息(F18),订阅结束。

      最后,Alice对Bob返回200 OK响应消息(F19),订阅结束确认。

      在以上的订阅消息结束处理中,根据RFC6665的规范(4.1.2.3),取消订阅可以通过重设Expire头,设置expire:0 来通知取消订阅。根据规范的说明,成功取消订阅会再次触发一个最终NOTIFY消息(F18)。因此,读者不用对此产生误解。另外,我们这里没有涉及更多订阅的定时器刷新等问题,更多关于订阅的处理,读者可以查阅rfc6665来做进一步的学习。

      关于订阅功能使用方面,笔者建议读者在部署IPPBX和使用SIP终端时要慎用此功能。因为,一旦开启了订阅信息,IPPBX分机之间的订阅消息会生成大量的无效的数据,这样可能影响IPPBX本身的性能和企业内网的网络的稳定性,还有用户消息传送的时延,这样可能导致其他处理流程的错误。比如,如果Bob的终端对Alice发送了NOTIFY消息,通知Alice现在Bob处于空闲状态,Alice可以对其进行呼叫,但是,可能当前的Alice也正在处于其他的状态,可能没有可能再次及时对Bob发起呼叫,因此这个流程就会出现其他的问题。

      一些技术论文对消息导致的系统性能问题和网络优化做了讨论。Ahmadreza Montazerolghaem发表的论文关于重传机制优化的论文可能对读者有所帮助,大家可以参考这个方法来进一步优化自己的网络环境。

      The Overload Reduction in SIP Servers through Exact Regulation of the Retransmission Timer of the Invite Message

      Finnian McKeon 发表的论文中对SIP即时消息互发对网络影响数据流量的影响可以给我们提供一些参考建议,用户可以查阅研究。

      另外,Maria Isabel Pous在论文-SIP-based Applications in UMTS: A Performance Analysis也对SIP消息产生的影响做了深入的分析,读者可以查阅其论文作为参考资料。

    18、Click to Dial

      Click to Dial,我们称之为点击呼叫或页面点击呼叫。浏览器用户以插件的形式或者页面的形式通过浏览器访问点击界面。用户通过点击页面的一个SIP URL链接,页面点击呼叫消息传递给电脑SIP终端,终端配置了呼叫方的SIP URL地址,通过REFER发送SIP终端,然后SIP终端和被呼叫方创建一个会话连接,实现双方呼叫。

      这里的呼叫场景适合于简单的点对点的SIP呼叫场景。如果用户通过媒体服务器实现呼叫的话,处理流程和我们现在讨论的有所不同。具体的呼叫流程如下:

      现在,我们配合具体的SIP消息内容和每一个流程来简单说明点击呼叫的处理过程。

      首先,Bob的PC端SIP对BobSIP电话发送REFER消息(F1),这里的头域中设置了Refer-Sub:false,这表示PC端要求不生成REFER的dialog,仅支持2XX响应消息。关于Refer-Sub的使用方法和参数设置,读者可以查阅RFC4488。

      然后,BobSIP电话终端回复202 接受(F2):

      接下来,Bob对Carol发送INVITE请求消息,表示需要对Carol进行呼叫(F3):

      接下来,Carol对Bob SIP 电话回复180 振铃(F4):

      然后,Alice对Bob SIP电话回复200 OK(F5):

      接下来,Bob的SIP 电话回复ACK确认消息(F6),然后实现双方语音流传输。

      到此为止,整个点击呼叫的流程结束,双方开始电话互通。

      事实上,现在点击呼叫业务功能可以通过很多种方式实现,可以通过浏览器插件的形式实现,也可以通过HTML加脚本语言的形式实现,WebRTC或者邮件终端插件工具来实现。

      特别是基于开源软交换的平台,例如Asterisk/FreePBX或者FreeSWITCH都可以通过接口语言来开发更加灵活的点击呼叫功能。例如,通过脚本语言加Asterisk AMI接口实现的页面点击呼叫功能。用户可以下载以下代码来实现点击呼叫功能。以下是一个PHP的页面点击呼叫实例地址,读者可以参考:

      https://github.com/spbx/Simple-Click2Call-for-Asterisk-PBX/blob/master/click2dial.php

      基于Asterisk的点击呼叫的插件,用户可以参考TBDialOut来实现,开源项目地址:

      http://www.oak-wood.co.uk/tbdialout/

      19、总结讨论

      笔者根据RFC5359,结合一些具体的图例非常系统地讨论了最常用的18个SIP呼叫流程的具体细节。在每一个细节中,笔者增加了一些相关的讨论,帮助读者能够更加全面地了解部署使用时的问题和风险。笔者再次强调,这18个SIP呼叫业务是一个规范流程,不一定是强制执行的标准,特别是涉及到Proxy的内容,读者一定要注意。不同的Proxy或者媒体服务器可能对流程的处理有所不同,读者需要根据自己的部署平台来对照检查。整体而言,通过这18个完整的SIP呼叫业务细节讨论,笔者为提供SIP呼叫业务的技术人员提供了相对比较完整的学习资料和比较权威的参考,希望对大家有所帮助。

      另外,因为笔者水平和资源有限,肯定有很多错误之处,敬请谅解。

      参考资料:

      https://tools.ietf.org/html/rfc4579

      https://www.rfc-editor.org/rfc/rfc5359.txt

      https://tools.ietf.org/html/rfc7088

      https://www.rfc-editor.org/rfc/rfc3515.txt

      https://tools.ietf.org/html/rfc3840

      https://tools.ietf.org/html/rfc3891

      https://www.rfc-editor.org/rfc/rfc6665.txt

      http://file.scirp.org/Html/1-1730003_32286.htm

      https://arrow.dit.ie/cgi/viewcontent.cgi?

      referer=https://www.google.com/&httpsredir=1&article=1005&context=ittscicon

      http://www.cs.columbia.edu/~nahum/papers/sip-multicore-journal.pdf

      https://support.sonus.net/display/SBXDOC51/GRUU+Support

      https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-99.html

      www.freepbx.org.cn

      https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/MOHParkServer/doc/MOHParkServer_User_Documentation.pdf?revision=8937&view=co

      http://ijsetr.com/uploads/463152IJSETR13872-273.pdf

      https://tools.ietf.org/html/rfc3665

      https://tools.ietf.org/html/rfc3265

      https://tools.ietf.org/html/rfc3515

      https://tools.ietf.org/html/rfc4317

    展开全文
  • 基于单片机的病房呼叫系统设计说明.doc
  • 基于PLC的病床呼叫器控制系统设计34986.doc
  • 人工智能-机器学习-智能呼叫流量控制与检出.pdf
  • ip冲突引起呼叫故障的问题处理过程

    千次阅读 2021-11-13 21:29:29
    本文介绍一次呼叫故障的处理过程,ippbx下挂iad存在ip冲突,导致ippbx发包mac错误引起故障。涉及wireshark的应用技巧,sip的流程和定时器,arp缓存更新机制等知识,也有常规处理问题的思路和步骤供大家参考。

          一次领导让去贵州六盘水,去帮办事处解决一个公司ippbx的呼叫故障问题,说问题已经反馈处理一个月,工程和研发多次处理都没定位,现场意见很大,再不解决,用户要拆设备了。研发这边不派人去,可能会造成当地办事处不满,我们研发要派人到现场给个认真处理的态度。于是很忐忑的被派去,想这是一个擦屁股,背锅的差事,我就是一个测试维护人员9527,这是什么套路?

        飞到贵阳和办事处人员汇合,了解基本情况如下:

        六盘水监狱,iad+ippbx+ims组网,反馈问题是打入打出多次尝试才能成功,重启后能正常一段时间。有时打出提示线路忙,再次尝试能成功。

    ip配置:共27个iad,ip从172.31.234.51到172.31.234.77

    wan的ip是10.8.64.252./24

    imp:172.31.234.220,wan口10.8.64.252,网关:10.8.64.1

    主用ims:221.13.5.226     备用ims:221.13.4.174

    号码:本地小号:1,3,5,7,8,9打头四位号长

    公网号码:085881649百号段,ims注册和呼叫使用+868581649xxx

      

     根据组网确定定位方法:

    1、去现场了解故障的范围,发生的有啥共性和规律性?

    2、根据反馈情况进行抓包跟踪,确定是否有sip信令表项,根据信令表项排查故障。

    排查过程:

            到监狱后,了解到是一个新建监狱,还未正式使用,监狱办公楼和岗亭,生活区,监狱内部通过光纤组网,用iad接入模拟电话,对接ippbx后,接入联通ims。办公楼区域反馈故障多,主要是不能呼出,一会能正常一下。

           决定先抓包,看一下是否有信令的表现?

           公司的ippbx上有一个信令和业务处理板名称是imp板,硬件是一个四口千兆网卡百兆snmp的嵌入centos6.5的板卡,它的eth2上有172.31.234.220这个ip地址,作为信令和语音rtp的ip,用于下联iad。eth3是运营商的内网地址10.8.64.252./24用于上联ims。iad用分机注册到imp板,imp记录分机注册的ip地址和号码。imp用eth3的地址和公网号码向ims注册。分机呼出公网号码时,iad发出消息到imp,携带注册时的分机号码作为主叫,imp上有公网号码和分机对应关系,相当呼出做nat,主叫号码由分机转换为公网号码用wan口ip发给ims。由公网的呼入,eth3接受消息,被叫是ippbx在公网的注册号码+8685881649xxx,反向查nat公网号码和分机对应关系,被叫公网号码转换i内网分机短号,imp用eth2,给对应iad的ip发出呼叫消息。内部分机互打时,主机iad发消息给imp,imp再查被叫分机注册时的对应ip地址,再把消息转给被叫的注册ip地址。

    1、串口上去,给imp板的snmp添加ip地址,用于ssh访问和抓包。

     

    考虑现象不是一直有,为不遗漏现象,采用多文件抓包的方法,让wireshark自动记录,自动打包。便于后面分析。

    2、利用rpcapd进行抓包,先抓一下eth2,多文件抓包,每50M自动打包一个。

     3、抓包后,对语音的voip进行分析,发现有一些呼叫失败,被叫号码是1028,1032。

     发现是业务板imp172.31.234.220的ip地址发给iad172.31.234.66时被拒绝了。看一下这个ip的iad

    是否有啥问题?

    登录172.31.234.66发现上仅仅配置一个号码9005,那为什么imp会把1032,1028的呼叫指向iad66呢?

    imp会记录分机注册成功时,携带的ip地址,有呼叫会发给这个地址,难道1032和1028也用这个ip注册过,但为啥有时会拒绝呼叫?环境中存在两个172.31.234.66的ip地址?

    4、怀疑系统中存在两个172.31.234.66,让在另一台pc上cmd模式下ping 172.31.234.66,然后arp –a显示mac缓存表。Linux下ping 172.31.234.66 –c 10,arp –n显示mac表,对比两个mac地址是否一致?

    imp板上的ping后显示:

    对应mac地址00:0e:5e:55:4e:86

    而另一台pc上ping后,显示的mac地址为00:0e:5e:58:d2:49。两个mac地址不一致,telnet逐个检查每个iad的配置,登陆172.31.234.66时发现它有这个mac地址。检查留存的ip地址配置文件表,发现有两个 iad的ip为172.31.234.66(分别为备勤楼,号码为1001到1034,另一个是计划岗楼4,号码仅一个9004)。判断分配ip时,没有留心,把ip地址分重了!

    5、去岗楼不方便,备勤楼外部人员可以进入,决定把备勤楼的ip进行修改为172.31.234.75后,观察一天再未出现此类故障。

    确定是ip冲突导致的问题。到现场一个小时找到故障,松了口气,锅不用背了。办事处的运营商的很满意,说监狱在郊外20公里山里,一个月间,来回多次都没解决问题,今天这么快就找到问题,释然了。

    三楼机房看看监狱的外层五米高墙,上面有铁丝网电网和岗楼,里面还有一圈铁网隔离墙,上面是有刀片式铁丝网,看得人心悸,问监控室的,说出大门得三道门,三个干警掌管钥匙,没有人配合,逃出概率为0。看围墙内犯人排队吃饭,还有朗朗的读英语声,犯人还学英语,不错。

    ip冲突导致sip信令故障原因分析:

         观察期间,对问题进行分析,呼叫一会好,一会不行,感觉imp上一回发给了正确的172.31.234.66的mac地址,一会发给了错误的mac地址,于是过来arp和sip消息。

         过滤:(sip  && ip.addr==172.31.234.66) ||  arp  contains  ac1f-ea42  arp过滤的是消息里包含ip 地址172.31.234.66的包。

    为了wireshark方便查看,调整wireshark的列显示edit→preference→columns

    内部小号为1001到1032的iad备勤楼对应iad的mac00:0e:5e:55:4e:86,计划岗楼iad的mac00:0e:5e:58:d2:49,仅分配一个号码9004。

    发现有这四种情况:

    1、当有呼叫1001到1032其中的一个号码的呼叫时(内线或外线呼叫),此时linux里的mac表被更新为错误的mac,导致invite消息发向了错误iad,这个iad上没有这些号码,直接回600,服务器忙,呼叫失败。

     

     

    上图中淡黄色的是arp单播探查消息,这是imp的缓存里还是错误的mac,arp单播probe探查消息,依然是错误的iad给的响应,导致arp缓存的定时器被恢复到reachable的状态。下一一次还是发给错误 iad。

    2、当1001至1032的用户主动发起呼叫时,imp的缓存只有arp的请求imp的地址或者有对你imp发出arp请求作出响应时才被修改,imp板回的100trying发向了错误mac地址上,由于没有收到100trying,源iad在0.5,1,4秒后重发invite。

    3、当正确mac的iad发出arp单播探查请求的imp板上时,imp会更新缓存中的mac值,imp消息发到正确iad上,通话能正常。

     

     

     172.31.234.220 is at 00:0e:5e:34:8e:29 (duplicate use of 172.31.234.66 detected!) 

    4、超时重复发invite在隔四秒重发前,正确的iad发出单播arp探查消息,更新了mac地址缓存,imp把后向183消息,发给了正确的iad,呼叫流程正常走下去

    结论:mac更新正常后,呼叫会成功,但当错误mac被更新到缓存中,呼叫会失败。

     总结:

    呼入呼出故障系两个iad的ip配置成了172.31.234.66,导致imp板的arp缓存有时被更新为错误的mac地址,当由ims呼入的电话到imp,imp板把invite消息转到错误的mac地址的iad上,iad没有配置相应的号码,回600全局忙,导致呼叫失败。正常的iad呼出时,imp发的100try发到了错误的mac地址上,导致iad超时重发invite,最后呼叫失败。

     要点:

    1、arp缓存要在收到设备发出arp请求或者回答本机的arp请求后才会被更改。

    2、处理问题时,要关注mac地址的变化。

         

    展开全文
  • 雅辉呼叫

    2013-01-28 21:58:28
    雅辉呼叫器YHA-918主机说明书.雅辉呼叫器YHA-918主机说明书
  • PLC技术
  • 在大部分的企业客户的电话呼叫业务中,特别是从运营商到企业IPPBX端的呼入业务中,有很多不同的呼叫涉及了多种SIP流程的操作,而且其流程和实际的IPPBX,代理和SIP终端存在着非常密切的关系。排查这些技术问题耗费...

    目录

    1、Call Hold

    2、Consultation Hold

    3、Music on Hold

    4、Transfer - Unattended

    5、Transfer - Attended


      在大部分的企业客户的电话呼叫业务中,特别是从运营商到企业IPPBX端的呼入业务中,有很多不同的呼叫涉及了多种SIP流程的操作,而且其流程和实际的IPPBX,代理和SIP终端存在着非常密切的关系。排查这些技术问题耗费相当多的时间。另外,因为越来越多的用户开始使用基于开源的软交换平台和媒体服务器(例如,Asterisk或FreeSWITCH,Kamailio等),用户更容易获得技术产品,因此,他们更容易接触到企业通信平台技术,导致其入门门槛也相对比较低,技术人员可能完全不了解系统底层的流程。而且不幸的是,在实际使用过程中,很多技术人员也仅仅停留在通过系统界面配置一个呼叫业务流程,他们根本没有了解和关注真正底层的呼叫流程和其细节,而且他们对真正的SIP消息之间的互相通信过程可能并不是非常熟悉。笔者发现,其中一个原因是他们没有太多学习渠道获得一些非常直观和权威的可参考的示例。

      大家经常谈论SIP呼叫业务,但是,究竟哪些SIP呼叫业务是企业用户所要求的? 关于SIP业务呼叫,RFC5359对18个最常用的SIP业务呼叫流程给出了完整的SIP流程图例,这些呼叫业务为企业用户解决方案部署提供了一个比较权威的参考。因此,笔者希望通过此文章完整列出所有18个关于SIP呼叫业务的SIP流程和其相应的图例说明,并且加以适当讨论和说明来解释这些呼叫功能中可能出现的问题或部署时应该注意到地方,以便帮助技术人员或者销售工程师能够对其产品或者周边应用终端有一个完整的比较深入的理解。提醒大家,笔者的解释和图例介绍仅针对标准的SIP流程来加以说明,完全以RFC5359为基础,不会涉及其他的设备,可能有时结合开源媒体服务器,软交换的功能加以说明是为了方便用户理解和实践。

      在关于SIP呼叫服务的规范协议RFC5359中,对其18个SIP呼叫流程做了完整的流程示例演示。当然,RFC5359定义的这18个示例不是一个规范标准,这18个SIP呼叫业务仅表示根据RFC5359作者建议的最常用的18个呼叫业务,不是一个强制执行的要求。这18个最常用的SIP呼叫业务功能包括:

    1. Call Hold
    2. Consultation Hold
    3. Music on Hold
    4. Transfer - Unattended
    5. Transfer - Attended
    6. Transfer - Instant Messaging
    7. Call Forwarding Unconditional
    8. Call Forwarding - Busy
    9. Call Forwarding - No Answer
    10. 3-Way Conference - Third Party Is Added
    11. 3-Way Conference - Third Party Joins
    12. Find-Me
    13. Call Management (Incoming Call Screening)
    14. Call Management (Outgoing Call Screening)
    15. Call Park
    16. Call Pickup
    17. Automatic Redial
    18. Click to Dial

      下面,我们对这18个最常用的SIP呼叫业务分别加以解释。另外,在所有的示例中,有几个专有说明需要提前解释:

      图例中所列举的假设用户是Alice,Bob,Carol

      100 Trying没有显示

      Via和Max-Forwards头没有显示

      From,To,Call-ID,Cseq,Contact,Route和 Record-Route和其他的头依赖于实际案例

      图例中使用假设域名来说明用户域名,例如,atlanta.ex.com, biloxi.ex.com和chicago.ex.com

      Tag和Call-ID替换为响应的用户关联的设置方式

      RFC5359中可能存在的描述错误,请用户和官方核实

      SIP呼叫业务的中文名称是笔者自己翻译,非任何官方翻译定义。因此,中文名称的准确性有待用户自己确认

    1、Call Hold

      Call Hold,此呼叫业务称之为呼叫保持。呼叫保持的流程实现需要经过几个步骤来完成。以下是RFC5359中的呼叫流程图例(25个flow):

      这里假设,Alice呼叫Bob,呼叫接听后,Bob通过终端电话按键Hold键把呼叫设置为保持状态。然后Bob解除呼叫保持状态,Alice挂机。注意,呼叫保持事实上是一个单向的功能。但是,执行保持的一方可以对第三方停止媒体发送,这样可能导致双方无媒体流交互。旧的处理方式是连接到地址0.0.0.0。现在新的处理方式是在SDP的a=中实现,a=inactive 表示无媒体发送;a=sendonly 表示仍有媒体发送。

      注意,在F10和F11中使用了渲染功能tag(rfc4235)来表示Bob终端不再渲染,例如Bob已经设置为保持状态。下面,我们通过完整的流程图附带SIP消息的说明来具体介绍呼叫保持的流程。

      Alice对P1发出INVITE请求,然后通过P1呼叫Bob。

      Bob呼叫振铃,Alice振铃(F4,F5):

     

      Alice收到 200 OK(F6/F7)消息:

      Alice发送到ACK确认信息到P1(F8),然后P1发送到Bob(F9)的 流程。

      Bob对P1发出INVITE消息执行F10,然后,P1对Alice发出INVITE消息执行F11。这里,开始双方正式进入呼叫保持状态。读者要注意, 结合我们开始时说明的,Bob使用了渲染 tag,并且o= 的version是增加的。前面在F6,F7时仍然是2890844527,这里已经增加到了2890844528。因为是一个RE-INVITE携带了a=sendonly。

      Alice接受了呼叫保持请求,并且回复200 OK(F12, F13),在SDP中携带了a=reconly。

      Bob回复ACK消息(F14/Bob->P1,F15/P1->Alice)。

      Bob关闭呼叫保持状态,用户通过按键Hold再次关闭保持功能。RE-INVITE中的SDP没有包括a=sendonly。执行F16(Bob到P1),F17(P1到Alice)流程。

      Alice回复200 OK,发送的消息中没有带SDP的a=reconly。执行F18(Alice->P1),F19流程(P1->Bob)。

      Bob回复ACK,执行F20(Bob到P1),F21(P1到Alice)流程。他们之间重新创建RTP媒体流。

      Alice发送BYE消息到P1,P1发送BYE消息到Bob,执行流程F22和F23。

     

      然后各自发送最后的200 OK,执行流程F24(Bob到P1),F25(P1到Alice)。

      到此为止,整个呼叫保持流程结束。

    2、Consultation Hold

      Consultation Hold,我们称之为持入呼叫保持或者驻留呼叫保持。呼叫方A呼叫被呼叫方B以后,被呼叫方B将通话设置为呼叫保持状态(通过终端的Hold键),然后被呼叫方B再呼叫其他第三方呼叫方C。B挂机以后,重新对被设置为呼叫保持的呼叫方A进行操作,呼叫方A关闭呼叫保持,然后呼叫方A挂机。其流程经过38个呼叫流程的处理。



      这里,读者一定要注意,驻留呼叫保持和电话转接的区别。电话转接(transfer)从概念上我们就可以识别清楚,在呼叫流程中涉及了转接方或者中间方。而驻留呼叫保持中的中间方完全没有介入其他两个被呼叫方,他们都是各自独立的呼叫。例如,在以上的图例中,Alice呼叫Bob,Bob呼叫Carol。Carol和Alice没有任何直接呼叫关系。下面,我们通过完整的流程讨论分别说明这38个呼叫流程的处理方式。

      驻留呼叫保持同样在F10的流程中使用了渲染tag来表示开启驻留呼叫保持状态。事实上,从呼叫业务流程的控制来说,驻留呼叫保持相对于呼叫保持,处理流程更加简单。Alice到P1的F1,P1到Bob的F2呼叫流程,发起INVITE消息。

      双方终端振铃,经过F4,F5处理流程。这里忽略了F3(Proxy到Alice的100 trying)。

      Bob对Proxy执行的F6,Proxy执行Proxy到Alice的F7呼叫流程。Bob对Proxy发送200 OK,Proxy对Alice发送200 OK。

      Alice到P的ACK消息,和P1到Bob的ACK消息,执行流程F8,F9。

      开启RTP媒体流,然后Bob发送INVITE到P1,P1发送INVITE到Alice,执行F10,F11流程,并且表示开启呼叫保持状态,使用了渲染功能表示保持状态启用。

      Alice对Proxy发送 200 OK(F12),带SDPa=reconly, 接受保持状态。Proxy发送200 OK到Bob,执行F13流程。

      Bob对Proxy发送最终ACK确认,执行F14;Proxy对Alice发送ACK确认消息,执行F15流程。至此,呼叫保持状态开启(Bob/Alice之间)。

      Bob呼叫Carol。Bob对Proxy发起INVITE消息(F16),Proxy对Carol发送INVITE消息(F17)。

      这里,忽略了F18(100 trying)。Carol 对Proxy发送 180 振铃(F19),Proxy对Bob发送180振铃(F20)。

      执行对INVITE确认流程。Carol对Proxy发送200 ok(F21),Proxy对Bob发送 200 ok(F22)。

      双方最后发送ACK确认信息。Bob发送ACK消息到Proxy(F23),Proxy发送ACK到Carol消息(F24)。双方开始媒体流互通。

     

      经过双方电话互通以后,Bob首先挂机,对Proxy发送BYE消息(F25),然后Proxy对Carol发送BYE消息挂机(F26)。

      对此次呼叫进行最终确认挂机。Carol对Proxy发送200 OK(F27),Proxy对Bob发送200 OK(F28)。到此为止,Bob和Carol的呼叫正式结束。

      现在开始重新开启对Alice的呼叫保持状态。重新发送INVITE消息。Bob对Proxy发送INVITE消息(F29),Proxy对Alice发送INVITE消息(F30)。

      接下来对INVITE进行确认。Alice对Proxy发送200 OK,接受INVITE。Proxy对Bob发送200 OK。

      Bob收到200 OK以后,对此次INVITE发送最终确认的ACK消息。Bob对Proxy发送ACK(F33),然后Proxy对Alice发送ACK(F34)。确认完成后,双方开始媒体流互通。

      双方完成呼叫以后,Alice发送对proxyBYE消息(F35),Proxy对Bob发送BYE消息(F36)。

      最后,确认双方的BYE消息,互相发送最后的200 OK。Bob对Proxy发送200 OK(F37),Proxy对Alice发送200 OK(F38)。到此为止,整个驻留呼叫保持的处理流程正式结束。

    3、Music on Hold

      Music on Hold(MoH),我们称之为呼叫音乐等待或者音乐等待。顾名思义,就是在等待过程中同时对等待方播放音乐媒体或者语音提示。通过音乐等待的方式会增加用户的体验,让用户不再感觉等待时间的烦躁。RFC7088 专门定义了语音等待的规范。IPPBX的功能热键可启用MoH功能。

      音乐等待具体的实现方式是,当呼叫方(Alice)呼叫被呼叫方(Bob)后,接听以后,被呼叫方用户(Bob)设置此呼叫为等待状态,在等待状态时,通过媒体服务器对呼叫方播放音乐,或者其他的自定义的语音流。被呼叫方通过对媒体服务器或者音乐播放服务器发送一个REFER消息,携带呼叫方信息。然后媒体服务器对呼叫方发起INVITE,替换已经创建的会话中的被呼叫方。然后,媒体服务器对被呼叫方(Alice)发送音乐媒体流服务。一定时间后,Bob重新设置等待的呼叫,对呼叫方(Alice)发送INVITE消息,然后替换会话中的媒体服务器,变成Bob和Alice之间的通话。注意,这里仍然使用了渲染功能,但是在F5流程中实现,表示其等待状态开启。如果Alice拒绝对端的音乐播放,则Alice仍然会处于等待功能,但是会是静音状态(无声音)。


      通过以上呼叫流程我们知道,完成音乐等待流程处理需要23个flows。其中,F5开启音乐等待功能,F12开始媒体服务器替换了Bob,媒体服务器对Alice发送音乐数据流确认。在F12的流程中使用了渲染功能,增加了对automation和byeless功能标签的支持。关于automation tag 的功能在rfc3840中定义,关于byeless tag 的支持在rfc4235中定义。rfc3840定义了媒体服务器的能力支持,rfc4235定义了自动对话事件包管理机制。具体的细节读者可以参考链接资源。以下是一个完整的音乐等待的呼叫流程,配合了SIP消息。我们根据此图例来进一步说明具体的呼叫流程。

      首先是Alice对Bob发送INVITE消息(F1),表示要对Bob进行呼叫。

      Bob对Alice发送180 振铃消息(F2):

      紧接着,Bob对Alice发送200 OK消息(F3):

      Alice对Bob发送确认ACK(F4),开始语音流传输通话。

      之后,Bob把Alice呼叫设置为音乐等待。Bob重新发送一个新的INVITE携带了SDP,并且包含了一个a=sendonly,表示等待开启。执行F5流程。

      然后,Alice回复Bob 200 OK消息(F6),在SDP中增加了a=reconly 表示接受等待。

      Bob回复Alice确认ACK,无RTP语音流。此时,Bob准备开始执行音乐媒体流服务。

      Bob对媒体服务器发送REFER消息,通知媒体服务器使用Alice替换Bob。

      媒体服务器对Bob发送202 消息,表示接受这个请求(F9)。

      然后媒体服务器发送NOTIFY消息(F10):

      Bob发送200 OK(F11):

      接下来,媒体服务器对Alice发送INVITE消息,替换Bob(F12),注意这里的SIP消息中增加了渲染功能的支持,包括automation和byeless功能标签,需要启用事件包处理,媒体服务器能力支持等渲染功能。

      以上图例中没有显示contact中的渲染功能标签,但是在RFC5359中的音乐等待(F12)中的消息细节是:

      F12 INVITE Music Server -> Alice

      INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0

      Via: SIP/2.0/TLS server.example.com:5061

      ;branch=z9hG4bK74rf

      Max-Forwards: 70

      From: <sips:music@server.example.com>;tag=0111

      To: <sips:a8342043f@atlanta.example.com;gr>

      Call-ID: a5-75-34-12-76@server.example.com

      CSeq: 1 INVITE

      Referred-By: <sips:bob@biloxi.example.com>     Contact: <sips:music@server.example.com>;automaton

      ;+sip.byeless;+sip.rendering="no"

      Require: replaces

      Replaces: 12345600@atlanta.example.com

      ;from-tag=23431;to-tag=1234567

      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

      Supported: replaces

      Content-Type: application/sdp

      Content-Length: …

      Alice接受媒体服务器的请求,对媒体服务器发送200 OK(F13):

      媒体服务器收到200 OK以后,对Alice发送确认ACK消息(F14),然后对Alice发送音乐媒体流,Alice现在可以听到媒体服务器对Alice播放的音乐文件。

      因为已经播放媒体流流程开始,Alice对Bob发送BYE消息(F16):

      Bob接受来自于Alice的BYE消息,对Alice发送200 OK(F16)。

      媒体服务器对Bob发送NOTIFY消息(F17),表示媒体播放成功,并且包含一个200 OK的响应消息。

      Bob对媒体服务器响应了一个200 OK(F18),表示收到此提示,同时包含了dialog的确认内容,包括了REFER需要的call-id,to tga和from tag。

      到此为止,Alice被完全驻留在媒体服务器的会话中。接下来,Bob可能需要重新接听Alice的电话,那么,Bob就会重新对Alice发送INVITE请求消息(F19),然后替换会话中的媒体服务器。

      Alice对Bob回复200 OK消息,表示接受替换,重新恢复到通话状态(F20)。

      Bob最后对Alice回复确认ACK(F21),可以恢复正常通话状态。

      双方通话以后,因为媒体服务器仍然和Alice有会话的绑定关系,因此为了结束媒体播放,Alice仍然需要对媒体服务器发送一个BYE消息,表示音乐等待播放结束(F22):

      媒体服务器收到200 OK以后,对Alice发送一个最后的200 OK(F23),告知媒体服务器已经收到Alice的响应,媒体服务器正式释放被驻留在媒体服务器的会话,解除Alice对媒体服务器的绑定关系。Bob和Alice的正常通话才算成功完成,双方开始正式的通话过程。

      在音乐等待的处理流程中使用了REFER的method来帮助处理音乐等待,具体的RFER规范在RFC3515中定义,读者可以查阅学习。

      我们的讨论中使用了一般的IPPBX媒体服务器来替换音乐媒体服务器,用户也可以通过第三方的音乐服务的服务器端来处理音乐文件,用户使用过程中可能可以获得更多的体验。另外,很多媒体服务器也可以对其播放文件实现自定义处理。例如,在Asterisk/FreePBX或者FreeSWITCH开源平台都可以通过修改配置文件来实现自定义的MoH文件支持。

      在上面的讨论中,我们仅根据呼叫流程的正常状态说明的整个MoH的处理过程。实际上,在MOH的实际部署过程中,读者会遇到很多的其他的技术问题。例如,播放文件的格式支持问题,终端兼容性问题,语音播放的带宽消耗问题,音乐播放的服务会话的管理问题,回复消息失败问题等。所以,一般的MoH功能仅在内网环境下使用一般不会出现太多问题。但是,如果通过第三方的媒体平台提供所谓比较灵活的媒体播放业务,读者一定要注意以上问题。

    4、Transfer - Unattended

      Transfer - Unattended或者Blind Transfer,我们称之为呼叫盲转功能。呼叫盲转简单来说,就是A呼叫B,然后B把A转接到C,B挂机。A会对B报告一个NOTIFY消息,表示成功转接。如果转接C失败,A会对B重新创建INVITE请求。以下是一个盲转呼叫示例流程图:

      另外读者一定要注意,尽管被呼叫方发送了BYE消息(F9),但是Alice和Bob之间的Dialog仍然存在,这个dialog结束是根据REFER创建的订阅来决定的。订阅的NOTIFY中包含订阅状态的结果消息或者NOTIFY响应的481:

      F15 NOTIFY Bob -> Alice

      NOTIFY sips:alice@client.atlanta.example.com SIP/2.0

      Via: SIP/2.0/TLS client.biloxi.example.com:5061

      ;branch=z9hG4bKnashds67

      Max-Forwards: 70

      From: Bob <sips:bob@biloxi.example.com>;tag=314159

      To: Alice <sips:alice@atlanta.example.com>;tag=1234567

      Call-ID: 12345601@atlanta.example.com

      CSeq: 3 NOTIFY

      Event: refer      Subscription-State: terminated;reason=noresource

      Contact: <sips:bob@client.biloxi.example.com>

      Content-Type: message/sipfrag

      我们会根据以上图例,结合具体的SIP消息和每个呼叫流程做进一步的介绍。

      首先,Bob呼叫Alice(F1):

      然后Alice对Bob回复一个180 振铃(F2):

      紧接着,Alice继续对Bob发送一个200 OK(F3):

      Bob对Alice发送ACK确认消息,然后双方执行RTP媒体流交互,开始通话。

      通话后,Alice需要把Bob电话转接到Carol第三方(F5):

      Bob对Alice回复202 Accepted(F6):

      然后Bob对Alice发送NOTIFY(F7),创建订阅消息包:

      Alice收到NOTIFY以后,回复200 OK(F8):

      紧接着,Alice会继续对Bob发送一个BYE消息(F9):此时RTP媒体流已经中断,双方不再继续通话。

      Bob也根据收到的BYE消息,对Alice发送一个200 OK消息(F10),到此为止,双方语音完全断开。根据我们上面的讨论,事实上,双方仍然存在一个订阅关系,因为电话转接(Bob被转接到Carol)是否成功仍然没有进行最后的确定。接下来,Bob电话被转接到Carol。呼叫流程开始执行真正的电话转接流程。

      根据以前的REFER消息,Bob对Carol发送INVITE消息,并且携带了“refer by” 的消息,说明来自于Alice的转接(F11):

      Carol然后对Bob发送180振铃(F12):

      紧接着,Carol对Bob发送200 OK(F13):

      Bob收到200 OK以后,发送ACK确认(F14),双方正式开始通话。

      现在,为了保持订阅关系的一致性,Bob需要给Alice发送一个NOTIFY(F15),通知Alice,Bob和Carol转接成功,可以正常通话。这里,也可能Alice忽略这些订阅消息。

      Alice最后发送200 OK(F16),Bob和Carol进行通话。

      通过16个流程的处理,一个完整的盲转才可以完成。很多IPPBX或者媒体服务器(Asterisk/FreePBX/FreeSWITCH)都支持Blind transfer的功能热键。用户也可以通过SIP电话终端屏幕上的按键来实现转接。

      例如,在示例的呼叫中,Bob呼叫Alice,Alice就可以通过功能热键实现电话转接功能。例如,在asterisk中定义的盲转方式:

      [featuremap]

      blindxfer = #1 // FreeSWITCH使用*1实现盲转。

      atxfer = *2 // FreeSWITCH使用*4实现询转。

      很多情况下,电话转接失败的概率很高,因为有可能第三方处于接听状态,有可能不在线等问题,或者DTMF设置不当,转接失败。这些问题用户都需要通过配置IPPBX来进行妥善处理。

    5、Transfer - Attended

      Transfer - Attended,我们称之为呼叫询转。简单来说,Alice呼叫Bob,通过通话,Alice可能需要把电话转接到Carol,然后Bob把Alice设置为等待状态。Bob继续呼叫Carol,同时对Carol说明Bob需要把电话转接给Alice。同时,Bob与Carol的通话接通后,替换双方之间的会话。Carol然后对Bob挂机。然后Alice对Bob发送一个报告,说明Alice和Carol的电话转接已经成功。然后Bob对Alice挂机。

      通过上面的介绍,读者可能已经发现,Transfer-Unattended(Blind Transfer)和Transfer-Attended之间有所不同的。最大的不同之处在于盲转过程中,电话转接到终端不会询问第三方是否可以转接,不关心转接到第三方是否同意或者接受这个电话转接(所以称之为“盲”)。而询转则有所不同,它和会转接到第三方提前询问,是否接受这个电话的转接,然后再进行电话转接流程(所以称之为“询”)。

      另外,在上面的例子中,Bob插入了Replace 头 Refer-To URL。具体的Replace 头的规范,读者可以参考RFC3891。注意,Refer-To URL是一个Contact URL,它是询转接受方(Carol)在F10中返回的200 OK响应消息中的Contact URL。这样可以保证正确的Carol的URL可达。在F10流程中,Contact URL中的参数gr表示Contact URL是一个GRUU,它表示是一个dialog之外的全球路由方式(RFC5627)。

      GRUU具有以下几个特征,首先,它定义了指定的具体的用户代理。其次,从理论上来说,可以支持全球路由方式。最后,它的存活周期很长。我们简单查看一下关于GRUU的使用方式。如果支持了GRUU的SIP终端登录的话,其请求可能被复制出几个不同的终端设备地址。

      但是,如果对某一台指定的设备发送请求消息的话,请求消息会根据不同的设备URL来发送,它会专门发送到指定的终端设备,例如,sip:user@domain;opaque=user:epid:UghFocauauCHBHoLhAAA;gruu

      发送到其他终端以后,那么,其他的设备就不会收到这个请求消息。

      在一些关于SIP的其他应用中,例如SBC的部署环境中,GRUU也支持了公开的GRUU和临时的GRUU,区别在于其存活周期的设定不同。具体的语法示例如下:

      pub-gruu=" Sip:userA@home.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

      ;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@home.net;gr";

      在询转过程中,如果示例中的Bob不知道Contact URL中的gruu,Bob必须自己修复这个问题。如果触发的INVITE失败,Bob必须重新使用refer带Refer-To URL来连接Carol,但是需要支持另外一个要求条件,Replace头中必须弃用Refer-To头。


      以上是关于电话询转到呼叫流程图,处理过程需要27个具体的步骤。现在,我们配合详细的SIP消息来进一步解释以上流程。

      首先是Alice对Bob发起INVITE请求,进行呼叫(F1):

      然后,Bob对Alice发送180 振铃(F2):

      紧接着,Bob对Alice发送 200 OK(F3):‘’

      Alice对Bob发送ACK确认消息(F4),双方呼叫接通。

      Bob对Alice发送INVITE消息,开启等待状态(F5)。

     

      Alice对Bob发送200 OK(F6):

      Bo对Alice发送ACK确认(F7):

      然后,Bob对Carol发送INVITE请求消息,要求完成Alice的电话转接:

      Carol回复Bob一个180振铃(F9):

      紧接着,Carol回复Bob一个200 OK(F10)。注意,这里的参数已经增加了一个gruu。

      Bob对Carol回复了一个ACK确认消息(F11),开始媒体流。

      经过Bob和Carol通话以后,Bob告诉Carol,Alice想和Carol直接通话,Carol同样和Alice通话。Bob将此通话设置为等待状态,邀请Alice和Carol通话。

      Carol对Bob发送200 OK(F13):

      Bob收到Carol的ACK消息(F14),Bob和Carol最终确定转接。

      然后Bob对Alice发送REFER消息,开始通知Carol的地址:

      Alice收到202 接受消息(F16),表示接受这个转接。

      紧接着,Alice继续对Bob发送NOTIFY消息(F17),通知Bob一个订阅事件,告知Alice电话转接的流程处理状态。

      Bob收到Alice 200 OK(F18):

      获悉了Bob已经知道订阅事件以后,Alice开始对Carol发送INVITE请求(F19),并且替换了Bob。

      Carol对Alice 发送200 OK(F20):

      然后,Alice对Carol发送ACK确认消息(F21),开始RTP语音流,转接完成。

      因为,Alice和Carol已经开始RTP流的交互,所以紧接着,Carol需要对Bob进行挂机处理。因此,Carol对Bob发送BYE消息,双方挂机(F22)。

      Bob对Carol发送200 OK,执行挂机处理(F22):

      到现在为止,Alice仍然需要告诉Bob电话转接状态。因此,Alice对Bob发送第二个NOTIFY事件,通知Bob电话已经完全成功转接(F24):

      Bob发送一个 200 OK消息,表示收到此事件(F25):

      然后Bob对Alice挂机,发送BYE消息(F26):

      最后,Alice对Bob发送200 OK(F27),询转正式流程结束。

      参考资料:

      https://tools.ietf.org/html/rfc4579

      https://www.rfc-editor.org/rfc/rfc5359.txt

      https://tools.ietf.org/html/rfc7088

      https://www.rfc-editor.org/rfc/rfc3515.txt

      https://tools.ietf.org/html/rfc3840

      https://tools.ietf.org/html/rfc3891

      https://www.rfc-editor.org/rfc/rfc6665.txt

      http://file.scirp.org/Html/1-1730003_32286.htm

      https://arrow.dit.ie/cgi/viewcontent.cgi?

      referer=https://www.google.com/&httpsredir=1&article=1005&context=ittscicon

      http://www.cs.columbia.edu/~nahum/papers/sip-multicore-journal.pdf

      https://support.sonus.net/display/SBXDOC51/GRUU+Support

      https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-99.html

      www.freepbx.org.cn

      https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/MOHParkServer/doc/MOHParkServer_User_Documentation.pdf?revision=8937&view=co

      http://ijsetr.com/uploads/463152IJSETR13872-273.pdf

      https://tools.ietf.org/html/rfc3665

      https://tools.ietf.org/html/rfc3265

      https://tools.ietf.org/html/rfc3515

      https://tools.ietf.org/html/rfc4317

    展开全文
  • Android呼叫拦截器 步骤1: 在Android Studio中创建一新项目 第2步: 创建一AIDL文件夹 在AIDL创建一新包文件夹名称必须为com.android.internal.telephony 在该程序包名称中创建AIDL文件必须为ITelephony....
  • 5)、一旦护士看见护士站紧急呼叫闪烁灯后,须先按下护士处理按钮以取消闪烁情况,再依病房紧急呼叫顺序处理病房紧急事故,若事故处理妥当后,病房紧急闪烁指示灯和病床上的紧急指示灯才能被重置。
  • 原因可能为: 1.目录权限  2.操作频繁 ...在“服务”里找到这三个服务,都去启动  Distributed Transaction Coordinator  Remote Procedure Call (RPC)  Security Accounts Manager  如果:Distribu
  • 数电医院病人紧急呼叫系统课程设计报告,亲,抓紧哦
  • 病房床位呼叫器设计+数电课程设计+数字电路课程设计
  • Android设备上的呼叫流程

    千次阅读 2021-05-21 18:27:20
    呼叫分为主动呼叫和被动呼叫,主动呼叫也叫"去电",MO Call,表示用户通过UI上的拨号键盘拨出的电话。 被动呼叫叫做"来电",MT Call,表示其他打电话端打过来的电话,可以选择接听或者拒接。 来电流程 来电的时候,会...
  • *客户服务呼叫中心系统解决方案 索引目录 1. 前言 2 2. ***客户服务现状分析 3 3. ***客服对呼叫中心的需求描述 3
  • PLC课程设计 基于病房紧急呼叫设计 病人按按钮呼叫护士站 病人病房呼叫有优先级之分
  • 无线通信呼叫建立过程,包括呼叫,短信,核心网的详细流程
  • GSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.docGSM呼叫流程.doc
  • H323学习笔记四之呼叫流程的建立

    千次阅读 2019-07-29 21:38:50
    前一篇文章提到:H323系统中的一次完整的点到点呼叫通信由五阶段组成:呼叫建立、通信初始化和能力交换、视听通信的建立、呼叫服务、呼叫终止。他们有各自的特点和功能,接下来按序介绍: 呼叫建立 ...
  • 呼叫中心(英文是Call Center),就是在一相对集中的场所,由一批服务人员组成的服务机构,通常利用计算机通讯技术,处理来自企业、顾客的咨询需求。例如10086热线客服电话就是一call center的例子。 OKCC呼叫...
  • 对于各类信令流程进行讲解,很清晰,不错的资料。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,533
精华内容 8,213
关键字:

呼叫处理的三个步骤

友情链接: TwoCamera.rar