Currently, one eXosip2 instance can only listen to one transport layer.
You are right about this restriction.
However, starting from eXosip2, the new API has been modified in
order to allow managing several instance of eXosip_t structure within
the same application and thus, you could create 3 instance, one
for UDP, another for TCP and finally for TLS.
However, there are still limitation with this behavior: if the transport
is modified during a session, the call/dialog information are not shared
among the eXosip_t instance and for example, a BYE under TCP wouldn't
match a dialog created with an INVITE using UDP.
My final target is to clearly allow for using several transport layer within
an eXosip_t instance. The stack wouldn't require much change to have
several transport. However, the tricky part is more about the via and contact
management that would be much more complex and would need again
careful attention! In the end, any decision to modify the transport made
in eXosip2 would certainly introduce more interop issue. (from experience,
if you were to send a 200ok for INVITE in TCP for an INVITE sent over
UDP... you will certainly not have problems only with eXosip2... I don't
think the network will anyway let the message go through...)
Opinion 1: I do think it's a design error to manage 2 transport layers on a client side.
(whatever the rfc is telling you about this)
Opinion 2: eXosip2 is a client side sip stack! It hasn't been designed for a usage
on server side... even if it's used in this domain by some projects!
I may still welcome any contribution that would carefully try to add support
for multiple transport layer within an eXosip_t instance! Such feature shouldn't
change any of the default behavior unless configured explicitely ;)
Let me know your comments!