Richard Shockey writes:
> I think the XCON folks were trying to be inclusive
> in their charter development but frankly I don't think
> its necessary. The IETF now has three SIP related WG's
> operating well and producing good work and the scope
> of the XCON proposal IMHO should be directed at SIP
> specifically. Its a complex issue, there is a real
> problem statement and a focused WG could tackle the
> problem head on and deliver results. This was the
> direction we took with SIPPING for the specific IM
> problem and its what we need to do with SIP Conferencing.
I think some clarification is in order.
The SIP conferencing work has been well underway for
quite some time now in the SIP and SIPPING working
groups. It is essentially complete, and will be in WGLC
momentarily. We don't need a SIP conferencing working
group; SIP conferencing already has a home.
That said, for a conferencing solution to be complete,
there are certain things that are required -- such as
floor control and membership permissions -- for which
SIP is simply not appropriate.
The raison d'être for XCON is precisely to do the
part of conferencing that is not SIP. The relationship
between the XCON protocols and SIP are far looser than
would legitimately warrant the level of concern being
expressed on this list.
For example: to be able to talk about specific media
streams in a conference, you need to be able to identify
streams of media. XCON does so in terms of SDP, since
that is the mechanism used by SIP to establish media
streams.
To examine what this means in the context of the charter's
claim that the solutions developed in XCON will not preclude
operation with other signaling protocols: if someone were
to decide to apply XCON to some theoretical IP-based call
control protocol that used PSTN TDM trunks for conveying
media [1], these identifiers could be replaced with SS7
circuit identification codes.
If the initial proposals being presented as input to
XCON had some strong binding to SIP that made their use
in other contexts difficult, I would understand the
concerns being expressed in this forum. However, the
proposed solutions (all of which I expect to instantly
be accepted as working group items in the case that the
working group is chartered) demonstrate no such binding.
I invite those with concerns to carefully examine the
protocol proposals [2] and indicate where they believe
this not to be the case.
/a
[1] This theoretical protocol is intentionally fantastic
to avoid the discussion being bogged down with descriptions
of any political reasons why certain protocol communities
may elect to use different conferencing solutions.
[2] http://www.softarmor.com/xcon/drafts/