[SR-Users] question about kamailio handling of forwarded invite

Ding Ma mading087 at gmail.com
Tue Jan 26 02:44:32 CET 2016


Yes, you’re absolutely right.

It turned out that the Asterisk has this uncommon way of handling ACL.
Asterisk assumes “permit”, then runs down the ACL, and changes the status to either “deny” or “permit” based on each matching trunk entry, but the last matching entry of ACL determines the final state.
This seems opposite to linux iptables way, which usually starts with "deny all”, apply each rule, and stops at the first “permit” rule that matches the packet.
We just need to change the deny/permit around according to the Asterisk way. 

Thanks,

> On Jan 25, 2016, at 2:28 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> parameters in the Via header have nothing to do with authentication. It seems that the key log messages are in Asterisk:
> 
> [Jan 21 23:13:20] NOTICE[20785][C-00000001] acl.c: SIP Peer ACL: Rejecting '10.0.1.30' due to a failure to pass ACL '(BASELINE)'
> [Jan 21 23:13:20] NOTICE[20785][C-00000001] chan_sip.c: Failed to authenticate device <sip:95678 at 10.0.1.35 <mailto:sip%3A95678 at 10.0.1.35>>;tag=as4028dabf
> 
> Is the 10.0.1.30 in the IP ACL white list for Asterisk?
> 
> Cheers,
> Daniel
> 
> On 22/01/16 16:15, DING MA wrote:
>> Hi, all
>> 
>> We're trying to build a system that consists of pbx, kamailio and asterisk in the following configuration.
>> 
>> pbx (sip trunk) --- kamailio --- asterisk
>> 
>> The kamailio and asterisk are integrated with same database. The outgoing calls to pbx works. But there is a problem with incoming calls from pbx.
>> If we make a consecutive calls from the same pbx user to the same user registered with kamailio. The first would go through, but the second call would be rejected by asterisk. We have insecure=invite set on the trunk/peer, so asterisk is not supposed to auth the invite from kamailio. But the pbx user (from in this case) is not in the database.
>> 
>> The asterisk log says:
>> 
>> [Jan 21 23:13:19] VERBOSE[20785] chan_sip.c: --- (16 headers 13 lines) ---
>> [Jan 21 23:13:19] VERBOSE[20785] chan_sip.c: Sending to 10.0.1.30:5061 <http://10.0.1.30:5061/> (no NAT)
>> [Jan 21 23:13:19] VERBOSE[20785][C-00000001] chan_sip.c: Sending to 10.0.1.30:5061 <http://10.0.1.30:5061/> (no NAT)
>> [Jan 21 23:13:19] VERBOSE[20785][C-00000001] chan_sip.c: Using INVITE request as basis request -  <http://4aaa2dce75c60e8546994c3501dae9e7@10.0.1.35:5061/>4aaa2dce75c60e8546994c3501dae9e7 at 10.0.1.35:5061 <mailto:4aaa2dce75c60e8546994c3501dae9e7 at 10.0.1.35:5061>
>> [Jan 21 23:13:20] NOTICE[20785][C-00000001] acl.c: SIP Peer ACL: Rejecting '10.0.1.30' due to a failure to pass ACL '(BASELINE)'
>> [Jan 21 23:13:20] NOTICE[20785][C-00000001] chan_sip.c: Failed to authenticate device <sip:95678 at 10.0.1.35 <mailto:sip%3A95678 at 10.0.1.35>>;tag=as4028dabf
>> [Jan 21 23:13:20] VERBOSE[20785][C-00000001] chan_sip.c:
>> <--- Reliably Transmitting (no NAT) to 10.0.1.30:5061 <http://10.0.1.30:5061/> --->
>> SIP/2.0 403 Forbidden^M
>> Via: SIP/2.0/TLS 10.0.1.30:5061;branch=z9hG4bK9c8e.5cd2c05f6a572312c7793abf5fe1183c.0;i=2;received=10.0.1.30^M
>> Via: SIP/2.0/TLS 10.0.1.35:5061;received=10.0.1.35;branch=z9hG4bK249855c1;rport=59929^M
>> From: <sip:95678 at 10.0.1.35 <mailto:sip%3A95678 at 10.0.1.35>>;tag=as4028dabf^M
>> To: <sip:16317 at 10.0.1.30 <mailto:sip%3A16317 at 10.0.1.30>>;tag=as35f47241^M
>> Call-ID: 4aaa2dce75c60e8546994c3501dae9e7 at 10.0.1.35:5061 <http://4aaa2dce75c60e8546994c3501dae9e7@10.0.1.35:5061/>^M
>> CSeq: 102 INVITE^M
>> Server: Asterisk PBX 13.6.0^M
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE^M
>> Supported: replaces, timer^M
>> Content-Length: 0^M
>> 
>> Comparing the two invites from kamailio to asterisk, it seems the only difference is that the second invite has an "i=2" in the Via header while the first one has "i=1". Not sure what the "i=1" is for. Would appreciate some insights on how kamailio is adding/handling the "i=#" in Via header.
>> 
>> Thanks.
>> 
>> Ding Ma
>> SPG, Motorola Solutions
>> 
>> 
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
> 
> -- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#!/miconda> - http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Book: SIP Routing With Kamailio - http://www.asipto.com <http://www.asipto.com/>
> http://miconda.eu <http://miconda.eu/>_______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160125/4c3aed77/attachment.html>


More information about the sr-users mailing list