WO2010025676A1 - 实现流媒体通信的方法、装置及系统 - Google Patents

实现流媒体通信的方法、装置及系统 Download PDF

Info

Publication number
WO2010025676A1
WO2010025676A1 PCT/CN2009/073728 CN2009073728W WO2010025676A1 WO 2010025676 A1 WO2010025676 A1 WO 2010025676A1 CN 2009073728 W CN2009073728 W CN 2009073728W WO 2010025676 A1 WO2010025676 A1 WO 2010025676A1
Authority
WO
WIPO (PCT)
Prior art keywords
streaming media
stream
identifier
negotiation
request
Prior art date
Application number
PCT/CN2009/073728
Other languages
English (en)
French (fr)
Inventor
张秦
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2010025676A1 publication Critical patent/WO2010025676A1/zh

Links

Classifications

    • 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
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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]
    • 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
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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
    • H04L65/756—Media network packet handling adapting media to device capabilities

Definitions

  • the present invention relates to streaming media communication technologies, and in particular, to a method, device and system for implementing streaming media communication. Background of the invention
  • FIG. 1 is a schematic diagram showing a protocol hierarchy for implementing streaming media communication based on IP.
  • the hierarchy of the protocol includes, in order from top to bottom, an application layer, a transport layer, and a network layer.
  • the application layer protocols are: Real Time Streaming Protocol (RTSP), Session Description Protocol (SDP), Real-Time Transport Protocol/Real-Time Transport Control Protocol (RTP/RTCP).
  • RTSP is used to control the transmission of streaming media data
  • SDP is used to describe the transmitted streaming media data
  • RTP/RTCP is used to transmit streaming media data.
  • the protocol for controlling streaming media data transmission is not limited to RTSP.
  • the transmission of streaming media data can be controlled using Session Initiation Protocol (SIP) or Media Resource Control Protocol (MRCP).
  • SIP Session Initiation Protocol
  • MRCP Media Resource Control Protocol
  • Transport layer protocols are: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
  • TCP transmission control data for example, RTSP messages
  • streaming media data for example, RTP/RTCP messages
  • TCP can also be used to transport streaming media data.
  • IP protocol IP protocol
  • Network such as, Internet / intranet (internet / intranet;).
  • RTSP is an application layer protocol based on the client-server model.
  • the client and the server exchange RTSP messages to implement resource description information, session establishment, and streaming data control.
  • Figure 2 shows a schematic diagram of the process of establishing and tearing down an existing RTSP session.
  • RTSP Agent A ie, RTSP Proxy A, hereinafter referred to as A
  • RTSP Agent B ie, RTSP Proxy B, hereinafter referred to as B
  • the process shown in Figure 2 includes the following steps:
  • Step 201 A establishes a TCP connection with B.
  • Step 202 A subscribes to the streaming media file (DESCRIBE) to B, and B returns a successful response (200 0K) to A.
  • DESCRIBE streaming media file
  • Step 203 ⁇ ⁇ ⁇ establish an audio session (SETUP (audio), B returns a successful response (200 0K).
  • Step 206 ⁇ Pack the audio file and the video file into RTP/RTCP data packets and send them to UDP and send them to A.
  • the network entities that may be involved are: Client, Proxy, and Server.
  • the proxy acts as the server on the server shown in Figure 2.
  • the proxy acts as the client in Figure 2.
  • the embodiments of the present invention provide a method, device, and system for implementing streaming media communication, so as to reduce the implementation complexity of the application layer and improve the performance of streaming media communication.
  • the negotiation confirmation information includes at least a correspondence between a current streaming media type and a flow identifier used by the current streaming media transmission;
  • a method for implementing streaming media communication, applied to a server includes:
  • the negotiation confirmation information includes at least a correspondence between the current streaming media type and a current identifier used by the current streaming media transmission, and returns the a response corresponding to the streaming media session establishment request, where the response carries the negotiation confirmation information;
  • a client that includes:
  • a first session management module configured to construct a streaming media session establishment request carrying the streaming media transmission negotiation request information, and obtain a streaming media transmission negotiation confirmation information from the response corresponding to the streaming media session establishment request, where the negotiation confirmation
  • the information includes at least a correspondence between the current streaming media type and the flow identifier used by the current streaming media transmission
  • a first play processing module configured to construct a play request, and according to the flow identifier corresponding to the stream controlled by the flow control transmission protocol SCTP used for transmitting the streaming media data, and the flow according to the received streaming media data Identifying a correspondence between the type of the streaming media and the type of the streaming media, and determining a type of the received streaming media data
  • a first communication module configured to send the streaming media session establishment request and a play request, and configured to receive a response from the server end corresponding to the streaming media session establishment request and streaming media data corresponding to the play request,
  • the streaming media data carries a stream identifier corresponding to the stream controlled by the flow control transport protocol SCTP used for transmitting the streaming media data.
  • a server comprising:
  • a second session management module configured to obtain the streaming media transmission negotiation request information from the received streaming media session establishment request, and determine the streaming media transmission negotiation confirmation information according to the local end capability and the negotiation request information;
  • the negotiation confirmation information includes at least Correspondence between the current streaming type and the stream identifier used by the current streaming media transmission;
  • a second play processing module configured to determine, after receiving the play request, the streaming media data to be sent
  • a second communication module configured to receive the streaming media session establishment request and a play request, and configured to send a response corresponding to the streaming media session establishment request and streaming media data corresponding to the play request, where the response carries There is the negotiation confirmation information, where the streaming media data carries a flow identifier corresponding to a flow coupled by a flow control transmission protocol SCTP for transmitting the streaming media data.
  • a system for implementing streaming media communication including the client and server in the embodiment of the present invention.
  • the client sends a streaming media session establishment request carrying the streaming media transmission negotiation request information to the server, and the server is configured according to the local end.
  • the capability and the negotiation request information determine a media transmission negotiation confirmation information, where the negotiation confirmation information includes at least a correspondence between a current streaming media type and a current identifier used by the current streaming media transmission, and carries the negotiation confirmation information.
  • FIG. 4 is a schematic flowchart diagram of a method for implementing streaming media communication according to an embodiment of the present invention.
  • the method shown in Figure 4 involves the processing of the client and the processing at the server side, which are described separately below.
  • the client processing flow includes the following steps:
  • Step 401 The client sends a streaming media session establishment request.
  • the streaming media session establishment request carries the streaming media transmission negotiation request information.
  • the negotiation request information may include: a third stream identifier recommended by the client for transmitting the SCTP coupling to which the current streaming media data belongs.
  • the negotiation request information may further include: information indicating that the transmission is performed by using the established SCTP coupling, or information indicating that the transmission is performed by using the newly constructed SCTP coupling.
  • SCTP coupling may be established, and all control data is transmitted in a certain preset stream of the SCTP coupling.
  • there are two ways to transmit control data The first type of transmission control data mode: corresponding to each streaming media session, establish an SCTP coupling, and preset a first stream identifier for transmitting control data. In this manner, all the control data of a certain streaming media session will be transmitted on the corresponding stream corresponding to the SCTP coupled with the preset first stream identifier, and all the control data further carry the preset First stream identification.
  • the sending the streaming session establishment request in this step may be: the pre-setting in the SCTP coupling corresponding to the streaming session to which the streaming session establishment request belongs. And sending, by the flow corresponding to the first flow identifier, a streaming media session establishment request further carrying the preset first flow identifier.
  • the second transmission control data mode establishing a SCTP coupling for sharing a plurality of streaming media sessions, and setting a correspondence between each streaming media session and each flow identifier coupled to the shared SCTP, the respective flows
  • the streams corresponding to the identifiers are respectively used to transmit control data of the corresponding streaming media session.
  • the first established streaming media session is mapped to streamO according to the establishment time sequence relationship of the streaming media session, and the second established streaming media session is corresponding to streaml, and so on. In this manner, all control data of a certain streaming media session will be transmitted on the shared SCTP-coupled stream corresponding to the corresponding second stream identifier, and all control data further carries a corresponding corresponding number.
  • Second-rate logo Second-rate logo.
  • the sending the streaming media session establishment request in the step may be: determining, according to the set correspondence relationship, a second flow identifier corresponding to the streaming media session to which the request belongs, And sending, by the flow corresponding to the determined second flow identifier in the shared SCTP coupling, a streaming media session establishment request that further carries the determined second flow identifier.
  • the response returned by the receiving server may be: the pre-set in the SCTP coupling corresponding to the streaming session to which the response belongs.
  • the stream corresponding to the first stream identifier receives a response that further carries the preset first stream identifier.
  • Step 403 The client sends a play request.
  • the sending a play request in this step may be: A play request carrying the preset first stream identifier is sent on the stream corresponding to the preset first stream identifier in the SCTP coupling corresponding to the streaming media session to which the request belongs.
  • the sending the play request in the step includes: determining, according to the set correspondence, a second flow identifier corresponding to the streaming media session to which the request belongs, A play request further carrying the second stream identifier is sent on the stream corresponding to the determined second stream identifier in the shared SCTP coupling.
  • Step 404 The client receives the streaming media data returned by the server, where the streaming media data carries a flow identifier corresponding to the SCTP-coupled stream used for transmitting the streaming media data.
  • a stream identifier corresponding to the SCTP-coupled stream used for transmitting the streaming media data and a fourth stream identifier that is re-allocated by the third stream identifier or the server end.
  • Step 401 The server receives a streaming media session establishment request.
  • the streaming media session establishment request in the step also carries the streaming media transmission negotiation request information.
  • the negotiation request information may include: a third stream identifier that is recommended by the client for transmitting the current streaming media data to be SCTP-coupled; the negotiation request information may further include: indicating that the established SCTP coupling is used. Information transmitted, or information transmitted using the newly created SCTP coupling.
  • Step 403 The server receives the play request, and determines the streaming media data to be sent according to the play request.
  • the receiving the play request in this step includes: the first stream in the SCTP coupling corresponding to the streaming media session to which the request belongs A play request carrying the first stream identifier is received on the corresponding stream.
  • Step 404 The server transmits the corresponding streaming media data corresponding to the flow identifier used by the current streaming media transmission confirmed by the negotiation, where the streaming media data includes an SCTP-coupled flow used for transmitting the streaming media data. Corresponding stream ID.
  • the client may further include: a first determining unit 1304, configured to use, according to the flow identifier carried in the response received by the first communication module, and a preset flow identifier for transmitting control data. Matching the result, determining that the received response is control data.
  • FIG. 14 is a schematic structural diagram of a server according to an embodiment of the present invention.
  • the server provided by the embodiment of the present invention includes: a second session management module 1401, configured to obtain streaming media transmission negotiation request information from a received streaming media session establishment request, and determine according to the local end capability and the negotiation request information.
  • the negotiation confirmation information includes at least a correspondence between the current streaming media type and the flow identifier used by the current streaming media transmission;
  • a second communication module 1403 configured to receive the streaming media session establishment request and a play request, and configured to send a response corresponding to the streaming media session establishment request and streaming media data corresponding to the play request, where the response And carrying the negotiation confirmation information, where the streaming media data carries a flow identifier corresponding to a flow coupled by the flow control transmission protocol SCTP used for transmitting the streaming media data.
  • the client 1501 is configured to send a streaming media session establishment request carrying the streaming media transmission negotiation request information to the server 1502, and receive a response corresponding to the streaming media session establishment returned by the server 1502, and obtain a streaming media transmission from the response.
  • the negotiation confirmation information includes at least a correspondence between the current streaming media type and the flow identifier used by the current streaming media transmission; and is configured to send a playback request to the server 1502, and receive streaming media data from the server 1502, according to the received a stream identifier corresponding to the SCTP-coupled stream used for transmitting the streaming media data carried in the streaming media data, and the stream identifier and the stream type Corresponding relationship, determining the type of the received streaming media data;
  • the server 1502 is configured to receive a streaming media session establishment request from the client 1501, obtain the streaming media transmission negotiation request information from the streaming media session establishment request, and determine the streaming media transmission negotiation confirmation information according to the local end capability and the negotiation request information. Returning a response corresponding to the streaming media session establishment request to the client 1501, and receiving the playback request from the client 1501, and sending the corresponding streaming media data to the client 1501.
  • the streaming media data carries a flow identifier corresponding to a stream coupled by the flow control transport protocol SCTP for transmitting the streaming media data.
  • Proxy B communicates with Server C
  • the role of Proxy B here is the client, and the corresponding Server C is the server.
  • the client sends a streaming media session establishment request carrying the streaming media transmission negotiation request information to the server, and the server end is based on the local end capability and
  • the negotiation request information determines a media transmission negotiation confirmation information, where the negotiation confirmation information includes at least a correspondence between the current streaming media type and a current identifier used by the current streaming media transmission, and the response carrying the negotiation confirmation information is carried.
  • the client sends a play request to the server, and the server transmits the corresponding streaming media data corresponding to the flow identifier confirmed by the negotiation, the streaming media data carries the flow identifier, and finally the client according to the streaming media
  • the stream identifier carried in the data determines the type of the stream media data, so that the client application can distinguish whether the received data is control data or streaming media data through the stream identifier carried in the streaming media data, and determine the streaming media data.
  • Type which reduces the application layer The complexity is realized, the transmission delay is reduced, and the performance of streaming communication is improved.
  • FIG. 6 is a schematic diagram of a process of media transmission negotiation according to Embodiment 1 of the present invention.
  • the entity involved in the media transmission negotiation process includes a media receiving end and a media sending end, and corresponding to the embodiment, the media receiving end is a client, and the media sending end is a server end, and the media transmission negotiation process is performed.
  • Step 601 The media receiving end indicates to the media sending end that: SCTP is used for transmission of streaming media data, hereinafter referred to as "media transmission”.
  • Step 602 The media receiving end indicates to the media sending end that: the new SCTP coupling or the original established SCTP coupling is used for media transmission.
  • Step 603 The media receiving end indicates to the media sending end: an IP and a port of the media receiving end.
  • Step 604 The media receiving end indicates to the media sending end that: the SCTP-coupled flow identifier of the media recommended by the media receiving end belongs to.
  • Step 605 The media sender confirms that the SCTP is used for media transmission.
  • Step 608 The media sender confirms the SCTP-coupled flow identifier to which the media belongs.
  • FIG. 8 is a schematic diagram of a message interaction process for implementing streaming media communication according to Embodiment 1 of the present invention.
  • the RTSP Client A in the figure is a client according to an embodiment of the present invention, hereinafter referred to as A ;
  • RTSP Server C is a server according to an embodiment of the present invention, hereinafter referred to as C.
  • the message interaction process shown in Figure 8 includes the following steps:
  • Step 801 A initiates SCTP coupling a to C, while establishing multiple streams in the current SCTP coupling.
  • the number of streams established is not less than three.
  • Step 802 A sends a DESCRIBE request to C on the stream 0 coupled to a, and subscribes to the streaming file; C receives a DESCRIBE request and returns a 200 0K response to A on stream 0 coupled to a.
  • Step 8031 A sends an audio session establishment request to C on stream 0 coupled with a.
  • the following fields are carried in the transport header field of the audio connection setup request:
  • RTP/AVP/SCTP specifies that the audio data is based on SCTP transmission
  • connection existing—indicating that the audio data will be transmitted based on the existing coupling, without re-creation; c) src_addr "192.0.2.5:554" - the source IP address and port number of the audio data;
  • Step 804 Complete the video session establishment process, complete the media transmission negotiation process, and determine which stream of the video media is transmitted on the SCTP.
  • Step 804 specifically includes the following steps 8041 and 8042.
  • Step 8041 A sends a video connection setup request (SETUP (video) ) to B on stream 0 coupled to a.
  • SETUP video
  • the following fields can be carried in the transport header field of the video connection setup request:
  • RTP/AVP/SCTP indicates that the video media data is based on SCTP transmission
  • the stream ID is the recommended value of A, and the peer can change when it returns a response.
  • Step 8042 C sends a 200 OK response to B on stream 0 coupled to a, and carries the following word in the transport header field a) RTP/ AVP/SCTP indicates that the video media data is based on SCTP transmission;
  • connection existing indicates that the video media data is based on the existing existing coupled transmission and does not need to be recreated
  • Step 805 A sends a play (PLAY) request message to C on the stream 0 coupled with a, requesting to play the streaming media; C receives the play request message, and returns a 200 response to A on stream 0 coupled with a.
  • PLAY play
  • Step 806 C transmits audio and video data on the negotiated stream.
  • the audio RTP packet is transmitted on streaml coupled to a
  • the video RTP packet is transmitted on stream2 coupled to a.
  • Embodiment 2 In the case that the client is in the internal network, the agent is located at the edge of the network, the server is on the external network, and the streaming media data does not pass through the proxy, the following provides a technical solution for transmitting control data and media data in the embodiment of the present invention.
  • SCTP couplings may be established for each streaming session, specifically: establishing an SCTP coupling for each streaming session between the client and the proxy, The control data corresponding to the streaming media session is transmitted in the corresponding stream identifier of the SCTP-coupled flow identifier, and the media transmission negotiation is performed through the control data; and a flow sharing session is established between the proxy and the server.
  • SCTP coupling, and establishing a plurality of flows corresponding to the plurality of streaming media sessions in the SCTP coupling transmitting control data of the corresponding streaming media session in the multiple flows, and passing the control Data is negotiated for media transmission of the corresponding streaming session;
  • FIG. 9 A schematic structural diagram of a system for implementing streaming communication for such an application scenario is shown in FIG.
  • Client a, Client b, and Client c represent the client
  • ProxyB represents the proxy
  • Server C represents the server
  • the solid arrow between ProxyB and Server C indicates that the bearer is Controlling SCTP coupling of data
  • the dashed arrows between Client A and Server C represent SCTP couplings carrying streaming media data.
  • the preset flow identifier may be stream 0, of course, stream 1, and so on.
  • the streaming media data for transmitting the corresponding streaming media session in the other flows except the flow corresponding to the preset flow identifier may be: transmitting the same in the same flow except the flow corresponding to the preset flow identifier.
  • the different types of streaming media data of the first-class media session may also be: different types of streaming media data of the same streaming media session are respectively transmitted in different flows except the flow corresponding to the preset flow identifier.
  • Which stream media is specifically used for transmission, is determined by controlling data for media transmission negotiation. This embodiment can also perform media negotiation according to the flow shown in FIG. 6.
  • the RTSP is still taken as an example in the application layer protocol.
  • A sends an audio session establishment request (SETUP (audio)) to B on stream 0 coupled with a, and after receiving the audio session establishment request, B also sends an audio session establishment request to C on stream 0 coupled to c. .
  • SETUP audio
  • the transport header field of the audio session establishment request needs to carry related information of the audio session, for example: based on which protocol the streaming media data is transmitted.
  • the following fields may be carried in the transport header field of the audio session establishment request: a) RTP/AVP/SCTP indicates that the streaming media data is based on SCTP transmission;
  • NPT Step 1104 A initiates SCTP coupling to C.
  • a and C have been negotiated: A is actively creating a coupling with C for transmitting streaming media data between A and C, and has negotiated each for the even The associated ip address and port number, and the stream identifier of the stream used to transport the streaming media data in the coupling. Therefore, in this step, A will initiate SCTP coupling b to C, establishing the above-mentioned already agreed coupling.
  • Step 1105 Complete the video session establishment process, and complete the media transmission negotiation process to determine which stream of the video media is transmitted on the SCTP.
  • A sends a video connection establishment request (SETUP (video)) to B on stream 0 coupled with a, and after receiving the video connection establishment request, B also sends a video connection establishment request to C on stream 0 coupled with c. .
  • SETUP video connection establishment request
  • the following fields can be carried in the transport header field of the video connection setup request:
  • RTP/AVP/SCTP - indicates that the streaming media is based on SCTP transmission
  • the flow identifier is the recommended value of A, and the peer can change when returning a response.
  • C sends a 200 OK response to B on stream 0 coupled to c.
  • B sends a 200 OK response to A on stream 0 coupled with a, and carries the following fields in the transport header field:
  • connection existing - indicates that the existing coupling is used, no re-creation is required;
  • Step 1106 A sends a play (PLAY) request message to B on the stream 0 coupled with a, requesting to play the streaming media; B, after receiving the play request message, also sends a play request message to C on stream 0 coupled with c. .
  • C returns a 200 0K response to B on stream 0 coupled to c. After receiving a 200 0K response, B returns a 200 response to A on stream 0 coupled to a.
  • Step 1107 According to the result of the above-mentioned steps 1103 and 1104, C will transmit the audio RTP packet on streaml coupled b, and the video RTP packet on stream2 coupled b; correspondingly, A will be in the streaml coupled b The audio RTP packet is received, and the video RTP packet is received on stream 2 coupled to b.
  • Embodiment 3 In the case that the agent is in the internal network, the agent is located at the edge of the network, the server is in the external network, and the streaming media data needs to be proxyed, the following provides a technical solution for transmitting control data and media data in the embodiment of the present invention. : Establish an SCTP coupling for each streaming session between the client and the agent, establish multiple streams in each SCTP coupling, and transmit control in the stream corresponding to each SCTP-coupled pre-set flow identifier.
  • FIG. 5 is a schematic structural diagram of a system for implementing streaming media communication according to Embodiment 1 of the present invention, where the system includes a client A and a server C, where:
  • the client A is configured to establish SCTP coupling with the server C, and transmit control data of the streaming media session in the stream corresponding to the SCTP-coupled preset flow identifier (it should be understood that: the control data is the client) a signaling message that is exchanged between A and the server C, and performs media transmission negotiation, and is configured to receive, according to the result of the media transmission negotiation, the streaming media data of the corresponding streaming media session in a transmission manner corresponding to the negotiation result;
  • the control data is the client
  • a signaling message that is exchanged between A and the server C, and performs media transmission negotiation, and is configured to receive, according to the result of the media transmission negotiation, the streaming media data of the corresponding streaming media session in a transmission manner corresponding to the negotiation result;
  • the server C is configured to establish an SCTP coupling with the client A, and configured to transmit control data of the streaming media session in the flow corresponding to the SCTP-coupled preset flow identifier, perform media transmission negotiation, and use
  • the streaming media data of the corresponding streaming media session is sent in a transmission manner corresponding to the negotiation result.
  • the server C may be further configured to establish multiple flows in the SCTP coupling according to the result of the media transmission negotiation, and to use the flow corresponding to the preset flow identifier. Sending streaming media data of the corresponding streaming media session in other streams than the other streams;
  • FIG. 12 is a schematic structural diagram of a system for implementing streaming media communication according to Embodiment 2 of the present invention.
  • the system structure diagrams shown in FIG. 9 and FIG. 12 are applicable to a system including clients a, b, c, proxy B, and server C. Situation, where:
  • the client a, b, c is configured to establish an SCTP coupling with the proxy B, and configured to transmit the control data of the streaming media session in the flow corresponding to the SCTP-coupled preset flow identifier, and perform media transmission negotiation. And receiving, according to the result of the media transmission negotiation, the streaming media data of the corresponding streaming media session; the foregoing: “Preceding media transmission negotiation, and receiving, according to the result of the media transmission negotiation, receiving corresponding
  • a description of the streaming media data of the streaming media session please refer to the description of the system for implementing streaming media communication in the foregoing embodiment of the present invention shown in FIG.
  • the proxy B is configured to establish an SCTP coupling with the clients a, b, and c, and transmit control data of the streaming media session in the flow corresponding to the SCTP-coupled preset flow identifier, and perform media transmission negotiation; And configured to establish, by the server, an SCTP coupling shared by the plurality of streaming media sessions, and establish, in the shared SCTP coupling, a plurality of flows corresponding to the plurality of streaming media sessions, in the multiple flows.
  • the server C is configured to establish an SCTP coupling with the proxy B for sharing a plurality of streaming media sessions, and establish a plurality of flows corresponding to the plurality of streaming media sessions in the shared SCTP coupling, where
  • the control data of the corresponding streaming media session is transmitted in the plurality of flows, and the media transmission negotiation of the corresponding streaming media session is performed by using the control data, and is used to send the streaming media data of the corresponding streaming media session according to the result of the media transmission negotiation.
  • control data for transmitting a corresponding streaming media session in the plurality of flows performing media transmission negotiation of a corresponding streaming media session through the control data, and used for negotiating according to the media transmission.
  • the streaming media data of the corresponding streaming media session please refer to the description of the system for implementing streaming communication according to the embodiment of the present invention shown in FIG. 15 above.
  • the server C is further configured to establish at least one SCTP coupling with the client a, b, c according to the result of the media transmission negotiation, where the at least one SCTP coupling is preset
  • the stream data of the corresponding streaming media session is sent in the other stream except the corresponding stream.
  • the server C is a first server, and may be configured to establish, by the client, an SCTP coupling including multiple flows according to the result of the media transmission negotiation, and Transmitting different types of streaming media data in a plurality of streams other than the streams corresponding to the preset flow identifiers, which are SCTP-coupled, including multiple streams;
  • the client a, b, and c are the first client, and may be configured to respectively receive different types in the multiple streams except the flow corresponding to the preset flow identifier that are SCTP-coupled by the multiple flows.
  • Streaming data is a first server, and may be configured to establish, by the client, an SCTP coupling including multiple flows according to the result of the media transmission negotiation, and Transmitting different types of streaming media data in a plurality of streams other than the streams corresponding to the preset flow identifiers, which are SCTP-coupled, including multiple streams;
  • the client a, b, and c are the first client, and may be configured to respectively receive different types in the
  • the server C is a second server, and may be configured to establish multiple SCTP couplings with the client according to the result of the media transmission negotiation, and used in the multiple SCTP pairs.
  • Different types of streaming media data are respectively sent in the streams other than the streams corresponding to the preset flow identifiers;
  • the client a, b, c is further configured to receive a flow of the corresponding streaming media session in a flow other than the flow corresponding to the preset flow identifier of the multiple flows established between the proxy and the proxy Media data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

