Subject: [p2p-sip] Some comments on Use-cases document

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 27 Mar 2006 14:51:38 -0500

I agree with David.

It is also NOT harm to linkage a particular design with a particular DHT, if
this is the good choice for a given time. However, other proposals are also
welcome. It is an open to all of us.

Standardizations are always done throughout the world if there is a
consensus to go for something that is good. With respect P2P-SIP, there are
a lot of things to be solved. However, if something provides immediate
value, as David and many others of this list have opined, what is the
problem for standardization? A better standard in the future can always
supersede an inferior standard of the past.

Best regards,

Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
Sent: Monday, March 27, 2006 2:40 PM
To: 'Mike Robinson'; henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto';
'Peter Pan'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Some comments on Use-cases document

I guess one view is the IETF should forever be relegated to the janitorial
role of cleaning up after the party's over.  But I believe the IETF can
participate in and even promote the party through standardization.  I'd like
the IETF to do more than simply formalize de facto standards, but actually
create the standards that attract the party.  

In the case of P2P-SIP, I entirely agree there are multiple, valid, proven
ways to solve each of these problems - none of which is the clear victor.
And I also agree there are outstanding issues that have no proven solutions.

If we pick amongst the best practices today, and skip the problems to which
we have no clear solution, I personally believe that'll give us the most
immediate value, while paving the road for future improvements. I don't
believe we'll ever meet any higher standard to get started than has already
been met. 

-david 

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson
Sent: Monday, March 27, 2006 10:32 AM
To: henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter Pan'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Some comments on Use-cases document

Henry:

Do I need to tell that 4800 P2P google references have nothing to do with
P2P SIP?

Please let us not obfuscate the issues. You know, as well as, anyone sincere
about the value of standards, that the pre-mature standardization leads to
bad design as well as failure of the standards. As I mentioned there is no
compelling use case presented yet that says we need to "standardize" p2p sip
now without even bothering to get output from P2P IRTF group which is
looking into core issues of P2P research.  

Many would say that we first need an IETF standard for P2P file sharing
before we want to use "P2P" to design P2P SIP. We need more research on P2P
SIP before we standardize any particular "conspiracy" (I use conspiracy in
the sense of Karst definition of linking design with a particular DHT)

-mike

V! OIP and SIP Trainer and Consultant

Henry Sinnreich <henry at pulver.com> wrote:

Mike Robinson writes:

>How many research ! or analytical papers have been published in this area? 

I have found by Googling a reference listing 4,800 papers on P2P. Hopefully,
this enough to get us started. :-)

Henry

rates.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060327/5075e129/attachment-0001.html

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 27 Mar 2006 17:45:11 -0500

Hi Radhika,

Roy, Radhika R. wrote:
> I agree with David.
> 
>  
> 
> It is also NOT harm to linkage a particular design with a particular 
> DHT, if this is the good choice for a given time. However, other 
> proposals are also welcome. It is an open to all of us.
> 
>  
> 
> consensus to go for something that is good. With respect P2P-SIP, there 
> are a lot of things to be solved. However, if something provides 
> immediate value, as David and many others of this list have opined, what 
> is the problem for standardization? A better standard in the future can 
> always supersede an inferior standard of the past.
> 

I agree that it may be possible to upgrade or replace technologies or
algorithms later, but there are two caveats:

1) The base system has to be built in a way which allows upgrades and 
extensions.

2) Once there is a deployed base, it is tricky to avoid forklift 
upgrades (e.g. we see this today with IPv6).

So long as provisions are made to ensure compatibility with these goals,
it may be possible to create something now with extension or upgrade
in the future.

Greg

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Mon, 27 Mar 2006 16:14:15 -0800 (PST)

Radhika:

You agree that there are many problems  that are not resolved yet, and no solution is  available. That means more research needs to be done. Research belongs in the labs, Universities or in IRTF. 

It is not clear how you can change a DHT and still be compatible since SIP messages and headers fields are so much dependent on the type of underlying DHT used. The data maintained by each DHT is different and so are node insertion and removal procedures. I believe the security issues of each DHT types would also be different, so when someone says that they can replace DHT later on, they are just being too simplistic.

Do you really want to create OSPF versus IS-IS kind of two incompatible solutions?

--mike

"Roy, Radhika R." <RADHIKA.R.ROY at saic.com> wrote:          v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}           I agree with David.
   
  It is also NOT harm to linkage a particular design with a particular DHT, if this is the good choice for a given time. However, other proposals are also welcome. It is an open to all of us.
   
  Standardizations are always done throughout the world if there is a consensus to go for something that is good. With respect P2P-SIP, there are a lot of things to be solved. However, if something provides immediate value, as David and many others of this list have opined, what is the problem for standardization? A better standard in the future can always supersede an inferior standard of the past.
   
  Best regards,
  Radhika

---------------------------------
  
  From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
 Sent: Monday, March 27, 2006 2:40 PM
 To: 'Mike Robinson'; henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter Pan'
 Cc: p2p-sip at cs.columbia.edu
 Subject: Re: [p2p-sip] Some comments on Use-cases document

  I guess one view is the IETF should forever be relegated to the janitorial role of cleaning up after the party???s over.  But I believe the IETF can participate in and even promote the party through standardization.  I???d like the IETF to do more than simply formalize de facto standards, but actually create the standards that attract the party.  
   
  In the case of P2P-SIP, I entirely agree there are multiple, valid, proven ways to solve each of these problems ??? none of which is the clear victor.  And I also agree there are outstanding issues that have no proven solutions.
   
  If we pick amongst the best practices today, and skip the problems to which we have no clear solution, I personally believe that???ll give us the most immediate value, while paving the road for future improvements. I don???t believe we???ll ever meet any higher standard to get started than has already been met. 
   
  -david 

---------------------------------
  
  From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson

  
    Henry:

    Do I need to tell that 4800 P2P google references have nothing to do with P2P SIP?

    Please let us not obfuscate the issues. You know, as well as, anyone sincere about the value of standards, that the pre-mature standardization leads to bad design as well as failure of the standards. As I mentioned there is no compelling use case presented yet that says we need to "standardize" p2p sip now without even bothering to get output from P2P IRTF group which is looking into core issues of P2P research.  

    Many would say that we first need an IETF standard for P2P file sharing before we want to use "P2P" to design P2P SIP. We need more research on P2P SIP before we standardize any particular "conspiracy" (I use conspiracy in the sense of Karst definition of linking design with a particular DHT)

    -mike

  

      Mike Robinson writes:

    >How many research ! or analytical papers have been published in this area? 
  
      I have found by Googling a reference listing 4,800 papers on P2P. Hopefully, this enough to get us started. J
  
    Henry

    rates.

---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1&cent;/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060327/aa7807a4/attachment.html

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 27 Mar 2006 21:19:09 -0500

Mike Robinson wrote:

>
> Radhika:
>
> You agree that there are many problems that are not resolved yet, and 
> no solution is available. That means more research needs to be done. 
> Research belongs in the labs, Universities or in IRTF.
>
The P2P technologies are continusouly evolving and still various issues 
remain open. There was a good presentation about DHT in the technical 
plenary of IETF65, which pointed out many security issues of DHTs. 
However, the conclusion of the presentation was not "don't use DHT" but 
rather "use DHT with caution" to be simplified in my understanding.
A P2P-based VoIP service provider has more subscribers than any other 
VoIP providers currently. Other commercial developments related to P2P 
SIP are being released via news media. I think this is a quite strong 
signal calling for P2P SIP standardization efforts. The number of people 
who have been showing interest in P2P SIP last several IETF meetings is 
another signal, I think.

