opensips-cp CDR correlation

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

opensips-cp CDR correlation

Brett Nemeroff
At Bogdan's request, I checked out the stored proc for CDR Correlation in the opensips-cp project. 

I see the Invite cursor declared as:
  DECLARE inv_cursor CURSOR FOR SELECT time, callid, from_tag, to_tag FROM opensips.acc where method='INVITE' and cdr_id='0';

This seems like a problem to me.. Imagine a call with several invites in it (SST for example). It could pick up an INVITE in the middle of the call as the "initial invite" and then improperly account duration, etc. 

Furthermore picking the BYE:
SELECT 1, time INTO bye_record, v_bye_time FROM opensips.acc WHERE method='BYE' AND callid=v_callid AND ((from_tag=v_from_tag AND to_tag=v_to_tag) OR (from_tag=v_to_tag AND to_tag=v_from_tag)) ORDER BY time ASC LIMIT 1;

Shouldn't that ordering at the end be DESC instead of ASC.. point is, don't you want the absolute FIRST invite per callid and the absolute last BYE per callid? (sure there shouldn't be much after the FIRST BYE, but still..)

BTW, Please redirect me if it's not appropriate to ask opensips-cp questions here..

-Brett


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Bogdan-Andrei Iancu
Hi Brett,

Brett Nemeroff wrote:

> At Bogdan's request, I checked out the stored proc for CDR Correlation
> in the opensips-cp project.
>
> I see the Invite cursor declared as:
>   DECLARE inv_cursor CURSOR FOR SELECT time, callid, from_tag, to_tag
> FROM opensips.acc where method='INVITE' and cdr_id='0';
>
> This seems like a problem to me.. Imagine a call with several invites
> in it (SST for example). It could pick up an INVITE in the middle of
> the call as the "initial invite" and then improperly account duration,
> etc.
yes, actually when we wrote this procedure was on a platform where the
re-INVITEs were not accounted, so you got only original INVITEs. But for
your case, you can simply modify the cursor and add in the "where"
statement "and to_tag=NULL" - this will skip the re-INVITEs.

>
> Furthermore picking the BYE:
> SELECT 1, time INTO bye_record, v_bye_time FROM opensips.acc WHERE
> method='BYE' AND callid=v_callid AND ((from_tag=v_from_tag AND
> to_tag=v_to_tag) OR (from_tag=v_to_tag AND to_tag=v_from_tag)) ORDER
> BY time ASC LIMIT 1;
>
> Shouldn't that ordering at the end be DESC instead of ASC.. point is,
> don't you want the absolute FIRST invite per callid and the absolute
> last BYE per callid? (sure there shouldn't be much after the FIRST
> BYE, but still..)
but "ORDER BY time ASC" will take the BYE with the smallest timestamp ->
the first BYE received, which should be correct IMO, as the call will be
terminated by the first BYE....or I'm missing something in what you are
saying?
>
> BTW, Please redirect me if it's not appropriate to ask opensips-cp
> questions here..
so far, this is the right place :)

Regards,
Bogdan

>
> -Brett
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
El Miércoles, 29 de Abril de 2009, Bogdan-Andrei Iancu escribió:
> > Shouldn't that ordering at the end be DESC instead of ASC.. point is,
> > don't you want the absolute FIRST invite per callid and the absolute
> > last BYE per callid? (sure there shouldn't be much after the FIRST
> > BYE, but still..)
>
> but "ORDER BY time ASC" will take the BYE with the smallest timestamp ->
> the first BYE received, which should be correct IMO, as the call will be
> terminated by the first BYE....or I'm missing something in what you are
> saying?

Always I hear "billing in a proxy" I must to show an example attack:

Phone1            Proxy         Phone2

INVITE CSeq:1 -----> --------------->
<------------------- <-------- 200 OK
ACK CSeq:1 --------> --------------->

<################ RTP ##############>

BYE CSeq:1 --------> --------------->
              [ ACC DONE ]
<------------------- <-- 400 Bad CSeq

            ( audio remains )



