asterisk users - Apr 2014 - Proper way to make Asterisk recognize SIP trunk of incoming INVITE when IP is not available

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,
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 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140425/094ca09e/attachment.html>

El 25/04/14 18:29, Alex Villac??s Lasso escribi?:
> 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, 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 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.
>
> 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.
>
>
If I manage to coax Kamailio to add a (synthetized) P-Asserted-Identity header
to the INVITE request before sending it to Asterisk, will Asterisk be able to
use it? Will this information show up on a CDR?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140425/be57555e/attachment.html>

And related thereto:

What needs to be done on kama and ast to ensure that all incoming calls
which route through a given kama box always matches a sip.conf [section]
based on the socket(7)'s remote address, w/o any consideration of the
INVITE's sip headers or body?

I tried a several variations, but nothing quite worked.

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

On 26 April 2014 00:29, Alex Villac??s Lasso <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-astdbbut
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 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 it will match
this peer, whereas the rest, coming from 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);
        } 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 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().

Hope this helps.

-Barry Flanagan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140427/a6f38c18/attachment.html>