WO2008098509A1 - Procédé et système de négociation d'un support et procédé de transmission d'information de description de support - Google Patents

Procédé et système de négociation d'un support et procédé de transmission d'information de description de support Download PDF

Info

Publication number
WO2008098509A1
WO2008098509A1 PCT/CN2008/070274 CN2008070274W WO2008098509A1 WO 2008098509 A1 WO2008098509 A1 WO 2008098509A1 CN 2008070274 W CN2008070274 W CN 2008070274W WO 2008098509 A1 WO2008098509 A1 WO 2008098509A1
Authority
WO
WIPO (PCT)
Prior art keywords
media
sdp
components
mixed
provider
Prior art date
Application number
PCT/CN2008/070274
Other languages
English (en)
French (fr)
Inventor
Wenming Zhu
Feng Wang
Original Assignee
Huawei Technologies 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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008098509A1 publication Critical patent/WO2008098509A1/zh

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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Definitions

  • the present invention relates to multimedia technologies, and in particular, to a method and system for negotiating media and a method for transmitting media description information. Background of the invention
  • multimedia technology has become an important part of communication technology.
  • the following is a brief introduction to some related protocols and technologies involved in the existing multimedia technology.
  • the Real-Time Transport Protocol is one of the multimedia communication protocols developed by the Internet Engineering Task Force (IETF). It is defined in Request for Comments (RFC) 1889 and is usually used in conjunction with the RTP Control Protocol (RTCP) for real-time audio, video, etc. Data provides end-to-end transport capabilities.
  • the audio and video data blocks generated by the multimedia application are encapsulated in RTP packets, each RTP packet is encapsulated in a User Datagram Protocol (UDP) message segment and then encapsulated in an Internet Protocol (IP) packet. .
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • the audio and video formats that can be encapsulated in the RTP message packet are declared in the configuration files such as RFC1890 and RFC 3551, and the monitoring and control of the RTP transmission process is performed by RTCP.
  • RTSP Real Time Streaming Protocol
  • RTP Resource Reservation Protocol
  • the Session Description Protocol is defined in RFC 2327 and is used for multimedia sessions. The content is described.
  • the description scope includes two parts: one is the session level, which describes the entire multimedia session, such as session initiator information, media connection address, transmission network type, etc.
  • the second is the media level, which may be performed on various media that may exist in the session. Description, such as media format, transmission parameters, media connection address, etc.
  • t 907165275 0 //The first five lines form the beginning, v is the version number 0, o is the participant ID, s is the session title, c is the connection attribute, t is the session establishment time and duration, and the following 0 indicates the end of the session is Ine's launch.
  • RTP/AVP transport protocol number 0, 96, 97, 98, representing PCMU, G.726 and AMR voice coding formats, respectively
  • a rtpmap:101 H.261 ⁇ Second stream: video, port 3400, RTP/AVP transmission, number 99, 101, indicating MPEG1/MPEG2 Video and H.261 code grid respectively Style
  • RTP/AVP transmission number 103, 121, indicates the MPEG1/MPEG2 Video and H.261 encoding formats, respectively.
  • the first five lines of the above message are descriptions of the multimedia session level, including information about the initiator of the message, session information, and network status at the session level; followed by a description of the supported media types, as described below:
  • the media type can be audio (audio), video (video), application (application), data (data), control program (control), etc.
  • port is a multimedia receiving port, if the media uses layering For encoding and transmission, the number of ports needs to be added later;
  • the transmission protocol can be RTP/AVP, or UDP;
  • the format list is the media format that the sender of the message can support, separated by spaces.
  • the network type is generally Internet (IN) for Internet TV (IPTV); the address type may be Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6); the connection address is a multimedia receiving address, for multicast
  • IPTV Internet TV
  • IPv4 Internet Protocol version 4
  • IPv6 Internet Protocol version 6
  • TTL time to live
  • the attribute type is the main extension path of the media attribute line, and can have many names, such as: an attribute type (rtpmap) that defines the correspondence between the media and the attribute value, and an attribute type (fmtp) that defines the correspondence between the internal format of the media and the attribute value.
  • the attribute value is the value assigned to the media attribute and is related to the attribute type.
  • the example SDP message describes three media, and an audio stream is transmitted on the UDP port 3459.
  • the alternative scheme is ⁇ -law pulse code modulation (PCMU), and the ITU audio coding standard G series. (G.726), adaptive multi-rate wideband coding standard (AMR-WB) or telephone voice signal; ports 3400 and 3456 respectively transmit a video stream, wherein port 3456 is used only for the transmission of the video stream, not receiving the transmission from the other party. media.
  • Session Initiation Protocol is an application layer protocol for establishing, changing, or ending a multimedia session. It cooperates with protocols such as SDP, RTSP, and Domain Name System (DNS) to complete session establishment and media negotiation. Once a session is established, the media will Using RTP to transmit directly in the bearer layer, you can flexibly interact with multiple media in one session. Because SIP is based on the open Internet standard, it has great advantages in voice and data service integration and interworking. It can span media and device time limit call control, support rich media formats, and dynamically add/delete media, which is easy to implement. More rich business features. At the same time, SIP supports intelligent services and terminal-side development to reduce network load.
  • SDP Session Initiation Protocol
  • IMS IP Multimedia Subsystem
  • NTN Next Generation Communication Network
  • the Session Announcement Protocol is to send relevant session establishment information to a desired conference participant in order to notify a multicast multimedia conference or other multicast session.
  • SAP itself does not establish a session, it is just the information necessary to establish a session, for example, the video or audio coding method adopted is notified to other participants in a multicast, when the participant receives the notification packet, Start the appropriate tool and set the correct parameters to establish a session with the initiator of the meeting.
  • Transport Stream is a media encapsulation format for the implementation of Multichannel Motion Picture Experts Group Compression Standard Version 1 (MPEG-1) / Moving Picture Experts Group Compression Standard Version 2 (MPEG-2) audio and video streams in a single transmission
  • MPEG-1 Multichannel Motion Picture Experts Group Compression Standard Version 1
  • MPEG-2 Moving Picture Experts Group Compression Standard Version 2
  • a TS is a medium formed by packaging and packaging a plurality of media components in a TS package.
  • a TS may have multiple media components, for example, may include audio, video, and data.
  • There may be different formats in each media component for example:
  • the video contained in a TS may be in H.264 format and MPEG-2 format.
  • a separate RTP transmission parameter is used. Under the TS mechanism, multiple media components occupy only one channel, and can be transmitted using a set of transmission parameters, thereby saving port resources in the network.
  • SDP can provide an interactive mechanism for end-to-end RTP transmission on the network by using the offer/response model by using other protocols such as SIP and SAP.
  • an SDP provider of a multimedia session may issue one SDP offer messages (SDP offer), including the following:
  • SDP responder analyzes the relevant media types and attributes in the SDP offer, and returns an SDP response message in combination with the media format supported by itself.
  • SDP answer to describe its own support for the media provided by the SDP provider.
  • the SDP answer can be:
  • the SDP offer/response model described above requires that the number of m rows in the SDP offer and the SDP answer must be exactly the same, that is, the SDP responder must respond to each m row in the SDP offer provided by the SDP provider. Then, the SDP provider continues to generate an SDP offer reflecting the media supported by the SDP responder according to the SDP answer.
  • This SDP offer/response mechanism can be executed cyclically during multiple media negotiation until the negotiation succeeds or fails.
  • Embodiments of the present invention provide a method for transmitting media description information, so as to facilitate transmission of media description information mixed with multiple media components.
  • a method, system, SDP provider, and SDP responder for negotiating media are provided to facilitate mixing of multiple media components The media negotiated.
  • a method of transmitting media description information comprising:
  • the media characterization information mixed in a plurality of media components is described, and the media internal media components mixed in the plurality of media components are described to form description information, and the description information is sent.
  • a method of negotiating media comprising:
  • the SDP provider describes the media mixed with the plurality of media components, and sends an SDP offer message SDP offer containing the description information to the SDP responder; the SDP responder returns a SDP responder device to the SDP provider according to the SDP offer.
  • SDP answer message of media capability SDP answer If the negotiation succeeds or fails, the process ends; if no negotiation succeeds and no negotiation fails, the SDP provider will regenerate the SDP offer according to the SDP answer, and loop the above steps until the negotiation succeeds or fails.
  • a system for negotiating media comprising: an SDP provider and an SDP responder;
  • the SDP provider describes the media mixed with the plurality of media components, and sends the SDP offer containing the description information to the SDP responder; if no negotiation succeeds and no negotiation fails, the SDP provider will regenerate the SDP according to the SDP answer. Offer
  • the SDP responder returns an SDP answer reflecting the media capabilities of the SDP responder device to the SDP provider based on the SDP offer.
  • An embodiment of the present invention provides an SDP provider, where the SDP provider includes: a description unit, a transceiver unit, and a determining unit;
  • a description unit describing media mixed with a plurality of media components, and providing an SDP offer containing the description information to the transceiver unit; and regenerating the SDP offer according to the SDP answer provided by the determining unit to the transceiver unit;
  • the transceiver unit sends the SDP offer provided by the description unit; receives the SDP answer Provided to the judgment unit;
  • the judging unit judges the negotiation result according to the SDP answer provided by the transceiver unit, and if no negotiation succeeds and no negotiation fails, the SDP answer is provided to the description unit.
  • An SDP responder comprising:
  • a receiving unit configured to receive an SDP offer
  • a generating unit configured to generate, according to the description information of the media mixed by the plurality of media components included in the SDP offer, an SDP answer reflecting the media capability of the SDP responder device, and a sending unit, configured to send the generated by the generating unit SDP answer.
  • the present invention performs external encapsulation and internal media component description by media mixed with a plurality of media components, and the SDP provider and the SDP receiver respectively use the description method to respectively send the SDP offer and the SDP answer.
  • the media in which a plurality of internal components are mixed is negotiated, thereby facilitating negotiation of media in which a plurality of media components are mixed.
  • FIG. 1 is a flowchart of a method for negotiating a media according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a typical SIP signaling interaction process according to an embodiment of the present invention
  • FIG. 3 is a flowchart for media negotiation according to an embodiment of the present invention
  • FIG. 4 is a structural diagram of an SDP provider according to an embodiment of the present invention
  • FIG. 5 is a structural diagram of an SDP responder according to an embodiment of the present invention. Mode for carrying out the invention
  • both parties need to use media mixed with multiple media components.
  • the body is negotiated as a transmission medium.
  • the negotiation process is performed in the embodiment of the present invention by using an SDP description and an SDP providing/responding mechanism.
  • the method for negotiating a media mainly includes the following steps:
  • Step 101 The SDP provider describes the media mixed with the plurality of media components, and generates an SDP offer including the description information.
  • Step 102 The SDP provider sends the generated SDP offer to the SDP responder.
  • Step 103 The SDP responder returns an SDP answer reflecting the media capability of the SDP responder device to the SDP provider according to the SDP offer.
  • Step 104 If the negotiation succeeds or fails, the process ends. If no negotiation succeeds and no negotiation fails, the SDP provider regenerates the SDP offer according to the returned SDP answer, and performs the above steps 102-104 cyclically until the negotiation succeeds or fails.
  • the medium in which the plurality of media components are mixed is: the media component having multiple codec configurations in the media, for example, the media component in the media may include: video, audio, application, data, etc., the video may be MPEG-2 video, H.264 video, etc., the audio may be MPEG-2 audio, AC-3 audio, etc., or a combination of these.
  • the SDP provider may be the sender of the media, may be the recipient of the media, or may be a separate device that knows the media information, and/or the media sender or receiver media capabilities; the SDP responder may be The recipient of the media may be the sender of the media or a separate device that knows the media receiver or sender's media capabilities.
  • the negotiation process may be a negotiation of the transmitted media before the media is sent, or may be a negotiation only for the media sender and the receiver media capabilities without transmitting the media.
  • the SDP provider describes the media provided by the media provider
  • the SDP responder describes the negotiation process of the media receiver media capability as an example.
  • the SDP offer describes the media or media provider's own capabilities of a variety of media components provided by the media provider.
  • the description of the media mixed with multiple media components mainly includes two aspects:
  • the media characterization information mixed in a plurality of media components that is, externally encapsulating the media mixed with the plurality of media components, the characterization information is used to indicate that the media is mixed by a plurality of media components. media.
  • the description of the characterization information in the SDP offer can be identified in the m-line or rtpmap attribute line using a uniform identifier.
  • the description of the TS characterization information is as follows:
  • port is the port that receives the media component
  • nl is the dynamic code assigned to the media, the allocation has been described in the relevant specification, and can be queried in RFC3551.
  • the fmtp attribute line is usually followed by a media line or rtpmap attribute line describing the media characterization information. Take the TS stream as an example. The description can be:
  • TS-description-x identifies the xth fmtp attribute line for TS.
  • N fmtp attribute lines declare all or part of the media components of the TS.
  • the fmtp attribute line can be expressed as:
  • the attribute description type generally uses a string without spaces; the attribute value can be a string or a value without a space character, and the list of multiple values can be separated by a comma; [] indicates that the attribute line can contain multiple description fields. Separated by a semicolon and a space character, this part is optional.
  • the extension of the fmtp attribute line may be as follows:
  • Expansion method 1 The internal media components of the media are classified, and each category is described.
  • a medium consisting of multiple media components may have multiple combinations of internal packages: there may be audio, video, and data; there may be multiple audios, and/or video; or multiple uses of the same Codec audio or video, etc. So you can classify the internal media components of the media into: audio, video, data, etc., and then use a description separately. The character is explained. For example, video-description, audeo-description, data-description, etc. can be used as the media description type; the attribute value can use the MIME type of the currently available media component.
  • the TS internal media component is identified by codecl, codec2, codec3 codecM, and different media components may use the same codec, where codec2 and codecM are two audio formats, and the other is a video format, then the internal
  • the video-description, audeo-description, data-description and other attributes describe the type as just a symbol, and you can use other strings instead.
  • the choice of attribute values is not limited to RFC3551, and new MIME types for media formats and data formats registered with IANA can also be used.
  • the order of the fmtp attribute lines may be limited, thereby improving negotiation efficiency; or the order of the fmtp attribute lines may not be limited, and the same one in this case
  • the media may have multiple descriptions , but the internal media components are the same, and should be negotiated as the same media. It can be seen that this expansion mode is clean and clear.
  • Extension 2 The media components inside the media encapsulated by multiple media components are described separately, without category.
  • the TS in the extension mode 1 is still taken as an example.
  • each internal media component of the media includes at least the MIME type of each media component, and other optional parameters and/or required parameters related to the MIME type are followed by a comma.
  • the optional parameter in [] is generally the specific codec parameter of each media component, which can be sample rate or bitrate.
  • the extension method can also sort the description lines of the internal media components, thereby improving the negotiation efficiency; or not sorting.
  • Extension 3 Describe only the media components supported by the media provider.
  • extension is similar to extension one, except that the repeated MIME types need only be described once. For example, if codecl and codec3 are the same MPEG-2 video, you can describe it once, for example:
  • the expansion mode is more compact and practical than the expansion mode. Because the media is just a way of encapsulating multiple media components, the internal media components can be as many as It is often impractical to describe it. At the same time, if the media provider or receiver can decode one media component in the media, and of course, the other media components of the same encoding can be decoded one by one, so the same use It is feasible to describe the multiple media components of the codec only once.
  • extension manners may adopt a method of adding a media attribute, the added media.
  • the attribute is different from fmtp:
  • Extension 4 Refer to multiple new media attributes to categorize the media components. Still using the above example, the introduced new media attribute characters may be ts-video, ts-audio, ts-data, etc., and the internal video format, audio format, data format, etc. of the TS are classified and described as follows:
  • the [] part of the above description is optional. It is a detailed description of the media component codec parameters, which can be the sampling rate or compression ratio, etc.
  • the content and format can be codec encoded using RTP/AVP. Description of the specification.
  • the description of the media described above may be used by the SDP provider in the SDP offer during the negotiation process of the media, or may be provided by the SDP answerer in the SDP answer during the media negotiation process, but in general, the same
  • the SDP offer and the SDP answer used in the negotiation process are described in the same way.
  • HTTP Hypertext Link Markup Language
  • GET GET
  • DESCRIBE RTSP Description
  • GET request When a user requests media information from a server through a network (WEB) interface, a GET request may be used.
  • the support for the SDP protocol is stated in the GET request as follows:
  • the above method can be used to describe the specific information that the user will obtain the media.
  • the media provided by the network side as an example of TS
  • the TS and its internal media components are described as follows:
  • the media provided by the network side is TS-encapsulated, and there are three media components inside the TS, namely H.264 video, MPEG-2 video, and AMR-WB audio.
  • RTSP if the terminal requests media description information from the server, the following DESCRIBE request can be initiated:
  • the server can return the following SDP message:
  • the foregoing description of the media is performed for a medium, that is, the media in the SDP negotiation process has only one MIME type; when for multiple media, that is, media corresponding to different MIME types.
  • m video 34568 RTP/AVP 102,104,111
  • the SDP message describes two TS streams: a TS consisting of H.264 video and AC-3 audio, the corresponding MIME type is TS-H264-AC3; a TS consisting of H.264 video and MPEG-2 audio internally.
  • the corresponding MIME type is TS-H264-MPA.
  • the SDP provider After performing the above process of describing the media mixed with the plurality of media components, the SDP provider sends the SDP offer containing the description information to the SDP responder, the SDP responder root The SDP offer returns an SDP answer reflecting the media capabilities of its media recipient to the SDP offer.
  • the SDP responder returns an SDP answer reflecting the media capability of the media receiver to the SDP offer according to the SDP offer: the SDP responder confirms each media line in the SDP offer, ie, m rows, according to the media capability of the media receiver. , then return to SDP answer.
  • the media receiver supports the encapsulation of media with multiple media components mixed, and also supports the encoding and decoding format of all media components within the media, then uses the same m-line and a-line partial response in SDP answer. Only the UDP port needs to be reassigned.
  • a TS-description ⁇ codexl, codec2, codecM>
  • codec2 codecM>
  • the first case described above is successful negotiation.
  • the media receiver supports encapsulation of media with multiple media components, but only supports the encoding and decoding format of the media components of the media.
  • the media receiver only supports codec2.
  • codecM encapsulated TS, but does not support codecl's codec format
  • the SDP responder returns the media components supported by the local media receiver only in the a line. If the provider of the TS does not support the demultiplexing function for the TS, the TS provider and the TS receiver still cannot use the TS for media transmission. In this case, the two parties can perform SDP negotiation on other media different from the TS.
  • the negotiation method belongs to the prior art and will not be described here.
  • the SDP provider can regenerate the SDP offer based on the received SDP answer.
  • the SDP offer can still use the TS stream as the transmission format, and its internal media component is codec2, ⁇ , codecM. In this way, only one set of transmission parameters can be used for TS communication, which saves network port resources;
  • the offer can also split the m lines and transmit different internal media components, but this method will occupy more network port resources.
  • the third case the media receiver does not support the encapsulation of media with multiple media components mixed.
  • the SDP provider can re-initiate the SDP offer according to the received SDP answer to describe the media supported by the SDP responder, and perform the above steps cyclically until the negotiation succeeds or fails.
  • the re-initiated SDP offer may have no description of the TS encapsulation capability, and is changed to an encapsulation format of an internal media component supported by the TS receiver, or another separate media format.
  • the negotiation fails.
  • the foregoing description is based on the description of the media sent by the media sender by the SDP offer by the SDP provider, and the SDP respondent describes the media capability of the media receiver by using the SDP answer as an example, and the method is not limited thereto.
  • the same applies to SDP The media recipient's media capabilities are described by the SDP offer, and the SDP respondent describes the media sender's media capabilities through SDP answer.
  • the above negotiation process can be used to negotiate media mixed with multiple media components in a SIP environment.
  • the SDP providing/responding mechanism is used to agree on media mixed with multiple media components.
  • a typical SIP signaling interaction process can be as follows:
  • Step 201 Device A sends a SIP invite message (INVITE) to device B.
  • Step 202 Device B responds to device A with a message in progress (183 Session In Progress);
  • Step 203 Device A sends a transmission reliability message (PRACK) to device B.
  • PRACK transmission reliability message
  • Step 202 and step 203 are mainly used for the negotiation process of bandwidth, resources, and the like.
  • Step 204 The device B sends a message (200 0K) indicating that the agreement is reached and the session is established to the device A.
  • Step 205 Device A returns a session establishment response (ACK) to device B.
  • ACK session establishment response
  • the device A may serve as an SDP provider, and the device B serves as an SDP responder, and the SDP offer is provided in the initial INVITE in step 201, and the SDP answer may be In step 202, 183 is provided in Session In Progress, and may also be provided in step 200 in 200K.
  • Device B may be used as the SDP provider, and device A may be the SDP responder.
  • the SDP offer may be in step 202.
  • the SDP answer may be provided in PRACK in step 203 or in ACK in step 205.
  • the system includes: an SDP provider 301 and an SDP responder 302.
  • SDP provider 301 describes media mixed with multiple media components, and will include The SDP offer of the description information is sent to the SDP responder 302; if no negotiation is successful and no negotiation fails, the SDP offer is regenerated according to the SDP answer;
  • the SDP responder 302 returns an SDP answer reflecting the media capabilities of the SDP responder device to the SDP provider 301 based on the SDP offer.
  • the SDP provider may be the sender of the media, may be the recipient of the media, or may be a separate device that knows the media information, and/or the media sender or receiver media capabilities.
  • the SDP responder may be the recipient of the media, may be the sender of the media, or may be a separate device that is aware of the media recipient or sender media capabilities.
  • the SDP responder and the SDP provider can use the methods provided in the above embodiments to describe media mixed with a plurality of media components or to negotiate media mixed with a plurality of media components.
  • the SDP provider includes: a description unit 401, a transceiver unit 402, and a determining unit 403;
  • a description unit 401 describing a plurality of media components mixed media, and providing an SDP offer containing the description information to the transceiver unit 402; and regenerating the SDP offer according to the SDP answer provided by the determining unit 403 to the transceiver unit 402;
  • the transceiver unit 402 sends the SDP offer provided by the description unit 401; the receiving SDP answer is provided to the determining unit 403;
  • the determining unit 403 determines the negotiation result according to the SDP answer provided by the transceiver unit 402. If no negotiation succeeds and no negotiation fails, the SDP answer is provided to the description unit 401.
  • the SDP provider can be the sender of the media, or the recipient of the media, or a separate device that knows the media information, and/or the media sender's media capabilities.
  • the negotiation is determined.
  • FIG. 5 is a structural diagram of an SDP responder according to an embodiment of the present invention.
  • the SDP responder may include: a receiving unit 501, a generating unit 502, and a sending unit 503.
  • the receiving unit 501 is configured to receive an SDP offer.
  • the generating unit 502 is configured to generate an SDP answer reflecting the media capability of the SDP responder device according to the description information of the media mixed by the plurality of media components included in the SDP offer.
  • the sending unit 503 is configured to send the SDP answer generated by the generating unit 502.
  • the generating unit 502 may include: an information parsing unit 504, a judging unit 505, an information describing unit 506, and an answer generating unit 507.
  • the information parsing unit 504 is configured to parse the description information of the media mixed with the plurality of media components included in the SDP offer.
  • the determining unit 505 is configured to determine, according to the parsing result of the information parsing unit 504, whether the SDP responder device supports the encapsulation of the media of the plurality of media components mixed by the SDP offer, and whether the media component of the media is supported. Codec format.
  • the information description unit 506 is configured to: when the determining unit 505 determines that the SDP responder device supports the encapsulation of the media in which the plurality of media components are mixed, and also supports the encoding and decoding formats of all media components in the media, using the SDP offer
  • the media line describes the characterization information of the media, describes all internal media components of the media in the attribute line, and reassigns the UDP port of the user data protocol; the determining unit 505 determines that the SDP responder device supports multiple media.
  • the attribute line is used to describe part of the media component supported by the SDP responder device; and the determining unit 505 determines the SDP responder device.
  • the use of the media line does not contain the representation of the mixed media.
  • the media internal media component is not described when the attribute line is any of the media internal media components of the media media component supported by the SDP responder device in the internal media component of the media.
  • the response generating unit 507 is configured to generate an SDP answer according to the description information of the information description unit 506.
  • the SDP provider describes the media mixed with the plurality of media components, and sends the SDP offer including the description information to the SDP respondent.
  • the SDP responder returns an SDP answer reflecting the local media capability to the SDP provider according to the SDP offer; if no negotiation succeeds and no negotiation fails, the SDP provider will regenerate the SDP offer according to the SDP answer, and loop the above steps until the negotiation Success or failure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

