Subject: [p2p-sip] OpenWengo

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Fri, 06 Jan 2006 09:00:20 -0500

Another SIP client, but open source: http://www.openwengo.com/

Does not appear to run in p2p mode, but might be a basis for experiments 
in that space, given the GPL license. (My only involvement with the 
client is that I downloaded it; don't know whether it is any good or 
fries your machine.)

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Mon, 09 Jan 2006 11:52:15 +0100

> Another SIP client, but open source: http://www.openwengo.com/

It looks very skypish :-)

> in that space, given the GPL license.

I completely agree that an open source approach would be great for both
supporting the specification and facilitating its adoption. However, I
think it would be most useful (and maybe easyer) to implement the p2p
support on an existing open source stack; in this way, test applications
will be simple and won't have to care about complex gui stuff, while the
(as minimal as possible) effort to add p2p features to existing programs
using that stack, can be made by official developers.

Is anyone interested in such a kind of project?

Among available stacks, my preference would go to nokia's sofia-sip
(http://sofia-sip.sourceforge.net/), which is pretty modular and well
documented.

Cheers
Enrico

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin at tilab.com. Thank you
====================================================================

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon, 9 Jan 2006 14:02:00 -0600

Enrico,

> my preference would go to nokia's sofia-sip (http://sofia-
> sip.sourceforge.net/), which is pretty modular and well documented.

It appears the Nokia SIP UA does not seem to support Windows desktops or the
Pocket PC.

Is this correct?

Henry

-----Original Message-----
From: Enrico Marocco [mailto:enrico.marocco at TILAB.COM] 
Sent: Monday, January 09, 2006 4:52 AM
To: Henning Schulzrinne
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] OpenWengo

Cheers
Enrico

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Tue, 10 Jan 2006 10:05:33 +0100

> It appears the Nokia SIP UA does not seem to support Windows desktops or the

I haven't tried myself, but, at least on windows, I'd guess it does. It
uses a module which provides abstraction of system specific tasks (eg
memory management, threads, sockets, etc) and I can see a lot of windows
stuff there (#ifdef.... #include <winsock.h>...).

Enrico

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Tue, 10 Jan 2006 10:07:10 +0100

Aymeric Moizard wrote:
> I maintain the eXosip stack. (http://www.antisip.com/download/)
> It's wriiten in C, portable, simple to use, simple to extend and it's
> GPL code.
> 
> I would (and will anyway) personally help much for adding p2p support in
> it.

Obviously the willingness of the maintainer to cooperate is a big bonus
for the stack ;-)

I think a good starting point should be the implementation on the
existing api of a simple application acting as a p2p node; if your stack
is well suited for such task, it could be a valid choice IMHO.

Enrico

---

From: Kai.Vehmanen at nokia.com ([email-masked])
Date: Tue, 10 Jan 2006 12:09:33 +0200

Hi,

>> GPL code.
>> 
>> I would (and will anyway) personally help much for adding p2p support

>> in it.
>
>Obviously the willingness of the maintainer to cooperate is a 
>big bonus for the stack ;-)

well, some of us in the Sofia-SIP project would be also interested
in this work. It seems we are all here. :)

Anyways, not to turn this into full marketing thread, eXosip/osip 
is a good combo as well, and there are also couple of other
very good alternatives available now such as the new
pjsip stack (plus of course vovida and resip):

   http://www.bulukucing.org/pjsip.html
      
A comparison of basic features is available at:
   http://www.huisetalage.nl/sip/stacks.pdf

A more complete feature set SIP/SDP wise for Sofia-SIP can be found at:
   http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html

As for our win32/pocketpc support, we basicly have the code
working under both cygwin/mingw and natively compiled with visualc,
but no pocketpc-support yet. Some people have been testing the
code on OSX.

>I think a good starting point should be the implementation on 
>the existing api of a simple application acting as a p2p node; 
>if your stack is well suited for such task, it could be a 
>valid choice IMHO.

With Sofia-SIP, an easy start could be for instance to add p2p-node
functionality to the the gaim+sofia-sip combo:

http://sofia-sip.sourceforge.net/ssip-gst.html

