Create media transport dynamically in PJSUA-LIB

[bennylp]

Currently all media transports are pre-created in PJSUA-LIB according to the number of maximum calls to be supported. This decision was made to speed up call setup time and to simplify call state logic.

But there are few drawbacks with this approach:

1. it requires STUN and TURN transport to be kept-alive, which means it needs to send periodic keep-alive packets, and this is not good for battery consumption in mobile devices.
2. it requires TURN long-term allocation, which will fail if the NAT/mapped public IP address mapping has changed.
3. even when TURN is not used it may still fail when normal UDP media transport (i.e. not ICE) is used and the IP address (STUN or not) changes.
4. it allocates a lot of resources when the number of max_calls is large.

Because of these drawbacks, it's better to create the media transport on demand when a call is set up. To speed up call setup, we may employ caching mechanism where a transport is kept-alive for few seconds and may be reused for subsequent calls. And for flexibility, add a new callback to enable application to create a custom transport for a particular call.

Other benefits of creating transports dynamically are:

1. allow different accounts to use different media settings (e.g. ICE, IPv6, etc.)
2. dual stack media (to create IPv4 or IPv6 media transport depending on the transport type in the incoming call)

[bennylp]

This ticket requires pretty major modifications to PJSUA-LIB. The problem is, because media transport creation may not complete immediately (e.g. for STUN and ICE), some actions need to be delayed, and this means we need to duplicate some parameters and save it somewhere for future processing.

For outgoing calls, the msg_data needs to be saved.

For incoming calls, and this is the major problem, the rdata needs to be saved, since we only call on_incoming_call() callback after the media transport is created, and this callback needs rdata parameter. This is a major problem since rdata is a huge object so duplicating it requires a lot of processing and a lot of memory.

Alternatively we could call on_incoming_call() before media channel is created, and delay sending 18x/2xx instead.

But nevertheless this is too much of modifications to do now.

So moving this ticket to Known-Issue for now.

[bennylp]

The work so far, still uncompileable, just for future reference.

[bennylp]

The work was done in #1266