For "fixing" this issue, the proxy could generate the accounting just after
receiving the 200 OK for a BYE. But then we can also play with an infinite
possibility of spoofed "Route"/"RURI" headers so the BYE is send and received
by the attacker itself, who replies 200 for the BYE (but it mantains the RTP
session with Phone2/Gateway.

--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Bogdan-Andrei Iancu
Hi Inaki,

Iñaki Baz Castillo wrote:

> El Miércoles, 29 de Abril de 2009, Bogdan-Andrei Iancu escribió:
>  
>>> Shouldn't that ordering at the end be DESC instead of ASC.. point is,
>>> don't you want the absolute FIRST invite per callid and the absolute
>>> last BYE per callid? (sure there shouldn't be much after the FIRST
>>> BYE, but still..)
>>>      
>> but "ORDER BY time ASC" will take the BYE with the smallest timestamp ->
>> the first BYE received, which should be correct IMO, as the call will be
>> terminated by the first BYE....or I'm missing something in what you are
>> saying?
>>    
>
> Always I hear "billing in a proxy" I must to show an example attack:
>
> Phone1            Proxy         Phone2
>
> INVITE CSeq:1 -----> --------------->
> <------------------- <-------- 200 OK
> ACK CSeq:1 --------> --------------->
>
> <################ RTP ##############>
>
> BYE CSeq:1 --------> --------------->
>               [ ACC DONE ]
> <------------------- <-- 400 Bad CSeq
>
>             ( audio remains )
>  
This is an old hot topic when comes to proxies (I noticed it poped again
on the sip-implementers list).

Of course your example is valid and can happen - but what people do not
understand is that not the proxy is doing billing!! the proxy is the one
just collecting information about SIP events...doing billing is the job
of some offline parties which analyses the acc data from proxy,
validates it and generates CDRs (billing stuff).

So a proxy may account several BYEs, but the CDR generator has the duty
in picking the right one - like searching for the first 200OK BYE, if
not, picking the first non-200OK with a reply code that does not
indicate a malformed BYE ( parsing, transaction, etc)..

>
>
> For "fixing" this issue, the proxy could generate the accounting just after
> receiving the 200 OK for a BYE.

I can give you another example, similar to yours where the BYE is valid,
but you get an 408 timeout on server because the P2 is dead. So, that
BYE+408 is a valid one -> what I'm saying is that accounting just after
the BYE+200OK is not valid all the time.
> But then we can also play with an infinite
> possibility of spoofed "Route"/"RURI" headers so the BYE is send and received
> by the attacker itself, who replies 200 for the BYE (but it mantains the RTP
> session with Phone2/Gateway.
>  
Yes, it is possible.

For this a proxy, using dialog info, can check the validity of the BYE
requests (both the inbound and outbound leg) to see if it matches (not
as SIP dialog, but as SIP route path also) the INVITE request.
For this, I have under devel such a function in the dialog module - to
check the correctness of the sequential requests...


Also, media traffic (even if put a lot of load on the system) may offers
valid information to be used and aggregated with the SIP acc info.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
2009/4/29 Bogdan-Andrei Iancu <[hidden email]>:
> This is an old hot topic when comes to proxies (I noticed it poped again on
> the sip-implementers list).

Yes XD


> Of course your example is valid and can happen - but what people do not
> understand is that not the proxy is doing billing!! the proxy is the one
> just collecting information about SIP events...doing billing is the job of
> some offline parties which analyses the acc data from proxy, validates it
> and generates CDRs (billing stuff).

Ok


>> For "fixing" this issue, the proxy could generate the accounting just
>> after receiving the 200 OK for a BYE.
>
> I can give you another example, similar to yours where the BYE is valid, but
> you get an 408 timeout on server because the P2 is dead. So, that BYE+408 is
> a valid one -> what I'm saying is that accounting just after the BYE+200OK
> is not valid all the time.

Good example.


Regards and thanks for your comments.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Dan Pascu
In reply to this post by Iñaki Baz Castillo
On Wednesday 29 April 2009, Iñaki Baz Castillo wrote:
> Always I hear "billing in a proxy" I must to show an example attack:
>
> Phone1 Proxy Phone2
>
> INVITE CSeq:1 -----> --------------->
> <------------------- <-------- 200 OK
> ACK CSeq:1 --------> --------------->
>
> <################ RTP ##############>
>
> BYE CSeq:1 --------> --------------->
> [ ACC DONE ]
> <------------------- <-- 400 Bad CSeq
>
> ( audio remains )
>
>
>
> For "fixing" this issue, the proxy could generate the accounting just
> after receiving the 200 OK for a BYE. But then we can also play with an
> infinite possibility of spoofed "Route"/"RURI" headers so the BYE is
> send and received by the attacker itself, who replies 200 for the BYE
> (but it mantains the RTP session with Phone2/Gateway.


You can always put a media relay in the media path, which means that when a BYE is received the media path is interrupted, making any Route/RURI scheme pointless.


--
Dan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu
On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
<[hidden email]> wrote:
> So a proxy may account several BYEs, but the CDR generator has the duty
> in picking the right one - like searching for the first 200OK BYE, if
> not, picking the first non-200OK with a reply code that does not
> indicate a malformed BYE ( parsing, transaction, etc)..

Soooo.. Any chance of updating the SP for opensips-cp to do this? :)
Can I just look for an ACC event where method='BYE' sip_code = 200 and
((from_tag=v_from_tag and to_tag=v_to_tag) or (from_tag=v_to_tag and
to_tag=v_from_tag))

I'm looking for "Smarter, but not perfect" for now. :)
-Brett

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Bogdan-Andrei Iancu
Brett Nemeroff wrote:

> On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>  
>> So a proxy may account several BYEs, but the CDR generator has the duty
>> in picking the right one - like searching for the first 200OK BYE, if
>> not, picking the first non-200OK with a reply code that does not
>> indicate a malformed BYE ( parsing, transaction, etc)..
>>    
>
> Soooo.. Any chance of updating the SP for opensips-cp to do this? :)
> Can I just look for an ACC event where method='BYE' sip_code = 200 and
> ((from_tag=v_from_tag and to_tag=v_to_tag) or (from_tag=v_to_tag and
> to_tag=v_from_tag))
>  
this is not correct - see the example with 408 I gave to Inaki. It is
not so simple to disregard the non-200 OK - you need to look at them if
no 200 OK is present.

So, you should have BYEs sorted by reply_code (ASC) and if more with the
same code, by time :D...Or do 2 selects: first for 200 replies (order by
time) and if no result, for non-200 (also ordered by time)

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
In reply to this post by Dan Pascu
2009/4/29 Dan Pascu <[hidden email]>:
> You can always put a media relay in the media path, which means that when a
> BYE is received the media path is interrupted, making any Route/RURI scheme
> pointless.

Sure, but forcing the media through a media proxy is not the "magic"
solution for all the scenarios.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Bogdan-Andrei Iancu
I think (even if I do not like it) it is....more or less the media flow
is the only continuously flowing traffic that may indicate if a call is
still going through or not. Signalling traffic is sporadic and
non-continuous, so not good for testing the state of the call.

Not only it is accurate, but also you can avoid cheating (with fake BYEs
or whatever), because you may bill the RTP session duration and not the
SIP session duration ;).

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> 2009/4/29 Dan Pascu <[hidden email]>:
>  
>> You can always put a media relay in the media path, which means that when a
>> BYE is received the media path is interrupted, making any Route/RURI scheme
>> pointless.
>>    
>
> Sure, but forcing the media through a media proxy is not the "magic"
> solution for all the scenarios.
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Adrian Georgescu
In reply to this post by Iñaki Baz Castillo

