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

XEP-Remarks/XEP-0260: Jingle SOCKS5 Bytestreams Transport Method (view source)

891 bytes added , 11:27, 9 May 2019

no edit summary

23

edits

@@ Line 10: / Line 10: @@
 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.