Hi, On Thu, Sep 9, 2010 at 12:48 PM, Javier Barroso <[email protected]> wrote: > From ekiga -d4 logs: > 2010/09/08 16:30:34.588 32:13:29.082 Housekeeper:0xb48ffb70 SIP Set > state Terminated_Timeout for SUBSCRIBE transaction > id=z9hG4bKd43fdd4b-c3b9-df11-8850-0017a420b5ad > 2010/09/08 16:30:34.588 32:13:29.082 > Housekeeper:0xb48ffb70 SIP Changing SUBSCRIBE handler from Restoring > to Unavailable, target=sip:j...@xxxx, > id=8c307b3c-b5b8-df11-8850-0017a420b...@pepinux > 2010/09/08 16:30:34.588 32:13:29.082 > Housekeeper:0xb48ffb70 SIP Retrying SUBSCRIBE in 30 seconds. > 2010/09/08 16:30:34.588 32:13:29.082 Housekeeper:0xb48ffb70 SIP Set > state Terminated_Timeout for SUBSCRIBE transaction > id=z9hG4bKbe95de4b-c3b9-df11-8850-0017a420b5ad > 2010/09/08 16:30:34.589 32:13:29.082 > Housekeeper:0xb48ffb70 SIP Changing SUBSCRIBE handler from Unavailable > to Unavailable, target=sip:j...@xxxxx, > id=8c307b3c-b5b8-df11-8850-0017a420b...@pepinux > 2010/09/08 16:30:34.589 32:13:29.082 > Housekeeper:0xb48ffb70 SIP Retrying SUBSCRIBE in 30 seconds. > > I'm viewing this continualy in ekiga.log: > > grep "2010/09/09.*Set state Terminated_Timeout for SUBSCRIBE" > ekiga.log | awk '{gsub ("....$","",$2); print $2}' | uniq -c | sort > -n > 36 00:00:36 > 36 00:01:12 > 36 00:01:49 > 36 00:02:25 > 36 00:03:02 > 36 00:03:39 > 36 00:04:16 > 36 00:04:53 > .... all the time ... > 36 11:26:34 > 36 11:27:11 > 36 11:27:48 > 36 11:28:24 > 36 11:29:01 > 36 11:29:38 > 36 11:30:15 > 36 11:30:52 > 36 11:31:29 > 36 11:32:05 (the time which I'm writting this mail) > > Is it normal ?
Yes, it is normal - Ekiga sends SUBSCRIBE messages to query the presence status (offline, online, away etc) of your contacts. > I'm viewing too this in wireshark capture (continuously launching SIP > SUBSCRIBE REQUEST): > 198 6.674571 192.168.101.120 38.223.166.2 SIP Request: > SUBSCRIBE sip:j...@xxxxx > 199 6.676041 10.4.0.120 38.223.166.2 SIP Request: > SUBSCRIBE sip:j...@xxxxxx > 202 6.681867 192.168.101.120 38.117.97.125 SIP Request: > SUBSCRIBE > sip:j...@yyyyyy > 203 6.683218 10.4.0.120 38.117.97.125 SIP Request: > SUBSCRIBE sip:j...@yyyyy > > I'm viewing at least 4 ips against ekiga is trying to subscribe my contacts: > 38.117.97.125, 38.223.166.2, 40.233.138.214, 39.165.13.136 > > I has only one account in my ekiga, and is to our internal asterisk. SUBSCRIBEs are sent to the server of the particular contact, not the server of your account. Those IPs should correspond to what xxxxxx and yyyyyy resolve to. Thus, if you have [email protected], then the SUBSCRIBE will be sent to 86.64.162.35 (which is the IP of ekiga.net). > Can I configure ekiga to not do such things (subscribe to externals ips)? I'm not sure, but I think no, presence status can't be disabled. > Anther issue, do you know why my linux is logging as two ip different > (10.4.0.120 and 192.168.101.120) ? > > My ip route config is: > $ ip route > 10.4.0.0/24 dev br-gest proto kernel scope link src 10.4.0.120 > 192.168.0.0/16 dev br-lan proto kernel scope link src 192.168.101.120 > default via 192.168.100.1 dev br-lan > > So I don't understand why connections to 38.223.166.2 goes sometimes > with my 10.4.0.120 ip ... I could be wrong (I'm not Ekiga developer), but here's my guess. First, SIP requires the sent message to contain the IP of the interface through which it was sent (in Via header). Therefore Ekiga can't send from 0.0.0.0 and let the kernel decide the source IP. Second, Ekiga doesn't "know" which interface (and therefore source address) will be used by the kernel for packets going to 38.223.166.2. AFAIK there is no way to query it; the other way would be to reproduce the kernel routing algorithm in Ekiga, which is impossible. Therefore Ekiga sends two copies of the message - one w/ 10.4.0.120 in Via and as the source address, and the other w/ 192.168.101.120. I'm not sure about the current version of Ekiga, but in older ones it was possible to specify which interface to use. -- Ian _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
