[OpenSIPS-Users] Far end byes are not being routed back to UAE

Tue Apr 5 19:28:34 CEST 2011

Thanks Ovidiu,

I'll be going over the RFC's till I find my answer.

Kurtis

On Tue, Apr 5, 2011 at 3:00 AM, <users-request at lists.opensips.org> wrote:

> Send Users mailing list submissions to
>        users at lists.opensips.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
>        users-request at lists.opensips.org
>
> You can reach the person managing the list at
>        users-owner at lists.opensips.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
>   1. Re: Far end byes are not being routed back to UAE (Ovidiu Sas)
>   2. Memory Issues because of AVPs? (duane.larson at gmail.com)
>   3. Re: t_relay behavior with 477 send failed (Amit Sharma)
>   4. Re: Memory Issues because of AVPs? (Bogdan-Andrei Iancu)
>   5. Re: Asynchronous DB queries in OpenSIPS 1.x (Bogdan-Andrei Iancu)
>   6. Re: Asynchronous DB queries in OpenSIPS 1.x (Bogdan-Andrei Iancu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 4 Apr 2011 22:20:55 -0400
> From: Ovidiu Sas <osas at voipembedded.com>
> Subject: Re: [OpenSIPS-Users] Far end byes are not being routed back
>        to UAE
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Cc: Kurtis vel <kurtisvelarde at gmail.com>
> Message-ID: <BANLkTimKVEB4RrcUvJDDC8GbdXH_WhThJQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The BYE is not properly formated: the RURI is bogus.
> It should be:
> BYE sip:1000 at 172.16.113.63:10090 SIP/2.0
> instead of:
> BYE sip:1000 at 50.56.106.41:5060 SIP/2.0
>
> The RURI in BYE should be identical to the URI in the Contact header of
> ACK:
> Contact: <sip:1000 at 172.16.113.63:10090>
>
> For more details, check the loose routing section in on the SIP rfc.
>
>
> Regards,
> Ovidiu Sas
>
> On Mon, Apr 4, 2011 at 8:20 PM, Kurtis vel <kurtisvelarde at gmail.com>
> wrote:
> > Hi Everyone,
> >
> > I'm a new user and am having an issue routing byes from the called
> recipient
> > back to the origin UAE.
> >
> > With `opensipsctl online` I can see that the device is registered. When
> the
> > recipient hangs up, opensips returns a 404 to the bye sent from my
> provider.
> > Attached is a sip trace and most or the opensips.cfg routing script. It
> is
> > marked where the 404 is being sent in both files.
> >
> > Tried adding -
> > ? ? ? ? ? ? ? ? ? ? ?? if (uri==myself){
> > ??????????????????????????????? route(1);
> > ??????????????????????? }
> >
> > In front of the 404 reply but a 483 To Many Hops is revived from the
> remote
> > network.
> >
> > Any help would be appreciated.
> >
> > Thanks
> >
> > Kurtis
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 05 Apr 2011 03:54:14 +0000
> From: duane.larson at gmail.com
> Subject: [OpenSIPS-Users] Memory Issues because of AVPs?
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID: <20cf3054ac035fdb5004a023d492 at google.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed";
>        DelSp="yes"
>
> A while back I had posted on here thinking that i might have a memory leak
>
> http://opensips-open-sip-server.1449251.n2.nabble.com/Memory-leak-td5942660.html#a5949293
>
> I've had to fix my SIPP scripts but also I had to change some stuff in my
> opensips.cfg file. In my script I commented out all of the times I set an
> AVP variable.
>
> So my question is
>
> Every time you load an AVP it gets put into memory correct? So in order for
> the memory not to get overloaded you need to do "avp_delete" correct? What
> about the AVPs that are declared in modparam's and that are set in the
> script? How do you make sure those are not overloading memory? What else
> could cause my opensips processes to gradually eat up the memory before
> opensips just starts erroring out because of no memory?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.opensips.org/pipermail/users/attachments/20110405/be5a10e0/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Apr 2011 12:01:09 +0530
> From: Amit Sharma <asharma at 3clogic.com>
> Subject: Re: [OpenSIPS-Users] t_relay behavior with 477 send failed
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID: <BANLkTikoRTGFWg-2wZG5h5DAkExKyZvU=g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Bogdan,
>    I set the flag with t_relay and it resolved the issue. I am able
> to handle failure from t_relay now.
>
> Thanks,
> Amit
>
> On Mon, Mar 21, 2011 at 10:33 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org> wrote:
> > Hi Amit,
> >
> > have you set the 0x02 flag for t_relay ? See:
> > ? ? ?http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id293378
> >
> > This flag will prevent the t_relay() function do internally deal with
> errors
> > (by sending back a negative reply).
> >
> > Regards,
> > Bogdan
> >
> > Amit Sharma wrote:
> >>
> >> I tried the fix from the 1.6 branch. The issue I still face is that now
> >> t_relay returns with a value of 1 even when the relaying has failed.
> >>
> >> How do you figure out if t_relay has failed (!t_relay()) does not work
> in
> >> this case? Does a return value 1 also signify an error?
> >> ?-Amit
> >>
> >> On Tue, Mar 15, 2011 at 3:51 PM, Bogdan-Andrei Iancu <
> bogdan at opensips.org
> >> <mailto:bogdan at opensips.org>> wrote:
> >>
> >> ? ?Hi Amit,
> >>
> >> ? ?Following your report, Anca did a fix on SVN - see:
> >> ? ? ?http://lists.opensips.org/pipermail/devel/2011-March/007893.html
> >>
> >> ? ?Please update from SVN and try again.
> >>
> >> ? ?Regards,
> >> ? ?Bogdan
> >>
> >> ? ?Amit Sharma wrote:
> >>
> >> ? ? ? ?I am facing an issue similiar to the one outlined in the thread
> >>
> >> ? ? ? ?http://lists.opensips.org/pipermail/users/2010-April/011783.html
> >>
> >>
> >> ? ? ? ? I am using the latest stable version of opensips (1.6.4) and
> >> ? ? ? ?tried the solution outlined in the thread above.
> >> ? ? ? ?The issue I have observed is that t_relay function doesn't
> >> ? ? ? ?return control to the script in case of a send failure (e.g
> >> ? ? ? ?inability to establish TCP connection etc) ?and I recieve a
> >> ? ? ? ?477 send failure on the client.
> >>
> >> ? ? ? ?This is the relevant and simplified route block that I am using
> >>
> >> ? ? ? ? route{
> >> ? ? ? ? ? ? ? ? ? lookup();
> >> ? ? ? ? ? ? ? ? serialize_branches(1);
> >> ? ? ? ? ? ? ? ? next_branches();
> >> ? ? ? ? ? ? ? ? route(1);
> >> ? ? ? ? }
> >>
> >> ? ? ? ?route[1]{
> >> ? ? ? ? ? ? ? ?xlog("L_ERR", "Before t_relay");
> >> ? ? ? ? ? ? ? ?t_relay();
> >> ? ? ? ? ? ? ? ?xlog("L_ERR", "After t_relay");
> >>
> >> ? ? ? ?}
> >>
> >> ? ? ? ? ?The log statement after the call to t_relay doesn't get
> >> ? ? ? ?printed in case the highest priority contact (TCP) ?is
> >> ? ? ? ?unreachable.
> >> ? ? ? ? ?In essence any failover logic written on the return value of
> >> ? ? ? ?t_relay doesn't execute.
> >>
> >> ? ? ? ?Thanks,
> >> ? ? ? ?Amit
> >>
> >>
> >>
> >>
> ?------------------------------------------------------------------------
> >>
> >> ? ? ? ?_______________________________________________
> >> ? ? ? ?Users mailing list
> >> ? ? ? ?Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> ? ? ? ?http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >>
> >> ? ?-- ? ? Bogdan-Andrei Iancu
> >> ? ?OpenSIPS eBootcamp - 28th February 2011
> >> ? ?OpenSIPS solutions and "know-how"
> >>
> >>
> >> ? ?_______________________________________________
> >> ? ?Users mailing list
> >> ? ?Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >> ? ?http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >
> >
> > --
> > Bogdan-Andrei Iancu
> > OpenSIPS eBootcamp - 28th February 2011
> > OpenSIPS solutions and "know-how"
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 05 Apr 2011 12:31:44 +0300
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Subject: Re: [OpenSIPS-Users] Memory Issues because of AVPs?
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID: <4D9AE180.7010307 at opensips.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Duane,
>
> On 04/05/2011 06:54 AM, duane.larson at gmail.com wrote:
> > A while back I had posted on here thinking that i might have a memory
> > leak
> >
> http://opensips-open-sip-server.1449251.n2.nabble.com/Memory-leak-td5942660.html#a5949293
> >
> >
> > I've had to fix my SIPP scripts but also I had to change some stuff in
> > my opensips.cfg file. In my script I commented out all of the times I
> > set an AVP variable.
> >
> > So my question is
> >
> > Every time you load an AVP it gets put into memory correct?
> yes, in shared memory, to be more specific.
> > So in order for the memory not to get overloaded you need to do
> > "avp_delete" correct?
> not necessarily - you use the function only only if you want to delete
> the AVPs at some specific point in script. AVPs are transaction/message
> persistent , and they are automatically deleted when the transaction /
> message is deleted (AVPs are part of transaction/message)
> > What about the AVPs that are declared in modparam's and that are set
> > in the script?
> those are just names of AVPs, not instances of AVPs
> > How do you make sure those are not overloading memory? What else could
> > cause my opensips processes to gradually eat up the memory before
> > opensips just starts erroring out because of no memory?
> As said, AVPs cannot cumulate in memory as they are attached to
> structures (transactions/messages) that are deleted.
>
> If you get errors on on running out of memory, please read and follow:
>     http://www.opensips.org/Resources/DocsTsMem
>
> Regards,
> Bogdan
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS eBootcamp - 2nd of May 2011
> OpenSIPS solutions and "know-how"
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 05 Apr 2011 12:35:56 +0300
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Subject: Re: [OpenSIPS-Users] Asynchronous DB queries in OpenSIPS 1.x
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Cc: OpenSIPS devel mailling list <devel at lists.opensips.org>
> Message-ID: <4D9AE27C.3060406 at opensips.org>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Hi Brett,
>
> On 03/16/2011 07:32 PM, Brett Nemeroff wrote:
> >
> > On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu <vladpaiu at opensips.org
> > <mailto:vladpaiu at opensips.org>> wrote:
> >
> >     Hello all,
> >
> >     Problem :
> >     1) Extend the OpenSIPS DB core. Add extra core processes that
> >     would only handle queries that return no results.
> >         For example : The accounting module need to insert an entry in
> >     the DB. The module calls the insert() function. Behind the scene,
> >     this triggers passing all the arguments to the new core processes,
> >     via IPC mechanisms. The insert() then exists and the SIP children
> >     continues execution as if the entry has been inserted in the DB.
> >     Meanwhile, the DB core processes receive the new parameters, build
> >     and send the query, blocking if necessary.
> >
> >
> > Maybe I'm just saying the same thing another way, but what about an
> > async execution queue. So you basically add to the queue messages to
> > be executed to the database and on some sort of timer loop process
> > them. To the script, we just assume everything is 100% successful.
> yes, it is the same what Vlad said, but in other words :)
> >
> > Is IPC really necessary for this? The goal here is really just to
> > offload the processing elsewhere so that the DB slowness doesn't
> > adversely affect opensips core performance. right?
> IPC is a really generic way of saying - the idea is that you need to
> "move" the query from the process handling the SIP message to another
> process (DB related only)
>
> >
> > I thin it's also important that there is a async execute and a sync
> > execute and people (users?) need to know that in the async execute,
> > you won't know if the execute succeeded in the script logic *ever*
>
> this support will be mainly be used from the other SIP modules (by the
> internal code) and not from script, so for "users", this will be
> transparent.
>
> Regards,
> Bogdan
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS eBootcamp - 2nd of May 2011
> OpenSIPS solutions and "know-how"
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.opensips.org/pipermail/users/attachments/20110405/d65238ac/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 05 Apr 2011 12:42:38 +0300
> From: Bogdan-Andrei Iancu <bogdan at opensips.org>
> Subject: Re: [OpenSIPS-Users] Asynchronous DB queries in OpenSIPS 1.x
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Cc: OpenSIPS devel mailling list <devel at lists.opensips.org>
> Message-ID: <4D9AE40E.2030704 at opensips.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Dave,
>
> We decided to put the async support in core (the mechanism for "moving"
> a query from current process to a DB process) - each DB module will
> choose to use or not this async support (like for db_text makes not
> sense, db_postgres may have a buitin one, etc)
>
> Regards,
> Bogdan
>
> On 03/16/2011 11:26 PM, Dave Singer wrote:
> > Vlad,
> > Would it be possible extend DB_VITRUAL kind of a combination of your
> > two options and Brett's suggestion.
> > I'm just guessing how things might work and possibilities. So for what
> > it is worth...
> > Since it is a middle layer, it could either use the async capabilities
> > of the native driver or put it in a queue to be handled by a special
> > db queue process that could also be threaded potentially (if
> > beneficial). The IPC would only need to pass the query that is needed.
> > To take advantage of the async the user would only need to use the
> > DB_VIRTUAL module.
> > Probably would want a module param to enable/disable async
> > (async_db_updates) in case it is important and maybe a bit flag option
> > as well that would reverse the async_db_updates option when flag set
> > for case by case basis.
> > Potentially with a separate queue process updates like registrations
> > could be combined into a single update.
> >
> > Dave
> >
> >
> > On Wed, Mar 16, 2011 at 10:32 AM, Brett Nemeroff<brett at nemeroff.com>
>  wrote:
> >>
> >>
> >>
> >> On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu<vladpaiu at opensips.org>
>  wrote:
> >>> Hello all,
> >>>
> >>> Problem :
> >>> 1) Extend the OpenSIPS DB core. Add extra core processes that would
> only
> >>> handle queries that return no results.
> >>>      For example : The accounting module need to insert an entry in the
> DB.
> >>> The module calls the insert() function. Behind the scene, this triggers
> >>> passing all the arguments to the new core processes, via IPC
> mechanisms. The
> >>> insert() then exists and the SIP children continues execution as if the
> >>> entry has been inserted in the DB. Meanwhile, the DB core processes
> receive
> >>> the new parameters, build and send the query, blocking if necessary.
> >>>
> >> Maybe I'm just saying the same thing another way, but what about an
> async
> >> execution queue. So you basically add to the queue messages to be
> executed
> >> to the database and on some sort of timer loop process them. To the
> script,
> >> we just assume everything is 100% successful.
> >> Is IPC really necessary for this? The goal here is really just to
> offload
> >> the processing elsewhere so that the DB slowness doesn't adversely
> affect
> >> opensips core performance. right?
> >>
> >> I thin it's also important that there is a async execute and a sync
> execute
> >> and people (users?) need to know that in the async execute, you won't
> know
> >> if the execute succeeded in the script logic *ever*
> >> -Brett
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS eBootcamp - 2nd of May 2011
> OpenSIPS solutions and "know-how"
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> End of Users Digest, Vol 33, Issue 11
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110405/6666ea25/attachment-0001.htm>