sr-users September 2006

sr-users@lists.kamailio.org

184 participants
436 discussions

by Tobias Lindgren

Hi all, I'm looking for a good voice recorder software (OpenSource pref.) that can record a conversation in a phonecall. Please let me know if you have tested one. Br, Tobias

17 years, 7 months

[Users] mediaproxy signIn IP address

by Klaus Darilion

Hi! It looks like there is some restriction of the IP address allowed to signIn to mediaproxy. Can this be configured or is this hardcoded? thanks klaus

17 years, 7 months

Re: [Serusers] Nathelper Ping OPTIONS

by Greger V. Teigre

:-D If she really is beautiful, I would take whatever she could give... However, this one doesn't want to talk to you. You need to find some tricks. g-) olivier wrote: > The beautifullest girl of the world can't give you what she doesn't > have ;) > > Thanks anyway, > > Olivier > > Greger V. Teigre a écrit : >> Yes, I saw that. Last time I tried, it worked. I couldn't see what >> possibly is wrong from the output and still can't. Sorry. >> g-) >> >> olivier.taylor wrote: >>> Hi Greger, >>> >>> I have tried to apply the patch to 0.9.6, see the result below :( >>> >>> I have downloaded the last 0.9.6. >>> >>> Olivier >>> >>> Greger V. Teigre a écrit : >>>> The patch should work for 0.9.6. AFAIK, 0.10.x already has the >>>> OPTIONS support. >>>> g-) >>>> >>>> olivier.taylor wrote: >>>>> Hello, >>>>> >>>>> just trying to enable the ping functionality in nathelper to send >>>>> SIP message (i.e. OPTIONS) instead of 4-byte UDP packets >>>>> on SER 0.9.6 and 0.10.0 >>>>> >>>>> as shown below, patch doesn't apply >>>>> Is there another possibility to have this feature? >>>>> >>>>> Olivier >>>>> >>>>> >>>>> patch -p1 < nathelper_ping.patch >>>>> Hmm... Looks like a unified diff to me... >>>>> The text leading up to this was: >>>>> -------------------------- >>>>> |diff -Naur -x CVS nathelper/nathelper.c nathelper_ping/nathelper.c >>>>> |--- nathelper/nathelper.c 2006-08-16 08:45:48.000000000 +0200 >>>>> |+++ nathelper_ping/nathelper.c 2006-08-10 14:54:14.000000000 +0200 >>>>> -------------------------- >>>>> Patching file nathelper.c using Plan A... >>>>> Hunk #1 failed at 118. >>>>> Hunk #2 failed at 172. >>>>> Hunk #3 failed at 193. >>>>> Hunk #4 failed at 212. >>>>> Hunk #5 failed at 239. >>>>> Hunk #6 failed at 257. >>>>> Hunk #7 failed at 267. >>>>> Hunk #8 failed at 276. >>>>> Hunk #9 failed at 320. >>>>> Hunk #10 failed at 367. >>>>> Hunk #11 failed at 1543. >>>>> 11 out of 11 hunks failed--saving rejects to nathelper.c.rej >>>>> Hmm... The next patch looks like a unified diff to me... >>>>> T >>>>> _______________________________________________ >>>>> Serusers mailing list >>>>> Serusers(a)lists.iptel.org >>>>> http://lists.iptel.org/mailman/listinfo/serusers >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

17 years, 7 months

[Serusers] Carrier-grade framework for SER

by Andreas Granig

