Re: [Standards] XEP-0167: Something, I can't understand

[Константин Козлов]

Hello!

Philipp Hancke пишет:

Am 02.07.2016 um 18:19 schrieb Константин Козлов:

Hello!

There's something, I still cannot understand in XEP-0167. I tried to ask
in both j...@conference.jabber.org and x...@muc.xmpp.org but got no
answer so far.

XEP-0167 chapter 5 says about *session-initiate* request:
/When the initiator sends a session-initiate message to the responder,
the  element includes all of the payload types that the
initiator //*can send and/or receive*//for Jingle RTP, each one
encapsulated in a separate  element//
/and later about *session-accept* request:
/The session-accept message SHOULD include a subset of the payload types
sent by the initiator, i.e., a list of the offered payload types that
the responder //*can send and/or receive*//./

I don't know how to understan that "and/or" construction, but I
understand it as /"can either send or receive or both"/. If I understand
correctly, there is no way to specify if the payload type could be
received or sent or both. Also, "senders" attribute mentioned below, but
this is an attribute of  element, not .


Right. There is not in SDP either.


So, there could be a situation, when initiator, for example can send and
receive iLBC and opus, also can send speex and receive g.722 and g.726.
And it preferes opus. Responder can send and receive iLBC and speex, can
also send opus and receive g.726. And it preferes speex. So,
*session-initiate* request will contain some payload types with names:
opus, iLBC, speex, g.722, g.726-32, g726-40
and *session-accept* request will contain payload types with names:
speex, opus, iLBC, opus, g.726-32, g.726-40


Jingle still (loosely) follows the rules of RFC 3264, in particular 
this from https://tools.ietf.org/html/rfc3264#section-6.1

   For streams marked as sendrecv in the answer,
   the "m=" line MUST contain at least one codec the answerer is willing
   to both send and receive, from amongst those listed in the offer.

Yes, but what about initiator?

This doesn't cover your scenario.

Yes.
I think you should not be mixing sendonly codecs and receiveonly 
codecs with sendrecv codes in the same m-line / content.
That's nice. But finally, what should I do? I guess, we need to add more 
rules to XEP-0167, how to choose payload types to offer them in 
session-initiate request and how to choose accepted payload types in 
session-accept request.


As for me, I'm thinking about two ways to selve the problem:
1. Add rule, that initiator MUST offer only payload types it can both 
send and receive and responder MUST accept only those of them, which it 
can receive, but there MUST be at least one payload type at can send as 
well. If no offered payload types meet thish condition, it SHOULD 
terminate session and include a Jingle reason of .
2. Add either attribute or child element of  element, 
which will explicitly specify if entity can send or receive it or both 
(default is both). In this case there could be a successful session even 
if amongst the codecs entities support, there's only one, which 
initiator can send and responder can receive and another one, which 
responder can send and initiator can receive!

The third question is about *"clockrate"* attribute. According to
XEP-0167, "name" attribute is "RECOMMENDED for static payload types,
REQUIRED for dynamic payload types", but *"clockrate" *is just
"RECOMMENDED". But according to RFC 4566
, both name and clockrate
are required for a=rtpmap: line of SDP message, which is is required for
dynamic payload types. And I found nothing about default value to use if
no *"clockrate"* attribute specified.


that sounds like a bug in XEP-0167. The intention was probably to omit 
this for some codecs which only specify a single clockrate anyway (say 
g.729). But that becomes an issue for mapping to SDP indeed which 
is no longer possible without a list of well-known codec-specific 
clockrates.
Considering it's a bug, maybe we should fix it by specifying for 
"clockrate" attribute the same rule as "name" attribute has?


With my best regards,
  Konstantin
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0167 (Jingle RTP Sessions)

[XMPP Extensions Editor]

Version 1.1.1 of XEP-0167 (Jingle RTP Sessions) has been released.

Abstract: This specification defines a Jingle application type for negotiating 
one or more sessions that use the Real-time Transport Protocol (RTP) to 
exchange media such as voice or video. The application type includes a 
straightforward mapping to Session Description Protocol (SDP) for interworking 
with SIP media endpoints.

Changelog: Fix typos (PMCA to PCMA). (XEP Editor: ssw)

Diff: http://xmpp.org/extensions/diff/api/xep/0167/diff/1.1/vs/1.1.1

URL: http://xmpp.org/extensions/xep-0167.html

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX progress

[Mickaël Rémond]

Hello,

