sr-users April 2007

sr-users@lists.kamailio.org

177 participants
272 discussions

[Users] Serweb + OpenSER 1.2.0 with postgres

by Joao Pereira

Hello is someone using serweb with OpenSER 1.2.0 and postgres? I want to know if it is possible. I tried the version in http://voip-info.org/wiki/view/OpenSER+1.1.x+and+SerWEB+0.9.4 but it isn't working and this error happens: Function aggregate_methods() doesn't exists. Try install Classkit extension. http://pecl.php.net/package/classkit I already tried classkit and the problem remains. Is someone using serweb + OpenSER 1.2.0 + postgres? Thanks regards Joao Pereira -- ______________________________________________ João Gomes Pereira FCCN Av. do Brasil, nº 101 1700-066 Lisboa tel: +351 218 440 100 - fax: +351 218 472 167 email|SIP: joao.pereira(a)fccn.pt http://www.fccn.pt ______________________________________________ --- Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218 440 100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218 440 100 and delete it immediately. ---

17 years, 7 months

Re: [Users] openser + nathelper + rtpproxy w/ ekiga

by Ben Racher

openser is not behind my NAT (see the dump, it has a public IP), wouldn't that defeat the purpose of nathelper? one of my clients is behind the NAT, the other isn't. some of the SDP flags appear to be correct, but I myself am still new enough to SIP that i can't tell what my SDP flags should be like coming out of the openser box. it appears to be correct, could you please take a look at the dump and tell me what specific transactions are causing it to fail? ben raviprakash sunkara wrote: > Hi > did U Check the sdp flags, nathelper modules in fixed_nated_sdp and > force_rtp_proxy flag,,,,,,, > > time interval to alive the natter.............. > > > is ur OpenSER is Behind the NAT, and Urs Users are also in Behind NAT > > > > On 4/19/07, *Ben Racher* <mack.stout(a)gmail.com > <mailto:mack.stout@gmail.com>> wrote: > > I'm trying to use openser's (1.1.1) default nathelper.cfg to > connect two > ekiga clients. One is behind a NAT. Both can contact each other, > but the > media streams (neither video nor audio) don't seem to be setup for > some > reason. rtpproxy registers that it should setup the connection, but it > doesn't seem to take off past that. > > here's an ngrep dump of the NAT'd client calling the other, and could > appreciate some wisdom on what I need to fix and what the problem is. > thanks. > > -------- > > U 2006/04/20 00:11:09.663917 209.91.15.175:5071 > <http://209.91.15.175:5071> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > INVITE sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110> SIP/2.0. > Date: Thu, 19 Apr 2007 04:44:30 GMT. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport. > > User-Agent: Ekiga/2.0.3. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110>>. > Contact: <sip:test_store@192.168.0.25:5071;transport=udp>. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Type: application/sdp. > Content-Length: 227. > Max-Forwards: 70. > . > v=0. > o=- 1176957870 1176957870 IN IP4 192.168.0.25 <http://192.168.0.25>. > s=Opal SIP Session. > c=IN IP4 192.168.0.25 <http://192.168.0.25>. > t=0 0. > m=audio 5006 RTP/AVP 101. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > m=video 5008 RTP/AVP 31. > a=rtpmap:31 H261/90000. > > > U 2006/04/20 00:11:09.673012 209.91.15.110:5060 > <http://209.91.15.110:5060> -> 209.91.15.175:5071 > <http://209.91.15.175:5071> > SIP/2.0 100 trying -- your call is important to us. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071;received=209.91.15.175 > <http://209.91.15.175>. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: < sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110>>. > Server: OpenSer (1.1.1-notls (i386/linux)). > Content-Length: 0. > Warning: 392 209.91.15.110:5060 <http://209.91.15.110:5060> "Noisy > feedback tells: pid=4047 > req_src_ip= 209.91.15.175 <http://209.91.15.175> req_src_port=5071 > in_uri=sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110> > out_uri=sip:test@209.91.15.19:5074;transport=udp via_cnt==1". > . > > > U 2006/04/20 00:11:09.673822 209.91.15.110:5060 > <http://209.91.15.110:5060> -> 209.91.15.19:5074 > <http://209.91.15.19:5074> > INVITE sip:test@209.91.15.19:5074;transport=udp SIP/2.0. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > Date: Thu, 19 Apr 2007 04:44:30 GMT. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;received=209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > > User-Agent: Ekiga/2.0.3. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110>>. > Contact: <sip:test_store@209.91.15.175:5071;transport=udp>. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Type: application/sdp. > Content-Length: 270. > Max-Forwards: 69. > P-hint: usrloc applied. > . > v=0. > o=- 1176957870 1176957870 IN IP4 192.168.0.25 <http://192.168.0.25>. > s=Opal SIP Session. > c=IN IP4 209.91.15.110 <http://209.91.15.110>. > t=0 0. > m=audio 35000 RTP/AVP 101. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > m=video 35002 RTP/AVP 31. > a=rtpmap:31 H261/90000. > a=direction:active. > a=nortpproxy:yes. > > > U 2006/04/20 00:11:09.678496 209.91.15.19:5074 > <http://209.91.15.19:5074> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > SIP/2.0 100 Trying. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0. > Via: SIP/2.0/UDP > 192.168.0.25:5071 <http://192.168.0.25:5071>;received= > 209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110>>. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Length: 0. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > > > U 2006/04/20 00:11:09.801370 209.91.15.19:5075 > <http://209.91.15.19:5075> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > SIP/2.0 100 Trying. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;received=209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Length: 0. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > > > U 2006/04/20 00:11:09.824859 209.91.15.19:5075 > <http://209.91.15.19:5075> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > SIP/2.0 502 Bad Gateway. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0 . > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;received=209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Length: 0. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > > > U 2006/04/20 00:11:09.827826 209.91.15.110:5060 > <http://209.91.15.110:5060> -> 209.91.15.19:5074 > <http://209.91.15.19:5074> > ACK sip:test@209.91.15.19:5074;transport=udp SIP/2.0. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > CSeq: 1 ACK. > User-Agent: OpenSer (1.1.1-notls (i386/linux)). > Content-Length: 0. > . > > > U 2006/04/20 00:11:09.828858 209.91.15.110:5060 > <http://209.91.15.110:5060> -> 209.91.15.175:5071 > <http://209.91.15.175:5071> > SIP/2.0 502 Bad Gateway. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;received=209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > From: "Test Store" > < sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Length: 0. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > > > U 2006/04/20 00:11:09.847970 209.91.15.175:5071 > <http://209.91.15.175:5071> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > ACK sip:test@209.91.15.110 <mailto:sip:test@209.91.15.110> SIP/2.0. > CSeq: 1 ACK. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Length: 0. > Max-Forwards: 70. > . > > > U 2006/04/20 00:11:10.209491 209.91.15.19:5075 > <http://209.91.15.19:5075> -> 209.91.15.110:5060 > <http://209.91.15.110:5060> > SIP/2.0 200 OK. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP 209.91.15.110 > <http://209.91.15.110>;branch=z9hG4bK393e.770a5756.0. > Via: SIP/2.0/UDP > 192.168.0.25:5071 > <http://192.168.0.25:5071>;received=209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: < sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > Contact: <sip:test@209.91.15.19:5075;transport=udp>. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Type: application/sdp. > Content-Length: 153. > Record-Route: > <sip:209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > v=0. > o=- 1176929527 1176929527 IN IP4 209.91.15.19 <http://209.91.15.19>. > s=Opal SIP Session. > c=IN IP4 209.91.15.19 <http://209.91.15.19>. > t=0 0. > m=video 5012 RTP/AVP 31. > a=rtpmap:31 H261/90000. > > > U 2006/04/20 00:11:10.210568 209.91.15.110:5060 > <http://209.91.15.110:5060> -> 209.91.15.175:5071 > <http://209.91.15.175:5071> > SIP/2.0 200 OK. > CSeq: 1 INVITE. > Via: SIP/2.0/UDP > 192.168.0.25:5071 <http://192.168.0.25:5071>;received= > 209.91.15.175 > <http://209.91.15.175>;branch=z9hG4bK9280b754-9eec-db11-9dcc-00187185e000;rport=5071. > From: "Test Store" > <sip:test_store@209.91.15.110 > <mailto:sip:test_store@209.91.15.110>>;tag=a84faa54-9eec-db11-9dcc-00187185e000. > > Call-ID: 3a45aa54-9eec-db11-9dcc-00187185e000(a)192.168.0.25 > <mailto:3a45aa54-9eec-db11-9dcc-00187185e000@192.168.0.25>. > To: <sip:test@209.91.15.110 > <mailto:sip:test@209.91.15.110>>;tag=0a37f656-5cec-db11-9452-001372710463. > > Contact: <sip:test@209.91.15.19:5075;transport=udp>. > Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE. > Content-Type: application/sdp. > Content-Length: 173. > Record-Route: > <sip: 209.91.15.110 > <http://209.91.15.110>;lr=on;ftag=a84faa54-9eec-db11-9dcc-00187185e000>. > . > v=0. > o=- 1176929527 1176929527 IN IP4 209.91.15.19 <http://209.91.15.19>. > s=Opal SIP Session. > c=IN IP4 209.91.15.110 <http://209.91.15.110>. > t=0 0. > m=video 35004 RTP/AVP 31. > a=rtpmap:31 H261/90000. > a=nortpproxy:yes. > > > > _______________________________________________ > Users mailing list > Users(a)openser.org <mailto:Users@openser.org> > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > -- > Thanks and Regards > Ravi Prakash Sunkara > ravi.sunkara(a)hyperion-tech.com <mailto:ravi.sunkara@hyperion-tech.com> > M:+91 9985077535 > www.hyperion-tech.com <http://www.hyperion-tech.com> > Client and Parent company :- www.august-networks.com > <http://www.august-networks.com>

