Summary:	ASTERISK-13357: [patch] Calls are not accepted from an outbound proxy
Reporter:	nick_lewis (nick_lewis)	Labels:
Date Opened:	2009-01-13 10:19:58.000-0600	Date Closed:	2009-01-15 07:58:29.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.c-findproxy.patch
Description:	find_peer does not make a match between a received invite and a peer if the invite comes from the outboundproxy rather than directly from the host. For example if a peer has the following sip.conf: [mytrunk] host=sip.myitsp.net port=5060 outboundproxy=nat.myitsp.net:5082 an invite from nat.myitsp.net:5082 is not matched to peer mytrunk This is a problem for applications in which a natproxy is used for both incoming and outgoing calls.
Comments:	By: nick_lewis (nick_lewis) 2009-01-13 10:27:45.000-0600 I think it would be possible to put the outboundproxy details into the peers_by_ip table instead of the host:port details but this would not then permit direct invites from the host. Perhaps both could be put in the peers_by_ip table? By: nick_lewis (nick_lewis) 2009-01-13 11:01:54.000-0600 On investigation I do not think obproxies can be added to peers_by_ip table. It will require an additional table peers_by_obproxy with a different key generator peer_obproxyhash_cb. The function find_peer can then search the latter if there is no match on the former. By: Leif Madsen (lmadsen) 2009-01-13 12:40:43.000-0600 Assigning to putnopvut for review to determine if this is functionality we would add to Asterisk, as I'm not entirely familiar with the outboundproxy stuff. By: Leif Madsen (lmadsen) 2009-01-13 12:41:10.000-0600 This is just a ping to oej incase he wanted to comment on this issue. By: Olle Johansson (oej) 2009-01-13 12:45:21.000-0600 The outbound proxy, like any other proxys, has to be a peer by itself in sip.conf. However, if you declare users we will match users first and ignore the proxy. The users match on the From: username - not the IP and port address. That is the way it works now. That's one of the reasons why we do have realtime users (not peers). In the future, we will redesign this for domain based matching, but it's not easily possible now. And that kind of matching would be a feature request you can file on http://www.asteriskideas.org. This is not a bug report and should be closed. By: Mark Michelson (mmichelson) 2009-01-13 15:23:14.000-0600 Since oej has provided a couple of workarounds and suggested a site for requesting new functionality, I will go ahead and close this. By: nick_lewis (nick_lewis) 2009-01-14 10:29:44.000-0600 There are some limitations in the alternatives suggested Adding an extra peer for the nat proxy used by each trunk requires that there be two entries for each trunk. The incoming and outgoing parts of the trunk would have to have different names which makes dialplans complex. To declare users instead of peers removes all security. Peers seem much more secure and in the absence of any outboundproxy setting work well bidirectionally. The loss of bidirectional operation when an outboundproxy config parameter is added seems more a bug than a missing feature By: nick_lewis (nick_lewis) 2009-01-14 10:34:51.000-0600 Anyway I have added a patch that allows IP matching on the proxy as well as the host. Someone may wish to use it even if it does not get into the trunk By: Olle Johansson (oej) 2009-01-14 12:15:28.000-0600 Why do you think that users are less secure than peers? By: nick_lewis (nick_lewis) 2009-01-15 03:28:55.000-0600 Users are authenticated by the From: header which is easy for anyone anywhere to forge in a call. Peers are authenticated by the actual IP source of the call. This ensures that the call is really coming from your ITSP. For bog standard voip lines it needs to be as simple to setup an asterisk PBX as it is a sip phone. In most cases the following sip.conf does the job to provide a two way voip line: register=myaccount@sip.myitsp.com/line1 [line1] type=peer username=myaccount host=sip.myitsp.com Some ITSP use a separate unit to provide nat traversal. These ITSP state that the address of this unit should be added to the client config as the outbound proxy for this voip line. For all sip phones this works fine. The equivalent on asterisk is: register=myaccount@sip.myitsp.com@nat.myitsp.net/line1 [line1] type=peer username=myaccount host=sip.myitsp.com outboundproxy=nat.myitsp.net Hence why I regard there to be a bug on asterisk. The consumer will also feel there is a bug when he tries to upgrade the sip phone on his voip line to an asterisk pbx and finds that it sometimes fails because of the different behaviour of asterisk to all other UAC devices that are connected to ITSP voip services. For example a two line sip phone may have one voip line from an ITSP that has integrated nat traversal and another that uses a separate unit for nat traversal. The consumer should be able to upgrade from a sip phone to asterisk configured thus: register=myitsp1account@sip.myitsp1.com/line1 register=myitsp2account@sip.myitsp2.com@nat.myitsp2.net/line2 [line1] type=peer username=myitsp1account host=sip.myitsp1.com [line2] type=peer username=myitsp2account host=sip.myitsp2.com outboundproxy=nat.myitsp2.net By: Olle Johansson (oej) 2009-01-15 04:06:43.000-0600 Assuming that the IP address is reliable is a bad assumption. Use authentication if you want any form of authentication. By: Olle Johansson (oej) 2009-01-15 04:09:43.000-0600 And why can't you add a peer for the outboundproxy to take incoming calls and then separate on the To: header. I know it's clumsy, but I don't agree with this way of doing it. The real fix would be do recognize the incoming calls based on the domain you register with and where the calls are coming from. The outbound proxy might resolve by SRV or multilple A records to multiple IP hosts, so your patch won't solve the problem at all for all cases. By: nick_lewis (nick_lewis) 2009-01-15 05:21:17.000-0600 Regarding authentication - ITSP voip lines do not provide this facility. They expect the UAC to authenticate when registering with them or making outgoing calls to them but they cannot handle any authentication challenge when delivering incoming calls. The best that can be done with ITSP voip lines is checking that the call came from the same IP address that was authenticated during registration. Regarding an incoming peer for each outgoing peer's outboundproxy - What is meant by separate on the To: header? It seems to me that this would require an entry in sip.conf something like: register=myaccount@sip.myitsp.com@nat.myitsp.net/line1 [line1] type=peer host=nat.myitsp.net [line1_out] type=peer username=myaccount host=sip.myitsp.com outboundproxy=nat.myitsp.net which is clumsy and there would also need to be extra dialplan stuff to associate line1 and line1_out. I dont think this complexity of config is something that a typical ITSP sip phone user would tolerate. It was a great step forwards when peers became bidirectional and this benefit needs to be maintained. Regarding DNS resolution - if I have understood your proposal correctly then it suffers the same potential problem. When the peer->host for incoming calls resolves nat.myitsp.net it could theoretically be a different IP from when reg->host resolves nat.myitsp.net. This is no different from the bidirectional peer case when peer->outboundproxy resolves nat.myitsp.net. In practice though this seems not to be a problem because ITSPs somehow get whole load-balanced natproxy clusters to project a single IP address By: Olle Johansson (oej) 2009-01-15 06:43:06.000-0600 You separate in the dialplan by reading the To header with the function that exists for reading SIP headers. The SIP domain is always the same, regardless of which of the proxy in the cluster that sends you a message. Hostnames is a totally different thing. By: nick_lewis (nick_lewis) 2009-01-15 07:11:16.000-0600 What needs to be separated in the dialplan? I assume we are talking here about incoming calls only. In the example there is only one voip line from each ITSP and therefore only one voip line with a particular natproxy. Does the need for separation in the dialplan apply only to when there are multiple voip lines sharing the same ITSP and therefore sharing the same natproxy? By: Olle Johansson (oej) 2009-01-15 07:18:58.000-0600 Nick - this is a bug tracker and not a support forum. Ask on the asterisk-users mailing list and you will be pointed to a lot of examples on the net. Since you're getting calls from the same IP, the only way to sort them out on account-level is by reading the To: header form the ITSP in the dialplan. By: nick_lewis (nick_lewis) 2009-01-15 07:44:32.000-0600 This issue is not to do with account-level separation but to do with getting an IP match so as to accept any call from an ITSP that is using a natproxy. I was querying your "separated in dialplan" comment because I was not sure that I understood the relevance to this issue. Now I am satisfied that the comment is not relevant to this issue. Ok I have offered the natproxy patch - it is on record for anyone interested - I have not been persuasive as to its benefits so I guess the issue is closed By: Olle Johansson (oej) 2009-01-15 07:58:17.000-0600 Thanks for wanting to contribute! Next time, we might agree better :-) Feel free to find me on IRC or mail to discuss at any time. There are significant problems with the peer/user/friend structure and I have made several proposals to solve them and worked toward reaching that goal. To remove the user data structure and then the object from trunk is a big step forward.