Especially without audio support (no gstreamer needed => turn
gaim into a p2p SIP-IM app), this is very easy combo for developers, 
as both Gaim and Sofia-SIP are well documented and have lots of
example code available. Similar thing can be of course done with
other stacks as well.

--
http://research.nokia.com/people/kai_vehmanen/
Networking Technologies Laboratory, Nokia Research Center

---

From: lists at bulukucing.org (Benny Prijono)
Date: Tue, 10 Jan 2006 13:33:11 +0000

>    http://www.bulukucing.org/pjsip.html

Thanks Kai for spreading the news.
Just to inform that pjsip site has moved to http://www.pjproject.net

pjsip as it stands lacks the impressive features of resiprocate or 
sofia-sip; only up to transaction layer has been implemented and 
tested, although i'm working daily to improve the situation. But 
documentation is complete, I hope.

regards,
Benny

---

From: henry at pulver.com (Henry Sinnreich)
Date: Tue, 10 Jan 2006 08:34:33 -0600

Thanks for all the good information about available SIP implementations!

It is hard to judge how much compliant SIP implementations are unless we go
by some objective and agreed criteria.
http://www.huisetalage.nl/sip/stacks.pdf is a good start but some more is
required.

Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has to
support. A matrix with check boxes would be the next step. Maybe Robert
Sparks can also advise us how the SIPit does it now.

I would be interested:

1. Is this list reasonable?
2. How does one check actual compliance with such a list?
3. How would a _reasonable_ compliance matrix look like?

Here is what I mean (some links may be stale already). What do you think?

Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements and
Configuration"
http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J.,
Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.

Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515,
April 2003.

Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification",
RFC 3265, June 2002.

Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.

Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers,
"Session Initiation Protocol (SIP) 

Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.

Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers,
"Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN)
Call Flows", BCP 76, RFC 3666, December 2003.

Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in
Session Initiation Protocol (SIP)", RFC 3262, June 2002.

Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP):
Locating SIP Servers", RFC 3263, June 2002.

Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session
Description Protocol (SDP)", RFC 3264, June 2002.

Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State
Publication", RFC 3903, October 2004.

Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle,
"Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC
3428, December 2002.

Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC
3311, October 2002.

Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol
(SIP)", RFC 3323, November 2002.

Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within Trusted Networks",
RFC 3325, November 2002.

Mahy, R., Biggs, B. and R. Dean, "The Session Initiation Protocol (SIP)
"Replaces" Header", RFC 3891, September 2004.

Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. Haukka, "Security
Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329,
January 2003.

Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.

Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the
Session Initiation Protocol (SIP)", RFC 3841, August 2004.

Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism",
RFC 3892, September 2004.

Peterson, J., Liu, H., Yu, J. and B. Campbell, "Using E.164 numbers with the
Session Initiation Protocol (SIP)", RFC 3824, June 2004.

Mahy, R., "A Message Summary and Message Waiting Indication Event Package
for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.

Mahy, R., "A Call Control and Multi-party usage framework for the Session
Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-03 (work in
progress), October 2003.

Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for
Conference State", draft-ietf-sipping-conference-package-08 (work in
progress), December 2004.

Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation
Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January
2004.

Peterson, J., "Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in
progress), September 2004.

Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-03 (work in progress), October 2004.

Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs
(GRUU) in the Session Initiation 

Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.

Levin, O., "Suppression of REFER Implicit Subscription",
draft-ietf-sip-refer-with-norefersub-00 (work in progress), January 2005.

Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples",
draft-ietf-sipping-service-examples-07 (work in progress), July 2004.

Rosenberg, J., "An INVITE Inititiated Dialog Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-05 (work in
progress), November 2004.

Sparks, R., "Session Initiation Protocol Torture Test Messages",
draft-ietf-sipping-torture-tests-04 (work in progress), July 2004.

Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control -
Transfer", draft-ietf-sipping-cc-transfer-03 (work in progress), October
2004.

Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile
Delivery", draft-ietf-sipping-config-framework-05 (work in progress),
November 2004..

Camarillo, G. and A. Roach, "Subscriptions to Request-Contained Resource
Lists in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-subscribe-02 (work in progress), January 2005.

Jennings, C. and J. Peterson, "Certificate Management Service for SIP",
draft-ietf-sipping-certs-01 (work in progress), October 2004.

Wijk, A., "Framework of requirements for real-time text conversation using
SIP.", draft-ietf-sipping-toip-00 (work in progress), October 2004.

RFC 2327: "SDP: Session Description Protocol"  by M. Handley, V. Jacobson,
IETF, April 1998

RFC 3999: "The TEL URI for Telephone Numbers" by H. Schulzrinne, IETF, June
2004.

Johnston, H. Sinnreich, A. Clark, and A. Pendleton, " SIP Service Quality
Reporting Event" IETF Internet-Draft, October 2004, Work in progress.

RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" by H.
Schulzrinne, S. Casner, R. Frederick, V. Jacobson, IETF, July 2003.

RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control
" by H. Schulzrinne and S. Casner, IETF, July 2003.

RFC 3761: "The E.164 to Uniform Resource Identifiers (URI) Dynamic
Delegation Discovery System (DDDS) Application (ENUM)" by P. Falstrom and M.
Mealing, IETF, April 2004.

RFC 3952: "Real-time Transport Protocol (RTP) Payload Format for internet
Low Bit Rate Codec (iLBC) Speech" by A. Duric, S. Andersen, IETF, December
2004.

RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)" by T. Friedman,
Ed., R. Caceres, Ed., A. Clark, November 2003.

RFC 3711: " The Secure Real-time Transport Protocol (SRTP)," by M. Baugher
et al, March 2004

RFC 3830: "MIKEY: Multimedia Internet KEYing" by J. Arkko et al, August 2004

"Key Management Extensions for Session Description Protocol (SDP) and Real
Time Streaming Protocol (RTSP)" by J. Arkko et al,
draft-ietf-mmusic-kmgmt-ext-12.txt, November 2004.

RFC 2246: "The TLS Protocol Version 1.0" by T. Dierks and  C. Allen, IETF,
January 1999

RFC 3489: "STUN-Simple Traversal of UDP Through NAT" by J. Rosenberg et al.
IETF, March 2003.

"Traversal Using Relay NAT" by J. Rosenberg, R. Mahy, and C. Huitema, IETF
Internet-Draft, October 2004.

"Interactive Connectivity Establishment (ICE): A Methodology for Network
Address Translator (NAT) Traversal for Multimedia Session Establishment
Protocols" by J. Rosenberg, IETF Internet Draft, October 2004.

"Symmetric RTP and RTCP Considered Helpful" by D. Wing, IETF Internet Draft,
October 2004.

RFC 2833: "RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals" by H. Schuzrinne and S. Petrack, IETF, May 2000.

Thanks, Henry

-----Original Message-----
From: Kai.Vehmanen at nokia.com [mailto:Kai.Vehmanen at nokia.com] 
Sent: Tuesday, January 10, 2006 4:10 AM
To: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] OpenWengo

Hi,

---

From: lists at bulukucing.org (Benny Prijono)
Date: Tue, 10 Jan 2006 16:09:05 +0000

> 2. How does one check actual compliance with such a list?

Your list with 50+ RFCs looks absolutely horrifying! It will take 
longer than forever and twice infinite number of man months to support 
all of them.

A better approach would be to divide the requirements based on the 
features claimed by a device, just like what 
draft-sinnreich-sipdev-req-08.txt is doing. It will make them more 
manageable.

 > 3. How would a _reasonable_ compliance matrix look like?

*Reasonable* is really the key here.
I've tried once to translate RFC 3261 (and its close friends) into 
requirement items, and ~5 RFCs can easily produce more than 200 
specific requirement items, because basicly each paragraph in the RFC 
produces one requirement item. Here's what my requirement document 
looks like:

http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/docs/PJSIP-Testing.pdf

The list gets so exhaustive that I don't even bother to read it again! 
But if we must make a (strict) compliance matrix, then probably it 
will look horrifyingly similar to that.

> http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt

Btw the link should read
http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt 
(missing "o" in ".org").

regards,
Benny

---

From: henry at pulver.com (Henry Sinnreich)
Date: Tue, 10 Jan 2006 10:44:33 -0600

