Hello,
When saving in the location table, the expires and last_modified columns contain the value 000-00-00 00:00:00 which causes issues when Kamailio is restarted and the preload modparam is set to load the location table from db in memory at startup.
I've already upgraded Kamailio to 4.4.3, and used the dbtables script from version 4.4 to recreate the location table, but without success.
Anyone else having this issue? Any resolution for it?
Regards,
Grant Bagdasarian
CM
Hello Daniel,
Here more clear trace https://www.dropbox.com/s/2z6ck71ulidqelh/kamailio-BYE-flow.png?dl=0
BYE send by kamailio to wrong freeswitch box.
Slava
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 20:09:53
Subject: Re: [SR-Users] BYE dispatcher
Hello Daniel,
Please check this sip call flow picture https://www.dropbox.com/s/itdewdg3ph7xcyx/kamailio-fs-BYE-flow.gif?dl=0
Kamilio send BYE to incorrect freeswitch which already responded to BYE from leg one.
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 19:11:56
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
Here are full trace call.
https://paste.fedoraproject.org/476607/14787290/
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 13:17:34
Subject: Re: [SR-Users] BYE dispatcher
Based on this out put Freeswitch send BYE to kamailio and Route present then kamailio forward BYE to client and no routes. Then client reply 481. Do I need add it ? Is this tag= problem ?
24 is freeswtich and 27 kamailio.
IP (tos 0x0, ttl 64, id 56723, offset 0, flags [none], proto UDP (17), length 704)
10.18.130.24.5160 > 10.18.130.27.sip: [udp sum ok] UDP, length 676
E.......@..B
...
....(....8.BYE sip:4300@client_public_ip:49383 SIP/2.0
Via: SIP/2.0/UDP 10.18.130.24:5160;rport;branch=z9hG4bKm80c0USSKv5Bp
Route: <sip:10.18.130.27;r2=on;lr=on;ftag=SXt3DQQ90a0Dj>
Route: <sip:proxy_public_ip:5084;r2=on;lr=on;ftag=SXt3DQQ90a0Dj>
Max-Forwards: 70
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
IP (tos 0x10, ttl 64, id 36705, offset 0, flags [none], proto UDP (17), length 700)
proxy_public_ip.llrp > client_public_ip.49383: [bad udp cksum 0x4d15 -> 0x34be!] UDP, length 672
E....a..@..d.E.\c.........M.BYE sip:4300@client_public_ip:49383 SIP/2.0
Via: SIP/2.0/UDP proxy_public_ip:5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
Max-Forwards: 69
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
IP (tos 0x0, ttl 52, id 7731, offset 0, flags [none], proto UDP (17), length 638)
client_public_ip.49383 > proxy_public_ip.llrp: [udp sum ok] UDP, length 610
E..~.3..4...c....E.\.....j..SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP proxy_public_ip:5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
Supported: replaces, path, eventlist
User-Agent: Grandstream Wave 1.2.2
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 13:07:11
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
I cleared registrations and tried again and issue still present.
Client reply with 481.
IP (tos 0x0, ttl 52, id 7731, offset 0, flags [none], proto UDP (17), length 638)
client_pub_ip.49383 > proxy_pub_ip.llrp: [udp sum ok] UDP, length 610
E..~.3..4...c....E.\.....j..SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP proxy_pub_ip :5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@ client_pub_ip :49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
Supported: replaces, path, eventlist
User-Agent: Grandstream Wave 1.2.2
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: miconda(a)gmail.com, "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 12:28:32
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
I changed dispatcher algorithm from 0 to 1 and start working as expected. Yes group 0 is accepted.
route[DISPATCHER] {
if(!ds_select_dst("0", "1")) {
xlog("L_ERROR","ERROR: Proxy Mapping - Desitnation for $fd not found...request dropped \n");
sl_send_reply("404","Desitination Not Found \n");
drop();
} else {
$var(did) = 1;
}
if($var(did)) {
if (!t_relay()) {
sl_reply_error();
}
#forward();
}
t_on_failure("DISPATCHER_FAIL_ROUTE");
exit;
}
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 04:33:33
Subject: Re: [SR-Users] BYE dispatcher
Hello,
On 08/11/16 20:42, Slava Bendersky wrote:
Hello Everyone,
My setup is kamailio as proxy with few boxes of freeswitch in the LAN. Having issue with BYE when extensions register on different freeswitch boxes. Here are some trace of the call.
Not sure if this tag= miss match or routing.
Dispatcher use group 0 with option 4 (round robin).
is group value 0 accepted? I think this may create problems if a function returns the group in the config as return code -- iirc, this was changed maybe for lcr or permissions.
On the other hand, the registrations are quite independent in SIP in relation with calls. The BYE should be routed based on record-routing to the freeswitch that was involved in routing initial INVITE, with no relation to new registrations from end devices. Is the BYE sent to the freeswitch that got the initial BYE.
Cheers,
Daniel
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello Daniel,
Please check this sip call flow picture https://www.dropbox.com/s/itdewdg3ph7xcyx/kamailio-fs-BYE-flow.gif?dl=0
Kamilio send BYE to incorrect freeswitch which already responded to BYE from leg one.
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 19:11:56
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
Here are full trace call.
https://paste.fedoraproject.org/476607/14787290/
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 13:17:34
Subject: Re: [SR-Users] BYE dispatcher
Based on this out put Freeswitch send BYE to kamailio and Route present then kamailio forward BYE to client and no routes. Then client reply 481. Do I need add it ? Is this tag= problem ?
24 is freeswtich and 27 kamailio.
IP (tos 0x0, ttl 64, id 56723, offset 0, flags [none], proto UDP (17), length 704)
10.18.130.24.5160 > 10.18.130.27.sip: [udp sum ok] UDP, length 676
E.......@..B
...
....(....8.BYE sip:4300@client_public_ip:49383 SIP/2.0
Via: SIP/2.0/UDP 10.18.130.24:5160;rport;branch=z9hG4bKm80c0USSKv5Bp
Route: <sip:10.18.130.27;r2=on;lr=on;ftag=SXt3DQQ90a0Dj>
Route: <sip:proxy_public_ip:5084;r2=on;lr=on;ftag=SXt3DQQ90a0Dj>
Max-Forwards: 70
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
IP (tos 0x10, ttl 64, id 36705, offset 0, flags [none], proto UDP (17), length 700)
proxy_public_ip.llrp > client_public_ip.49383: [bad udp cksum 0x4d15 -> 0x34be!] UDP, length 672
E....a..@..d.E.\c.........M.BYE sip:4300@client_public_ip:49383 SIP/2.0
Via: SIP/2.0/UDP proxy_public_ip:5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
Max-Forwards: 69
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0
IP (tos 0x0, ttl 52, id 7731, offset 0, flags [none], proto UDP (17), length 638)
client_public_ip.49383 > proxy_public_ip.llrp: [udp sum ok] UDP, length 610
E..~.3..4...c....E.\.....j..SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP proxy_public_ip:5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_public_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
Supported: replaces, path, eventlist
User-Agent: Grandstream Wave 1.2.2
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 13:07:11
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
I cleared registrations and tried again and issue still present.
Client reply with 481.
IP (tos 0x0, ttl 52, id 7731, offset 0, flags [none], proto UDP (17), length 638)
client_pub_ip.49383 > proxy_pub_ip.llrp: [udp sum ok] UDP, length 610
E..~.3..4...c....E.\.....j..SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP proxy_pub_ip :5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@ client_pub_ip :49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
Supported: replaces, path, eventlist
User-Agent: Grandstream Wave 1.2.2
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
Slava.
From: "volga629" <volga629(a)skillsearch.ca>
To: miconda(a)gmail.com, "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 12:28:32
Subject: Re: [SR-Users] BYE dispatcher
Hello Everyone,
I changed dispatcher algorithm from 0 to 1 and start working as expected. Yes group 0 is accepted.
route[DISPATCHER] {
if(!ds_select_dst("0", "1")) {
xlog("L_ERROR","ERROR: Proxy Mapping - Desitnation for $fd not found...request dropped \n");
sl_send_reply("404","Desitination Not Found \n");
drop();
} else {
$var(did) = 1;
}
if($var(did)) {
if (!t_relay()) {
sl_reply_error();
}
#forward();
}
t_on_failure("DISPATCHER_FAIL_ROUTE");
exit;
}
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, 9 November, 2016 04:33:33
Subject: Re: [SR-Users] BYE dispatcher
Hello,
On 08/11/16 20:42, Slava Bendersky wrote:
Hello Everyone,
My setup is kamailio as proxy with few boxes of freeswitch in the LAN. Having issue with BYE when extensions register on different freeswitch boxes. Here are some trace of the call.
Not sure if this tag= miss match or routing.
Dispatcher use group 0 with option 4 (round robin).
is group value 0 accepted? I think this may create problems if a function returns the group in the config as return code -- iirc, this was changed maybe for lcr or permissions.
On the other hand, the registrations are quite independent in SIP in relation with calls. The BYE should be routed based on record-routing to the freeswitch that was involved in routing initial INVITE, with no relation to new registrations from end devices. Is the BYE sent to the freeswitch that got the initial BYE.
Cheers,
Daniel
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
Kamailio SIP Server v4.4.4 stable release is out.
This is a maintenance release of the latest stable branch, 4.4, that
includes fixes since the release of v4.4.3. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v4.4.x. Deployments running previous v4.x.x
versions are strongly recommended to be upgraded to v4.4.4.
For more details about version 4.4.4 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2016/11/kamailio-v4-4-4-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Greetings list,
I am using dialog aur dispatcher modules for calls distribution across
multiple gateways. I am able to get number of active dialogs against a
gateway but could not get early dialogs going on particular gateway.
Dialog information is inserted in database only for state 4. Also, I tried
to use dlg_list command to get early dialogs. I see call statistics but
"callee_contact::" is empty untill call is answered.
for ringing I am getting this.
root@debian:/usr/local/kamailio/sbin# ./kamctl fifo dlg_list
dialog:: hash=3443:9422
state:: 2
ref_count:: 1
timestart:: 0
timeout:: 0
callid:: GGjl58SQ32LXQB1dV2-CBA..
from_uri:: sip:1015@192.168.10.39:5060;transport=UDP
from_tag:: 652ee907
caller_contact:: sip:1015@192.168.10.41:55842;transport=UDP
caller_cseq:: 1
caller_route_set::
caller_bind_addr:: udp:192.168.10.39:5060
callee_bind_addr::
to_uri:: sip:1010@192.168.10.39:5060;transport=UDP
to_tag::
callee_contact::
callee_cseq::
callee_route_set::
callee_contact:: is empty.
Is there any way to get early dialog info againts a gateway.? Or any way to
insert early dialog into database with callee_contact not empty?
Best Regards,
Aqs Younas
Hello,
I am considering to package a new release out of latest stable branch
4.4, respectively v4.4.4. The target date is one of the days between Nov
8-10, a matter of work load that needs to be done for getting it out.
As usual, if you are aware of any issue not yet reported on github bug
tracker, do it as soon as possible to give it a chance to be fixed:
- https://github.com/kamailio/kamailio/issues
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
Hello Daniel,
Yes, reply was 202 not 200. Right now it work as expected.
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Monday, 7 November, 2016 04:51:11
Subject: Re: [SR-Users] fnmatch
Hello,
for clarification -- what's the actual problem here? fnmatch("$rs", "200") is matching the 202?
Cheers,
Daniel
On 07/11/16 08:52, Serge S. Yuriev wrote:
Hello,
In debug you can see 202 Accepted but match configured on 200. Not matched
--
Wbr, Serge via mobile
07.11.2016, 01:08, "Slava Bendersky" <volga629(a)skillsearch.ca> :
BQ_BEGIN
Hello Everyone,
I trying fnmatch to find which sip status is returned by B2BUA. But some reason it doesn't work.
Nov 6 17:02:15 cavprx00 kamailio: 2(3747) ERROR: *** cfgtrace:onreply_route=[MESSAGE_FORWARD] c=[/etc/kamailio/kamailio-asterisk.cfg] l=456 a=26 n=xlog
Nov 6 17:02:15 cavprx00 kamailio: 2(3747) INFO: <script>: Message 1 Accepted by B2BUA --> 202 with Accepted
Nov 6 17:02:15 cavprx00 kamailio: 2(3747) ERROR: *** cfgtrace:onreply_route=[MESSAGE_FORWARD] c=[/etc/kamailio/kamailio-asterisk.cfg] l=469 a=16 n=if
Nov 6 17:02:15 cavprx00 kamailio: 2(3747) ERROR: *** cfgtrace:onreply_route=[MESSAGE_FORWARD] c=[/etc/kamailio/kamailio-asterisk.cfg] l=457 a=26 n=fnmatch
Nov 6 17:02:15 cavprx00 kamailio: 2(3747) ERROR: *** cfgtrace:onreply_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio-asterisk.cfg] l=370 a=2 n=return
if(fnmatch("$rs", "200") && (fnmatch("$rr", "Accepted"))) {
xlog("L_INFO", "Message Accepted by B2BUA --> $rs with $rr \n");
$var(tu) = $tu;
xlog("L_INFO", "New To --> $var(tu)\n");
}
Is this fnmatch correct for this operation ?
Slava.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Greetings list,
I am using dialog aur dispatcher modules for calls distribution across
multiple gateways. I am able to get number of active dialogs against a
gateway but could not get early dialogs going on particular gateway.
Dialog information is inserted in database only for state 4. Also, I tried
to use dlg_list command to get early dialogs. I see call statistics but
"callee_contact::" is empty untill call is answered.
For ringing I am getting this.
root@debian:/usr/local/kamailio/sbin# ./kamctl fifo dlg_list
dialog:: hash=3443:9422
state:: 2
ref_count:: 1
timestart:: 0
timeout:: 0
callid:: GGjl58SQ32LXQB1dV2-CBA..
from_uri:: sip:1015@192.168.10.39:5060;transport=UDP
from_tag:: 652ee907
caller_contact:: sip:1015@192.168.10.41:55842;transport=UDP
caller_cseq:: 1
caller_route_set::
caller_bind_addr:: udp:192.168.10.39:5060
callee_bind_addr::
to_uri:: sip:1010@192.168.10.39:5060;transport=UDP
to_tag::
callee_contact::
callee_cseq::
callee_route_set::
callee_contact:: is empty.
Is there any way to get early dialog info against each gateway or every
dialog stat insertion in database dialog table.
Best Regards.
hello all
i'm using kam version 4.4.1 and i would like to generate an ISUP part on
the 1xx,2xx responses to a remote carrier since the fsw i send the calls
to cannot handle ISUP SDP.
despite seeing in the doc that those functions cannot be used there and
only in REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE, i tried and it
works.... partially, because it seems it doesnt create the last boundary
and it creates a next boundary with an empty "Encapsulated multipart
part: "
this the the route i call from onreply_route
route[SIPISUP] {
set_body_multipart();
msg_apply_changes();
$var(isup) = "\x01\x12\x49\x01\x0a\x03\x02\x0a\x08\x84\x90\x33\x41
\x72\x17\x01\x06\x0a\x08\x04\x13\x93\x70\x21\x73\x23\x10\x08\x01\x01
\x00";
append_body_part("$var(isup)","application/isup;version=itu-t92
+","signal;handling=optional");
msg_apply_changes();
sipt_destination($rU, 31, 4);
sipt_set_calling($fU, 4, 0, 3);
msg_apply_changes();
}
am i doing something wrong? how can i set this to end the SDP with last
boundary?
thanks a lot and regards
david
