Hello,
On 1/1/10 6:24 PM, Antonio Goméz Soto wrote:
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?
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
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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users