Re: [asterisk-users] sip forking needed for ekiga 3.0
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 legal. > > The real question is why does Asterisk think it is the same request > when the > from tag is different ? > > b. > Asterisk ignores tags in To and From headers unless you have "pedantic=yes" set in sip.conf. Mark Michelson ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 RFC -- see MESSAGE) because the tag is different doesn't make it any > less poorly designed just because it's not specifically written that it > can't be done. The Ekiga developer points out: Have a look at this link : http://www.faqs.org/rfcs/rfc3261.html And look how an UAS (Asterisk in this case) is supposed to handle merged requests : 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. In our case, the From tag is different, so it should not detect a loop. This excerpt show that any client or server should be able to receive merged requests. There is obviously a bug here in Asterisk. I have no idea how (in-)correct it is, again, just being the messenger. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 legal. > > The real question is why does Asterisk think it is the same request > when the > from tag is different ? > > b. > > 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 RFC -- see MESSAGE) because the tag is different doesn't make it any less poorly designed just because it's not specifically written that it can't be done. N. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 question is why does Asterisk think it is the same request when the from tag is different ? b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
> -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 enough of the thread to know the Asterisk issue you are > > trying to describe is loop detection and not forking. Asterisk does > > support forking: Dial(SIP/user1&SIP/user2) is forking. Not > being able > > to handle duplicate requests from different IPs is loop handling and > > you'll already find bugs open about that. > > I will relay your description of "loop detection" back on to the Ekiga > guys. I'm just the messenger here. Can you provide a SIP trace of the signalling taking place? What are you getting back from the Asterisk box? - Brad ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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. It used to be called the Gateway of Last Resort. Last being final and not penultimate. With that being said, if you somehow manage to get by the internal consistency checks and more than one interface (and by interface, I also mean alias, as those are 'virtual interfaces') matches the default gateway, your machine is misconfigured and internet traffic will not properly flow. I know you're just the messenger here, and it's not your fault. But the message is wrong. Ekiga has tried to solve a problem (that of determining a 'best path' for SIP to allow data flow in a NAT or filtered scenario) using poorly thought-out logic. While there may be any number of SIP proxies out there (SER is one of them, and I know that's what the Ekiga service uses) that might be able to handle a mistake on the client side with ease and grace, there's no guarantee that they all will, and assuming they will simply because your test environment allows it is lazy. The RFCs are there for a reason. All SIP forking is UAS territory. Not UAC territory. N. Brian J. Murrell wrote: > 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 more than one matches? Then what? > > Have you read the whole thread here? > > b. > > > > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 filtering, etc.? > > And if the network set up is too complex that that still causes > problems do what the Ekiga guy told you and set the IP address you > want to use in the config file. Uhm. That's not an option. There is no option to do that. Should there be? Perhaps. But hey, I'm just here to report the "failure" (i.e. to properly accept multiple "legal" registrations through this so called SIP forking) that the Ekiga guys are telling me about. > I've read enough of the thread to know the Asterisk issue you are > trying to describe is loop detection and not forking. Asterisk does > support forking: Dial(SIP/user1&SIP/user2) is forking. Not being able > to handle duplicate requests from different IPs is loop handling and > you'll already find bugs open about that. I will relay your description of "loop detection" back on to the Ekiga guys. I'm just the messenger here. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 complex that that still causes problems do what the Ekiga guy told you and set the IP address you want to use in the config file. It's not a difficult situation. I have servers with 15 public IP addresses on them and manage to run SIP services no problems. I've read enough of the thread to know the Asterisk issue you are trying to describe is loop detection and not forking. Asterisk does support forking: Dial(SIP/user1&SIP/user2) is forking. Not being able to handle duplicate requests from different IPs is loop handling and you'll already find bugs open about that. > Oh? I like to make sure I've done my homework before ascending to sarcasm especially when I'm the one that requested "Thots" in the first place... Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 more than one matches? Then what? Have you read the whole thread here? b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
"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 difficult to determine the best IP address for a piece of client software to use. Check the local machines default gateway, apply the subnet mask and then compare it against all the local IP's. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 Dial(SIP/exten1&SIP/exten2&SIP/exten3,...)). > > Exactly. These are all endpoint or middlepoint things. SIP forking is never an original starting point thing. That's just WEIRD. You fork to hit multiple endpoints simultaneously. Not one endpoint from multiple starting points. N. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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/exten1&SIP/exten2&SIP/exten3,...)). -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 you are to "just work". > Call me a purist, but > I'm of the opinion that you should KNOW which interface to use based on > which interface is registered We are talking about IP aliases here, not real interfaces. > and choose ONE interface based on the > rules you've established during registration. What rules would you establish during registration? > What happens if you want > to ensure that data goes across a VPN (in order to encrypt your VoIP > communications) instead of the public internet? Presumably you have some [policy] routing that ensures that. But on the other hand, if you did have two addresses on an interface, one for VPN and one for "everything else", unless you "shotgun" out you need to either know which address to use or ask the user. Either case may fail. > That takes all the logic out of the equation and just says, "Here's a > bunch of packets. Figure out what to do with them. I'll be waiting for > your response." I don't think it's quite that bad. It's more like here's a bunch of session requests, please complete them [you don't know it yet, but I'm going to tear down all but the first one you complete]. But the glitch is that even though I send you 3 of them, due to [policy] routing and firewalling, you might only get one. > There's a reason routing rules exist and mature services allow you to > control the interface from which it originates. Really, I'm just the messenger here. I doubt the ekiga team and the asterisk team would be willing to sit down and discuss who is right here, so I'm trying to be the conduit. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 that data goes across a VPN (in order to encrypt your VoIP communications) instead of the public internet? Or if you want to ensure a particular route based on why you created your multiple interfaces in the first place? That takes all the logic out of the equation and just says, "Here's a bunch of packets. Figure out what to do with them. I'll be waiting for your response." There's a reason routing rules exist and mature services allow you to control the interface from which it originates. N. Brian J. Murrell wrote: > 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 that one or more of the IP aliases will fail > for whatever reason (policy routing, filtering, etc.), so just try them > all, and use the first one to make a completion and drop the others. > > b. > > > > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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 that one or more of the IP aliases will fail for whatever reason (policy routing, filtering, etc.), so just try them all, and use the first one to make a completion and drop the others. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
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). 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? N. Brian J. Murrell wrote: > 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 multiple addresses on my workstation: > > 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff > inet 10.75.22.1/24 brd 10.75.22.255 scope global eth0 > inet 10.75.22.101/24 brd 10.75.22.255 scope global secondary eth0:1 > > So when ekiga (3.0) tries to place a call through Asterisk it in fact > does parallel requests from all addresses. This is what appears to > confuse Asterisk. Please see the above tickets for more details. > > Thots? > > b. > > > > > ___ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > AstriCon 2008 - September 22 - 25 Phoenix, Arizona > Register Now: http://www.astricon.net > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
