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 [email protected] and [email protected] 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.
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 <failed-application/>.
2. Add either attribute or child element of <payload-type/> 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
<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.
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: [email protected]
_______________________________________________
