Great News (Score: 2, Interesting) by rocks@pipedot.org on 2014-04-28 18:09 (#17X) I actually paid for Skype for group video chat... and I joined GooglePlus for Hangouts...Personally, I would prefer to pay Skype than have to join a Social Network, but this is the pressure of modern collaboration, you have to go where your colleagues are or you just look ludite.Maybe this means I won't need to renew my Skype subscription to retain this feature. Unfortunately, they had it set up on auto-renew when I signed up, so I will have to check my preferences, which is something I frequently forget to check... thanks for the heads up in any case Re: Great News (Score: 2, Interesting) by renevith@pipedot.org on 2014-04-28 19:24 (#184) Assuming you've used both Skype and Hangouts video chat a fair amount, how would you compare the quality/stability etc.? Do you ever use them over a sketchy connection, on either side? Re: Great News (Score: 2, Interesting) by rocks@pipedot.org on 2014-04-29 12:09 (#18M) I like both. I use Skype more -- but this is mostly because many of my contacts are on Skype. My experience with Skype is that it can be unstable on certain links, especially using wireless internet at some hotels and such. Then again, I have used it for international connections from all over Europe, Latin America and North America and would rate my satisfaction >95%. I like Google Hangouts as well and it has been stable for me in all cases. Then again, I have not tested Google Hangouts on the same connections where Skype has experienced difficulty. I have only used Google Hangouts from wired or otherwise strong internet connections where Skype works fine as well. My sense is that Skype/Hangouts connection quality is linked directly to internet connection quality.The link between Google+ and Google Hangouts stopped me from using Hangouts for a long time (I have zero interest in social networks), but I finally joined to use Hangouts because certain work collaborations had a pre-existing culture of using Hangouts and not Skype. Since then, I have been surprised at the number of contacts who have joined Google+ principally to use Hangouts. Anecdotally then, I would say that Hangouts is competing well and perhaps this is why Skype dropped the fee. I think my ideal scenario would be an open or standard communication protocol like email for multi-head video chat so that different people, groups could all be using different clients without being centralized in some database. This probably exists, but if everyone is on Skype/GooglePlus/Facebook it is not necessarily suitable. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 16:26 (#1A5) viva Jitsi.org!https://meet.jit.si is the future, today. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 19:06 (#1AF) Ugh, this is terrible. The standard Jitsi client (not the WebRTCed version linked above) won't even talk to Ekiga.net and similar networks! (Because of conflicting NAT traversal methodologies.) What a mess the open source conferencing world is in.From the Jitsi FAQ:_________Why can't I connect to ekiga.net?NB: the problems described in this section also apply to other providers such as 1und1.deShort Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:However, experience since the publication of RFC 3489 has foundthat classic STUN simply does not work sufficiently well to bea deployable solution.Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.___________
Re: Great News (Score: 2, Interesting) by renevith@pipedot.org on 2014-04-28 19:24 (#184) Assuming you've used both Skype and Hangouts video chat a fair amount, how would you compare the quality/stability etc.? Do you ever use them over a sketchy connection, on either side? Re: Great News (Score: 2, Interesting) by rocks@pipedot.org on 2014-04-29 12:09 (#18M) I like both. I use Skype more -- but this is mostly because many of my contacts are on Skype. My experience with Skype is that it can be unstable on certain links, especially using wireless internet at some hotels and such. Then again, I have used it for international connections from all over Europe, Latin America and North America and would rate my satisfaction >95%. I like Google Hangouts as well and it has been stable for me in all cases. Then again, I have not tested Google Hangouts on the same connections where Skype has experienced difficulty. I have only used Google Hangouts from wired or otherwise strong internet connections where Skype works fine as well. My sense is that Skype/Hangouts connection quality is linked directly to internet connection quality.The link between Google+ and Google Hangouts stopped me from using Hangouts for a long time (I have zero interest in social networks), but I finally joined to use Hangouts because certain work collaborations had a pre-existing culture of using Hangouts and not Skype. Since then, I have been surprised at the number of contacts who have joined Google+ principally to use Hangouts. Anecdotally then, I would say that Hangouts is competing well and perhaps this is why Skype dropped the fee. I think my ideal scenario would be an open or standard communication protocol like email for multi-head video chat so that different people, groups could all be using different clients without being centralized in some database. This probably exists, but if everyone is on Skype/GooglePlus/Facebook it is not necessarily suitable. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 16:26 (#1A5) viva Jitsi.org!https://meet.jit.si is the future, today. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 19:06 (#1AF) Ugh, this is terrible. The standard Jitsi client (not the WebRTCed version linked above) won't even talk to Ekiga.net and similar networks! (Because of conflicting NAT traversal methodologies.) What a mess the open source conferencing world is in.From the Jitsi FAQ:_________Why can't I connect to ekiga.net?NB: the problems described in this section also apply to other providers such as 1und1.deShort Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:However, experience since the publication of RFC 3489 has foundthat classic STUN simply does not work sufficiently well to bea deployable solution.Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.___________
Re: Great News (Score: 2, Interesting) by rocks@pipedot.org on 2014-04-29 12:09 (#18M) I like both. I use Skype more -- but this is mostly because many of my contacts are on Skype. My experience with Skype is that it can be unstable on certain links, especially using wireless internet at some hotels and such. Then again, I have used it for international connections from all over Europe, Latin America and North America and would rate my satisfaction >95%. I like Google Hangouts as well and it has been stable for me in all cases. Then again, I have not tested Google Hangouts on the same connections where Skype has experienced difficulty. I have only used Google Hangouts from wired or otherwise strong internet connections where Skype works fine as well. My sense is that Skype/Hangouts connection quality is linked directly to internet connection quality.The link between Google+ and Google Hangouts stopped me from using Hangouts for a long time (I have zero interest in social networks), but I finally joined to use Hangouts because certain work collaborations had a pre-existing culture of using Hangouts and not Skype. Since then, I have been surprised at the number of contacts who have joined Google+ principally to use Hangouts. Anecdotally then, I would say that Hangouts is competing well and perhaps this is why Skype dropped the fee. I think my ideal scenario would be an open or standard communication protocol like email for multi-head video chat so that different people, groups could all be using different clients without being centralized in some database. This probably exists, but if everyone is on Skype/GooglePlus/Facebook it is not necessarily suitable. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 16:26 (#1A5) viva Jitsi.org!https://meet.jit.si is the future, today. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 19:06 (#1AF) Ugh, this is terrible. The standard Jitsi client (not the WebRTCed version linked above) won't even talk to Ekiga.net and similar networks! (Because of conflicting NAT traversal methodologies.) What a mess the open source conferencing world is in.From the Jitsi FAQ:_________Why can't I connect to ekiga.net?NB: the problems described in this section also apply to other providers such as 1und1.deShort Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:However, experience since the publication of RFC 3489 has foundthat classic STUN simply does not work sufficiently well to bea deployable solution.Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.___________
Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 16:26 (#1A5) viva Jitsi.org!https://meet.jit.si is the future, today. Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 19:06 (#1AF) Ugh, this is terrible. The standard Jitsi client (not the WebRTCed version linked above) won't even talk to Ekiga.net and similar networks! (Because of conflicting NAT traversal methodologies.) What a mess the open source conferencing world is in.From the Jitsi FAQ:_________Why can't I connect to ekiga.net?NB: the problems described in this section also apply to other providers such as 1und1.deShort Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:However, experience since the publication of RFC 3489 has foundthat classic STUN simply does not work sufficiently well to bea deployable solution.Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.___________
Re: Great News (Score: 0) by Anonymous Coward on 2014-05-01 19:06 (#1AF) Ugh, this is terrible. The standard Jitsi client (not the WebRTCed version linked above) won't even talk to Ekiga.net and similar networks! (Because of conflicting NAT traversal methodologies.) What a mess the open source conferencing world is in.From the Jitsi FAQ:_________Why can't I connect to ekiga.net?NB: the problems described in this section also apply to other providers such as 1und1.deShort Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:However, experience since the publication of RFC 3489 has foundthat classic STUN simply does not work sufficiently well to bea deployable solution.Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.___________