Hi, Our softphone support mulltiple sip accounts and we would like to support per account transport management (i.e. binding transport to a specific interface, use stun per account). I noticed the following in pjsip: We create a standard sip udp transport at initialization, pjsip_tpmgr_get_transport_count returns 1 [sfl-debug] Number of transport: 1 17:47:12.994 sip_transport. Outstanding transmit buffers: 0 17:47:12.994 sip_transport. Dumping listeners: 17:47:12.994 sip_transport. Dumping transports: 17:47:12.994 sip_transport. udp0x1de8910 udp 0.0.0.0:5060 [published as 192.168.50.182:5060] (refcnt=1) If, for example, we create a new udp transport using STUN , pjsip_tpmgr_get_transport_count still return 1 [sfl-debug] Number of transport: 1 17:57:50.630 sip_transport. Outstanding transmit buffers: 0 17:57:50.630 sip_transport. Dumping listeners: 17:57:50.630 sip_transport. Dumping transports: 17:57:50.630 sip_transport. udp0x9b7260 udp 0.0.0.0:56268 [published as 208.88.110.46:63516] (refcnt=1) Looking at the code, transport_attach registers the account in the transport manager's hashtable using the transport type and address family, which are the same for both transport. The entry in the hashtable is set to NULL and the newly created transport takes its place. I can still receive calls on my two accounts even Answer INVITE request using transport: udp0x9b7260 udp 0.0.0.0:56268 [published as 208.88.110.46:63516] (refcnt=3) Answer INVITE request using transport: udp0x7849e0 udp 0.0.0.0:5060 [published as 192.168.50.182:5060] (refcnt=9) So, my question is: How this fact (having two transport of the same type) affects the behavior of the library? I noticed taht reference counting looked like inaccurate. Since this feature could be interesting for our application, would it be hard to implement it in PJSIP. I saw that we could specify an remote IP address (which is inittialized at 0) as a key in transport manager's hash table. Thanks, Alexandre
