[Kamailio-Users] re-invite mid call?

[Antonio Goméz Soto]

Hi,

maybe I should go to the -dev list for this, but thought I'd ask here first.
Is it possible to let openSER send a SIP reinvite in the middle of a call,
to redirect the sound stream to some rtpproxy? Maybe using the MI?

Or should OpenSER be modified to do this?

Thanks,
Antonio

[Alex Balashov]

No. It's a proxy, it can't originate requests.

Post by Antonio Goméz Soto
Hi,
maybe I should go to the -dev list for this, but thought I'd ask here first.
Is it possible to let openSER send a SIP reinvite in the middle of a call,
to redirect the sound stream to some rtpproxy? Maybe using the MI?
Or should OpenSER be modified to do this?
Thanks,
Antonio
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Antonio Goméz Soto]

Post by Alex Balashov
No. It's a proxy, it can't originate requests.

I am sorry, maybe I do not understand enough about SIP and proxies.
Wouldn't it be possible to fake re-invites? Tell each phone that it
gets a reinvite coming from the other phone, and basically redirecting
the sound stream to an rtpproxy for example? or a codec translator?

I'd like to switch from g711 to g729 when the link gets overloaded
for example. Or record the phonecall.

I am trying to learn more about SIP. Aren't reinvites within
a dialog common?

Maybe I could make changes to openser to enable this?

Antonio

Post by Alex Balashov

Post by Antonio Goméz Soto
Hi,
maybe I should go to the -dev list for this, but thought I'd ask here first.
Is it possible to let openSER send a SIP reinvite in the middle of a call,
to redirect the sound stream to some rtpproxy? Maybe using the MI?
Or should OpenSER be modified to do this?
Thanks,
Antonio
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Alex Balashov]

Post by Antonio Goméz Soto
I am sorry, maybe I do not understand enough about SIP and proxies.
Wouldn't it be possible to fake re-invites? Tell each phone that it
gets a reinvite coming from the other phone, and basically redirecting
the sound stream to an rtpproxy for example? or a codec translator?
I'd like to switch from g711 to g729 when the link gets overloaded
for example. Or record the phonecall.
I am trying to learn more about SIP. Aren't reinvites within
a dialog common?
Maybe I could make changes to openser to enable this?

Yes, reinvites are common, and you have correctly ascertained their
purpose.

What I think you are not understanding is that a reinvite, like any
other request, must be originated from an endpoint (a user agent). A
proxy is not a user agent; it cannot generate replies. The only
thing proxies do, as a matter of definition, is forward requests they
receive, and forward replies to them in the opposite direction (when
applicable).

Again, I draw your attention to the HTTP server vs. Squid analogy we
made earlier. The question you are asking sounds equivalent to, "Can
Squid send a GET request?" The answer is no, Squid cannot send any
requests; it can only act on requests it receives and direct them
somewhere.

[Antonio Goméz Soto]

Post by Alex Balashov

Post by Antonio Goméz Soto
I am sorry, maybe I do not understand enough about SIP and proxies.
Wouldn't it be possible to fake re-invites? Tell each phone that it
gets a reinvite coming from the other phone, and basically redirecting
the sound stream to an rtpproxy for example? or a codec translator?
I'd like to switch from g711 to g729 when the link gets overloaded
for example. Or record the phonecall.
I am trying to learn more about SIP. Aren't reinvites within
a dialog common?
Maybe I could make changes to openser to enable this?

Yes, reinvites are common, and you have correctly ascertained their
purpose.
What I think you are not understanding is that a reinvite, like any
other request, must be originated from an endpoint (a user agent). A
proxy is not a user agent; it cannot generate replies. The only thing
proxies do, as a matter of definition, is forward requests they receive,
and forward replies to them in the opposite direction (when applicable).
Again, I draw your attention to the HTTP server vs. Squid analogy we
made earlier. The question you are asking sounds equivalent to, "Can
Squid send a GET request?" The answer is no, Squid cannot send any
requests; it can only act on requests it receives and direct them
somewhere.

Right. I see now. It can only send out requests which it has received,
and not create new ones.
But on the other hand, kamailio *does* keep dialog state, so might it be
possible to create some add-on module, that injects fake messages into
the input stream? Using info that is in the dialog state?
Or.. come to think of it, would that mess up the dialog between the endpoint,
because it would increment counters that are maintained by the endpoint?

Antonio

[Alex Balashov]

Post by Antonio Goméz Soto
Right. I see now. It can only send out requests which it has received,
and not create new ones.
But on the other hand, kamailio *does* keep dialog state, so might it be
possible to create some add-on module, that injects fake messages into
the input stream? Using info that is in the dialog state?
Or.. come to think of it, would that mess up the dialog between the
endpoint, because it would increment counters that are maintained by
the endpoint?

Yes, it would most likely interfere with the statekeeping done by the
endpoints.

The question you are asking is a technical one, but the answer is
really philosophical and conceptual one (i.e. in terms of how RFC 3261
defines various types of SIP elements). Is it theoretically possible
to add some hacks to a SIP proxy to make it behave as something other
than a proxy by spoofing messages in a convincing way? Yes, it is -
with enough ambition; in fact, Kamailio has a number of such hacks
internally, such as the dialog module's timeout attribute which can
spoof a BYE in both directions after a certain amount of time has
passed. But that's what they are - hacks. Useful, perhaps, but they
are departures from what a proxy is supposed to do that break proxy
purity.

