[Standards] Jingle drafts
stpeter at stpeter.im
Fri Apr 11 16:36:25 UTC 2008
Olivier Crête wrote:
> On Fri, 2008-04-11 at 09:35 -0600, Peter Saint-Andre wrote:
>> Olivier Crête wrote:
>>> So most of my
>>> questions on Jingle audio apply here too. It would probably be more
>>> simple to have a single Jingle-rtp XEP with a media="" attribution in
>>> the content tag.
>>> That would also give us free "text" type for
>>> synchronized subtitles (there is some RFC about that somewhere).
>> I can't find an RFC about this. Perhaps you mean the following I-D?
> RFC 4103 would be an example, although I'm not certain if having
> text-as-rtp is really good for something like XMPP, making it
> supportable would probably make gatewaying easier.
Yeah I think we have text communication pretty well covered in XMPP. :)
But for synchronized voice+video+text you're right. We have not
considered use cases like that (again, we're trying to keep things simple).
I suppose what you're saying is that we would have a generalized way to
negotiate an RTP transport, and what you do with that transport is up to
you (it could be voice, it could be video, it could be real-time text,
it could be anything that that the RTP folks dream up). If we go down
that path, then we'd need a different way to discover capabilities
before the negotiation begins. Right now discovery depends on namespaces
like urn:xmpp:jingle:audio-rtp and urn:xmpp:jingle:video-rtp. But I
suppose we can define disco features that are used in service discovery
and entity capabilities (e.g., one feature for each media type), which
would be separate from the RTP negotiation itself.
>>> 4. Application format
>>> Why is the height/width specified? Why most payload types, it can change
>>> dynamically without the signalling being notified, for example in the
>>> case of H.263. How does width/height related to x/y? Are x/y coordinates
>>> inside a width/height sized area or is width/height the size of the
>>> rectangle displayed at x/y ? In either case, both the size of the
>>> picture and of the full frame should probably be included? And what is
>>> the use case for these?
>> I think we were simply trying to make sure that parameters communicated
>> in the SDP were not lost on the Jingle side of a gateway.
> I think in SDP those parameters are always per-codec (and sadly, each
> codec specifies them a bit differently).
Right, so we should capture them all with <parameter/> elements.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards