sr-users June 2011

sr-users@lists.kamailio.org

75 participants
114 discussions

by Daniel-Constantin Mierla

Hello, just to let everyone to know that starting with today Peter got developer access to GIT repository. He sent many patches in the past months to fix issues or add new features to presence modules (e.g., OMA extensions to embedded XCAP server) -- some are pending to be committed and expect more to come, as he is continuing to work with this part of SIP server. The user id is 'pd'. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

13 years, 6 months

Re: [SR-Users] Best way to handle OPTIONS message with Max-Forwards of 0

by Sean O'Donnell

Looks more comprehensive than mine. Thanks! Sean O'Donnell ---- On Wed, 8 Jun 2011, Klaus Darilion (klaus.mailinglists(a)pernau.at) wrote: Anyway - not standard conform but efficient (put somewhere in the beginning) force_rport(); if (is_method("OPTIONS")) { sl_send_reply("200","OK"); exit; } # sipura/linksys keepalive if (is_method("NOTIFY")) { if ( search("^Event: keep-alive") ) { sl_send_reply("200","Keep Alive"); exit; } } # ignore requests generated by sipvicious # User-Agent: friendly-scanner if ($ua == "friendly-scanner") { exit; } regards Klaus Am 08.06.2011 18:28, schrieb Sean O'Donnell: > Hi: > > We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our > service providers > has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. > > Looking at RFC 3261 section 11, this seems to be a valid method of forcing the > proxy to respond to the OPTIONS. > However, the standard initial sanity checks in most proxy configs will reject > this message. I fixed our script > by changing to this: > > # initial sanity checks -- messages with > # max_forwards==0, or excessively long requests > if (!mf_process_maxfwd_header("10")) { > if( method != "OPTIONS" ) { > sl_send_reply("483","Too Many Hops"); > return; > }; > }; > if ( msg:len > max_len ) { > sl_send_reply("513", "Message too big"); > return; > }; > > but does anyone have a better solution? > > Thanks, > > Sean O'Donnell > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

13 years, 6 months

Re: [SR-Users] Best way to handle OPTIONS message with Max-Forwards of 0

by Sean O'Donnell

Thanks for the reply. In our case, the SBC treated the 483 as an error of some sort and wouldn't send traffic. It wanted a 200/OK. Anyway, I thought that when a proxy responds to an OPTIONS, its supposed to answer with a 200/OK (3261 11.2). Is that correct? Sean O'Donnell ---- On Wed, 8 Jun 2011, Klaus Darilion (klaus.mailinglists(a)pernau.at) wrote: What is the problem with the default config? The proxy will respond with 483 as the standard defines. I guess the SBC will doe this to check if the proxy is alive and will accept any response as "the proxy is alive". regards Klaus Am 08.06.2011 18:28, schrieb Sean O'Donnell: > Hi: > > We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our > service providers > has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. > > Looking at RFC 3261 section 11, this seems to be a valid method of forcing the > proxy to respond to the OPTIONS. > However, the standard initial sanity checks in most proxy configs will reject > this message. I fixed our script > by changing to this: > > # initial sanity checks -- messages with > # max_forwards==0, or excessively long requests > if (!mf_process_maxfwd_header("10")) { > if( method != "OPTIONS" ) { > sl_send_reply("483","Too Many Hops"); > return; > }; > }; > if ( msg:len > max_len ) { > sl_send_reply("513", "Message too big"); > return; > }; > > but does anyone have a better solution? > > Thanks, > > Sean O'Donnell > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

13 years, 6 months

Best way to handle OPTIONS message with Max-Forwards of 0

by Sean O'Donnell

Hi: We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our service providers has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. Looking at RFC 3261 section 11, this seems to be a valid method of forcing the proxy to respond to the OPTIONS. However, the standard initial sanity checks in most proxy configs will reject this message. I fixed our script by changing to this: # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { if( method != "OPTIONS" ) { sl_send_reply("483","Too Many Hops"); return; }; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); return; }; but does anyone have a better solution? Thanks, Sean O'Donnell

13 years, 6 months

Incorrect registrar Expires handling

by Andreas Granig

Hi, Found an interesting call-flow today where a client (pjsip) is behind NAT and behaves like this during registration (kamailio-3.1.3): REGISTER sip:somedomain.com Contact: <sip:me@10.0.0.7:2001;ob> Expires: 900 SIP/2.0 200 OK Contact: <sip:me@10.0.0.7:2001;ob>;expires=900;received="sip:1.2.3.4:3001" REGISTER sip:somedomain.com Contact: <sip:me@1.2.3.4:3001;transport=UDP;ob> Contact: <sip:me@10.0.0.7:2001;ob>;expires=0 Expires: 900 SIP/2.0 200 OK Contact: <sip:me@10.0.0.7:2001;ob>;expires=900;received="sip:1.2.3.4:3001", <sip:me@1.2.3.4:3001;transport=UDP;ob>;expires=900 So obviously the client is trying to unregister its private contact (for whatever reason - probably to play nice with registrars not supporting far-end NAT traversal), and tries to register the Contact with the "received" address instead. Kamailio however ignores the ";expires=0" for the private Contact and just saves both of them with the expiry value given in the Expires header. Taking the client behavior aside for now: is this the correct behavior of the registrar module? In RFC3261 chapter 10.2.1.1 it says: #+ There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter. #- So I'd say that in my specific case "expires" Contact header param (which is 0 for the binding having 10.0.0.7) should de-register this particular binding, whereas the Expires header should be applied to the second binding (having the 1.2.3.4) because it doesn't carry an "expires" param. Opinions on that one? Andreas

