Hi Lenir!
I've never used, thus I do not know how to use it. MAybe some can help us:
What should be written into src and dst AVPs? The SIP URI of B and C
(call forwarding scenario)?
Which radius types will be used for them?
regards
klaus
Lenir wrote:
> Hey guys,
>
> I sent this as a duplicate for eaiser searching for others to find.
>
> pardon my ignorance...Klaus that was help full, thank you.
> Ok, so I know how/which AVPs to populate. But I still don't know when to
> populate them.
>
> Let me elaborate more on this, Im doing radius accounting, so I don't know
> when to set the flag in conjunction with when to populate the AVPs.
>
> Will the avp_write() function trigger a radius star/stop record when the
> AVPs are populated?
>
> Do I use a radius function in conjunction with all of this?
>
> If anybody has a brief example or a snippet of their config, this would
> greatly help.
>
>
> Thanks,
>
> Lenir
> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Sent: Thursday, December 15, 2005 5:29 AM
> To: Lenir
> Cc: users(a)openser.org
> Subject: Re: [Users] Multi Call Leg Accounting/Billing
>
> Hi Lenir!
>
> You should read the emails on the mailing list (or the archive).
> Read the thread initiated from Helge on 8.12.2005
>
> klaus
>
> Lenir wrote:
>
>>Hello guys,
>>
>>
>>
>>I read in the documentation for the ACC module that it supports multi
>>call-leg accounting via the use of AVPs, which comes in handing when
>>doing call forwarding. However, I've googled the way with all the
>>keywords that I could think of and I cant find an example of this
>>feature. I understand that you have to turn it on using:
>>
>>
>>
>>modparam("acc", "multi_leg_enabled", 1)
>>
>>modparam("acc", "src_leg_avp_id", 110)
>>
>>modparam("acc", "dst_leg_avp_id", 111)
>>
>>
>>
>>But it doesn't show or say when/how to use the AVPs. Can anybody provide
>>a sample snippet or their openser.cfg file to demonstrate how it's used?
>>
>>
>>
>>
>>
>>Thanks in advance!
>>
>>
>>
>>Lenir
>>
>>
>>
>>P.s. perhaps put a sample config in the documentation. The one there
>>doesn't show how to use Multi Call-leg billing.
>>
>>
>>
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Users mailing list
>>Users(a)openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
Hi,
Does OpenSER support sequentially processing the same
reply by several onreply routes, i.e.
route
{
# general case - have all replies processed by
# onreply_route[1]
t_on_reply("1");
if (mycondition)
{
# special case - these replies should be processed
# by onreply_route[1] _and_ by onreply_route[2]
t_on_reply("2");
}
t_relay();
}
onreply_route[1]
{
#
append_hf("P-MyExtraInfo: xyz\r\n");
}
onreply_route[2]
{
# do some extra processing here
}
I did not find any info on this topic in the docs. Imho
the ability to use trigger several onreply_routes for
sequential processing can help extremly in keeping code
clean and readable.
Assume a proxy that is required, e.g., to insert a
new header field into _any_ reply. In addition, some
other replies need some extra handling in the onreply
route. Without the capability to trigger multiple
onreply-routes this leads to many conditionals in either
the main route or in the reply route(s).
Thanks in advance,
--Joachim
Ok, other than the fact that you have pattern matching in lcr, what are
the key differences between Dispatcher and LCR? Anyone have any examples
or howto's to point me to?
Sincerely,
Too cheap to by a SLB.. :-)
Hi Bogdan,
> I meant t_reply() will keep its behaviour as looking into URI for the
> destination - but it will incorporate the NAPTR lookup.
Great - this answers my question.
> to response also to on earlier question, regarding the timing
> - I say 3 months are more than enough ;).
Excellent.
Many thanks for your help (and patience ;)
--Joachim
> Joachim Fabini wrote:
>
> >Hi Bogdan,
> >
> >
> >
> >>indeed, there was a misunderstanding :) .t_relay() with no
> >>param will be kept with the current functionality.
> >>Or you suggest to be able to specify only a different proto
> >>or port from the RURI?
> >>
> >>
> >
> >I did not yet find the primitive which is supposed to
> >statefully relay and do the following:
> >1. NAPTR query on the transport to use PLUS
> >2. _exactly_ what t_relay() does now for the
> > transport returned by the NAPTR query.
> >
> >You say that t_relay() is kept with the current functionality.
> >Does this mean no NAPTR, or will t_relay() be extended to use
> >NAPTR before SRV/A query? If the latter then everything is OK.
> >
> >Otherwise we have the alternatives:
> >
> >t_relay() -> Stateful relaying according to destination
> > address using the incoming transport (no NAPTR).
> >t_relay_to() -> Stateful relaying to a specific host (you said
> > that <host> is mandatory here) using NAPTR to
> > determine the transport.
> >
> >
> >To summarize:
> >My point is that none of these two primitives covers the case
> >when the message is to be relayed to the next hop based only
> >on the destination address _and_ using the transport selected
> >by the destination proxy (determined via NAPTR query).
> >
> >Except if either a) t_relay() does NAPTR or b) the host
> >parameter in t_relay_to() is optional.
> >
> >--Joachim
> >
> >
> >
> >
>
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Seeing the roadmap for 1.1 I realized that NAPTR solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
Hallo again,
I still can't get openser mysql module to find correct libmysqlclient.
So I have changed my setup I now have debian stable with libc:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries and Timezone
ii libc6-dev 2.3.2.ds1-22 GNU C Library: Development Libraries and Hea
dpkg -i openser-mysql-module_1.0.0.0_i386.deb
Selecting previously deselected package openser-mysql-module.
(Reading database ... 23597 files and directories currently installed.)
Unpacking openser-mysql-module (from openser-mysql-module_1.0.0.0_i386.deb) ...
dpkg: dependency problems prevent configuration of openser-mysql-module:
openser-mysql-module depends on libmysqlclient10; however:
Package libmysqlclient10 is not installed.
dpkg: error processing openser-mysql-module (--install):
I tried installing SER again to see if I still can get it to work and it worked fine.
I installed this version of ser:
Get:1 http://apt.sip-router.org stable/main ser 0.9.4-0.1
Unpacking ser-mysql-module (from .../ser-mysql-module_0.9.4-0.1_i386.deb) ...
Setting up ser-mysql-module (0.9.4-0.1) ...
These are the mysql packages I have installed:
ii libmysqlclient12 4.0.24-10sarge1 mysql database client library
ii libmysqlclient15 5.0.13rc-1 mysql database client library
ii mysql-client-5.0 5.0.13rc-1 mysql database client binaries
So openser-mysql-module, needs to use the shared library libmysqlclient12 instead of libmysqlclient10?
Any ideas?
regards
/Maria
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
> Sent: den 15 december 2005 15:10
> To: Maria Yndefors
> Cc: users(a)openser.org
> Subject: Re: [Users] mysql cluster and openser
>
>
> indeed, if you have debian unstable, use the corresponding openser
> package...
>
> regards,
> bogdan
>
> Maria Yndefors wrote:
>
> >Ok,
> >I have downloaded the packages from deb-stable directory? So
> I guess I have to change to the unstable packages...
> >I guess libc is not the same on them.
> >
> >openser_1.0.0.0_i386.deb
> >openser-mysql-module_1.0.0.0_i386.deb
> >
> >Regards
> >/Maria
> >
> >
> >
>
Hi!
I have a SIP phone sending a REGISTER request every second. I want to
block requests from this SIP phone for some time. I've read the docs but
IMO the configuration and usage is quite complicated. Can the pike
module be used to block this user? I'm not sure how to configure the
pike module to block the REGISTER (1 request per second) but to allow
proper dialing (e.g. a call setup may have 4 requests within one second).
Does the pike module count all requests received or only those requests
for which I execute pike_check_req()?
regards
klaus
I've got some problem when I try to forward an incoming call to a PSTN
gateway :
The call comes in over the public network interface and should be
forwarded via the private interface to the gateway (which only has a pvt
address), but for some reason, the traffic is sent out over the public
interface again and -logically- not able to find the gateway.
Any idea where to look ?
Wilko
We thought about sending calls back though OpenSER too, and in Asterisk referencing all dial commands with @proxy, but it really was not clear how things like ACD Queues with agent call backs would work for a start.
-----Original Message-----
From: Iqbal [mailto:iqbal@gigo.co.uk]
Sent: Friday, December 16, 2005 11:26 AM
To: Douglas Garstang
Cc: Klaus Darilion; users(a)openser.org
Subject: Re: [Users] Transaction already in Process
jumping in alittle late on this one, but i read that routing the calls
back via openser is a pain rather than terminating on asterisk.
I had the same dilemma sometime ago when doing virtual pbx setup, but i
found it easier to send the call back to ser, and let it do all the
registration/routing etc, and just use asterisk for features. would be
interested on feedback on this....I may have designed it all wrong after
reading this :-)
Iqbal
Douglas Garstang wrote:
>Klaus,
>
>That's it!
>
>Doug.
>
>-----Original Message-----
>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
>Sent: Friday, December 16, 2005 12:25 AM
>To: Douglas Garstang
>Cc: users(a)openser.org
>Subject: Re: [Users] Transaction already in Process
>
>
>So how does it look like when Client A calls Client B? Is the signaling
>Like in the figure?
>
> Asterisk
> / \
> / \
> Openser \
> / \
> / \
>Client A Client B
>
>
>regards
>klaus
>
>
>
>Douglas Garstang wrote:
>
>
>>Klaus,
>>
>>All calls are going through OpenSER from the phones. However, they don't go BACK to OpenSER. Asterisk terminates the call. Putting all calls BACK through OpenSER would be a nightmare. It would make a lot of Asterisk features such as ACD Queues, MeetMe Conferencing etc very hard to manage. I'm not even sure if they would work.
>>
>>Doug.
>>
>>-----Original Message-----
>>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
>>Sent: Thursday, December 15, 2005 8:23 AM
>>To: Douglas Garstang
>>Cc: users(a)openser.org
>>Subject: Re: [Users] Transaction already in Process
>>
>>
>>I can't explain it, but I do not like the idea replicating with failure
>>routes ...
>>
>>IMO it would be better to modify t_replicate to allow to replicate to
>>moultiple instances.
>>
>>Would i be possible to route all calls via openser? Then you do not need
>>the location info in the Asterisks.
>>
>>
>>regards
>>klaus
>>
>>Douglas Garstang wrote:
>>
>>
>>
>>>Klaus,
>>>
>>>Asterisk can't use a database for location/contact information. It also has no native means to transfer registrations between itself and another Asterisk system. It can't even perform a user defined action when a phone registers... doesn't leave us with many options. Right now, using OpenSER to replicate (forward,t_relay,t_replicate whatever) seems to be working ok. Do you have any reason to believe it wouldn't scale up well?
>>>
>>>Doug.
>>>
>>>-----Original Message-----
>>>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
>>>Sent: Thursday, December 15, 2005 3:23 AM
>>>To: Douglas Garstang
>>>Cc: users(a)openser.org
>>>Subject: Re: [Users] Transaction already in Process
>>>
>>>
>>>Hi Douglas!
>>>
>>>I still think it is a bad idea to replicate REGISTER to Asterisk 4
>>>times. Where does Asterisk store the location table? In a database? Why
>>>not replicate the location data on DB level?
>>>
>>>regards
>>>klaus
>>>
>>>Douglas Garstang wrote:
>>>
>>>
>>>
>>>
>>>>Arrgh!
>>>>
>>>>Now I'm getting "t_newtran: transaction already in process" messages whenever I try to call t_relay() or t_replicate twice, even when the first attempt has FAILED. In the case of t_relay() I have new addresses in the destination set and I still get this error. Why? When you attempt to deliver, and it fails, how can to attempt again without getting those messages? What fundamental piece am I missing?
>>>>
>>>>How could I do this? Forget the fancy stuff. I don't care about checking for failure anymore.
>>>>
>>>>t_replicate("192.168.10.7","5060");
>>>>t_replicate("192.168.10.8","5060");
>>>>t_replicate("192.168.10.200","5060");
>>>>
>>>>Doug.
>>>>
>>>>_______________________________________________
>>>>Users mailing list
>>>>Users(a)openser.org
>>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>.
>
>
>