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

Philipp Hancke fippo at goodadvice.pages.de
Wed Jul 6 16:43:06 UTC 2016


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 jdev at conference.jabber.org and xsf at 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 <description/> element includes all of the payload types that the
> initiator //*can send and/or receive*//for Jingle RTP, each one
> encapsulated in a separate <payload-type/> 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 <content/> element, not <payload-type/>.

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.

This doesn't cover your scenario. I think you should not be mixing 
sendonly codecs and receiveonly codecs with sendrecv codes in the same 
m-line / content.

> Now, when session is accepted, initiator will start sending RTP data
> encoded with opus, which responder cannot receive and responder will
> start sending RTP data encoded with speex, which initiator cannot receive.
> Or there's something I don't understand?!
> The second question is preferences. XEP-0167 says that order of
> <payload-type/> elements within <description/> element indicates sending
> entity preferences. But there's no mention about what to do with that
> information. What other party should do with knowledge of this party's
> payload type prefenrences?

It actually specifies the preferences of the sender of the description.
This allows the sender of the media to switch between codecs depending 
on network conditions, i.e. you might prefer ISAC to Opus in some 
scenarios. Modern codecs like opus do this inband.

> 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
> <http://tools.ietf.org/html/rfc4566#section-6>, 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.

Lots of legacy here. Hope that helps a bit.


More information about the Standards mailing list