对媒体进行协商的方法、 系统和发送媒体描述信息的方法 技术领域
本发明涉及多媒体技术， 特别涉及一种对媒体进行协商的方法和系 统以及发送媒体描述信息的方法。 发明背景
随着网络技术的不断发展和人们生活需求的不断提高， 多媒体技术 已经成为通信技术中重要的部分。 下面对现有的多媒体技术中涉及到的 一些相关协议和技术做筒单的介绍。
实时传输协议（RTP )是互联网工程任务组（IETF )制定的多媒体 通信协议之一， 在请求注解（RFC ) 1889中定义， 通常与 RTP控制协议 ( RTCP )配合使用，为实时的音频、视频等数据提供端到端的传输功能。 由多媒体应用程序生成的音频和视频数据块被封装在 RTP信息包中，每 个 RTP信息包被封装在用户数据报协议（ UDP )消息段中， 然后再封装 在网际协议（IP )数据包中。 可封装在 RTP 消息包中的音视频格式在 RFC1890, RFC 3551等配置文件中声明， 而对 RTP传输过程的监听和 控制由 RTCP来完成。
实时流协议（RTSP )是一个应用层协议， 在 RFC2326 中定义， 用 于建立和控制媒体的传输， 它本身不参与媒体的传输， 而是用于媒体服 务器与用户端的远程控制。 RTSP具有易解析、可重用 Web的安全机制、 与传输层无关的特性， 通过与诸如 RTP、 资源预留协议（RSVP )等更 低层的协议一起， 提供基于 Internet的整套流化服务。
会话描述协议（SDP )在 RFC2327中定义， 其作用是对多媒体会话 的内容进行描述。 描述范围包括两部分： 其一是会话级， 对整个多媒体 会话进行说明， 如会话发起者信息、 媒体连接地址、 传输网络类型等； 其二是媒体级，对该会话中可能存在的各个媒体进行描述，如媒体格式、 传输参数、 媒体连接地址等。 通过使用 RTP/音频视频配置（AVP ) 中的 媒体格式声明 RFC 3551以及 SDP的提供 /应答模型， SDP可在会话建立 或 /和更新的过程中完成媒体参数的协商， 为之后的媒体做好准备。
下面举一个包括会话级和媒体级的描述行的 SDP消息， 表示如下： v=0
o=- 2987933615 2987933615 IN IP6 5555::1:2:3:4
s=- c=IN IP6 5555:1:2:3:4
t=907165275 0 //前五行构成开头， v是版本号 0, o是与会者标识， s为会话标题， c为连接属性， t为会话建立时间和时长， 后面的 0表示 会话的结束标识为 bye的发起。
m=audio 3458 RTP/AVP 0 96 97 98
a=rtpmap:0 PCMU
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
a=rtpmap:98 telephone-event 〃第一种流： 音频， 端口 3458 ,
RTP/AVP传输协议， 编号 0,96,97,98, 分别表示 PCMU, G.726和 AMR 语音编码格式
m=video 3400 RTP/AVP 99 101
a=rtpmap:99MPV
a=rtpmap:101 H.261 〃第二种流： 视频， 端口 3400, RTP/AVP 传输， 编号 99, 101 , 分别表示 MPEG1/MPEG2 Video和 H.261编码格 式
m=video 3456 RTP/AVP 103 121
a=sendonly
a=rtpmap:103 H.261
a=rtpmap:121 MPV //第三种流： 视频， 端口 3456 ,
RTP/AVP传输，编号 103, 121 ,分别表示 MPEG1/MPEG2 Video和 H.261 编码格式。 上述消息的前 5行是多媒体会话级的描述， 包括消息发起者的相关 信息， 会话信息， 以及会话级的网络状况； 后面是对支持的媒体类型的 描述， 相关说明如下：
m=<媒体类型>〈端口 > <传输协议> <格式列表>
m行为媒体行， 其中，媒体类型可以是音频（ audio )、视频（ video )、 应用程序 ( application ), 数据 ( data ), 控制程序 ( control )等； 端口是 多媒体接收端口， 若媒体使用分层编码和传输， 则后面需要加上端口的 个数； 传输协议可以是 RTP/AVP、 或者 UDP; 格式列表是该消息的发送 者所能支持的媒体格式， 中间用空格分开。
c = <网络类型> <地址类型> <连接地址>
其中， 网络类型， 对于网络电视（IPTV )来说一般是因特网 （IN ); 地址类型可以是互联网协议版本 4( IPv4 )或者互联网协议版本 6( IPv6 ); 连接地址为多媒体接收地址， 对组播方式， 地址后面应该有生存时间 ( TTL )参数。 如果组播源使用分层编码， 则一个流可能出现多个组播 地址， 因此 TTL后面还可以有组播地址的个数说明， 各项之间用 "/" 分隔； 单播方式不允许使用 "/"。
a = <二进制属性 > 该二进制属性用于表明该属性是媒体特征之一， 如： a = recvonly , 表明该媒体只用于接收。
a = <属性类型 >:<属性值 >
其中， 属性类型是媒体属性行主要的扩展途径， 可以有很多名称， 如： 定义媒体与属性值对应关系的属性类型（rtpmap ), 定义媒体内部格 式与属性值对应关系的属性类型 （fmtp )等； 属性值是给该媒体属性指 配的值， 与属性类型相关。 a行统称为属性行， 其中 a = rtpmap行称为 rtpmap属性行； a = fmtp行称为 fmtp属性行。
由上面示例可以看出， 示例 SDP消息描述了三个媒体， UDP端口 3459 上传输的是一个音频流， 可选的方案为 μ -律脉沖编码调制 ( PCMU )、 国际电联音频编码标准 G系列（G.726 )、 自适应多速率宽带 编码标准（ AMR-WB )或者电话语音信号； 端口 3400和 3456分别传输 一个视频流， 其中端口 3456仅用于视频流的发送， 不接收对方发送来 的媒体。
为适应新的需求， 往往需要对 SDP协议进行扩展， 最通用的扩展方 法为 a行扩展， 来定义新的媒体属性类型以及相关的属性值。 例如： a = des: qos 和 a = curr： qos行用于对会话两端的资源预留进行协商； a = fmtp: value描述行用于对媒体格式进行更详细的说明， 其描述的具体 内容可以不被协议所约束。
会话初始化协议（ SIP )是用于建立、 改变或结束多媒体会话的应用 层协议， 与 SDP、 RTSP、 域名系统（DNS )等协议的配合， 共同完成会 话建立及媒体协商； 一旦建立会话，媒体将使用 RTP在承载层中直接传 送，在一次会话中可以灵活的交互多种媒体。由于 SIP基于公开的 Internet 标准， 在语音、 数据业务结合和互通方面具有很大优势， 能跨越媒体和 设备时限呼叫控制， 支持丰富的媒体格式， 可动态增 /删媒体， 容易实现 更加丰富的业务特性， 同时， SIP 支持智能化业务和终端侧发展从而减 轻网络负担， 其本身支持包括动态注册机制、 位置管理机制、 重定向机 制等应用层移动性功能， 便于扩展新业务， 而且协议筒单， 具有公认的 扩展潜力， 因此获得了包括在 IP多媒体子系统（ IMS )及下一代通信网 络（ NGN ) 中的越来越多的应用。
会话通告协议（SAP )是为了通知一个多播的多媒体会议或其它多 播会话而将相关的会话建立信息发送给所期望的会议参与者。 SAP本身 不建立会话， 它只是将建立会话所必要的信息， 例如， 所采取的视频或 音频编码方式通知给其它在一个多播内的参与者， 当参与者收到该通知 数据包后就可以启动相应的工具并设置正确的参数向该会议的发起者 建立会话了。
传输流（TS )是一种媒体封装格式， 为实现多路运动图像专家组压 缩标准版本 1 ( MPEG-1 ) /运动图像专家组压缩标准版本 2 ( MPEG-2 ) 的音视频流在单个传输通道上传输， TS 被设计为一种多路复用机制。 TS是将多种媒体成分进行打包封装在 TS包中形成的媒体， 一个 TS中 可能有多种媒体成分， 例如， 可能包含音频、 视频、 以及数据。 每一种 媒体成分中可能有不同的格式， 例如： 一个 TS 中包含的视频可能是 H.264格式和 MPEG-2格式的。相比单个媒体成分的媒体使用单独的 RTP 传输参数， 在 TS机制下， 多种媒体成分只占用一个通道， 使用一套传 输参数边可以传输， 节省了网络中的端口资源。
在多媒体应用中， IETF制定了一系列 RFC规范来对于各种音频 /视 频编码格式进行说明。 并且， SDP通过与 SIP、 SAP等其它协议配合， 使用提供 /应答模型可以为这些媒体在网络上实现端到端的 RTP传输提 供一套交互机制。
仍以上述例子进行说明，多媒体会话的一个 SDP提供者可能发出一 个 SDP提供消息 （SDP offer ), 包含如下内容：
v=0
o=- 2987933615 2987933615 IN IP6 5555:: 1 :2:3:4
s=- c=IN IP6 5555:1:2:3:4 //媒体接收地址
1=907165275 0 II SDP头部， 标识提供者的相关网络 和时间信息
m=audio 3458 RTP/AVP 0 96 97 98
a=rtpmap:0 PCMU
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
a=rtpmap:98 telephone-event 〃第一个；巟： 用于语音交谈 m=video 3400 RTP/AVP 98 99
a=rtpmap:98 MPV
a=rtpmap:99 H.261 //第二个流： 用于视频
m=video 3456 RTP/AVP 98 99
a=sendonly
a=rtpmap:98 H.261
a=rtpmap:99 MPV //第三个流： 单向发送的视频流 SDP应答者对该 SDP offer中相关的媒体类型和属性进行分析， 同 时结合自身支持的媒体格式， 返回一个 SDP应答消息（SDP answer )来 描述自身对于 SDP提供者提供的媒体的支持能力。针对上面的例子， 该 SDP answer可以是：
v=0
o=- 12357924 1357924 IN IP6 5555::5:6:7:8
s=- c=IN IP6 5555:5:6:7:8 t=907165275 0 // SDP头部， 标识应答者的相关网络 和时间信息
m=audio 4011 RTP/AVP 96 97 98
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AMR-WB
a=rtpmap:98 telephone-event 〃第一个；巟： 用于语音交谈, 不支 持编码 PCMU
m=video 4012 RTP/AVP 99
a=rtpmap:99 H.261 //第二个流： 用于视频， 不支持编码 MPV
m=video 0 RTP/AVP 98 〃第三个流： UDP端口为 0, 表示不支持 该视频流
上面所述的 SDP提供 /应答模型要求 SDP offer和 SDP answer中的 m 行数必须严格一致， 也就是说， SDP应答者必须对 SDP提供者提供的 SDP offer 中的每个 m行进行应答。 然后， SDP提供者继续根据 SDP answer生成反映 SDP应答者支持的媒体的 SDP offer, 这种 SDP提供 / 应答机制可以在多次媒体协商过程中循环执行， 直至协商成功或失败。
由以上可以看出， 现有技术已经给出了一种 SDP交互机制， 为各种 已经注册了多用途网络邮件扩展（MIME )类型的媒体格式提供了一种 协商的方法， 但是对于多种媒体成分混装的媒体的协商并没有给出完整 的解决方案。 发明内容
本发明实施例提供了一种发送媒体描述信息的方法， 以便于对多种 媒体成分混装的媒体描述信息进行发送。 提供了一种对媒体进行协商的 方法、 系统、 SDP提供者和 SDP应答者， 以便于对多种媒体成分混装的 媒体进行协商。
一种发送媒体描述信息的方法， 该方法包括：
在会话描述协议 SDP中，对多种媒体成分混装的媒体表征信息进行 描述， 以及对多种媒体成分混装的媒体内部媒体成分进行描述形成描述 信息， 发送该描述信息。
一种对媒体进行协商的方法， 该方法包括：
SDP提供者对多种媒体成分混装的媒体进行描述， 并将包含描述信 息的 SDP提供消息 SDP offer发送给 SDP应答者； SDP应答者根据该 SDP offer向 SDP提供者返回反映 SDP应答者端设备媒体能力的 SDP应 答消息 SDP answer; 如果协商成功或失败， 结束流程； 如果没有协商成 功且没有协商失败， SDP提供者将根据该 SDP answer 重新生成 SDP offer, 循环上述步骤， 直至协商成功或失败。
一种对媒体进行协商的系统， 该系统包括： SDP提供者和 SDP应答 者；
SDP提供者， 对多种媒体成分混装的媒体进行描述， 并将包含描述 信息的 SDP offer发送给 SDP应答者； 如果没有协商成功且没有协商失 败， SDP提供者将根据该 SDP answer重新生成 SDP offer;
SDP应答者，根据该 SDP offer向 SDP提供者返回反映 SDP应答者 端设备媒体能力的 SDP answer。
本发明实施例提供了一种 SDP提供者， 该 SDP提供者包括： 描述 单元、 收发单元、 以及判断单元；
描述单元， 对多种媒体成分混装的媒体进行描述， 并将包含描述信 息的 SDP offer提供给收发单元； 根据判断单元提供的 SDP answer重新 生成 SDP offer提供给收发单元；
收发单元，将描述单元提供的 SDP offer发送出去；接收 SDP answer 提供给判断单元；
判断单元， 根据收发单元提供的 SDP answer判断协商结果， 如果 没有协商成功且没有协商失败， 将该 SDP answer提供给描述单元。
一种 SDP应答者， 该 SDP应答者包括：
接收单元， 用于接收 SDP offer;
生成单元，用于根据所述 SDP offer中包含的多种媒体成分混装的媒 体的描述信息， 生成反映 SDP应答者端设备媒体能力的 SDP answer; 发送单元， 用于发送所述生成单元生成的 SDP answer。
由以上技术方案可以看出， 本发明通过对多种媒体成分混装的媒体 进行外部的封装和内部媒体成分的描述， 并且 SDP提供者和 SDP接收 者使用该描述方法分别发送 SDP offer和 SDP answer来对该多种内体成 分混装的媒体进行协商， 以此， 方便于实现多种媒体成分混装的媒体进 行协商。 附图筒要说明
图 1为本发明实施例提供的对媒体进行协商的方法流程图； 图 2为本发明实施例提供的一个典型的 SIP信令交互过程图； 图 3为本发明实施例提供的对媒体进行协商的系统结构图 图 4为本发明实施例提供的 SDP提供者的结构图；
图 5为本发明实施例提供的 SDP应答者的结构图。 实施本发明的方式
为了使本发明的目的， 技术方案、 以及优点更加清楚， 下面结合具 体实施例对本发明进行详细描述。
在一个多媒体会话中， 双方需要就是否使用多种媒体成分混装的媒 体作为传输媒体进行协商。 本发明实施例中使用 SDP描述、 以及 SDP 的提供 /应答机制进行该协商过程。
如图 1所示， 本发明实施例提供的对媒体进行协商的方法主要包括 以下步骤：
步骤 101 : SDP提供者对多种媒体成分混装的媒体进行描述， 并生 成包含该描述信息的 SDP offer。
步骤 102: SDP提供者将生成的 SDP offer发送给 SDP应答者。 步骤 103: SDP应答者根据该 SDP offer向 SDP提供者返回反映 SDP 应答者端设备媒体能力的 SDP answer。
步骤 104: 如果协商成功或失败， 结束流程； 如果没有协商成功且 没有协商失败， SDP提供者根据返回的 SDP answer重新生成 SDP offer, 循环执行上述步骤 102-104, 直到协商成功或失败。
其中， 所述多种媒体成分混装的媒体为： 该媒体内部具有多种编解 码配置的媒体成分， 例如， 其内部的媒体成分可以包含： 视频、 音频、 应用程序、 数据等， 视频可以是 MPEG-2视频、 H.264视频等， 音频可 以是 MPEG-2音频、 AC-3音频等， 或者是这些情况的组合。
其中， SDP提供者可以是该媒体的发送方， 可以是媒体的接收方， 也可以是知晓该媒体信息、和 /或该媒体发送方或接收方媒体能力的单独 装置； SDP应答者可以是该媒体的接收方， 可以是媒体的发送方， 也可 以是知晓该媒体接收方或发送方媒体能力的单独装置。
该协商过程可以是在发送媒体前对所发送的媒体进行的协商， 也可 以是在不发送媒体的情况下仅针对媒体发送方和接收方媒体能力的协 商。下面均以 SDP提供者描述媒体提供方提供的媒体， SDP应答者描述 媒体接收方媒体能力的协商过程为例。 SDP offer是对媒体提供者提供的多种媒体成分混装的媒体或者媒 体提供者的自身能力进行描述， 该对多种媒体成分混装的媒体进行的描 述主要包括两个方面：
I. 对多种媒体成分混装的媒体表征信息进行描述， 也就是对多种媒 体成分混装的媒体进行外部的封装， 该表征信息是用来表征该媒体是由 多种媒体成分混装的媒体。
在 SDP offer中对该表征信息的描述可以使用一个统一的标识符在 m行或者 rtpmap属性行中进行标识。 例如， 对于 TS可以使用符号 TS 在 a = rtpmap行中进行标识， 该符号与其它已注册的 MIME类型一样， 可以被 SDP协议接受。 对该 TS表征信息的描述语句如下：
m= video port RTP/AVP nl
a=rtpmap:nl TS
其中， port为接收该媒体成分的端口； nl是分配给该媒体的动态编 码， 该分配在相关规范中已有说明， 可以在 RFC3551中查询。
在 m行对 TS进行标识的方法可以是：在 RTP/AVP配置中将某个未 被使用的净荷类型 （payload type )静态地指配给 TS, 如 29, 则相关的 TS表征信息可描述如下： m=video port RTP/AVP 29 这种方法不需要使用媒体行后面的 rtpmap属性行对 29号媒体进行 描述， 因为前面的编码 nl是动态地指配， 可以为任何注册了的 MIME 类型所用， 而 29号已经被固定指配给 TS了， 在媒体行即可将 TS的表 征信息描述清楚。
II. 对多种媒体成分混装的媒体内部媒体成分进行描述。 在 SDP 中 可以采用对 fmtp属性行， 即 a = fmtp行进行扩展的形式， 说明该多媒体 内部的媒体成分。 fmtp属性行通常在对该媒体表征信息进行描述的媒体 行或者 rtpmap属性行后面。 以 TS流为例， 其描述可以为：
m= video port RTP/AVP nl
a=rtpmap:nl TS
a=TS-description- 1
[a=TS-description-2]
[a=TS-description-N]
其中，方括号表示可选项， TS-description-x标识对 TS的第 x个 fmtp 属性行。 这 N个 fmtp属性行声明了该 TS的全部或者部分媒体成分。
其中的 fmtp属性行具体可以表述为：
a = fmtp: <MIME类型 > <属性描述类型 >=<属性值 > [； <属性描述类 型 >=<属性值 >]
其中的属性描述类型一般使用无空格的字符串； 属性值可以是没有 空格符的字符串或者数值， 多个值的列表可以使用逗号隔开； []表示该 属性行可以包含多个描述字段， 之间使用分号和空格符隔开， 该部分为 可选项。
所述对 fmtp属性行的扩展方式可以有以下几种：
扩展方式一： 将该媒体的内部媒体成分进行分类， 分别对各类进行 描述。
因为一个由多种媒体成分组成的媒体可能内部的封装有多种组合： 可能既有音频、 又有视频、 还有数据； 可能有多个音频、 和 /或视频； 也 可能包含多个使用相同编解码的音频或视频等。 所以可以将该媒体内部 媒体成分分类为： 音频类、 视频类、 数据类等， 然后分别使用一个描述 符进行说明。 例如 , 可以使用 video-description、 audeo-description、 data-description 等作为媒体描述类型； 属性值可以使用当前可用的媒体 成分的 MIME类型。仍以 TS为例，该 TS内部媒体成分用 codecl、 codec2、 codec3 codecM进行标识， 不同媒体成分可能采用相同的编解码， 其中， codec2和 codecM为两种音频格式， 其它为视频格式， 那么该内 部媒体成分可以描述为： m=video protl RTP/AVP nl
a=rtpmap:nl TS
a=fmtp:nl video-description=codecl, codec3, codecM; audio-description=codec2, codec4 从上述例子中可以看出在使用这种扩展方式时， 媒体内部的媒体成 分在 a = fmtp行中都有体现，即使内部有些媒体成分采用相同的编解码， 也同样适用，比如， codecl和 codec3都可以是 MPEG - 2视频，其 MIME 类型为 MPV。
另外， 在本例子中没有 data类型的数据， 所以 data-description字段 为空。
其中的 video-description, audeo-description , data-description等属性 描述类型只是一种符号， 还可以使用其它字符串代替。 属性值的选择也 不仅局限于 RFC3551 ,新的在 IANA注册的媒体格式、数据格式的 MIME 类型也可以使用。
在采用该扩展方式对该媒体内部媒体成分进行描述时， 可以对上述 fmtp属性行的顺序进行限定， 从而提高协商效率； 也可以不对上述 fmtp 属性行的顺序进行限定， 这样种情况下的同一个媒体可能有多种描述形 式， 但其内部的媒体成分是一样的， 应该作为同一种媒体进行协商。 可以看出， 这种扩展方式筒洁明了。
扩展方式二： 依次对多种媒体成分封装的媒体内部的媒体成分单独 进行描述， 而不分类别。
仍然采用扩展方式一中的 TS为例， 该扩展方式的描述可以为： m=video portl RTP/AVP nl
a=rtpmap:nl TS
a=fmtp:nl
ts=codecl[,samplerate=90000,bitrate=32000,...];ts=codec2[,codec2的格 式描述内容]; ... ts=codecM[,codecM的格式描述内容]
上述对该媒体各内部媒体成分的描述中至少要包含各媒体成分的 MIME类型， 其它与该 MIME类型相关的可选参数和 /或必选参数以逗 号方式紧随其后。 []中为可选参数， 一般为各媒体成分的具体编解码参 数， 可以为采样率（samplerate )或压缩比率 （bitrate )等。
与扩展方式一相似的， 该扩展方式也可以对内部各媒体成分的描述 行进行排序， 从而提高协商效率； 也可以不进行排序。
这种扩展方式更加灵活 , 可以将各个内部媒体成分描述的更加清楚 详细。
扩展方式三： 仅描述媒体提供者所支持的媒体成分。
这种扩展方式与扩展方式一类似， 不同的是对于重复的 MIME类型 只需描述一次。 例如， codecl和 codec3是同样的 MPEG-2视频， 就可 以进行一次描述， 例如：
a = fmtp:nl video-description=codec3,… , codeM
由以上可以看出， 该扩展方式相比较扩展方式一更加筒洁且实用。 因为媒体只是多种媒体成分封装的方式， 内部的媒体成分可以是任意多 个， 对其——描述往往不切实际， 同时， 如果媒体提供方或接收方能够 对该媒体中的一个媒体成分进行解码， 当然也能对相同编码的其它媒体 成分逐一解码， 所以对使用相同编解码的多个媒体成分只进行一次描述 是可行的。
以上所述三种扩展方式可以在 fmtp属性行， 即 a = fmtp行内， 对整 个媒体的内部媒体成分进行描述， 以下几种扩展方式可以采用新增媒体 属性符的方法， 所述新增的媒体属性符区别于 fmtp:
扩展方式四： 引用多个新的媒体属性符对媒体成分进行归类描述。 仍以上面例子进行说明， 引入的新的媒体属性符可以是 ts-video、 ts-audio、 ts-data等， 将 TS内部的视频格式、 音频格式、 数据格式等进 行分类描述， 描述如下：
m=video portl RTP/AVP nl
a=rtpmap:nl TS
a=ts-video:nl coded codec3 ...
a=ts-audio:nl codec2 ... codecM 扩展方式五： 引用一个新的媒体属性符逐一对内部成分进行描述。 上面的例子可以描述如下：
m=video portl RTP/AVP nl
a=rtpmap:nl TS
a=ts:nl coded [samplerate=90000] [bitrate=32000] [...]
a=ts:nl codec2 [对 codec2的其他描述内容] a=ts:nl codecM [对 codecM的其他描述内容]
上面描述中 []部分为可选项， 是对媒体成分编解码参数的详细描述， 可以是采样率或压缩比率等，其内容和格式可以使用 RTP/AVP对编解码 的描述规范。 一个 a = ts: nl行只描述一个编解码格式。
上面所述的对媒体进行的描述可以用在对媒体进行协商过程中 SDP 提供者在 SDP offer中采用， 也可以在媒体进行协商过程中 SDP应答者 在 SDP answer中提供， 但一般情况下， 同一协商过程中的 SDP offer和 SDP answer中采用的描述方式相同。
另外， 上述对媒体进行的描述也可以在 HTTP、 RTSP等其它协议的 一些应用中使用， 且并不是以提供 /应答的交互机制出现， 而是在客户端 发起请求后返回一个 SDP消息， 该 SDP消息采用此描述方法来描述服 务器端的媒体能力。例如： 超文本链接标记语言（ HTTP )的获取（ GET ) 请求， 以及 RTSP的描述（ DESCRIBE )请求。 下面以 HTTP的 GET请 求和 RTSP的 DESCRIBE请求为例进行说明：
当用户通过网络（WEB )界面向服务器请求媒体信息时， 可能使用 GET请求。 该 GET请求中声明了对 SDP协议的支持， 如下：
GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
服务器对其返回的响应中， 可以采用上述方法对用户将要获取媒体 的具体信息进行描述。 以网络侧提供的媒体是 TS为例， 以上述扩展方 式二对 TS以及其内部的媒体成分进行描述如下：
HTTP/1.0 200 0K
Date: 23 Jan 2006 15:35:06 GMT
Content- Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session
e=adm@example.com
a=range:npt=0-l :49:34
t=0 0
m=video 0 RTP/AVP 99
a=rtpmap:99 TS
a=fmtp:99
ts=H264,profile-level-id=42A01E,packetization-mode=2;
ts=MPV/90000; ts=AMR-WB
a=control:rtsp：〃 video.example.com/twister/video.ts
该描述中， 说明网络侧提供的媒体是 TS封装的， TS内部有三种媒 体成分， 分别是 H.264视频、 MPEG-2视频以及 AMR- WB音频。
在 RTSP中， 如终端向服务器请求媒体描述信息， 则可以发起如下 的 DESCRIBE请求：
DESCRIBE rtsp：〃 video.example.com/concert/video.ts RTSP/2.0
CSeq: 1
Supported: play.basic, play. scale
对上述例子中所述媒体， 服务器可以返回如下 SDP消息：
RTSP/2.0 200 OK
CSeq: 1
Content- Type: application/sdp
Content-Length: 182
Server: Phony Server/1.0
Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=video 3456 RTP/AVP 99
c=IN IP4 224.2.0.1/16
a=rtpmap:99 TS
a=ts:99 H264 prof ile-level-id=42 AO 1 E packetization-mode=2 a=ts:99 MPV/90000
a=ts:99 AMR-WB
a=control: rtsp ://live .example . com/concert/video .ts
由以上描述可以看出， 上述对媒体进行的描述是针对一种媒体进行 的， 也就是在 SDP协商过程中的媒体仅有一种 MIME类型； 在对多种 媒体， 即对应不同 MIME类型的媒体时， 可以直接使用通常的 rtpmap 属性行即可。 例如：
. . .
m=video 34568 RTP/AVP 102,104,111
a=rtpmap:102 TS-H264-AC3
a=rtpmap:104 H264/90000
a=rtpmap: 111 TS-H264-MPA
. . .
该 SDP消息描述了两种 TS流： 内部由 H.264视频和 AC-3音频组 成的 TS ,对应的 MIME类型是 TS-H264-AC3；内部由 H.264视频和 MPEG - 2音频组成的 TS, 对应的 MIME类型是 TS-H264-MPA。
上述这种对多种媒体进行描述不用对 a行进行扩展， 但是对每种媒 体成分的编解码组合都必须在相关配置中说明。
进行了上述对多种媒体成分混装的媒体进行描述的过程后， SDP提 供者将包含该描述信息的 SDP offer发送给 SDP应答者， SDP应答者根 据该 SDP offer向 SDP提供者返回反映其媒体接收方媒体能力的 SDP answer。
所述 SDP应答者根据该 SDP offer向 SDP提供者返回反映其媒体接 收方媒体能力的 SDP answer为： SDP应答者根据该媒体接收方的媒体 能力对 SDP offer 中的各个媒体行即 m行进行确认， 然后返回 SDP answer。
下面将对 SDP应答者返回 SDP answer的过程进行描述。 根据该媒 体接收方的媒体能力该过程可以分为三种情况：
第一种情况： 该媒体接收方支持多种媒体成分混装的媒体的封装， 同时也支持该媒体内部所有媒体成分的编解码格式， 则在 SDP answer 中使用相同的 m行和 a行部分回应，只需要对 UDP端口进行重新指配。
在此以一个在 SDP offer中描述了 TS类型， 内部媒体成分有 M个， 分另1 J是 codecl , codec2, .·· , codecM, 其中 codec2和 codecM为音频格 式，其它为视频格式为例，该 SDP offer使用扩展 a行的方法对该媒体的 内部媒体成分进行描述， 如下： m=video portl RTP/AVP nl
a=rtpmap:nl TS
a=TS-description<codexl, codec2, codecM> 该例子中只使用一个 a行对 TS的内部媒体成分进行描述。 其描述 方式可以采用上面所述的几种对 a行的扩展方式进行描述。
在第一种情况下， SDP应答者使用相同的 m行和 a行对媒体接收者 的媒体能力进行描述， 如下： m=video port2 RTP/AVP n2 a=rtpmap:n2 TS
a=TS-description<codexl, codec2, codecM> 由上可以看出该 SDP answer中的描述信息仅仅接收端口号 port2和 动态分配的 AVP编号 n2与 SDP offer中的描述信息不同，在完成此 SDP answer的发送后， 此次对多种媒体成分混装的媒体的协商完成， 媒体提 供方和媒体接收方可以使用内部 codecl , codec2, .·· , codecM 混装的 TS流作为媒体传输格式。
上面所述第一种情况为协商成功。
第二种情况:该媒体接收方支持多种媒体成分混装的媒体的封装，但 是仅支持该媒体内部部分媒体成分的编解码格式， 比如在上面所述例子 中，媒体接收方仅支持 codec2,…， codecM封装的 TS,但是不支持 codecl 的编解码格式，则此时 SDP应答者对该 SDP offer返回如下 SDP answer: m=video port2 RTP/AVP n2
a=rtpmap:n2 TS
a=TS-description<codec2, codecM> 此时， SDP应答者仅在 a行返回本端媒体接收方支持的媒体成分。 如果该 TS的提供方不支持对 TS的解复用功能，则 TS提供方和 TS 接收方仍然不能使用该 TS进行媒体传输。 此时， 双方可以对不同于 TS 的其他媒体进行 SDP协商， 其协商方法属于现有技术， 在此不做赘述。
如果该 TS的提供方支持对 TS的解复用功能， 则 SDP提供者可以 才艮据收到的 SDP answer重新生成 SDP offer。 此时的 SDP offer可以仍然 以 TS流为传输格式， 其内部媒体成分为 codec2, ··· , codecM, 这种方 式只使用一套传输参数即可进行 TS的交流，节省了网络端口资源； SDP offer也可以对 m行进行拆分，分别传输不同的内部媒体成分，但这种方 式会占用较多网络端口资源。 此时的 SDP offer可以为： m=audio port22 RTP/AVP n22
a=rtpmap:n22 codec2
m=video port23 RTP/AVP n23
a=rtpmap:n23 codec3 m=audio port2M RTP/AVP n2M
a=rtpmap:n2M codecM 上述第二种情况中 ,如果 SDP应答者端设备支持所述多种媒体成分 混装的媒体， 但是不支持该媒体内部任何一种媒体成分时， 协商失败。
第三种情况：该媒体接收方不支持多种媒体成分混装的媒体的封装。 此时， SDP应答者可以按照现有技术中的方法进行通常的 SDP应答，将 m行的端口设为 0。 如果该媒体的接收方虽然不支持多种媒体成分混装 的媒体的封装， 但是支持其中的几种媒体成分， 那么可以通过 SDP answer将该媒体能力反映出来。 仍以上面所述例子进行说明， 若媒体接 收者不支持 TS的封装，但是支持其中的 codecl视频， 则 SDP应答者返 回的 SDP answer可以是： m=video port21 RTP/AVP n21
a=rtpmap:n21 codecl 如果媒体接收方同时支持音频 codec2, 则要看在 SDP offer中有没 有相应的 m行对音频进行描述， 如果有， 则 SDP answer也可以通过相 应的 m行将 codec2反映出来， 具体如下：
如果 SDP offer为： m=video portl RTP/AVP nl
a=rtpmap:nl TS
a=TS-description<codecl, codec2, codecM>
m=audio portl 1 RTP/AVP nil
a=rtpmap:nll codecX 其 SDP answer为： m=video port21 RTP/AVP n21
a=rtpmap:n21 coded
m=audio port22 RTP/AVP n22 n23
a=rtpmap:n22 codecX
a=rtpmap:n23 codec2
SDP提供者接收到该 SDP answer之后，可以根据收到的 SDP answer 重新发起 SDP offer对 SDP应答者端的支持的媒体进行描述， 循环执行 上述步骤， 直至协商成功或失败。 其中， 重新发起的 SDP offer可以没 有对该 TS封装能力的描述，改为 TS接收方支持的内部媒体成分的封装 格式， 或者另外的单独的媒体的格式。
上述第三种情况中，如果 SDP应答者端设备不支持所述多种媒体成 分混装的媒体， 也不支持该媒体内部任何一种媒体成分时， 协商失败。
以上描述均是以 SDP提供者通过 SDP offer对媒体发送方发送的媒 体进行描述， SDP应答者通过 SDP answer对该媒体接收方的媒体能力 进行描述为例进行的说明， 该方法并不限于此， 也同样适用于 SDP提供 者通过 SDP offer对媒体接收方媒体能力进行描述， SDP应答者通过 SDP answer对媒体发送方媒体能力进行描述等情况。
上述协商过程可以用于在 SIP环境下对多种媒体成分混装的媒体进 行的协商。 在 SIP会话建立过程中使用 SDP提供 /应答机制针对多种媒 体成分混装的媒体达成一致， 如图 2所示， 一个典型的 SIP信令交互过 程可以为以下步骤：
步骤 201: 设备 A向设备 B发送 SIP邀请消息 （INVITE );
步骤 202:设备 B向设备 A回应一个会话进行中的消息（ 183 Session In Progress );
步骤 203: 设备 A向设备 B发送传输可靠性消息 （PRACK );
其中步骤 202和步骤 203主要用于对带宽和资源等的协商过程。 步骤 204:设备 B向设备 A发送表征达成一致、会话建立的消息（ 200 0K );
步骤 205: 设备 A向设备 B返回会话建立响应 （ACK )。
在以上步骤中， 对多种媒体成分封装的媒体进行协商时， 设备 A可 以作为 SDP提供者， 设备 B作为 SDP应答者， SDP offer在步骤 201中 初始的 INVITE中提供，此时 SDP answer可以在步骤 202中 183 Session In Progress中提供， 也可以在步骤 204中 200 0K中提供； 也可以为设 备 B作为 SDP提供者， 设备 A作为 SDP应答者， 此时 SDP offer可以 在在步骤 202中 183 Session In Progress中或在步骤 204中 200 0K中提 供， SDP answer可以在在步骤 203中 PRACK或在步骤 205中 ACK中 提供。
下面对本发明实施例提供的对媒体进行协商的系统进行详细说明。 如图 3所示， 该系统包括： SDP提供者 301和 SDP应答者 302。
SDP提供者 301 , 对多种媒体成分混装的媒体进行描述， 并将包含 该描述信息的 SDP offer发送给 SDP应答者 302; 如果没有协商成功且 没有协商失败， 则根据 SDP answer重新生成 SDP offer;
SDP应答者 302,根据该 SDP offer向 SDP提供者 301返回反映 SDP 应答者端设备媒体能力的 SDP answer。
其中， 所述 SDP提供者可以是该媒体的发送方， 可以是媒体的接收 方， 也可以是知晓该媒体信息、 和 /或该媒体发送方或接收方媒体能力的 单独装置。
所述 SDP应答者可以是该媒体的接收方， 可以是媒体的发送方， 也 可以是知晓该媒体接收方或发送方媒体能力的单独装置。
SDP应答者和 SDP提供者可以使用上述实施例提供的方法对多种 媒体成分混装的媒体进行描述或对多种媒体成分混装的媒体进行协商。
下面对 SDP提供者的结构进行详细的描述， 如图 4所示， 该 SDP 提供者包括： 描述单元 401、 收发单元 402、 以及判断单元 403;
描述单元 401 , 对多种媒体成分混装的媒体进行描述， 并将包含描 述信息的 SDP offer提供给收发单元 402;根据判断单元 403提供的 SDP answer重新生成 SDP offer提供给收发单元 402;
收发单元 402,将描述单元 401提供的 SDP offer发送出去；接收 SDP answer提供给判断单元 403;
判断单元 403,根据收发单元 402提供的 SDP answer判断协商结果， 如果没有协商成功且没有协商失败， 将该 SDP answer提供给描述单元 401。
SDP提供者可以为所述媒体的发送方、 或所述媒体的接收方、 或知 晓所述媒体信息、 和 /或媒体发送方媒体能力的单独装置。
判断模块获取的 SDP answer 中如果有对所述媒体的表征信息进行 的描述又有对所述媒体的所有内部媒体成分进行的描述， 则判断协商成 功；
所述判断模块获取的 SDP answer 中如果没有对所述媒体的内部媒 体成分进行的描述， 则判断协商失败。
图 5为本发明实施例提供的 SDP应答者的结构图， 如图 5所示， 该 SDP应答者可以包括： 接收单元 501、 生成单元 502和发送单元 503。
接收单元 501 , 用于接收 SDP offer。
生成单元 502, 用于根据 SDP offer中包含的多种媒体成分混装的媒 体的描述信息， 生成反映 SDP应答者端设备媒体能力的 SDP answer。
发送单元 503 , 用于发送生成单元 502生成的 SDP answer。
其中， 生成单元 502可以包括： 信息解析单元 504、 判断单元 505、 信息描述单元 506和应答生成单元 507。
信息解析单元 504, 用于对 SDP offer中包含的多种媒体成分混装的 媒体的描述信息进行解析。
判断单元 505 , 用于根据信息解析单元 504的解析结果， 判断 SDP 应答者端设备是否支持该 SDP offer所描述的多种媒体成分混装的媒体 的封装， 以及是否支持该媒体内部的媒体成分的编解码格式。
信息描述单元 506, 用于在判断单元 505判断 SDP应答者端设备支 持多种媒体成分混装的媒体的封装， 同时也支持该媒体内部所有媒体成 分的编解码格式时， 使用与 SDP offer对应的媒体行对媒体的表征信息 进行描述， 在属性行对媒体的所有内部媒体成分进行描述， 对用户数据 才艮协议 UDP端口进行重新指配； 在判断单元 505判断 SDP应答者端设 备支持多种媒体成分混装的媒体的封装， 并且仅支持该媒体内部部分媒 体成分的编解码格式时，使用属性行对 SDP应答者端设备支持的部分媒 体成分进行描述；在判断单元 505判断 SDP应答者端设备不支持多种媒 体成分混装的媒体的封装时， 使用媒体行中不包含混装媒体的表征信 息，或仅在属性行对媒体的内部媒体成分中 SDP应答者端设备支持的媒 媒体成分混装的媒体内部媒体成分的任意一种时， 不对媒体内部媒体成 分进行描述。
应答生成单元 507,用于根据信息描述单元 506的描述信息生成 SDP answer。
由以上描述可以看出，在本发明实施例所提供的方法和系统中， SDP 提供者对多种媒体成分混装的媒体进行描述， 并将包含该描述信息的 SDP offer发送给 SDP应答者， SDP应答者根据该 SDP offer向 SDP提供 者返回反映其本端媒体能力的 SDP answer; 如果没有协商成功且没有协 商失败， SDP提供者将根据该 SDP answer重新生成 SDP offer, 循环上 述步骤， 直至协商成功或失败。 由此， 通过对多种媒体成分混装的媒体 进行外部的封装和内部媒体成分的描述， 方便于实现对多种媒体成分混 装的媒体进行协商。
以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均 应包含在本发明保护的范围之内。