17 years, 7 months

[Users] presence: dealing with publish

by Cesc

Hi, I am using openser1.2 If the presence module receives a PUBLISH: - without E-Tag, it gets stored and if needed, a NOTIFY is generated ... works for me. - with an E-tag, for which this openser has not seen the first PUB (the one without E-tag) ... it gets discarded/ignored? How is the e-tag used in processing publishes and then generating notifies? I ask this because in my (peculiar) setup with two openser's sending publish to each other, depending on the order I start the elements (2 phones, 2 opensers), I don't get always a working behavior: - if the opensers are running before the phones start ... no problem ... I guess as they see the PUB without e-tag, it all goes fine - if the boot order is : openser1 ... then phone 1 ... sometime after (enough to miss the first PUB without e-tag) ... openser2 ... then phone2 ... Phone 2 does not receive NOTIFYs of status changes from phone1, eventhough the PUBlish messages do get to openser2 ... but somehow, they get "discarded" ... Regards, Cesc

17 years, 7 months

[Users] corrupted From with uac_replace_from in case of re-invite

by tele

Hi all, I'm occured in this problem already seen here: http://www.openser.org/pipermail/users/2006-March/003540.html My problem occured between two different UA and only in case of a Re-INVITE for a T.38 fax communication. Im' using openser 1.2.0. I'm doing some translation with From for a correct CLI screening. I'm also checked that the RR parameters are correctly mirrored. find attached here the debug.log and a network trace. thank you :tele

17 years, 7 months

[Users] Using OpenSER as SIP Proxy over NAT

by Saar Carmi

Hi I need to use the SER proxy over NAT. For that, I only need that all SIP communcation between SER and other Sip Server will always work on a single port - altough the SIP client that connects SER use different port for REGISTER and INVITE Is it possible? Thank you Saar Carmi -- Saar Carmi Mobile: 054-7782417 Email: saarcarmi(a)gmail.com

17 years, 7 months

[Serusers] module documentation - new search page

by Marcin Pazdro

Hi all, I would like to encourage you to test and use new module search page. It was placed here http://www.iptel.org/ser/doc/search Additionally some links to this page were added by greger in appropriate places across the iptel.org portal. Note that search-page is constructed using AJAX "technology" and used frameworks limit the amount of browsers that may correctly display this page. Supported browsers are: - IE >= 6; - Opera >= 9; - FF >= 1.6; Should you experience any problems or if you have any comments or suggestions, please let me know. If you are unable to use it (because of browser) and you would like to have a search page that support even lynx and have similar functionalities like described in this functional specification: http://www.iptel.org/ser_documentation_dynamic_search_page_functional_speci…, write to me too. If there will be huge demand for less interactive but more universal and better supported version of that search page I will consider creating it. Best regards, Marcin :)

