Hi Alexei, Did you ever get to the bottom of this, I am having the same problem (public_addr and bound_addr) are set but the RTP binds to the other interface. Surely this should bind to the specified interface? Thanks, Michael Alexei Kuznetsov wrote: > On 26.01.2009, at 12:05, Benny Prijono wrote: > >> On Fri, Jan 23, 2009 at 5:14 PM, Ruud Klaver <ruud at ag-projects.com> >> wrote: >> >> On 23 Jan 2009, at 01:19, Alexei Kuznetsov wrote: >> >> Hi, >> >> There's a problem on the Mac OS X with installed Parallels, which >> adds virtual nics to the host machine. pjsua-lib bounds to one of >> these addresses and tries to use it in signalling and media. I know I >> can use bound_addr explicitly, but it's not the point. I'd like to >> predict the way my app bounds to the local addresses and do something >> to make it more convinient for the user. So, is there any algorithm? >> >> >> I have also noticed this problem. It seem to be pretty random, but >> I'm curious to know if there is any logic behind it. >> >> >> Of course there is! Do you think pjsip just subjectively selects IP >> interface at random? It's not that clever you know. ;-) >> >> Here: >> http://trac.pjsip.org/repos/browser/pjproject/trunk/pjlib/src/pj/sock_common.c#L448 >> >> >> The selected IP shouldn't matter much IMO. For signaling, the IP will >> be (re)learnt from REGISTER response. And for media, that exactly >> what ICE is for, among other things. >> >> cheers >> Benny > > Yes, that doesn't matter much in general case. But I have a user whose > SIP provider uses Communigate Pro, which tries to solve the NAT > problem by routing media through itself and not using STUN. It does > not support ICE either. This behaviour depends on the appropriate > published IP address of the SIP user agent. > > As far as I understood the code from sock_common.c, the user's machine > chooses the address here > > /* If we end up with 127.0.0.0/8 or 0.0.0.0/8, resolve the IP > * by getting the default interface to connect to some public host. > * The 0.0.0.0/8 is a special IP class that doesn't seem to be > * practically useful for our purpose. > */ > if (status != PJ_SUCCESS || !pj_sockaddr_has_addr(addr) || > (af==PJ_AF_INET && (pj_ntohl(addr->ipv4.sin_addr.s_addr)>>24)==127) || > (af==PJ_AF_INET && (pj_ntohl(addr->ipv4.sin_addr.s_addr)>>24)==0)) > { > status = pj_getdefaultipinterface(af, addr); > } > > because computer's hostname does not resolve and the first available > interface is the interface that we'd like to be default (but it's not). > > Here's an example. 10.211.55.2 is chosen as a default by pjsua-lib. > User's default router is 192.168.1.1. > > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fd92:a3:1186:7c97:21e:c2ff:fe1b:26d7 prefixlen 128 > gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > ether 00:1e:c2:1b:26:d7 > media: autoselect status: inactive > supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP > <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP > <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX > <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX > <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT > <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none > fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078 > lladdr 00:1f:5b:ff:fe:10:b7:c4 > media: autoselect <full-duplex> status: inactive > supported media: autoselect <full-duplex> > en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::21e:c2ff:febb:c8fc%en1 prefixlen 64 scopeid 0x6 > inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:1e:c2:bb:c8:fc > media: autoselect status: active > supported media: autoselect > en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> > mtu 1500 > inet6 fe80::21c:42ff:fe00:8%en2 prefixlen 64 scopeid 0x7 > inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255 > ether 00:1c:42:00:00:08 > media: autoselect status: active > supported media: autoselect > en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> > mtu 1500 > inet6 fe80::21c:42ff:fe00:9%en3 prefixlen 64 scopeid 0x8 > inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255 > ether 00:1c:42:00:00:09 > media: autoselect status: active > supported media: autoselect > > Any thoughts? > > Alexei > > _______________________________________________ > 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 > -- Vox Telecom Limited Block B, Rutherford Estate tel: +27 11 809 1500 direct: +27 11 809 1646 mobile: +27 83 364 2370 fax: 0865 023 695 - http://www.voxtelecom.co.za email:michaelt at voxtelecom.co.za Disclaimer: BizCall does not accept responsibility or liability for the unauthorised use of its e-mail facility and/or opinions relating to bona fide company matters. Save for statements and/or opinions relating to bona fide company matters, Bizcall denies responsibility or liability for the contents of this communication.
