19 Jun
2009
19 Jun
'09
5:37 p.m.
On 06/19/2009 03:35 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
2009/6/18 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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
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?
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.