17 years, 7 months

[Users] IBM machines Supports the OpenSER as production

by raviprakash sunkara

Hello Users, I want to know , is OpenSER supports Highly expensive IBM machines for the VoIP services. the Machines like IBM System p™ servers IBM IntelliStation(r) POWER™ IBM BladeCenter(r) IBM System i5™, eServer™ i5 and eServer™ iSeries™ systems These are Unix I need to install Fedora Core 6 or 5 or SUSE linux into them, Please help me ........................ -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 www.hyperion-tech.com Client and Parent company :- www.august-networks.com

17 years, 7 months

[Users] NEW FEATURE: DNS-based failover

by Bogdan-Andrei Iancu

Hi everybody, OpenSER 1.2.0 has now the capability to do DNS based failover, according to RFC3263 (http://www.ietf.org/rfc/rfc3263.txt). The SIP resolver was enhanced to to be able to save and resume later the DNS queries in order to get all possible IP destinations. The resolving process is step-by-step done (get next IP only on demand) to minimize the total number of DNS queries. So having this support does not imply, in normal processing, more load on the DNS server. Additional queries are done only when needed (after failure detected). The scanning for new IP destinations is done by the SIP resolver on all DNS levels: NAPTR, SRV, A. Both core and TM are using this new feature. In core, the stateless forwarding can do only DNS-based failover at transport level (if no egress interface found or send operation failed due whatever reason). In TM, the DNS-based failover is extended to transaction level. If the transaction completes with 503 or 408 with no reply, automatically, a new branch will be fork if any destination IP can be found by the DNS resolver. Read more here http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103 For controlling this feature use: - newly added core parameter "disable_dns_failover" - use to generally disable the DNS-based failover. By default is false. - in TM, t_relay() take a new flag for turning off the DNS-based failover. This setting is per transaction. By default, the failover is done. Any feedback is appreciated. regards, Bogdan

17 years, 7 months

[Users] avp_db_query doesn't work with DBTEXT???

by Daryl Sanders

I cannot seem to get avp_db_query to work with dbtext. My query looks like this.. avp_db_query("SELECT uuid FROM subscriber WHERE username = '$rU'", "$avp(s:callee_uuid)"); I receive the following error: avpops:db_query_avp: error - cannot do the query Are there any other options for doing a query on a dbtext table from within the config? Thanks, Daryl

17 years, 7 months

[Users] nathelper openser 1.2, change all c= in SDP

by laurent schweizer

Hello, I use opsnser 1.2 with nathelper and I see that not all c= in the SDP are changed. with some user agent it's ok but for some else, this is a problem. any solutions ? flag ? Laurent exemple: SDP in the 200 ok modified with nathelper (openser -> UA ) v=0.o=CiscoSystemsSIP-GW-UserAgent 5635 2443 IN IP4 xxx.xxx.127.1.s=SIP Call.c=IN IP4 xxx.xxx.127.1.t=0 0.m=audio 43594 RTP/AVP 8 106.c=IN IP4 yyy.yyy.14.234.a=rtpmap:8 PCMA/8000.a=rtpmap:106 telephone-event/8000.a=fmtp:106 0-15.a=ptime:20.a=nortpproxy:yes..

17 years, 7 months

← Newer
1
...
10
11
12
13
14
15
16
...
28
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 April 2007