Theo and Jonathan,
I think both of these documents are great and I definitely like the
idea of a REST interface for SIP as I could see it helping in the
whole realm of web-based "mashups" that are going on right now.
My fundamental question, though, is this: why is this work to create a
REST interface to SIP going on within BLISS?
Yes, I understand that it was developed through the ACH discussions
and can provide a way to deal with ACH issues, but isn't the whole
idea of a "REST interface to SIP" something that has much larger
applicability? And if so, shouldn't this really be brought up over on
SIPPING?
I think it's definitely a good interface to develop for SIP... I just
wonder if all the right folks who should be part of that discussion
are actually subscribed to this list.
My 2 cents,
Dan
P.S. Jonathan, I'm sure you know this, but the "Security
Considerations" section of draft-griffin-bliss-rest-00 obviously needs
some work as there are very definitely security issues with a REST API
(some of which Theo has mentioned in his draft).
On Oct 27, 2008, at 12:14 PM, Theo Zourzouvillys wrote:
On Mon, Oct 27, 2008 at 3:51 PM, Jonathan Rosenberg
<[EMAIL PROTECTED]> wrote:
As a follow up from Dublin, I worked with a colleague of mine to put
together a brief document which describes REST a bit and presents
some
examples of how it can be used for the kinds of configuration
problems we
have in ACH. The draft is here:
http://www.ietf.org/internet-drafts/draft-griffin-bliss-rest-00.txt
comments welcome.
Jonathan,
The biggest issue with using REST is for notifications of changes to
resources in a scalable way that works behind NAT. There are a number
of choices: HTTP polling (perhaps COMET), XMPP, or in the case of
BLISS, a SIP event package. However, this is a far more generic
problem than just this domain - think RSS and twitter, and the huge
amount of resource wasted every day from polling over HTTP for changes
- although none the less something i'm interested in helping solve.
So while i've not explicitly tackled the notification part of it yet,
I have documented an initial framework that can be used for providing
simple configuration/data API services in a RESTful manner:
http://dev.voip.co.uk/~theo/ietf/draft-zourzouvillys-bliss-rest-for-sip-00.txt
The idea is that "profiles" then sit on top of this framework running
within the network, e.g:
- ACH configuration
- Phone book
- Recent/missed calls
- Voicemail access/configuration
I'd also appreciate any comments!
Kind regards,
~ Theo
--
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [EMAIL PROTECTED]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
