SipTransportsRefactor
Version 1 (Saúl Ibarra Corretgé, 02/14/2014 05:57 pm)
| 1 | 1 | Saúl Ibarra Corretgé | h1. SIP Transports Refactoring |
|---|---|---|---|
| 2 | 1 | Saúl Ibarra Corretgé | |
| 3 | 1 | Saúl Ibarra Corretgé | This document describes the design for refactoring the SIP transports in the SIP SIMPLE SDK core. |
| 4 | 1 | Saúl Ibarra Corretgé | |
| 5 | 1 | Saúl Ibarra Corretgé | h2. Rationale |
| 6 | 1 | Saúl Ibarra Corretgé | |
| 7 | 1 | Saúl Ibarra Corretgé | Currently the Engine has a single UDP transports and a TCP factory and a TLS factory. This has worked for a while, but it has certain problems / limitations: |
| 8 | 1 | Saúl Ibarra Corretgé | |
| 9 | 1 | Saúl Ibarra Corretgé | * TLS settings apply to the factory itself, so every transport generated by this factory will use the TLS settings provided. This means that currently the TLS transport uses the TLS settings of the default account. A single CA list is loaded, and a single cert. |
| 10 | 1 | Saúl Ibarra Corretgé | * If a transport fails and the factory is restarted, all accounts are (potentially) affected, since they'll need to re-REGISTER, re-SUBSCRIBE and so on. |
| 11 | 1 | Saúl Ibarra Corretgé | |
| 12 | 1 | Saúl Ibarra Corretgé | h2. Possible solutions |
| 13 | 1 | Saúl Ibarra Corretgé | |
| 14 | 1 | Saúl Ibarra Corretgé | PJSIP currently is very tied to the concept of having a single transport manager. There is one global PJSIP User Agent, which holds a single PJSIP Endpoint, which in turn creates the one and only transport manager. |
| 15 | 1 | Saúl Ibarra Corretgé | |
| 16 | 1 | Saúl Ibarra Corretgé | There are 2 possible solutions to this problem: |
| 17 | 1 | Saúl Ibarra Corretgé | |
| 18 | 1 | Saúl Ibarra Corretgé | * Create multiple transport managers, one per account more precisely. |
| 19 | 1 | Saúl Ibarra Corretgé | * Modify the transport manager to allow registering multiple factories for the same type. |
| 20 | 1 | Saúl Ibarra Corretgé | |
| 21 | 1 | Saúl Ibarra Corretgé | After some exploration the first approach was taken as the ultimate solution to the problem. |
| 22 | 1 | Saúl Ibarra Corretgé | |
| 23 | 1 | Saúl Ibarra Corretgé | h2. Solution outline |
| 24 | 1 | Saúl Ibarra Corretgé | |
| 25 | 1 | Saúl Ibarra Corretgé | The basic idea is to create multiple transport managers (one per account) and pass them to the PJSIP APIs so they would be used to send a given request. At the transport layer things are pretty "transport-manager-agnostic". Once a pjsip_tx_data object is created, it holds a reference to the transport manager. |
| 26 | 1 | Saúl Ibarra Corretgé | |
| 27 | 1 | Saúl Ibarra Corretgé | Things that need to be changed: |
| 28 | 1 | Saúl Ibarra Corretgé | |
| 29 | 1 | Saúl Ibarra Corretgé | * Remove current transport manager from pjsip_endpoint |
| 30 | 1 | Saúl Ibarra Corretgé | * Modify pjsip_endpt_create_request to get a transport manager instance as a parameter (other similar pjsip_endpt_* functions need this too) |
| 31 | 1 | Saúl Ibarra Corretgé | * The pjsip_dialog structure needs to be extended to keep a reference to the associated transport manager |
| 32 | 1 | Saúl Ibarra Corretgé | * pjsip_dlg_create_uac/s need to be extended to get a transport manager as a parameter and attach it to the dialog structure |
| 33 | 1 | Saúl Ibarra Corretgé | |
| 34 | 1 | Saúl Ibarra Corretgé | h2. Core and middleware changes |
| 35 | 1 | Saúl Ibarra Corretgé | |
| 36 | 1 | Saúl Ibarra Corretgé | h3. Engine |
| 37 | 1 | Saúl Ibarra Corretgé | |
| 38 | 1 | Saúl Ibarra Corretgé | * The engine will be the responsible for creating TransportManager objects |
| 39 | 1 | Saúl Ibarra Corretgé | * Settings related to SIP transports and ports are moved away from the Engine to Account |
| 40 | 1 | Saúl Ibarra Corretgé | |
| 41 | 1 | Saúl Ibarra Corretgé | h3. TransportManager |
| 42 | 1 | Saúl Ibarra Corretgé | |
| 43 | 1 | Saúl Ibarra Corretgé | * Entity resposible for starting transport for UDP, TCP and TLS |
| 44 | 1 | Saúl Ibarra Corretgé | * Instances of this class are passed to underlying core components such as Invitation, Subscription, Request. |
| 45 | 1 | Saúl Ibarra Corretgé | * Notifications are posted when a transport is connected and when it's disconnected: SIPTransportManagerTransportDidConnect/Disconnect. |
| 46 | 1 | Saúl Ibarra Corretgé | * Notifications are posted when an incoming request is received: SIPTransportManagerGotIncomingRequest |
| 47 | 1 | Saúl Ibarra Corretgé | * Ports of different transports can be set and queried |
| 48 | 1 | Saúl Ibarra Corretgé | |
| 49 | 1 | Saúl Ibarra Corretgé | h3. Account |
| 50 | 1 | Saúl Ibarra Corretgé | |
| 51 | 1 | Saúl Ibarra Corretgé | * Accounts hold on to an instance of TransportManager and listen for notifications sent by it |
| 52 | 1 | Saúl Ibarra Corretgé | * If settings change (CFGSettingsObjectDidChange), the account will change the transport settings accordingly by calling methods / setting properties on the transport manager |
| 53 | 1 | Saúl Ibarra Corretgé | * New per-account settings: sip.transport_list, sip.udp_port, sip.tcp_port, sip.tls_port |
| 54 | 1 | Saúl Ibarra Corretgé | * New notifications: SIPAccountGotIncomingRequest |