> - the initiator consider the second message a response and maps it to an
> answer.
> - the responder will also consider it a response and map it to an answer.
>
Hi Philipp,
Why would it be considered as a response if there were no
first?
PS when are you going to return to xsf@ chat? :-)
Hi Daniel,
If you didn't receive iq type=result yet for your offer then it looks like
a remote offer. maybe even something to consider for .
Best Regards,
Sergey
вт, 16 нояб. 2021 г. в 22:33, Daniel Gultsch :
> Hi,
>
> I’m trying to implement ICE Restarts with XEP-0371. The XEP states
> that
I mean to use both *anchor* and *xml:lang* attributes to not write a
complicated element query parser if one is not provided by the used libs.
Best Regards,
Sergey
ср, 1 сент. 2021 г. в 11:10, JC Brand :
>
>
> On 01.09.21 10:06, Sergey Ilinykh wrote:
>
&g
why not just
```
```
?
Best Regards,
Sergey
ср, 1 сент. 2021 г. в 10:59, JC Brand :
> Hi Jonas
>
> On 31.08.21 17:23, Jonas Schäfer wrote:
>
> Hi JC,
>
> This has somehow slipped past me.
>
>
> Thanks for taking the time to respond.
>
> On Freitag, 13. August 2021 14:00:06 CEST JC Brand
What about a slightly different scenario?
Romeo sees a funny picture on funnypics.com, copies it to a messenger's
input field. The messenger prefetches the whole picture, generates a
thumbnail (at least it's impossible to have a thumbnail without fetching
everything), computes hashes and then
> The XEP Editor would like to Call for Experience with XEP-0050 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0050 implemented? Please note that the
> protocol must
Another perspective for profiles is work/life balance. Work/life MUCs or
anything else fitting this concept.
Particularly in Psi I've already added some options allowing to ignore some
autojoining mucs for example at work or local-only (not stored on a server)
bookmarks.
Best Regards,
Sergey
For bundling we already have https://xmpp.org/extensions/xep-0338.html
Only mux is w/o XEP.
Best Regards,
Sergey
пн, 13 апр. 2020 г. в 14:41, Daniel Gultsch :
> Am Mo., 13. Apr. 2020 um 11:33 Uhr schrieb Sergey Ilinykh <
> rion...@gmail.com>:
> >
> > I can't say an
I can't say anything about the history. But I like Jitsi's implementation
and will add support to Psi soon.
Best Regards,
Sergey
пн, 13 апр. 2020 г. в 14:23, Daniel Gultsch :
> Hi,
>
> webrtc uses rtcp-mux but to my knowledge XMPP has no way of signaling
> that a party wants to use that.
>
>
established for all
components at once
- Wrong reference to RFC 6455 was replaced with correct one: RFC 6544
Best Regards,
Sergey
вт, 17 мар. 2020 г. в 12:54, Sergey Ilinykh :
> > who is implementing 8445?
> >
> > Firefox only implements aggressive nomination.
> > http
>
> >
>> > I'm still not sure if it solves the problem if one end sends two
>> "restart"
>> > transport-infos in rapid succession. It'll receive a "restart"
>> > transport-info
>> > in response, but which one should it pair it with?
>> >
>> >
>> > according to ufrag.
>> >
>> > so
>
> > I'm still not sure if it solves the problem if one end sends two
> "restart"
> > transport-infos in rapid succession. It'll receive a "restart"
> > transport-info
> > in response, but which one should it pair it with?
> >
> >
> > according to ufrag.
> >
> > so one end sends
>
>
> I'm still not sure if it solves the problem if one end sends two "restart"
> transport-infos in rapid succession. It'll receive a "restart"
> transport-info
> in response, but which one should it pair it with?
>
according to ufrag.
so one end sends (ep1) restart, the other end (ep2)
ndidates should be matched with a set of
> > candidates received in a transport-info message.
> >
> > Perhaps some sort of remote-generation attribute is necessary for
> > candidates
> > sent in response to a peer's candidates?
> >
&
verywhere.
> I don't think bumping the namespace is practical until deployment is more
wide-spread.
I can agree here. But it would be nice to hear more thoughts from those who
already implemented this XEP.
вт, 17 мар. 2020 г. в 12:14, Philipp Hancke :
> Am 12.03.20 um 22:30 schrieb Serg
int to know for certain
> which
> generation of its local candidates should be matched with a set of
> candidates received in a transport-info message.
>
> Perhaps some sort of remote-generation attribute is necessary for
> candidates
> sent in response to a peer's candidates?
>
>
https://github.com/xsf/xeps/pull/905
PR Changes:
1. RFC 5245 is replaced with RFC 8445
2. Aggressive nomination is not supported anymore
3. remote-candidate is now MUST to mimic ICE SDP RFC
4. Now remote-candidate has to be send for all components at once when
ICE for media stream
e.
I believe in some cases (not stickers) the text has to be preserved for
SIMS.
Best Regards,
Sergey
чт, 17 окт. 2019 г. в 15:43, JC Brand :
> On Thu, Oct 17, 2019 at 03:05:32PM +0300, Sergey Ilinykh wrote:
> >Doesn't SIMS ([1]https://xmpp.org/extensions/xep-0385.html) resolve
> all
Doesn't SIMS (https://xmpp.org/extensions/xep-0385.html) resolve all the
concerns yet?
We can have a with cid: uri too.
The only thing is missed as for me is an attribute where the referenced
text has to be removed or not.
Best Regards,
Sergey
чт, 17 окт. 2019 г. в 14:24, Marvin W :
> Hi,
>
Mittwoch, 19. Juni 2019 19:46:02 CEST Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> >In Most of the case when I want to share something
which not
if it doesn't bring any value and some other jingle action already allow
the absence of the transport element".
Best Regards,
Sergey
ср, 26 июн. 2019 г. в 13:43, Philipp Hancke :
> Am 22.06.19 um 17:18 schrieb Sergey Ilinykh:
> > In response to Council Minutes 2019-06-19
> >
&
In response to Council Minutes 2019-06-19
quote from
https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method
Another problem with early (before accept) transport replace is the fact we
have to send the same offer twice. For example we have S5B and IBB. The
ср, 19 июн. 2019 г. в 21:33, Ralph Meijer :
> On 19/06/2019 19.46, Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> > In Most of the
Hi
I mostly implemented SIMS in Psi and see next problems
1) The requirement for top-level reference element looks strange.
In Most of the case when I want to share something, I don't want to
refer to anything.
If I really want to have a reference I would add it inside of
.
2) Top-level
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?
> By the way would love to do some interop assuming you are currently
> implementing Jingle File Transfer in Psi.
>
> cheers
> Daniel
>
> Am Mo., 29. Apr. 2019 um 10:05 Uhr schrieb Sergey Ilinykh <
> rion...@gmail.com>:
> >
> > Hi
> >
> > There
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
I guess it's something about accessing forbidden resources from restrictive
corporate networks.
ср, 13 мар. 2019 г., 10:40 Philipp Hörist :
> Whats the use case for this XEP?
> Until now i only needed DNS querys to connect to the XMPP Server, i see
> this XEP is not helping with that as it
I like the addition.
Best Regards,
Sergey
пт, 1 мар. 2019 г. в 11:36, Ненахов Андрей :
> This was discussed in July 2018 and, I guess, moved nowhere, but I'll
> raise the issue once again. Any decent messenger bar XMPP based ones have
> capabilities to signal type of user activity beyond just
Problem:
On each client start it necessary to send to disco info to each service
to determine where is upload, muc, socks5 and other useful stuff.
This slowdowns the startup and adds some load to the network and
server. Depending on implementation and service type this is not
obligatory should
30 matches
Mail list logo
