Hello,
First, i have 7 years experience with Asterisk, but I started a project
with Kamailio, forgive me in advance if I say silly things...! ;-)
I set up a classic Asterisk / Kamailio configuration:
sip phones -> kamailio -> asterisk -> sip trunks/pstn.
When a call comes from the PSTN side, if I configure Asterisk as follows:
[012345678]
type = friend
username = 012345678
secret = xxxxxxx
host = dynamic
fromdomain = sip.mydomain.com
fromuser = 012345678
Standard mode:
exten => 012345678, 1, Dial(SIP/012345678) -> The call is redirected on the
phone by Kamailio ! :-)
------------------------------------------------------------------------------------------------------------------------------------------------
Trunk mode:
[mytrunk]
type = friend
username = mytrunkUser
secret = xxxxxxx
host = dynamic
fromdomain = sip.mydomain.com
fromuser = mytrunkUser
exten => 012345678, 1, Dial(SIP/mytrunk/012345678) -> The call is rejected
by Kamailio....
exten => 012345679, 1, Dial(SIP/mytrunk/012345679) -> The call is rejected
by Kamailio ....
My question is how to allow the routing of multiple numbers (trunk mode) in
a SIP account with Kamailio?
Best regards,
Mickael
Hello everyone,
My name is Bruno, I'm a student from Portugal studying IMS at the moment. I've been following tutorials online, trying to get Kamailio to work as an IMS core - I'm pretty much a newbie in this field.
Unfortunantly I've been getting several errors and I can't seem to properly configure everything. I was wondering if there is a All-in-One VM that can be downloaded, with Kamailio ready to be used as an IMS core?
Thanks in advance. Best regards,
Bruno C.
Good day,
I’m experiencing some problems with our VoiP providers handling of REGISTER requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 with SIP-Alg enabled. This setup kind of works with UDP but our provider wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done some wire tracing and to me it seems that the providers configuration is to blame, but then - there are many RFCs out there and many NAT and UAC bug workarounds. Anyway, I wanted to get the opinion of “the" experts about how the requests send to the UAS SHOULD be correctly interpreted.
The REGISTER requests/responses look like this (outside of the firewall):
Protocol TCP!
client port 19091 <-> server port 5060
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc
Call-ID: 2825358480@10_10_128_10
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
REGISTER sip:pbx.peoplefone.ch SIP/2.0
Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>
Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514"
Max-Forwards: 70
User-Agent: N720-DM-PRO/70.089.00.000.000
Expires: 180
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0
From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda
Call-ID: 2825358480@10_10_128_10
CSeq: 2 REGISTER
Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP"
Server: kamailio (3.2.1 (x86_64/linux))
Content-Length: 0
The ip:port the firewall is sending those requests from is ip 212.126.160.92 port 19091. So this does NOT match the port from the Contact header. For TCP this seems rather logical to me, as one cant be listening on a TCP port and use it for sending at the same time. The UAC closes this “register connection” with TCP FIN after the register, and so does the firewall.
However unfortunately subsequent requests from the provider (ie UAS) come in on port 19091 (not port 6717 from the Contact header) and the firewall simply drops them.
Observations:
- the server does NOT include received=212.126.160.92 in the Via of the reponse. According to RFC3581 this is mandatory when rport is present in the request, so this is probably an error in the server.
- the server does include received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error.
- after the client received the 200 OK it closes the TCP connection.
- the server tries several times to re-contact the client (incoming TCP SYN). However not on port 6717 (defined in the Contact header) but on port 19091 (where the REGISTER came from).
RFC3581 defines special behaviour when “rport” is defined in the request (i.e. response should go to the same port the request came from) - however it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) requests from the server to the client. Those are strictly spoken not replies (or are they?).
RFC5626 defines that a “proxy” should keep track of the flows over which it received a registration and send requests over the same flow. It is not clear if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” parameter in the Contact field if it whishes further requests over the same flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact field. Both are not the case here, so in short I think RFC5626 should NOT be applied. In which case conecting to the originating port (instead of the Contact port) would be a server error.
So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on
Transport: TCP
IP: 212.126.160.92
Port: 6717
If anyone who lives and breathes SIP could enlighten me if the UAS is right to call back on 19091 instead of 6717 I would really appreciate it;-))
Best regards,
Joachim
Hello all,
Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio.
Especially creating partitions, DRBD devices and mount points.
Thanks in advance,
-Sid
"May the light be with you." ______________________________________________
Siddhardha Garige
www.luminepixels.com
Trying to call a T.38 enabled endpoint B from an endpoint A that doesn't. This
results in a "488 Not Acceptable" from A.
The kamailio (4.0.3) in between with topoh enabled (with mask_callid set to 1.
Kamailio ACKs the 488 to A, but the ACK has the wrong (masked) Call-ID,
resulting in the ACK to A being ignored, A keeps sending 488 at intervals
before just dropping the call.
My understanding is the Call-ID in the ACK has to be the same as the Call-ID
from the 488. But instead of sending the unmasked Call-ID used in all other
messages between A and Kamailio, the ACK contains the masked Call-ID used in
all messagea between A and Kamailio.
I can't find a bug report relating to this. Is this a known feature or maybe
fixed in newer versions?
A->Kamailio
SIP/2.0 488 Not acceptable here.
Via: SIP/2.0/UDP
109.235.32.40;branch=z9hG4bKf91a.c6c88747.0;received=109.235.32.40.
Via: SIP/2.0/UDP 172.19.162.1;branch=pocos-
rS4MusXox1l5QHyNxRy6uAXsEOdsxidSEAktxGZKWgeKCgeS-
RrKEAy057Nl9DEpWpefZD6AhGtwWDJjEqeuEAZgZs5iZA7*.
From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a.
To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097.
Call-ID: 0b5946b977210450571f767a19cd6fa0(a)99sip.pocos.nl.
CSeq: 102 INVITE.
Kamailio<-A
ACK sip:+31880100705@109.235.32.48 SIP/2.0.
Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKf91a.c6c88747.0.
Max-Forwards: 16.
From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a.
To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097.
Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*.
CSeq: 102 ACK.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
Hi,
I'm using 'allow_trusted()' from Permissions module without a problem in a
Kamailio 4.0 routing logic. It does just work, but the MI command
'trusted_dump' tells me that the module is not in use:
'''
server:/home/jmillan# kamctl fifo trusted_dump
500 Trusted-module not in use
'''
Doing a 'trusted_reload' does neither make any query to database to
retrieve the data.
Other MI commands of same module do work correctly. ie: 'address_reload' or
'address_dump'
Note: I have tested in a Kamailio 1.5 and the result is the same.
Regards.
--
José Luis Millán
Hello,
it is time to nail down the roadmap to the next major release. We
discussed during the last IRC devel meeting, proposing to get it out by
beginning of June. Given we need to have at least one month of testing,
I propose the next milestones:
- freezing the development: Wednesday, April 22, 2015
- if testing goes smooth, then branching 4.3 after about one month:
During the week starting May 18
- test more in beta phase, prepare packaging, etc. and release after 2-3
weeks: One of the days between June 4 and 11
Other suggestions or adjustments are welcome! Send them to mailing list
to discuss further.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Hi, all
I'm trying to set up 2 kamailio servers for active-active redundancy. The two kamailio severs share the the same database with db_mode=3, and no registration replication. Use pjsua2 as SIP client for testing. The test setup is as follows:
kamailio server 1(k1): 10.0.1.30:5061 <http://10.0.1.30:5061/>
kamailio server 2(k2): 10.0.1.32:5061 <http://10.0.1.32:5061/>
sip client c1: sip:16317@10.0.1.30 <mailto:sip%3A16317@10.0.1.30>, client ip: 10.0.1.254
sip client c2: sip:72316@10.0.1.30 <mailto:sip%3A72316@10.0.1.30>, client ip: 10.0.1.254
c1 is registered with k1.
c2 is registered with k2.
When c1 calls c2, the call flow is as follows:
INVITE:
c1------>k1------>k2------>c2
200 OK:
c1<------k1<------k2<------c2
So far, the INVITE works. c1 and c2 can establish a call. However, when c2 hangs up and sends BYE, the BYE is forwarded all the way to k1, and then k1 gives a 500 server error.
The log on k1 seems to indicate k1 was attempting to create a TLS connection to itself instead of using the existing TLS connection to c1 to forward the BYE.
BYE:
c1 X k1<------k2<------c2
|
|------->Connection refused/500
Here is the kamailio log on k1:
Mar 16 10:34:21 kamailio.sip.com <http://kamailio.sip.com/> /usr/sbin/kamailio[13396]: ERROR: <core> [tcp_main.c:2740]: tcpconn_1st_send(): connect 10.0.1.30:55999 <http://10.0.1.30:55999/> failed (RST) Connection refused
Mar 16 10:34:21 kamailio.sip.com <http://kamailio.sip.com/> /usr/sbin/kamailio[13396]: ERROR: <core> [tcp_main.c:2750]: tcpconn_1st_send(): 10.0.1.30:55999 <http://10.0.1.30:55999/>: connect & send for 0x7fc96a68a1a0 failed: Connection refused (111)
This is the routing logic for BYE in kamailio.cfg:
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
xlog("L_DBG", "=====BYE $ru from $fu $si:$sp to $du=====\n");
dlg_manage();
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
else if ( is_method("ACK") ) {
# ACK is forwarded statelessy
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
# Add Record-Route for in-dialog NOTIFY as per RFC 6665.
record_route();
}
route(RELAY);
exit;
} else {......
If I add location based routing for BYE from peer kamailio, then the BYE seems to be forwarded correctly:
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
xlog("L_DBG", "=====BYE $ru from $fu $si:$sp to $du=====\n");
dlg_manage();
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
# If BYE coming from Kamailio peer, route BYE by location
$var(peerlist)=$sel(cfg_get.trusted.peers);
$var(i) = 0;
while($var(i)<$(var(peerlist){param.count})) {
xlog("L_DBG", "=====$(var(peerlist){param.count})=====$(var(peerlist){param.valueat,$var(i)})=====\n");
if(src_ip==$(var(peerlist){param.valueat,$var(i)})) {
lookup("location");
xlog("L_DBG", "=====BYE from $fu $si:$sp to $du=====\n");
break;
}
$var(i) = $var(i) + 1;
}
}
else if ( is_method("ACK") ) {
# ACK is forwarded statelessy
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
# Add Record-Route for in-dialog NOTIFY as per RFC 6665.
record_route();
}
route(RELAY);
exit;
} else {......
My first question is why k1 loose_route sends the BYE to itself instead of the client. Is this a bug?
My next question is whether the above location routing for BYE from peer kamailio a good/safe approach.
The SIP traces will be sent later to avoid exceeding email size limit.
Thanks
Hello,
There seems to be an implementational difference in interpolation of PVs
in AVP and XAVP identifiers and/or field names.
The pseudovariables documentation[1] on classical AVPs says:
The 'id' can be:
...
pseudo variable - if value of pv is integer, id is integer,
if string, id is string
So, for example, this composition of variables works:
$var(f) = 'donkey';
$avp($var(f) = 'eehaw';
xlog("L_INFO", "Donkey says: $avp(donkey)\n");
It correctly prints:
Donkey says: eehaw
Making some assumptions, I tried this, and it did not work similarly as
expected:
$var(f) = 'donkey';
$xavp(r=>$var(f)) = 'eehaw';
xlog("L_INFO", "Donkey says: $xavp(r=>donkey)\n");
This prints:
Donkey says: <null>
And a PV dump confirms that the PV value is not interpolated:
Mar 31 18:26:15 localhost /usr/local/sbin/kamailio[2399]: INFO: debugger
[debugger_api.c:1799]: dbg_dump_json(): {"$xavp(r)":[{"$var(f)":["eehaw"]}]}
Interpolation of variables does not work for either field or stem names.
Is this a design principle of XAVPs, or an oversight?
Thanks,
-- Alex
[1]
http://www.kamailio.org/wiki/cookbooks/4.2.x/pseudovariables#avp_id_-_avps
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
I've been working on Kamailio websocket integration and I believe I'm having
issues with the IPv6 address representation in the Contact header's alias
parameter. After Googling, it appears after
https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is
represented in brackets []. However, it when using websockets, and the alias=
parameter uses brackets [] around and IPv6 address, there are message parsing
issues.
With a header such as the following
Contact:
<sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434e;alias=[2001:db8:0:1]~48768~6>
Asterisk 13.2.0 will give the following error:
pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP
10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line'
header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send
garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed:
WARNING: sanity [sanity.c:236]: check_ruri_scheme(): failed to parse request
uri [�a�{1me▒s�na@50�9���1.�8:�2v0;i��a��=11>7�n7x>10O�2v0~1]
Is it proper to have [] brackets around the IPv6 alias address in the Contact
header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip
and sipjs work perfectly in Firefox and Chrome.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
