[Kamailio-Users] re-invite mid call?

Olle E. Johansson oej at edvina.net
Sat Jan 2 11:00:18 CET 2010


1 jan 2010 kl. 18.24 skrev 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?)
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


More information about the Users mailing list