On Apr 29, 2009, at 3:42 PM, Iñaki Baz Castillo wrote:

2009/4/29 Dan Pascu <[hidden email]>:
You can always put a media relay in the media path, which means that when a
BYE is received the media path is interrupted, making any Route/RURI scheme
pointless.

Sure, but forcing the media through a media proxy is not the "magic"
solution for all the scenarios.


Inaki,

Just for clarity, do you mean that is not a solution for which case:

A) All scenarios that do use MP or
B) When you do not want to use MP explicitly

The distinction is important because in the first case it could be a bug (please report it) that could eventually be fixed when it does not work properly and in the later is a topology setup decision.

Adrian


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu
Don't I basically just want to know if the last reply for method='BYE' is 200?

ie: if the BYE gets replied with a 200, but THEN a 408 or.. well any
>=400 code arrives, then disregard the BYE ?

Tricky...

Is it not possible to have the dialog module trigger an ACC event when
the dialog is destroyed after being in an up state? Like a stop event?



On Wed, Apr 29, 2009 at 8:40 AM, Bogdan-Andrei Iancu
<[hidden email]> wrote:

> Brett Nemeroff wrote:
>>
>> On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
>> <[hidden email]> wrote:
>>
>>>
>>> So a proxy may account several BYEs, but the CDR generator has the duty
>>> in picking the right one - like searching for the first 200OK BYE, if
>>> not, picking the first non-200OK with a reply code that does not
>>> indicate a malformed BYE ( parsing, transaction, etc)..
>>>
>>
>> Soooo.. Any chance of updating the SP for opensips-cp to do this? :)
>> Can I just look for an ACC event where method='BYE' sip_code = 200 and
>> ((from_tag=v_from_tag and to_tag=v_to_tag) or (from_tag=v_to_tag and
>> to_tag=v_from_tag))
>>
>
> this is not correct - see the example with 408 I gave to Inaki. It is not so
> simple to disregard the non-200 OK - you need to look at them if no 200 OK
> is present.
>
> So, you should have BYEs sorted by reply_code (ASC) and if more with the
> same code, by time :D...Or do 2 selects: first for 200 replies (order by
> time) and if no result, for non-200 (also ordered by time)
>
> Regards,
> Bogdan
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
In reply to this post by Adrian Georgescu
2009/4/29 Adrian Georgescu <[hidden email]>:
>
> On Apr 29, 2009, at 3:42 PM, Iñaki Baz Castillo wrote:

> Sure, but forcing the media through a media proxy is not the "magic"
> solution for all the scenarios.
>
>
> Inaki,
> Just for clarity, do you mean that is not a solution for which case:
> A) All scenarios that do use MP or
> B) When you do not want to use MP explicitly
> The distinction is important because in the first case it could be a bug
> (please report it) that could eventually be fixed when it does not work
> properly and in the later is a topology setup decision.

I mean B) case  :)

Let me explain an example:

- Two users with STUN or public IP so no media-proxy is required in
order to get audio properly.
- But me (the provider) want to account a call between them (perhaps
not for billing, but for any other reason).

Solutions for *secure* accounting:

a) Use of a media-proxy (but this requires a media-proxy... and I
don't want it since it's not needed for getting audio).

b) One of both phones use SessionTimer (this depends on the clients,
obviously not a "secure" solution for me).

c) Me (the provider) use a transparent B2BUA in the middle of the call
so the B2BUA forces SessionTimers for leg_A (phone 1) and leg_B (phone
2).

Option c) ensures, just with SIP signalling, that the accounting is
accurate without the need of a media-proxy (which could add delay and
consumes *my* network resources).



--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Adrian Georgescu
> Let me explain an example:
>
> - Two users with STUN or public IP so no media-proxy is required in
> order to get audio properly.
> - But me (the provider) want to account a call between them (perhaps
> not for billing, but for any other reason).
>
> Solutions for *secure* accounting:
>
> a) Use of a media-proxy (but this requires a media-proxy... and I
> don't want it since it's not needed for getting audio).
>
> b) One of both phones use SessionTimer (this depends on the clients,
> obviously not a "secure" solution for me).
>
> c) Me (the provider) use a transparent B2BUA in the middle of the call
> so the B2BUA forces SessionTimers for leg_A (phone 1) and leg_B (phone
> 2).
>
> Option c) ensures, just with SIP signalling, that the accounting is
> accurate without the need of a media-proxy (which could add delay and
> consumes *my* network resources).

What you describe can work technically but seem to require cooperation  
from the end-points. Is the goal to have reliable accounting for when  
the network has problems or when the users miss-behave?

Adrian


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
2009/4/29 Adrian Georgescu <[hidden email]>:

> What you describe can work technically but seem to require cooperation from
> the end-points.

No, SessionTimers just requieres one endpoint supporting them. In the
case I described, the B2BUA (acting as UAS for phone 1 and UAC for
phone 2) does support SessionTimers so can monitorize the dialog
status in both legs.


> Is the goal to have reliable accounting for when the network
> has problems or when the users miss-behave?

Imagine a company using a hosted virtual PBX solution (the
proxy/SA/B2BUA has public IP while the phones are behind NAT).
Imagine the boss wishing to have an accurated log (cdr) of how long
his employers are speaking between them. These calls take place,
probably, into the same LAN so a media-proxy is not required to allow
bidirectional audio. Also, forcing a media-proxy could consume high
bandwitch and create audio delay. It shouldn't be required just to get
accurate accounting.