So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something
else, so it really comes down to (a) what you want and (b) what the
product is intended to be. At the moment - several clever hacks
notwithstanding, and some UAS functionality (e.g. registrar)
notwithstanding as well - it's a proxy. As long as the intent of the
product is to continue to be a proxy, it is largely limited to the
sort of things a proxy can do, formally speaking.

To do the kinds of things you're wanting to do in a way that is
accommodated by the specifications and the protocol mechanics of SIP,
what you're really looking for is something that can behave as a user
agent in its own right.

[Antonio Goméz Soto]

Op 01-01-10 17:54, Alex Balashov schreef:
[ .. ]

The question you are asking is a technical one, but the answer is really
philosophical and conceptual one (i.e. in terms of how RFC 3261 defines
various types of SIP elements). Is it theoretically possible to add some
hacks to a SIP proxy to make it behave as something other than a proxy
by spoofing messages in a convincing way? Yes, it is - with enough
ambition; in fact, Kamailio has a number of such hacks internally, such
as the dialog module's timeout attribute which can spoof a BYE in both
directions after a certain amount of time has passed. But that's what
they are - hacks. Useful, perhaps, but they are departures from what a
proxy is supposed to do that break proxy purity.

Ok, i see what you mean.

So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.

And do you think the Kamailio maintainers oppose extending the
functionality in this direction?

To do the kinds of things you're wanting to do in a way that is
accommodated by the specifications and the protocol mechanics of SIP,
what you're really looking for is something that can behave as a user
agent in its own right.

Any suggestions (given the fact that it needs to accomodate a couple
of ten thousands of phones?)

Antonio

[Alex Balashov]

Post by Antonio Goméz Soto

Post by Alex Balashov
So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.

And do you think the Kamailio maintainers oppose extending the
functionality in this direction?

I think the general answer is yes, but the specific answer tends to be
no in some very particular scenarios. There have been a number of
apostasies from proxy purity in the past; off the top of my head:

* Dialog timeout, dialog bridge and dialog refer;
* t_uac_dlg (tm);
* uac_req_send() (uac)

It is obvious that the wishes of the proxy god are not always honoured
here.

But the existence of these notwithstanding, the question is whether
Kamailio is the appropriate tool for extensive request intermediation
in principle. I would say it is not. The above features provide a
crude facility for originating requests from the MI interface, but it
requires invocation via the command line and is not part of the normal
event loop and/or state machine. On top of that, it would be
difficult - though perhaps not impossible - to use these basic request
construction facilities to construct sequential in-dialog requests
(such as re-INVITEs) that contain ALL the appropriate attributes
required of them, since no other supporting functionality is provided
to keep track of and easily expose state for all of them. These
features are intended for certain very narrow scenarios, not a
reflection of larger accommodations toward UAC behaviour as an
all-encompassing design principle.

Few questions have black-and-white answers; it's simply a matter of
degree to which the design and architecture of something is suitable
for a particular class of tasks. In the case of things like
re-INVITEs, I think the suitability is very low.

Post by Antonio Goméz Soto
Any suggestions (given the fact that it needs to accomodate a couple
of ten thousands of phones?)

Don't know - take a look at SEMS, Yate, Sippy, Asterisk, Freeswitch, etc.

[Olle E. Johansson]

Post by Antonio Goméz Soto
[ .. ]

The question you are asking is a technical one, but the answer is really
philosophical and conceptual one (i.e. in terms of how RFC 3261 defines
various types of SIP elements). Is it theoretically possible to add some
hacks to a SIP proxy to make it behave as something other than a proxy
by spoofing messages in a convincing way? Yes, it is - with enough
ambition; in fact, Kamailio has a number of such hacks internally, such
as the dialog module's timeout attribute which can spoof a BYE in both
directions after a certain amount of time has passed. But that's what
they are - hacks. Useful, perhaps, but they are departures from what a
proxy is supposed to do that break proxy purity.

Ok, i see what you mean.

So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.

And do you think the Kamailio maintainers oppose extending the
functionality in this direction?

To do the kinds of things you're wanting to do in a way that is
accommodated by the specifications and the protocol mechanics of SIP,
what you're really looking for is something that can behave as a user
agent in its own right.

Any suggestions (given the fact that it needs to accomodate a couple
of ten thousands of phones?)

Anything inserted by the proxy will mean that a middelbox adds +1 to the CSEQ.
This means that the real UA will send another message with a duplicated CSEQ. If the server UA follows the RFC, this message should not be handled, as the CSEQ needs to be raised by at least one for every sent message from a UA. So the proxy will have to continue raising the CSEQ for all following messages by remembering a delta or you can just hope that the server UA ignores this issue.

The same issue occurs when a proxy does authentication (see the UA module in Kamailio for a warning exactly about this).

/O

[Antonio Goméz Soto]

Post by Olle E. Johansson

Post by Antonio Goméz Soto
[ .. ]

The question you are asking is a technical one, but the answer is really
philosophical and conceptual one (i.e. in terms of how RFC 3261 defines
various types of SIP elements). Is it theoretically possible to add some
hacks to a SIP proxy to make it behave as something other than a proxy
by spoofing messages in a convincing way? Yes, it is - with enough
ambition; in fact, Kamailio has a number of such hacks internally, such
as the dialog module's timeout attribute which can spoof a BYE in both
directions after a certain amount of time has passed. But that's what
they are - hacks. Useful, perhaps, but they are departures from what a
proxy is supposed to do that break proxy purity.

Ok, i see what you mean.

So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.

And do you think the Kamailio maintainers oppose extending the
functionality in this direction?

To do the kinds of things you're wanting to do in a way that is
accommodated by the specifications and the protocol mechanics of SIP,
what you're really looking for is something that can behave as a user
agent in its own right.

Any suggestions (given the fact that it needs to accomodate a couple
of ten thousands of phones?)

Anything inserted by the proxy will mean that a middelbox adds +1 to the CSEQ.
This means that the real UA will send another message with a duplicated CSEQ. If the server UA follows the RFC,
this message should not be handled, as the CSEQ needs to be raised by at least one for every sent message from a UA.
So the proxy will have to continue raising the CSEQ for all following messages by remembering a delta or you can just
hope that the server UA ignores this issue.
The same issue occurs when a proxy does authentication (see the UA module in Kamailio for a warning exactly about this).
/O

Hi,

couldn't you increment CSEQ by send bogus messages to the respective endpoints?
A bogus SIP UPDATE or something?


Antonio

[Alex Balashov]

Post by Antonio Goméz Soto
couldn't you increment CSEQ by send bogus messages to the respective
endpoints? A bogus SIP UPDATE or something?

No, because the sending UA uses certain pattern of CSeq values for
requests it sends - there is a separate set of CSeq value states from
the other endpoint UA, and they are not intrinsically related.

Secondly, I think you misunderstood what Daniel was saying; he was
saying that to spoof subsequent requests the CSeq value would need to
be increased relative to the "sender." But that assumes the proxy is
a party to all of the UA's transactions, which cannot be guaranteed.

Once again, the problem here is fundamental - what you want is not
what a proxy was designed to do, and Kamailio was not designed to
venture outside of its principal character as a proxy to accommodate
such needs. You really need something that can (a) asynchronously
originate requests and (b) generate independent logical call legs
without any requirement to know or conserve state integrity between
two third parties.

[Antonio Goméz Soto]

Hi all,

first I want to thank you for providing answers to my numerous questions.
You have made perfectly clear that Kamailio is only a proxy, and is rather
good at that.

Secondly, I now am rather pessimistic about scaling up our current asterisk
system (which is only used by our own office) to be useful for the entire
organisation.

We actually use:

- flash operator panel to transfer calls
- call recording (mid-call using *1)
- call pickup
- barge-in
- conferences
- call forwarding
- ACD functions + listening through ChanSpy
- and various other things

The data network people don't want all calls to flow through some
central point, because of WAN network load, and think they can have phones
talk to each other using g711 when they are one the same LAN, and g729 when
they need to go through a WAN.

But as I see it now, it will be pretty much impossible to scale up using
Kamailio if we still need operator panels in offices here and there, because
there is no operator panel that can manipulate calls through Kamailio
(because that's only a proxy), and there is no operator panel that can handle
multiple parallel asterisk installations or SEMS or whatever.

Switching to different codecs depending on network location might
be doable using an Kamailio extension, but that will require a lot of
work, keeping a database, and manipulating the codec info in the SDP.

Mid-call recording poses it's own problems. If it must go undetected then
ALL calls must go through a rtp proxy, which the network people will oppose,
and even if not, Kamailio will not be the proper tool to enable it.
Also recording of G729 calls rules out SEMS and basically all other
opensource solutions except asterisk.

Of course there also is the question of managing all this. We currently
edit configfiles, but that doesn't scale all too well, so we'll probably
need some management and reporting tools as well.

And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.

Scaling up our asterisk system while preserving all of its features seems to
be a lot more involving than I initially thought...

Thanks,
Antonio

PS: And I'd like a one-to-one chat with some guys on the asterisk mailing list
who simply point to openSER when someone asks for scalability ;-)

[Alex Balashov]

Hi Antonio,

As I mentioned in one of my previous posts, and will emphasise again:
large scale cannot happen magically just through the addition of a
few small elements.

From your description of your environment, it sounds like the systems
and features being used are primarily "host-wise" - e.g. tied to the
runtime state/environment of a single instance of Asterisk on a single
host. This is a limitation upon its scalability.

To provide services on a large scale, the system has to be composed of
non-hostwise components; the architecture must be distributed. This
is a defining property and an organising principle of its design from
the very bottom, not a setting you can simply enable when your user
base grows large enough. Building distributed VoIP service delivery
platforms is a very different science than building non-distributed
ones.

Once again, let me make a more general cluster analogy; if you have a
single instance of an application on a different server, you cannot
just add more some more servers, run the application in parallel on
them, and expect it to work. Instead, either the whole application
must be written in a way that anticipates its being deployed in
parallel on multiple nodes, or single instances of it must be placed
into some sort of harness that can implement a distributed/parallel
abstraction layer for it while preserving for the application the
illusion of single-instance runtime. Either way, multiple nodes
executing the program must have a way of keeping shared logical state
across the entire execution continuum (in a centralised or distributed
way), passing messages amongst nodes asynchronously, synchronising
storage access to prevent race conditions / mutual exclusion
violations, avoid deadlocks, etc.

An application or service designed to run on multiple nodes to begin
with will have these facilities baked into its architecture, while an
application or service not designed to do that would probably have to
be rewritten or, at least, very extensively modified in order to suit
the new requirement. In more generic computation this probably means
the use of something like the LAM/MPI libraries, or perhaps some sort
of concept aspiring to Google's MapReduce and/or BigTable.