13 years, 6 months

incorrect port 0 in reply from rtp proxy

by Mokhtar Bengana

I have Kamailio and rtpproxy running behind NAT on the same server. Inbound calls to Kamailio from the outside work fine and I have two way audio but when I try an outbound echo test call the call connects but I have no audio. rtpproxy seems to be running and all rtp ports are poiting to Kamailio internal ip. The syslog is showing this error. Not sure what's missing in the config. Appreciate any inputs. Thanks. root@Kamailio:~# tail /var/log/syslog Jun 3 01:24:02 Kamailio kamailio[810]: INFO: rtpproxy [rtpproxy.c:1403]: rtp proxy <udp:127.0.0.1:22222> found, support for it enabled Jun 3 01:25:05 Kamailio kamailio[791]: INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via Jun 3 01:25:29 Kamailio kamailio[791]: ERROR: rtpproxy [rtpproxy.c:2211]: incorrect port 0 in reply from rtp proxy Jun 3 01:25:30 Kamailio kamailio[793]: ERROR: rtpproxy [rtpproxy.c:2211]: incorrect port 0 in reply from rtp proxy

13 years, 6 months

t.38 fax

by Sanjeev Singh

does SER support t.38 fax? what other features related to fax does SER support. please expain in detail. thanks, Sanjeev Singh

13 years, 6 months

xhttp and dollar sign

by Andreas Granig

Hi, Is it possible to somehow quote the $ sign in xhttp_send_reply() in order not to be interpreted by kamailio-3.1.3? Tried with "\" and putting the whole body in single quotes, but I always get this error message during startup: ERROR: <core> [pvapi.c:720]: wrong char [$/36] in [${foo}] ERROR: <core> [sr_module.c:1156]: bad PVE format: "${foo}" ERROR: <core> [mod_fix.c:501]: Cannot convert function parameter 1 to spve So I actually just want to return the string "${foo}". Andreas

13 years, 6 months

Error bad syntax - DEBUG_FLAGS

by Skyler

Hi all, I'm new to Kamailio (3.1), learning the configuration language. I'm trying to take the advice from one of the docs to create a DEBUG block and place calls everywhere in my script. Right out of the gate I get these errors on loading. Can someone tell me where I went wrong and how I can fix this? It says flag not declared though it's there and I'm a bit lost. 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 6: syntax error 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 6: missing '(' or ')' ? 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 6: bad command: missing ';'? 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 18: '('')' expected (function call) 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 18: bad command: missing ';'? 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 800, column 20: bad command 0(10986) : <core> [cfg.y:3412]: parse error in config file //etc/kamailio/kamailio.cfg, line 802, column 24: flag not declared #------------------------------ # Flags #------------------------------ #!define FLAG_DEBUG 1 ... route { # Call debug flags route(ROUTE_DEBUG_FLAGS); ..... route[ROUTE_DEBUG_FLAGS] { resetflag(FLAG_DEBUG); #------------------------------------------------------------ # Methods that will have debugging turned on #----------------------------------------------------------- if (is_method("ACK")) { resetflag(FLAG_DEBUG); } else if (is_method("BYE")) { setflag(FLAG_DEBUG); } else if (is_method("CANCEL")) { setflag(FLAG_DEBUG); } else if (is_method("INVITE")) { setflag(FLAG_DEBUG); } else if (is_method("OPTIONS")) { setflag(FLAG_DEBUG); } else if (is_method("PUBLISH")) { setflag(FLAG_DEBUG); } else if (is_method("REGISTER")) { resetflag(FLAG_DEBUG); } else if (is_method("MESSAGE")) { setflag(FLAG_DEBUG); } else if (is_method("NOTIFY")) { setflag(FLAG_DEBUG); } else if (is_method("SUBSCRIBE")) { setflag(FLAG_DEBUG); } else if (is_method("INFO")) { setflag(FLAG_DEBUG); } else if (is_method("PRACK")) { setflag(FLAG_DEBUG); } else if (is_method("REFER")) { setflag(FLAG_DEBUG); } else { setflag(FLAG_DEBUG); } } }

13 years, 6 months

Using =~ to get the group identifier with longest match

by Iñaki Baz Castillo

Hi, I wonder how feasible is the folowing: I have a regular expresion like: REGEXP = "^((1|20)|(13|3|4)|(5|6))" There are 3 matching groups: 1) (1|20) 2) (13|3|4) 3) (5|6) I want to match the RURI user, let's suppose $rU = "138787686223". In this case the above regexp matches groups 1 and 2, but since group 2 matching is longest ("13" is longest than "1") I want to get value 2. In case $rU = "999999" I need to get "null", in case $rU = "1000022323" I need to get "1". AFAIK there is no way to do it with current regular expression utils in Kamailio, but maybe I miss something. Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

13 years, 6 months

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 2011