WO2007121264A2 - Procédés et dispositif pour combiner des techniques d'accélération de session pour accélérer les négociations orientées support - Google Patents

Procédés et dispositif pour combiner des techniques d'accélération de session pour accélérer les négociations orientées support Download PDF

Info

Publication number
WO2007121264A2
WO2007121264A2 PCT/US2007/066462 US2007066462W WO2007121264A2 WO 2007121264 A2 WO2007121264 A2 WO 2007121264A2 US 2007066462 W US2007066462 W US 2007066462W WO 2007121264 A2 WO2007121264 A2 WO 2007121264A2
Authority
WO
WIPO (PCT)
Prior art keywords
session
terminal
message
media
fss
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2007/066462
Other languages
English (en)
Other versions
WO2007121264A3 (fr
Inventor
Marwan A. Jabri
David Jack
Robert Jongbloed
Brody Kenrick
David Myers
Mohammed Raad
Craig Southeren
Albert C. Wong
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dilithium Networks Pty Ltd
Original Assignee
Dilithium Networks Pty 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 Dilithium Networks Pty Ltd filed Critical Dilithium Networks Pty Ltd
Publication of WO2007121264A2 publication Critical patent/WO2007121264A2/fr
Publication of WO2007121264A3 publication Critical patent/WO2007121264A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways

Definitions

  • This application is also a continuation-in-part of U.S. Patent Application No. 1 1/408,810, filed on April 21, 2006, which claims priority to U.S. Provisional Patent Application No. 60/674,160, filed on March 21, 2005.
  • This application is also a continuation-in-part of U.S. Patent Application No. 11/482,515, filed on July 7, 2006, which claims priority to U.S. Provisional Patent Application No. 60/697,788, filed on July 8, 2005.
  • This application is also a continuation-in-part of U.S. Patent Application No.
  • H.324 is an International Telecommunication Union (ITU) protocol standard for multimedia communication over general switched networks (GSTN).
  • H.324M is an extension of H.324 for operations over mobile networks
  • 3G-324M is a recommendation by the third generation partnership program (3GPP) defining adaptation of H.324M for use within 3GPP and also adopted by 3GPP2.
  • 3GPP third generation partnership program
  • H.324-like equipment devices and systems employing protocol based or derived from H.324.
  • H.324-like equipment can connect to other H.324-like equipment via switching centers and to other non-H.324-like equipment through multimedia gateways.
  • An example of a non-H.324-like equipment is an H.323 equipment.
  • H.323 is an International Telecommunication Union (ITU) protocol standard for multimedia communication over general switched networks (GSTN).
  • H.324M is an extension of H.324 for operations over mobile networks
  • 3G-324M is a recommendation by the third generation partnership
  • An H.323-like equipment is an equipment that employs a protocol based or derived from the H.323 protocol.
  • H.324 to indicate H.324-like equipment including H.324M and 3G-324M equipment and "H.323" to indicate H.323-like equipment.
  • equipment to indicate either a user end equipment such as a handset, or network end equipment such as a switch or gateway.
  • the term “equipment” covers the meaning of "entity”.
  • equipment and terminal interchangeably, and they both indicate the same meaning in the present document.
  • the present invention relates generally to the field of mobile networks. More particularly, the present invention relates to a method and apparatus for accelerated session setup in mobile networks. The method allows for the combination of a number of session setup techniques that can be used in a mobile terminal either together or independently of each other. Merely by way of example, three session setup techniques are combined in order to illustrate the operation of embodiments of the present invention.
  • the first stage of the call is to establish an end-to-end bearer between the equipments. This stage is called Call Signaling and is outside the scope of H.324, except where modems and the General Switched Telephony Network are used.
  • the second stage of the call is to establish the H.324 session, to provide a means of transporting video, audio and data between the equipments in a format that is known to, and supported by the equipments.
  • MLD Mobile level detection
  • media video, audio and data
  • media can flow between the terminals.
  • the SRP scheme (or Numbered version - NSRP, in cases where the mobile level is greater than zero) used for H.324/H.245, which requires an SRP message to be received by the endpoint for every message sent, prior to sending any other message, regardless of whether it is associated with the same Signaling Entity or not, further limits the scope to pipeline messages on the network, making call setup slower than if this were not the case.
  • SRP messages are not shown in FIG. 2. [0011] In conventional equipment, the combined effect of the requirement to send an H.245 Response message for each H.245 Request Message received, and of the need to receive an SRP Ack for every SRP Command Frame sent means that a single H.245 Request message may take some time to be conveyed successfully.
  • FIG. 1 The communication involved in sending an H.245 Request message from one terminal (A) to another (B), and getting an H.245 Response (Ack) message back is shown in FIG. 1, which also shows the SRP Command Frames (SRP CF) and SRP Response Frames (SRP RF or SRP Ack) involved when single H.245 messages are formed into single SRP Command Frames.
  • SRP CF SRP Command Frames
  • SRP RF or SRP Ack SRP Response Frames
  • the present invention relates generally to the field of mobile networks. More particularly, the present invention relates to a method and apparatus for accelerated session setup in mobile networks. The method allows for the combination of a number of session setup techniques that can be used in a mobile terminal either together or independently of each other. Merely by way of example, three session setup techniques are combined in order to illustrate the operation of embodiments of the present invention.
  • the present invention relates generally to methods of establishing multimedia telecommunication (a multimedia "call") between equipment ("terminals"). More particularly, the invention provides methods for reducing the time required to establish calls between terminals that implement the ITU-T H.324 Recommendation and other Standards and Recommendations derived from or related to this (H.324-like) such as the 3G-324M recommendation developed and adopted by the Third Generation Partnership Projects (3GPP and 3GPP2).
  • the invention has been applied to the establishment of multimedia telecommunication between 3G-324M (an H.324M based protocol) multimedia handsets on a mobile telecommunications network, and between 3G-324M multimedia handsets and other types of terminals (handsets or servers) and could be based on proprietary protocols or IP based terminals, such as H.323, SIP, RTSP, MRCP, or any other form of proprietary or standard multimedia communication protocol, on a packet network using a Multimedia Gateway or a 3G-324M terminating device to mediate between the protocols used at each end, but it would be recognized that the invention may also include other applications.
  • the 3G-324M terminating device could be a line- card that terminates 3G-324M calls and locally converts the signaling, session and media information to formats that could be processed and/or consumed locally and/or retransmitted using another protocol (proprietary or IP base) to another type of terminal (handset or server).
  • another protocol proprietary or IP base
  • Multimedia Gateway we will use the term Multimedia Gateway to indicate a stand-alone, a distributed or a simple line-card (e.g. blade, board or chip-set) that has the function of mediating connectivity between one or more multimedia terminals, regardless of whether the terminals are handsets or servers/gateways themselves.
  • the 3G-324M session could be established in a way where the call signaling could be performed using a protocol such a SIP, and where the 3G-324M payloads could be transported using one or more RTP channels.
  • a method of establishing a session between a first device and a second device is provided.
  • the session is established over a telecommunications network using an accelerated session setup technique.
  • the method includes providing a first accelerated session setup technique, providing a second accelerated session setup technique, and establishing the session using either the first accelerated session setup technique or the second accelerated session setup technique based on a predetermined process.
  • a telecommunications apparatus includes a first processor adapted to attempt session establishment using one or more explicit parameters and a second processor adapted to attempt session establishment using one or more preconfigured profiles.
  • the telecommunications apparatus also includes a third processor adapted to attempt session establishment using a field in an H.245 message and a transmitter adapted to transmit audio and video information in accordance with a session established in whole or in part by the first processor, the second processor, or the third processor.
  • a telecommunications apparatus includes a first processor adapted to attempt session establishment using one or more preconfigured profiles and one or more explicit parameters and a second processor adapted to attempt session establishment using a field in an H.245 message.
  • the telecommunications apparatus also includes a transmitter adapted to transmit audio and video information in accordance with a session established in whole or in part by the first processor or the second processor.
  • a telecommunications apparatus includes a first transmitter adapted to send media to a telecommunications device prior to receiving an in-band message from the telecommunications device and a second transmitter adapted to send interleaved multiplexer level sequences to the telecommunications device.
  • the telecommunications apparatus also includes a processor adapted to determine a partial completion of a desired session and a third transmitter adapted to send one or more H.245 messages.
  • the one or more H.245 messages are used to establish a video channel or an audio channel.
  • a method of establishing a session between a first terminal and a second terminal communicating through a telecommunications network includes performing a first session setup technique and determining a first portion of a set of desired session characteristics.
  • the method also includes performing a second session setup technique and determining a second portion of the set of desired session characteristics.
  • a telecommunications apparatus includes a first processor adapted to attempt session establishment using a first session establishment technique and a second processor adapted to attempt session establishment using a second session establishment technique.
  • the telecommunications apparatus also includes a transmitter adapted to transmit audio and video information in accordance with a session established in whole or in part by the first processor or the second processor.
  • a negotiated parameter of the first session establishment technique and the second session establishment technique includes a shared negotiated parameter.
  • a method of modifying a mode of operation for a session over one or more 3G telecommunication networks is provided.
  • the method is provided between at least a pair of H.324-like terminals coupled to the one or more 3G telecommunication networks.
  • the method includes utilizing a first accelerated session setup technique to establish the session between users prior to receiving an initial H.245 message.
  • the session is characterized by a first mode of operation.
  • the method also includes determining a second mode of operation for the session utilizing an H.245 message and establishing the second mode of operation for the session.
  • embodiments of the present invention provide for enhanced performance compared to conventional techniques and accelerated techniques. Moreover, embodiments provide increased flexibility in comparison with some accelerated techniques. As described throughout the present specification, by combining various techniques, embodiments provide a performance and flexibility tradeoff not available using a single technique. Utilizing a hierarchical approach, differing session setup techniques are employed in a logical manner. Additionally, embodiments provide desired performance in conditions of interoperation between conflicting versions of various session setup techniques. Furthermore, minimal degradation when negotiating with a conventional terminal or with terminals that support various acceleration techniques is experienced when using embodiments of the present invention. Also, since the desires of man-to-machine services might be different than man-to-man services, implementation options for varying services are provided as appropriate.
  • networks that support the H.324M standard for mobile multimedia telephony may use a number of available session setup schemes as further disclosed in the present application. These schemes differ in the speed of the session setup and the flexibility and reliability offered to the terminal and the network. Flexibility refers to the ability of service providers to provide the media in a differentiated way without having to define these new formats as part of the default formats supported by the network. Flexibility also refers to an ability to establish a session with desired characteristics determined at the terminal. Reliability refers to the confidence in successfully establishing a session, both in the presence of noise and in the likelihood that a peer terminal does not support a feature. Some session setup methods can be considered lossless in that acknowledgments are mandatory on the communicating devices, while others can be considered highly reliable because of the repetition of messages and other techniques. Depending upon the embodiment, one or more of these benefits, as well as other benefits, may be achieved.
  • FIG. 1 is a diagram useful in illustrating the communications that flow between two H.324 terminals when an H.245 Request message is sent from one terminal to the other;
  • FIG. 2 illustrates session Setup for a call between H.324-like equipment
  • FIG. 3 is a simplified flowchart illustrating a method of combining several session setup techniques according to an embodiment of the present invention
  • FIG. 4 is a simplified diagram illustrating the use of AnswerFastl according to an embodiment of the present invention.
  • FIG. 5 illustrates an embodiment of the ASN.1 Syntax description for an AnswerFast2 Request
  • FIG. 6 illustrates an embodiment of the ASN.1 Syntax description for an AnswerFast2 Response
  • FIG. 7 is a simplified diagram illustrating the use of AnswerFast2 according to an embodiment of the present invention.
  • FIG. 8 is a simplified diagram illustrating the use of AnswerFast2 according to another embodiment of the present invention.
  • FIG. 9 is a simplified diagram illustrating fallback from AnswerFast2 according to an embodiment of the present invention.
  • FIG. 10 is a diagram illustrating communication flow between two H.324 terminals using extensions of H.245 messages to reduce connection times for H.324 calls according to an embodiment of the present invention
  • FIG. 11 is a diagram illustrating communication flow between two H.324 terminals using extensions of H.245 messages and concatenation to reduce connection times for H.324 calls according to an embodiment of the present invention
  • FIG. 12 is a diagram illustrating an alternative communication flow between two H.324 terminals using extensions of H.245 messages to reduce connection times for H.324 calls according to another embodiment of the present invention
  • FIG. 13 is a diagram illustrating a method of recovering media after loss of a preference message according to an embodiment of the present invention
  • FIG. 14 is a diagram illustrating a method of recovering media after loss of a preference message according to an embodiment of the present invention.
  • FIG. 15 is a simplified flowchart illustrating a method of reducing a call setup time for a call between H.324-like terminals according to an embodiment of the present invention
  • FIG. 16 illustrates an embodiment of the ASN.1 Syntax description for AnswerFast3 Request
  • FIG. 17 illustrates an embodiment of some coded Profiles, and their description, that can be used in AnswerFast3 Request and Response;
  • FIG. 18 illustrates an embodiment of the ASN.1 Syntax description for AnswerFast3 Response
  • FIG. 19 illustrates an embodiment of the method of using bearer "user" information to reduce connection times for H.324 calls
  • FIG. 20 is a simplified diagram illustrating the use of AnswerFast3 in Q.931 SETUP between two H.324 terminals according to an embodiment of the present invention
  • FIG. 21 illustrates an embodiment of the AnswerFast4 speed-up technique according to the present invention
  • FIG. 22 is a simplified diagram illustrating the use of AnswerFast4 according to an embodiment of the present invention.
  • FIG. 23 is a simplified diagram illustrating the use of AnswerFast4 according to another embodiment of the present invention.
  • FIG. 24 is a simplified illustration of the structure of an AnswerFast4 frame according to an embodiment of the present invention.
  • FIG. 25 is a simplified diagram illustrating a method of AnswerFast4 according to an embodiment of the present invention with media transmitted in AnswerFast4 frames;
  • FIG. 26 illustrates the structure of the FSS frames according to an embodiment of the present invention.
  • FIG. 27 illustrates the structure of the FSS Frame Information field according to an embodiment of the present invention
  • FIG. 28 illustrates the structure of the FSS Synchronization Flag according to an embodiment of the present invention
  • FIG. 29 illustrates the structure of the Predefined Profile Index according to an embodiment of the present invention
  • FIG. 30 illustrates the structure of the Detailed Profile Index in the Predefined Profile Index according to an embodiment of the present invention
  • FIG. 31 illustrates communication of Request and Response messages according to an embodiment of the present invention
  • FIG. 32 illustrates an example of a conventional communication flow using mobile level detect sequences between two terminals
  • FIG. 33 illustrates an example of a communication flow using the AnswerFast4 technique to establish a connection between two terminals
  • FIG. 34 illustrates an example of a communication flow using an interleaved sequence using mobile level stuffing sequences according to an embodiment of the present invention
  • FIG. 35 illustrates an example of an alternative example of a communication flow using an interleaved sequence using mobile level stuffing sequences according to an alternative embodiment of the present invention
  • FIG. 36 illustrates an example of a further alternative example of a communication flow using an interleaved sequence with media using mobile level stuffing sequences according to an alternative embodiment of the present invention
  • FIG. 37 is a simplified diagram illustrating a fallback procedure according to an embodiment of the present invention.
  • FIG. 38 provide a listing of FSS/MOS parameters utilized in embodiments of the present invention.
  • FIG. 39 provide a listing of FSS/MOS parameters utilized in embodiments of the present invention.
  • FIG. 40 illustrates an embodiment of the method of using bearer "user" information to reduce connection times for calls between an H.324 terminal and an H.323 terminal using a gateway;
  • FIG. 41 illustrates a possible hierarchy of AnswerFast methods/techniques
  • FIG. 42 illustrates a combination of AnswerFast techniques whereby session characteristics are refined in subsequent AnswerFast or conventional techniques.
  • FIG. 43 illustrates a combination of AnswerFast4 and AnswerFast2 techniques whereby session characteristics are refined in subsequent AnswerFast2 or conventional techniques.
  • Mobile networks utilize methods and apparatus that provide for session creation between two mobile terminals or between a mobile terminal and an infrastructure node (i.e. equipment in the network that the mobile device is communicating with) to allow media (voice, video, text, and the like) to flow between the terminals and/or the nodes.
  • an infrastructure node i.e. equipment in the network that the mobile device is communicating with
  • media voice, video, text, and the like
  • networks that support the H.324M standard for mobile multi-media telephony may use a number of available session setup schemes. These methods differ in the speed of the session set-up and the flexibility and reliability offered to the terminal and the network. Flexibility refers to the ability of service providers to provide the media in a differentiated way without having to define these new formats as part of the default formats supported by the network. Reliability refers to the confidence in successfully establishing a session.
  • Some session setup methods can be considered lossless in that acknowledgments are mandatory on the communicating devices, while others can be considered highly reliable because of the repetition of messages and other
  • initial messages are sent by both terminals and/or nodes after a bearer channel has been established.
  • the bearer channel is the channel established by the network that carries information between the terminals and/or the nodes.
  • these messages may be referred to as "bullets.”
  • these messages carry a small amount of information that express some of the capabilities and preferences (as in which media types the device prefers to use) of each of the communicating devices (whether they be terminals or nodes).
  • the communicating devices use a common decision making algorithm to determine which session setup mechanism is used. Once the session setup is complete, media flows between the communicating devices until the session is closed.
  • the "bullets” carry the information referred to above. Using this information, a decision is made on whether the fastest session setup method (referred to as FM in the figure) should be used (which in turn has lower flexibility than the other methods). If the decision is made to use the fastest session setup method, then the session is created in that manner. If session creation fails, then a common, reliable method (and most time consuming method, referred to as H.245 in the figure) is used to set-up the session. More flexibility can be added to the session set-up by the optional adoption of a more flexible session set-up method (for example in FIG. 1, fast session setup is included as an example) which allows the communicating devices to share more information and thus consumes more time while allowing additional flexibility to the way media is communicated between the communicating devices.
  • FM fastest session setup method
  • H.245 most time consuming method
  • ACN typically involves the transmission of more information and the acknowledgement of more of that information than the faster session set-up schemes.
  • the most reliable session set-up scheme will be used. In this way, a number of session setup schemes can be used in the same communication device to allow the advantages of the various schemes to be realized in different situations.
  • Embodiments of the present invention allows the different session setup schemes or protocols to operate in the same device with a meaningful result. Moreover, embodiments provide for scalable session setup creation, where speed is traded with flexibility and reliability. A further advantage of embodiments of the present invention is that methods and systems provided herein allow a subset of the available session set-up schemes to be used in any one device and still operate reliably with devices that implement a smaller or larger subset.
  • Mobile networks utilize methods and apparatus that provide for session creation between two mobile terminals or between a mobile terminal and an infrastructure node (i.e. equipment in the network that the mobile device is communicating with) to allow media (voice, video, text, and the like) to flow between the terminals and/or the nodes.
  • an infrastructure node i.e. equipment in the network that the mobile device is communicating with
  • the invention provides methods for reducing the time required to establish calls (in particular the completion of session setup and the transmission of usable media) between terminals that implement the ITU-T H.324 Recommendation and other Standards and Recommendations derived from or related to this such as the 3G-324M recommendation developed and adopted by the Third Generation Partnership Projects (3GPP and 3GPP2).
  • a method and apparatus for concatenating the H.245 messages that are required to pass between the terminals at the start of the call to establish the capabilities of both terminals and agree on the type and format of media and data to be exchanged (ii) a method and apparatus for using non-standard H.245 messages to accelerate such establishment (iii) a method and apparatus of informing each terminal of the capabilities of the other and proposing the type and format of media and data to be exchanged by means of any user-defined fields that are inserted in the call signaling protocol that is used for bearer establishment prior to the start of the H.324 stage of the call, (iv) a method and apparatus of making transmissions on the bearer channel prior to, or in parallel with, the initiation of the H.324 Standard procedures, the messages comprising media or preference information informing each terminal of the capabilities of the other and proposing the type and format of media and data to be exchanged by means of messages that are transmitted and (iv) a method and apparatus of transmitting and
  • AnswerFast these five different families of session speed-up methods are described in the present specification. Collectively, the methods are referred to herein as AnswerFast and they include the following:
  • AnswerFastSRP This method enables terminals to send multiple SRP/NSRP messages in a particular way to speed up the session set up time.
  • AnswerFast 1 This method enables terminals to group H.245 messages in a particular way to speed up the session set up time.
  • AnswerFast2 This method makes use of fields in the H.245 TerminalCapabilitySet request message.
  • AnswerFast3 This method makes use of the signaling layer (TS 24.008) to incorporate one or more preferred operation modes.
  • AnswerFast4 This method transmits messages including media and preferred operation mode as the first burst of bits transmitted on the bearer channel. These bits are prevented from emulating existing mobile level flags, including the baseline H.324 mode, so they are ignored by existing terminals, maintaining interoperability.
  • one hierarchical order of utilizing the AnswerFast techniques in H.324 is:
  • AnswerFast2 (optionally with AnswerFast 1 and/or AnswerFastSRP) 4. AnswerFastl (optionally with AnswerFastSRP)
  • AnswerFastl may be adopted after successful utilization of AnswerFast3 and AnswerFast4. AnswerFastl may be adopted at the same time as AnswerFast2.
  • AnswerFastSRP may be adopted in conjunction with AnswerFast 1 and AnswerFast2 and may also be used in conjunction only with an otherwise normal session setup. It is also feasible some subpart of negotiations may be conducted in an AnswerFast negotiation in an earlier phase of the call and a later negotiation could build on that earlier negotiation or refine (or even redefine) it, or avoid an aspect that might be conflicting. For example AnswerFast2 negotiations might use some outcomes of an AnswerFast3 or AnswerFast4 negotiation to continue a call.
  • the AnswerFast2 phase may use a mobile/multiplexer level negotiated in an earlier stage, or may choose to use or choose to avoid using some particular logical channel numbers or multiplexer table entry numbers.
  • a feature may be redefined or re-determined in a later phase, for example a master-slave relationship may have been used to avoid conflicts in AnswerFast4 media flows, but then the session may re-determine the relationship using an H.245 based MasterSlaveDetermination message.
  • a master-slave relationship may have been used to avoid conflicts in AnswerFast4 media flows, but then the session may re-determine the relationship using an H.245 based MasterSlaveDetermination message.
  • the invention has been applied to the establishment of multimedia telecommunication between 3G-324M (H.324M based protocol) multimedia handsets on a mobile telecommunications network, and between 3G-324M multimedia handsets and H.323 based terminals on a packet network using a multimedia gateway to mediate between the protocols used at each endpoint, but it would be recognized that the invention may also include other applications.
  • 3G-324M H.324M based protocol
  • multimedia gateway to mediate between the protocols used at each endpoint
  • Equipment Preference signaling can be done using a combination of information access and communication methods using call signaling protocols (e.g. ISUP, Q.931, SIP, BICC), bearer based methods (circuit switched or packet switched), on-line stored information and off-line stored information.
  • call signaling protocols e.g. ISUP, Q.931, SIP, BICC
  • bearer based methods circuit switched or packet switched
  • H.324 SRP There is scope to optimize H.324 SRP to support faster call setup, call tear- down and other session messaging (H.245 Messaging), in environments where network latency is significant.
  • H.324/H.245 One of the features of H.324/H.245 is the use of SRP, which provides acknowledgement for all delivered PDUs. This is useful to ensure that all command and control messages have been received at the far end terminal, but provides a limit to the throughput of messages on networks with moderate to high latency (>40 ms round trip time).
  • SRP only allows for one message to be outstanding (without acknowledgement) at any time to ensure guaranteed delivery and correct message sequencing. This latency can be mitigated to some extent by minimizing the number of messages exchanged during call setup such as a message containing multiple Multiplex Table Entries, or combining Terminal Capability Set and Master Slave determination messages, however it does still adversely impact the can setup time.
  • timeouts are such within H.324/H.245 that if a critical packet (or its acknowledgement) is lost during call setup (perhaps due to data loss) the call may fail, and abort if timer values within stack implementations are not tuned appropriately. All of these phases are necessary to remain standards compliant, but it may be the case that in some circumstances SRP may be used in such a way to allow messages to be sent while an SRP ACK is outstanding.
  • H.324/H.245 procedures are artificially held back due to the behavior of H.245/SRP.
  • Essentially independent procedures such as the opening of different logical channels are unnecessarily coupled by the requirement that only one H.245 SDU may be outstanding at any time. By removing this limitation for independent procedures the time to execute H.245 procedures could be reduced by between 50 100%.
  • Some SDUs must be preserved in strict order, for example with all procedures, or within a single instance of an Open Logical Channel procedure, however independent OLC requests do not need to be coupled as they are in the current standard.
  • NRSRP Numbered SRPs
  • a terminal combines H.245 Request Terminal Capabilities (TCS) and Request Master Slave Determination (MSD) messages into a single H.245 PDU. It also concatenates TCS and MSD Response Messages (Acks), multiple Open Logical Channel Requests (OLC) and Multiplex Table Entry Send Request (MES) in a single H.245 PDU. Finally it combines OLC and MES responses into a third H.245 PDU.
  • TCS Request Terminal Capabilities
  • MSD Request Master Slave Determination
  • This embodiment requires that the MSDSE and CESE state machines can run in parallel, and that the multiple LCSE and MTSE state machines can run in parallel.
  • This embodiment is merely one example of the application of the method of concatenated H.245 messages in the present invention; other concatenations of messages can be constructed; these may put different constraints on the signaling entity state machines within the implementation of H.245.
  • the method also includes reverting to a normal operation if one of the terminals does not support AnswerFastl (i.e., concatenated H.245 messages).
  • the calling terminal in this case detects that because it would not have received the H.245 response to the second of the concatenated H.245 messages.
  • the calling terminal would revert to individual H.245 messages in the SRP command frames and retransmit the H.245 messages individually from the second message onwards.
  • the method can also be applied to the Numbered Simple Retransmission Protocol (numbered version of SRP which includes a sequence number in the SRP command and SRP acknowledgement frames) and other like variations, such as WNSRP.
  • SRP Numbered Simple Retransmission Protocol
  • WNSRP Wideband Network Packet Control Protocol
  • AnswerFastl provides a mechanism whereby terminals combine multiple
  • H.245 messages in order to reduce the session set up time.
  • the usage of H.245 within H.324 allows terminals to concatenate multiple H.245 messages into a single PDU, thus avoiding the need to use two round trips for each request/response pair (due to the need for an SRP response for each PDU).
  • H.324 terminals do not take advantage of this capability, other H.324 terminals will incorporate these techniques.
  • AnswerFastl techniques reduce the number of round trips required for call set up from ten to three.
  • a terminal can send a MasterSlaveDetermination Request and TerminalCapabilitySet Request messages in a single PDU, or can send TerminalCapabilitySetAck, MasterSlaveDeterminationAck, Open Logical Channel Requests and MultiplexEntrySend Request messages in a single PDU.
  • AnswerFastl takes advantage of the existing protocol facilities, rather than as an extension to it.
  • a terminal that implements AnswerFastl does not need to define any behavior or protocol elements in addition to those already allowed and defined by the H.245 and H.324 standards.
  • FIG. 4 is a simplified diagram illustrating the use of AnswerFastl according to an embodiment of the present invention.
  • the media may be unidirectional or bidirectional.
  • H.245 message are concatenated in the AnswerFastl technique. Interoperability with terminals that do not implement AnswerFastl is achieved by noting that if the receiving terminal ignores the second and subsequent H.245 elements in a PDU, the transmitting terminal can detect any timeouts and continues the H.245 messaging using one H.245 message per PDU.
  • H.245 message grouping for H.324, also referred to as concatenation.
  • H.245 message grouping is compatible with the H.324 recommendation as defined in clause A. 1 of H.324.
  • the number of SRP Acks may be reduced for a call session, thus shortening the call setup time.
  • the use of concatenation is not required by embodiments of the present invention, which may result in increased call setup times.
  • H.245 message grouping makes techniques and systems available to implementers that avoid unnecessary long call setup times, which delays message exchange. For purposes of consistency between H.324 and H.245, the terms "MultimediaSystemControlPDU messages" and
  • MultimediaSystemControlMessage's are utilized interchangeably. Accordingly, the use of these terms is not intended to limit the present invention, but merely to provide alternative phrases.
  • bits produced by the X.691 encoding process shall be put into the octets of an information field, with the first bit generated going into the Most Significant Bit (MSB) of the first octet, and progressing down to the Least Significant Bit (LSB) of the last octet.
  • MSB Most Significant Bit
  • LSB Least Significant Bit
  • MuItimediaSystemControlPDU messages may be sent in each information field, to be transported in a single SRP or LAPM frame. It should be noted that the specified X.691 encoding process produces MuItimediaSystemControlPDU messages which are each a multiple of 8 bits in length (10.1.3/X.691), so all messages begin on an octet boundary. It is recommended that as many available complete H.245 Mu ltimediaSystemControlMessages as possible should be sent in an information field of a single SRP or LAPM frame.
  • One message sending sequence during initial H.245 message exchange is:
  • H.324 terminals capable of using LAPMN.42 as the control channel link layer can indicate this capability by setting the transportWithl-frames parameter of the H223Capability structure true.
  • Such terminals upon receiving the corresponding indication from the far-end terminal, shall henceforth, and without further notification of intent, proceed to establish an error-corrected connection according to the procedures given in 6.8.1.2/H.324 and subsequently transmit control channel messages only using LAPMN.42 for the duration of the connection.
  • the terminal transmits an SRP response message in reply to any SRP command message received.
  • AnswerFast2 Exemplary Embodiment In a particular embodiment of the method of using custom H.245 messages, a non-standard Capability is used.
  • An H.324-like equipment requires that the first H.245 message it sends is a Terminal Capability Set (TCS) message.
  • TCS Terminal Capability Set
  • the calling equipment includes a capability of type NonStandardParameter in the TCS it sends to the answering equipment. This capability is identified by a NonStandardldentifier with a unique Object Identifier.
  • This capability contains Equipment Preferences which are the additional parameters needed by the called terminal to start the call, including terminalType (needed for MSD in the same manner as it is required for standard H.245 operation) and Multiple Table Entry (MTE) Descriptors.
  • FIG. 5 shows an example of an ASN.1 description containing the syntax for all of these data.
  • the calling party is required to accept the decision of the called party as to whether this method is used, and what channels are selected. If the called equipment does not support this method the calling equipment receives a conventional TCSAck and normal H.245 negotiation is then used to continue the session setup.
  • a called terminal receives a TCS containing the NonStandard capability relating to this method and itself supports the method, it will perform a master slave determination by comparing the terminalType value in the received NonStandard capability with the value for the local terminal. The highest value will be selected as the master. In the event of equal terminal type values, the calling terminal will be selected as the master.
  • the called terminal will analyze the received capability table and capability descriptors to determine the OpenLogicalChannel and multiplex table entries for the new connection.
  • the called terminal will respond with a normal TCSAck if it cannot derive an acceptable channel configuration, or if it is unable to accept the multiplexEntryDescriptors provided.
  • the remainder of the call setup will then be via normal H.245 negotiation.
  • NonStandard ResponseMessage of the type NonStandardMessage. See FIG. 6 for an ASN.1 Syntax description of the encoded data.
  • the NonStandardldentifier of the non-standard response message will have the same Object Identifier as the NonStandard capability which identifies this method.
  • the called terminal does not include any additional or NonStandard capabilities into the TCS it sends to the calling terminal, even if it supports this method. The calling terminal must wait to receive either a TCSAck or the NonStandardMessage before proceeding.
  • FIG. 7 The process of setting up an H.324 call between two terminals which support this embodiment of the method of using custom H.245 messages is illustrated in FIG. 7.
  • This embodiment offers one and a half less round trip exchanges than the embodiment of the method of Concatenated H.245.
  • the methods and systems provided herein ensure that the called terminal will not malfunction or hang-up since it is able to handle the case of a non-standard Capability being communicated to it.
  • the second key aspect is that the encapsulation of the custom message in the TerminalCapabilitySet request message allows the terminal to transmit the custom message in the first H.245 message after the mobile level determination is done, and hence it does not have to wait.
  • the third aspect is that the TerminalCapabilitySet request containing the AnswerFast2 message embedded as a non-standard Capability can be transmitted using the AnswerFastl mode (together with one or more H.245 messages).
  • the fourth aspect is that the called terminal responds with an Ack message that informs the calling terminal of the preferred modes of the called terminal and its selection of one of the preferred modes of the calling terminal if the calling terminal presented several preferences in its AnswerFast2 message.
  • the AnswerFast2 method uses the H.245 protocol to transmit "special" messages that are aimed at shortening the procedure to establish a session.
  • the concept is to transmit special messages as soon as possible, and this can be done in various ways. Which way is selected depends on how stringent one wants to be with regards to departure from conventional H.324 session establishment.
  • the H.324 protocol mandates that the first H.245 message be the TerminalCapabilitySet (TCS) Request message. Hence one can insert the special messages in the TCS.
  • TCS TerminalCapabilitySet
  • Embodiments of the present invention cover the concept of transmitting special message(s) for the purpose of speeding up the session establishment, regardless of the actual position and order of the message, which will depend on the particular embodiment.
  • non-standard As the conventional H.324 protocol does not provide for them, or provides for them in a generic way, and they are not yet standardized.
  • the non-standard message(s) can be inserted as a "non-standard” Capability of the TerminalCapabilitySet request message, and this is the approach that we will describe, without loss of generality, to illustrate the mechanics of the operations.
  • the "non-standard” Capability allows H.324-like terminals to define a mode of operation that enables faster session set up.
  • AnswerFast2 enables the minimization of the amount of information that is incorporated in the non-standard Capability.
  • AnswerFast2 reduce the amount of transmitted information, for example, to a minimum amount.
  • non-standard Capabilities as Non-Standard Capabilities or Non-Standard H.245 Capabilities.
  • FIG. 7 is a simplified diagram illustrating the use of AnswerFast2 according to an embodiment of the present invention.
  • a H.245 NonStandard Capability is used between two H.324 terminals that support AnswerFast2.
  • the message flow between the two H.324 terminals supporting AnswerFast2 in H.245 NonStandard Capability is illustrated.
  • the media may be a unidirectional or bidirectional channel. Using a minimal amount of information to signal a capability through the use of bit fields and/or use of profiles minimizes the amount of information required to be transmitted. This in turn leads to minimized call set up time, even in the reduced call set up time case.
  • the profiles can be the same as described for either AnswerFast3 or AnswerFast4, or any variants listed. It is also possible, with minimum additional information, or special use and interpretation of an otherwise unused field, to indicate the use of a system of predefined rules based on already available information.
  • An example could be a capability indication and the use of rules to select from the conventional capabilities as to which channels would be opened in an accelerated fashion. This could be performed completely by inference, or could also be explicitly acknowledged.
  • An acknowledgment may also contain extra session information, such as further information used to open a channel.
  • the calling terminal includes a capability of type NonStandardParameter in the TerminalCapabilitySet it sends to the called party terminal (a possible format for this capability is described more fully below).
  • This capability contains additional information needed by the called terminal to start the session, possibly including indications of multiplexer table entries, or entry numbers and logical channels characteristics, or logical channel numbers to use.
  • the calling party is enabled to accept the decision of the called party as to whether AnswerFast2 is used, and what channels are selected.
  • the called terminal may respond with a NonStandardMessage containing the further information needed for the calling terminal to start the session (a possible format for this capability is described more fully below).
  • the called terminal does not include any additional capabilities into the TerminalCapabilitySet it sends to the called terminal.
  • other H.245 messages such as a MasterSlaveDetermination request message, may be concatenated with the TerminalCapabilitySet in case the fallback procedure as described herein is used.
  • FIG. 8 is a simplified diagram illustrating the use of AnswerFast2 according to another embodiment of the present invention. As shown in FIG. 8, a H.245 NonStandard Capability is used between two H.324 terminals that support AnswerFast2. The message flow between the two H.324 terminals supporting
  • AnswerFast2 in H.245 NonStandard Capability is illustrated.
  • inference or a preference rule set is used at each terminal and the optional response message is not required to be sent before media transmission may begin.
  • the media may be a unidirectional or bidirectional channel.
  • the AnswerFast2 Request Capability is provided as follows.
  • a calling terminal requests AnswerFast2 by including a capability of type NonStandardParameter into the outgoing TerminalCapabilitySet. This capability is identified by a NonStandardldentifier with an object ID to be determined.
  • the version field indicates the version of the AnswerFast2 extension.
  • the afkey field is a unique identifier to identify it is an AnswerFast2 non-standard parameter and is defined as 71 123521.
  • the terminalType field is encoded with the same value as would be used in the terminalType field of an outgoing H.245 MasterSlaveDetermination Request from the calling party.
  • the multiplexEntryDescriptors are settings as would be used in an outgoing MultiplexEntrySend Request.
  • the NonStandardldentifier is defined as " ⁇ iso ( 1 ) member-body ( 2 ) au ( 36 ) acn ( 71123521 ) vendor specif ic 1 ( 1 ) vendor specif ic 2 ( 1 ) ⁇ ", which represents AnswerFast2.
  • a calling terminal be able to open logical channels for all transmitAudioCapability, receiveAudioCapability (treated also as having the ability to transmit audio), receiveAndTransmitAudioCapability, transmitVideoCapability receive VideoCapability (treated also as having the ability to transmit audio), and receiveAndTransmitVideoCapability entries that are advertised in the outgoing TerminalCapabilitySet, as the receiving terminal will interpret each capability as a proposed OpenLogicalChannel request.
  • Each indicated capability may be interpreted by the receiver as a proposition to open a logical channel matching the capability.
  • Other rules such as a preference order for acceptance, or a limitation based on media type could be applied to determine properties of a channel to be opened.
  • a media type limitation could take the form of limiting accelerated session set up to only a single audio, single video or single data channel.
  • the calling terminal sets its multiplex table to be exactly as the calling terminal specifies for its transmitted channels.
  • a terminal may determine its multiplex table entries using some method, predefined, predetermined or explicit. In cases wherein the called terminal sets its multiplex table entries to be exactly as the calling terminal uses, the receiver is allowed to properly accept and process data that is received.
  • the AnswerFast2 capability is contained in a CapabilityDescriptor within the capability table that is distinct from the audio, video, and user indication capabilities. This ensures that terminals that do not support AnswerFast2 will ignore the additional entry. Endpoints that support AnswerFast2 generally provide multiple capabilities in the same CapabilityDescriptor as the AnswerFast2 capability. This allows for future enhancement of the AnswerFast2 procedure using new NonStandardldentifier values.
  • an AnswerFast2 Request Response may be provided as follows. If a called terminal receives a TerminalCapabilitySet containing an AnswerFast2 capability, it will perform a master slave determination by comparing the terminal type value in the received AnswerFast2 request with the value for the local terminal. The highest value will be selected as the master. In the event of equal terminal type values, the calling terminal will be selected as the master. Alternatively if the MasterSlaveDetermination Request is transmitted with the TerminalCapabilitySet it may instead be used for Master Slave determination.
  • the called terminal will analyze the received capability table to determine the proposed OpenLogicalChannel and multiplex table entries for the new connection.
  • the called terminal may respond with a normal TerminalCapabilitySetAck if it cannot derive an acceptable channel configuration, or if it is unable to accept the multiplexEntryDescriptors provided. This will also occur if the called terminal does not support AnswerFast2.
  • the called party may replace the normal TerminalCapabilitySetAck with a
  • NonStandardParameter a PER encoded structure with the following ASN definition:
  • the sequenceNumber field corresponds to the sequence number value of the TerminalCapabilitySetAck that is being replaced by this response. This allows the calling terminal to maintain H.245 message synchronization.
  • the decision field indicates the master/slave status of the called terminal, i.e. the calling terminal sets its master/slave status to the opposite of the value indicated in this field.
  • the multiplexTableEntryNumber field contains a list of all multiplex table entries that were accepted by the called terminal. In general, there is an implied symmetry for multiplex table entries. The called terminal sets its multiplex table to be exactly as the caller terminal specifies for its transmitted channels.
  • the logicalChannels field contains a list of all channels that both terminals will transmit. Channels transmitted from the calling party are indicated by a dataType field of value nullData in the forwardLogicalChannelP ammeters element in combination with an optional reverseLogicalChannelParameters containing the channel information. [0137] Fallback from AnswerFast2
  • fallback techniques are provided for terminals that do not support one or more of the AnswerFast techniques described herein. For example, for fallback from AnswerFast2, if the called terminal does not support AnswerFast2, or if it rejects the proposed AnswerFast2 parameters, the called terminal receives a conventional TerminalCapabilitySetAck and normal H.245 negotiation are used to continue the call.
  • FIG. 9 is a simplified diagram illustrating fallback from AnswerFast2 according to an embodiment of the present invention.
  • the calling terminal attempts a call with AnswerFast2 in H.245 NonStandard Capability to a terminal that does not support AnswerFast2.
  • an MSD is transmitted and H.245 negotiations are continued according to AnswerFast 1, AnswerFastSRP or conventional negotiations.
  • other fallback mechanisms are possible.
  • the invention has been applied to performing a fast session setup procedure over the H.245 control-channel utilizing an inference algorithm, but it would be recognized that the invention may also include other applications.
  • the methods described herein are generic and can be implemented in many different ways by a person skilled in the art. We describe herein exemplary embodiments to illustrate the methods which can be adapted easily to suit specific equipment needs.
  • FIG. 10 is a diagram illustrating communication flow between two H.324 terminals using extensions of H.245 messages to reduce connection times for H.324 calls according to an embodiment of the present invention.
  • a method is provided in which call setup times are reduced (i.e., the number of sequential steps used to establish an H.324-like call are reduced) by using the non-standard or generic messaging capabilities of the H.245 protocol during the call setup process.
  • the use of the non-standard or generic messaging capabilities are referred to as "AF2" in or with the TCS message in the figures.
  • a terminal includes a capability in the genericlnformation field in the TerminalCapabilitySet.
  • information related to a capability of a terminal is included in the genericlnformation field in the TerminalCapabilitySet message.
  • the capability used in a particular embodiment is the FSS request message ⁇ itu-t(O) recommendation(O) h(8) 324 generic-capabilities(l) fastSessionSetup(O) explicit profile (2), with this OID in genericlnformation.messageldentifier field ⁇ .
  • the mobileLevel field is not used, and it is determined at an earlier stage negotiation, either through pre-arranged/predefined selection, or as a result of an earlier negotiation such as an AnswerFast3 or an AnswerFast3 negotiation.
  • These messages can be used to signal that the calling equipment is capable of operating in a particular way, and to provide proposals and preferences to the remote terminal relating to Master Slave Determination, Logical Channel(s) to be opened and Multiplexer Table Entries embedded within these non-standard extensions to accelerate call setup. If the remote terminal supports this method, it may signal the calling terminal using a non-standard extension which will also indicate that it accepts, and may also propose modifications or provide other information, including for example the Multiplexer Table Entries that it is using.
  • the terminal will simply ignore the non-standard extension and not respond with the non-standard response, but a standard response (e.g., a conventional TCSAck).
  • a standard response e.g., a conventional TCSAck
  • the call will then proceed as for a standard H.324-like call, utilizing normal H.245 negotiation to continue the call setup.
  • an MLD sequence is performed between the two terminals Entity A (Caller) and Entity B (Callee).
  • Entity A Caller
  • Entity B Entity B
  • a call signaling message is transmitted from the first terminal to the second terminal through the telecommunication network.
  • the call signaling message is used to initiate a call.
  • a bearer channel is established between the first terminal and the second terminal once the call signaling message has been received by the second terminal. Then a common mobile level for operation is determined.
  • One or more custom Non-Standard H.245 messages or custom Non-Standard fields are provided in standard messages as illustrated after the conventional MLD process shown in FIG. 10.
  • the one or more custom Non-Standard H.245 messages, custom Non-Standard fields in standard messages, or messages in generic fields are illustrated as "AF2 in TCS," that is, messaging in the terminal capability set (TCS) field.
  • a non-standard Capability is used.
  • the first H.245 message sent is a Terminal Capability Set (TCS) message.
  • TCS Terminal Capability Set
  • the calling equipment includes a capability of type NonStandardParameter in the TCS it sends to the answering equipment. This capability is identified by a NonStandardldentifier with a unique Object Identifier. This capability contains the additional parameters needed by the called terminal to start the call, including terminalType (needed for MSD in the same manner as it is required for standard H.245 operation) and Multiple Table Entry (MTE) Descriptors.
  • FIG. 5 shows an example of an ASN.1 description containing the syntax for these data.
  • the calling party is enabled to accept the decision of the called party as to whether this method is used, and what channels are selected.
  • the response message is not required to determine what channels are selected.
  • a determination of the inferred common mode (ICM) follows the rules defined in FSS using only the information available in the first H.245 message group, the TCS and/or the MSD and any custom messages contained therein.
  • the codecs are selected in the same way as normal H.245 message exchange, except all transactions are conducted implicitly till the final outcome, this outcome forms the inferred common mode.
  • the following discussion provides examples of inference algorithms and is provided merely by way of example. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • Adaptation layer settings are specified by the local terminal in OpenLogicalChannel messages. For each media, adaptation layer 3 (AL3) is commonly supported. If only AL3 is specified for a media in the mediaProfiles of a terminal, only AL3 is supported. If AL2 is included, both AL2 and AL3 are supported. If ALl is included, all ALl , AL2 and AL3 are supported.
  • AL3 adaptation layer 3
  • Initial logical channel number selections are made by the local terminal. If a reverse channel number conflicts with a receive channel number opened by the remote, the receive channel number will use the next available logical channel number. The processing of channels should be from the first entry of the mediaProfiles. Conflicts that can occur during determination of ICM and logical channel number can be resolved implicitly as described above.
  • media are represented by a list OpenLogicalChannel.
  • Media preferences may be indicated by specifying more than one OpenLogicalChannel, with the same logical channel number in the desired logical channel preference order. If more than one logical channel of the same type is expected to be opened, different OpenLogicalChannel message of the same media type but different logical channel numbers are specified.
  • Further symmetric codecs are indicated by specifying a separate OpenLogicalChannel with reverse logical channel parameter only, which is the same as the expected symmetric media type.
  • Terminal capability sets for both terminals are inferred from the combination of mediaProfiles from local and remote.
  • Multiple OpenLogicalChannel entries with the same LCN correspond to a series of alternative capability descriptor entry; OpenLogicalChannels with different LCNs correspond to simultaneous capability descriptor entries.
  • the capability direction is set to receive capability (e.g. receiveVideoCapability, receiveAudioCapability) unless symmetric is set, where the capability direction is set to receive and transmit capability (e.g. receiveAndTransmitVideoCapability, receiveAndTransmitAudioCapability).
  • the set of capability descriptors is derived with the same order of preference as the order in mediaProfile, and includes by default an instance of each logical channel type.
  • the remote terminal is assumed to support all adaptation layers (ALl, AL2 and AL3) for all media categories (audio, video and data).
  • Other settings in the TerminalCapabilitySet adopt the corresponding recommended values specified in 3GPP TR 26.1 10, H.324, H.245 and H.223.
  • Codecs are selected in the same way as normal H.245 message exchanges, deduced according to capability preferences and media mode conflict resolution as in B.2.2.2/H.324 and C.4.1.3/H.324. Channels are considered open following the computation of the inferred mode.
  • the peer's channel is selected by reversing the TCS inputs to the selection algorithm.
  • the following behavior is described as a method to minimize the chance of endpoints attempting to open conflicting logical channels when the slave endpoint has symmetric capability limitations.
  • the slave should attempt to open a logical channel for the master's most preferred capability for which it has capability, as given by the order the master has expressed its capabilities; and the master should attempt to open a logical channel for its most preferred capability for which the slave has capability, as given by the order it has expressed its capabilities.
  • a terminal may do so by giving CapabilityDescriptors that relate to its preferred mode or modes small values of capabilityDescriptorNumber.
  • each entity selects media channels most preferred for reception by its peer entity. Both entities prefer AMR. Entity A prefers to receive MPEG4-Video while entity B prefers to receive H.263.
  • each entity selects media channels most preferred for reception by its peer entity. Both entities prefer AMR. Entity A prefers to receive MPEG4- Video while entity B uses MPEG4- Video in symmetry to the master.
  • Embodiments of the present invention utilize an ICM procedure.
  • the ICM is the unique media mode determined by both terminals based on local profile request and peer profile request.
  • the ICM is the same for both terminals.
  • a called terminal receives a TCS containing the
  • NonStandard capability relating to this method and itself supports the method, it will perform a master slave determination by comparing the terminalType value in the received NonStandard capability with the value for the local terminal. The highest value will be selected as the master. In the event of equal terminal type values, the calling terminal will be selected as the master.
  • the called terminal will analyze the received capability table to determine the OpenLogicalChannel and multiplex table entries for the new connection.
  • the called terminal will respond with a normal TCSAck if it cannot derive an acceptable channel configuration, or if it is unable to accept the multiplexEntryDescriptors provided. The remainder of the call setup will then be via normal H.245 negotiation.
  • the called party may replace the normal TCSAck with an H.245 ResponseMessage of the type NonStandardMessage. See FIG. 6 for an ASN.1 Syntax description of the encoded data.
  • the NonStandardldentifier of the non-standard response message will have the same Object Identifier as the NonStandard capability which identifies this method.
  • H.245 OpenLogicalChannel procedures do not need to be completed to establish the media stream, however depending on the levels of predefined additional information they may be used to transfer additional information.
  • FIG. 1 in which media transmission is delayed until after OpenLogicalChannel, embodiments of the present invention reduce call setup times and thereby transmit media with less delay after bearer establishment.
  • the one or more custom H.245 messages or custom non-standard fields are associated with one or more set up parameters for a mode of operation for the call.
  • the mode of operation includes an initial mode of operation.
  • the mode of operation includes a predetermined mode of operation.
  • the one or more custom Non-Standard H.245 messages or custom Non- Standard fields in standard messages are transmitted from the first terminal to the second terminal.
  • a custom Non-Standard response message associated with the one or more custom Non-Standard H.245 messages or custom Non- Standard fields may be transmitted from the second terminal to the first terminal.
  • Computer-readable medium are utilized herein to provide the functionality enabled by embodiments of the present invention. Generally, the computer-readable medium include instructions utilized in practicing the methods described herein. [0172] Embodiments of the present invention are not limited to implementations solely employing the use of Non-Standard messaging, but may include fast session setup techniques as described throughout the present specification. As discussed below, other embodiments incorporate concatenation techniques to reduce call setup times. In these other embodiments, other H.245 messages, such as the
  • MSD MasterSlaveDetermination
  • this may include ignoring the outcome of mobile level.
  • a terminal After a terminal has received its peer's TCS, decoded it successfully, and determined an ICM, further H.245 message exchange for session setup may be skipped and opened logical channels operate immediately. A response message or confirmation message could also be sent.
  • Embodiments of the present invention utilizing Non-Standard messaging offer a number of benefits including one and a half less round trip exchanges than the embodiment of the method of Concatenated H.245.
  • the expression of Capability in the NonStandard field of the TerminalCapabilitySet request message provides that the called terminal will not malfunction or hang-up as it is required to be able to handle the case of a non-standard Capability being communicated to it.
  • TerminalCapabilitySet request message allows the terminal to transmit the custom message in the first H.245 message after the mobile level determination is done, and hence it does not have to wait for any further messages, or acknowledgements, or underlying SRP acknowledgements, before it may transmit media.
  • TerminalCapabilitySet request containing the Non-Standard message embedded as a non-standard Capability can be transmitted together with one or more H.245 messages using concatenation allowing for additional information to be sent for common mode inference, or for establishing sessions more quickly with terminals employing AnswerFastl techniques.
  • the called terminal responds with an acknowledgement message that informs the calling terminal of the preferred modes of the called terminal and its selection of one of the preferred modes of the calling terminal.
  • FIG. 1 1 is a diagram illustrating communication flow between two H.324 terminals using extensions of H.245 messages and concatenation to reduce connection times for H.324 calls according to an embodiment of the present invention.
  • call setup times are reduced by concatenating multiple H.245 messages in one or more SRP/NSRP (H.245 PDU) Command Frames.
  • SRP/NSRP H.245 PDU
  • the H.245 messages are concatenated in a way as not to violate inter- procedure dependencies.
  • H.245 within H.324 allows equipment to concatenate multiple H.245 elements into a single PDU, thus avoiding the need to use two round trips for each request/response pair due to the need for an SRP/NSRP response to be received for each H.245 PDU before the next PDU is allowed be transmitted.
  • Embodiments of the present invention use concatenated H.245 to send multiple H.245 messages, each originating from different Signaling Entities that have no dependencies on each other, within a single H.245 PDU.
  • the first concatenated H.245 PDU sent contains at least two Request messages, where the first message is a Request. If only the Ack for the first message is received, the sending equipment will retransmit those Requests and any other messages that have not been acknowledged, and in doing this and in sending any and all subsequent H.245 messages should revert to sending only a single H.245 message in each subsequent H.245 PDU.
  • a method provided herein includes transmitting a call signaling message from a first terminal to a second terminal through a telecommunication network to initiate a call, establishing a bearer channel between the first terminal and the second terminal once the call signaling message has been received by the second terminal, and determining a common mobile level. Additionally, the method includes determining two or more H.245 messages associated with set up parameters for an initial mode of operation, concatenating the two or more H.245 messages into one SRP command frame according to a predetermined size of the SRP command frame, and transmitting the SRP command frame including the two or more H.245 messages from the first terminal to the second terminal through a telecommunication network. As illustrated in FIG.
  • an AnswerFast2 message in the TCS field is concatenated with an MSD message.
  • other H.245 messages are concatenated and the example illustrated in FIG. 1 1 is provided merely by way of example.
  • One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • a terminal In a particular embodiment of this method of concatenated H.245 messages, a terminal combines H.245 Request Terminal Capabilities (TCS) and Request Master Slave Determination (MSD) messages into a single H.245 PDU. It also concatenates TCS and MSD Response Messages (Acks), multiple Open Logical Channel Requests (OLC) and Multiplex Table Entry Send Request (MES) in a single H.245 PDU.
  • TCS Request Terminal Capabilities
  • MSD Request Master Slave Determination
  • the method also includes reverting to a normal operation if one of the terminals does not support concatenated H.245 messages.
  • the calling terminal detects the lack of support since the calling terminal does not receive the H.245 response to the second of the concatenated H.245 messages.
  • the calling terminal would revert to individual H.245 messages in the SRP command frames and retransmit the H.245 messages individually from the second message onwards .
  • the method can also be applied to the Numbered Simple
  • Retransmission Protocol (numbered version of SRP which includes a sequence number in the SRP command and SRP acknowledgement frames) and other like variations.
  • SRP Sequence number in the SRP command and SRP acknowledgement frames
  • FIG. 12 illustrates an alternative communication flow between two H.324 terminals using extensions of H.245 messages to reduce connection times for H.324 calls according to another embodiment of the present invention.
  • a retransmission of the H.245 messages, and underlying SRP frame or frames can be performed.
  • the retransmission can be performed at the network link layer, for example in a modem buffer, at the SRP layer, or at the H.245 layer.
  • the lower layers are simple retransmissions not affecting the H.245 layer.
  • the H.245 layer retransmission could be redundant retransmissions without regard to the standard retransmission timer or the retransmissions could be achieved by a shortening of the standard timer associated with retransmission, T401, to much less than the round trip time.
  • FIG. 13 is a diagram illustrating a method of recovering media after loss of a preference message according to an embodiment of the present invention.
  • the preference/capability message, TCS, transmitted from the first terminal to the second terminal is lost and media arrives at the second terminal (Entity B) before the preferences, TCS, message.
  • the terminal will wait for the TCS to arrive. This sequence may occur, for example, if TCS is lost, or could also occur if a response message required for media to be able to be decoded arrives after the first media.
  • the AnswerFast2 negotiations are finalized and the terminal may use conventional procedures to recover an incoming media stream so that it can be decoded.
  • one procedure to recover media is to immediately transmit a VideoFastUpdatePicture signal allowing for clear media decoding at the arrival of the produced updated picture.
  • This procedure is illustrated in FIG. 13.
  • the likelihood of media arriving before the capability/preference message, the TCS in this example is reduced in some embodiments by using WNSRP with a short T401 timer, as previously mentioned with reference to FIG. 12.
  • the media recovery message may use a CloseLogicalChannel message with a "reopen" indication.
  • the media recovery message may use a new Custom message (H.245 or other) that causes a restart of media transmission to facilitate recovery.
  • FIG. 14 is a diagram illustrating a method of recovering media after loss of a preference message according to an embodiment of the present invention.
  • the preference/capability message, TCS, transmitted from the first terminal to the second terminal is lost and media arrives at the second terminal (Entity B) before the preferences, TCS, message.
  • Entity B the second terminal
  • the terminal will wait for the TCS to arrive and, while waiting, it will buffer all arriving media. This sequence may occur, for example, if TCS is lost, or could also occur if a response message required for media to be able to be decoded arrives after the first media.
  • the terminal may then decode the buffered media stream at faster than real time to arrive at real time decoding of the arriving media. This has the benefit of not missing any of the media at the decoder, but only displaying from the point after where the decoder can be configured correctly.
  • the buffer may also be adaptive and need only store the media after certain key points of temporal significance, such as intra coded frames.
  • the transmitter could also transmit more intra coded frames until such point that it has received an acknowledgment that indicates to it that the other end is fully configured. This may be an H.245 Ack or a lower level SRP Ack.
  • FIG. 15 is a simplified flowchart illustrating a method of reducing a call setup time for a call between H.324-like terminals according to an embodiment of the present invention.
  • the method (600) is considered from the perspective of one of the two terminals (referred to as a first terminal) communicating during a call and includes determining a multiplexer level (602) and sending a TCS message with an AF2 message (604).
  • terminal capability information and/or preferences may be provided in a Non-Standard H.245 message or a Non-Standard field in standard messages.
  • the terminal capability information and/or preferences may be provided in the GenericCapabilities field of the TCS message.
  • the terminal capability information relates to the procedures utilized to setup the call, for example, call setup with reduced setup times.
  • multiple TCS messages with an AF2 message may be transmitted. Additionally, the process of sending one or more TCS messages with an AF2 message may be repeated, resulting in a series of groups of messages.
  • One or more TCS messages with an AF2 message transmitted from the second terminal are received at the first terminal (606). Utilizing the preference information in the first TCS message (604), which relates to characteristics of the first terminal, and preference information in the second TCS message (606), which relates to characteristics of the second terminal, the media channel properties are inferred (608). Additional discussion related to methods of inferring the media channel properties are provided throughout the present specification, for example, in relation to the discussion of the determination of the ICM above.
  • a TCS acknowledgement (TCSAck) is transmitted from the first terminal to the second terminal (610) and media may be optionally transmitted (612) after the inference of the common mode of operation. Additionally, a response to the second TCS message may be transmitted from the first terminal to the second terminal (614). A TCS acknowledgement (TCSAck) is received from the second terminal (616) and in some cases, an optional response is also received from the second terminal (618). As illustrated in process 620, embodiments of the present invention provide for the transmission of media as early as process 612 and as late as process 620. Thus, the time delay between initiating a call and sending and receiving media is reduced through the use of the methods and systems described herein.
  • Session characteristics may be modified (622) and additional messages may be sent and received (624) before the call is ended (626).
  • FIG. 15 provides a particular method of reducing a call setup time for a call between H.324-like terminals according to an embodiment of the present invention.
  • Other sequences of steps may also be performed according to alternative embodiments.
  • alternative embodiments of the present invention may perform the steps outlined above in a different order.
  • the individual steps illustrated in FIG. 15 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step.
  • additional steps may be added or removed depending on the particular applications.
  • One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • Q.931 User-User Information Element is used in the SETUP and CONNECT PDUs (See. 3GPP TS 24.008 or Q.931).
  • This Information Element is filled with an ASN.1 encoded structure (See FIG.16) including terminalType (used for MSD in the same manner as it is required for standard H.245 operation) and a list of profiles the calling terminal wishes to offer.
  • terminalType used for MSD in the same manner as it is required for standard H.245 operation
  • the calling party is required to accept the decision of the called party as to whether this method is used, and what profile is selected.
  • Each profile dictates the Mobile Level, Multiplex Table Entries, Logical Channels used and codecs used for each Logical Channel.
  • FIG.17 illustrates some examples of profiles. The profile contains all the information required to immediately begin a call and establish media between the terminals without the need to go through further H.245 signaling after the bearer is set up.
  • the calling terminal receives a Q.931 CONNECT PDU without a User-User Information Element and normal call setup is then used.
  • a called terminal receives a SETUP PDU containing the User-User Information Element relating to this method and itself supports the method, it will perform a master slave determination by comparing the terminalType value in the received Information Element with the value for the local terminal. The highest value will be selected as the master. In the event of equal terminal type values, a technique such as selecting the calling terminal as the master can be used to resolve the conflict.
  • the called terminal will also select one of the offered profiles. If none of the offered profiles are suitable then no User-User Information Element should be added to the Q.931 CONNECT PDU, and the call proceeds as normal.
  • the master slave determination result and the selected profile is encoded according to the ASN.1 Syntax for the response and added to the Q.931 CONNECT PDU as a User-User Information Element.
  • FIG.18 illustrates a particular embodiment.
  • AnswerFast3 allows a H.324 calling terminal to specify a list of session profiles as part of the Q.931 SETUP PDU.
  • This technique shares some similarities with the procedures performed by H.323 FastConnect.
  • a session profile is provided that specifies values for the multiplexer as well as H.245 parameters for codecs and logical channels.
  • exact values for the all aspects of the multiplexer, H.245 parameters for the codecs to be used, and the logical channels are specified by the session profiles.
  • the terminals are enabled to exchange the parameters of the session at the time the called terminal accepts the call, rather than using mobile level detection, multiple H.245 procedures, and NSRP round trips after the call is accepted.
  • session profiles define the following information either explicitly or implicitly: • Initial Mobile Level
  • Profiles as described herein can cover several characteristics of a call or session, all characteristics of a call/session, or only a single characteristic, such as one sleeted from the list above. Additionally, profiles could be coupled with preference rules that either make them additive, mutually exclusive, or any combination thereof. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • profiles could be used for audio, video, data and multiplexer. Overarching profiles could use sub-profiles as piece parts or define each detail explicitly. Profiles may also refer to other standard's and recommendation's profiles. Profiles may indicate a "transmit only", a "receive only” or a "transmit and receive” capability. Profiles could also be used on an individual codec basis, whereby each codec has a different profile associated with it.
  • Profile modifiers can be used to modify aspects of several profiles in a more general way. For example, if the bandwidth of a link was to increase, for instance double (due to bonding or otherwise) the bandwidth associated with each channel could also increase (e.g., double). However, if the profile is hard coded, the channel would be under utilizing the resources. In this case a rule could be applied to all profiles such that all channels with variable bit rates get a proportional increase, while constant bit rates do not. The re-allocation could be proportional, or redundancy coding could be put into effect on certain channels with a resulting effective rate change. Other profile features may also be modified on bit rate, such as video frame size or frame rate. Thus, after a certain bit rate is met, the next frame size up (i.e. QCEF — > CJF) may be used, or the frame rate may be increased.
  • bit rate such as video frame size or frame rate.
  • Other profiles may be modified such that they only become active under certain other conditions.
  • An example is a CIF video profile that does not become active until a predetermined sufficient bit rate is met.
  • the predetermined sufficient bit rate is 128kbps, whereas in other embodiments, other bit rates are utilized.
  • An additional modifier may be the indication of an expectation of symmetric properties for a session.
  • One such symmetry might be the desire to have the same codec running for both transmit and receive. This may be desirable due to some limitations in some devices such as processing power or internal memory.
  • Audio profiles can specify many characteristics, with non limiting examples relating to codec, maximum bit rate and maximum number of AL-SDU (max al-sdu) frames allowed.
  • Video profiles can specify many characteristics, including, but not limited to codec, frame size, maximum bit rate, unrestricted Vectors, arithmeticCoding, advancedPrediction, pbFrames, decoderConfigurationlnformation, combinations thereof, and the like.
  • Multiplexer profiles can specify many characteristics, including, but not limited to multiplexer level and use of double flag or optional header, as well as relationships between other channels for multiplexing data/media streams.
  • Profiles may also have other predefined characteristics associated with them, such as pre-assigning logical channel number(s) to a given logical channel type or profile definition. Profiles can also define relationships between a codec or logical channel and a multiplexer table entry or multiplexer table entry number. A simple rule would be mapping logical channel number to the multiplexer table entry number, or vice versa, an example being multiplexer table entry 1 mapping to/from logical channel number 1 for an audio channel and multiplexer table entry 2 mapping to/from logical channel number 2 for a video channel.
  • Profiles could be created in the Annex to the H.324 recommendation. Creating or refining further profiles in separate documents to the H.324 Recommendation may be used to extend profiles in a way more useful to industry.
  • a separate set of profiles could be specified and recommended by H.324 and by 3GPP/3G-324M. Different profiles could be used in different releases of 3GPP/3G- 324M allowing for the reuse of profile indices/identifiers and greater control over capabilities required/expected in a device.
  • Embodiments of the present invention are not limited to presently available profiles, but include the use of future profiles as they are developed and standardized.
  • a number of audio, video, and multiplex profiles are listed in the following description. These profiles are not intended to limit the present invention, but only to provide examples of profiles utilized by various embodiments of the present invention.
  • audioProfile 256 (0x0100) G.71 1 Audio Baseline profile [TBD] [Other subsets TBD]
  • audioProfile 4096 (Ox 1000) GSM-AMR Audio
  • Video Profiles [0221] videoProfile 0 (0x0000) H.263 QCIF Video Baseline profile [TBD] [Other subsets TBD]
  • multiplexProfile 0 (0x0000) 1 ⁇ LCN AlJRC UCF ⁇
  • logical channels are pre-assigned. For example, for one or more audio channels, the logical channel numbers are 1 (Al) 5 17 (A2), 33 (A3), and the like. For one or more video channels, the logical channel numbers are 2 (Vl), 18 (V2), 34 (V3), and the like. It should be noted that AMR and MPEG4 are as defined in 3GPP and are used here merely for reference. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • the Subaddress field may be more appropriate than the User-User Information Field. If this is the case, a maximum size of space available to a session profile information may be limited to 20 octets.
  • the calling party transmits its preferred session profiles in its Set up message.
  • the called party responds with a selected or accepted session profile in one of its response (Alerting, Call proceeding, Connect) messages. If a calling terminal receives a session profile acknowledge in a response message it can proceed with using the session profile as though the TerminalCapabilitySet, MasterSlaveDetermination, MultiplexEntrySend, and OpenLogicalChannel state machines have completed and established the specified profile.
  • subsequent alterations to the session configuration can be negotiated using conventional H.245 procedures. A reason for performing such alterations is to overcome any limitations inherent in the use of profiles that do not afford full expression of capabilities available using the terminals or session characteristics that are desired.
  • the subsequent alterations could be to add or remove additional channels, or to make modifications or replacements to the channels created through the fast session set up mechanism. Additional examples of an alteration would be an adjustment to bit rate or codec capabilities expressed through a
  • TerminalCapabilitySet Furthermore, modification to decoder information, such as sending an OpenLogicalChannel with decoder information, specifically decoderConfigurationlnformation, to open a new channel, or to add a more optimal multiplexer table entry.
  • modification to decoder information such as sending an OpenLogicalChannel with decoder information, specifically decoderConfigurationlnformation, to open a new channel, or to add a more optimal multiplexer table entry.
  • An example of a session characteristic requiring alteration might be the case where a device requires symmetric codecs, but the rules used or information exchanged do not allow for this expression. In this case, a resolution could be to ignore the incorrectly asymmetric codec's data and re-open the channel based on the required symmetrical requirements.
  • Another technique useful for symmetric codecs and other session characteristic control is to delay message transmission, request, response or media until after certain characteristics of the receiving terminal are known.
  • An example is that until the remote terminal characteristics are known (e.g., codec transmission selection, capabilities, and the like) a device may withhold some of its own message transmissions, request, response or media. Accordingly, the session configuration is improved by using this technique.
  • techniques provided according to embodiments of the present invention provide session modifications that complement logical channel numbers and multiplexer table entries that are already used by the session set up process.
  • the relationship between the logical channel number or multiplexer table entry, TerminalCapability entry, or some other aspect, and the corresponding entry in the altering message could also be used to decide if an action is to be considered as an alteration/modification or an addition.
  • an Open Logical Channel for a channel already considered open through the use of fast session set up techniques may be considered an alteration of the established session.
  • An Open Logical Channel on a new channel may be considered a request to open a new channel.
  • Acceptance of an AnswerFast3 request by the called terminal results in a predetermined status of master slave determination by comparing the terminal type value in the received AnswerFast3 request with the value for the local terminal. The highest value will be selected as the master. In the event of equal terminal type values, the calling terminal will be selected as the master.
  • Other variants are available, such as the transmission of an additional random number, in a similar fashion to Master Slave determination, may be used to reduce the likelihood of this resolution being decided on the caller/callee status. It is also possible that in some cases, an inability to resolve this status in a symmetrical way would be a sufficient condition to revert to another set up technique.
  • FIG. 20 is a simplified diagram illustrating the use of AnswerFast3 in Q.931 SETUP between two H.324 terminals according to an embodiment of the present invention.
  • the media may be a unidirectional or bidirectional channel.
  • a calling terminal requests AnswerFast3 by including a request PDU in the Q.931 SETUP message (e.g., the Subaddress field Information Element).
  • the message is populated with a PER encoded structure with the following ASN definition:
  • a called terminal responds to an AnswerFast3Request by including a response PDU in one of the allowed Q.931 response messages to establish a session on the underlying network.
  • the response message could be the Alerting, Call Proceeding, or Connect message depending on the type of called terminal and whether gateways are used in the core network.
  • the called terminal can easily check for the presence of the AnswerFast3 Response message in each response message it receives. Embedding the AnswerFast3 Response message in an early message such as the Alerting or Call Proceeding could allow the calling terminal to use the time until a Connect message is received for house-keeping purposes.
  • the AnswerFast3 Response message is an ASN.1 PER encoded structure with the following definition:
  • CONNECT message it may assume that the called terminal does not support AnswerFast3, or has not accepted any of the specified profiles. In this case, the calling terminal will proceed with the connection as if AnswerFast3 is not used. Thus, an AnswerFast3 fallback mode is provided by embodiments of the present invention.
  • the calling terminal can also attempt to use AnswerFast2 as discussed more fully above.
  • the calling terminal can also attempt to use AnswerFast4 as discussed more fully below.
  • the embodiment is illustrated in FIG. 21 where the Equipment Preferred modes (Request and Response messages shown in FIG. 21) are transmitted on the bearer channel.
  • the Equipment Preferred modes can be similar to that described in the AnswerFast3 embodiment section and can be an explicit description of preferred modes or a coded (index for look-up in a table of common modes).
  • the Answerer (Entity B) could be the Decision maker which selects the preferred mode of operation from Preference Modes proposed by the Caller (Entity A) in its Request Message.
  • the Caller Preference Modes in its Request Message could include one or more Preference Modes.
  • the Answerer Request Message could be empty or could include dummy informational messages.
  • the Caller Request Message could be empty or could include dummy informational messages.
  • the Answerer Response Message carries the adopted Preference Mode (i.e. the Answerer decides which mode to proceed with).
  • Another way to select a Decision Maker is to have both terminals transmit a random number and have the terminal with highest (or lowest) number be the decision maker. In case of a tie, the scheme would assume the Caller (or Answerer) to be the Decision maker.
  • frame flag emulation in the S2 needs to be detected and protected. Protection can utilize a repetition mechanism. For example, if the framing flag is ⁇ flxf2>, and an ⁇ flxf2> occurs in S2, then the ⁇ flxf2> is replaced by ⁇ f Ixf2xf Ixf2> by the transmitted. The receiver will replace any received ⁇ f Ixf2xf Ixf2> by ⁇ flxf2>. Note that if error encoding is used then this could be signaled by using a different set of framing flags in this procedure.
  • the caller and answerer terminals transmit their Request message constructed as described above one or more times (typically a minimum of 2) back to back
  • the caller terminal After the caller terminal transmits its preferred modes it expects a response or a conventional H.324-like initial bearer transmission of this method of session speed-up is not supported. What the answerer first transmits on the bearer channel can be ignored by the caller and only used by the caller to notice that the called (answerer) terminal supports this method of session speed-up.
  • the called terminal transmits its response which incorporates the accepted mode of operation as described in the AnswerFast3 operation with the only difference being that the messages would be constructed according the construction procedure above with the message being the response message.
  • Once the caller terminal receives the response it can start transmitting its media. The called terminal will be in position to accept media when it has transmitted its response.
  • Preference Messages contain only a small/limited amount of information/preferences, such as profiles, transmit and receive indications, preferences for algorithms/techniques and mobile level detect then they will have small size and may be repeated in a redundant fashion very quickly at call start up.
  • These Preference Messages could then also be known as bullets, session setup bullets, or signaling bullets due to their size and "rapid-fire" repetition. Note that the caller will be in a position to accept media according to its proposal when it transmits its request. Also note if the terminals do not recognize the messages or cannot detect them (e.g. because of corruption) then they can proceed according to AnswerFast2 speed-up.
  • AnswerFast4 is a method for speeding up the call set up by communicating the preferred session profiles, including those described in AnswerFast3 above, on the bearer channel instead of the signaling channel.
  • the session profiles or preferences are messages similar to those described above, and can be further encoded for noise immunity purposes using error control techniques to improve error resiliency.
  • the proposed session profile information is transmitted on the bearer channel as soon as it is established, and is repeated at some rate until AnswerFast4 fallback phase begins.
  • the AnswerFast4 messages are selected in a way that non AnswerFast4 supporting terminals will ignore the messages as unknown noise, corruption, or unwanted data.
  • the called party message also contains preferences. Once the called party terminal detects the Caller AnswerFast4 Request, it analyses the request and may transmit an Answerer AnswerFast4 Response.
  • AnswerFast4 Response message is an optional message, and such a message is not necessary to the operation of AnswerFast4, but is provided for flexibility, for example, for H.324 terminals that need acknowledgement for instance of the selected mode of operation.
  • An example may be a gateway with H.324 termination. Gateways typically need to allocate resources for transcoding, and changing the transcoding resources may be costly in complexity and processing time.
  • the AnswerFast4 Response message may alleviate the complexity, although at the cost of slightly increased session set up time compared to the case where an AnswerFast4 Response is not used, or not necessary.
  • the response may also take the form of a simple bit filed change to the otherwise being redundantly transmitted preferences (e.g. An Ack bit).
  • Another example of the tradeoff of flexibility versus efficiency of set up time is the simplification of the session profiles or preferences, in that one can elect for an approach where flexibility is not paramount but set up time is, and one can opt in this case to the simplest mechanism to signal preferences, which would include the use of predetermined profiles, and their combination as messages with media and mobile level sequences in order to achieve fast session set up, fastest fallback, but not necessarily the most flexible in terms of ability to transmit custom profiles or data.
  • Other aspects such as symmetry of session aspects, such as symmetric codecs, are a further example of flexibility that might be desired in some protocols or implementations.
  • the AnswerFast4 concept described in this specification covers the principle of transmitting a "signal" early on the bearer, and independently of the H.245 messaging, and how the "signal" is exploited by the peer terminal as an indication of supporting similar acceleration technique, and provide the means to exchange media with minimal signaling.
  • the description in the present specification covers embodiments that include the optional AnswerFast4 Response for completeness.
  • FIG. 22 is a simplified diagram illustrating AnswerFast4 according to an embodiment of the present invention.
  • the session profiles are similar to that described in the AnswerFast3 section.
  • the session profiles can be explicitly expressed (instead of being predefined).
  • the AnswerFast4 Request message can be constructed according to the procedure described below.
  • FIG. 23 is a simplified diagram illustrating AnswerFast4 according to another embodiment of the present invention.
  • inference or a preference rule set is used at each terminal and the optional response message is not required to be sent before media transmission may begin.
  • FIG. 24 is a simplified illustration of the structure of an AnswerFast4 frame according to an embodiment of the present invention. As illustrated in FIG. 24, the AnswerFast4 request and response frames are octet aligned. Accordingly, AnswerFast4 message transmissions are octet aligned, allowing for compatibility with conventional transmissions of other mobile levels.
  • the Frame Info field of the AnswerFast4 frame has the values shown in Table 3:
  • the payload length field indicates the payload size before applying emulation insertion octets.
  • the messages can be optimized for size by use of a payload present indicator, that if not present would leave the message at a minimum size. If payload were present, a payload present indicator, a payload length and a payload would all be included in the message.
  • the payload can be of any length.
  • the frame information is configured to limit the payload to 150 octets, as in many networks, frames are transmitted and processed in 160 octets time-slots.
  • the payload length will be varied as appropriate to the particular applications.
  • the messages can also be used for differing purposes depending on certain values in a header field. Different message types, such as Request, Response or Command and Indication, or media could be indicated. Also, sequence numbers or segment indicators could also be used for error resiliency and protocol use.
  • the CRC field is 16 bits in length and is determined by applying a Cyclic Redundancy Check (CRC) to the entire frame excluding the AnswerFast4 Sync Flags.
  • CRC Cyclic Redundancy Check
  • the CRC is as described in accordance with 8.1.1.6.1/V.42.
  • the frame will be discarded.
  • Error detection or error correction can be added to AnswerFast4 messages if desired. Error correction could be used with a Forward Error Correction code similar to those already used in H.324 for higher multiplexer levels and a modification to the message allowing transmission of the required information. Error detection could be implemented using a cyclic redundancy check.
  • the CRC value could be transmitted in the message in a specified field.
  • Multiplexer synchronization flag emulation protection may be performed on AnswerFast frames to ensure the entire message appears as noise and/or unwanted data on the bearer. This ensures that any transmissions are not misinterpreted by legacy devices as conventional transmissions such as level detect. It also affords the ability to invisibly transmit AnswerFast4 messages during a session through another legacy device, such as a gateway, that may be capable of intercepting legacy transmissions.
  • an emulation insertion procedure is performed before sending the frame to the bearer.
  • the fields with Payload Length, Payload, and CRC are applied with an emulation insertion procedure.
  • all octets with values 0xA3, 0x35, OxEl, 0x4D, 0x19, OxBl and 0x7E are duplicated by 1 octet with the same value.
  • Response message is optional, and can be used as a confirmation in some situations, for example, if a terminal such as a gateway prefers to confirm the media codec selections prior to proceeding with a session.
  • a terminal such as a gateway prefers to confirm the media codec selections prior to proceeding with a session.
  • Another situation in which a Response is used is if the AnswerFast4 Request contains some application specific information request, for example, an encryption key.
  • a media mode can be determined according to the preferences and capabilities expressed from each device. If preferences resemble H.245 preferences (e.g. expressed by TCS, OLCs, and the like) codecs may be selected in the same way as normal H.245 message exchanges except that transactions are conducted implicitly till the final outcome. This technique forms an ICM and it may be deduced according to capability preferences and media mode conflict resolution as specified in B.2.2.2 and C.4.1.3 in H.245. [0281] Many other restrictions and rules sets for determining media mode are also possible, and some may be made over fewer variable characteristics. If profiles are used, then a simple matching of capabilities in preferred order could be conducted.
  • 0x0000, 0x0100, Ox 1000 are supported by a device, and it receives indication that a peer device supports only 0x01000, then 0x0100 would be selected.
  • a preference selection will be made.
  • An example of a preference rule would be to assign preference to the order in which the profiles are expressed. This preference order could be forward or reverse, and could be modified by other inputs.
  • Another rule could be to select a preference based on index, either highest or lowest.
  • 0x0100 could be selected by a rule using a highest index rule.
  • One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • a terminal detects an AnswerFast4 Request message, it can determine configurations (media/data/multiplexer modes) for both itself and the remote device according to the preferences received and the preferences it will transmit or has transmitted.
  • the determination of configuration can be made from the input/presence of the AnswerFast4 message and a set of predefined rules. These rules may be predefined or predetermined based on some input, or may be simple rules based on explicit messages. Rules may, or may not, re-use rules that already exist in a device presently, such as H.245 most preferred mode.
  • the AnswerFast4 Sync Flag is defined as illustrated in Table 4.
  • An AnswerFast4 synchronization flag may be selected to ensure that it is not interpreted as a conventional message, but instead appears as noise/ignorable data to a conventional terminal.
  • one AnswerFast4 Synchronization Flag is inserted immediately before and after each AnswerFast4 Frame. Generally, only one AnswerFast4 Synchronization Flag will exist in between two consecutive AnswerFast4 Frames.
  • Embodiments of the present invention provide a procedure for constructing AnswerFast4 Requests and Responses. Once the bearer is established, if a terminal supports AnswerFast4, it will preferably immediately send an AnswerFast4 Request frame. In an embodiment, the frame may be repeated until one of the following situations occurs:
  • a valid mobile level stuffing flag is detected, as described in C.6/H.324; or A time out occurs, and no valid AnswerFast4 Request has been detected.
  • the terminal accepts it by sending an AnswerFast4 Response frame if this option is used. Note that the AnswerFast4 Response itself does not require payload data. The frame is repeated, except the payload field which may contain media data if media data tunneling is desired
  • media may be transmitted in the payload field of the AnswerFast4 Response frame if responses and media tunneling are in use.
  • the payload content may contain a MUX-PDU, which is in accordance with the specification of H.223, using the finally agreed mobile level.
  • the payload length will not be more than 150 octets.
  • all terminals supporting AnswerFast4 will support and handle MUX-PDUs if included in the AnswerFast4 messages.
  • An AnswerFast message may contain media as their payload.
  • This media may take the form of a MUX-PDU at a given multiplexer level, but it may be a specific other coding, such as the native codec bit stream form in an AnswerFast message, to take advantage of other attributes that coding may possess.
  • media is sent in an AnswerFast message, then it is not necessary to redundantly transmit the message, and instead a train of messages containing media can be sent that represent the audio/visual/data of the session.
  • Each of these different media types are sent tunneled in the messages and may be distinguished in a variety of ways from each other so that each media channel is able to be interpreted at each side.
  • the media encapsulated/tunneled in an AnswerFast message may also be recovered and passed to its associated decoder even in the case where an error check has cast doubt onto the veracity of the received transmission, thus if a CRC failure occurs on a tunneled video packet, the packet may still be attempted to be used in the decoder.
  • a channel may also be bidirectional after it is established, or an implicit (or signaled/predefined) relationship set up between two distinct channels.
  • a bidirectional channel, or a pair of unidirectional channels might be used for accelerated and flexible negotiations without the need of establishing or using the H.245 control channel, these bidirectional messages could then be acknowledged.
  • the media may simply be transmitted in appropriate MUX-PDUs on the bearer (without tunneling in AnswerFast4 messages).
  • FIG. 25 is a simplified diagram illustrating a method of AnswerFast4 according to an embodiment of the present invention with media transmitted in AnswerFast4 frames.
  • the terminal After sending an AnswerFast4 Request and optionally detecting an AnswerFast4 Response, the terminal will begin a normal session using the agreed mobile level. Audio and video exchange will also start immediately if they have not been started during the AnswerFast4 Response stage if in use. Utilizing embodiments of the present invention, audio and video exchange are enabled to continue seamlessly if they have been started during the AnswerFast4 Response stage whether used or not.
  • the terminal may immediately continue normal H.324 session procedure according to Annex C/H.324 as described in more detail below. Audio and video coding will be restarted if they have been started during sending AnswerFast4 Response frames.
  • AnswerFast4 If some, or all, aspects of an AnswerFast4 session are not successful, then a fallback to AnswerFast2 technology is recommended. If a configuration mismatch suggests a correction, then AnswerFast2 techniques can be used to determine the correct mode and, if necessary, restart the codecs and logical channels in the fashion expected by the remote device. If AnswerFast2 (optionally with AnswerFast 1 and/or some SRP extensions) does not succeed, conventional behavior should be adopted.
  • AnswerFast2 (optionally with AnswerFast 1 and/or some SRP extensions) does not succeed, conventional behavior should be adopted.
  • the calling terminal may stop sending AnswerFast4 Response frames immediately and continue normal H.324 session procedure according to Annex C/H.324 as described in more detail below.
  • a fallback to conventional mobile level operation may be triggered by detection of valid normal mobile level flags.
  • a certain threshold number must be detected to provide a level associated with detection according to
  • the terminal should preferably stop sending the AnswerFast4 messages and drop back to AnswerFast2, or conventional behavior, as it should be apparent that the terminal is communicating with a non-AnswerFast4 capable terminal.
  • the AnswerFast4 Request payloads are ASN.1 PER encoded structure as shown below:
  • terminalCapabilitySet TerminalCapabilitySet SEQUENCE (1..65535) OF OpenLogicalChannel , multiplexEntrySend MultiplexEntrySend,
  • This structure allows a terminal to use either predefined session profiles, such as those described for AnswerFast3, or to use explicit session profile definitions. Note that if flexibility is not paramount, then predetermined modes can be used and the AnswerFast4 messages can be reduced to a minimal signal that is exploited by terminals to transmit their media as early as possible, in approximately one half a round trip time.
  • the AnswerFast4 payload handling procedure is that the calling party is always the Master when the terminal types are identical between the two terminals and explicit Master Slave Determination knowledge is required. Alternatively the terminals may ignore the need for knowledge of master-slave relationship until later on in the session (e.g., in AnswerFast2 if used or in conventional H.245 messaging). Thus, the calling party will be in a position to accept media according to the form of the media mode signaling approach and the desired flexibility.
  • AnswerFast technology may be required to be ready to accept (receive and decode) media immediately, depending on the form of the signaling of the session preferences whether predetermined, predefined, or explicit.
  • the receiver will preferably be ready to accept and decode the media at the earliest possible time, which is equal to 0.5 round trips. In other embodiments, session establishment is performed in approximately 0.5 round trips.
  • the media may arrive simultaneously, or in parallel, with the message indicating the preferences to be used. In this case, the receiving terminal will use the information indicating the configuration and decode/use the media.
  • the information indicating the configuration may arrive or be processed too slowly to make the best use of the arriving media, or initial media is clipped by the establishment of the end to end bearer.
  • One of several approaches to the situation involving configuration messages is to buffer all media that has arrived until the message arrives. The buffered information is used, thereby losing a minimal amount of session information.
  • Another approach applicable to initial media clipping and lack of decoder information is to transmit non-temporally redundant media (e.g., key frames/intra frames) at either increased frequency, possibly exclusively, or at a known time.
  • a further approach that will aid the decoding device is to include an indication, in the coding, that a media message contains non-temporally redundant media. On detection of this marker, a stream can be decoded from this point alone, allowing for processing savings and a reduction in complexity.
  • One particular time that would be particularly useful for the encoding/transmitting side to transmit non-temporally redundant media would be upon receipt of an acknowledgment (implicit or explicit) from the receiver at the transmitter. This follows from the fact that upon receipt of an acknowledgment, the transmitter knows the receiver is ready to decode. Other possibilities would also include the case of not receiving a negative acknowledgement in a certain time period. A particular example of this case would be the receipt of the TCS Ack in the AnswerFast2 case, or on the receipt of either an AnswerFast4 response message or AnswerFast4 session media in the AnswerFast4 case. These media arrival behaviors may be predetermined (if flexibility is not paramount), predefined, or could be explicitly signaled depending on a devices support. It should be noted that if the terminals do not recognize the messages or cannot detect them (e.g., because of corruption) then they may proceed according to AnswerFast2 speed-up techniques previously described throughout the present specification.
  • Embodiments of the present invention also provide for techniques to fallback from AnswerFast4. For example, if a calling terminal does not receive an AnswerFast4 message, but a normal H.245 TerminalCapabilitySet message (with or without an AnswerFast2 style message), the terminal will assume that the called terminal does not support AnswerFast4, or has not accepted any of the specified profiles. In this case, the calling terminal will continue to use the conventional TerminalCapabilitySet, MasterSlaveDetermination, MultiplexEntrySend, and OpenLogicalChannel procedures to create the session. It can also attempt to use AnswerFast2 techniques utilizing H.245 commands as described more fully throughout the present specification.
  • the fallback to conventional operation may be triggered by detection of a normal TCS that lacks indication of AnswerFast technique support.
  • a terminal Upon detecting this TCS, a terminal should preferably stop sending AnswerFast4 messages and drop back to AnswerFast2 or conventional behavior as it should be apparent that the terminal is communicating with a legacy device.
  • Embodiments of the present invention provide techniques that combine interleaving of fast session establishment signaling or messaging with conventional techniques and media.
  • a further embodiment of the AnswerFast4 technique involves a combination of conventional multiplexer level set up and AnswerFast4.
  • One possible combination of techniques is with AnswerFast4 messages being transmitted onto the bearer less densely than the maximum possible (e.g., not back to back). This sparseness of transmission leaves the bearer unused by the AnswerFast technique at points in time. When not in use, the bearer is available to the device to use in a conventional fashion.
  • the AnswerFast device Since the AnswerFast device is operating partially in a conventional manner, interleaving in this manner will minimize any delay when interoperating with another conventional device.
  • the sparseness of AnswerFast4 message retransmission is a parameter that can be tuned based on required error resilience and conventional interoperation delay desired.
  • Adaptation of the AnswerFast4 messages is also possible based on input from the conventional operations. For example, detection of a particular mobile level through conventional means, even in an AnswerFast4 to AnswerFast4 negotiation, may be used to determine the form of media transmissions.
  • FSS Fast Session Setup
  • AnswerFast4 a bearer-based Fast Session Setup Procedure
  • methods and systems are provided that include the FSS procedure as an alternative procedure for establishing an audio and video communication session in H.324.
  • the procedure transmits the preferred operation mode as the first bits transmitted on the bearer channel. Because these bits are prevented from emulating existing mobile level flags, including the base-line H.324 mode, they are ignored by existing terminals and hence maintains interoperability with existing terminals.
  • the procedure allows significant reduction of the session setup time.
  • a fallback mechanism is described for the connecting terminals that do not support FSS.
  • caller The terminal that originates the call (the calling terminal).
  • callee The terminal that answers the call (the called terminal).
  • ICM inferred common mode
  • NMLO normal mobile level operation
  • request frame An FSS frame of the request type, specified in the Frames & Synchronization Flags section.
  • Request frame payload field Alternatively other codings for the FSS request message could be used.
  • FSS response frame An FSS frame of the response type, specified in the Frames & Synchronization Flags section. Alternatively other codings for the FSS response message could be used.
  • FSS response message An ASN.1 coded FSS response message contained in the FSS Response frame payload field. Alternatively other codings for the FSS response message could be used.
  • session profile A collection of specified values for all aspects of the multiplexer along with H.245 parameters for the codecs to be used and the logical channels to be opened. Profiles defining one or more aspects are also included herein, for example a session profile containing an audio profile and a multiplexer profile.
  • a mode for the FSS procedure in which both the connecting terminals determine the common mode for media channels (Inferred Common Mode) from their respective Fast Session Setup request messages.
  • a terminal can interrupt the FSS phase by transmitting standard mobile level sequence flags as described in C.6 ⁇ H.324.
  • the FSS phase may be repeated if desired.
  • circuit-switched operation for example 3GPP 3G-324M, the two connecting terminals should repeat the transmission of an FSS frame (Request or Response) while waiting to proceed to the next phase.
  • the Session Profiles can be predefined or explicitly expressed.
  • the FSS Request and FSS Response messages are constructed according to the procedures described in the FSS Request Payloads and FSS Response Payloads sections below, respectively.
  • a terminal supporting FSS shall support Predefined Profiles. Support of
  • Explicit Profiles is recommended. A tradeoff between speed and flexibility is provided by the predefined profiles included herein. As an example, standardized predefined profiles may increase session setup speed by providing a limited range of operating points. For terminals utilizing this technique, there exists a significant probability of selecting and transmitting using a predefined profile commonly shared with a peer terminal. Matching of these predefined profiles thus increases session setup speed. Explicit profiles are also included according to embodiments of the present invention and provide additional advantages including flexibility. [0314] Predefined Profiles for FSS Procedure
  • Embodiments of the present invention provide a number of predefined profiles for FSS procedures. These predefined profiles include profiles for audio codecs, video codecs, multiplexer capability profiles, and multiplexer table entry profiles and may be similar to profiles and preconfigured modes disclosed throughout the present disclosure. The following particular predefined or preconfigured characteristics are provided:
  • Video channels are represented as Al, A2, A3, ... Video channels are represented as Vl, V2, V3, ... multiplexProfile 0 (0x0000)
  • the FSS Request and FSS Response frames are octet aligned and have the structure shown in FIG. 26.
  • the Frame Information (FI) field consists of 3-bit Frame Type (FT), followed by 3-bit Segment Sequence Number (SSN), followed by 1-bit for Last SSN (LS) flag, and followed by 1-bit Payload Marker (PM) flag.
  • FT Frame Type
  • SSN Segment Sequence Number
  • LS Last SSN
  • PM Payload Marker
  • the FT field has the values shown in Table 5, which provides a description of the Fast Session Setup Frame Type field.
  • the Sequence Number (SN) field is present when LS is set to 1. It indicates the sequence number of an FSS Request or FSS Response frame. The number shall start from 0. For FSS Request, it indicates the total number of re-proposals for a request and counter-offers for any subsequent response(s). For FSS Response, it matches the SN of the received FSS Request associated with the Response, or is an increment of the SN modulo 256 of the received FSS Response.
  • the Payload Length (PL) field indicates the payload size in octets before applying emulation insertion octets.
  • the FSS frame payload or FSS-PDU shall not exceed 150 octets.
  • the receiver shall support the overall FSS-MDU payload length of up to 1050 octets excluding any octets inserted during the Flag Emulation Avoidance procedure described in the FSS Flag Emulation Avoidance section below.
  • the Payload when present, corresponds to either a FastSessionSetupRequest message, a FastSessionSetupResponse message, or a single H.223 MUX-PDU.
  • the PM field shall be set to 1.
  • the ASN. I definitions of the FastSessionSetupRequest and FastSessionSetupResponse messages and all other ASN.1 messages referred to in this specification are described in the ASN.1 Syntax for FSS Procedure section below, and are encoded according the Packed Encoding Rules (PER) as defined in ITU-T Rec. X.691.
  • PER Packed Encoding Rules
  • the CRC (cyclic redundancy coding) field is 16 bits and is determined by applying the CRC to the entire frame excluding the FSS Synchronization Flags (see below).
  • the CRC is as described in 8.1.1.6.1 /V .42.
  • the CRC is calculated before the FEA procedure described in the FSS Flag Emulation Avoidance section below.
  • the corresponding FSS frame On detecting a CRC error, the corresponding FSS frame shall be discarded. For some implementations, some fields in the FSS frames are not fully utilized. These fields are populated with reserved bits or hard-coded values in some embodiments, thus reducing system complexity.
  • FIG. 28 illustrates the definition of the FSS Synchronization Flag as according to an embodiment of the present invention. Other flags are utilized in other embodiments, including standard multiplexer PDU framing for non-negotiated multiplexer table entries.
  • FSS Synchronization Flag shall be inserted immediately before each FSS Frame and one FSS Synchronization Flag shall be inserted immediately after each FSS Frame. Only one FSS Synchronization Flag shall exist between two consecutive FSS Frames.
  • An FSS Request payload is represented by the ASN.1 FastsessionsetupRequest message and allows a terminal to use either a predefined session profile or an explicit session profile definition.
  • a selection is made between either predefined or explicit session profiles based on one or more predefined rules or one or more preferences indicating a priority of profile type.
  • two terminals capable of using both predefined and explicit profiles may choose to use explicit profiles.
  • the selection of a profile will depend on the particular applications.
  • the nonStandard field is a container to allow a non-Standard based FSS Request to be specified. Examples of the additional information that may be provided in the nonStandard field include a MultiplexTableEntry, a Userlnputlndication, or a GenericCapability.
  • the predefinedProfile field contains the detailed settings of an FSS Request using the predefined profile approach and is described in the FSS with Predefined Profiles section below.
  • the explicitProfile field contains the detailed settings of an FSS Request using the explicit profile approach and is described in the FSS with Explicit Profiles section below.
  • An FSS Response payload is represented by the FastSessionSetupResponse message and allows a terminal to use either a predefined session profile or an explicit session profile definition.
  • the nonStandard field is a container to allow a non-Standard based FSS Response to be specified.
  • the predefinedProfle field contains the detailed settings of FSS Response using the predefined profile approach and is described in the FSS with Predefined Profiles section below.
  • the explicitProfile field contains the detailed settings of FSS Response using an explicit profile and is described in the FSS with Explicit Profiles section below.
  • a message data unit (FSS-MDU) size exceeds 150 octets, it shall be segmented into multiple sub-units called protocol data units (FSS-PDU). If an FSS- MDU directly maps to one FSS-PDU, without segmentation, the LS flag in the FI field of the FSS frame shall be set to 1. If an FSS-MDU maps into more than 1 segment, the LS flag shall be set to 0 except the last segment, which shall have the LS flag set to 1. The SSN shall be set to 0 for the first segment and monotonically incremented until the last segment, the maximum value of which is 6. The value 7 is reserved. All segments shall be sent at least once.
  • FSS-MDU message data unit
  • FSS-PDU protocol data units
  • a flag emulation avoidance (FEA) procedure Before transmitting the FSS frames onto the bearer, a flag emulation avoidance (FEA) procedure shall be performed against synchronization flags for all mobile levels of H.324 (flags of mobile levels 0-3).
  • the fields with Frame Information, Payload Length, Payload and CRC are included in the FEA procedure. All octets with values OxA3, 0x35, OxEl, Ox4D, 0x19, OxBI and Ox7E shall be duplicated by inserting adjacently an octet with the same value.
  • a predefined profile request payload is represented by the ASN.1 message FastSessionSetupPredef inedRequest which has the following fields:
  • version indicates the version number of the FSS Predefined Profile being used by the terminal transmitting the message. It shall be set to 1 for this release of the recommendation.
  • h245version indicates the version number of 1-1.245 being used by the terminal transmitting the message.
  • vendorld indicates the unique vendor identifier as adopted by ITU-T Rec. H.245 for the terminal transmitting the message.
  • terminalType indicates the terminal type number as specified in ITU-T
  • initialMobileLevel indicates the starting maximum mobile level the originating terminal can support.
  • h2231nfo indicates H.223 specific settings supported. This includes h223AnnexADoubleFlag, h223AnnexBOptionalHeader and multiplexProfiles.
  • h223AnnexADoubleFlag indicates the use of H.223 Annex A double flag mode for mobile level 1 either as an initial mobile level or the final mobile level.
  • h223AnnexBOptionalHeader indicates the use of H.223 Annex B optional header mode for mobile level 2 or 3 either as an initial mobile level or the final mobile level.
  • multiplexProfile indicates which predefined multiplex table profile is used by the terminal transmitting the message.
  • capabilityProfile indicates which predefined multiplex capability profile is used by the terminal transmitting the message
  • audioProfiles contains a list of predefined audio profiles ordered in the preference of use.
  • the list of predefined audio profiles are unordered and are used to express capabilities rather than preference of use.
  • videoProfiles contains a list of predefined video profiles ordered in the preference of use.
  • the list of predefined video profiles are unordered and are used to express capabilities rather than preference of use.
  • dataApplicationProfiles indicates a list of predefined data application profiles ordered in the preference of use. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored.
  • encryptionProfiles contains a list of predefined encryption profiles ordered in the preference of use. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored. In other embodiments, the list of predefined encryption profiles are unordered and are used to express capabilities rather than preference of use.
  • additionalParameters contains a list of predefined miscellaneous profiles including non-standard profiles ordered in the preference of use. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored.
  • mediaTunnel when set to TRUE, indicates that the terminal may accept media tunneled as payload of any FSS Response. When set to FALSE, the terminal does not support media payload in any FSS Response.
  • a terminal is preferably adapted to immediately receive media. Buffering of media, for example, in a receiving terminal may be performed to accommodate either message processing time or message corruption/loss of a capability set preference, or response, if sent, and the like. Accordingly, in the event of loss of, for example, a capability set preference, or response, sent by a peer terminal, a terminal receiving media will buffer the media until a repeated capability set preference, or response, message is received from the peer terminal.
  • the answering terminal when set to byCallee, decides the mode of operation and transmits the information of the mode in its
  • FSS Response frame to the caller.
  • the session profile is determined by both terminals as the inferred common mode.
  • a predefined profile response should not contain any message payload. If it does, the message payload may be ignored.
  • the predefined profile response consists of the FastSessionSetupPredef inedResponse ASN.1 message payload which has the following fields:
  • h223Info indicates H.223 specific settings supported. This includes h223AnnexADoubleFlag, h223AnnexBOptionaIHeader, and multipIexProfile.
  • h223AnnexADoubleFIag indicates the use of H.223 Annex A double flag mode for mobile level 1 as the final mobile level.
  • h223AnnexBOptionaIHeader indicates the use of H.223 Annex B optional header mode for mobile level 2 or 3 as the final mobile level.
  • multipIexProfile indicates which predefined multiplex table profile is used by the terminal transmitting the message. AudioProfiles contains a list of predefined audio profiles for both media directions.
  • the list should contain at least one audio channel path for outgoing direction and one for incoming direction, which is indicated by the MDI in a PPI. For example, for a bidirectional audio channel, at least one audio profile should be specified. If the list consists of unidirectional audio channels, one in each media direction, then at least two audio profiles should be specified.
  • videoProfiles contains a list of predefined video profiles for both media directions.
  • the list should contain at least one video channel path for outgoing direction and one for incoming direction, which is indicated by the MDI in a PPI.
  • the MDI for a bidirectional video channel, at least one video profile should be specified. If the list consists of unidirectional video channels, one in each media direction, then at least two video profiles should be specified.
  • dataApplicationProfiles contains a list of predefined data application profiles for both media directions.
  • the list should contain at least one data application channel path for outgoing direction and one for incoming direction, which is indicated by the MDI in a PPI.
  • at least one data application profile should be specified. If the list consists of unidirectional data application channels, one in each media direction, then at least two data application profiles should be specified. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored.
  • encryptionProfiles contains a list of predefined encryption profiles for both media directions.
  • the list should contain at least one encryption channel path for outgoing direction and one for incoming direction, which is indicated by the MDI in a PPI.
  • at least one encryption profile should be specified. If it consists of unidirectional encryption channels, one in each media direction, then at least two encryption profiles should be specified. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored.
  • AdditionalParameters contains a list of predefined miscellaneous profiles including non-standard profiles. This parameter is reserved and shall not be used. On receiving this parameter, it shall be ignored. [0350] Predefined Profiles and Indices
  • a predefined profile makes use of a single index, called predefined profile index (PPI) to represent a whole set of predefined parameters for audio codec, video codec, multiplex capability, and multiplex entry table. It also includes a media direction index (MDI) for each media type. In other embodiments, subsets of these profiles are utilized as appropriate to the particular application. For example, a predefined profile may represent an audio codec of a specific configuration or an entire channel state pertaining to a logical channel.
  • PPI predefined profile index
  • MDI media direction index
  • Baseline profiles for audio codec, video codec, multiplex capability, and multiplex entry table are defined in this recommendation. These baseline profiles are specified in the Predefined Profiles for FSS Procedure section above. Additional profiles can be added through normal standardization procedures.
  • FIG. 29 illustrates the structure of the PPI according to an embodiment of the present invention.
  • a PPI is represented by a 16-bit value.
  • the 3 most significant bits (MSBs) (bit 16 to bit 14), represent the Media Direction Index (MDI) as described in the Media Channels with Different Media Directions and Adaptation Layer Types section.
  • the remaining 13 least significant bits (LSBs) (bit 13 to bit 1) represent the Detailed Profile Index (DPI).
  • the values PPI with the pattern Ox [3,5,7,9,B,D,F]FFF are reserved.
  • the 5 MSBs represent the DPI profile category index (DPI-CI) which has either the media type for the case of media, the multiplex capability category for the case of multiplex capability, or the multiplexing category for the case of multiplex entry table.
  • DPI-CI DPI profile category index
  • the 8 LSBs are the unique identifier for a profile of the particular media, multiplex capability or multiplex entry table, called profile identifier (DPI-PID).
  • Table 6 illustrates the ranges of the DPI-CI according to an embodiment of the present invention.
  • Table 7 illustrates the ranges of the DPI-PID for the DPI-Cl with values smaller than 20 according to an embodiment of the present invention.
  • FIG. 30 illustrates a structure of the DPI in the PPI according to an embodiment of the present invention.
  • the definition of the ITU-T Rec. H.324 and 3GPP 3G-324M session profiles may be extended in separate documents from time to time.
  • the defined baseline profiles are described in the Predefined Profiles for FSS Procedure section above.
  • the 5-bit DPI-CI for the audio codec type defines the codecs as shown in
  • Table 9 illustrates definitions of predefined video codec types according to an embodiment of the present invention.
  • a 5-bit DPI-CI for the video codec type is utilized in a particular embodiment.
  • Table 1 H.324 - Definitions of predefined multiplex table profiles.
  • Logical channels are pre-assigned. For one or more audio channels, the logical channel numbers are 1 (Al), 17 (A2), 33 (A3), .... For one or more video channels, the logical channel numbers are 2 (V 1), 18 (V2), 34 (V3), .... For one or more data application channels, the logical channel numbers are 3 (Dl), 19 (D2), 35 (D3), .... For one or more non-standard channels, the logical channel numbers are 4 (01), 20 (02), 36 (03), .... The maximum number of predefined entries for any multiplex table PPI is 13. Details of baseline predefined multiplex table profiles are defined in Appendix IV.2.4/H.324.
  • the FSS Response frame is used as an Ack only and not to define operating conditions. In this case, it is not necessary for the receiving terminal to send further FSS frames.
  • FSS fallback When valid mobile level stuffing flags are detected or when timer T401 expires before detecting a valid FSS frame, normal H.324 session procedure shall be used according to Annex C. This is also referred to as FSS fallback.
  • an FSS Request When an FSS Request is detected, the payload is processed. If the payload is decoded successfully, the terminal accepts it by sending an FSS Response frame.
  • An FSS Response itself may incorporate message payload data or media payload data depending on the modeDetermination and mediaTunnel flags in the FSS Request defined in the modeDetermination section and the mediaTunnel Mode section. The frame may be immediately repeated, except the payload field for the media payload data, until one of the following situations occurs:
  • the caller shall be the master when the terminalType fields in the FSS Request frames of the two terminals are identical.
  • the terminalType fields differ, the terminal which has higher terminalType value shall be the master.
  • a terminal indicates its capability to accept media tunneled in any FSS Response by setting the mediaTunnel to TRUE, according to the mediaTunnel Mode section below.
  • the terminal shall begin NMLO using the agreed mobile level. Audio and video exchange as determined by the ICM or from the accepted FastSessionSetupPredefinedResponse shall also start immediately if they have not already started during the FSS Response phase. Audio and video exchange shall continue seamlessly if they have been started during the FSS Response phase. After the receipt, and acceptance of a peer's preferences the transition to normal media transmissions in the inferred mode occurs. The encapsulation of the media inside the special FSS framing is no longer necessary and it is transmitted directly on the bearer.
  • the terminal may decide not to proceed with the FSS procedure. It shall follow the procedure described in the Fast Session Setup Fallback Procedure Specification Section. After an FSS Request has been sent and an FSS Request has been detected, if the terminal does not detect an FSS Response frame, but detects valid mobile level stuffing flags, the terminal shall follow the procedure described in the Fast Session Setup Fallback Procedure Specification Section.
  • the FSS Response to be transmitted On receiving FSS Response without message payload before receiving FSS Request at the beginning of the FSS procedure, the FSS Response to be transmitted shall have the SSN set to 7. On receiving an FSS Response without message payload and with SSN set to 7, the terminal shall reset to restart the media bitstream generation what NMLO begins. Transmission of media tunneled in the FSS Response frames may be ignored. On receiving unexpected FSS frames, they shall be ignored.
  • FastSessionSetupPredefinedResponse the selected logical channels in the form of PPIs for both directions within the capabilities of both terminals.
  • the caller shall send an FSS Response frame without message payload only after receiving FastSessionSetupPredefinedResponse from the callee.
  • the ICM is determined by both terminals according to logical channel selection in C.4.1.3/H.245 and C.5.1.3/H.245 with the information described in the Media Channels With Different Media Direcations And Adaptation Layer Types section below.
  • the FSS Response frames of both terminals shall not include any message payload on accepting the ICM.
  • the FSS Response frames are not transmitted and media sent using the ICM is interpreted as an acknowledgement of successful session setup.
  • the mediaTunnel flag in FastSessionSetupPredefinedRequest is set by a terminal to indicate its capability in receiving media tunneled in FSS Response frames. If a terminal is not operating in the mediaTunnel mode, the terminal will preferably wait to receive an FSS Response message before transmitting media.
  • the peer terminal may tunnel media data in its FSS Response frames which do not require message payload.
  • the terminal tunneling the media shall transmit one H.223 MUX-PDU in accordance with the ITU-T Rec. H.223 using the finally agreed mobile level as the payload of an FSS Response frame without any mobile flags.
  • FSSPSR does not need to be applied to the media payload.
  • MUX-PDUs shall be sent in sequence, until the completion of the FSS Response phase and the start of the normal media transmission phase (NMLO).
  • the peer terminal When a terminal sets mediaTunnel in its FastSessionSetupPredefinedRequest to FALSE, the peer terminal shall not tunnel any media in its FSS Response frames. Waiting for a message before transmitting media has substantial benefits in allowing for a more simple implementation especially with regards to gateways and simple terminals.
  • a terminal may choose to re-propose a new FSS Request instead of a fallback as described in the Fast Session Setup Fallback Procedure Specification Section.
  • the modeDetermination field in FastSessionSetupPredefinedRequest of both terminals is set to simultaneous, and a terminal does not accept the FSS Request from the peer terminal, it may re-propose a new FSS Request by incrementing the SN in the FSS Request frame by 1 modulo 256 with the new request settings. If both terminals re- propose a new FSS Request simultaneously, simultaneous determination mode continues to be adopted provided that modeDetermination is set simultaneous by both terminals. If both terminals re-propose a new FSS Request simultaneously and either terminal set modeDetermination to byCallee, non-simultaneous determination shall be adopted.
  • a simultaneous determination re-proposal mode may be repeated until an ICM can be determined by both terminals, or until a terminal decides to follow the fallback procedure described in the FSS Setup Fallback Procedure Specification Section.
  • a simultaneous determination re-proposal mode may be followed by a non- simultaneous determination mode but not vice versa.
  • the answering terminal may re- propose its request by incrementing the SN in the FSS Request frame by 1 modulo 256 with the new request settings.
  • the caller accepts the FSS Request by the answering terminal, it shall respond to the answering terminal by sending the FSS Response with the SN in the FSS Response frame matching that of the FSS Request frame with the final selection.
  • the caller may re-propose its request by incrementing the SN in the FSS Request frame by 1 modulo 256 with the new request settings.
  • a terminal may re-propose a new FSS Request as described above, or counter propose a new FSS Response as described in the Response Counter-Offer Procedure Section.
  • the non-simultaneous determination mode may be repeated until both terminals can accept a common mode initially selected by the callee, or subsequently selected by one of the terminals, or until a terminal decides to follow the fallback procedure described in the Fast Session Setup Fallback Procedure Specification Section.
  • a terminal may choose to counter-offer with a new FastSessionSetupPredefinedResponse after receiving an FastSessionSetupPredefinedResponse from the peer terminal instead of re- proposing a new FastSessionSetupPredefinedRequest as described in the Request Re- Proposal Procedure section or fallback as described in the Fast Session Setup Fallback Procedure Specification section.
  • the new counter proposed FastSessionSetupPredefinedResponse shall be set with the SN in the FSS Response frame incrementing by 1 modulo 256 from the SN in the last FSS Request frame received.
  • the determination of the FastSessionSetupPredefinedResponse shall be based on the message content of the received FastSessionSetupPredefinedResponse with the adjustment of the media channel directions from all currently proposed channel profiles.
  • the received FastSessionSetupPredefinedResponse is modified by the removal of the channels that it cannot accept and the addition of the channels that it can support.
  • FSS with Explicit Profiles [0394]
  • FSS Explicit Profile Request [0396]
  • the explicit profile request is represented by the FastSessionSetupExplicitRequest ASN.1 message which has the following fields:
  • version indicates the version number of the FSS Explicit Profile being used by the terminal transmitting the message.
  • h245version, vendorld, terminalType, initialMobileLevel, mediaTunnel and modeDetermination have the same meaning as in the Predefined Profile Request Payload section.
  • h223Info indicates H.223 specific settings support. This includes h223AnnexADoubleFlag, h223AnnexBOptionalHeader, and multiplexEntrySend. h223AnnexADoubleFlag and h223AnnexBOptionalHeader have the same meaning as in the Predefined Profile Request Payload section.
  • multiplexEntrySend indicates the multiplex entry table to be used by the terminal transmitting the message and is specified according to H.245.
  • multiplexCapability indicates the multiplex capability to be used by the terminal transmitting the message and is specified according to H.245.
  • openLogicalChannels contains a list of media channels in both directions to be used ordered by preference and are specified according to H.245.
  • Media include audio, video, data application and encryption.
  • additionalParameters contains a list of H.245 messages encoded in
  • the list may include additional information, requests and non-standard H.245 messages ordered in the preference of use.
  • the explicit profile response does not contain any payload.
  • the explicit profile response is represented by the FastSessionSetupExplicitResponse ASN.1 message which has the following fields:
  • h223Info indicates H.223 specific settings support. This includes h223AnnexADoubleFlag, h223AnnexBOptionalHeader and multiplexEntrySend. h223AnnexADoubleFlag and h223AnnexBOptionalHeader have the same meaning as in the Predefined Profile Response Payload section. multiplexEntrySend has the same meaning as in the FSS Explicit Profile Request section.
  • multiplexCapability and additionalParameters have the same meaning as in the FSS Explicit Profile Request section.
  • openLogicalChannels contains a list of media channels selected for both media directions and are specified according to H.245.
  • Media include audio, video, data application and encryption.
  • additionalParameters contains a list of H.245 messages encoded in ASN.1 according to H.245.
  • the list may include additional information, responses to requests indicated in the additionalParameters in the corresponding FastSessionSetupExplicitRequest message, and non-standard H.245 messages ordered in the preference of use.
  • FSS Explicit Profile Request and Response Exchange Procedure When two connecting terminals utilize FSS Explicit Profiles, the FSS Explicit Profile Request and Response procedure is identical to the procedure described in the FSS Predefined Profiles Exchange Procedure section with all occurrences of predefined profile and FastSessionSetupPredefinedResponse to be replaced by explicit profile and FastSessionSetupExplicitResponse respectively.
  • the interworking of predefined and explicit profiles is described in the Interworking between FSS Predefined Profiles and FSS Explicit Profiles section.
  • OpenLogicalChannel request messages For the case of bidirectional logical channels, only the forward logical channel number can be specified.
  • the reverse logical channel number shall be the same as the forward logical channel number. In an embodiment, if a reverse logical channel number is already assigned, the next available logical channel number will be assigned. The highest logical channel number will be 14, and any OpenLogicalChannel number requests that lead to a logical channel number exceeding 14 will be ignored.
  • MultiplexEntrySend request message should match with the assigned logical channel numbers.
  • Response Counter-Offer Procedure The procedure is identical to the Response Counter-Offer Procedure with all occurrences of FastSessionSetupPredefinedRequest and FastSessionSetupPredefinedResponse to be replaced by FastSessionSetupExplicitRequest and FastSessionSetupExplicitResponse respectively.
  • the callee may skip to send the FSS Request and send the FSS Response.
  • a selection may be made to select a preferred profile exchange mode.
  • the preferred profile exchange mode process may select a mode that is the same as or different than the mode originally transmitted by the callee.
  • the callee selects both Predefined and Explicit Profiles for initial transmission. Merely by way of example, if the callee originally transmitted Predefined profiles and then determined that the caller preferred Explicit Profiles, the callee may select to switch modes from Predefined Profiles to Explicit Profiles.
  • a terminal that decodes and supports the received profile type should either send an FSS Response with a message payload (non-simultaneous determination) or resend the FSS Request with modeDetermination set to byCallee using the same profile type as that it received and follow the procedure described in the FSS Predefined Profiles Exchange Procedure or FSS Explicit Profile Request and Response Exchange Procedure sections.
  • the callee shall ignore the FSS Response it received. If the callee sent the FSS Response and receives the resent FSS Request frames, it shall ignore the FSS Request it received. If the callee sent the FSS Request and receives the resent FSS Request frames, it shall decide which mode of profile it will use and follow the procedure described in the FSS Predefined Profiles Exchange Procedure or FSS Explicit Profile Request and Response Exchange
  • the caller shall handle the FSS Response frame according to the FSS Predefined Profiles Exchange Procedure or FSS Explicit Profile Request and Response Exchange Procedure sections.
  • a terminal may choose to re-propose a new FSS Request instead of fallback as described in the Fast Session Setup Fallback Procedure Specification section.
  • the terminal may send a new FSS Request using the same profile type as the peer terminal according to FSS Predefined Profiles Exchange Procedure or FSS Explicit Profile Request and
  • An H.324 entity which supports FSS shall support the fallback procedure when the peer H.324 entity does not support FSS or transmits the mobile level flags before the completion of the FSS procedure. If a terminal does not receive an FSS Request but has detected a normal start up procedure with a normal H.245 TerminalCapabilitySet message at an agreed initial mobile level, it shall assume that the peer terminal does not support FSS, or has not accepted any of the specified FSS profiles. In this case, the terminal shall stop transmitting FSS frames and continue to use the conventional TerminalCapabilitySet, MasterSlaveDetermination,
  • a terminal detects a normal start up procedure with a normal H.245 TerminalCapabilitySet message at an agreed initial mobile level, no matter if the terminal has completed the FSS procedure, it shall consider the peer terminal has proceeded the FSS fallback. In this case, the terminal shall ignore the FSS outcome and start the conventional TerminalCapabilitySet, MasterSlaveDetermination, MultiplexEntrySend and OpenLogicalChannel procedures to establish the session.
  • a terminal If a terminal does not detect a valid FSS frame or normal start up procedure within the timer T401, it should assume that the peer terminal does not support FSS and fallback to continue normal H.324 session procedure according to Annex C. If a terminal receives an FSS Request or Response without the PPI being understood, it shall initiate the FSS fallback procedure according to the descriptions in this section. If audio and video coding processes were started during transmission of the FSS Response frames, they should be reset to restart their bitstream generation.
  • Phase D Fast Session Setup phase, as specified in this specification, is inserted before the level setup procedure. If FSS is completed successfully, H.245 message exchange is skipped and logical channels operate immediately. If FSS fallback occurs, the connection continues from initial mobile level setup phase.
  • Adaptation layer support per data type. The field is already covered within multiplex capability profile. 2. Media direction capability.
  • adaptation layer support the settings are used to influence the final logical channels to be opened between two connecting terminals.
  • the adaptation layer support follows the following order of preference for each media type:
  • Video over AL2 is the preference, and is selected if the peer terminal can also support it.
  • AL 1 framed or unframed depending on the media type. For all audio and video data types over AL 1, AL 1 shall be set to use framed mode.
  • AL3 with 7-bit sequence number.
  • Send buffer size is set to the recommended value as specified by the appropriate recommendation.
  • Use of optional retransmission mode is left to the implementers.
  • Determination of the final logical channels to be opened follows normal open logical channel request, which could involve one or more request re-proposals and/or response counter-offers.
  • the final decision is the outcome for the predefined profile approach.
  • the decision is calculated from the media direction capability with adaptation layer support and further information on the media direction mode to determine the final media mode settings.
  • the predicted media modes determined from all combinations of requests should be unique.
  • either one or more re -proposals of the request may be performed as described in the Request Re- Proposal Procedure sections or the Interworking Request Re-Proposal Procedure section, or FSS fallback is used, as described in the Fast Session Setup Fallback Procedure Specification Section. It will be noted that when a predictable conflict occurs, the master terminal looks at its preferred media list first to work out the final media to open.
  • MDI Media Direction Index
  • transmitMode refers to the use of unidirectional logical channel.
  • A3 adaptation layer 3
  • transmitAndReceiveMode refers to the use of bidirectional logical channel. This is independent of the adaptation layer type to be used.
  • noTransmitMode refers to the possible use of unidirectional logical channel for incoming media direction. It will not start any logical channel for any direction unless signaled by the remote.
  • a terminal may operate in one or more modes of operation for a given channel.
  • a channel may operate in different modes for transmit and receive. That is, a channel may transmit media in a first mode and receive media in a second mode (i.e., noTransmitMode).
  • the modes are symmetric, being the same for both transmit and receive.
  • this exemplary terminal would result in an asymmetric session transmitting MPEG-4 media and receiving H.263 media.
  • the peer terminal would provide matching video profiles in its FSS Request: transmit H.263 and receive MPEG-4.
  • FIG. 31 An embodiment of the present invention is illustrated in FIG. 31, where the Equipment Preferred modes (Custom Request and Response messages shown in FIG. 31) are transmitted on the bearer channel.
  • the Equipment Preferred modes can be similar to that described in the AnswerFast3 embodiment section above and can be an explicit description of preferred modes or a coded (index for look-up in a table of common modes).
  • FIG. 23 is a simplified diagram illustrating AnswerFast4 according to another embodiment of the present invention.
  • inference or a preference rule set is used at each terminal and the optional response message is not required to be sent before media transmission may begin.
  • FIG. 25 is a simplified diagram illustrating a method of AnswerFast4 according to an embodiment of the present invention with media transmitted in AnswerFast4 frames.
  • the terminal After sending an AnswerFast4 Request and optionally detecting an AnswerFast4 Response, the terminal will begin a normal session using the agreed mobile level. Audio and video exchange will also start immediately if they have not been started during the AnswerFast4 Response stage if in use. Utilizing embodiments of the present invention, audio and video exchange are enabled to continue seamlessly if they have been started during the AnswerFast4 Response stage whether used or not.
  • Embodiments of the present invention provide the complete ASN.1 syntax script used for Fast Session Setup Procedure used in embodiments of the present invention.
  • FastSessionSetupPredefinedRequest SEQUENCE ( version INTEGER (1..7), h245version INTEGER (1..31), vendorld NonStandardldentifier OPTIONAL, terminalType INTEGER (0..255), -- For
  • OPTIONAL capabilityProfile INTEGER (0..65535) OPTIONAL, audioProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL, videoProfiles SET SIZE (1..65535) OF INTEGER (0_.65535) OPTIONAL, dataApplicationProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL, encryptionProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL, additionalParameters OCTET STRING OPTIONAL, mediaTunnel BOOLEAN, modeDetermination CHOICE
  • FastSessionSetupExplicitRequest SEQUENCE ⁇ version INTEGER (1..7), h245version INTEGER (1..31), vendorld NonStandardldentifier OPTIONAL, terminalType INTEGER (0..255), -- For MasterSlaveDetermination initialMobileLevel INTEGER (0..7), -- [4,7] are reserved h223Info SEQUENCE
  • ⁇ version INTEGER (1. .7), h245version INTEGER (1. .31), vendorld NonStandardldentifier OPTIONAL, terminalType INTEGER (0. .255), -- For MasterSlaveDetermination mobileLevel INTEGER (0..7), -- [4,7] are reserved h223Info SEQUENCE ⁇ h223AnnexADoubleFlag BOOLEAN, h223AnnexBOptionalHeader BOOLEAN, multiplexEntrySend MultiplexEntrySend OPTIONAL, ⁇ OPTIONAL, multiplexCapability MultiplexCapability OPTIONAL, openLogicalChannels SET SIZE (1..65535) OF OpenLogicalChannel OPTIONAL, additionalParameters OCTET STRING OPTIONAL, ⁇
  • AnswerFast4 Example Embodiment using interleaving conventional flags and media [0446] A conventional method for establishing communications between two terminals is provided below.
  • Entity A (or terminal) transmits mobile level flags only; repeated until detection occurs;
  • Entity B (or terminal) transmits mobile level flags only; repeated until detection occurs;
  • Entity A detects mobile level flags from Entity B; (Entity A knows both its mobile level (“ML”) and Entity B's mobile level (“ML”), completing the IMLS - Initial Mobile Level Setup) [Time at 0.5 round trip delay "RTD”];
  • Entity B detects mobile level flags from Entity A; (Entity B knows both its ML and Entity A's ML, completing IMLS) [Time at 0.5 RTD];
  • FIG. 32 illustrates an example of a conventional communication flow using mobile level detect sequences between two terminals.
  • This diagram is an example and one of ordinary skill in the art would recognize slight variations.
  • the example includes a caller and receiver, which is termed callee in this example.
  • the method illustrates entity A and entity B, which are conventional.
  • a time line is illustrated in the vertical lines from an upper region of the illustration to a lower region of the illustration.
  • entity A (or terminal) transmits mobile level flags only; repeated until detection occurs.
  • Entity B (or terminal) transmits mobile level flags only; repeated until detection occurs.
  • entity A detects mobile level flags from Entity B.
  • entity A knows both its mobile level (“ML”) and Entity B's mobile level (“ML”), completing the IMLS - Initial Mobile Level Setup. Timing for round trip delay in the method is about 0.5 RTD.
  • entity B detects mobile level flags from Entity A.
  • entity B knows both its ML and Entity A's ML, completing IMLS, which has a RTD of about 0.5.
  • the two entities begin negotiations to establish a communication connection after the IMLS is completed. An overall delay to seeing media is often worst of the two entities IMLS point. We calculate the delay to be about 0.5 RTD + Conventional setup after IMLS, as shown.
  • Entity A transmits one (or more) AnswerFast4 frames
  • Entity B transmits mobile level flags only; repeated until detection occurs;
  • Entity A detects mobile level flags from entity B [Time at 0.5 RTD];
  • Entity B ignores (i.e., assumed noise/corruption) the AnswerFast4 frames from entity A;
  • Entity A performs fallback, and begins sending mobile level flags to entity B;
  • Entity A knows both its ML and Entity B's ML, completing IMLS - Initial Mobile Level Setup) [Time at 0.5 RTD];
  • Entity B detects mobile level flags from entity A (Entity B knows both its ML and Entity A's ML, completing IMLS) [Time at 1.0 RTD];
  • FIG. 33 illustrates an example of a communication flow using the AnswerFast4 technique to establish a connection between two terminals.
  • This diagram is merely an example, which should not unduly limit the scope of the claims herein.
  • the example includes a caller and receiver, which is termed callee in this example.
  • the method illustrates entity A, which supports the AnswerFast4 call.
  • a time line is illustrated in the vertical lines from an upper region of the illustration to a lower region of the illustration.
  • entity A transmits one (or more) AnswerFast4 frames.
  • Entity B transmits mobile level flags only; repeated until detection occurs. As also shown, entity A detects mobile level flags from entity B. A round time delay is about 0.5 RTD. Entity B ignores the AnswerFast4 frames from entity A, which entity B assumes is noise/corruption and/or other artifact. Of course, depending upon the embodiment, there can be other flags inserted, combined, and removed with the AnswerFast4 frames or the like.
  • entity A detects mobile level sequences from entity B
  • entity A performs a fallback process.
  • Entity A begins sending mobile level flags to entity B.
  • entity A knows both its ML and Entity B's ML, which completes the IMLS - Initial Mobile Level Setup.
  • the round trip delay is about 0.5 RTD.
  • entity B detects mobile level flags from entity A.
  • Entity B knows both its ML and Entity A's ML, which completes the IMLS.
  • the time associated with the process is 1.0 RTD.
  • the method initiates negotiations to take place after IMLS has been completed. An overall delay to seeing media is worst of the two entities IMLS point. The delay is about 1.0 RTD + Conventional setup after IMLS.
  • a method for communicating between two terminals using an interleaved mobile level flag sequence according to an embodiment of the present invention is provided below.
  • Entity A transmits one (or more) AnswerFast4 frames to entity B;
  • Entity B transmits mobile level flags only to entity A and is often repeated until detection occurs;
  • Entity A transmits a block of mobile level flags to entity B;
  • Entity A detects mobile level flags from entity B [Time at 0.5 RTD];
  • Entity B ignores (e.g., assumed noise/corruption) the AnswerFast4 frames from entity A; 6. Entity B detects mobile level flags from entity A (Entity B knows both its ML and entity A's ML, completing IMLS - Initial Mobile Level Setup) [Time at 0.5 RTD + transmission time for custom message (could be zero for null message)];
  • Entity A detects more mobile level flags from entity B, and decides to fallback assuming other end does not support the AnswerFast4 frames (A knows both its ML and B's ML, completing EVILS) [Time at 0.5 RTD + decision time (which is implementation dependent) ];
  • interleaving mobile level need not be the same as the mobile level expressed in AnswerFast4 frames, however in some embodiments they may be the same in order to simplify the logic in that implementation.
  • the above sequence of steps provides method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these.
  • FIG. 34 illustrates an example of a communication flow using an interleaved sequence using mobile level stuffing sequences according to an embodiment of the present invention.
  • This diagram is merely an example, which should not unduly limit the scope of the claims herein.
  • AnswerFast4 request messages and mobile level flags have been interleaved according to a specific embodiment.
  • entity A transmits one (or more) AnswerFast4 frames to entity B.
  • Entity B transmits mobile level flags only to entity A and is often repeated until detection occurs.
  • Entity A transmits a block of mobile level flags to entity B.
  • Entity A detects mobile level flags from entity B.
  • a time associated with the detection of the mobile level flags from entity B to detection by entity A is about 0.5 RTD.
  • entity B ignores (e.g., assumed noise/corruption) the AnswerFast4 frames from entity A since entity B cannot support the preference mode associated with the AnswerFast4 requests.
  • Entity detects mobile level flags from entity A (since Entity B knows both its ML and entity A's ML, which completes the IMLS - Initial Mobile Level Setup).
  • a round trip delay is 0.5 RTD + transmission time for custom message (could be zero for null message).
  • Entity A detects more mobile level flags from entity B, and decides to fallback assuming other end does not support AnswerFast4.
  • entity A knows both its ML and entity B's ML, which completes the IMLS.
  • a round trip delay is 0.5 RTD + decision time (implementation dependent) according to a specific embodiment. As shown, the method initiates negotiations to take place after IMLS completed. An overall delay to seeing media is worst of the two entities EVILS point. That is, the delay is 0.5 RTD + max (AnswerFast4 Transmit time, AnswerFast4 fallback detect time ) + Conventional setup after EVILS.
  • RTD + max AnswerFast4 Transmit time, AnswerFast4 fallback detect time
  • certain delay time may be reduced. That is, the present method and system provides for a reduced fallback time, which is often significantly less than 0.5 RTD.
  • a reduced fallback time which is often significantly less than 0.5 RTD.
  • the above sequence of steps provides method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these. Depending upon the embodiment, there can be other variations, modifications, and alternatives.
  • Entity A transmits one (or more) AnswerFast4 frames to entity B;
  • Entity B transmits one (or more) AnswerFast4 frames to entity A;
  • Entity A transmits a block of mobile level flags to entity B;
  • Entity B transmits a block of mobile level flags to entity A;
  • Entity A detects the AnswerFast4 frames from entity B (while mobile level flags are ignored) [Time at 0.5 RTD];
  • Entity B detects the AnswerFast4 frames from entity A (while the mobile level flags are ignored) [Time at 0.5 RTD];
  • the above sequence of steps provides method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these. Depending upon the embodiment, there can be other variations, modifications, and alternatives.
  • the media transmitted before receiving an indication from the other side in a tunneled fashion arriving at a time around 0.5 RTD would preferably be selected from a profile of expected configurations/pre-configurations.
  • Media sent on these configured/preconfigured profiles/channels could then be of several limited types that are expected and more likely to result in an established session and a very fast channel set up.
  • the media need to be tunneled, but by tunneling/encapsulating the media with certain preference information the media upon reception is known to be decodable (by the receiver, if it is acceptable) and also if it is the only acceptable type coming in (so that if more than one type is to be received then a best can then be selected if the preferences are known). Also, concurrency of preference information and preferences removes the need to have buffering at the receiver on a channel whilst the preference information arrives.
  • the media transmitted in the tunneled fashion may also not be in a profile, and instead just be transmitted in a most preferred mode by the transmitter, this allows for greater feature expression by the transmitter but may result in a higher chance of failure.
  • Feature removal based on the preferences of a peer may be applied to bring the transmissions into line with the acceptable transmissions, however if the receiver could not decode its initial pre-negotiation media then the benefit of sending the pre- negotiation media is not achieved.
  • FIG. 35 illustrates an example of an alternative example of a communication flow using an interleaved sequence using mobile level stuffing sequences according to an alternative embodiment of the present invention.
  • This diagram is merely an example, which should not unduly limit the scope of the claims herein.
  • An alternative method for communicating between two terminals using an interleaved mobile level flag sequence is provided below. As shown, entity A transmits one (or more) AnswerFast4 frames to entity B. Entity B transmits one (or more) AnswerFast4 frames to entity A. [0465] Next, certain mobile level flags are interleaved into the sequence.
  • entity A transmits a block of mobile level flags to entity B and entity B transmits a block of mobile level flags to entity A.
  • entity B transmits a block of mobile level flags to entity A.
  • each of the entities can support the AnswerFast4 frames.
  • Entity A detects the AnswerFast4 frames from entity B (while mobile level flags are ignored) [Time at 0.5 RTD].
  • Entity B detects the AnswerFast4 frames from entity A (while the mobile level flags are ignored) [Time at 0.5 RTD].
  • Each entity acts on the AnswerFast4 preferences using the AnswerFast4 preferences to establish an initial mode of operations for each of the entities.
  • no conventional negotiations take place according to a specific embodiment.
  • an overall delay to seeing media is worst of the two entities IMLS point. That is, round trip delay is 0.5 RTD with media sent in the AnswerFast4 message and 1.0 RTD with media not sent until after mode determination.
  • round trip delay is 0.5 RTD with media sent in the AnswerFast4 message and 1.0 RTD with media not sent until after mode determination.
  • round trip delay is 0.5 RTD with media sent in the AnswerFast4 message and 1.0
  • the above sequence of steps provides a method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these. Depending upon the embodiment, there can be other variations, modifications, and alternatives.
  • Entity A transmits one (or more) AnswerFast4 frames to entity B comprising media;
  • Entity B transmits one (or more) AnswerFast4 frames to entity A comprising media;
  • Entity A transmits a block of mobile level flags to entity B;
  • Entity B transmits a block of mobile level flags to entity A;
  • Entity A detects the AnswerFast4 frames from entity B and the media (while mobile level flags are ignored) [Time at 0.5 RTD];
  • Entity B detects the AnswerFast4 frames from entity A and the media (while the mobile level flags are ignored) [Time at 0.5 RTD];
  • An overall delay to seeing acceptable media is the worst of the two entities IMLS point [0.5 RTD if tunneled media is acceptable to receiver, 1.0 RTD if tunneled media is not acceptable to the receiver];
  • the above sequence of steps provides a method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these. Depending upon the embodiment, there can be other variations, modifications, and alternatives.
  • FIG. 36 illustrates an example of an alternative example of a communication flow using an interleaved sequence including media using mobile level stuffing sequences according to an alternative embodiment of the present invention.
  • This diagram is merely an example, which should not unduly limit the scope of the claims herein.
  • An alternative method for communicating between two terminals using an interleaved mobile level flag sequence is provided below.
  • entity A transmits one (or more) AnswerFast4 frames to entity B comprising media.
  • Entity B transmits one (or more) AnswerFast4 frames to entity A comprising media.
  • entity A transmits a block of mobile level flags to entity B and entity B transmits a block of mobile level flags to entity A.
  • entity B transmits a block of mobile level flags to entity A.
  • each of the entities can support the AnswerFast4 frames with media.
  • Entity A detects the AnswerFast4 frames from entity B (while mobile level flags are ignored) [Time at 0.5 RTD].
  • Entity B detects the AnswerFast4 frames from entity A (while the mobile level flags are ignored) [Time at 0.5 RTD].
  • Each entity acts on the AnswerFast4 preferences using the AnswerFast4 preferences and the media, if it is acceptable to the receiver, to establish an initial mode of operations for each of the entities.
  • no conventional negotiations take place according to a specific embodiment.
  • an overall delay to seeing media is worst of the two entities IMLS point. That is, round trip delay is 0.5 RTD.
  • round trip delay is 0.5 RTD.
  • the above sequence of steps provides a method according to an embodiment of the present invention.
  • the method uses a combination of steps including a way of establishing communications between two terminals using an interleaved mobile level detection technique according to a specific embodiment.
  • the present method establishes communications using a desired preference mode of operation in a faster manner than conventional techniques.
  • steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.
  • the various steps can be implemented using a computer code or codes in software, firmware, hardware, or any combination of these. Depending upon the embodiment, there can be other variations, modifications, and alternatives.
  • the FSS procedure for reducing session setup time is simplified, retaining the ability to expand it in the future.
  • the establishment of a typical videotelephony session between two H.324M terminals requires the completion of several procedures such as mobile level detection and H.245 messaging.
  • the introduction of faster session setup techniques into H.324 will make setup times consistent with similar protocols (H.323 and SIP) and will significantly enhance the user experience.
  • a Bearer-based FSS procedure is provided.
  • Embodiments of the present invention provide the FSS procedure as an alternative procedure for establishing an audio and video communication session in H.324.
  • a terminal transmits the preferred operation mode as the first bits on the bearer channel. These bits are prevented from emulating existing mobile level flags, including the base-line H.324 mode, so they are ignored by existing terminals, maintaining interoperability.
  • the procedure allows significant reduction of the session setup time.
  • ICM inferred common mode
  • NMLO normal mobile level operation
  • the FSS procedure is made in the following steps: (1) FSS Phase; (2) Media Exchange Phase.
  • a terminal may interrupt the FSS Phase by transmitting standard mobile level sequence flags and continue with normal level setup procedure.
  • the FSS frames are octet aligned and have the structure shown in Table 13.
  • Payload (0 or more octets up to 150 octets)
  • Table 13 H.324 - Structure of the Fast Session Setup frames.
  • the Frame Information (FI) bit allocation is shown in Table 14. Bit 8 is reserved and shall be set to 1. Bit 7 represents the Last Segment (LS) flag, and the three following bits represent the Segment Sequence Number (SSN). The three least significant bits are reserved and shall be set to 0. The use of LS and SSN are specified in the PSR procedure.
  • the Payload Length (PL) field indicates the payload size in octets before the application of the Frame Emulation Avoidance (FEA) procedure.
  • the FSS frame payload (FSS-PDU) shall not exceed 150 octets.
  • the receiver shall support overall FSS-MDU payload length of up to 1050 octets excluding octets inserted during FEA.
  • the Payload corresponds to an H.245 genericRequest message as defined in "Object Identifier Assignment for Fast Session Setup Procedure," which is encoded according to Packed Encoding Rules (PER) as defined in ITU-T Rec. X.691.
  • PER Packed Encoding Rules
  • the CRC (cyclic redundancy check) field is 16 bits and is determined by applying the CRC described in 8.1.1.6.1/V.42 to the entire frame, excluding the FSS Synchronization Flags and before FEA. On detecting a CRC error, the corresponding FSS frame shall be discarded.
  • the FSS Synchronization Flag is defined as shown in Table 15.
  • FSS Synchronization Flag shall be inserted immediately before and after each FSS Frame. Only one FSS Synchronization Flag shall exist between two consecutive FSS Frames.
  • FSS LS flag shall be used in place of CCSRL LS.
  • LS shall be set to 1 on the FSS-PDU containing the last segment of an FSS-MDU. It shall be set to 0 otherwise.
  • the SSN shall be set to 0 for the first segment and monotonically incremented for each segment, the maximum value of SSN shall be 6. The value 7 is reserved.
  • an FEA procedure Before transmitting an FSS frame onto the bearer, an FEA procedure shall be performed against synchronization flags for all mobile levels of H.324. Frame Information, Sequence Number, Payload Length, Payload and CRC are included in the FEA procedure. All octets with values 0xA3, 0x35, OxEl, 0x4D, OxIE, 0xB2, 0x19, OxBl and 0xC5 shall be duplicated by inserting adjacently an octet with the same value. The value 0x7E shall have inserted adjacently an octet with the value 0xC5.
  • a terminal may transmit up to 10 stuffing sequences of its highest supported mobile level, as described in C.6.1/H.324, between FSS Frames. For mobile level 0, up to 20 flags may be inserted.
  • a terminal if a terminal supports FSS, it shall immediately send an FSS Request frame. The frame should be repeated until an FSS Request frame is detected, or one of the conditions in "Fast Session Setup Fallback Procedure Specification" is fulfilled. For the latter case, the procedure in the "Fast Session Setup Fallback Procedure Specification" shall be followed.
  • the terminal accepts it by beginning the exchange and processing of media data as determined by the ICM at NMLO using the agreed mobile level.
  • Logical Channel Numbers are assigned by the message originator in H.245 OpenLogicalChannel request messages contained in mediaProfile. For the case of bidirectional logical channels, the reverse logical channel number shall be the same as the forward logical channel number.
  • Logical channels having symmetric codec capability shall include H.245 OpenLogicalChannel request message with reverseLogicalChannelParameters of the same dataType with the same logical channel number.
  • the logical channel number shall be mapped to H.223 multiplex entry index. For example, if logical channel 1 is opened, multiplex entry index 1 will be associated to this logical channel as "(LCNl, RC UCF ⁇ ". For reverse logical channels, the logical channel number shall be mapped to multiplex entry index at the H.223 demultiplexer.
  • a fallback procedure shall be used by a FSS terminal to switch to normal operation mode. During fallback, a terminal shall stop transmitting FSS frames, ignore the FSS outcome and continue using normal start up procedures. The following conditions shall initiate fallback:
  • a normal start up procedure with a normal H.245 TerminalCapabilitySet message as the first non-empty H.223 MUX-PDU at an agreed initial mobile level is detected, regardless of whether the terminal has completed the FSS procedure.
  • Phase D Fast Session Setup phase, as specified herein, is inserted before the level setup procedure. If FSS is completed successfully, H.245 message exchange is skipped and opened logical channels operate immediately. If FSS fallback occurs, the connection continues from initial mobile level setup phase.
  • Terminal type as defined in 7.4/H.324.
  • First octet indicates initial mobile level.
  • Second octet MSB indicates using H.223 Annex A double flag mode; next bit indicates using H.223 Annex B optional header mode; other bits are reserved and shall be set to 0. Other octets shall be ignored.
  • H.245 OpenLogicaIChannels specifying media channel preferences.
  • Other H.245 ASN.l structures may be appended such as Userlnputlndication.
  • Embodiments of the present invention provide methods and systems that serve as additions to existing standards.
  • FSS/MOS procedures are inserted before, or concurrently with, the conventional level setup procedure. If the FSS/MOS procedure is completed successfully, H.245 message exchange may be skipped and opened logical channels operate immediately. If FSS fallback occurs, the connection continues from the level setup procedure.
  • a procedure for establishing a call includes, once the bearer is established, if a terminal supports FSS, sometimes referred to as the Signaling Preconfigured Channel (SPC), the terminal will send its FSS Request.
  • the FSS Request which may also be referred to as a Media Oriented Setup (MOS) request, is sent immediately. Then Request transmissions will typically be repeated until an FSS Request is detected, or one of the conditions for fallback is fulfilled (where the fallback procedures arefollowed).
  • the FSS (or MOS) Capability Identifier is defined as shown in Table 16.
  • the terminal accepts it by beginning the transmission and processing of media data as determined by the ICM at NMLO using the agreed mobile level.
  • a MOS requestAck shall be sent on receiving every MOS Request.
  • the caller when the terminalType fields in the FSS Request of the two terminals are identical, the caller shall be the master. When the terminalType fields differ, the terminal which has higher terminalType value shall be the master. When the terminalType fields in the MOS Request of the two terminals are identical, and the two terminals have different values of caller field, the caller shall be the master. If the caller fields are identical, the terminalType and statusDeterminationNumber fields in the MOS Request of the two terminals are used according to the Master-slave determination procedure in C.2/H.245 and in an inferred manner without additional H.245 signaling. Generally, unexpected FSS-SDUs shall be discarded.
  • a terminal indicates its requested logical channels by listing H.245 OpenLogicalChannel (OLC) requests according to an order of preference in mediaProfile. The requests shall be processed in the same order.
  • Logical channel numbers (LCNs) are assigned by the message originator. OLC requests with the same LCN indicate alternative media capabilities for the logical channel.
  • Terminal capability sets for both terminals are inferred from the combination of mediaProfiles from local and remote.
  • Multiple OpenLogicalChannel entries with the same LCN correspond to a series of alternative capability descriptor entry; OpenLogicalChannels with different LCNs correspond to simultaneous capability descriptor entries.
  • the capability direction is set to receive capability (e.g. receiveVideoCapability, receiveAudioCapability) unless symmetric is set, where the capability direction is set to receive and transmit capability (e.g. receiveAndTransmitVideoCapability, receiveAndTransmitAudioCapability).
  • the set of capability descriptors is derived with the same order of preference as the order in mediaProfile, and includes by default an instance of each logical channel type.
  • the remote terminal is assumed to support all adaptation layers (ALl, AL2 and AL3) for all media categories (audio, video and data).
  • ALl, AL2 and AL3 adaptation layers
  • Other settings in the TerminalCapabilitySet adopt the corresponding recommended values specified in 3GPP TR 26.1 10, H.324, H.245 and H.223.
  • Codecs are selected in the same way as normal H.245 message exchanges, deduced according to capability preferences and media mode conflict resolution as in B.2.2.2/H.324 and C.4.1.3/H.324. Channels are considered open following the computation of the inferred mode.
  • the peer's channel is selected by reversing the TCS inputs to the selection algorithm.
  • An example of ICM is illustrated in Table 17, which illustrates an example that does not have symmetric codecs set.
  • each entity selects media channels most preferred for reception by its peer entity. Both entities prefer AMR. Entity A prefers to receive MPEG4- Video while entity B prefers to receive H.263.
  • Table 18 illustrates another example of ICM in which symmetric codecs are set.
  • each entity selects media channels most preferred for reception by its peer entity. Both entities prefer AMR. Entity A prefers to receive MPEG4-Video while entity B uses MPEG4-Video in symmetry to the master.
  • the reverse LCN shall be the same as the forward LCN.
  • Terminal A desires Audio OLC on 1 and Video bidirectional on 2 (forward and reverse, which will dominate) and Terminal B desires Audio OLC on 1 and Video is OLC on 3 (irrelevant for this example though)
  • the result is:
  • Terminal A transmits audio on 1
  • Terminal B transmits audio on 1
  • Terminal A transmits video on 2
  • Terminal B transmits video on 2
  • the channel numbers eventuated upon is assigned by the message originator.
  • Terminal A desires Audio OLC on 1 and Video bidirectional on 2 (forward and reverse, which will dominate) and Terminal B desires Video is OLC on 1 (irrelevant for this example though) and Audio OLC on 2.
  • the audio channel from 2 will clash with the video logical channel number desired in the reverse direction of the bidirectional request.
  • Terminal A transmits audio on 1
  • Terminal B transmits audio on 2
  • Terminal A transmits video on 2 (with reverse on 3)
  • Terminal B transmits video on 3 (using reverse of Terminal A),
  • the highest LCN shall be 14, and any OLC requests that lead to LCN exceeding 14 shall be ignored. In other embodiments, the highest LCN shall be 13, and any OLC requests that lead to LCN exceeding 13 shall be ignored. If ICM contains an H.223 adaptation layer type not supported by a terminal, the terminal shall fallback.
  • a method of making a master-slave determination during a call setup procedure between a call between a pair of H.324-like terminals coupled to a telecommunications network includes transmitting a first set of parameters from the first terminal to the second terminal.
  • the first set of parameters includes at least a first terminalType field, a first caller field, and a first statusDeterminationNumber field.
  • transmitting the first set of parameters is performed prior to transmitting an H.245 message from the first terminal the second terminal.
  • the first set of parameters may be included in a preference message transmitted directly on a bearer.
  • the method also includes receiving a second terminalType field transmitted from the second terminal to the first terminal.
  • the second set of parameters includes at least a second terminalType field, a second caller field, and a second statusDeterminationNumber field.
  • the method further includes utilizing an inference algorithm to make the master-slave determination.
  • the inference algorithm includes defining the first terminal as a master terminal if a value of the first terminalType field is greater than a value of the second terminalType field and defining the second terminal as the master terminal if the value of the first terminalType field is less than the value of the second terminalType field.
  • the inference algorithm includes defining the first terminal as the master terminal if the first caller field indicates that the first terminal is the caller and the second caller field indicates that the second terminal is not the caller and defining the second terminal as the master terminal if the second caller field indicates that the second terminal is the caller and the first caller field indicates that the first terminal is not the caller.
  • the inference algorithm further includes defining the first terminal as the master terminal if the first statusDeterminationNumber is greater than the second statusDeterminationNumber and defining the second terminal as the master terminal if the first statusDeterminationNumber is less than the second statusDeterminationNumber.
  • the process of making the master-slave determination is performed without transmitting an acknowledgement message from the first terminal to the second terminal indicating the master-slave determination.
  • the acknowledgement message may include a MasterSlaveDetermination Ack message.
  • the pair of H.324-like terminals may include a 3G-324M terminal, for example, a 3G-
  • the logical channel number shall be mapped to H.223 multiplex entry index. For example, if logical channel 1 is opened, multiplex entry index 1 will be associated to this logical channel as "(LCNl, RC UCF ⁇ ". For a reverse logical channel, the logical channel number shall be mapped to multiplex entry index at the H.223 demultiplexer.
  • Explicit multiplex table entries may be set using additionallnfo parameter. Alternate multiplex entries may be signaled similarly as assigning LCNs for alternative media capabilities. It should be noted that outgoing LCNs specified in explicit multiplex table entries for transmission are not expected to be changed. Additionally, it should be noted that for alternative logical channels of ⁇ AMR, G.723.1 ⁇ with LCN 3 and ⁇ H.263, H.261 ⁇ with LCN 2, additional multiplex entries may be set as follows:
  • Index 5 (empty); Index 5: ⁇ LC 3, RC 22 ⁇ , ⁇ LC2, RC UCF)
  • a fallback procedure is used by a terminal to switch to an alternate phase of normal operation mode. Fallback in some embodiments may be further caused under the additional conditions shall also initiate a fallback from MOS:
  • RTD network round trip delay
  • a terminal will stop transmitting FSS frames, ignore the FSS outcome, and follow normal start up procedures as defined in H.324 Annex C.
  • a number of conditions may initiate fallback. For example, detecting more than 20 valid consecutive mobile level stuffing flags as described in C.6/H.324 will result in initiation of a fallback procedure.
  • a normal start up procedure with detection of a normal H.245 TerminalCapabilitySet message as the first non-empty H.223 MUX-PDU at an agreed initial mobile level before completion of the FSS procedure, or a normal H.245 TerminalCapabilitySet message with empty genericControlCapability containing FSS (DID after completion of the FSS procedure will result in initiation of a fallback procedure.
  • FIG. 37 is a simplified diagram illustrating a fallback procedure according to an embodiment of the present invention.
  • FIG. 38 and FIG. 39 provide a listing of FSS/MOS parameters utilized in embodiments of the present invention.
  • Embodiments of the present invention also utilize the MOS Ack Capability Identifier and the MOS Ack Parameter - requestAck as defined in H.324 Annex K.
  • FIG. 24 is a simplified illustration of the structure of an AnswerFast4 frame according to an embodiment of the present invention.
  • the AnswerFast4 request and response frames are octet aligned. Accordingly, AnswerFast4 message transmissions are octet aligned, allowing for compatibility with conventional transmissions of other mobile levels.
  • the Frame Information (FI) bit allocation is shown in Table 19. Bit 8 is reserved and shall be set to 1. Bit 7 represents the Last Segment (LS) flag, and the three following bits represent the Segment Sequence Number (SSN). The three least significant bits are reserved and shall be set to 0. The use of LS and SSN are specified in the section on the Payload Segmentation and Reassembly (PSR) Procedure.
  • PSR Payload Segmentation and Reassembly
  • the FI field of the AnswerFast4 frame has the values shown in Table20:
  • the payload length field indicates the payload size before applying emulation insertion octets.
  • the messages can be optimized for size by use of a payload present indicator, that if not present would leave the message at a minimum size. If payload were present, a payload present indicator, a payload length and a payload would all be included in the message.
  • the payload can be of any length.
  • the frame information is configured to limit the payload to 150 octets, as in many networks, frames are transmitted and processed in 160 octets time-slots.
  • the payload length will be varied as appropriate to the particular applications.
  • the messages can also be used for differing purposes depending on certain values in a header field. Different message types, such as Request, Response or Command and Indication, or media could be indicated. Also, sequence numbers or segment indicators could also be used for error resiliency and protocol use.
  • the Payload corresponds to an FSS-SDU or an FSS-SDU segment.
  • FSS-SDU corresponds to an H.245 genericRequest message (using GenericMessage) as defined more fully in FIG. 38 and FIG. 39, and is encoded as H.245 MultimediaSystemControlMessage according to Tacked Encoding Rules (PER) as defined in ITU-T Rec. X.691.
  • the Cyclic Redundancy Check (CRC) field is 16 bits in length and is determined by applying a CRC to the entire frame excluding the AnswerFast4 Sync Flags.
  • the CRC is as described in accordance with 8.1.1.6.1/V.42.
  • the corresponding FSS frame will be discarded.
  • Error detection or error correction can be added to AnswerFast4 messages if desired. Error correction could be used with a Forward Error Correction code similar to those already used in H.324 for higher multiplexer levels and a modification to the message allowing transmission of the required information. Error detection could be implemented using a cyclic redundancy check. The CRC value could be transmitted in the message in a specified field.
  • Multiplexer synchronization flag emulation protection may be performed on AnswerFast frames to ensure the entire message appears as noise and/or unwanted data on the bearer. This ensures that any transmissions are not misinterpreted by legacy devices as conventional transmissions such as level detect. It also affords the ability to invisibly transmit AnswerFast4 messages during a session through another legacy device, such as a gateway, that may be capable of intercepting legacy transmissions.
  • an emulation insertion procedure is performed before sending the frame to the bearer.
  • the fields with Payload Length, Payload, and CRC are applied with an emulation insertion procedure.
  • all octets with values 0xA3, 0x35, OxEl, 0x4D, 0x19, OxBl and 0x7E are duplicated by 1 octet with the same value.
  • Response message is optional, and can be used as a confirmation in some situations, for example, if a terminal such as a gateway prefers to confirm the media codec selections prior to proceeding with a session.
  • a terminal such as a gateway prefers to confirm the media codec selections prior to proceeding with a session.
  • Another situation in which a Response is used is if the AnswerFast4 Request contains some application specific information request, for example, an encryption key.
  • H.245 preferences e.g. expressed by TCS, OLCs, and the like
  • codecs may be selected in the same way as normal H.245 message exchanges except that transactions are conducted implicitly till the final outcome.
  • This technique forms an ICM and it may be deduced according to capability preferences and media mode conflict resolution as specified in B.2.2.2 and C.4.1.3 in H.245.
  • the ICM provides methods and techniques in which a unique non-conflicting media mode is determined by both terminals based on media preferences contained in a local profile request and a peer profile request.
  • the media preferences contained in the local profile request and the peer profile request are the same for both terminals.
  • 0x0100 could be selected by a rule using a highest index rule.
  • One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • a terminal detects an AnswerFast4 Request message, it can determine configurations (media/data/multiplexer modes) for both itself and the remote device according to the preferences received and the preferences it will transmit or has transmitted.
  • the determination of configuration can be made from the input/presence of the AnswerFast4 message and a set of predefined rules. These rules may be predefined or predetermined based on some input, or may be simple rules based on explicit messages. Rules may, or may not, re-use rules that already exist in a device presently, such as H.245 most preferred mode.
  • the AnswerFast4 Sync Flag is defined as illustrated in Table 21.
  • An AnswerFast4 synchronization flag may be selected to ensure that it is not interpreted as a conventional message, but instead appears as noise/ignorable data to a conventional terminal.
  • one AnswerFast4 Synchronization Flag is inserted immediately before and after each AnswerFast4 Frame. Generally, only one AnswerFast4 Synchronization Flag will exist in between two consecutive AnswerFast4 Frames.
  • This procedure is identical to Command and Control Segmentation and Reassembly Layer (CCSRL) procedure in C.8.1/H.324 with the following modifications.
  • the FSS LS flag shall be used in place of CCSRL LS.
  • LS shall be set to 1 on the FSS-PDU containing the last segment of an FSS-SDU. It shall be set to 0 otherwise.
  • the SSN shall be set to 0 for the first segment and monotonically incremented for each segment, the maximum value of SSN shall be 6. The value 7 is reserved.
  • an FEA procedure Before transmitting an FSS frame onto the bearer, an FEA procedure shall be performed against synchronization flags for all mobile levels of H.324. Frame Information, Segment Sequence Number, Payload Length, Payload and CRC are included in the FEA procedure. All octets with values 0xA3, 0x35, OxEl, 0x4D, OxIE, 0xB2, 0x19, OxBl, 0x7E, and 0xC5 shall have an octet with value 0xC5 inserted immediately preceding them.
  • a terminal should insert stuffing flags of its mobile level, as described in C.6.1/H.324, between FSS Frames separated by one FSS Synchronization Flag. No more than 10 flags shall be inserted. For mobile level 0, no more than 20 flags shall be inserted. A terminal should also insert minimum stuffing flags in between MUX-PDUs until a non-stuffing MUX-PDU is detected.
  • Embodiment in the Context of a H.324/H.323 Gateway [0581] A further embodiment demonstrating use with a gateway to an H.323 terminal using "FastConnect" is illustrated by FIG. 40. These embodiments offer a maximum reduction in call set up time. These embodiments eliminate all round trip exchange for H.245 messages and, for the H.324 call segment, initial mobile level detection.
  • Embodiment in the Context of a H.324/SIP Gateway [0583] The embodiment in this context is similar to that of the H.324/H.323 gateway with the exception that the gateway converts the information (AnswerFastl, 2, 3 and/or 4) to SIP signaling messages.
  • the 3G modem may contribute to significant increases in the call set up time. Therefore, the operation and interaction of the modem with the call/session set up phase is an area of interest. Merely by way of example, areas in which potential optimization is available include:
  • the receiver and transmitter sides may be in separate threads.
  • the thread priority should preferably be set to as high as possible to maintain continuous data flow at the communication bearer.
  • Embodiments of the present invention minimize the time to ready media processors, which is potentially noticeable, by initializing media input/output (e.g., audio and video) as soon as possible.
  • the optimal time is when a call is going to be made. From the perspective of a caller, this refers to the time when the call button is pressed. From the perspective of an answerer, this refers to the time when the RING tone is detected.
  • Media processors including audio and video media processors, are provided, one for frame capturing and encoding, and one for decoding and playback.
  • encoders and decoders are made available and ready before the start of AnswerFast procedures.
  • This process is referred to as codec initialization and is applicable to both audio and video.
  • This embodiment has less relevance to system performance when the initialization time is negligible.
  • encoders and decoders can be instantiated as soon as the inferred common mode is available, thus allowing time to ready the encoders and decoders as quickly as possible after that event.
  • Embodiments of the present invention provide for session preparation, in which media devices are initialized and placed in a ready state before the bearer is established. For some applications, optimization may need to be performed to achieve the desired session preparation.
  • These media devices include, but are not limited to:
  • Video capture/camera including self-view if applicable and associated codecs
  • Video display and associated codecs
  • the AnswerFast messaging system has a range of flexibility both in application and implementation.
  • the information transmission and any rules can cover any configurations desired, and the fully configurable session can be set up in significantly faster time than is available through conventional set up procedures. It is possible to reduce the complexity of rules and implementations by placing certain limitations on the kinds of flexibility available.
  • Primitive versions of the AnswerFast transmissions could be used that are less configurable and flexible, but still yield many advantages. The advantages may be leveraged best in a setting were many homogenous devices, or devices with homogenous characteristics (e.g., the same codecs) are interoperating. In this setting, several assumptions may be made about the expected decisions of the remote device, and in the majority of cases, these assumptions would be confirmed correct. This can give a statistical gain in the performance of the devices, as the number of times an assumption is confirmed would far outweigh the times it is incorrect, which would typically result in a corrective negotiation.
  • networks that support the H.324M standard for mobile multimedia telephony may use a number of available session setup schemes. These schemes differ in the speed of the session setup and the flexibility and reliability offered to the terminal and the network. Flexibility refers to the ability of service providers to provide the media in a differentiated way without having to define these new formats as part of the default formats supported by the network. Reliability refers to the confidence in successfully establishing a session. Some session setup methods can be considered lossless in that acknowledgments are mandatory on the communicating devices, while others can be considered highly reliable because of the repetition of messages and other techniques.
  • any terminal may support AnswerFast3 and another terminal may support AnswerFast 1/2/4. Both terminals should be able to operate at their common support type (i.e. in this case AnswerFast2) as if the calling terminal would not receive the AnswerFast3 response in the call signaling phase.
  • the general mode is that terminals fall back to the highest common mode and within that mode to the highest supported version.
  • AnswerFast3 and then AnswerFast4 and then AnswerFast2 and then AnswerFastl and then a standard mode of operation can be performed.
  • any combination of these types depending upon the application can also be performed according to specific embodiments.
  • AnswerFast2 may be performed if AnswerFast3 fails or is not supported.
  • AnswerFastl may be performed if AnswerFast2 fails or is not supported.
  • AnswerFastSRP may be continued to be used in the case either or both AnswerFastl and AnswerFast2 are not accepted. Any practical combination of these may be used depending upon a level of support for each of the terminals according to a specific embodiment. In general, however, techniques using the call signaling process for embedding messages for the initial mode of operation may be performed before those techniques using processes after call signaling has been established. Of course, one of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • embodiments of the present invention provide methods and system to support fallback procedures when the called H.324 entity does not support one or more of the AnswerFast methods. For example, if a calling terminal begins a call using AnswerFast3, and the called terminal does not support AnswerFast3, the calling terminal will fallback using the following procedures:
  • terminal configurations are utilized to take advantage of the benefits provided by AnswerFast technologies.
  • embodiments of the present invention utilize SRP extensions (i.e., frame parallel transmission) to provide several benefits.
  • SRP extension techniques more fully described in U.S. Patent Application No. 10/732,917, previously referenced, could be used in conjunction with the H.245 techniques described herein with respect to
  • AnswerFast2 may be performed if AnswerFast3 fails or is not supported.
  • AnswerFastl may be performed if AnswerFast2 fails or is not supported. Any practical combination of these may be used depending upon a level of support for each of the terminals according to a specific embodiment. In general, however, techniques using the call signaling process for embedding messages for the initial mode of operation may be performed before those techniques using processes after call signaling has been established. Of course, one of ordinary skill in the art would recognize many variations, modifications, and alternatives.
  • FIG. 41 illustrates a hierarchy based on time of execution in a call.
  • the hierarchy can also represent a fallback strategy when one technique fails entirely.
  • the hierarchy can similarly represent a refinement/augmentation strategy when an earlier technique does not provide a session with the completely desired characteristics. In this case, a result from the earlier session might be retained, refined or augmented. For example, mobile level selected earlier might be retained, media channels might be refined, or additional media channels might be added.
  • the hierarchy need not be limited to only AnswerFast techniques presently described, many variants exist in the scope of the present invention.
  • FIG. 42 and FIG. 43 show session refinement mechanism whereby characteristics of a session achieved by an initial session setup method are further refined, redefined or augmented according to a second, or additional session setup method, which is preferably an AnswerFast mechanism to ensure speed of session establishment is minimized but may be another technique such as a conventional technique.
  • a second, or additional session setup method which is preferably an AnswerFast mechanism to ensure speed of session establishment is minimized but may be another technique such as a conventional technique.
  • FIG. 43 shows in particular a combination for refinement that has substantial benefits.
  • This call sequence attempts to initiate a session optionally using one or more AswerFast4 variants, such as a profile based version incorporating tunneled/pre- negotatied media, or a fully negotiated version. If after the AnswerFast negotiations are complete, there are aspects of the desired session that were unfulfilled then a subsequent AnswerFast stage may be used to further refine the characteristics.
  • AnswerFast2 is used to refine the session, but it adopts characteristics such as mobile level and any existing media channels, and augments the session with additional media channels, additional multiplexer table entries and also any other session capabilities or information desired (these additional capabilities/information may be provided using conventional techniques also).
  • the AnswerFast2 technique preferably also encompasses an AnswerFast 1 and an AnswerFastSRP technique although this is optional.
  • This combination of techniques combines various AnswerFast4 techniques and AnswerFast2 techniques.
  • the AnswerFast4 profiles (inclusive of tunneled media), and the AnswerFast4 negotiated media are combined using a common preference message format and possibly one or more common preference expressions such as mobile level and combined with optional conventional mobile level interleaving.
  • the selection between using an AnswerFast profile based media and AnswerFast explicitly negotiated media is made either by predetermined arrangement of a hierarchy of the two techniques, or an expression of support and a preference (such as signaling supported and signaling preferred). The preference may be included in preference message, implicit in the media or some other way.
  • this combination will be able to attempt to negotiate a session using AnswerFast4 profiles or AnswerFast4 negotiated, but in the cases this happens or negotiation fails or establishes only a partial session, then the session negotiation continues in H.245 control channel messages, in particular an AnswerFast2 mechanism expressed in a TerminalCapabilitySet field such as the genericlnformation field.
  • the AnswerFast2 technique uses the mobile level as negotiated in the AnswerFast4 common preferences.
  • the combination may also benefit from overriding or redefining a decision from the AnswerFast4 common preferences using a later message, such as in the AnswerFast2 negotiations or in normal H.245 messages.
  • the master slave determination as decided in AnswerFast4 negotiations may be re -determined using H.245 to ensure it can be controlled more easily in infrastructure and the like.
  • the combination will also interoperate with conventional terminals in a time that is almost negligibly different to another conventional terminal.
  • This combination may further optionally support AnswerFastSRP and AnswerFastl in order to obtain the best performance for AnswerFast2 and interoperation with legacy devices.
  • the performance of this combination would be displayable media received in around 0.5 RTD (or 1.0 RTD) for the AnswerFast4 tunneled media mode, displayable media received in around 1.0 RTD for the AnswerFast4 negotiated media mode, displayable media received in around 1.5 RTD for the AnswerFast2 media.
  • This combination is similar to the combination Class 1.1 and is interoperable with it. However, in this case, the AnswerFast4 profiles do not attempt to use tunneled/non-negotiated media. The terminals instead elect to wait until preferences are received from the other terminal and then elect to send profile based media if allowed by any mode selection algorithms. The performance of this combination would be displayable media received in around 1.0 RTD for the AnswerFast4 tunneled media mode, displayable media received in around 1.0 RTD for the AnswerFast4 negotiated media mode, displayable media received in around 1.5 RTD for the AnswerFast2 media. This combination can interoperate with Class Ll using AnswerFast4 profiles, AnswerFast4 negotiated or AnswerFast2.
  • This combination is similar to the combination Class Ll and is interoperable with it. However, in this case, there is no use of the AnswerFast4 negotiated technique. The performance of this combination would be displayable media received in around 0.5 RTD (or 1.0 RTD) for the AnswerFast4 tunneled media mode, displayable media received in around 1.5 RTD for the AnswerFast2 media. This combination can interoperate with Class Is using AnswerFast4 profiles or AnswerFast2.
  • Combination Class II.2 [0617] This combination is similar to the combination Class I.I and is interoperable with it. However, in this case, there is no use of the AnswerFast4 negotiated technique and the AnswerFast4 profiles do not attempt to use tunneled/non-negotiated media. The terminals instead elect to wait until preferences are received from the other terminal and then elect to send profile based media if allowed by any mode selection algorithms.
  • the performance of this combination would be displayable media received in around 1.0 RTD for the AnswerFast4 tunneled media mode and displayable media received in around 1.5 RTD for the AnswerFast2 media.
  • This combination can interoperate with Class Is using AnswerFast4 profiles, AnswerFast4 negotiated or AnswerFast2 and Class ILl using AnswerFast4 profiles or AnswerFast2.
  • Combination Class III This combination is similar to the combination Class I.I and is interoperable with it. However in this case there is no use of the AnswerFast4 profiles. The performance of this combination would be displayable media received in around 1.0 RTD for the AnswerFast4 negotiated mode, displayable media received in around 1.5 RTD for the AnswerFast2 media. This combination can interoperate with Class I mehods using AnswerFast4 negotiated or AnswerFast2 and Class II methods using AnswerFast2. Variants of Class III may also elect to not perform negotiations until after receiving a preference message from the remote.
  • AnswerFast2 It does not use AnswerFast4 profiles or AnswerFast4 negotiated. The performance of this combination would be displayable media received in around 1.5 RTD for the AnswerFast2 media. This combination can interoperate with the methods Class I, II, and III using AnswerFast2.
  • Variants of Class IV may also elect to not use the common AnswerFast4 information and may instead perform conventional techniques, or other techniques such as preconfigured or implicit selection, to determine other session characteristics such as multiplexer level.
  • Combination Class H.245-1 This combination of techniques combines AnswerFastl techniques and AnswerFastSRP techniques. It is also interoperable with AnswerFastl alone, AnswerFastSRP alone and conventional setup. This provides primarily the benefits of the AnswerFastl technique, but the AnswerFastSRP technique provides advantages particularly in the case of errors and large H.245 messages (that require segmentation).
  • This combination of techniques combines AnswerFastl techniques, AnswerFast2 techniques and AnswerFastSRP techniques. This provides a reasonably fast and flexible setup when talking to like combination terminals and also a fast, almost negligible, fallback when talking to Class H.245-1 terminals. It also has the benefit of having a reasonable simple implementation. It is also interoperable with AnswerFastl, AnswerFastSRP and conventional setup.
  • embodiments of the present invention provide a method and apparatus adapted for use in the management of the session setup schemes or protocols.
  • a method of allowing a terminal or node to use a number of session setup schemes is provided.
  • initial preference messages are sent by both terminals and/or nodes after a bearer channel has been established.
  • the bearer channel is the channel established by the network that carries information between the terminals and/or the nodes.
  • these messages may be referred to as "bullets".
  • bullets typically, these messages carry a small amount of information that express some of the capabilities and preferences (as in which media types the device prefers to use, and possibly which algorithms are supported and/or preferred) of each of the communicating devices (whether they be terminals or nodes).
  • the communicating devices use a common decision making algorithm to determine which session setup mechanism is used. Once the session setup is complete, media flows between the communicating devices until the session is closed.
  • the "bullets” carry the information referred to above. Using this information, a decision is made on whether the fastest session setup method should be used, in this case the fastest method is an AnswerFast4 technique that tunnels media encapsulated in preference messages according to a limited set of preconfigured channel profiles (referred to as FM in FIG. 3), the use of these profiles causes this technique to have lower flexibility than the other methods. Further details of tunneling information and media in pre-negotiation messages may be found throughout the present specification.
  • the session is created in that manner, or at least an attempt is made that may result in either a complete session or may result in a partial session containing only a subset of the desired number of media/data channels. Such missing desired channels might cause an attempt to establish these additional channels using a fallback technique.
  • a common, reliable method (and most time consuming method, referred to as H.245 in FIG. 3) may be used to setup the session. More flexibility can be added to the session setup by the optional adoption of a more flexible session setup method, but that is still based on AnswerFast4 techniques (for example in FIG. 3, FSS is included) further details of which are also found in the applications recited in the previous paragraph.
  • FSS allows the communicating devices to share more information and thus consumes more time while allowing additional flexibility to the way media is communicated between the communicating devices because both terminals both have access to at least a reasonable amount of preference information received from the other terminal.
  • the session setup fails, then the slowest and most reliable accelerated session setup method may be used.
  • performance even if in only a few cases, may not be acceptable to device manufacturers or the consumer and so a reliable session setup scheme which is slightly faster than the most reliable scheme could optionally be included in the device.
  • This slightly faster version could be a variant of AnswerFast2, a variant of AnswerFastl or a variant of AnswerFastSRP, or a combination of all three.
  • this scheme is referred to as ACN, and it is an AnswerFast2 technique that preferably employs AnswerFastl and AnswerFastSRP to achieve its best performance.
  • Accelerated H.245 procedures such as those employed in ACN typically involve the transmission of more information and the acknowledgement of more of that information than the faster session setup schemes. As with the other schemes, if the session fails to be established, then the most reliable session setup scheme will be used. In this way, a number of session setup schemes can be used in the same communication device to allow the advantages of the various schemes to be realized in different situations.
  • the established sessions may optionally be further refined and/or augmented using additional session setup techniques. For example, an AnswerFast4 session may be refined using AnswerFast2 session setup techniques. Moreover, other sessions may be refined using H.245 procedures.
  • Embodiments of the present invention allows the different session setup schemes or protocols to operate in the same device with a meaningful result.
  • embodiments provide for scalable session setup creation, where speed is traded with flexibility and reliability.
  • a further advantage of embodiments of the present invention is that methods and systems provided herein allow a subset of the available session setup schemes to be used in any one device and still operate reliably with devices that implement a smaller or larger subset.
  • embodiments of the present invention combine one or more accelerated or conventional session setup techniques in a hierarchical manner. Such session setup techniques may be combined in various manners as described herein. In addition to the embodiments described, other combinations may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may combine the session setup techniques outlined above in a different order. Moreover, the various techniques may include multiple sub-techniques that may be performed in various orders and combinations as appropriate to the individual technique. Furthermore, additional techniques may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé pour établir une session entre un premier dispositif et un second dispositif. La session est établie par l'intermédiaire d'un réseau de télécommunications au moyen d'une technique d'établissement session accéléré. Le procédé consiste à fournir une première technique d'établissement de session accéléré et à fournir une seconde technique d'établissement de session accéléré, à établir la session au moyen de la première ou de la seconde technique d'établissement de session accéléré en fonction d'un processus prédéterminé.
PCT/US2007/066462 2006-04-11 2007-04-11 Procédés et dispositif pour combiner des techniques d'accélération de session pour accélérer les négociations orientées support Ceased WO2007121264A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US79130006P 2006-04-11 2006-04-11
US60/791,300 2006-04-11

Publications (2)

Publication Number Publication Date
WO2007121264A2 true WO2007121264A2 (fr) 2007-10-25
WO2007121264A3 WO2007121264A3 (fr) 2008-01-03

Family

ID=38610369

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/066462 Ceased WO2007121264A2 (fr) 2006-04-11 2007-04-11 Procédés et dispositif pour combiner des techniques d'accélération de session pour accélérer les négociations orientées support

Country Status (1)

Country Link
WO (1) WO2007121264A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012095402A1 (fr) 2011-01-13 2012-07-19 Telefonaktiebolaget L M Ericsson (Publ) Prise en charge par porteuses multiples en situation d'encombrement de trafic
TWI387305B (zh) * 2008-09-26 2013-02-21 Legend Beijing Ltd User terminal communication method and device
CN113141352A (zh) * 2021-03-26 2021-07-20 深圳市捷视飞通科技股份有限公司 多媒体数据的传输方法、装置、计算机设备和存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2290069A1 (fr) * 1999-11-19 2001-05-19 Nokia Mobile Phones Ltd. Methode d'etablissement d'une communication en presence d'une indication hors bande de la participation du rtcp a l'etablissement d'une communication multimedia
US7330542B2 (en) * 2000-12-22 2008-02-12 Nokia Corporation Method and system for establishing a multimedia connection by negotiating capability in an outband control channel
US7839804B2 (en) * 2004-07-15 2010-11-23 Qualcomm Incorporated Method and apparatus for performing call setup for a video call in 3G-324M

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI387305B (zh) * 2008-09-26 2013-02-21 Legend Beijing Ltd User terminal communication method and device
WO2012095402A1 (fr) 2011-01-13 2012-07-19 Telefonaktiebolaget L M Ericsson (Publ) Prise en charge par porteuses multiples en situation d'encombrement de trafic
US9602417B2 (en) 2011-01-13 2017-03-21 Telefonaktiebolaget Lm Ericsson (Publ) Multiple bearer support upon congestion situations
CN113141352A (zh) * 2021-03-26 2021-07-20 深圳市捷视飞通科技股份有限公司 多媒体数据的传输方法、装置、计算机设备和存储介质
CN113141352B (zh) * 2021-03-26 2022-09-30 深圳市捷视飞通科技股份有限公司 多媒体数据的传输方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
WO2007121264A3 (fr) 2008-01-03

Similar Documents

Publication Publication Date Title
US7680143B2 (en) Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
CN101124783B (zh) 发起缩减了建立时间的会话的建立过程的方法
EP1633113B1 (fr) Méthodes et système d'établissement rapide de session entre des équipements en utilisant H.324 et protocoles de télécommunications associés.
US7139279B2 (en) Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7920493B2 (en) Fast session setup extensions to H.324
US20070266161A1 (en) Methods and system for fast session establishment between equipment using h.324 and related telecommunications protocols
US20070129052A1 (en) Methods and system for fast session establishment for H.324 and related telecommunications terminals
WO2007121264A2 (fr) Procédés et dispositif pour combiner des techniques d'accélération de session pour accélérer les négociations orientées support
US20070060163A1 (en) Methods and system for communications between equipment using one or more interleaved mobile level stuffing sequences
WO2007044884A1 (fr) Procedes et systemes d'etablissement de session rapide pour terminaux h.324 et terminaux de telecommunication associes

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

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A) SENT 18.12.2008.

122 Ep: pct application non-entry in european phase

Ref document number: 07760510

Country of ref document: EP

Kind code of ref document: A2