Hi!
Is it possible to limit the ringing duration? For example to give up before
going to the called number voicemail...
Thanks in advance,
Michel
________________________________________________
Message sent using UebiMiau 2.7.8
Hi!
I suspect openser to have TCP problems under high load:
Scenario: sipp sends INVITE to openser, which replies with 404
I have 4x sipp with 1000 INVITEs/s and 1x sipp with 3000INVITEs/s, thus
5 TCP connections
After some time, I get error on the TCP connection with 3000INVITEs/s:
-->syslog.txt
Looks like the first part of the request is missing, but sniffing
revealed that the request is proper formated as you see in the TCP
packet -->ngrep.txt
Are there known high-load problems?
Any ideas how I can debug this?
regards
klaus
Anyone know how to use dial plan to play messages as soon as a phone is picked up. Like when a user picks up a phone, get a message to contact administrator instead of a dial tone?
Hi,
I would like to know if it's possible to set a ringing timeout for
particular calls?And if it exists, what is the way to do this?
Thanks in advance for your help,
Michel
________________________________________________
Message sent using UebiMiau 2.7.8
I am having trouble setting up a failure route to roll over to
another on failure. I have failure_route[1] set up to catch 302
redirects and act accordingly. If no redirect is detected then the
INVITE should roll to failure route 2, as per the line that says
t_on_failure("2");. This is however not what occurs. When an INVITE
comes in, and hits failure_route[1] I can see in /var/log/messages
that it hit that route, however it never gets to failure_route[2]
even though there is no 302, instead the 408 is sent to my sip
provider, they ack it, and the call is dropped. Any help is as always
greatly appreciated.
########################################################################
#################################
# FAILURE ROUTE 1 --- 302 REDIRECT ---
########################################################################
################################
failure_route[1]
{
xlog("got to failure route 1");
t_on_failure("2");
if(t_check_status("302")){
xlog("$tU has a forward");
get_redirects("*", "redirect");
t_relay("my.sip.proxy");
exit;
};
}
########################################################################
###############################
# FAILURE ROUTE 2 ----- VOICEMAIL -------
########################################################################
################################
failure_route[2]
{
xlog("got to failure route 2");
xlog("$tU getting a vmail");
if (t_check_status("408|486|487")){
revert_uri();
strip(1);
prefix("201");
rewriteport("5070");
append_branch();
t_relay();
exit;
};
}
Maybe a roadmap will be good to have on the ser web site.
Adrian
At 19:17 20/07/2006, Daniel-Constantin Mierla wrote:
>On 07/19/06 21:14, Chahn John Kim wrote:
>> Thank you all for your comments.
>>
>> After having researched documents and history from both iptel and
OpenSER,
>> I could not resist a feeling that iptel is somewhat lagging in their
>> intension to go forward with SER to the direction that it had
headed to.
I am wondering if you can provide specifics about where SER was
headed to
and why you think it is not going forward there.
-jiri
--
Jiri Kuthan
Hello, I am new in the list and Openser.
Arrive at this project because I have servants with Asterisk, my service to been growing to the point that my Asterisk arrives at a point where they colapsan.
The reason I believe that it must to the amount of concurrent calls that receive. I understand that Openser is able to process very superior a concurrent volume of calls that Asterisk.
My problem is that in these Asterisk I have scripts cgi (AGI) that controls the quarreled one and others. This implemented in a data base Postgresql.
My consultation has to do with as I can leave to the service this operative you see autentificando against OpenSER. I understand that the Asterisk podrian to validate itself against Openser, thus then they podrian to only follow quarreling. As I can implement this scene with Openser and my Asterisk, that they recommend to me, or I must implement the quarreled one with Openser, ah another important thing is that I have clients who are of type pre payment and post payment. Or this is possible to implement with the data base that brings Openser (MySQL).
Another doubt is as I add users to the data base, this takes control of the commando:
openserctl
Soon as I implement authentication against the data base for each call that between. One you see validated the user like him step the control asterisk so that they only do the quarreled one.
Good as first consultation I believe that it is sufficient, I hope can help me. Excuse my English.
Greetings Fernando
Hello,
Hi Klaus, Thanks for your response. In answer to your question: yes, the INVITE does contain a Route header.
Further info on the problem:
There are 3 proxies between A and B parties.
The INVITE message is routed from A-Party through Proxy-1, through Proxy-2 before finally reaching B-Party. The Route header first appears in the INVITE message sent by Proxy-1 and is removed at Proxy-2.
There is an errored response message to this INVITE (e.g. 'Busy' or 'Request Terminated'). The errored response is acknowledged with a one-hop locally generated ACK at each point between B and A.
I expected the ACK at Proxy-2 to take the same one-hop route as the original INVITE at Proxy-2, i.e. the ACK sent by Proxy-2 will contain routing data based on routing data from the INVITE previously sent by Proxy-2.
What actually occurs is that the Route header in the ACK sent by Proxy-2 is a duplicate of the Route header of the INVITE that Proxy-2 has RECEIVED from Proxy-1 and NOT that of the INVITE message it had previously sent.
Are you aware of this problem and any resolution and/or workarounds?
We would like to remove this unwanted Route header from the ACK. How is it possible to do this (i.e. which routing block?)?
The known issue described in the previous email (below) appears to prevent us from removing this header from the ACK. Are you or anyone else in the OpenSER community aware of any fix or resolution to this problem?
Best regards,
Andrew Augustin
-----Ursprüngliche Nachricht-----
Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Dienstag, 25. Juli 2006 18:15
An: Augustin, Andrew (external)
Cc: users(a)openser.org
Betreff: Re: [Users] Locally generated single-hop ACKs with Route headers
I wonder why there are route headers in the ACK - they are only
necessary if the INVITE also hed route headers (RFC3261, 17.1.1.3)
regards
klaus
Augustin, Andrew (external) wrote:
> Hello,
>
> I am using OpenSER v1.0.1
>
> I am currently testing with proxies running OpenSER.
>
> I have a problem with ACK messages generated and routed for scenarios
> where an inititiated call session fails to establish between A and B
> parties e.g. Unsuccessful No Answer, Unsuccessful Busy. The ACK
> messages are single hop locally generated responses to the sip error
> message e.g. '487 Request Terminated', '486 Busy'.
>
> The behaviour I observe is that Route headers are 'remembered' from
> the initiating INVITE message and inserted into the ACK messages
> automatically generated by OpenSER.
>
> This extra Route header causes problems with routing and the
> generation unwanted messages (error message resends) in addition to
> expeceted scenario call-flow. It is also visible at the B-Party.
>
> I would like to either prevent the creation of, or remove this Route
> header. I have tried to remove this header using the OpenSER available
> methods, but this has failed.
>
> I have noticed that the known issue described in the document: SIP
> Express Router v0.8.8 - Developer's Guide under section: 9.6.4 Known
> Issues appears to describe this problem.
>
> "local ACK/CANCELs copy'n'pastes Route and ignores deleted
> Routes"
>
> Has this issue been resolved? If so, from what version of OpenSER?
>
> If it has not been resolved, is there a way to resolve or workaround
> this problem?
>
> Best regards,
> Andrew Augustin
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users