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

Константин Козлов yagiza at yandex.ru
Sat Jul 9 03:33:39 UTC 2016


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 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.
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


More information about the Standards mailing list