Novertheless, in general, I guess it is a quite subjective matter 
whether a particular technology is ready for standardization or its 
standardization is worth the effort. But I guess you can agree that it 
is not a good idea waiting for all the problems to be solved before 
standardization of anything.
Many protocols or technologies have been evolving even after the first 
version of their standards. It does not mean standardization of those 
protocols was a mistake or worthless.
Considering all the time we spent so far on discussions about various 
apsects of P2P SIP, I think we have passed the stage to say "there are 
lots of problems unsolved". Would it be too much if I ask for more 
concrete discussions like what tools we can develop, what use case can 
be supported in which manner, and what is the difficulty for a certain 
use case?

> It is not clear how you can change a DHT and still be compatible since 
> SIP messages and headers fields are so much dependent on the type of 
> underlying DHT used.

I thought you attended the P2P SIP ad-hoc meeting in Dallas but maybe I 
was confused.
What you are describing above is based on a certain approach. Please 
check the presentation about a P2P SIP architecture made during the 
ad-hoc meeting in Dallas. The presentation is available in the IETF65 
agenda and presentation page. You can find a different approach that 
enables a modular design in which the underlying DHT or an overlay 
algorithm can be changed without affecting the SIP messages.

> The data maintained by each DHT is different and so are node insertion 
> and removal procedures. I believe the security issues of each DHT 
> types would also be different, so when someone says that they can 
> replace DHT later on, they are just being too simplistic.
>
I think what Radhika meant was that different P2P SIP domains could use 
different DHTs. OSPF and IS-IS won't be together in the same domain but 
each can be used in different domains. Same approach for P2P SIP. Again 
please check the P2P SIP architecture presentation in the ad-hoc meeting.

I respect your concern regarding P2P SIP standardization. Such concern 
was expressed back in the first P2P SIP ad-hoc meeting in March last 
year. We have come a long way since then to have a proposed charter and 
the BOF in Dallas.

I hope we move forward.
Thanks.

Eunsoo
ps)I think David made really good points.

>
> */"Roy, Radhika R." <RADHIKA.R.ROY at saic.com>/* wrote:
>
>     I agree with David.
>     It is also NOT harm to link! age a particular design with a
>     particular DHT, if this is the good choice for a given time.
>     However, other proposals are also welcome. It is an open to all of us.
>     Standardizations are always done throughout the world if there is
>     a consensus to go for something that is good. With respect
>     P2P-SIP, there are a lot of things to be solved. However, if
>     something provides immediate value, as David and many others of
>     this list have opined, what is the problem for standardization? A
>     better standard in the future can always supersede an inferior
>     standard of the past.
>     Best regards,
>     Radhika
>     ------------------------------------------------------------------------
>     *From:* p2p-sip-bounces at cs.columbia.edu
>     [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *David Barrett
>     *Sent:* Monday, March 27, 2006 2:40 PM
>     *To:* 'Mike Robinson'; henry at pulver.com; 'Karst Bjorgson'; 'Kyara
>     Yamamoto'; 'Peter Pan'
>     *Cc:* p2p-sip at cs.columbia.edu
>     *Subject:* Re: [p2p-sip] Some comments on Use-cases document
>     I guess one view is the IETF should forever be relegated to the j!
>     anitorial role of cleaning up after the party???s over. But I
>     believe the IETF can participate in and even promote the party
>     through standardization. I???d like the IETF to do more than
>     simply formalize de facto standards, but actually create the
>     standards that attract the party.
>     In the case of P2P-SIP, I entirely agree there are multiple,
>     valid, proven ways to solve each of these problems ??? none of
>     which is the clear victor. And I also agree there are outstanding
>     issues that have no proven solutions.
>     If we pick amongst the best practices today, and skip the problems
>     to which we have no clear solution, I personally believe that???ll
>     give us the most immediate value, while paving the road for future
>     improvements. I don???t believe we???ll ever meet any higher
>     standard to get started than has already been met.
>     -david
>     ------------------------------------------------------------------------
>     *From:* p2p-sip-bounces at cs.columbia.edu
>     [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *Mike Robinson
>     *Sent:* Monday, March 27, 2006 10:32 AM
>     *To:* henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter
>     Pan'
>     *Cc:* p2p-sip at cs.columbia.edu
>     *Subject:* Re: [p2p-sip] Some comments on Use-cases document
>     Henry:
>     Do I need to tell that 48! 00 P2P google references have nothing
>     to do with P2P SIP?
>     Please let us not obfuscate the issues. You know, as well as,
>     anyone sincere about the value of standards, that the pre-mature
>     standardization leads to bad design as well as failure of the
>     standards. As I mentioned there is no compelling use case
>     presented yet that says we need to "standardize" p2p sip now
>     without even bothering to get output from P2P IRTF group which is
>     Many would say that we first need an IETF standard for P2P file
>     sharing before we want to use "P2P" to design P2P SIP. We need
>     more research on P2P SIP before we standardize any particular
>     "conspiracy" (I use conspiracy in the sense of Karst definition of
>     linking design with a particular DHT)
>     -mike
>     */Henry Sinnreich <henry at pulver.com>/* wrote:
>
>         Mike Robinson writes:
>         I have found by Googling a reference listing 4,800 papers on
>         P2P. Hopefully, this enough to get us started. J
>         Henry
>
>     rates.
>
>
> ------------------------------------------------------------------------
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great 
> rates starting at 1?/min. 
> <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com> 
>
>
>
> <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>
>------------------------------------------------------------------------
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>
>

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 28 Mar 2006 11:07:38 -0500

Hi Mike

> Research belongs in the labs, Universities or in IRTF.

Thank goodness Universities are partnering with industry then,
to focus the effort on practical solutions ;)

I actually differ on this point, in that I do think there
are valid prototypes, as well as examples of structured
overlay network deployments which meet quite a few of our
needs.

> underlying DHT used. The data maintained by each DHT is different and so 
> are node insertion and removal procedures. I believe the security issues 
> of each DHT types would also be different, so when someone says that 
> they can replace DHT later on, they are just being too simplistic.

I think you're assuming a particular model here.  If the SIP
messages are the container for the peer-to-peer messages, then
you may be right.

Replacing the overlay algorithm isn't trivial, but neither should
it be the focus of all our efforts (ensuring that the hooks are there
is more likely to be useful).

> Do you really want to create OSPF versus IS-IS kind of two incompatible 

Please be aware that the incompatibility you mention is _not_ a problem,
as it's firmly tied to administrative boundaries.  Therefore,
within the domain, it is an administrative decision as to which protocol
to deploy, that best suits the situation.  Forwarding between domains
isn't affected.

At this stage, draft-shim-sipping-p2p-arch-00.txt proposes that
we use CS/SIP to cross admin domain boundaries. Perhaps this is
equivalent to the differentiation seen in the interior
routing/exterior routing problem?

What we may want to be able to do with peer-to-peer functions
in the future is create the kind of distinction found between
OSPF and BGP (rather than OSPF and ISIS).  Please remember we
started with RIP, and only had to tweak the forwarding algorithms
later to do VLSM.

Greg
P2P-SIP conspiracy member.

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Wed, 29 Mar 2006 21:18:09 -0800 (PST)

Eunsoo wrote

> VoIP providers currently. 

>Other commercial developments related to P2P SIP are being released via > news media.

What does it really prove?  Let us see.

Unfortunately, you are  equating Skype  VoIP over  P2P with your version of p2psip. "P2P VOIP (as in skype) works" is neither a proof nor a validation of your p2p sip design since skype is not based on p2p sip. Besides,   it  is not a pure p2p solution in a strict sense. Skype documentation also lists a number of optimizations that go far beyond signaling a session to get the better voice quality. Please see their site for more details.

Actually, without having some support from an infrastructure provider (or always connected nodes in the public domain) it may not be even possible to run a pure p2p voip system beyond your organization. You have issues of NAT traversal, authentication and  certification management  that cannot be simply washed away. Both Krishna Sankar and Karst raised a number of technical issues.  

May be what IETF needs a VOIP over P2P forum, rather than P2P SIP group.
In the p2p sip, all you are using p2p overlay is for resolving URI into end point 
IP addresses.  That can be done in many ways, and SIP can be used in the unmodified way as it is. It may be possible that you don't even need to tinker much with SIP (johnson's draft discusses one such possibility). 

In addition, using  p2p overlay to resolve URIs does not solve  voice quality issues, and I think Krishna Sankar articulated those issues very well. So, if you believe in skype, that means that you need voip over p2p group that looks into broader issues than the proposed p2p sip group.

--mike

I hope we move forward.
Thanks.

Eunsoo

>
> */"Roy, Radhika R." /* wrote:
>
>     I agree with David.
>     */Henry Sinnreich /* wrote:
>
>         Mike Robinson writes:
> rates starting at 1???/min. 
>  
>
>
>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060330/ac5466c5/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 30 Mar 2006 10:20:48 -0800

it has been suffocating after the proposed decisions #1 - #4 :-(

very curious if anyone here ever assign himself with a simpler p2p project
like cloning dango skype in p2p-sip, image himself the only militia, and
walk his mind (&hands) thru entire design cycle toward commercializability?

maybe a down-to-earth approach can help uncover problems in current p2p-sip
direction.

egs,

* do sip retransmission scheme and backoff timers fit well in p2p arena?
(some p2p msgs need no retransmission)
* what if a sip/udp packet exceeds MTU with appended p2p info (eg,
finger/k-bucket entries)?
* can p2p-sip keep incremental paces (and "religion") after strong security
and distributed databases are added to the overlayS in later phases?
* even if it imaginably can, will it be imaginably efficient and
competitive? (h323 and Jabber fans criticize protocol efficiency of sip even
with sigcomp)
* autonomous certificate management...etc

me feel the p2p-sip topic definitely not SOSIMPLE...

peter
----- Original Message -----
From: Mike Robinson
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Sent: Wednesday, March 29, 2006 9:18 PM
Subject: Re: [p2p-sip] Some comments on Use-cases document

Eunsoo wrote

Unfortunately, you are  equating Skype  VoIP over  P2P with your version of
p2psip. "P2P VOIP (as in skype) works" is neither a proof nor a validation
of your p2p sip design since skype is not based on p2p sip. Besides,   it
is not a pure p2p solution in a strict sense. Skype documentation also lists
a number of optimizations that go far beyond signaling a session to get the
better voice quality. Please see their site for more details.

Actually, without having some support from an infrastructure provider (or
always connected nodes in the public domain) it may not be even possible to
run a pure p2p voip system beyond your organization. You have issues! of NAT
traversal, authentication and  certification management  that cannot be
simply washed away. Both Krishna Sankar and Karst raised a number of
technical issues.

May be what IETF needs a VOIP over P2P forum, rather than P2P SIP group.
In the p2p sip, all you are using p2p overlay is for resolving URI into end
point
IP addresses.  That can be done in many ways, and SIP can be used in the
unmodified way as it is. It may be possible that you don't even need to
tinker much with SIP (johnson's draft discusses one such possibility).

In addition, using  p2p overlay to resolve URIs does not solve  voice
quality issues, and I think Krishna Sankar articulated those issues very
well. So, if you believe in skype, that means that you need voip over p2p
group that looks into broader issues than the proposed p2p sip group.

--mike

Eunsoo Shim <eunsoo at research.panasonic.com> wrote:

signal calling for P2! P SIP standardization efforts. The number of people

be supported in which ma! nner, and what is the difficulty for a certain
use case?

> types would also be different, so when someone says tha! t they can

I hope we move forward.
Thanks.

Eunsoo

> It is also NOT harm! to link! age a particular design with a
> *Sent:* Monday, March 27, 2006 2:40 PM> *To:* 'Mike Robinson';
henry at pulver.com; 'Karst Bjorgson'; 'Kyara
> Please let us not obfuscate the issues. You ! know, as well as,
>>How many! research ! or analytical papers have been published
> in this area?

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1?/min.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 30 Mar 2006 16:28:56 -0500

Mike Robinson wrote:

> Unfortunately, you are equating Skype VoIP over P2P with your version 
> of p2psip. "P2P VOIP (as in skype) works" is neither a proof nor a 
> validation of your p2p sip design since skype is not based on p2p sip. 
> Besides, it is not a pure p2p solution in a strict sense.

I guess you mean something without any kind of central entity by 'pure 
p2p solution in a strict sense'. If you review discussions in the past 
P2P SIP ad-hoc meetings and in the mailing list, you may find out that 
the group is quite open for assuming some limited central entities, in 
particular, for authentication. As the proposed charter suggests, many 
people think a distributed identity management is a hard problem and the 
group should not try to standardize a protocol for that w.r.t. P2P SIP.

> Skype documentation also lists a number of optimizations that go far 
> beyond signaling a session to get the better voice quality. Please see 
> their site for more details.
>
> Actually, without having some support from an infrastructure provider 
> (or always connected nodes in the public domain) it may not be even 
> possible to run a pure p2p voip system beyond your organization. You 
> have issues! o! f NAT traversal, authentication and certification 
> management that cannot be simply washed away. Both Krishna Sankar and 
> Karst raised a number of technical issues.

All those issues have been raised and discussed in the group from the 
beginning.

> May be what IETF needs a VOIP over P2P forum, rather than P2P SIP group.

I guess you mean a group to design a complete P2P VoIP system by 'a VoIP 
over P2P forum'. You may notice that IETF WGs do not design a complete 
system but design protocols that are components of systems or tools. It 
is (should be) applied to the P2P SIP group, too.

> IP addresses.

You are close. Basically the P2P overlay provides a resource location 
service for SIP. The resource could be UA (or user), TURN server, and so 
on.

> That can be done in many ways, and SIP can be used in the unmodified 
> way as it is.

That's the approach a number of people proposed.

> It may be possible that you don't even need to tinker much with SIP 
> (johnson's draft discusses one such possibility).
>
> quality issues,

Right. Neither SIP or P2P overlay protocol will solve voice quality 
issues. The group is not aimed to address voice quality issues.
For example, for voice quality, codec selection is important. The SDP 
can be used to notify the type of the codec. But you got to develop an 
algorithm to select a codec, which is not what an IETF WG does 
typically. You may need a better voice codec. It is not dealt with in 
the IETF, either. Please don't expect an IETF WG will address/do all 
those things.
This group is not supposed to address all kind of issues related to 
SIP-based P2P real-time media applications. The group should develop a 
few tools/components by which people can build a system.

> and I think Krishna Sankar articulated those issues very well. So, if 
> you believe in skype, that means that you need voip over p2p group 
> that looks into broader issues than the proposed p2p sip group.
>
Again, I understand there are broader issues than what is covered by the 
proposed charter. Actually that is the purpose of the charter --- 
narrowing down and defining a limited scope/deliverables.

Thanks.

Eunsoo

>
>
>
>
> */Eunsoo Shim <eunsoo at research.panasonic.com>/* wrote:
>
>     Mike Robinson wrote:
>
>     >
>     > Radhika:
>     >
>     signal calling for P2! P ! SIP standardization efforts. The number
>     of people
>     be supported in which ma! nn! er, and what is the difficulty for a
>     certain
>     use case?
>
>     > types would also be different, so when someone says tha! t !
>     they can
>     > It is also NOT harm! t! o link! age a particular design with a
>     > Please let us not obfuscate the issues. You ! kn! ow, as well as,
>     >>How many! r! esearch ! or analytical papers have been published
>     > in this area?