Best regards.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Bogdan-Andrei Iancu
In reply to this post by Brett Nemeroff
Which may be or not - your query does not cover the "not" case :)

Regards,
Bogdan

Brett Nemeroff wrote:

> Don't I basically just want to know if the last reply for method='BYE' is 200?
>
> ie: if the BYE gets replied with a 200, but THEN a 408 or.. well any
>  
>> =400 code arrives, then disregard the BYE ?
>>    
>
> Tricky...
>
> Is it not possible to have the dialog module trigger an ACC event when
> the dialog is destroyed after being in an up state? Like a stop event?
>
>
>
> On Wed, Apr 29, 2009 at 8:40 AM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>  
>> Brett Nemeroff wrote:
>>    
>>> On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
>>> <[hidden email]> wrote:
>>>
>>>      
>>>> So a proxy may account several BYEs, but the CDR generator has the duty
>>>> in picking the right one - like searching for the first 200OK BYE, if
>>>> not, picking the first non-200OK with a reply code that does not
>>>> indicate a malformed BYE ( parsing, transaction, etc)..
>>>>
>>>>        
>>> Soooo.. Any chance of updating the SP for opensips-cp to do this? :)
>>> Can I just look for an ACC event where method='BYE' sip_code = 200 and
>>> ((from_tag=v_from_tag and to_tag=v_to_tag) or (from_tag=v_to_tag and
>>> to_tag=v_from_tag))
>>>
>>>      
>> this is not correct - see the example with 408 I gave to Inaki. It is not so
>> simple to disregard the non-200 OK - you need to look at them if no 200 OK
>> is present.
>>
>> So, you should have BYEs sorted by reply_code (ASC) and if more with the
>> same code, by time :D...Or do 2 selects: first for 200 replies (order by
>> time) and if no result, for non-200 (also ordered by time)
>>
>> Regards,
>> Bogdan
>>
>>    
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Dan Pascu
In reply to this post by Iñaki Baz Castillo
On Wednesday 29 April 2009, Iñaki Baz Castillo wrote:
> No, SessionTimers just requieres one endpoint supporting them. In the
> case I described, the B2BUA (acting as UAS for phone 1 and UAC for
> phone 2) does support SessionTimers so can monitorize the dialog
> status in both legs.


You realize that a B2BUA completely separates the 2 call legs, which includes audio. If you only attempt to split the signaling path, but leave the media path to flow directly, you may have trouble with NAT. So if you replace a media relay with a B2BUA which does media transcoding, I do not believe you are any better.


> Imagine a company using a hosted virtual PBX solution (the
> proxy/SA/B2BUA has public IP while the phones are behind NAT).
> Imagine the boss wishing to have an accurated log (cdr) of how long
> his employers are speaking between them. These calls take place,
> probably, into the same LAN so a media-proxy is not required to allow
> bidirectional audio.


It may not be required, but it can be used to get some additional benefits, even more in this particular example, considering that LAN traffic is cheap.


> Also, forcing a media-proxy could consume high bandwitch and create
> audio delay.


This is actually incorrect. A media relay should be positioned next to the PSTN gateway, so that the network will not see more traffic than it would have seen if the media streams would have reached the gateway directly.


> It shouldn't be required just to get accurate accounting.


I do not recall anyone making such a statement. Using a media relay is just one solution to avoid issues with signaling or problems caused by malicious user activity. You're free to consider it or not.


All your examples where the system could be circumvented are based on the fact that someone was attempting to fool the SIP proxy to consider the session has ended by transmitting doctored SIP messages, while at the same time trying to preserve the media stream and keep talking. If any attempt to terminate the SIP signaling will also terminate the media, the users will have no incentive to try to circumvent the SIP signaling, because they will be left without the desired fruit of their work (the free media stream). Like it or not, what defines a voice call is the presence of an active media stream, not some sporadic circumventable SIP signaling. A user can try to fool the later, but cannot have a call without the former.


A smart entrepreneur, will attempt to take away the incentive to circumvent the system, like for example using a flat fee billing scheme. That is a much desirable and cheaper thing to do, than to attempt to put layer after layer of protection that will be ultimately circumvented sooner or later anyway. If one keeps promoting a model based on scarcity and high prices, the incentive to hack the system will always be there.


--
Dan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
El Miércoles, 29 de Abril de 2009, Dan Pascu escribió:

> You realize that a B2BUA completely separates the 2 call legs, which
> includes audio.

I mean "SIP transparent B2BUA" which doesn't handle media and doesn't touch
the SDP at all.


> If you only attempt to split the signaling path, but leave
> the media path to flow directly, you may have trouble with NAT.

For that I have a proxy calling a media-proxy when needed, but if both users
are behind the same NATm using the media-proxy is not required (and this is
the example I described).


> So if you
> replace a media relay with a B2BUA which does media transcoding, I do not
> believe you are any better.

I've never told about B2BUA with media transcoding.


> > Imagine a company using a hosted virtual PBX solution (the
> > proxy/SA/B2BUA has public IP while the phones are behind NAT).
> > Imagine the boss wishing to have an accurated log (cdr) of how long
> > his employers are speaking between them. These calls take place,
> > probably, into the same LAN so a media-proxy is not required to allow
> > bidirectional audio.
>
> It may not be required, but it can be used to get some additional
> benefits, even more in this particular example, considering that LAN
> traffic is cheap.

LAN traffic is cheap? perhaps I should describe again the scenario I
described:

A company using a *hosted* virtual proxy/PBX service. The provider (the
proxy/B2BUA is in some datacenter while the phones are in the company office
behind a NAT router). There is no media-proxy in the LAN. If you force a
media-proxy it should take place out of the office (so comsuming
ADSL/SHDSL/... bandwith).


> > Also, forcing a media-proxy could consume high bandwitch and create
> > audio delay.
>
> This is actually incorrect. A media relay should be positioned next to the
> PSTN gateway, so that the network will not see more traffic than it would
> have seen if the media streams would have reached the gateway directly.

In my example, I clearly spoke about a conversation between two phones in the
LAN.
With your suggestion (using a media-proxy to ensure the accounting
reliability) the audio would go and back to the provider datacenter (in which
the media-proxy resides).


Regards.



--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Dan Pascu
On Wednesday 29 April 2009, Iñaki Baz Castillo wrote:
> LAN traffic is cheap? perhaps I should describe again the scenario I
> described:
>
> A company using a *hosted* virtual proxy/PBX service. The provider (the
> proxy/B2BUA is in some datacenter while the phones are in the company
office
> behind a NAT router). There is no media-proxy in the LAN. If you force a
> media-proxy it should take place out of the office (so comsuming
> ADSL/SHDSL/... bandwith).

There's a saying that all good things in life are illegal, immoral or make
you fat ;)

It's a tradeoff. If you are not willing to make it, then don't. Find
another way to solve your problem. I'm sorry if you got the impression I
was trying to convince you of anything...

> In my example, I clearly spoke about a conversation between two phones
> in the  LAN.
> With your suggestion (using a media-proxy to ensure the accounting
> reliability) the audio would go and back to the provider datacenter (in
> which the media-proxy resides).

My bad. I was under the impression that we are discussing ways to prevent
a user from hacking a system and getting calls which are free of charge.
In my (limited) knowledge, this only applies to PSTN calls (which have a
fee). Maybe you care to elaborate why do you care for accounting for free
(as in no fee involved) SIP to SIP calls or why would a user be interested
in hijacking a SIP to SIP call that is free of charge?

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: opensips-cp CDR correlation

Iñaki Baz Castillo
El Miércoles, 29 de Abril de 2009, Dan Pascu escribió:

> My bad. I was under the impression that we are discussing ways to prevent
> a user from hacking a system and getting calls which are free of charge.
> In my (limited) knowledge, this only applies to PSTN calls (which have a
> fee). Maybe you care to elaborate why do you care for accounting for free
> (as in no fee involved) SIP to SIP calls or why would a user be interested
> in hijacking a SIP to SIP call that is free of charge?

Again my example:

------------
Imagine a company using a hosted virtual PBX solution (the
proxy/SA/B2BUA has public IP while the phones are behind NAT).
Imagine the boss wishing to have an accurated log (cdr) of how long
his employers are speaking between them.
------------

I can sure that I do have those kind of clients (or really worse XDDD)


--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
123