Data session

LINE Planet provides a data session that allows applications to send and receive application data. For example, an application can send or receive text messages to enable text chatting during a group call (conference).

Keep in mind that the data communication protocol must be defined by the application. The data session provided by LINE Planet serves only as a communication channel for application-defined data communication protocols.

Supported call type	Minimum SDK version
1-to-1 call, group call	PlanetKit 3.2

Note

• LINE Planet is a real-time communication platform. On the internet, real-time communication is not guaranteed because packets may be lost or delayed depending on network conditions. These network impairments affect real-time communication quality, and in severe cases, calls can be interrupted. Heavy traffic can also cause various network impairments. If your application uses a data session, note that data communication might degrade the quality of voice or video calls.
• A data session is available only after a call is set up or participants join a group call.

Data session specifications

Data session APIs are directional, so there are sender and receiver. For each side, applications should request a data session with a pre-defined stream ID. Here, "pre-defined" means that the stream ID value must be defined between both sides before the implementation stage.

Stream ID

A stream ID is an identifier for data communication. The characteristics of stream IDs are as follows:

• Stream IDs are not dynamically generated. They are assigned during the design stage of the application and remain constant throughout the service operation. This means that if a receiver is unable to handle a particular stream ID, applications must stop using that specific stream ID.
• Stream IDs must be chosen from a specific range of integers, from 100 through 999.
• A single stream ID can be used by both the sender and the receiver. This means that the same identifier is used for communication in both directions, allowing for a bidirectional flow of data.

Subgroup support

Data sessions belonging to a subgroup can be used to send and receive data between the subgroup members. Even if the same stream ID is used, if the subgroups are different, different data sessions are defined and used.

Subgroups are separated by subgroup name. If the subgroup name is nil, it means the main room.

Note

• To use a data session within a subgroup in an application, the "dataSession" subgroup attribute must be true.
• Data sessions within a subgroup are supported in PlanetKit 4.1 or higher.

For more information about subgroups, refer to the documents in the Subgroup category.

Lifetime of a data session

The lifetime of a data session by call type is as follows:

• 1-to-1 call
  • Once a data session is created, it remains active until the call is ended.
• Group call - main room data session
  • Once a data session is created, it remains active until the group call is ended.
• Group call - subgroup data session
  • Once a data session is created for a specific subgroup, it remains active while the participant who created the data session remains subscribed to the subgroup. When the participant unsubscribes from the subgroup, the data session is deactivated.

Data session type

Data sessions have four types. Applications should choose which type to use, depending on application data characteristics.

Data session type	Description
Reliable message	Lost packets are retransmitted. The didReceive callback is called when each message is aggregated, so the callback is called as many times as send() is called.
Unreliable message	Lost packets are not retransmitted. The didReceive callback is called when each message is aggregated. When there is no packet loss, the callback is called as many times as send() is called. When there is packet loss, however, the callback can be called fewer times than send().
Reliable bytes	Lost packets are retransmitted. PlanetKit fragments data if the application data is large. However, packets are not aggregated on the receiver side, so applications should aggregate the fragmented packets.
Unreliable bytes	Lost packets are not retransmitted. PlanetKit fragments data if the application data is large. However, packets are not aggregated on the receiver side, so applications should aggregate the fragmented packets.

Maximum transmission bandwidth

Data sessions cannot transmit data at more than 2 Mbps. This is because data session bandwidth can degrade voice or video quality. For this reason, PlanetKit controls the data rate. If your application is sending excessive traffic, PlanetKit generates an exception event to notify your application that the data transmission should be slowed down.

Sender side

This section describes APIs and tasks for the sender side.

Sender side APIs

The following APIs are used by the sender side.

API	Description
makeOutboundDataSession()	Creates an outbound data session with a stream ID
getOutboundDataSession()	Retrieves a previously created outbound data session
send()	Sends data using the outbound data session
changeDestination()	Changes the destination of data

Create an outbound data session

To create an outbound data session, use makeOutboundDataSession().

public func makeOutboundDataSession(
    streamId: PlanetKitDataSessionStreamId,
    type: PlanetKitDataSessionType,
    delegate: PlanetKitOutboundDataSessionDelegate,
    completion: escaping PlanetKitOutboundDataSession.Completion
)

Parameter	Description
streamId	Stream identifier defined by the application. For more information, see Stream ID.
type	Data session type. For more information, see Data session type.
delegate	Delegate for handling events related to the outbound data session
completion	Completion callback

The result of creating an outbound data session can be determined by failReason in the completion callback. For more information, see Data session fail reason.

