[OpenSIPS-Users] [Release] Planing 1.8.2 minor release
Hello all, We plan to have the OpenSIPS minor release 1.8.2 on Thursday 1st of November - the date may be postponed if there are outstanding bugs still pending! There are several bugs we are working on and considered to be a must for the release: - TLS related fixes to align to SSL API changes - SVN bugs 3522861, 3552688 - dialog related crashes - SVN bugs 3570495, 3572504, 3576387 - hanged dialog in memory - dialog lifetime update - VIA parsing issue - SVN bug 3571806 - SIP Trace malformed records - SVN bug 3576351 - B2B timeout inconsistency - SVN bug 3574453 - B2B general issues - SVN bugs 3578383, 3579200 If there are other critical bugs/issues/crashes which are not listed here, please let us know ASAP, so we can evaluate (to see if should be included in 1.82) and eventually fix them. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Invalid contacts in location table, TCP timeout
Hello Fabian, Regarding your questions: 1) limiting the number of contacts to be used: a) either keep in memory just one registration (last one) - see the cxx and f flags http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292725 doing save(location,c1f) b) either keep all contacts in mem, but use only the most recent one: modparam(usrloc, desc_time_order, 1) lookup(location,b); # see http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292943 2) regarding the TCP timeout, it can be controlled via tcp_connect_timeout: http://www.opensips.org/Resources/DocsCoreFcn18#toc78 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 01:34 PM, Fabian Bernhard wrote: Dear list We develop SIP clients and have an OpenSIPS 1.8.0 test server. We are bound to use TCP and frequently kill the clients without unregistering. This leads to invalid contacts in the location table. It often takes a long time for an INVITE or MESSAGE to be forwarded by the server. In syslog we see a lot of these entries: Oct 18 14:55:50 Debian-60-squeeze-64-minimal /usr/sbin/opensips[11050]: ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s Oct 18 14:55:50 Debian-60-squeeze-64-minimal /usr/sbin/opensips[11050]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Oct 18 14:55:50 Debian-60-squeeze-64-minimal /usr/sbin/opensips[11050]: ERROR:core:tcp_send: connect failed Oct 18 14:55:50 Debian-60-squeeze-64-minimal /usr/sbin/opensips[11050]: ERROR:tm:msg_send: tcp_send failed Oct 18 14:55:50 Debian-60-squeeze-64-minimal /usr/sbin/opensips[11050]: ERROR:tm:t_forward_nonack: sending request failed I think that OpenSIPS tries to forward the messages to all contacts in the location table, one contact after the other. Because some of them are not valid anymore the server is unable to send the message. This means that it takes 30 seconds for an INVITE to be received if there are 3 old contacts in the location table, due to the 10 seconds timeout. I have hoped that the following configuration would resolve the problem. I thought it would make OpenSIPS to send the message to the most recent contact first: modparam(usrloc, desc_time_order, 1) It turned out that this is not the case, for whatever reason. My questions: 1/ Is this behavior normal and expected? I.e. waiting 10 seconds for the TCP timeout before trying the next contact in the location table? 2/ Is there a way to configure OpenSIPS to a) send the messages in parallel to all contacts and b) to delete invalid contacts from location table upon above error? 3/ Can I reduce the TCP timeout to something like 2 seconds? If yes: how? Thanks and best regards Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Fwd: Concurrent calls limitation
*Hi,
Someone can help me please??*
Hi,
I'm trying to limit a calls of an user by using the script above
route[39]
{
if(!isflagset(31))
{
if( avp_db_load($fu/username,a)
avp_check($avp(channels), ge/0))
{
# get current calls for user
get_profile_size(caller,$fu,$var(calls));
# check within limit
if($avp(channels) $var(calls))
{
xlog(L_INFO, Call control: user '$fU'
currently has '$var(calls)' of '$avp(channels)' active calls before this
one\n);
$var(setprofile) = 1;
}
else
{
xlog(L_INFO, Call control: user channel
limit exceeded [$var(calls)/$avp(channels)]\n);
send_reply(487, Request Terminated:
Channel limit exceeded\n);
exit;
}
}
else
{
$var(setprofile) = 0;
}
if($var(setprofile) 0)
{
xlog(L_INFO, Call control, setprofile:
$var(setprofile)\n);
create_dialog();
set_dlg_profile(caller,$fu);
}
setflag(31);
}
}
But if i limit the max calls at 1 i can make more than one calls.
can you help me please ??
--
Best Regards.
--
Best Regards.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Concurrent calls limitation
Hi,
Before the channel limit test, print via xlog the value you loaded (the
limit) and the current size (from profile). See what you get there for
your calls.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/23/2012 11:43 AM, Engineer voip wrote:
Hi,
I'm trying to limit a calls of an user by using the script above
route[39]
{
if(!isflagset(31))
{
if( avp_db_load($fu/username,a)
avp_check($avp(channels), ge/0))
{
# get current calls for user
get_profile_size(caller,$fu,$var(calls));
# check within limit
if($avp(channels) $var(calls))
{
xlog(L_INFO, Call control: user
'$fU' currently has '$var(calls)' of '$avp(channels)' active calls
before this one\n);
$var(setprofile) = 1;
}
else
{
xlog(L_INFO, Call control: user
channel limit exceeded [$var(calls)/$avp(channels)]\n);
send_reply(487, Request Terminated:
Channel limit exceeded\n);
exit;
}
}
else
{
$var(setprofile) = 0;
}
if($var(setprofile) 0)
{
xlog(L_INFO, Call control, setprofile:
$var(setprofile)\n);
create_dialog();
set_dlg_profile(caller,$fu);
}
setflag(31);
}
}
But if i limit the max calls at 1 i can make more than one calls.
can you help me please ??
--
Best Regards.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS 1.8.0-1 with B2BUA/top hiding and UPDATE dialog hiccups
Hello Jock, You mean - https://sourceforge.net/tracker/index.php?func=detailaid=3545275group_id=232389atid=1086410 ? Also, could you post somewhere you trace (taken on opensips side) ? Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 05:41 PM, Jock McKechnie wrote: I have a problem with a very simple OpenSIPS doing B2BUA topology hiding that is unable to handle incoming UPDATEs from the server-side. The proxy does not tie the UPDATE to the in-progress dialog, and so it warns with a No dialog found error. I was able to locate a post from earlier this year (March, I think) with this same issue, and one of the devs patched the daily to correct it. I'm running the latest 1.8.0-1 from the opensips Debian package repository and it does not appear to be patched with this fix. Unfortunately I can't find the post again to determine when the patch was actually made and to what revision. Did the patch go in and this feature was broken again, is the patch not in this release, or am I just stupid? My thanks! - Jock ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] tm module CANCEL reason on timeout
Hi John, The 480 code is on purpose. See the mapping between Q.850 and SIP for reasons: https://support.net.com/display/VXDOC471/Mapping+Q.850+to+SIP+Responses or: wiki.freeswitch.org/index.php?title=Special:PdfPrintpage=Hangup_Causes So, if you have a TIMEOUT with no reply, you should report a 408, but if there is timeout with reply, it should be 480. And as in SIP you generate CANCEL only for timeouts with replies - it;s 480. Please correct me if my logic is wrong. On controlling the Reason phrase in Cancel, this is a bit tricky, as CANCELs are internally generated (on timer) and you have no script interaction. I see 2 approaches here: - make local_route to be trigerred from local CANCELs too, so you can do your own headers - at INVITE time (per branch) set via an AVP the reason hdr to be used (if not default) in case of CANCELing that branch. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 04:38 PM, John Quick wrote: In modules/tm/timer.c function final_response_handler, a #define is used to set the Reason header in the CANCEL when triggered by the invite timeout. The default is cause=480;text=NO_ANSWER, but I think it should be 408 because 408 is timeout and 480 is temporarily unavailable. I need to be able to control the Reason header when a timeout is triggered in tm. When the call is being sent to our SS7 gateway, we need the reason header to be set as follows: Reason: Q.850;cause=19;text=No Answer When the call is going to a SIP device, I want the header to be like the current default: Reason: SIP;cause=408;text=NO_ANSWER Is it permissible to add 2 reason headers or to somehow append different reasons for different transports to one header? Could the developers put this on the roadmap please - to add functionality to have more control over the reason header in the tm module on timeout. Many thanks. John Quick Smartvox Limited ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Hangup call on leg B side
Hi,
Simply use the B2B modules for that that:
http://www.opensips.org/Resources/B2buaTutorial
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/22/2012 12:12 PM, pars3c wrote:
Hi ,
i don't know how to realize this:
A --- INVITEproxy INVITE B
--- 200 OK
---BYE
---INVITE -C
--- 200 OK proxy --- 200 OK
---ACK --- ---ACK ---
When B answer the call, the proxy should immediately hang up the call
and make a new invite. For user A is always the same call.
I tried this :
onreply_route {
connect
if (is_method(INVITE) status == 200) {
dlg_bye(callee);
drop();
}
}
But it doesn't work. When arrive 200 , the proxy drop the message to
the user a , wait for a while, and then send a cancel to b (it should
send a BYE, instead send a CANCEL, probably because it not have a ACK).
How can I try this?
Thanks
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] tm module CANCEL reason on timeout
Hi Bogdan, It is interesting that RFC3398 recommends mapping ISUP 19 to SIP 480. I think this makes sense and so I agree with your logic. It is good to use two different response values, one for timeout (no response) and another for ring-no-answer (where a 180 response has been received) because these are two completely different conditions. However, doesn't this mean that there is an inconsistency elsewhere in OpenSIPS? If I understand correctly, the timers in the tm module operate as follows: timeout (no response) is linked to fr_timer ring-no-answer is linked to fr_inv_timer. Yet, the tm module always generates the same SIP response, 408, for both fr_timer and for fr_inv_timer. Should it not generate 408 for fr_timer and 480 for fr_inv_timer? Regarding your suggestions for controlling the reason phrase within the tm module, I would say that both methods look satisfactory. The AVP is probably the more straightforward for users. However, I have just found the following information in RFC3326: A SIP message MAY contain more than one Reason value (i.e., multiple Reason lines), but all of them MUST have different protocol values (e.g., one SIP and another Q.850). If it were added to the tm module, would the reason cause AVP allow the addition of multiple Reason headers? John -Original Message- From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] Sent: 25 October 2012 12:41 To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] tm module CANCEL reason on timeout Hi John, The 480 code is on purpose. See the mapping between Q.850 and SIP for reasons: https://support.net.com/display/VXDOC471/Mapping+Q.850+to+SIP+Responses or: wiki.freeswitch.org/index.php?title=Special:PdfPrintpage=Hangup_Causes So, if you have a TIMEOUT with no reply, you should report a 408, but if there is timeout with reply, it should be 480. And as in SIP you generate CANCEL only for timeouts with replies - it;s 480. Please correct me if my logic is wrong. On controlling the Reason phrase in Cancel, this is a bit tricky, as CANCELs are internally generated (on timer) and you have no script interaction. I see 2 approaches here: - make local_route to be trigerred from local CANCELs too, so you can do your own headers - at INVITE time (per branch) set via an AVP the reason hdr to be used (if not default) in case of CANCELing that branch. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 04:38 PM, John Quick wrote: In modules/tm/timer.c function final_response_handler, a #define is used to set the Reason header in the CANCEL when triggered by the invite timeout. The default is cause=480;text=NO_ANSWER, but I think it should be 408 because 408 is timeout and 480 is temporarily unavailable. I need to be able to control the Reason header when a timeout is triggered in tm. When the call is being sent to our SS7 gateway, we need the reason header to be set as follows: Reason: Q.850;cause=19;text=No Answer When the call is going to a SIP device, I want the header to be like the current default: Reason: SIP;cause=408;text=NO_ANSWER Is it permissible to add 2 reason headers or to somehow append different reasons for different transports to one header? Could the developers put this on the roadmap please - to add functionality to have more control over the reason header in the tm module on timeout. Many thanks. John Quick Smartvox Limited ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] tm module CANCEL reason on timeout
Hi John, From SIP reply codes perspective there is no difference between timeout with replies or timeout without replies - you all the time get the 408 (at least this is what I know :) ). The difference is only in the reason code. Now about the implementation - if using AVPs, you will have to provide let's say the full Reason hdr (name, value, EOH) so you could put actually more headers in the AVP (it will be handled like a string to appended to headers). If there is no such AVP, we will use the internal default one. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/25/2012 03:37 PM, John Quick wrote: Hi Bogdan, It is interesting that RFC3398 recommends mapping ISUP 19 to SIP 480. I think this makes sense and so I agree with your logic. It is good to use two different response values, one for timeout (no response) and another for ring-no-answer (where a 180 response has been received) because these are two completely different conditions. However, doesn't this mean that there is an inconsistency elsewhere in OpenSIPS? If I understand correctly, the timers in the tm module operate as follows: timeout (no response) is linked to fr_timer ring-no-answer is linked to fr_inv_timer. Yet, the tm module always generates the same SIP response, 408, for both fr_timer and for fr_inv_timer. Should it not generate 408 for fr_timer and 480 for fr_inv_timer? Regarding your suggestions for controlling the reason phrase within the tm module, I would say that both methods look satisfactory. The AVP is probably the more straightforward for users. However, I have just found the following information in RFC3326: A SIP message MAY contain more than one Reason value (i.e., multiple Reason lines), but all of them MUST have different protocol values (e.g., one SIP and another Q.850). If it were added to the tm module, would the reason cause AVP allow the addition of multiple Reason headers? John -Original Message- From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] Sent: 25 October 2012 12:41 To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] tm module CANCEL reason on timeout Hi John, The 480 code is on purpose. See the mapping between Q.850 and SIP for reasons: https://support.net.com/display/VXDOC471/Mapping+Q.850+to+SIP+Responses or: wiki.freeswitch.org/index.php?title=Special:PdfPrintpage=Hangup_Causes So, if you have a TIMEOUT with no reply, you should report a 408, but if there is timeout with reply, it should be 480. And as in SIP you generate CANCEL only for timeouts with replies - it;s 480. Please correct me if my logic is wrong. On controlling the Reason phrase in Cancel, this is a bit tricky, as CANCELs are internally generated (on timer) and you have no script interaction. I see 2 approaches here: - make local_route to be trigerred from local CANCELs too, so you can do your own headers - at INVITE time (per branch) set via an AVP the reason hdr to be used (if not default) in case of CANCELing that branch. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 04:38 PM, John Quick wrote: In modules/tm/timer.c function final_response_handler, a #define is used to set the Reason header in the CANCEL when triggered by the invite timeout. The default is cause=480;text=NO_ANSWER, but I think it should be 408 because 408 is timeout and 480 is temporarily unavailable. I need to be able to control the Reason header when a timeout is triggered in tm. When the call is being sent to our SS7 gateway, we need the reason header to be set as follows: Reason: Q.850;cause=19;text=No Answer When the call is going to a SIP device, I want the header to be like the current default: Reason: SIP;cause=408;text=NO_ANSWER Is it permissible to add 2 reason headers or to somehow append different reasons for different transports to one header? Could the developers put this on the roadmap please - to add functionality to have more control over the reason header in the tm module on timeout. Many thanks. John Quick Smartvox Limited ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load Balancer Issue
Hi Nil,
Seems the problem is in the proxy, where you do not do RR at all.
Try
Proxy:
route{
if (!has_totag()) {
# initial request
record_route();
} else {
# sequential request - obey Route indication
loose_route();
}
if (!t_relay()) {
# xlog(L_ERR,sl_reply_error\n);
sl_reply_error();
}
}
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/22/2012 02:25 PM, Nilanjan Banerjee wrote:
Thanks Bogdan for taking time to respond to my post. I think you have
guessed it right, I am using the sample routing script given in the
Load Balancer (LB) tutorial and that is most likely sending the ACK
and BYE messages directly to Client 2 bypassing the Proxy. The routing
code snippets I am using at the LB and the Proxy are shown below.
Could you please tell me what's going wrong over here? I am using
record route support at both the clients. Alternatively if you could
please tell me what should go in the routing blocks of the LB and the
Proxy so that all the messages go through the LB and the Proxy then
that will be of immense help too.
Regards,
Nil.
Load Balancer:
route{
if (!mf_process_maxfwd_header(3)) {
sl_send_reply(483,looping);
exit;
}
if (!has_totag()) {
# initial request
record_route();
} else {
# sequential request - obey Route indication
loose_route();
t_relay();
exit;
}
# detect resources and do balancing
load_balance(1,sc);
# LB function returns negative if no suitable destination (for
requested resources) is found,
# or if all destinations are full
if ($retcode0) {
sl_send_reply(500,Service full);
exit;
}
xlog(Selected destination is: $du\n);
# send it out
if (!t_relay()) {
sl_reply_error();
}
}
Proxy:
route{
record_route();
if (!t_relay()) {
# xlog(L_ERR,sl_reply_error\n);
sl_reply_error();
}
}
On Sun, Oct 21, 2012 at 7:39 PM, Bogdan-Andrei Iancu
bog...@opensips.org mailto:bog...@opensips.org wrote:
Hi Nil,
I wild guess is you are not correctly do loose_route on the LB,
so instead of following the Route (to OpenSIPS Proxy), it goes
directly to end destination in RURI (Client 2).
Of course, I assume that all parties (LB + Proxy) do
record_route() for the call, right ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/21/2012 10:09 AM, Nilanjan Banerjee wrote:
Hello,
I am trying to build the following setup using OpenSIPS load
balancer and the proxy functionality:
Client 1 (sipp) OpenSIPS Load Balancer OpenSIPS
Proxy Client 2 (sipp)
At the client ends I am using the following commands:
Client 1: sipp -sn uac -rsa [Load Balancer Address] [Client 2
Address]
Client 2: sipp -sn uas
The Load Balancer is configured with a destination as the
OpenSIPS Proxy and the Proxy is configured to simply forward the
SIP messages based on IP address (using only forward(); in the
routing block).
Now everything (INVITE, OK and ACK messages) works fine except
the BYE messages that are getting forwarded by the Load Balancer
directly to Client 2 unlike the INVITE, OK and ACK messages that
traverse the Proxy. Client 2 however, sends the OK to the BYE to
the OpenSIPS Proxy. Since the BYE messages do not traverse the
Proxy, the OK to the BYE messages are getting retransmitted
repeatedly by Client 2 and the sessions are not getting
terminated properly. How do I make the BYE messages to go through
the Proxy or the OK message sent directly to the Load Balancer so
that the retransmissions do not happen and the sessions get
terminated properly?
[NB: When the Load Balancer is taken out of the loop and the
Proxy configuration is kept the same, all the SIP messages
traverses the Proxy and everything works fine i.e., the BYE and
the OKs to the BYEs are handled properly and sessions get
terminated properly.]
Would greatly appreciate any help in this matter. Thanks in advance.
Nil.
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] tm module CANCEL reason on timeout
Bogdan, I think your AVP implementation would be very useful. Thanks. From SIP reply codes perspective there is no difference between timeout with replies and timeout with none - I dislike this, but that does not mean it is wrong! It seems illogical to me - what is the point of having available a large pool of SIP Response codes (some of which are rarely used) and then using the same one to show two completely different results. This has caused me problems when trying to detect a failed downstream server or network path. I had to write extra code in my failure_route just to help identify which of these two outcomes has happened when status is 408. Best regards, John Quick -Original Message- From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] Sent: 25 October 2012 14:34 To: john.qu...@smartvox.co.uk Cc: 'OpenSIPS users mailling list' Subject: Re: [OpenSIPS-Users] tm module CANCEL reason on timeout Hi John, From SIP reply codes perspective there is no difference between timeout with replies or timeout without replies - you all the time get the 408 (at least this is what I know :) ). The difference is only in the reason code. Now about the implementation - if using AVPs, you will have to provide let's say the full Reason hdr (name, value, EOH) so you could put actually more headers in the AVP (it will be handled like a string to appended to headers). If there is no such AVP, we will use the internal default one. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/25/2012 03:37 PM, John Quick wrote: Hi Bogdan, It is interesting that RFC3398 recommends mapping ISUP 19 to SIP 480. I think this makes sense and so I agree with your logic. It is good to use two different response values, one for timeout (no response) and another for ring-no-answer (where a 180 response has been received) because these are two completely different conditions. However, doesn't this mean that there is an inconsistency elsewhere in OpenSIPS? If I understand correctly, the timers in the tm module operate as follows: timeout (no response) is linked to fr_timer ring-no-answer is linked to fr_inv_timer. Yet, the tm module always generates the same SIP response, 408, for both fr_timer and for fr_inv_timer. Should it not generate 408 for fr_timer and 480 for fr_inv_timer? Regarding your suggestions for controlling the reason phrase within the tm module, I would say that both methods look satisfactory. The AVP is probably the more straightforward for users. However, I have just found the following information in RFC3326: A SIP message MAY contain more than one Reason value (i.e., multiple Reason lines), but all of them MUST have different protocol values (e.g., one SIP and another Q.850). If it were added to the tm module, would the reason cause AVP allow the addition of multiple Reason headers? John -Original Message- From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] Sent: 25 October 2012 12:41 To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] tm module CANCEL reason on timeout Hi John, The 480 code is on purpose. See the mapping between Q.850 and SIP for reasons: https://support.net.com/display/VXDOC471/Mapping+Q.850+to+SIP+Responses or: wiki.freeswitch.org/index.php?title=Special:PdfPrintpage=Hangup_Cause s So, if you have a TIMEOUT with no reply, you should report a 408, but if there is timeout with reply, it should be 480. And as in SIP you generate CANCEL only for timeouts with replies - it;s 480. Please correct me if my logic is wrong. On controlling the Reason phrase in Cancel, this is a bit tricky, as CANCELs are internally generated (on timer) and you have no script interaction. I see 2 approaches here: - make local_route to be trigerred from local CANCELs too, so you can do your own headers - at INVITE time (per branch) set via an AVP the reason hdr to be used (if not default) in case of CANCELing that branch. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/22/2012 04:38 PM, John Quick wrote: In modules/tm/timer.c function final_response_handler, a #define is used to set the Reason header in the CANCEL when triggered by the invite timeout. The default is cause=480;text=NO_ANSWER, but I think it should be 408 because 408 is timeout and 480 is temporarily unavailable. I need to be able to control the Reason header when a timeout is triggered in tm. When the call is being sent to our SS7 gateway, we need the reason header to be set as follows: Reason: Q.850;cause=19;text=No Answer When the call is going to a SIP device, I want the header to be like the current default: Reason: SIP;cause=408;text=NO_ANSWER Is it permissible to add 2 reason headers or to somehow append different reasons for different transports to one
Re: [OpenSIPS-Users] Invalid contacts in location table, TCP timeout
Hi Bogdan, Thank you very much for your answer. We have tested the tcp_connect_timeout and have already very good results. I have some follow up questions, if I may: 1) limiting the number of contacts to be used: a) either keep in memory just one registration (last one) - see the cxx and f flags http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292725 doing save(location,c1f) b) either keep all contacts in mem, but use only the most recent one: modparam(usrloc, desc_time_order, 1) lookup(location,b); # see http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292943 Do I understand this correctly, if I use option b) then option a) is useless, i.e. I should only use one of the two options? It is not relevant for testing, but if we would like to support multiple registrations with the same SIP id from different locations, for instance home and office, should we then use option a) with something like save(location, c2f)? Regards, Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Invalid contacts in location table, TCP timeout
Hi Fabian, yes, use only one option a) or b) ( from (1) ). and indeed, a) gives you more liberty as you select the last 2 or so (not only the last one as you have in b) ). But on second thoughts, use the desc_timer_order in both cases (a and b) ! Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/25/2012 06:55 PM, Fabian Bernhard wrote: Hi Bogdan, Thank you very much for your answer. We have tested the tcp_connect_timeout and have already very good results. I have some follow up questions, if I may: 1) limiting the number of contacts to be used: a) either keep in memory just one registration (last one) - see the cxx and f flags http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292725 doing save(location,c1f) b) either keep all contacts in mem, but use only the most recent one: modparam(usrloc, desc_time_order, 1) lookup(location,b); # see http://www.opensips.org/html/docs/modules/1.8.x/registrar.html#id292943 Do I understand this correctly, if I use option b) then option a) is useless, i.e. I should only use one of the two options? It is not relevant for testing, but if we would like to support multiple registrations with the same SIP id from different locations, for instance home and office, should we then use option a) with something like save(location, c2f)? Regards, Fabian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] max branches count error
HI,all:
We try to make a call to a server and try as many as possible, but we find we
can try around 10 times then errors happen (we expect 20 times):
ERROR: tm:add_uac: maximum number of branches exceeded
ERROR: tm:t_forward_nonack: failure to add branches
ERROR: tm:w_t_relay: t_forward_nonack failed
route[1]
{
$avp(i)=0;
t_on_failure(1);
t_relay(1.2.3.4);
exit;
}
failure_route[1]
{
if ( $avp(i) 20 ) {# max try 20 times
xlog( i=$avp(i) \n) ;
$avp(i)=$avp(i)+1;
remove_branch(1);
t_on_failure(1);
t_relay(1.2.3.4);
}
exit;
}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
