[sr-dev] [Kamailio-Users] [OT] SIP ALG Detector released

[Daniel-Constantin Mierla]

On 06/19/2009 03:35 PM, Iñaki Baz Castillo wrote:
> 2009/6/18 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>   
>> thanks for it, sounds very useful. What I see missing here is the case when
>> the alg screws the routing so the reply does not get back to phone (e.g.,
>> via replaced on the way out but not changed back for reply), so it might be
>> good to have like an ack when the reply was received by the UA.
>>     
>
> However, the test is done in the client, not in the server. This is,
> the ACK could tell the server that the reply was received, but if not,
> what to do?
>   

in this way the server would know that client is behind or not alg (with 
special header saying yes/no or due to timeout).

So first I was thinking to extend so both client/server know the alg 
presence state. But this option requires to maintain some state in the 
server, then I came with the second idea to include the encoded content 
in the initial request (within one or more headers), so it stays 
request-reply approach. Basically, not all content has to be encoded, 
but several headers and body, e.g., via header, contact header, call-id 
and sdp body -- if these are not touched, then all should be ok.

Cheers,
Daniel

>> Or maybe would be better to do the other way. The client sends the request
>> encoded to the server, the server unecodes it, does the diff and decides
>> whether it is a possible alg in the middle.
>>     
>
> I was thinking about it, but it doesn't convince me since ALG's
> usually "require" a "common" INVITE request with common SDP body. If
> the INVITE sent by the client contains itself encoded, it wouldn't
> look a "common" request and the ALG could react in any exotic way :(
>
>
>   
>> I think it is very useful, as the server would also know alg presence state
>> :-).
>>     
>
> That's would be a different approach. I decided to do the test just in
> the client, so an user testing it doesn't require access to the
> server. Also the server doesn't require to store results in DB and so.
>
>
> Regards.
>
>
>
>   

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