Claims

权利要求书
1、 一种发送媒体描述信息的方法， 其特征在于， 该方法包括： 在会话描述协议 SDP中，对多种媒体成分混装的媒体表征信息进行 描述， 以及对多种媒体成分混装的媒体内部媒体成分进行描述形成描述 信息后， 发送该描述信息。
2、根据权利要求 1所述的方法， 其特征在于， 所述对多种媒体成分 混装的媒体表征信息进行描述为：在 SDP中使用一个统一的标识符在媒 体行或 rtpmap属性行进行标识。
3、根据权利要求 1所述的方法， 其特征在于， 所述多种媒体成分混 装的媒体为多个时， 所述对多种媒体成分混装的媒体表征信息进行描述 为： 在 SDP中采用多个 rtpmap属性行分别使用不同标识符、 或者采用 多个媒体行分别使用不同标识符进行所述对多种媒体成分混装的媒体 表征信息进行描述。
4、根据权利要求 1所述的方法， 其特征在于， 所述对多种媒体成分 混装的媒体内部媒体成分进行描述为： 在 SDP中采用对 fmtp属性行进 行扩展的形式、 或者采用在属性行新增属性符的形式对所述多种媒体成 分混装的媒体内部媒体成分进行描述。
5、 根据权利要求 4所述的方法， 其特征在于， 所述对 fmtp属性行 进行扩展为： 将所述媒体的内部媒体成分进行分类，在 fmtp属性行中分 别对各类媒体成分进行描述； 或者，
在 fmtp属性行中逐一对所述媒体内部的媒体成分单独进行描述；或 者，
在 fmtp属性行中仅描述本端设备支持的所述媒体内部媒体成分。
6、根据权利要求 4所述的方法， 其特征在于， 所述在属性行新增属 性符的形式为： 在属性行中引用多个新的属性符对所述媒体内部媒体成 分进行归类描述； 或者，
在属性行中引用一个新的媒体属性符逐一对所述媒体内部媒体成分 编解码参数进行描述。
7、根据权利要求 1所述的方法， 其特征在于， 所述多种媒体成分混 装的媒体为传输流 TS。
8、 一种对媒体进行协商的方法， 其特征在于， 该方法包括：
SDP提供者对多种媒体成分混装的媒体进行描述， 并生成包含该描 述信息的 SDP提供消息 SDP offer;
SDP提供者将所述生成的 SDP Offer发送给 SDP应答者；
SDP应答者根据该 SDP offer向 SDP提供者返回反映 SDP应答者端 设备媒体能力的 SDP应答消息 SDP answer;
如果协商成功或失败， 结束流程； 如果没有协商成功且没有协商失 败， SDP提供者将根据该 SDP answer重新生成 SDP offer, 并转至执行 所述 SDP提供者将所述生成的 SDP Offer发送给 SDP应答者的步骤，直 至协商成功或失败。
9、 根据权利要求 8所述的方法， 其特征在于， 所述 SDP提供者对 多种媒体成分混装的媒体进行描述为： SDP提供者对其本端设备所提供 或接收的多种媒体成分混装的媒体进行描述，或者 SDP提供者对其本端 设备的媒体能力进行描述。
10、 根据权利要求 8所述的方法， 其特征在于， 所述 SDP应答者 根据所述 SDP offer向 SDP提供者返回反映 SDP应答者端设备媒体能力 的 SDP answer包括： 当 SDP应答者端设备支持该 SDP offer所描述的多 种媒体成分混装的媒体的封装， 同时也支持该媒体内部所有媒体成分的 编解码格式时， SDP应答者在 SDP answer中使用与 SDP offer对应的媒 体行对所述媒体的表征信息进行描述， 在属性行对所述媒体的所有内部 媒体成分进行描述， 对用户数据报协议 UDP端口进行重新指配；
当 SDP应答者端设备支持多种媒体成分混装的媒体的封装，并且仅 支持该媒体内部部分媒体成分的编解码格式时， SDP应答者仅在 SDP answer 中的属性行对 SDP应答者端设备支持的所述部分媒体成分进行 描述；
当 SDP应答者端设备不支持多种媒体成分混装的媒体的封装时， SDP应答者在 SDP answer中的媒体行中不包含所述混装媒体的表征信 息，或仅在属性行对所述媒体的内部媒体成分中 SDP应答者端设备支持 的媒体成分进行描述；
当 SDP应答者端设备不支持该多种媒体成分混装的媒体内部媒体 成分的任意一种时， SDP应答者在 SDP answer中不对所述媒体内部媒 体成分进行描述。
11、 根据权利要求 10所述的方法， 其特征在于， 所述协商成功为： SDP应答者端设备支持多种媒体成分混装的媒体的封装， 同时也支持该 媒体内部所有媒体成分的编解码格式；
所述协商失败为： SDP应答者端设备不支持所述多种媒体成分混装 的媒体的所有内部媒体成分；
所述 SDP提供者将根据该 SDP answer重新生成 SDP offer包括： SDP 提供者重新对 SDP answer中反映的媒体能力的媒体进行描述生成 SDP offer„
12、 根据权利要求 8所述的方法， 其特征在于， 所述多种媒体成分 混装的媒体是 TS。
13、 一种对媒体进行协商的系统， 其特征在于， 该系统包括：
SDP提供者， 用于对多种媒体成分混装的媒体进行描述， 并发送包 含该描述信息的 SDP offer; 如果没有协商成功且没有协商失败， SDP提 供者将根据接收到的 SDP answer重新生成 SDP offer;
SDP应答者， 用于接收所述 SDP提供者发送的 SDP offer, 根据所 answer。
14、 根据权利要求 13所述的系统， 其特征在于， 所述 SDP提供者 是所述媒体的发送方，所述 SDP应答者是所述媒体的接收方，所述 SDP 应答者端设备为所述媒体的接收方； 或者，
所述 SDP提供者是所述媒体的接收方， 所述 SDP应答者是所述媒 体的发送方， 所述 SDP应答者端设备为所述媒体的发送方； 或者，
所述 SDP提供者是知晓所述媒体信息、 和 /或媒体发送方媒体能力 的单独装置，所述 SDP应答者是知晓所述媒体接收方媒体能力的单独装 置， 所述 SDP应答者端设备为所述媒体接收方。
15、 根据权利要求 13所述的系统， 其特征在于， 所述 SDP提供者， 还用于在接收到的 SDP answer 中有对所述媒体的表征信息进行的描述 又有对所述媒体的所有内部媒体成分进行的描述时， 判断协商成功； 在 接收到的 SDP answer中没有对所述媒体的内部媒体成分进行的描述时， 判断协商失败。
16、 一种 SDP提供者， 其特征在于， 该 SDP提供者包括： 描述单元， 用于对多种媒体成分混装的媒体进行描述， 生成包含该 描述信息的 SDP offer; 根据接收到的 SDP answer重新生成 SDP offer; 收发单元， 用于将所述描述单元生成的 SDP offer发送出去； 接收 SDP answer;
判断单元， 用于根据所述收发单元接收到的 SDP answer判断协商 结果，如果没有协商成功且没有协商失败，将该 SDP answer提供给所述 描述单元。
17、 根据权利要求 16所述的 SDP提供者， 其特征在于， 所述 SDP 提供者为所述媒体的发送方、 或所述媒体的接收方、 或知晓所述媒体信 息、 和 /或媒体发送方媒体能力的单独装置。
18、 根据权利要求 16所述的 SDP提供者， 其特征在于， 所述判断 单元，还用于在所述 SDP answer中有对所述媒体的表征信息进行的描述 又有对所述媒体的所有内部媒体成分进行的描述时， 判断协商成功； 在 所述 SDP answer中没有对所述媒体的内部媒体成分进行的描述时，判断 协商失败。
19、 一种 SDP应答者， 其特征在于， 该 SDP应答者包括： 接收单元， 用于接收 SDP offer;
生成单元，用于根据所述 SDP offer中包含的多种媒体成分混装的媒 体的描述信息， 生成反映 SDP应答者端设备媒体能力的 SDP answer; 发送单元， 用于发送所述生成单元生成的 SDP answer。
20、 根据权利要求 19所述的 SDP应答者， 其特征在于， 所述生成 单元包括：
信息解析单元，用于对所述 SDP offer中包含的多种媒体成分混装的 媒体的描述信息进行解析；
判断单元， 用于根据所述信息解析单元的解析结果， 判断 SDP应答 者端设备是否支持该 SDP offer所描述的多种媒体成分混装的媒体的封 装， 以及是否支持该媒体内部的媒体成分的编解码格式； 述多种媒体成分混装的媒体的封装， 同时也支持该媒体内部所有媒体成 分的编解码格式时， 使用与 SDP offer对应的媒体行对所述媒体的表征 信息进行描述， 在属性行对所述媒体的所有内部媒体成分进行描述， 对 用户数据 协议 UDP端口进行重新指配； 在所述判断单元判断 SDP应 答者端设备支持多种媒体成分混装的媒体的封装， 并且仅支持该媒体内 部部分媒体成分的编解码格式时，使用属性行对 SDP应答者端设备支持 的所述部分媒体成分进行描述；在所述判断单元判断 SDP应答者端设备 不支持多种媒体成分混装的媒体的封装时， 使用媒体行中不包含所述混 装媒体的表征信息，或仅在属性行对所述媒体的内部媒体成分中 SDP应 答者端设备支持的媒体成分进行描述； 在所述判断单元判断 SDP应答者 端设备不支持该多种媒体成分混装的媒体内部媒体成分的任意一种时， 不对所述媒体内部媒体成分进行描述；
应答生成单元，用于根据所述描述单元的描述信息生成 SDP answer。
PCT/CN2008/070274 2007-02-15 2008-02-04 Procédé et système de négociation d'un support et procédé de transmission d'information de description de support WO2008098509A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200710080258 CN101247388A (zh) 2007-02-15 2007-02-15 对媒体进行协商的方法、系统和发送媒体描述信息的方法
CN200710080258.7 2007-02-15