Benny Prijono wrote:

> Your list with 50+ RFCs looks absolutely horrifying!

Unfortunately I have to agree with you, but how can we dismiss all this work
performed in the IETF? What would we say to the authors?

The whole list is actually much bigger, if you only take a look at:

http://rfc3261.net/ published by Nils Ohlmeier cc:'d here.

Thanks, Henry

-----Original Message-----
From: Benny Prijono [mailto:lists at bulukucing.org] 
Sent: Tuesday, January 10, 2006 10:09 AM
To: henry at pulver.com
Cc: Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu; 'Robert Sparks'; 'Alan
Johnston'
Subject: Re: [p2p-sip] Evaluating SIP implementations

http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/docs/PJSIP-Te
sting.pdf

Btw the link should read

regards,
Benny

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 10 Jan 2006 11:57:58 -0500

I don't know whether it is the best or feasible for SIP but please let 
me remind you of an approach taken for MPEG-4.
They defined multiple 'profiles'. Each profile has a set of requirements 
and an implementation may be compliant with only one or multiple profiles.
So compliance is per profile rather than for the whole MPEG-4 spec.
If this approach is feasible for SIP, it can ease the horror.
Thanks.

Eunsoo

Henry Sinnreich wrote:

>>Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has
>>    
>>
>to
>  
>
>>Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements
>>    
>>
>and
>  
>
>>Configuration"
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>  
>

---

From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 10 Jan 2006 12:22:13 -0500

Yes, and then the Internet Streaming Media Alliance (ISMA.tv) picks the
particular profiles that they will require interoperability for,  
which become the
ones to use.

Note that this is an industry forum. That seems appropriate for a  
body that is basically
trying to decide what part of a large protocol to actually use.

So, there is a SIP Forum, with a Technical Working Group
http://www.sipforum.org/content/view/28/139/
but I know little about them. Is this something that they are  
doing  ? Is it something that
they should be doing ?

> If this approach is feasible for SIP, it can ease the horror.

Regards
Marshall Eubanks

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 10 Jan 2006 11:51:03 -0800

> performed in the IETF? What would we say to the authors?

Is it just me or is this the elephant in the room that nobody discusses?

For example, SIP alone is documented in over *30 different RFCs* 
according to Henry's list, and that's just *one* protocol.  To do 
anything meaningful you also need SDP, STUN, TURN, ICE, RTP, RTCP, etc, 
etc.  Every one of these requires its own parsers, and its own state 
machines.  Given this, just building a reasonably compliant "Hello 
world!" VoIP app is an incredible undertaking.

Furthermore, while a totally vanilla VoIP app can be simplified with 
off-the-shelf libraries, bending the RFCs in ways the authors didn't 
intend (such as P2P-SIP) is a Herculean effort because it's not just one 
library that needs tweaking, but many -- each with its own maintainer, 
own build process, own CVS repository, update cycle, bug database, etc.

What I think would help SIP adoption more than anything is a "SIP 2.0" 
that is a distillation of everything learned up to date, re-unified into 
a single document with a single grammar, parser, and update cycle.

Personally, I would pull together the essential elements of the various 
text protocols (SIP, SDP, STUN, TURN, ICE, and some DHT-maintenance 
commands), but leave RTP and the binary protocols separate.  With this 
tighter, smaller standard, true interoperability within this minimal 
subset might have a greater chance of succeeding.

Until then, given that *nobody* understand the big picture entirely, and 
even *fewer* have the resources to build it, everyone will just do the 
best they can and we'll end up basically where we are -- with a wide 
collection of "SIP compliant" devices and services that, despite the 
best intentions of the designers, are mostly incompatible, or that only 
achieve compatibility through extreme testing and custom tweaking.

Am I a lone pessimist in this view, or would you agree?

-david

---

From: jack at atosc.org (Aymeric Moizard)
Date: Mon, 9 Jan 2006 21:43:21 +0100 (CET)

> It looks very skypish :-)

and based on deprecated source of eXosip...

I maintain the eXosip stack. (http://www.antisip.com/download/)
It's wriiten in C, portable, simple to use, simple to extend and it's GPL 
code.

Aymeric