CN106953834A - 一种实现终端媒体能力协商的方法、终端及网络设备 - Google Patents

一种实现终端媒体能力协商的方法、终端及网络设备 Download PDF

Info

Publication number
CN106953834A
CN106953834A CN201610009485.XA CN201610009485A CN106953834A CN 106953834 A CN106953834 A CN 106953834A CN 201610009485 A CN201610009485 A CN 201610009485A CN 106953834 A CN106953834 A CN 106953834A
Authority
CN
China
Prior art keywords
terminal
message
media capability
avpf
avp
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.)
Granted
Application number
CN201610009485.XA
Other languages
English (en)
Other versions
CN106953834B (zh
Inventor
刘雅
潘洁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN201610009485.XA priority Critical patent/CN106953834B/zh
Publication of CN106953834A publication Critical patent/CN106953834A/zh
Application granted granted Critical
Publication of CN106953834B publication Critical patent/CN106953834B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种实现终端媒体能力协商的方法，所述方法包括：第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；所述第一媒体能力信息表征所述第二终端具备支持音视频配置文件AVP的能力；当确定自身不具备识别协商框架的能力时，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；所述第二终端的媒体能力用于表征所述第二终端具备支持AVP/AVPF的能力；基于所述第二终端的媒体能力反馈第二消息给所述第二终端。本发明还同时公开了一种终端及网络设备。

Description

一种实现终端媒体能力协商的方法、终端及网络设备
技术领域
本发明涉及无线通信技术领域，尤其涉及一种实现终端媒体能力协商的方法、终端及网络设备。
背景技术
IP多媒体子系统(IMS，IP Multimedia Subsystem)网络可提供基于全IP的多媒体业务，其特点是采用会话初始协议(SIP，Session Initiation Protocol)进行端到端的呼叫控制，辅助运营商进行全IP网络安全、计费等方面的管理工作。为了成功创建多媒体会话，SIP信令通过传输会话描述协议(SDP，SessionDescription Protocol)消息进行会话方的媒体能力协商，协商内容包括媒体类型、传输协议配置文件，媒体带宽等信息；其中，所述传输协议配置文件包括音视频配置文件(AVP，Audio-Visual Profile)和带有反馈的音视频配置文件(AVPF，Audio-Visual Profile with Feedback)两种。
建立视频通话时，IR.94规定必须在初始协商中使用AVPF进行实时传输协议(RTP，Realtime Transport Protocol)配置文件(profile)协商，然而，现有的AVPF协商方式，若会话双方采用不同的协商方式进行协商，则会导致AVPF协商失败，降低用户体验；因此，提供一种实现终端媒体能力协商的方案，能够确保支持AVPF的会话双方能成功协商AVPF，使会话过程中音视频业务可根据网络及传输状况进行自适应调整及差错修复，提升用户体验，已成为亟待解决的问题。
发明内容
有鉴于此，本发明实施例期望提供一种实现终端媒体能力协商的方法、终端及网络设备，能够确保支持AVPF的会话双方成功协商AVPF，使会话过程中音视频业务可根据网络及传输状况进行自适应调整及差错修复，提升用户体验。
为达到上述目的，本发明实施例的技术方案是这样实现的：
本发明实施例提供了一种实现终端媒体能力协商的方法，所述方法包括：
第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；所述第一媒体能力信息表征所述第二终端具备支持AVP的能力；
当确定自身不具备识别协商框架的能力时，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；所述第二终端的媒体能力用于表征所述第二终端具备支持AVP/AVPF的能力；
基于所述第二终端的媒体能力反馈第二消息给所述第二终端。
上述方案中，所述第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息，包括：
第一终端对第二终端发送的第一消息进行实时传输协议RTP配置文件(profile)检测，确定所述第一消息的媒体行携带AVP信息。
上述方案中，所述方法还包括：
当确定自身具备识别协商框架的能力时，识别得到所述第一消息采用协商框架并携带AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息。
上述方案中，所述对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力，包括：
基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
上述方案中，所述第二终端支持AVPF时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
所述第二终端仅支持AVP时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
直接在所述第二信息中携带AVP信息反馈给所述第二终端。
本发明实施例还提供了一种实现终端媒体能力协商的方法，网络侧获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式；所述方法还包括：
网络侧获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；
基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；
将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；
发送所述第三消息给所述第二终端。
上述方案中，所述基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式，包括：
对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；
对所述第二消息进行RTP配置文件检测，依据所述第二消息携带的RTP配置文件类型确定所述第一终端的媒体能力。
上述方案中，所述依据匹配结果对所述第二消息进行处理得到第三消息，包括：
确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息。
上述方案中，所述确定所述第一终端的媒体能力与所述第二终端的媒体能力不同之后，所述方法还包括：
确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP。
本发明实施例还提供了一种终端，所述终端为第一终端，所述终端包括：检测模块、第一确定模块及反馈模块；其中，
所述检测模块，用于对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；
所述第一确定模块，用于确定自身不具备识别协商框架的能力，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；
所述反馈模块，用于基于所述第二终端的媒体能力反馈第二消息给所述第二终端。
上述方案中，所述检测模块，具体用于对第二终端发送的第一消息进行RTP配置文件检测，确定所述第一消息的媒体行携带AVP信息。
上述方案中，所述第一确定模块，还用于确定第一终端具备识别协商框架的能力，且识别得到所述第一消息采用协商框架并携带支持反馈的音视频配置文件AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息。
上述方案中，所述第一确定模块，具体用于基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
上述方案中，所述第二终端支持AVPF时，所述反馈模块，具体用于采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
所述第二终端仅支持AVP时，所述反馈模块，具体用于直接在所述第二信息中携带AVP信息反馈给所述第二终端。
本发明实施例还提供了一种网络设备，所述网络设备包括：获取模块、第二确定模块、处理模块及发送模块；其中，
所述获取模块，用于获取第二终端发送给第一终端的第一消息，以及，获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；
所述第二确定模块，用于基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式，以及，基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；
所述处理模块，用于将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；
所述发送模块，用于发送所述第三消息给所述第二终端。
上述方案中，所述第二确定模块，具体用于对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；
对所述第二消息进行RTP配置文件检测，依据所述第二消息携带的RTP配置文件类型确定所述第一终端的媒体能力。
上述方案中，所述处理模块，具体用于确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息。
上述方案中，所述网络设备还包括通知模块，用于确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP。
本发明实施例所提供的实现终端媒体能力协商的方法、终端及网络设备；第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；确定自身不具备识别协商框架的能力，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；基于所述第二终端的媒体能力反馈第二消息给所述第二终端。或者，网络侧获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式；获取第一终端反馈给所述第二终端的第二消息；基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；发送所述第三消息给所述第二终端。如此，能够确保支持AVPF的会话双方成功协商AVPF，使会话过程中音视频业务可根据网络及传输状况进行自适应调整及差错修复，提升用户体验。
附图说明
图1为本发明实施例实现终端媒体能力协商的方法流程示意图一；
图2为本发明实施例实现终端媒体能力协商的方法流程示意图二；
图3为本发明实施例实现终端媒体能力协商的方法流程示意图三；
图4为本发明实施例实现终端媒体能力协商的方法流程示意图四；
图5为本发明实施例实现终端媒体能力协商的方法流程示意图五；
图6为本发明实施例终端的组成结构示意图；
图7为本发明实施例网络设备的组成结构示意图。
具体实施方式
AVP是RFC 3556为RTCP定义的配置文件。音视频类会话通过RTP实时传输协议实现端到端的数据传输，通过RTCP控制协议监测数据传输状况，保障业务质量。因此，需要为RTCP分配独立于RTP数据传输的带宽，用于反馈数据包的发送和接收情况，保障对数据传输的实时监测和控制。AVP定义了RTCP的带宽配置方式，可分别为发送报告与接收报告配置独立带宽。其中，发送报告主要用于接收侧数据包同步，接收报告主要用于拥塞控制。在会话建立时，需在SIP中的SDP部分进行声明，格式为：
m＝audio 49152RTP/AVP 98//媒体行＝媒体类型端口号传输协议payload格式。
AVPF在RFC 4585中定义，继承了AVP定义的RTCP带宽配置方式，并在AVP的框架上进行拓展，增加反馈机制，发送端可通过接收端的反馈进行实时的自适应调整和有效的错误修复。用户在SIP中的SDP部分声明支持AVPF后，可通过申请的RTCP带宽向通信对端发送通知和请求，反馈主要分为两类：
1、反馈传输相关信息(Transport layer feedback message)，包括：
a、Generic NACK，用于接收侧指示丢失的一个或多个RTP包序列号；
b、TMMBR/TMMBN，调整最大传输码率请求/通知。
2、反馈负载数据相关信息(Payload-specific feedback message)，包括：
a、PLI，多用于指示图像的关键帧丢失；
b、SLI，指示宏块的编码数据丢失；
c、RPSI，指示损坏图像的区域大小和ID用于参考图像选择；
d、FIR，请求对端重传I帧以及解码所需的图像参数信息用于解码器刷新；
e、TSTR/TSTN，帧率、分辨率调整请求/通知；
f、VBCM，携带接收情况报告或刷新请求。
若要在会话中支持传输上述消息，初始媒体协商时，会话方需在SDP中声明支持AVPF，终端可采用如下协商方式之一进行AVPF协商：
第一协商方式：SDP中只携带AVPF进行协商，即直接在SDP Offer的媒体行中携带AVPF，SDP answer与offer携带格式一致；
第二协商方式：SDP中使用SDPCapNeg(SDP Capability Negotiation)协商框架同时携带AVP与AVPF信息，即SDP Offer的媒体行携带AVP信息，并通过携带‘tcap’与‘pcfg’字段申明终端对AVPF的支持。
然而，采用第一协商方式，若SDP中携带AVPF进行协商，而对端不支持AVPF，则终端必须发起第二个SDP offer(update或re-invite)携带AVP进行二次协商，如此，会产生额外的SIP信令资源消耗；采用第二协商方式，若消息接收端支持AVPF，但不支持SDPCapNeg协商框架，在接收到SDP offer后，则无法识别SDPCapNeg框架中与AVPF相关的‘tcap’与‘pcfg’字段，则认为发送端仅支持AVP，造成AVPF协商的失败，两端协商为AVP，降低用户体验。
在本发明实施例中，采用不同AVPF协商方式的会话方，可在网络侧或者终端侧采用兼容策略，对不同的AVPF协商方式进行检测和翻译，使会话双方成功协商AVPF，确保音视频业务可根据网络及传输状况进行自适应调整及差错修复，提升用户体验；
其中，在终端侧，第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；确定自身不具备识别协商框架的能力，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；基于所述第二终端的媒体能力反馈第二消息给所述第二终端；
在网络侧，网络侧获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式；获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；发送所述第三消息给所述第二终端。
实施例一
图1为本发明实施例实现终端媒体能力协商的方法流程示意图，应用于终端侧，如图1所示，本发明实施例实现终端媒体能力协商的方法包括：
步骤101：第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息。
这里，所述第一消息可以为SIP中的SDP消息，具体可为SDP offer；
在一实施例中，所述第一终端为支持AVPF的终端；所述第一媒体能力信息表征所述第二终端具备支持音视频配置文件AVP的能力；
所述第一终端对第二终端发送的第一消息进行配置文件信息检测，包括：
所述第一终端对第二终端发送的第一消息进行RTP配置文件，即RTPprofile检测，即检测所述第一消息的媒体行携带的RTP profile类型，若为AVP，则可初步确定第二终端支持AVP；若为AVPF，则确定所述第二终端支持AVPF；
其中，所述媒体行即为所述第一消息中的m行；
当确定所述第二终端支持AVPF时，则可采用与第一协商方式对应的反馈方式进行SDP answer，即直接在SDP answer中携带AVPF，以使第一终端接收到所述SDP answer后，检测到m行携带AVPF，则认为AVPF配置文件协商成功。
在一实施例中，所述第一媒体能力信息为AVP信息。
步骤102：当确定自身不具备识别协商框架的能力时，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力。
这里，所述协商框架可以为SDPCapNeg协商框架；终端若不具备识别SDPCapNeg协商框架的能力，则对端发送的消息即便采用了SDPCapNeg协商框架，终端也无法识别出所述SDPCapNeg协商框架。
在一实施例中，所述媒体属性关键字可以为a＝rtcp等；所述第二终端的媒体能力用于表征所述第二终端具备支持AVP/AVPF的能力；
所述对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力，包括：
基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
在一实施例中，所述方法还包括：
当第一终端确定自身具备识别协商框架的能力时，识别得到所述第一消息采用协商框架并携带AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息；
这里，当所述第一消息为SDP offer时，所述第二消息为SDP answer；可通过某具体字段表征所述第一消息携带AVPF信息，如：当所述协商框架为SDPCapNeg协商框架时，相应的，通过‘tcap’与‘pcfg’字段表征所述协商框架携带AVPF信息。
在一实施例中，采用第一方式反馈第二消息即采用协商框架反馈第二消息；所述第一方式为与所述第二协商方式对应的反馈方式，即采用SDPCapNeg协商框架进行SDP answer，所述SDP answer携带AVPF信息。
步骤103：基于所述第二终端的媒体能力反馈第二消息给所述第二终端。
在一实施例中，确定第二终端支持AVPF时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
这里，所述第二方式为与所述第一协商方式对应的反馈方式，即直接在SDPanswer中携带AVPF信息。
确定第二终端仅支持AVP时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
直接在所述第二信息中携带AVP信息反馈给所述第二终端。
实施例二
图2为本发明实施例实现终端媒体能力协商的方法流程示意图，如图2所示，本发明实施例实现终端媒体能力协商的方法包括：
步骤201：第一终端对第二终端发送的第一消息进行RTP profile检测，确定所述RTP profile类型为AVP时，执行步骤202；确定所述RTP profile类型为AVPF时，执行步骤204。
本步骤之前，所述方法还包括：第一终端接收第二终端发送的第一消息。
在本发明实施例中，所述第一消息为SDP offer，如：SDP offer使用SDPCapNeg框架申明支持AVPF：
m＝video 60010RTP/AVP 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝tcap：1RTP/AVPF
a＝pcfg：1t＝1
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
第一终端对第二终端发送的第一消息进行RTP profile检测具体包括：第一终端检测第二终端发送的SDP offer的媒体行携带的RTP profile类型，若为AVP，则可初步确定第二终端支持AVP；若为AVPF，则确定所述第二终端支持AVPF；
其中，所述媒体行即为所述第一消息中的m行；如上述SDP offer中m＝video60010RTP/AVP 113，对其检测可得携带AVP。
步骤202：第一终端判断自身是否具备识别协商框架的能力，如果不具备，执行步骤203；如果具备，执行步骤206。
在本发明实施例中，所述协商框架为SDPCapNeg协商框架。
步骤203：对所述第一消息进行媒体属性关键字识别，判断所述第一消息是否携带预设的媒体属性关键字，如果携带，执行步骤204；如果没有携带，执行步骤205。
这里，所述媒体属性关键字可以为a＝rtcp等；
若第一消息携带预设的媒体属性关键字，确定所述第二终端支持AVPF；
若第一消息未携带预设的媒体属性关键字，确定所述第二终端仅支持AVP；
如对上述SDP offer检测可得消息体中携带a＝rtcp的关键字，可知第二终端支持AVPF。
步骤204：直接在第二消息中携带AVPF信息，发送所述第二消息给所述第二终端，执行步骤208。
在本发明实施例中，所述第二消息为SDP answer，相应的，所述直接在第二消息中携带AVPF信息即在所述SDP answer的媒体行中携带AVPF信息；
即：SDP answer-1
m＝video 17148RTP/AVPF 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
步骤205：直接在第二消息中携带AVP信息，发送所述第二消息给所述第二终端，执行步骤208。
步骤206：判断所述第一消息是否采用协商框架并携带AVPF信息，如果是，执行步骤207；否则，执行步骤205。
在本发明实施例中，通过在SDP offer中携带‘tcap’与‘pcfg’字段表征所述协商框架携带AVPF信息。
步骤207：采用协商框架携带AVPF信息反馈第二消息给所述第二终端。
本步骤操作也即采用与所述第二协商方式对应的反馈方式反馈第二消息给所述第二终端；
即：SDP answer-2
m＝video 17148RTP/AVPF 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝acfg：1t＝1
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
步骤208：结束本次处理流程。
实施例三
图3为本发明实施例实现终端媒体能力协商的方法流程示意图，应用于网络侧，如图3所示，本发明实施例实现终端媒体能力协商的方法包括：
步骤301：网络侧获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式。
在一实施例中，所述第一消息为SIP消息，具体为SDP offer；所述网络侧为IMS核心网，具体可以为网元代理呼叫会话控制功能实体(P-CSCF，Proxy-Call Session Control Function)；
相应的，本步骤之前，所述方法还包括：
IMS核心网通过检测SIP消息的源地址和目的地址识别所述第二终端与所述第一终端正在建立的会话；相应的，所述第一消息为所述IMS核心网在识别所述会话后缓存的最近一条SIP消息。
在一实施例中，所述基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式，包括：
网络侧对所述第一消息进行RTP profile检测，确定所述第一消息的媒体行携带的RTP profile类型为AVPF，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第一协商方式；
确定所述第一消息的媒体行携带的RTP profile类型为AVP，则进一步对所述第一消息进行协商框架识别，若所述第一消息采用协商框架且携带AVPF信息，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第二协商方式；若所述第一消息未采用协商框架，则确定所述第二终端的媒体能力为AVP；所述第二终端的媒体能力用于表征所述第二终端支持的RTPprofile类型；
这里，所述协商框架可以为SDPCapNeg协商框架。
在一实施例中，所述方法还包括：网络侧缓存所述第一消息、所述第二终端的媒体能力及支持的协商方式。
步骤302：网络侧获取第一终端反馈给所述第二终端的第二消息。
在一实施例中，所述第二消息为SIP消息，具体为SDP answer；
所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成，也即，第一终端收到所述第二终端发送的第一消息后，并不对所述第一消息进行检测，而是依据本端的媒体能力及支持的协商方式反馈SDP answer；如：所述第一终端支持AVPF，支持第二协商方式，则所述SDP answer采用SDPCapNeg协商框架并携带AVPF信息。
步骤303：基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式。
在一实施例中，本步骤具体包括：
对所述第二消息进行RTP profile检测，依据所述第二消息携带的RTPprofile类型确定所述第一终端的媒体能力；若检测得到所述第二消息携带的RTP profile类型为AVPF，则确定所述第一终端的媒体能力为AVPF，若检测得到所述第二消息携带的RTP profile类型为AVP，则确定所述第一终端的媒体能力为AVP；即所述RTP profile类型用于表征终端的媒体能力；
在检测得到所述第二消息携带的RTP profile类型为AVPF的情况下，对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；若识别得到所述第二消息采用协商框架，则确定所述第一终端支持第二协商方式，若识别得到所述第二消息未采用协商框架，则确定所述第一终端支持第一协商方式；
这里，需要说明的是，上述确定所述第一终端的媒体能力及确定第一终端支持的协商方式的操作没有固定的执行顺序，亦可先执行确定第一终端支持的协商方式的过程，再执行确定所述第一终端的媒体能力的操作过程。
步骤304：将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息。
在一实施例中，本步骤具体包括：
将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，确定所述第二终端的媒体能力与所述第一终端的媒体能力相同，且所述第二终端支持的协商方式与所述第一终端支持的协商方式相同，则网络侧直接转发所述第二消息，即不对所述第二消息进行处理，使所述第三消息与所述第二消息相同；
确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
具体的，确定所述第一终端支持的协商方式为第一协商方式，所述第二终端支持的协商方式为第二协商方式，对第二消息进行协商方式转换使其采用第二协商方式，得到第三消息；确定所述第一终端支持的协商方式为第二协商方式，所述第二终端支持的协商方式为第一协商方式，对第二消息进行协商方式转换使其采用第一协商方式，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息；
这里，所述第一终端的媒体能力与所述第二终端的媒体能力不同，即第一终端与第二终端中一个支持AVP，另一个支持AVPF，则媒体能力协商结果必为AVP；
具体的，确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息包括：
确定所述第一终端的媒体能力为AVP，所述第二终端的媒体能力为AVPF，不对所述第二消息进行处理，使所述第二消息与所述第三消息相同；
确定所述第一终端的媒体能力为AVPF，所述第二终端的媒体能力为AVP，对所述第二消息进行转换，使其符合AVP的协商，即所述第二消息直接携带AVP信息发送给所述第二终端。
在一实施例中，所述确定所述第一终端的媒体能力与所述第二终端的媒体能力不同之后，所述方法还包括：
确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP；具体为采用SIP消息，如update消息，通知所述第一终端媒体能力协商结果为AVP。
步骤305：发送所述第三消息给所述第二终端。
实施例四
图4为本发明实施例实现终端媒体能力协商的方法流程示意图，应用于网络侧，如图4所示，本发明实施例实现终端媒体能力协商的方法包括：
步骤401：P-CSCF获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式。
在本发明实施例中，所述第一消息为SIP消息，具体为SDP offer；
本步骤之前，所述方法还包括：
P-CSCF通过检测SIP消息的源地址和目的地址识别所述第二终端与所述第一终端正在建立的会话。
在本发明实施例中，所述基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式，包括：
P-CSCF对所述第一消息进行RTP profile检测，确定所述第一消息的媒体行携带的RTP profile类型为AVPF，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第一协商方式；
确定所述第一消息的媒体行携带的RTP profile类型为AVP，则进一步对所述第一消息进行协商框架识别，若所述第一消息采用协商框架且携带AVPF信息，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第二协商方式；若所述第一消息未采用协商框架，则确定所述第二终端的媒体能力为AVP；所述第二终端的媒体能力用于表征所述第二终端支持的RTPprofile类型；
其中，所述协商框架为SDPCapNeg协商框架。
例如：第二终端采用SDPCapNeg协商框架申明支持AVPF：
SDP offer
m＝video 60010RTP/AVP 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝tcap：1RTP/AVPF
a＝pcfg：1t＝1
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
网络侧获取上述SDP offer后识别得到所述第二终端的媒体能力为AVPF，采用的协商方式为第二协商方式。
在本发明实施例中，所述方法还包括：网络侧缓存所述第一消息、所述第二终端的媒体能力及支持的协商方式。
步骤402：P-CSCF获取第一终端反馈给所述第二终端的第二消息。
在本发明实施例中，所述第二消息为SDP answer；第一终端收到所述第二终端发送的第一消息即SDP offer后，并不对所述第一消息进行检测，而是依据本端的媒体能力及支持的协商方式反馈SDP answer；
例如，所述第二终端支持AVPF，且仅支持第一协商方式：
SDP answer
m＝video 17148RTP/AVPF 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝rtpmap：113 H264/90000
a＝fmtp：113 profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
步骤403：基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式。
在本发明实施例中，本步骤具体包括：
对所述第二消息进行RTP profile检测，依据所述第二消息携带的RTPprofile类型确定所述第一终端的媒体能力；若检测得到所述第二消息携带的RTP profile类型为AVPF，则确定所述第一终端的媒体能力为AVPF，若检测得到所述第二消息携带的RTP profile类型为AVP，则确定所述第一终端的媒体能力为AVP；即所述RTP profile类型用于表征终端的媒体能力；
在检测得到所述第二消息携带的RTP profile类型为AVPF的情况下，对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；若识别得到所述第二消息采用协商框架，则确定所述第一终端支持第二协商方式，若识别得到所述第二消息未采用协商框架，则确定所述第一终端支持第一协商方式。
对上述SDP answer进行相应的检测和识别后可得所述第一终端支持AVPF，且仅支持第一协商方式。
步骤404：确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息。
在本发明实施例中，P-CSCF确定所述第一终端与所述第二终端均支持AVPF，但采用了不同的协商方式，则基于第二终端支持的协商方式，即将answer翻译为SDPCapNeg框架形式，反馈给所述第二终端，如下所示：
m＝video 17148RTP/AVPF 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝acfg：1t＝1
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
步骤405：发送所述第三消息给所述第二终端。
实施例五
图5为本发明实施例实现终端媒体能力协商的方法流程示意图，应用于网络侧，如图5所示，本发明实施例实现终端媒体能力协商的方法包括：
步骤501：P-CSCF获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式。
在本发明实施例中，所述第一消息为SIP消息，具体为SDP offer；
本步骤之前，所述方法还包括：
P-CSCF通过检测SIP消息的源地址和目的地址识别所述第二终端与所述第一终端正在建立的会话。
在本发明实施例中，所述基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式，包括：
P-CSCF对所述第一消息进行RTP profile检测，确定所述第一消息的媒体行携带的RTP profile类型为AVPF，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第一协商方式；
确定所述第一消息的媒体行携带的RTP profile类型为AVP，则进一步对所述第一消息进行协商框架识别，若所述第一消息采用协商框架且携带AVPF信息，则确定所述第二终端的媒体能力为AVPF，所述第二终端支持的协商方式为第二协商方式；若所述第一消息未采用协商框架，则确定所述第二终端的媒体能力为AVP；所述第二终端的媒体能力用于表征所述第二终端支持的RTPprofile类型；
其中，所述协商框架为SDPCapNeg协商框架。
例如：第二终端仅支持AVP：
SDP offer
m＝video 60010RTP/AVP 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
网络侧获取上述SDP offer后识别得到所述第二终端的媒体能力为AVP。
在本发明实施例中，所述方法还包括：网络侧缓存所述第一消息、所述第二终端的媒体能力及支持的协商方式。
步骤502：P-CSCF获取第一终端反馈给所述第二终端的第二消息。
在本发明实施例中，所述第二消息为SDP answer；第一终端收到所述第二终端发送的第一消息即SDP offer后，并不对所述第一消息进行检测，而是依据本端的媒体能力及支持的协商方式反馈SDP answer；
例如，所述第二终端支持AVPF，且仅支持第一协商方式：
SDP answer
m＝video 17148RTP/AVPF 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
a＝rtcp-fb：*nack
a＝rtcp-fb：*nack pli
a＝rtcp-fb：*ccm fir
a＝rtcp-fb：*ccm tmmbr
步骤503：基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式。
在本发明实施例中，本步骤具体包括：
对所述第二消息进行RTP profile检测，依据所述第二消息携带的RTPprofile类型确定所述第一终端的媒体能力；若检测得到所述第二消息携带的RTP profile类型为AVPF，则确定所述第一终端的媒体能力为AVPF，若检测得到所述第二消息携带的RTP profile类型为AVP，则确定所述第一终端的媒体能力为AVP；即所述RTP profile类型用于表征终端的媒体能力；
在检测得到所述第二消息携带的RTP profile类型为AVPF的情况下，对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；若识别得到所述第二消息采用协商框架，则确定所述第一终端支持第二协商方式，若识别得到所述第二消息未采用协商框架，则确定所述第一终端支持第一协商方式。
对上述SDP answer进行相应的检测和识别后可得所述第一终端支持AVPF，且仅支持第一协商方式。
步骤504：确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行协商方式转换处理，得到第三消息。
这里，所述第三消息携带AVP信息。
在本发明实施例中，P-CSCF确定第一终端支持AVPF但第二终端仅支持AVP，则对所述第二消息进行转换，使其符合AVP的协商，即所述第二消息直接携带AVP信息发送给所述第二终端。
在本发明实施例中，所述第三消息包括：
m＝video 17148 RTP/AVP 113
b＝AS：640
b＝RS：8000
b＝RR：6000
a＝rtpmap：113H264/90000
a＝fmtp：113profile-level-id＝42C016…
步骤505：通知所述第一终端媒体能力协商结果为AVP。
在本发明实施例中，采用SIP消息，如update消息，通知所述第一终端媒体能力协商结果为AVP。
步骤506：发送所述第三消息给所述第二终端。
需要说明的是，步骤505及步骤506的操作顺序可互换。
实施例六
图6为本发明实施例终端的组成结构示意图；如图6所示，本发明实施例终端的组成包括：检测模块61、第一确定模块62及反馈模块63；其中，
所述检测模块61，用于对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；
所述第一确定模块62，用于确定自身不具备识别协商框架的能力，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；
所述反馈模块63，用于基于所述第二终端的媒体能力反馈第二消息给所述第二终端；
这里，所述第一消息可以为SIP中的SDP消息，具体可为SDP offer；
在一实施例中，所述第一终端为支持AVPF的终端。
在一实施例中，所述检测模块61，具体用于对第二终端发送的第一消息进行RTP profile检测，确定所述第一消息的媒体行携带AVP信息；
所述检测模块61对第二终端发送的第一消息进行RTP profile检测，即检测所述第一消息的媒体行携带的RTP profile类型，若为AVP，则可初步确定第二终端支持AVP；若为AVPF，则确定所述第二终端支持AVPF；
当确定所述第二终端支持AVPF时，所述反馈模块63，用于采用与第一协商方式对应的反馈方式进行SDP answer，即直接在SDP answer中携带AVPF。
在一实施例中，所述协商框架可以为SDPCapNeg协商框架；所述媒体属性关键字可以为a＝rtcp等。
在一实施例中，所述第一确定模块62，还用于确定第一终端具备识别协商框架的能力，且识别得到所述第一消息采用协商框架并携带支持反馈的音视频配置文件AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息。
在一实施例中，所述第一确定模块62，具体用于基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
在一实施例中，所述第二终端支持AVPF时，所述反馈模块63，具体用于采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
所述第二终端仅支持AVP时，所述反馈模块，具体用于直接在所述第二信息中携带AVP信息反馈给所述第二终端。
实施例七
图7为本发明实施例网络设备的组成结构示意图；如图7所示，本发明实施例网络设备的组成包括：获取模块71、第二确定模块72、处理模块73及发送模块74；其中，
所述获取模块71，用于获取第二终端发送给第一终端的第一消息，以及，获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；
所述第二确定模块72，用于基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式，以及，基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；
所述处理模块73，用于将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；
所述发送模块74，用于发送所述第三消息给所述第二终端；
这里，所述第一消息可以为SIP消息，具体可以为SDP offer；所述网络设备可以为P-CSCF。
在一实施例中，所述获取模块71，还用于通过检测SIP消息的源地址和目的地址识别所述第二终端与所述第一终端正在建立的会话。
在一实施例中，所述获取模块71，还用于缓存所述第一消息、所述第二终端的媒体能力及支持的协商方式。
在一实施例中，所述第二确定模块72，具体用于对所述第二消息进行RTPprofile检测，依据所述第二消息携带的RTP profile类型确定所述第一终端的媒体能力；
对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；
这里，所述协商框架可以为SDPCapNeg协商框架。
在一实施例中，所述处理模块73，具体用于确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息。
在一实施例中，所述网络设备还包括通知模块75，用于确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP。
在本发明实施例中，所述终端中的检测模块61、第一确定模块62及反馈模块63；所述网络设备中的获取模块71、第二确定模块72、处理模块73、发送模块74及通知模块75均可由终端或服务器中的中央处理器(CPU，CentralProcessing Unit)或数字信号处理器(DSP，Digital Signal Processor)、或现场可编程门阵列(FPGA，Field Programmable Gate Array)、或集成电路(ASIC，Application Specific Integrated Circuit)实现。
这里需要指出的是：以上涉及终端和网络设备的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明所述终端和服务器实施例中未披露的技术细节，请参照本发明方法实施例的描述。
以上所述，仅为本发明较佳实施例而已，并非用于限定本发明的保护范围。

Claims (18)

1.一种实现终端媒体能力协商的方法，其特征在于，所述方法包括：
第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；所述第一媒体能力信息表征所述第二终端具备支持音视频配置文件AVP的能力；
当确定自身不具备识别协商框架的能力时，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；所述第二终端的媒体能力用于表征所述第二终端具备支持AVP或带有反馈的音视频配置文件AVPF的能力；
基于所述第二终端的媒体能力反馈第二消息给所述第二终端。
2.根据权利要求1所述方法，其特征在于，所述第一终端对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息，包括：
第一终端对第二终端发送的第一消息进行实时传输协议RTP配置文件检测，确定所述第一消息的媒体行携带AVP信息。
3.根据权利要求1或2所述方法，其特征在于，所述方法还包括：
当确定自身具备识别协商框架的能力时，识别得到所述第一消息采用协商框架并携带AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息。
4.根据权利要求1或2所述方法，其特征在于，所述对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力，包括：
基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
5.根据权利要求4所述方法，其特征在于，所述第二终端支持AVPF时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
所述第二终端仅支持AVP时，所述基于所述第二终端的媒体能力反馈第二消息给所述第二终端，包括：
直接在所述第二信息中携带AVP信息反馈给所述第二终端。
6.一种实现终端媒体能力协商的方法，其特征在于，网络侧获取第二终端发送给第一终端的第一消息，基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式；所述方法还包括：
网络侧获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；
基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；
将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；
发送所述第三消息给所述第二终端。
7.根据权利要求6所述方法，其特征在于，所述基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式，包括：
对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；
对所述第二消息进行RTP配置文件检测，依据所述第二消息携带的RTP配置文件类型确定所述第一终端的媒体能力。
8.根据权利要求6或7所述方法，其特征在于，所述依据匹配结果对所述第二消息进行处理得到第三消息，包括：
确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息。
9.根据权利要求8所述方法，其特征在于，所述确定所述第一终端的媒体能力与所述第二终端的媒体能力不同之后，所述方法还包括：
确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP。
10.一种终端，所述终端为第一终端，其特征在于，所述终端包括：检测模块、第一确定模块及反馈模块；其中，
所述检测模块，用于对第二终端发送的第一消息进行配置文件信息检测，确定所述第一消息携带第一媒体能力信息；
所述第一确定模块，用于确定自身不具备识别协商框架的能力，对所述第一消息进行媒体属性关键字识别，基于识别结果确定所述第二终端的媒体能力；
所述反馈模块，用于基于所述第二终端的媒体能力反馈第二消息给所述第二终端。
11.根据权利要求10所述终端，其特征在于，所述检测模块，具体用于对第二终端发送的第一消息进行RTP配置文件检测，确定所述第一消息的媒体行携带AVP信息。
12.根据权利要求10或11所述终端，其特征在于，所述第一确定模块，还用于确定第一终端具备识别协商框架的能力，且识别得到所述第一消息采用协商框架并携带支持反馈的音视频配置文件AVPF信息，采用第一方式反馈第二消息给所述第二终端；所述第二消息携带所述AVPF信息。
13.根据权利要求10或11所述终端，其特征在于，所述第一确定模块，具体用于基于预设的媒体属性关键字对所述第一消息进行媒体属性关键字识别；
所述第一消息携带预设的媒体属性关键字时，确定所述第二终端支持AVPF；
所述第一消息未携带预设的媒体属性关键字时，确定所述第二终端仅支持AVP。
14.根据权利要求13所述终端，其特征在于，所述第二终端支持AVPF时，所述反馈模块，具体用于采用第二方式反馈第二消息给所述第二终端；所述第二消息携带AVPF信息；
所述第二终端仅支持AVP时，所述反馈模块，具体用于直接在所述第二信息中携带AVP信息反馈给所述第二终端。
15.一种网络设备，其特征在于，所述网络设备包括：获取模块、第二确定模块、处理模块及发送模块；其中，
所述获取模块，用于获取第二终端发送给第一终端的第一消息，以及，获取第一终端反馈给所述第二终端的第二消息；所述第二消息为所述第一终端收到所述第一消息后，不对所述第二终端的媒体能力进行识别，直接依据自身的媒体能力及支持的协商方式生成；
所述第二确定模块，用于基于所述第一消息确定所述第二终端的媒体能力及支持的协商方式。以及，基于所述第二消息确定所述第一终端的媒体能力及支持的协商方式；
所述处理模块，用于将所述第二终端的媒体能力及支持的协商方式分别与所述第一终端的媒体能力及支持的协商方式进行匹配，依据匹配结果对所述第二消息进行处理得到第三消息；
所述发送模块，用于发送所述第三消息给所述第二终端。
16.根据权利要求15所述网络设备，其特征在于，所述第二确定模块，具体用于对所述第二消息进行协商框架识别，依据识别结果确定第一终端支持的协商方式；
对所述第二消息进行RTP配置文件检测，依据所述第二消息携带的RTP配置文件类型确定所述第一终端的媒体能力。
17.根据权利要求15或16所述网络设备，其特征在于，所述处理模块，具体用于确定所述第一终端的媒体能力与所述第二终端的媒体能力相同，所述第一终端支持的协商方式与所述第二终端支持的协商方式不同，基于第二终端支持的协商方式对所述第二消息进行协商方式转换处理，得到第三消息；
确定所述第一终端的媒体能力与所述第二终端的媒体能力不同，对所述第二消息进行处理得到第三消息，所述第三消息携带AVP信息。
18.根据权利要求17所述网络设备，其特征在于，所述网络设备还包括通知模块，用于确定所述第二消息携带AVPF信息，通知所述第一终端媒体能力协商结果为AVP。
CN201610009485.XA 2016-01-07 2016-01-07 一种实现终端媒体能力协商的方法、终端及网络设备 Active CN106953834B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610009485.XA CN106953834B (zh) 2016-01-07 2016-01-07 一种实现终端媒体能力协商的方法、终端及网络设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610009485.XA CN106953834B (zh) 2016-01-07 2016-01-07 一种实现终端媒体能力协商的方法、终端及网络设备

Publications (2)

Publication Number Publication Date
CN106953834A true CN106953834A (zh) 2017-07-14
CN106953834B CN106953834B (zh) 2020-01-24

Family

ID=59466020

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610009485.XA Active CN106953834B (zh) 2016-01-07 2016-01-07 一种实现终端媒体能力协商的方法、终端及网络设备

Country Status (1)

Country Link
CN (1) CN106953834B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111327562A (zh) * 2018-12-13 2020-06-23 海能达通信股份有限公司 一种会话的检测方法、会话系统及存储介质
WO2021164490A1 (en) * 2020-02-20 2021-08-26 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Methods, apparatus and user equipment for wireless communication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1593047A2 (en) * 2003-02-13 2005-11-09 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
CN1751304A (zh) * 2003-02-13 2006-03-22 诺基亚有限公司 在多媒体流中用于信号指示流质量匹配和控制机制的方法
CN101835121A (zh) * 2009-03-09 2010-09-15 华为技术有限公司 一种对媒体协商进行适配处理的方法、系统和装置
CN103493479A (zh) * 2010-10-04 2014-01-01 布鲁珍视网络有限公司 低延迟h.264视频编码的抗误码的系统和方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1593047A2 (en) * 2003-02-13 2005-11-09 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
CN1751304A (zh) * 2003-02-13 2006-03-22 诺基亚有限公司 在多媒体流中用于信号指示流质量匹配和控制机制的方法
CN101835121A (zh) * 2009-03-09 2010-09-15 华为技术有限公司 一种对媒体协商进行适配处理的方法、系统和装置
CN103493479A (zh) * 2010-10-04 2014-01-01 布鲁珍视网络有限公司 低延迟h.264视频编码的抗误码的系统和方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111327562A (zh) * 2018-12-13 2020-06-23 海能达通信股份有限公司 一种会话的检测方法、会话系统及存储介质
CN111327562B (zh) * 2018-12-13 2023-03-24 海能达通信股份有限公司 一种会话的检测方法、会话系统及存储介质
WO2021164490A1 (en) * 2020-02-20 2021-08-26 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Methods, apparatus and user equipment for wireless communication

Also Published As

Publication number Publication date
CN106953834B (zh) 2020-01-24

Similar Documents

Publication Publication Date Title
US10863008B2 (en) Apparatus and method for processing header compressed packet in electronic device
US10638351B2 (en) Service rate adjustment method and apparatus
US7885266B2 (en) Method for IP multimedia services session setup
US20160308919A1 (en) Speech communication terminal, intermediate node, processing device, connection method, and non-transitory computer-readable recording medium
US20100255831A1 (en) Determining delay in a communications system
WO2012063889A1 (ja) コアネットワークおよび通信システム
CN106953834A (zh) 一种实现终端媒体能力协商的方法、终端及网络设备
CN112311802B (zh) 信息传输方法和信息传输装置
WO2023078458A1 (zh) 通话异常处理方法、装置及电子设备
US10716029B2 (en) Terminal, base station, and communication method
WO2014003465A1 (ko) 영상통화의 효율적 세션 교섭을 위한 장치 및 방법
US11509696B2 (en) Methods and apparatuses for enhancement to IP multimedia subsystem
CN115580659A (zh) 异常网络服务恢复方法、装置、电子设备和服务器
CN109982023A (zh) 一种视频会话中的分辨率调整方法
JP2017503449A (ja) 切り替え方法、ソース基地局、ターゲット基地局、システム、記憶媒体
JP4421563B2 (ja) ＲＴＰセッション断検出方法、ＶｏＩＰゲートウェイ装置およびプログラム
US9955380B2 (en) Method and system for optimizing radio resources between UE and ENB during VoLTE call
KR20060038296A (ko) 이동통신 네트워크에서의 멀티플렉싱 장치 및 방법
WO2019172449A1 (ja) Ｒｔｐ変換装置及びｒｔｐ変換方法
US20100262698A1 (en) Method for negotiating redundant transmission
US9769042B2 (en) Method for monitoring a communication system
JP2008042587A (ja) 中継装置及び中継方法
JP5570392B2 (ja) 再送要求送信プロトコル変換装置
KR100666956B1 (ko) 네트워크에서의 미디어 전송 장치 및 방법
CN102761526B (zh) Vc‑1编码视音频在支持h.323协议族的终端设备中传输的方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant