Let's say I craft a desktop sharing operation set, having in mind
what VNC can provide. That is fine. The problem I have with this is
that we have several different concerns in the protocols. SIP, Jabber
and some of the rest provide different layered services.
OperationSet-s are interfaces designed to be independent of the
underlying protocol so this shouldn't be a problem.
session negotiation and establishment (SIP/SDP, jabber (not sure
which JEPs) message exchange SIMPLE bidirectional media
pipes RTP/RTSP some other out-of band data
The media part is handled by JMF and the RTP (not sure how's that
done in java, probably somewhere in java.net, but that is my least
concern), where the SIP PP implements/should implement the wrapping
of all related parts.
The protocol provider is supposed to encapsulate signalling protocols
only (I agree that the name may leed to confusion). RTP and RTSP are
taken care of by implementations of the media service.
Can we construct layered ProtocolProviders - SIP&Jabber will be able
to use and RTP PP for rtp media streams, the VNC PP for vnc streams,
maybe http streams can be used as a firewall friendly alternative as
Well that's actually how things are currently intended to be.
ProtocolProviders only take care of the signalling and instant messaging
part of a protocol. Media Service implementations, notified by protocol
provider originating events and details would be handling media
accordingly. The part of a VNC implementation that would have to handle
the actual data exchange would have to place itself at the same level as
the media service. The VNC operation set implementation would only take
care of generating the right javax.sdp and javax.sip objects (i.e. sip messages and SDP descriptions) based
on parameters such as CallID and CallParticipantID, port number, ip
address and whatever else is necessary.
An implementation of an OperationSetDesktopSharing over SIP would therefore generate the corresponding SDP string while its Jabber impl would produce the JEP-0066 description like the one you quote.
You can see the similarities between the two. Both the vnc and rtp streams are of no concerns to the SIP and Jabber stacks, they could be handled by a separate, reusable sub-systems.
How that translates into sc terms, I don't have an idea, too new to
this and still reading, but hope it gives the general picture from
where I am standing.
Yes that's a good vision and it is quite similar to the way things are (or should I say will be, once finished) done in SC-1.0. With the only difference that data transport protocols do not appear as subsystems of a protocol provider but as parallel OSGI services directly accessible to the GUI (and to any other plugin/bundle for that matter). The reason to have things this way is that various data transportation protocols would require that their own programming interfaces be made available to others (such as the GUI) so there's no straightforward way (if any) of simply hiding them in the PP impl and exporting a common interface.
I hope I am making sense. Let me try an example for the VoIP case. Whenever an incoming call is received, the GUI (and any other interested plugins) would receive an event through the BasicTelephony operation set notifying them of the orignating call. At that point the GUI asks the MediaService to open a session corresponding to the received CallID object. The MediaService would return a MediaDescription object which the GUI, would pass back to the ProtocolProvider through a method like
.answerCall(CallID id, MediaDescription desc)
so that it could extract the necessary details out of the description and generate the corresponding protocol dependant description. For SIP that would be an SDP string and for Jabber (I believe) an XMPP string (I am not familiar with jabber so translate that in whatever it really has to be ).
I don't know how things work in VNC but a wild guess produces the following analogy:
When receiving an invitation for desktop sharing, the GUI (or some other plugin) would receive the event through the OperationSetDesktopSharing implementation and pass the corresponding CallID (or some other session identification if necessary) to a DesktopSharing service of some kind (analogical to the MediaService). That service would prepare to send and receive data through the network and generate on its own turn a DeskSharingDescription which would then be forwarded back by the GUI to the DesktopSharing operation set in a method like
.acceptSession(CallID id, DeskSharingDescription desc)
Does that or something similar make sense? If I am not being clear (which is probably the case) I may try to draw a diagram, let me know if so.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org