Re: [OpenSIPS-Users] Users Digest, Vol 21, Issue 4
Hi Bogdan, Thanks for reply. I fill up; modparam(nathelper,rtpproxy_sock,udp: 127.0.0.1:7890), but still getting errors as listed below; Apr 2 11:43:49 rose /usr/local/sbin/opensips[16309]: ERROR:nathelper:force_rtp_proxy_body: no available proxies Apr 2 11:43:52 rose /usr/local/sbin/opensips[16310]: ERROR:nathelper:unforce_rtp_proxy_f: no available proxies Apr 2 11:43:52 rose /usr/local/sbin/opensips[16311]: ERROR:nathelper:force_rtp_proxy: Unable to parse body Please advise to overcome this problem. From: Bogdan-Andrei Iancu bog...@voice-system.ro Subject: Re: [OpenSIPS-Users] Getting Error when using NATHELPER module To: OpenSIPS users mailling list users@lists.opensips.org Message-ID: 4bb471de.8070...@voice-system.ro Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello Ahmed, you script does not configure any rtpproxy to be used - the rtpproxy_sock parameter is empty: modparam(nathelper,rtpproxy_sock,) You need to set a valid link to a running rtpproxy : http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id228332 Regards, Bogdan Ahmed Munir wrote: Hi, I've configured OpenSIPs with Radius and now working to configure NAT on OpenSIPs using module mod_nathelper. After configuring, I'm getting following errors as listed down below; Apr 1 11:53:31 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:select_rtpp_node: script error -no valid set selected Apr 1 11:53:31 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:force_rtp_proxy_body: no available proxies Apr 1 11:53:46 rose /usr/local/sbin/opensips[11382]: ERROR:nathelper:select_rtpp_node: script error -no valid set selected Apr 1 11:53:46 rose /usr/local/sbin/opensips[11382]: ERROR:nathelper:unforce_rtp_proxy_f: no available proxies Apr 1 11:53:46 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:force_rtp_proxy: Unable to parse body And the configuration of OpenSIPs is listed below; [...] Kindly state, how can I resolve this error in my above configuration. Please advise. -- Regards, Ahmed Munir ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro -- Regards, Ahmed Munir ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
Hi Jeff, Jeff Pyle wrote: This goes way back. Bogdan addressed it last year sometime, citing a reason why ACK processing is slower than other processing. And, since the two messages hit different children of Opensips, the ACK hits the exit gate after the reINVITE, even though the ACK arrived first. I've seen it with Broadworks and Asterisk. There were a number of solutions posted although none of them worked for me. My workaround is to call a perl script to sleep for 100ms if the message is not an ACK. That allows the ACK time to get through. For this solution, you can use the usleep function provided by opensips : http://www.opensips.org/html/docs/modules/1.6.x/cfgutils.html#id228403 And you can optimize this a bit by doing sleep only for the non-ACK sequential requests - check based on totag. Also , if you were using dialog support, you can check the dialog state, and if there is an re-INVITE for a dialog still in confirmed but not acked state, do the sleep, otherwise, let it go through. I would certainly love a real solution, that is, speeding up the ACK or some other mechanism to enforce the sequence. The problem is that opensips tries to do something more than it should - it tries to match (as transactions) the ACK for 200 OK against the INVITE - this is bogus (the the 200 OK ACK and INVITE are separate transactions) and the algorithm is very slow and costly - normally this is dialog matching and not transaction matching. I would love to disable that part (and be fully RFC compliant), but this will alter some of the current behaviour, like : - ACC module is using TM to get the 200OK ACK - not sure how many people are using it. - OSP module is using that also, so sure for what purposes. Regards, Bogdan - Jeff On Apr 1, 2010, at 3:47 PM, Brett Nemeroff wrote: Hello All, I'm working with a Broadsoft which is setup to send outbound calls to OpenSIPs. The Broadsoft extension is set to ring simultaneously multiple extensions. One which hits the proxy and the other is internal on the broadsoft. What I'm seeing is an outbound call from broadsoft to the proxy to the provider (normal) the provider answers and replies with a 200 OK, forwarded onto broadsoft, without problem. However, then I immediately get a ACK / INVITE FROM the broadsoft in reply to the 200 OK. That seems ok, but when it goes to the provider the ORDER is switched and it forwards the INVITE first THEN the ACK. I'm not sure if that matters, but the provider is replying with a 400 Bad Request. Which may be because I'm trying to reinvite a call which hasn't been ACKd yet? Any ideas here? why would the order change? And could this potentially cause call setup issues? Thanks, Brett ___ 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 www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Could I use mysql lines in opensips.cfg?
or for any kind of mysql query, you may use the avp_db_query function from avpops module: http://www.opensips.org/html/docs/modules/1.6.x/avpops.html#id271033 Regards, Bogdan Brett Nemeroff wrote: I personally would probably end up storing the users into memcache and checking against that. the userblacklist module might also do what you need.. http://www.opensips.org/html/docs/modules/1.6.x/userblacklist.html#id227282 On Fri, Apr 2, 2010 at 12:15 AM, CheeWii quanwe...@gmail.com wrote: Hi, I use Opensips as an SMS gateway. Now I need to check all message's username firstly. If the username is in my mysql database,thus it belong to the white name-list,then I realy it normally.If not ,I will drop it directlly. So I think I should exec some some mysql commands to check the usename. How can I accomplish it? Thanks a lot:) 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 -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Users Digest, Vol 21, Issue 4
Hi Ahmed, At startup, do you see any errors about nathelper module failing to connect to rtpproxy ? becuase the module will simply disable and ignore the rtpptroxy for usage. Regards, Bogdan Ahmed Munir wrote: Hi Bogdan, Thanks for reply. I fill up; modparam(nathelper,rtpproxy_sock,udp:127.0.0.1:7890 http://127.0.0.1:7890), but still getting errors as listed below; Apr 2 11:43:49 rose /usr/local/sbin/opensips[16309]: ERROR:nathelper:force_rtp_proxy_body: no available proxies Apr 2 11:43:52 rose /usr/local/sbin/opensips[16310]: ERROR:nathelper:unforce_rtp_proxy_f: no available proxies Apr 2 11:43:52 rose /usr/local/sbin/opensips[16311]: ERROR:nathelper:force_rtp_proxy: Unable to parse body Please advise to overcome this problem. From: Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro Subject: Re: [OpenSIPS-Users] Getting Error when using NATHELPER module To: OpenSIPS users mailling list users@lists.opensips.org mailto:users@lists.opensips.org Message-ID: 4bb471de.8070...@voice-system.ro mailto:4bb471de.8070...@voice-system.ro Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello Ahmed, you script does not configure any rtpproxy to be used - the rtpproxy_sock parameter is empty: modparam(nathelper,rtpproxy_sock,) You need to set a valid link to a running rtpproxy : http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id228332 Regards, Bogdan Ahmed Munir wrote: Hi, I've configured OpenSIPs with Radius and now working to configure NAT on OpenSIPs using module mod_nathelper. After configuring, I'm getting following errors as listed down below; Apr 1 11:53:31 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:select_rtpp_node: script error -no valid set selected Apr 1 11:53:31 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:force_rtp_proxy_body: no available proxies Apr 1 11:53:46 rose /usr/local/sbin/opensips[11382]: ERROR:nathelper:select_rtpp_node: script error -no valid set selected Apr 1 11:53:46 rose /usr/local/sbin/opensips[11382]: ERROR:nathelper:unforce_rtp_proxy_f: no available proxies Apr 1 11:53:46 rose /usr/local/sbin/opensips[11386]: ERROR:nathelper:force_rtp_proxy: Unable to parse body And the configuration of OpenSIPs is listed below; [...] Kindly state, how can I resolve this error in my above configuration. Please advise. -- Regards, Ahmed Munir ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro http://www.voice-system.ro -- Regards, Ahmed Munir ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Conflicting info for q-value order
Hi Brett,
Brett Nemeroff wrote:
Bogdan,
Hey, I was working on this problem some more and this is what I found...
Serialize branches does in fact order the branches, but lowest to
highest.. if you just do a:
1. serialize_branches
2. t_relay
3. next_branches
4. t_relay
5. next_branches
6. t_relay
7. next_branches
8. t_relay
and you have q-values of .01 .02 .03 .04
Calls would be sent like:
1. call to q-value .01
2. call to q-value .04
3. call to q-value .03
4. call to q-value .02
next_branches appears to POP in the right order. Serialize branches
has the affect of ordering them wrong (no POP). So if you just call
next_branches first, then it appears to work properly. In other words
like:
1. serialize_branches
2. next_branches
3. t_relay
4. next_branches
5. t_relay
6. next_branches
7. t_relay
8. next_branches
9. t_relay
Does this logic make sense? It's probably still worth fixing
serialize_branches just because this behavior is a bit confusing. I'll
try to get this tested today for you and let you know how it goes.
actually it does make sense, as the serialize_branches is not intended
to be used alone (without next_branches function).
So, they complete one each other.
Maybe to make usage of the serialize funtion for q sorting only (without
doing the serial / parallel forking), we could have:
1) serialize_branch(sort) - the function will simply sort them,
without preparing the branches for next_branches
2) serialize_branch(); next_branches(all) - we change the next
branches to extract them all, disregarding the q levels.
Regards,
Bogdan
Thanks!
-Brett
On Thu, Apr 1, 2010 at 6:53 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Brett,
Based on the RFC quotes, I would say the serialize function is considering
0.0 as higest priority and RFC suggest the other way around.
Could you try the attached patch to see if it fixes the problem ?
Regards,
Bogdan
Brett Nemeroff wrote:
Hi All,
I'm trying to figure out an issue with q-values on 302 redirects. I'm
being told that I'm following q-values wrong on a 302. OpenSIPs is
delivering to a URI with a q-value of 0.25 before a q-value of 0.5.
From the RFC:
As the target set grows, the client MAY generate new requests to the
URIs in any order. A common mechanism is to order the set by the q
parameter value from the Contact header field value. Requests to the
URIs MAY be generated serially or in parallel. One approach is to
process groups of **decreasing** q-values serially and process the URIs
in each q-value group in parallel. Another is to perform only serial
processing in decreasing q-value order, arbitrarily choosing between
contacts of equal q-value.
However, I see serialize_branches setting branches in ascending order
(0.25 is picked before 0.5) which works according to the online docs;
which state:
Takes all the branches added for parallel forking (with
append_branch() and including the current RURI)
and prepare them for serial forking. The ordering is done in
**increasing** q order. The serialized branches
are internally stored in AVPs - you will be able to fetch and use
via the next_branches() function.
I've looked for a simple function to reverse the order as well, but
that doesn't seem like the right fix and I can't find a simple way to
do it without looping thru the branches and rebuilding the array.
Am I missing something here?
Thanks,
Brett
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
www.voice-system.ro
Index: serialize.c
===
--- serialize.c (revision 6739)
+++ serialize.c (working copy)
@@ -184,7 +184,7 @@
contacts[n].q = q;
/* insert based on q */
- for (i = first; i != -1 contacts[i].q q; i =
contacts[i].next);
+ for (i = first; i != -1 contacts[i].q = q; i =
contacts[i].next);
if (i == -1) {
/* append */
___
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
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips just stops responding
I see, let me know if without the Localcache module works ok or not. Regards, Bogdan Jayesh Nambiar wrote: Hi Bogdan, Thanks for your reply. I will try this the next time my config behaves like this. By the way the only change that I did in this lastly was, I removed the LocalCache module support and have had the opensips to query the DB for Authentication. It's been 18 hours and till now the server is up and running fine. I'll keep a watch and follow the steps mentioned by you !! Thanks, --- Jayesh Message: 2 Date: Fri, 02 Apr 2010 11:40:32 +0300 From: Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro Subject: Re: [OpenSIPS-Users] Opensips just stops responding To: OpenSIPS users mailling list users@lists.opensips.org mailto:users@lists.opensips.org Message-ID: 4bb5ad80.80...@voice-system.ro mailto:4bb5ad80.80...@voice-system.ro Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Jayesh, Could you try to use gdb to attached to the unresponsive processes and to see where they are stuck ? Use gdb /path/opensips PID and do bt to get backtrace. Check for processes responsible for the network read (do an opensipsctl fifo ps to see which are the UDP listener processes) Regards, Bogdan Jayesh Nambiar wrote: Hi all, I am running Opensips 1.6.2 and am running a strange problem of Opensips not responding to any SIP messages after a day or two. It needs to be restarted for it to get working again. The overview of my setup is as follows: 1) I am using Localcache module to authorize REGISTER and INVITE requests from cache. 2) Using Mediaproxy for Nated clients with Media-Relay on a different server 3) Running basic queries based on INVITE before placing the call. After running for a day or two, Opensips just stops responding to any SIP message. I check moni, it shows me the server is alive and in_use transactions keep on increasing since Opensips is not processing anyone. I checked get_statistics shmem: even that is perfectly ok. I have assigned 1GB to shmem and hardly 30 MB is used. I dont even see any error logs etc. The top command shows no over utilization of CPU and memory. Can someone point me on where and how to check for this problem. Has someone had a similar problem before. It looks similar to this post http://www.mail-archive.com/users@lists.opensips.org/msg06098.html but I dont see a solution to this either. Thanks for any help. --- Jayesh ___ 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 www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Regards, -- Anca Vamanu www.voice-system.ro James Lamanna wrote: On Thu, Apr 1, 2010 at 12:26 AM, Anca Vamanu a...@opensips.org wrote: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Hi James, Can you please run a network trace and catch the Notify that goes first to the phone and makes it blink amber as you said? Send that to me to see how we can fix that. Hi Anca, Attached is a log of a startup of 2 phones. Each phone is monitoring the other phone. This is a clean startup, so all presence tables are empty. I think this may be a lack of any NOTIFYs being sent at startup to the phone that a phone is online. Thanks. -- 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] Conflicting info for q-value order
Why not just permanently change the sort order? What's the purpose of sorting them if you don't intend to sequentially execute them? What I'm wondering is what is more confusing to users troubleshooting q-value issues. Have serialize branches sort branches backwards, or having it sort them properly, but not prepare the branches? If you change the order, it may have the affect of people doing what I did: serialize branches without next_branches and it looks like it'll work (ie: can't tell with 2 branches) but in reality , it wasn't working right. Maybe the best thing to do is to just add a note in the docs about serialize_branches. I have a feeling that if you change serialize_branches, next_branches would likely need to get changed too, right? Because of the pop order. Thanks, Brett On Fri, Apr 2, 2010 at 4:29 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Brett, Brett Nemeroff wrote: Bogdan, Hey, I was working on this problem some more and this is what I found... Serialize branches does in fact order the branches, but lowest to highest.. if you just do a: 1. serialize_branches 2. t_relay 3. next_branches 4. t_relay 5. next_branches 6. t_relay 7. next_branches 8. t_relay and you have q-values of .01 .02 .03 .04 Calls would be sent like: 1. call to q-value .01 2. call to q-value .04 3. call to q-value .03 4. call to q-value .02 next_branches appears to POP in the right order. Serialize branches has the affect of ordering them wrong (no POP). So if you just call next_branches first, then it appears to work properly. In other words like: 1. serialize_branches 2. next_branches 3. t_relay 4. next_branches 5. t_relay 6. next_branches 7. t_relay 8. next_branches 9. t_relay Does this logic make sense? It's probably still worth fixing serialize_branches just because this behavior is a bit confusing. I'll try to get this tested today for you and let you know how it goes. actually it does make sense, as the serialize_branches is not intended to be used alone (without next_branches function). So, they complete one each other. Maybe to make usage of the serialize funtion for q sorting only (without doing the serial / parallel forking), we could have: 1) serialize_branch(sort) - the function will simply sort them, without preparing the branches for next_branches 2) serialize_branch(); next_branches(all) - we change the next branches to extract them all, disregarding the q levels. Regards, Bogdan Thanks! -Brett On Thu, Apr 1, 2010 at 6:53 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Brett, Based on the RFC quotes, I would say the serialize function is considering 0.0 as higest priority and RFC suggest the other way around. Could you try the attached patch to see if it fixes the problem ? Regards, Bogdan Brett Nemeroff wrote: Hi All, I'm trying to figure out an issue with q-values on 302 redirects. I'm being told that I'm following q-values wrong on a 302. OpenSIPs is delivering to a URI with a q-value of 0.25 before a q-value of 0.5. From the RFC: As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the q parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of **decreasing** q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. However, I see serialize_branches setting branches in ascending order (0.25 is picked before 0.5) which works according to the online docs; which state: Takes all the branches added for parallel forking (with append_branch() and including the current RURI) and prepare them for serial forking. The ordering is done in **increasing** q order. The serialized branches are internally stored in AVPs - you will be able to fetch and use via the next_branches() function. I've looked for a simple function to reverse the order as well, but that doesn't seem like the right fix and I can't find a simple way to do it without looping thru the branches and rebuilding the array. Am I missing something here? Thanks, Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro Index: serialize.c === --- serialize.c (revision 6739) +++ serialize.c (working copy) @@ -184,7 +184,7 @@ contacts[n].q = q; /* insert based on q */ - for (i = first; i != -1 contacts[i].q q; i = contacts[i].next); + for (i = first; i != -1 contacts[i].q = q; i =
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
Hi James, For this case, indeed I see that when BYE is received the server generates a Notify with state confirmed.. which is really strange. Can you please run opensips in debug mode and catch the logs when BYE is processed. Send them to me in an e-mail. Thanks, -- Anca Vamanu www.voice-system.ro James Lamanna wrote: Also, I've found a case where the BLF light stays red, even when a call is hung up. This seems to happen in the intercom case, where the SIP URI is sip:u...@ip;intercom=true. It doesn't happen on every intercom call, but once it does happen, it is impossible to clear without clearing the presence tables and rebooting the phone.. -- James Can you please catch the traces for this case also? All the presence traffic that you see when you hang up the phone - the Publish generated by OpenSIPS and the Notify sent to the phone. Thanks, Hi Anca, Here's the full trace. I call one phone (01) from my cell phone, and 02 is monitoring it. When 01 hangs up, the light on 02 stays red. Thanks for all your help! -- 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] Question about mediaproxy relay preference
New model? Which model. Maybe I missed something. :) On Fri, Apr 2, 2010 at 7:57 AM, Adrian Georgescu a...@ag-projects.com wrote: Yes, it blows away the DNS SRV concept. The new model where media relays automatically connect to one or more dispatchers using TLS is much more secure and has more self-organizing properties then statically configured DNS that can hold a limited amount of records. Still you have full control to promote a chosen relay on top of the list if you want to. You just need to work out a bit your configuration for achieving this. Adrian On Apr 2, 2010, at 2:46 PM, Brett Nemeroff wrote: Adrian, I do this in a few configurations. However, it kinda blows away the whole DNS SRV features, doesn't it? Anyway to indicate a mediaproxy preference without nailing to a specific one? -Brett On Fri, Apr 2, 2010 at 2:30 AM, Adrian Georgescu a...@ag- projects.com wrote: You have control over which MP is selected by setting an AVP in the proxy routing logic. So you can make some checks about your topology and then fetch the relay address from a database. Adrian On Apr 2, 2010, at 1:46 AM, Henk Hesselink wrote: We're moving our mediaproxies to 2.0 and have run into the following: in the old setup we used the priority value in the mediaproxy SRV records to prefer local (same datacenter) relays but to failover to a different datacenter if all local relays were unavailable. We then used the SRV weight value to load balance between different capacity relays within the datacenter. With 2.0 using conntrack we don't need to load balance anymore, but we'd still like to be able to prefer a local relay. Right now a call can be completely in one datacenter and yet have the relay in a different one, causing unnecessary latency. Ideally when a dispatcher sees that an endpoint of a call is on the same subnet as any of its relays, then it should prefer those relays. Is something like that possible? Regards, Henk Hesselink ___ 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 ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf] Found failover, working on set: 1101\n);
if (!ds_select_domain(1101, 8)) {
t_reply(503, Unable to locate failover set requested);
return;
};
route(1);
};
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
http://sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send:
sendto(sock,0xb3b9bd28,1039,0,0xb3ba2cf4,16): Network
is unreachable(101)
ERROR:tm:msg_send: udp_send failed
ERROR:tm:t_forward_nonack: sending request failed
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf] Found failover, working on set: 1101\n);
if (!ds_select_domain(1101, 8)) {
t_reply(503, Unable to locate failover set requested);
return;
};
route(1);
};
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
http://sip:+12125551...@192.168.0.99:5060
ERROR:core:udp_send:
Re: [OpenSIPS-Users] b2b top-hiding problem with custom_headers
Hi Ancu, No more problems with the buffer size! Excellent. P-Asserted-Identity still doesn't make it through even though it's defined in the custom_headers list. Everything else seems to. Any thoughts? I'm going to need more than 10 headers in the list. But when I try, I see: ERROR:b2b_logic:mod_init: Too many extra headers defined. The maximum value is 10 . Is this an easy adjustment in one of the files? I'll need 20 to be safe. - Jeff On Apr 1, 2010, at 10:35 AM, Anca Vamanu wrote: Hi Jeff, Jeff Pyle wrote: I found the BUF_LEN value in the b2b_entities/client.c and b2b_entities/dlg.c value, and increased it from 256 to 512. This seems to have taken care of the errors. I wonder what else I've broken by changing this. That was indeed the right place for the change. No, nothing else gets broken, that macro was only used there. Now I have committed the fix that allocated memory dynamically for the headers, so if you upgrade you will never see this problem. The header I'm having a problem with is P-Asserted-Identity, 19 characters long. Shorter ones have no problem. Perhaps there is a maximum length defined somewhere? If so, I couldn't find it. I tried changing HDR_DEFAULT_LEN in b2b_logic/b2b_logic.h from 7 to 14. This caused problems. The HDR_DEFAULT_LEN is used for something else - the b2b_logic module had a list of default headers that must be passed from one side to the other, and this macro says how many they are. Regards, -- Anca Vamanu www.voice-system.ro - Jeff On Apr 1, 2010, at 9:57 AM, Jeff Pyle wrote: Hello, During my first adventure into topology hiding it seemed the b2b modules weren't bringing all my custom_headers from one side to the other. During my testing I encountered this problem: ERROR:b2b_entities:client_new: Buffer too small ERROR:b2b_logic:create_top_hiding_entities: failed to create new b2b client instance ERROR:b2b_logic:b2b_init_request: failed to create top hinding specific entities This is a bare-minimum config on Opensips 1.7 build 6748 with permissions, signaling, sl, tm, rr, the two b2b modules, maxfwd and xlog loading. Any suggestions? Thanks, Jeff ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips crash
Hi Daniel, I tried today to reproduce the crash (with the info you sent me) and no luck. The scenario was : calling to 127 number, let it give timeout and redirect from failure route to a new destination (128)no crash. Maybe it will be easier and simpler if I can access to a server where you can reproduce the crash, so that I can inspect the core directly on the server were it was produced. Do you think this is possible? Regards, Bogdan Daniel Ribeiro wrote: Hi Bogdan, Are you able to reproduce the issue? Regards, Daniel On Tue, Mar 30, 2010 at 1:03 PM, Daniel Ribeiro ribeiro.dani...@gmail.com mailto:ribeiro.dani...@gmail.com wrote: Bogdan, Attached there is : opensips.cfg usr_preferences core dump file for version 1.6 wireshark with call scenario Thanks, Daniel -- Daniel Ribeiro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2b top-hiding problem with custom_headers
Hi Jeff, I increased the number of extra hdrs to 32 - please update from SVN. Regards, Bogdan Jeff Pyle wrote: Hi Ancu, No more problems with the buffer size! Excellent. P-Asserted-Identity still doesn't make it through even though it's defined in the custom_headers list. Everything else seems to. Any thoughts? I'm going to need more than 10 headers in the list. But when I try, I see: ERROR:b2b_logic:mod_init: Too many extra headers defined. The maximum value is 10 . Is this an easy adjustment in one of the files? I'll need 20 to be safe. - Jeff On Apr 1, 2010, at 10:35 AM, Anca Vamanu wrote: Hi Jeff, Jeff Pyle wrote: I found the BUF_LEN value in the b2b_entities/client.c and b2b_entities/dlg.c value, and increased it from 256 to 512. This seems to have taken care of the errors. I wonder what else I've broken by changing this. That was indeed the right place for the change. No, nothing else gets broken, that macro was only used there. Now I have committed the fix that allocated memory dynamically for the headers, so if you upgrade you will never see this problem. The header I'm having a problem with is P-Asserted-Identity, 19 characters long. Shorter ones have no problem. Perhaps there is a maximum length defined somewhere? If so, I couldn't find it. I tried changing HDR_DEFAULT_LEN in b2b_logic/b2b_logic.h from 7 to 14. This caused problems. The HDR_DEFAULT_LEN is used for something else - the b2b_logic module had a list of default headers that must be passed from one side to the other, and this macro says how many they are. Regards, -- Anca Vamanu www.voice-system.ro - Jeff On Apr 1, 2010, at 9:57 AM, Jeff Pyle wrote: Hello, During my first adventure into topology hiding it seemed the b2b modules weren't bringing all my custom_headers from one side to the other. During my testing I encountered this problem: ERROR:b2b_entities:client_new: Buffer too small ERROR:b2b_logic:create_top_hiding_entities: failed to create new b2b client instance ERROR:b2b_logic:b2b_init_request: failed to create top hinding specific entities This is a bare-minimum config on Opensips 1.7 build 6748 with permissions, signaling, sl, tm, rr, the two b2b modules, maxfwd and xlog loading. Any suggestions? Thanks, Jeff ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
Jeff,
I used the cfgutils usleep function to achieve the same and it worked
perfectly. The 400 Bad request because of the race condition regarding
the ACK/reinvite is fixed. With one exception
The reINVITE from the BroadSoft has no SDP.
BroadSoft --- reINVITE--OpenSIPS Provider (NO SDP in invite)
Provider --- 200 OK + SDP --- OpenSIPs -- Broadsoft (has c=0.0.0.0 in it)
BroadSoft -- ACK + SDP -- OpenSIPs - Provider (has c=0.0.0.0 in it)
Needless to say, there is no audio on this call.
I think it's worth mentioning that:
1. This is ONE LEG of a simultaneous ring from a BroadSoft
2. The initial invite for this leg has a c=0.0.0.0 from the BroadSoft
in SDP (before the reINVITE)
Who's at fault here? Any ideas?
Thanks,
Brett
On Thu, Apr 1, 2010 at 8:24 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
First, the nuts and bolts.
In the loose_route section:
if (!is_method(ACK)) {
perl_exec(nonack_delay);
}
And, in the Perl file:
sub nonack_delay {
select(undef,undef,undef,0.060);
return 1;
}
I lied. Not 100ms, but 60ms.
This worked like a champ, at the cost of keeping a non-ACK message fermenting
in the process for exactly 60ms longer than it otherwise would have. A bit
of a kick in teeth to scalability but I saw no other solution.
I do believe 400 was the negative response of choice from most UAs subjected
to the out-of-order ugliness.
- Jeff
On Apr 1, 2010, at 4:21 PM, Brett Nemeroff wrote:
WOW
Ok, well the real question is.. did the 100ms sleep fix your problem?
And what was the result of the ordering issue for you? Did you get a
400 from the provider like I'm seeing?
I'll give it a shot..
-Brett
On Thu, Apr 1, 2010 at 2:56 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
This goes way back. Bogdan addressed it last year sometime, citing a
reason why ACK processing is slower than other processing. And, since the
two messages hit different children of Opensips, the ACK hits the exit gate
after the reINVITE, even though the ACK arrived first. I've seen it with
Broadworks and Asterisk.
There were a number of solutions posted although none of them worked for
me. My workaround is to call a perl script to sleep for 100ms if the
message is not an ACK. That allows the ACK time to get through. I would
certainly love a real solution, that is, speeding up the ACK or some
other mechanism to enforce the sequence.
- Jeff
On Apr 1, 2010, at 3:47 PM, Brett Nemeroff wrote:
Hello All,
I'm working with a Broadsoft which is setup to send outbound calls to
OpenSIPs. The Broadsoft extension is set to ring simultaneously
multiple extensions. One which hits the proxy and the other is
internal on the broadsoft.
What I'm seeing is an outbound call from broadsoft to the proxy to the
provider (normal)
the provider answers and replies with a 200 OK, forwarded onto
broadsoft, without problem.
However, then I immediately get a ACK / INVITE FROM the broadsoft in
reply to the 200 OK. That seems ok, but when it goes to the provider
the ORDER is switched and it forwards the INVITE first THEN the ACK.
I'm not sure if that matters, but the provider is replying with a 400
Bad Request. Which may be because I'm trying to reinvite a call which
hasn't been ACKd yet?
Any ideas here? why would the order change? And could this potentially
cause call setup issues?
Thanks,
Brett
___
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
___
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
Ok, that makes sense actually..
so this block:
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
Instead of firing failure_route[2] (since it isn't a SIP failure)
it'll hit the xlog and return.
So what kind of send failures cause this? unroutable addresses? DNS
resolution errors? bad data? I've noticed that if I t_relay to
something fake like 1.2.3.4 that I'll end up with a 408 in a failure
route.. I think...
Thanks,
Brett
On Fri, Apr 2, 2010 at 8:21 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf] Found failover, working on set: 1101\n);
if (!ds_select_domain(1101, 8)) {
t_reply(503, Unable to locate failover set requested);
return;
Re: [OpenSIPS-Users] dispatcher fail-over doesn't seem happy
I think jock case was internal blacklisting (in opensips) of the
destination IP.
Regards,
Bogdan
Brett Nemeroff wrote:
Ok, that makes sense actually..
so this block:
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
Instead of firing failure_route[2] (since it isn't a SIP failure)
it'll hit the xlog and return.
So what kind of send failures cause this? unroutable addresses? DNS
resolution errors? bad data? I've noticed that if I t_relay to
something fake like 1.2.3.4 that I'll end up with a 408 in a failure
route.. I think...
Thanks,
Brett
On Fri, Apr 2, 2010 at 8:21 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Brett,
if t_relay() fails (whatever reason, like transport issues, IP problems,
URI problems, etc), it will not end up in failure route! failure route
is for SIP failures, not for any kind of failures.
Also see the 0x02 flag in t_relay() docs:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id266164
Regards,
Bogdan
Brett Nemeroff wrote:
Bogdan,
I think the ds_next_doman in the failure route should have been
called. On the initial t_relay, the failure route was already armed
and should have caught send failures. The top of the failure route
catches specific SIP codes, but the bottom half, including the
ds_next_domain should have fired for the send failure. Right?
Jock,
What's showing up in the logs around the send failure?
-Brett
On Fri, Apr 2, 2010 at 3:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf]
Re: [OpenSIPS-Users] Conflicting info for q-value order
Hi Brett, Brett Nemeroff wrote: Why not just permanently change the sort order? What's the purpose of sorting them if you don't intend to sequentially execute them? more or less no. So, using serialized_branches() without next_branches() makes no sense. What I'm wondering is what is more confusing to users troubleshooting q-value issues. Have serialize branches sort branches backwards, or having it sort them properly, but not prepare the branches? how the serialize function sends data (branches) to the next_branches() is completely transparent for the user, so the user should not care of that. The serialize function does sorting and prepare the data for usage - the data is stored in AVPs and to be later consumed by next_branches() function. If you change the order, it may have the affect of people doing what I did: serialize branches without next_branches and it looks like it'll work (ie: can't tell with 2 branches) but in reality , it wasn't working right. serialize without next_branches is bogus - as said, serialize take all branches (remove them), sort them and push them into AVPs to be used by next_branches(). So, after running serialize function, you do not have the branch set present (as it was moved into AVPs) Maybe the best thing to do is to just add a note in the docs about serialize_branches. I have a feeling that if you change serialize_branches, next_branches would likely need to get changed too, right? Because of the pop order. Probably a better documentation (and probably a short tutorial) will solve the issue. Regards, Bogdan Thanks, Brett On Fri, Apr 2, 2010 at 4:29 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Brett, Brett Nemeroff wrote: Bogdan, Hey, I was working on this problem some more and this is what I found... Serialize branches does in fact order the branches, but lowest to highest.. if you just do a: 1. serialize_branches 2. t_relay 3. next_branches 4. t_relay 5. next_branches 6. t_relay 7. next_branches 8. t_relay and you have q-values of .01 .02 .03 .04 Calls would be sent like: 1. call to q-value .01 2. call to q-value .04 3. call to q-value .03 4. call to q-value .02 next_branches appears to POP in the right order. Serialize branches has the affect of ordering them wrong (no POP). So if you just call next_branches first, then it appears to work properly. In other words like: 1. serialize_branches 2. next_branches 3. t_relay 4. next_branches 5. t_relay 6. next_branches 7. t_relay 8. next_branches 9. t_relay Does this logic make sense? It's probably still worth fixing serialize_branches just because this behavior is a bit confusing. I'll try to get this tested today for you and let you know how it goes. actually it does make sense, as the serialize_branches is not intended to be used alone (without next_branches function). So, they complete one each other. Maybe to make usage of the serialize funtion for q sorting only (without doing the serial / parallel forking), we could have: 1) serialize_branch(sort) - the function will simply sort them, without preparing the branches for next_branches 2) serialize_branch(); next_branches(all) - we change the next branches to extract them all, disregarding the q levels. Regards, Bogdan Thanks! -Brett On Thu, Apr 1, 2010 at 6:53 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Brett, Based on the RFC quotes, I would say the serialize function is considering 0.0 as higest priority and RFC suggest the other way around. Could you try the attached patch to see if it fixes the problem ? Regards, Bogdan Brett Nemeroff wrote: Hi All, I'm trying to figure out an issue with q-values on 302 redirects. I'm being told that I'm following q-values wrong on a 302. OpenSIPs is delivering to a URI with a q-value of 0.25 before a q-value of 0.5. From the RFC: As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the q parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of **decreasing** q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. However, I see serialize_branches setting branches in ascending order (0.25 is picked before 0.5) which works according to the online docs; which state: Takes all the branches added for parallel forking (with append_branch() and including the current RURI) and prepare them for serial forking. The ordering is done in **increasing** q order. The serialized branches are internally stored in AVPs - you will be able to fetch and use via the next_branches()
Re: [OpenSIPS-Users] Could I use mysql lines in opensips.cfg?
or alias_db is designed exactly to handle looking up a username. if found you have side benefit of having the request uri set for next hop. On Apr 2, 2010, at 5:18 AM, Bogdan-Andrei Iancu wrote: or for any kind of mysql query, you may use the avp_db_query function from avpops module: http://www.opensips.org/html/docs/modules/1.6.x/avpops.html#id271033 Regards, Bogdan Brett Nemeroff wrote: I personally would probably end up storing the users into memcache and checking against that. the userblacklist module might also do what you need.. http://www.opensips.org/html/docs/modules/1.6.x/userblacklist.html#id227282 On Fri, Apr 2, 2010 at 12:15 AM, CheeWii quanwe...@gmail.com wrote: Hi, I use Opensips as an SMS gateway. Now I need to check all message's username firstly. If the username is in my mysql database,thus it belong to the white name-list,then I realy it normally.If not ,I will drop it directlly. So I think I should exec some some mysql commands to check the usename. How can I accomplish it? Thanks a lot:) 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 -- Bogdan-Andrei Iancu 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] dispatcher fail-over doesn't seem happy
Greetings Bogdan;
Unfortunately there's a minor hitch in the getalong with this suggestion -
the failure route utilises two functions that can only be called from a
failure_route block (t_was_cancelled() and ds_next_domain()).
From my understanding of what you're suggesting below, I should move my
failure logic into its own route block and then call it, both from the
failure_route block and from the t_relay() failed section. This would be a
very elegant way to handle it, if I could use it :)
It appears there is no 'back door' method of calling a failure_route() block
from inside a route block, as in:
if (!t_relay()) {
failure_route(2);
}
Any new thoughts?
Many thanks, both of you.
- JP
On Fri, Apr 2, 2010 at 2:58 AM, Bogdan-Andrei Iancu
bog...@voice-system.rowrote:
Hi Jock,
I guess the problem is detecting the failure . The failure route catches
only SIP failures (like you sent the requests and you get nothing or
negative reply); but failure route does not catch sending error (like in
your case).
So, you should do something like:
route[try_next] {
here put the next stuff
}
{
...
t_on_failure(sip_failure);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
route(try_next);
}
...
}
failure_route[sip_failure]
{
if (t_check_status() {
# is a destination failure
route(try_next);
}
}
Regards,
bogdan
Jock McKechnie wrote:
On Thu, Apr 1, 2010 at 10:26 AM, Brett Nemeroff br...@nemeroff.com
mailto:br...@nemeroff.com wrote:
Where is your failure route? :)
-Brett
I intentionally chose to not include it, along with the other 200
lines of config, for simplicity, but you're right, given this is a
failure, I clearly should've, duh :)
failure_route[2] {
if (t_was_cancelled()) {
xlog( L_NOTICE, [$Tf] FR: transaction cancelled -
exiting\n );
exit;
}
# If fr_timer expires t_check_status(408) is true, although
$rs is null
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd\n );
} else {
xlog( L_NOTICE, [$Tf] FR: $ci -- $rs reason $rr\n );
}
# 403 -- typically ISDN network says 'not a valid number' etc..
if( t_check_status(403) ){
xlog(L_WARN, [$Tf] FR: $ci -- SIP-$rs Forbidden -
ISDN Cause Code 1\n );
return;
}
if( ds_next_domain() ){
xlog( L_NOTICE, [$Tf] FR: $ci Next gateway $fU -
$tU via $rd \n );
t_on_failure(2);
if( !t_relay() ){
xlog( L_WARN, [$Tf] FR: $ci -- ERROR -
Cannot t_relay() -- $fU - $tU via $rd\n );
return;
}
return;
} else {
xlog( L_WARN, [$Tf] FR: $ci No more gateways -
503.\n );
t_reply(503, Service unavailable -- no more
gateways );
return;
}
}
- Jock
On Thu, Apr 1, 2010 at 11:20 AM, Jock McKechnie
jock.mckech...@gmail.com mailto:jock.mckech...@gmail.com wrote:
Greetings all;
I'm attempting to set up a fail-over only scenario using
dispatcher and am
encountering some problems. I'm using dispatcher since we're
already
utilising it for load balancing, so it makes sense to reuse the
tool, and
according to the OpenSIPS 1.6 dispatcher module documentation it
supports
fail-over.
If the destination server is running, everything works as
expected - algo 8
(which OpenSIPS logs as not found and defaulting to the first
entry) pushes
the call to the first server at all times. However if I block
the route to
the destination server like so:
/sbin/route add -host 192.168.0.99 reject
Then instead of failing over I get a SIP 477 (Send failed) error.
The chunk of routing looks like so:
xlog(L_WARN, [$Tf] Found failover, working on set: 1101\n);
if (!ds_select_domain(1101, 8)) {
t_reply(503, Unable to locate failover set requested);
return;
};
route(1);
};
route[1] {
t_on_failure(2);
xlog(L_WARN, Attempting to relay call to $ru\n);
if (!t_relay()) {
xlog(L_WARN, [$Tf] t_relay fail\n);
return;
}
return;
}
The log contains:
[Thu Apr 1 11:14:35 2010] Found failover, working on set: 1101
WARNING:dispatcher:ds_select_dst: algo 8 not implemented - using
first
entry...
Attempting to relay call to sip:+12125551...@192.168.0.99:5060
[OpenSIPS-Users] Nonce expire
I'm having some trouble with nonce expiring I believe. The problem is that every other one of my endpoint registrations is doing an auth challenge w/401. From my config: modparam(registrar, default_expires, 60) modparam(registrar, min_expires, 60) modparam(registrar, max_expires, 60 modparam(auth, nonce_expire, 3600) From this I would expect the devices to try to register every 60 seconds, and get challenged every hour with a new nonce. Comments on why OpenSIPS is challenging every other registration? Thanks -dg ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Nonce expire
A quick follow up on this, I enabled some logging, but the retcode is not
making any sense to me (probably because I'm using it wrong).
From my config:
xlog (REGISTER $fu);
# authenticate the REGISTER requests (uncomment to enable
auth)
if (!www_authorize(, subscriber))
{
xlog (Not authorized - challenging, error:
$retcode);
www_challenge(, 1);
exit;
}
Then in the log:
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: Not
authorized - challenging, error: 4294967293
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:49:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: Not
authorized - challenging, error: 4294967292
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:38 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: Not
authorized - challenging, error: 4294967292
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Also I'm running 1.6.2-tls compiled today from latest 1_6 branch in SVN.
-dg
On Fri, Apr 2, 2010 at 1:40 PM, Daniel Goepp d...@goepp.net wrote:
I'm having some trouble with nonce expiring I believe. The problem is that
every other one of my endpoint registrations is doing an auth challenge
w/401.
From my config:
modparam(registrar, default_expires, 60)
modparam(registrar, min_expires, 60)
modparam(registrar, max_expires, 60
modparam(auth, nonce_expire, 3600)
From this I would expect the devices to try to register every 60 seconds,
and get challenged every hour with a new nonce.
Comments on why OpenSIPS is challenging every other registration?
Thanks
-dg
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Nonce expire
Ah...I see what that retcode is anyway, 2^32 = 4294967296, so those are
really just -4 first, no credentials, then -3 stale nonce
-dg
On Fri, Apr 2, 2010 at 1:50 PM, Daniel Goepp d...@goepp.net wrote:
A quick follow up on this, I enabled some logging, but the retcode is not
making any sense to me (probably because I'm using it wrong).
From my config:
xlog (REGISTER $fu);
# authenticate the REGISTER requests (uncomment to enable
auth)
if (!www_authorize(, subscriber))
{
xlog (Not authorized - challenging, error:
$retcode);
www_challenge(, 1);
exit;
}
Then in the log:
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: Not
authorized - challenging, error: 4294967293
Apr 2 13:49:38 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:49:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: Not
authorized - challenging, error: 4294967292
Apr 2 13:50:18 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:38 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30180]: Not
authorized - challenging, error: 4294967292
Apr 2 13:50:58 ip-10-160-23-47 /usr/local/sbin/opensips[30182]: REGISTER
sip:1...@vidtel.com sip%3a1...@vidtel.com
Also I'm running 1.6.2-tls compiled today from latest 1_6 branch in SVN.
-dg
On Fri, Apr 2, 2010 at 1:40 PM, Daniel Goepp d...@goepp.net wrote:
I'm having some trouble with nonce expiring I believe. The problem is
that every other one of my endpoint registrations is doing an auth challenge
w/401.
From my config:
modparam(registrar, default_expires, 60)
modparam(registrar, min_expires, 60)
modparam(registrar, max_expires, 60
modparam(auth, nonce_expire, 3600)
From this I would expect the devices to try to register every 60 seconds,
and get challenged every hour with a new nonce.
Comments on why OpenSIPS is challenging every other registration?
Thanks
-dg
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c:853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: dialog info: Apr 2 16:42:24 [12585] DBG:presence:printf_subs: [pres_uri]= sip:000...@opensips.ip [to_user]= 02 [to_domain]= opensips.ip [w_user]= 01[w_domain]= opensips.ip [event]= dialog [status]= active [expires]= 60 [callid]= 9673ec38-b54b9...@192.168.1.165 [local_cseq]=0 [to_tag]= 89c56fdf6f5b6f30be24c8867d74b34a-8b2f [from_tag]= f9ba884d0d82aab [contact]= sip:000...@phone.nat.ip:6095 [record_route]= Apr 2 16:42:24 [12585] DBG:presence:search_phtable: pres_uri= sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence:get_p_notify_body: No record exists in hash_table Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:dlginfo_agg_nbody: [pres_user]=02 [pres_domain]= opensips.ip, [n]=0 Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:build_dialoginfo: [pres_uri] sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence:search_phtable: pres_uri= sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:build_dialoginfo: No record exists in hash_table Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: Could not get the notify_body Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: headers: Max-Forwards: 70^M Event: dialog^M Contact: sip:s...@opensips.ip:5060^M Subscription-State: active;expires=50^M Apr 2 16:42:24 [12585] DBG:presence:build_dlg_t: CONTACT = sip:000...@phone.nat.ip:6095 Apr 2 16:42:24 [12585] DBG:tm:t_uac: next_hop=sip:000...@phone.nat.ip::6095 Apr 2 16:42:24 [12585] DBG:core:mk_proxy: doing DNS lookup... Apr 2 16:42:24 [12585] DBG:tm:dlg2hash: 63929 Apr 2 16:42:24 [12585] DBG:tm:print_request_uri: sip:000...@phone.nat.ip::6095 Apr 2 16:42:24 [12585] DBG:tm:set_timer: relative timeout is 50 Apr 2 16:42:24 [12585] DBG:tm:insert_timer_unsafe: [4]: 0x7f0f225b44d0 (580) Apr 2 16:42:24 [12585] DBG:tm:set_timer: relative timeout is 30 Apr 2 16:42:24 [12585] DBG:tm:insert_timer_unsafe: [0]: 0x7f0f225b4500 (35) Apr 2 16:42:24 [12585] INFO:presence:send_notify_request: NOTIFY sip:000...@opensips.ip via sip:000...@phone.nat.ip::6095 on Regards, -- Anca Vamanu www.voice-system.ro -- James James Lamanna wrote: On Thu, Apr 1, 2010 at 12:26 AM, Anca Vamanu a...@opensips.org wrote: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Hi James, Can you please run a network trace and catch the Notify that goes first to the phone and makes it blink amber as you said? Send that to me to see how we can fix that. Hi Anca, Attached is a log of a startup of 2 phones. Each phone is monitoring the other phone. This is a clean startup, so all presence tables are empty. I think this may be a lack of any NOTIFYs being sent at startup to the phone that a phone is online. Thanks. -- 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Fri, Apr 2, 2010 at 4:40 PM, James Lamanna jlama...@gmail.com wrote: On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c:853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. [snip] Setting fallback2db == 1 as a modparam doesn't hit it either because it aggregates the body. Also, that has another side effect of crashing opensips after about 1 minute as well. Last entry in the log in that case is termination due to SIGCHLD. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Broadsoft reininvite / ack order switched at opensips
If the SDP from the provider in their 200 OK has a c=0.0.0.0, I'd ask the
provider what's up.
I bet it's the provider's SBC not able to handle the fact that Broadworks puts
the SDP on the ACK. I've met a few that handle it incorrectly.
- Jeff
On Apr 2, 2010, at 10:23 AM, Brett Nemeroff wrote:
Jeff,
I used the cfgutils usleep function to achieve the same and it worked
perfectly. The 400 Bad request because of the race condition regarding
the ACK/reinvite is fixed. With one exception
The reINVITE from the BroadSoft has no SDP.
BroadSoft --- reINVITE--OpenSIPS Provider (NO SDP in invite)
Provider --- 200 OK + SDP --- OpenSIPs -- Broadsoft (has c=0.0.0.0 in it)
BroadSoft -- ACK + SDP -- OpenSIPs - Provider (has c=0.0.0.0 in it)
Needless to say, there is no audio on this call.
I think it's worth mentioning that:
1. This is ONE LEG of a simultaneous ring from a BroadSoft
2. The initial invite for this leg has a c=0.0.0.0 from the BroadSoft
in SDP (before the reINVITE)
Who's at fault here? Any ideas?
Thanks,
Brett
On Thu, Apr 1, 2010 at 8:24 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
First, the nuts and bolts.
In the loose_route section:
if (!is_method(ACK)) {
perl_exec(nonack_delay);
}
And, in the Perl file:
sub nonack_delay {
select(undef,undef,undef,0.060);
return 1;
}
I lied. Not 100ms, but 60ms.
This worked like a champ, at the cost of keeping a non-ACK message
fermenting in the process for exactly 60ms longer than it otherwise would
have. A bit of a kick in teeth to scalability but I saw no other solution.
I do believe 400 was the negative response of choice from most UAs subjected
to the out-of-order ugliness.
- Jeff
On Apr 1, 2010, at 4:21 PM, Brett Nemeroff wrote:
WOW
Ok, well the real question is.. did the 100ms sleep fix your problem?
And what was the result of the ordering issue for you? Did you get a
400 from the provider like I'm seeing?
I'll give it a shot..
-Brett
On Thu, Apr 1, 2010 at 2:56 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
This goes way back. Bogdan addressed it last year sometime, citing a
reason why ACK processing is slower than other processing. And, since the
two messages hit different children of Opensips, the ACK hits the exit
gate after the reINVITE, even though the ACK arrived first. I've seen it
with Broadworks and Asterisk.
There were a number of solutions posted although none of them worked for
me. My workaround is to call a perl script to sleep for 100ms if the
message is not an ACK. That allows the ACK time to get through. I would
certainly love a real solution, that is, speeding up the ACK or some
other mechanism to enforce the sequence.
- Jeff
On Apr 1, 2010, at 3:47 PM, Brett Nemeroff wrote:
Hello All,
I'm working with a Broadsoft which is setup to send outbound calls to
OpenSIPs. The Broadsoft extension is set to ring simultaneously
multiple extensions. One which hits the proxy and the other is
internal on the broadsoft.
What I'm seeing is an outbound call from broadsoft to the proxy to the
provider (normal)
the provider answers and replies with a 200 OK, forwarded onto
broadsoft, without problem.
However, then I immediately get a ACK / INVITE FROM the broadsoft in
reply to the 200 OK. That seems ok, but when it goes to the provider
the ORDER is switched and it forwards the INVITE first THEN the ACK.
I'm not sure if that matters, but the provider is replying with a 400
Bad Request. Which may be because I'm trying to reinvite a call which
hasn't been ACKd yet?
Any ideas here? why would the order change? And could this potentially
cause call setup issues?
Thanks,
Brett
___
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
___
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
___
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] Segfault during load test
Hello, I was load testing opensips-1.6 r. 6605 and I got a seg fault. I will try updating to most recent revision of 1.6, but I thought someone would like to take a look at this. regards, takeshi Core was generated by `/usr/local/sbin/opensips -m 1024'. Program terminated with signal 11, Segmentation fault. [New process 29728] #0 slot_add (_s=0x2b361ce6ac10, _r=0x2b363326ca20) at hslot.c:151 151 *dest = _r; (gdb) bt #0 slot_add (_s=0x2b361ce6ac10, _r=0x2b363326ca20) at hslot.c:151 #1 0x2b3619b9ac65 in mem_insert_urecord (_d=0x2b361ce69560, _aor=value optimized out, _r=0x7fff919cb740) at udomain.c:648 #2 0x2b3619b9ad42 in insert_urecord (_d=0x2b361ce69560, _aor=0x7fff919cb958, _r=0x7fff919cb740) at udomain.c:781 #3 0x2b3619fb5769 in insert_contacts (_m=0x79b600, _c=0x79c468, _d=0x2b361ce69560, _a=0x7fff919cb958, _sctx=0x7fff919cb950) at save.c:398 #4 0x2b3619fb6592 in save (_m=0x79b600, _d=0x2b361ce69560 , _f=value optimized out, _s=0x0) at save.c:680 #5 0x0040e9e9 in do_action (a=0x78def8, msg=0x79b600) at action.c:967 #6 0x004114bc in run_action_list (a=value optimized out, msg=0x79b600) at action.c:139 #7 0x00466b24 in eval_expr (e=0x78dfd0, msg=0x79b600, val=0x0) at route.c:1240 #8 0x0046659d in eval_expr (e=0x78e020, msg=0x79b600, val=0x0) at route.c:1553 #9 0x00466545 in eval_expr (e=0x78e070, msg=0x79b600, val=0x0) at route.c:1558 #10 0x0040d9cd in do_action (a=0x78e2c8, msg=0x79b600) at action.c:689 #11 0x004114bc in run_action_list (a=value optimized out, msg=0x79b600) at action.c:139 #12 0x0040fcc3 in do_action (a=0x78e888, msg=0x79b600) at action.c:706 #13 0x004114bc in run_action_list (a=value optimized out, msg=0x79b600) at action.c:139 #14 0x00411819 in run_top_route (a=0x78ad18, msg=0x79b600) at action.c:119 #15 0x00455ff5 in receive_msg ( buf=0x754f20 REGISTER sip:domain13564.com SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.2.6:;rport;branch=z9hG4bK-4540-1443964-5\r\nFrom: \13564\ sip:13...@domain13564.com sip%3a13...@domain13564.com;tag=4540SIPpTag001443964\r\nTo: \13564\ sip:13564@..., len=575, rcv_info=0x7fff919ccc10) at receive.c:162 #16 0x0049a304 in udp_rcv_loop () at udp_server.c:492 #17 0x00429bbd in main (argc=3, argv=value optimized out) at main.c:818 (gdb) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
