Hi Benny, Thanks for your advice. But for the pjsua_destroy, I have already bound the transport id for each account. The pjsua_destroy still does not close my first one udp port. Further more, if I try to re-create the transport with the same port after pjsua_destroy, it will fail because the port is in use. The version of pjsip I use is 1.4.0. 2009/12/9 Benny Prijono <bennylp at teluu.com> > 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 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20091209/418ca419/attachment-0001.html>
