EP2018754A1 - Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung - Google Patents

Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung

Info

Publication number
EP2018754A1
EP2018754A1 EP07728862A EP07728862A EP2018754A1 EP 2018754 A1 EP2018754 A1 EP 2018754A1 EP 07728862 A EP07728862 A EP 07728862A EP 07728862 A EP07728862 A EP 07728862A EP 2018754 A1 EP2018754 A1 EP 2018754A1
Authority
EP
European Patent Office
Prior art keywords
data
ptt
communication
poc
communication channel
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.)
Withdrawn
Application number
EP07728862A
Other languages
English (en)
French (fr)
Inventor
Pavel Dostal
Ivo Sedlacek
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Nokia Siemens Networks GmbH and Co KG
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 Nokia Siemens Networks GmbH and Co KG filed Critical Nokia Siemens Networks GmbH and Co KG
Publication of EP2018754A1 publication Critical patent/EP2018754A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities

Definitions

  • the invention relates to a method for building a
  • Push-to-talk (Ptt) communication link between a first Ptt device and a second Ptt device in which data of different data type, such as voice data, image data or textual data, is transferred between the first and second Ptt devices, wherein the first Ptt device transmits a Ptt connection request for the mutual transmission of different data types to the second Ptt device, and subsequently establishes a communication connection for at least a selection of these different data types over a communication channel according to a communication protocol according to Preamble of claim 1.
  • Ptt Push-to-talk
  • the invention further relates to a push-to-talk (Ptt) device for establishing a push-to-talk (Ptt) communication connection to another Ptt device in which data of different types of data, such as voice data, image data or text data , are transmitted between the first and the second Ptt devices via a communication channel according to a communication protocol, according to the preamble of claim 7.
  • Ptt push-to-talk
  • Pttt push-to-talk
  • the invention further relates to a communication arrangement for establishing a push-to-talk (Ptt) communication connection with a first Ptt device and a second Ptt device, between which see data of different data type, such as
  • Voice data, image data or text data are transmitted via a communication channel according to a communication protocol, and a Ptt server, according to the preamble of claim 8.
  • Push-to-talk (Ptt) communication connections are used in particular in connection with mobile technology, in which case one also speaks of push-to-talk-over-cellular (PoC) connections, since the corresponding ptt Devices around mobile devices.
  • PoC push-to-talk-over-cellular
  • a mobile subscriber using his Ptt device is enabled to transmit a voice message to one or more receivers simultaneously via a mobile radio interface, usually by pressing a key.
  • the voice data are usually already distributed during the speech process of the sender via the mobile communication network, and transmitted to the desired recipient (s).
  • a PoC communication connection is therefore similar to the known CB radio, but with the great difference that the users of a PoC connection are reachable worldwide, since the transmission of the data takes place via a mobile radio network.
  • the following is primarily of PoC compounds the speech, but the invention is not limited in principle to an application in the mobile sector.
  • PoC communication works in a similar way to Internet telephony ("Voice over IP", VoIP) .Participants first receive signaling through the SIP system.
  • the voice data ("talk bursts") are subsequently transmitted via the RTP protocol (Real-Time Transport Protocol), in order to maximize standardization in order to ensure the compatibility of the participating PoC devices
  • RTP protocol Real-Time Transport Protocol
  • PoC Version 1.0 the basic features of the communication protocol. set up for setting up and operating the PoC communication connection.
  • PoC communication connection ie a PoC session
  • the voice data be transferred to the other PoC participants.
  • the first PoC user ie a first PoC client unit
  • a release for sending data such as voice data
  • data such as voice data
  • the first PoC user is already granted a release for sending data by the PoC server unit, although no communication connection between the PoC server is yet to be seen Unit and the selected PoC
  • the first PoC subscriber can thus not be sure whether his data has already been received by the second PoC subscriber.
  • PoC session if data of different data types are to be transmitted, ie not only voice data, but also audio data (eg music files), video data, pictures, text or other textual data as provided in the PoC Version 2.0 standard. Difficulties may arise, for example, if not every one of the PoC clients can technically exploit each data type, or if a certain PoC client does not want to receive a specific data type (such as voice or audio data, if the subscriber is noisy his PoC device in certain situations want to operate).
  • data type such as voice or audio data, if the subscriber is noisy his PoC device in certain situations want to operate.
  • PoC initiator from a group of different data types contained in the connection request of a PoC client (the so-called "PoC initiator"), only subgroups of data types can be accepted by the other PoC clients Thus, the PoC initiator has no way of determining whether and for which data types the other PoC clients are ready to receive.Of course, during a PoC session it could be detected whether another subscriber can receive a specific data type, at which point the PoC However, the session has already been created, and already causes costs, but it would be advantageous if it is possible to decide whether a connection to a subscriber should be established before a PoC session is established.
  • Claim 1 initially relates to a method for establishing a push-to-talk (Ptt) communication connection between a first Ptt device and a second Ptt device in which data of different data type, such as voice data, audio data, video data, image data Textual data, or other textual data, between the first and second Ptt devices, the first Ptt device transmitting a Ptt
  • Ptt push-to-talk
  • a priority information with which a transmission priority is assigned to the different data types to be transmitted via the communication channel and the communication protocol only allows the establishment of a communication channel with the second Ptt device, if the second ptt device is available for the data type or the data types with the highest transmission priority, and transmits a lower-priority data type over this communication channel only if the second ptt device is available for that data type, and the second ptt Device is also available for all higher-priority data types.
  • a "ranking list" of the different data types is created, which is either the same for each PoC session or which can be specified by the PoC initiator before the PoC session is set up.
  • Session is loaded, according to the invention can participate only if he supports the data type with the highest transmission priority.
  • the invited PoC client may again participate only if it supports all data types with a higher transmission priority.
  • This communication protocol therefore allows the PoC initiator to specify before the PoC session that each participating PoC client supports at least one data type, namely the one to which the PoC initiator has given the highest priority.
  • the data types are transmitted via communication channels, which are understood to be organizational transmission paths in which a communication protocol is implemented for the transmission of a group of data types which are subject to this communication protocol.
  • Such communication channels are also referred to as "Media Floor Control Entities", where the "Media” are the representational data types, and in the case of a “Media Floor Control”, a communication protocol, in which case the transmission is more continuous (Real-time) data types such as voice, audio or video data over a communication channel, with discrete (non-real-time) data types such as text messages or text files, it is not common to choose a separate communication channel.
  • claim 2 provides that a first communication channel is used for a first subgroup of the different data types to be transmitted, and for a second subgroup the one to be transmitted. carrying, different data types, a second communication ⁇ kationskanal is used.
  • the Ptt communication connection is a mobile radio communication connection, for example for setting up a PoC session.
  • the assignment of the Ubertragungsprioritat can take place approximately in accordance with claim 6 in the Session Description Protocol.
  • Claim 7 relates to a push-to-talk (Ptt) device for establishing a push-to-talk (Ptt) communication connection to another Ptt device, in which data of different data type, such as voice data, audio data, Video data, image data, text data, or other textual data, between the first and the second Ptt device via a communication channel according to a communication protocol are transmitted.
  • ErfmdungsgeLogic is provided in such a device that a unit for creating a Ptt Verbmdungsanfrage is provided, which contains a priority information, with the over the communication channel to be transmitted, different data types is assigned a Ubertragungsprioritat, and with a transmitting unit for transmitting the PTT Connection request is equipped to another Ptt device.
  • data of different data type such as voice data, audio data, video data, image data, textual data, or other textual data
  • the ptt devices each comprise a unit for generating a ptt connection request and a transmission unit for sending the ptt connection request to another ptt device, wherein the ptt connection request of the first ptt device contains priority information with which the assigned via the communi ⁇ cation channel to be transmitted, different types of data, a transmission priority, and the PTT server is equipped with a communication protocol, the only zulasst the structure of a communication channel between the first Ptt-UNIT and the second PTT GERAT if the second ptt device is available for the data type or the data types with the highest transmission priority, and allows the transmission of a data type with lower transmission priority over this communication channel only if the second ptt device is available for this data type, and the second Ptt device also for all data ypen is available with higher U-bertragungsprioritat.
  • the 1 is a schematic representation of a communication arrangement with a PoC initiator, a PoC server unit, and three other PoC participants that are contacted by the PoC initiator,
  • FIG. 2 shows a schematic representation of the conventional structure of a PoC session in a communication arrangement according to FIG. 1
  • the invention generally relates to push-to-talk (Ptt) communication arrangements with Ptt clients or Ptt devices 1, 2 and at least one Ptt server unit 3.
  • Ptt push-to-talk
  • the invention is intended to refer to a specific Arrangement of this type are explained, namely a push-to-talk over-cellular (PoC) communication arrangement with a PoC initiator 1, a PoC server unit 3, and three other PoC clients 2a, 2b, 2c, the be contacted by the PoC initiator 1.
  • the PoC clients 1, 2 a, 2 b, 2 c are each set up for communication in accordance with the UMTS standard, the GSM standard, the GPRS standard, or another mobile communication standard.
  • PoC communication understood a communication between the PoC clients 1,2a, 2b, 2c via a mobile radio interface, in which the transmitter, for example by selecting a special Push button of the PoC device, voice data to at least one receiver, preferably to a plurality of receivers, simultaneously according to the duplex method, preferably according to the HaIb duplex method, can transmit.
  • the transmitter and the receiver can be each of the PoC clients 1, 2 a, 2 b, 2 c.
  • the half-duplex method only the user of the transmitting unit can speak, the users of the receiving units can only hear and not interrupt the user of the transmitting unit.
  • the recorded voice, voice data are usually already during the Einschens the voice data by a PoC client 1,2a, 2b, 2c via the IMS (IP Multimedia Subsystem) core communication network to the at ⁇ the PoC clients 1, 2a, 2b, 2c distributed.
  • This technology is also referred to as "streaming.” This makes it possible to compare a PoC communication connection with the known CB radio, but with the great difference that the subscribers of a PoC connection can be reached worldwide because the transmission of the data via a mobile network takes place.
  • PoC service for each PoC client 1,2a, 2b, 2c, his personal, fixed groups of PoC clients 1,2a , 2b, 2c.
  • a group of PoC clients 2a, 2b, 2c and their respective addresses can be defined.
  • the addresses may be in the form of a telephone number, for example, as Session Initiation Protocol-Unique Resource
  • the user-defined group of PoC clients 2a, 2b, 2c receives usually a separate group address, for example, also in the form of a SIP URL, so that the PoC initiator 1 when setting up a PoC session all group members using the PoC server unit 3 can address and load the PoC session. In this case, the PoC connection request is transmitted to all PoC clients 2a, 2b, 2c contained in the respective group.
  • the PoC clients 1,2a, 2b, 2c and the PoC server unit 3 are usually set up for communication according to the Session Initiation Protocol (SIP), as well as in the lower communication layers, i. in the transport layer, for communication according to the Transport Control Protocol (TCP) and / or User Datagram Protocol (UDP), as well as in the switching layer for communication according to the Internet Protocol (IP).
  • SIP Session Initiation Protocol
  • TCP Transport Control Protocol
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • the PoC communication arrangement according to FIG. 1 is thus set up for communication based on the IP Multimedia Subsystem (IMS).
  • IMS IP Multimedia Subsystem
  • the transmission of user data in particular of voice data, but also of audio, video or text data, starting from the first PoC client 1 according to the half-duplex method to the specified in the selected group PoC Clients 2a, 2b, 2c via the IP-based communication network as well as via the PoC server unit 3.
  • the PoC clients 1, 2 a, 2 b, 2 c are each connected to the PoC server unit 3 by means of a mobile radio interface, the mobile radio interfaces in those cases in which the communication arrangement based on the UMTS standard, by means of the dio Access Network (RAN), the Core Network (CN) and the IP Multimedia Subsystem.
  • RAN dio Access Network
  • CN Core Network
  • IP Multimedia Subsystem IP Multimedia Subsystem
  • the PoC initiator 1 first transmits a SIP INVITE message to the PoC server unit 3 by means of the UMTS core network (UMTS core communication network).
  • the data types to be transmitted may be, for example, speech data Sp, audio data A, video data V, image data I, text data T, or other textual data F (for example files).
  • PoC initiator 1 can send and receive all of these data types, and therefore invites all other PoC clients 2a, 2b, 2c in its PoC connection request to a PoC session in which all these data types should be exchanged.
  • a communication channel Fl is defined for the voice data Sp, audio data A, video data V and image data I.
  • a second communication channel NF is defined for the discrete data types.
  • the PoC connection request shown in FIG. 2 initially takes the form of a SIP INVITE message to the PoC server unit 3, which forwards it to the selected PoC clients 2 a, 2 b, 2 c.
  • PoC client 2a supports only voice data Sp, and is also available for a PoC session.
  • PoC client 2a therefore accepts the structure of a communication channel Fl for voice data Sp.
  • PoC client 2b in this example supports voice data Sp, audio data A and video data V, and is also available for a PoC session.
  • PoC client 2b therefore accepts the Structure of a communication channel Fl for voice data Sp, audio data A and video data V.
  • PoC client 2c supports all data types in this example, it is only for image data I, other data F and
  • Text data T available for a PoC session available for a PoC session.
  • PoC client 2c it could be that PoC client 2c is in a meeting and wants to operate its PoC device silently.
  • the PoC client 2c therefore accepts the construction of a communication channel Fl for image data I, and the establishment of a communication channel NF for other data F and text data T.
  • the PoC server unit 3 thus sends the response to the PoC initiator 1 that there is a need to set up communication channel Fl and NF for all data types. Subsequently, the PoC session is established in a known manner, but PoC client 2c can not communicate with the PoC clients 2a and 2b. According to the prior art, prior to the start of the PoC session, PoC initiator 1 will also not learn that one of the subscribers, namely PoC client 2c, does not receive voice data Sp. The PoC session is still established and charged in a conventional manner.
  • FIG. 3 shows what effect the communication protocol according to the invention has on the establishment of a PoC session.
  • a PoC connection request is first issued in the form of a
  • the invention initially requires no changes in the initiation of a PoC session using the Session Initiation Protocol.
  • Erfmdungsgelaut is in this PoC Verbmdungsanfrage, as in the Session Desc ⁇ ption Protocol m in a comparison with the prior art additionally provided message field but a Prio ⁇ tatsmformation contain, with the to be transmitted, the different data types Sp, A, V, I, T and F. a transmission priority is assigned.
  • transmission rates for the respective group of data types can be defined. For example, it is shown in FIG. 3 that PoC initiator 1 gives the speech data Sp the highest priority, the audio data a lower priority, and so on.
  • the image data I is given the lowest probability in the communication channel Fl m in this example.
  • the other data F has a higher transmission priority than the text data T.
  • the PoC initiator 1 has a unit (not shown in FIGS. 3 and 4) for creating a PoC connection request containing a priority information with which the different to be transmitted via the communication channel Fl, NF Data types Sp, A, V, I, T, F is assigned a transmission priority, and via a transmitting unit (m in FIGS. 3 and 4 not visible) for sending the PoC Verbmdungsanfrage to another PoC client. 2
  • PoC client 2a in turn supports only voice data Sp, and is also available for a PoC session.
  • the PoC client 2a therefore accepts the establishment of a communication channel F1 for voice data Sp. This is permitted by the communication protocol, since PoC client 2a for the data type is available with the highest transmission priority, namely for voice data Sp.
  • PoC client 2b in turn supports voice data Sp, audio data ⁇ and video data V, and is also available for a PoC session.
  • the PoC client 2b therefore accepts the establishment of a communication channel F1 for voice data Sp, audio data A and video data V.
  • the communication protocol firstly allows the establishment of a communication channel F1 for voice data, since this is the data type with the highest transmission priority , But also the transmission of the data type A with lower Ubertragungsprioritat on this Kor ⁇ munikationskanal Fl is allowed, since PoC client 2b for all data types with higher Ubertragungsprioritat, ie voice data Sp, is available. Furthermore, the transmission of data type V with a lower transmission priority via this communication channel F1 is also permitted since PoC client 2b is also available for all data types with a higher transmission priority, ie voice data Sp and audio data A.
  • PoC client 2c in turn supports all data types, but is only available for image data I, other data F and text data T.
  • the PoC client 2c therefore accepts the establishment of a communication channel Fl for image data I, and the establishment of a communication channel NF for other data F and text data T.
  • the communication channel Fl to PoC client 2c is not established, although PoC client 2c for image data I would be available.
  • the difference of erfmdungsgedorfen communication protocol over the prior art according to FIG. 2 expresses.
  • PoC client 2c Since PoC client 2c is available for the data type with the highest transmission priority in the communication channel NF, namely for other data F, the communication channel NF is established. However, the transmission of the data type T with a lower transmission priority is also permitted via this communication channel F1 since the PoC client 2c is also available for all data types with a higher transmission priority, namely other data F.
  • the PoC clients 2a and 2b would thus exchange voice data Sp with the PoC initiator 1, and the PoC client 2c text data T and other data F.
  • the method according to the invention thus completely solves the task according to the invention for those cases in which only a single communication channel is defined. If a plurality of communication channels are defined, as in FIG. 3, PoC sessions can still occur in which not all users can share at least one data type.
  • FIG. 4 another embodiment may be provided which is shown in FIG. 4.
  • the PoC connection request for instance in the Session Description Protocol
  • further priority information is included, with which a communication priority is also assigned to the communication channels Fl, NF, and the communication protocol the structure of the communication channel NF with the lower transmission priority only if a setup of the communication channel F1 with the higher transmission priority takes place.
  • This rule initially leaves the establishment of communication channels with the PoC clients 2a and 2b unchanged. dert, as a comparison of Fig. 4 with Fig. 3 shows, since in any case the communication channel Fl is constructed with the highest transmission ⁇ priority.
  • PoC client 2c With regard to PoC client 2c, however, it now appears that the communication protocol according to the invention now does not permit the structure of the communication channel NF, since no structure of the communication channel F1 with the higher transmission priority takes place. As a result, no PoC session with PoC client is established. Instead, only the PoC clients 2a and 2b participate in the PoC session with the PoC initiator 1, wherein all users can exchange voice data Sp, and thus can share at least one data type.
  • the invention thus ensures, even in these cases, that a PoC client 2a, 2b, 2c is only admitted to a PoC session if it is ready to receive for at least one common data type with all other PoC clients participating in the PoC session is.
  • Fig. 4 takes place at a ⁇ order of priority assigned to the communication channels Fl and NF the structure of the PoC session with the PoC client portedung 2c.
  • the communication channel NF has a higher transmission priority than the communication channel Fl, so that the communication protocol according to the invention does not allow the communication channel Fl to be established with the PoC clients 2a and 2b, since no establishment of the communication channel NF having the higher transmission priority has been performed.
  • a further embodiment of the method according to the invention comprises assigning the data types a transmission priority irrespective of their allocation to communication channels. organize. Multiple data types can thus have the same transmission priority, but each data type has only one priority assignment.
  • the PoC initiator 1 could give voice data Sp, audio data A and video data V respectively the highest transmission priority, image data I the second highest priority, and all other data types the lowest priority.
  • the PoC clients 2a, 2b and 2c can thus participate in the PoC session only if they are available for voice data Sp, audio data A and video data V. In terms of the example of FIG. 4, this would mean that only PoC client 2b could participate in a PoC session with PoC initiator 1.
  • the invention therefore represents a particularly simple but also versatile possibility of only allowing a PoC client 2a, 2b, 2c to a PoC session if it is ready to receive data for the desired data types of the PoC initiator 1.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Verfahren zum Aufbau einer Push-to-talk- (Ptt) - Kommunikationsverbindung zwischen zwei Ptt-Geräten (1,2), bei der Daten unterschiedlichen Datentyps, wie etwa Sprachdaten (Sp), Audiodaten (A), Videodaten (V) usw., zwischen den Ptt- Geräten (1,2) übertragen werden, wobei das erste Ptt-Gerät (1) eine Ptt-Verbindungsanf rage übermittelt, und in weiterer Folge eine Kommunikationsverbindung für zumindest eine Auswahl dieser unterschiedlichen Datentypen über einen Kommunikationskanal (Fl, NF) gemäß eines Kommunikationsprotokolls aufgebaut wird. Erfindungsgemäß ist vorgesehen, dass in der Ptt-Verbindungsanf rage eine Prioritätsinformation enthalten ist, mit der den Datentypen eine Übertragungspriorität zugewiesen wird, und dass das Kommunikationsprotokoll den Aufbau eines Kommunikationskanals (Fl, NF) nur dann zulässt, wenn das zweite Ptt-Gerät (2) für den Datentyp oder die Datentypen mit der höchsten Übertragungspriorität verfügbar ist, und die Übermittlung eines Datentyps mit niedrigerer Übertragungspriorität über diesen Kommunikationskanal (Fl, NF) nur dann zulässt, wenn das zweite Ptt-Gerät (2) für diesen Datentyp verfügbar ist und das zweite Ptt-Gerät (2) auch für alle Datentypen mit höherer Übertragungspriorität verfügbar ist.

Description

Verfahren zum Aufbau einer Push-to-talk-Kommunikations- verbindung
Die Erfindung bezieht sich auf ein Verfahren zum Aufbau einer
Push-to-talk- (Ptt) -Kommunikationsverbindung zwischen einem ersten Ptt-Gerät und einem zweiten Ptt-Gerät, bei der Daten unterschiedlichen Datentyps, wie etwa Sprachdaten, Bilddaten oder Textdaten, zwischen dem ersten und dem zweiten Ptt-Gerät übertragen werden, wobei das erste Ptt-Gerät eine Ptt- Verbindungsanfrage für die gegenseitige Übertragung unterschiedlicher Datentypen an das zweite Ptt-Gerät übermittelt, und in weiterer Folge eine Kommunikationsverbindung für zu- mindest eine Auswahl dieser unterschiedlichen Datentypen über einen Kommunikationskanal gemäß eines Kommunikationsprotokolls aufgebaut wird, gemäß dem Oberbegriff von Anspruch 1.
Die Erfindung betrifft weiters ein Push-to-talk- (Ptt) -Gerät zum Aufbau einer Push-to-talk- (Ptt ) -Kommunikationsverbindung zu einem weiteren Ptt-Gerät, bei der Daten unterschiedlichen Datentyps, wie etwa Sprachdaten, Bilddaten oder Textdaten, zwischen dem ersten und dem zweiten Ptt-Gerät über einen Kommunikationskanal gemäß eines Kommunikationsprotokolls über- tragen werden, gemäß dem Oberbegriff von Anspruch 7.
Die Erfindung betrifft weiters eine Kommunikationsanordnung zum Aufbau einer Push-to-talk- (Ptt ) -Kommunikationsverbindung mit einem ersten Ptt-Gerät und einem zweiten Ptt-Gerät, zwi- sehen denen Daten unterschiedlichen Datentyps, wie etwa
Sprachdaten, Bilddaten oder Textdaten, über einen Kommunikationskanal gemäß eines Kommunikationsprotokolls übertragen werden, sowie einem Ptt-Server, gemäß dem Oberbegriff von Anspruch 8. Push-to-talk- (Ptt) -Kommunikationsverbindungen finden insbesondere im Zusammenhang mit der Mobilfunktechnologie Anwendung, wobei man in diesem Fall auch von Push-to-talk-over-Cellular (PoC) -Verbindungen spricht, da es sich bei den entsprechenden Ptt-Geräten um Mobilfunkgeräte handelt. Hierbei wird es einem Mobilfunkteilnehmer mithilfe seines Ptt-Geräts ermöglicht, eine Sprachnachricht an einen oder mehrere Empfänger gleichzeitig über eine Mobil- funk-Schnittstelle zu übermitteln, meistens durch Betätigen einer Taste. Dabei werden die Sprachdaten üblicherweise schon während des Sprechvorgangs des Senders über das Mobilfunk-Kommunikationsnetzwerk verteilt, und an den oder die gewünschten Empfänger übermittelt. Eine PoC- Kommunikationsverbindung ähnelt daher dem bekannten CB-Funk, allerdings mit dem großen Unterschied, dass die Teilnehmer einer PoC-Verbindung weltweit erreichbar sind, da die Übertragung der Daten über ein Mobilfunk-Netzwerk erfolgt. Im folgenden ist in erster Linie von PoC-Verbindungen die Rede, die Erfindung ist aber prinzipiell nicht auf eine Anwendung im Mobilfunkbereich eingeschränkt.
Technisch funktioniert eine PoC-Kommunikation ähnlich wie bei der Internet-Telefonie („Voice over IP", VoIP). Die Teilneh- mer bekommen zuerst eine Signalisierung durch das SIP-
Protokoll (Session Initiation Protocol) , nachfolgend werden die Sprachdaten („Talk Bursts") über das RTP-Protokoll (Real- Time Transport Protocol) übertragen. Dabei ist man um größtmögliche Standardisierung bemüht, um die Kompatibilität der teilnehmenden PoC-Geräte sicher zu stellen. Derzeit existieren etwa der ,,PoC Version 1.0"-Standard sowie eine Version 2.0, die grundlegende Eigenschaften der Kommunikationsproto- kolle für Aufbau und Betrieb der PoC-Kommunikationsverbindung festlegen sollen.
Gemäß gegenwärtig üblicher Industriespezifikationen sind zwei unterschiedliche Varianten zum Aufbau einer
PoC-Kommunikationsverbindung (d.h. einer PoC-Session) beschrieben, die sich dadurch unterscheiden, zu welchem Zeitpunkt ein erster PoC-Benutzer nach erfolgtem Aufbau der PoC-Session mit einer PoC-Server-Einheit mit dem Sprechen be- ginnen kann, und die Sprachdaten zu den weiteren PoC- Teilnehmern übertragen werden.
Gemäß dem sogenannten „Late Media Modus" wird dem ersten PoC-Benutzer, d.h. einer ersten PoC-Client-Einheit , erst dann eine Freigabe zum Senden von Daten, etwa von Sprachdaten, erteilt, wenn zu einem angewählten PoC-Benutzer, bei dem es sich auch um eine PoC-Client-Einheit handelt, tatsächlich eine PoC-Kommunikationsverbindung aufgebaut wurde, und dieser PoC-Benutzer die Ptt-Verbindungsanfrage auch angenommen hat.
Gemäß der zweiten Variante, die auch als „Early Media Modus" bezeichnet wird, wird dem ersten PoC-Benutzer von der PoC- Server-Einheit bereits dann eine Freigabe zum Senden von Daten erteilt, obwohl noch keine Kommunikationsverbindung zwi- sehen der PoC-Server-Einheit und dem angewählten PoC-
Teilnehmer besteht. Der erste PoC-Teilnehmer kann somit nicht sicher sein, ob seine Daten vom zweiten PoC-Teilnehmer bereits empfangen wurden.
Zusätzliche Schwierigkeiten ergeben sich beim Aufbau einer
PoC-Session, wenn Daten unterschiedlichen Datentyps übertragen werden sollen, also nicht nur Sprachdaten, sondern auch Audiodaten (z.B. Musikdateien), Videodaten, Bilder, Textnach- richten oder andere textuelle Daten, wie dies auch im PoC Version 2.0-Standard vorgesehen ist. Schwierigkeiten können dabei etwa entstehen, wenn nicht jeder der PoC-Clients jeden Datentyp technisch verwerten kann, oder wenn ein bestimmter PoC-Client einen bestimmten Datentyp nicht empfangen möchte (etwa Sprach- oder Audiodaten, falls der Teilnehmer sein PoC- Gerät in bestimmten Situationen geräuschlos betreiben möchte) . In diesen Fällen können somit aus einer Gruppe verschiedener Datentypen, die in der Verbindungsanfrage eines PoC- Clients (dem sog. „PoC-Initiator" ) enthalten sind, von den anderen PoC-Clients lediglich Untergruppen von Datentypen akzeptiert werden. Gemäß dem Stand der Technik besitzt der PoC- Initiator somit keinerlei Möglichkeit festzustellen, ob und für welche Datentypen die anderen PoC-Clients empfangsbereit sind. Selbstverständlich könnte während einer PoC-Session erkannt werden, ob ein anderer Teilnehmer einen bestimmten Datentyp empfangen kann, zu diesem Zeitpunkt wurde die PoC- Session aber bereits erstellt, und verursacht bereits Kosten. Vorteilhaft wäre es stattdessen, wenn bereits vor Aufbau ei- ner PoC-Session entschieden werden kann, ob eine Verbindung zu einem Teilnehmer aufgebaut werden soll.
Diese Schwierigkeit findet im PoC Version 2.0-Standard Erwähnung, ohne dass hierfür eine Lösung vorgeschlagen wurde. Eine solche Lösung sollte möglichst einfach sein und sicher stellen, dass ein PoC-Client nur dann zu einer PoC-Session zugelassen wird, wenn er für zumindest einen gemeinsamen Datentyp mit allen anderen an der PoC-Session teilnehmenden PoC- Clients empfangsbereit ist.
Dieses Ziel wird durch ein Verfahren gemäß Anspruch 1, ein Push-to-talk-Gerät gemäß Anspruch 7, und eine Kommunikations- anordnung zum Aufbau einer Push-to-talk- Kommunikationsverbindung gemäß Anspruch 8 erreicht.
Anspruch 1 bezieht sich zunächst auf ein Verfahren zum Aufbau einer Push-to-talk- (Ptt) -Kommunikationsverbindung zwischen einem ersten Ptt-Gerät und einem zweiten Ptt-Gerät, bei der Daten unterschiedlichen Datentyps, wie etwa Sprachdaten, Audiodaten, Videodaten, Bilddaten, Textdaten, oder andere, tex- tuelle Daten, zwischen dem ersten und dem zweiten Ptt-Gerät übertragen werden, wobei das erste Ptt-Gerät eine Ptt-
Verbindungsanfrage für die gegenseitige Übertragung unterschiedlicher Datentypen an das zweite Ptt-Gerät übermittelt, und in weiterer Folge eine Kommunikationsverbindung für zumindest eine Auswahl dieser unterschiedlichen Datentypen über einen Kommunikationskanal gemäß eines Kommunikationsprotokolls aufgebaut wird. Erfindungsgemäß ist vorgesehen, dass in der Ptt-Verbindungsanfrage eine Prioritätsinformation enthalten ist, mit der den über den Kommunikationskanal zu übertragenden, unterschiedlichen Datentypen eine Übertragungspriori- tat zugewiesen wird, und das Kommunikationsprotokoll den Aufbau eines Kommunikationskanals mit dem zweiten Ptt-Gerät nur dann zulässt, wenn das zweite Ptt-Gerät für den Datentyp oder die Datentypen mit der höchsten Übertragungspriorität verfügbar ist, und die Übermittlung eines Datentyps mit niedrigerer Übertragungspriorität über diesen Kommunikationskanal nur dann zulässt, wenn das zweite Ptt-Gerät für diesen Datentyp verfügbar ist, und das zweite Ptt-Gerät auch für alle Datentypen mit höherer Übertragungspriorität verfügbar ist.
Somit wird eine „Rangliste" der unterschiedlichen Datentypen erstellt, die entweder für jede PoC-Session dieselbe ist, o- der durch den PoC-Initiator vor dem Aufbau der PoC-Session festgelegt werden kann. Ein PoC-Client, der zu einer PoC- Session geladen wird, kann erfindungsgemäß nur dann teilnehmen, wenn er den Datentyp mit der höchsten Übertragungspriorität unterstützt. Für einen Datentyp mit niedrigerer Priorität darf der eingeladenen PoC-Client wiederum nur dann teil- nehmen, wenn er alle Datentypen mit höherer Übertragungspriorität unterstützt. Dieses Kommunikationsprotokoll erlaubt es dem PoC-Initiator daher, vor der PoC-Session festzulegen, dass jeder teilnehmende PoC-Client zumindest einen Datentyp unterstützt, und zwar jenen, dem der PoC-Initiator die höchs- te Priorität verliehen hat.
Die Übertragung der Datentypen erfolgt dabei über Kommunikationskanäle, worunter organisatorische Übertragungswege verstanden werden, in denen ein Kommunikationsprotokoll für die Übertragung einer Gruppe von Datentypen, die diesem Kommunikationsprotokoll unterliegen, implementiert ist. Solche Kommunikationskanäle werden auch als „Media Floor Control Enti- ties" bezeichnet, wobei es sich bei den „Media" um die gegenständlichen Datentypen handelt, und bei einer „Media Floor Control" um ein Kommunikationsprotokoll. Dabei ist es üblich, dass die Übertragung kontinuierlicher (Echtzeit-) Datentypen wie etwa Sprach-, Audio- oder Videodaten über einen Kommunikationskanal erfolgt, bei diskreten (Nicht-Echtzeit- ) Datentypen wie etwa Textnachrichten oder textuelle Dateien ist es aber nicht üblich, einen eigenen Kommunikationskanal zu wählen.
Wie noch näher ausgeführt werden wird, ist es aber im Rahmen der Erfindung vorteilhaft, auch für diskrete Datentypen einen Kommunikationskanal zu definieren. Daher sieht Anspruch 2 vor, dass für eine erste Untergruppe der zu übertragenden, unterschiedlichen Datentypen ein erster Kommunikationskanal verwendet wird, und für eine zweite Untergruppe der zu über- tragenden, unterschiedlichen Datentypen ein zweiter Kommuni¬ kationskanal verwendet wird.
Durch diese Maßnahme wird es insbesondere möglich, die Merk- male von Anspruch 3 zu verwirklichen, dem zu Folge in der Ptt-Verbmdungsanfrage eine Prioritatsinformation enthalten ist, mit der den Kommunikationskanalen eine Ubertragungspπo- πtat zugewiesen wird, und das Kommunikationsprotokoll den Aufbau des Kommumkationskanals mit der niedrigeren Ubertra- gungsprioritat nur dann zulasst, wenn ein Aufbau des Kommumkationskanals mit der höheren Ubertragungsprioritat erfolgt.
Gemäß Anspruch 4 handelt es sich bei der Ptt- Kommunikationsverbindung um eine Mobilfunk- Kommunikationsverbindung, etwa zum Aufbau einer PoC-Session. Gemäß Anspruch 5 erfolgt die Ptt-Verbmdungsanfrage mithilfe einer SIP-INVITE-Nachπcht . Die Zuweisung der Ubertragungsprioritat kann etwa gemäß Anspruch 6 im Session Description Protocol erfolgen.
Anspruch 7 bezieht sich auf ein Push-to-talk- (Ptt) -Gerat zum Aufbau einer Push-to-talk- (Ptt ) -Kommunikationsverbindung zu einem weiteren Ptt-Gerat, bei der Daten unterschiedlichen Datentyps, wie etwa Sprachdaten, Audiodaten, Videodaten, BiId- daten, Textdaten, oder andere, textuelle Daten, zwischen dem ersten und dem zweiten Ptt-Gerat über einen Kommunikationska- nal gemäß eines Kommunikationsprotokolls übertragen werden. Erfmdungsgemaß ist bei einem solchen Gerat vorgesehen, dass eine Einheit zum Erstellen einer Ptt-Verbmdungsanfrage vor- gesehen ist, die eine Prioritatsinformation enthalt, mit der den über den Kommunikationskanal zu übertragenden, unterschiedlichen Datentypen eine Ubertragungsprioritat zugewiesen wird, und mit einer Sendeeinheit zum Senden der Ptt- Verbindungsanfrage an ein weiteres Ptt-Gerat ausgestattet ist.
Schließlich wird gemäß Anspruch 8 eine Kommunikationsanord- nung zum Aufbau einer Push-to-talk- (Ptt) -
Kommunikationsverbindung mit einem ersten Ptt-Gerat und einem zweiten Ptt-Gerat, zwischen denen Daten unterschiedlichen Datentyps, wie etwa Sprachdaten, Audiodaten, Videodaten, Bilddaten, Textdaten, oder andere, textuelle Daten, über einen Kommunikationskanal gemäß eines Kommunikationsprotokolls u- bertragen werden, sowie einem Ptt-Server, vorgeschlagen. Hierbei wird erfmdungsgemaß vorgeschlagen, dass die Ptt- Gerate jeweils eine Einheit zum Erstellen einer Ptt- Verbmdungsanfrage, sowie eine Sendeeinheit zum Senden der Ptt-Verbindungsanfrage an ein weiteres Ptt-Gerat umfassen, wobei die Ptt-Verbindungsanfrage des ersten Ptt-Gerats eine Prioπtatsinformation enthalt, mit der den über den Kommuni¬ kationskanal zu übertragenden, unterschiedlichen Datentypen eine Ubertragungsprioritat zugewiesen wird, und der Ptt- Server mit einem Kommunikationsprotokoll ausgestattet ist, das den Aufbau eines Kommunikationskanals zwischen dem ersten Ptt-Gerat und dem zweiten Ptt-Gerat nur dann zulasst, wenn das zweite Ptt-Gerat für den Datentyp oder die Datentypen mit der höchsten Ubertragungsprioritat verfugbar ist, und die U- bermittlung eines Datentyps mit niedrigerer Ubertragungsprioritat über diesen Kommunikationskanal nur dann zulasst, wenn das zweite Ptt-Gerat für diesen Datentyp verfugbar ist, und das zweite Ptt-Gerat auch für alle Datentypen mit höherer U- bertragungsprioritat verfugbar ist.
Die Erfindung wird im folgenden anhand der beiliegenden Figuren naher erläutert. Hierbei zeigen die Fig. 1 eine schematische Darstellung einer Kommunikationsanordnung mit einem PoC-Initiator, einer PoC-Server-Einheit , sowie drei weiteren PoC-Teilnehmern, die vom PoC-Initiator kontaktiert werden,
Fig. 2 eine schematische Darstellung des herkömmlichen Aufbaus einer PoC-Session in einer Kommunikationsanordnung gemäß Fig. I1
Fig. 3 eine schematische Darstellung des Aufbaus einer PoC-
Session in einer Kommunikationsanordnung gemäß Fig. 1 für eine erste Ausführungsform der Erfindung, und die
Fig. 4 eine schematische Darstellung des Aufbaus einer PoC- Session in einer Kommunikationsanordnung gemäß Fig. 1 für eine zweite Ausführungsform der Erfindung. Die Erfindung bezieht sich allgemein auf Push-to-talk- (Ptt) Kommunikationsanordnungen mit Ptt-Clients bzw. Ptt- Geräten 1,2 und zumindest einer Ptt-Server-Einheit 3. Im fol- genden soll die Erfindung in Bezug auf eine spezielle Anordnung dieser Art erläutert werden, nämlich eine Push-to-talk- over-Cellular (PoC) -Kommunikationsanordnung mit einem PoC- Initiator 1, einer PoC-Server-Einheit 3, sowie drei weiteren PoC-Clients 2a, 2b, 2c, die vom PoC-Initiator 1 kontaktiert werden. Die PoC-Clients 1,2a, 2b, 2c sind jeweils eingerichtet zur Kommunikation gemäß dem UMTS-Standard, dem GSM-Standard, dem GPRS-Standard, oder einem anderen Mobilfunk-Kommunikationsstandard.
Allgemein wird im Rahmen der Erfindung unter einer
PoC-Kommunikation eine Kommunikation zwischen den PoC-Clients 1,2a, 2b, 2c über eine Mobilfunk-Schnittstelle verstanden, bei der der Sender, beispielsweise durch Auswahl einer speziellen Drucktaste des PoC-Geräts, Sprachdaten an mindestens einen Empfänger, vorzugsweise an mehrere Empfänger, gleichzeitig gemäß dem Duplex-Verfähren, vorzugsweise gemäß dem HaIb- duplex-Verfahren, übermitteln kann. Das setzt voraus, dass bereits eine PoC-Session aufgebaut wurde, wobei der Sender und der Empfänger ein jeder der PoC-Clients 1,2a, 2b, 2c sein kann. Gemäß dem Halbduplex-Verfahren kann nur der Benutzer der Sendeeinheit sprechen, die Benutzer der Empfängereinheiten können den Benutzer der Sendeeinheit nur hören und nicht unterbrechen.
Gemäß der PoC-Technologie werden die eingesprochenen Sprachdaten üblicherweise schon während des Einsprechens der Sprachdaten durch einen PoC-Client 1,2a, 2b, 2c über das IMS (IP Multimedia Subsystem) -Kern-Kommunikationsnetz zu den an¬ deren PoC-Clients 1,2a, 2b, 2c verteilt. Diese Technologie wird auch als „Streaming" bezeichnet. Damit kann eine PoC- Kommunikationsverbindung mit dem bekannten CB-Funk verglichen werden, allerdings mit dem großen Unterschied, dass die Teil- nehmer einer PoC-Verbindung weltweit erreichbar sind, da die Übertragung der Daten über ein Mobilfunk-Netzwerk erfolgt.
Für den Fall, dass der Sender immer wieder die gleichen Empfänger ansprechen möchte, ist im Rahmen des PoC-Dienstes für jeden PoC-Client 1,2a, 2b, 2c vorgesehen, sich seine persönlichen, fest vorgegebenen Gruppen von PoC-Clients 1,2a, 2b, 2c zu definieren. So kann beispielsweise eine Gruppe von PoC-Clients 2a, 2b, 2c und deren jeweilige Adressen definiert werden. Die Adressen können beispielsweise in Form einer Te- lefonnummer als Session Initiation Protocol-Unique Resource
Locator (SIP-URL) , oder in Form einer Session Initiation Pro- tocol-Adresse (SIP-Adresse als SIP-URL) angegeben werden. Die benutzerdefinierte Gruppe von PoC-Clients 2a, 2b, 2c erhält da- bei üblicherweise eine eigene Gruppen-Adresse, beispielsweise ebenfalls in Form einer SIP-URL, sodass der PoC-Initiator 1 beim Aufbau einer PoC-Session alle Gruppenmitglieder mittels der PoC-Server-Einheit 3 adressieren und zur PoC-Session ein- laden kann. Hierbei wird die PoC-Verbindungsanfrage an alle in der jeweiligen Gruppe enthaltenen PoC-Clients 2a, 2b, 2c ü- bermittelt .
Die PoC-Clients 1,2a, 2b, 2c sowie die PoC-Server-Einheit 3 sind in der Regel zur Kommunikation gemäß dem Session Initiation Protocol (SIP) eingerichtet, sowie in den unteren Kommunikationsschichten, d.h. in der Transportschicht, zur Kommunikation gemäß dem Transport Control Protocol (TCP) und/oder User Datagramm Protocol (UDP) , sowie in der Vermittlungs- schicht zur Kommunikation gemäß dem Internet Protocol (IP). Die PoC-Kommunikationsanordnung gemäß Fig. 1 ist somit zur Kommunikation basierend auf dem IP Multimedia Subsystem (IMS) eingerichtet .
Nach erfolgtem Aufbau einer PoC-Session erfolgt die Übertragung von Nutzdaten, insbesondere von Sprachdaten, aber auch von Audio-, Video- oder Textdaten, ausgehend vom ersten PoC-Client 1 gemäß dem Halbduplex-Verfahren zu den in der jeweils angewählten Gruppe angegebenen PoC-Clients 2a, 2b, 2c ü- ber das IP-basierte Kommunikationsnetz sowie über die PoC-Server-Einheit 3.
Wie in der Fig. 1 dargestellt ist, sind die PoC-Clients 1,2a, 2b, 2c mittels jeweils einer Mobilfunk-Schnittstelle mit der PoC-Server-Einheit 3 verbunden, wobei die Mobilfunk-Schnittstellen in jenen Fällen, in denen die Kommunikationsanordnung auf dem UMTS-Standard beruht, mittels des Ra- dio Access Network (RAN) , des Core Network (CN) und des IP Multimedia Subsystems aufgebaut sein können.
Wie in der Fig. 2 in einem ersten Nachrichtenflussdiagramm dargestellt ist, wird vom PoC-Initiator 1 zunächst eine SIP-INVITE-Nachricht mittels des UMTS-Core Network (UMTS-Kern-Kommunikationsnetz) zu der PoC-Server-Einheit 3 übertragen. Bei den zu übertragenden Datentypen kann es sich etwa um Sprachdaten Sp, Audiodaten A, Videodaten V, Bilddaten I, Textdaten T, oder sonstige, textuelle Daten F (z.B. Dateien) handeln. Wie in der Fig. 2 dargestellt ist, kann beispielsweise PoC-Initiator 1 alle diese Datentypen senden und empfangen, und lädt daher alle anderen PoC-Clients 2a, 2b, 2c in seiner PoC-Verbindungsanfrage zu einer PoC-Session ein, in der alle diese Datentypen ausgetauscht werden sollen. Dabei wird für die Sprachdaten Sp, Audiodaten A, Videodaten V und Bilddaten I ein Kommunikationskanal Fl definiert. Für die diskreten Datentypen, also etwa die Textdaten T und die sonstigen Daten F, wird ein zweiter Kommunikationskanal NF defi- niert.
Die in Fig. 2 gezeigte PoC-Verbindungsanfrage ergeht in Form einer SIP-INVITE-Nachricht zunächst an die PoC-Server-Einheit 3, die sie an die ausgewählten PoC-Clients 2a, 2b, 2c weiter- leitet. PoC-Client 2a unterstützt dabei beispielsweise nur Sprachdaten Sp, und ist auch für eine PoC-Session verfügbar. PoC-Client 2a akzeptiert daher den Aufbau eines Kommunikationskanals Fl für Sprachdaten Sp.
PoC-Client 2b unterstützt in diesem Beispiel Sprachdaten Sp, Audiodaten A und Videodaten V, und ist ebenfalls für eine PoC-Session verfügbar. PoC-Client 2b akzeptiert daher den Aufbau eines Kommunikationskanals Fl für Sprachdaten Sp, Audiodaten A und Videodaten V.
PoC-Client 2c unterstützt in diesem Beispiel zwar alle Daten- typen, ist aber nur für Bilddaten I, sonstige Daten F und
Textdaten T für eine PoC-Session verfügbar. So könnte es etwa sein, dass sich PoC-Client 2c in einer Besprechung befindet, und sein PoC-Gerät lautlos betreiben möchte. PoC-Client 2c akzeptiert daher den Aufbau eines Kommunikationskanals Fl für Bilddaten I, und den Aufbau eines Kommunikationskanals NF für sonstige Daten F und Textdaten T.
Die PoC-Server-Einheit 3 sendet somit die Antwort an den PoC- Initiator 1, dass Bedarf am Aufbau von Kommunikationskanal Fl und NF für alle Datentypen besteht. Es wird in weiterer Folge in bekannter Weise die PoC-Session aufgebaut, wobei aber PoC- Client 2c mit den PoC-Clients 2a und 2b nicht kommunizieren kann. Gemäß dem Stand der Technik wird PoC-Initiator 1 vor dem Beginn der PoC-Session auch nicht erfahren, dass einer der Teilnehmer, nämlich PoC-Client 2c, keine Sprachdaten Sp empfängt. Die PoC-Session wird in herkömmlicher Weise dennoch aufgebaut und verrechnet.
In der Fig. 3 ist im Gegensatz dazu gezeigt, welche Wirkung das erfindungsgemäße Kommunikationsprotokoll auf den Aufbau einer PoC-Session hat. Wie in Fig. 2 gezeigt, ergeht zunächst eine PoC-Verbindungsanfrage in Form einer
SIP-INVITE-Nachricht an die PoC-Server-Einheit 3, die sie an die ausgewählten PoC-Clients 2a, 2b, 2c weiterleitet. Die Er- findung bedingt zunächst keine Änderungen in der Initiierung einer PoC-Session mithilfe des Session Initiation Protocols. Erfmdungsgemaß ist in dieser PoC-Verbmdungsanfrage, etwa im Session Descπption Protocol, m einem gegenüber dem Stand der Technik zusatzlich vorgesehenen Nachrichtenfeld aber eine Prioπtatsmformation enthalten, mit der den zu ubertragen- den, unterschiedlichen Datentypen Sp, A, V, I, T und F eine Ubertragungsprioritat zugewiesen wird. Sind mehr als ein Kom- munikationskanal vorgesehen, etwa zwei Kommunikationskanale Fl und NF, in denen jeweils eine Gruppe von Datentypen organisatorisch zusammengefasst ist, können Ubertragungspπorita- ten für die jeweilige Gruppe an Datentypen definiert werden. So ist in der Fig. 3 etwa dargestellt, dass PoC-Initiator 1 den Sprachdaten Sp die höchste Priorität verleiht, den Audiodaten eine niedrigere Priorität, usw. Den Bilddaten I wird im Kommunikationskanal Fl m diesem Beispiel die niedrigste Pn- oritat verliehen. Im Kommunikationskanal NF haben die sonstigen Daten F eine höhere Ubertragungsprioritat als die Textdaten T.
Zur praktischen Ausfuhrung der Erfindung verfugt der PoC- Initiator 1 über eine Einheit (in den Fig. 3 und 4 nicht ersichtlich) zum Erstellen einer PoC-Verbmdungsanfrage, die eine Prioritatsmformation enthalt, mit der den über den Kommunikationskanal Fl, NF zu übertragenden, unterschiedlichen Datentypen Sp,A,V,I,T,F eine ubertragungsprioritat zugewiesen wird, und über eine Sendeeinheit (m den Fig. 3 und 4 nicht ersichtlich) zum Senden der PoC-Verbmdungsanfrage an einen weiteren PoC-Client 2.
Mit Bezug auf die Fig. 3 unterstutzt PoC-Client 2a wiederum nur Sprachdaten Sp, und ist auch für eine PoC-Session verfugbar. PoC-Client 2a akzeptiert daher den Aufbau eines Kommunikationskanals Fl für Sprachdaten Sp. Das wird vom Kommunika- tionsprotokoll zugelassen, da PoC-Client 2a für den Datentyp mit der höchsten Ubertragungsprioritat verfugbar ist, nämlich für Sprachdaten Sp.
PoC-Client 2b unterstutzt wiederum Sprachdaten Sp, Audiodaten Ä und Videodaten V, und ist ebenfalls für eine PoC-Session verfugbar. PoC-Client 2b akzeptiert daher den Aufbau eines Kommunikationskanals Fl für Sprachdaten Sp, Audiodaten A und Videodaten V. Vom Kommunikationsprotokoll wird zunächst der Aufbau eines Kommunikationskanals Fl für Sprachdaten zugelas- sen, da es sich hierbei um den Datentyp mit der höchsten U- bertragungsprioritat handelt. Aber auch die Übermittlung des Datentyps A mit niedrigerer Ubertragungsprioritat über diesen Korπmunikationskanal Fl wird zugelassen, da PoC-Client 2b auch für alle Datentypen mit höherer Ubertragungsprioritat, also Sprachdaten Sp, verfugbar ist. Des Weiteren wird auch die U- bermittlung des Datentyps V mit niedrigerer Ubertragungsprioritat über diesen Kommunikationskanal Fl zugelassen, da PoC- Client 2b auch für alle Datentypen mit höherer Ubertragungsprioritat, also Sprachdaten Sp und Audiodaten A, verfugbar ist.
PoC-Client 2c unterstutzt wiederum alle Datentypen, ist aber nur für Bilddaten I, sonstige Daten F und Textdaten T verfugbar. PoC-Client 2c akzeptiert daher den Aufbau eines Kommuni- kationskanals Fl für Bilddaten I, und den Aufbau eines Kommunikationskanals NF für sonstige Daten F und Textdaten T. Da PoC-Client 2c aber für den Datentyp mit der höchsten Ubertragungsprioritat, nämlich für Sprachdaten Sp, nicht verfugbar ist, wird der Kommunikationskanal Fl zu PoC-Client 2c nicht aufgebaut, obwohl PoC-Client 2c für Bilddaten I verfugbar wäre. Hierin äußert sich der Unterschied des erfmdungsgemaßen Kommunikationsprotokolls gegenüber dem Stand der Technik gemäß Fig. 2. Da PoC-Client 2c aber für den Datentyp mit der höchsten Übertragungspriorität im Kommunikationskanal NF verfügbar ist, nämlich für sonstige Daten F, wird der Kommunikationskanal NF aufgebaut. Aber auch die Übermittlung des Datentyps T mit niedrigerer Übertragungspriorität wird über diesen Kommunikationskanal Fl zugelassen, da PoC-Client 2c auch für alle Datentypen mit höherer Übertragungspriorität, nämlich sonstige Daten F, verfügbar ist.
In diesem Anwendungsbeispiel würden somit die PoC-Clients 2a und 2b mit dem PoC-Initiator 1 Sprachdaten Sp austauschen, und der PoC-Client 2c Textdaten T und sonstige Daten F.
Das erfindungsgemäße Verfahren löst die erfindungsgemäße Auf¬ gabe somit für jene Fälle vollständig, in denen lediglich ein einziger Kommunikationskanal definiert ist. Falls mehrere Kommunikationskanäle definiert sind, wie in der Fig. 3, kann es noch zu PoC-Sessions kommen, in denen nicht alle Teilneh- mer zumindest einen Datentyp teilen können.
Daher kann eine weitere Ausführungsform vorgesehen sein, die in der Fig. 4 dargestellt ist. Hierbei ist in der PoC- Verbindungsanfrage, etwa im Session Description Protocol, in einem gegenüber dem Stand der Technik zusätzlich vorgesehenen Nachrichtenfeld eine weitere Prioritätsinformation enthalten, mit der auch den Kommunikationskanälen Fl, NF eine Übertragungspriorität zugewiesen wird, und das Kommunikationsprotokoll den Aufbau des Kommunikationskanals NF mit der niedrige- ren Übertragungspriorität nur dann zulässt, wenn ein Aufbau des Kommunikationskanals Fl mit der höheren Übertragungspriorität erfolgt. Diese Regel lässt den Aufbau von Kommunikationskanälen mit den PoC-Clients 2a und 2b zunächst unverän- dert, wie ein Vergleich der Fig. 4 mit der Fig. 3 zeigt, da ohnehin der Kommunikationskanal Fl mit der höchste Übertra¬ gungspriorität aufgebaut wird.
Hinsichtlich PoC-Client 2c zeigt sich aber nun, dass das erfindungsgemäße Kommunikationsprotokoll nun den Aufbau des Kommunikationskanals NF nicht zulässt, da kein Aufbau des Kommunikationskanals Fl mit der höheren Übertragungspriorität erfolgt. Dadurch wird keine PoC-Session mit PoC-Client aufge- baut. An der PoC-Session mit dem PoC-Initiator 1 nehmen stattdessen lediglich die PoC-Clients 2a und 2b teil, wobei alle Teilnehmer Sprachdaten Sp austauschen können, und somit zumindest einen Datentyp teilen können.
Die Erfindung stellt somit auch in diesen Fällen sicher, dass ein PoC-Client 2a, 2b, 2c nur dann zu einer PoC-Session zugelassen wird, wenn er für zumindest einen gemeinsamen Datentyp mit allen anderen an der PoC-Session teilnehmenden PoC- Clients empfangsbereit ist.
Hinsichtlich Fig. 4 kann bemerkt werden, dass bei einer Um¬ kehrung der Prioritätszuordnung zu den Kommunikationskanälen Fl und NF der Aufbau der PoC-Session nur mit PoC-Client 2c erfolgt. In diesem Fall hat nämlich der Kommunikationskanal NF eine höhere Übertragungspriorität als der Kommunikationskanal Fl, sodass das erfindungsgemäße Kommunikationsprotokoll den Aufbau des Kommunikationskanals Fl mit den PoC-Clients 2a und 2b nicht zulässt, da kein Aufbau des Kommunikationskanals NF mit der höheren Übertragungspriorität erfolgt ist.
Eine weitere Ausführungsform des erfindungsgemäßen Verfahrens besteht darin, den Datentypen eine Übertragungspriorität unabhängig von deren Zuteilung zu Kommunikationskanälen zuzu- ordnen. Mehrere Datentypen können somit dieselbe Übertragungspriorität besitzen, aber jeder Datentyp besitzt lediglich eine Prioritätszuordnung. Der PoC-Initiator 1 könnte etwa Sprachdaten Sp, Audiodaten A und Videodaten V jeweils die höchste Übertragungspriorität verleihen, Bilddaten I die zweithöchste Priorität, und allen anderen Datentypen die niedrigste Priorität. Die PoC-Clients 2a, 2b und 2c können an der PoC-Session somit nur dann teilnehmen, wenn sie für Sprachdaten Sp, Audiodaten A und Videodaten V verfügbar sind. In Bezug auf das Beispiel von Fig. 4 würde das bedeuten, dass nur PoC-Client 2b an einer PoC-Session mit dem PoC-Initiator 1 teilnehmen könnte.
Die Erfindung stellt daher eine besonders einfache, aber auch vielseitige Möglichkeit dar, einen PoC-Client 2a, 2b, 2c nur dann zu einer PoC-Session zuzulassen, wenn er für gewünschte Datentypen des PoC-Initiators 1 empfangsbereit ist.

Claims

Patentansprüche
1. Verfahren zum Aufbau einer Push-to-talk- (Ptt ) -
Kommunikationsverbindung zwischen einem ersten Ptt-Gerät (1) und einem zweiten Ptt-Gerät (2), bei der Daten un¬ terschiedlichen Datentyps, wie etwa Sprachdaten (Sp), Audiodaten (A), Videodaten (V), Bilddaten (I), Textdaten (T), oder andere, textuelle Daten (F) zwischen dem ersten Ptt-Gerät (1) und dem zweiten Ptt-Gerät (2) übertra- gen werden, wobei das erste Ptt-Gerät (1) eine Ptt-
Verbindungsanfrage für die gegenseitige Übertragung unterschiedlicher Datentypen (Sp, A, V, I, T, F) an das zweite Ptt-Gerät (2) übermittelt, und in weiterer Folge eine Kommunikationsverbindung für zumindest eine Auswahl die- ser unterschiedlichen Datentypen (Sp, A, V, I, T, F) über einen Kommunikationskanal (Fl, NF) gemäß eines Kommunikationsprotokolls aufgebaut wird, dadurch gekennzeichnet, dass in der Ptt-Verbindungsanfrage eine Prioritätsinfor- mation enthalten ist, mit der den über den Kommunikationskanal (Fl, NF) zu übertragenden, unterschiedlichen Datentypen (Sp, A, V, I, T, F) eine Übertragungspriorität zugewiesen wird, und das Kommunikationsprotokoll den Aufbau eines Kommunikationskanals (Fl, NF) mit dem zweiten Ptt- Gerät (2) nur dann zulässt, wenn das zweite Ptt-Gerät
(2) für den Datentyp oder die Datentypen (Sp, A, V, I, T, F) mit der höchsten Übertragungspriorität verfügbar ist, und die Übermittlung eines Datentyps (Sp, A, V, I, T, F) mit niedrigerer Übertragungspriorität über diesen Kommunika- tionskanal (Fl, NF) nur dann zulässt, wenn das zweite
Ptt-Gerät (2) für diesen Datentyp (Sp, A, V, I, T, F) verfügbar ist, und das zweite Ptt-Gerät (2) auch für alle Da- tentypen (Sp, A, V, I, T, F) mit höherer Übertragungspriorität verfügbar ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für eine erste Untergruppe (Sp, A, V, I) der zu übertragenden, unterschiedlichen Datentypen (Sp, A, V, I, T, F) ein erster Kommunikationskanal (Fl) verwendet wird, und für eine zweite Untergruppe (T, F) der zu übertragenden, unterschiedlichen Datentypen (Sp, A, V, I, T, F) ein zweiter Kommunikationskanal (NF) verwendet wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass in der Ptt-Verbindungsanfrage eine Prioritätsinformation enthalten ist, mit der den Kommunikationskanälen (Fl, NF) eine Übertragungspriorität zugewiesen wird, und das Kommunikationsprotokoll den Aufbau des Kommunikationskanals (Fl, NF) mit der niedrigeren Übertragungsprio- rität nur dann zulässt, wenn ein Aufbau des Kommunikationskanals (Fl, NF) mit der höheren Übertragungspriorität erfolgt .
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es sich bei der Ptt-Kommunikationsverbindung um eine Mobilfunk-Kommunikationsverbindung handelt.
5 . Verfahren nach einem der Ansprüche 1 bis 4 , d a d u r c h g e k e n n z e i c h n e t , dass die Ptt-Verbindungsanfrage mithilfe einer SIP- INVITE-Nachricht erfolgt.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Zuweisung der Übertragungspriorität im Session Description Protocol erfolgt.
7. Push-to-talk- (Ptt) -Gerät (1) zum Aufbau einer Push-to- talk- (Ptt) -Kommunikationsverbindung zu einem weiteren Ptt-Gerät (2) , bei der Daten unterschiedlichen Datentyps (Sp, A, V, I, T, F) , wie etwa Sprachdaten (Sp), Audiodaten
(A), Videodaten (V), Bilddaten (I), Textdaten (T), oder andere, textuelle Daten (F), zwischen dem ersten Ptt- Gerät (1) und dem zweiten Ptt-Gerät (2) über einen Kommunikationskanal (Fl, NF) gemäß eines Kommunikationspro- tokolls übertragen werden, dadurch gekennzeichnet, dass eine Einheit zum Erstellen einer Ptt- Verbindungsanfrage vorgesehen ist, die eine Prioritätsinformation enthält, mit der den über den Kommunikati- onskanal (Fl, NF) zu übertragenden, unterschiedlichen Datentypen (Sp, A, V, I, T, F) eine Übertragungspriorität zugewiesen wird, und mit einer Sendeeinheit zum Senden der Ptt-Verbindungsanfrage an ein weiteres Ptt-Gerät (2) ausgestattet ist.
8. Kommunikationsanordnung zum Aufbau einer Push-to-talk- ( Ptt) -Kommunikationsverbindung mit einem ersten Ptt- Gerät (1) und einem zweiten Ptt-Gerät (2), zwischen de- nen Daten unterschiedlichen Datentyps (Sp, A, V, I, T, F) , wie etwa Sprachdaten (Sp) , Audiodaten (A) , Videodaten (V), Bilddaten (I), Textdaten (T), oder andere, textuel- Ie Daten (F), über einen Kommunikationskanal (Fl, NF) gemäß eines Kommunikationsprotokolls übertragen werden, sowie einem Ptt-Server (3), dadurch gekennzeichnet, dass die Ptt-Geräte (1,2) jeweils eine Einheit zum Erstellen einer Ptt-Verbindungsanfrage, sowie eine Sendeeinheit zum Senden der Ptt-Verbindungsanfrage an ein weiteres Ptt-Gerät (1,2) umfassen, wobei die Ptt- Verbindungsanfrage des ersten Ptt-Geräts (1) eine Prioritätsinformation enthält, mit der den über den Kommunikationskanal (Fl, NF) zu übertragenden, unterschiedlichen Datentypen (Sp, A, V, I, T, F) eine Übertragungspriorität zu- gewiesen wird, und der Ptt-Server (3) mit einem Kommunikationsprotokoll ausgestattet ist, das den Aufbau eines Kommunikationskanals (Fl, NF) zwischen dem ersten Ptt- Gerät (1) und dem zweiten Ptt-Gerät (2) nur dann zu- lässt, wenn das zweite Ptt-Gerät (2) für den Datentyp oder die Datentypen (Sp, A, V, I, T, F) mit der höchsten Ü- bertragungspriorität verfügbar ist, und die Übermittlung eines Datentyps (Sp, A, V, I, T, F) mit niedrigerer Übertragungspriorität über diesen Kommunikationskanal (Fl, NF) nur dann zulässt, wenn das zweite Ptt-Gerät (2) für die- sen Datentyp (Sp, A, V, I, T, F) verfügbar ist, und das zweite Ptt-Gerät (2) auch für alle Datentypen (Sp, A, V, I, T, F) mit höherer Übertragungspriorität verfügbar ist.
EP07728862A 2006-05-08 2007-05-07 Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung Withdrawn EP2018754A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006021375A DE102006021375B4 (de) 2006-05-08 2006-05-08 Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung
PCT/EP2007/054409 WO2007128809A1 (de) 2006-05-08 2007-05-07 Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung

Publications (1)

Publication Number Publication Date
EP2018754A1 true EP2018754A1 (de) 2009-01-28

Family

ID=37441975

Family Applications (2)

Application Number Title Priority Date Filing Date
EP06122756A Withdrawn EP1855437A1 (de) 2006-05-08 2006-10-23 Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung
EP07728862A Withdrawn EP2018754A1 (de) 2006-05-08 2007-05-07 Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP06122756A Withdrawn EP1855437A1 (de) 2006-05-08 2006-10-23 Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung

Country Status (5)

Country Link
US (1) US8855697B2 (de)
EP (2) EP1855437A1 (de)
BR (1) BRPI0712537A2 (de)
DE (1) DE102006021375B4 (de)
WO (1) WO2007128809A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4672334B2 (ja) * 2004-11-04 2011-04-20 パナソニック株式会社 通信方法及び通信端末
GB0617862D0 (en) * 2006-09-11 2006-10-18 Sepura Ltd Mobile communications systems
US7949006B2 (en) * 2006-11-09 2011-05-24 Motorola Mobility, Inc. System and method for media burst control of discrete content for push-to-cellular communication
US8903445B2 (en) * 2008-04-08 2014-12-02 Optis Wireless Technology, Llc PoC server and a mobile terminal comprising a PoC client for providing PoC communication services
JP2012080257A (ja) * 2010-09-30 2012-04-19 Canon Inc 提供装置、配信装置、その処理方法及びプログラム
US9301335B1 (en) * 2013-07-31 2016-03-29 Sprint Spectrum L.P. Method and system for using a proxy device to throttle communications between a tethered device and a network
CN108200656B (zh) * 2018-02-08 2019-04-26 深圳安信卓科技有限公司 信道抢占系统及方法
JP6407461B1 (ja) * 2018-02-27 2018-10-17 株式会社シアンス・アール 信号処理装置、通信システム、信号処理装置で実施される方法、及び信号処理装置で実行されるプログラム
CN112202763B (zh) * 2020-09-28 2022-04-22 杭州安恒信息技术股份有限公司 一种ids策略生成方法、装置、设备及介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7130282B2 (en) * 2002-09-20 2006-10-31 Qualcomm Inc Communication device for providing multimedia in a group communication network
GB0319360D0 (en) * 2003-08-18 2003-09-17 Nokia Corp Setting up communication sessions
US20050124365A1 (en) * 2003-12-05 2005-06-09 Senaka Balasuriya Floor control in multimedia push-to-talk
EP1619854A1 (de) * 2004-07-21 2006-01-25 Siemens Mobile Communications S.p.A. Erweiterte SIP Nachricht für einen drücken-zum-betrachten Dienst

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007128809A1 *

Also Published As

Publication number Publication date
WO2007128809A1 (de) 2007-11-15
DE102006021375B4 (de) 2008-03-06
EP1855437A1 (de) 2007-11-14
BRPI0712537A2 (pt) 2012-12-25
US20090280851A1 (en) 2009-11-12
DE102006021375A1 (de) 2007-11-15
US8855697B2 (en) 2014-10-07

Similar Documents

Publication Publication Date Title
EP1597935B1 (de) Verfahren zum verwalten von kommunikationssitzungen
EP2018754A1 (de) Verfahren zum aufbau einer push-to-talk-kommunikationsverbindung
DE102004053597B4 (de) Verfahren zum automatischen Erzeugen und/oder Steuern einer Telekommunikations-Konferenz mit einer Vielzahl von Teilnehmern, Telekommunikations-Konferenz-Endgerät und Telekommunikations-Konferenz-Servereinrichtung
DE102005016587B4 (de) Verfahren zum Bilden einer gemeinsamen Kommunikationssitzung, Verfahren zum Bilden einer ersten Kommunikationssitzung und einer zweiten Kommunikationssitzung aus einer gemeinsamen Kommunikationssitzung und Kommunikationssitzungs-Steuerungs-Server
DE102005037569A1 (de) Verfahren zum Vergeben eines Kommunikationsrechts, Kommunikationskonferenz-Sitzung-Server und Kommunikationskonferenz-Sitzung-Server-Anordnung
DE102004063298B4 (de) Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
DE102004010925B4 (de) Verfahren und Kommunikationsanordnung zum Aufbauen einer Push-to-talk-Kommunikationsverbindung und Push-to-talk-Client-Einheit
DE102010021770B4 (de) Verfahren und Vorrichtung zum Anfordern einer Medien-Replikation in einer kollaborativen Kommunikationssitzung und Verfahren und Vorrichtung zum Zuweisen eines Kommunikations-Mediums einer kollaborativen Kommunikationssitzung
DE602004007552T2 (de) Verfahren und einrichtung für push-to-talk-dienst
DE102005049077B4 (de) Verfahren zum Übertragen von Mediendaten, Kommunikationsnetzwerk-Einheit und Computerprogrammelement
WO2005009066A2 (de) Beschleunigter aufbau einer verbindung zwischen mehreren mobilfunkteilnehmern
DE102005039668B4 (de) Verfahren zum rechnergestützten Bilden einer Konferenzsitzungs-Einladungsnachricht, Verfahren zum rechnergestützten Erzeugen einer Konferenzsitzung, Verfahren zum rechnergestützten Verarbeiten von Nachrichten in einer Konferenzsitzung, Konferenzsitzungs-Einladungsnachricht-Erzeugungseinheit, Konferenzsitzungs-Erzeugungseinheit und Kommunikations-Endgeräte
WO2007128808A1 (de) Verfahren zum aufbau einer push-to-talk-(ptt)-kommunikationsverbindung
WO2009153176A1 (de) Verfahren zur ermittlung aktiver kommunikationssitzungen und kommunikationssitzungs-informationsserver
DE102005039669B3 (de) Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transportprotokoll-Steuerungsprotokoll-Einheit, Konferenz-Abstimmungs-Auswerte-Einheit, Konferenz-Servereinheit und Kommunikations-Endgerät
DE102005049074B4 (de) Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts, Verfahren zum rechnergestützten Erzeugen einer Kommunikationsrecht-Anforderungsnachricht, Kommunikationsrecht-Vergabe-Einheit, Kommunikations-Konferenz-Servereinheit, Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, Kommunikations-Endgerät und Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz
WO2018189337A1 (de) Verfahren zum führen einer audio- und/oder videokonferenz
DE102005043006B4 (de) Kommunikationssystem, Kommunikationssitzungs-Server-Einheit, Medienverteilungs-Einheit und Verfahren zum Übertragen von Daten im Rahmen einer Kommunikationssitzung
DE102004005720B3 (de) Verfahren zum Verwalten von Kommunikationssitzungen
DE102010017925A1 (de) Verfahren und Vorrichtung zum Zuweisen einer Kontroll-Rolle einer kollaborativen Kommunikationssitzung und Verfahren und Vorrichtung zum Anfordern einer Kontroll-Rolle einer kollaborativen Kommunikationssitzung
DE102008048880B4 (de) Verfahren, Vorrichtung und Computerprogrammprodukt zum Ausgeben von Kommunikationsbeiträgen einer Konferenz und Verfahren, Vorrichtung und Computerprogrammprodukt zum Erzeugen einer Nachricht mit einem Kommunikationsbeitrag einer Konferenz
WO2008022613A2 (de) Verfahren zum erzeugen einer kommunikationssitzung - steuernachricht unter verwendung von sip
DE102005014519A1 (de) PoC-Kommunikationssystem, Verfahren zum Übertragen einer PoC-Signalisierung und/oder von PoC-Daten sowie Servervorrichtung dafür
DE102004008392A1 (de) Verfahren zum Verwalten von Kommunikationssitzungen
DE102004005124A1 (de) Verfahren und Kommunikationsanordnung zum Übermitteln von ein vorgegebenes Format aufweisenden Informationen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081208

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090331

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SOLUTIONS AND NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150918