Posted: Thu Apr 23, 2009 6:29 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
23 apr 2009 kl. 09.01 skrev Venefax:
Quote:
I wonder what would it take so we in Asterisk can guarantee that RTP
flows
outside in a SIP-to-SIP call. I mean, if the codecs are the same,
how can we
be sure that there will never be a packet-to-packet bridging or
anything
else like that. If we did this, then Openser would be irrelevant.
Any ideas?
The behaviour today is not random. If you configure properly, Asterisk
won't
be involved in the call.
As a side note: The directrtp= option only works if you have complete
control
of codecs on the answering end. If not, it will fail miserably, and
that's the
reason it's still marked experimental.
But you still have to remember that Asterisk still allocates much more
resources
for each call, as Asterisk is a call stateful PBX, compared with a
transaction
stateful SIP proxy. The SIP proxy will always be faster and more
lightweight,
unless you add a lot of call stateful functionality to it.
Personally, I don't see why you want to make one piece of software into
a different piece of software. OpenSER/Kamailio has one role in the
SIP network, Asterisk a very different role and they work well together.
/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 6:40 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Olle E. Johansson wrote:
Quote:
The SIP proxy will always be faster and more
lightweight,
unless you add a lot of call stateful functionality to it.
Personally, I don't see why you want to make one piece of software into
a different piece of software. OpenSER/Kamailio has one role in the
SIP network, Asterisk a very different role and they work well together.
I would second that, and imagine that the difference in the resources
Asterisk allocates to a call is far greater than just dialog statekeeping.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 6:47 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
I think that in my company and in many companies, if we could use Asterisk
the way Openser works, we would save tons of money in training and learning
curve. Human talent is far more expensive than iron. I wonder why we cannot
change Asterisk a little so directrpt=yes does in fact work.
-----Original Message-----
From: asterisk-dev-bounces@lists.digium.com
[mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Alex Balashov
Sent: Thursday, April 23, 2009 3:32 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Avoiding RTP flows (new topic)
Olle E. Johansson wrote:
Quote:
The SIP proxy will always be faster and more
lightweight,
unless you add a lot of call stateful functionality to it.
Personally, I don't see why you want to make one piece of software into
a different piece of software. OpenSER/Kamailio has one role in the
SIP network, Asterisk a very different role and they work well together.
I would second that, and imagine that the difference in the resources
Asterisk allocates to a call is far greater than just dialog statekeeping.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 6:49 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
23 apr 2009 kl. 09.37 skrev Venefax:
Quote:
I think that in my company and in many companies, if we could use
Asterisk
the way Openser works, we would save tons of money in training and
learning
curve. Human talent is far more expensive than iron. I wonder why we
cannot
change Asterisk a little so directrpt=yes does in fact work.
Believe me, if that was a small change, we would have fixed it years
ago when
Mark introduced this code.
There are multiple proposals up for improving the media negotiation in
Asterisk
and we've spent quite a lot of time discussing this on the mailing
list and
during asterisk developer meetings. The videocaps branch has been around
for many years now, which is one of the proposals for improved media
negotiation, even though it's not focusing on the directrtp issue,
it's one way
of solving it.
/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 7:01 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Asterisk *cannot* *work* the way that a *proxy* works.
It is not a proxy. The difference here is an essential, a conceptual
one that translates into the very basis of the respective programmatic
architectures and runtime characteristics.
Asterisk can be optimised. It can't be ontologically redefined.
Venefax wrote:
Quote:
I think that in my company and in many companies, if we could use Asterisk
the way Openser works, we would save tons of money in training and learning
curve. Human talent is far more expensive than iron. I wonder why we cannot
change Asterisk a little so directrpt=yes does in fact work.
-----Original Message-----
From: asterisk-dev-bounces@lists.digium.com
[mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Alex Balashov
Sent: Thursday, April 23, 2009 3:32 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Avoiding RTP flows (new topic)
Olle E. Johansson wrote:
> The SIP proxy will always be faster and more
> lightweight,
> unless you add a lot of call stateful functionality to it.
>There are multiple proposals up for improving the media negotiation in
Asterisk
and we've spent quite a lot of time discussing this on the mailing
list and
during asterisk developer meetings. The videocaps branch has been around
for many years now, which is one of the proposals for improved media
negotiation, even though it's not focusing on the directrtp issue,
it's one way
of solving it.
Quote:
> Personally, I don't see why you want to make one piece of software into
> a different piece of software. OpenSER/Kamailio has one role in the
> SIP network, Asterisk a very different role and they work well together.
I would second that, and imagine that the difference in the resources
Asterisk allocates to a call is far greater than just dialog statekeeping.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 7:14 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Let me be a little clearer:
Sure, you can get Asterisk out of the media path by just passing through
the SDP in such a way that an RTP session is set up between the two
endpoints without involving it at all. That's all good and fine, and
well within the capacity of what is then effectively a signaling-only
[SIP] B2BUA to do. If you want to do this with a B2BUA instead of a
proxy, you can already do that with something like Yate.
What you can't do with Asterisk is defy the fundamental purpose of its
architecture: it's a PBX. It is designed as a media endpoint and has a
heavyweight event loop with a lot of different processes and threads
being invoked in order to provide a relatively high-level application
environment. You will not get the kind of switching setup capacity and
integration paths with Asterisk that you can get with a proxy dedicated
solely for that purpose and requiring no bridging of diverse call legs.
Besides that, the integration paths and interfaces offered by the
OpenSER technology stack are designed on a correspondingly low level of
abstraction that is commensurate with the one on which the proxy
operates - it provides a relatively thin layer of (transactional)
insulation from the underlying application-layer protocol's mechanics.
So, what you're asking is not possible not so much because someone is
myopic and can't wrap their head around the possibility of passing
through media without p2p bridging or re-INVITEs, but rather because
you're conflating concepts. It's like asking to put the milk back in
the cow.
Venefax wrote:
Quote:
I think that in my company and in many companies, if we could use Asterisk
the way Openser works, we would save tons of money in training and learning
curve. Human talent is far more expensive than iron. I wonder why we cannot
change Asterisk a little so directrpt=yes does in fact work.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 7:16 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
I have complete control over the codecs. For a second leg of the call, I
only offer the same codec negotiated in the inbound leg. So maybe
directrtp=yes is actually working in my application. Today I had 300 open
calls and 20 calls per second, and the processor never went over 20%. The
question is, how do I know for sure how is the media being handled. Is there
any way to positively detect that?
F.Alves
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 7:45 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
23 apr 2009 kl. 10.03 skrev Venefax:
Quote:
I have complete control over the codecs. For a second leg of the
call, I
only offer the same codec negotiated in the inbound leg. So maybe
directrtp=yes is actually working in my application. Today I had 300
open
calls and 20 calls per second, and the processor never went over
20%. The
question is, how do I know for sure how is the media being handled.
Is there
any way to positively detect that?
F.Alves
Well, now this is a question for asterisk-users ;-)
Try "rtp debug" in the cli.
/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 8:30 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Venefax schrieb:
Quote:
I have complete control over the codecs. For a second leg of the call, I
only offer the same codec negotiated in the inbound leg. So maybe
directrtp=yes is actually working in my application. Today I had 300 open
calls and 20 calls per second, and the processor never went over 20%. The
question is, how do I know for sure how is the media being handled. Is there
any way to positively detect that?
Take a look at the incoming/outgoing SDP.
Use tcpdump/wireshark
klaus
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 10:37 am Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Alex Balashov <abalashov@evaristesys.com> writes:
Quote:
Asterisk *cannot* *work* the way that a *proxy* works.
It is not a proxy. The difference here is an essential, a conceptual
one that translates into the very basis of the respective programmatic
architectures and runtime characteristics.
Asterisk can be optimised. It can't be ontologically redefined.
I must admit I don't really see the point of SIP proxies. They can be
used for authentication, but Asterisk is doing ok at authentication.
A HTTP proxy gives you NAT-traversal and caching; it primarily helps the
media get through efficiently. What good is a SIP proxy?
/Benny
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 2:03 pm Post subject: [asterisk-dev] Avoiding RTP flows (new topic)
Benny Amorsen wrote:
Quote:
Alex Balashov <abalashov@evaristesys.com> writes:
> Asterisk *cannot* *work* the way that a *proxy* works.
>
> It is not a proxy. The difference here is an essential, a conceptual
> one that translates into the very basis of the respective programmatic
> architectures and runtime characteristics.
>
> Asterisk can be optimised. It can't be ontologically redefined.
I must admit I don't really see the point of SIP proxies. They can be
used for authentication, but Asterisk is doing ok at authentication.
A HTTP proxy gives you NAT-traversal and caching; it primarily helps the
media get through efficiently. What good is a SIP proxy?
A SIP proxy can do that too.
I suppose that apart from being an intelligent routing decision point,
there aren't that many uses for pure proxy elements, but the thing is
that almost none of them are. They have some UAS capabilities as well.
OpenSER is certainly quite heavy on that.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum