|
This profile defines the requirements for Bluetooth
devices necessary for the support of the intercom functionality within the
3-in-1 phone use case. The requirements are expressed in terms of end-user
services, and by defining the features and procedures that are required
for interoperability between Bluetooth devices in the 3-in-1 phone use
case.
More popularly, this is often referred to as the ‘walkie-talkie’
usage of Bluetooth.
For more details : Download the K4
Specification from the SIG website, or visit the Documents
Page.
As the intercom usage is completely symmetrical,
there are no specific roles defined. A device supporting the Intercom
profile will generally be denoted as Terminal (TL).
The Intercom profile defines the protocols and
procedures that shall be used by devices implementing the intercom part of
the use case called ‘3-in-1 phone’.
The scenarios targeted by this use case are
typically those where a direct speech link is required between two devices
(phone, computer, …), established using telephony-based signalling. A
typical scenario is:
- Two (cellular) phone users engaged in a speech call, on a direct
phone-to-phone connection using Bluetooth only.
Here is a brief summary of the interactions that
take place when a terminal wants to establish an intercom call towards
another terminal. In the description below, the term initiator (A-party)
and acceptor (B-party) will be used to designate the direction of the
call.
- If the initiator of the intercom call does not have the Bluetooth
Address of the acceptor, it has to obtain this; e.g. using the Device
discovery procedure
- The profile does not mandate a particular security mode. If users of
either device (initiator/acceptor) want to enforce security in the
execution of this profile, the authentication procedure) has to be
performed to create a secure connection.
- The initiator establishes the link and channel. Based on the
security requirements enforced by users of either device,
authentication may be performed and encryption may be enabled.
- The intercom call is established.
- After the intercom call has been cleared, the channel and link will
be released as well.
There are 3 definitions in this profile which
warrant further explanation
- Call information – The ability to provide additional
information during the active phase of a call.
- Intercom call – A speech call between two terminals.
- On hook – The ability to indicate the action of
going on-hook (e.g. to terminate a call) and release of all radio
resources related to that call.
When conformance to this profile is claimed, all
capabilities indicated mandatory for this profile shall be supported in
the specified manner (process-mandatory). This also applies for all
optional and conditional capabilities for which support is indicated. All
mandatory capabilities and optional and conditional capabilities, for
which support is indicated, are subject to verification as part of the
Bluetooth certification program.
When describing TCS Binary procedures, this chapter
provides additional information concerning lower layer handling.
Call control procedures are defined in Section 2.2 of TCS
Binary, except for the following which require some changes/additions
Call Request - The following applies: before
a call request can be made, a connection-oriented L2CAP channel needs to
be established between the two devices,
Call Connection - This procedure include a
mandatory SCO link establishment sub-procedure, which shall be
initiated before sending a CONNECT. The speech path shall be connected by
a unit when it receives a CONNECT or CONNECT ACKNOWLEDGE.
Call Clearing - after the last call-clearing
message has been sent, a unit shall:
- release the SCO link by invoking the appropriate LMP sub-procedure,
if not already released.
- terminate the L2CAP channel used for TCS Call-control signalling (if
not already terminated) and detach the other unit.
If a unit in a CC state other than Null detects
loss of link, it shall immediately go to the Null state. Call
clearing procedures shall in this case not be performed.
In this profile, only connection-oriented channels
are used. In the PSM field of the Connection Request packet, the default
value for TCS-BIN, 0x0005 shall be used.
- Maximum Transmission unit -The minimum MTU that a L2CAP
implementation used for this profile should support is 3 octets.
- Flush timeout option - The flush timeout value used for both
the GW and the TL shall be the default value of 0xFFFF.
- Quality of Service - Negotiation of Quality of Service is
optional.
This chapter contains signalling diagrams that are
used to clarify the interworking between units. These diagrams are
informative only. The diagrams do not represent all possible signalling
flows as defined by this profile.
The figure below shows the allowed signalling flow
in the successful case:
Image reprinted from Bluetooth IP Profile, Figure
10.1 , page 159
The figure below shows the allowed signalling flow
for the call clearing:
Image reprinted from Bluetooth IP Profile, Figure
10.2 , page 160
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
