hi all,
Thanx for clearing my earlier doubts. Now i got a problem in lcr module.
I have a doubt regarding the gw table abd lcr table.
I'll just explain a scenario:
I have 3 gateways in grp_id '1'. and i have 1 gateway in grp_id '2'.
Now for example a prefix '11' arrives, i give grp_id as '1' and priority as '1'. Now among the three gateways that i have, which one will it choose to send the call as all the three will have the same priority. What is the logic used to resolve this situation.
Do i have to put multiple entries of same prefixes in the lcr table to have different priorities and
different groups.
Does lcr module load the contents in memory or it queries the DB everytime.
can someone please share the working example of script containing lcr properly. It would help me a lot.
Thanx a lot..
Jayesh
---------------------------------
Yahoo! Mail for Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
I have problem with RTPProxy, does someone know what is the problema?
I am using SER with RTPProxy with config in
http://www.voip-info.org/wiki-SER+example+NAThelper.
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26003]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26001]: SER: open_uac_fifo:
fifo server up at /tmp/ser_fifo...
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26004]: ERROR:
send_rtpp_command: can't read reply from a RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26004]: WARNING: rtpp_test:
can't get version of the RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26004]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26006]: ERROR:
send_rtpp_command: can't read reply from a RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26006]: WARNING: rtpp_test:
can't get version of the RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26006]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26007]: ERROR:
send_rtpp_command: can't read reply from a RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26007]: WARNING: rtpp_test:
can't get version of the RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26007]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Sep 1 01:28:24 localhost /usr/local/sbin/ser[25992]: ERROR:
send_rtpp_command: can't read reply from a RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[25992]: WARNING: rtpp_test:
can't get version of the RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[25992]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26005]: ERROR:
send_rtpp_command: can't read reply from a RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26005]: WARNING: rtpp_test:
can't get version of the RTP proxy
Sep 1 01:28:24 localhost /usr/local/sbin/ser[26005]: WARNING: rtpp_test:
support for RTP proxyhas been disabled temporarily
Hello,
as scheduled, the next release has to be in September, by the end of the
month. The next step is to freeze the CVS for a while -- this will
happen in just a few days. No new features will added, only bugfixes
must be committed. Afterwards, a branch will be created for release and
new features can be included in CVS head
So, until the cvs is frozen, it is the last chance to add something in
the upcoming release. If you have something in mind, let us know.
Testing the development version would help a lot in the next period!
Points of high interest are TLS, branch_route, acc, avpops, textops,
uac, uac_redirect ... as much as possible with pseudo-variables.
Cheers,
Daniel
Hello,
I'm using ser-0.9.3 with serweb-0.9.3 that comes with it. I used "yum
install .." command. Ser works good but i have a problem with serweb. When i
logged in I'm getting an error on the first page as "FIFO not running or bad
path to it", I searched in the list and find something but it's pending so i
can't still resolve it. Any idea?
Thanks
Erdem HAKI
Hi,
I would like to know that after setting up mediaproxy with SER, will
all calls' media stream go through the proxy? Will mediaproxy, proxy
the call only when absolutely necessary or will it proxy in all
cases? From what I understand about 80-90% of cases the rtp stream
can get through NAT using STUN.
I cannot find any information on this question on the internet.
Thanks and regards,
Vikash.
I'd like to ask to somebody with more knowledge of me if a possible
solution to NAT traversal is really feasible.
For various reasons, we DON'T want to use an RTP proxy.
We'd like to avoid the use of STUN because: 1) creates hairpin problems;
2) many UAC have a bad STUN client code implementation; 3) it requires
additional configuration by the final user.
It seems to me that with the nathelper's message rewriting functions it
is possible to solve every problem for the SIP protocol.
Moreover, as we have the REAL IP of the UA (in the original SIP
messages) we could also avoid haipin problems: it is sufficient to use
the original IP/Port of the two UAs if both have the same natted IP (ie
they are behind the same NAT). This doesn't work when the UAs are behind
multiple NATs, but this is a relatively uncommon case.
So, the unresolved problem is with the RTP data, because we don't know
what will be the NATted port so we cannot correctly mangle the SDP data
in the INVITE message.
Am I correct up to this point?
Now, I'm asking myself if it is feasible to use a "MINI RTP Proxy" that
receives the initial INVITEs, discovering the NATted RTP ports, and then
IMMEDIATLY RE-INVITE the two UAs to connect directly each other. So only
the first RTP packet is actually proxed, all subsequent traffic will be
directly between the two UAs.
I think that something similar is done by Asterisk.
Is this feasible?
If it is, then we could have a good solution to NAT Traversal:
1) No Hairpin problems (for one NAT cases)
2) No problems of the normal RTP proxy (waste of bandwidth, longer
delays, bad scalability).
3) Will work with all type of NATs except for symmetric ones (the same
that work with STUN).
4) Simpler UAC configuraton: only username, password and sip server.
Thanks.
--
___________________________________________________
__
|- giannici(a)neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________
Hello all,
I have following records in the table 'usr_preferences':
username attribute value
1000 fwdbusy sip:1001@example.de
1000 fwdnoanswer sip:1001@example.de
I use these records to get the functionallity of "Call Forwarding -
Busy" and "Call Forwarding - No Answer" into the OpenSer - server.
I use a failure_route to act on the SIP - messages "Request Timeout
(408)" and "Busy(486)" and forward the INVITE - message to the URI saved
in the table 'usr_preferences'. See my snippet of the openser.cfg:
----snip ---
failure_route[1] {
if (isflagset(27) && t_check_error(408)) {
if (avp_pushto("$ruri", "s:fwdnoanswer")) {
avp_delete("s:fwdnoanswer");
resetflag(27);
route(6);
break;
};
};
if (isflagset(26) && t_check_error(486)) {
if (avp_pushto("$ruri", "s:fwdbusy")) {
avp_delete("s:fwdbusy");
resetflag(26);
route(6);
break;
};
};
};
----snap ---
These configuration works fine.
Is there a possibillity to set a timer for the phone after the server
receives the message "Request Timeout" from the phone? Or can I let the
server ring for example five times and generate the message?
Greetings Jens
Heya,
This might be an obvious answer, but when I forward a packet to another box
using the forward() method, this seems to break the URI?
rewriteuri("sip:test@test.co.uk");
forward(x.x.x.x, 5060);
Now on my asterisk box and looking at ngrep, the test(a)test.co.uk has
disappeared, and asterisk takes the SIPDOMAIN as 'x.x.x.x', rather than
'test.com'.
Is this the desired behaviour? Is there a way to do what I want to do? I
need to be able to pick out the original SIPDOMAIN in asterisk even after
the packet has been forwarded by SER. People seem to have talked about doing
this, but I'm not sure how I can forward it without obliterating the URI.
Cheers,
Chris.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
