Summary:	ASTERISK-01068: [patch] Allow calls to/from unknown destinations (SRV) maintain callerid
Reporter:	ktsaou (ktsaou)	Labels:
Date Opened:	2004-02-20 20:45:49.000-0600	Date Closed:	2004-09-25 02:40:23
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.c.diff
Description:	The problem is that * does not forward/accept callerids when talking with other SIP agents and proxies. Actually, it forwards only phone numbers without domains and does not forward non-numeric SIP addresses at all. In all cases, it replaces the domain part with either its general section fromdomain option, its peer entry fromdomain option, or its bindaddr IP address. There is no way for different type=user entities to have different fromdomain, which limits significantly a multi-domain installation of asterisk and never delivers the fully qualified alphanumeric SIP address to local phones to allow them dial-back with a keypress or display the SIP address of the caller. This patch will allow chan_sip.c to: 1. use the domain part of a type=user callerid as a fromdomain entry. This means that type=user SIP entities can now have a callerid like: Costa Tsaousis <costa@tsaousis.gr> When this user is making a call, and the peer does not have a fromdomain already (or there is no defined peer), the domain part of the callerid (tsaousis.gr in this case) will become a fromdomain for the call. 2. Accept the domain part of incoming calls, only if there is no callerid option for the type=user entity in sip.conf, or there is no entity defined at all in sip.conf (anonymous incoming calls). Both have been tested using two asterisk installations while forwarding calls from one to the other using DNS SRV. The fact that localy defined (sip.conf) callerids overwrite the ones defined at the user agent has been verified. The fact that the destination of the call recieves the valid fully qualified SIP address has also been verified (using Cisco 7960 phones). This patch allows asterisk to be used for generic SIP usage on the internet, which is faulty today, without it.
Comments:	By: Olle Johansson (oej) 2004-02-26 15:27:11.000-0600 I think this open potential security bugs. As I've stated in several bug notes, we need a long-term solution to how Asterisk accepts and sends domains. I don't know yet how this have to be designed, but a shortterm patch will not help the situation longterm. Asterisk needs to be domain-aware. By: ktsaou (ktsaou) 2004-02-26 17:08:11.000-0600 So, in the meantime, you prefer to have just a useless number or just the word 'asterisk' sent rather than a meaningful SIP address? By: Olle Johansson (oej) 2004-02-26 17:16:51.000-0600 useless number? Asterisk sends the extension where someone can answer. Again, Asterisk is not a SIP proxy, it's a PBX. We can't have asterisk send out usernames that is not in the extensions.conf dial plan. By: ktsaou (ktsaou) 2004-02-26 17:55:39.000-0600 Come on guys. THE SIP ADDRESS IS IN EXTENSIONS.CONF. YOU CAN CALL IT, YOU CAN USE IT. IT IS THERE! Who says it is not? After all, * will not forward the SIP address the phone says it is. It will forward the SIP callerid the admin configured it to do so. This is what PBXes do. They set callerids based on their configuration. If on the other hand you afraid that someone on the internet can fake his identidy, the only thing * can do is not to accept an incomming call FROM the local domain if the caller is not registered. This will protect self and is already configurable by the administrators in extensions.conf and sip.conf. The only thing that can be done on top of that is a full log (not CDR) of all SIP calls with timestamps, IP addresses and callerids of the involved parties. This will offer traceability. If there is traceability, the lawyers already have the laws to resolve such situations. What are you trying to accomplish exactly? By: ktsaou (ktsaou) 2004-02-26 18:51:53.000-0600 This patch is about SRV and registration based SIP calls across domains. The current operation of local users is not altered. The numeric callerid of the internal dialplan is useless for SIP calls across domains (SRV or registered), pretty much the same way my internal extension is useless for you when you want to call me and you don't know my public phone number. For SIP, the public phone number is the domain while the internal extension is the username. Without the patch, you cannot call me back from outside the local * since you are missing the domain I arrived from. I know there is a global fromdomain= option, but this is very limited. We need to have this option per user (there is one for each peer already). So, this patch is really harmless: it allows the administrator to set per user fromuser= and fromdomain=, just like * ALREADY (without the patch) does for peers and with the global fromdomain= does for all users together. If the administrator does not want to, this patch does not enforce him to set domains in callerids. In the switched telephony world, callerid consistency is guaranteed by the telco you are using. The telco owns the numbers, delegates them to you and also restricts you from faking your identity. Then, all the telcos (or some of them) have a trust relationship and therefore they trust each other for exchanging accurate callerid information. On the internet however, there is no third trusty party. There is no telco or PTT. The only thing you can do is to trust something that is already accurate. This might be for example DNS. Such a scenario should require from the called SIP party to do a DNS SRV lookup for the domain of the calling SIP party or just a reverse lookup of the IP address of the calling party and match IP addresses. I think however that such things are outside the scope of * or any other SIP implementation. They should be decided and documented at an RFC level. Anyway, I don't really understand your objections about this patch. If in the [general] section of sip.conf I set: callerid=costa fromdomain=tsaousis.gr Asterisk will transmit costa@tsaousis.gr as the callerid of all outgoing SIP calls. What is the problem for having this on a per user basis? By: Mark Spencer (markster) 2004-02-27 11:25:19.000-0600 Since this isn't really a bug in Asterisk, but a feature request, I'm redesignating it as a feature request.  It definitely won't make it in 1.0, but we might see about working through the details for post 1.0 eventually. The existing Asterisk logic is that anytime you receive a call, you're receiving the call *from* the Asterisk server and *not* from the endpoint that originated the call.  The Caller*ID for registered friends will be correct, and returning the call to Asterisk should get you back with the original caller *through* Asterisk, thus providing voicemail etc. If we were to populate the outgoing domain with that of the incoming domain, then calling the person back would go directly to their phone -- no features (e.g. voicemail) would be supplied. By: ktsaou (ktsaou) 2004-03-04 21:14:18.000-0600 Mark, if the domain SRV record does not point to asterisk, you can always set the domain part of the callerid to the hostname of the asterisk box. I think however that this would be very rare. Normally, If someone needs this feature he will have his domain SRV record pointing to the asterisk box. If not then it is his problem to configure his SIP proxy (that handles the domain) as needed for providing accurate dialplan and voicemail. I don't think asterisk is required to do something for preventing this. By: ktsaou (ktsaou) 2004-03-05 15:56:20.000-0600 Also, if asterisk hosts multiple indepedent companies with different dial plans each and overlapping extensions, then sending the asterisk IP/hostname as the domain of an SRV based SIP call will make the return path usless, since the callerid sent will not identify the domain the call was originated from (extensions across domains might overlap, so only the domain can select the company hosted on the same box). By: Olle Johansson (oej) 2004-03-05 16:16:05.000-0600 I agree that we need to support SIP domains properly. But not with short time patches, we need a redesign here. And, as Mark said, propably not for 1.0 release. I'll continue working on it in chan_sip2 with inspiration from your patches. By: twisted (twisted) 2004-04-29 08:38:51 Is this now included in chan_sip2 as an option?  If so, we can close this out. By: Mark Spencer (markster) 2004-05-02 22:01:39 I agree that we need something that lets us somehow map the fromdomain into a context.  Not sure what the right way for that is. By: twisted (twisted) 2004-06-16 23:28:34 Can we revisit this as SRV is enabled by default now? By: Mark Spencer (markster) 2004-06-24 00:25:06 Lets just role this into chan_sip2 for further discussion.