It's the same thing with VoIP and Asterisk. Much of what you've got
now relies on particular Asterisk nodes performing particular
functions, which just isn't how a distributed system works unless you
are willing to settle for some sort of compromise involving node
specialisation -- which might be okay: a dedicated conferencing
server, dedicated ACD/queue server, etc. But this ultimately has
scalability barriers too and represents an inefficiency.

I have mentioned one possible and common distributed Asterisk
architecture before: a central FastAGI controller in which all
application logic is implemented - and, in the case of things which
already exist in Asterisk such as queues, often RE-implemented in a
way compatible with distributed architecture - to which all calls are
dispatched via N Asterisk servers. Such a backend could implement the
necessary shared state for logical abstractions extended across N
servers. The example I often give is one of Asterisk queues (in the
sense of Queue()): a queue exists only in one Asterisk server, but
you can reimplement the "user experience" aspect of a queue in FastAGI
(estimated time to wait announcement, music, etc.), which would then
allow you to extend one logical queue over multiple Asterisk servers
and potentially support thousands of callers in "one" queue.

Even if you do not use such an architecture, you're going to have to
think along these lines. Kamailio alone cannot make anything scale;
the service delivery backend has to be built with a distributed
architecture in mind.

-- Alex

[Antonio Goméz Soto]

Alex,

thank you for your extensive answer. (sorry to top-post).
It's just that I have been asked to scale up an existing system
(which happens to be asterisk), and I'm now trying to get a
grasp on how to do it.

Thanks,
Antonio.

Post by Alex Balashov
Hi Antonio,
large scale cannot happen magically just through the addition of a few
small elements.
From your description of your environment, it sounds like the systems
and features being used are primarily "host-wise" - e.g. tied to the
runtime state/environment of a single instance of Asterisk on a single
host. This is a limitation upon its scalability.
To provide services on a large scale, the system has to be composed of
non-hostwise components; the architecture must be distributed. This is a
defining property and an organising principle of its design from the
very bottom, not a setting you can simply enable when your user base
grows large enough. Building distributed VoIP service delivery platforms
is a very different science than building non-distributed ones.
Once again, let me make a more general cluster analogy; if you have a
single instance of an application on a different server, you cannot just
add more some more servers, run the application in parallel on them, and
expect it to work. Instead, either the whole application must be written
in a way that anticipates its being deployed in parallel on multiple
nodes, or single instances of it must be placed into some sort of
harness that can implement a distributed/parallel abstraction layer for
it while preserving for the application the illusion of single-instance
runtime. Either way, multiple nodes executing the program must have a
way of keeping shared logical state across the entire execution
continuum (in a centralised or distributed way), passing messages
amongst nodes asynchronously, synchronising storage access to prevent
race conditions / mutual exclusion violations, avoid deadlocks, etc.
An application or service designed to run on multiple nodes to begin
with will have these facilities baked into its architecture, while an
application or service not designed to do that would probably have to be
rewritten or, at least, very extensively modified in order to suit the
new requirement. In more generic computation this probably means the use
of something like the LAM/MPI libraries, or perhaps some sort of concept
aspiring to Google's MapReduce and/or BigTable.
It's the same thing with VoIP and Asterisk. Much of what you've got now
relies on particular Asterisk nodes performing particular functions,
which just isn't how a distributed system works unless you are willing
to settle for some sort of compromise involving node specialisation --
which might be okay: a dedicated conferencing server, dedicated
ACD/queue server, etc. But this ultimately has scalability barriers too
and represents an inefficiency.
I have mentioned one possible and common distributed Asterisk
architecture before: a central FastAGI controller in which all
application logic is implemented - and, in the case of things which
already exist in Asterisk such as queues, often RE-implemented in a way
compatible with distributed architecture - to which all calls are
dispatched via N Asterisk servers. Such a backend could implement the
necessary shared state for logical abstractions extended across N
servers. The example I often give is one of Asterisk queues (in the
sense of Queue()): a queue exists only in one Asterisk server, but you
can reimplement the "user experience" aspect of a queue in FastAGI
(estimated time to wait announcement, music, etc.), which would then
allow you to extend one logical queue over multiple Asterisk servers and
potentially support thousands of callers in "one" queue.
Even if you do not use such an architecture, you're going to have to
think along these lines. Kamailio alone cannot make anything scale; the
service delivery backend has to be built with a distributed architecture
in mind.
-- Alex

[Daniel-Constantin Mierla]

Hello,

top posting is good :-) ...

just sharing my own way of scaling, let's say the SIP proxy way:

- I run all the services a proxy can do in the proxy (authentication,
lcr, call filering, call forwarding, presence, user location)
- keep asterisk for media related features (voicemail, announcement,
recording)

I have the (big) advantage of usually designing from beginning the
service and I convince customers that some features do not fit in a
limited budget (cheap VoIP platform with cheap VoIP phones).

In your case you have to go with a more expensive server platform,
meaning that you have to invest in several asterisk boxes and a routing
mechanism between them, as you use very specific asterisk apps (like
fop) and want to stick with that.

I would try to do:
- partition the users per asterisk instance - as much as possible host
the users talking to each other in same asterisk
- use kamailio as central registry server - if the destination user is
not on the same asterisk instance, forward it to kamailio and from there
to the right asterisk instance

You will have all the features within groups, most of them across entire
platform (e.g., things like call pickup will work only within the group).

Cheers,
Daniel