Hi guys, I'd like to propose another possibility for a highly-available and scalable system design based on SER: The problems I've encountered for scalable systems are: - Distribution of the user location and alias location among the nodes (user location is based on registrations, alias location comes from web interfaces and is used for call forwarding). - Reloading up to date location tables after breakdown and recovery of a node So I'm just thinking loud about the following provisioning system: - Write a client which fulfills the this demands: - Receive one or more locations from SER via a SER module or from a web application and distribute them to other known clients. Take care of retransmissions if a client isn't reachable or reports a temporary failure. - Receive one or more locations from other clients and write them into the SER FIFO. If writing into the FIFO fails, try to write directly into the database (location-table, alias-table etc.). Report a temporary failure if this also fails. Maybe a centralized server should be used which receives the locations from the clients and distributes them to other clients, so that the nodes just know about the server and nothing about other nodes. This would make integration of new nodes easy. On the other hand, it's another single point of failure, so a decentralized solution should be considered. But that would mean that you've to inform every node about the existence of a new node. The protocol used between the nodes should be simple and fast. So I think SOAP drops out here. Maybe XMLRPC or ICE (http://www.zeroc.com/ice.html) could be used. One might think now why not just use replication on SIP layer, but t_replicate only supports one peer and you've no possibility to get locations on a node while it's down. Replication of other location tables like the alias-table is also not possible. I'd be willing to release these parts as GPL for creating an open framework for carrier-grade SER integration, so any feedback, improvements or flames are highly welcome. Cheers, Andy

17 years, 7 months

[Users] auth ACK and BYE?

by Mark Kent

I just noticed that my SIP phone sends authentication credentials for ACK and BYE in a session where the INVITE required authentication credentials. I recognize this as a good thing... but it also surprised me. Currently, I don't handle it in my openser.cfg... I neither ask for the credentials nor do I strip them off before passing the message down the line... other than for INVITE. I'm going to correct this in my config, and I thought it worth mentioning for others just in case others also hadn't considered it. -mark

17 years, 7 months

[Serusers] digit matching

by Richard C. Thompson

Hi All I hope someone can point me in the right direction or just give me a hint. I have the following route in ser.cfg and it works great. All I would like to do is change it so it matches on any number that starts with 002 regardless of length not just 12 more digits or a fixed length. if(uri=~"sip:(002............)@") I tried if(uri=~"sip:(002*)@") but it didn't work TIA Rick

17 years, 7 months

[Users] Beer in oslo tomorrow

by Atle Samuelsen

This is just a beer reminder.. Remember beer in Oslo tomorrow. :) Topic: ser 0.10 _A

17 years, 7 months

[Serusers] Callfwd example not routing

by Murray Hooper

