> 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. > > Dmitriy Serov wrote: > 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@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).
The line support doesn't work like that. It adds a URI parameter with a randomly generated value, unique for each outbound registration. This is a common approach that SIP clients use when they are registering to multiple SIP servers and need to determine which server has sent it an INVITE. The user portion remains untouched. - Joshua ----------------------------------------------------------- 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:us...@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:us...@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 ad...@sip.example.com calling to us...@sip.example.com. > External sip server redirect call to my server with packet: > INVITE sip:trunk2-in@8.8.8.8:5060 SIP/2.0 > From: "PhonerLite" > <sip:ad...@sip.example.com>;tag=5F39A540-782390-DE41886A_kmbdctn-8A47 > To: <sip:us...@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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
