Summary:	ASTERISK-00724: [patch] Sip 30X-reply support
Reporter:	zond (zond)	Labels:
Date Opened:	2003-12-29 17:41:27.000-0600	Date Closed:	2011-06-07 14:04:56
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_sipforward.patch
Description:	The sip 301 reply is not at all supported, and sip 302 allways uses the internal routing (ast_request with type="Local"), even when the sip-reply contains a perfectly defined sip-address. Also, the callerid gets lost in the forwarding. The supplied cvs diff contains a fix that adds sip 301-reply support, adds an optional extended call_forward-declaration used when sip-forwarding and adds callerid to the forwarded call. Please tell me if you want the diff in another format, I am quite new at this kind of contribution.
Comments:	By: Brian West (bkw918) 2003-12-29 18:01:26.000-0600 diff -u please By: zond (zond) 2003-12-29 18:48:22.000-0600 Aight, now the two changed files are "diff -u"'d and the results uploaded. By: zond (zond) 2004-01-05 11:10:56.000-0600 Bugfix in the patch. By: Brian West (bkw918) 2004-01-11 12:25:27.000-0600 which ones needs to be applied and has anyone else tested this? By: zond (zond) 2004-01-11 12:33:26.000-0600 Use the newest patch. I have no idea wether anyone else has tried it yet.. By: jrollyson (jrollyson) 2004-01-25 21:23:02.000-0600 Mark, can you review this one and see what its going to break. Also, do we want to handle native *external* transfers at all? Would this be best served as a config option? ie allow-external-transfer or some such? By: jrollyson (jrollyson) 2004-01-25 21:36:39.000-0600 If I read this right, I think I see potential for this feature to be heavily abused. Do we really want to be able to send *any* call from * to any arbitrary external SIP destination without any administrative oversight to allow it. If this is implemented, there MUST be some control over whether or not it is allowed and what external destinations are acceptable. By: Mark Spencer (markster) 2004-01-25 21:37:03.000-0600 This is certainly an interesting patch, but i definitely don't like a few parts of it: 1) Is 301 the same as 302?  If so, just do 301: before 302: and it gets the same treatment. 2) I'm not sure I"m content with the idea of allowing phones to redirect us to arbitrary SIP locations.  For example, I run FWD or similar service and then I someone has me try to call sip.dontscrewithus.mil with different strings by forwarding my call.  Also, this presents an easy denial of service attack against asterisk by simply redirecting us to a URI that doesn't exist or takes a long time to resolve.  At a minimum this would have to be configurable in the general section (and possibly in individual friends/peers/users for bonus points). 3) Avoid using malloc so freely.  malloc means trouble and I try to use it only where absolutely necessary. By: zond (zond) 2004-01-26 03:31:25.000-0600 Aight. I will refine the patch if you want. How about this? 1) I believe they should be treated the same, anyway - I think it is only their more or less temporary status that differs - lets put 301 right before 302 to clean the code up. 2) Lets make it so only a "user" in the sip.conf can forward like this (or a "friend", of course) - since they can make the asterisk dial anyplace anyway. 3) Ok, how do you want it done? I am no c-hacker -- what is the best way? By: zond (zond) 2004-01-26 03:33:46.000-0600 One more thing - lets have one administrative option in the [general] part of the sip.conf that defines networks we allow anyone to 301/302-forward to... My actual use for this patch is to allow another registrator/proxy on the same host to 301-forward to another of its ports. By: Olle Johansson (oej) 2004-01-26 08:39:37.000-0600 Scenario I want to support: * An Asterisk user calls outbound to sip:something@domain.com * The receiving SIP proxy issues a 302 redirect to sip:somethingelse@domain.com * The call is initiated by a new invite to sip:somethingelse@domain.com by asterisk We could optionally allow automatic redirection or somehow cancel the call and inform the callee of the new address. Option: allowsipredirect=yes|no in [general] section or in a [peer] definition for peer. Not sure how allow/deny domains would work. We already allow calling to any domain through Asterisk. Maybe some SIP proxies responsible for the domain according to the DNS should be trusted to issue a redirect for a call to that domain. Food for thought. I haven't checked what level of support for this that is implemented today. By: zond (zond) 2004-01-28 06:04:36.000-0600 The scenario you describe is as far as I know the one my patch creates. The optional redirection could work, but it would be preferable to decide to which domains one want them allowed. Yes, we allow calling anywhere through *, but not by anyone (ie, not by non-user/friend proxies). By: zond (zond) 2004-01-28 08:09:13.000-0600 Now I have created a patch that adds the option "cansipforward" to the "general" context and to the peer-context of sip.conf I am not _completely_ sure this works in all cases, please doublecheck if anyone knows a lot about the sip-dial routines. If either global cansipforward is set, or the peers cansipforward is set, a 301/302 is parsed as a complete SIP URL, else it is just an extension parsed as before the patch. I have also removed the double code at 301: I have not, however, removed the mallocs, since I am not completely aware of how I should do instead. By: Brian West (bkw918) 2004-02-05 21:04:43.000-0600 Use this on all your ast_verbose to keep in sync with the rest of it. ast_verbose(VERBOSE_PREFIX_3 "somethinghere\n"); Other than that it works. By: zond (zond) 2004-02-06 06:18:07.000-0600 Ok, VERBOSE_PREFIX_3 added. By: zond (zond) 2004-02-06 06:32:30.000-0600 Oops, my bad, uploaded the wrong file. Now it should be the right one. By: zond (zond) 2004-02-14 10:37:07.000-0600 Well, we have been using this patch for production for a few months now, anyway. By: Olle Johansson (oej) 2004-03-17 16:11:03.000-0600 Testing this. One problem that I stumble over is that if I redirect back to my Asterisk server, I get 'loop detected', meaning I can't redirect back to my server. We need to make Asterisk aware of what domains it serve, but it's not an easy fix. Also, on my FreeBSD I couldn't find strndup(), so I had to rewrite that part to strdup and then null the rest of the string out. The patch also relies on URLs and channel names to map, which I don't think is always true - is it? A sip redirect could reply with mailto:, tel:, sip: h323: and possibly other urls. Especially the tel: url needs handling similar to the enumlookup function (which is wrong now, but anyway)... I think this patch is a huge step forward. Will incorporate it in the chan_sip2 testing, and add the dial part to app_dial2 when I get time for it. By: zond (zond) 2004-03-17 16:17:43.000-0600 Hmyes, the loop detected may be a problem.. perhaps some kind of ttl should be implemented instead? Hm, the strndup-thing seems annoying.. but easily fixed :D Anyway, I agree that this patch needs lots of work.. but I too think it is a step in the right direction. By: Olle Johansson (oej) 2004-03-17 16:37:15.000-0600 No ttl needed, domain support needed. Working that direction. As I said, I think it needs maturing withing chan_sip2. :-) Right now, this patch works in SIP only environments with Asterisk, as long as you don't try to redirect to another Asterisk extension, which may happen with phones that redirect on DND. edited on: 03-17-04 15:34 By: Olle Johansson (oej) 2004-03-21 04:48:12.000-0600 Thinking... What happens if we always allow sip forward, but take the domain part into SIPDOMAIN variable (like all incoming SIP invites) and then make app_dial forward the call to chan_local with the username as an extension, as is today. That's an easy fix. That would be inline with how asterisk handles SIP URI:s today, and you could set the dial plan to handle whether or not you care about the domain part. We also need to consider joining this patch with the forwardcontext patch 0000494 By: psm (psm) 2004-03-22 14:39:38.000-0600 I'm quite surprised about the comments up here. Possibility to transfer or forward to external domains is BASIC functionality of SIP. Deleting the domain name and searching the 302 or REFER within local dial-plan is as flawed as stripping domain name from e-mail address and serching local /etc/passwd for all internet users. Please consider that domain name in SIP equals to part of telephone number, and ENUM is the best example: +87810 39311 10000   is equivalent to   sip:10000@fwd.pulver.com Try guessing what happens if you dial 10000 instead of the whole e.164 number By: Olle Johansson (oej) 2004-03-22 14:48:15.000-0600 psm, I would fully agree with you if we were talking about a SIP proxy. Asterisk is not a SIP proxy, it's a multiprotocol PBX. The dial plan is there and we have to work with the existing architecture as a base. We can call and receive calls from external domains in Asterisk today. We need refer to work the same way as the rest of asterisk, not do clever things in the channel. By: psm (psm) 2004-03-23 03:31:35.000-0600 Well, yes, asterisk is not a SIP proxy, but it should be at least SIP compliant. Note that 561  (local extension) 561@foo.com 561@bar.net are 3 completely different things which can't be mixed up. Now assume you're making outgoing call from Asterisk to some SIP destination using your present dial-plan. The called user is not present and responds with 302 Moved Temporarily -> 561@bar.net Now Asterisk throws away the domain, and calls local extension 561 which might actually belong to your top-level boss. You will have to explain why you're calling him for the 10-th time during last 5 minutes :-) Now imagine, what happens if 302 points to 9911@foo.com - your call lands at emergency service. Or a malicious user can return 9011something@abc.com and your asterisk will strip the domain and make international call! This is nothing else than HUGE security hole and SERIOUS incompatibility issue with basic SIP protocol principles. Please note, that SIP URIs returned in 302 or REFERs have no knowledge of your local dial-plan and instead are fully-qualified URIs in the global Internet. Thus mathing them with local dial-plan is a serious flaw. By: Olle Johansson (oej) 2004-03-23 03:58:03.000-0600 psm: I fully agree with you - but we still have to follow Asterisk's design. The SIP channel can't break the rest of the code. That's the challenge. Please follow my work with the chan_sip2 channel and you'll see that I've been going this way for a long time. At this moment, I'm coding support for making asterisk aware of what domains it is hosting to be able to close some of the security holes you also see. Please assist me by testing that version of the channel. You can solve a lot of what you're writing today with the current dialplan and some trickery with variables that handles domains. Check the SIPDOMAIN variable. My Asterisk is fully aware of what domains it is serving and in what cases it should forward the call by DNS srv records. It's possible today. * Going back to this bug report and SIP redirects: The dial plan is the control center of everything. The administrator needs to be able to filter out how people redirect calls and who are allowed to do what. I may be redirecting all my sip calls to tel:+4670555555555 - an expensive mobile phone call to Sweden. You don't want your asterisk to automatically dial out on the PSTN and set up an international phone call everytime someone calls me. It has to be controlled by the dial plan. Period. By: psm (psm) 2004-03-23 06:40:31.000-0600 oej: Sure, I highly appreciate your efforts with chan_sip2, since knowing the local domain is a must in SIP. And yes, I fully agree that one should be extremely careful when the redirect number contains a tel: URI and perhaps reject such redirection by default. Anyway, the SIP channel must be RFC3261 compliant, otherwise you're going to create lots of user confusion and dissatisfaction I've described above. So if it sees a sip: URI with non-local domain, according to RFC it SHOULD try there and not play strange games with it - like stripping the domain. Please keep in mind, that EVERY SIP UA is doing this - not just proxies, but all HW/SW IP SIP Phones as well. Let's view it like this: domain stands for first N digits of the complete e164 number. You never strip e.g. first 4 digits of a number just because your SW design wants it. On the other hand, if it sees a tel: URI, it's supposed to match it against the local dial plan and perhaps reject it. * so to the bug report - if chan_sip strips the domain from sip: URI and tries to match only the user part against the local dial plan, it's RUDE violation of the RFC and unacceptable behaviour. The tel: URIs are other story. By: Olle Johansson (oej) 2004-03-23 07:06:59.000-0600 psm: You're preaching to the choir :-) The current SIP channel breaks the RFCs in several ways, and I'm trying to fix that in chan_sip2. Please assist. What I'm not going to do is to break the current Asterisk architecture, because such a solution will not be committed to CVS and it will cause other problems. Regarding this bug: No, I'm not trying to throw away the domain part, I'm trying to be compliant with how it works in Asterisk today with the SIPDOMAIN variable storing the DOMAIN part. That should work even in a 302. Then you're doing the proxy stuff within the dial plan, making it visible instead of hiding. Play around with SIPDOMAIN and you'll understand. By: Brian West (bkw918) 2004-04-18 02:05:47 OK to stir up a hornets nest and get a response.... here we go.. I have talked to mark and he said he likes it as Local/ (yes yes we know its not 100% sip compliant) Post back to reopen and we will go from there. bkw By: Olle Johansson (oej) 2004-04-18 02:48:45 Bzzzzz.... I tried to use a Local/ but couldn't transport the address over to the new channel. Need Mark's help. I'll check with him. By: Mark Spencer (markster) 2004-05-02 00:49:10 I don't like the idea that an end user can force us to call or lookup an arbitrary server.  I *like* the way asterisk interprets everything locally.  If it was to be possible to allow 302's to send you to another location: 1) You use SIP/ instead of Local/ -- may require some changes 2) It will have to be an option which defaults to off But even at that, I don't think I want it even as an option at this point. Maybe i"ll change my mind.  Anyway, 301 should otherwise be supported.