Difference between revisions of "XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method"

Jump to navigation Jump to search
no edit summary
Line 1: Line 1:
'''Strange proxy-error'''
{{Quote|text=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.}}
{{Quote|text=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.}}


Line 4: Line 6:


-----
-----
'''When to send candidate-used/error'''


{{Quote|text=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.}}
{{Quote|text=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.}}
Line 13: Line 17:
-----
-----


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:
'''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
# One party sends a proxy candidate
Line 20: Line 26:


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.
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.
Follow next rules to make things right
# dstaddr for a local proxy candidate is computed like sha1(SID + Local JID + Remote JID)
# dstaddr for all other connections/bindings is computed like sha1(SID + Initiator JID + Responder JID)
-----
'''Port bindings confusion'''
Let's assume one of your "Direct" candidates is 10.0.0.2:8000. Then you configured you router to forward your <external IP>:8000 to 10.0.0.2:8000. Looks pretty good until now. Next you send both cadidates to the remote side and if your ISP provides you with public IP the probability of successful connection is quite high and that's perfect. But there is one problem, you can't distinguish which candidate received the incoming connection. They always come to 10.0.0.2:8000 and there is no any requirement for source IP to be in the same network. Of course it's also useless to compare connection dst IP and candidate's host because in case of NAT the IP will be different anyway not talking about if the host is not an IP but a domain name.
And as a consequence of lack of such a knowledge you can assign incoming connection socket to a wrong candidate. And then when remote side tells you candidate-used it may have no any socket or may have some wrong socket leading to connection failure.
If the XEP could provide a way to authenticates a specific candidate instead of the transport as a whole, that would make it possibe to listen on the same port (read do less port bindings). For example this could be done by computatio dstaddr per candidate like ''sha1(sid, cid, initiator jid, responder jid)'', but there is no such a way for now.
So as a rule of thumb:
# Never use the same local port for 2+ candidates
# If you still want to configure your router manually then do it, but use different local ports for all other candidates.
23

edits

Navigation menu