sr-users June 2005

sr-users@lists.kamailio.org

241 participants
595 discussions

by Dirk Willbrandt

Hi list ! I have a Problem with the appending of an rpid with the functions avp_load_radius(), append_rpid_hf(). In my Radius DB i have an SIP-AVP field which is filled with the Value rpid:[NUMBER] When i run manuall the Radius Reply-Query i get the correct value for SIP-AVP. Now, i reconfigured my ser.cfg so that an avp_load_radius() is executed after an incoming INVITE. My Radius is answering on the command and sends the correct SIP-AVP Value for the User. Now my Problem: I can't append the RPID or anything else to the SIP-Header after the answer from the Radius. So the call is going out without the rpid in the Header. Can anyone help me ? Here is the Configure-Snip: if (method=="INVITE") { # here comes the invite if (!radius_proxy_authorize("")) { # for the digest avp_load_radius it seems that i must use an proxy auth proxy_challenge("","0"); # and an proxy challenge if(!avp_load_radius("digest")) { # here i get the SIP-AVP from the radius log(1,"Failure with the AVP-Value\n"); # if it fails i'll get a message break; # go out } avp_print(); # print all avp's (this command is never executed :( ) append_hf ("Remote-Party-ID: 111222333\r\n"); # append this silly row - it is never executed append_rpid_hf("", ";party=calling;id-type=subscriber;screen=yes"); # append the rpid from SIP-AVP - and this command is also never executed break; # go out }; route(3); # go to route block 3 break; # end } I tried also this snippet without the breaks and proxy-commands but it doesn't work. I don't know what is wrong - please help me :s Thanks ! Dirk

18 years, 11 months

[Serusers] Check if user is already authenticated or registered

by Bastian Schern

Hello everybody, is it possible to check if a user is already registered or authenticated? I want to allow only registered users call to PSTN destinations. Regards Bastian

18 years, 11 months

Re: [Serusers] sems IP

by Samuel Osorio Calvo

SEMS is not directly listening to any IP, it relies on the co-located instance of SER to interact with the "IP world". The topology is the following: [SER A]<--IP interface-->[SER B]<=fifo interface=>[SEMS] SER A is the standard SIP proxy, and you can configure it to forward messages to SER B as it would be another gateway (t_relay, rewrite_uri|hos, |etc..) depending on some rules (such as a predefined prefix in the r-uri as is done in the examples). SER B is the front end for SEMS and has a different config file from SER A. It receives the messages from SER A and forward them to SEMS using t_write_unix() so SEMS can receive the messages. As depicted, the interface between SER B and SEMS is not an IP interface but a FIFO or UNIX socket interface (depending on your config files). You can have SER A, SER B, and SEMS running in the same machine or place SER A in one and SER B+SEMS in another. I hope it makes things clearer, Samuel. Unclassified. >>> Llanos Serna García-Conde <llanosserna(a)hotmail.com> 06/01/05 01:04PM >>> Hi all, I have two instance of SER running, listening to the same port (5060), but to different IP addresses. The SER instance with ser.cfg runs in 172.25.97.19 The SER instance with voicemail.cfg runs in 172.25.97.18 SEMS is running in 172.25.97.19 and I want to change it to run in 172.25.97.18. How can I change that? Thanks, Llanos

18 years, 11 months

[Serusers] Re: [Serdev] Bug? Inconsistent return of loose_route function

by Cesc Santasusana

