my 2 cents:
1. nice attack ;-)
2. perform accounting only on a dialog statefull node
2.1 the gateway is the most accurate accounting source
2.2 if you need proxy based accounting use a media relay which you
disable on BYE
regards
klaus
Iñaki Baz Castillo wrote:
> Hi, first of all I'm sorry f
Strange!
Nevertheless there is no need to drop 100 as 100 is never relayed.
klaus
Aurelien Grimaud wrote:
> Daniel-Constantin Mierla a écrit :
>> Hello,
>>
>> On 12/18/08 13:18, Aurelien Grimaud wrote:
>>> Hi,
>>> In my openser, I had to not relay any provisional which is < 180.
>>> I used drop
IF you do not need full control you can use the engage_media_proxy()
function. This function monitors the dialog and handles reINVITEs and
BYEs and CANCELs automatically.
klaus
Krunal Patel wrote:
> Hi,
>
> Does anybody know how to detect whether use_media_proxy is called?
> What I want to do
El Jueves, 18 de Diciembre de 2008, Daniel-Constantin Mierla escribió:
> > The call hasn't finished, but Kamailio has ended the accounting for
> > this call since it received a BYE. And this BYE will generate a
> > correct ACC Stop action (since it matches From_tag, To_tag and
> > Call-ID).
> >
>
Daniel-Constantin Mierla a écrit :
> Hello,
>
> On 12/18/08 13:18, Aurelien Grimaud wrote:
>> Hi,
>> In my openser, I had to not relay any provisional which is < 180.
>> I used drop in reply route to do this.
>> No provisional < 180 is sent to caller.
>>
>> Unfortunately, dropping 100 seems to make
Hello,
On 12/18/08 13:18, Aurelien Grimaud wrote:
> Hi,
> In my openser, I had to not relay any provisional which is < 180.
> I used drop in reply route to do this.
> No provisional < 180 is sent to caller.
>
> Unfortunately, dropping 100 seems to make the transaction module not
> disarming its f
Hello,
On 12/18/08 13:48, Iñaki Baz Castillo wrote:
> Hi, first of all I'm sorry for this cross-posting, but I think it
> could be interesting for any SIP proxy with accounting capabilities.
>
> I'm thinking in the following flow in which the caller/attacker would
> get an unlimited call (but a li
Hello,
On 12/18/08 17:09, Andreas Granig wrote:
> Iñaki Baz Castillo wrote:
>
>> Well, failure_route will not be called when receiving a 200 OK in this
>> BYE transaction.
>> failure_route is only invoked for [3456]XX responses. 200 can only be
>> handled in on_reply_route, but I don't know if
2008/12/18 Andreas Granig :
>
>
> Andreas Granig wrote:
>>
>> I think I was discussing this with Daniel some time ago, and as far as I
>> remember, he thought it was save to do so (although it's not enabled for
>
> Save to call acc_db_request() is what I mean here...
Ah, ok, it makes sense. I will
Andreas Granig wrote:
> I think I was discussing this with Daniel some time ago, and as far as I
> remember, he thought it was save to do so (although it's not enabled for
Save to call acc_db_request() is what I mean here...
___
Users mailing list
U
Iñaki Baz Castillo wrote:
> Well, failure_route will not be called when receiving a 200 OK in this
> BYE transaction.
> failure_route is only invoked for [3456]XX responses. 200 can only be
> handled in on_reply_route, but I don't know if acc flag can be set in
> on_reply_route.
Ah, yeah, you're
2008/12/18 Andreas Granig :
>> Yes, but it doesn't explain how to do the accounting when receiving
>> the 200 OK for the BYE.
>>
>>
>
> Uh, well... register a new failure route and don't set the flag for
> automatic accounting when receiving the BYE, and in your failure route, do
> something like
>> On Monday 08 December 2008, Juan Asencio wrote:
>>> Thank you for your fast response. So after I compile them, the files
>>> carrierroute.so should appear on the directory of modules?
>>>
>>> Because I thought did it right, but I can't see the carrierroute.so
>>> anywhere. So I'm not sure if I d
Iñaki Baz Castillo wrote:
> 2008/12/18 Andreas Granig :
>> Iñaki Baz Castillo wrote:
Stop accounting:
1) On 200 OK (or maybe 481 or other response) from the gateway in
response to
a BYE.
2) On BYE from the gateway
>>> Is it feasible with the acc module? Can the acc be sto
2008/12/18 Andreas Granig :
> Iñaki Baz Castillo wrote:
>>>
>>> Stop accounting:
>>> 1) On 200 OK (or maybe 481 or other response) from the gateway in
>>> response to
>>> a BYE.
>>> 2) On BYE from the gateway
>>
>> Is it feasible with the acc module? Can the acc be stoped depending on
>> the respon
Iñaki Baz Castillo wrote:
>> Stop accounting:
>> 1) On 200 OK (or maybe 481 or other response) from the gateway in response to
>> a BYE.
>> 2) On BYE from the gateway
>
> Is it feasible with the acc module? Can the acc be stoped depending on
> the response? is it valid to set the acc flag in on_re
2008/12/18 Alex Hermann :
> On Thursday 18 December 2008, Iñaki Baz Castillo wrote:
>> Hi, first of all I'm sorry for this cross-posting, but I think it
>> could be interesting for any SIP proxy with accounting capabilities.
>
>> But I think this is too complex, isn't it?
> It is complex, but not i
> On Monday 08 December 2008, Juan Asencio wrote:
>> Thank you for your fast response. So after I compile them, the files
>> carrierroute.so should appear on the directory of modules?
>>
>> Because I thought did it right, but I can't see the carrierroute.so
>> anywhere. So I'm not sure if I did it
On Thursday 18 December 2008, Iñaki Baz Castillo wrote:
> Hi, first of all I'm sorry for this cross-posting, but I think it
> could be interesting for any SIP proxy with accounting capabilities.
> But I think this is too complex, isn't it?
It is complex, but not impossible.
I think is is feasabl
Hi,
For BYEs: when you process the INVITE you can add a special parameter to
record-route header that you will check in the route header of your BYE.
++ I tested this.
I am adding nat=yes in record-route when caller is detected behind NAT.
& When processing BYE , I checked whether nat=yes does ex
Hi, first of all I'm sorry for this cross-posting, but I think it
could be interesting for any SIP proxy with accounting capabilities.
I'm thinking in the following flow in which the caller/attacker would
get an unlimited call (but a limited CDR duration):
18/12/2008 в 11:31 +0100, BERGANZ François wrote:
> Can you explain me a little more please?
Well, I will try, but I not sure that I can ;-) Also, sory for my bad
english.
If I understand your task correctly (not sure) , in my point of view you
can make this service logic:
- user 1001 send initi
Hi,
In my openser, I had to not relay any provisional which is < 180.
I used drop in reply route to do this.
No provisional < 180 is sent to caller.
Unfortunately, dropping 100 seems to make the transaction module not
disarming its fr_timer.
The 180 has been waited for more time than my fr_timer
Hi,
in asterisk sip.conf file ...
[openser]
type = friend
host=ip_address_of_open
insecure = very
username=dummy_name
proxy= host
outbound_proxy=host
nat = yes;
canreinvnit =no;
And In Asterisk CTL > show sip peers
You will see the openser peer is registered
And See openSER debug whether Op
Can you explain me a little more please?
Cordialement,
BERGANZ François
http://www.acropolistelecom.net
Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.
-Message d'origine-
De : users-boun...@lists.kamailio.org [mailto:users-boun...@lists.kamailio.org]
De la part de
18/12/2008 в 11:14 +0100, BERGANZ François wrote:
> I want to authenticate in openser some users
OK, frontend will auth users - need some code in INVITE route in the
kamailio config.
> which are in asterisk conf (to do load balancing with another asterisk).
Also little code in kamailio config.
I want to authenticate in openser some users which are in asterisk conf (to do
load balancing with another asterisk).
If I delete the user from the asterisk config and insecure=invite for the
openser, asterisk accept the call, but, I want that asterisk see that it is
that user which is doing th
Message: 1
Date: Wed, 17 Dec 2008 16:29:56 +0200
From: TCB
Subject: [Kamailio-Users] serMyAdmin error
To: users
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
I'm trying to install serMyAdmin using a remote mysql DB. I keep getting
the
following error.
Caused by: org.sprin
-I have that error:
<--- SIP read from UDP://192.168.1.156:5060 --->
INVITE sip:33662971...@192.168.1.156 SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 192.168.1.156;branch=z9hG4bK20d2.de427962.0
Via: SIP/2.0/UDP
192.168.1.60:43490;branch=z9hG4bK-d8754z-c15d2350d0742a11-1---d8754z-;rport=43490
Ma
Thanks Henning,
> Carrierroute rewrites the R-URI because you normally want to route your
> message according them. So this is hardcoded in the logic of the module. The
> from uri user (like you've tried above) can be only used as the user part for
> the R-URI. Mangling your from uri is normall
Hello,
On 12/18/08 10:54, Krunal Patel wrote:
> Hi,
>
> Does anybody know how to detect whether use_media_proxy is called?
> What I want to do is:
> Do end_media_session for bye or cancel if & only if use_media_proxy
> has been called during invite or reply route.
>
> Is it possible?
for BYEs: wh
El Jueves, 18 de Diciembre de 2008 08:54, Krunal Patel escribió:
> Hi,
>
> Does anybody know how to detect whether use_media_proxy is called?
> What I want to do is:
> Do end_media_session for bye or cancel if & only if use_media_proxy has
> been called during invite or reply route.
>
> Is it possi
В Чтв, 18/12/2008 в 09:41 +0100, BERGANZ François пишет:
> Hello,
>
> I have :
>
> ASTERISK-OPENSER-SOFTPHONE
>
> My softphone auth to openser (with username/password of asterisk sync
> with a database…)
> Openser forward the INVITE to asterisk and asterisk return Unautorize!
> I trie
Hi,
Does anybody know how to detect whether use_media_proxy is called?
What I want to do is:
Do end_media_session for bye or cancel if & only if use_media_proxy has been
called during invite or reply route.
Is it possible?
If it is then please let me know how to implement it?
Thanks in advance
Hello,
I have :
ASTERISK-OPENSER-SOFTPHONE
My softphone auth to openser (with username/password of asterisk sync with a
database
)
Openser forward the INVITE to asterisk and asterisk return Unautorize!
I tried to have the same realm to try de have the same auth for asterisk
35 matches
Mail list logo
