Hi Benny I use pjsip svn trunk revision 2488. Signaling does work. Media does not work. I have 2 SIP servers with rtp forwarding and 3 pjsip clients. location 1: client 1 + 2 and server 1 are in the first local network behind NAT. server 1: 192.168.1.10 client 1: 192.168.1.11 client 2: 192.168.1.12 location 2 server 2: in the internet: public ip 212.212.xx.xx no NAT needed location 3 client 3: 192.168.2.21 in the second local network behind NAT. I need STUN activated that client 3 can talk with client 1 over server 2 as server 2 does forward rtp. If I activate STUN then the public IP is used. client1/2 can talk over server 2 to client 3 client1 to 2 over server 1 has no media transport If I deactivate STUN then client 1 can talk to client 2 over server 1. We have media transport but client 3 can't talk to client 1/2 over server 2. The problem is that media is sent to wrong adresses. Do you see my problem? When rtp port forwarding is disabled it all works without STUN but I have the media transport through the server. As I want to use L16 I must forward rtp... Signaling does always work. Regards Michael. --- On Thu, 3/5/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: Thursday, March 5, 2009, 1:03 PM 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> 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 _______________________________________________ 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 -----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/20090305/05740ceb/attachment-0001.html>