Hi, It is the same fix I applied to my working copy when i started this thread. So, it has been running for a week now, no problems so far. Regards, Cesc Unclassified >>> Jan Janak <jan(a)iptel.org> 05/31/05 03:53PM >>> It should be fixed now, please update your sources and re-try. thanks for the report, Jan. On 24-05-2005 10:42, Cesc Santasusana wrote: > Hi, > > Ok ... so it is a bug ... now how to fix it? > > > static inline int after_loose(struct sip_msg* _m, int preloaded) > > ..... > > if (enable_double_rr && is_2rr(&puri.params)) { > > .... > > if (res > 0) { /* No next route found */ > > DBG("after_loose: No next URI found\n"); > > return (preloaded ? NOT_RR_DRIVEN : RR_DRIVEN); > > or simply > > return (preloaded RR_DRIVEN); > > Cesc > > > > Unclassified > > >>> Jan Janak <jan(a)iptel.org> 05/23/05 07:25PM >>> > Hello, comments inline. > > On 23-05-2005 18:57, Cesc Santasusana wrote: > > Hi, > > > > I found what i think is a bug in the return value of loose_route() ..... > > bear with me because it is a rather long email. > > > > First, the scenario: > > > > phone1 ----- SER1 ----- SER2 ----- phone2 > > > > p1 to s1 and p2 to s2 use UDP > > s1 to s2 uses tcp or tls > > > > The bug comes into place when there is a change of protocol in ser, > > from UDP into TCP or TLS. > > We do not use a preloaded route set from the phones. > > What ser does is it adds 2 route headers, using the r2 parameter. > > Route: <route1>, <route2> > > > > CASE A: -------------------------------------------- > > In this scenario, say p1 places a call to p2, going through s1 and s2, > > creating the route set with the record-route. > > Now, let's say p2 generates the BYE message. > > When the BYE gets to s1, the last hop, in the config we do: > > if( loose_route () ) { > > t_relay(); > > } > > But, and here is the inconsistency, loose_route (remember we are using > > TCP/TLS, so there are 2 routes in one header field) returns FALSE. > > > > CASE B: -------------------------------------------- > > If this experiment is repeated using ALL UDP, the route headers when they > > get to s1 contain only one route, and the call to loose_route() returns ..... TRUE! > > > > > > Unless the config file does not allow blind sip message relaying, both cases end > > up working ... the BYE gets to the final destination. But if the config file does not > > accept relaying ... the request-uri in the BYE is not taken as a local domain ... and > > thus the message is rejected ... (To Alex Mack: could this be the solution to your problem? > > the BYEs not reaching the phone? add some log output and check it ... ) > > > > ================================================================ > > So, this is not consistent. Now, what is the solution? > > I think that both case A and B should return the same, but what, true or false? > > Yes, they should return the same value in this case and it should be > true (see below). It looks like you discovered a bug. > > > As I see it, the solution causing less trouble is that both return true. So, the last proxy > > considers this BYE as being loose_routed. > > For this ... change the code in: > > rr::loose_route.c:: static inline int after_loose(struct sip_msg* _m, int preloaded) > > ..... > > if (enable_double_rr && is_2rr(&puri.params)) { > > .... > > if (res > 0) { /* No next route found */ > > DBG("after_loose: No next URI found\n"); > > return (preloaded ? NOT_RR_DRIVEN : RR_DRIVEN); > > or simply > > return (preloaded RR_DRIVEN); > > > > > > And now ... the other option is that both return false ... but this would make big changes. > > Correct me if i am wrong, but wouldn't this be the compliant solution? > > Considering that the r-uri is not part of the route set, when the last proxy processes > > all route headers and there are no more left, there is no loose routing done. The > > destination is taken from the r-uri, not the route set ... thus loose_route should return > > false. > > Or I am getting it all wrong? rfc and goal of loose_route() ? > > The meaning of the return value of loose_route is as follows (or > should be): > > 1 - Record routing was used to route the message > 0 - Record routing was not (usually requests establishing a dialog or > transactional requests). > > So the function should return true in the mentioned case, because > record routing was used although the message does not contain any > Route header fields anymore. > > In other words the purpose of loose_route return value is to distinguish > mid-dialog requests (such as ACK or BYE) from dialog-establishing > requests (such as INVITE). The reason why we have to do this is that we > typically do not apply all the logic in the script to mid-dialog > requests (because you should not change the request-uri of the request > anymore once the dialog has been established -- changes caused by > loose_route do not count). > > You may also wonder why don't we use the contents of the Request-URI > for this -- there should be the Contact value of phone1 in the > Request-URI in mid-dialog requests and the value should not match > uri==myself so all we need to do is to enclose all the processing > logic within if (uri == myself) condition. > > This would work in a perfect world without the need to be backwards > compatible with strict routers. In our world we have to be backwards > compatible with strict routers and we have to deal with broken > implementations too (that strip ;lr parameters). Due to backwards > compatibility with strict routers it can happen that the Request-URI > will contain the URI of the proxy that is currently processing the > request and subsequent if (uri==myself) would be true. > > Jan.

18 years, 11 months

[Serusers] sems IP

by Llanos Serna García-Conde

18 years, 11 months

[Serusers] ser_fifo permissions

by Llanos Serna García-Conde

18 years, 11 months

[Serusers] Re: Fwd: Re: error in SQL query

by Christoph Hehl

Now I get this errormessages: Parse error: parse error, unexpected T_STRING in /srv/www/htdocs/serweb_2004-07-27/html/config.php on line 217 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/html/page.php on line 7 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/html/page.php on line 8 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/html/page.php on line 9 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/phplib/session.inc on line 462 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/phplib/session.inc on line 463 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/phplib/session.inc on line 464 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/phplib/session.inc on line 465 Warning: Cannot modify header information - headers already sent by (output started at /srv/www/htdocs/serweb_2004-07-27/html/config.php:217) in /srv/www/htdocs/serweb_2004-07-27/phplib/session.inc on line 466 Database error: cannot use database MySQL Error: 1046 (No Database Selected) Session halted.

18 years, 11 months

[Serusers] voicemail

by Llanos Serna García-Conde

18 years, 11 months

[Serusers] SER Question

by diarmuid.oneill24＠mail.dcu.ie

Hello, I am a student in DCU University in Dublin, Ireland, and i was down loading the SIP Express Router onto a Sun Blade and i cant seem to permanently set the environment variable "SIP_DOMAIN" to my localhost. I use the followng commands in the terminal to set the variable SIP_DOMAIN to the localhost and it works but when i reboot the Sun Blade and type in "#echo ${SIP_DOMAIN}" i dont get back localhost. If you have any solutions to this problem, i would be delighted to hear of them. #SIP_DOMAIN=localhost #export SIP_DOMAIN #echo ${SIP_DOMAIN} Regards, Diarmuid.

18 years, 11 months

[Serusers] error in SQL query

by Christoph Hehl

hello. I have a Problem by login in Servweb. If i klick on the login button i get this errormessages: error in SQL query, line: 30 What's wrong? thanks

18 years, 11 months

Jump to page:

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 June 2005