Publications (1)

Publication Number Publication Date
WO2008098509A1 true WO2008098509A1 (fr) 2008-08-21

Family

ID=39689670

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070274 WO2008098509A1 (fr) 2007-02-15 2008-02-04 Procédé et système de négociation d'un support et procédé de transmission d'information de description de support

Country Status (2)

Country Link
CN (1) CN101247388A (zh)
WO (1) WO2008098509A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100077057A1 (en) * 2008-09-23 2010-03-25 Telefonaktiebolaget Lm Ericsson (Publ) File Transfer in Conference Services
CN101924744A (zh) * 2009-06-10 2010-12-22 中兴通讯股份有限公司 一种融合ip消息消息会话中继协议msrp参数协商的方法
CN101997848B (zh) * 2009-08-14 2015-05-20 中兴通讯股份有限公司 应用服务器呼叫控制中呼叫继续的方法和装置
CN102334323B (zh) * 2010-04-30 2013-12-18 华为技术有限公司 建立联合会话的方法、设备及系统
CN102369710A (zh) * 2010-04-30 2012-03-07 华为技术有限公司 建立联合会话的方法、设备及系统
CN102647402B (zh) * 2011-02-22 2015-07-29 华为技术有限公司 一种多媒体会话的协商方法、相关设备和系统
US9526091B2 (en) * 2012-03-16 2016-12-20 Intel Corporation Method and apparatus for coordination of self-optimization functions in a wireless network
CN102624629B (zh) * 2012-03-26 2017-11-24 中兴通讯股份有限公司 一种广域网报文传送方法及装置
CN104270594B (zh) * 2014-09-24 2018-11-09 大唐移动通信设备有限公司 数据包发送与接收的方法及设备
CN106506444B (zh) * 2016-09-21 2019-04-26 中国电子科技集团公司第三十研究所 一种面向lte集群系统的媒体协商系统及方法
CN114302353B (zh) * 2021-12-31 2023-10-20 咪咕音乐有限公司 媒体协商方法、通信设备及可读存储介质
CN117149640B (zh) * 2023-09-04 2024-07-26 中移互联网有限公司 基于对象化的sdp分层规整测试方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185288B1 (en) * 1997-12-18 2001-02-06 Nortel Networks Limited Multimedia call signalling system and method
US20050026558A1 (en) * 2003-05-07 2005-02-03 Marco Stura Access flow based charging for IMS/POC services
CN1852300A (zh) * 2005-09-12 2006-10-25 华为技术有限公司 一种多媒体消息系统之间进行能力协商的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185288B1 (en) * 1997-12-18 2001-02-06 Nortel Networks Limited Multimedia call signalling system and method
US20050026558A1 (en) * 2003-05-07 2005-02-03 Marco Stura Access flow based charging for IMS/POC services
CN1852300A (zh) * 2005-09-12 2006-10-25 华为技术有限公司 一种多媒体消息系统之间进行能力协商的方法

Also Published As

Publication number Publication date
CN101247388A (zh) 2008-08-20

Similar Documents

Publication Publication Date Title
WO2008098509A1 (fr) Procédé et système de négociation d&#39;un support et procédé de transmission d&#39;information de description de support
WO2007031028A1 (fr) Procede de negociation de la duree du paquet de flux multimedia
KR101008698B1 (ko) 멀티미디어 세션을 위한 서비스 품질 파라미터의 시그널링
US8059656B1 (en) Expedited resource negotiation in SIP
JP5363461B2 (ja) グループ呼機能の問い合わせ
US8307049B2 (en) Method and device for obtaining media description information of IPTV services
US20090092109A1 (en) Method and Apparatus for Enabling Discovery Within a Home Network
JP2006525693A (ja) マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法
CN101060532B (zh) 因特网网络电视业务信息传输方法
WO2009052762A1 (fr) Procédé, dispositif et système d&#39;amélioration de service de diffusion (bc)
US8639279B2 (en) Method of requesting a communication session using segmented signaling messages
Westerlund How to Write an RTP Payload Format
WO2006008297A2 (en) Push to watch network element and software architecture
WO2008040186A1 (fr) Procédé, système et passerelle destinés à négocier la capacité d&#39;un détecteur de signal des données
CN113329040B (zh) 媒体流转发过程中的协议转换方法、装置
KR20100069419A (ko) 접속 설정 프로토콜 기반의 브이오 아이피 네트워크에서 미디어 코덱 결정 방법 및 장치
KR20060038296A (ko) 이동통신 네트워크에서의 멀티플렉싱 장치 및 방법
Katrinis et al. A Comparison of Frameworks for Multimedia Conferencing: SIP and H. 323
WO2008000183A1 (fr) Procédé, appareil et système de surveillance de la qualité de service de réseaux à commutateur logiciel
Ruiz et al. Multimedia Control Protocols for Wireless Networks
US20110016216A1 (en) Optimized negotiation of coding resources between communication clients
Fang RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
KR101006141B1 (ko) Ｓｉｐ 메시지 전송 방법
CN118264751A (zh) 通话处理方法及系统、非易失性存储介质、电子设备
Westerlund RFC 8088: How to Write an RTP Payload Format

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08706647

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08706647

Country of ref document: EP

Kind code of ref document: A1