From kiwino1 at gmail.com Fri Oct 1 05:16:59 2010 From: kiwino1 at gmail.com (Bert) Date: Fri, 01 Oct 2010 13:16:59 +0800 Subject: [Ekiga-list] zrtp encryption? In-Reply-To: <4CA4EBDB.3070105@pu-pm.univ-fcomte.fr> References: <20100930024341.GA30996@aurora.owens.net> <4CA47B94.8090300@pu-pm.univ-fcomte.fr> <20100930153420.GA1566@aurora.owens.net> <4CA4EBDB.3070105@pu-pm.univ-fcomte.fr> Message-ID: <4CA56ECB.5060701@gmail.com> Try Zimmerman's Zphone http://zfoneproject.com/ It is free and open source. I like to know if it works. On 01-Oct-2010 3:58 AM, Eugen Dedu wrote: > On 30/09/10 17:34, Rob Owens wrote: >> On Thu, Sep 30, 2010 at 01:59:16PM +0200, Eugen Dedu wrote: >>> On 30/09/10 04:43, Rob Owens wrote: >>>> What's the status of zrtp encryption in Ekiga? I thought I remembered >>>> reading somewhere that it was planned for somewhere in the 3.x >>>> release, >>>> but everything I can find about it now says "not yet". >>>> >>>> I just tested Twinkle with zrtp and it works nice and easy (I didn't >>>> sniff any packets to make sure it's working right, but the GUI >>>> tells me >>>> it is). But Twinkle doesn't support video... >>>> >>>> I'd love to use Ekiga for encrypted video conversations. Any chance >>>> it'll happen? >>> >>> According to http://www.opalvoip.org/wiki/index.php?n=Main.Milestones, >>> zrtp will be complete when the current development becomes stable. I >>> would say this appears in 3-12 months (if you want more precision, >>> contact its author). >>> >>> Ekiga will hopefully release a version with it 0-3 months later, but >>> this interval can be greater. >>> >> Thanks for the info. Twinkle uses libzrtpcpp for its zrtp support. I >> guess Ekiga can't use that due to architecture reasons? > > I do not know. Someone needs to look into that... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpunltd at gmail.com Fri Oct 1 14:13:28 2010 From: cpunltd at gmail.com (Custom Processing Unlimited) Date: Fri, 1 Oct 2010 09:13:28 -0500 Subject: [Ekiga-list] zrtp encryption? In-Reply-To: <4CA56ECB.5060701@gmail.com> References: <20100930024341.GA30996@aurora.owens.net> <4CA47B94.8090300@pu-pm.univ-fcomte.fr> <20100930153420.GA1566@aurora.owens.net> <4CA4EBDB.3070105@pu-pm.univ-fcomte.fr> <4CA56ECB.5060701@gmail.com> Message-ID: hmm... looks interesting.. -- "Custom" is NOT mass produced! ...then it's just a product line. Custom Processing Unlimited -------------- next part -------------- An HTML attachment was scrubbed... URL: From palama at inwind.it Sat Oct 2 11:02:47 2010 From: palama at inwind.it (palama at inwind.it) Date: Sat, 2 Oct 2010 13:02:47 +0200 Subject: [Ekiga-list] Missed call notification In-Reply-To: <20100925144055.4207917f.palama@inwind.it> References: <4C971774.4070503@pu-pm.univ-fcomte.fr> <4C9CB671.2060804@pu-pm.univ-fcomte.fr> <20100925144055.4207917f.palama@inwind.it> Message-ID: <20101002130247.65db453e.palama@inwind.it> Is it possible to instruct ekiga.net to send me an email when someone calls me and I am not registerd? Thanks for your help. Antonio Palam? -- From Eugen.Dedu at pu-pm.univ-fcomte.fr Sat Oct 2 12:46:42 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Sat, 02 Oct 2010 14:46:42 +0200 Subject: [Ekiga-list] Missed call notification In-Reply-To: <20101002130247.65db453e.palama@inwind.it> References: <4C971774.4070503@pu-pm.univ-fcomte.fr> <4C9CB671.2060804@pu-pm.univ-fcomte.fr> <20100925144055.4207917f.palama@inwind.it> <20101002130247.65db453e.palama@inwind.it> Message-ID: <4CA729B2.6040305@pu-pm.univ-fcomte.fr> On 02/10/10 13:02, palama at inwind.it wrote: > Is it possible to instruct ekiga.net to send me an email when someone calls me and I am not registerd? I do not think it is possible, but I am not sure. This would somewhat allow to spam. On the contrary, it would be useful that ekiga.net save the address of people who tried to contact you, and the next time you register to ekiga.net it send you something like "missed call from xyz" for each such person. -- Eugen From rowens at ptd.net Sat Oct 2 14:19:39 2010 From: rowens at ptd.net (Rob Owens) Date: Sat, 2 Oct 2010 10:19:39 -0400 Subject: [Ekiga-list] Missed call notification In-Reply-To: <4CA729B2.6040305@pu-pm.univ-fcomte.fr> References: <4C971774.4070503@pu-pm.univ-fcomte.fr> <4C9CB671.2060804@pu-pm.univ-fcomte.fr> <20100925144055.4207917f.palama@inwind.it> <20101002130247.65db453e.palama@inwind.it> <4CA729B2.6040305@pu-pm.univ-fcomte.fr> Message-ID: <20101002141939.GA17125@aurora.owens.net> On Sat, Oct 02, 2010 at 02:46:42PM +0200, Eugen Dedu wrote: > On 02/10/10 13:02, palama at inwind.it wrote: >> Is it possible to instruct ekiga.net to send me an email when someone calls me and I am not registerd? > > I do not think it is possible, but I am not sure. This would somewhat > allow to spam. > > On the contrary, it would be useful that ekiga.net save the address of > people who tried to contact you, and the next time you register to > ekiga.net it send you something like "missed call from xyz" for each > such person. > iptel.org has free SIP accounts (which work with Ekiga software) and they provide voicemail and "voicemail2email". http://www.iptel.org/service I've never used their voicemail service, but the SIP service is reliable. -Rob From palama at inwind.it Sat Oct 2 14:59:13 2010 From: palama at inwind.it (palama at inwind.it) Date: Sat, 2 Oct 2010 16:59:13 +0200 Subject: [Ekiga-list] Missed call notification In-Reply-To: <20101002141939.GA17125@aurora.owens.net> References: <4C971774.4070503@pu-pm.univ-fcomte.fr> <4C9CB671.2060804@pu-pm.univ-fcomte.fr> <20100925144055.4207917f.palama@inwind.it> <20101002130247.65db453e.palama@inwind.it> <4CA729B2.6040305@pu-pm.univ-fcomte.fr> <20101002141939.GA17125@aurora.owens.net> Message-ID: <20101002165913.28515b1a.palama@inwind.it> On Sat, 2 Oct 2010 10:19:39 -0400 Rob Owens wrote: > On Sat, Oct 02, 2010 at 02:46:42PM +0200, Eugen Dedu wrote: > > On 02/10/10 13:02, palama at inwind.it wrote: > >> Is it possible to instruct ekiga.net to send me an email when someone calls me and I am not registerd? > > > > I do not think it is possible, but I am not sure. This would somewhat > > allow to spam. > > > > On the contrary, it would be useful that ekiga.net save the address of > > people who tried to contact you, and the next time you register to > > ekiga.net it send you something like "missed call from xyz" for each > > such person. > > > iptel.org has free SIP accounts (which work with Ekiga software) and > they provide voicemail and "voicemail2email". > > http://www.iptel.org/service > > I've never used their voicemail service, but the SIP service is > reliable. > > -Rob I know other providers give such a service, another one is sip.antisip.com, but I would like not to change my ekiga.net sip address. Antonio -- From william-t2 at live.com Sat Oct 2 23:18:01 2010 From: william-t2 at live.com (william howell) Date: Sat, 2 Oct 2010 19:18:01 -0400 Subject: [Ekiga-list] Missed call notification In-Reply-To: <20101002165913.28515b1a.palama@inwind.it> References: , <4C971774.4070503@pu-pm.univ-fcomte.fr>, , <4C9CB671.2060804@pu-pm.univ-fcomte.fr>, <20100925144055.4207917f.palama@inwind.it>, <20101002130247.65db453e.palama@inwind.it>, <4CA729B2.6040305@pu-pm.univ-fcomte.fr>, <20101002141939.GA17125@aurora.owens.net>, <20101002165913.28515b1a.palama@inwind.it> Message-ID: Goto www.elastix.org, download ver 1.6 of their PBX software, it's free, direct you Ekiga sip to that PBX as a trunk, then you have possibilities you never imagined before, and for free (well almost, it will cost you some learning). William > Date: Sat, 2 Oct 2010 16:59:13 +0200 > From: palama at inwind.it > To: ekiga-list at gnome.org > Subject: Re: [Ekiga-list] Missed call notification > > On Sat, 2 Oct 2010 10:19:39 -0400 > Rob Owens wrote: > > > On Sat, Oct 02, 2010 at 02:46:42PM +0200, Eugen Dedu wrote: > > > On 02/10/10 13:02, palama at inwind.it wrote: > > >> Is it possible to instruct ekiga.net to send me an email when someone calls me and I am not registerd? > > > > > > I do not think it is possible, but I am not sure. This would somewhat > > > allow to spam. > > > > > > On the contrary, it would be useful that ekiga.net save the address of > > > people who tried to contact you, and the next time you register to > > > ekiga.net it send you something like "missed call from xyz" for each > > > such person. > > > > > iptel.org has free SIP accounts (which work with Ekiga software) and > > they provide voicemail and "voicemail2email". > > > > http://www.iptel.org/service > > > > I've never used their voicemail service, but the SIP service is > > reliable. > > > > -Rob > > I know other providers give such a service, another one is sip.antisip.com, but I would like not to change my ekiga.net sip address. > > Antonio > > -- > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From franckd at agmp.org Sun Oct 3 07:09:11 2010 From: franckd at agmp.org (Franck Danard) Date: Sun, 03 Oct 2010 09:09:11 +0200 Subject: [Ekiga-list] Starting problem on Windows Message-ID: <4CA82C17.4000502@agmp.org> Hi. I try since lots of month to use Ekiga on windows XP and I've always an error when I launch program. Error on entry point...etc I tried to find a solution on your mailing list or on the net, but nothing. For the moment, it's the first program which use the h264 on free version and I need it. Please, could you help me to fix this problem? Regards -- */Franck Danard/* -------------- next part -------------- An HTML attachment was scrubbed... URL: From franckd at agmp.org Sun Oct 3 08:16:40 2010 From: franckd at agmp.org (Franck Danard) Date: Sun, 03 Oct 2010 10:16:40 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CA82C17.4000502@agmp.org> References: <4CA82C17.4000502@agmp.org> Message-ID: <4CA83BE8.8090705@agmp.org> Look at the hardcopy: I use the last Ekiga version. (3.2.7). Regards */Franck Danard/* Le 03/10/2010 09:09, Franck Danard a ?crit : > Hi. > > I try since lots of month to use Ekiga on windows XP and I've always > an error when I launch program. > Error on entry point...etc > I tried to find a solution on your mailing list or on the net, but > nothing. > For the moment, it's the first program which use the h264 on free > version and I need it. > > Please, could you help me to fix this problem? > > Regards > > -- > */Franck Danard/* > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: moz-screenshot-8.png Type: image/png Size: 5325 bytes Desc: not available URL: From tompoe at meltel.net Mon Oct 4 01:50:56 2010 From: tompoe at meltel.net (Tom Poe) Date: Sun, 3 Oct 2010 21:50:56 -0400 Subject: [Ekiga-list] adding ekiga as softphone to asterisk 1.6 Message-ID: <201010032150.56499.tompoe@meltel.net> Here's /etc/sip.conf file quote: ;sip_custom_post.conf If you have extra parameters that are needed for a ;extension to work to for example, those go here. So you have extension ;1000 defined in your system you start by creating a line [1000](+) in this ;file. Then on the next line add the extra parameter that is needed. ;When the sip.conf is loaded it will append your additions to the end of ;that extension. ; #include sip_custom_post.conf Here's what I found with ekiga documentation about adding ekiga to asterisk: Assuming that your Asterisk is in place and functioning, the first step is to make Ekiga a client of your Asterisk. You do this by having the following lines in sip.conf ? one of Asterisk's many configuration files: [general] context=default srvlookup=yes videosupport=yes disallow=all ; First disallow all codecs allow=ulaw allow=alaw ; Allow codecs in order of allow=ilbc ; preference allow=gsm allow=h261 [101] type=friend secret=welcome qualify=yes ; Qualify peer is not more than 2000 mS away nat=no ; This phone is not natted host=dynamic ; This device registers with us canreinvite=no ; Asterisk by default tries to redirect context=home ;port=5061 ; Uncomment this line if Ekiga and Asterisk ; are on the same host - - - - - - - - - Has anyone figured out how to handle the situation. Should I treat the instruction that says to add to sip.conf as updated to say the info should be added to sip_post_custom.conf? Any help appreciated. Tom From t.simonnet at esiee.fr Mon Oct 4 06:16:22 2010 From: t.simonnet at esiee.fr (Thierry Simonnet) Date: Mon, 04 Oct 2010 08:16:22 +0200 Subject: [Ekiga-list] adding ekiga as softphone to asterisk 1.6 In-Reply-To: <201010032150.56499.tompoe@meltel.net> References: <201010032150.56499.tompoe@meltel.net> Message-ID: <4CA97136.4070409@esiee.fr> Hello, I use ekiga with Asterisk 1.4 and 1.6 without major troubles. I use 3 asterisk configuration files for SIP usage : users.conf, sip.con and extensions.conf Ekiga's conf : user, name are set to 6001. Registrar : name or IP adress of my PBX. You can use asterisk CLI command : sip show peers to check if user is registered. Don't hesitate to contact me for more informations. Best regards Th. Simonnet ------------------------ users.conf : [general] disallow = all allow = ulaw,alaw,gsm,ilbc,speex,g726,adpcm,lpc10,g729,g723,h261,h263,h263p,h264,t140,red for each user (you can also use macros, LDAP.... [6001] username = Esiee 1 transfer = yes mailbox = 6001 call-limit = 100 type = friend videosupport = yes ;textsupport = yes fullname = Esiee 1 registersip = no host = dynamic callgroup = 1 context = DLPN_ESIEE1 cid_number = 6001 hasvoicemail = yes vmsecret = 6001 email = threewaycalling = no hasdirectory = no callwaiting = no hasmanager = no hasagent = no hassip = yes hasiax = no secret = esiee1 nat = yes qualify = yes canreinvite = no dtmfmode = rfc2833 insecure = port,invite pickupgroup = 1 autoprov = no label = macaddress = linenumber = 1 LINEKEYS = 1 disallow = all allow = ulaw,alaw,gsm,ilbc,speex,g726,adpcm,lpc10,g729,g723,h261,h263,h263p,h264,t140,red sip.conf : I only use this file for registering and defining trunks to other PBX for example for registering ekiga.net : [general] register => :@ekiga.net/ekiga [ekiga] type=friend fromuser= secret= host=ekiga.net canreinvite=no qualify=yes insecure=invite,port context = DID_ekiga nat = yes disallow = all allow = ulaw,alaw,gsm,ilbc,speex,g726,adpcm,lpc10,g729,g723,h261,h263,h263p,h264,t140,red extensions.conf : [general] static = yes writeprotect = no autofallthrough = yes clearglobalvars = no priorityjumping = no [globals] CONSOLE = Console/dsp TRUNKMSD = 1 FEATURES = DIALOPTIONS = RINGTIME = 20 FOLLOWMEOPTIONS = PAGING_HEADER = Intercom CID_6001 = 6001 CID_6002 = 6002 CID_6003 = 6003 CID_6004 = 6004 CID_6005 = 6005 CID_6006 = 6006 CID_6007 = 6007 CID_6008 = 6008 CID_6009 = 6009 CID_6010 = 6010 CID_6011 = 6011 CID_6012 = 6012 ekiga = SIP/ekiga [DLPN_ESIEE1] include = CallingRule_ekiga include = internal include = default include = parkedcalls include = conferences include = ringgroups include = voicemenus include = queues include = voicemailgroups include = directory include = pagegroups include = page_an_extension [CallingRule_ekiga] exten = _4.,1,NoOp() exten = _4.,n,Dial(SIP/ekiga/${EXTEN:1},30) exten = _4.,n,Hangup() [internal] exten = 6200,1,VoicemailMain() exten = _#6XXX,1,Set(MBOX=${EXTEN:1}@default) exten = _#6XXX,n,VoiceMail(${MBOX}) exten = a,1,VoicemailMain(${MBOX}) exten => 6900,1,Verbose(1,Echo test application) ;console asterisk exten => 6900,2,Playback(tt-weasels) ;message a ecouter exten => 6900,n,Echo() ;je parle et je m'entend exten => 6900,n,Hangup() ;d??connection exten = _6XXX,1,NoOp() exten = _6XXX,n,Dial(SIP/${EXTEN},5) exten = _6XXX,n,GotoIf(["${DIALSTATUS}" = "BUSY"]?busy:unavail) exten = _6XXX,n(unavail), Voicemail(${EXTEN}@default,u) exten = _6XXX,n,Hangup() exten = _6XXX,n(busy), Voicemail(${EXTEN}@default,b) exten = _6XXX,n,Hangup() [DID_ekiga] include = internal Le 04/10/2010 03:50, Tom Poe a ?crit : > Here's /etc/sip.conf file quote: > ;sip_custom_post.conf If you have extra parameters that are needed for > a > ;extension to work to for example, those go here. So you have > extension > ;1000 defined in your system you start by creating a line [1000](+) in > this > ;file. Then on the next line add the extra parameter that is needed. > ;When the sip.conf is loaded it will append your additions to the end of > ;that extension. > ; > #include sip_custom_post.conf > > Here's what I found with ekiga documentation about adding ekiga to > asterisk: > Assuming that your Asterisk is in place and functioning, the first step is > to make Ekiga a client of your Asterisk. You do this by having the > following lines in sip.conf ? one of Asterisk's many configuration files: > > [general] > context=default > srvlookup=yes > videosupport=yes > > disallow=all ; First disallow all codecs > allow=ulaw > allow=alaw ; Allow codecs in order of > allow=ilbc ; preference > allow=gsm > allow=h261 > > [101] > type=friend > secret=welcome > qualify=yes ; Qualify peer is not more than 2000 mS away > nat=no ; This phone is not natted > host=dynamic ; This device registers with us > canreinvite=no ; Asterisk by default tries to redirect > context=home > ;port=5061 ; Uncomment this line if Ekiga and Asterisk > ; are on the same host > - - - - - - - - - > > Has anyone figured out how to handle the situation. Should I treat the > instruction that says to add to sip.conf as updated to say the info should > be added to sip_post_custom.conf? > > Any help appreciated. > Tom > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list From c.monty at web.de Mon Oct 4 14:09:16 2010 From: c.monty at web.de (c.monty at web.de) Date: Mon, 4 Oct 2010 16:09:16 +0200 (CEST) Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account Message-ID: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015> An HTML attachment was scrubbed... URL: From Eugen.Dedu at pu-pm.univ-fcomte.fr Mon Oct 4 14:12:53 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Mon, 04 Oct 2010 16:12:53 +0200 Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account In-Reply-To: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015> References: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015> Message-ID: <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> On 04/10/10 16:09, c.monty at web.de wrote: > Hello! > > I'm failing to configure the SIP account correctly. > I enter the following data: > Name: > Registrar: sip.1und1.de > User:<1und1 phone number starting with 49...> > Authentication User:<1und1 phone number starting with 49...> > Password: > Timeout: 3600 > > Using another application "PhonerLite" with exactly the same data, the > connection works. > > But with Ekiga 3.2.7 I get this error message: > Status: Cound not register (Forbidden) > > Are there any other configuration settings that needs to be modified? Yes, see http://wiki.ekiga.org/index.php/Troubleshooting#Cannot_register_to_sip.1und1.de_or_some_other_registrar_with_ekiga_.3C.3D_3.2.x and tell us if it works. -- Eugen From c.monty at web.de Mon Oct 4 14:40:16 2010 From: c.monty at web.de (c.monty at web.de) Date: Mon, 4 Oct 2010 16:40:16 +0200 (CEST) Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account In-Reply-To: <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> References: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015>, <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> Message-ID: <1978968219.2926474.1286203216543.JavaMail.fmail@mwmweb015> Hello! After editing line User:<1und1 phone number starting with 49...>%limit Authentication User:<1und1 phone number starting with 49...>%limit the Status column is empty now. Does this mean Ekiga has connected successfully? THX -----Urspr?ngliche Nachricht----- Von: "Eugen Dedu" Gesendet: 04.10.2010 16:12:53 An: "Ekiga mailing list" Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account On 04/10/10 16:09, c.monty at web.de wrote: > Hello! > > I'm failing to configure the SIP account correctly. > I enter the following data: > Name:[ > Registrar: sip.1und1.de > User:<1und1 phone number starting with 49...> > Authentication User:<1und1 phone number starting with 49...> > Password: > Timeout: 3600 > > Using another application "PhonerLite" with exactly the same data, the > connection works. > > But with Ekiga 3.2.7 I get this error message: > Status: Cound not register (Forbidden) > > Are there any other configuration settings that needs to be modified? Yes, see http://wiki.ekiga.org/index.php/Troubleshooting#Cannot_register_to_sip.1und1.de_or_some_other_registrar_with_ekiga_.3C.3D_3.2.x and tell us if it works. -- Eugen _______________________________________________ ekiga-list mailing list ekiga-list at gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list From palama at inwind.it Mon Oct 4 15:06:25 2010 From: palama at inwind.it (palama at inwind.it) Date: Mon, 4 Oct 2010 17:06:25 +0200 Subject: [Ekiga-list] Missed call notification In-Reply-To: References: <4C971774.4070503@pu-pm.univ-fcomte.fr> <4C9CB671.2060804@pu-pm.univ-fcomte.fr> <20100925144055.4207917f.palama@inwind.it> <20101002130247.65db453e.palama@inwind.it> <4CA729B2.6040305@pu-pm.univ-fcomte.fr> <20101002141939.GA17125@aurora.owens.net> <20101002165913.28515b1a.palama@inwind.it> Message-ID: <20101004170625.417e2e27.palama@inwind.it> On Sat, 2 Oct 2010 19:18:01 -0400 william howell wrote: > > Goto www.elastix.org, download ver 1.6 of their PBX software, it's free, direct you Ekiga sip to that PBX as a trunk, then you have possibilities you never imagined before, and for free (well almost, it will cost you some learning). > > William Thanks for the suggestion. I am already trying to setup an asterisk based PBX and I imagine I will be able to run a voice mail service myself when everything is setup. Anyway this is not what I was looking for i.e. an external notification service that works even if everything is switched off in my shack. Best regards, Antonio Palam? -- From Eugen.Dedu at pu-pm.univ-fcomte.fr Mon Oct 4 16:53:38 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Mon, 04 Oct 2010 18:53:38 +0200 Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account In-Reply-To: <1978968219.2926474.1286203216543.JavaMail.fmail@mwmweb015> References: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015>, <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> <1978968219.2926474.1286203216543.JavaMail.fmail@mwmweb015> Message-ID: <4CAA0692.30903@pu-pm.univ-fcomte.fr> Well, you should modify the *account* name, not your user name. And restart ekiga, just in case. On 04/10/10 16:40, c.monty at web.de wrote: > Hello! > > After editing line > User:<1und1 phone number starting with 49...>%limit > Authentication User:<1und1 phone number starting with 49...>%limit > > the Status column is empty now. > Does this mean Ekiga has connected successfully? > > THX > > > -----Urspr?ngliche Nachricht----- > Von: "Eugen Dedu" > Gesendet: 04.10.2010 16:12:53 > An: "Ekiga mailing list" > Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account > > On 04/10/10 16:09, c.monty at web.de wrote: >> Hello! >> >> I'm failing to configure the SIP account correctly. >> I enter the following data: >> Name:[ >> Registrar: sip.1und1.de >> User:<1und1 phone number starting with 49...> >> Authentication User:<1und1 phone number starting with 49...> >> Password: >> Timeout: 3600 >> >> Using another application "PhonerLite" with exactly the same data, the >> connection works. >> >> But with Ekiga 3.2.7 I get this error message: >> Status: Cound not register (Forbidden) >> >> Are there any other configuration settings that needs to be modified? > > Yes, see > http://wiki.ekiga.org/index.php/Troubleshooting#Cannot_register_to_sip.1und1.de_or_some_other_registrar_with_ekiga_.3C.3D_3.2.x > and tell us if it works. > From franckd at agmp.org Mon Oct 4 17:17:08 2010 From: franckd at agmp.org (Franck Danard) Date: Mon, 04 Oct 2010 19:17:08 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CA83BE8.8090705@agmp.org> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> Message-ID: <4CAA0C14.7080705@agmp.org> No idea about this? */Franck Danard/* Le 03/10/2010 10:16, Franck Danard a ?crit : > Look at the hardcopy: > > > I use the last Ekiga version. (3.2.7). > > Regards > > */Franck Danard/* > > Le 03/10/2010 09:09, Franck Danard a ?crit : >> Hi. >> >> I try since lots of month to use Ekiga on windows XP and I've always >> an error when I launch program. >> Error on entry point...etc >> I tried to find a solution on your mailing list or on the net, but >> nothing. >> For the moment, it's the first program which use the h264 on free >> version and I need it. >> >> Please, could you help me to fix this problem? >> >> Regards >> >> -- >> */Franck Danard/* >> >> >> _______________________________________________ >> ekiga-list mailing list >> ekiga-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 5325 bytes Desc: not available URL: From c.monty at web.de Mon Oct 4 17:22:21 2010 From: c.monty at web.de (Thomas Schneider) Date: Mon, 4 Oct 2010 19:22:21 +0200 (CEST) Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account In-Reply-To: <4CAA0692.30903@pu-pm.univ-fcomte.fr> References: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015>, <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> <1978968219.2926474.1286203216543.JavaMail.fmail@mwmweb015>, <4CAA0692.30903@pu-pm.univ-fcomte.fr> Message-ID: <1205336710.2943857.1286212941786.JavaMail.fmail@mwmweb014> Hello! You are absolutely right: modification of user name was wrong (and stupid). However, now I have a different error message in Status column (for both Ekiga.net account and 1und1 SIP account): Could not register (Transport error) VOIP registration with PhonerLite is still working. THX -----Urspr?ngliche Nachricht----- Von: "Eugen Dedu" <Eugen.Dedu at pu-pm.univ-fcomte.fr> Gesendet: 04.10.2010 18:53:38 An: c.monty at web.de Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account Well, you should modify the *account* name, not your user name. And restart ekiga, just in case. On 04/10/10 16:40, c.monty at web.de wrote: > Hello! > > After editing line > User:<1und1 phone number starting with 49...>%limit > Authentication User:<1und1 phone number starting with 49...>%limit > > the Status column is empty now. > Does this mean Ekiga has connected successfully? > > THX > > > -----Urspr?ngliche Nachricht----- > Von: "Eugen Dedu" > Gesendet: 04.10.2010 16:12:53 > An: "Ekiga mailing list" > Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account > > On 04/10/10 16:09, c.monty at web.de wrote: >> Hello! >> >> I'm failing to configure the SIP account correctly. >> I enter the following data: >> Name:[ >> Registrar: sip.1und1.de >> User:<1und1 phone number starting with 49...> >> Authentication User:<1und1 phone number starting with 49...> >> Password: >> Timeout: 3600 >> >> Using another application "PhonerLite" with exactly the same data, the >> connection works. >> >> But with Ekiga 3.2.7 I get this error message: >> Status: Cound not register (Forbidden) >> >> Are there any other configuration settings that needs to be modified? > > Yes, see > http://wiki.ekiga.org/index.php/Troubleshooting#Cannot_register_to_sip.1und1.de_or_some_other_registrar_with_ekiga_.3C.3D_3.2.x > and tell us if it works. > From Eugen.Dedu at pu-pm.univ-fcomte.fr Mon Oct 4 17:24:24 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Mon, 04 Oct 2010 19:24:24 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CA83BE8.8090705@agmp.org> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> Message-ID: <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> I plan to look into it, but right now I do not have the time, maybe tomorrow or later. There was a post about a similar error, it was because another, older, copy of a library was installed independently of ekiga, and ekiga used that one (it was in the PATH) instead of its own. Is it your case? If no, I need to dig it further... Eugen On 03/10/10 10:16, Franck Danard wrote: > Look at the hardcopy: > > > I use the last Ekiga version. (3.2.7). > > Regards > > */Franck Danard/* > > Le 03/10/2010 09:09, Franck Danard a ?crit : >> Hi. >> >> I try since lots of month to use Ekiga on windows XP and I've always an error >> when I launch program. >> Error on entry point...etc >> I tried to find a solution on your mailing list or on the net, but nothing. >> For the moment, it's the first program which use the h264 on free version and >> I need it. >> >> Please, could you help me to fix this problem? >> >> Regards >> >> -- >> */Franck Danard/* >> >> >> _______________________________________________ >> ekiga-list mailing list >> ekiga-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list From Eugen.Dedu at pu-pm.univ-fcomte.fr Mon Oct 4 17:25:34 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Mon, 04 Oct 2010 19:25:34 +0200 Subject: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account In-Reply-To: <1205336710.2943857.1286212941786.JavaMail.fmail@mwmweb014> References: <2081413023.2906748.1286201356408.JavaMail.fmail@mwmweb015>, <4CA9E0E5.7010207@pu-pm.univ-fcomte.fr> <1978968219.2926474.1286203216543.JavaMail.fmail@mwmweb015>, <4CAA0692.30903@pu-pm.univ-fcomte.fr> <1205336710.2943857.1286212941786.JavaMail.fmail@mwmweb014> Message-ID: <4CAA0E0E.5090002@pu-pm.univ-fcomte.fr> You need to send us the -d 4 output. And be prepared to wait a bit, I am very busy these days... Eugne On 04/10/10 19:22, Thomas Schneider wrote: > Hello! > > You are absolutely right: modification of user name was wrong (and stupid). > > However, now I have a different error message in Status column (for both Ekiga.net account and 1und1 SIP account): > Could not register (Transport error) > > VOIP registration with PhonerLite is still working. > > > THX > > > > -----Urspr?ngliche Nachricht----- > Von: "Eugen Dedu"<Eugen.Dedu at pu-pm.univ-fcomte.fr> > Gesendet: 04.10.2010 18:53:38 > An: c.monty at web.de > Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account > > Well, you should modify the *account* name, not your user name. And > restart ekiga, just in case. > > On 04/10/10 16:40, c.monty at web.de wrote: >> Hello! >> >> After editing line >> User:<1und1 phone number starting with 49...>%limit >> Authentication User:<1und1 phone number starting with 49...>%limit >> >> the Status column is empty now. >> Does this mean Ekiga has connected successfully? >> >> THX >> >> >> -----Urspr?ngliche Nachricht----- >> Von: "Eugen Dedu" >> Gesendet: 04.10.2010 16:12:53 >> An: "Ekiga mailing list" >> Betreff: Re: [Ekiga-list] Configuration Ekiga 3.2.7 (Windows) for 1&1 SIP account >> >> On 04/10/10 16:09, c.monty at web.de wrote: >>> Hello! >>> >>> I'm failing to configure the SIP account correctly. >>> I enter the following data: >>> Name:[ >>> Registrar: sip.1und1.de >>> User:<1und1 phone number starting with 49...> >>> Authentication User:<1und1 phone number starting with 49...> >>> Password: >>> Timeout: 3600 >>> >>> Using another application "PhonerLite" with exactly the same data, the >>> connection works. >>> >>> But with Ekiga 3.2.7 I get this error message: >>> Status: Cound not register (Forbidden) >>> >>> Are there any other configuration settings that needs to be modified? >> >> Yes, see >> http://wiki.ekiga.org/index.php/Troubleshooting#Cannot_register_to_sip.1und1.de_or_some_other_registrar_with_ekiga_.3C.3D_3.2.x >> and tell us if it works. >> > From franckd at agmp.org Mon Oct 4 18:08:44 2010 From: franckd at agmp.org (Franck Danard) Date: Mon, 04 Oct 2010 20:08:44 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> Message-ID: <4CAA182C.7030400@agmp.org> */Franck Danard/* Le 04/10/2010 19:24, Eugen Dedu a ?crit : > I plan to look into it, but right now I do not have the time, maybe > tomorrow or later. Like you want Eugen. ;-) > > There was a post about a similar error, it was because another, older, > copy of a library was installed independently of ekiga, and ekiga used > that one (it was in the PATH) instead of its own. Is it your case? Maybe that yes.It's possible. :-\ > If no, I need to dig it further... In any case, thanks a lot for your help. :-) > > Eugen > > On 03/10/10 10:16, Franck Danard wrote: >> Look at the hardcopy: >> >> >> I use the last Ekiga version. (3.2.7). >> >> Regards >> >> */Franck Danard/* >> >> Le 03/10/2010 09:09, Franck Danard a ?crit : >>> Hi. >>> >>> I try since lots of month to use Ekiga on windows XP and I've >>> always an error >>> when I launch program. >>> Error on entry point...etc >>> I tried to find a solution on your mailing list or on the net, but >>> nothing. >>> For the moment, it's the first program which use the h264 on free >>> version and >>> I need it. >>> >>> Please, could you help me to fix this problem? >>> >>> Regards >>> >>> -- >>> */Franck Danard/* >>> >>> >>> _______________________________________________ >>> ekiga-list mailing list >>> ekiga-list at gnome.org >>> http://mail.gnome.org/mailman/listinfo/ekiga-list >> >> >> >> _______________________________________________ >> ekiga-list mailing list >> ekiga-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From Carl.Hayes at jdsu.com Thu Oct 7 20:00:07 2010 From: Carl.Hayes at jdsu.com (Carl Hayes) Date: Thu, 7 Oct 2010 13:00:07 -0700 Subject: [Ekiga-list] (no subject) Message-ID: <09D542D16F3CBE4C86A3B0DB2A3AFDC51570EA2A08@MILEXCH1.ds.jdsu.net> I tried to use Ekiga. Was able to install correctly but when I try to connect from a windows XP netmeeting ekiga crashes. I have included the GDB output. Any help would be appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: gdb-ekiga.txt.gz Type: application/x-gzip Size: 8735 bytes Desc: gdb-ekiga.txt.gz URL: From franckd at agmp.org Fri Oct 8 04:43:28 2010 From: franckd at agmp.org (Franck Danard) Date: Fri, 08 Oct 2010 06:43:28 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> Message-ID: <4CAEA170.7090303@agmp.org> Hi. I downloaded another dll file, and it does works well now. But this dll isn't more recent than my old dll file: Maybe that I could have some problems in the futur with others programs if they use this dll. My old file is my dll file. The other, is the replaced file. Regards */Franck Danard/* Le 04/10/2010 19:24, Eugen Dedu a ?crit : > I plan to look into it, but right now I do not have the time, maybe > tomorrow or later. > > There was a post about a similar error, it was because another, older, > copy of a library was installed independently of ekiga, and ekiga used > that one (it was in the PATH) instead of its own. Is it your case? > If no, I need to dig it further... > > Eugen > > On 03/10/10 10:16, Franck Danard wrote: >> Look at the hardcopy: >> >> >> I use the last Ekiga version. (3.2.7). >> >> Regards >> >> */Franck Danard/* >> >> Le 03/10/2010 09:09, Franck Danard a ?crit : >>> Hi. >>> >>> I try since lots of month to use Ekiga on windows XP and I've >>> always an error >>> when I launch program. >>> Error on entry point...etc >>> I tried to find a solution on your mailing list or on the net, but >>> nothing. >>> For the moment, it's the first program which use the h264 on free >>> version and >>> I need it. >>> >>> Please, could you help me to fix this problem? >>> >>> Regards >>> >>> -- >>> */Franck Danard/* >>> >>> >>> _______________________________________________ >>> ekiga-list mailing list >>> ekiga-list at gnome.org >>> http://mail.gnome.org/mailman/listinfo/ekiga-list >> >> >> >> _______________________________________________ >> ekiga-list mailing list >> ekiga-list at gnome.org >> http://mail.gnome.org/mailman/listinfo/ekiga-list > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: moz-screenshot.png Type: image/png Size: 2289 bytes Desc: not available URL: From franckd at agmp.org Fri Oct 8 04:51:10 2010 From: franckd at agmp.org (Franck Danard) Date: Fri, 08 Oct 2010 06:51:10 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAEA170.7090303@agmp.org> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> <4CAEA170.7090303@agmp.org> Message-ID: <4CAEA33E.3040307@agmp.org> Hmm Another question. Maybe I can use 2 differents dll file? Use the good dll file for Ekiga into another folder? It's possible to do it? */Franck Danard/* Le 08/10/2010 06:43, Franck Danard a ?crit : > I downloaded another dll file, and it does works well now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome.trullen at etoilediese.fr Fri Oct 8 06:27:29 2010 From: jerome.trullen at etoilediese.fr (=?utf-8?q?=C3=89toile_Di=C3=A8se?=) Date: Fri, 8 Oct 2010 08:27:29 +0200 Subject: [Ekiga-list] H264 video plugin Message-ID: <201010080827.29461.jerome.trullen@etoilediese.fr> Hello, For those whose distribution installed a too recent version of libx264 for Opal to use it, we compiled the H264 video plugin against the version 65 of libx264. The plugin and the library are statically linked so I suppose anyone may download this plugin and use it. The compilation was made with : Distribution : Mandriva 2010.1 this information may be useful if one wants to know which versions of any library was installed on the system when compiling Opal : 3.3.6 sources downloaded from ekiga.org libpt : 2.6.5 original from the distrib Ekiga : 3.2.6 original from the distrib URLs : http://www.etoilediese.fr/client/ekiga/h264_video_pwplugin_helper http://www.etoilediese.fr/client/ekiga/h264_video_pwplugin.so I presume that those files should be copied in /usr/lib/opal-3.6.6/codecs/video and Ekiga restarted. Regards, -- ?toile Di?se From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Oct 8 07:39:39 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 08 Oct 2010 09:39:39 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAEA170.7090303@agmp.org> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> <4CAEA170.7090303@agmp.org> Message-ID: <4CAECABB.70600@pu-pm.univ-fcomte.fr> On 08/10/10 06:43, Franck Danard wrote: > Hi. > > I downloaded another dll file, and it does works well now. > But this dll isn't more recent than my old dll file: I think that in fact ekiga needs an older dll for that library. > Maybe that I could have some problems in the futur with others programs if they > use this dll. > > My old file is my dll file. > The other, is the replaced file. > > Regards > > > */Franck Danard/* > > Le 04/10/2010 19:24, Eugen Dedu a ?crit : >> I plan to look into it, but right now I do not have the time, maybe tomorrow >> or later. >> >> There was a post about a similar error, it was because another, older, copy of >> a library was installed independently of ekiga, and ekiga used that one (it >> was in the PATH) instead of its own. Is it your case? If no, I need to dig >> it further... >> >> Eugen >> >> On 03/10/10 10:16, Franck Danard wrote: >>> Look at the hardcopy: >>> >>> >>> I use the last Ekiga version. (3.2.7). >>> >>> Regards >>> >>> */Franck Danard/* >>> >>> Le 03/10/2010 09:09, Franck Danard a ?crit : >>>> Hi. >>>> >>>> I try since lots of month to use Ekiga on windows XP and I've always an error >>>> when I launch program. >>>> Error on entry point...etc >>>> I tried to find a solution on your mailing list or on the net, but nothing. >>>> For the moment, it's the first program which use the h264 on free version and >>>> I need it. >>>> >>>> Please, could you help me to fix this problem? >>>> >>>> Regards >>>> >>>> -- >>>> */Franck Danard/* From Eugen.Dedu at pu-pm.univ-fcomte.fr Fri Oct 8 07:40:14 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Fri, 08 Oct 2010 09:40:14 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAEA33E.3040307@agmp.org> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> <4CAEA170.7090303@agmp.org> <4CAEA33E.3040307@agmp.org> Message-ID: <4CAECADE.9050204@pu-pm.univ-fcomte.fr> On 08/10/10 06:51, Franck Danard wrote: > Hmm > Another question. > > Maybe I can use 2 differents dll file? > Use the good dll file for Ekiga into another folder? > It's possible to do it? I suppose yes, try putting it in the same directory as ekiga. If it still does not work, ask someone with Windows knowledge. -- Eugen From t.simonnet at esiee.fr Fri Oct 8 08:02:47 2010 From: t.simonnet at esiee.fr (Thierry Simonnet) Date: Fri, 08 Oct 2010 10:02:47 +0200 Subject: [Ekiga-list] Starting problem on Windows In-Reply-To: <4CAECADE.9050204@pu-pm.univ-fcomte.fr> References: <4CA82C17.4000502@agmp.org> <4CA83BE8.8090705@agmp.org> <4CAA0DC8.4080205@pu-pm.univ-fcomte.fr> <4CAEA170.7090303@agmp.org> <4CAEA33E.3040307@agmp.org> <4CAECADE.9050204@pu-pm.univ-fcomte.fr> Message-ID: <4CAED027.7010002@esiee.fr> In fact, ekiga installer packages avutil.dll and put it in the ekiga directory. Then there is no need to upgrade this dll because ekiga.exe is compiled against a reference version. ffmpeg library MUSTN'T be upgraded when used for a specific application. Too much modifications and then often incompatible. Le 08/10/2010 09:40, Eugen Dedu a ?crit : > On 08/10/10 06:51, Franck Danard wrote: >> Hmm >> Another question. >> >> Maybe I can use 2 differents dll file? >> Use the good dll file for Ekiga into another folder? >> It's possible to do it? > > I suppose yes, try putting it in the same directory as ekiga. If it > still does not work, ask someone with Windows knowledge. > From iconoklastic at yahoo.com Mon Oct 11 00:21:38 2010 From: iconoklastic at yahoo.com (Robert Kopp) Date: Sun, 10 Oct 2010 17:21:38 -0700 (PDT) Subject: [Ekiga-list] Invitation to connect on LinkedIn Message-ID: <752460106.1991032.1286756498986.JavaMail.app@ech3-cdn08.prod> LinkedIn ------------ Ekiga, I'd like to add you to my professional network on LinkedIn. - Robert Robert Kopp Support Staff at Community Vision United States Confirm that you know Robert Kopp https://www.linkedin.com/e/-ftw4xo-gf4llgyv-5k/isd/1764519561/g2-h0bNT/ -- (c) 2010, LinkedIn Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamecra at seznam.cz Mon Oct 11 19:26:46 2010 From: adamecra at seznam.cz (adamecra at seznam.cz) Date: Mon, 11 Oct 2010 21:26:46 +0200 (CEST) Subject: [Ekiga-list] Invitation to connect on LinkedIn In-Reply-To: <752460106.1991032.1286756498986.JavaMail.app@ech3-cdn08.prod> Message-ID: <627.191.560-23542-42727946-1286825206@seznam.cz> > ------------ P?vodn? zpr?va ------------ > Od: Robert Kopp > P?edm?t: [Ekiga-list] Invitation to connect on LinkedIn > Datum: 11.10.2010 02:34:19 > ---------------------------------------- > LinkedIn > ------------ > > > Ekiga, > > I'd like to add you to my professional network on LinkedIn. > > - Robert > > Robert Kopp > Support Staff at Community Vision > United States > > Confirm that you know Robert Kopp > https://www.linkedin.com/e/-ftw4xo-gf4llgyv-5k/isd/1764519561/g2-h0bNT/ > > > > -- > (c) 2010, LinkedIn Corporation > > From orschiro at googlemail.com Tue Oct 19 11:33:55 2010 From: orschiro at googlemail.com (orschiro at googlemail.com) Date: Tue, 19 Oct 2010 13:33:55 +0200 Subject: [Ekiga-list] Sip account - busy tone after some time Message-ID: Hi guys, I have a strange problem. I'm connected to a sip account but I don't receive any calls after some time. The person who calls gets then only a busy tone. I'm registered at sipgate.de. Any ideas how to solve this problem? I'm using sipgate version Version : 3.2.7 Release : 4.fc14 for Fedora14. Thank you in advance. -- robert From nursen.tore at gmail.com Sun Oct 24 09:34:36 2010 From: nursen.tore at gmail.com (nursen tore) Date: Sun, 24 Oct 2010 12:34:36 +0300 Subject: [Ekiga-list] xlite setting for ekiga.net account Message-ID: Hello I am using Xlite version 3, in order to use the dial pad of the soft phone. I try configure it with use of my ekiga.net account. i use ekiga.net as proxy server. and use my username and password . I also use stun server as stun.ekiga.net. but i cannot make it work. can somebody help me. Thanks for the answer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at gathman.org Mon Oct 25 02:27:30 2010 From: stuart at gathman.org (Stuart Gathman) Date: Sun, 24 Oct 2010 22:27:30 -0400 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? Message-ID: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> I am new at SIP, but I got tired of googling to try and find why I keep getting 606 from ekiga.net, and dived into the protocol myself with wireshark and RFC3261. So feel free to correct me. STUN is used, and returns the correct public IP and port. Ekiga doesn't use the port (assuming consumer nat with port forwarding, I guess). The REGISTER packet contains this Contact header field: Contact: ;q=1, ;q=0.500 RFC3261 section 8.1.1.8 says there can be only one sip uri, but that seems to be for INVITE only (and 10.3 talks about iterating over all sip uris). So I believe that ekiga.net is barfing on the private ip in the 2nd contact. Other services seem to ignore it, including ekiga call-out (sip.diamondcard.us). ekiga.net gives this response: Status-Line: SIP/2.0 606 Not Acceptable From Eugen.Dedu at pu-pm.univ-fcomte.fr Mon Oct 25 09:26:40 2010 From: Eugen.Dedu at pu-pm.univ-fcomte.fr (Eugen Dedu) Date: Mon, 25 Oct 2010 11:26:40 +0200 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> Message-ID: <4CC54D50.1010108@pu-pm.univ-fcomte.fr> On 25/10/10 04:27, Stuart Gathman wrote: > I am new at SIP, but I got tired of googling to try and find why I keep getting 606 from ekiga.net, and dived into the protocol myself with wireshark and RFC3261. So feel free to correct me. > > STUN is used, and returns the correct public IP and port. Ekiga doesn't use the port (assuming consumer nat with port forwarding, I guess). > > The REGISTER packet contains this Contact header field: > > Contact:;q=1,;q=0.500 > > RFC3261 section 8.1.1.8 says there can be only one sip uri, but that seems to be for INVITE only (and 10.3 talks about iterating over all sip uris). So I believe that ekiga.net is barfing on the private ip in the 2nd contact. Other services seem to ignore it, including ekiga call-out (sip.diamondcard.us). ekiga.net gives this response: > > Status-Line: SIP/2.0 606 Not Acceptable I do not think the error comes from Contact, since I have myself: REGISTER sip:ekiga.net SIP/2.0 [...] Contact: ;q=1, ;q=0.667, ;q=0.334 and ekiga works. You said something about ekiga not using the advertised port. Such a bug was fixed in ekiga 3.2.7, do you use this version or more ancient one? However, that bug prevented the packet to reach ekiga client, not making the sender send 606... Send us the whole conversation (REGISTER and 606 answer I suppose). -- Eugen From israelnogueiramiranda at gmail.com Mon Oct 25 15:44:17 2010 From: israelnogueiramiranda at gmail.com (Israel Miranda) Date: Mon, 25 Oct 2010 13:44:17 -0200 Subject: [Ekiga-list] Problem with netmeeting and h323 Message-ID: Hi there. I can't use ekiga to connect to to a windows xp netmeeting conference. I mean, actually the connection is established but I get no video, no error and I don't know where to look for errors or how to debug it. I tried to connect to a co-worker computer and theoretically there are no network restriction in our LAN, but we are at different locations which are connected through our company's firewalls. I believe this is not a network problem because windows computers in my site can connect to the meeting, but I am having problems with CentOs Linux 5.4 and ekiga 2.02 I used the h323:x.y.z.w syntax to connect using the LAN ip of my co-worker. Any help is appreciated. Thanks in advance. -- "Crie como um deus comande como um rei trabalhe como um escravo." Guy Kawasaki Israel Vin?cius Miranda -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at gathman.org Mon Oct 25 17:27:50 2010 From: stuart at gathman.org (Stuart D Gathman) Date: Mon, 25 Oct 2010 13:27:50 -0400 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <4CC54D50.1010108@pu-pm.univ-fcomte.fr> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> Message-ID: <4CC5BE16.1020105@gathman.org> On 10/25/2010 05:26 AM, Eugen Dedu wrote: >> Status-Line: SIP/2.0 606 Not Acceptable > > I do not think the error comes from Contact, since I have myself: > REGISTER sip:ekiga.net SIP/2.0 > [...] > Contact: ;q=1, > ;q=0.667, > ;q=0.334 > > and ekiga works. > > You said something about ekiga not using the advertised port. Such a > bug was fixed in ekiga 3.2.7, do you use this version or more ancient > one? However, that bug prevented the packet to reach ekiga client, > not making the sender send 606... The bug fixed in 3.2.7 was to use the nat port for RTP connections, not the SIP connection. The nat port isn't used for the SIP connection because the registry wants to give out an IP,port that works from any public ip, not just the registry. This is why port forwarding must be used, and there can be only one SIP client behind a nat firewall. (I'm talking like an expert already, but I'm really not.) This beginner thinks that it would be possible to proxy SIP traffic (which is low bandwidth) through the registry, using the nat port for SIP, and thereby support multiple simultaneous SIP clients behind the nat firewall. This seems, in fact, to be what my companies commercial VOIP outfit (aptela.com) does, since it supports multiple SIP clients behind our iptables nat firewall. I'm pretty sure I don't understand it all yet, because I don't see how STUN can give ekiga (the program) the nat port to use for an RTP connection (which would be to a different IP). > Send us the whole conversation (REGISTER and 606 answer I suppose). Will do as soon as I get home. But I discovered a new wrinkle last night. If I load the ip_nat_sip module for the iptables nat at home, then ekiga.net lets me register. However, diamondcard.us and aptela.com conversations then lose outgoing audio! I also discovered that aptela.com will only let me register at home with STUN turned off. diamondcard.us works either way (except for losing outgoing audio with ip_nat_sip loaded). Obviously, I'm not exactly sure what ip_nat_sip does... From stuart at gathman.org Mon Oct 25 23:38:42 2010 From: stuart at gathman.org (Stuart Gathman) Date: Mon, 25 Oct 2010 19:38:42 -0400 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <4CC54D50.1010108@pu-pm.univ-fcomte.fr> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> Message-ID: <20101025193842.62b09bfb@xo-10-a4-48.localdomain> On Mon, 25 Oct 2010 11:26:40 +0200 Eugen Dedu wrote: > > Send us the whole conversation (REGISTER and 606 answer I suppose). No. Time Source Destination Protocol Info 108 283.537345 192.168.1.105 192.168.10.1 DNS Standard query SRV _sip._udp.ekiga.net Frame 108 (79 bytes on wire, 79 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.216261000 [Time delta from previous captured frame: 7.392260000 seconds] [Time delta from previous displayed frame: 7.392260000 seconds] [Time since reference or first frame: 283.537345000 seconds] Frame Number: 108 Frame Length: 79 bytes Capture Length: 79 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 65 Identification: 0xdd66 (56678) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd08a [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 45367 (45367), Dst Port: domain (53) Source port: 45367 (45367) Destination port: domain (53) Length: 45 Checksum: 0x91cd [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 109] Transaction ID: 0x1fd9 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries _sip._udp.ekiga.net: type SRV, class IN Name: _sip._udp.ekiga.net Type: SRV (Service location) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 41 dd 66 40 00 40 11 d0 8a c0 a8 01 69 c0 a8 .A.f at .@......i.. 0020 0a 01 b1 37 00 35 00 2d 91 cd 1f d9 01 00 00 01 ...7.5.-........ 0030 00 00 00 00 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 00 00 21 00 01 .ekiga.net..!.. No. Time Source Destination Protocol Info 109 283.629180 192.168.10.1 192.168.1.105 DNS Standard query response, No such name Frame 109 (128 bytes on wire, 128 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.308096000 [Time delta from previous captured frame: 0.091835000 seconds] [Time delta from previous displayed frame: 0.091835000 seconds] [Time since reference or first frame: 283.629180000 seconds] Frame Number: 109 Frame Length: 128 bytes Capture Length: 128 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 114 Identification: 0xba14 (47636) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x34ac [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 45367 (45367) Source port: domain (53) Destination port: 45367 (45367) Length: 94 Checksum: 0xaa7d [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 108] [Time: 0.091835000 seconds] Transaction ID: 0x1fd9 Flags: 0x8183 (Standard query response, No such name) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0011 = Reply code: No such name (3) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries _sip._udp.ekiga.net: type SRV, class IN Name: _sip._udp.ekiga.net Type: SRV (Service location) Class: IN (0x0001) Authoritative nameservers ekiga.net: type SOA, class IN, mname dns.ovh.net Name: ekiga.net Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 3 hours Data length: 37 Primary name server: dns.ovh.net Responsible authority's mailbox: tech.ovh.net Serial number: 2009102401 Refresh interval: 1 day Retry interval: 1 hour Expiration limit: 41 days, 16 hours Minimum TTL: 1 day 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 72 ba 14 00 00 3f 11 34 ac c0 a8 0a 01 c0 a8 .r....?.4....... 0020 01 69 00 35 b1 37 00 5e aa 7d 1f d9 81 83 00 01 .i.5.7.^.}...... 0030 00 00 00 01 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 00 00 21 00 01 c0 .ekiga.net..!... 0050 16 00 06 00 01 00 00 2a 30 00 25 03 64 6e 73 03 .......*0.%.dns. 0060 6f 76 68 c0 1c 04 74 65 63 68 c0 35 77 c0 78 41 ovh...tech.5w.xA 0070 00 01 51 80 00 00 0e 10 00 36 ee 80 00 01 51 80 ..Q......6....Q. No. Time Source Destination Protocol Info 110 283.629534 192.168.1.105 192.168.10.1 DNS Standard query SRV _sip._udp.ekiga.net.gathman.org Frame 110 (91 bytes on wire, 91 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.308450000 [Time delta from previous captured frame: 0.000354000 seconds] [Time delta from previous displayed frame: 0.000354000 seconds] [Time since reference or first frame: 283.629534000 seconds] Frame Number: 110 Frame Length: 91 bytes Capture Length: 91 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 77 Identification: 0xdd6f (56687) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd075 [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 42337 (42337), Dst Port: domain (53) Source port: 42337 (42337) Destination port: domain (53) Length: 57 Checksum: 0x27bc [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 111] Transaction ID: 0xed1a Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries _sip._udp.ekiga.net.gathman.org: type SRV, class IN Name: _sip._udp.ekiga.net.gathman.org Type: SRV (Service location) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 4d dd 6f 40 00 40 11 d0 75 c0 a8 01 69 c0 a8 .M.o at .@..u...i.. 0020 0a 01 a5 61 00 35 00 39 27 bc ed 1a 01 00 00 01 ...a.5.9'....... 0030 00 00 00 00 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 07 67 61 74 68 6d .ekiga.net.gathm 0050 61 6e 03 6f 72 67 00 00 21 00 01 an.org..!.. No. Time Source Destination Protocol Info 111 283.648436 192.168.10.1 192.168.1.105 DNS Standard query response Frame 111 (149 bytes on wire, 149 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.327352000 [Time delta from previous captured frame: 0.018902000 seconds] [Time delta from previous displayed frame: 0.018902000 seconds] [Time since reference or first frame: 283.648436000 seconds] Frame Number: 111 Frame Length: 149 bytes Capture Length: 149 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 135 Identification: 0xba15 (47637) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x3496 [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 42337 (42337) Source port: domain (53) Destination port: 42337 (42337) Length: 115 Checksum: 0x9866 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 110] [Time: 0.018902000 seconds] Transaction ID: 0xed1a Flags: 0x8180 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries _sip._udp.ekiga.net.gathman.org: type SRV, class IN Name: _sip._udp.ekiga.net.gathman.org Type: SRV (Service location) Class: IN (0x0001) Authoritative nameservers gathman.org: type SOA, class IN, mname ns1.bmsi.com Name: gathman.org Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 3 hours Data length: 46 Primary name server: ns1.bmsi.com Responsible authority's mailbox: hostadmin.bmsi.com Serial number: 2007052605 Refresh interval: 1 hour Retry interval: 15 minutes Expiration limit: 14 days Minimum TTL: 12 hours 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 87 ba 15 00 00 3f 11 34 96 c0 a8 0a 01 c0 a8 ......?.4....... 0020 01 69 00 35 a5 61 00 73 98 66 ed 1a 81 80 00 01 .i.5.a.s.f...... 0030 00 00 00 01 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 07 67 61 74 68 6d .ekiga.net.gathm 0050 61 6e 03 6f 72 67 00 00 21 00 01 c0 20 00 06 00 an.org..!... ... 0060 01 00 00 2a 30 00 2e 03 6e 73 31 04 62 6d 73 69 ...*0...ns1.bmsi 0070 03 63 6f 6d 00 09 68 6f 73 74 61 64 6d 69 6e c0 .com..hostadmin. 0080 41 77 a1 31 3d 00 00 0e 10 00 00 03 84 00 12 75 Aw.1=..........u 0090 00 00 00 a8 c0 ..... No. Time Source Destination Protocol Info 112 283.650074 192.168.1.105 192.168.10.1 DNS Standard query A ekiga.net Frame 112 (69 bytes on wire, 69 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.328990000 [Time delta from previous captured frame: 0.001638000 seconds] [Time delta from previous displayed frame: 0.001638000 seconds] [Time since reference or first frame: 283.650074000 seconds] Frame Number: 112 Frame Length: 69 bytes Capture Length: 69 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 55 Identification: 0xdd71 (56689) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd089 [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 45758 (45758), Dst Port: domain (53) Source port: 45758 (45758) Destination port: domain (53) Length: 35 Checksum: 0x2e66 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 113] Transaction ID: 0x4d80 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries ekiga.net: type A, class IN Name: ekiga.net Type: A (Host address) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 37 dd 71 40 00 40 11 d0 89 c0 a8 01 69 c0 a8 .7.q at .@......i.. 0020 0a 01 b2 be 00 35 00 23 2e 66 4d 80 01 00 00 01 .....5.#.fM..... 0030 00 00 00 00 00 00 05 65 6b 69 67 61 03 6e 65 74 .......ekiga.net 0040 00 00 01 00 01 ..... No. Time Source Destination Protocol Info 113 283.652424 192.168.10.1 192.168.1.105 DNS Standard query response A 86.64.162.35 Frame 113 (156 bytes on wire, 156 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.331340000 [Time delta from previous captured frame: 0.002350000 seconds] [Time delta from previous displayed frame: 0.002350000 seconds] [Time since reference or first frame: 283.652424000 seconds] Frame Number: 113 Frame Length: 156 bytes Capture Length: 156 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 142 Identification: 0xba16 (47638) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x348e [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 45758 (45758) Source port: domain (53) Destination port: 45758 (45758) Length: 122 Checksum: 0x5756 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 112] [Time: 0.002350000 seconds] Transaction ID: 0x4d80 Flags: 0x8180 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 1 Authority RRs: 2 Additional RRs: 2 Queries ekiga.net: type A, class IN Name: ekiga.net Type: A (Host address) Class: IN (0x0001) Answers ekiga.net: type A, class IN, addr 86.64.162.35 Name: ekiga.net Type: A (Host address) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 24 seconds Data length: 4 Addr: 86.64.162.35 Authoritative nameservers ekiga.net: type NS, class IN, ns ns.ovh.net Name: ekiga.net Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 24 seconds Data length: 9 Name server: ns.ovh.net ekiga.net: type NS, class IN, ns dns.ovh.net Name: ekiga.net Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 24 seconds Data length: 6 Name server: dns.ovh.net Additional records ns.ovh.net: type A, class IN, addr 213.251.128.136 Name: ns.ovh.net Type: A (Host address) Class: IN (0x0001) Time to live: 7 hours, 10 minutes, 11 seconds Data length: 4 Addr: 213.251.128.136 dns.ovh.net: type A, class IN, addr 213.186.33.102 Name: dns.ovh.net Type: A (Host address) Class: IN (0x0001) Time to live: 7 hours, 10 minutes, 11 seconds Data length: 4 Addr: 213.186.33.102 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 8e ba 16 00 00 3f 11 34 8e c0 a8 0a 01 c0 a8 ......?.4....... 0020 01 69 00 35 b2 be 00 7a 57 56 4d 80 81 80 00 01 .i.5...zWVM..... 0030 00 01 00 02 00 02 05 65 6b 69 67 61 03 6e 65 74 .......ekiga.net 0040 00 00 01 00 01 c0 0c 00 01 00 01 00 00 23 b8 00 .............#.. 0050 04 56 40 a2 23 c0 0c 00 02 00 01 00 00 23 b8 00 .V at .#........#.. 0060 09 02 6e 73 03 6f 76 68 c0 12 c0 0c 00 02 00 01 ..ns.ovh........ 0070 00 00 23 b8 00 06 03 64 6e 73 c0 3a c0 37 00 01 ..#....dns.:.7.. 0080 00 01 00 00 64 d3 00 04 d5 fb 80 88 c0 4c 00 01 ....d........L.. 0090 00 01 00 00 64 d3 00 04 d5 ba 21 66 ....d.....!f No. Time Source Destination Protocol Info 114 283.652920 192.168.1.105 192.168.10.1 DNS Standard query PTR 35.162.64.86.in-addr.arpa Frame 114 (85 bytes on wire, 85 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.331836000 [Time delta from previous captured frame: 0.000496000 seconds] [Time delta from previous displayed frame: 0.000496000 seconds] [Time since reference or first frame: 283.652920000 seconds] Frame Number: 114 Frame Length: 85 bytes Capture Length: 85 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 71 Identification: 0xdd71 (56689) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd079 [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 56442 (56442), Dst Port: domain (53) Source port: 56442 (56442) Destination port: domain (53) Length: 51 Checksum: 0x6d8a [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 115] Transaction ID: 0xd2a3 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries 35.162.64.86.in-addr.arpa: type PTR, class IN Name: 35.162.64.86.in-addr.arpa Type: PTR (Domain name pointer) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 47 dd 71 40 00 40 11 d0 79 c0 a8 01 69 c0 a8 .G.q at .@..y...i.. 0020 0a 01 dc 7a 00 35 00 33 6d 8a d2 a3 01 00 00 01 ...z.5.3m....... 0030 00 00 00 00 00 00 02 33 35 03 31 36 32 02 36 34 .......35.162.64 0040 02 38 36 07 69 6e 2d 61 64 64 72 04 61 72 70 61 .86.in-addr.arpa 0050 00 00 0c 00 01 ..... No. Time Source Destination Protocol Info 115 283.655308 192.168.10.1 192.168.1.105 DNS Standard query response PTR ekiga.net Frame 115 (186 bytes on wire, 186 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.334224000 [Time delta from previous captured frame: 0.002388000 seconds] [Time delta from previous displayed frame: 0.002388000 seconds] [Time since reference or first frame: 283.655308000 seconds] Frame Number: 115 Frame Length: 186 bytes Capture Length: 186 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 172 Identification: 0xba17 (47639) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x346f [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 56442 (56442) Source port: domain (53) Destination port: 56442 (56442) Length: 152 Checksum: 0x7a6d [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 114] [Time: 0.002388000 seconds] Transaction ID: 0xd2a3 Flags: 0x8180 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 1 Authority RRs: 2 Additional RRs: 2 Queries 35.162.64.86.in-addr.arpa: type PTR, class IN Name: 35.162.64.86.in-addr.arpa Type: PTR (Domain name pointer) Class: IN (0x0001) Answers 35.162.64.86.in-addr.arpa: type PTR, class IN, ekiga.net Name: 35.162.64.86.in-addr.arpa Type: PTR (Domain name pointer) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 25 seconds Data length: 11 Domain name: ekiga.net Authoritative nameservers 162.64.86.in-addr.arpa: type NS, class IN, ns dns1.gaoland.net Name: 162.64.86.in-addr.arpa Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 25 seconds Data length: 15 Name server: dns1.gaoland.net 162.64.86.in-addr.arpa: type NS, class IN, ns dns2.gaoland.net Name: 162.64.86.in-addr.arpa Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 25 seconds Data length: 7 Name server: dns2.gaoland.net Additional records dns1.gaoland.net: type A, class IN, addr 212.94.162.1 Name: dns1.gaoland.net Type: A (Host address) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 24 seconds Data length: 4 Addr: 212.94.162.1 dns2.gaoland.net: type A, class IN, addr 212.94.162.33 Name: dns2.gaoland.net Type: A (Host address) Class: IN (0x0001) Time to live: 2 hours, 32 minutes, 24 seconds Data length: 4 Addr: 212.94.162.33 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 ac ba 17 00 00 3f 11 34 6f c0 a8 0a 01 c0 a8 ......?.4o...... 0020 01 69 00 35 dc 7a 00 98 7a 6d d2 a3 81 80 00 01 .i.5.z..zm...... 0030 00 01 00 02 00 02 02 33 35 03 31 36 32 02 36 34 .......35.162.64 0040 02 38 36 07 69 6e 2d 61 64 64 72 04 61 72 70 61 .86.in-addr.arpa 0050 00 00 0c 00 01 c0 0c 00 0c 00 01 00 00 23 b9 00 .............#.. 0060 0b 05 65 6b 69 67 61 03 6e 65 74 00 c0 0f 00 02 ..ekiga.net..... 0070 00 01 00 00 23 b9 00 0f 04 64 6e 73 31 07 67 61 ....#....dns1.ga 0080 6f 6c 61 6e 64 c0 3d c0 0f 00 02 00 01 00 00 23 oland.=........# 0090 b9 00 07 04 64 6e 73 32 c0 53 c0 4e 00 01 00 01 ....dns2.S.N.... 00a0 00 00 23 b8 00 04 d4 5e a2 01 c0 69 00 01 00 01 ..#....^...i.... 00b0 00 00 23 b8 00 04 d4 5e a2 21 ..#....^.! No. Time Source Destination Protocol Info 116 283.663436 192.168.1.105 75.101.138.128 STUN Message: Binding Request Frame 116 (70 bytes on wire, 70 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.342352000 [Time delta from previous captured frame: 0.008128000 seconds] [Time delta from previous displayed frame: 0.008128000 seconds] [Time since reference or first frame: 283.663436000 seconds] Frame Number: 116 Frame Length: 70 bytes Capture Length: 70 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:stun] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 75.101.138.128 (75.101.138.128) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 56 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xa2be [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 75.101.138.128 (75.101.138.128) User Datagram Protocol, Src Port: 5068 (5068), Dst Port: stun (3478) Source port: 5068 (5068) Destination port: stun (3478) Length: 36 Checksum: 0x9548 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Simple Traversal of UDP Through NAT [Response In: 117] Message Type: Binding Request (0x0001) Message Length: 0x0008 Message Transaction ID: 111258645A405E08C8FFBFF9F65D0FDE Attributes Attribute: CHANGE-REQUEST Attribute Type: CHANGE-REQUEST (0x0003) Attribute Length: 4 .... .... .... .0.. = Change IP: NOT SET .... .... .... ..0. = Change Port: NOT SET 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 38 00 00 40 00 40 11 a2 be c0 a8 01 69 4b 65 .8.. at .@......iKe 0020 8a 80 13 cc 0d 96 00 24 95 48 00 01 00 08 11 12 .......$.H...... 0030 58 64 5a 40 5e 08 c8 ff bf f9 f6 5d 0f de 00 03 XdZ@^......].... 0040 00 04 00 00 00 00 ...... No. Time Source Destination Protocol Info 117 283.675190 75.101.138.128 192.168.1.105 STUN Message: Binding Response Frame 117 (130 bytes on wire, 130 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.354106000 [Time delta from previous captured frame: 0.011754000 seconds] [Time delta from previous displayed frame: 0.011754000 seconds] [Time since reference or first frame: 283.675190000 seconds] Frame Number: 117 Frame Length: 130 bytes Capture Length: 130 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:stun] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 75.101.138.128 (75.101.138.128), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00) 1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 116 Identification: 0x5bdd (23517) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 52 Protocol: UDP (0x11) Header checksum: 0x5225 [correct] [Good: True] [Bad : False] Source: 75.101.138.128 (75.101.138.128) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: stun (3478), Dst Port: 5068 (5068) Source port: stun (3478) Destination port: 5068 (5068) Length: 96 Checksum: 0xa255 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Simple Traversal of UDP Through NAT [Request In: 116] [Time: 0.011754000 seconds] Message Type: Binding Response (0x0101) Message Length: 0x0044 Message Transaction ID: 111258645A405E08C8FFBFF9F65D0FDE Attributes Attribute: MAPPED-ADDRESS Attribute Type: MAPPED-ADDRESS (0x0001) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port: 5068 IP: 72.209.xxx.xxx (72.209.xxx.xxx) Attribute: SOURCE-ADDRESS Attribute Type: SOURCE-ADDRESS (0x0004) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port: 3478 IP: 10.252.131.113 (10.252.131.113) Attribute: CHANGED-ADDRESS Attribute Type: CHANGED-ADDRESS (0x0005) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port: 3479 IP: 75.101.138.128 (75.101.138.128) Attribute: XOR_MAPPED_ADDRESS Attribute Type: XOR_MAPPED_ADDRESS (0x8020) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port (XOR-d): 734 [Port: 5068] IP (XOR-d): 89.195.156.183 (89.195.156.183) [IP: 72.209.xxx.xxx (72.209.xxx.xxx)] Attribute: SERVER Attribute Type: SERVER (0x8022) Attribute Length: 16 Server version: Vovida.org 0.96 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 80 .....H..~/....E. 0010 00 74 5b dd 40 00 34 11 52 25 4b 65 8a 80 c0 a8 .t[. at .4.R%Ke.... 0020 01 69 0d 96 13 cc 00 60 a2 55 01 01 00 44 11 12 .i.....`.U...D.. 0030 58 64 5a 40 5e 08 c8 ff bf f9 f6 5d 0f de 00 01 XdZ@^......].... 0040 00 08 00 01 13 cc 48 d1 xx xx 00 04 00 08 00 01 ......H......... 0050 0d 96 0a fc 83 71 00 05 00 08 00 01 0d 97 4b 65 .....q........Ke 0060 8a 80 80 20 00 08 00 01 02 de 59 c3 xx xx 80 22 ... ......Y...." 0070 00 10 56 6f 76 69 64 61 2e 6f 72 67 20 30 2e 39 ..Vovida.org 0.9 0080 36 00 6. No. Time Source Destination Protocol Info 118 283.697992 192.168.1.105 192.168.10.1 DNS Standard query SRV _sip._udp.ekiga.net Frame 118 (79 bytes on wire, 79 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.376908000 [Time delta from previous captured frame: 0.022802000 seconds] [Time delta from previous displayed frame: 0.022802000 seconds] [Time since reference or first frame: 283.697992000 seconds] Frame Number: 118 Frame Length: 79 bytes Capture Length: 79 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 65 Identification: 0xdd75 (56693) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd07b [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 57902 (57902), Dst Port: domain (53) Source port: 57902 (57902) Destination port: domain (53) Length: 45 Checksum: 0x263d [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 119] Transaction ID: 0x5a72 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries _sip._udp.ekiga.net: type SRV, class IN Name: _sip._udp.ekiga.net Type: SRV (Service location) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 41 dd 75 40 00 40 11 d0 7b c0 a8 01 69 c0 a8 .A.u at .@..{...i.. 0020 0a 01 e2 2e 00 35 00 2d 26 3d 5a 72 01 00 00 01 .....5.-&=Zr.... 0030 00 00 00 00 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 00 00 21 00 01 .ekiga.net..!.. No. Time Source Destination Protocol Info 119 283.701936 192.168.10.1 192.168.1.105 DNS Standard query response, No such name Frame 119 (128 bytes on wire, 128 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.380852000 [Time delta from previous captured frame: 0.003944000 seconds] [Time delta from previous displayed frame: 0.003944000 seconds] [Time since reference or first frame: 283.701936000 seconds] Frame Number: 119 Frame Length: 128 bytes Capture Length: 128 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 114 Identification: 0xba18 (47640) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x34a8 [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 57902 (57902) Source port: domain (53) Destination port: 57902 (57902) Length: 94 Checksum: 0x3eed [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 118] [Time: 0.003944000 seconds] Transaction ID: 0x5a72 Flags: 0x8183 (Standard query response, No such name) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0011 = Reply code: No such name (3) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries _sip._udp.ekiga.net: type SRV, class IN Name: _sip._udp.ekiga.net Type: SRV (Service location) Class: IN (0x0001) Authoritative nameservers ekiga.net: type SOA, class IN, mname dns.ovh.net Name: ekiga.net Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 3 hours Data length: 37 Primary name server: dns.ovh.net Responsible authority's mailbox: tech.ovh.net Serial number: 2009102401 Refresh interval: 1 day Retry interval: 1 hour Expiration limit: 41 days, 16 hours Minimum TTL: 1 day 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 72 ba 18 00 00 3f 11 34 a8 c0 a8 0a 01 c0 a8 .r....?.4....... 0020 01 69 00 35 e2 2e 00 5e 3e ed 5a 72 81 83 00 01 .i.5...^>.Zr.... 0030 00 00 00 01 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 00 00 21 00 01 c0 .ekiga.net..!... 0050 16 00 06 00 01 00 00 2a 30 00 25 03 64 6e 73 03 .......*0.%.dns. 0060 6f 76 68 c0 1c 04 74 65 63 68 c0 35 77 c0 78 41 ovh...tech.5w.xA 0070 00 01 51 80 00 00 0e 10 00 36 ee 80 00 01 51 80 ..Q......6....Q. No. Time Source Destination Protocol Info 120 283.702347 192.168.1.105 192.168.10.1 DNS Standard query SRV _sip._udp.ekiga.net.gathman.org Frame 120 (91 bytes on wire, 91 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.381263000 [Time delta from previous captured frame: 0.000411000 seconds] [Time delta from previous displayed frame: 0.000411000 seconds] [Time since reference or first frame: 283.702347000 seconds] Frame Number: 120 Frame Length: 91 bytes Capture Length: 91 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 192.168.10.1 (192.168.10.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 77 Identification: 0xdd76 (56694) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd06e [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 192.168.10.1 (192.168.10.1) User Datagram Protocol, Src Port: 59748 (59748), Dst Port: domain (53) Source port: 59748 (59748) Destination port: domain (53) Length: 57 Checksum: 0x7f51 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (query) [Response In: 121] Transaction ID: 0x5182 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries _sip._udp.ekiga.net.gathman.org: type SRV, class IN Name: _sip._udp.ekiga.net.gathman.org Type: SRV (Service location) Class: IN (0x0001) 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 00 4d dd 76 40 00 40 11 d0 6e c0 a8 01 69 c0 a8 .M.v at .@..n...i.. 0020 0a 01 e9 64 00 35 00 39 7f 51 51 82 01 00 00 01 ...d.5.9.QQ..... 0030 00 00 00 00 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 07 67 61 74 68 6d .ekiga.net.gathm 0050 61 6e 03 6f 72 67 00 00 21 00 01 an.org..!.. No. Time Source Destination Protocol Info 121 283.704682 192.168.10.1 192.168.1.105 DNS Standard query response Frame 121 (149 bytes on wire, 149 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.383598000 [Time delta from previous captured frame: 0.002335000 seconds] [Time delta from previous displayed frame: 0.002335000 seconds] [Time since reference or first frame: 283.704682000 seconds] Frame Number: 121 Frame Length: 149 bytes Capture Length: 149 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:dns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.10.1 (192.168.10.1), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 135 Identification: 0xba19 (47641) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0x3492 [correct] [Good: True] [Bad : False] Source: 192.168.10.1 (192.168.10.1) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: domain (53), Dst Port: 59748 (59748) Source port: domain (53) Destination port: 59748 (59748) Length: 115 Checksum: 0xeffb [validation disabled] [Good Checksum: False] [Bad Checksum: False] Domain Name System (response) [Request In: 120] [Time: 0.002335000 seconds] Transaction ID: 0x5182 Flags: 0x8180 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries _sip._udp.ekiga.net.gathman.org: type SRV, class IN Name: _sip._udp.ekiga.net.gathman.org Type: SRV (Service location) Class: IN (0x0001) Authoritative nameservers gathman.org: type SOA, class IN, mname ns1.bmsi.com Name: gathman.org Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 3 hours Data length: 46 Primary name server: ns1.bmsi.com Responsible authority's mailbox: hostadmin.bmsi.com Serial number: 2007052605 Refresh interval: 1 hour Retry interval: 15 minutes Expiration limit: 14 days Minimum TTL: 12 hours 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 00 .....H..~/....E. 0010 00 87 ba 19 00 00 3f 11 34 92 c0 a8 0a 01 c0 a8 ......?.4....... 0020 01 69 00 35 e9 64 00 73 ef fb 51 82 81 80 00 01 .i.5.d.s..Q..... 0030 00 00 00 01 00 00 04 5f 73 69 70 04 5f 75 64 70 ......._sip._udp 0040 05 65 6b 69 67 61 03 6e 65 74 07 67 61 74 68 6d .ekiga.net.gathm 0050 61 6e 03 6f 72 67 00 00 21 00 01 c0 20 00 06 00 an.org..!... ... 0060 01 00 00 2a 30 00 2e 03 6e 73 31 04 62 6d 73 69 ...*0...ns1.bmsi 0070 03 63 6f 6d 00 09 68 6f 73 74 61 64 6d 69 6e c0 .com..hostadmin. 0080 41 77 a1 31 3d 00 00 0e 10 00 00 03 84 00 12 75 Aw.1=..........u 0090 00 00 00 a8 c0 ..... No. Time Source Destination Protocol Info 122 283.710300 192.168.1.105 86.64.162.35 SIP Request: REGISTER sip:ekiga.net Frame 122 (605 bytes on wire, 605 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.389216000 [Time delta from previous captured frame: 0.005618000 seconds] [Time delta from previous displayed frame: 0.005618000 seconds] [Time since reference or first frame: 283.710300000 seconds] Frame Number: 122 Frame Length: 605 bytes Capture Length: 605 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: QuantaMi_10:a4:48 (00:17:c4:10:a4:48), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Destination: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 192.168.1.105 (192.168.1.105), Dst: 86.64.162.35 (86.64.162.35) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 591 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x7e29 [correct] [Good: True] [Bad : False] Source: 192.168.1.105 (192.168.1.105) Destination: 86.64.162.35 (86.64.162.35) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 571 Checksum: 0xae45 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Session Initiation Protocol Request-Line: REGISTER sip:ekiga.net SIP/2.0 Method: REGISTER Request-URI: sip:ekiga.net Request-URI Host Part: ekiga.net [Resent Packet: False] Message Header CSeq: 8 REGISTER Sequence Number: 8 Method: REGISTER Via: SIP/2.0/UDP 72.209.xxx.xxx:5060;branch=z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448;rport Transport: UDP Sent-by Address: 72.209.xxx.xxx Sent-by port: 5060 Branch: z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448 RPort: rport User-Agent: Ekiga/3.2.7 From: ;tag=2ebd02e0-3ade-df11-9109-0017c410a448 SIP from address: sip:SDGathman at ekiga.net SIP from address User Part: SDGathman SIP from address Host Part: ekiga.net SIP tag: 2ebd02e0-3ade-df11-9109-0017c410a448 Call-ID: a06902e0-3ade-df11-9109-0017c410a448 at xo-10-a4-48.localdomain To: SIP to address: sip:SDGathman at ekiga.net SIP to address User Part: SDGathman SIP to address Host Part: ekiga.net Contact: ;q=1, ;q=0.500 Contact Binding: ;q=1 URI: SIP contact address: sip:SDGathman at 72.209.xxx.xxx Contact Binding: ;q=0.500 URI: SIP contact address: sip:SDGathman at 192.168.1.105 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING Expires: 3600 Content-Length: 0 Max-Forwards: 70 0000 00 1d 7e 2f bd 0c 00 17 c4 10 a4 48 08 00 45 00 ..~/.......H..E. 0010 02 4f 00 00 40 00 40 11 7e 29 c0 a8 01 69 56 40 .O.. at .@.~)...iV@ 0020 a2 23 13 c4 13 c4 02 3b ae 45 52 45 47 49 53 54 .#.....;.EREGIST 0030 45 52 20 73 69 70 3a 65 6b 69 67 61 2e 6e 65 74 ER sip:ekiga.net 0040 20 53 49 50 2f 32 2e 30 0d 0a 43 53 65 71 3a 20 SIP/2.0..CSeq: 0050 38 20 52 45 47 49 53 54 45 52 0d 0a 56 69 61 3a 8 REGISTER..Via: 0060 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 37 32 2e SIP/2.0/UDP 72. 0070 32 30 39 2e xx xx xx 2e xx xx xx 3a 35 30 36 30 209.xxx.xxx:5060 0080 3b 62 72 61 6e 63 68 3d 7a 39 68 47 34 62 4b 66 ;branch=z9hG4bKf 0090 38 33 65 31 62 65 30 2d 33 61 64 65 2d 64 66 31 83e1be0-3ade-df1 00a0 31 2d 39 31 30 39 2d 30 30 31 37 63 34 31 30 61 1-9109-0017c410a 00b0 34 34 38 3b 72 70 6f 72 74 0d 0a 55 73 65 72 2d 448;rport..User- 00c0 41 67 65 6e 74 3a 20 45 6b 69 67 61 2f 33 2e 32 Agent: Ekiga/3.2 00d0 2e 37 0d 0a 46 72 6f 6d 3a 20 3c 73 69 70 3a 53 .7..From: ;tag=2ebd02e0 0100 2d 33 61 64 65 2d 64 66 31 31 2d 39 31 30 39 2d -3ade-df11-9109- 0110 30 30 31 37 63 34 31 30 61 34 34 38 0d 0a 43 61 0017c410a448..Ca 0120 6c 6c 2d 49 44 3a 20 61 30 36 39 30 32 65 30 2d ll-ID: a06902e0- 0130 33 61 64 65 2d 64 66 31 31 2d 39 31 30 39 2d 30 3ade-df11-9109-0 0140 30 31 37 63 34 31 30 61 34 34 38 40 78 6f 2d 31 017c410a448 at xo-1 0150 30 2d 61 34 2d 34 38 2e 6c 6f 63 61 6c 64 6f 6d 0-a4-48.localdom 0160 61 69 6e 0d 0a 54 6f 3a 20 3c 73 69 70 3a 53 44 ain..To: ..Contact: ;q=1, 01b0 20 3c 73 69 70 3a 53 44 47 61 74 68 6d 61 6e 40 ;q 01d0 3d 30 2e 35 30 30 0d 0a 41 6c 6c 6f 77 3a 20 49 =0.500..Allow: I 01e0 4e 56 49 54 45 2c 41 43 4b 2c 4f 50 54 49 4f 4e NVITE,ACK,OPTION 01f0 53 2c 42 59 45 2c 43 41 4e 43 45 4c 2c 53 55 42 S,BYE,CANCEL,SUB 0200 53 43 52 49 42 45 2c 4e 4f 54 49 46 59 2c 52 45 SCRIBE,NOTIFY,RE 0210 46 45 52 2c 4d 45 53 53 41 47 45 2c 49 4e 46 4f FER,MESSAGE,INFO 0220 2c 50 49 4e 47 0d 0a 45 78 70 69 72 65 73 3a 20 ,PING..Expires: 0230 33 36 30 30 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 3600..Content-Le 0240 6e 67 74 68 3a 20 30 0d 0a 4d 61 78 2d 46 6f 72 ngth: 0..Max-For 0250 77 61 72 64 73 3a 20 37 30 0d 0a 0d 0a wards: 70.... No. Time Source Destination Protocol Info 123 283.805316 86.64.162.35 192.168.1.105 SIP Status: 606 Not Acceptable (0 bindings) Frame 123 (494 bytes on wire, 494 bytes captured) Arrival Time: Oct 24, 2010 20:17:09.484232000 [Time delta from previous captured frame: 0.095016000 seconds] [Time delta from previous displayed frame: 0.095016000 seconds] [Time since reference or first frame: 283.805316000 seconds] Frame Number: 123 Frame Length: 494 bytes Capture Length: 494 bytes [Frame is marked: True] [Protocols in frame: eth:ip:udp:sip] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Destination: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) Address: QuantaMi_10:a4:48 (00:17:c4:10:a4:48) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Address: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 86.64.162.35 (86.64.162.35), Dst: 192.168.1.105 (192.168.1.105) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00) 1000 00.. = Differentiated Services Codepoint: Class Selector 4 (0x20) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 480 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 54 Protocol: UDP (0x11) Header checksum: 0x8818 [correct] [Good: True] [Bad : False] Source: 86.64.162.35 (86.64.162.35) Destination: 192.168.1.105 (192.168.1.105) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) Length: 460 Checksum: 0x45c1 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Session Initiation Protocol Status-Line: SIP/2.0 606 Not Acceptable Status-Code: 606 [Resent Packet: False] [Request Frame: 122] [Response Time (ms): 95] Message Header CSeq: 8 REGISTER Sequence Number: 8 Method: REGISTER Via: SIP/2.0/UDP 192.168.10.6:5060;branch=z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448;rport=5060;received=72.209.xxx.xxx Transport: UDP Sent-by Address: 192.168.10.6 Sent-by port: 5060 Branch: z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448 RPort: 5060 Received: 72.209.xxx.xxx From: ;tag=2ebd02e0-3ade-df11-9109-0017c410a448 SIP from address: sip:SDGathman at ekiga.net SIP from address User Part: SDGathman SIP from address Host Part: ekiga.net SIP tag: 2ebd02e0-3ade-df11-9109-0017c410a448 Call-ID: a06902e0-3ade-df11-9109-0017c410a448 at xo-10-a4-48.localdomain To: ;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.ead5 SIP to address: sip:SDGathman at ekiga.net SIP to address User Part: SDGathman SIP to address Host Part: ekiga.net SIP tag: c64e1f832a41ec1c1f4e5673ac5b80f6.ead5 Server: Kamailio (1.5.3-notls (i386/linux)) Content-Length: 0 0000 00 17 c4 10 a4 48 00 1d 7e 2f bd 0c 08 00 45 80 .....H..~/....E. 0010 01 e0 00 00 40 00 36 11 88 18 56 40 a2 23 c0 a8 .... at .6...V@.#.. 0020 01 69 13 c4 13 c4 01 cc 45 c1 53 49 50 2f 32 2e .i......E.SIP/2. 0030 30 20 36 30 36 20 4e 6f 74 20 41 63 63 65 70 74 0 606 Not Accept 0040 61 62 6c 65 0d 0a 43 53 65 71 3a 20 38 20 52 45 able..CSeq: 8 RE 0050 47 49 53 54 45 52 0d 0a 56 69 61 3a 20 53 49 50 GISTER..Via: SIP 0060 2f 32 2e 30 2f 55 44 50 20 31 39 32 2e 31 36 38 /2.0/UDP 192.168 0070 2e 31 30 2e 36 3a 35 30 36 30 3b 62 72 61 6e 63 .10.6:5060;branc 0080 68 3d 7a 39 68 47 34 62 4b 66 38 33 65 31 62 65 h=z9hG4bKf83e1be 0090 30 2d 33 61 64 65 2d 64 66 31 31 2d 39 31 30 39 0-3ade-df11-9109 00a0 2d 30 30 31 37 63 34 31 30 61 34 34 38 3b 72 70 -0017c410a448;rp 00b0 6f 72 74 3d 35 30 36 30 3b 72 65 63 65 69 76 65 ort=5060;receive 00c0 64 3d 37 32 2e 32 30 39 2e xx xx xx 2e xx xx xx d=72.209.xxx.xxx 00d0 0d 0a 46 72 6f 6d 3a 20 3c 73 69 70 3a 53 44 47 ..From: ;tag=2ebd02e0-3 0100 61 64 65 2d 64 66 31 31 2d 39 31 30 39 2d 30 30 ade-df11-9109-00 0110 31 37 63 34 31 30 61 34 34 38 0d 0a 43 61 6c 6c 17c410a448..Call 0120 2d 49 44 3a 20 61 30 36 39 30 32 65 30 2d 33 61 -ID: a06902e0-3a 0130 64 65 2d 64 66 31 31 2d 39 31 30 39 2d 30 30 31 de-df11-9109-001 0140 37 63 34 31 30 61 34 34 38 40 78 6f 2d 31 30 2d 7c410a448 at xo-10- 0150 61 34 2d 34 38 2e 6c 6f 63 61 6c 64 6f 6d 61 69 a4-48.localdomai 0160 6e 0d 0a 54 6f 3a 20 3c 73 69 70 3a 53 44 47 61 n..To: 0180 3b 74 61 67 3d 63 36 34 65 31 66 38 33 32 61 34 ;tag=c64e1f832a4 0190 31 65 63 31 63 31 66 34 65 35 36 37 33 61 63 35 1ec1c1f4e5673ac5 01a0 62 38 30 66 36 2e 65 61 64 35 0d 0a 53 65 72 76 b80f6.ead5..Serv 01b0 65 72 3a 20 4b 61 6d 61 69 6c 69 6f 20 28 31 2e er: Kamailio (1. 01c0 35 2e 33 2d 6e 6f 74 6c 73 20 28 69 33 38 36 2f 5.3-notls (i386/ 01d0 6c 69 6e 75 78 29 29 0d 0a 43 6f 6e 74 65 6e 74 linux))..Content 01e0 2d 4c 65 6e 67 74 68 3a 20 30 0d 0a 0d 0a -Length: 0.... From stuart at gathman.org Tue Oct 26 20:09:24 2010 From: stuart at gathman.org (Stuart D Gathman) Date: Tue, 26 Oct 2010 16:09:24 -0400 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <20101025193842.62b09bfb@xo-10-a4-48.localdomain> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> Message-ID: <4CC73574.2030200@gathman.org> On 10/25/2010 07:38 PM, Stuart Gathman wrote: > On Mon, 25 Oct 2010 11:26:40 +0200 > Eugen Dedu wrote: > > Send us the whole conversation (REGISTER and 606 answer I suppose). > > > > Source: 86.64.162.35 (86.64.162.35) > Destination: 192.168.1.105 (192.168.1.105) > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > Source port: sip (5060) > Destination port: sip (5060) > Length: 460 > Checksum: 0x45c1 [validation disabled] > [Good Checksum: False] > [Bad Checksum: False] > Session Initiation Protocol > Status-Line: SIP/2.0 606 Not Acceptable > Status-Code: 606 > [Resent Packet: False] > [Request Frame: 122] > [Response Time (ms): 95] > Message Header > CSeq: 8 REGISTER > Sequence Number: 8 > Method: REGISTER > Via: SIP/2.0/UDP 192.168.10.6:5060;branch=z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448;rport=5060;received=72.209.xxx.xxx > > How did that 192.168.10.6 get in there? That is probably what ekiga.net is complaining about? It is certainly not in the REGISTER packet. From benoit.seutin at gmail.com Wed Oct 27 11:20:26 2010 From: benoit.seutin at gmail.com (=?ISO-8859-1?Q?Beno=EEt_Seutin?=) Date: Wed, 27 Oct 2010 13:20:26 +0200 Subject: [Ekiga-list] Full screen video call Message-ID: Hello, When I am in a video call, is it possible to display video in full screen ? If not, it is an interessant feature. Regards, -- Beno?t Seutin -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.simonnet at esiee.fr Wed Oct 27 11:27:32 2010 From: t.simonnet at esiee.fr (Thierry Simonnet) Date: Wed, 27 Oct 2010 13:27:32 +0200 Subject: [Ekiga-list] Full screen video call In-Reply-To: References: Message-ID: <4CC80CA4.5070105@esiee.fr> F11 or View -> Fullscreen Le 27/10/2010 13:20, Beno?t Seutin a ?crit : > Hello, > > When I am in a video call, is it possible to display video in full > screen ? > If not, it is an interessant feature. > > Regards, > > -- > Beno?t Seutin > > > _______________________________________________ > ekiga-list mailing list > ekiga-list at gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From thedogfarted at gmail.com Wed Oct 27 15:12:45 2010 From: thedogfarted at gmail.com (=?UTF-8?B?SsSBbmlzIFJ1a8WhxIFucw==?=) Date: Wed, 27 Oct 2010 18:12:45 +0300 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <4CC73574.2030200@gathman.org> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> <4CC73574.2030200@gathman.org> Message-ID: On Tue, Oct 26, 2010 at 11:09 PM, Stuart D Gathman wrote: > On 10/25/2010 07:38 PM, Stuart Gathman wrote: >> >> On Mon, 25 Oct 2010 11:26:40 +0200 >> Eugen Dedu ?wrote: >> >> Send us the whole conversation (REGISTER and 606 answer I suppose). >> >> >> >> ? ? Source: 86.64.162.35 (86.64.162.35) >> ? ? Destination: 192.168.1.105 (192.168.1.105) >> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) >> ? ? Source port: sip (5060) >> ? ? Destination port: sip (5060) >> ? ? Length: 460 >> ? ? Checksum: 0x45c1 [validation disabled] >> ? ? ? ? [Good Checksum: False] >> ? ? ? ? [Bad Checksum: False] >> Session Initiation Protocol >> ? ? Status-Line: SIP/2.0 606 Not Acceptable >> ? ? ? ? Status-Code: 606 >> ? ? ? ? [Resent Packet: False] >> ? ? ? ? [Request Frame: 122] >> ? ? ? ? [Response Time (ms): 95] >> ? ? Message Header >> ? ? ? ? CSeq: 8 REGISTER >> ? ? ? ? ? ? Sequence Number: 8 >> ? ? ? ? ? ? Method: REGISTER >> Via: SIP/2.0/UDP 192.168.10.6:5060;branch=z9hG4bKf83e1be0-3ade-df11-9109-0017c410a448;rport=5060;received=72.209.xxx.xxx >> > How did that 192.168.10.6 get in there? ?That is probably what ekiga.net is > complaining about? ?It is certainly not in the REGISTER packet. Now something is really strange here. From the trace I guess that your local (private) IP is 192.168.1.105. If so, the what is the "192.168.10.6"?? Could it be the case that 192.168.10.6 is your gateway, trying to be a SIP ALG (Application Level Gateway) by rewriting packets, and failing badly. Wherever the 192.168.10.6 came from, it *IS* the reason why ekiga.net barfs, and that is a *BUG*. Myself and others have complained about that since long ago, to no avail. *NOWHERE* in the SIP standards it says that a registrar should barf on private IPs in Via. Even more, it breaks clients that use SIP outbound + ICE instead of STUN to traverse NAT (as SIP outbound *REQUIRES* to have non-NATed address in Via). -- Ian From thedogfarted at gmail.com Wed Oct 27 15:19:26 2010 From: thedogfarted at gmail.com (=?UTF-8?B?SsSBbmlzIFJ1a8WhxIFucw==?=) Date: Wed, 27 Oct 2010 18:19:26 +0300 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> <4CC73574.2030200@gathman.org> Message-ID: On Wed, Oct 27, 2010 at 6:12 PM, J?nis Ruk??ns wrote: > Wherever the 192.168.10.6 came from, it *IS* the reason why ekiga.net > barfs, and that is a *BUG*. Myself and others have complained about > that since long ago, to no avail. *NOWHERE* in the SIP standards it > says that a registrar should barf on private IPs in Via. Even more, it > breaks clients that use SIP outbound + ICE instead of STUN to traverse > NAT (as SIP outbound *REQUIRES* to have non-NATed address in Via). Oh, and... >>> Session Initiation Protocol >>> Status-Line: SIP/2.0 606 Not Acceptable Quoting RFC 3261, section 10.3 Processing REGISTER Requests: "A registrar MUST not generate 6xx responses." (the last sentence in the first paragraph). As you can see, ekiga.net violates this one as well. -- Ian From stuart at gathman.org Wed Oct 27 15:33:50 2010 From: stuart at gathman.org (Stuart Gathman) Date: Wed, 27 Oct 2010 11:33:50 -0400 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> <4CC73574.2030200@gathman.org> Message-ID: <4CC8465E.7040100@gathman.org> On 10/27/2010 11:19 AM, J?nis Ruk??ns wrote: > On Wed, Oct 27, 2010 at 6:12 PM, J?nis Ruk??ns wrote: > >> Wherever the 192.168.10.6 came from, it *IS* the reason why ekiga.net >> barfs, and that is a *BUG*. Myself and others have complained about >> that since long ago, to no avail. *NOWHERE* in the SIP standards it >> says that a registrar should barf on private IPs in Via. Even more, it >> breaks clients that use SIP outbound + ICE instead of STUN to traverse >> NAT (as SIP outbound *REQUIRES* to have non-NATed address in Via). >> That IP turns out to be "public" IP of the Linksys wireless router connected to the local LAN, which is managed by a linux server. The laptops go through the wireless router. When I get a chance, I'll run a trace on the packets as they enter the linux server from the router - to see whether linux (centos-5.4) or the linksys is rewriting the REGISTER packets. I suspect the latter. Thank you for looking at this. It explains why many services (including the commercial ones I'm using) work fine. Ekiga.net has some bugs that need to be worked around to use their free service. I think now my goal is to run a sipproxy our home linux server. That should fix up issues with ekiga, and allow multiple simultaneous clients (not that our ISP would be happy with that ... but no worse than ISO downloads). Maybe there are other free sip registrars that don't have (these particular) bugs. From thedogfarted at gmail.com Wed Oct 27 16:18:31 2010 From: thedogfarted at gmail.com (=?UTF-8?B?SsSBbmlzIFJ1a8WhxIFucw==?=) Date: Wed, 27 Oct 2010 19:18:31 +0300 Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: <4CC8465E.7040100@gathman.org> References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> <4CC73574.2030200@gathman.org> <4CC8465E.7040100@gathman.org> Message-ID: On Wed, Oct 27, 2010 at 6:33 PM, Stuart Gathman wrote: > That IP turns out to be "public" IP of the Linksys wireless router > connected to the local LAN, which is managed by a linux server. ?The > laptops go through the wireless router. ? When I get a chance, I'll run > a trace on the packets as they enter the linux server from the router - > to see whether linux (centos-5.4) or the linksys is rewriting the > REGISTER packets. ?I suspect the latter. If the Linksys router is used only as an access point, putting the router in bridging mode (I think most of them have it) could help. Then NATing would happen only on your Linux server, which you can configure to your likening. Btw if you plan to post the trace on the list, please attach a zipped pcap file rather than posting it's contents inline. The latter makes it hard to read. > Maybe there are other free sip registrars that don't have > (these particular) bugs. Look around in the list archives, IIRC there was a couple of them mentioned in not so old posts. I think iptel.org was one of them. Cheers -- Ian From stuart at gathman.org Thu Oct 28 00:02:42 2010 From: stuart at gathman.org (Stuart D. Gathman) Date: Wed, 27 Oct 2010 20:02:42 -0400 (EDT) Subject: [Ekiga-list] Invalid Contact header field, or bug in ekiga.net? In-Reply-To: References: <20101024222730.7cf9de20@xo-10-a4-48.localdomain> <4CC54D50.1010108@pu-pm.univ-fcomte.fr> <20101025193842.62b09bfb@xo-10-a4-48.localdomain> <4CC73574.2030200@gathman.org> <4CC8465E.7040100@gathman.org> Message-ID: On Wed, 27 Oct 2010, J?nis Ruk??ns wrote: > If the Linksys router is used only as an access point, putting the > router in bridging mode (I think most of them have it) could help. > Then NATing would happen only on your Linux server, which you can > configure to your likening. That would be ok, except - Looks like I configured the Linksys to only have access to selected services on the server and the internet. Bridging would give it access to the rest of the LAN. I have an openvpn that laptops use to talk to each other and the LAN. I guess I didn't trust WPA much :-) I also remember wanting to make the WAP public, in which case I certainly wouldn't give it access to the LAN :-) I think a sipproxy is the best solution. > Btw if you plan to post the trace on the list, please attach a zipped > pcap file rather than posting it's contents inline. The latter makes > it hard to read. Sorry about that. Will zip it next time. Some lists don't like attachments. -- Stuart D. Gathman Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. From aramil at freemail.gr Sun Oct 31 11:01:31 2010 From: aramil at freemail.gr (Aramil) Date: Sun, 31 Oct 2010 13:01:31 +0200 Subject: [Ekiga-list] No incoming traffic problem Message-ID: <4CCD4C8B.2000901@freemail.gr> Hello all, I am using a NanoStation 2 in Router mode.The NS is connected wirelessly to my neighbor's router and a switch is connect via ethernet to the NS for LAN use. The past few days I'm trying to use a VoIP client software to connect to my VoIP account.I use Ekiga Softphone to do so, which requires UDP ports 3478-3479 and 5000-5100 to be open. So I have opened these ports both on my neighbor's router and on the NS.The problem that I'm encountering is that although I manage to register to the VoIP service, when I answer an incoming call the caller is able to hear me, but I'm not able to hear the caller.So I used wireshark and figured that there is no incoming traffic on my end. I have used many linux VoIP clients with PCs connecting straight forward to an ADSL router and worked perfectly.So this has something to do with NS... Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vandevliert at gmail.com Sun Oct 31 15:47:28 2010 From: vandevliert at gmail.com (ETJ vandevliert) Date: Sun, 31 Oct 2010 16:47:28 +0100 Subject: [Ekiga-list] how to change callerID Message-ID: Hello, we are using xlite and like to change to Ekiga. There is one feature we are not able to configure. In Xlite when being called the incoming call is matched with the xlite address book. If there is a similar record in the address book of xlite available, it will be shown in the popup of the incoming call. Example: Xlite will also show the name of the contact with telephone number 04422535 in the call popup. "Incoming call from David Callalot" If Egika does have a similar contact lookup feature for incoming calls, pls explain how to configure. If not, how can this feature be added? Grz, Evan Bos -------------- next part -------------- An HTML attachment was scrubbed... URL: From aramil at freemail.gr Sun Oct 31 10:41:39 2010 From: aramil at freemail.gr (Aramil) Date: Sun, 31 Oct 2010 12:41:39 +0200 Subject: [Ekiga-list] No incoming traffic problem Message-ID: <4CCD47E3.4060405@freemail.gr> Hello all, I am using a NanoStation 2 in Router mode.The NS is connected wirelessly to my neighbor's router and a switch is connect via ethernet to the NS for LAN use. The past few days I'm trying to use a VoIP client software to connect to my VoIP account.I use Ekiga Softphone to do so, which requires UDP ports 3478-3479 and 5000-5100 to be open. So I have opened these ports both on my neighbor's router and on the NS.The problem that I'm encountering is that although I manage to register to the VoIP service, when I answer an incoming call the caller is able to hear me, but I'm not able to hear the caller.So I used wireshark and figured that there is no incoming traffic on my end. I have used many linux VoIP clients with PCs connecting straight forward to an ADSL router and worked perfectly.So this has something to do with NS... Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: