[vvc-l] Skype/323/SIP interop: request for information
s.horne at packetizer.com
Thu Mar 29 14:58:40 UTC 2012
Let me hit the reset button and discuss from a technical standpoint on how
from my experience to bridge from Skype to H.323/SIP.
Skype originally introduced the Skype API which did not support video pipes
so implementers would render the image on a memory surface then capture it
(Screen Scrape) A number of companies released products that did this.
About 2.5 years ago Skype released their SkypeKit API which was a much more
advanced low level interface. This is the API BlueJeans and the Spranto
Gateway uses. It finally became possible to route audio and video packets
(RTP) directly into and out of a skype instance without
decoding/transcoding, avoiding nasty screen scrapings. Well in theory that
all works fine but in reality it's a very different story. Skype supports
H.264, G.711, G.729 and their proprietary Silk codec (in RTP packets) . The
video sizes are also fixed 640x480 352x288 320x240 and 160x120. The API
expects the implementer to adjust the input resolution to whatever it
demands. If you send a RTP packet of the wrong size it simply will not
render at the far end. The RTP payload type are also fixed (96) so if you
just grabbed a H.323/SIP video RTP packet (payload ?) it will also will not
render. You can't easily control the frame size of H.264 packets from a
H.323/SIP device, you can set an upper limit but what is sent can be
anything and everything. The secret is to manage the chaos from the
H.323/SIP side and put in place contingencies if something changes.
For instance most H.323 devices support and send CIF (352x288) and CIF is
supported in Skype so it's a matter of buffering and tweaking the packets
and they can be exchanged directly between H.323/SIP and Skype without
actually decoding, BUT there are occasions where the H.323 device says no
I'm going to send 352x240 etc Skype just goes nope and video fails. The
trick is to intercept the key frames (H.323 devices always send one before
changing resolution) and detect the change and dynamically on-demand decode,
resize, encode so skype still gets its 352x288 and the skype user is unaware
of the change on H.323 side.
There is no concept of a gateway in skype it's all peer to peer. So unique
1-1 instances need to bundled together to act as a multiparty gateway.
Perhaps the biggest issue from a technical standpoint is the API itself and
its structure. It's straight out horrible and a number of the early releases
just didn't work or would easily become unstable. So far SkypeKit 4 seems at
least to be stable. They issue a developers key to enable the code to link
to the skype network that lasts 2 months so you are forever back on the
developers site getting a new key.
Perhaps the biggest show stopper is the commercial Terms of Service, it's
ridiculously restrictive and virtually eliminates using the code for
anything other than an endpoint. As a small player it's almost impossible to
deploy a commercial skype gateway solution in a box. You are pretty much
restricted to hosting the bridge.
Then there is the dialplan issues of how to map phone numbers to skype id's,
that's whole other story.
So in short it can be done and I currently have a closed demo running in the
h323.net cloud (I sent a link to a few people) but in reality unless you're
a big guy it's difficult to host, maintain and comply with the TOS and
without the strong community support needed you can't maintain it, hence why
it's on the sale block.
If anyone want to pick my brains on the technical stuff I'm happy to talk
From: vvc-l-bounces at lists.aarnet.edu.au
[mailto:vvc-l-bounces at lists.aarnet.edu.au] On Behalf Of Jason Bordujenko
Sent: 29 March 2012 10:26
Subject: [vvc-l] Skype/323/SIP interop: request for information
Thanks for some great feedback on the desktop video initiatives that you are
investigating at your respective institutions. We have had an overwhelming
amount of discussion both on the list and privately about the solutions that
are currently proliferating and there are calls for another round of reviews
based on the current crop against the criteria we set in the DVPG report
handed down in July 2010
July2010.pdf). AARNet are keen to see the community drive this adoption off
the back of the interest that has been collated here and we are keen to see
whether this would be taken up by one of our fantastic customers and/or
partners to take this on based on the rating scales that were developed by
Additionally, and in line with the findings of this report, we are now
investigating Skype interoperability solutions. Has any of the learned VVC-l
community got some experiences on a product or solution that they have
implemented to interoperate between Skype and H.323 and/or SIP? There are a
number out there, however from our research there are very few that have
actually been able to deliver what they claim.
Phil Wolff from Skype Journal (http://skypejournal.com) has provided this
list of his top 7 desires for 'next gen Skype':
1. Talking to the Skype network through a protocol without Skype's software.
2. Personal data portability, so users easily bring/take profiles, contacts,
3. Developer TOS that permits deploying SkypeKit on servers and in
4. Freedom to deploy without Skype's signature on every release.
5. Security systems audited by independent experts and members of the
6. Scriptable desktop clients to customize the user interface.
7. SDKs for APIs that can be implemented in developer hours, not developer
Interested in any comments from VVC-l on the above or solutions that may
work to our advantage in bringing clients utilising Skype to our existing
conferencing capability sets?
PS. Don't forget the DST changeover this weekend! Please email us at
support at nvcs.edu.au if you have any concerns.
National Video Conferencing Support Manager, Applications & Services
AARNet - The Australian Academic and Research Network
t. +61 (0) 7 3317 9572 m. +61 412 824 549
e. <mailto:jason.bordujenko at aarnet.edu.au> w. <http://www.aarnet.edu.au/>
street address: Ground Floor, 143 Coronation Drive, QLD, 4064, Australia
postal address: 1/143 Coronation Drive, QLD, 4064, Australia
Please consider the environment before printing this email.
This email and any files transmitted with it are confidential, and the
rights of confidentiality in such information are not waived or lost by its
mistaken delivery to you. Any dissemination, copying, use or disclosure of
the email and/or such files without the permission of AARNet, or the sender,
is strictly prohibited. If you have received this email in error, please
contact the sender immediately and delete all copies of this transmission.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vvc-l