[asterisk-users] SOLVED: Re: Proper way to make Asterisk recognize SIP trunk of incoming INVITE when IP is not available

Fri May 2 12:40:14 CDT 2014

El 02/05/14 11:41, Alex Villacís Lasso escribió:
> El 02/05/14 10:49, Alex Villacís Lasso escribió:
>> El 27/04/14 07:47, Barry Flanagan escribió:
>>> On 26 April 2014 00:29, Alex Villacís Lasso <a_villacis at palosanto.com <mailto:a_villacis at palosanto.com>> wrote:
>>>
>>>     I am currently preparing a kamailio-asterisk combination. The asterisk installation uses realtime for SIP. The kamailio configuration was based on the reference at http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb but has
>>>     been heavily modified. Currently asterisk runs on localhost and only listens on SIP/RTP at 127.0.0.1 . Therefore, all of the SIP traffic appears to come from localhost, from the point of view of asterisk.
>>>
>>>     Currently I have a model on which internal SIP phones get identified by the authentication username, and then the contact names at From: and To: get massaged to incorporate the SIP domain, in order to emulate multiple-domain support. The 'sip'
>>>     table in Asterisk defines all such contacts as SIP accounts of the form name_domain.com <http://name_domain.com>, and the SIP phones are configured to use 'name' as authentication username for domain 'domain.com <http://domain.com>'. However, SIP
>>>     providers that register on the server with authentication names are left with their original names, since in the model, SIP trunks are available to all domains.
>>>
>>>     Now I have to add support for SIP providers which are to be authorized on the basis of IP only. Apparently, the kamailio module permissions.so (WITH_IPAUTH) is made for just this purpose, so I enabled it. After authentication, I need to route the
>>>     INVITE to asterisk, and asterisk must somehow match the account for the SIP trunk from the available information on the INVITE request.
>>>
>>>
>>>
>>> What I have done in a similar situation is to use  force_send_socket in Kamailio when sending INVITEs from your trusted host (your trunks) so that it is coming in to Asterisk from a different port (say 5070), and then in your Asterisk sip.conf settings 
>>> create a new peer for this like so:
>>>
>>> [peer-incoming]
>>> context=peercontext
>>> type=peer
>>> host=127.0.0.1
>>> port=5070
>>>
>>> Now, when Asterisk receives an INVITE from 127.0.0.1:5070 <http://127.0.0.1:5070> it will match this peer, whereas the rest, coming from 127.0.0.1:5060 <http://127.0.0.1:5060>, will match your other subscribers.
>>>
>>> Here is a bit of the Kamailio config:
>>>
>>> if (is_method("INVITE"))
>>>     {
>>>         # If call is coming from a trusted source (Trunk/PSTN) then we send it to Asterisk from port 5070
>>>         # so that Asterisk knows this is not coming from a subscriber. The peer in Asterisk needs to be set with port=5070
>>>         # as well as the host=<ip address>
>>>         if (allow_trusted())
>>>         {
>>>             xlog("L_INFO","Inbound to Asterisk from Trusted Source IP $si, Caller: $fU, Callee: $rU with Call-ID $hdr(Call-ID)");
>>>             force_send_socket(127.0.0.1:5070 <http://127.0.0.1:5070>);
>>>         } else {
>>>             # This is a call from a registered subscriber.
>>>             xlog("L_INFO","Inbound to Asterisk from $fU to $rU with Call-ID $hdr(Call-ID)");
>>>         }
>>>     }
>>>     route(RELAY);
>>>     exit;
>>> }
>>>
>>> NOTE: Kamailio must be set to listen on 127.0.0.1:5070 <http://127.0.0.1:5070> as well as your usual ports for this to work! Also, your SIP Trunk trusted peers need to be in the Kamailio trusted table, or explicitly test for the src_ip rather than use 
>>> allow_trusted().
>>>
>> I would rather have a solution that does not involve allocating a new UDP port every time a new IP-trusted SIP trunk is configured.
>>
>> I tried appending a P-Asserted Identity header to the incoming INVITE before routing it to asterisk, like this:
>>
>> #!ifdef WITH_IPAUTH
>>     if((!is_method("REGISTER")) && allow_source_address() && $au == "")
>>     {
>>         # Attempt to create a P-Asserted-Identity if none exists, to preserve
>>         # incoming Caller-ID
>>         if (!is_present_hf("P-Asserted-Identity"))
>>         {
>>             append_hf("P-Asserted-Identity: <sip:$fU@$fd>\r\n");
>>         }
>>
>>         # Loading $fU from database using IP
>>         sql_pvquery("elxpbx", "SELECT name FROM sip WHERE host = '$si' AND sippasswd IS NULL", "$fU");
>>
>>         # source IP allowed
>>         return;
>>     }
>> #!endif
>>
>> With tcpdump, I can see that the header is indeed appended to the SIP headers of the INVITE, but there is no effect in Asterisk. From examination of the Asterisk 11.8.1 source code, I see that channels/chan_sip.c contains a get_pai() function that is 
>> supposed to process P-Asserted-Identity and extract a caller ID. I am still studying the code, but I would appreciate help on this issue, to see why my attempt is not working.
>>
>>
> By placing debugging statements, I think get_pai() is not being called when receiving an incoming INVITE, corresponding to an incoming call from the IP-authenticated trunk being handled by an IVR, but not yet routed to an internal extension. Why is this 
> so? Is this by design?
>
>
SOLVED: asterisk needs to be configured with trustrpid=yes in the affected trunk for the P-Asserted-Identity header to take effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140502/40bba4f7/attachment.html>