[Standards] XEP-0167: Something, I can't understand
yagiza at yandex.ru
Sat Jul 2 16:19:47 UTC 2016
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/>.
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
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?
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.
With my best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards