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> 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://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/20090304/ba1b5444/attachment.html>
