sr-users

sr-users@lists.kamailio.org

37302 discussions

by Tomas Björklund

Hi, A bit offtopic perhaps, but are there any good win32 sip ua's out there? I'm interested in both commercial and opensource software (my friends doesn't seem to whant to buy Cisco 7960's ... wonder why :) / Tomas

21 years, 9 months

[Serusers] Redundant forwarding

by Jamin W. Collins

This is probably a very simple question. I'm trying to create a very simplistic configuration that simply forwards the call to one of two fixed destinations. Essentially, it forwards all calls to server A and if that fails, forwards the call to server B. Forwarding to server A is no problem. Within route, I simply have: if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; }; rewriteFromRoute(); if (!forward("192.168.1.1")) { sl_reply_error(); }; This works perfectly, but only forwards to one server. I tried changing the last bit to: if (!forward("192.168.1.1")) { if (!forward("192.168.0.1")) { sl_reply_error(); }; }; However, this results in "ERROR: bad config file (5 errors)". Any suggestions? Is something like this possible? -- Jamin W. Collins

21 years, 9 months

RE: [Serusers] problem in using acc.so and radius_acc.so and auth.so

by Benny Ho

Dear Jiri, I have successfully compile the acc.so with SQL support. And I run a number of testing on it. It seems works fine but I encounter the following error which crach the ser. =========================================================== [root@md benny]# 0(3545) mod_init(): Database connection opened successfuly Maxfwd module- initializing rr - initializing acc - initializing stateless - initializing mysql - initializing 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 0(0) INFO: udp_init: SO_RCVBUF is initially 65535 0(0) INFO: udp_init: SO_RCVBUF is finally 131070 9(3565) INFO: fifo process starting: 3565 9(3565) SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... 10(3574) ACC: transaction answered: method=INVITE, i-uri=sip:1000@md.com;user=ph one, o-uri=sip:1000@192.168.10.18:5000;user=phone, call_id= 426a69eafe94e7923666 1278d86d5024(a)192.168.10.18, from= UserAgent-1<sip:1000@192.168.10.18:5000;user=p hone>, code=408 10(3574) use_table(): Invalid parameter value 0(3545) child process 3574 exited by a signal 11 0(3545) core was not generated 0(3545) INFO: terminating due to SIGCHLD ========================================================================= It seems to be a crash on use_table() when code=408, I tried to unanswer to call or call to itself, and this problem generated. Benny -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Monday, February 24, 2003 6:30 PM To: Benny Ho Subject: RE: [Serusers] problem in using acc.so and radius_acc.so and auth.so First of all, note well: http://lists.iptel.org/pipermail/serusers/2003-February/000493.html At 04:36 AM 2/24/2003, Benny Ho wrote: >Could you tell me how to enable SQL_ACC def? and setting teh db_url >parameter? uncomment the "#DEFS+=-DSQL_ACC" line in modules/acc/Makefile >I cannot find any doc for mysql modules. mysql module is not used from ser scripts directly -- modules which rely on mysql use it internally. acc w/mysql has not been released yet, it is work in progress on CVS and it has not been documented. -jiri

21 years, 9 months

Re: [Serusers] Redundant forwarding

by lgfausak＠august.net

I'm currently working with SNOM to get this issue fixed. I'll report when I know something. It might not hurt if someone else reported it to them! ---greg Greg Fausak > >At 09:34 PM 2/24/2003, Jamin W. Collins wrote: >>On Mon, Feb 24, 2003 at 08:54:00PM +0100, Jiri Kuthan wrote: >>> What is CIC? >> >>A PBX made by I3 (www.inin.com) >> >>> Send us network dumps please -- that will make it easier to understand >>> for us. You can for example use "ngrep port 5060". >> >>Network dump from the SER server is attached. > >snom phone is a common suspect again. > >The first signaling transaction looks ok. The only unusual thing is that >for some reason, the ININ server advertises 192.168.0.9 as media receiver >whereas its signaling lives at 192.168.1.16. Is media decomposed? > >The really suspicious is the second transaction. The snom phone sitting >at .36 advertises contacts with .34 in its replies. That makes the >caller (ININ) to send an ACK to .34. Snom does not received it and >keeps soliciting it by retransmitting 200s. > >-Jiri > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers >

21 years, 9 months

[Serusers] Some thoughts and questions

by Tomas Björklund

Hi, I've been looking at ser for a couple of days now and there some things I can't find in the documentation. .1. Logging funktionality I'm used to being able to log more detail than what I can get out ser. I'm problably missing something in the documentation, but what I want is something like the following timestamp ser[pid] Incoming packet from ip:port [dump of packet (only the sip header/body)] timestamp ser[pid] Invite from [] to [] timestamp ser[pid] After rewrite: from [] to [] timestamp ser[pid] Relaying packet to [pstn-gw/other sip server] / timestamp ser[pid] Handling request for local user [] Can you send arguments to the log() function in the configuration file for example log(1,"Call from %s", uri:from); ?? .2. Rewrite rules Is it possible to rewrite the from uri? For example when I [sip:tomas@krixor.xy.org] want to call a pstn number I must rewrite the from address to [sip:myphonenumber@krixor.xy.org] before I send the request to the pstn gateway And when a incoming call comes from the pstn gateway I want to rewrite the from address from [<sip:number@ip-of-pstn-gateway>] to {"PSTN Luser" <sip:number@pstn-gw.mydomain.com>] I haven't looked at the source in the CVS yet, but I aim to do so soon, I saw in the list archive that you have lots of nice new features planned for the next release. ENUM support is one of the better ones :) Anyway, looking forward to trying to help with the development of this software. Best regards, Thomas Björklund

21 years, 9 months

[Serusers] Rewriting URI in the Contact field

by Maxim Sobolev

Folks, I need an advise on how to better implement one feature, which isn't currently present in SER. We need to allow UAs behind NAT properly register with the registrar - by "properly" I mean that host:port portion of URI in Contact field should not be used, but host:port the request came from should be used instead. By definition we know that those UAs will support symmetric SIP signalling, so that this scheme will work just fine. In my opinion there are two ways to do it: either add new rewritecontact* family of functions similar to rewritehost ones. or add a new flag for the save() function. This is where I need your help - which implementation looks better for you (or maybe you have even some better idea), since we are really interested in inclusion of our changes into the mainline to reduce our local hacks. Regards, Maxim

21 years, 9 months

[Serusers] Some patches for integration

by Maxim Sobolev

Folks, Attached please find several patches for ser 0.8.10. They do the following: 1. Removes hardcoded `/usr/local' from Makefiles and replaces it with LOCALBASE variable setable in the top Makefile.defs. This should make life of packagers easier. 2. Allows to override PREFIX variable with something else from environment. 3. Adds support for FreeBSD doc/man directories layout. 4. Adds some missed -I's into radius modules. 5. Fixes radius modules to use the same symbolic avp names as in dictionary. 6. Adds support for recording source port in msg structure and adds it in "Noisy feedback". This should be extremely useful for debugging various SIP&NAT scenarios and later could be re-used to implement `rport' support described in my previous message. It would be nice to have those patches integrated into the next release. Thanks! -Maxim

21 years, 9 months

[Serusers] Record-route:/Contact: conflict?

by Greg Fausak

I've got a packet that looks like: # U 2003/02/24 07:56:52.503535 216.87.144.203:5060 -> 216.87.145.22:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r. From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc. To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532. Date: Mon, 24 Feb 2003 13:56:43 GMT. Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 2 INVITE. Session-Expires: 7200;refresher=uac. Require: timer. Allow-Events: telephone-event. Contact: <sip:92143357976@216.87.144.196:5060;user=phone>. Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>. Content-Type: application/sdp. Content-Length: 209. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 16632 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 X-NSE/8000. a=fmtp:100 192-194. The main thing to note is the packet is sent to a SNOM phone from my PROXY server. Curious, when the SNOM phone responds it is responding to 216.87.144.196, which is my GATEWAY. My GATEWAY is configured to only listen to the PROXY server, so it drops the packet. In the packet above, the Record-route line indicates that 216.87.144.203 should be responded to, which is my PROXY. Also in the packet above, there is a 'Contact:' line that indicates the GATEWAY at 216.87.144.196 should be contacted. Obviously the SNOM phone is getting the address from the Contact: line (or maybe the SDP) rather than the Record-route: line. Is it doing so incorrectly, or do I have a bug in my GATEWAY, or does the PROXY need to strip out the Contact: line?

