I did some testing of my Jingle S5B code today and I hit an issue that is kinda overlooked currently in the spec.
Lets say A is the initiator and B is the receiver. A has access to a proxy. Now A sends the session-intiate message with the streamhost candidates (local and proxy). B then sends the session-accept with candidates (local and assisted). A fails to connect to B using the local candidate (they are on different LANs), it also fails to connect to B's assisted candidate (A is on a restrictive network that only allows certain ports out). At this point A will send B a "candidate-error" message. In the meanwhile B tried (and failed) to connect to A's local candidate but succeeded in connecting to A's proxy, so B sends A a "candidate-used" message. At this point A will try to connect to the proxy in order to activate the bytestream, but this will fail since A's firewall blocks port 7777. Now A and B are stuck in a kinda limbo, since B "thinks" one candidate was successful. I think adding an additional <transport-info/> tag with a value such as "proxy-error" would be appropriate in this situation. This would be the opposite of the "activated" action. This could also be used, if for some reason activating the bytestream failed (such as the wrong hash being used). What do you think? //Marcus
