[Kamailio-Users] re-invite mid call?

[Antonio Goméz Soto]

Op 02-01-10 11:00, Olle E. Johansson schreef:
>
> 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

Hi,

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


Antonio