On Sun, Dec 6, 2009 at 4:03 AM, Liu Jahow <jahowliu at gmail.com> wrote: > Hi, > As far as I know, for UDP, there will be only one entry with the same > transport type in the transport manager even if we register multi transports > with the same type but different ports. It seems that transport manager will > accept the new one registration to replace the last one. But those > transports we create still do work and just we can't see them in transport > manager. First of all, please see http://trac.pjsip.org/repos/ticket/50 Note that the purpose of the hash table in the transport manager is to find which transport to use to send a message to a destination, and it contains only one transport instance per hash table key. For UDP and TCP/TLS listener, the key is the transport type only, so if you register more than one UDP transports (or TCP/TLS listeners), the newly registered instance overwrites the old one. And since the "dump transports" output only shows the transports registered in the hash table, it only shows one UDP transport indeed. But that doesn't mean that the other instances cannot be used, as you mentioned. Though these other instances will not be used to send outgoing requests (unless "pairing" is used, see below). > Besides, we need to close our UDP transport ourself if we want to use the > PJSUA_DESTROY to close the PJSUA. Because PJSUA_DESTROY will only destroy > the transport manager and it only have idea that it has only one UDP > transport, the last transport. > To avoid that, I would recommend to explicitly use the "pairing" (locking an account/dialog/transaction to use a specific transport) mechanism as described in ticket #50 above. This way, the account/dialog/transaction that use the specific transport will add reference counter to that transport instance, so that when these account/dialog/transaction objects are all gone, the transport will be destroyed automatically since the reference counter will get to zero. Cheers Benny > 2009/12/5 Alexandre Savard <alexandre.savard at savoirfairelinux.com> >> >> 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 >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > -- > Best Regards, > > Alex Liu > foxconn mail : alex.ch.liu at ambit.com.tw > private mail : jahowliu at gmail.com > msn : jahowliu at yahoo.com.tw > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -- Best regards, Benny
