Not yet. It's still a problem for me. But I'm not settig bound_addr manually. I was trying to understand the logic of choosing the address to bind to. And I haven't looked at it since then. Alexei On 25.02.2009, at 17:57, Michael Toop wrote: > 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.
