sr-dev November 2009

sr-dev@lists.kamailio.org

30 participants
177 discussions

gethostbyname() usage in resolving hostname
by marius zbihlei 26 Nov '09

26 Nov '09

Hello, I have seen that sip-router (and also kamailio) uses the old gethostbyname()/gethostbyname2() (for IPv6) method of resolving hostnames. These calls have been deprecated according to the POSIX 2001 standard these calls are obsolete: Quote from the gethostbyname manpage "POSIX.1-2001 marks *gethostbyaddr*() and *gethostbyname*() obsolescent. See *getaddrinfo <http://linux.die.net/man/3/getaddrinfo>*(3), *getnameinfo <http://linux.die.net/man/3/getnameinfo>*(3), *gai_strerror <http://linux.die.net/man/3/gai_strerror>*(3). " (http://linux.die.net/man/3/gethostbyname) How about changing these calls to the new and improved API(getaddrinfo)? Some benefits of using the getaddrinfo API: 1. Thread safe calls (also async-sig-safe) 2. IPv4/IPv6 compliant 3. Order or returned addresses conforming to RFC 3484 (private network address returned first) (http://udrepper.livejournal.com/16116.html) For a more complete description of the differences , I point to Urlich Drepper's excelent article: http://people.redhat.com/drepper/userapi-ipv6.html Any benefits from using these calls? Any problems from removing the old calls? Cheers, Marius

2 1

[ openser-Bugs-2903162 ] we don't follow the RFC
by SourceForge.net 26 Nov '09

26 Nov '09

Bugs item #2903162, was opened at 2009-11-24 16:09 Message generated for change (Comment added) made by klaus_darilion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Francois () >Assigned to: Klaus Darilion (klaus_darilion) Summary: we don't follow the RFC Initial Comment: Hello all, As I could see in the source, we don’t follow the RFCs. If I send an INVITE, kamailio response a “Giving a try” It isn’t in the RFCs! It is normaly “Trying”. I could change it in -src/modules/tm/t_funcs.c -line: static str relay_reason_100 = str_init("Giving a try"); I hope you understand what I mean ---------------------------------------------------------------------- >Comment By: Klaus Darilion (klaus_darilion) Date: 2009-11-26 13:07 Message: btw: upt to Kamailio 1.5 you could send the 100 response manually (with arbitrary reason phrase) and use a flag in t_Relay to not generate a 100 response. ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2009-11-26 13:05 Message: Hi! The RFC only defines the reason code (100), but not the phrase (Trying). Btw, the default can be changed using a tm module parameter: http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#a… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_…

1 0

[ openser-Bugs-2903162 ] we don't follow the RFC
by SourceForge.net 26 Nov '09

26 Nov '09

Bugs item #2903162, was opened at 2009-11-24 16:09 Message generated for change (Comment added) made by klaus_darilion You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Francois () Assigned to: Nobody/Anonymous (nobody) Summary: we don't follow the RFC Initial Comment: Hello all, As I could see in the source, we don’t follow the RFCs. If I send an INVITE, kamailio response a “Giving a try” It isn’t in the RFCs! It is normaly “Trying”. I could change it in -src/modules/tm/t_funcs.c -line: static str relay_reason_100 = str_init("Giving a try"); I hope you understand what I mean ---------------------------------------------------------------------- >Comment By: Klaus Darilion (klaus_darilion) Date: 2009-11-26 13:05 Message: Hi! The RFC only defines the reason code (100), but not the phrase (Trying). Btw, the default can be changed using a tm module parameter: http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#a… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_…

1 0

git:kamailio_3.0: tm: fix for dialog(k) module workaround
by Daniel-Constantin Mierla 25 Nov '09

25 Nov '09

Module: sip-router Branch: kamailio_3.0 Commit: 0cab381fc93e53ca039ddbfa8ae6546fa14be066 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0cab381… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Nov 25 18:21:22 2009 +0100 tm: fix for dialog(k) module workaround - check if types!=TMCB_MAX if callback registration checks - TMCB_MAX is used to store pointer to dialog in order to clean it quickly --- modules/tm/t_hooks.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/tm/t_hooks.c b/modules/tm/t_hooks.c index ceb3c24..3b8931b 100644 --- a/modules/tm/t_hooks.c +++ b/modules/tm/t_hooks.c @@ -184,14 +184,14 @@ int register_tmcb( struct sip_msg* p_msg, struct cell *t, int types, return E_BUG; } - if (types&TMCB_REQUEST_IN) { + if ((types!=TMCB_MAX) && (types&TMCB_REQUEST_IN)) { if (types!=TMCB_REQUEST_IN) { LOG(L_CRIT, "BUG:tm:register_tmcb: callback type TMCB_REQUEST_IN " "can't be register along with types\n"); return E_BUG; } cb_list = req_in_tmcb_hl; - }else if (types & TMCB_LOCAL_REQUEST_IN) { + }else if ((types!=TMCB_MAX) && (types & TMCB_LOCAL_REQUEST_IN)) { if (types!=TMCB_LOCAL_REQUEST_IN) { LOG(L_CRIT, "BUG:tm:register_tmcb: callback type" " TMCB_LOCAL_REQUEST_IN can't be register along with"

1 0

CVS:commitlog: sip_router/modules/iptrtpproxy/examples ser-oob-rtpproxy.cfg.patch
by Tomas Mandys 25 Nov '09

25 Nov '09

tma0 2009/11/25 12:47:12 CET SER CVS Repository Added files: modules/iptrtpproxy/examples ser-oob-rtpproxy.cfg.patch Log: -patch to ser-oob.cfg fro iptrtpproxy support Revision Changes Path 1.1 +419 -0 sip_router/modules/iptrtpproxy/examples/ser-oob-rtpproxy.cfg.patch (new) http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/iptrtpprox…

1 0

CVS:commitlog: sip_router/etc ser-oob.cfg
by Tomas Mandys 25 Nov '09

25 Nov '09

tma0 2009/11/25 12:41:00 CET SER CVS Repository Modified files: etc ser-oob.cfg Log: - simple dialog_id support Revision Changes Path 1.47 +10 -2 sip_router/etc/ser-oob.cfg http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg.di…

1 0

[ openser-Bugs-2903162 ] we don't follow the RFC
by SourceForge.net 24 Nov '09

24 Nov '09

Bugs item #2903162, was opened at 2009-11-24 16:09 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Francois () Assigned to: Nobody/Anonymous (nobody) Summary: we don't follow the RFC Initial Comment: Hello all, As I could see in the source, we don’t follow the RFCs. If I send an INVITE, kamailio response a “Giving a try” It isn’t in the RFCs! It is normaly “Trying”. I could change it in -src/modules/tm/t_funcs.c -line: static str relay_reason_100 = str_init("Giving a try"); I hope you understand what I mean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2903162&group_…

1 0

unsubscibe
by Jim 21 Nov '09

21 Nov '09

1 0

recursive calls to failure_route strange behavior
by Andres Moya 20 Nov '09

20 Nov '09

Dear all! Please help. I have problem dealing with recursive call in failure route. this route happen first time for authentication to external SIP provider (react on code 401), then it have response 480 i want to direct traffic to another operator via cr_route. First i relay INVITE and getting 401, then sending authentication, but provider gives 480. I can see it in a dump of SIP session. But my failure_route still thinking that reply code is 401 on second reply. Maybe because i dont understand well how branches concept work here? Or using kamailio 3.0? ;) Looks like it give me status code of first reply and ignoring actual code in reply. :( I don't know if it something with development version or my own misunderstanding. sorry route[PSTN_RELAY] { # open trans or it will complain on uac_replace_from if (!t_check_trans()) t_newtran(); #!ifdef WITH_NAT if (check_route_param("nat=yes")) { setbflag("6"); } if (isflagset(5) || isbflagset("6")) { route(RTPPROXY); } #!endif cr_user_carrier("$fU", "$fd", "$avp(s:carrier)"); xlog ("L_INFO","carrier $avp(s:carrier) selected for $fU at $fd\n"); $avp(s:domain)="route_domain1"; if( !cr_route("$avp(s:carrier)", "$avp(s:domain)", "$rU", "$rU", "call_id") ){ sl_send_reply("403", "Not allowed"); xlog ("cr_route failed for $rU from $fU@$fd\n"); t_release(); exit; } #loading auth information for $rd (ruri domain) and replace "From" header route (LOAD_AUTH); xlog ("L_INFO","relaying to $rd\n"); #reducing size to fit MTU remove_hf("User-Agent"); remove_hf("P-Preferred-Identity"); remove_hf("Record-route"); remove_hf("a=nortpproxy"); # setflag(11); # so failroute can procees carrierroute backup # we do all in one failure block; t_on_failure("FAIL_ONE"); if (!t_relay()) { sl_reply_error(); } exit; } ##### LOAD_AUTH ########## # loading authentication information from carrierauth table # set From field according to carrierauth information # arguments: # $rd - request uri doamin, sip provider carrier # returns: # avp(i:20) - rewrited host = $rd # avp(i:21) - auth user # avp(i:22) - auth pass # avp(i:23) - auth realm # avp(i:24) - auth domain route[LOAD_AUTH]{ xlog ("L_INFO","searching authentication for $rd host"); $avp(i:20)=$rd; if ( avp_db_query( "SELECT username, password, realm, domain FROM carrierauth WHERE hostname='$rd'", "$avp(i:21);$avp(i:22);$avp(i:23);$avp(i:24)") > 0 ) { xlog ("L_INFO"," for $rd got user: $avp(i:21) pass: $avp(i:22) realm: $avp(i:23) domain: $avp(i:24)"); # replace from_user@from_domain xlog("L_INFO","changing from -> sip:$avp(i:21)@$avp(i:24)"); uac_replace_from("sip:$avp(i:21)@$avp(i:24)"); } # we are not relaying authentications :) remove_hf("Authorization"); # remove client authentication # reset flag to mark no authentication yet performed resetflag(10); # let's use 10 to know uac authentication was sent return(1); } failure_route[FAIL_ONE] { xlog("L_INFO","failure reply: $T_rpl($rr) $T_rpl($rs) $T_reply_code $branch(count) $rb\n"); ####### ####### Here is a problem. Error code $T_reply_code is always 401 even for second time... I have 480 on ngrep ####### if ( t_check_status("401|407") ) # Unathorised reply { xlog("Authentication required \n"); # have we already tried to authenticate? do we have auth information loaded? if (isflagset(10) || $avp(i:21)==$null ) # auth was already sent or we don't have auth info { xlog("Authentication to $avp(i:20) provider as $avp(i:21)@$avp(i:24) failed\n"); t_reply("503","Authentication failed"); avp_delete("$avp(i:20)"); avp_delete("$avp(i:21)"); avp_delete("$avp(i:22)"); avp_delete("$avp(i:23)"); avp_delete("$avp(i:24)"); exit(); # :( } # if call from here LOAD_AUTH will look for original uri, not rewriten before if( !is_avp_set("$avp(i:20)") || $avp(i:20)=='') # if LAOD_AUTH was not done yet route (LOAD_AUTH); # loads auth avps and rewrite 'from' field # this avps loaded before by LOAD_AUTH # avp(i:20) - rewrited host # avp(i:21) - auth user # avp(i:22) - auth pass # avp(i:23) - auth realm # avp(i:24) - auth domain remove_hf("Authorization"); # remove client authentication if (uac_auth()) # adding auth header { xlog("L_INFO","Authorization header set, sending..."); # mark that auth was performed setflag(10); # trigger again the failure route t_on_failure("FAIL_ONE"); # repeat the request with auth response this time append_branch(); # ? t_relay(); exit; } } # In case of failure on PSTN provider, send it to an alternative route: if ( t_check_status("408|5[0-9][0-9]")) { # if ( isflagset(11) && t_check_status("408|5[0-9][0-9]")) { revert_uri(); if (!cr_next_domain("$avp(s:carrier)", "$avp(s:domain)", "$rU", "$rd", "$T_reply_code", "$avp(s:domain)")) { xlog("L_ERR", "cr_next_domain failed\n"); exit; } if (!cr_route("$avp(s:carrier)", "$avp(s:domain)", "$rU", "$rU", "call_id")) { xlog("L_ERR", "cr_route failed\n"); exit; } route(LOAD_AUTH); t_on_failure("FAIL_ONE"); append_branch(); if (!t_relay()) { xlog("L_ERR", "t_relay to $rd failed\n"); exit; } } #!ifdef WITH_NAT if (is_method("INVITE") && (isbflagset("6") || isflagset(5))) { unforce_rtp_proxy(); } #!endif if (t_is_canceled()) { 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(); ##} }

4 10

SF.net SVN: openser:[5957] branches/1.5/modules/tm/t_hooks.h
by Marius Zbihlei 20 Nov '09

20 Nov '09

Revision: 5957 http://openser.svn.sourceforge.net/openser/?rev=5957&view=rev Author: mariuszbihlei Date: 2009-11-20 13:59:26 +0000 (Fri, 20 Nov 2009) Log Message: ----------- Correct description for TMCB_REQUEST_BUILT callback: It is not called before but after a new request has been sent. Patch by Timo Reimann (timo.reimann AT 1und1.de) Modified Paths: -------------- branches/1.5/modules/tm/t_hooks.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2009