I was summoned... :-)
Am 29.04.19 um 12:02 schrieb Sergey Ilinykh:
Hi
There is a problem with jingle-s5b in the way how it handles additional
candidates sent with transport-info message.
Let's imagine a situation. We have an accepted session. Both sides sent
their host candidates in session-in
That would be perfect indeed.
пн, 29 апр. 2019 г., 18:16 Evgeny :
> On Mon, Apr 29, 2019 at 6:05 PM, Daniel Gultsch
> wrote:
> > how about sending the upnp as a fallback using transport-replace, with
> > a new transport (new id) of type s5b:1?
>
> Guys, how about switching to TURN instead? Maybe
There is a quote from the xep below:
This message MUST contain a element qualified by the
'urn:xmpp:jingle:transports:s5b:1' namespace, which SHOULD in turn contain
one element for each SOCKS5 Bytestreams candidate generated by
or known to the responder, but MAY instead be empty if the responder
On Mon, Apr 29, 2019 at 6:05 PM, Daniel Gultsch
wrote:
how about sending the upnp as a fallback using transport-replace, with
a new transport (new id) of type s5b:1?
Guys, how about switching to TURN instead? Maybe it's time already? ICE
is not something new anymore. You will really benefit f
Hi,
how about sending the upnp as a fallback using transport-replace, with
a new transport (new id) of type s5b:1?
I’m not really sure that the method you describe in (1) is legal
according to the XEP. transport-info isn’t explicitly specified in 260
and even if it is legal (166 doesn’t forbid it
Hi
There is a problem with jingle-s5b in the way how it handles additional
candidates sent with transport-info message.
Let's imagine a situation. We have an accepted session. Both sides sent
their host candidates in session-initiate/accept and both sides failed
because of NAT. But one of sides (