After the outbound session is created, didTooLongQueuedData reports the status of data traffic. Refer to the following table and take necessary action in your application.

Event	Description	Action required by an application
didTooLongQueuedData (enabled=true)	Data traffic is too heavy.	Stop sending data or reduce the transmission bitrate.
didTooLongQueuedData (enabled=false)	Network conditions become better.	Send more data.

Note

If didTooLongQueuedData events continue to occur, it can negatively impact the quality of voice and video communication. To mitigate this, you should reduce the data transmission bitrate.

Retrieve an outbound data session

To retrieve an existing outbound data session, use getOutboundDataSession().

public func getOutboundDataSession(streamId: PlanetKitDataSessionStreamId) -> PlanetKitOutboundDataSession?

Parameter	Description
streamId	Stream ID. For more information, see Stream ID.

Send data

To send data using an outbound data session, use send() of PlanetKitOutboundDataSession.

public func send(data: Data, timestamp: UInt64) -> Bool

Parameter	Description
data	Data to send. The maximum size for "Message" type is 128 kBytes, and the maximum size for other types is 4 MBytes.
timestamp	User-defined timestamp to identify the data

Change the destination of data

To change the destination of data, use changeDestination() of PlanetKitOutboundDataSession.

Note

This method is effective for group calls only.

public func changeDestination(streamId: PlanetKitDataSessionStreamId, peerId: PlanetKitUserId?, completion: @escaping (Bool)->Void)

Parameter	Description
streamId	Stream ID. For more information, see Stream ID.
peerId	Peer who will receive the data. Setting to nil has the following effect: - For a main room data session, send data to all peers in the room. - For a subgroup data session, send data to all subgroup members.
completion	Completion callback to receive the result of the request

Receiver side

This section describes APIs and tasks for the receiver side.

Receiver side APIs

The following APIs are used by the receiver side.

API	Description
dataSessionIncoming	Called when the sender newly created an outbound data session
makeInboundDataSession()	Creates an inbound data session to receive data
getInboundDataSession()	Retrieves a previously created inbound data session
unsupportInboundDataSession()	Informs the sender that the application do not support the stream ID

Get notified of an incoming data session

When the sender creates a new data session, the receiver side is notified of the event through dataSessionIncoming.

// For 1-to-1 calls
func dataSessionIncoming(_ call: PlanetKitCall, streamId: PlanetKitDataSessionStreamId, type: PlanetKitDataSessionType)

// For group calls
func dataSessionIncoming(_ conference: PlanetKitConference, streamId: PlanetKitDataSessionStreamId, subgroup: PlanetKitSubgroup?, type: PlanetKitDataSessionType)

Parameter	Description
call or conference	Instance of the 1-to-1 call or group call
subgroup	(Group calls only) Subgroup name. nil means the main room.
streamId	Stream ID set by the sender. For more information, see Stream ID.
type	Data session type. For more information, see Data session type.

In a group call, a participant who joined after someone started data streaming using the main room data session will also receive dataSessionIncoming when receiving data upon completion of the join flow. In this case, since the data session is for the main room, the subgroup name will be nil.

For the subgroup cases, members who subscribe after someone starts data streaming using the subgroup data session will also receive an dataSessionIncoming with an appropriate the subgroup name when receiving data upon completion of the subscription flow.

Create an inbound data session

To create an inbound data session, use makeInboundDataSession().

public func makeInboundDataSession(
    streamId: PlanetKitDataSessionStreamId,
    delegate: PlanetKitInboundDataSessionDelegate,
    completion: @escaping PlanetKitInboundDataSession.Completion
)

Parameter	Description
streamId	Stream identifier defined by the application. For more information, see Stream ID.
delegate	Delegate for handling events related to the inbound data session
completion	Completion callback

The result of creating an inbound data session can be determined by failReason in the completion callback. For more information, see Data session fail reason.

You can get notified of the data reception event through didReceive of the delegate.

Retrieve an inbound data session

To retrieve an existing inbound data session, use getInboundDataSession().

public func getInboundDataSession(streamId: PlanetKitDataSessionStreamId) -> PlanetKitInboundDataSession?

Parameter	Description
streamId	Stream ID. For more information, see Stream ID.

Report an unsupported data session

To inform the sender that the application does not support the stream ID, use unsupportInboundDataSession().

public func unsupportInboundDataSession(streamId: PlanetKitDataSessionStreamId)

Parameter	Description
streamId	Stream ID. For more information, see Stream ID.

