2 Jan
2010
2 Jan
'10
3:23 p.m.
Hello,
On 1/1/10 6:24 PM, Antonio Goméz Soto wrote:
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Op 01-01-10 17:54, Alex Balashov schreef:
[ .. ]
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
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
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users