On 06/19/2009 03:35 PM, Iñaki Baz Castillo wrote:
2009/6/18 Daniel-Constantin Mierla miconda@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.