21 years, 9 months

[Serusers] SER parser benchmarks

by Sebastien Pierre

Hi! I was just wondering if you had some benchmark for the SER parser... as SER does not seem to offer a libser, it makes it more difficult to write benchmarking programs :/ TIA, -- Sebastien

21 years, 9 months

Re: [Serusers] FCP support in SER: Modifying SDP

by jaime.gill＠orange.co.uk

Thanks Jiri, I'll have a look at the CVS version. I'm sure there will be more hacking to do only to make it compile.... :( However, got the replacement of the "c=.." part working. I'll test this as soon as I can. Jaime Jiri Kuthan <jiri(a)iptel.org> on 24/02/2003 13:20:00 To: Jaime GILL/EN/HTLUK@HTLUK Nils Ohlmeier <nils(a)ohlmeier.de> cc: Jan Janak <J.Janak(a)sh.cvut.cz> serusers(a)lists.iptel.org Subject: Re: [Serusers] FCP support in SER: Modifying SDP At 12:50 PM 2/24/2003, jaime.gill(a)orange.co.uk wrote: [...] >It think the problem is in the replacement of the SDP information. The first >occurrence of the IP address in "v= " and the port in "m= " in the SDP get >replaced, but the second IP in "c=" is not. nit: it's not the "v=" line, but "o=" ('owner') line which you are replacing. However, you are not probably worried so much about this one -- it maintains primarily a (not widely utilizied) identification purpose. All "c=" occurences do matter. (In addition to port numbers in "m=" lines.) [...] >I have been trying to understand how the proxy builds the forwarded message from >the old one, and realised that for the Via replacement (or adding of more >params), I need to be using a string called add_to_branch_s and >add_to_branch_len (so ignore the replace_via implementation in the current >tar.gz). I suggest you used the mhomed option (available only on CVS). The issue is you need to print the correct IP address in Via on multihomed host. With mhomed enabled, IP routing is utilized to determine the right IP address. Let me know if you need something more for getting Via right. >But for the SDP, whenever I work with get_body, it does not modify it >appropriately. So currently, I'm using msg->orig to get to the initial message, >search for certain IP4 and audio strings and replace them with the information >provided by the fcp server. That means, in the case of the SDP, 2 IP address >replacements (in v=.. and c=..) and 1 port replacement (in m=..). As I mentioned >before, I only manged to change the v=.. and m=... Whenever I try to replace >more than one appearance, strange things happen, like strings in non expected >places, like Via, and cannot work out why. So my question is an open one:): what >is the best way to change the SDP part? I suggest here too -- use the CVS version. It has departed from the use of the buffers (orig and buf) -- we have now just one buffer (buf) without any zero termination. Previously, the two buffers and 0-termination caused lot of issues, some of them possibly annoying you right now. Look at the textops/replace_all action (only on CVS too) to see how to replace multiple occurences of a string in SIP messages. (Caution: you will eventually need to calculate new SDP body size and change content-length too.) >The other of my questions is whether all this mess with NAT's will get solved >when the proxy supports TCP, The major problem is media, which will keep using UDP. >and whether this is the best approach to solve the >SIP through NAT/FW problem. As all NAT traversal methods -- none of them is perfect, each has cons and pros. The benefit of FCP is that once fcpd works, maintenance of the SIP code is easier in user space. Also, you can better couple your pinhole policy with SER's SIP-layer policy. >For example, how about a nathelper module for >netfilter/iptables that gets this working, in the same manner as IRC or ftp >currently? Does anybody know about any work progressing this for linux/FreeBSD? I'm not aware of such. There is Billy Biggs masquerading module, but it is pretty old and no longer maintained. -Jiri _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 9 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