Post by Antonio Goméz Soto
Alex,
thank you for your extensive answer. (sorry to top-post).
It's just that I have been asked to scale up an existing system
(which happens to be asterisk), and I'm now trying to get a
grasp on how to do it.
Thanks,
Antonio.

Post by Alex Balashov
Hi Antonio,
large scale cannot happen magically just through the addition of a few
small elements.
From your description of your environment, it sounds like the systems
and features being used are primarily "host-wise" - e.g. tied to the
runtime state/environment of a single instance of Asterisk on a single
host. This is a limitation upon its scalability.
To provide services on a large scale, the system has to be composed of
non-hostwise components; the architecture must be distributed. This is a
defining property and an organising principle of its design from the
very bottom, not a setting you can simply enable when your user base
grows large enough. Building distributed VoIP service delivery platforms
is a very different science than building non-distributed ones.
Once again, let me make a more general cluster analogy; if you have a
single instance of an application on a different server, you cannot just
add more some more servers, run the application in parallel on them, and
expect it to work. Instead, either the whole application must be written
in a way that anticipates its being deployed in parallel on multiple
nodes, or single instances of it must be placed into some sort of
harness that can implement a distributed/parallel abstraction layer for
it while preserving for the application the illusion of single-instance
runtime. Either way, multiple nodes executing the program must have a
way of keeping shared logical state across the entire execution
continuum (in a centralised or distributed way), passing messages
amongst nodes asynchronously, synchronising storage access to prevent
race conditions / mutual exclusion violations, avoid deadlocks, etc.
An application or service designed to run on multiple nodes to begin
with will have these facilities baked into its architecture, while an
application or service not designed to do that would probably have to be
rewritten or, at least, very extensively modified in order to suit the
new requirement. In more generic computation this probably means the use
of something like the LAM/MPI libraries, or perhaps some sort of concept
aspiring to Google's MapReduce and/or BigTable.
It's the same thing with VoIP and Asterisk. Much of what you've got now
relies on particular Asterisk nodes performing particular functions,
which just isn't how a distributed system works unless you are willing
to settle for some sort of compromise involving node specialisation --
which might be okay: a dedicated conferencing server, dedicated
ACD/queue server, etc. But this ultimately has scalability barriers too
and represents an inefficiency.
I have mentioned one possible and common distributed Asterisk
architecture before: a central FastAGI controller in which all
application logic is implemented - and, in the case of things which
already exist in Asterisk such as queues, often RE-implemented in a way
compatible with distributed architecture - to which all calls are
dispatched via N Asterisk servers. Such a backend could implement the
necessary shared state for logical abstractions extended across N
servers. The example I often give is one of Asterisk queues (in the
sense of Queue()): a queue exists only in one Asterisk server, but you
can reimplement the "user experience" aspect of a queue in FastAGI
(estimated time to wait announcement, music, etc.), which would then
allow you to extend one logical queue over multiple Asterisk servers and
potentially support thousands of callers in "one" queue.
Even if you do not use such an architecture, you're going to have to
think along these lines. Kamailio alone cannot make anything scale; the
service delivery backend has to be built with a distributed architecture
in mind.
-- Alex

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Antonio Goméz Soto]

Hi Daniel.

Post by Daniel-Constantin Mierla
- partition the users per asterisk instance - as much as possible host
the users talking to each other in same asterisk
- use kamailio as central registry server - if the destination user is
not on the same asterisk instance, forward it to kamailio and from there
to the right asterisk instance

It's not clear to me what this means. The phones register to Kamailio
as their registrar server. And they will send INVITE's to their proxy
(i.e. the asterisk server?). So only Kamailio will know the ip address
of a phone (except if asterisk accesses the same database using
realtime - is that what you mean?)

Antonio

[Daniel-Constantin Mierla]

Hello,

Post by Antonio Goméz Soto
Hi Daniel.

Post by Daniel-Constantin Mierla
- partition the users per asterisk instance - as much as possible host
the users talking to each other in same asterisk
- use kamailio as central registry server - if the destination user is
not on the same asterisk instance, forward it to kamailio and from there
to the right asterisk instance

It's not clear to me what this means. The phones register to Kamailio
as their registrar server.

you can do this way, too, scaling better.

But I thought you want to preserve as much as possible current
architecture. So the phones register to asterisk -- this to be done by
configuring each phone to use the proper asterisk.

Once you add a new phone, you add a routing info in kamailio binding the
phone id to asterisk ip (you can do that with alias_db, pdt, htable, and
other modules, just a matter of taste).

In asterisk dialplan, if the dialed number is not a local phone, forward
it to kamailio which will forward to right asterisk.

I can think of various options to optimize and auto-provision, like
automatically updating kamailio's routing rules based on user registration.

Cheers,
Daniel

Post by Antonio Goméz Soto
And they will send INVITE's to their proxy
(i.e. the asterisk server?). So only Kamailio will know the ip address
of a phone (except if asterisk accesses the same database using
realtime - is that what you mean?)

[Olle E. Johansson]

Post by Antonio Goméz Soto
Hi Daniel.

Post by Daniel-Constantin Mierla
- partition the users per asterisk instance - as much as possible host
the users talking to each other in same asterisk
- use kamailio as central registry server - if the destination user is
not on the same asterisk instance, forward it to kamailio and from there
to the right asterisk instance

It's not clear to me what this means. The phones register to Kamailio
as their registrar server. And they will send INVITE's to their proxy
(i.e. the asterisk server?). So only Kamailio will know the ip address
of a phone (except if asterisk accesses the same database using
realtime - is that what you mean?)

