29 Oct
2007
29 Oct
'07
4:20 p.m.
Hi, I'd like to extend the "location" table with more attributes and get
them
as AVP's after "lookup()" function. Is it any automatic way to do that?
I mean something as "auth_db" module's "load_credentials" that
load AVP's with
more subscriber data.
I don't find it so I think I'll need to do a custom SQL query after
"lookup()"
(in branch_route) and get the custom fields.
Anyway I ask it: is there any way I don't know to get this "easily"?
Thanks.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
30 Oct
30 Oct
5:55 a.m.
Hi Iñaki,
Currently this is not possible, but there were some discussions about
this feature some time ago (if I'm not wrong, there is a feature request
about this on the tracker).
The only custom information you can push form script (at save) and
retrieved (at lookup) are the branch flags :).
Regards,
Bogdan
Iñaki Baz Castillo wrote:
Hi, I'd like to extend the "location"
table with more attributes and get them
as AVP's after "lookup()" function. Is it any automatic way to do that?
I mean something as "auth_db" module's "load_credentials" that
load AVP's with
more subscriber data.
I don't find it so I think I'll need to do a custom SQL query after
"lookup()"
(in branch_route) and get the custom fields.
Anyway I ask it: is there any way I don't know to get this "easily"?
Thanks.
10:48 a.m.
El Tuesday 30 October 2007 04:55:57 Bogdan-Andrei Iancu escribió:
Hi Iñaki,
Currently this is not possible, but there were some discussions about
this feature some time ago (if I'm not wrong, there is a feature request
about this on the tracker).
The only custom information you can push form script (at save) and
retrieved (at lookup) are the branch flags :).
Yes, but it's not enought. I use "location" table to enter manual
forwardings
and need an atribute extra for things as "invite timeout" and so.
Thanks, I'll look for the fueature request).
Regards.
--
ilimit...
*Iñaki Baz Castillo*
ibc(a)in.ilimit.es
ÀREA SISTEMES
0034 937 333 375
VOLTA 1, PIS 5
08224 TERRASSA.BCN
Aquest enviament és confidencial i està destinat únicament a la persona a qui
s'ha enviat.
Pot contenir informació privada sotmesa al secret professional, la distribució
de la qual està prohibida per la legislació vigent.
11:28 a.m.
But why do you need to keep the timeout in the location table? keep it
in avp table or in the subscriber table.
regards,
bogdan
Iñaki Baz Castillo wrote:
El Tuesday 30 October 2007 04:55:57 Bogdan-Andrei
Iancu escribió:
Hi Iñaki,
Currently this is not possible, but there were some discussions about
this feature some time ago (if I'm not wrong, there is a feature request
about this on the tracker).
The only custom information you can push form script (at save) and
retrieved (at lookup) are the branch flags :).
Yes, but it's not enought. I use "location" table to enter manual
forwardings
and need an atribute extra for things as "invite timeout" and so.
Thanks, I'll look for the fueature request).
Regards.
11:57 a.m.
El Tuesday 30 October 2007 10:28:36 Bogdan-Andrei Iancu escribió:
But why do you need to keep the timeout in the
location table? keep it
in avp table or in the subscriber table.
I don't understand how can be useful a timeout value in subscriber table. If a
subscriber calls it will hangup when he decides, why to force it?
I use LCR for call before users with greater "q".
And I insert entries in "location" table via web app to implement forwarding
(depending on the "q" value it can be serial or parallel).
So I need a INVITE timeout for each forwarding but not for each subscriber
user.
For example:
"location" table:
-----------------------------------------------------------------------------------------------------
username domain contact q timeout
200 domain.org sip:200@10.10.1.33:5060 0.50 null
200 domain.org sip:215@domain.org 0.40 20
200 domain.org sip:66612323@domain.org 0.30 60
200 domain.org sip:65532090@domain.org 0.30 60
-----------------------------------------------------------------------------------------------------
When 200(a)domain.org is called "next_contacts()"
returns "sip:200@10.10.1.33:5060" (the "real" registered user) so
it's valid
the parameter "fr_inv_timer_next" of "lcr" module.
If it doesn't answer, failure_route calls to sip:215@domain.org. The timeout
would be "lcr" - "fr_inv_timer_next" by default, but I'd like this
to be
customizable per entry in "location" table:
During "lookup(location)" "timeout" field should be loaded
as "fr_inv_timer_avp".
For this I'd need a way to load that value when doing "lookup()".
That is why it'd be cool this feature in my case.
Regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
4:30 p.m.
nothing special:
RTPproxy:
./rtpproxy -fl 127.0.0.1 -s udp:127.0.0.1:7899
$ ./rtpproxy -v
Basic version: 20040107
Extension 20050322: Support for multiple RTP streams and MOH
Extension 20060704: Support for extra parameter in the V command
OpenSER:
$ ./openser -V
version: openser 1.3.0-pre1-notls (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP,
PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024,
BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:2992M
@(#) $Id: main.c 2880 2007-10-08 07:13:00Z henningw $
main.c compiled on 04:47:44 Oct 29 2007 with gcc 4.1.3
modparam("nathelper", "rtpproxy_sock", "2 ==
udp:localhost:7899")
modparam("nathelper", "natping_interval", 0)
modparam("nathelper", "sipping_bflag", 7)
modparam("nathelper", "sipping_from", "sip:pinger@test.ro")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "ping_nated_only", 0)
modparam("nathelper", "natping_processes", 3)
regards,
bogdan
Iñaki Baz Castillo wrote:
El Tuesday 30 October 2007 10:28:36 Bogdan-Andrei
Iancu escribió:
But why do you need to keep the timeout in the
location table? keep it
in avp table or in the subscriber table.
I don't understand how can be useful a timeout value in subscriber table. If a
subscriber calls it will hangup when he decides, why to force it?
I use LCR for call before users with greater "q".
And I insert entries in "location" table via web app to implement forwarding
(depending on the "q" value it can be serial or parallel).
So I need a INVITE timeout for each forwarding but not for each subscriber
user.
For example:
"location" table:
-----------------------------------------------------------------------------------------------------
username domain contact q timeout
200 domain.org sip:200@10.10.1.33:5060 0.50 null
200 domain.org sip:215@domain.org 0.40 20
200 domain.org sip:66612323@domain.org 0.30 60
200 domain.org sip:65532090@domain.org 0.30 60
-----------------------------------------------------------------------------------------------------
When 200(a)domain.org is called "next_contacts()"
returns "sip:200@10.10.1.33:5060" (the "real" registered user) so
it's valid
the parameter "fr_inv_timer_next" of "lcr" module.
If it doesn't answer, failure_route calls to sip:215@domain.org. The timeout
would be "lcr" - "fr_inv_timer_next" by default, but I'd like
this to be
customizable per entry in "location" table:
During "lookup(location)" "timeout" field should be loaded
as "fr_inv_timer_avp".
For this I'd need a way to load that value when doing "lookup()".
That is why it'd be cool this feature in my case.
Regards.
5:27 p.m.
Upsss.....I mixed a bit the threads :D...this was actually for the
RTPproxy stuff......
silly me,
bogdan
Bogdan-Andrei Iancu wrote:
nothing special:
RTPproxy:
./rtpproxy -fl 127.0.0.1 -s udp:127.0.0.1:7899
$ ./rtpproxy -v
Basic version: 20040107
Extension 20050322: Support for multiple RTP streams and MOH
Extension 20060704: Support for extra parameter in the V command
OpenSER:
$ ./openser -V
version: openser 1.3.0-pre1-notls (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP,
PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024,
BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:2992M
@(#) $Id: main.c 2880 2007-10-08 07:13:00Z henningw $
main.c compiled on 04:47:44 Oct 29 2007 with gcc 4.1.3
modparam("nathelper", "rtpproxy_sock", "2 ==
udp:localhost:7899")
modparam("nathelper", "natping_interval", 0)
modparam("nathelper", "sipping_bflag", 7)
modparam("nathelper", "sipping_from",
"sip:pinger@test.ro")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "ping_nated_only", 0)
modparam("nathelper", "natping_processes", 3)
regards,
bogdan
Iñaki Baz Castillo wrote:
El Tuesday 30 October 2007 10:28:36 Bogdan-Andrei
Iancu escribió:
But why do you need to keep the timeout in the
location table? keep it
in avp table or in the subscriber table.
I don't understand how can be useful a timeout value in subscriber
table. If a subscriber calls it will hangup when he decides, why to
force it?
I use LCR for call before users with greater "q".
And I insert entries in "location" table via web app to implement
forwarding (depending on the "q" value it can be serial or parallel).
So I need a INVITE timeout for each forwarding but not for each
subscriber user.
For example:
"location" table:
-----------------------------------------------------------------------------------------------------
username domain contact q
timeout
200 domain.org sip:200@10.10.1.33:5060 0.50 null
200 domain.org sip:215@domain.org 0.40 20
200 domain.org sip:66612323@domain.org 0.30 60
200 domain.org sip:65532090@domain.org 0.30 60
-----------------------------------------------------------------------------------------------------
When 200(a)domain.org is called "next_contacts()" returns
"sip:200@10.10.1.33:5060" (the "real" registered user) so it's
valid
the parameter "fr_inv_timer_next" of "lcr" module.
If it doesn't answer, failure_route calls to sip:215@domain.org. The
timeout would be "lcr" - "fr_inv_timer_next" by default, but I'd
like
this to be customizable per entry in "location" table:
During "lookup(location)" "timeout" field should be loaded as
"fr_inv_timer_avp".
For this I'd need a way to load that value when doing "lookup()".
That is why it'd be cool this feature in my case.
Regards.
6233
days inactive
6234
days old
6 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo