Re: [SR-Users] pkg.stats problem
Hello, can you get the type of the process with 'kamctl ps'? Cheers, Daniel On 9/20/13 6:51 PM, Vitaliy Aleksandrov wrote: Didn't check master branch before writing previous email. There were some commits about memory leaks in websocket module. Will try master. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] pkg.stats problem
Hello,
I have one installation with a strange pkg.stats output:
root@host:~# kamcmd pkg.stats index 36
{
entry: 36
pid: 2599
rank: -4
used: 16234288
free: 15788240
real_used: 16900864
}
After some time I've checked it again and found that used and real_used
fields grew up while free wasn't changed:
root@host:~# kamcmd pkg.stats index 36
{
entry: 36
pid: 2599
rank: -4
used: 19393184
free: 15788240
real_used: 20125968
}
Additional info:
- kamailio-4.0.2 started with -m 128 -M 16
- Process:: ID=36 PID=2599 Type=tcp main process
- this server works as a websocket(ws,wss) to udp/tcp gateway.
How is it possible that real_used is bigger that -M allows and free
value is not changing while used/real_used are growing up.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] pkg.stats problem
Didn't check master branch before writing previous email. There were some commits about memory leaks in websocket module. Will try master. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Stupid NAT tricks to learn from Apple
Hi Daniel, I know, shocking (heh)! The protocol violations were very slight - omitting SDP rtpmap lines for dynamic RTP payloads, omitting a=rtcp-mux for RTP+RTCP mux (but they're already muxing SIP too, so ehh). Possibly others. On Fri, Sep 20, 2013 at 10:19 AM, Daniel-Constantin Mierla wrote: > Hello, > > interesting, thanks for sharing! > > What else I could say, I am really deeply extremely ... (can't find other > words) ... shocked they don't use SIGCOMP specs [ha ha!]! I remember some > discussions when I said that usage of one well established compression > algoritm will get it done in few hours (implementatio wise) than what IETF > came up with in this regard. Sad but true, many IETF specs have no touch > with reality... > > Maybe I missed while quick reading, what are the "various /slight/ protocol > violations" you spotted? > > Cheers, > Daniel > > > On 9/20/13 3:16 PM, Kristian Kielhofner wrote: >> >> I've been spending some time looking at some of the significant >> changes Apple has made to Facetime in iOS 7. I'm far from an Apple >> fanboy but some of them are pretty interesting: >> >> - multiplexing everything over a single UDP port >> - deflate compression with SIP >> - various /slight/ protocol violations ;) >> >> More here: >> >> http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html >> >> As SDP bodies swell more and more can we hope to build significant >> support for multiplexing and deflate compression in the SIP-focused >> open source ecosystem? >> > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 > - more details about Kamailio trainings at http://www.asipto.com - > > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Kristian Kielhofner ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Stupid NAT tricks to learn from Apple
Hi Kristian, On 9/20/13 5:15 PM, Kristian Kielhofner wrote: Hi Daniel, I know, shocking (heh)! The protocol violations were very slight - omitting SDP rtpmap lines for dynamic RTP payloads, omitting a=rtcp-mux for RTP+RTCP mux (but they're already muxing SIP too, so ehh). Possibly others. ahh, ok, I remarked your notes about, but somehow I had in mind only the SIP part (headers), not the SDP body. I was looking to see if they use some custom format or not-specified values for headers... Thanks, Daniel On Fri, Sep 20, 2013 at 10:19 AM, Daniel-Constantin Mierla wrote: Hello, interesting, thanks for sharing! What else I could say, I am really deeply extremely ... (can't find other words) ... shocked they don't use SIGCOMP specs [ha ha!]! I remember some discussions when I said that usage of one well established compression algoritm will get it done in few hours (implementatio wise) than what IETF came up with in this regard. Sad but true, many IETF specs have no touch with reality... Maybe I missed while quick reading, what are the "various /slight/ protocol violations" you spotted? Cheers, Daniel On 9/20/13 3:16 PM, Kristian Kielhofner wrote: I've been spending some time looking at some of the significant changes Apple has made to Facetime in iOS 7. I'm far from an Apple fanboy but some of them are pretty interesting: - multiplexing everything over a single UDP port - deflate compression with SIP - various /slight/ protocol violations ;) More here: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html As SDP bodies swell more and more can we hope to build significant support for multiplexing and deflate compression in the SIP-focused open source ecosystem? -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Stupid NAT tricks to learn from Apple
Hello, interesting, thanks for sharing! What else I could say, I am really deeply extremely ... (can't find other words) ... shocked they don't use SIGCOMP specs [ha ha!]! I remember some discussions when I said that usage of one well established compression algoritm will get it done in few hours (implementatio wise) than what IETF came up with in this regard. Sad but true, many IETF specs have no touch with reality... Maybe I missed while quick reading, what are the "various /slight/ protocol violations" you spotted? Cheers, Daniel On 9/20/13 3:16 PM, Kristian Kielhofner wrote: I've been spending some time looking at some of the significant changes Apple has made to Facetime in iOS 7. I'm far from an Apple fanboy but some of them are pretty interesting: - multiplexing everything over a single UDP port - deflate compression with SIP - various /slight/ protocol violations ;) More here: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html As SDP bodies swell more and more can we hope to build significant support for multiplexing and deflate compression in the SIP-focused open source ecosystem? -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com - ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Stupid NAT tricks to learn from Apple
On Fri, Sep 20, 2013 at 9:36 AM, Olle E. Johansson wrote: > > 20 sep 2013 kl. 15:16 skrev Kristian Kielhofner : > > I've been spending some time looking at some of the significant > changes Apple has made to Facetime in iOS 7. I'm far from an Apple > fanboy but some of them are pretty interesting: > > - multiplexing everything over a single UDP port > > > After reading your very good blog entry (thanks!) I suspect that > they have gone the extra way and mixed SIP/RTP/RTCP due to > carrier grade nats. There's a new RFC describing issues with those > and one is a shortage of ports. Every customer gets only a few > allocations and only one per common port. ONly one SIP phone > on 5060 as an example. > > Limiting the number of ports used will not only make firewall > traversal easier, it will make CGN traversal easier. While waiting > for the real stuff - IPv6. > > Blog: > http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html > CGN RFC: > http://www.rfc-editor.org/rfc/rfc7021.txt > > /O Olle, Great point! I've updated my blog post with this information. Thanks! -- Kristian Kielhofner ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher: set $du in failure_route
Hello,
great to see you made it trough several nice workarounds to build your
wanted solution.
If not helping others for same needs, definitely shows the potential to
play with config to find solutions for crazy ideas :-) and hopefully
more people will start looking at parameters and functions from
different perspectives, not just at the pure meaning of them.
Thanks for sharing,
Daniel
On 9/20/13 3:25 PM, Grant Bagdasarian wrote:
Answering another question of mine: "I just need to know how to
extract the terminatingsbcaddress from the $avp(dsattrs) avp, so I can
set the $du in failure_route."
Solution: Use param transformations
$(avp(dsattrs){param.value,terminatingsbcaddress})
This does require the modparam to be changed from:
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS
NVARCHAR(MAX)) + ',' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ',' + Attributes) AS Attributes")
To
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS
NVARCHAR(MAX)) + ';' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ';' + Attributes) AS Attributes")
Note the commas been replaced by semicolons.
I hope this will help others with similar issues in the future.
*From:*sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] *On Behalf Of *Grant
Bagdasarian
*Sent:* Friday, September 20, 2013 2:49 PM
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] dispatcher: set $du in failure_route
Answering my own question: Is there a way to insert this piece of SQL
into the query the dispatcher executes to load its table, so that the
attrs_avp is filled with these additional values?
Yes, it is. Don't know if this is a safe way in doing so, but here it is.
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS
NVARCHAR(MAX)) + ',' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ',' + Attributes) AS Attributes")
Forget what I said/asked before this question, it doesn't make sense,
it is solved with this solution.
I just need to know how to extract the terminatingsbcaddress from the
$avp(dsattrs) avp, so I can set the $du in failure_route.
*From:*sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] *On Behalf Of *Grant
Bagdasarian
*Sent:* Friday, September 20, 2013 10:03 AM
*To:* mico...@gmail.com ; Kamailio (SER) -
Users Mailing List
*Subject:* Re: [SR-Users] dispatcher: set $du in failure_route
Hello,
Thank you for the idea!
When executing my stored procedure to select the route, one of my
columns is built up like below.
('routeid='+CAST(IDASNVARCHAR(MAX))+','+'terminatingsbcaddress='+TerminatingSBCAddress+','+Attributes)ASAttributes
This gives me the already set attributes for the route, but also adds
two additional key value pairs to the column.
I should be able to store the values in avp's right? And access them
later in failure_route? The terminatingsbcaddress key stores the
address which is used to reset the $du value.
The less queries I can perform, the better.
If this is possible, how do I extract the terminatingsbcaddress from
this column and store it in an AVP? I've never worked with AVP's before.
I know I have to start by doing:
$var(attributes) = $dbr(vd_query_result=>[0,0]);
If this is not possible, is there a way to insert this piece of SQL
into the query the dispatcher executes to load its table, so that the
attrs_avp is filled with these additional values?
I couldn't find the SQL which was executed by the dispatcher in the
source code.
*From:*sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] *On Behalf Of
*Daniel-Constantin Mierla
*Sent:* Thursday, September 19, 2013 9:11 PM
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] dispatcher: set $du in failure_route
On 9/18/13 4:53 PM, Grant Bagdasarian wrote:
My Dispatcher table has been extended with more columns and also
functions as our routing table.
I've modified the names of the columns Dispatcher uses to match
the columns of the routing table.
One of the columns contains the address which is used to set the
$du value.
So, for every request I'm executing a stored procedure using
sqlops to select the address of the SBC (for $du) and the set id
to use for the dispatcher.
If I'm correct, the dispatcher table is loaded into memory once
Kamailio is started or the table is reloaded.
In case the first destination fails, how would I get the address
of the next SBC to reset the $du value in failure_route?
I think I can do it using the setid and the next priority, but how
do I access these two values in failure_route?
Are there any other solutions to this, perhaps other modules with
similar functionality as the dispatcher module?
The s
Re: [SR-Users] Stupid NAT tricks to learn from Apple
20 sep 2013 kl. 15:16 skrev Kristian Kielhofner : > I've been spending some time looking at some of the significant > changes Apple has made to Facetime in iOS 7. I'm far from an Apple > fanboy but some of them are pretty interesting: > > - multiplexing everything over a single UDP port After reading your very good blog entry (thanks!) I suspect that they have gone the extra way and mixed SIP/RTP/RTCP due to carrier grade nats. There's a new RFC describing issues with those and one is a shortage of ports. Every customer gets only a few allocations and only one per common port. ONly one SIP phone on 5060 as an example. Limiting the number of ports used will not only make firewall traversal easier, it will make CGN traversal easier. While waiting for the real stuff - IPv6. Blog: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html CGN RFC: http://www.rfc-editor.org/rfc/rfc7021.txt /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Stupid NAT tricks to learn from Apple
20 sep 2013 kl. 15:16 skrev Kristian Kielhofner : > I've been spending some time looking at some of the significant > changes Apple has made to Facetime in iOS 7. I'm far from an Apple > fanboy but some of them are pretty interesting: > > - multiplexing everything over a single UDP port That's what's Google has done with Hangouts and what we're currently working on in the IETF to standardize, driven by WebRTC. Will be very beneficial for all VoIP. > - deflate compression with SIP > - various /slight/ protocol violations ;) getting depressed /O > > More here: > > http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html > > As SDP bodies swell more and more can we hope to build significant > support for multiplexing and deflate compression in the SIP-focused > open source ecosystem? > > -- > Kristian Kielhofner > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher: set $du in failure_route
Answering another question of mine: "I just need to know how to extract the
terminatingsbcaddress from the $avp(dsattrs) avp, so I can set the $du in
failure_route."
Solution: Use param transformations
$(avp(dsattrs){param.value,terminatingsbcaddress})
This does require the modparam to be changed from:
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS NVARCHAR(MAX)) +
',' + 'terminatingsbcaddress=' + TerminatingSBCAddress + ',' + Attributes) AS
Attributes")
To
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS NVARCHAR(MAX)) +
';' + 'terminatingsbcaddress=' + TerminatingSBCAddress + ';' + Attributes) AS
Attributes")
Note the commas been replaced by semicolons.
I hope this will help others with similar issues in the future.
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Grant Bagdasarian
Sent: Friday, September 20, 2013 2:49 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
Answering my own question: Is there a way to insert this piece of SQL into the
query the dispatcher executes to load its table, so that the attrs_avp is
filled with these additional values?
Yes, it is. Don't know if this is a safe way in doing so, but here it is.
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS NVARCHAR(MAX)) +
',' + 'terminatingsbcaddress=' + TerminatingSBCAddress + ',' + Attributes) AS
Attributes")
Forget what I said/asked before this question, it doesn't make sense, it is
solved with this solution.
I just need to know how to extract the terminatingsbcaddress from the
$avp(dsattrs) avp, so I can set the $du in failure_route.
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Grant Bagdasarian
Sent: Friday, September 20, 2013 10:03 AM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing
List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
Hello,
Thank you for the idea!
When executing my stored procedure to select the route, one of my columns is
built up like below.
('routeid='+ CAST(ID AS NVARCHAR(MAX)) + ',' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ',' + Attributes) AS Attributes
This gives me the already set attributes for the route, but also adds two
additional key value pairs to the column.
I should be able to store the values in avp's right? And access them later in
failure_route? The terminatingsbcaddress key stores the address which is used
to reset the $du value.
The less queries I can perform, the better.
If this is possible, how do I extract the terminatingsbcaddress from this
column and store it in an AVP? I've never worked with AVP's before.
I know I have to start by doing:
$var(attributes) = $dbr(vd_query_result=>[0,0]);
If this is not possible, is there a way to insert this piece of SQL into the
query the dispatcher executes to load its table, so that the attrs_avp is
filled with these additional values?
I couldn't find the SQL which was executed by the dispatcher in the source code.
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Daniel-Constantin
Mierla
Sent: Thursday, September 19, 2013 9:11 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
On 9/18/13 4:53 PM, Grant Bagdasarian wrote:
My Dispatcher table has been extended with more columns and also functions as
our routing table.
I've modified the names of the columns Dispatcher uses to match the columns of
the routing table.
One of the columns contains the address which is used to set the $du value.
So, for every request I'm executing a stored procedure using sqlops to select
the address of the SBC (for $du) and the set id to use for the dispatcher.
If I'm correct, the dispatcher table is loaded into memory once Kamailio is
started or the table is reloaded.
In case the first destination fails, how would I get the address of the next
SBC to reset the $du value in failure_route?
I think I can do it using the setid and the next priority, but how do I access
these two values in failure_route?
Are there any other solutions to this, perhaps other modules with similar
functionality as the dispatcher module?
The setid and next hop address are stored in AVPs, the names of the avps are
set via module parameters. See readme starting at:
http://kamailio.org/docs/modules/stable/modules/dispatcher.html#idp15216488
In failure route, before calling ds_next_*(), the first avps store the values
used for next destination. You can probably use them for your db query.
Cheers,
Daniel
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: Wednesday, S
[SR-Users] Stupid NAT tricks to learn from Apple
I've been spending some time looking at some of the significant changes Apple has made to Facetime in iOS 7. I'm far from an Apple fanboy but some of them are pretty interesting: - multiplexing everything over a single UDP port - deflate compression with SIP - various /slight/ protocol violations ;) More here: http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.html As SDP bodies swell more and more can we hope to build significant support for multiplexing and deflate compression in the SIP-focused open source ecosystem? -- Kristian Kielhofner ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dispatcher: set $du in failure_route
Answering my own question: Is there a way to insert this piece of SQL into the
query the dispatcher executes to load its table, so that the attrs_avp is
filled with these additional values?
Yes, it is. Don't know if this is a safe way in doing so, but here it is.
modparam("dispatcher", "attrs_col", "('routeid='+ CAST(ID AS NVARCHAR(MAX)) +
',' + 'terminatingsbcaddress=' + TerminatingSBCAddress + ',' + Attributes) AS
Attributes")
Forget what I said/asked before this question, it doesn't make sense, it is
solved with this solution.
I just need to know how to extract the terminatingsbcaddress from the
$avp(dsattrs) avp, so I can set the $du in failure_route.
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Grant Bagdasarian
Sent: Friday, September 20, 2013 10:03 AM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
Hello,
Thank you for the idea!
When executing my stored procedure to select the route, one of my columns is
built up like below.
('routeid='+ CAST(ID AS NVARCHAR(MAX)) + ',' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ',' + Attributes) AS Attributes
This gives me the already set attributes for the route, but also adds two
additional key value pairs to the column.
I should be able to store the values in avp's right? And access them later in
failure_route? The terminatingsbcaddress key stores the address which is used
to reset the $du value.
The less queries I can perform, the better.
If this is possible, how do I extract the terminatingsbcaddress from this
column and store it in an AVP? I've never worked with AVP's before.
I know I have to start by doing:
$var(attributes) = $dbr(vd_query_result=>[0,0]);
If this is not possible, is there a way to insert this piece of SQL into the
query the dispatcher executes to load its table, so that the attrs_avp is
filled with these additional values?
I couldn't find the SQL which was executed by the dispatcher in the source code.
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Daniel-Constantin
Mierla
Sent: Thursday, September 19, 2013 9:11 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
On 9/18/13 4:53 PM, Grant Bagdasarian wrote:
My Dispatcher table has been extended with more columns and also functions as
our routing table.
I've modified the names of the columns Dispatcher uses to match the columns of
the routing table.
One of the columns contains the address which is used to set the $du value.
So, for every request I'm executing a stored procedure using sqlops to select
the address of the SBC (for $du) and the set id to use for the dispatcher.
If I'm correct, the dispatcher table is loaded into memory once Kamailio is
started or the table is reloaded.
In case the first destination fails, how would I get the address of the next
SBC to reset the $du value in failure_route?
I think I can do it using the setid and the next priority, but how do I access
these two values in failure_route?
Are there any other solutions to this, perhaps other modules with similar
functionality as the dispatcher module?
The setid and next hop address are stored in AVPs, the names of the avps are
set via module parameters. See readme starting at:
http://kamailio.org/docs/modules/stable/modules/dispatcher.html#idp15216488
In failure route, before calling ds_next_*(), the first avps store the values
used for next destination. You can probably use them for your db query.
Cheers,
Daniel
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: Wednesday, September 18, 2013 4:23 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
Of course.
Grant Bagdasarian mailto:g...@cm.nl>> wrote:
Hello,
Can the $du value also be set in a failure_route? For instance in the case the
first destination fails.
I'm currently setting the $du value before I'm calling the ds_next_domain
function in request_route.
We have multiple carriers which are connected to different SBCs.
In case $du is not re-set in failure_route, Kamailio will try to send the
INVITE to the carrier directly, bypassing the SBC, correct?
Regards,
Grant
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Sent from my mobile, and thus lacking in the refinement one might expect from a
fully fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Re: [SR-Users] dispatcher: set $du in failure_route
Hello,
Thank you for the idea!
When executing my stored procedure to select the route, one of my columns is
built up like below.
('routeid='+ CAST(ID AS NVARCHAR(MAX)) + ',' + 'terminatingsbcaddress=' +
TerminatingSBCAddress + ',' + Attributes) AS Attributes
This gives me the already set attributes for the route, but also adds two
additional key value pairs to the column.
I should be able to store the values in avp's right? And access them later in
failure_route? The terminatingsbcaddress key stores the address which is used
to reset the $du value.
The less queries I can perform, the better.
If this is possible, how do I extract the terminatingsbcaddress from this
column and store it in an AVP? I've never worked with AVP's before.
I know I have to start by doing:
$var(attributes) = $dbr(vd_query_result=>[0,0]);
If this is not possible, is there a way to insert this piece of SQL into the
query the dispatcher executes to load its table, so that the attrs_avp is
filled with these additional values?
I couldn't find the SQL which was executed by the dispatcher in the source code.
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Daniel-Constantin
Mierla
Sent: Thursday, September 19, 2013 9:11 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
On 9/18/13 4:53 PM, Grant Bagdasarian wrote:
My Dispatcher table has been extended with more columns and also functions as
our routing table.
I've modified the names of the columns Dispatcher uses to match the columns of
the routing table.
One of the columns contains the address which is used to set the $du value.
So, for every request I'm executing a stored procedure using sqlops to select
the address of the SBC (for $du) and the set id to use for the dispatcher.
If I'm correct, the dispatcher table is loaded into memory once Kamailio is
started or the table is reloaded.
In case the first destination fails, how would I get the address of the next
SBC to reset the $du value in failure_route?
I think I can do it using the setid and the next priority, but how do I access
these two values in failure_route?
Are there any other solutions to this, perhaps other modules with similar
functionality as the dispatcher module?
The setid and next hop address are stored in AVPs, the names of the avps are
set via module parameters. See readme starting at:
http://kamailio.org/docs/modules/stable/modules/dispatcher.html#idp15216488
In failure route, before calling ds_next_*(), the first avps store the values
used for next destination. You can probably use them for your db query.
Cheers,
Daniel
From:
sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: Wednesday, September 18, 2013 4:23 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] dispatcher: set $du in failure_route
Of course.
Grant Bagdasarian mailto:g...@cm.nl>> wrote:
Hello,
Can the $du value also be set in a failure_route? For instance in the case the
first destination fails.
I'm currently setting the $du value before I'm calling the ds_next_domain
function in request_route.
We have multiple carriers which are connected to different SBCs.
In case $du is not re-set in failure_route, Kamailio will try to send the
INVITE to the carrier directly, bypassing the SBC, correct?
Regards,
Grant
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Sent from my mobile, and thus lacking in the refinement one might expect from a
fully fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