Well, if you need Asterisk states, you need to register with Asterisk and not with Kamailio. Or possibly both.

But if you have a set of phones that can run "simple" services, then you can let them register with Kamailio and have a gold service running on a full Asterisk PBX. SIP is designed in a way to let the phones be in control of a lot of services. Even though you're using a proxy, services like call transfer, three-way conferencing and call hold will work - if the phones support it. Most business-level IP phones does support a lot of these advanced services.

/O

[Alex Balashov]

Antonio,

Post by Antonio Goméz Soto
thank you for your extensive answer. (sorry to top-post).
It's just that I have been asked to scale up an existing system
(which happens to be asterisk), and I'm now trying to get a
grasp on how to do it.

It may be necessary for you - and your superiors - to accept that not
all problems can be solved with the constraints one is given, and this
may be one of them.

As others have pointed out, you can reorganise Asterisk in various
ways to take advantage of Kamailio by centralising and/or specialising
some nodes. But while this may buy you more capacity, it is not a
true distributed design, and a true distributed design doesn't seem
impossible without reimplementing large aspects of your existing system.

-- Alex

[Alex Balashov]

Post by Alex Balashov
Antonio,

Post by Antonio Goméz Soto
thank you for your extensive answer. (sorry to top-post).
It's just that I have been asked to scale up an existing system
(which happens to be asterisk), and I'm now trying to get a
grasp on how to do it.

It may be necessary for you - and your superiors - to accept that not
all problems can be solved with the constraints one is given, and this
may be one of them.
As others have pointed out, you can reorganise Asterisk in various ways
to take advantage of Kamailio by centralising and/or specialising some
nodes. But while this may buy you more capacity, it is not a true
distributed design, and a true distributed design doesn't seem
impossible without reimplementing large aspects of your existing system.

*possible

[Raúl Alexis Betancor Santana]

Post by Antonio Goméz Soto
Hi all,
first I want to thank you for providing answers to my numerous questions.
You have made perfectly clear that Kamailio is only a proxy, and is rather
good at that.
Secondly, I now am rather pessimistic about scaling up our current asterisk
system (which is only used by our own office) to be useful for the entire
organisation.

Hi Antonio, I think that you are "blocked" with the limited vision that
Asterisk gives you about VoIP world ... let me explain that ...

Post by Antonio Goméz Soto
- flash operator panel to transfer calls

That could be done with xmlrpc calls if you use SEMS+Kamailio

Post by Antonio Goméz Soto
- call recording (mid-call using *1)

SEMS have support for call-recording, we use it.

Post by Antonio Goméz Soto
- call pickup

Well, this is a little bit complex ... but still doable.

Post by Antonio Goméz Soto
- barge-in

...
barge-in definition - telecom
A feature of a key telephone system (KTS) or PBX, barge-in allows an
authorized user from an authorized station to join, without invitation, an
active call on a call in progress through the use of an authorization code
the user enters via the telephone keypad.
...

Umm ... a type of chanspy I suppose ... well, this would be complicated ...
but still doable.

Post by Antonio Goméz Soto
- conferences

Supported by SEMS

Post by Antonio Goméz Soto
- call forwarding

Supported by Kamailio with script routing.

Post by Antonio Goméz Soto
- ACD functions + listening through ChanSpy

Umm ... maybe LB+Dispatcher

Post by Antonio Goméz Soto
- and various other things

You will have to specify.

Post by Antonio Goméz Soto
The data network people don't want all calls to flow through some
central point, because of WAN network load, and think they can have phones
talk to each other using g711 when they are one the same LAN, and g729 when
they need to go through a WAN.

Trust me ... if you use VoIP phones (hardphones, no softphones), the will be
not difference between G711 local calls and G729 local calls ... if phones
are goog enought. No matter of what you do ... you could build a VoIP system
with no "central point", it's just a matter of time,knowleadge and bugget

Post by Antonio Goméz Soto
But as I see it now, it will be pretty much impossible to scale up using
Kamailio if we still need operator panels in offices here and there,
because there is no operator panel that can manipulate calls through
Kamailio (because that's only a proxy), and there is no operator panel that
can handle multiple parallel asterisk installations or SEMS or whatever.

You are wrong here, if you follow the "asterisk path" ... Asternic FOP 2.0
allow you to easly control more than one asterisk.
On the other hand, you could also develop your own panels to control
SEMS+Kamailo, you could build a VoIP infraestructure on witch you use SEMS as
B2BUA withouth the need to forward all RTP traffic throught it, so you will
get a very good and scalable Asterisk replacement.

Post by Antonio Goméz Soto
Switching to different codecs depending on network location might
be doable using an Kamailio extension, but that will require a lot of
work, keeping a database, and manipulating the codec info in the SDP.

Functions to mangling the SDP are out there, but you will have to do the work,
or hire someone to doit.

Post by Antonio Goméz Soto
Mid-call recording poses it's own problems. If it must go undetected then
ALL calls must go through a rtp proxy, which the network people will
oppose, and even if not, Kamailio will not be the proper tool to enable it.

If you want it to be "undetectable" and don't want to use a RTP proxy, if you
have the needed network hardware, you still could do it.

Post by Antonio Goméz Soto
Also recording of G729 calls rules out SEMS and basically all other
opensource solutions except asterisk.

You could use G729 with sems, we use it, you only need to write down some
lines of C++ code to use the Intel G.729 ipp libraries, for example ... or
you could develop a wrapper an use Asterisk .so files of G729 codecs, or a
hardware card, it's a matter of time, knowleadge and bugget

Post by Antonio Goméz Soto
Of course there also is the question of managing all this. We currently
edit configfiles, but that doesn't scale all too well, so we'll probably
need some management and reporting tools as well.

Yes, you have the tools, now it's time to beging to work, no pre-made systems,
no just-click-and-run software.

Post by Antonio Goméz Soto
And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.

Eint ?? ... an attended transfer it's no more than two calls A call B, B puts
A on hold, B calls C, C accept the transfer, B transfer A to C ... it just
work with the basic example .cfg of kamailio, because it's a work of the UA's
involved on that calls, not a task of the proxy.

Call-pickup could also be done at proxy level, if your UA's support that
supplementary services, if not .. a B2BUA must be used.

Post by Antonio Goméz Soto
Scaling up our asterisk system while preserving all of its features seems
to be a lot more involving than I initially thought...

Yes, it is ... a very big and very good challenge.

Post by Antonio Goméz Soto
PS: And I'd like a one-to-one chat with some guys on the asterisk mailing
list who simply point to openSER when someone asks for scalability ;-)

Could be used, it's a matter of knowing how to do it and that's the hard
part ... ;-)

[Antonio Goméz Soto]

Post by Raúl Alexis Betancor Santana
Hi Antonio, I think that you are "blocked" with the limited vision that
Asterisk gives you about VoIP world ... let me explain that ...

Post by Antonio Goméz Soto
- flash operator panel to transfer calls

That could be done with xmlrpc calls if you use SEMS+Kamailio

Uhmm, is that event-driven? Because I am convinced you cannot
write a good operator panel on polling line statuses alone.

Post by Raúl Alexis Betancor Santana
[ snip ]

Post by Antonio Goméz Soto
Also recording of G729 calls rules out SEMS and basically all other
opensource solutions except asterisk.

You could use G729 with sems, we use it, you only need to write down some
lines of C++ code to use the Intel G.729 ipp libraries, for example ... or

Is this legal, I mean, will the G.729 patent holders object to this?

Post by Raúl Alexis Betancor Santana
you could develop a wrapper an use Asterisk .so files of G729 codecs, or a
hardware card, it's a matter of time, knowleadge and bugget

true, anything can be done if you have unlimit budget.

Post by Raúl Alexis Betancor Santana

Post by Antonio Goméz Soto
And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.

Eint ?? ... an attended transfer it's no more than two calls A call B, B puts
A on hold, B calls C, C accept the transfer, B transfer A to C ... it just
work with the basic example .cfg of kamailio, because it's a work of the UA's
involved on that calls, not a task of the proxy.
Call-pickup could also be done at proxy level, if your UA's support that
supplementary services, if not .. a B2BUA must be used.

What is it exactly that a UA must support? Do regular VoIP phones support it?

Best,
Antonio

[Daniel-Constantin Mierla]

Post by Antonio Goméz Soto
[...]

Post by Raúl Alexis Betancor Santana

Post by Antonio Goméz Soto
And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.

Eint ?? ... an attended transfer it's no more than two calls A call B, B puts
A on hold, B calls C, C accept the transfer, B transfer A to C ... it just
work with the basic example .cfg of kamailio, because it's a work of the UA's
involved on that calls, not a task of the proxy.
Call-pickup could also be done at proxy level, if your UA's support that
supplementary services, if not .. a B2BUA must be used.

What is it exactly that a UA must support? Do regular VoIP phones support it?

for call transfer the phones should support REFER and most of them do.

For call pickup you need dialoginfo presence modules loaded on proxy and
the phones to support the SIP extension rfc4235:
http://kamailio.org/docs/modules/3.0.x/modules_k/presence_dialoginfo.html
http://kamailio.org/docs/modules/3.0.x/modules_k/pua_dialoginfo.html

Not many phones support it now, but I guess more will do it in near
future. Snom does it now pretty good.

Cheers,
Daniel

[Olle E. Johansson]

Post by Antonio Goméz Soto
Hi all,
first I want to thank you for providing answers to my numerous questions.
You have made perfectly clear that Kamailio is only a proxy, and is rather
good at that.
Secondly, I now am rather pessimistic about scaling up our current asterisk
system (which is only used by our own office) to be useful for the entire
organisation.
- flash operator panel to transfer calls
- call recording (mid-call using *1)
- call pickup
- barge-in
- conferences
- call forwarding
- ACD functions + listening through ChanSpy
- and various other things
The data network people don't want all calls to flow through some
central point, because of WAN network load, and think they can have phones
talk to each other using g711 when they are one the same LAN, and g729 when
they need to go through a WAN.
But as I see it now, it will be pretty much impossible to scale up using
Kamailio if we still need operator panels in offices here and there, because
there is no operator panel that can manipulate calls through Kamailio
(because that's only a proxy), and there is no operator panel that can handle
multiple parallel asterisk installations or SEMS or whatever.
Switching to different codecs depending on network location might
be doable using an Kamailio extension, but that will require a lot of
work, keeping a database, and manipulating the codec info in the SDP.
Mid-call recording poses it's own problems. If it must go undetected then
ALL calls must go through a rtp proxy, which the network people will oppose,
and even if not, Kamailio will not be the proper tool to enable it.
Also recording of G729 calls rules out SEMS and basically all other
opensource solutions except asterisk.
Of course there also is the question of managing all this. We currently
edit configfiles, but that doesn't scale all too well, so we'll probably
need some management and reporting tools as well.
And I currently have no clue on how to do attended transfer, or call pickup
on such a system, both of which seem pretty basic to me in a corporate
environment.
Scaling up our asterisk system while preserving all of its features seems to
be a lot more involving than I initially thought...
Thanks,
Antonio
PS: And I'd like a one-to-one chat with some guys on the asterisk mailing list
who simply point to openSER when someone asks for scalability ;-)

Well, to scale you DO need a proxy. The issue here is what you use the proxy for and how you distribute the telephony services you need. You always have to start with the services you use. If Asterisk is a simple PSTN gateway for SIP, then it is very easy, since there's no state involved you are interested in sharing. If you are using Asterisk for PBX services and you do need blinking lamps, there is a state you are interested in.

Now, with a decent server, you can manage thousands of simulatenous calls on one Asterisk server. You can use OpenSER for failover between two Asterisk servers, but only use one in production in order to preserve states on one machine. That's is one way of making it easy for yourself.

If you really need to distribute states, there are now multiple ways to do that between multiple Asterisk servers, with custom device states as one example.

So the people who pointed you to OpenSER/kamailio was not wrong at all. If they said that it was easy to scale a PBX using OpenSER, they might have been wrong. It's not easy yet, but many of us are working on making it easier.

/O

[Antonio Goméz Soto]

Post by Olle E. Johansson

Post by Antonio Goméz Soto
Hi all,

[snip]

Post by Olle E. Johansson
Well, to scale you DO need a proxy. The issue here is what you use the proxy for and how you distribute
the telephony services you need. You always have to start with the services you use. If Asterisk is a simple PSTN gateway for SIP,
then it is very easy, since there's no state involved you are interested in sharing. If you are using Asterisk for PBX services
and you do need blinking lamps, there is a state you are interested in.
Now, with a decent server, you can manage thousands of simulatenous calls on one Asterisk server. You can use OpenSER for failover
between two Asterisk servers, but only use one in production in order to preserve states on one machine. That's is one way of
making it easy for yourself.
If you really need to distribute states, there are now multiple ways to do that between multiple Asterisk servers, with custom
device states as one example.
So the people who pointed you to OpenSER/kamailio was not wrong at all. If they said that it was easy to scale a PBX using
OpenSER, they might have been wrong. It's not easy yet, but many of us are working on making it easier.
/O

Olle,

this sounds like decent advice. Looking at the asterisk source, I think I could safely say that with
all lists converted to astobj2 (in 1.8) that asterisk can handle tens of thousands of phone registrations,
and thousands of channels. I think asterisk is making great strides in scalability at the moment,
don't you agree? It might even scale up to OpenSER/Kaimilio numbers.

It may not be able to handle the media for all those calls, but that is an entirely different matter.

OTOH, it might just be wishful thinking..

Thanks,
Antonio

[Daniel-Constantin Mierla]

Hello,

Post by Antonio Goméz Soto
[ .. ]

The question you are asking is a technical one, but the answer is really
philosophical and conceptual one (i.e. in terms of how RFC 3261 defines
various types of SIP elements). Is it theoretically possible to add some
hacks to a SIP proxy to make it behave as something other than a proxy
by spoofing messages in a convincing way? Yes, it is - with enough
ambition; in fact, Kamailio has a number of such hacks internally, such
as the dialog module's timeout attribute which can spoof a BYE in both
directions after a certain amount of time has passed. But that's what
they are - hacks. Useful, perhaps, but they are departures from what a
proxy is supposed to do that break proxy purity.

Ok, i see what you mean.

So, yes, you could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.

And do you think the Kamailio maintainers oppose extending the
functionality in this direction?

about any kind of extensions to kamailio -- nobody will oppose as long
as there is a developer doing it (old or new) and committing to maintain
the new code -- the project is open to new enhancements all the time. It
has to be a module, so the rest is not affected.

However, as Alex said, kamailio is designed to be proxy and this does
the best. You may discover that you have to invest a lot in a new module
to get complete user agent client behavior while you can get it faster
with other applications. If I would be you, I would go with SEMS, with
few tens of line you should get what you want, here some examples:
http://ftp.iptel.org/pub/sems/doc/current/AppDocExample.html

SEMS is designed for this scope, is lightweight comparing with other sip
media apps, it is SIP only (therefore it avoids multi-protocol complexity).

But decision is not simple, if you need to catch the call for
transcoding, then it better to do it with the apps able to do
transcoding for g729 Asterisk might be the only chance -- not sure if
SEMS can do it due to licensing.

For call recording, if you do the re-INVITE in the middle of the call,
then you advertised it to caller and callee, so practically they can
detect it, which does not help much if it is for legal purposes. So you
should do it from beginning with a media server in the middle.

From my point of view, the architecture should be:
- several media servers - you need them when having lot of users, not
matter you do recording or transcoding
- kamailio to handle registration, call routing and other proxy
features, plus load balancing between media server instances

Then you can scale as you need by adding new media servers.

Cheers,
Daniel

Post by Antonio Goméz Soto

To do the kinds of things you're wanting to do in a way that is
accommodated by the specifications and the protocol mechanics of SIP,
what you're really looking for is something that can behave as a user
agent in its own right.

Any suggestions (given the fact that it needs to accomodate a couple
of ten thousands of phones?)
Antonio
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users