GNOME Bugzilla – Bug 553810
Add an option to force Ekiga to bind only to a specific address
Last modified: 2008-10-20 18:10:04 UTC
Some broken systems do not support well SIP forking, and induce an incoherent behavior when receiving forked requests. In those cases, we should allow the client to bind only to one specific address. See bug #553595
Indeed. I'd even opt for a gconf key with no UI (yet, perhaps) that I could plug in the address to bind. This SIP forking behavior... the idea is that Ekiga will complete the SIP transaction with the first "fork" to complete and throw away the others? What little I read on SIP forking explains it in the opposite direction, forking out to multiple different SIP endpoints, presumably the first to answer connects. We have a service like this at work called "followme" where I put all of the possible phone numbers I could be at into the system and when somebody calls me, they all ring and the one that picks up gets connected. So basically a one-to-many fork rather than a many-to-one fork.
Yes, but even an endpoint can do forking. Otherwise, you have no way to transparently support many "ip addresses" corresponding to different routes.
FWIW, I can work around this issue by installing a local (i.e. to the machine running ekiga) iptables rule: # iptables -I OUTPUT -s ! 10.75.22.1 -d pbx -p udp --dport 5060 -j REJECT Where, as you might guess 10.75.22.1 is the only address I want to use when connecting to my Asterisk server (pbx).
So, some messages later on the asterisk-users mailing list and I am told that this feature, of multiple registrations is not in fact SIP forking, but something else called "loop handling". It seems to be re-enforced over several messages that SIP forking is in fact making multiple outgoing SIP connections to different end-points. I guess ultimately, the question is, do you really want to release (maybe 3.0 is already "release"d) Ekiga 3.0 when it fails to operate in such an environment. I'm sure I won't be the last person trying to connect it to Asterisk from a machine with multiple IPs.
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 ? A loop is still something different. Are you sure you talked with people who know SIP ?
This would probably be easier if you'd just get on the asterisk-users list and chime in, but here is what "SIP <sip@arcdiv.com>" says: 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. How much sip@arcdiv.com knows about SIP, I don't know.
I don't want to go and start a flame on the users mailing list with people who think they know something and in fact know nothing. 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.
Notice also that REGISTER never works, it is the root cause of the problem.
(In reply to comment #7) > I don't want to go and start a flame on the users mailing list with people who > think they know something and in fact know nothing. a) having a discussion about software interaction is not a flame b) how do you know they know nothing? A discussion is needed to come to a conclusion about how Asterisk and/or Ekiga should move forward to resolving this issue. > 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. If you say so. I'm not even a SIP amateur, never mind expert. I'm just trying to bring the two parties that are not inter-operating together to a conclusion. I'm just about done with all of this though. I have a solution that works for me and your refusal to meet and discuss the issue is just frustrating. How can anything constructive come about if you won't even consider discussing it?
I don't want to subscribe to the user mailing list and start a discussion because I do not want to spend hours loosing my precious spare time and getting nervous with aggressive users (I have read his e-mails and I do not want to discuss with him at all). Moreover, that forking technic is not from me, but from the OPAL guys. I did not code on that part of the OPAL stack, so I am not the one with the good arguments to go there and argue in their name. However, I found this in the RFC : UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. That means that, at least for the REGISTER, we are not respecting the RFC.
(In reply to comment #10) > > However, I found this in the RFC : > UAs MUST NOT send a new registration (that is, containing new Contact > header field values, as opposed to a retransmission) until they have > received a final response from the registrar for the previous one or > the previous REGISTER request has timed out. > > That means that, at least for the REGISTER, we are not respecting the RFC. Ahhh. I wonder if that is what is helping to confuse Asterisk. I think personally, I'd like to hold off pointing the finger at Asterisk any further until that is fixed. It's difficult to argue that somebody is doing something wrong when one is not doing everything right themselves. Did you open a bug on that REGISTER thing (so I can CC and follow progress) or will you handle that bug in this ticket?
"It's difficult to argue that somebody is doing something wrong when one is not doing everything right themselves." I don't want to answer to insults. (not referring to you but to the guy who is hiding behind the 'SIP' nickname). We can keep this ticket open, I have asked Robert what he thinks about this. But my remark above is still valid. Asterisk is not able to handle forking. If you put a proxy in front of it, and that the proxy forks requests, you will get the same problem than Ekiga, which is not the correct behavior. It is not a question of good design, or poor design. And this guys is not even an Asterisk developer, so if I want to discuss it, I will discuss it with someone knowledgeable like Olle or Kevin, not with this 'SIP' dude.
(In reply to comment #12) > > We can keep this ticket open, I have asked Robert what he thinks about this. OK. Robert is the OPAL guy? > But my remark above is still valid. Asterisk is not able to handle forking. If > you put a proxy in front of it, and that the proxy forks requests, you will get > the same problem than Ekiga, which is not the correct behavior. It is not a > question of good design, or poor design. And this guys is not even an Asterisk > developer, so if I want to discuss it, I will discuss it with someone > knowledgeable like Olle or Kevin, not with this 'SIP' dude. OK. So once the REGISTER issue is resolved, can you try to resolve that? I think you are more likely to get an Asterisk developer's attention than I am. I suppose the right course of action is to file a bug in Digium's bug handler. I really don't want to be the go-between on that again though. Are you willing to file a bug with Digium?
(In reply to comment #5) > 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 ? Mark Michelson <mmichelson@digium.com> says: Asterisk ignores tags in To and From headers unless you have "pedantic=yes" set in sip.conf.
The behavior has been improved in 3.0.1.