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? Here is the user's ifconfig output. The wi-fi interface is en1 with 192.168.1.34; en2 and en3 with 10.211.55.2 and 10.37.129.2 respectively are virtual nics created by Parallels. 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 And from pjsua logs: 18:26:37.353 udp0x885800 SIP UDP transport started, published address is 10.211.55.2:49171 And I can't reproduce the problem on my machine -- pjsua-lib still bounds to the proper addres. Alexei

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? > > Here is the user's ifconfig output. The wi-fi interface is en1 with > 192.168.1.34; en2 and en3 with 10.211.55.2 and 10.37.129.2 > respectively are virtual nics created by Parallels. > > 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 > > And from pjsua logs: > 18:26:37.353 udp0x885800 SIP UDP transport started, published > address is 10.211.55.2:49171 > > And I can't reproduce the problem on my machine -- pjsua-lib still > bounds to the proper addres. > > Alexei 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. Ruud Klaver AG Projects

On Fri, Jan 23, 2009 at 5:14 PM, Ruud Klaver <ruud@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

 (af==PJ_AF_INET && (pj_ntohl(addr->ipv4.sin_addr.s_addr)>>24)==0))

On 26.01.2009, at 12:05, Benny Prijono wrote: > On Fri, Jan 23, 2009 at 5:14 PM, Ruud Klaver <ruud@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

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@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@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@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.

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@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@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@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.