We needed to have a working solution to support easily MUC on mobile today,
so we made the simple possible change on MUC to support that. It basically
allow users to become MUC subscribers. No need to send presence to room to
receive messages.

We described it there:
https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/

ejabberd master already supports it.
I hope this will help us gather from the field feedback to help improve MIX.

Anyway, we are also ready to implement and propose feedback on the next MIX
iteration.

Cheers,

-- 
Mickaël Rémond


On Wed, Jul 6, 2016 at 2:22 PM Steve Kille  wrote:

>
>
> > > it's just that Steve wants to double-check that the text reflects the
> > > Summit agreements before he submits.
> >
> > Ensuring that the text reflects whatever was agreed on the summit sounds
> more like a reason to make the text public as soon as
> > possible, instead of a reason to hold it back.
>
> [Steve Kille]
>
> There is real benefit to staged review.   If you share early text with a
> wide audience, lots of people ending up making comments
> that would have been better handled with review by a smaller group.
>
> The plan here is that Kev reviews my changes before they are generally
> shared.I believe that the summit comments are addressed.
>
>
> Steve
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Changes to XEP-0077: In-Band Registration

[Peter Waher]

Hello Vaibhav

There are various extensions that can be used together with In-band 
registration to make it more secure.

One way, it to secure it using CAPTCHA, as outlined in XEP-0158: 
http://xmpp.org/extensions/xep-0158.html. This method tries to seed out bots by 
assuring a human user creates the account.

Another way, more suitable for controlled creation of accounts by machines (for 
instance, for IoT), is outlined in XEP-0348, and is based on signing IBR forms, 
using some other credentials that can be used to distinguish approved account 
creators from others.

Best regards,
Peter Waher


Message: 3
Date: Fri, 8 Jul 2016 17:28:25 +0530
From: vaibhav singh 

Hi All,

I realised the subject was not in the correct format for the email I sent
in the morning. Please ignore that email.

I am a newbie software developer who recently started looking into XMPP
XEP's. In Band registration was something that caught my eye, as the XEP
itself said that it is utterly insecure and recommended people not to use
it.

I had some questions I wanted to clarify:
1.) Is there anything else people can use in XMPP to bootstrap users
quickly, apart from in-band registration?

2.) If in-band registration is so insecure, and (from the looks of it) so
important (atleast a really good feature to have) why are there no
alternative work flows people can use?

3.) If there is no simple alternative to In Band Registration, I can
probable try to create an XEP for an alternative protocol, or maybe suggest
some changes to the existing work flow. Can someone describe to me
concisely how to go about suggesting changes to an existing XEP/ writing an
Internet Draft?

Regards,
Vaibhav Singh


-- 

Regards,
Vaibhav Singh
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] [standards] Changes to XEP-0077: In-Band Registration

[vaibhav singh]

Hi All,

I realised the subject was not in the correct format for the email I sent
in the morning. Please ignore that email.

I am a newbie software developer who recently started looking into XMPP
XEP's. In Band registration was something that caught my eye, as the XEP
itself said that it is utterly insecure and recommended people not to use
it.

I had some questions I wanted to clarify:
1.) Is there anything else people can use in XMPP to bootstrap users
quickly, apart from in-band registration?

2.) If in-band registration is so insecure, and (from the looks of it) so
important (atleast a really good feature to have) why are there no
alternative work flows people can use?

3.) If there is no simple alternative to In Band Registration, I can
probable try to create an XEP for an alternative protocol, or maybe suggest
some changes to the existing work flow. Can someone describe to me
concisely how to go about suggesting changes to an existing XEP/ writing an
Internet Draft?

Regards,
Vaibhav Singh


-- 

Regards,
Vaibhav Singh
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313: MAM: RSM response data

[Kevin Smith]

On 7 Jul 2016, at 11:00, Dave Cridland  wrote:
> 
> Folks,
> 
> XEP-0313 §4 says:
> 
> "The final  response MUST include an RSM  element indicating 
> the UID of the first and last message of the (possibly limited) result set."
> 
> This seems plausible, but looks like a hangover from the marker messages in 
> previous versions. It doesn't help that this isn't in any of the examples; 
> I'd expect an Example 2.5 to show this. It's not in Example 3, however.
> 
> Example 9 does show the data, however - alongside the other RSM data I'd 
> expect.
> 
> Can I safely assume §4's normative statement is meant to be talking about the 
>  result?

That seems likely. 
/K
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___