I've seen this problem (or a similar one) before. I don't think it's a problem with the header decoding, because the phone goes into a timeout before the headers could have affected anything. In the case I saw, it was a problem with capabilities negotiation. The phone tried to open a connection and requested capabilities such as the use of UP-specific code pages. It also used the UP-specific encoding in its connection request, because the headers and capabilities information are sent in the same packet. Kannel responded with a ConnectReply which denied the use of these capabilities, and for some reason the phone just didn't want to hear that. I have heard that there _is_ a possible response that will cause the phone to try again without the secret UP extensions, but I couldn't figure out what it might be.
Since then, I've thought about the problem occasionally, and the answer might be in the later WSP 1.2 specification. In the definition of the Encoding-Version heading, it says that a server which encounters unknown encodings should reply with a status code 400 (Bad Request), and then the client should try again. This seemed a bit strange to me, because the ConnectReply packet does not have space for a status code. But it turns out that it _is_ permissible to send a normal Reply packet (with status code) in response to a Connect request, and this will cause the connection to be aborted. Now, Kannel implements WSP 1.1 which does not define any Encoding-Version header. But because of all this, it might be better for Kannel send a status 400 error reply if a connect request uses unknown headers, rather than using the capabilities response to signal the problem and then trying to cope. Certainly it's worth trying, to see if it makes those phones behave better. I have some thoughts about the best way to implement this, but I'll write them down if people agree with the principle :) Richard Braakman
