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. 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20091206/0e5cbd3e/attachment.html>
