[asterisk-dev] [Code Review] 4476: new res_pjsip module to identify endpoint for an incoming call with a trunk that has outbound registration.

[Dmitriy Serov]

> On March 24, 2015, 3:39 p.m., Mark Michelson wrote:
> > I'm not a big fan of this module for a couple of reasons:
> > 
> > 1) The data in the request URI is intended to describe who the call is destined to be sent to, not who the call originated from. There are systems out there where the endpoint names in pjsip.conf match extensions in the dialplan, making it easy to route incoming calls to their destination. Therefore it may be possible for endpoint 100 to dial "200" to call endpoint 200, and have Asterisk think the incoming call is both from 200 and to 200. This can be mitigated through the use of endpoint identifier priorities, but this is not something the average user is expected to have to mess with in their setup.
> > 
> > 2) Josh Colp actually already wrote an alternate means of dealing with this situation, and it's already in Asterisk trunk. See this review: https://reviewboard.asterisk.org/r/2964/ In trunk, you can specify "line = yes" in an outbound registration configuration. With this, each outbound registration from Asterisk carries a "line" parameter in the Contact header. This way, when the provider places a call into Asterisk, the To URI will have that line parameter, and we can use that as a way to match the correct endpoint.
> > 
> > So, my thought on this is that the problem you are trying to solve needs to be solved. Since we already have something that solves this issue, but only in trunk, the best way to handle this is to backport the "line = yes" feature from trunk into Asterisk 13.

I did not know about the existence of such a patch. But still it implements slightly different. It allows you to write "to" field in the incoming packet, and long-existing method using option allows you to contact_user set Request line URI Username, while maintaining an independent value field "to" (as in the example).
Using option "line" is more consistent with the behavior of the endpoint, not the trunk. Multiple endpoint may have the same value of option "line" and identification of incoming packets will be difficult.

And last reason: bad people will be much easier to fake an incoming call from the server. Explain: in my example, any user on the server sip.example.com may call sip:line at 8.8.8.8:5060 and, according to your logic, the call is marked as incoming call through my trunk, because it is written option "line".
To fake username in request line when the call is not from your server much more difficult, if not impossible.

I'm also not a fan of my proposed solutions. But this behavior was in chan_sip and other better I don't know yet. For greater security, I give out long random names for endpoints (change them periodically).


- Dmitriy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4476/#review14793
-----------------------------------------------------------


On March 24, 2015, 12:23 p.m., Dmitriy Serov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4476/
> -----------------------------------------------------------
> 
> (Updated March 24, 2015, 12:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and rnewton.
> 
> 
> Bugs: ASTERISK-24852
>     https://issues.asterisk.org/jira/browse/ASTERISK-24852
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The main task: to find the right endpoint for an incoming call with a trunk that has outbound registration.
> 
> Simple example (a piece of pjsip.conf):
> [trunk1]
> type=registration
> transport=udp-transport
> outbound_auth=trunk1
> server_uri=sip:sip.example.com
> client_uri=sip:user1 at sip.example.com
> contact_user=trunk1-in
> 
> [trunk2]
> type=registration
> transport=udp-transport
> outbound_auth=trunk2
> server_uri=sip:sip.example.com
> client_uri=sip:user2 at sip.example.com
> contact_user=trunk2-in
> 
> [trunk1-in]
> type=endpoint
> context=from-trunk
> disallow=all
> allow=ulaw
> outbound_auth=trunk1
> aors=trunk1
> 
> [trunk2-in]
> type=endpoint
> context=from-trunk
> disallow=all
> allow=ulaw
> outbound_auth=trunk2
> aors=trunk2
> 
> trunk1, trunk2 - outbound registrations to EXTERNAL sip server sip.example.com. One server and two registrations.
> ; "contact_user=" sets the SIP contact header's user portion of the SIP URI this will affect the extension reached in dialplan when the far end calls you at this registration.
> In example option has values "trunk1-in" and "trink2-in".
> 
> Case: random user admin at sip.example.com calling to user2 at sip.example.com.
> External sip server redirect call to my server with packet:
> INVITE sip:trunk2-in at 8.8.8.8:5060 SIP/2.0
> From: "PhonerLite" <sip:admin at sip.example.com>;tag=5F39A540-782390-DE41886A_kmbdctn-8A47
> To: <sip:user2 at sip.example.com>
> 
> This invite can be:
> - anonymous. Very bad.
> - identified by IP. Config has two endpoints with same IP.
> - identified by username From. It cannot identify by "admin" (random)
> 
> res_pjsip_endpoint_identifier_request_user helps to identify this invite by uri username in request line (contact_user in registration).
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_pjsip_endpoint_identifier_request_user.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4476/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dmitriy Serov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150325/757469b4/attachment.html>