I am trying to get a call forwarding to a PSTN gateway. I see the SIP call come in but appears I am missing something to get the routing/call forward to be recognized. Below is SIP log. Sep 26 13:04:52 localhost ./ser[7102]: SIP Request: Sep 26 13:04:52 localhost ./ser[7102]: method: <INVITE> Sep 26 13:04:52 localhost ./ser[7102]: uri: <sip:5199571788@216.183.86.133> Sep 26 13:04:52 localhost ./ser[7102]: version: <SIP/2.0> Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=1 Sep 26 13:04:52 localhost ./ser[7102]: Found param type 232, <branch> = <z9hG4bK0a45e9d0>; state=6 Sep 26 13:04:52 localhost ./ser[7102]: Found param type 235, <rport> = <n/a>; state=17 Sep 26 13:04:52 localhost ./ser[7102]: end of header reached, state=5 Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: Via found, flags=1 Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: this is the first via Sep 26 13:04:52 localhost ./ser[7102]: After parse_msg... Sep 26 13:04:52 localhost ./ser[7102]: preparing to run routing scripts... Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=128 Sep 26 13:04:52 localhost ./ser[7102]: end of header reached, state=9 Sep 26 13:04:52 localhost ./ser[7102]: DEBUG: get_hdr_field: <To> [33]; uri=[sip:5199571788@216.183.86.133] Sep 26 13:04:52 localhost ./ser[7102]: DEBUG: to body [<sip:5199571788@216.183.86.133> ] Sep 26 13:04:52 localhost ./ser[7102]: get_hdr_field: cseq <CSeq>: <102> <INVITE> Sep 26 13:04:52 localhost ./ser[7102]: DEBUG: get_hdr_body : content_length=218 Sep 26 13:04:52 localhost ./ser[7102]: found end of header Sep 26 13:04:52 localhost ./ser[7102]: DEBUG: is_maxfwd_present: max_forwards header not found! Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=64 Sep 26 13:04:52 localhost ./ser[7102]: check_via_address(216.143.130.61, 216.143.130.61, 0) Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=33554432 Sep 26 13:04:52 localhost ./ser[7102]: DEBUG: add_param: tag=as35382f6d Sep 26 13:04:52 localhost ./ser[7102]: end of header reached, state=29 Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=256 Sep 26 13:04:52 localhost ./ser[7102]: find_first_route: No Route headers found Sep 26 13:04:52 localhost ./ser[7102]: loose_route: There is no Route HF Sep 26 13:04:52 localhost ./ser[7102]: is_local(): Realm '216.183.86.133' is not local Sep 26 13:04:52 localhost ./ser[7102]: is_local(): Realm '216.143.130.61' is not local Sep 26 13:04:52 localhost ./ser[7102]: parse_headers: flags=-1 Sep 26 13:04:52 localhost ./ser[7102]: check_via_address(216.143.130.61, 216.143.130.61, 0) Sep 26 13:04:52 localhost ./ser[7102]: DEBUG:destroy_avp_list: destroying list (nil) Sep 26 13:04:52 localhost ./ser[7102]: receive_msg: cleaning up Sep 26 13:04:52 localhost ./ser[7098]: SIP Request: Sep 26 13:04:52 localhost ./ser[7098]: method: <ACK> Sep 26 13:04:52 localhost ./ser[7098]: uri: <sip:5199571788@216.183.86.133> Sep 26 13:04:52 localhost ./ser[7098]: version: <SIP/2.0> Sep 26 13:04:52 localhost ./ser[7098]: parse_headers: flags=1 Sep 26 13:04:52 localhost ./ser[7098]: Found param type 232, <branch> = <z9hG4bK0a45e9d0>; state=6 Sep 26 13:04:52 localhost ./ser[7098]: Found param type 235, <rport> = <n/a>; state=17 Sep 26 13:04:52 localhost ./ser[7098]: end of header reached, state=5 Sep 26 13:04:52 localhost ./ser[7098]: parse_headers: Via found, flags=1 Sep 26 13:04:52 localhost ./ser[7098]: parse_headers: this is the first via Sep 26 13:04:52 localhost ./ser[7098]: After parse_msg... Sep 26 13:04:52 localhost ./ser[7098]: preparing to run routing scripts... Sep 26 13:04:52 localhost ./ser[7098]: parse_headers: flags=4 Sep 26 13:04:52 localhost ./ser[7098]: DEBUG: add_param: tag=7770e7624e56f146f4f19d50775e8c7e.230c Sep 26 13:04:52 localhost ./ser[7098]: end of header reached, state=29 Sep 26 13:04:52 localhost ./ser[7098]: DEBUG: get_hdr_field: <To> [75]; uri=[sip:5199571788@216.183.86.133] Sep 26 13:04:52 localhost ./ser[7098]: DEBUG: to body [<sip:5199571788@216.183.86.133>] Sep 26 13:04:52 localhost ./ser[7098]: DEBUG: sl_filter_ACK : local ACK found -> dropping it! Sep 26 13:04:52 localhost ./ser[7098]: DEBUG:destroy_avp_list: destroying list (nil) Sep 26 13:04:52 localhost ./ser[7098]: receive_msg: cleaning up

17 years, 7 months

[Serusers] Nathelper Ping OPTIONS

by olivier.taylor

Hello, just trying to enable the ping functionality in nathelper to send SIP message (i.e. OPTIONS) instead of 4-byte UDP packets on SER 0.9.6 and 0.10.0 as shown below, patch doesn't apply Is there another possibility to have this feature? Olivier patch -p1 < nathelper_ping.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur -x CVS nathelper/nathelper.c nathelper_ping/nathelper.c |--- nathelper/nathelper.c 2006-08-16 08:45:48.000000000 +0200 |+++ nathelper_ping/nathelper.c 2006-08-10 14:54:14.000000000 +0200 -------------------------- Patching file nathelper.c using Plan A... Hunk #1 failed at 118. Hunk #2 failed at 172. Hunk #3 failed at 193. Hunk #4 failed at 212. Hunk #5 failed at 239. Hunk #6 failed at 257. Hunk #7 failed at 267. Hunk #8 failed at 276. Hunk #9 failed at 320. Hunk #10 failed at 367. Hunk #11 failed at 1543. 11 out of 11 hunks failed--saving rejects to nathelper.c.rej Hmm... The next patch looks like a unified diff to me... T

17 years, 7 months

[Serusers] How to restrict only one call per user at the same time

by Ricardo Carvalho

Hi all, In an environment where the same user can be registered at the same time in multiple phones, how may I restrict users to only be able to make one call simultaneously? I mean... only make other call after hanging up the last one, never simultaneously made from different phones. How may I implement that? Regards, Ricardo.

17 years, 7 months

← Newer
1
...
6
7
8
9
10
11
12
...
44
Older →

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 September 2006