XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method
If the nominated candidate is of the proxy type and either party cannot connect to the proxy (for example because of a restrictive firewall), the failing party shall send a transport-info message containing an <proxy-error/> element. The parties shall then consider the bytestream unsuccessful and SHOULD attempt to fall back to another transport as described in Fallback Methods.
This is a little bit weird. If remote send me proxy candidate and I can't connect to any remote candidate including this proxy, I would rather send <candidate-error>.
If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically (but not necessarily) IBB; see the Fallback Methods section of this document for details.
A client should not send candidate-error if it hasn't sent yet all its local candidates. Otherwise if we already have candidate-error from remote then the transport will be considered failed. For example it's possible if upnp binding lasts too long while jingle session was auto-accepted and all candidates tried.
Basically this dependency of transport state on candidate-error is hardly compatible with trickle candidates. Instead we need another XEP with more clear and flexible s5b negotiation procedure. Or at least modify this one so each side can send an alert that its local candidates were exhausted. Then we can consider transport failed ony when remote reported us it doesn't have more candidates and candidate-error.
Regarding proxy activation the spec is quite confusing either refering to XEP-0065's requester/target or Jingle's initiator/responder in its "2.2 Exchanging Candidates". Neither of these is valid in this case. As we know either party can add content in an already opened session and either party can propose a "proxy" candidate. With XEP-0065 it was different, only requester (session initiator) could have candidates. But with Jingle the algo has to be kept the same as with XEP-0065:
- One party sends a proxy candidate
- The other party connects and accepts it
- Then the first party connects to the proxy too and finally activates it
In other words the party which sent proxy eventually activates it, not obligtory the Jingle's initiator. Section "2.4 Completing the Negotiation" is more clear about in terms about activation, so probably one has to read it first.