[Kamailio-Users] re-invite mid call?

[Daniel-Constantin Mierla]

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 at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/