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