sr-users April 2011

sr-users@lists.kamailio.org

64 participants
105 discussions

Broken Via/reply-matching for natping OPTION
by Andreas Granig 20 Apr '11

20 Apr '11

Hi, When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g: OPTIONS sip:192.168.51.1:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0. Route: <something> Should be branch=z9hG4bK<something> instead of branch=0, right? When a reply comes back, like this... SIP/2.0 100 Trying. Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0;rport=5062. From: sip:pinger@<something> ... then kamailio logs this: INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via The full debug log looks like this: DEBUG: <core> [parser_helpers.c:196]: path for branch: '<sip:lb@127.0.0.1:5060;lr;received=sip:192.168.51.1:5060>' DEBUG: <core> [parser/msg_parser.c:640]: SIP Reply (status): DEBUG: <core> [parser/msg_parser.c:642]: version: <SIP/2.0> DEBUG: <core> [parser/msg_parser.c:644]: status: <100> DEBUG: <core> [parser/msg_parser.c:646]: reason: <Trying> DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <0>; state=6 DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> = <5062>; state=16 DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via DEBUG: <core> [receive.c:145]: After parse_msg... DEBUG: tm [t_lookup.c:1081]: DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9 DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [23]; uri=[sip:192.168.51.1:5060] DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:192.168.51.1:5060#015#012] DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <OPTIONS> DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction DEBUG: tm [t_lookup.c:1150]: DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 DEBUG: <core> [parser/msg_parser.c:103]: found end of header INFO: <core> [forward.c:786]: broken reply to forward - no 2nd via DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Thanks, Andreas

4 6

planning next major release 3.2
by Daniel-Constantin Mierla 20 Apr '11

20 Apr '11

Hello, soon we should sketch the roadmap for the next major release 3.2. There are some private git branches with lot of work on it, so we need to synchronize a bit and decide about the proper time: before or after summer. Several devels will be in Berlin for Linuxtag, but no so much overlapping for a big face to face meeting, therefore might be better to have a IRC chat conference sometime in the near future. Next week will be fine for me, say Wednesaday till Friday, in the afternoon to allow fair time of the day for US timezones. If you have other proposals, speak up. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2 3

Re: [SR-Users] Ipv6 SIP UA
by Daniel-Constantin Mierla 20 Apr '11

20 Apr '11

Hello, On 4/19/11 9:58 AM, Pavel Segeč wrote: > Hi, > > may someone help me and recommend a software SIP client with a good IPv6 > support implemented? I tried Xlite, Bria, Linphone, SIP communicator and > Jitsi but with a bad results. Each have some problem within pure IPv6 > environment. the last sipit I attended (last year, though) was not rich at all in IPv6 softphones. In the past there was a patched version of KPhone we used at FhG Fokus for some tests, but I wouldn't call it production ready: http://old.iptel.org/products/kphone/ From what was listed above, you touched most of the active softphones, afaik ekiga,qutecom and twinkle do not have it, not sure about zoiper. Cheers, Daniel

4 3

Re: [SR-Users] Ipv6 SIP UA
by Klaus Darilion 19 Apr '11

19 Apr '11

I once wrote a SIP client based on pjsip: http://www.ipcom.at/en/telephony/qjsimple/ AFAIK it works will using IPv6 when using UDP. regards Klaus Am 19.04.2011 09:58, schrieb Pavel Segeč: > Hi, > > may someone help me and recommend a software SIP client with a good IPv6 > support implemented? I tried Xlite, Bria, Linphone, SIP communicator and > Jitsi but with a bad results. Each have some problem within pure IPv6 > environment. > > palo > > > __________ Informacia od ESET NOD32 Antivirus, verzia databazy 6053 > (20110418) __________ > > Tuto spravu preveril ESET NOD32 Antivirus. > > http://www.eset.sk > > > > _______________________________________________ > 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

1 0

ser flavour accounting
by Claudio Furrer 19 Apr '11

19 Apr '11

