Hi Michael, I'm not sure what you're suggesting there. For one, you can't use the information from a "preloaded STUN", as each socket must be resolved independently. What you "doesn't work" problem is? Is it with media, or with the signaling? What pjsip version are you using? cheers -benny On Thu, Mar 5, 2009 at 6:08 AM, Michael <michael_zurich at yahoo.com> wrote: > Hi Benny > > Thanks for the info. Is it not possible to do the following: > > - One STUN for PJSIP/PJMEDIA as it is, loaded at start-up. No change. > - Adding a flag noSTUN at account level. > - If a call is "build", check the flag. > > I see the problem with the pre-created media transport. Why not creating an > the fly using the flag (noSTUN) and then using the info from "pre-loaded" > STUN? > So you do not have to wait for STUN resolution, just a flag which says not > to use the STUN info. Would that not be a applicable and fast solution? > > I think you are right not to delay a call. This could give problems if STUN > is not reachable. > > Regards > > Michael. > > > --- On *Wed, 3/4/09, Benny Prijono <bennylp at teluu.com>* wrote: > > > From: Benny Prijono <bennylp@xxxxxxxxx> > Subject: Re: STUN problem > To: "pjsip list" <pjsip at lists.pjsip.org> > Date: Wednesday, March 4, 2009, 6:45 PM > > > On Wed, Mar 4, 2009 at 6:27 AM, Michael <michael_zurich at yahoo.com<http://mc/compose?to=michael_zurich at yahoo.com> > > wrote: > >> >> Hi >> >> I have pjsip and use it as SIP client with 2 SIP accounts. First account >> is local Asterisk at internal 192.168.x.x. Second account is public in >> Internet at 212.x.x.x.First account does not need STUN and second needs >> STUN. If I activate STUN then second works but first not. If I deactivate >> STUN, first works but second not. I looked at other SIP-clients like >> phoner.de They use STUN configuration on account basis. >> >> Could you add STUN on account configuration (for each account) or at least >> a flag in the account to disable/enable STUN for each account or do you have >> a workaround? >> >> > Unfortunately no, and it's not that easy either, I tried it. The part with > SIP is probably not that difficult to change. The main problem is with the > media transports. At the moment media transports are precreated, shared > among accounts, and they use single configuration. I suppose if we make STUN > configurable on per account basis, then the same should be done on the media > transports too. Which means media transports cannot be pre-created, they > need to be created when there is new call. > > And there lies the difficulty, since media transport creation may not > complete immediately, for example when waiting for STUN resolution. Which > means the incoming call event needs to be delayed. Which means the event > needs to be stored somewhere, and so on. > > It is a desirable feature, unfortunately it's also not straightforward to > implement. > > cheers > Benny > > > >> Michael. >> >> >> > > -----Inline Attachment Follows----- > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <http://mc/compose?to=pjsip at lists.pjsip.org> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090305/a9d82131/attachment.html>
