Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt

From: Henry Sinnreich <[email-masked]>
Date: Wed, 03 Feb 2010 12:17:52 -0600

We have published an I-D on "SIP APIs for Web Communications" and would
appreciate any comments and input.

Here is the link and the announcement:

http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title  : SIP APIs for Communications on the Web
 Author(s) : H. Sinnreich, A. Johnston
 Filename : draft-sinnreich-sip-web-apis-00.txt
 Pages  : 19
 Date  : 2010-1-19
 
   Interactive communications are becoming part of rich Internet
   applications (RIA). This can be accomplished entirely by using Web
   technology and developing it as an Internet standard. Voice over IP
   (VoIP) features developed for Session Initiation Protocol (SIP 2.0)
   can be preserved in rich multimedia communications and applications
   on the web.  Hyper Text Transport Protocol (HTTP) is used for control
   and signaling data and RTP for interactive media transport
   respectively. No other network application protocols are required.
   Web, fixed and mobile device application development tools can thus
   be used to include components and widgets for Internet presence,
   Instant Messaging (IM), voice and video.  This opens Internet
   communications, including voice to application developers and will
   also enhance the user experience with real-time Web and mobile
   communications.  Usage scenarios include service providers, private
   IP networks, device application developers and media companies
   providing a mix of integrated communications, applications and media.
   This memo argues for the development and standardization of
   Application Programming Interfaces (APIs) to allow the benefits of
   SIP to be used by Rich Internet Applications (RIA), for fixed and
   mobile devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sinnreich-sip-web-apis-00.txt

------ End of Forwarded Message

Thanks in advance for your comments.

Henry

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 3 Feb 2010 15:21:11 -0500

Hi Henry,

(Based on a one-pass read through)

I like the ideas expressed in this draft. The summary of SIP 2.0 is on
target and the definition of a web API is a good idea. It is something I can
use.

Moving to HIP is a good idea.

Regards,

Peter Musgrave

On Wed, Feb 3, 2010 at 1:17 PM, Henry Sinnreich
<[email-masked]>wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Feb 2010 10:43:45 +0100

Henry,

Where the draft talks about "porting core SIP functions to standards XML based API" (section 4.5), can you shed some more light on this? Is it just a case of adopting existing SIP semantics and defining a new syntax (XML)? If so, this would seem to require the web application to support the same complex SIP state machine, with its notions of transactions, dialogs, early dialogs, backwards compatibility capabilities, tolerance of unreliable transports, offer-answer rules, and at least some of the many SIP extensions. Or had you intended some sort of simplification, and if so can you give more detail?

Thanks,

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Sinnreich
> Sent: 03 February 2010 18:18
> To: dispatch mailing list
> Subject: [dispatch] FW: I-D ACTION:draft-sinnreich-sip-web-apis-00.txt
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 04 Feb 2010 07:36:42 -0600

John,

Thanks for your comments.

We are not thinking about just an XML encoding for SIP - you are
correct, that would still expose way too much complexity.  We were
thinking about starting with the functionality in RFC 5638, then see how
much we can abstract and separate the "plumbing" of SIP from what an app
developer needs/cares about.  We hope to avoid replicating the entire
SIP state machine.

However, this is just a starting point, and feedback and input from
others who share our goal is most welcome.

- Alan -

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 4 Feb 2010 09:16:32 -0500

Henry/Alan,

I think some mention of other web technologies in the draft might help frame
the effort.

e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-like
media constructs, uses ICE and if I recall correctly does put address inside
messages).

If I had a web API which allowed direct connections to SIP endpoints/media
servers I think that would be powerful. In the past I have done things like
created a "B2B-like" entity with a Jingle stack and a SIP stack - but then I
end up with identity issues and issues with simultaneous sessions to media
servers.

I agree that a very simple call state machine is desired - even if the SIP
mechanics need to be strongly restricted. I also agree that SDP is getting a
bit tired.

Peter

On Thu, Feb 4, 2010 at 8:36 AM, Alan Johnston <[email-masked]>wrote:

> > Where the draft talks about "porting core SIP functions to standards XML
> based API" (section 4.5), can you shed some more light on this? Is it just a
> case of adopting existing SIP semantics and defining a new syntax (XML)? If
> so, this would seem to require the web application to support the same
> complex SIP state machine, with its notions of transactions, dialogs, early
> dialogs, backwards compatibility capabilities, tolerance of unreliable
> transports, offer-answer rules, and at least some of the many SIP
> extensions. Or had you intended some sort of simplification, and if so can
> you give more detail?
> >
> > Thanks,
> >
> > John
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Feb 2010 11:10:55 -0500

Peter Musgrave wrote:
>  I also agree that SDP is getting a bit tired. 

SDP was tired in 2000. It should have been buried long ago.

	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 04 Feb 2010 10:11:04 -0600

Peter,

As mentioned, our expertise and focus here is in SIP and similar APIs for
Jingle would give developers a bigger choice, depending on the usage
scenario.
As for ICE, we argue it to work in HIP for all application protocols alike,
besides all the other reasons for using HIP.

>If I had a web API which allowed direct connections to SIP endpoints/media
servers I think that would be powerful.
Yes, since all or most of the telecom gear supports SIP, we believe there
are lots of such apps.

Henry

---

From: <[email-masked]>
Date: Thu, 4 Feb 2010 17:18:52 +0100

Henry wrote
> Peter Musgrave wrote:
>> If I had a web API which allowed direct connections to SIP endpoints/media servers I think that would be powerful.
> Yes, since all or most of the telecom gear supports SIP, we believe there are lots of such apps.

do you think of something like this: http://www.developergarden.com/startseite ? It's a REST-based API to set up voice calls or conferences. It's an attempt to hide SIP's complexity from web developers. 

Wolfgang Beck

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
www.telekom.com 

Erleben, was verbindet. 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

________________________________

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Henry Sinnreich
Gesendet: Donnerstag, 4. Februar 2010 17:11
An: Peter Musgrave; Alan Johnston
Cc: dispatch mailing list
Betreff: Re: [dispatch] I-D ACTION:draft-sinnreich-sip-web-apis-00.txt

Peter,

>e.g. How does a SIP API compare to e.g. Jingle (which uses RTP, has SDP-like media constructs, uses ICE and if I recall correctly does put address inside messages). 

As mentioned, our expertise and focus here is in SIP and similar APIs for Jingle would give developers a bigger choice, depending on the usage scenario.
As for ICE, we argue it to work in HIP for all application protocols alike, besides all the other reasons for using HIP.

>If I had a web API which allowed direct connections to SIP endpoints/media servers I think that would be powerful.
Yes, since all or most of the telecom gear supports SIP, we believe there are lots of such apps.

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 04 Feb 2010 10:36:05 -0600

http://www.developergarden.com/startseite

Shows we don¹t have a monopoly in trying to hide SIP complexity from
developers.
Examples like Conf Call light are very convincing.

The next step is allowing Web application developers to mix and match RIA
and SIP-like apps in a seamless manner within the same IDE.
Or has someone done it already as well?

Henry

On 2/4/10 10:18 AM, "[email-masked]" <[email-masked]> wrote:

> Henry wrote
>> > Peter Musgrave wrote:
>>> >> If I had a web API which allowed direct connections to SIP
>>> endpoints/media servers I think that would be powerful.
> do you think of something like this: http://www.developergarden.com/startseite
> ? It's a REST-based API to set up voice calls or conferences. It's an attempt
> to hide SIP's complexity from web developers.
>  
> Wolfgang Beck
> 
>  
> 
>  
> 
> www.telekom.com <http:www.telekom.com>
> 
> Erleben, was verbindet.
> 
>  
> 
> Jingle would give developers a bigger choice, depending on the usage scenario.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Feb 2010 11:42:58 -0500

I like this draft. I find it much more to the point than was the simple 
sip draft. And it makes the case much better.

I agree with John that unless some simplification is done, a "web api" 
won't be any simpler than what we have.

The key to that is coming up with a higher level abstraction, that has 
all the degrees of freedom that are needed, while hiding everything 
else. This is very hard to do. And doing so successfully requires very 
carefully identifying the audience.

ISTM that developing such a new level of abstraction is a prerequisite 
to other progress on this front. I'm uncertain if IETF is or is not the 
right place to do that.

	Thanks,
	Paul

---

From: Tom Taylor <[email-masked]>
Date: Thu, 04 Feb 2010 12:47:43 -0500

Joerg and his student certainly tried, with SDPng. Maybe with the rise of XML 
SDPng's time has come.

---

From: Eric Burger <[email-masked]>
Date: Thu, 4 Feb 2010 20:08:58 -0500

What is totally missing is a comparison to Parlay X. We need something a bit deeper than REST vs. Web Serivces.

On Feb 3, 2010, at 3:21 PM, Peter Musgrave wrote:

> I like the ideas expressed in this draft. The summary of SIP 2.0 is on target and the definition of a web API is a good idea. It is something I can use.
> 
> On Wed, Feb 3, 2010 at 1:17 PM, Henry Sinnreich <[email-masked]> wrote: