sr-users October 2009

sr-users@lists.kamailio.org

63 participants
105 discussions

[Kamailio-Users] keep tos value from incoming SIP message

by kévin l'heveder

Hi all, I found out how to set the tos value in a outgoing SIP message with the tos parameter from core-cookbook. But my issue is to forward an incoming SIP message keeping the tos value unchange. Is there already a way to do that, something already implemented? Or is there a way to get the tos value from incoming message and dynamically change the tos parameter? Regards,

15 years, 1 month

[Kamailio-Users] using a proxy and a registrar(only) server to make a cal

by Rajesh

Dear All, I would like to establish a set up where i have two servers, one acting as a proxy and the other acting as a registrar server(only). Client A ---->Proxy--->Registrar. I am able to register using the above mentioned set up, but am unable to make call.. i get "timed out error" when i try calling. am ataching my cfg below.Any help is greatly appreciated. (My proxy server wil not do registration and my registrar server wil only do registration) ####### Global Parameters ######### debug=3 log_stderror=yes log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the following lines to enable debugging */ #debug=6 #fork=no #log_stderror=yes /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment the following lines to enable TLS support (default off) */ #disable_tls = no #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "/usr/local/etc/kamailio/tls/user/user-cert.pem" #tls_private_key = "/usr/local/etc/kamailio/tls/user/user-privkey.pem" #tls_ca_list = "/usr/local/etc/kamailio/tls/user/user-calist.pem" port=5060 /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ #listen=udp:192.168.1.2:5060 ####### Modules Section ######## #set module path mpath="/usr/local/lib/kamailio/modules/" /* uncomment next line for MySQL DB support */ loadmodule "db_mysql.so" loadmodule "mi_fifo.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "uri_db.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "imc.so" /* uncomment next lines for MySQL based authentication support NOTE: a DB (like db_mysql) module must be also loaded */ loadmodule "auth.so" loadmodule "auth_db.so" /* uncomment next line for aliases support NOTE: a DB (like db_mysql) module must be also loaded */ #loadmodule "alias_db.so" /* uncomment next line for multi-domain support NOTE: a DB (like db_mysql) module must be also loaded NOTE: be sure and enable multi-domain support in all used modules (see "multi-module params" section ) */ #loadmodule "domain.so" /* uncomment the next two lines for presence server support NOTE: a DB (like db_mysql) module must be also loaded */ #p#loadmodule "presence.so" #p#loadmodule "presence_xml.so" #n#loadmodule "nathelper.so" # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- rr params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- uri_db params ----- /* by default we disable the DB support in the module as we do not need it in this configuration */ modparam("uri_db", "use_uri_table", 0) modparam("uri_db", "db_url", "") # ----- acc params ----- /* what sepcial events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") /* uncomment the following lines to enable DB accounting also */ #c#modparam("acc", "db_flag", 1) #c#modparam("acc", "db_missed_flag", 2) #c#modparam("acc", "db_url", #c# "mysql://openser:openserrw@localhost/openser") #c#modparam("acc", "db_extra", #c# "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") # ----- usrloc params ----- /* uncomment the following lines if you want to enable DB persistency for location entries */ modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "mysql://openser:openserrw@localhost/openser") # ----- auth_db params ----- /* uncomment the following lines if you want to enable the DB based authentication */ modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("auth_db", "load_credentials", "") # ----- alias_db params ----- /* uncomment the following lines if you want to enable the DB based aliases */ #modparam("alias_db", "db_url", # "mysql://openser:openserrw@localhost/openser") # ----- domain params ----- /* uncomment the following lines to enable multi-domain detection support */ #modparam("domain", "db_url", # "mysql://openser:openserrw@localhost/openser") #modparam("domain", "db_mode", 1) # Use caching # ----- multi-module params ----- /* uncomment the following line if you want to enable multi-domain support in the modules (dafault off) */ #modparam("alias_db|auth_db|usrloc|uri_db", "use_domain", 1) # ----- presence params ----- /* uncomment the following lines if you want to enable presence */ #p#modparam("presence|presence_xml", "db_url", #p# "mysql://openser:openserrw@localhost/openser") #p#modparam("presence_xml", "force_active", 1) #p#modparam("presence", "server_address", "sip:192.168.1.2:5060") # -- nathelper #n#modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7722") #n#modparam("nathelper", "natping_interval", 30) #n#modparam("nathelper", "ping_nated_only", 1) #n#modparam("nathelper", "sipping_bflag", 7) #n#modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") #n#modparam("registrar|nathelper", "received_avp", "$avp(i:80)") #-------tm params----- modparam("tm", "fr_timer", 10 ) modparam("tm", "fr_inv_timer", 15 ) modparam("tm", "wt_timer", 10 ) #-------imc params----- modparam("imc", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("imc", "hash_size", 8) modparam("imc", "imc_cmd_start_char", "#") #modparam("imc", "imc_cmd_start_char", "#") #n#modparam("usrloc", "nat_bflag", 6) ####### Routing Logic ######## # main request routing logic route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } # NAT detection route(4); if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(1); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(2); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard.\n"); exit; } } sl_send_reply("404","Not here"); } exit; } #initial requests # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authentication xlog("__The next step is Registration__\n"); rewritehost("192.168.64.77"); xlog("__Registration Successful__\n"); #nr route(3); # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting } if (!uri==myself) /* replace with following line if multi-domain support is used */ ##if (!is_uri_host_local()) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ##if($rd=="tls_domain1.net") { ## t_relay("tls:domain1.net"); ## exit; ##} else if($rd=="tls_domain2.net") { ## t_relay("tls:domain2.net"); ## exit; ##} route(1); } # requests for my domain #nr if( is_method("PUBLISH|SUBSCRIBE")) #nr route(2); #nr if (is_method("REGISTER")) #nr { #nr if (!save("location")) #nr sl_reply_error(); #nr exit; #nr } ########## if(uri=~"sip:q.*@") # if(uri=~"sip:q@192.168.64.75") { # IMC - message xdbg("script: message from [$fu] r-uri [$ru] msg [$rb]\n"); if(is_method("MESSAGE")) { log("MESSAGE received -> processing with imc\n"); sl_send_reply("200", "ok"); imc_manager(); exit; } else { sl_send_reply("404", "not found"); exit; }; } else { xdbg("script: message not for room, from [$fu] r-uri [$ru] msg [$rb]\n"); if(!lookup("location")) { sl_send_reply("404", "not found"); exit; } t_relay(); #sl_send_reply("200", "ok"); exit(); }; if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # apply DB based aliases (uncomment to enable) ##alias_db_lookup("dbaliases"); if (!lookup("location")) { switch ($retcode) { case -1: case -3: t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also setflag(2); route(1); } route[1] { #n# if (check_route_param("nat=yes")) { #n# setbflag(6); #n# } #n# if (isflagset(5) || isbflagset(6)) { #n# route(5); #n# } /* example how to enable some additional event routes */ if (is_method("INVITE")) { #t_on_branch("1"); t_on_reply("1"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); } exit; } # Presence route /* uncomment the whole following route for enabling presence server */ route[2] { #p# if (!t_newtran()) #p# { #p# sl_reply_error(); #p# exit; #p# }; #p# #p# if(is_method("PUBLISH")) #p# { #p# handle_publish(); #p# t_release(); #p# } #p# else #p# if( is_method("SUBSCRIBE")) #p# { #p# handle_subscribe(); #p# t_release(); #p# } #p# exit; # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route /* uncomment the whole following route for enabling authentication */ route[3] { if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("192.168.64.75", "subscriber")) { www_challenge("192.168.64.75", "0"); exit; } if ($au!=$tU) { sl_send_reply("403","Forbidden auth ID"); exit; } } else { # authenticate if from local subscriber (uncomment to enable auth) if (from_uri==myself) { #imc#if (!proxy_authorize("", "subscriber")) { #imc#proxy_challenge("", "0"); #imc#exit; #imc#} #imc#if (is_method("PUBLISH")) #imc#{ #imc# if ($au!=$tU) { #imc# sl_send_reply("403","Forbidden auth ID"); #imc# exit; #imc# } #imc#} else { #imc# if ($au!=$fU) { #imc# sl_send_reply("403","Forbidden auth ID"); #imc# exit; #imc# } #imc#} #imc# consume_credentials(); # caller authenticated } } return; } # Caller NAT detection route /* uncomment the whole following route for enabling Caller NAT Detection */ route[4]{ #n# force_rport(); #n# if (nat_uac_test("19")) { #n# if (method=="REGISTER") { #n# fix_nated_register(); #n# } else { #n# fix_nated_contact(); #n# } #n# setflag(5); #n# } return; } # RTPProxy control /* uncomment the whole following route for enabling RTPProxy Control */ route[5] { #n# if (is_method("BYE")) { #n# unforce_rtp_proxy(); #n# } else if (is_method("INVITE")){ #n# force_rtp_proxy(); #n# } #n# if (!has_totag()) add_rr_param(";nat=yes"); return; } branch_route[1] { xdbg("new branch at $ru\n"); } onreply_route[1] { xdbg("incoming reply\n"); #n# if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { #n# force_rtp_proxy(); #n# } #n# if (isbflagset(6)) { #n# fix_nated_contact(); #n# } } failure_route[1] { #n# if (is_method("INVITE") #n# && (isbflagset(6) || isflagset(5))) { #n# unforce_rtp_proxy(); #n# } if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} # uncomment the following lines if you want to redirect the failed # calls to a different new destination ##if (t_check_status("486|408")) { ## sethostport("192.168.2.100:5060"); ## append_branch(); ## # do not set the missed call flag again ## t_relay(); ##} } -- Regards, Rajesh

15 years, 1 month

Re: [Kamailio-Users] SIP-T: Multipart SDPs, ISUP parsing, etc

by Henning Westerholt

On Montag, 12. Oktober 2009, mashudi wrote: > Hi Henning Westerholt , > did you ever handle SIP-T using Kamailio? > could you share it? Hi Mashudi, sorry, i did not handled SIP-T so far with openser/kamailio. Regards, Henning > > On Friday 13 February 2009, Ovidiu Sas wrote: > >> The multipart body content parsing is embedded in the sdp parser. > >> The sdp parser is available in the source tree under the ./parser/sdp > >> directory. > > > > There is also some documentation about the parser on our wiki: > > > > http://www.kamailio.org/dokuwiki/doku.php/development:sdp-parsing > > > > Cheers, > > > > Henning > > > > _______________________________________________ > > Kamailio (OpenSER) - Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > > > > ***************************************** > > Sekarang Gratis Nelpon SLJJ Flexi diperluas ke > > Yogya > > ***************************************** > > ================================= > Mau GRATIS TELPON LOKAL, DISCOUNT 50% SMS, > DISCOUNT 20% SLJJ, dan DISCOUNT FLEXI MILIS? > Ikuti Dahsyatnya FLEXI KOMUNITAS. > Ketik CREATE<spasi>[NAMA GRUP], sms ke 345. > Contoh: CREATE SMU2, sms ke 345. > Informasi selanjutnya : > - hubungi 147 > - http://www.telkomflexi.com > - ketik INFO, sms ke 345 > > > ================================= > This Email has been scanned : Anti Virus > =================================

15 years, 1 month

[Kamailio-Users] Sip-T

by ljjimenez＠gmail.com

Hi list, can somebody guide on how to read, if it is possible, application/isup payload sent using SIP-T to do routing decisions based of the contents. Thanks in advance Luis Jimenez Luis Jimenez

15 years, 1 month

[Serusers] Via: branch tags for CANCELs sometimes don't match the one in the INVITE

by Frank Durda IV

I have been tracking a problem for some time regarding CANCELs that the switch beyond SER was randomly ignoring. There appear to be a number of issues, but one that was identified is caused by SER unexpectedly emitting a branch tag on the Via: header of the CANCEL with a value that isn't identical to the value that appeared in the INVITE message. When the CANCEL arrives at the destination switch with a different branch tag than what was shown in the INVITE, the destination switch correctly rejects the CANCEL with a 481, saying it never heard of this call. So the call doesn't really end. They say they are following RFC 3261, and that does state that the Via: header MUST exactly match. This variance of the branch tag that SER emits doesn't happen every time and is infrequent and random, occurring, perhaps 1% of the time. 99% of the time, the same branch value appears in both INVITE and CANCEL messages. This occasional mismatch is being seen in 2.0.0-rc1 on FreeBSD, Server: SER (2.0.0-rc1 (x86_64/freebsd)) syn_branch=0 is set because branches of zero in ACKs were a really bad thing too. Based on a number of these that have been reviewed, the branch tag generated by SER has three parts, eg branch=STRING1.STRING2.0 I note that STRING1 remains the same but when the malfunction occurs, STRING2 is completely different, as in: FROM INVITE branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c11079.0 FROM CANCEL branch=z9hG4bK7314.b4c66001f96f5dd30ddbf6536fd34935.0 Below is a sample call showing one of these events. Any suggestions on what the problem might be or if this is a known bug (hopefully with a patch) are appreciated. - - - - - - - - - - - - - - - - - - Here is a sample call. IP addresses and phone numbers have been altered, but call ID and branch tags are untouched: CALL ARRIVES AT SER U 2009/10/05 23:00:45.616070 216.0.0.1:5060 -> 208.9.10.11:5060 INVITE sip:9615551212@208.9.10.11:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C P-Asserted-Identity: <sip:8881112222@216.0.0.1:5060> To: sip:9615551212@208.9.10.11:5060 Contact: <sip:8881112222@216.0.0.1:5060> Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE Max-Forwards: 70 Content-Length: 281 Allow: INVITE, ACK, CANCEL, BYE Content-Type: application/sdp Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 v=0 o=SIPUAC_1.92.1.8 2077471748 1 IN IP4 55.66.77.88 s=call c=IN IP4 55.66.77.88 t=0 0 m=audio 21356 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:30 SER SENDS TRYING BACK TO CALLING SWITCH U 2009/10/05 23:00:45.626174 208.9.10.11:5060 -> 216.0.0.1:5060 SIP/2.0 100 trying -- your call is important to us From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: sip:9615551212@208.9.10.11:5060 Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: SER (2.0.0-rc1 (x86_64/freebsd)) Content-Length: 0 SER SENDS CALL ON TO PSTN SWITCH U 2009/10/05 23:00:45.626192 10.100.20.42:5060 -> 10.133.44.55:5060 INVITE sip:9615551212@10.133.44.55:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C P-Asserted-Identity: <sip:8881112222@216.0.0.1:5060> To: sip:9615551212@208.9.10.11:5060 Contact: <sip:8881112222@216.0.0.1:5060> Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE Max-Forwards: 16 Content-Length: 301 Allow: INVITE, ACK, CANCEL, BYE Content-Type: application/sdp Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c1107 9.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 v=0 o=SIPUAC_1.92.1.8 2077471748 1 IN IP4 55.66.77.88 s=call c=IN IP4 55.66.77.88 t=0 0 m=audio 55878 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:30 a=nortpproxy:yes CALLING SWITCH TELLS SER IT IS TRYING U 2009/10/05 23:00:45.629000 10.133.44.55:5060 -> 10.100.20.42:5060 SIP/2.0 100 Trying Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c1107 9.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Content-Length: 0 CALLING PARTY CHANGES MIND - GOES ON-HOOK U 2009/10/05 23:00:50.579059 216.0.0.1:5060 -> 208.9.10.11:5060 CANCEL sip:9615551212@208.9.10.11:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060> Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 CANCEL Max-Forwards: 70 Content-Length: 0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 SER SENDS CANCEL TO PSTN SWITCH, BUT BRANCH TAGS DON'T MATCH: U 2009/10/05 23:00:50.590039 10.100.20.42:5060 -> 10.133.44.55:5060 CANCEL sip:9615551212@10.133.44.55:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060> Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 CANCEL Max-Forwards: 16 Content-Length: 0 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.b4c66001f96f5dd30ddbf6536fd3493 5.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 NOTE BRANCH MISMATCH: FROM INVITE branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c11079.0 FROM CANCEL branch=z9hG4bK7314.b4c66001f96f5dd30ddbf6536fd34935.0 SER SENDS 200 CANCELING BACK TO CALLING SWITCH U 2009/10/05 23:00:50.590054 208.9.10.11:5060 -> 216.0.0.1:5060 SIP/2.0 200 canceling From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=68cf7f6b22161b0d4dc719dbc13e05af-90a6 Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 CANCEL Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: SER (2.0.0-rc1 (x86_64/freebsd)) Content-Length: 0 PSTN SWITCH REJECTS CANCEL, NOT RECOGNIZING THE CALL PSTN NETWORK CONTINUES TO PROCESS CALL DESPITE CALLER NOW BEING ON-HOOK U 2009/10/05 23:00:50.591489 10.133.44.55:5060 -> 10.100.20.42:5060 SIP/2.0 481 Call/Transaction Does Not Exist Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 CANCEL From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+0+b6afb3ac Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.b4c66001f96f5dd30ddbf6536fd3493 5.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Content-Length: 0 PSTN SWITCH SENDS BACK ACM/183 Session Progress TO SER U 2009/10/05 23:00:52.619487 10.133.44.55:5060 -> 10.100.20.42:5060 SIP/2.0 183 Session Progress Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c1107 9.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@10.133.44.55:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no SER SENDS 183 SESSION PROGRESS BACK TO CALLING SWITCH U 2009/10/05 23:00:52.629924 208.9.10.11:5060 -> 216.0.0.1:5060 SIP/2.0 183 Session Progress Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@208.9.10.11:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no SER RECEIVES 200 OK FROM PSTN SWITCH U 2009/10/05 23:00:58.129670 10.133.44.55:5060 -> 10.100.20.42:5060 SIP/2.0 200 OK Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c1107 9.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@10.133.44.55:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no SER PASSES 200 OK ON TO CALLING SWITCH U 2009/10/05 23:00:58.137724 208.9.10.11:5060 -> 216.0.0.1:5060 SIP/2.0 200 OK Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@208.9.10.11:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no BECAUSE OF NO RESPONSE TO 200 OK, PSTN SWITCH SENDS IT AGAIN U 2009/10/05 23:00:58.629267 10.133.44.55:5060 -> 10.100.20.42:5060 SIP/2.0 200 OK Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.6082c3659eb65543a8e2788f54c1107 9.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@10.133.44.55:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no U 2009/10/05 23:00:58.639701 208.9.10.11:5060 -> 216.0.0.1:5060 SIP/2.0 200 OK Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 INVITE From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_1 Server: DC-SIP/2.0 Contact: <sip:9615551212@208.9.10.11:5060;user=phone> Content-Type: application/sdp Content-Length: 223 v=0 o=- 3463772452 3463772517 IN IP4 10.133.44.55 s=- c=IN IP4 10.200.20.40 t=0 0 m=audio 50924 RTP/AVP 18 101 a=sendrecv a=ptime:20 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=fmtp:18 annexb=no CALLING SWITCH FINALLY SENDS AN ACK TO SER TO GET RETRIES TO STOP. U 2009/10/05 23:00:58.690296 216.0.0.1:5060 -> 208.9.10.11:5060 ACK sip:9615551212@208.9.10.11:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 ACK Max-Forwards: 70 Content-Length: 0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_2 SER FORWARDS ACK TO PSTN SWITCH. PSTN NETWORK THINKS CALL IS ALIVE, VOIP NETWORK KNOWS CALL IS DEAD. U 2009/10/05 23:00:58.690355 10.100.20.42:5060 -> 10.133.44.55:5060 ACK sip:9615551212@10.133.44.55:5060;user=phone SIP/2.0 From: <sip:8881112222@216.0.0.1:5060>;tag=2077471748_C To: <sip:9615551212@208.9.10.11:5060>;tag=000a0285+1+21a4018b+2cd8ce96 Call-ID: sbcsipuac.2_11.22.33.44_b09sb07_1_2009100519004555_2077471748_716911 CSeq: 1005 ACK Max-Forwards: 16 Content-Length: 0 Via: SIP/2.0/UDP 10.100.20.42;branch=z9hG4bK7314.1fc8626bef702f1428ad6fd4fd2aa7a f.0 Via: SIP/2.0/UDP 216.0.0.1:5060;branch=z9hG4bK_2077471748_2110_2 .... So the called party has answered the call and can't hear anything. Depending on whether a human or automation was called, this call could remain active on the PSTN for some time.

15 years, 1 month

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?

by Henning Westerholt

On Montag, 12. Oktober 2009, Vibhor Singhal wrote: > Please find attached the text file that contains the error that I encounter > while installing Kamailio.I could not get any solution for this.Please > guide me how to resolve this problem. Hi Vibhor, just paste the error message in the mail, its easier then this office document.. You need to install the correct mysql development libraries to be able to compile the db_mysql module. For debian you'll find the package names in the documents in the wiki i posted to you i think. And i'd suggest that you use the latest stable version of kamailio "1.5.2" instead of 1.5.0. This way you'll not run into bugs that were already fixed. Regards, Henning

15 years, 1 month

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?

by Henning Westerholt

On Montag, 12. Oktober 2009, Vibhor Singhal wrote: > Thanks for the information. Can you please refer any forum or document that > can guide me on how to make Kamailio as Asterisk's frontend. Hi Vibhor, please CC always to the user list. Just use the search machine of your choice. ;) Here are some example posts with more information: http://www.voip-info.org/wiki/view/Asterisk+at+large http://www.kamailio.org/pipermail/users/2008-February/016181.html http://www.nabble.com/Load-Balancing-Asterisk-using-Kamailio-td23250215.html > And in Kamailio's SIP_trace module, will I get SIP message in the raw form > as mentioned below: Hm, never used this module, but i think it will store the messages in the database. But you could modfiy the module, its open source after all.. Regards, Henning

15 years, 1 month

[Kamailio-Users] Retransmitted SUBSCRIBEs

by catalina oancea

Hello, If a phone re-sends a presence SUBSCRIBE requests even after 5 or 500 milliseconds, kamailio replied with '400 Bad request' to the second SUBSCRIBE The scenario is: Phone Kamailio SUBSCRIBE ----------> 401 <---------- SUBSCRIBE ----------> 202 <---------- Pause [ 5ms] (or 500 ms, the same thing happens) SUBSCRIBE ----------> (previous SUBSCRIBE retransmitted) 400 Bad request <---------- Is this the expected behavior? Is there any way to get kamailio to recognize the retransmission? This causes problems with Snom phones because they receive 400 reply when they retransmit the SUBSCRIBE, and presence stops working. Thanks Catalina

15 years, 1 month

[Kamailio-Users] off-topic :: empty user part of Contact header

by kokoska rokoska

Hello, I have a little bit off-topic question, but - may be - someone could give me an advice :-) One of our users, when replying to INVITE, sends in 200 OK Contact header without user part: SIP/2.0 200 OK CSeq: 102 INVITE Contact: <sip:1.2.3.4:1234> ... instead of: SIP/2.0 200 OK CSeq: 102 INVITE Contact: <sip:user@1.2.3.4:1234> ... and it fools our SIP<->ISUP GW and it generates completely strange R-URI in ACK :-( My questions are: 1. Is it valid Contact (without user part)? 2. What SIP<->ISUP GW should do (mirror Contact without user part to R-URI in ACK, reject/drop 200 OK etc.)? May be I can ask them to change behaviour... 3. What should do our proxy (drop 200 OK, using htable try to repair R-URI in ACK or Contact in 200 OK etc.)? 4. ??? Any suggestion is very appreciated :-) Best regards, kokoska.rokoska

15 years, 1 month

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?

by Henning Westerholt

On Freitag, 9. Oktober 2009, Vibhor Singhal wrote: > We are developing CTI applications where we need SIP data from PBX such as > SourceIP,Username,Destination IP,TAG,VIA,Contact,CALL-ID,C-Sequence etc for > each of the SIP packets such as REGISTER,BYE,INVITE,ACK,SUBSCRIBE,NOTIFY > etc. > > e.g Wrieshark displays SIP packets for activities going on SIP port in the > below mentioned format: > [..] > > For this we are trying Kamailio as Asterisk frontend.Plz tell us about the > installation process and how to make kamailio as asterisk's fromtend Hallo Vibhor, for installation of kamailio take a look to the wiki, for example at: http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-1.5.x-from-svn In the "installation" section there are also some more informations: http://www.kamailio.org:80/dokuwiki/doku.php How to use kamailio as a frontend to asterisk has been discussed a lot on this list in the past, the easiest way is probably use the "dispatcher" module. Take a look to the docs for this module for more informations. Best regards, Henning

15 years, 1 month

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2009