CN101998325A - 一种指示终端媒体类型的呼叫方法及装置 - Google Patents
一种指示终端媒体类型的呼叫方法及装置 Download PDFInfo
- Publication number
- CN101998325A CN101998325A CN2009101675605A CN200910167560A CN101998325A CN 101998325 A CN101998325 A CN 101998325A CN 2009101675605 A CN2009101675605 A CN 2009101675605A CN 200910167560 A CN200910167560 A CN 200910167560A CN 101998325 A CN101998325 A CN 101998325A
- Authority
- CN
- China
- Prior art keywords
- user terminal
- terminal
- application server
- user
- request message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明提供了一种指示终端媒体类型的呼叫方法及装置,方法包括:第一用户终端与应用服务器或第二用户终端协商后,发起对第三用户终端的呼叫;所述应用服务器向所述第三用户终端发送请求消息,所述请求消息中携带有终端媒体类型;所述第三用户终端基于所述请求消息向所述应用服务器发起offer,所述应用服务器将所述第三用户终端发起的所述offer转发给所述第一用户终端,从而发起所述第三用户终端与所述第一用户终端之间的协商;所述第一用户终端与所述第三用户终端协商完成后进行通话。
Description
技术领域
本发明涉及通信领域,尤其涉及IMS域业务嵌套场景,提出一种新类型的媒体。
背景技术
IP多媒体子***(IP Multimedia Core Network Subsystem,简称IMS)是由第三代合作伙伴计划(3rd Generation PartnershipProject,简称3GPP)组织提出的一种基于IP的网络架构,其构建了一个开放而灵活的业务环境,支持多媒体应用,并为用户提供丰富的多媒体业务。
IMS是基于IP的电信网络架构,与接入技术无关,除了可以为GPRS(General Packet Radio Service,通用分组无线业务)、WLAN(Wireless Local Area Network,无线局域网)等分组接入网络提供业务外,还可以为GSM(Global System for Mobile communications,全球移动通讯***)、UMTS(Universal Mobile TelecommunicationsSystem,统一移动通讯***)等移动蜂窝网络提供业务。
IMS域呼叫采用SIP(Session Initial Protocol)协议,而SIP协议要求媒体的协商必须满足OFFER/ANSWER模型(详见rfc3264),即OFFER/ANSWER必须成对出现,不能出现连续2个同类型的OFFER(这种情况协议规定用491消息拒绝第二个OFFER),不能出现没有OFFER的ANSWER。
作为被叫的终端侧,接收到呼叫请求INVITE,需要进行用于通话的资源准备工作。如果被叫接收到初始会话请求INVITE中没有携带媒体,则作为被叫的终端,则无法知道应该准备什么样的媒体,特别在被叫终端能力比主叫终端能力强的情况下,由于被叫不知道主叫实际支持的能力,对被叫造成的困扰更大,更有甚者,如果主叫终端与被叫终端之间能力没有交集的话,则后续协商媒体的协商无法完成。
TISPAN(Telecommunications and Internet converged Servicesand Protocols for Advanced Networking)定义的IMS***框架见图1,部分网元功能如下:
UE:用户终端,User Equipment。
CSCF(Call Session Control Function,呼叫会话控制功能):CSCF是IMS中的会话控制功能体。CSCF在IMS中实现了多媒体呼叫中主要的软交换控制功能,可以看作SIP中的各种基本Server的集合。
CSCF又分为三类:P-CSCF、S-CSCF、I-CSCF。
P-CSCF(Proxy CSCF):P是用户接入核心网的节点,在IMS的CSCF中离用户最近。对外转发着UE的消息并且将从外面收到的SIP消息返回给UE。P可以看作SIP中的Proxy。
S-CSCF(Serving CSCF):S是IMS中核心中的核心,处于IMS的核心控制地位,基本上任何SIP消息都要经过它的处理,包括路由、AS业务触发、重定向等主要控制功能。S可以看作SIP中的Registrar、Proxy以及Redirect Server。
I-CSCF(Interrogating-CSCF):I是一个网络的边界节点,主要对外来呼叫中的被叫的S进行定位,从而隐藏该网络的拓扑结构,因为若所有外来呼叫都要经过该网络的I,则外面的用户无从知道该网络内部S以及P等网元的分布情况。I是可选的,也就是说可以不需要这样一个网元,如果你不想刻意隐藏自己的网络结构。因为进入的呼叫都要经过I,虽然I的功能较为单一,但负担比较重,因此一个网络一旦使用了I,一般就不止一个,以便进行负载均衡。也正因为如此,I是不会关心会话状态的。当然,因为I的特殊位置,也可以借助I做些其他工作,比如过滤外来请求,统计呼叫数据等。I通常还接受自己网络内的REGISTER请求,并为其指定一个S。I可以看作SIP中的Proxy、Redirect Server。
HSS(Home Subscriber Server,归属签约用户服务器):是用于集中存放用户数据(认证信息、业务信息、漫游信息、原始计费信息等)的地方,用户数据总是存放在其归属域(开户地)的HSS中,可以跟HSS打叫道的有I,S和AS等,UE不会跟HSS有直接接触。一个网络可以配置多个HSS,这时就需要SLF(ubscriber LocationFunction,签约用户位置功能)将一个用户地址映射到对应HSS。这时SLF就是SIP中的一个Redirect Server。
AS(Application Server,应用服务器):用于实现具体业务的服务器。通常AS由S根据用户请求以及触发条件进行触发,它是作为SIP中的B2BUA实现的。IMS中的这种触发机制正是其支持业务与承载分离的基础。
图2是IMS域实现用户无应答前转并且新呼叫INVITE不带SDP的流程示意图,步骤说明如下:
步骤201:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤202:AS转发INVITE给UE-B;
步骤203-204:UE-B回183响应,携带用户B的SDP;
步骤205-206:UE-A回PRACK消息给UE-B;
步骤207-208:UE-B回PRACK消息给UE-A;
步骤209-210:UE-B回180消息给UE-A;
用户B处于振铃中。
AS等待应答定时器超时,取消到B的试呼,然后重新发起到C的试呼,下面是具体流程。
步骤211-214:AS取消到UE-B的试呼;
步骤215:AS发起到UE-C的呼叫,不携带SDP;
步骤216:UE-C回183,携带UE-C的SDP;
步骤217:AS将UE-C的SDP通过UPDATE带给UE-A;
步骤218:UE-A回200,携带UE-A的媒体;
步骤219:AS将UE-A的SDP通过PRACK发送给UE-C;
步骤220:UE-C回200(PRACK);
步骤221-222:UE-C振铃,回180;
用户C处于振铃状态。
步骤223-224:UE-C摘机应答,发送200OK给UE-A;
步骤225-226:UE-A回UE-C ACK消息;
UE-A与UE-C进入通话中。
步骤227-230:UE-C挂机,通话结束。
图3是IMS域实现用户自动台流程并且INVITE不带SDP的流程示意图,步骤说明如下:
步骤301:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤302:AS回200OK,携带提示音媒体;
步骤303:UE-A回ACK,UE-A与AS之间建立通话;
AS放提示音,并且完成收号过程;
步骤304:AS发起到UE-B的呼叫,UE-B的号码由上一步AS收号得到;
步骤305:UE-B回183,携带UE-B的SDP;
步骤306:AS将媒体通过re-INVITE发送给UE-A;
步骤307:UE-A回200OK,携带UE-A的SDP;
步骤308:AS将UE-A的媒体通过PRACK发送给UE-B;
步骤309:UE-B回200OK(PRACK);
步骤310:AS回UE-A ACK消息;
步骤311:UE-B回180消息;
UE-B进入振铃状态;
AS等待UE-B应答定时器超时,则取消到UE-B的试呼,重新收号并发起到新收用户的呼叫。
步骤312-315:AS释放掉向UE-B的试呼;
步骤316:AS发起INVITE,到UE-C;
步骤317:UE-C回183,携带SDP;
步骤318:AS将媒体通过re-INVITE发送给UE-A;
步骤319:UE-A回200,携带UE-A的SDP;
步骤320:AS将媒体通过PRACK消息发送给UE-C;
步骤321:UE-C回200OK;
步骤322:AS回ACK;
步骤323:UE-C回180;
UE-C处于振铃中。
步骤324:被叫摘机,回200OK;
步骤325:AS回ACK给UE-C;
A、C用户进入通话中。
步骤327-329:呼叫释放。
步骤303-304:UE-B回183响应,携带用户B的SDP;
步骤305-306:UE-A回PRACK消息给UE-B;
步骤307-308:UE-B回PRACK消息给UE-A;
步骤309-310:UE-B回180消息给UE-A;
用户B处于振铃中。
AS等待应答定时器超时,取消到B的试呼,然后重新发起到C的试呼,下面是具体流程。
步骤311-314:AS取消到UE-B的试呼;
步骤315:AS发起到UE-C的呼叫,不携带SDP;
步骤316-317:UE-C回183,携带UE-C的SDP;
步骤318-319:UE-A回UE-C PRACK,携带UE-A的媒体;
步骤320-321:UE-C回UE-A 200OK;
步骤322-323:UE-C振铃,回180;
用户C处于振铃状态。
步骤324:UE-C摘机应答,发送200OK给UE-A;
步骤325:UE-A回UE-C ACK消息;
UE-A与UE-C进入通话中。
步骤326-329:UE-C挂机,通话结束。
图4是IMS域实现用户无应答前转并且新呼叫INVITE携带SDP的流程示意图,步骤说明如下:
步骤401:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤402:AS转发INVITE给UE-B;
步骤403-404:UE-B回183响应,携带用户B的SDP;
步骤405-406:UE-A回PRACK消息给UE-B;
步骤407-408:UE-B回PRACK消息给UE-A;
步骤409-410:UE-B回180消息给UE-A;
用户B处于振铃中。
AS等待应答定时器超时,取消到B的试呼,然后重新发起到C的试呼,下面是具体流程。
步骤411-414:AS取消到UE-B的试呼;
步骤415:AS发起到UE-C的呼叫,携带SDP(该SDP可能是UE-A的INVITE中携带的媒体,或者某一步骤中携带的媒体,或者AS构造的媒体);
步骤416:UE-C回183,携带UE-C的SDP;
步骤417:AS将UE-C的SDP通过UPDATE发送给UE-A;
步骤418:UE-A回200,携带UE-A的媒体;
步骤419:AS发送PRACK给UE-C;
对于步骤418中携带的UE-A的媒体是否转给UE-C,跟由AS通过决策决定,如果决策需要转,则可以通过PRACK或者UPDATE再发个UE-C,由于这个转换对于本场景分析没有影响,因此假定步骤418中携带的媒体不需要转给UE-C;
步骤420:UE-C回200OK;
步骤421-422:UE-C振铃,回180;
用户C处于振铃状态。
步骤423-424:UE-C摘机应答,发送200OK给UE-A;
步骤425-426:UE-A回UE-C ACK消息;
UE-A与UE-C进入通话中。
步骤427-430:UE-C挂机,通话结束。
图5是IMS域实现用户自动台流程并且INVITE携带SDP的流程示意图,步骤说明如下:
步骤501:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤502:AS回200OK,携带提示音媒体;
步骤503:UE-A回ACK,UE-A与AS之间建立通话;
AS放提示音,并且完成收号过程;
步骤504:AS发起到UE-B的呼叫,UE-B的号码由上一步AS收号得到;
步骤505:UE-B回183,携带UE-B的SDP;
步骤506:AS将媒体通过re-INVITE发送给UE-A;
步骤507:UE-A回200OK,携带UE-A的SDP;
步骤508:AS将UE-A的媒体通过PRACK发送给UE-B;
步骤509:UE-B回200OK(PRACK);
步骤510:AS回UE-AACK消息;
步骤511:UE-B回180消息;
UE-B进入振铃状态;
AS等待UE-B应答定时器超时,则取消到UE-B的试呼,重新收号并发起到新收用户的呼叫。
步骤512-515:AS释放掉向UE-B的试呼;
步骤516:AS发起INVITE,到UE-C,携带SDP(该SDP可能是UE-A的INVITE中携带的媒体,或者某一步骤中携带的媒体,或者AS构造的媒体);
步骤517:UE-C回183,携带SDP;
步骤518:AS将UE-C的SDP通过re-INVITE发送给UE-A;
步骤519:UE-A回200,携带UE-A的SDP;
对于步骤519中携带的UE-A的媒体是否转给UE-C,跟由AS通过决策决定,如果决策需要转,则可以通过PRACK或者UPDATE再发个UE-C,由于这个转换对于本场景分析没有影响,因此假定步骤519中携带的媒体不需要转给UE-C;
步骤520:AS将媒体通过PRACK消息发送给UE-C;
步骤521:UE-C回200OK;
步骤522:AS回ACK;
步骤523:UE-C回180;
UE-C处于振铃中。
步骤524:被叫摘机,回200OK;
步骤525:AS回ACK给UE-C;
A、C用户进入通话中。
步骤526-529:呼叫释放。
上述4图分别介绍了无应答前转INVITE不携带SDP,自动台INVITE不携带SDP,无应答前转INVITE携带SDP,自动台INVITE携带SDP的实现流程,协商的流程都是通过可靠传输的183携带媒体,然后再发送180的方式,流程图也可变更为通过可靠传输的180携带媒体的方式;上述4图使用非precondition流程进行介绍,precondition流程的只是增加了媒体预留完成的通知,原理类似,不再累述。
对于各类前转以及一号通、顺振、同振业务流程,如果被叫未回任何携带媒体的可靠响应,则对媒体协商没有任何影响,如果被叫回携带媒体的可靠响应,则流程图与无应答前转类似,不再累述;对于盲转转接、自动台等AS作为B2BUA实现业务,一侧为通话态,一侧为非通话态的业务,流程图与自动台类似,不再累述。
下文将继续以无应答前转和自动台为例进行讲述。
图2和图3所示无应答前转和自动台INVITE不带SDP的流程,采用这种流程,会有如下问题:
被叫接收到不携带媒体的INVITE,则不知道应该如何准备本侧的媒体,比如,如果被叫支持音频和视频呼叫,则应该准备音频的媒体,还是视频的媒体,还是同时准备;
被叫无法决策采用何种类型的媒体与主叫进行协商;
若新的媒体类型由被叫引入,则引起计费的问题;
图4和图5所示为无应答和自动台INVITE携带SDP的流程,采用这种流程,主要的问题是:
由于第二次INVITE中携带offer媒体,则被叫回的媒体是answer的媒体,AS只有将被叫回的answer媒体转为offer媒体发送出去(因此主叫与AS之间offer/answer模型已经是配对的),这样就出现answer转offer。而answer转offer则会增加媒体协商冲突的几率,同时也可能会引起媒体震荡。
(offer/answer的具体定义见rfc3264:An Offer/Answer Modelwith the Session Description Protocol(SDP))。
发明内容
本发明提出一种新的SDP,该SDP的作用是用于指示被叫,并且该SDP不属于会话媒体offer\answer协商的范畴,既解决被叫准备本侧媒体有依据,又避免引起answer转offer的问题,克服现有技术的不足。
本发明提出了一种指示终端媒体类型的呼叫方法,包括以下步骤:第一用户终端与应用服务器或第二用户终端协商后,发起对第三用户终端的呼叫;应用服务器向第三用户终端发送请求消息,请求消息中携带有终端媒体;第三用户终端基于请求消息向应用服务器发起offer,应用服务器将所述第三用户终端发起的offer转发给第一用户终端,从而发起第三用户终端与第一用户终端之间的协商;第一用户终端与第三用户终端协商完成后进行通话。
其中,在第一用户终端与应用服务器或第二用户终端协商的步骤中,具体包括以下步骤:第一用户终端通过应用服务器呼叫第二用户终端;第一用户终端和第二用户终端进行协商;应用服务器等待应答定时器超时后,取消对第二用户终端的呼叫。
其中,在第一用户终端与应用服务器或第二用户协商终端的步骤中,具体包括以下步骤:第一用户终端通过应用服务器呼叫第二用户终端;第一用户终端和第二用户终端进行协商;第一用户终端与第二用户终端进行通话。
其中,请求消息中的终端媒体通过特定的标识与会话初始协议(SIP)协议中的定义的媒体进行区分。
其中,请求消息中的终端媒体通过定义Content-Disposition:notice-session来与SIP协议中的定义的消息进行区分。
其中,请求消息中携带的终端媒体为第一用户终端的媒体或应用服务器修改的终端媒体。
本发明提出了一种指示终端媒体类型的呼叫装置,装置包括:第一用户终端,呼叫第二用户终端或应用服务器并与其协商,并且之后呼叫第三用户;第二用户或应用服务器,与所述第一用户进行协商,并且在协商完成之后,应用服务器向第三用户终端发送请求消息,请求消息中携带有终端媒体;第三用户,基于请求消息向所述应用服务器发起offer,应用服务器将第三用户终端发起的offer转发给第一用户终端,从而发起第三用户终端与第一用户终端之间的协商。
其中,请求消息中的终端媒体通过特定的标识与会话初始协议(SIP)协议中的定义的消息进行区分。
其中,请求消息中的终端媒体通过定义Content-Disposition:notice-session来与SIP协议中的定义的消息进行区分。
其中,请求消息中携带的终端媒体为第一用户终端的媒体或应用服务器修改的终端媒体。
采用本发明的新类型的SDP,既解决被叫准备本侧媒体以及协商有依据,又避免引起answer转offer的问题,克服现有技术的不足。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是IMS***参考框架示意图;
图2是IMS域实现用户无应答前转并且新呼叫INVITE不携带SDP的流程示意图;
图3是IMS域实现自动台并且新呼叫INVITE不携带新类型SDP的流程示意图;
图4是IMS域实现用户无应答前转并且新呼叫INVITE携带session SDP的流程示意图;
图5是IMS域实现自动台并且新呼叫INVITE携带session SDP的流程示意图;
图6是IMS域实现用户无应答前转并且新呼叫INVITE携带新类型SDP的流程示意图;
图7是IMS域实现自动台并且新呼叫INVITE携带新类型SDP的流程示意图;
图8是根据本发明的装置示意图。
具体实施方式
下面结合附图和具体实施方式对本发明作进一步的说明。
为了解决上述问题,本发明提供提出一种新类型的SDP,该SDP通过一定的标识,将它与进行媒体协商的session SDP区分出来。比如通过定义Content-Disposition:notice-session。
该SDP的应用场景是:对于初始INVITE中携带SDP,但是AS(业务服务器)发起新呼叫时,发现初始的INVITE携带的媒体已经进行过协商,再将该SDP携带放入INVITE中呼出到新用户,则会导致answer转offer。此时,将SDP修改为新类型的SDP,然后用INVITE携带新类型的SDP发送给新用户,这样保证被叫回的媒体为一个offer的媒体,从而不会引起answer转offer的操作。
仍以无应答前转和自动台为例,介绍采用新类型的SDP之后的信令示意图,图中仍以可靠传输的183携带媒体,仍以不支持precondition的流程为示例,但采用precondition的流程,以及使用可靠180携带媒体,或者存在update切换媒体的流程,与示意流程并无差异,因此不做累述。
图6是IMS域实现用户无应答前转并且新呼叫INVITE携带新类型SDP的流程示意图,步骤说明如下:
步骤601:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤602:AS转发INVITE给UE-B;
步骤603-604:UE-B回183响应,携带用户B的SDP;
步骤605-606:UE-A回PRACK消息给UE-B;
步骤607-608:UE-B回200(PRACK)消息给UE-A;
步骤609-610:UE-B回180消息给UE-A;
用户B处于振铃中。
AS等待应答定时器超时,取消到B的试呼,然后重新发起到C的试呼,下面是具体流程。
步骤611-614:AS取消到UE-B的试呼;
步骤615:AS发起到UE-C的呼叫,携带新类型的SDP,通过某类型标识决定该SDP不作为session SDP,不参与offer/answer的协商过程;图中采用Content-Disposition:notice-session作为新媒体的标识;
步骤616:UE-C回183,携带UE-C的SDP,作为offer的SDP;
步骤617:AS将UE-C的SDP通过UPDATE发送给UE-A;
步骤618:UE-A回200,携带UE-A的SDP;
步骤619:AS发送PRACK给UE-C,携带UE-A的SDP,作为answer的SDP;
步骤620:UE-C回200OK;
步骤621-622:UE-C振铃,回180;
用户C处于振铃状态。
步骤623-624:UE-C摘机应答,发送200OK给UE-A;
步骤625-626:UE-A回UE-C ACK消息;
UE-A与UE-C进入通话中。
步骤627-630:UE-C挂机,通话结束。
其中,终端媒体类型不改变所述UE-A与应用服务器或UE-B的协商后的offer/answer进展。
图7是IMS域实现用户自动台流程并且INVITE携带SDP的流程示意图,步骤说明如下:
步骤701:UE-A发起初始会话请求INVITE消息到AS,携带用户A的SDP;
步骤702:AS回200OK,携带提示音媒体;
步骤703:UE-A回ACK,UE-A与AS之间建立通话;
AS放提示音,并且完成收号过程;
步骤704:AS发起到UE-B的呼叫,UE-B的号码由上一步AS收号得到;
步骤705:UE-B回183,携带UE-B的SDP;
步骤706:AS将媒体通过re-INVITE发送给UE-A;
步骤707:UE-A回200OK,携带UE-A的SDP;
步骤508:AS将UE-A的媒体通过PRACK发送给UE-B;
步骤709:UE-B回200OK(PRACK);
步骤710:AS回UE-A ACK消息;
步骤711:UE-B回180消息;
UE-B进入振铃状态;
AS等待UE-B应答定时器超时,则取消到UE-B的试呼,重新收号并发起到新收用户的呼叫。
步骤712-715:AS释放掉向UE-B的试呼;
步骤716:AS发起INVITE,到UE-C,携带新类型的SDP,通过某类型标识决定该SDP不作为session SDP,不参与offer/answer的协商过程;图中采用Content-Disposition:notice-session作为新媒体的标识;
步骤717:UE-C回183,携带作为offer的SDP;
步骤718:AS将UE-C的SDP通过re-INVITE发送给UE-A;
步骤719:UE-A回200,携带UE-A的SDP;
步骤720:AS将媒体SDP通过PRACK消息发送给UE-C,该SDP作为answer;
步骤721:UE-C回200OK;
步骤722:AS回ACK;
步骤723:UE-C回180;
UE-C处于振铃中。
步骤724:被叫摘机,回200OK;
步骤725:AS回ACK给UE-C;
A、C用户进入通话中。
步骤726-729:呼叫释放。
其中,发给UE-C的呼叫请求携带的媒体,可能为UE-A媒体,也可能为AS在终端媒体基础上修改后的媒体,比如修改里面的IP、PORT等。
根据本发明的基本原理,上述实施例还有其他变换方式,例如:新类型的SDP通过其它标识而不是Content-Disposition:notice-session。
本发明还提出了一种指示终端媒体类型的基于SIP的呼叫装置,参照图8,包括:第一用户终端,呼叫第二用户终端或应用服务器并与其协商,并且之后呼叫第三用户;第二用户或应用服务器,与所述第一用户进行协商,并且在协商完成之后,应用服务器向第三用户终端发送请求消息,请求消息中携带有终端媒体;第三用户,基于请求消息向所述应用服务器发起offer,应用服务器将第三用户终端发起的offer转发给第一用户终端,从而发起第三用户终端与第一用户终端之间的协商。
其中,请求消息通过特定的标识与SIP协议中的消息进行区分。进一步地,请求消息通过定义Content-Disposition:notice-session来与SIP协议中的消息进行区分。
其中,请求消息中携带的终端媒体为第一用户终端的媒体或应用服务器修改的终端媒体。
领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种指示终端媒体类型的呼叫方法,其特征在于,所述方法包括以下步骤:
第一用户终端与应用服务器或第二用户终端协商后,发起对第三用户终端的呼叫;
所述应用服务器向所述第三用户终端发送请求消息,所述请求消息中携带有终端媒体;
所述第三用户终端基于所述请求消息向所述应用服务器发起offer,所述应用服务器将所述第三用户终端发起的所述offer转发给所述第一用户终端,从而发起所述第三用户终端与所述第一用户终端之间的协商;
所述第一用户终端与所述第三用户终端协商完成后进行通话。
2.根据权利要求1所述的方法,其特征在于,在所述第一用户终端与应用服务器或第二用户终端协商的步骤中,具体包括以下步骤:
所述第一用户终端通过所述应用服务器呼叫所述第二用户终端;
所述第一用户终端和所述第二用户终端进行协商;
所述应用服务器等待应答定时器超时后,取消对所述第二用户终端的呼叫。
3.根据权利要求1所述的方法,其特征在于,在所述第一用户终端与应用服务器或第二用户协商终端的步骤中,具体包括以下步骤:
所述第一用户终端通过所述应用服务器呼叫所述第二用户终端;
所述第一用户终端和所述第二用户终端进行协商;
所述第一用户终端与所述第二用户终端进行通话。
4.根据权利要求1所述的方法,其特征在于,所述请求消息中的终端媒体通过特定的标识与会话初始协议(SIP)协议中的定义的媒体进行区分。
5.根据权利要求1所述的方法,其特征在于,所述请求消息中的终端媒体通过定义Content-Disposition:notice-session来与所述SIP协议中的定义的消息进行区分。
6.根据权利要求1所述的方法,其特征在于,所述请求消息中携带的终端媒体为所述第一用户终端的媒体或所述应用服务器修改的终端媒体。
7.一种指示终端媒体类型的呼叫装置,其特征在于,所述装置包括:
第一用户终端,呼叫第二用户终端或应用服务器并与其协商,并且之后呼叫第三用户;
所述第二用户或应用服务器,与所述第一用户进行协商,并且在协商完成之后,所述应用服务器向所述第三用户终端发送请求消息,所述请求消息中携带有终端媒体;
所述第三用户,基于所述请求消息向所述应用服务器发起offer,所述应用服务器将所述第三用户终端发起的所述offer转发给所述第一用户终端,从而发起所述第三用户终端与所述第一用户终端之间的协商。
8.根据权利要求7所述的装置,其特征在于,所述请求消息中的终端媒体通过特定的标识与会话初始协议(SIP)协议中的定义的消息进行区分。
9.根据权利要求7所述的装置,其特征在于,所述请求消息中的终端媒体通过定义Content-Disposition:notice-session来与所述SIP协议中的定义的消息进行区分。
10.根据权利要求7所述的装置,其特征在于,所述请求消息中携带的终端媒体为所述第一用户终端的媒体或所述应用服务器修改的终端媒体。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101675605A CN101998325A (zh) | 2009-08-25 | 2009-08-25 | 一种指示终端媒体类型的呼叫方法及装置 |
PCT/CN2010/075291 WO2011023041A1 (zh) | 2009-08-25 | 2010-07-20 | 一种指示终端媒体类型的呼叫方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101675605A CN101998325A (zh) | 2009-08-25 | 2009-08-25 | 一种指示终端媒体类型的呼叫方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101998325A true CN101998325A (zh) | 2011-03-30 |
Family
ID=43627231
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009101675605A Pending CN101998325A (zh) | 2009-08-25 | 2009-08-25 | 一种指示终端媒体类型的呼叫方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101998325A (zh) |
WO (1) | WO2011023041A1 (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102904882A (zh) * | 2012-09-24 | 2013-01-30 | 中兴通讯股份有限公司南京分公司 | 随机呼叫的转发方法及装置 |
CN103475648A (zh) * | 2013-08-29 | 2013-12-25 | 上海斐讯数据通信技术有限公司 | 基于sip协议的呼叫盲转方法及呼叫盲转*** |
CN106658752A (zh) * | 2015-11-03 | 2017-05-10 | ***通信集团公司 | 一种通信资源确认方法、装置及*** |
CN107371140A (zh) * | 2016-05-11 | 2017-11-21 | ***通信有限公司研究院 | 一种呼叫前转的处理方法及设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1893427A (zh) * | 2005-07-07 | 2007-01-10 | 华为技术有限公司 | 一种进行业务支持能力协商的方法 |
CN101448222A (zh) * | 2008-04-01 | 2009-06-03 | 中兴通讯股份有限公司 | 一种实现ims集中业务被叫转接的方法 |
CN101459897A (zh) * | 2008-04-17 | 2009-06-17 | 中兴通讯股份有限公司 | 一种前转业务中的媒体协商方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103428218B (zh) * | 2006-04-26 | 2017-04-12 | 三星电子株式会社 | 转发用户设备的性能信息的方法和*** |
CN101227303B (zh) * | 2007-01-19 | 2011-08-24 | 中兴通讯股份有限公司 | 彩铃和彩像发送方法以及早媒体发送方法 |
CN100596238C (zh) * | 2007-09-12 | 2010-03-24 | 华为技术有限公司 | 多媒体通信方法及网元设备 |
-
2009
- 2009-08-25 CN CN2009101675605A patent/CN101998325A/zh active Pending
-
2010
- 2010-07-20 WO PCT/CN2010/075291 patent/WO2011023041A1/zh active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1893427A (zh) * | 2005-07-07 | 2007-01-10 | 华为技术有限公司 | 一种进行业务支持能力协商的方法 |
CN101448222A (zh) * | 2008-04-01 | 2009-06-03 | 中兴通讯股份有限公司 | 一种实现ims集中业务被叫转接的方法 |
CN101459897A (zh) * | 2008-04-17 | 2009-06-17 | 中兴通讯股份有限公司 | 一种前转业务中的媒体协商方法 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102904882A (zh) * | 2012-09-24 | 2013-01-30 | 中兴通讯股份有限公司南京分公司 | 随机呼叫的转发方法及装置 |
WO2014044096A1 (zh) * | 2012-09-24 | 2014-03-27 | 中兴通讯股份有限公司 | 随机呼叫的转发方法及装置 |
CN103475648A (zh) * | 2013-08-29 | 2013-12-25 | 上海斐讯数据通信技术有限公司 | 基于sip协议的呼叫盲转方法及呼叫盲转*** |
CN103475648B (zh) * | 2013-08-29 | 2017-12-19 | 上海斐讯数据通信技术有限公司 | 基于sip协议的呼叫盲转方法及呼叫盲转*** |
CN106658752A (zh) * | 2015-11-03 | 2017-05-10 | ***通信集团公司 | 一种通信资源确认方法、装置及*** |
CN106658752B (zh) * | 2015-11-03 | 2020-04-14 | ***通信集团公司 | 一种通信资源确认方法、装置及*** |
CN107371140A (zh) * | 2016-05-11 | 2017-11-21 | ***通信有限公司研究院 | 一种呼叫前转的处理方法及设备 |
Also Published As
Publication number | Publication date |
---|---|
WO2011023041A1 (zh) | 2011-03-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1972254B (zh) | 终端之间语音和多媒体的互动服务的装置和方法 | |
US10044553B2 (en) | Media resource reservation request failure handling for voice over mobile wireless network | |
EP2061269B2 (en) | Method for providing access mode selection to multimode terminal, system and apparatus thereof | |
CN101330748B (zh) | 一种ip多媒体子***集中业务会话控制路径的切换方法 | |
EP1973283A1 (en) | Interworking network element, interworking system between the csi terminal and the ims terminal and the method thereof | |
CN101175248B (zh) | Ip多媒体子***集中控制业务的紧急呼叫***及方法 | |
US20090036128A1 (en) | Method and system for dynamic call anchoring | |
CN101166364A (zh) | 一种在紧急业务时实现语音呼叫连续性的方法和*** | |
US20080316976A1 (en) | METHOD AND APPARATUS FOR SIGNALING INTERWORKING CDMA 3G1x MOBILES AND EVDO MOBILES WITH AN IMS CORE NETWORK | |
WO2013178291A1 (en) | Ims inbound roamer and short number dialling | |
WO2012027939A1 (zh) | 一号通呼叫的方法及业务控制点 | |
KR20060113284A (ko) | 이종망간에 음성 서비스를 지원하는 아이엠에스 시스템 및그에 따른 호 설정 방법 | |
EP2014110A2 (en) | A subscriber server system for a cellular communication system | |
CN101132644B (zh) | Ip多媒体子***集中控制业务紧急呼叫实现方法和*** | |
CN101998325A (zh) | 一种指示终端媒体类型的呼叫方法及装置 | |
CN102598645A (zh) | Ip多媒体子***网络中的紧急信令 | |
CN102761917A (zh) | 一种被叫侧发生会话切换的处理方法和as | |
EP2173085B1 (en) | A method for realizing user decision user busy forwarding | |
CN101111000B (zh) | Ims集中业务中由被叫用户设备释放呼叫的方法 | |
CN102833715B (zh) | 询问转接实现方法、应用服务器、业务终端和*** | |
CN102932764A (zh) | 一种集成呼叫控制装置 | |
JP5909516B2 (ja) | 通信システム、緊急通報規制装置および通信方法 | |
KR101574317B1 (ko) | 효율적인 착신 호 처리를 위한 방법 및 이를 위한 시스템 | |
CN103139745A (zh) | 紧急呼叫实现方法、***及归属网络、拜访网络服务装置 | |
CN103428781A (zh) | 一种ip语音通话切换的方法及***、用户设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20110330 |