I have the same issue,
If I get PSTN calls from ASTERISK to SER and I want to redirect calls
from SER to voicemail on the same *, SER says loop detected. I use
two gateways to get rid of this.
If there are any ideas how to solve this from configuration of SER I
would love to hear it.
Adrian
>>>>
Andres wrote:
>
>>
>> My question is, is there any way to have ser receive a call from
>> asterisk and then reroute it back to the same asterisk server without
>> getting a "loop detected" error?
>>
> Aren't you seeing this "loop detected" on the Asterisk CLI?? If so
> should post this in the Asterisk list instead. We know this happens
> anytime you try to loop a call back to Asterisk, but its Asterisk who
> complains. Not SER.
>
Answer from the Asterisk users list :-)
No, there's not a way to do it, but maybe to issue a 302 redirect.
Haven't tried it, but that may work.
The Loop Detected stuff is annoying, yes.
/O
Hello,
I wrote a tiny module "dispatcher", able to select a destination to
relay the requests to from a set of addresses. It would compute hashes
over parts of the request (e.g., call-id) and select an address from the
destination set based on modulo function. The selected address is used
then as outbound proxy. The module could be used as a stateless load
balancer, but with no guarantee of fair distribution. It can be easily
extended (other distribution functions), but right now I have no time --
contributors will be very welcome.
Would someone be interested in such module? If yes, I will add it to cvs
very soon.
Daniel
A problem related to function fix_contact was fixed in latest CVS. Also
the sample configuration has been recently updated. Please use cvs
update in devel branch or 8.14 to get the fix and recompile the module.
Adrian
Your config calls fix_contact twice, this is why is crashing. Until
this is fixed please follow the guidelines in ser.cfg example from
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/ser/sip_router/
modules/mediaproxy/config/ser.cfg?rev=HEAD&content-type=text/plain
Adrian
>>>
here is my config any help at all work be great
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
break;
};
if (method == "REGISTER" || ! search("^Record-Route:"))
{
if (is_from_local())
{
log("LOG: Someone trying to register from private IP,
rewriting\n");
if (client_nat_test("3"))
{
setflag(2);
force_rport();
fix_contact();
};
};
};
if (method == "REGISTER")
{
save("location");
break;
};
#if (method == "INVITE")
#{
# if("!(is_from_local() || is_uri_host_local()))
# {
# sl_send_reply("403", "Relaying is forbidden");
# break;
# };
# t_on_failure("1");
#}
#else if (method == "BYE" || method == "CANCEL")
#{
# end_media_session();
#};
if (loose_route())
{
if (method == "INVITE" || method == "ACK")
{
use_media_proxy();
};
t_relay();
break;
};
# Force subsequent messages to pass through this proxy
if (method == "INVITE")
{
record_route();
};
if (client_nat_test("3") && !search("^Record-Route:"))
{
# Mark as NAT'ED
force_rport();
fix_contact();
};
if (method == "INVITE")
{
t_on_reply("1");
};
#if (is_uri_host_local())
#{
# if(!lookup("location"))
# {
# sl_send_reply("404", "User not found");
# break;
# };
#};
if (method == "INVITE" || method == "ACK")
{
use_media_proxy();
};
if (uri=~"^sip:7[0-9]{3}@.*")
{
if (is_user_in("from", "pbx"))
{
# if (isflagset(6))
#{
rewritehostport("*.*.*.*");
forward(uri:host, uri:port);
xlog("L_ERR", "LOG - method<%rm> uri<%ru> from<%fu>
to<%tu>\n");
log (1,"PSTN Call\n");
setflag(2);
break;
#};
};
};
if (!t_relay())
{
if (method == "INVITE" || method == "ACK")
{
end_media_session();
};
sl_reply_error();
};
}
failure_route[1]
{
end_media_session();
}
onreply_route[1]
{
if (status=~"(183)|(2[0-9][0-9])")
{
if (client_nat_test("1"))
{
fix_contact();
};
use_media_proxy();
};
}
> -----Original Message-----
> From: Adrian Georgescu [SMTP:ag@ag-projects.com]
> Sent: 06 August 2004 12:11
> To: Sean Lowry
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] mediaproxy + ser0.8.14 problem
>
> That sample configuration is OK. Your problem must be searched
> elsewhere.
>
>
> On Aug 6, 2004, at 12:51 PM, Sean Lowry wrote:
>
>> Umm very strange i used the example.cfg and inside there it has the
>> fix_contact in the registration, and in the client_nat_test and also
>> in te
>> onreply_route.
>>
>>
>> so what is the correct format if this is wrong.
>>
>>
>> Sean
>>
>>> -----Original Message-----
>>> From: Adrian Georgescu [SMTP:ag@ag-projects.com]
>>> Sent: 06 August 2004 11:55
>>> To: dave(a)fuuz.com
>>> Cc: serusers(a)lists.iptel.org
>>> Subject: [Serusers] mediaproxy + ser0.8.14 problem
>>>
>>> See http://lists.iptel.org/pipermail/serusers/2004-August/010420.html
>>>
>>>
>>>
>>> -------
>>> hi all,
>>>
>>>
>>>
>>> Have been trying to get media proxy to work with 0.8.14 and am not
>>> having a huge amount of joy. Basically the route processing seems to
>>> be
>>> fine, but as soon as ser attempts to actually pass traffic through
>>> media
>>> proxy it crashes out!
>>>
>>>
>>>
>>>
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Request from RFC Private IP
>>> Detected --> mediaproxy flagged
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3066]: VOICEMAIL: VM user detected -->
>>> activating VM Flag
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Caller is NAT'd
>>> (destination
>>> offline) --> enable reply processing
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Invite received -->
>>> enabling
>>> media proxy
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3052]: child process 3066 exited by a
>>> signal 11
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3052]: core was not generated
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3052]: INFO: terminating due to SIGCHLD
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3186]: INFO: signal 15 received
>>>
>>> Aug 5 15:30:13 sip /sbin/ser[3193]: INFO: signal 15 received
>>>
>>>
>>>
>>> (the same is true if the destination is online as well).
>>>
>>>
>>>
>>> I may have a problem with symmetric/asymmetric clients, but I don't
>>> think ser should actually crash like that... does anyone have any
>>> ideas?
>>>
>>>
>>>
>>>
>>> Dave << File: ATT13254.txt >>
That sample configuration is OK. Your problem must be searched
elsewhere.
On Aug 6, 2004, at 12:51 PM, Sean Lowry wrote:
> Umm very strange i used the example.cfg and inside there it has the
> fix_contact in the registration, and in the client_nat_test and also
> in te
> onreply_route.
>
>
> so what is the correct format if this is wrong.
>
>
> Sean
>
>> -----Original Message-----
>> From: Adrian Georgescu [SMTP:ag@ag-projects.com]
>> Sent: 06 August 2004 11:55
>> To: dave(a)fuuz.com
>> Cc: serusers(a)lists.iptel.org
>> Subject: [Serusers] mediaproxy + ser0.8.14 problem
>>
>> See http://lists.iptel.org/pipermail/serusers/2004-August/010420.html
>>
>>
>>
>> -------
>> hi all,
>>
>>
>>
>> Have been trying to get media proxy to work with 0.8.14 and am not
>> having a huge amount of joy. Basically the route processing seems to
>> be
>> fine, but as soon as ser attempts to actually pass traffic through
>> media
>> proxy it crashes out!
>>
>>
>>
>>
>>
>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Request from RFC Private IP
>> Detected --> mediaproxy flagged
>>
>> Aug 5 15:30:13 sip /sbin/ser[3066]: VOICEMAIL: VM user detected -->
>> activating VM Flag
>>
>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Caller is NAT'd (destination
>> offline) --> enable reply processing
>>
>> Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Invite received --> enabling
>> media proxy
>>
>> Aug 5 15:30:13 sip /sbin/ser[3052]: child process 3066 exited by a
>> signal 11
>>
>> Aug 5 15:30:13 sip /sbin/ser[3052]: core was not generated
>>
>> Aug 5 15:30:13 sip /sbin/ser[3052]: INFO: terminating due to SIGCHLD
>>
>> Aug 5 15:30:13 sip /sbin/ser[3186]: INFO: signal 15 received
>>
>> Aug 5 15:30:13 sip /sbin/ser[3193]: INFO: signal 15 received
>>
>>
>>
>> (the same is true if the destination is online as well).
>>
>>
>>
>> I may have a problem with symmetric/asymmetric clients, but I don't
>> think ser should actually crash like that... does anyone have any
>> ideas?
>>
>>
>>
>>
>> Dave << File: ATT13254.txt >>
See http://lists.iptel.org/pipermail/serusers/2004-August/010420.html
-------
hi all,
Have been trying to get media proxy to work with 0.8.14 and am not
having a huge amount of joy. Basically the route processing seems to be
fine, but as soon as ser attempts to actually pass traffic through media
proxy it crashes out!
Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Request from RFC Private IP
Detected --> mediaproxy flagged
Aug 5 15:30:13 sip /sbin/ser[3066]: VOICEMAIL: VM user detected -->
activating VM Flag
Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Caller is NAT'd (destination
offline) --> enable reply processing
Aug 5 15:30:13 sip /sbin/ser[3066]: NAT: Invite received --> enabling
media proxy
Aug 5 15:30:13 sip /sbin/ser[3052]: child process 3066 exited by a
signal 11
Aug 5 15:30:13 sip /sbin/ser[3052]: core was not generated
Aug 5 15:30:13 sip /sbin/ser[3052]: INFO: terminating due to SIGCHLD
Aug 5 15:30:13 sip /sbin/ser[3186]: INFO: signal 15 received
Aug 5 15:30:13 sip /sbin/ser[3193]: INFO: signal 15 received
(the same is true if the destination is online as well).
I may have a problem with symmetric/asymmetric clients, but I don't
think ser should actually crash like that... does anyone have any ideas?
Dave
Make sure you don't call fix_contact twice. This will crash SER.
Adrian
----------
Hi there.
I'm having a few issues with media proxy.
when i load ser it works fine, and users can register but as soon as
then
make a call it kills ser.
error log below
error log below
2(6938) DEBUG: t_reply: finished
22(6938) DEBUG: mk_proxy: doing DNS lookup...
22(6938) parse_headers: flags=2048
22(6938) parse_headers: flags=-1
22(6938) clen_builder: content-length: 272 (272)
22(6938) check_via_address(212.9.98.1, 192.168.1.68, 0)
35(7006) DBG: tcp_main_loop: dead child 22 (shutting down?)
0(6889) child process 6938 exited by a signal 11
0(6889) core was not generated
0(6889) INFO: terminating due to SIGCHLD
1(6891) INFO: signal 15 received
1(6891) Memory status (pkg):
1(6891) fm_status (0x80d9820):
1(6891) heap size= 1047440
1(6891) dumping free list:
1(6891) hash = 1 fragments no.: 8,
bucket size: 8 - 8 (first 8)
1(6891) 7(6905) INFO: signal 15 received
7(6905) Memory status (pkg):
3(6893) INFO: signal 15 received
3(6893) 9(6910) INFO: signal 15 received
9(6910) Memory status (pkg):
9(6910) fm_status (0x80d9820):
9(6910) heap size= 1047440
9(6910) dumping free list:
11(6914) INFO: signal 15 received
11(6914) Memory status (pkg):
14(6921) INFO: signal 15 received
13(6917) INFO: signal 15 received
16(6925) INFO: signal 15 received
15(6922) INFO: signal 15 received
15(6922) Memory status (pkg):
15(6922) 27(6989) INFO: signal 15 received
17(6928) INFO: signal 15 received
17(6928) 33(7002) Memory status (pkg):
17(6928) fm_status (0x80d9820):
34(7005) 17(6928) INFO: signal 15 received
34(7005) Memory status (pkg):
34(7005) fm_status (0x80d9820):
34(7005) 20(6933) INFO: signal 15 received
20(6933) Memory status (pkg):
does anyone have any idea's
Sean
Hello,
There is a new document available describing the FIFO protocol of SER in
detail. The document describes the basics of FIFO communication, how to write
an application that will communicate with SER and it lists most of the commands
available in SER and their syntax.
I have not integrated the document into SER docuementation yet,
you can get preview from:
http://iptel.org/~janakj/fifo.pdf
Any feedback is appreciated.
Jan.
Hello everyone,
I have a question regarding auth_radius module Documentation:
Shouldn't Example 1-3 in
http://www.iptel.org/ser/doc/modules/html/auth_radius.html#AEN77
read
if (! radius_www_authorize("iptel.org")) {
www_challenge("iptel.org", "1");
};
instead of
if (radius_www_authorize("iptel.org")) {
www_challenge("iptel.org", "1");
};
?
After all, Section 4.1 of the SIP Express Router RADIUS HOWTO
says that one can simply replace www_authorize with
radius_www_authorize. www_authorize however uses the negation
operator. Am I missing something?
I assume this is simply typo in the documentation, but it leads
to some confusion. Can you fix it?
Cheers,
Marcel