Call this method if the stream ID received through the dataSessionIncoming event cannot be processed by the application (that is, unknown to the receiver).

• 1-to-1 call
  • The sender becomes aware that this method has been called through the data session fail reason "Unsupported". The sender cannot send data through this stream anymore.
• Group call
  • The sender does not know that this method has been called because there are multiple receivers.
  • The user of the application that called this method will not receive data through this stream, but the sender can continue to send data through this stream.

Closure of a data session

When a data session is closed, the didClose event of PlanetKitOutboundDataSessionDelegate (for the sender) or PlanetKitInboundDataSessionDelegate (for the receiver) occurs.

The didClose event delivers the reason for the closure of the data session with the reason parameter. The data session closure reasons defined in the PlanetKitDataSessionClosedReason enum are as follows:

Enum value	Description
sessionEnd	The data session has ended normally.
internal	An unexpected error occurred internally.
unsupported	The data session ID is unsupported by the peer.

Data session fail reason

A data session fail reason lets you determine the result of data session creation and its failure reason. The data session fail reasons defined in the PlanetKitDataSessionFailReason enum are as follows:

Enum value	Description
none	Successfully created a data session.
internal	Unexpected error occurred internally.
notIncoming	Cannot make an inbound data session without an incoming event (dataSessionIncoming).
alreadyExist	Data session stream ID already exists.
invalidId	Data session stream ID is invalid.
invalidType	Data session type is invalid.

Tip

Data session fail reasons are available since PlanetKit 5.1.

Data session compatibility

Based on the call type, you can determine the data session compatibility as follows:

• 1-to-1 call
  • The value of isDataSessionSupported of PlanetKitCallConnectedParam delivered by didConnect determines whether the peer supports a data session or not.
• Group call
  • The value of isDataSessionSupported of PlanetKitConferencePeer describes whether the participant supports a data session or not.

Even if peers have data session capabilities, handling a specific stream ID is another compatibility issue. This issue is related to handling of a specific stream ID by older versions of clients where handling of the stream ID is not implemented.

You can solve the compatibility issue of a specific stream ID by one of the following methods:

• In older versions of clients, reject unknown stream IDs by calling unsupportInboundDataSession().
• When developing older versions of clients, assign a specific stream ID as a reliable type for compatibility check, and design a protocol for compatibility check. In subsequent versions of clients, use the protocol to solve the compatibility issue in the way you want.

Related API

APIs related to the data session function are as follows.

Common

• send() of PlanetKitOutboundDataSession ^{iOS, macOS}
• changeDestination() of PlanetKitOutboundDataSession ^{iOS, macOS}
• didTooLongQueuedData of PlanetKitOutboundDataSessionDelegate ^{iOS, macOS}
• didClose of PlanetKitOutboundDataSessionDelegate ^{iOS, macOS}
• didReceive of PlanetKitInboundDataSessionDelegate ^{iOS, macOS}
• didClose of PlanetKitInboundDataSessionDelegate ^{iOS, macOS}
• PlanetKitDataSessionClosedReason ^{iOS, macOS}
• PlanetKitDataSessionFailReason ^{iOS, macOS}

1-to-1 call

• makeOutboundDataSession() of PlanetKitCall ^{iOS, macOS}
• getOutboundDataSession() of PlanetKitCall ^{iOS, macOS}
• makeInboundDataSession() of PlanetKitCall ^{iOS, macOS}
• getInboundDataSession() of PlanetKitCall ^{iOS, macOS}
• unsupportInboundDataSession() of PlanetKitCall ^{iOS, macOS}
• dataSessionIncoming of PlanetKitCallDelegate ^{iOS, macOS}

Group call

• makeOutboundDataSession() of PlanetKitConference ^{iOS, macOS}
• getOutboundDataSession() of PlanetKitConference ^{iOS, macOS}
• makeInboundDataSession() of PlanetKitConference ^{iOS, macOS}
• getInboundDataSession() of PlanetKitConference ^{iOS, macOS}
• unsupportInboundDataSession() of PlanetKitConference ^{iOS, macOS}
• makeOutboundDataSession() of PlanetKitSubgroup ^{iOS, macOS}
• getOutboundDataSession() of PlanetKitSubgroup ^{iOS, macOS}
• makeInboundDataSession() of PlanetKitSubgroup ^{iOS, macOS}
• getInboundDataSession() of PlanetKitSubgroup ^{iOS, macOS}
• unsupportInboundDataSession() of PlanetKitSubgroup ^{iOS, macOS}
• dataSessionIncoming of PlanetKitConferenceDelegate ^{iOS, macOS}