PTT Notification Service Transport Selection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current push-to-talk (PTT) systems face challenges in providing robust session management and notification mechanisms, particularly in handling different access transport types and ensuring reliable connectivity and fault tolerance across various networks.

Innovation Solution

The implementation of a notification service that determines the access transport type used by PTT clients and selects the appropriate component for notification transmission, utilizing SIP proxies or gateways based on the transport type, ensuring seamless communication and redundancy across deployment sites.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a single notification component is used for all PTT clients, then the system structure is simple, but notification reliability deteriorates when the client's access transport type is unknown or incompatible

Engineering Contradiction:
Improvenotification system structureVSAvoidnotification delivery reliability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The notification service dynamically changes the transmission parameter (access transport type) based on the client's registered transport type. When a notification needs to be sent, the service queries the client's preferred transport type (IMS, non-IMS, allowing unsolicited IP traffic, or not allowing unsolicited IP traffic) and sends the notification using that specific transport type, ensuring compatibility and reliable delivery

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The notification service acts as an intermediary between the PTT platform and the PTT client. It receives notifications from the PTT platform, determines the appropriate access transport type by querying the service database, selects the corresponding notification component (SIP proxy, gateway, or other appropriate component), and transmits the notification through the selected component using the correct transport type

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If multiple notification components are maintained for different transport types, then notification reliability improves, but system complexity increases

Engineering Contradiction:
Improvenotification delivery reliabilityVSAvoidnotification system structure
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The notification service provides a universal interface for sending notifications while internally supporting multiple transport types (IMS, non-IMS, allowing unsolicited IP traffic, not allowing unsolicited IP traffic). The service database stores transport type information for each client, and the notification service automatically selects the appropriate transport type and component, making the multi-component system appear as a single unified service to external callers

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system uses self-service through automatic transport type determination. When a notification is received, the notification service automatically queries the service database to determine the client's access transport type, selects the appropriate notification component, and transmits the notification without manual intervention. This automation reduces the operational complexity of managing multiple notification components

Inventive Principle:
Principle #25Self-service

3Measurement precision

If the notification service queries transport type for every notification, then notification accuracy improves, but notification latency increases

Engineering Contradiction:
Improvetransport type determination accuracyVSAvoidnotification delivery time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The client's access transport type is determined and stored in the service database in advance, during client registration or session establishment. When a notification needs to be sent, the notification service simply queries the pre-stored transport type information from the database rather than determining it in real-time, significantly reducing notification latency while maintaining accuracy

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP3254484B1Session management and notification mechanisms for push-to-talk (PTT)
Publication Date: 2021.04.28 KODIAK NETWORKS INC
  • EP3254484B1 patent drawingFigure 1
  • EP3254484B1 patent drawingFigure 2
  • EP3254484B1 patent drawingFigure 3

AI summary

An embodiment method includes receiving, by a notification service running on a processor, a notification from a first component of a push-to-talk (PTT) platform. The notification is for transmission to a PTT client. The method further includes determining, by the notification service, an access transport type used by the PTT client to communicate with the PTT platform, and selecting, by the notification service, a second component to transmit the notification to the PTT client. Selecting the second component is in accordance with the access transport type used by the PTT client. The method further includes transmitting, by the notification service, the notification to the second component.