El Jueves, 30 de Abril de 2009, Dan Pascu escribió:
> I said that to highlight that with media sessions in the range of
> hundreds, it loads the machine so little that it doesn't show, so it can
> be installed on the sip proxy machine without affecting it. Geez.
>
> So you concluded that if it can
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> > 2. It needs a specialized B2BUA box with custom logic.
>
> Why couldn't it be integrated in the same proxy box? or why couldn't
> it replace the proxy?
It could. But can it support the same load as the proxy, so it can be used
as a replace
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> 2009/4/30 Dan Pascu :
>
> > With 20 media relays I expect to drive 6+ simultaneous sessions.
Why
> > do you estimate you need that many, when I can drive thousands of
sessions
> > with a single machine and max out the network bandwidth m
2009/4/30 Dan Pascu :
> On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
>> 2009/4/30 kokoska rokoska :
>> > FYI - we are relaying more than 1000 RTP sessions with one server (2x
>> > QuadCore) using RTPproxy (packets goes to user space) without visible
>> > load on the server. It is almost idl
2009/4/30 Dan Pascu :
> With 20 media relays I expect to drive 6+ simultaneous sessions. Why
> do you estimate you need that many, when I can drive thousands of sessions
> with a single machine and max out the network bandwidth much sooner than
> maxing out the CPU of that machine?
You said:
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> 2009/4/30 kokoska rokoska :
> > FYI - we are relaying more than 1000 RTP sessions with one server (2x
> > QuadCore) using RTPproxy (packets goes to user space) without visible
> > load on the server. It is almost idle.
> > So I expect "kernel"
2009/4/30 Dan Pascu :
> The B2BUA based solution:
>
> 1. It generates the same amount of media traffic from the network.
Just in the case of calls to a PSTN gw (ok, this is what we are speaking about).
> 2. It needs a specialized B2BUA box with custom logic.
Why couldn't it be integrated in the
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> 2009/4/30 Dan Pascu :
> > Continuing to debate this in pointless. I already showed you that a
> > solution based on a media relay can be made as cheap as the B2BUA
based
> > solution that you promote, while being much more accurate.
>
> 1 med
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> Dan, I'm not trying to say which option is better. I just mean that
> doing media-relaying is not the *only* or better solution for all the
> cases.
Nobody ever claimed such a thing. I thought the point was to offer
alternatives and let the u
2009/4/30 kokoska rokoska :
> FYI - we are relaying more than 1000 RTP sessions with one server (2x
> QuadCore) using RTPproxy (packets goes to user space) without visible
> load on the server. It is almost idle.
> So I expect "kernel" (i.e. media-proxy) could go even far-far away :-)
That's reall
Iñaki Baz Castillo napsal(a):
> 2009/4/30 Dan Pascu :
>> Continuing to debate this in pointless. I already showed you that a
>> solution based on a media relay can be made as cheap as the B2BUA based
>> solution that you promote, while being much more accurate.
>
> 1 media-proxy => 100 R
2009/4/30 Dan Pascu :
> Continuing to debate this in pointless. I already showed you that a
> solution based on a media relay can be made as cheap as the B2BUA based
> solution that you promote, while being much more accurate.
1 media-proxy => 100 RTP sessions (100 calls)
X media-proxy =>
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> No, a proxy is fully vulnerable to a spoofed BYE, why? because the
> proxy MUST route the BYE according to RURI, Route headers..., while a
> B2BUA doesn't route it, just "eats" it and generate a new one in leg
> B.
I think we already agreed th
2009/4/30 Dan Pascu :
> I don't think you would. Mediaproxy will most likely max out your network
> capacity before needing another server (at least with the right hardware).
>
> Also you seem to forget that your "cheaper" solution still needs an extra
> box as well (the B2BUA). Unless by cheap yo
2009/4/30 Adrian Georgescu :
> > No, a proxy is fully vulnerable to a spoofed BYE, why? because the
> > proxy MUST route the BYE according to RURI, Route headers..., while a
> > B2BUA doesn't route it, just "eats" it and generate a new one in leg
>
> As far as I know with OpenSIPS you could chose,
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> >> Also, for calls to a gateway in our same datacenter, forcing the RTP
> >> through a media-proxy is not the only solution. Using SessionTimers
> >> (so a B2BUA is required and not just a proxy) is also a good solution
> >> (and cheaper since
On Apr 30, 2009, at 1:49 PM, Iñaki Baz Castillo wrote:
2009/4/30 Adrian Georgescu :
You can use the dialog module to do the same and generate your own
correct
BYEs instead of relaying them, couldn't you?
You have full control over the reply route and can do all you
describe in
the proxy
2009/4/30 Adrian Georgescu :
> You can use the dialog module to do the same and generate your own correct
> BYEs instead of relaying them, couldn't you?
>
> You have full control over the reply route and can do all you describe in
> the proxy, can't you?
>
> What can a B2BUA detect that the proxy
On Apr 30, 2009, at 12:28 PM, Iñaki Baz Castillo wrote:
2009/4/30 Adrian Georgescu :
The more load you have at some moment in time you need to add more
servers.
The curent design allows MP2 to handle several thousands of
simultaneous
sessions. Anyway, far from trying to advocate its load ca
2009/4/30 Adrian Georgescu :
> The more load you have at some moment in time you need to add more servers.
> The curent design allows MP2 to handle several thousands of simultaneous
> sessions. Anyway, far from trying to advocate its load capabilities the
> question we all try to find the answer fo
>> No _new_ servers are needed, as in you can
>> reuse any existing server for this purpose. Nowadays mediaproxy is
>> very
>> efficient because it uses conntrack rules in the kernel to forward
>> the
>> packets. It does forward hundreds of media streams with virtually
>> no load
>> on the CP
2009/4/30 Dan Pascu :
> On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
>> Yes, I agree on it. However I just wanted to mean that using a
>> media-proxy is not the best solution for all the cases, specially when
>> clients are behind same NAT (an office for example) and the PBX/Proxy
>> is hos
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> Yes, I agree on it. However I just wanted to mean that using a
> media-proxy is not the best solution for all the cases, specially when
> clients are behind same NAT (an office for example) and the PBX/Proxy
> is hosted in some datacenter.
The
2009/4/30 Bogdan-Andrei Iancu :
>> Yes, I agree on it. However I just wanted to mean that using a
>> media-proxy is not the best solution for all the cases, specially when
>> clients are behind same NAT (an office for example)
>
> from the open internet, you cannot tell (100% sure) if two devices a
Hi Inaki,
Some inline notes :) :
Iñaki Baz Castillo wrote:
> 2009/4/30 Dan Pascu :
>
>> I'm sure there is this kind (and unfortunately not in short supply), but
>> you do realize that if some employee has a expertise to hack a SIP device
>> to send abnormal BYE requests that attempt to fake th
2009/4/30 Dan Pascu :
> I'm sure there is this kind (and unfortunately not in short supply), but
> you do realize that if some employee has a expertise to hack a SIP device
> to send abnormal BYE requests that attempt to fake the closing of the SIP
> session while preventing the media from closing,
On Thursday 30 April 2009, Iñaki Baz Castillo wrote:
> 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
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
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
>
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 lea
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 t
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 disrega
2009/4/29 Adrian Georgescu :
> 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
> 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
2009/4/29 Adrian Georgescu :
>
> 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 th
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 destroye
On Apr 29, 2009, at 3:42 PM, Iñaki Baz Castillo wrote:
2009/4/29 Dan Pascu :
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 prox
I think (even if I do not like it) it ismore 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,
2009/4/29 Dan Pascu :
> 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.
--
Brett Nemeroff wrote:
> On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
> 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
On Wed, Apr 29, 2009 at 3:06 AM, Bogdan-Andrei Iancu
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 BY
On Wednesday 29 April 2009, Iñaki Baz Castillo wrote:
> Always I hear "billing in a proxy" I must to show an example attack:
>
> Phone1Proxy Phone2
>
> INVITE CSeq:1 -> --->
> <--- < 200 OK
> ACK CSeq:1 > --->
>
> <
2009/4/29 Bogdan-Andrei Iancu :
> 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
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 should
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 sti
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 c
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.. Im
47 matches
Mail list logo