Hello, I'm trying to migrate ser-0.9.x to the current sr-3.1.x and right now trying to figure out the acc functions/parameters. I used to use "acc_db_request" from acc module, but it's not working using acc_db and acc_syslog in conjuntion. acc_db has acc_db_request[0,1] but are not callable from the configuration file, and acc_syslog has acc_db_request, but doesn't matter if i load this module, the function isn't found... loading modules under /usr/lib/siprouter/modules:/usr/lib/siprouter/modules_s 0(23455) : <core> [cfg.y:3412]: parse error in config file /tmp/ser.cfg, line 358, column 74: unknown command, missing loadmodule? line 358 is: acc_db_request("480 Offline User", "missed_calls"); I would appreciate if you can guide me through the ACC documentation or changes that it has suffered.. I tried to track the git log.. but many changes since my old ser :( Thank you Claudio pd: FYI i did this modifications to adjust my acc settings: # Accounting module +loadmodule "acc_syslog.so" loadmodule "acc_db.so" # ----------------- setting module-specific parameters --------------- @@ -139,15 +140,13 @@ # number of flag, which will be used for accounting; if a message is # labeled with this flag, its completion status will be reported # modparam("acc", "log_flag", 1 ) -modparam("acc_db", "log_level", 1) +modparam("acc_syslog", "log_level", 1) # MySQL acc params modparam("acc_db", "db_url", "mysql://ser:heslo@localhost/ser") -modparam("acc_db", "db_flag", 2) -modparam("acc_db", "db_missed_flag", 3) +modparam("acc_db", "log_flag", 2) +modparam("acc_db", "log_missed_flag", 3) modparam("acc_db", "log_fmt", "miocfspD") -# Acc time set to localtime (1) -modparam("acc_db", "db_localtime", 1)

2 1

modules_s/uri_db functions
by Claudio Furrer 19 Apr '11

19 Apr '11

Hello, What happened to checks.c file on uri_db module (modules_s)? Seem to be an empty file now, only headers exist. Is it the same to use modules_k/ version? I'm currently at v3.1.. Regards, Claudio

2 1

tm stats pseudo variables?
by Juha Heinanen 19 Apr '11

19 Apr '11

is there any means to access native tm stats from script? i know about $stat pvs for accessing k versions of tm stats, but i want access to native tm stats. -- juha

3 2

RTPProxy and bridging IPv4/IPv6 with parallel forking
by Dan-Cristian Bogos 19 Apr '11

19 Apr '11

Hey Guys, I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario: * AOR having contacts on both ipv4 and ipv6 and I wanted to do parallel forking. RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario? EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches. So what do u think? DanB PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.

4 10

stats in kamailio
by Ricardo Martinez 19 Apr '11

19 Apr '11

Hello. I’m trying to get statistics to use charts in SIREMIS v2.0. I was able to load the “Memory” statistics but I want to know if there is more information to use from Kamailio, right now I have : $stat(used_size) $stat(real_used_size) $stat(max_used_size) $stat(free_size) $stat(location-users) $stat(location-contacts) Where can I find the complete list of statistics to get from kamailio?. Thanks in advance. Ricardo Martinez.-

5 13

Attended transfer in load-balanced multi-server setup
by Pan B. Christensen 18 Apr '11

18 Apr '11

Hello all, I'm having problems with attended transfer in certain scenarios. Let me first try to document the relevant parts of the setup: There are two load-balanced Asterisk gateways connected to the old Nortel system. Currently, PSTN connections are done by Nortel. We then have two load-balanced kamailio servers. The phones are connected to these. There are several other servers not relevant to this question. Blind transfer works in any scenario. I've been told that attended transfer works in any scenario if the original call is SIP to SIP. If the original call is from Nortel/PSTN to SIP, then attended transfer will usually not work. Scenarios: A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device (user B). User B pushes the transfer button (puts current call on hold and makes a new call) and dials a Nortel / PSTN number to user C. This call goes out through the nortel2 server. Users B and C talk a short while before user B pushes the Transfer button again to connect users A and C. In this scenario, the REFER is forwarded by kamailio to nortel1, which replies "SIP/2.0 481 Call leg/transaction does not exist." The call to join is of course on the other asterisk (nortel2). A similar scenario is where user B transfers to another SIP user. This call will only exist in one of the kamailio servers, and Asterisk will give the same response to the REFER. A third scenario is where both calls are handled by the same Asterisk server. This scenario works. I'm assuming I'll have to build REFER-handling logic into kamailio, but am unsure of how to proceed. Any suggestions? Thanks in advance. With kind regards, Pan

2 2

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2025

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 April 2011