Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Grey Man
Shotgunning the use of IP addresses is foolish at best and lazy programming at worst. Imagine if the poeple writing browsers did that! The internet could end up with double or triple the traffic for no extra benefit not to mention the additinoal load on web servers etc. It's not particularly

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Brian J. Murrell
On Fri, 2008-09-26 at 08:43 +0100, Grey Man wrote: It's not particularly difficult to determine the best IP address for a piece of client software to use. Oh? Check the local machines default gateway, apply the subnet mask and then compare it against all the local IP's. Yeah? And if

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Grey Man
On Fri, Sep 26, 2008 at 2:36 PM, Brian J. Murrell [EMAIL PROTECTED] wrote: Check the local machines default gateway, apply the subnet mask and then compare it against all the local IP's. Yeah? And if more than one matches? Then what? Use one of them! And if the network set up is too

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Brian J. Murrell
On Fri, 2008-09-26 at 14:54 +0100, Grey Man wrote: On Fri, Sep 26, 2008 at 2:36 PM, Brian J. Murrell [EMAIL PROTECTED] wrote: Yeah? And if more than one matches? Then what? Use one of them! And if the one I choose to use doesn't work because of some kind of policy routing or

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread SIP
A machine with more than one default gateway is a VERY special case (used for load-balancing or possibly failover). Most systems will not allow it. I mean... logically, it's odd. Default means when not applied to any other special rule, I choose this one.Not this two. Not this three. This one.

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Watkins, Bradley
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian J. Murrell Sent: Friday, September 26, 2008 10:12 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] sip forking needed for ekiga 3.0 I've read

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Brian J. Murrell
On Fri, 2008-09-26 at 10:16 -0400, SIP wrote: The RFCs are there for a reason. All SIP forking is UAS territory. Not UAC territory. From http://bugzilla.gnome.org/show_bug.cgi?id=553810 Damien Sandras asks: I repeat, Ekiga is doing something perfectly legal. The real

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread SIP
Brian J. Murrell wrote: On Fri, 2008-09-26 at 10:16 -0400, SIP wrote: The RFCs are there for a reason. All SIP forking is UAS territory. Not UAC territory. From http://bugzilla.gnome.org/show_bug.cgi?id=553810 Damien Sandras asks: I repeat, Ekiga is doing something

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Brian J. Murrell
On Fri, 2008-09-26 at 10:41 -0400, SIP wrote: Oh yes. It's perfectly legal. It's also a) NOT SIP forking, b) Lazy, and c) Poorly designed. Sending multiple requests and hoping and praying that the recipient will ignore two of them (it will NOT in many cases -- specifically set out by the

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-26 Thread Mark Michelson
Brian J. Murrell wrote: On Fri, 2008-09-26 at 10:16 -0400, SIP wrote: The RFCs are there for a reason. All SIP forking is UAS territory. Not UAC territory. From http://bugzilla.gnome.org/show_bug.cgi?id=553810 Damien Sandras asks: I repeat, Ekiga is doing something perfectly

[asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread Brian J. Murrell
So, I have been testing ekiga 3.0 with Asterisk, and sadly, it don't work. I am told by the ekiga devs in http://bugzilla.gnome.org/show_bug.cgi?id=553595 and http://bugzilla.gnome.org/show_bug.cgi?id=553810 that the problem is that Asterisk does not support SIP forking. The issue is that I have

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread SIP
My thoughts are that to do parallel requests from every IP address on the machine is extremely weird behaviour. How would any server know which to respond to? SIP forking is supposed to send requests to multiple different destinations (or fork mid-stream to send to different destinations).

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread Brian J. Murrell
On Thu, 2008-09-25 at 14:56 -0400, SIP wrote: Sending from multiple different points of origin doesn't make any sense at all in either a logical or rational fashion. What's it supposed to accomplish? It seems to be a shot-gun approach to making a SIP connection. The assumption being I suppose

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread SIP
That strikes me as being careless and unreliable. Call me a purist, but I'm of the opinion that you should KNOW which interface to use based on which interface is registered and choose ONE interface based on the rules you've established during registration. What happens if you want to ensure

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread Brian J. Murrell
On Thu, 2008-09-25 at 15:31 -0400, SIP wrote: That strikes me as being careless and unreliable. That's one argument. I can also see the ekiga developers' argument though and that's to strive for the most automatic functionality possible. The less things you have to ask users, the more likely

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread Alex Balashov
You need to define what you mean by SIP forking. There are many things people mean by that. They are usually one of: 1) Call branching (proxies do this). 2) Parallel but distinct call legs managed by a UAC (this is what Asterisk does when you Dial(SIP/exten1SIP/exten2SIP/exten3,...)). --

Re: [asterisk-users] sip forking needed for ekiga 3.0

2008-09-25 Thread SIP
Alex Balashov wrote: You need to define what you mean by SIP forking. There are many things people mean by that. They are usually one of: 1) Call branching (proxies do this). 2) Parallel but distinct call legs managed by a UAC (this is what Asterisk does when you