实现流媒体通信的方法、 装置及系统 本申请要求了 2008年 9月 8日提交的、 申请号为 200810215636. 2、 发明名称为 "实现流媒体 通信的方法、 装置及系统"的中国申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及流媒体通信技术， 特别涉及实现流媒体通信的方法、 装置及系统。 发明背景
流媒体是指在网络中使用流式传输技术进行传输的连续媒体， 如： 音频、 视频、 多媒体文件等。 图 1示出了目前基于 IP实现流媒体通信的协议层次示意图，该协议层次由上至下依次包括:应用层、 传输层和网络层。
参见图 1， 应用层协议有： 实时流协议 （RTSP)、 会话描述协议 （SDP)、 实时传输协议 /实时传 输控制协议 （RTP/RTCP)。 RTSP用于控制流媒体数据的传输； SDP用于描述所传输的流媒体数据， RTP/RTCP用于传输流媒体数据。当然，在实际应用中，用于控制流媒体数据传输的协议不限于 RTSP， 例如， 可以使用会话初始化协议 （SIP) 或媒体资源控制协议 （MRCP) 等控制流媒体数据的传输。
传输层协议有：传输控制协议 (TCP)和用户数据报协议（UDP)。通常采用 TCP传输控制数据（例 如： RTSP消息）， 采用 UDP传输流媒体数据 （例如： RTP/RTCP消息）。 在特殊应用场景下 （例如， 流 媒体数据需要穿越防火墙)， 也可以采用 TCP传输流媒体数据。
网络层协议有： IP协议。
网络如， 互联网 /内部网 （internet/intranet；)。
RTSP是一个基于客户端一服务器模型的应用层协议， 在流媒体通信中， 客户端与服务器之间通 过交换 RTSP消息来实现资源描述信息的获取、 会话的建立、 流媒体数据的播放控制等功能。 图 2示 出了现有 RTSP会话的建立和拆除过程示意图。 参见图 2， RTSP Agent A (即 RTSP代理 A， 以下简称 A) 是所述会话的客户端， RTSP Agent B (即 RTSP代理 B， 以下简称 B) 是所述会话的服务器端。 图 2所示过程包括以下步骤：
步骤 201 : A与 B建立 TCP连接。
步骤 202: A向 B订阅流媒体文件 （DESCRIBE), B向 A返回成功响应 （200 0K)。
步骤 203: Α与 Β建立音频会话 ( SETUP (audio) , B向 A返回成功响应 ( 200 0K)。
步骤 204: Α与 Β建立视频会话 （SETUP (video) ), B向 A返回成功响应 （200 0K)。
步骤 205: Α向 Β发送播放请求 （PLAY), B向 A返回成功响应 （200 0K)。
步骤 206: Β将音频文件和视频文件打包成 RTP/RTCP数据包承载于 UDP发送给 A。
步骤 207: A向 B发送拆除会话请求（TEARD0WN), 用于拆除 A与 B之间的音频会话和视频会话， B向 A返回成功响应 （200 0K)。 步骤 208: 拆除 A与 B之间的 TCP连接。
流媒体通信中， 可能涉及的网络实体有： 客户端（Client)、代理（Proxy)和服务器（Server)。 在 Client与 Proxy的会话交互过程中， Proxy充当图 2所示服务器端的角色； 在 Proxy与 Server 的会话交互过程中， Proxy充当图 2所示客户端的角色。
发明人在实现本发明的过程中， 发现现有技术中： 当流媒体数据需要穿越防火墙（NAT/FW) 时， 不能采用 UDP 传输流媒体数据， 而是采用 TCP 传输流媒体数据， 这种方式称为内嵌二进制数据 (Embedded Binary Data) 方式。 此时， 控制数据与流媒体数据在同一条 TCP连接上传输， 应用层 收到来自于传输层的数据后， 必须先识别该 TCP连接上传输的数据是控制数据还是音频 RTP包或是 视频 RTP包， 再进行相应的后续处理， 这增加了上层应用的复杂度， 也降低了流媒体通信的性能。 发明内容
本发明实施例提供实现流媒体通信的方法、 装置及系统， 以降低应用层的实现复杂度， 提高流 媒体通信的性能。
本发明实施例的技术方案具体是这样实现的：
一种实现流媒体通信的方法， 应用于客户端， 包括：
发送流媒体会话建立请求， 所述请求中携带有流媒体传输协商请求信息；
接收服务器端返回的响应， 从所述响应中获得流媒体传输协商确认信息， 所述协商确认信息至 少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；
发送播放请求；
接收服务器返回的流媒体数据， 所述流媒体数据中携带有用于传输所述流媒体数据所用的流控 制传输协议 SCTP偶联的流对应的流标识；
根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系， 确定所述流媒体数据 的类型。
一种实现流媒体通信的方法， 应用于服务器端， 包括：
接收流媒体会话建立请求， 所述请求中携带有流媒体传输协商请求信息；
根据本端能力和所述协商请求信息， 确定流媒体传输协商确认信息， 所述协商确认信息至少包 含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系， 并返回与所述流媒体会话建立 请求对应的响应， 所述响应中携带有所述协商确认信息；
接收播放请求；
通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒体数据， 所述流媒 体数据中包含用于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
一种客户端， 包括：
第一会话管理模块， 用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求， 并从对 应于所述流媒体会话建立请求的响应中获得流媒体传输协商确认信息， 所述协商确认信息至少包含 当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系； 第一播放处理模块， 用于构造播放请求， 并根据接收的流媒体数据中携带的用于传输所述流媒 体数据所用的流控制传输协议 SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关 系， 确定所述接收的流媒体数据的类型；
第一通信模块， 用于发送所述流媒体会话建立请求和播放请求， 并用于接收来自服务器端的对 应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据， 所述流媒体数据携带用 于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
一种服务器， 包括：
第二会话管理模块， 用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息， 根据 本端能力以及所述协商请求信息确定流媒体传输协商确认信息； 所述协商确认信息至少包含当前流 媒体类型与当前流媒体传输所用的流标识之间的对应关系；
第二播放处理模块， 用于在接收到播放请求后， 确定待发送的流媒体数据；
第二通信模块， 用于接收所述流媒体会话建立请求和播放请求， 并用于发送对应于所述流媒体 会话建立请求的响应和对应于所述播放请求的流媒体数据，其中所述响应携带有所述协商确认信息， 所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议 SCTP 偶联的流对应的流标 识。
一种实现流媒体通信的系统， 包括本发明实施例上述客户端和服务器。
由上述技术方案可见， 本发明实施例所提供的实现流媒体通信的方法， 首先由客户端向服务器 端发送携带有流媒体传输协商请求信息的流媒体会话建立请求， 并由服务器端根据本端能力和所述 协商请求信息确定流媒体传输协商确认信息， 所述协商确认信息至少包含当前流媒体类型与当前流 媒体传输所用的流标识之间的对应关系， 并将携带有所述协商确认信息的响应返回给客户端， 然后 由客户端向服务器端发送播放请求， 服务器端通过协商确认的流标识对应的流传输相应的流媒体数 据， 该流媒体数据携带有流标识， 最后由客户端根据流媒体数据中携带的流标识确定该流媒体数据 的类型， 可见， 使得客户端的应用程序通过流媒体数据中携带的流标识即可区分所接收的数据是控 制数据还是流媒体数据， 并确定流媒体数据的类型， 从而降低了应用层的实现复杂度， 减少了传输 时延， 提高了流媒体通信的性能。 附图简要说明
图 1示出了目前基于 IP实现流媒体通信的协议层次示意图；
图 2示出了现有 RTSP会话的建立和拆除过程示意图；
图 3示出了现有 SCTP偶联的结构示意图；
图 4为本发明实施例中实现流媒体通信的方法的流程示意图；
图 5为本发明实施例一中实现流媒体通信的系统的结构示意图；
图 6为本发明实施例一中进行媒体传输协商的过程示意图；
图 7示出了本发明实施例一所建立的偶联的结构示意图；
图 8为本发明实施例一中实现流媒体通信的消息交互流程示意图； 图 9为本发明实施例二中实现流媒体通信的系统的结构示意图；
图 10示出了本发明实施例二中所建立的偶联的结构示意图；
图 11为本发明实施例二中实现流媒体通信的消息交互流程示意图；
图 12为本发明实施例三中实现流媒体通信的系统的结构示意图；
图 13为本发明实施例客户端的组成结构示意图；
图 14为本发明实施例服务器的组成结构示意图；
图 15为本发明实施例实现流媒体通信的系统的组成结构示意图。 实施本发明的方式
为使本发明的目的、 技术方案及优点更加清楚明白， 以下参照附图并举实施例， 对本发明作进 一步详细说明。
为了降低应用层的实现复杂度、 提高流媒体通信的性能， 本发明实施例提出一种基于流控制传 输协议 （SCTP) 实现流媒体通信的技术方案。
SCTP是 IETF提出的一种传输层协议， 它运行于提供不可靠传递的分组网络上， 向用户提供用 户数据无错误无重复的确认传输。 SCTP偶联 (association)类似于 TCP连接，但含义更广。一条 SCTP 偶联的两个 SCTP端点都向对方提供一个 SCTP端口号和一个 IP地址列表， 这样每个 SCTP偶联都由 两个 SCTP端口号和两个 IP 地址列表来识别。
在一条 SCTP偶联中可以包含多个流 (stream) , 各个流之间的数据传输相对独立。 图 3示出了现 有 SCTP偶联的结构示意图。 参见图 3， 图中所示 stream 0、 stream 1 stream n同属于一条 SCTP 偶联， 每个流的编号唯一。 应用层中的 SCTP应用程序在传输数据包时指明所述数据包的 SCTP偶联 和所属流标识， 接收端收到数据包后， 就可以根据数据包中的流标识来确定所接收的数据包归属于 哪个流， 从而保证各个流之间所传输的数据的独立性。
本发明实施例利用 SCTP偶联的多流特性提出基于 SCTP实现流媒体通信的技术方案。 如背景技 术所述， 流媒体通信中， 可能涉及的网络实体有： 客户端、 代理和服务器。 在客户端与代理的会话 交互过程中， 代理实际上充当服务器端的角色； 在代理与服务器的会话交互过程中， 代理实际上充 当客户端的角色， 因此， 本发明实施例提供了分别应用于客户端与服务器端的实现流媒体通信的技 术方案。
图 4为本发明实施例实现流媒体通信的方法的流程示意图。 图 4所示方法涉及客户端的处理以 及服务器端的处理， 下面分别进行说明。
参见图 4， 客户端处理流程包括以下步骤：
步骤 401 : 客户端发送流媒体会话建立请求。
本步骤所述流媒体会话建立请求中携带有流媒体传输协商请求信息。 所述协商请求信息中可以 包含： 客户端推荐的用于传输当前流媒体数据所属 SCTP偶联的第三流标识。所述协商请求信息中还 可以进一步包含： 表示采用已经建立的 SCTP偶联进行传输的信息、 或表示采用新建的 SCTP偶联进 行传输的信息。 在发送本步骤所述流媒体会话建立请求之前， 可以建立 SCTP偶联， 并将所有的控制数据在所 述 SCTP偶联的某一预先设置的流中传输。 在具体实现时， 有如下两种传输控制数据的方式： 第一种传输控制数据方式： 对应于每一个流媒体会话， 建立一条 SCTP偶联， 并预先设置用于 传输控制数据的第一流标识。这种方式下， 某一流媒体会话的所有控制数据将在其对应的 SCTP偶联 的所述预先设置的第一流标识对应的流上传输， 并且， 所有的控制数据中进一步携带所述预先设置 的第一流标识。
例如： 对应于第一种传输控制数据方式， 本步骤所述发送流媒体会话建立请求可以是： 在与所 述流媒体会话建立请求所属的流媒体会话对应的 SCTP 偶联中的所述预先设置的第一流标识对应的 流上发送进一步携带有所述预先设置的第一流标识的流媒体会话建立请求。
第二种传输控制数据方式： 建立一条供多个流媒体会话共用的 SCTP偶联， 并设置各个流媒体 会话与所述共用的 SCTP偶联的各个流标识之间的对应关系，所述各个流标识对应的流分别用于传输 对应的流媒体会话的控制数据。 在设置所述对应关系时， 可以根据流媒体会话的建立时间先后次序 关系， 将最先建立的流媒体会话对应到 streamO, 将第二个建立的流媒体会话对应到 streaml , 依此 类推。这种方式下， 某一流媒体会话的所有控制数据将在该共用的 SCTP偶联的与之相应的第二流标 识对应的流上传输， 并且， 所有的控制数据中进一步携带与之对应的第二流标识。
例如： 对应于第二种传输控制数据方式， 本步骤所述发送流媒体会话建立请求可以是： 根据所 述设置的对应关系确定与所述请求所属的流媒体会话对应的第二流标识，在所述共用的 SCTP偶联中 所述确定的第二流标识对应的流上发送进一步携带有所述确定的第二流标识的流媒体会话建立请 求。
步骤 402 : 客户端接收服务器端返回的响应， 从所述响应中获得流媒体传输协商确认信息。 本步骤中， 所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的 对应关系。 此外， 所述协商确认信息中还可以包含： 服务器端协商确认的用于传输当前流媒体数据 所属 SCTP偶联的流标识。 所述协商确认信息中还可以进一步包含： 表示采用已经建立的 SCTP偶联 进行传输的信息、 或表示采用新建的 SCTP偶联进行传输的信息。
对应于步骤 401 所述第一种传输控制数据的方式， 本步骤所述接收服务器端返回的响应可以 是：从与所述响应所属的流媒体会话对应的 SCTP偶联中的所述预先设置的第一流标识对应的流上接 收进一步携带有所述预先设置的第一流标识的响应。
对应于步骤 401 所述第二种传输控制数据的方式， 本步骤所述接收服务器端返回的响应可以 是： 根据所述设置的对应关系确定与所述响应所属的流媒体会话对应的第二流标识， 从所述共用的 SCTP偶联中所述确定的第二流标识对应的流上接收进一步携带有所述确定的第二流标识的响应。
在接收到携带有流标识（如第一流标识、第二流标识） 的响应后， 客户端就可以根据所述响应 中携带的流标识 （如第一流标识、 第二流标识）和预先设置的用于传输控制数据的流标识的匹配结 果， 确定所述接收到的响应是控制数据。
步骤 403 : 客户端发送播放请求。
对应于步骤 401所述第一种传输控制数据的方式， 本步骤所述发送播放请求可以是： 在与所述 请求所属的流媒体会话对应的 SCTP 偶联中的所述预先设置的第一流标识对应的流上发送携带有所 述预先设置的第一流标识的播放请求。
对应于步骤 401所述第二种传输控制数据的方式， 本步骤所述发送播放请求包括： 根据所述设 置的对应关系确定与所述请求所属的流媒体会话对应的第二流标识，在所述共用的 SCTP偶联中所述 确定的第二流标识对应的流上发送进一步携带有所述第二流标识的播放请求。
步骤 404: 客户端接收服务器返回的流媒体数据， 所述流媒体数据中携带有用于传输所述流媒 体数据所用的 SCTP偶联的流对应的流标识。
用于传输所述流媒体数据所用的 SCTP偶联的流对应的流标识， 为所述第三流标识或者服务器 端重新分配的第四流标识。
若步骤 402所述协商确认信息中包含表示采用已经建立的 SCTP偶联进行传输的信息，则本步骤 所述接收服务器返回的流媒体数据可以是：从已经建立的 SCTP偶联中协商确认的流标识对应的流上 接收服务器端返回的流媒体数据。
若步骤 402所述协商确认信息中包含表示采用新建的 SCTP偶联进行传输的信息，则在步骤 402 接收服务器端返回的响应之后， 进一步需要对应所述流媒体会话， 建立新的 SCTP偶联； 此时， 本步 骤所述接收服务器返回的流媒体数据可以是：从所述新的 SCTP偶联中协商确认的流标识对应的流上 接收服务器端返回的流媒体数据。
步骤 405 : 客户端根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系， 确 定所述流媒体数据的类型。
至此， 结束客户端的处理。 还可以参见图 4， 服务器端处理流程包括以下步骤：
步骤 401 : 服务器接收流媒体会话建立请求。
本步骤所述流媒体会话建立请求中也携带有流媒体传输协商请求信息。 所述协商请求信息中可 以包含： 客户端推荐的用于传输当前流媒体数据所属 SCTP偶联的第三流标识； 所述协商请求信息中 还可以进一步包含： 表示采用已经建立的 SCTP偶联进行传输的信息、 或表示采用新建的 SCTP偶联 进行传输的信息。
对应于客户端处理流程中步骤 401所述第一种传输控制数据的方式， 本步骤所述接收流媒体会 话建立请求可以是：从与所述请求所属的流媒体会话对应的 SCTP偶联中的流上接收进一步携带有客 户端预先设置的第一流标识的流媒体会话建立请求。
对应于客户端处理流程中步骤 401所述第二种传输控制数据的方式， 本步骤所述接收流媒体会 话建立请求可以是：从所述共用的 SCTP偶联中的流上接收进一步携带有客户端确定的第二流标识的 流媒体会话建立请求。
步骤 402 : 服务器根据本端能力和所述协商请求信息， 确定流媒体传输协商确认信息， 并返回 与所述流媒体会话建立请求对应的响应， 所述响应中携带有所述协商确认信息。
本步骤中， 服务器可以根据本端能力和协商请求信息中的客户端推荐的用于传输当前流媒体数 据的第三流标识， 协商确认用于传输当前流媒体数据所属 SCTP偶联的流标识， 所述流标识为所述第 三流标识或者服务器端重新分配的第四流标识， 得到包含当前流媒体类型与当前流媒体传输所用的 流标识的对应关系的协商确认信息。
并且，可以根据本端能力和协商请求信息中包含的表示采用已经建立的 SCTP偶联进行传输的信 息、 或表示采用新建的 SCTP偶联进行传输的信息， 确定采用已经建立的 SCTP偶联中所述客户端推 荐的第三流标识或者服务器端重新分配的第四流标识对应的流传输当前流媒体数据， 得到包含当前 媒体流类型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的 SCTP 偶联的信息 的协商确认信息， 或者， 确定采用新建的 SCTP偶联中所述客户端推荐的第三流标识或者服务器端重 新分配的第四流标识对应的流传输当前流媒体数据， 得到包含当前媒体流类型与当前媒体流传输所 用的流标识的对应关系以及表示媒体传输所用的 SCTP偶联的信息的协商确认信息。
对应于客户端处理流程中步骤 401所述第一种传输控制数据的方式， 本步骤所述返回响应可以 是：在与所述响应所属流媒体会话对应的 SCTP偶联中所述携带有所述流媒体会话建立请求中的第一 流标识对应的流上发送携带有所述第一流标识的响应。
对应于客户端处理流程中步骤 401所述第二种传输控制数据的方式， 本步骤所述返回响应可以 是：在所述共用的 SCTP偶联中所述携带的第二流标识对应的流上发送进一步携带有所述第二流标识 的响应。
步骤 403 : 服务器接收播放请求， 根据所述播放请求确定待发送的流媒体数据。
对应于客户端处理流程中步骤 401所述第一种传输控制数据的方式， 本步骤所述接收播放请求 包括：从与所述请求所属的流媒体会话对应的 SCTP偶联中的所述第一流标识对应的流上接收携带有 所述第一流标识的播放请求。
对应于客户端处理流程中步骤 401所述第二种传输控制数据的方式， 本步骤所述接收播放请求 包括： 从所述共用的 SCTP偶联中的流上接收携带有所述第二流标识的播放请求。
步骤 404: 服务器通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒 体数据， 所述流媒体数据中包含用于传输所述流媒体数据所用的 SCTP偶联的流对应的流标识。
若步骤 402所述协商确认信息为采用已经建立的 SCTP偶联进行传输，则本步骤所述通过协商确 认的流标识对应的流传输相应的流媒体数据可以是：在所述已经建立的 SCTP偶联中协商确认的流标 识对应的流上传输流媒体数据。
若步骤 402所述协商确认信息为采用新建的 SCTP偶联进行传输， 则在步骤 402返回响应之后， 进一步需要对应所述流媒体会话， 重新建立新的 SCTP偶联； 此时， 本步骤所述通过协商确认的流标 识对应的流传输相应的流媒体数据可以是：在所述新的 SCTP偶联中协商确认的流标识对应的流上传 输流媒体数据。
至此， 结束服务器端的处理。 对应于上述实现流媒体通信的方法， 本发明实施例还提供了一种客户端和一种服务器端。 图 13为本发明实施例客户端的组成结构示意图。 参见图 13， 本发明实施例提供的客户端包括: 第一会话管理模块 1301， 用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求， 并从对应于所述流媒体会话建立请求的响应中获得流媒体传输协商确认信息， 所述协商确认信息至 少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；
第一播放处理模块 1302， 用于构造播放请求， 并根据接收的流媒体数据中携带的用于传输所 述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的 对应关系， 确定所述接收的流媒体数据的类型；
第一通信模块 1303， 用于发送所述流媒体会话建立请求和播放请求， 并用于接收来自服务器端 的对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据， 所述流媒体数据携 带用于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
较佳地， 所述客户端中还可以进一步包括： 第一确定单元 1304， 用于根据第一通信模块接收的 所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果， 确定所述接收到的 响应是控制数据。 图 14为本发明实施例服务器的组成结构示意图。 参见图 14， 本发明实施例提供的服务器包括： 第二会话管理模块 1401， 用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息， 根据本端能力以及所述协商请求信息确定协商确认信息； 所述协商确认信息至少包含当前流媒体类 型与当前流媒体传输所用的流标识之间的对应关系；
第二播放处理模块 1402， 用于在接收到播放请求后， 确定待发送的流媒体数据；
第二通信模块 1403， 用于接收所述流媒体会话建立请求和播放请求， 并用于发送对应于所述流 媒体会话建立请求的响应和对应于所述播放请求的流媒体数据， 其中所述响应携带有所述协商确认 信息，所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的 流标识。
较佳地， 所述第二会话管理模块 1401 , 具体可以用于从接收的流媒体会话建立请求中获取流媒 体传输协商请求信息， 所述流媒体传输协商请求信息包含客户端推荐的用于传输当前流媒体数据所 属 SCTP偶联的第三流标识；根据本端能力和该流媒体会话建立请求中的客户端推荐的所述第三流标 识， 协商得到包含当前流媒体类型与当前流媒体传输所用流标识的对应关系的协商确认信息， 其中 所述流标识为所述第三流标识或者重新分配的第四流标识。 图 15为本发明实施例实现流媒体通信的系统的组成结构示意图。 参见图 15， 本发明实施例提 供的实现流媒体通信的系统包括图 13所示客户端和图 14所示服务器， 具体地：
客户端 1501， 用于向服务器 1502发送携带有流媒体传输协商请求信息的流媒体会话建立请求， 接收服务器 1502返回的对应于所述流媒体会话建立的响应，从所述响应中获得流媒体传输协商确认 信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系； 并用于向服务器 1502发送播放请求， 接收来自服务器 1502流媒体数据， 根据接收的流媒体数据中 携带的用于传输所述流媒体数据所用的 SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型 的对应关系， 确定所述接收的流媒体数据的类型；
服务器 1502, 用于接收来自客户端 1501 的流媒体会话建立请求， 从所述流媒体会话建立请求 获取流媒体传输协商请求信息，根据本端能力以及所述协商请求信息确定流媒体传输协商确认信息， 返回携带有所述协商确认信息的对应于所述流媒体会话建立请求的响应给客户端 1501， 并用于接收 来自客户端 1501 的播放请求， 将相应的流媒体数据发送给客户端 1501， 所述流媒体数据携带有用 于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
参见图 9、 12, 应当理解的是： 当 Client a与 Proxy B通信时， 这里的 Client a的角色是客 户端， 相应的 Proxy B为服务器端；
当 Proxy B与 Server C通信时， 这里的 Proxy B的角色就是客户端， 相应的 Server C为服务 器端。
由上述可见， 本发明实施例所提供的实现流媒体通信的方法， 首先由客户端向服务器端发送携 带有流媒体传输协商请求信息的流媒体会话建立请求， 并由服务器端根据本端能力和所述协商请求 信息确定流媒体传输协商确认信息， 所述协商确认信息至少包含当前流媒体类型与当前流媒体传输 所用的流标识之间的对应关系， 并将携带有所述协商确认信息的响应返回给客户端， 然后由客户端 向服务器端发送播放请求， 服务器端通过协商确认的流标识对应的流传输相应的流媒体数据， 该流 媒体数据携带有流标识， 最后由客户端根据流媒体数据中携带的流标识确定该流媒体数据的类型， 可见， 使得客户端的应用程序通过流媒体数据中携带的流标识即可区分所接收的数据是控制数据还 是流媒体数据， 并确定流媒体数据的类型， 从而降低了应用层的实现复杂度， 减少了传输时延， 提 高了流媒体通信的性能。
实际应用中存在各种各样的流媒体通信场景， 例如： 流媒体通信可能只涉及客户端和服务器， 还可能进一步涉及代理； 所述客户端和服务器可能位于不同网络， 而代理位于网络边缘； 流媒体数 据可能需要经过代理， 也可能不需要经过代理等等。 因此， 本发明针对实际应用中可能出现的各种 流媒体通信应用场景， 提出了与之相应的实现流媒体通信的技术方案。 下面将根据不同的应用场景 描述本发明实施例所提供的实现流媒体通信的技术方案。 实施例一： 对于不涉及代理， 客户端在内部网络、 服务器在外部网络的情况， 本发明实施例中 提供了如下传输控制数据和媒体数据的技术方案：
在客户端与服务器之间， 为每一个流媒体会话建立一条 SCTP偶联， 每条 SCTP偶联中建立多个 流， 在每条 SCTP偶联的预先设置的流标识对应的流中传输控制数据， 并通过控制数据进行媒体传输 协商； 根据所述媒体传输协商的结果， 以与该协商结果对应的传输方式在所述每条 SCTP偶联的除预 先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据。
针对这种应用场景实现流媒体通信的系统的结构示意图如图 5所示。 图 5中， Client A表示客 户端， Server C表示服务器， Client A与 Server C之间的实线箭头表示 SCTP偶联， 该 SCTP偶联 中不仅承载有控制数据， 还承载有流媒体数据。
较佳地， 所述预先设置的流标识可以是流 0， 当然也可以是流 1， 等等。 上述在除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据可以 是： 在除所述预先设置的流标识对应的流之外的同一个流中传输同一流媒体会话的不同类型的流媒 体数据， 也可以是： 在除所述预先设置的流标识对应的流之外的不同流中分别传输同一流媒体会话 的不同类型的流媒体数据。 具体采用哪个流传输哪种流媒体数据， 是通过控制数据进行媒体传输协 商决定的。
图 6为本发明实施例一中进行媒体传输协商的过程示意图。 参见图 6， 媒体传输协商过程中涉 及的实体包括媒体接收端和媒体发送端， 对应于本实施例， 所述媒体接收端为客户端、 所述媒体发 送端为服务器端， 该媒体传输协商过程包括：
步骤 601 : 媒体接收端向媒体发送端指明： 采用 SCTP进行流媒体数据的传输， 以下简称 "媒体 传输"。
步骤 602: 媒体接收端向媒体发送端指明： 采用新建 SCTP偶联或原有已经建立好的 SCTP偶联 进行媒体传输。
步骤 603: 媒体接收端向媒体发送端指明： 媒体接收端的 IP和端口。
步骤 604: 媒体接收端向媒体发送端指明： 媒体接收端推荐的媒体所属 SCTP偶联的流标识。 步骤 605: 媒体发送端确认采用 SCTP进行媒体传输。
步骤 606: 媒体发送端确认采用新建 SCTP偶联或原有已经建立好的 SCTP偶联进行媒体传输。 步骤 607: 媒体发送端向媒体接收端指明： 媒体发送端的 IP和端口。
步骤 608: 媒体发送端确认媒体所属 SCTP偶联的流标识。
至此， 结束媒体传输协商过程。
假设本实施例中， 所述预先设置用于传输控制数据的流标识为 0， 经上述媒体传输协商之后， 决定使用流标识为 1的流传输音频数据、使用流标识为 2的流传输视频数据，以应用层协议采用 RTSP 为例， 图 7示出了本发明实施例一中所建立的偶联的结构示意图。 参见图 7， 客户端与服务器之间 的一个流媒体会话创建一条偶联， 该偶联创建 3个流， 其中， stream 0用于传输 RTSP控制数据， stream 1用于传输音频数据（如图所示 Audio RTP包）， stream 2用于传输视频数据（如图所示 Video RTP包）。
图 8为本发明实施例一中实现流媒体通信的消息交互流程示意图。 图中 RTSP Client A为本发 明实施例所述客户端， 以下简称 A; RTSP Server C为本发明实施例所述服务器， 以下简称 C。 图 8 所示消息交互流程包括以下步骤：
步骤 801 : A向 C发起 SCTP偶联 a， 同时在当前 SCTP偶联中建立多个流。 针对本实施例， 由于 将音频数据和视频数据置于不同流中传输， 因此， 所建立的流不少于 3个。
步骤 802: A在偶联 a的 stream 0上向 C发送 DESCRIBE请求，订阅流媒体文件； C收到 DESCRIBE 请求后在偶联 a的 stream 0上向 A返回 200 0K响应。
步骤 803: 完成音频会话建立过程， 同时完成媒体传输协商过程， 确定音频媒体数据在 SCTP的 哪个流上传输。 步骤 803具体包括如下步骤 8031和步骤 8032。
步骤 8031： A在偶联 a的 stream 0上向 C发送音频会话建立请求。 在音频连接建立请求的 transport头域中携带如下字段：
a) RTP/AVP/SCTP一一指明音频数据基于 SCTP传输；
b) connection=existing一一说明音频数据将基于原有已存在的偶联传输， 不需要重新创 建；
c) dest— addr= "192.0.2.5:544 "——音频数据的接收目的 ip地址和端口号， BP: Client
A的地址和端口号；
d) streamid='l: "——说明客户端建议音频数据所属 SCTP偶联的流标识， 1表示 RTP所属的流 标识， 冒号之后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。 流标识 A的建议值， 对端在回响应时可以改变。
示例如下：
SETUP rtsp: //example, com/ twister.3gp/audio RTSP/2.0
CSeq: 2
User- Agent: PhonyClient/1.2
Require： play, basic
Transport： RTP/AVP/SCTP； unicast； connection=existing;
dest_addr= " 192.0.2.5: 544 "； streamid=" 1: " ; 步骤 8032: C在偶联 a的 streamO上向 A发送 200 OK响应。 并在该 200 OK响应的 transport 头域中携带如下字段：
a) RTP/AVP/SCTP—指明音频媒体数据基于 SCTP传输；
b) connection existing—说明音频数据将基于原有已存在的偶联传输， 不需要重新创建； c) src_addr= "192.0.2.5:554" ——音频数据的源 ip地址和端口号；
d) streamid='l: "—说明服务器传输音频媒体的实际流标识， 1表示 RTP所属的流标识。 如 果冒号之后没有任何标识， 则表示无 RTCP包。
示例如下： RTSP/2.0 200 0K
CSeq: 2
Server: PhonyServer/1.0
Transport： RTP/AVP/SCTP； unicast； connect ion=exi sting;
src_addr="192.0.2.5:554";
streamid= " 1： "； ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Accept— Ranges : NPT
步骤 804: 完成视频会话建立过程， 同时完成媒体传输协商过程， 确定视频媒体数据在 SCTP 的哪个流上传输。 步骤 804具体包括如下步骤 8041和步骤 8042。
步骤 8041: A在偶联 a的 stream 0上向 B发送视频连接建立请求 （ SETUP (video) ) 。 本步骤中， 可以在视频连接建立请求的 transport头域中携带以下字段：
a) RTP/AVP/SCTP 指明视频媒体数据基于 SCTP传输；
b) connection existing 说明视频媒体数据基于原有已存在的偶联传输， 不需要重 新创建；
c) dest— addr="192.0.2.5:9000"——视频媒体数据的接收目的 ip地址和端口号； d) src_addr= "192.0.2.5:554" ——视频媒体数据的源 ip地址和端口号；
e) streamid='3:4' 说明客户端建议视频媒体数据所属 SCTP偶联的流标识， 3表示 RTP 所属的流标识， 4表示 RTCP所属的流标识。 如果冒号之后没有任何标识， 则表示无 RTCP包。 流 标识是 A的建议值， 对端在返回响应时可以改变。
示例如下：
SETUP rtsp://example. com/twister.3gp/video RTSP/2.0
CSeq: 3
User- Agent: PhonyClient/1.2
Require： play, basic
Session: 12345678
Transport： RTP/AVP/SCTP； unicast； connection= existing；
dest_addr="192.0.2.5: 9000"；
src_addr="192.0.2.5 : 554" ; streamid= "3:4 "； 步骤 8042: C在偶联 a的 stream 0上向 B发送 200 OK响应， 并在 transport头域中携带如下字 a) RTP/AVP/SCTP 指明视频媒体数据基于 SCTP传输；
b) connection existing 说明视频媒体数据基于原有已存在的偶联传输， 不需要重 新创建；
c) src_addr= "192.0.2.5:554" "——视频媒体数据的源 ip地址和端口号；
d) streamid='2:' 说明服务器传输视频媒体数据的实际流标识， 2表示 RTP所属的流标 识， 冒号之后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。
示例如下：
RTSP/2.0 200 0K
CSeq: 3 Server : PhonyServer/1. 0
Transport： RTP/AVP/SCTP； unicast； connection=existing ;
src_addr=" 192. 0. 2. 5 : 554" ;
streamid= "2 : "； ssrc=93CB001E
Session : 12345678
Expires : 24 Jan 1997 15 : 35 : 12 GMT
Date : 23 Jan 1997 15 : 35 : 12 GMT
Accept— Ranges : NPT
步骤 805: A在偶联 a的 stream 0上向 C发送播放 （PLAY) 请求消息， 请求播放流媒体； C收 到播放请求消息后， 在偶联 a的 stream 0上向 A返回 200响应。
步骤 806: C在协商好的流上传输音频和视频数据。在偶联 a的 streaml上传送音频 RTP包， 在 偶联 a的 stream2上传送视频 RTP包。
至此， 结束本发明实施例一中实现流媒体通信的消息交互流程。 实施例二： 对于涉及代理， 客户端在内部网络、 代理位于网络边缘、 服务器在外部网络、 流媒 体数据不经过代理的情况， 本发明实施例中提供了如下传输控制数据和媒体数据的技术方案： 由于流媒体数据不需要经过代理， 可以为每一个流媒体会话建立至少三条 SCTP偶联， 具体地： 在客户端与代理之间， 为每一个流媒体会话建立一条 SCTP偶联， 在所述 SCTP偶联的预先设置 的流标识对应的流中传输相应流媒体会话的控制数据， 并通过所述控制数据进行媒体传输协商； 在代理和服务器之间， 建立一条供多个流媒体会话共用的 SCTP偶联， 并在所述 SCTP偶联中建 立与所述多个流媒体会话一一对应的多个流， 在所述多个流中传输相应流媒体会话的控制数据， 并 通过所述控制数据进行相应流媒体会话的媒体传输协商；
根据所述媒体传输协商的结果，在客户端与服务器之间，为每一个流媒体会话建立至少一条 SCTP 偶联， 在所述至少一条偶联的除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的 流媒体数据。
针对这种应用场景实现流媒体通信的系统的结构示意图如图 9所示。图 9中， Client a、 Client b和 Client c表示客户端， ProxyB表示代理， Server C表示服务器， Client A与 ProxyB之间的实 线箭头， 以及 ProxyB与 Server C之间的实线箭头表示承载有控制数据的 SCTP偶联， Client A与 Server C之间的虚线箭头表示承载有流媒体数据的 SCTP偶联。
与实施例一类似， 较佳地， 所述预先设置的流标识可以是流 0， 当然也可以是流 1， 等等。 上述在除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据可以 是： 在除所述预先设置的流标识对应的流之外的同一个流中传输同一流媒体会话的不同类型的流媒 体数据， 也可以是： 在除所述预先设置的流标识对应的流之外的不同流中分别传输同一流媒体会话 的不同类型的流媒体数据。 具体采用哪个流传输哪种流媒体数据， 是通过控制数据进行媒体传输协 商决定的。 本实施例也可以根据图 6所示流程进行媒体协商。 仍然以应用层协议采用 RTSP为例，图 10示出了本发明实施例二中所建立的偶联的结构示意图。 参见图 10， 为描述简便， 图中省略了处于客户端与服务器之间的代理， 客户端与服务器之间的一个 流媒体会话创建两条偶联—— 3和1)， 其中， 偶联 a用于传输控制数据（如图所示 RTSP消息)， 偶联 b中的 stream 1用于传输音频数据 （如图所示 Audio RTP包）， 偶联 b中的 stream 2用于传输视频 数据 （如图所示 Video RTP包）。 值得说明的是： RTCP主要完成媒体数据的流量控制和拥塞控制， 而由于 SCTP已经提供了类似功能， 因此， 在基于 SCTP实现流媒体通信时， 可以不产生 RTCP包， 所 以， 图 10中并未示出 RTCP包。
图 11为本发明实施例二中实现流媒体通信的消息交互流程示意图。参见图 11，图中 RTSP Client A为本发明实施例所述客户端， 以下简称 A; RTSP Proxy B为本发明实施例所述代理， 以下简称 B; RTSP Server C为本发明实施例所述服务器， 以下简称 图 11所示消息交互流程包括以下步骤： 步骤 1101〜步骤 1102: 与图 8所示步骤 801〜802相同， 在此不再赘述。
步骤 1103: 完成音频会话建立过程， 同时需要完成媒体传输协商过程， 确定音频媒体数据在新 建 SCTP偶联的哪个流上传输。
A在偶联 a的 stream 0上向 B发送音频会话建立请求 （SETUP (audio) )， B收到所述音频会话建 立请求后， 也在偶联 c的 stream 0上向 C发送音频会话建立请求。
音频会话建立请求的 transport头域中需要携带该音频会话的相关信息， 例如： 基于哪种协议 传输流媒体数据等。 本步骤中， 可以在音频会话建立请求的 transport头域中携带如下字段： a) RTP/AVP/SCTP 指明流媒体数据基于 SCTP传输；
b) connection=new——说明需要创建一条新的偶联；
c) setup=active——说明 SCTP偶联是由 A主动创建的；
d) dest_addr=' : 9' 流媒体数据的目的 ip地址和端口号， BP : Cl ient A的地址和端口 号， 因为是 A主动创建， 所以端口号设置为 9 (废弃端口） ；
e) streamid=' l : "——说明流媒体所属 SCTP偶联的流标识， 1表示 RTP所属的流标识， 冒 号之后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。 流标识 为 A的建议值， 对端在返回响应时可以改变。
示例如下：
SETUP rtsp : //example, com/twister. 3gp/trackID=l RTSP/2. 0
CSeq : 2
User- Agent : PhonyCl ient/1. 2
Require： play. basic
Transport： RTP/AVP/SCTP； unicast； connection=new ；
setup=act ive； dest_addr= "： 9 "；
streamid= " 1： "；
C在偶联 c的 stream 1上向 B发送 200 OK响应， B收到该 200 OK响应后， 在偶联 a的 stream 1 上向 A发送 200 OK响应， 并在该 200 OK响应的 transport头域中携带如下字段： a) RTP/AVP/SCTP——指明流媒体基于 SCTP传输；
b) connection=new——说明需要创建一条新的偶联；
c) setup=passive——说明 SCTP偶联是 B被动创建；
d) src_addr= "192.0.2.5:554" ——流媒体数据的源 ip地址和端口号， 这里是 Server C 的地址和端口号；
e) streamid='l:' 说明 B传输流媒体的实际流标识， 1表示 RTP所属的流标识， 冒号之 后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。
示例如下： RTSP/2.0 200 0K
CSeq: 2
Server： PhonyServer/1.0
Transport： RTP/AVP/SCTP； unicast； connect ion=new;
setup=passive； src_addr='192.0.2.5 : 554"；
streamid= "1: "； ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35: 12 GMT
Date: 23 Jan 1997 15:35: 12 GMT
Accept— Ranges : NPT 步骤 1104: A向 C发起 SCTP偶联 b。
通过上述步骤 1103， A与 C之间已经协商好： 由 A主动创建一条与 C之间的偶联， 用于传输 A 与 C之间的流媒体数据， 并且， 已协商好各自用于该偶联的 ip地址和端口号， 以及该偶联中用 于传输流媒体数据的流的流标识。 因此， 本步骤中， A将向 C发起 SCTP偶联 b， 建立上述已经协 商好的偶联。
步骤 1105: 完成视频会话建立过程， 同时需要完成媒体传输协商过程， 确定视频媒体数据 在 SCTP的哪个流上传输。
A在偶联 a的 stream 0上向 B发送视频连接建立请求 （SETUP (video) ) ， B收到所述视频连接建立 请求后， 也在偶联 c的 stream 0上向 C发送视频连接建立请求。
本步骤中， 可以在视频连接建立请求的 transport头域中携带以下字段：
a) RTP/AVP/SCTP——指明流媒体基于 SCTP传输；
b) connection= existing——说明使用已经存在的偶联， 不需要重新创建； 因为通过上 述步骤 1106， A与 C之间已经建立起用于传输流媒体数据的偶联 b， 所以不需要重新创建了； c) dest— addr="192.0.2.5:9000"——流媒体数据的目的 ip地址和端口号；
d) src_addr= "192.0.2.5:554" ——流媒体数据的源 ip地址和端口号； e) streamid='2:' 说明流媒体所属 SCTP偶联的流标识， 2表示 RTP所属的流标识， 冒号 之后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。 流标识是 A的建议值， 对端在返回响应时可以改变。
示例如下： SETUP rtsp: //example, com/twister.3gp/trackID=2 RTSP/2.0
CSeq: 3
User- Agent: PhonyClient/1.2
Require： play. basic
Session: 12345678
Transport： RTP/AVP/SCTP； unicast； connection= existing；
dest_addr="192.0.2.5: 9000"；
src_addr="192.0.2.5 : 554" ; streamid= "2: "；
C在偶联 c的 stream 0上向 B发送 200 OK响应， B收到该 200 OK响应后， 在偶联 a的 stream 0 上向 A发送 200 OK响应， 并在 transport头域中携带如下字段：
a) RTP/AVP/SCTP——指明流媒体基于 SCTP传输；
b) connection= existing——说明使用已经存在的偶联， 不需要重新创建；
c) src_addr= "192.0.2.5:554" "——流媒体数据的源 ip地址和端口号；
d) streamid='2:' 说明 B传输流媒体的实际流标识， 2表示 RTP所属的流标识， 冒号之 后的数字表示 RTCP所属的流标识， 如果冒号之后没有任何标识， 则表示无 RTCP包。
示例如下：
RTSP/2.0 200 0K
CSeq: 3
Server: PhonyServer/1.0
Transport： RTP/AVP/SCTP； unicast； connection=existing;
src_addr="192.0.2.5: 554"；
streamid= "2: "； ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept- Ranges: NPT
步骤 1106: A在偶联 a的 stream 0上向 B发送播放 （PLAY) 请求消息， 请求播放流媒体； B收 到播放请求消息后， 也在偶联 c的 stream 0上向 C发送播放请求消息。 C在偶联 c的 stream 0上 向 B返回 200 0K响应， B收到 200 0K响应后， 在偶联 a的 stream 0上向 A返回 200响应。 步骤 1107: 根据上述步骤 1103和 1104协商的结果， C将在偶联 b的 streaml上传送音频 RTP 包， 在偶联 b的 stream2上传送视频 RTP包； 相应地， A将在偶联 b的 streaml上接收音频 RTP包， 在偶联 b的 stream2上接收视频 RTP包。
至此， 结束本发明实施例二中实现流媒体通信的消息交互流程。 实施例三： 对于涉及代理， 客户端在内部网络、 代理位于网络边缘、 服务器在外部网络、 流媒 体数据需要经过代理的情况， 本发明实施例中提供了如下传输控制数据和媒体数据的技术方案： 在客户端与代理之间， 为每一个流媒体会话建立一条 SCTP偶联， 每条 SCTP偶联中建立多个流， 在每条 SCTP 偶联的预先设置的流标识对应的流中传输控制数据， 并通过控制数据完成媒体传输协 商， 根据所述媒体传输协商的结果， 以与该协商结果对应的传输方式在所述每条 SCTP偶联的除预先 设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据；
在代理和服务器之间， 建立一条供多个流媒体会话共用的 SCTP偶联， 并在所述 SCTP偶联中建 立与所述多个流媒体会话一一对应的多个流， 在所述多个流中传输相应流媒体会话的控制数据， 并 通过控制数据完成媒体传输协商，根据所述媒体传输协商的结果在所述 SCTP偶联的除用于传输控制 数据的流之外的其他流中传输流媒体数据。
针对这种应用场景实现流媒体通信的系统的结构示意图如图 12所示。 图 12中， 各 Client与 Proxy B之间的实线箭头以及 Proxy B与 Server C之间的实线箭头表示 SCTP偶联， 各 SCTP偶联中 不仅承载有控制数据， 还承载有流媒体数据。 以上对本发明实施例提供的实现流媒体通信的方法进行了详细说明， 下面结合附图， 对本发明 实施例提供的实现流媒体通信的系统进行说明。
参见图 5所示本发明实施例一中实现流媒体通信的系统结构示意图， 该系统包括客户端 A和 服务器 C， 其中：
所述客户端 A，用于与服务器 C建立 SCTP偶联，在所述 SCTP偶联的预先设置的流标识对应的 流中传输流媒体会话的控制数据 （应当理解的是： 控制数据就是客户端 A和服务器 C之间交互的信 令消息）， 进行媒体传输协商， 并用于根据所述媒体传输协商的结果， 以与该协商结果对应的传输方 式接收相应流媒体会话的流媒体数据； 需要说明的是： 前述提及的 "进行媒体传输协商， 并用于根 据所述媒体传输协商的结果， 以与该协商结果对应的传输方式接收相应流媒体会话的流媒体数据" 的描述请参考前述图 15所示的本发明实施例的实现流媒体通信的系统的描述。
所述服务器 C，用于与客户端 A建立 SCTP偶联， 并用于在所述 SCTP偶联的预先设置的流标识 对应的流中传输流媒体会话的控制数据， 进行媒体传输协商， 并用于根据所述媒体传输协商的结果， 以与该协商结果对应的传输方式发送相应流媒体会话的流媒体数据。需要说明的是：前述提及的"进 行媒体传输协商， 并用于根据所述媒体传输协商的结果， 以与该协商结果对应的传输方式发送相应 流媒体会话的流媒体数据"的描述请参考前述图 15所示的本发明实施例的实现流媒体通信的系统的 描述。 图 5所述系统中， 所述服务器 C， 还可以用于根据所述媒体传输协商的结果在所述 SCTP偶联中 建立多个流， 并用于在除所述预先设置的流标识对应的流之外的其他流中发送相应流媒体会话的流 媒体数据；
所述客户端 A， 还可以用于在除所述预先设置的流标识对应的流之外的其他流中接收相应流媒 体会话的流媒体数据。 参见图 9、 图 12所示本发明实施例二中实现流媒体通信的系统结构示意图， 图 9和图 12所示 系统结构示意图适用于系统包括客户端 a、 b、 c、 代理 B和服务器 C的情况， 其中：
所述客户端 a、 b、 c , 用于与代理 B建立 SCTP偶联， 并用于在所述 SCTP偶联的预先设置的流 标识对应的流中传输流媒体会话的控制数据， 进行媒体传输协商， 并用于根据所述媒体传输协商的 结果， 接收相应流媒体会话的流媒体数据； 需要说明的是： 前述提及的 "进行媒体传输协商， 并用 于根据所述媒体传输协商的结果， 接收相应流媒体会话的流媒体数据"的描述请参考前述图 15所示 的本发明实施例的实现流媒体通信的系统的描述。
所述代理 B， 用于与客户端 a、 b、 c分别建立 SCTP偶联， 在所述 SCTP偶联的预先设置的流标 识对应的流中传输流媒体会话的控制数据， 进行媒体传输协商； 并用于与服务器建立供多个流媒体 会话共用的 SCTP偶联， 在所述共用的 SCTP偶联中建立与所述多个流媒体会话一一对应的多个流， 在所述多个流中传输相应流媒体会话的控制数据， 通过所述控制数据进行相应流媒体会话的媒体传 输协商； 需要说明的是： 前述提及的 "进行媒体传输协商"和 "在所述多个流中传输相应流媒体会 话的控制数据， 通过所述控制数据进行相应流媒体会话的媒体传输协商"的描述请参考前述图 15所 示的本发明实施例的实现流媒体通信的系统的描述。
所述服务器 C， 用于与代理 B建立供多个流媒体会话共用的 SCTP偶联， 在所述共用的 SCTP偶 联中建立与所述多个流媒体会话一一对应的多个流， 在所述多个流中传输相应流媒体会话的控制数 据， 通过所述控制数据进行相应流媒体会话的媒体传输协商， 并用于根据所述媒体传输协商的结果， 发送相应流媒体会话的流媒体数据。 需要说明的是： 前述提及的 "在所述多个流中传输相应流媒体 会话的控制数据， 通过所述控制数据进行相应流媒体会话的媒体传输协商， 并用于根据所述媒体传 输协商的结果， 发送相应流媒体会话的流媒体数据"的描述请参考前述图 15所示的本发明实施例的 实现流媒体通信的系统的描述。
图 9所示系统中， 所述服务器 C， 还用于根据所述媒体传输协商的结果与客户端 a、 b、 c建立 至少一条 SCTP偶联， 在所述至少一条 SCTP偶联的除预先设置的流标识对应的流之外的其他流中发 送相应流媒体会话的流媒体数据；
所述客户端 a、 b、 c , 还用于在所述至少一条 SCTP偶联的除预先设置的流标识对应的流之外的 其他流中接收相应流媒体会话的流媒体数据。
较佳地， 图 9所示系统中， 所述服务器 C为第一服务器， 可以用于根据所述媒体传输协商的结 果与客户端建立一条包含多个流的 SCTP偶联， 并用于在所述包含多个流的 SCTP偶联的除预先设置 的流标识对应的流之外的多个流中分别发送不同类型的流媒体数据； 所述客户端 a、 b、 c为第一客户端， 可以用于在所述包含多个流的 SCTP偶联的除预先设置的流 标识对应的流之外的多个流中分别接收不同类型的流媒体数据。
较佳地， 图 9所示系统中， 所述服务器 C为第二服务器， 可以用于根据所述媒体传输协商的结 果与客户端建立多条 SCTP偶联， 并用于在所述多条 SCTP偶联的除预先设置的流标识对应的流之外 的流中分别发送不同类型的流媒体数据；
所述客户端 a、 b、 c为第二客户端， 可以用于在所述多条 SCTP偶联的除预先设置的流标识对应 的流之外的流中分别接收不同类型的流媒体数据。
图 12所示系统中， 所述服务器 C， 还用于根据所述媒体传输协商的结果在所述共用的 SCTP偶 联中为所述多个流媒体会话的每一个流媒体会话建立至少一个流， 在所述至少一个流中发送相应流 媒体会话的流媒体数据；
所述代理 B， 还用于在所述共用的 SCTP偶联的多个流中接收相应流媒体会话的流媒体数据； 并用于根据所述媒体传输协商的结果在所述与客户端 a、 b、 c之间的 SCTP偶联中建立多个流， 在所 述建立的多个流的除所述预先设置的流标识对应的流之外的其他流中发送接收自服务器的相应流媒 体会话的流媒体数据；
所述客户端 a、 b、 c, 还用于在所述与代理之间建立的多个流的除所述预先设置的流标识对应 的流之外的其他流中接收相应流媒体会话的流媒体数据。
由上述实施例可见， 本发明实施例所提供的实现流媒体通信的方法， 通过在代理与服务器之间 建立供多个流媒体会话共用的 SCTP偶联， 并在所述共用的 SCTP偶联的不同流上传输所述多个流媒 体会话的控制数据， 这样， 可以通过所述控制数据进行媒体传输协商， 从而确定如何进行流媒体数 据的传输。一方面能够充分利用 SCTP偶联的多流特性， 使应用程序通过流标识即可区分所接收的数 据属于哪一个流， 从而降低了应用层的实现复杂度、 减少了传输时延、 提高了流媒体通信的性能， 并增强了多路会话的并发性； 另一方面， 由于代理与服务器之间的多个流媒体会话共用一条 SCTP偶 联， 减少了创建 SCTP偶联所带来的开销以及资源消耗。
此外， 由于 SCTP协议本身所具备的一些优秀特性， 使得本发明实施例所提供的实现流媒体通信 的技术方案还能取得如下有益效果：
1 )通过 SCTP建立"四次握手"中的 cookie机制， 有效避免服务器遭受拒绝服务（DOS, Denial of Service) 攻击， 增强了流媒体通信的安全性， 使得提供实时流媒体数据的服务器变得更加可靠。
2 ) SCTP 具有无序可靠传输的功能， 可以使达到接收端的数据包不用等待前面的数据包就可以 直接提交到应用层， 提高了数据的传输效率。
3 ) 利用 SCTP支持多流传输的功能， 使音频数据和视频数据分开传输， 减少了声音和视频同时 丢包失真的概率。
本领域普通技术人员可以理解实现上述实施例中实现流媒体通信的过程可以通过程序指令相关 的硬件来完成， 所述的程序可以存储于客户端、 代理或服务器的可读取存储介质中， 该程序在执行 时执行上述方法中的对应步骤。 所述的存储介质可以如： R0M/MM、 磁碟、 光盘等。
以上所述仅为本发明的较佳实施例而已， 并非用于限定本发明的保护范围。 凡在本发明的精神 和原则之内所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求
1、 一种实现流媒体通信的方法， 其特征在于， 应用于客户端， 包括：
发送流媒体会话建立请求， 所述请求中携带有流媒体传输协商请求信息；
接收服务器端返回的响应， 从所述响应中获得流媒体传输协商确认信息， 所述协商确认信息至 少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；
发送播放请求；
接收服务器返回的流媒体数据， 所述流媒体数据中携带有用于传输所述流媒体数据所用的流控 制传输协议 SCTP偶联的流对应的流标识；
根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系， 确定所述流媒体数据 的类型。
2、 根据权利要求 1所述的方法， 其特征在于， 在所述发送流媒体会话建立请求之前， 进一步包 括： 对应于每一个流媒体会话， 建立一条 SCTP偶联， 并预先设置用于传输控制数据的所述 SCTP偶 联中流对应的流标识；
所述发送流媒体会话建立请求包括：在与所述请求所属的流媒体会话对应的 SCTP偶联中的所述 预先设置的流标识对应的流上发送进一步携带有所述预先设置的流标识的流媒体会话建立请求； 所述接收服务器端返回的响应包括：从与所述响应所属的流媒体会话对应的 SCTP偶联中的所述 预先设置的流标识对应的流上接收进一步携带有所述预先设置的流标识的响应；
所述发送播放请求包括：在与所述请求所属的流媒体会话对应的 SCTP偶联中的所述预先设置的 流标识对应的流上发送携带有所述预先设置的流标识的播放请求。
3、 根据权利要求 1所述的方法， 其特征在于， 在所述发送流媒体会话建立请求之前， 进一步包 括： 建立一条供多个流媒体会话共用的 SCTP偶联， 并设置各个流媒体会话与所述共用的 SCTP偶联 的各个流标识之间的对应关系， 所述各个流标识对应的流分别用于传输对应的流媒体会话的控制数 据；
所述发送流媒体会话建立请求包括： 根据所述设置的对应关系确定与所述请求所属的流媒体会 话对应的流标识，在所述共用的 SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述确 定的流标识的流媒体会话建立请求；
所述接收服务器端返回的响应包括： 根据所述设置的对应关系确定与所述响应所属的流媒体会 话对应的流标识，从所述共用的 SCTP偶联中所述确定的流标识对应的流上接收进一步携带有所述确 定的流标识的响应；
所述发送播放请求包括： 根据所述设置的对应关系确定与所述请求所属的流媒体会话对应的流 标识，在所述共用的 SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述流标识的播放 请求。
4、 根据权利要求 2或 3所述的方法， 其特征在于， 所述接收进一步携带有所述流标识的响应的 步骤后， 进一步包括：
根据所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果， 确定所述 接收到的响应是控制数据。
5、 根据权利要求 2或 3所述的方法， 其特征在于， 所述协商请求信息中包含： 客户端推荐的用 于传输当前流媒体数据所属 SCTP偶联的流标识；
所述协商确认信息中包含：服务器端协商确认的用于传输当前流媒体数据所属 SCTP偶联的流标 识。
6、 根据权利要求 5所述的方法， 其特征在于， 所述协商请求信息中进一步包含： 表示采用已经 建立的 SCTP偶联进行传输的信息、 或表示采用新建的 SCTP偶联进行传输的信息；
所述协商确认信息中进一步包含： 表示采用已经建立的 SCTP偶联进行传输的信息、或表示采用 新建的 SCTP偶联进行传输的信息。
7、 根据权利要求 6所述的方法， 其特征在于， 若所述协商确认信息中包含表示采用已经建立的
SCTP偶联进行传输的信息， 则所述接收服务器返回的流媒体数据包括： 从已经建立的 SCTP偶联中 协商确认的流标识对应的流上接收服务器端返回的流媒体数据。
8、根据权利要求 6所述的方法，其特征在于， 若所述协商确认信息中包含表示采用新建的 SCTP 偶联进行传输的信息， 则在接收服务器端返回的响应之后， 进一步包括： 对应所述流媒体会话， 建 立新的 SCTP偶联；
所述接收服务器返回的流媒体数据包括：从所述新的 SCTP偶联中协商确认的流标识对应的流上 接收服务器端返回的流媒体数据。
9、 一种实现流媒体通信的方法， 其特征在于， 应用于服务器端， 包括：
接收流媒体会话建立请求， 所述请求中携带有流媒体传输协商请求信息；
根据本端能力和所述协商请求信息， 确定流媒体传输协商确认信息， 所述协商确认信息至少包 含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系， 并返回与所述流媒体会话建立 请求对应的响应， 所述响应中携带有所述协商确认信息；
接收播放请求；
通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒体数据， 所述流媒 体数据中包含用于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
10、 根据权利要求 9所述的方法， 其特征在于， 在所述接收流媒体会话建立请求之前， 进一步 包括： 对应于每一个流媒体会话， 建立一条 SCTP偶联；
所述接收流媒体会话建立请求包括：从与所述请求所属的流媒体会话对应的 SCTP偶联中的流上 接收进一步携带有客户端预先设置的第一流标识的流媒体会话建立请求；
所述返回响应包括：在与所述响应所属流媒体会话对应的 SCTP偶联中所述携带于所述流媒体会 话建立请求中的第一流标识对应的流上发送携带有所述第一流标识的响应；
所述接收播放请求包括：从与所述请求所属的流媒体会话对应的 SCTP偶联中的所述第一流标识 对应的流上接收携带有所述第一流标识的播放请求。
11、 根据权利要求 9所述的方法， 其特征在于， 在所述接收流媒体会话建立请求之前， 进一步 包括： 建立一条供多个流媒体会话共用的 SCTP偶联； 所述接收流媒体会话建立请求包括：从所述共用的 SCTP偶联中的流上接收进一步携带有客户端 确定的第二流标识的流媒体会话建立请求；
所述返回响应包括：在所述共用的 SCTP偶联中所述携带的第二流标识对应的流上发送进一步携 带有所述第二流标识的响应；
所述接收播放请求包括：从所述共用的 SCTP偶联中的流上接收携带有所述第二流标识的播放请 求。
12、 根据权利要求 10或 11所述的方法， 其特征在于， 所述协商请求信息中包含： 客户端推荐 的用于传输当前流媒体数据所属 SCTP偶联的第三流标识；
所述根据本端能力和所述协商请求信息， 确定流媒体传输协商确认信息的步骤包括： 根据本端能力和该流媒体会话建立请求中的客户端推荐的用于传输当前流媒体数据的第三流标 识， 协商确认用于传输当前流媒体数据所属 SCTP偶联的流标识， 所述流标识为所述第三流标识或者 服务器端重新分配的第四流标识， 得到包含当前流媒体类型与当前流媒体传输所用的流标识的对应 关系的协商确认信息。
13、 根据权利要求 12所述的方法， 其特征在于， 所述协商请求信息中包含： 表示采用已经建立 的 SCTP偶联进行传输的信息、 或表示采用新建的 SCTP偶联进行传输的信息；
所述根据本端能力和所述协商请求信息， 确定协商确认信息包括： 根据本端能力和所述协商请 求信息，确定采用已经建立的 SCTP偶联中所述客户端推荐的第三流标识或者服务器端重新分配的第 四流标识对应的流传输当前流媒体数据， 得到包含当前媒体流类型与当前媒体流传输所用的流标识 的对应关系以及表示媒体传输所用的 SCTP偶联的信息的协商确认信息；
或者， 根据本端能力和所述协商请求信息， 确定采用新建的 SCTP偶联中所述客户端推荐的第三 流标识或者服务器端重新分配的第四流标识对应的流传输当前流媒体数据， 得到包含当前媒体流类 型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的 SCTP 偶联的信息的协商确 认信息。
14、 根据权利要求 13所述的方法， 其特征在于， 若所述协商确认信息为采用已经建立的 SCTP 偶联进行传输， 则所述通过协商确认的流标识对应的流传输相应的流媒体数据包括： 在所述已经建 立的 SCTP偶联中协商确认的流标识对应的流上传输流媒体数据。
15、 根据权利要求 13所述的方法， 其特征在于， 若所述协商确认信息为采用新建的 SCTP偶联 进行传输， 则在所述返回响应之后， 进一步包括： 对应所述流媒体会话， 重新建立新的 SCTP偶联； 所述通过协商确认的流标识对应的流传输相应的流媒体数据包括：在所述新的 SCTP偶联中协商 确认的流标识对应的流上传输流媒体数据。
16、 一种客户端， 其特征在于， 包括：
第一会话管理模块， 用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求， 并从对 应于所述流媒体会话建立请求的响应中获得流媒体传输协商确认信息， 所述协商确认信息至少包含 当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；
第一播放处理模块， 用于构造播放请求， 并根据接收的流媒体数据中携带的用于传输所述流媒 体数据所用的流控制传输协议 SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关 系， 确定所述接收的流媒体数据的类型；
第一通信模块， 用于发送所述流媒体会话建立请求和播放请求， 并用于接收来自服务器端的对 应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据， 所述流媒体数据携带用 于传输所述流媒体数据所用的流控制传输协议 SCTP偶联的流对应的流标识。
17、 根据权利要求 16所述的客户端， 其特征在于， 进一步包括： 第一确定单元， 用于根据所述 第一通信模块接收的所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结 果， 确定所述接收到的响应是控制数据。
18、 一种服务器， 其特征在于， 包括：
第二会话管理模块， 用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息， 根据 本端能力以及所述协商请求信息确定流媒体传输协商确认信息； 所述协商确认信息至少包含当前流 媒体类型与当前流媒体传输所用的流标识之间的对应关系；
第二播放处理模块， 用于在接收到播放请求后， 确定待发送的流媒体数据；
第二通信模块， 用于接收所述流媒体会话建立请求和播放请求， 并用于发送对应于所述流媒体 会话建立请求的响应和对应于所述播放请求的流媒体数据，其中所述响应携带有所述协商确认信息， 所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议 SCTP 偶联的流对应的流标 识。
19、 根据权利要求 18所述的服务器， 其特征在于，
第二会话管理模块， 具体用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息， 所述流媒体传输协商请求信息包含客户端推荐的用于传输当前流媒体数据所属 SCTP 偶联的第三流 标识； 根据本端能力和该流媒体会话建立请求中的客户端推荐的所述第三流标识， 协商得到包含当 前流媒体类型与当前流媒体传输所用流标识的对应关系的协商确认信息， 其中所述流标识为所述第 三流标识或者重新分配的第四流标识。
20、 一种实现流媒体通信的系统， 其特征在于， 包括如权利要求 16 所述客户端和如权利要求 18所述服务器。
PCT/CN2009/073728 2008-09-08 2009-09-03 实现流媒体通信的方法、装置及系统 WO2010025676A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810215636.2 2008-09-08
CN200810215636.2A CN101674228B (zh) 2008-09-08 2008-09-08 实现流媒体通信的方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2010025676A1 true WO2010025676A1 (zh) 2010-03-11

