Re: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
Hi Brett,
I think using script variables should work -
http://www.opensips.org/Resources/DocsCoreVar#varscript.
Regards,
Anca
On 10/13/2010 01:31 AM, Brett Woollum wrote:
Hi Anca,
I figured out the solution that you were referring to. I added the
local_route section and changed the header in there, and it works.
The only problem now is that the AVP variable I set in route doesn't
seem to be persistent into the new request inside local_route. This is
a problem because I need some way to send the variables to local_route
so that I can put them into the new request. Is there a way to make an
AVP variable persistent into the local_route as well? Or maybe there
is a better way to make these variables accessible from inside
local_route?
Here is my working code (with statically set caller id. I need to make
this dynamic):
local_route {
if (is_method(INVITE)) {
remove_hf(From);
append_hf(From: \TEST3\ sip:12...@1.2.3.4;tag=$ft\r\n);
#exit;
}
if (is_method(BYE) ) {
acc_log_request(internally generated BYE);
}
}
Brett Woollum
br...@woollum.com
- Original Message -
From: Anca Vamanu a...@opensips.org
To: users@lists.opensips.org
Sent: Tuesday, October 12, 2010 2:37:55 AM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
Hi Brett,
The b2bua generates a new request with the info from the received one.
The problem is with the changes upon a request not being visible to
the following functions called from the script.
So you have to change the header on the generated one, in local route.
Regards,
Anca
On 10/12/2010 10:24 AM, Brett Woollum wrote:
In addition, the uac_replace_from(display,uri); function does not
seem to work either. I tested this function by putting:
uac_replace_from(TEST, sip:12...@1.2.3.4);
immediately above the call to B2B_INIT_REQUEST and the outbound
From: header remains unchanged (incorrect).
Brett Woollum
br...@woollum.com
- Original Message -
From: Brett Woollum br...@woollum.com
To: users-request users@lists.opensips.org
Sent: Monday, October 11, 2010 11:53:39 PM GMT -08:00 US/Canada
Pacific
Subject: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
Hello,
I have a working implementation of the B2BUA modules for OpenSIPS.
One problem I am having is that the B2BUA module doesn't seem to
respect the From: header that I updated before B2B_INIT was
called (at the end of the script). Before I call B2B_INIT, my
script looks up the correct caller-id from a database and replaces
the From: header with the new information. Here is that code:
xlog(This is an external call...);
avp_db_query(select id from subscriber where username=\$fU\ AND
domain=\1.2.3.4\, $avp(s:subscriber_id));
if(is_avp_set($avp(s:subscriber_id))){
avp_db_query(select
external_cid_name,external_cid_uri,external_cid_uri_domain from
cid where subscriber_id=\$avp(s:subscriber_id)\,
$avp(s:external_cid_name);$avp(s:external_cid_uri);$avp(s:external_cid_uri_domain));
remove_hf(From);
append_hf(From:
\$avp(s:external_cid_name)\
sip:$avp(s:external_cid_uri)@$avp(s:external_cid_uri_domain);tag=$ft\r\n);
}
The resulting From: header is perfect (it includes the new
caller-id information) and works without problems when I don't use
the B2BUA module. It seems as though the B2BUA module (which is
called last in the script) does not respect the new header, and
instead processes the call using whatever was in $fu when the
script started. Unfortunately $fu is not writable, so I can't
directly change it.
What are some possible work-arounds to get the B2BUA module to
create the new call but include the From: header that I've
updated earlier in the script?
Any ideas are greatly appreciated!
Brett Woollum
br...@woollum.com
___ 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
--
Anca Vamanu
www.voice-system.ro
___ 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
--
Anca Vamanu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] About Nat Traversal and Stun
Hi, stun module allows you to run a stun server on the opensips platform... so your device sith the stun client uses your proxy ip(s) to access a stun server. Paul CheeWii wrote: Hi, I want to solve the nat traversal problem, and I read the great book Building Telephony System with Opensips 1.6.0. Now I encounter some doubts. From the book,I know the STUN solution is considered a near-end NAT traversal solution. And I think a near-end NAT traversal solution is implemented on the client-side. Why does Opensips have the module named stun? What is the relationship of the stun module in Opensips and the stun in client? In addition,what is the main and effective solutions in Opensips to solve the nat traversal problem? Best wishes~ CheeWii ___ 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 swallows BYEs
I'm not explicitly routing that BYE, but as Andrew Pogrebennyk pointed out, since I'm rewriting the Contact header with OpenSIPS address it is expected that BYE won't go any further than OpenSIPs proxy and therefore my only solutions seems to be the configuration of the b2bua modules. Isn't it? On Mon, Oct 11, 2010 at 6:35 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi David, ok, so the BYE is sent to the wrong destination - how do you route BYE in your script? do you use the standard loose_route block ? Regards, Bogdan David Santiago wrote: As I said it is being forwarded to the jain slee server that originated it. The effect is the same as if it was replied. The flow is: step 1: [JAIN SLEE SERVER] ---BYE-- [OPENSIPS] [VOIP PROVIDER] step 2: [JAIN SLEE SERVER] ---BYE-- [OPENSIPS] [VOIP PROVIDER] that BYE should be forwarded to the VOIP provider, instead. I'm having a look at how to configure the b2bua thing should this problem be fixed. Thanks for the follow up, Bogdan. David On Fri, Oct 8, 2010 at 1:38 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi David, my question is what happens with the BYE: - is it replied by opensips ? - is it forwarded to some whatever destination ? Regards, Bogdan David Santiago wrote: Bogdan, right now it's being forwarded again to the slee server who sent it, as I'm basically using the configuration provided in http://www.opensips.org/html/docs/modules/1.6.x/dispatcher.html On Wed, Oct 6, 2010 at 4:16 PM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi David, Is the BYE replied or forwarded to whatever destination ? probably your record routing is somehow broken. OpenSIPS may misroute the BYE because the invalid route set - posting the 200 OK for INVITE and the BYE will help in investigating this. Regards, Bogdan David Santiago wrote: Hi all, I have a running OpenSIPS installation that I'm using for testing purposes. The fact is that I'm forwarding requests from a voip provider to a jain slee server and everything is working fine (INVITEs, ACKs, RTP flow,...), except for the BYEs generated from the server side. They reach the OpenSIPs proxy and are not forwarded to the voip provider in order to finish the call. I'm not sure if I have to manually setup a route for this to happen, or if this behaviour is only available by using the B2BUA approach in OpenSIPS. Thanks a lot! David ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro http://www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Using b2bua top hiding plus dispatcher module
I'll check it later, but the fact is that I have to solve first the
problem that prevents the INVITEs generated by OpenSIPs to be sent to
the internal jain slee server.
I have confirmed that after the call to ds_select(), the value of $du
points to such server (which has been obtained from the
/opt/opensipsnotls/etc/opensips/dispatcher.list file), but the INVITEs
are not sent there, but to the public IP address of the OpenSIPs
server. Without the b2bua setup, the dispatcher has been working
fine in other tests I've made...
Regards,
David
On Tue, Oct 12, 2010 at 11:22 AM, Anca Vamanu a...@opensips.org wrote:
Hi David,
The only thing that won't work as you like is the append_hf - it won't
work as you like since the b2bua module won't see that header. You need
to do that for the new request generated by the b2bua and put that code
in the local_route.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/11/2010 01:48 PM, David Santiago wrote:
Hi all,
After cleaning up the initialization problems in the b2bua related
modules I'm testing a configuration I want to use in order to enable
the top hiding scenario, plus using the dispatcher module so I can
configure the internal jain slee server that receives the requests
from the opensips proxy, like this:
VOIP PROVIDER--- OPENSIPS--- INTERNAL JAIN SLEE SERVER
I will write here the configuration I'm using, taken from the
configuration example available, that results in the INVITEs received
from the VOIP PROVIDER being sent by OPENSIPS to itself (to its public
address, in particular), ad infinitum.
The modparam(dispatcher, list_file,
/opt/opensipsnotls/etc/opensips/dispatcher.list) entry points to the
file required by the dispatcher module to determine the ip and port
where the internal jain slee server is running. Furthermore, our
service implementation requires the addition of the
P-Preferred-Service header, which is done with append_hf().
Any hint would be appreciated. Thanks in advance!
# Debugging mode:
debug=9
memlog=6
fork=yes
auto_aliases=no
log_stderror=no
disable_dns_blacklist=yes
listen=10.122.54.163:5060 # private opensips ip
# alias=OSIPS_REALM
#port=OSIPS_PORT
sip_warning=0
#server_header=SRV_SIGNATURE
#user_agent_header=PP_USER_AGENT
#mhomed=yes
#memlog=2
check_via=no
dns=off
rev_dns=off
children=8
disable_tcp=yes
log_facility=LOG_LOCAL0
# for more info: opensips -h
# -- module loading --
mpath=/opt/opensipsnotls/lib/opensips/modules/
#loadmodule db_mysql.so
#loadmodule xlog.so
loadmodule textops.so
loadmodule maxfwd.so
loadmodule rr.so
loadmodule sl.so
loadmodule tm.so
loadmodule signaling.so
loadmodule b2b_entities.so
loadmodule b2b_logic.so
loadmodule usrloc.so
loadmodule registrar.so
loadmodule mi_fifo.so
loadmodule dispatcher.so
# - setting module-specific parameters ---
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
#modparam(usrloc, db_url,
mysql://opensips:opensip...@localhost/opensips)
#modparam(usrloc, db_mode, 2)
modparam(tm, pass_provisional_replies, 1)
modparam(dispatcher, list_file,
/opt/opensipsnotls/etc/opensips/dispatcher.list)
modparam(b2b_entities, server_address,
sip:MY_OPENSIPS_PUBLIC_IP_GOES_HERE:5060)
#modparam(b2b_logic, script_scenario,
/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml)
#modparam(b2b_logic, extern_scenario,
/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml)
modparam(b2b_entities, script_req_route, b2b_request)
modparam(b2b_entities, script_reply_route, b2b_reply)
route[b2b_request] {
xlog(b2b_request ($ci)\n);
}
route[b2b_reply] {
xlog(b2b_reply ($ci)\n);
}
route {
xlog(mozaa - Here we go...);
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len= 2380 ) {
sl_send_reply(513, Message too big);
exit;
};
if (!method==REGISTER)
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf(P-hint: rr-enforced\r\n);
route(1);
};
if(is_method(INVITE) /* only for Invite messages from bob*/
!(src_ip == 10.122.54.163 src_port ==5060)) /* skip
Invite messages generated by the server*/
{
# DO NOT call t_newtran() on this request - it will result in the
transaction never being deleted
##b2b_init_request(prepaid, sip:3...@opensips.org:5070,
sip:3...@opensips.org:5070);
xlog(mozaa ft - [$ft]);
xlog(mozaa fu - [$fu]);
xlog(mozaa tt - [$tt]);
xlog(mozaa tu - [$tu]);
xlog(mozaa du - [$du]);
xlog(mozaa si - [$si]);
$var(to) = $tu;
$var(to) = $(var(to){s.substr,4,0});
$var(to) = $(var(to){s.select,0,@});
$var(proxy_public_addr) =
[OpenSIPS-Users] loose_route and $du
Hello,
sorry for the newbie stupid question.
Is it normal that after a loose_route() the $du is set to null?
this is my config:
if (loose_route()) {
if (is_method(BYE)) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction fails
} else if (is_method(INVITE)) {
# even if in most of the cases is
useless, do RR for
# re-INVITEs alos, as some buggy
clients do change route set
# during the dialog.
record_route();
}
# route it out to whatever destination was set
by loose_route()
# in $du (destination URI).
xlog([LOOSE_ROUTE] from $si:$sp method $rm
SET_DESTINATION $du);
route(1);
}
in my log file I have:
Oct 13 12:09:42 TDCVIRX09 /usr/local/sbin/opensips[17647]:
[LOOSE_ROUTE] from 192.168.6.132:10002 method BYE SET_DESTINATION
null
thanks
--
Stefano Sasso
http://stefano.dscnet.org/
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Changing Opensips port number
Hi, Sorry for the newbie question. How do you change the port number in opensips? I want to change it from 5060 to something else however when I do so on opensips.cfg and restart opensips, Opensips doesn't seem to listen on the port I have specified. Do I need to change the number elsewhere? regards james ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
I'm not sure that process persistence is what Brett was looking for but rather
Dialog persistence. I have found that local memcache support is very fast and
takes care of this type of need quite well.
Using a unique key, made up perhaps of the SIP call-id and type of value like
B2Bwhatever_callerid and the value you desire it to contain will allow you to
store, retrieve, and delete the value at will from any point in call
processing. Plus you can pass in an expire time so it will be deleted in the
event something goes wrong with the call. If you want to get real fancy you
could even set up a memcached server and do those same functions from
distributed Proxies.
http://www.opensips.org/Resources/DocsTutMemcache.
There are always a thousand ways to do any one thing in opensips, like storing
the avp to the database
case INVITE :
avp_db_store($ci, $avp(s:epochtime));
#epochtime set in set variables route - store it to db with call id as uuid.
and grabbing it back
case BYE :
avp_db_load($ci, a); #get all records from db
stored with this call id as uuid.
#this caused epochtime avp to become multi.
avp_db_delete($ci, a); #get rid of db entries for
this call
(this example doesn't exactly match your need but you get the idea) but
memcache is one way to do this job.
Richard
On Oct 13, 2010, at 3:13 AM, Anca Vamanu wrote:
Hi Brett,
I think using script variables should work -
http://www.opensips.org/Resources/DocsCoreVar#varscript.
Regards,
Anca
On 10/13/2010 01:31 AM, Brett Woollum wrote:
Hi Anca,
I figured out the solution that you were referring to. I added the
local_route section and changed the header in there, and it works.
The only problem now is that the AVP variable I set in route doesn't seem to
be persistent into the new request inside local_route. This is a problem
because I need some way to send the variables to local_route so that I can
put them into the new request. Is there a way to make an AVP variable
persistent into the local_route as well? Or maybe there is a better way to
make these variables accessible from inside local_route?
Here is my working code (with statically set caller id. I need to make this
dynamic):
local_route {
if (is_method(INVITE)) {
remove_hf(From);
append_hf(From: \TEST3\ sip:12...@1.2.3.4;tag=$ft\r\n);
#exit;
}
if (is_method(BYE) ) {
acc_log_request(internally generated BYE);
}
}
Brett Woollum
br...@woollum.com
- Original Message -
From: Anca Vamanu a...@opensips.org
To: users@lists.opensips.org
Sent: Tuesday, October 12, 2010 2:37:55 AM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
Hi Brett,
The b2bua generates a new request with the info from the received one. The
problem is with the changes upon a request not being visible to the
following functions called from the script.
So you have to change the header on the generated one, in local route.
Regards,
Anca
On 10/12/2010 10:24 AM, Brett Woollum wrote:
In addition, the uac_replace_from(display,uri); function does not seem to
work either. I tested this function by putting:
uac_replace_from(TEST, sip:12...@1.2.3.4);
immediately above the call to B2B_INIT_REQUEST and the outbound From:
header remains unchanged (incorrect).
Brett Woollum
br...@woollum.com
- Original Message -
From: Brett Woollum br...@woollum.com
To: users-request users@lists.opensips.org
Sent: Monday, October 11, 2010 11:53:39 PM GMT -08:00 US/Canada Pacific
Subject: [OpenSIPS-Users] B2BUA From Header Caller-ID Question
Hello,
I have a working implementation of the B2BUA modules for OpenSIPS. One
problem I am having is that the B2BUA module doesn't seem to respect the
From: header that I updated before B2B_INIT was called (at the end of the
script). Before I call B2B_INIT, my script looks up the correct caller-id
from a database and replaces the From: header with the new information.
Here is that code:
xlog(This is an external call...);
avp_db_query(select id from subscriber where username=\$fU\ AND
domain=\1.2.3.4\, $avp(s:subscriber_id));
if(is_avp_set($avp(s:subscriber_id))){
avp_db_query(select
external_cid_name,external_cid_uri,external_cid_uri_domain from cid where
subscriber_id=\$avp(s:subscriber_id)\,
$avp(s:external_cid_name);$avp(s:external_cid_uri);$avp(s:external_cid_uri_domain));
remove_hf(From);
append_hf(From: \$avp(s:external_cid_name)\
sip:$avp(s:external_cid_uri)@$avp(s:external_cid_uri_domain);tag=$ft\r\n);
}
The resulting From: header is perfect (it includes the new
Re: [OpenSIPS-Users] failed to decode uri
I was forced to remove the OpenSIPS b2bua as it seems it was causing the origination gateway to choke on these 200 OKs. Dialogs are no longer hanging, but I still see errors on the origination gateway that are concerning: /usr/local/sbin/opensips[4399]: ERROR:core:parse_from_header: bad from header /usr/local/sbin/opensips[4399]: ERROR:rr:record_route: From parsing failed /usr/local/sbin/opensips[4402]: ERROR:core:parse_to: unexpected char [#000] in status 6: 2345678910sip:2345678...@6.12.24.48:5060 I can't find anything out of the ordinary in traces. What should I be looking for? Again, any help would be appreciated. Thanks. On Tue, Oct 12, 2010 at 9:15 PM, thrillerbee thriller...@gmail.com wrote: To add a little more detail, after doing some from uri normalization, this is eventually passed on to an OpenSIPS instance running b2bua for top hiding. I'm assuming this error indicates that the header param that is used to rebuild the original from uri is different than expected, but I don't see any discernible differences in a trace between the headers in the 200 OK (to the INVITE) and the provisional responses received right before it. The provisional responses are proxied; the 200 OK is not. Any help would be most appreciated. Thanks. On Tue, Oct 12, 2010 at 6:13 PM, thrillerbee thriller...@gmail.comwrote: I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Relaying custom header(s) in presence
Hello all, The current implementation of the pua module allows sending custom headers in PUBLISH requests. I would like to have the ability to save those headers in the presence server and relay them to presence subscribers via notifications (NOTIFY requests). This would require adding a new field to the presentity table to store the extra header(s). Each registered event must provide a list of headers to store (none given, none stored). When a PUBLISH is received, if there are header(s) to be saved, those header(s) will be saved along with the body. When the NOTIFY request is prepared, if extra header(s) are available, then those header(s) will be appended to the request. Regards, Ovidiu Sas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] DNS Failover test
Hi guys, Am a SIP and Opensips newbie and am trying to create a proof of concept on a unique (I think) Opensips and SIPS implementation. Basically am developing a web-based SIP Phone based on PHP and using Opensips. Because of the nature of the application, users will have the same domain and just one proxy server which will process invites and registrations. Based on my understanding of SIP and Opensip, I have developed a UAC that can send invites and registrations to a proxy server. My problem is coming when I have to route a call from one agent to another. According to RFC 3263 the proxy server needs to determine the sip server for the person receiving the call. Know if the proxy server of the person receiving the call and the person initiating the call is the same and both the caller and callee are on the same domain than how does Opensips route the message? I've worked on this the last few days and below is an excerpt from my log files. For some reason the proxy server is not able to route the message to user2 therefore it sends a message to user1 changing the SIP header from 100 to 407(Proxy authorization needed). Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:build_local: using FROM=From:sip:us...@72.55.133.123sip%3aus...@72.55.133.123 ;tag=232523 , TO=To:sip:us...@72.55.133.123 sip%3aus...@72.55.133.123 ;tag=9360cfebad69401b0dbd073e6bd6f131.188c , CSEQ_N=CSeq: 3 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: incoming reply Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: SIP Request: Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:t_should_relay_response: T_code=100, new_code=407 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: method: ACK Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:t_pick_branch: picked branch 0, code 407 (prio=501) Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: uri: sip:us...@72.55.133.123sip%3aus...@72.55.133.123 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=407, flags=2 Could anyone give me some insights on how to go around this problem? Any help will be appreaciated. regards, james ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Core dump in svn head
Over the past couple weeks I have been getting occasional segfaults just
prior to (or perhaps in the process of) a t_relay() in my failure_route.
Still haven't gotten to the bottom of the root cause in my config, but I
was able to find and fix the symptomatic code in the
pre_print_uac_request() function in t_fwd.c (based on Bogdan's previous
fix for a similar problem).
Backtrace:
#0 0xb763ba55 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb72ede1d in pre_print_uac_request (t=0x972ddf78, branch=1,
request=0x972cec64) at t_fwd.c:177
#2 0xb72eeac0 in add_uac (t=0x972ddf78, request=0x7fff,
uri=0xbf8a250c, next_hop=0xbf8a2514, path=0xb7315100, proxy=0x0) at
t_fwd.c:401
#3 0xb72efbc0 in t_forward_nonack (t=0x972ddf78, p_msg=0xb7314de0,
proxy=0x0) at t_fwd.c:660
#4 0xb72fbdbf in w_t_relay (p_msg=0xb7314de0, proxy=0x0, flags=value
optimized out) at tm.c:1116
#5 0x08057810 in do_action (a=0x819f924, msg=0xb7314de0) at
action.c:1155
#6 0x080557ff in run_action_list (a=0x819e7cc, msg=0xb7314de0) at
action.c:140
#7 0x0805981e in do_action (a=0x819fed4, msg=0xb7314de0) at
action.c:821
#8 0x080557ff in run_action_list (a=0x819e584, msg=0xb7314de0) at
action.c:140
#9 0x0805981e in do_action (a=0x81a0390, msg=0xb7314de0) at
action.c:821
#10 0x080557ff in run_action_list (a=0x819d588, msg=0xb7314de0) at
action.c:140
#11 0x0805aef1 in run_top_route (a=0x819d588, msg=0xb7314de0) at
action.c:120
#12 0xb7304c2c in t_should_relay_response (Trans=0x972ddf78,
new_code=408, branch=0, should_store=0xbf8a3094,
should_relay=0xbf8a3098, cancel_bitmap=0xbf8a30e8, reply=0x)
at t_reply.c:621
#13 0xb730683d in relay_reply (t=0x972ddf78, p_msg=0x, branch=0,
msg_status=408, cancel_bitmap=0xbf8a30e8) at t_reply.c:1133
#14 0xb72f21e5 in fake_reply (t=0x972ddf78, branch=0, code=408) at
timer.c:259
#15 0xb72f3dd7 in timer_routine (ticks=3285, attr=0x0) at timer.c:365
#16 0x080c12c0 in start_timer_processes () at timer.c:325
#17 0x0806e37e in main (argc=Cannot access memory at address 0x7fff
) at main.c:872
Here is the patch to fix:
Index: modules/tm/t_fwd.c
===
--- modules/tm/t_fwd.c (revision 7259)
+++ modules/tm/t_fwd.c (working copy)
@@ -166,7 +166,7 @@
-request-REQ_METHOD);
/* copy dst_uri into branch (after branch route possible updated
it) */
- if (request-dst_uri.len) {
+ if ( request-dst_uri.s request-dst_uri.len0 ) {
t-uac[branch].duri.s =
shm_resize(t-uac[branch].duri.s,
request-dst_uri.len);
if (t-uac[branch].duri.s==NULL) {
After the code change and a recompile, the following lines appear in my
logs, whereas previously at this spot OpenSIPS crashed:
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:core:parse_uri:
uri too short: (-1)
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:tm:uri2proxy:
bad_uri: (null)
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]:
ERROR:tm:t_forward_nonack: failure to add branches
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:tm:w_t_relay:
t_forward_nonack failed
Dave.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DNS Failover test
I could be wrong but does your phone register with the proxy and then the proxy create a location record for each user? That would be how opensips would know how to route it. On Oct 13, 2010 1:04 PM, James Mbuthia jmmbut...@gmail.com wrote: Hi guys, Am a SIP and Opensips newbie and am trying to create a proof of concept on a unique (I think) Opensips and SIPS implementation. Basically am developing a web-based SIP Phone based on PHP and using Opensips. Because of the nature of the application, users will have the same domain and just one proxy server which will process invites and registrations. Based on my understanding of SIP and Opensip, I have developed a UAC that can send invites and registrations to a proxy server. My problem is coming when I have to route a call from one agent to another. According to RFC 3263 the proxy server needs to determine the sip server for the person receiving the call. Know if the proxy server of the person receiving the call and the person initiating the call is the same and both the caller and callee are on the same domain than how does Opensips route the message? I've worked on this the last few days and below is an excerpt from my log files. For some reason the proxy server is not able to route the message to user2 therefore it sends a message to user1 changing the SIP header from 100 to 407(Proxy authorization needed). Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:build_local: using FROM=From:sip:us...@72.55.133.123sip%3aus...@72.55.133.123 ;tag=232523 , TO=To:sip:us...@72.55.133.123 sip%3aus...@72.55.133.123 ;tag=9360cfebad69401b0dbd073e6bd6f131.188c , CSEQ_N=CSeq: 3 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: incoming reply Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: SIP Request: Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:t_should_relay_response: T_code=100, new_code=407 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: method: ACK Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:t_pick_branch: picked branch 0, code 407 (prio=501) Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]: DBG:core:parse_msg: uri: sip:us...@72.55.133.123sip%3aus...@72.55.133.123 Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]: DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=407, flags=2 Could anyone give me some insights on how to go around this problem? Any help will be appreaciated. regards, james ___ 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] $avp in codec_exists
Hi Dimitri,
I don;t think it will pay off - especially that you can do it from
script level (multi checks in if statement)
Regards,
Bogdan
DM wrote:
Hi Bogdan,
It is hard to implement with multiple codecs?, eg. if I store it like
this:
$avp(s:codlist)=PCMA|G723|tel;
So not with just one codec.
Thanks,
Dimitri
2010/7/14 Bogdan-Andrei Iancu bog...@voice-system.ro
mailto:bog...@voice-system.ro
thanks!
Jozsef CZOMPO wrote:
Hi bogdan
Thanks for the reply. I'm opened a feature request ticket: #3029568
Czo
On 2010.07.14., at 17:33, Bogdan-Andrei Iancu wrote:
Hi Jozsef,
open a feature request on the project tracker for this small add-on
- it
sounds useful and it is not difficult to add.
Regards,
bogdan
Jozsef CZOMPO wrote:
Hi
I need to specify in database table the codec order per sip
clients.
So i'm created a table with some fields. But if use
codec_exists('PCMU') it return true, when i'm using
codec_exists($avp(s:codec)) i'm getting syntax error, and if i'm
using
codec_exists('$avp(s:codec)') i'm getting false. When i'm use xlog
( L_ERR, $avp(s:codec)); the result is PCMU, so the
avp_db_query
is working fine.
So, how can i use this?
Thank
Czo
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro http://www.voice-system.ro
___
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 mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro http://www.voice-system.ro
___
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
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS swallows BYEs
David, In this case, instead of using the expensive solution of a b2bua, why don't you take care of properly re-write the contact. The question is why do you replace the received contact with the IP of your opensips ? Regards, Bogdan David Santiago wrote: I'm not explicitly routing that BYE, but as Andrew Pogrebennyk pointed out, since I'm rewriting the Contact header with OpenSIPS address it is expected that BYE won't go any further than OpenSIPs proxy and therefore my only solutions seems to be the configuration of the b2bua modules. Isn't it? On Mon, Oct 11, 2010 at 6:35 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi David, ok, so the BYE is sent to the wrong destination - how do you route BYE in your script? do you use the standard loose_route block ? Regards, Bogdan David Santiago wrote: As I said it is being forwarded to the jain slee server that originated it. The effect is the same as if it was replied. The flow is: step 1: [JAIN SLEE SERVER] ---BYE--[OPENSIPS][VOIP PROVIDER] step 2: [JAIN SLEE SERVER] ---BYE--[OPENSIPS][VOIP PROVIDER] that BYE should be forwarded to the VOIP provider, instead. I'm having a look at how to configure the b2bua thing should this problem be fixed. Thanks for the follow up, Bogdan. David On Fri, Oct 8, 2010 at 1:38 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi David, my question is what happens with the BYE: - is it replied by opensips ? - is it forwarded to some whatever destination ? Regards, Bogdan David Santiago wrote: Bogdan, right now it's being forwarded again to the slee server who sent it, as I'm basically using the configuration provided in http://www.opensips.org/html/docs/modules/1.6.x/dispatcher.html On Wed, Oct 6, 2010 at 4:16 PM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi David, Is the BYE replied or forwarded to whatever destination ? probably your record routing is somehow broken. OpenSIPS may misroute the BYE because the invalid route set - posting the 200 OK for INVITE and the BYE will help in investigating this. Regards, Bogdan David Santiago wrote: Hi all, I have a running OpenSIPS installation that I'm using for testing purposes. The fact is that I'm forwarding requests from a voip provider to a jain slee server and everything is working fine (INVITEs, ACKs, RTP flow,...), except for the BYEs generated from the server side. They reach the OpenSIPs proxy and are not forwarded to the voip provider in order to finish the call. I'm not sure if I have to manually setup a route for this to happen, or if this behaviour is only available by using the B2BUA approach in OpenSIPS. Thanks a lot! David -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Permissions Module bug in 1.6.3 ?
Thanks Logan, The patch was already uploaded on SVN trunk and stable. Regards, Bogdan logan wrote: Bogdan, I've applied the patch you provided and initial testing has been successful. I'll keep you posted on the rest of my tests. Thank you for your attention to this! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] regular expression matching
Hi Gabriel,
why don't you use in DR 2 different rule with different strip and
pri_prefix like:
rule1:
matches:00593
strips: 5 digits
pri_prefix: 7424
rule2:
matches:001 (or you can use default rule with empty matching prefix)
strips: 0 digits
pri_prefix: 7424
The GWs used by each rule can be the same, of course.
Regards,
Bogdan
Gabriel Bermudez wrote:
hi bodgan
true, the problem is my voip provider, all calls must be delivered
with a pri prefix at the begining, but local calls must be delivered
without the E.164 prefix and I receive all my calls in E.164 so I must
replace this prefix with another on, so for a local call.
local call (593 E.164 prefix)
005938 - 74248
international call
0015678942356 - 74240015678942356
I have managed to check for the special prefix with this expression
do_routing();
$avp(s:pri_local) = $(avp(s:dr_attrs){param.value,pri_local});
$avp(s:pri_local_re) = sip:+$avp(s:pri_local)+*;
xlog(check if $ru matches $avp(s:pri_local_re));
if(avp_check($ruri, fm/$avp(s:pri_local_re))) {
$avp(s:pri_replace) = $(avp(s:dr_attrs){param.value,pri_replace});
xlog($avp(s:pri_local) must be replaced by $avp(s:pri_replace));
$avp(s:new_uri) = $rU;
$avp(s:local_len) = $(avp(s:pri_local){s.len});
$avp(s:new_uri) = $avp(s:pri_replace) +
$(avp(s:new_uri){s.substr,$avp(s:local_len),0});
xlog(new uri $avp(s:new_uri));
$rU = $avp(s:new_uri);
}
works, but I would like to do the replacement less verbose, for
performace reasons mainly. Can it be done?
Regards,
2010/10/11 Bogdan-Andrei Iancu bog...@voice-system.ro:
Hi Gabriel,
when using regexp ops, you cannot use variables in the regexp definition.
But your I miss your logic here - if you do routing based on prefixes
(do_routing() ), why do you need an extra regexp checking for that rule
? if the Rule matches, you already know that RURI looks like
sip:7424005938...@a.b.c.d
Regards,
Bogdan
Gabriel Bermudez wrote:
Hi everyone,
I'm having trouble creating a regex in the opensips.cfg file. This is
the snipplet
modparam(drouting, attrs_avp, '$avp(s:dr_attrs)')
...
do_routing();
$avp(s:special) = $(avp(s:dr_attrs){param.value,special});
xlog(attrs/$avp(s:dr_attrs) special/$avp(s:special) rU/$ru
^sip:$avp(s:special)[0-9]*@);
if (uri =~ ^sip:$avp(s:special)[0-9]*@) {
xlog(do something to the R-URI);
}
the $avp(s:dr_attrs) gets loaded with special=742400593, so the
avp(s:special) has the value 742400593 and the the $ru variable
which I presume must have the same value of the uri variable has
sip:7424005938...@a.b.c.d, but for some reason the expression is
not returning true. What I'm doing wrong.
Regards,
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
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
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] failed to decode uri
Hi, regarding the decode_uri issue : the uac module stores a cookie in the RR header, so at Route time it will be able to restore the original FROM / TO hdr. I suspect that the one of the parties (caller or callee) is messing around with this RR parameter (vsf , vst), most probably with the case sensitiveness (switching from lower to upper case). If you post a SIP trace on proxy, I can point you to the bogus party. Regards, Bogdan thrillerbee wrote: To add a little more detail, after doing some from uri normalization, this is eventually passed on to an OpenSIPS instance running b2bua for top hiding. I'm assuming this error indicates that the header param that is used to rebuild the original from uri is different than expected, but I don't see any discernible differences in a trace between the headers in the 200 OK (to the INVITE) and the provisional responses received right before it. The provisional responses are proxied; the 200 OK is not. Any help would be most appreciated. Thanks. On Tue, Oct 12, 2010 at 6:13 PM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com wrote: I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] failed to decode uri
Again, can you post a trace of the message causing the error? Regards, Bogdan thrillerbee wrote: I was forced to remove the OpenSIPS b2bua as it seems it was causing the origination gateway to choke on these 200 OKs. Dialogs are no longer hanging, but I still see errors on the origination gateway that are concerning: /usr/local/sbin/opensips[4399]: ERROR:core:parse_from_header: bad from header /usr/local/sbin/opensips[4399]: ERROR:rr:record_route: From parsing failed /usr/local/sbin/opensips[4402]: ERROR:core:parse_to: unexpected char [#000] in status 6: 2345678910sip:2345678...@6.12.24.48:5060 http://sip:2345678...@6.12.24.48:5060 I can't find anything out of the ordinary in traces. What should I be looking for? Again, any help would be appreciated. Thanks. On Tue, Oct 12, 2010 at 9:15 PM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com wrote: To add a little more detail, after doing some from uri normalization, this is eventually passed on to an OpenSIPS instance running b2bua for top hiding. I'm assuming this error indicates that the header param that is used to rebuild the original from uri is different than expected, but I don't see any discernible differences in a trace between the headers in the 200 OK (to the INVITE) and the provisional responses received right before it. The provisional responses are proxied; the 200 OK is not. Any help would be most appreciated. Thanks. On Tue, Oct 12, 2010 at 6:13 PM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com wrote: I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] error in opensips-cp
Hi Leon, Have you created the ocp_admin_privileges table ? see the install instructions for OpenSIPS control panel on http://opensips-cp.sourceforge.net/ Regards, Bogdan Leon Li wrote: Hi , I followed the instruction in “build telephony system with opensips 1.6” to install opensips-cp. However, an error comes up when access the link http://localhost/cp. Failed to issue query, error message: MDB2 Edrror: no such table. I did import the two tables for cdr and smonitor, and both appears in mysql. Any ideas? I can generate a log file as instructed. Regards Leon ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] loose_route and $du
Hi Stefano,
yes, it is possible - if the request does not have any other Route hdr
to indicate the next hope, routing based on RURI will be done, so the
loose_route function will not set any $du (destination URI) - this du
is actually a kind of outbound proxy used by opensips when it wants to
send the request to other destination than RURI.
Such a case is when your opensips is the last hop before the end client.
Regards,
Bogdan
Stefano Sasso wrote:
Hello,
sorry for the newbie stupid question.
Is it normal that after a loose_route() the $du is set to null?
this is my config:
if (loose_route()) {
if (is_method(BYE)) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction
fails
} else if (is_method(INVITE)) {
# even if in most of the cases is
useless, do RR for
# re-INVITEs alos, as some buggy
clients do change route set
# during the dialog.
record_route();
}
# route it out to whatever destination was set
by loose_route()
# in $du (destination URI).
xlog([LOOSE_ROUTE] from $si:$sp method $rm
SET_DESTINATION $du);
route(1);
}
in my log file I have:
Oct 13 12:09:42 TDCVIRX09 /usr/local/sbin/opensips[17647]:
[LOOSE_ROUTE] from 192.168.6.132:10002 method BYE SET_DESTINATION
null
thanks
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Changing Opensips port number
Hi James, how do you set the port? via port param or via the listen param? are you sure you restart was effective? Regards, Bogdan James Mbuthia wrote: Hi, Sorry for the newbie question. How do you change the port number in opensips? I want to change it from 5060 to something else however when I do so on opensips.cfg and restart opensips, Opensips doesn't seem to listen on the port I have specified. Do I need to change the number elsewhere? regards james ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Core dump in svn head
Hi Dave,
In failure route, how do you add the new destination/branch ?
Also, do you have a branch route set ?
Regards,
Bogdan
Dave May wrote:
Over the past couple weeks I have been getting occasional segfaults just
prior to (or perhaps in the process of) a t_relay() in my failure_route.
Still haven't gotten to the bottom of the root cause in my config, but I
was able to find and fix the symptomatic code in the
pre_print_uac_request() function in t_fwd.c (based on Bogdan's previous
fix for a similar problem).
Backtrace:
#0 0xb763ba55 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb72ede1d in pre_print_uac_request (t=0x972ddf78, branch=1,
request=0x972cec64) at t_fwd.c:177
#2 0xb72eeac0 in add_uac (t=0x972ddf78, request=0x7fff,
uri=0xbf8a250c, next_hop=0xbf8a2514, path=0xb7315100, proxy=0x0) at
t_fwd.c:401
#3 0xb72efbc0 in t_forward_nonack (t=0x972ddf78, p_msg=0xb7314de0,
proxy=0x0) at t_fwd.c:660
#4 0xb72fbdbf in w_t_relay (p_msg=0xb7314de0, proxy=0x0, flags=value
optimized out) at tm.c:1116
#5 0x08057810 in do_action (a=0x819f924, msg=0xb7314de0) at
action.c:1155
#6 0x080557ff in run_action_list (a=0x819e7cc, msg=0xb7314de0) at
action.c:140
#7 0x0805981e in do_action (a=0x819fed4, msg=0xb7314de0) at
action.c:821
#8 0x080557ff in run_action_list (a=0x819e584, msg=0xb7314de0) at
action.c:140
#9 0x0805981e in do_action (a=0x81a0390, msg=0xb7314de0) at
action.c:821
#10 0x080557ff in run_action_list (a=0x819d588, msg=0xb7314de0) at
action.c:140
#11 0x0805aef1 in run_top_route (a=0x819d588, msg=0xb7314de0) at
action.c:120
#12 0xb7304c2c in t_should_relay_response (Trans=0x972ddf78,
new_code=408, branch=0, should_store=0xbf8a3094,
should_relay=0xbf8a3098, cancel_bitmap=0xbf8a30e8, reply=0x)
at t_reply.c:621
#13 0xb730683d in relay_reply (t=0x972ddf78, p_msg=0x, branch=0,
msg_status=408, cancel_bitmap=0xbf8a30e8) at t_reply.c:1133
#14 0xb72f21e5 in fake_reply (t=0x972ddf78, branch=0, code=408) at
timer.c:259
#15 0xb72f3dd7 in timer_routine (ticks=3285, attr=0x0) at timer.c:365
#16 0x080c12c0 in start_timer_processes () at timer.c:325
#17 0x0806e37e in main (argc=Cannot access memory at address 0x7fff
) at main.c:872
Here is the patch to fix:
Index: modules/tm/t_fwd.c
===
--- modules/tm/t_fwd.c (revision 7259)
+++ modules/tm/t_fwd.c (working copy)
@@ -166,7 +166,7 @@
-request-REQ_METHOD);
/* copy dst_uri into branch (after branch route possible updated
it) */
- if (request-dst_uri.len) {
+ if ( request-dst_uri.s request-dst_uri.len0 ) {
t-uac[branch].duri.s =
shm_resize(t-uac[branch].duri.s,
request-dst_uri.len);
if (t-uac[branch].duri.s==NULL) {
After the code change and a recompile, the following lines appear in my
logs, whereas previously at this spot OpenSIPS crashed:
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:core:parse_uri:
uri too short: (-1)
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:tm:uri2proxy:
bad_uri: (null)
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]:
ERROR:tm:t_forward_nonack: failure to add branches
Oct 12 16:04:13 sipdev1 /usr/sbin/opensips[31245]: ERROR:tm:w_t_relay:
t_forward_nonack failed
Dave.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] B2BUA Transfers Intermittently Working/Not Working (Bug?)
Hello Everyone, In an attempt to figure out the best way to build my OpenSIPS config with the B2BUA module included, I've started over with a very simple script implementing nothing but the B2BUA module (and usrloc). My goal is to allow the phones to place calls between them and transfer the calls to other local phones (similar to a PBX). I have the B2BUA module configured to allow the call to be transferred (REFER) up to 4 times. This scenario script and OpenSIPS config file work well depending on which leg of the call is being transferred. It appears that the originator of the call cannot be put back on the opposite leg of the call, as shown in the second example above. Another way to think of the problem is that the remote side cannot be transferred. For both of the scenarios below, I have 3 phones. One is for the Sales department, one is for Tech Support, and the third represents the Boss. Here is a scenario where I can transfer the call four times successfully: 1. Sales places a call to Tech Support. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 2. Sales transfers his leg of the call to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) 3. The Boss transfers his leg of the call back to Sales. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 4. Sales transfers his leg of the call back to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) Here is a scenario where the process is interrupted: 1. Sales places a call to Tech Support. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 2. Sales transfers his leg of the call to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) 3. Tech Support transfers his leg of the call back to Sales. (The Boss has the local side of the call, and Sales has the remote side of the call.) **THE CALL FAILS AT THIS POINT** - The Boss's phone is left on the call with nobody on the other end. Tech Support's phone appears to transfer successfully. Nothing happens with the Sales phone. My OpenSIPS Server is at 1.2.3.4 in this example, and the phones are on the 10.20.1.x subnet. There is no NAT between the devices. This appears to be no correlation between which devices are doing the transferring (meaning the Boss and Tech Support could switch roles and it still fails). I am running OpenSIPS 1.6.3 on CentOS 5.5 x64. I'll send my log file, config file, and scenario file in a moment (they were too big to fit in one email). Brett Woollum br...@woollum.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialplan problem ?
Hi Marcio,
The answer is:
Oct 13 17:05:47 perseu /sbin/opensips[13077]: DBG:dialplan:build_rule:
references:1 , max:1
Oct 13 17:05:47 perseu /sbin/opensips[13077]: DBG:dialplan:destroy_rule:
destroying rule with priority 1
It looks like opensips rejects the rules while loading them at startup,
so basically you end up with no rule at runtime.
what opensips version are you using ?
Regards,
Bogdan
Marcio Veloso Antunes wrote:
Hi guys,
Sorry to bother you, but i can't find the problem why this is not working:
Actual dialplan:
r...@perseu:/etc/opensips# opensipsctl dialplan show
dialplan tables
id | dpid | pr | match_op | match_exp | match_len | subst_exp |
repl_exp | attrs
+--++--+---+---+-+--+---
18 | 1 | 0 | 1 | ^00[1-9][0-9]+ | 0 | ^0(0[1-9][0-9]+) | \1 |
19 | 1 | 1 | 1 | ^00[1-9][1-9][0-9]{8} | 0 | ^0(0[1-9][1-9][0-9]{8}) |
\1 |
(2 rows)
String being tested: '002185392949'
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Transfers Intermittently Working/Not Working (Bug?)
Unfortunately the mailing list won't let me send replies with my logs or config file since they're too big. You can find them on this page: http://www.woollum.com/temp/opensips.txt Thanks! Brett Woollum br...@woollum.com - Original Message - From: Brett Woollum br...@woollum.com To: users-request users@lists.opensips.org Sent: Wednesday, October 13, 2010 1:50:06 PM GMT -08:00 US/Canada Pacific Subject: [OpenSIPS-Users] B2BUA Transfers Intermittently Working/Not Working (Bug?) Hello Everyone, In an attempt to figure out the best way to build my OpenSIPS config with the B2BUA module included, I've started over with a very simple script implementing nothing but the B2BUA module (and usrloc). My goal is to allow the phones to place calls between them and transfer the calls to other local phones (similar to a PBX). I have the B2BUA module configured to allow the call to be transferred (REFER) up to 4 times. This scenario script and OpenSIPS config file work well depending on which leg of the call is being transferred. It appears that the originator of the call cannot be put back on the opposite leg of the call, as shown in the second example above. Another way to think of the problem is that the remote side cannot be transferred. For both of the scenarios below, I have 3 phones. One is for the Sales department, one is for Tech Support, and the third represents the Boss. Here is a scenario where I can transfer the call four times successfully: 1. Sales places a call to Tech Support. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 2. Sales transfers his leg of the call to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) 3. The Boss transfers his leg of the call back to Sales. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 4. Sales transfers his leg of the call back to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) Here is a scenario where the process is interrupted: 1. Sales places a call to Tech Support. (Sales has the local side of the call, and Tech Support has the remote side of the call.) 2. Sales transfers his leg of the call to the Boss. (The Boss has the local side of the call, and Tech Support has the remote side of the call.) 3. Tech Support transfers his leg of the call back to Sales. (The Boss has the local side of the call, and Sales has the remote side of the call.) **THE CALL FAILS AT THIS POINT** - The Boss's phone is left on the call with nobody on the other end. Tech Support's phone appears to transfer successfully. Nothing happens with the Sales phone. My OpenSIPS Server is at 1.2.3.4 in this example, and the phones are on the 10.20.1.x subnet. There is no NAT between the devices. This appears to be no correlation between which devices are doing the transferring (meaning the Boss and Tech Support could switch roles and it still fails). I am running OpenSIPS 1.6.3 on CentOS 5.5 x64. I'll send my log file, config file, and scenario file in a moment (they were too big to fit in one email). Brett Woollum br...@woollum.com ___ 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] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Hi Taisto,
Your problem is not timer related or how serial forking is done in
opensips (I will comment on these in a later reply).
Right now, the quick answer to fix your problem: failure route must be
re-armed after each branch - this is why your failure route does not
catches the end of the second branch. Adding a t_on_failure(1) before
t_relay() in failure route will fix your problem.
Regards,
Bogdan
Taisto Qvist wrote:
Hi Bogdan,
I've now been trying with some tests, and I cant really get it to work,
since the transactionlayer on the server transaction returns a 408
back to the UAC before serial forking has ended.
This seems a little bit related to what I once commented on a long time
ago regarding handling of timer C and the fact that the timer c seems to
be quite tied to Timer B
When the fr_timer pops, (causing the CANCEL to be sent so that we can move
on to the next serial-fork-target), the tm-layer seems store this
timer-pop
as a 408 response
20:41:44 osips[4686]: DBG:tm:utimer_routine: timer
routine:4,tl=0xb5b6770c next=(nil), timeout=64930
20:41:55 osips[4686]: DBG:tm:timer_routine: timer
routine:1,tl=0xb5b67728 next=(nil), timeout=660
20:41:55 osips[4686]: DBG:tm:final_response_handler: stop retr. and
send CANCEL (0xb5b675c0)
20:41:55 osips[4686]: DBG:tm:t_should_relay_response: T_code=180,
new_code=408
20:41:55 osips[4686]: DBG:tm:t_pick_branch: picked branch 0, code 408
(prio=800)
As the capture and log I've attached indicates, I am not able to
perform a three
step serial fork. I have three Uas:es registered with 1.0, 0.9, and
0.8 in q-values.
First timer pop causes a CANCEL, and a new INVITE towards UAS with
q=0.9, but when
it pops the second time, TM still cancels the second target, but
instead of continuing
with the third, it sends a 408 towards the UAC.
It might be something with my script-handling in the failure_route, so
here it is:
failure_route[1]
{
if ( t_was_cancelled() )
{
log(2, transaction was cancelled by UAC\n);
}
xlog((lab1) - In FailureRoute: branches=$(branch(uri)[*])\n);
if ( isflagset(1) )
{
log(2,(lab1) - 3++ Received, attempting serial fork!\n);
next_branches();
switch ( $retcode )
{
case 1:
log(2,(lab1) - More branches left, rollOver timer
set.);
$avp(s:timerC) = 12;
setflag(1); # Do I need this? Should I use
branchflags instead?
break;
case 2:
log(2,(lab1) - Last branch, timerC set to 60 sec);
$avp(s:timerC) = 60;
break;
default:
log(2,(lab1) - No more serial fork targets.);
exit;
}
if ( !t_relay() )
{
log(2,(lab1) - Error during relay for serial fork!\n);
}
}
else
{
log(2,(lab1) - 3++ result. Serialforking not available.\n);
}
}
When I say that it seems related to another issue I commented on a
long time
ago, I am referring to the general handling of Timer C, which doesn't
seem to
be a separate timer, but is reusing the timerB.
When the timer pops after the normal 180 seconds, the TM layer will
*instantly*
generate a 408 response on the server txn, while at the same time
generating
the CANCEL attempting to terminate the client txn.
To me, this is wrong, but maybe I am suppose to handle this in the
failure_route?
What I would expect is that the CANCEL will cause a 487 response from
the UAS,
and this will be the final response sent to the UAC.
Also by behaving this way, we may cause a protocol violation even
though the risk
is small.
Once timer C pops we send the CANCEL hoping that it will cause a 487.
BUT, it is
quite possible that before the cancel is received by the UAS, it sends
a 200 to
the INVITE! Even IF the CANCEL receives a 2xx response, we may still
get a 2xx
response to the INVITE.
But with the current behavior of opensips, this would cause opensips
to proxy
TWO final responses on the server txn, once being the initial 408 sent
by the
txn on timer C timeout, and then the real/actual 2xx sent by the uas.
I've also seen a similar problem with 6xx responses received on a
branch during
forking.
Opensips forwards the 6xx *before* the remaining client txns has
completed, and
there is no guarantee that these client txns will all terminate with
487 even
if opensips tries to CANCEL all of them asap.
They may still return 2xx to the invite, which would cause a
forwarding of both
a 6xx and a 2xx on the server txn. This scenario is even mentioned in
rfc3261.
So all these three problems have in common that the server txn seems
to be
terminating a bit early, before the client side has fully completed,
but as
I said, it might at least partially be something I should handle in my
[OpenSIPS-Users] Services management - question about proper module
Hello. I am planning to provide opensips with a kind of mechanism to manage customer services/features like call-forward/VM/follow-me and so on. It should work in following way: If $rU is provided in subscriber table then user enabled service name is obtained from some db table. On the basis of that value opensips should do the magic :) The question is what kind of module is the best to follow. Is it AVPops or maybe there is another way to achieve my goal. What are pros and cons. Thx in advance, Maciej. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DNS Failover test
But when does the proxy create a location record?
When the callee phone registers it gets an authenticate challenge and
after the challenge it gets a 200 Ok header.
When the caller phone calls it gets a 407 proxy challenge and after
verification gets a 100 response.
According to my understanding the proxy creates a location record for
the person being called, however this is not entered into the
database so where is it? Below is a snippet of my invite and register
code in opensips.cfg
if (!(method==REGISTER) from_uri==myself) /*no multidomain version*/
##if (!(method==REGISTER) is_from_local()) /*multidomain */
##
{
if (!proxy_authorize(, subscriber)) {
proxy_challenge(, 0);
exit;
}
if (!db_check_from()) {
sl_send_reply(403,Forbidden auth ID);
exit;
}
consume_credentials();
## # caller authenticated
}
if (is_method(REGISTER))
{
# authenticate the REGISTER requests (uncomment to enable auth)
if (!www_authorize(, subscriber))
{
www_challenge(, 0);
exit;
}
##
if (!db_check_to())
{
sl_send_reply(403,Forbidden auth ID);
exit;
}
if (!save(location))
sl_reply_error();
exit;
}
}
The proxy does not save the location details under the location table
however sending an invite before the callee has been registered
results in a 405. So, where does the proxy save the callee location if
its not saving on the database? And how do I need to go around that?
On 10/13/10, Bogdan-Andrei Iancu bog...@voice-system.ro wrote:
Right, and before that, when receiving a request, a proxy looks at the
domain part of RURI to see if that domain is a SIP domain that can be
locally handled or a it is a foreign SIP domain that need to forward to
another SIP server.
So, check if the domain RURI is a local domain - see the default
opensips.cfg for an example how to do it.
Regards,
Bogdan
Duane Larson wrote:
I could be wrong but does your phone register with the proxy and then
the proxy create a location record for each user? That would be how
opensips would know how to route it.
On Oct 13, 2010 1:04 PM, James Mbuthia jmmbut...@gmail.com
mailto:jmmbut...@gmail.com wrote:
Hi guys,
Am a SIP and Opensips newbie and am trying to create a proof of
concept on a unique (I think) Opensips and SIPS implementation.
Basically am developing a web-based SIP Phone based on PHP and using
Opensips. Because of the nature of the application, users will have
the same domain and just one proxy server which will process invites
and registrations. Based on my understanding of SIP and Opensip, I
have developed a UAC that can send invites and registrations to a
proxy server. My problem is coming when I have to route a call from
one agent to another. According to RFC 3263 the proxy server needs to
determine the sip server for the person receiving the call. Know if
the proxy server of the person receiving the call and the person
initiating the call is the same and both the caller and callee are on
the same domain than how does Opensips route the message?
I've worked on this the last few days and below is an excerpt from my
log files. For some reason the proxy server is not able to route the
message to user2 therefore it sends a message to user1 changing the
SIP header from 100 to 407(Proxy authorization needed).
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]:
DBG:tm:build_local: using FROM=From:sip:us...@72.55.133.123
mailto:sip%3aus...@72.55.133.123;tag=232523
, TO=To:sip:us...@72.55.133.123
mailto:sip%3aus...@72.55.133.123
;tag=9360cfebad69401b0dbd073e6bd6f131.188c
, CSEQ_N=CSeq: 3
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]:
incoming reply
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]:
DBG:core:parse_msg: SIP Request:
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]:
DBG:tm:t_should_relay_response: T_code=100, new_code=407
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]:
DBG:core:parse_msg: method: ACK
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]:
DBG:tm:t_pick_branch: picked branch 0, code 407 (prio=501)
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19405]:
DBG:core:parse_msg: uri: sip:us...@72.55.133.123
mailto:sip%3aus...@72.55.133.123
Oct 13 08:26:53 CL-T020-483CL /usr/local/sbin/opensips[19406]:
DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=407,
flags=2
Could anyone give me some insights on how to go around this problem?
Any help will be appreaciated.
regards,
james
Re: [OpenSIPS-Users] Changing Opensips port number
Hi Bogdan, I set the port on opensips.cfg like: port=5060 /* uncomment and configure the following line if you want opensips to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:198.162.1.0:5060 I change the 5060 to another number then restart using opensipsctl. Is there something else I have missed? james On 10/13/10, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, how do you set the port? via port param or via the listen param? are you sure you restart was effective? Regards, Bogdan James Mbuthia wrote: Hi, Sorry for the newbie question. How do you change the port number in opensips? I want to change it from 5060 to something else however when I do so on opensips.cfg and restart opensips, Opensips doesn't seem to listen on the port I have specified. Do I need to change the number elsewhere? regards james ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ 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] Core dump in svn head
Yes, I do set a branch_route to strip RPID header and strip/set the
P-Asserted-Identity header.
I'm using drouting, and that portion of the failure_route is based on
the code from Flavio's book (with the addition of e164 mangling,
t_on_branch to handle the header stuff mentioned above, and t_on_failure
to handle multiple failures):
if(isflagset(10)){
if (!t_check_status(408|[56][0-9][0-9])) {
# this is not a GW failure
exit;
}
if (use_next_gw()) {
xlog($ci\t$C(rc)$si $rm$C(xx)
$C(xr)failure_route[1]$C(xx)
$C(xr)use_next_gw()=$C(rg)$ru$C(xx)\n);
### Need to duplicate e164 check from original
do_routing() call
### Want to do this in branch_route, but not
allowed to use is_uri_user_e164() there
###
#
# Does the gateway entry request e164 format?
if ($avp(s:dr_gw_attrs) != )
($(avp(s:dr_gw_attrs){param.value,format})==e164) {
xlog($ci\t$C(rc)$si $rm$C(xx)
failure_route[1] Gateway requires e164 format\n);
# Check and fix RURI
if (is_uri_user_e164($ru)) {
xlog($ci\t$C(rc)$si $rm$C(xx)
failure_route[1] $ru is in e164 format\n);
} else {
xlog($ci\t$C(rc)$si $rm$C(xx)
failure_route[1] $ru is not in e164 format\n);
dp_translate(3);
}
}
# Need to ensure that failures on the failure
are also handled
t_on_branch(1);
t_on_failure(1);
xlog($ci\t$C(rc)$si $rm$C(xx)
failure_route[1] t_relay() next rU = $rU fU=$fU
tU=$tU du=$du\n);
setdebug(4);
t_relay();
setdebug();
xlog($ci\t$C(rc)$si $rm$C(xx)
failure_route[1] t_relay() complete\n);
exit;
} else {
xlog($ci\t$C(rc)$si $rm$C(xx)
$C(xr)failure_route[1]-$C(xx) isflagset(10) $C(sr)-- use_next_gw()
FAILED!!!$C(xx)\n);
t_reply(503, Service not available, no more
gateways);
exit;
}
Dave.
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei
Iancu
Sent: Wednesday, October 13, 2010 4:43 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Core dump in svn head
Hi Dave,
In failure route, how do you add the new destination/branch ?
Also, do you have a branch route set ?
Regards,
Bogdan
Dave May wrote:
Over the past couple weeks I have been getting occasional segfaults
just
prior to (or perhaps in the process of) a t_relay() in my
failure_route.
Still haven't gotten to the bottom of the root cause in my config, but
I
was able to find and fix the symptomatic code in the
pre_print_uac_request() function in t_fwd.c (based on Bogdan's
previous
fix for a similar problem).
Backtrace:
#0 0xb763ba55 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb72ede1d in pre_print_uac_request (t=0x972ddf78, branch=1,
request=0x972cec64) at t_fwd.c:177
#2 0xb72eeac0 in add_uac (t=0x972ddf78, request=0x7fff,
uri=0xbf8a250c, next_hop=0xbf8a2514, path=0xb7315100, proxy=0x0) at
t_fwd.c:401
#3 0xb72efbc0 in t_forward_nonack (t=0x972ddf78, p_msg=0xb7314de0,
proxy=0x0) at t_fwd.c:660
#4 0xb72fbdbf in w_t_relay (p_msg=0xb7314de0, proxy=0x0, flags=value
optimized out) at tm.c:1116
#5 0x08057810 in do_action (a=0x819f924, msg=0xb7314de0) at
action.c:1155
#6 0x080557ff in run_action_list (a=0x819e7cc, msg=0xb7314de0) at
action.c:140
#7 0x0805981e in do_action (a=0x819fed4, msg=0xb7314de0) at
action.c:821
#8 0x080557ff in run_action_list (a=0x819e584, msg=0xb7314de0) at
action.c:140
#9 0x0805981e in do_action (a=0x81a0390, msg=0xb7314de0) at
action.c:821
#10 0x080557ff in run_action_list (a=0x819d588, msg=0xb7314de0) at
action.c:140
#11 0x0805aef1 in run_top_route (a=0x819d588, msg=0xb7314de0) at
action.c:120
#12 0xb7304c2c in t_should_relay_response (Trans=0x972ddf78,
new_code=408, branch=0, should_store=0xbf8a3094,
should_relay=0xbf8a3098, cancel_bitmap=0xbf8a30e8, reply=0x)
at t_reply.c:621
#13 0xb730683d in relay_reply (t=0x972ddf78, p_msg=0x,
branch=0,
msg_status=408, cancel_bitmap=0xbf8a30e8) at t_reply.c:1133
