Re: [SR-Users] Loopback
Hello, On 8/28/13 8:22 PM, Marc Soda wrote: Thanks, I appreciate it. In this setup the there are 2 endpoints (700 and 701) peered up to an Asterisk server (172.16.60.6) via a Kamailio proxy (172.16.60.20). 700 (172.16.60.28) is calling 701 (172.16.3.65). When 701 answers the OK is sent to the proxy and then to Asterisk. Asterisk is then ACKing the OK. The ACK is being sent to the proxy and then the proxy should be sending it back to the endpoint. It is not. The ACK is being sent to the proxy and then the proxy is sending to itself again, via the loopback interface. I believe loose_route() should be re-writing the destination to be the endpoint, but it not. what device is at 701? The 200ok receved from it has the contact address with the IP of kamailio: U 172.16.3.65:5060 -> 172.16.60.20:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.60.20;received=172.16.60.20;branch=z9hG4bK9381.d7d662b.0. Via: SIP/2.0/UDP 172.16.60.6:5060;rport=5060;branch=z9hG4bK0919ead7. Record-Route: . Call-ID: 64a513d30fc6a51e54e8255b7169345c@172.16.60.6:5060. From: "Alpha" ;tag=as5e1a80d8. To: ;tag=64c37e7e-19b8-46ae-ad0d-f2a4abe667bc. CSeq: 102 INVITE. Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE. *Contact: *. . It should be its IP address, otherwise Kamailio doesn't know where to sent requests within dialog. It seems there is a NAT between your kamailio and 701, as kamailio adds alias parameter to Contact in 200ok. That can be used to route the ack, like: handle_ruri_alias(); $ru = $du; $du = $null; Do the above for the ACK before calling loose_route(). Then it will get out of kamailio, but might not solve the overall routing, if the 701 is not at next hop or it doesn't like the r-uri, because it is not what it has set. The best is to ask for the proper fix on 701 device. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] XMPP issue
Dear All,
I am working on XMPP module of kamailio(4.0.2) server along with Jabberd2
xmpp server (as recommended in XMPP module's README).
I was successful in setting-up Jabberd sever and i can transfer files
through it (using Jitsi's XMPP clients) as a standalone xmpp server.
But the problem is when trying to integrate this jabberd2 server with my
kamailio server.
*Problem*:
After starting Kamailio sever, Syslog is given the error as follows:
Aug 28 19:45:14 kamailio /usr/local/sbin/kamailio[
19648]: ERROR: xmpp [network.c:110]: net_connect(): resolving
xmpp.example.com failed (Unknown host).
And XMPP related Configuration in Kamailio.cfg is as follows:
# - XMPP -
#!ifdef WITH_XMPP
modparam("xmpp", "backend", "component")
modparam("xmpp", "domain_separator", "*")
modparam("xmpp", "gateway_domain", "192.168.2.41")
modparam("xmpp", "xmpp_domain", "192.168.2.41")
modparam("xmpp", "xmpp_host", "192.168.2.41")
modparam("xmpp", "xmpp_port", 5347)
modparam("xmpp", "xmpp_password", "xmpp")
modparam("xmpp", "outbound_proxy", "sip:192.168.2.41;transport=tcp")
modparam("xmpp", "gwmap", "192.168.2.41")
modparam("presence", "db_url", "mysql://kamailio:kamailiorw@kamailio
/kamailio")
modparam("usrloc", "db_url", "mysql://kamailio:kamailiorw@kamailio
/kamailio")
modparam("pua", "db_url", "mysql://kamailio:kamailiorw@kamailio/kamailio")
modparam("pua", "db_table", "pua")
modparam("presence_xml", "db_url", "mysql://kamailio:kamailiorw@kamailio
/kamailio")
#modparam("presence_xml", "integrated_xcap_server", 1)
modparam("presence", "max_expires", 3600)
modparam("presence", "server_address", "sip:192.168.2.41:5060")
modparam("pua_xmpp", "server_address", "sip:192.168.2.41")
#!endif
#-XMPP
# Presence server route
route[PRESENCE]
#!ifdef WITH_XMPP
#if ($rd =="192.168.2.41") {
if (!t_newtran())
{
sl_reply_error();
exit;
};
};
# if( is_method("NOTIFY") && uri=~"sip:.+@192.168.2.41")
if( is_method("NOTIFY"))
{
xlog("processing NOTIFY...\n");
pua_xmpp_notify();
t_reply("200", "OK");
exit;
}
if(is_method("PUBLISH"))
{
xlog("processing PUBLISH ...\n");
if($hdr(Sender)!= $null)
{
xlog("Sender header found.\n");
}
handle_publish();
t_release();
}
else
if( is_method("SUBSCRIBE"))
{
xlog("processing SUBSCRIBE ...\n");
handle_subscribe();
if( uri=~"sip:.+@192.168.2.41" && $hdr(Event)== "presence")
{
xlog("calling pua_xmpp_req_winfo()\n");
pua_xmpp_req_winfo("$ruri", "$hdr(Expires)");
}
t_release();
}
exit;
#!endif
What could be the wrong with this ?
And regarding *File transfer *feature in kamailio, is there any other ways
to get through?
Any help will greatly appreciate.
Regards,
Nandini
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] unregister user when kamailio looses TCP connection.
On 8/28/13 10:33 PM, Juha Heinanen wrote: Vitaliy Aleksandrov writes: Didn't know about $T_reply_rid variable and that unregister can remove only single contact. In my case the problem with unregister is that stale contact will be removed only if somebody tries to call to a disconnected phone. so you get one call to unregistered contact and after that it is not anymore in location db. is that not acceptable to you? are you proposing to scan all contacts for broken tcp connections on some timer or what? proposed solution in the patch was to scan all the location records when a tcp connection goes down. I suggested to keep the connection id + peer ip/port in a list and scan the location records from time to time, eventually via a dedicated timer process. Anyhow, the patch is not that complete yet, some cases were not approached. Another idea I threw in (which I thought of doing), is to to something similar to nat keepalive mechanism in nathelper module (which fetches natted contacts and send nat pings), but now fetching all tcp contacts and verifying that the tcp connection is still active. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] unregister user when kamailio looses TCP connection.
Thanks community for all replies.
I did the second try. Result is in the attachment.
This time a did it in the way proposed by Daniel-Constantin Mierla.
All job is done in timer process when it iterates through all
registrations looking for expired ones.
It works for all database modes except DB_ONLY.
I'm not sure about tcpconn_get() / tcpconn_put() functions.
tcpconn_get() increments ref counter, but there are several function to
decrement it: tcpconn_put(), tcpconn_chld_put() and
atomic_dec_and_test(). When I was looking for examples in other modules
I saw that tcp_read.c uses tcpconn_chld_put(), but forward.h and
msg_translator.c uses only tcpconn_get() without decrementing ref
counter at all.
It would be great if somebody more experienced shed some light on this.
diff -uNpr kamailio-4.0.3/ip_addr.h sshfs_kamailio-4.0.3/ip_addr.h
--- kamailio-4.0.3/ip_addr.h 2013-08-15 16:42:39.0 +0300
+++ sshfs_kamailio-4.0.3/ip_addr.h 2013-08-28 18:28:08.0 +0300
@@ -142,6 +142,7 @@ struct receive_info{
struct socket_info* bind_address; /* sock_info structure on which
the msg was received*/
char proto;
+ int tcpconn_id; /* tcp_connnection->id */
#ifdef USE_COMP
short comp; /* compression */
#endif
diff -uNpr kamailio-4.0.3/modules/registrar/save.c sshfs_kamailio-4.0.3/modules/registrar/save.c
--- kamailio-4.0.3/modules/registrar/save.c 2013-08-15 16:42:39.0 +0300
+++ sshfs_kamailio-4.0.3/modules/registrar/save.c 2013-08-29 01:44:11.0 +0300
@@ -259,6 +259,14 @@ static inline ucontact_info_t* pack_ci(
ci.sock = _m->rcv.bind_address;
}
+ /* set tcp connection id */
+ if (_m->rcv.proto==PROTO_TCP || _m->rcv.proto==PROTO_TLS
+ || _m->rcv.proto==PROTO_WS || _m->rcv.proto==PROTO_WSS) {
+ ci.tcpconn_id = _m->rcv.tcpconn_id;
+ } else {
+ ci.tcpconn_id = -1;
+ }
+
/* additional info from message */
if (parse_headers(_m, HDR_USERAGENT_F, 0) != -1 && _m->user_agent &&
_m->user_agent->body.len>0 && _m->user_agent->body.lencseq++;
if ( r->contacts==0
|| ul.get_ucontact_by_instance(r, &_c->uri, ci, &c) != 0) {
diff -uNpr kamailio-4.0.3/modules/usrloc/ucontact.c sshfs_kamailio-4.0.3/modules/usrloc/ucontact.c
--- kamailio-4.0.3/modules/usrloc/ucontact.c 2013-08-15 16:42:39.0 +0300
+++ sshfs_kamailio-4.0.3/modules/usrloc/ucontact.c 2013-08-29 01:49:56.0 +0300
@@ -135,6 +135,7 @@ ucontact_t* new_ucontact(str* _dom, str*
c->reg_id = _ci->reg_id;
c->last_modified = _ci->last_modified;
c->last_keepalive = _ci->last_modified;
+ c->tcpconn_id = _ci->tcpconn_id;
#ifdef WITH_XAVP
ucontact_xavp_store(c);
#endif
diff -uNpr kamailio-4.0.3/modules/usrloc/ul_mod.c sshfs_kamailio-4.0.3/modules/usrloc/ul_mod.c
--- kamailio-4.0.3/modules/usrloc/ul_mod.c 2013-08-15 16:42:39.0 +0300
+++ sshfs_kamailio-4.0.3/modules/usrloc/ul_mod.c 2013-08-29 13:04:13.0 +0300
@@ -161,6 +161,7 @@ int timer_interval = 60;/*!< Timer
int db_mode = 0;/*!< Database sync scheme: 0-no db, 1-write through, 2-write back, 3-only db */
int use_domain = 0;/*!< Whether usrloc should use domain part of aor */
int desc_time_order = 0;/*!< By default do not enable timestamp ordering */
+int handle_lost_tcp = 0;
int ul_fetch_rows = 2000;/*!< number of rows to fetch from result */
int ul_hash_size = 9;
@@ -214,6 +215,7 @@ static param_export_t params[] = {
{"fetch_rows", INT_PARAM, &ul_fetch_rows },
{"hash_size", INT_PARAM, &ul_hash_size},
{"nat_bflag", INT_PARAM, &nat_bflag },
+ {"handle_lost_tcp", INT_PARAM, &handle_lost_tcp },
{"preload", STR_PARAM|USE_FUNC_PARAM, (void*)ul_preload_param},
{"db_update_as_insert", INT_PARAM, &ul_db_update_as_insert},
{"timer_procs", INT_PARAM, &ul_timer_procs},
@@ -387,6 +389,10 @@ static int mod_init(void)
return -1;
}
}
+
+ if (handle_lost_tcp && db_mode == DB_ONLY)
+ LM_WARN("handle_lost_tcp option makes nothing in DB_ONLY mode\n");
+
init_flag = 1;
return 0;
diff -uNpr kamailio-4.0.3/modules/usrloc/ul_mod.h sshfs_kamailio-4.0.3/modules/usrloc/ul_mod.h
--- kamailio-4.0.3/modules/usrloc/ul_mod.h 2013-08-15 16:42:38.0 +0300
+++ sshfs_kamailio-4.0.3/modules/usrloc/ul_mod.h 2013-08-29 02:06:38.0 +0300
@@ -84,6 +84,7 @@ extern int ul_hash_size;
extern int ul_db_update_as_insert;
extern int ul_db_check_update;
extern int ul_keepalive_timeout;
+extern int handle_lost_tcp;
/*! nat branch flag */
extern unsigned int nat_bflag;
diff -uNpr kamailio-4.0.3/modules/usrloc/urecord.c sshfs_kamailio-4.0.3/modules/usrloc/urecord.c
--- kamailio-4.0.3/modules/usrloc/urecord.c 2013-08-15 16:42:39.0 +0300
+++ sshfs_kamailio-4.0.3/modules/usrloc/urecord.c 2013-08-29 13:01:02.0 +0300
@@ -40,6 +40,7 @@
#include "../../dprint.h"
#include "../../ut.h"
#include "../../hashes.h"
+#include "../../tcp_conn.h"
#include "ul_mod.h"
#include "usrloc.h"
#inc
Re: [SR-Users] unregister user when kamailio looses TCP connection.
Daniel-Constantin Mierla writes: > proposed solution in the patch was to scan all the location records when > a tcp connection goes down. ok. for me it is enough to unregister tcp (and udp) contact when tm tries to reach it. the only problem with that currently is that branch failure route is not executed immediately, but after tm timer fires although tm learns immediately that tcp contact is not reachable. > Another idea I threw in (which I thought of doing), is to to something > similar to nat keepalive mechanism in nathelper module (which fetches > natted contacts and send nat pings), but now fetching all tcp contacts > and verifying that the tcp connection is still active. that sounds like a clean, good solution. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Server silently droping Bye message.
Hello,
Thanks in advanced for the help. I am absolutely new with kamailio and still
struggling through silly problems so please forgive me if the solutions is
so obvious.
I have a network like
Devices --à Kamailio --à pstn GW
The PSTN GW is more or less out of my reach for changing the behaivour.
As devices I have xlite, 3cx and an android app
Kamailio is on version 4.0.2
I have problems with the calls to PSTN, When A is the Android app the server
is not able to relay the Bye coming from the pstngw so the android app does
not disconnect the call. This do not happened when A are xlite or 3cx. Bye
is correctly sent to the PSTNGW if it comes from the android app. For calls
inside the kamailio server there is no problem with the devices and all the
byes are sent ok.
When I call from the android app I have to drop some of the parameters on
the Contact header because the pstngw do not like them and drop the call
otherwise (responding with a 500 IRP error) I droped the parameters using:
subst('/^Contact: (.*)>.*$/Contact: \1>/i');#delete the parameter that
is anoying pstnGW on contact header
I also change request uri deleting the 00, but I do this modification on all
the calls. I have tried without this ruri modification and the resoult is
the same xlite ok android ko so I do not think that is affecting.
subst_uri('/^sip:00(.*)/sip:\1/i'); # delete the 00
Searching on the kamailio log I found that in the android call:
DEBUG:
tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=113 , global msg
id=112 , T on entrance=0x
DEBUG:
tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start searching:
hash=30121, isACK=0
DEBUG:
tm [t_lookup.c:492]: matching_3261(): DEBUG: RFC3261 transaction matching
failed
DEBUG:
tm [t_lookup.c:716]: t_lookup_request(): DEBUG: t_lookup_request: no
transaction found
DEBUG:
tm [t_hooks.c:374]: run_reqin_callbacks_internal(): DBG:
trans=0x7f60cadc8d10, callback type 1, id 0 entered
While on the xlite call I can see
tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=116 , global msg
id=115 , T on entrance=(nil)
tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start searching:
hash=64449, isACK=0
tm [t_lookup.c:477]: matching_3261(): DEBUG: RFC3261 transaction matched,
tid=1cbf.617b985b6620c855b501dfbfced5f7a4.0
tm [t_lookup.c:733]: t_lookup_request(): DEBUG: t_lookup_request:
transaction found (T=0x7f60cadb2510)
When processing the BYE. So Im thinking that the problem is that Kamailio
do not know where to send it. Im not sure that is the problem.
Ive checked and tags and session information seem ok to me, so I do not
understand what is wrong with the Bye so the server cannot find where it
should be sent to.
I attached a trace with both calls first xlite and then android
This is the Bye on the XLite call
Frame 59: 788 bytes on wire (6304 bits), 788 bytes captured (6304 bits)
Ethernet II, Src: Cisco_67:50:00 (macAdd), Dst: FujitsuT_80:7d:d8 (macAdd)
Internet Protocol Version 4, Src: PSTNGWIP (PSTNGWIP), Dst: ServerIP
(ServerIP)
User Datagram Protocol, Src Port: sip (5060), Dst Port: ServerPort
(ServerPort)
Session Initiation Protocol (BYE)
Request-Line: BYE sip:XliteAnumber@publicXliteIP:55838;transport=tcp
SIP/2.0
Method: BYE
Request-URI: sip:XliteAnumber@publicXliteIP:55838;transport=tcp
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
PSTNGWIP;branch=z9hG4bK5d4.f93633a612aca237ad1f5c341c1b2986.0
Via: SIP/2.0/UDP
PSTNGWIP:5061;branch=z9hG4bK-fat3ctwlimdw3lkb;rport=5061
Route:
Route:
Max-Forwards: 16
From: 00Bnumber
;tag=eihmt4yopie2j4fq.i
To: ;tag=2b8f312e
Call-ID: NGZlMDU3OWE2YjM1ZGQ1OTEyM2NiNmI0YjM1MjA0YTg
CSeq: 515 BYE
Sequence Number: 515
Method: BYE
Contact: Anonymous
User-Agent: Sippy
cisco-GUID: 521708479-278139363-3214082078-3387785402
h323-conf-id: 521708479-278139363-3214082078-3387785402
and that one is the one on the Android one:
Frame 115: 766 bytes on wire (6128 bits), 766 bytes captured (6128 bits)
Ethernet II, Src: Cisco_67:50:00 (macAdd), Dst: FujitsuT_80:7d:d8 (macAdd)
Internet Protocol Version 4, Src: PSTNGWIP (PSTNGWIP), Dst: ServerIP
(ServerIP)
User Datagram Protocol, Src Port: sip (5060), Dst Port: ServerPort
(ServerPort)
Session Initiation Protocol (BYE)
Request-Line: BYE
sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp SIP/2.0
Method: BYE
Request-URI: sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
PSTNGWIP;branch=z9hG4bKf0a2.679a023eeebfc2b9acae8c683386146f.0
Via: SIP/2.0/UDP
PSTNGWIP:5061;branch=z9hG4bK-ge57vxpelnqy57yg;rport=5061
Route:
Route:
Max-Forwards: 16
[SR-Users] PUBLISH/SUBSCRIBE in pidf format
Can anybody suggest me whether kamailio 4.0.3 supports pidf format for handling presence related stuff instead of XCAP server.If yes what are the corrosponding changes in the kamaolio cfg file? If not, then how can I test my kamailio presence with XCAP functionality with a browser based client like SIPML5.Actually I want the XCAP related stuff instead of pidf which is currently available in Dubango SIPML5 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Server silently droping Bye message.
Hello,
the BYE does not have information about the public ip of the nat router
behind which is located the android device.
With the default config of kamailio, that should be stored as alias
parameter in the contact header.
You should send the full signaling from first invite to the bye for the
case that does not work, in order to see if something goes wrong there
and what party is responsible for that.
You should use ngrep to take the trace on kamailio server, because it
easy to read and captures the both sides. A sample command would be:
ngrep -d any -qt -W byline port 5060
Of course you can replace IP addresses with suggestive tokens.
Cheers,
Daniel
On 8/29/13 2:00 PM, Helena Garcia-Nieto wrote:
Hello,
Thanks in advanced for the help. I am absolutely new with kamailio and
still struggling through silly problems so please forgive me if the
solutions is so obvious.
I have a network like
Devices --àKamailio --àpstn GW
The PSTN GW is more or less out of my reach for changing the behaivour.
As devices I have xlite, 3cx and an android app
Kamailio is on version 4.0.2
I have problems with the calls to PSTN, When A is the Android app the
server is not able to relay the Bye coming from the pstngw so the
android app does not disconnect the call. This do not happened when A
are xlite or 3cx. Bye is correctly sent to the PSTNGW if it comes from
the android app. For calls inside the kamailio server there is no
problem with the devices and all the byes are sent ok.
When I call from the android app I have to drop some of the parameters
on the Contact header because the pstngw do not like them and drop the
call otherwise (responding with a 500 IRP error) I droped the
parameters using:
subst('/^Contact: (.*)>.*$/Contact: \1>/i');#delete the parameter
that is anoying pstnGW on contact header
I also change request uri deleting the 00, but I do this modification
on all the calls. I have tried without this ruri modification and the
resoult is the same xlite ok android ko so I do not think that is
affecting.
subst_uri('/^sip:00(.*)/sip:\1/i'); # delete the 00
Searching on the kamailio log I found that in the android call:
DEBUG:
tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=113 ,
global msg id=112 , T on entrance=0x
DEBUG:
tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start
searching: hash=30121, isACK=0
DEBUG:
tm [t_lookup.c:492]: matching_3261(): DEBUG: RFC3261 transaction
matching failed
DEBUG:
tm [t_lookup.c:716]: t_lookup_request(): DEBUG: t_lookup_request: no
transaction found
DEBUG:
tm [t_hooks.c:374]: run_reqin_callbacks_internal(): DBG:
trans=0x7f60cadc8d10, callback type 1, id 0 entered
While on the xlite call I can see
tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=116 ,
global msg id=115 , T on entrance=(nil)
tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start
searching: hash=64449, isACK=0
tm [t_lookup.c:477]: matching_3261(): DEBUG: RFC3261 transaction
matched, tid=1cbf.617b985b6620c855b501dfbfced5f7a4.0
tm [t_lookup.c:733]: t_lookup_request(): DEBUG: t_lookup_request:
transaction found (T=0x7f60cadb2510)
When processing the BYE. So I'm thinking that the problem is that
Kamailio do not know where to send it. I'm not sure that is the problem.
I've checked and tags and session information seem ok to me, so I do
not understand what is wrong with the Bye so the server cannot find
where it should be sent to.
I attached a trace with both calls first xlite and then android
This is the Bye on the XLite call
Frame 59: 788 bytes on wire (6304 bits), 788 bytes captured (6304 bits)
Ethernet II, Src: Cisco_67:50:00 (macAdd), Dst: FujitsuT_80:7d:d8 (macAdd)
Internet Protocol Version 4, Src: PSTNGWIP (PSTNGWIP), Dst: ServerIP
(ServerIP)
User Datagram Protocol, Src Port: sip (5060), Dst Port: ServerPort
(ServerPort)
Session Initiation Protocol (BYE)
Request-Line: BYE
sip:XliteAnumber@publicXliteIP:55838;transport=tcp SIP/2.0
Method: BYE
Request-URI: sip:XliteAnumber@publicXliteIP:55838;transport=tcp
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
PSTNGWIP;branch=z9hG4bK5d4.f93633a612aca237ad1f5c341c1b2986.0
Via: SIP/2.0/UDP
PSTNGWIP:5061;branch=z9hG4bK-fat3ctwlimdw3lkb;rport=5061
Route:
Route:
Max-Forwards: 16
From: 00Bnumber
;tag=eihmt4yopie2j4fq.i
To: ;tag=2b8f312e
Call-ID: NGZlMDU3OWE2YjM1ZGQ1OTEyM2NiNmI0YjM1MjA0YTg
CSeq: 515 BYE
Sequence Number: 515
Method: BYE
Contact: Anonymous
User-Agent: Sippy
cisco-GUID: 521708479-278139363-3214082078-3387785402
h323-conf-id: 521708479-278139363-3214082078-3387785402
and that one is the one on the Android one:
Frame 115: 766 bytes on wire (6128 bits), 766 bytes captur
Re: [SR-Users] bad cseq attack
Daniel-Constantin Mierla writes:
> I will comment over the rest of proposed changes once I will check the
> sources.
i guess you have been too busy to check this:
> > in parser/parse_fline.c, i would like to make the first three L_DBG and
> > change the last to L_ERR:
> >
> > LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n",
> > (fl->type==SIP_REPLY)?"reply(status)":"request");
> >
> > LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset );
> > prn=pkg_malloc( offset );
> > if (prn) {
> > for (t=0; t > if (*(buffer+t)) *(prn+t)=*(buffer+t);
> > else *(prn+t)='°';
> > LOG(L_INFO, "ERROR: parsed so far: %.*s\n", offset, ZSW(prn) );
> > pkg_free( prn );
> > };
> > error1:
> > fl->type=SIP_INVALID;
> > LOG(L_INFO, "ERROR:parse_first_line: bad message\n");
> > /* skip line */
> > nl=eat_line(buffer,len);
> > return nl;
one error level message should be enough about the same issue. the
first two are clearly debug related.
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] File transfer using Kamailio
Dear Sir,
Thank you for the response,
And now i am working on XMPP module of kamailio(4.0.2) server along with
Jabberd2 xmpp server (as recommended in XMPP module's README).
I was successful in setting-up Jabberd sever and i can transfer files
through it (using Jitsi's XMPP clients) as a standalone xmpp server.
But the problem is when trying to integrate this jabberd2 server with my
kamailio server.
Problem:
After starting Kamailio sever, Syslog is given the error as follows:
Aug 28 19:45:14 kamailio /usr/local/sbin/kamailio[
19648]: ERROR: xmpp [network.c:110]: net_connect(): resolving
xmpp.example.com failed (Unknown host).
And XMPP related Configuration in Kamailio.cfg is as follows:
# - XMPP -
#!ifdef WITH_XMPP
modparam("xmpp", "backend", "component")
modparam("xmpp", "domain_separator", "*")
modparam("xmpp", "gateway_domain", "192.168.2.41")
modparam("xmpp", "xmpp_domain", "192.168.2.41")
modparam("xmpp", "xmpp_host", "192.168.2.41")
modparam("xmpp", "xmpp_port", 5347)
modparam("xmpp", "xmpp_password", "xmpp")
modparam("xmpp", "outbound_proxy", "sip:192.168.2.41;transport=tcp")
modparam("xmpp", "gwmap", "192.168.2.41")
modparam("presence", "db_url",
"mysql://kamailio:kamailiorw@kamailio/kamailio")
modparam("usrloc", "db_url",
"mysql://kamailio:kamailiorw@kamailio/kamailio")
modparam("pua", "db_url", "mysql://kamailio:kamailiorw@kamailio/kamailio")
modparam("pua", "db_table", "pua")
modparam("presence_xml", "db_url",
"mysql://kamailio:kamailiorw@kamailio/kamailio")
#modparam("presence_xml", "integrated_xcap_server", 1)
modparam("presence", "max_expires", 3600)
modparam("presence", "server_address", "sip:192.168.2.41:5060")
modparam("pua_xmpp", "server_address", "sip:192.168.2.41")
#!endif
#-XMPP
# Presence server route
route[PRESENCE]
#!ifdef WITH_XMPP
# if ($rd =="192.168.2.41") {
if (!t_newtran())
{
sl_reply_error();
exit;
};
};
# if( is_method("NOTIFY") && uri=~"sip:.+@192.168.2.41")
if( is_method("NOTIFY"))
{
xlog("processing NOTIFY...\n");
pua_xmpp_notify();
t_reply("200", "OK");
exit;
}
if(is_method("PUBLISH"))
{
xlog("processing PUBLISH ...\n");
if($hdr(Sender)!= $null)
{
xlog("Sender header found.\n");
}
handle_publish();
t_release();
}
else
if( is_method("SUBSCRIBE"))
{
xlog("processing SUBSCRIBE ...\n");
handle_subscribe();
if( uri=~"sip:.+@192.168.2.41" && $hdr(Event)== "presence")
{
xlog("calling pua_xmpp_req_winfo()\n");
pua_xmpp_req_winfo("$ruri", "$hdr(Expires)");
}
t_release();
}
exit;
#!endif
What could be the wrong with this ?
Both the servers(kamailio and jabberd) are working fine as alone , but the
problem is with Integration.
And regarding File transfer feature in kamailio, is there any other ways to
get through, between two soft clients (either SIP or XMPP)?
Regards,
Nandini
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/File-transfer-using-Kamailio-tp120695p121055.html
Sent from the Users mailing list archive at Nabble.com.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] bad cseq attack
I thought I replied to this, but actually I couldn't find it, maybe I
just had the intention to do it and then got distristracted by something
else -- thanks for the reminder.
The proposed changes are fine with me, they can be committed.
Daniel
On 8/29/13 2:53 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I will comment over the rest of proposed changes once I will check the
sources.
i guess you have been too busy to check this:
in parser/parse_fline.c, i would like to make the first three L_DBG and
change the last to L_ERR:
LOG(L_INFO, "ERROR:parse_first_line: bad %s first line\n",
(fl->type==SIP_REPLY)?"reply(status)":"request");
LOG(L_INFO, "ERROR: at line 0 char %d: \n", offset );
prn=pkg_malloc( offset );
if (prn) {
for (t=0; ttype=SIP_INVALID;
LOG(L_INFO, "ERROR:parse_first_line: bad message\n");
/* skip line */
nl=eat_line(buffer,len);
return nl;
one error level message should be enough about the same issue. the
first two are clearly debug related.
-- juha
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Server silently droping Bye message.
ngrep output is preferred, because expanded wireshark has to much garbage around actuall sip message content. If you have the wireshark capture, then you can export pcap file and then use 'ngrep -qt -W byline -I file.pcap' to get pure text format for sip messages (then replace your ip addresses as needed). Anyhow, for this case the problem resides in the contact header you send out. The alias parameter has to be before the '>' but your subst() moves the '>' after the initial contact uri, leaving the new parameter alias out of URI itself, resulting in being a header parameter. One solution is to do subst() before record_route() in the config and after it execute: msg_apply_changes(); Cheers, Daniel On 8/29/13 3:31 PM, Helena Garcia-Nieto wrote: Sorry I thought I attached the complete trace, I captured it with wireshark on the server machine so I hope it is enough since you can see both sides. Yes I realized the alias is added on the invite from the Kamailio to the PSTN GW: Contact: ;alias=PublicAndroidIP~35986~2 but it is not present on the BYE the PSTNGW send back to kamailio. But kamailio has the information on the database, so I though it may be able to send the message anyway. Thanks Helena -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Loopback
On Thu, Aug 29, 2013 at 3:53 AM, Daniel-Constantin Mierla wrote: > what device is at 701? The 200ok receved from it has the contact address > with the IP of kamailio: > SFLPhone > It seems there is a NAT between your kamailio and 701, as kamailio adds > alias parameter to Contact in 200ok. That can be used to route the ack, > like: > > handle_ruri_alias(); > $ru = $du; > $du = $null; > There is no NAT in this scenario, although NAT support is enabled as we will have to deal with it. Should I still use handle_ruri_alias()? Thanks, Marc ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Server silently droping Bye message.
Thanks! Thank you very very much for your help.
I'll add the ngrep next time!
I'm absolutely new at kamailio and I'm doing the Subs on the main config
file (/usr/local/etc/kamailio/kamailio.cfg) on the PSTN call detection
route[PSTN] {:
if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$"))
return;
# only local users allowed to call
if(from_uri!=myself) {
sl_send_reply("403", "Not Allowed");
exit;
}
if (strempty($sel(cfg_get.pstn.gw_port))) {
$ru = "sip:" + $rU + "@" +
$sel(cfg_get.pstn.gw_ip);
} else {
$ru = "sip:" + $rU + "@" +
$sel(cfg_get.pstn.gw_ip) + ":"
+ $sel(cfg_get.pstn.gw_port);
}
# modifications to acces env5
subst_uri('/^sip:00(.*)/sip:\1/i'); #append delete the 00
subst('/^Contact: (.*)>.*$/Contact: \1>/i');#delete the parameter that is
anoying env5 on contact header
And I cannot find the msg_apply_changes(); part on that file, can you tell
me where I can better do the subs, in which file?
I'm not actually moving the > just droping everything after it.
I'm sure there is a better option to change the contact header, would you
have any suggestion?
Thanks in advanced
Helena
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: jueves, 29 de agosto de 2013 15:49
To: Helena Garcia-Nieto; 'Kamailio (SER) - Users Mailing List'
Subject: Re: [SR-Users] Server silently droping Bye message.
ngrep output is preferred, because expanded wireshark has to much garbage
around actuall sip message content. If you have the wireshark capture, then
you can export pcap file and then use 'ngrep -qt -W byline -I file.pcap' to
get pure text format for sip messages (then replace your ip addresses as
needed).
Anyhow, for this case the problem resides in the contact header you send
out. The alias parameter has to be before the '>' but your subst() moves the
'>' after the initial contact uri, leaving the new parameter alias out of
URI itself, resulting in being a header parameter.
One solution is to do subst() before record_route() in the config and after
it execute:
msg_apply_changes();
Cheers,
Daniel
On 8/29/13 3:31 PM, Helena Garcia-Nieto wrote:
Sorry I thought I attached the complete trace, I captured it with wireshark
on the server machine so I hope it is enough since you can see both sides.
Yes I realized the alias is added on the invite from the Kamailio to the
PSTN GW:
Contact:
;alias=PublicAndroi
dIP~35986~2
but it is not present on the BYE the PSTNGW send back to kamailio.
But kamailio has the information on the database, so I though it may be
able to send the message anyway.
Thanks
Helena
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Loopback
I ended up doing this right before the call to loose_route():
if ((is_method("ACK") || is_method("BYE")) &&
!isdsturiset()) {
handle_ruri_alias();
if ($du != $null) {
$ru = $du;
$du = $null;
}
}
Thanks a lot Daniel!
On Thu, Aug 29, 2013 at 10:58 AM, Marc Soda wrote:
> On Thu, Aug 29, 2013 at 3:53 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>
>> what device is at 701? The 200ok receved from it has the contact address
>> with the IP of kamailio:
>>
>
> SFLPhone
>
>
>> It seems there is a NAT between your kamailio and 701, as kamailio adds
>> alias parameter to Contact in 200ok. That can be used to route the ack,
>> like:
>>
>> handle_ruri_alias();
>> $ru = $du;
>> $du = $null;
>>
>
> There is no NAT in this scenario, although NAT support is enabled as we
> will have to deal with it. Should I still use handle_ruri_alias()?
>
> Thanks,
> Marc
>
--
Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com
1787 Sentry Parkway West, Building 16, Suite 100, Blue Bell, PA 19422
Office: (215) 297-4400 x203 | Fax: (215) 297-4401 | Email:
ms...@coredial.com
- - - - -
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Blind transfer / Agent transfer using Kamaio
Hello, can someone give me some pointers as to how to do a blind transfer / agent transfer using Kamailio. My current set up uses Kamailio to authenticate and register users and Asterisk to do the call handling. Thank you, Arun ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Blind transfer / Agent transfer using Kamaio
Hi Arun, You can find here information about blind transfer: http://www.kamailio.org/dokuwiki/doku.php/old-content:how_to_set_up_blind_call_forwarding_using_21_on_your_phone Regards, Lucas Girard On Thu, 2013-08-29 at 10:32 -0700, arun Jayaprakash wrote: > Hello, can someone give me some pointers as to how to do a blind > transfer / agent transfer using Kamailio. My current set up uses > Kamailio to authenticate and register users and Asterisk to do the > call handling. > > > Thank you, > Arun > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] tls nat
After many failures because of broken libraries I managed to decrypt my problematic TLS sessions providing the private key of kamailio to wireshark. With TLS+SRTP enabled my nokia phones send session progress and pracks with rtp port. This breaks NAT/rtpproxy in kamailio, which replaces the rtpproxy port in session progress, but then forgets about it for the 200 OK. Attached is a tree overview and the conversations of each phone with kamailio. hiro |Time | 192.168.5.86 | 192.168.5.149 | | | | kamailio-ip| |9.737280 | INVITE| | |SIP From: (5061) | | |10.224330| 407 Proxy Authentication Required | |SIP Status | |(51151) <-- (5061) | | |10.245086| ACK | | |SIP Request | |(51151) --> (5061) | | |10.306416| INVITE| | |SIP From: (5061) | | |10.358255| 100 trying -- your call is important to us | |SIP Status | |(51151) <-- (5061) | | |10.363237| | INVITE SDP () |SIP Request | | |(5061) --> (59293) | |10.558970| | 100 Trying| |SIP Status | | |(5061) <-- (59293) | |11.119249| | 183 Session Progress |SIP Status | | |(5061) <-- (59293) | |11.246997| 183 Session Progress SDP () | |SIP Status | |(51151) <-- (5061) | | |11.583092| PRACK | | |SIP Request | |(51151) --> (5061) | | |11.717971| | PRACK SDP () |SIP Request | | |(5061) --> (59293) | |11.940783| | 200 OK| |SIP Status | | |(5061) <-- (59293) | |11.992804| | 180 Ringing |SIP Status | | |(5061) <-- (59293) | |12.005967| 200 OK SDP () | |SIP Status | |(51151) <-- (5061) | | |12.039001| 180 Ringing | |SIP Status | |(51151) <-- (5061) | | |12.052879| SRTP (AMR-WB) | |SRTP Num packets:1 Duration:0.000s SSRC:0x381DBA9F | |(49152) --> (49246) | | |13.363596| | 200 OK| |SIP Status | | |(5061) <-- (59293) | |13.432772| 200 OK| | |SIP Status | |(51151) <-- (5061) | | |13.600600| ACK | | |SIP Request | |(51151) --> (5061) | | |13.675750| | ACK | |SIP Request | | |(5061) --> (59293) | |19.807564| | BYE | |SIP Request | | |(5061) <-- (59293) | |19.876545| BYE | | |SIP Request | |(51151) <-- (5061) | | |20.029472| 200 OK| | |SIP Status | |(51151) --> (5061) | | |20.095618| | 200 OK| |SIP Status | | |(5061) --> (59293) | INVITE sips:fiSWDAVNMudB0W2cxgpS@192.168.5.149:5061 SIP/2.0 Record-Route: Via: SIP/2.0/TLS kamailio-ip:5061;branch=z9hG4bK4a76.f9b14487.0;i=1 Via: SIP/2.0/TLS 192.168.5.86:5061;received=dyn-ip;branch=z9hG4bKa5c6nckkbpgklpom273bgar;rport=38059 From: ;tag=gd8h3hj4m1hc6aa007r8 To: Contact: Supported: precondition,100rel,timer CSeq: 108850 INVITE Call-ID: b6AhNLSnoIfoug7SwYt0O4B6Zj4mFJ Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE User-Agent: Nokia RM-530 091.004 (en) Expires: 120 Privacy: None Session-Expires: 1800 Max-Forwards: 16 Content-Type: application/sdp Accept-Language: en Content-Length: 695 v=0 o=8 63546
