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

Fri May 2 20:19:47 CEST 2014

On 02/05/14 19:39, Alex Villacís Lasso wrote:
> El 02/05/14 10:40, Alex Villacís Lasso escribió:
>> El 24/04/14 19:09, Alex Villacís Lasso escribió:
>>> I am currently preparing a kamailio-asterisk combination. The 
>>> asterisk installation uses realtime for SIP. The kamailio 
>>> configuration (attached) 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, and 
>>> the SIP phones are configured to use 'name' as authentication 
>>> username for domain '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 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.
>>>
>>> A typical INVITE for this scenario looks like this, before being 
>>> processed by kamailio:
>>>
>>> INVITE sip:6008010 at 172.28.161.218:5060;transport=udp;user=phone SIP/2.0
>>> Via: SIP/2.0/UDP 
>>> 200.25.144.58:5060;branch=z9hG4bK+676ea13f680e853fd847230512a347561+32e3da76+1
>>> Call-ID: FBE75B3A at 32e3da76
>>> From: 
>>> <sip:042294440 at 200.25.144.58:5060;user=phone>;tag=32e3da76+1+544c000c+52be771c
>>> To: <sip:6008010 at 172.28.161.218:5060;user=phone>
>>> CSeq: 975469826 INVITE
>>> Expires: 180
>>> Organization: SetelGYE
>>> Min-SE: 90
>>> Session-Expires: 18000
>>> Supported: replaces, 100rel, timer
>>> Contact: <sip:042294440 at 200.25.144.58:5060;transport=udp;user=phone>
>>> Content-Length: 149
>>> Content-Type: application/sdp
>>> Max-Forwards: 70
>>> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, NOTIFY, PRACK, UPDATE, 
>>> INFO, REFER
>>>
>>> v=0
>>> o=- 0 0 IN IP4 201.217.79.3
>>> s=-
>>> c=IN IP4 201.217.79.3
>>> t=0 0
>>> m=audio 5388 RTP/AVP 8 101
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-15
>>>
>>> Here, 6008010 is the phone number that was dialed at the provider in 
>>> order to reach my system, and 042294440 is the provider-supplied 
>>> Caller-ID, which I want to preserve all the way to Asterisk. In 
>>> particular, 042294440 appears as the value that ends up as $fU 
>>> (From: username) while being processed in kamailio. If I pass the 
>>> SIP packet as-is to asterisk, asterisk first tries to match by the 
>>> value of $fU, which obviously fails to match the trunk name. It then 
>>> tries to match by incoming IP, which also fails because asterisk 
>>> received this packet from 127.0.0.1 . Finally, asterisk sort of 
>>> matches to the first record in the sip table, which is *not* the SIP 
>>> account for this trunk, but some other random account.
>>>
>>> I have a partial solution that uses sqlops to make a query to the 
>>> sip table, using the $si (source IP) and reads the trunk name in 
>>> order to replace $fU. This works, as now $fU will have the trunk 
>>> name and asterisk will now recognize the intended SIP account for 
>>> the trunk. However, this has the unfortunate side effect of throwing 
>>> out the Caller-ID information.
>>>
>>> What is the standard/proper way to deal with this situation? Is 
>>> there a well-known way to make Asterisk match the trunk name, 
>>> without overwriting the Caller-ID information? Before you ask, 
>>> requesting the provider to modify its INVITEs is not an option. I 
>>> believe there is a standard way to deal with this, since this 
>>> scenario should also arise with a kamailio that faces the internet, 
>>> and relays INVITEs (after authentication) to an asterisk in a local 
>>> network. As far as I can tell, the fact that in my case the 'local 
>>> network' is localhost should be irrelevant.
>> 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.
> SOLVED: asterisk needs to be configured with trustrpid=yes in the 
> affected trunk for the P-Asserted-Identity header to take effect.
Thanks for replying to close the thread and tell the solution you found, 
it is really important for others searching on archive later on a 
similar issue.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda