19 Jun
2009
19 Jun
'09
4:35 p.m.
2009/6/18 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>