sr-users October 2009

sr-users@lists.kamailio.org

63 participants
105 discussions

by Siddhardha Garige

Hello all, Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio. Especially creating partitions, DRBD devices and mount points. Thanks in advance, -Sid "May the light be with you." ______________________________________________ Siddhardha Garige www.luminepixels.com

9 years, 5 months

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error

by vivi

Hi all.. I have solve the problem . Cheers, vivi From: vivi [mailto:vivi.hilton@gmail.com] Sent: Saturday, June 06, 2009 11:29 PM To: 'users(a)lists.kamailio.org' Subject: /usr/local/sbin/kamdbctl create error Hi all I have specify the wanted db type (DBENGINE=MYSQL) in the /usr/local/etc/kamailio/kamctlrc then I using "/usr/local/sbin/kamdbctl create" to create MySQL database, but I got this error: ERROR: database engine not specified, please setup one in the config script root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim /usr/local/etc/kamailio/kamctlrc root@acer:/usr/local/src/kamailio-1.5.0/sip-server# /usr/local/sbin/kamdbctl create MySQL password for root: INFO: test server charset ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR: Creating core database and grant privileges failed! Cheers, vivi

10 years, 2 months

[Kamailio-Users] AudioCodes + Kamailio : Problem in SIP Message Headers

by Samuel Muller

Hello all, I recently add a classical Audiocodes Mediant 2000 with 2x 8E1, the purpose is to have several interconnections with PSTN. I configured it like this : Audiocodes registers as a gateway to the Kamailio, using a dedicated port (5062). Registration seems to be OK, and the pstn gw uses OPTIONS method to ping the proxy. I can attack the Audiocodes with a SIP phone behind Kamailio, no pbm. But the audiocodes returns some errors about SIP headers sent by Kamailio : ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected Here you have the example of an INVITE from a SIP phone to the PSTN : ** audiocodes debug ** 4d:12h:30m:26s ( lgr_flow)(44730 ) ---- Incoming SIP Message from 77.246.81.132:5060 ---- INVITE sip:0323719001@77.246.81.136:5062;transport=udp SIP/2.0 Record-Route: <sip:77.246.81.132;lr=on;ftag=71078b346a20fb3eo0;nat=yes> Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bKdace.1ab1d59.0 Via: SIP/2.0/UDP 192.168.0.113:5060;rport=15170;received=77.246.81.162;branch=z9hG4bK-b432f96 From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr>>;tag=71078b346a20fb3eo0 To: <sip:0323719001@sip.720.fr <sip%3A0323719001(a)sip.720.fr>> Call-ID: 944d8aec-27503ee6(a)192.168.0.113 CSeq: 102 INVITE Max-Forwards: 49 Contact: "Sam" <sip:0123451010@77.246.81.162:15170> Expires: 240 User-Agent: Linksys/SPA941-5.1.8 Content-Length: 281 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, replaces Content-Type: application/sdp P-Asserted-Identity: <0123451010> Remote-Party-ID: <0123451010>;party=caller;privacy=none;screen=yes v=0 o=- 26933860 26933860 IN IP4 192.168.0.113 s=- c=IN IP4 77.246.81.133 t=0 0 m=audio 35038 RTP/AVP 18 0 8 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=nortpproxy:yes ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected ( sip_stack)(44734 ) !! [ERROR] Message type: INVITE [Time: 12:30:26] ( sip_stack)(44735 ) !! [ERROR] Source header: [Time: 12:30:26] ( sip_stack)(44736 ) !! [ERROR] Line: 17. Column: 23 [Time: 12:30:26] The outgoing INVITE from Kamailio is exactly the same received by the AudioCodes. When I searched over Google, I just found 2 answers about Asterisk / Audiocodes unsolved problem, but no more informations. I supposed that the problem is as indicated : " s=- " where source is empty in place of "NULL" / "0" or something like this ... Someone can confirm or already met the problem ? Many thanks all :) .Sam.

12 years, 3 months

[Kamailio-Users] Having problems using RTPProxy to bridge internal/external networks

by Joe Hart

Hi all, For a project on which I'm currently working, I am having some problems figuring out how to correctly configure Kamailio to communicate with RTP Proxy in order to send media into and out of a network with private IP address ranges. I have a proxy set up to send the SIP traffic, and all of this is working fine. However, I'm having some trouble getting the RTP Proxy set up. Currently, when the call is connected, the offer/answer is made and RTP Proxy seems to be taking over, but I'm having trouble getting my audio to flow in both directions. Examination of the traffic coming into and out of this machine seems to indicate that the IP addresses aren't being mangled correctly. Specifically, it appears the internal IP address isn't being changed to reflect the IP address of the machine on which RTP Proxy is running, so that when the caller tries to send audio back, the IP it's given to reply to is 10.10.x.x, which obviously won't work. I have tried experimenting with specifically setting IP addresses in the rtpproxy_offer() and _answer() methods to no avail, as well as setting various flags in those methods. However, I must admit that I'm not entirely sure what's happening under the hood with these methods, or what rtpproxy is doing with that information when it gets it. Rather than continue to hack at this by trial and error, I'm hoping someone here can point me in the right direction. Any advice, example code or pep talks would be greatly appreciated. Thanks in advance, -- Joe Hart Voice Systems Integrator Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0673

12 years, 3 months

[OpenSER-Users] uaCSTA support in openser

by Hugo Koblmueller

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

13 years, 10 months

[Kamailio-Users] kamailio and PRACK

by BERGANZ François

Hello, Does kamailio support PRACK method ? If yes, how? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

14 years, 4 months

[Kamailio-Users] Carrierroute issue

by michel freiha

Hi all, I'm using carrierroute module and ie seems that it's not working well...Suppose I have 2 entries in carrierroute table...Entry 1 with scan prefix 00 and prob 0 and a second entry with scan prefix 00 and prob=1...As soon as i make a call, this call will be forwarded to the entry with prob 0 because i guess it appears before the one with prob 1 in the table... When starting Kamailio I got the below: Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 1, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: domain 0 not found, add it Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_tree: tree default has 1 trees Jul 29 12:30:11 [23143] DBG:carrierroute:add_route_tree: tree 0Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: created route tree: 0, with id 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 00, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 111, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 00, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix 011, prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: adding prefix , prob -14931260.000000 Jul 29 12:30:11 [23143] INFO:carrierroute:get_route_tree: found domain 0 Jul 29 12:30:11 [23143] INFO:carrierroute:add_route: found route, now adding Jul 29 12:30:11 [23143] INFO:carrierroute:add_route_rule: no backed up rules It seems that kamailio is not reading probability entry in carrier route table Please find below carrierroute table structure: CREATE TABLE IF NOT EXISTS `carrierroute` ( `id` int(10) unsigned NOT NULL auto_increment, `carrier` int(10) unsigned NOT NULL default '0', `domain` varchar(64) NOT NULL default '', `scan_prefix` varchar(64) NOT NULL default '', `flags` int(11) unsigned NOT NULL default '0', `mask` int(11) unsigned NOT NULL default '0', `prob` float NOT NULL default '0', `strip` int(11) unsigned NOT NULL default '0', `rewrite_host` varchar(128) NOT NULL default '', `rewrite_prefix` varchar(64) NOT NULL default '', `rewrite_suffix` varchar(64) NOT NULL default '', `description` varchar(255) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=23 ; Can someone help me to find this issue? Regards

14 years, 10 months

[Kamailio-Users] tcp_blocking_connect related errors and Kamailio using 100% CPU

by Pascal Maugeri

Hi Using Kamailio 1.5 we periodically get the following errors: Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (110) Connection timed out Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_send: connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:tm:msg_send: tcp_send failed They are several emails in this mailing list explaining we should play with tcp parameters. I will try to change my configuration and see if we can solve this issue. But when this kind of error happen we observe that the kamailio processes are using 100% of CPU (top). Our client is using SIP over TCP only (no UDP). Do you have any hint on how to configure Kamailio to improve TCP support ? Is it normal to kamailio processes to overload CPU ? Regards, Pascal

14 years, 11 months

[Serusers] Via: branch tags from SER for CANCELs/BYEs frequently don't match value in the INVITE

by Frank Durda IV

As you may recall, this is a problem where frequently (well, virtually all of the time) when SER passed a BYE or CANCEL message through, the device receiving such messages from SER would reject them, because the Via: header line that SER added to the BYE or CANCEL message didn't match the one that SER added to the INVITE message sent earlier. I brought this up a couple of times in the list previously. As there was not any response on this point at all, I have done some digging and have a simplified example and analysis of what SER appears to be doing wrong. First, here is an example of the problem occurring. Here are key header lines from the INVITE and a BYE message of a sample call: INVITE INPUT TO SER From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE SER EMITTED THIS INVITE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone> Call-ID: 16305237000a0285 CSeq: 252558264 INVITE BYE INPUT TO SER (from calling party) Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE SER EMITTED THIS BYE (to called party) Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 Call-ID: 16305237000a0285 From: <sip:9715551212@10.11.12.13;isup-oli=62;user=phone>;tag=000a0285+1+9c6d0174+ff665515 To: <sip:3719110000@10.20.30.40;user=phone>;tag=15358744 CSeq: 252558265 BYE The called switch rejects the BYE with a 481 because top-most Via: in the BYE does not match the one from the INVITE. Here are the two VIAs added by SER that do not match: INVITE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKe47c.7be033a8ca37f0e8a1c6bfe63b043efe.0 BYE Via: SIP/2.0/UDP 66.77.88.99;branch=z9hG4bKf47c.c79c6922afd022e9b4cdf00110f17fd5.0 A review of how SER constructs the branch=nnnn value reveals where the differences are coming from: #1. e47c vs f47c difference caused by the Cseq: number changing between INVITE and BYE messages. The Cseq: value is supposed to be different in the INVITE and BYE per RFC 3261. The Cseq: should not be used in generating the branch=nnnn value. In this example, the BYE just happened to get the very next sequence number, but it will always be a value other than the sequence number seen in the INVITE. #2. 7be033a8ca37f0e8a1c6bfe63b043efe vs c79c6922afd022e9b4cdf00110f17fd5 is caused by ;tag=15358744 added to BYE To: header line. At minimum, any tags present on the To: and From: header should not be used in generating the branch=nnnn value because of the handling of tags in called-party-BYE situations. Also, there is no requirement in RFC 3261 that the To: nor From: header lines be used in generating the branch=nnnn value at all. Based on what I am seeing, it appears that neither the Cseq: nor the complete To: or From: header lines should have ever been used in constructing a branch=nnnn value, because of the adverse affects on CANCEL and BYE messages. Four things appear to be key to causing the branch=nnnn computation to generate non-compliant results in this example, as well as the case of a CANCEL message sent prior to the completion of the INVITE. (There could be other scenarios.) #1. The Cseq: value of the BYE will be different than the INVITE (per RFC 3261). The Cseq: header line should not ever be used in generation the hash for a branch=nnnn value as it will prevent the branch in BYE from matching the one in the INVITE. #2. If the called party generated the BYE message, the tags on the To: and From: header lines will be exchanged (also per RFC 3261), so the entire To: and From: header line's content cannot be used for generating a hash for a branch=nnnn value that is expected to match earlier messages that had a branch=nnnn value computed prior to the tag swap. #3. If a tag was previously absent on the To:/From:, a BYE from either party will add one. Again, the entire To: and From: header lines cannot be used for generating a hash for a branch=nnnn value that matches earlier messages prior to the addition of any tag. #4. Any deviation in the From: and To: header lines between INVITE and BYE/CANCEL will yield a different branch=nnnn value, even though the parameters of the From: and To: header lines may still be perfectly legal and technically identical. Any deviation may be the result of a sloppy SIP implementation in the calling equipment, but isn't valid grounds for not handling the message correctly. Examples include things like alternate number formats (as in To: sip:8885551212@66.77.88.99:5060 (seen in INVITE) versus To: <sip:8885551212@66.77.88.99:5060> (seen in CANCEL from same calling device), or differences in the amount of whitespace (including trailing whitespace), which is supposed to be ignored in SIP messages but the MD5 generator doesn't appear to know that it should ignore whitespace. Any one or a combination of these items (and possibly others) will cause the current branch=nnnn generation code in SER to generate a different branch=nnnn value and a receiving system who is following RFC 3261 will reject the BYE or CANCEL message that has passed through SER. This is non-compliant behavior. For BYE, you only get into this situation if you are using Record-Route to force the BYE message to pass through SER so that it can tear down the call (unforce_rtp_proxy() and similar actions), but for a CANCEL message, anybody can run into this problem, if syn_branch=0. So, while this defect in the branch=nnnn generation doesn't affect everybody, it still appears to be wrong. Is there by chance a compliant version of char_msg_val() exists that doesn't have these issues? That is, it doesn't use the Cseq: header line, and if it uses the From: or To: header line at all, it computes using only the called/calling digits, and not anything else that may appear on those header lines. I also don't understand why this is being MD5'ed. The RFC only says that the branch must be unique, and there are lots of cheaper has algorithms out there. Thanks for reading this far and thanks in advance for anyone who has fixed this or can come up with a fix.

15 years

[Kamailio-Users] Kamailio RTP Proxy issues

by General Lee

Hi, I am currently integrating an H323 to SIP gateway with Kamailio and trying to route all calls through RTP Proxy. I have a problem where RTP Proxy treats both the incoming H323 gateway call (Caller) and outgoing SIP call (Callee) as the 'caller' in the RTP Proxy syslog. RTP Proxy doesn't assign a 'callee' therefore not able to setup a call (See syslog below). I have configured Kamailio to accept the 'ACK' with SDP and this is working correctly. When I enable H323 Fast connect and the SDP is included in the INVITE, the call connects correctly and is routed through RTP Proxy. I feel the problem is related to RTP Proxy receiving an INVITE from the H323-SIP gateway without SDP. Can anyone explain why RTP Proxy treats both the incoming H323 Gateway call and outgoing SIP call as the 'caller' in the RTP Proxy syslog. How can I make RTP Proxy treat the incoming H323 call as the 'callee'? Thanks, More information below ******************************************************************************* My H323 endpoints use H323 Slow Connect, so when the H323-SIP Gateway delivers the 'INVITE' to Kamailio there is no SDP included in the INVITE. I added a 'onreply_route' to the Kamailio configuration file which handles the 'ACK' with SDP which is working correctly. All of my SIP calls (Signalling + Media) are forced though RTP Proxy and I would like to force all H323-SIP Gateway calls through RTP Proxy. When placing a call from my H323 endpoint to my SIP UA, the RTP Proxy syslog records the incoming and outgoing call, however RTP Proxy states that the ‘callee’ is actually the 'caller'. The RTP Proxy syslog also states that the caller is the caller so there is no 'callee' (see below). In the syslogs both the ‘callee’ and ‘caller’ are recognised as the ‘caller’ so RTP Proxy has no callee to send the traffic back to. When the INVITE is received the ‘callee’ is populated in the syslogs as the ‘caller’. The H323 Gateway call is not recorded until after the ‘ACK’ with SDP is received from the gateway. Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 (Should be callee) Oct 27 17:33:05 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 (Should be callee) Then after the ‘ACK’ is received from the Gateway, the H323 call is mentioned in the syslog as well as the other caller who is supposed to be the callee. Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10204 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 69.72.11.51:10214 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49620 Oct 27 17:33:06 rtpproxy[24086]: INFO:handle_command: pre-filling caller's address with 72.19.211.106:49622 -- View this message in context: http://www.nabble.com/Kamailio-RTP-Proxy-issues-tp26112049p26112049.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

15 years

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 October 2009