<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">El 25/04/14 18:29, Alex Villacís Lasso
escribió:<br>
</div>
<blockquote cite="mid:535AEFE8.8080200@palosanto.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 14px;" lang="x-western">I am currently preparing a
kamailio-asterisk combination. The asterisk installation uses
realtime for SIP. The kamailio configuration was based on the
reference at <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb">http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb</a>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
A typical INVITE for this scenario looks like this, before being
processed by kamailio: <br>
<br>
INVITE <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:sip:6008010@172.28.161.218:5060;transport=udp;user=phone">sip:6008010@172.28.161.218:5060;transport=udp;user=phone</a>
SIP/2.0 <br>
Via: SIP/2.0/UDP
200.25.144.58:5060;branch=z9hG4bK+676ea13f680e853fd847230512a347561+32e3da76+1<br>
Call-ID: FBE75B3A@32e3da76 <br>
From: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:sip:042294440@200.25.144.58:5060;user=phone"><sip:042294440@200.25.144.58:5060;user=phone></a>;tag=32e3da76+1+544c000c+52be771c
<br>
To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:sip:6008010@172.28.161.218:5060;user=phone"><sip:6008010@172.28.161.218:5060;user=phone></a>
<br>
CSeq: 975469826 INVITE <br>
Expires: 180 <br>
Organization: SetelGYE <br>
Min-SE: 90 <br>
Session-Expires: 18000 <br>
Supported: replaces, 100rel, timer <br>
Contact: <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:sip:042294440@200.25.144.58:5060;transport=udp;user=phone"><sip:042294440@200.25.144.58:5060;transport=udp;user=phone></a>
<br>
Content-Length: 149 <br>
Content-Type: application/sdp <br>
Max-Forwards: 70 <br>
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, NOTIFY, PRACK, UPDATE,
INFO, REFER <br>
<br>
v=0 <br>
o=- 0 0 IN IP4 201.217.79.3 <br>
s=- <br>
c=IN IP4 201.217.79.3 <br>
t=0 0 <br>
m=audio 5388 RTP/AVP 8 101 <br>
a=rtpmap:101 telephone-event/8000 <br>
a=fmtp:101 0-15 <br>
<br>
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 <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>not<span class="moz-txt-tag">*</span></b>
the SIP account for this trunk, but some other random account. <br>
<br>
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. <br>
<br>
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. <br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
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?<br>
</body>
</html>