Family

ID=41796753

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073728 WO2010025676A1 (zh) 2008-09-08 2009-09-03 实现流媒体通信的方法、装置及系统

Country Status (2)

Country Link
CN (1) CN101674228B (zh)
WO (1) WO2010025676A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102638388B (zh) * 2011-02-09 2014-03-12 华为技术有限公司 流标签的协商方法、相关装置以及系统
CN102217237B (zh) * 2011-05-09 2013-12-04 华为技术有限公司 媒体流性能监控方法及设备
CN103210671B (zh) * 2011-09-06 2016-02-03 华为技术有限公司 一种消息发送方法和装置
CN102546803B (zh) * 2012-01-13 2014-08-20 浙江工商大学 基于能力集的远端桌面通信方法
WO2015192288A1 (zh) * 2014-06-16 2015-12-23 华为技术有限公司 一种通信连接的建立方法、终端和系统
CN105530615A (zh) * 2015-10-23 2016-04-27 江苏鑫软图无线技术股份有限公司 基于sctp协议的组呼业务数据分组识别方法
CN111107445B (zh) * 2018-10-29 2023-04-18 浙江宇视科技有限公司 一种媒体协议流优化方法及系统
CN110049310B (zh) * 2019-04-04 2021-06-15 广东省安心加科技有限公司 视频图像获取、视频质量检测方法和装置
CN114244908B (zh) * 2021-11-05 2024-08-23 浙江蓝卓工业互联网信息技术有限公司 一种跨网域的rtsp流媒体传输方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1717914A (zh) * 2003-10-23 2006-01-04 国际商业机器公司 用于在网络中动态实时流聚集的方法、系统和产品
EP1921870A2 (en) * 1999-09-21 2008-05-14 Alcatel USA Sourcing, L.P. System and method for transporting IN/AIN signalling over an internet protocol (IP) network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1921870A2 (en) * 1999-09-21 2008-05-14 Alcatel USA Sourcing, L.P. System and method for transporting IN/AIN signalling over an internet protocol (IP) network
CN1717914A (zh) * 2003-10-23 2006-01-04 国际商业机器公司 用于在网络中动态实时流聚集的方法、系统和产品

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HU, YANZHONG ET AL.: "Comparing and analysis research on performance of streaming media transmission SCTP protocol", NETWORK SECURITY TECHNOLOGY & APPLICATION, no. 6, June 2008 (2008-06-01), pages 82 - 84 *
STEWART, R. ET AL., RFC 2960, STREAM CONTROL TRANSMISSION PROTOCOL, October 2000 (2000-10-01) *

Also Published As

Publication number Publication date
CN101674228A (zh) 2010-03-17
CN101674228B (zh) 2011-10-05

Similar Documents

Publication Publication Date Title
WO2010025676A1 (zh) 实现流媒体通信的方法、装置及系统
US9590821B2 (en) Communication system for transmitting data under a tunnel protocol between at least two data computers via a wide area network and a method for running such a communication system
JP5043392B2 (ja) Ｓｉｐ通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム
US8788682B2 (en) Communication device, and method, in an internet protocol network, of controlling a communication device
JP2006525693A (ja) マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法
WO2007031028A1 (fr) Procede de negociation de la duree du paquet de flux multimedia
TW200427269A (en) Methods for managing a pool of multicast addresses and allocating addresses in a communications system
CN107113223B (zh) 用于消息会话中继协议会话的消息块大小的协商
WO2012174927A1 (zh) 一种视频监控系统及媒体穿越网络地址转换设备的方法
WO2015180570A1 (zh) 数据通道建立方法和通信设备
WO2019184262A1 (zh) 多类型媒体数据网络地址转换穿越方法、终端及系统
WO2007019777A1 (fr) Méthode d’établissement de session et nœud de contrôle de session
WO2009082908A1 (fr) Procédé, dispositif et système de traitement d'un protocole de flux en temps réel
CN111107445B (zh) 一种媒体协议流优化方法及系统
US8463307B1 (en) Method of requesting a communication session using segmented signaling messages
WO2008086741A1 (fr) Procédé, dispositif et système pour réaliser un service de télécopie et. 38 sur internet
Ver Steeg et al. Unicast-based rapid acquisition of multicast RTP sessions
WO2015192288A1 (zh) 一种通信连接的建立方法、终端和系统
JP4868606B2 (ja) ストリーミング送信制御方法
EP2239923B1 (en) Relay access node with separate control and transport signaling for session-based communications
WO2006000141A1 (fr) Systeme de securite du reseau multimedia et procede correspondant
Herrero et al. Application layer
KR100748695B1 (ko) 하나의 세션을 사용하여 서로 다른 종류의 ｐｔａ 서비스를동시에 수행하는 ｐｔａ 서비스 방법 및 그 시스템
Camarillo et al. RFC 8855: The Binary Floor Control Protocol (BFCP)
Ver Steeg et al. RFC 6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions

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: 09811051

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: 09811051

Country of ref document: EP

Kind code of ref document: A1