Subject: Re: [P2PSIP] Question on additional services

From: Krzysztof Hennig <[email-masked]>
Date: Mon, 2 Jul 2007 02:14:52 -0700 (PDT)

Hi Victor,

In general DHT may keep any type of mapping you want
to store. Current discussion covers only storing AoR
<-> Contact URI mapping. It may also store presence
status, xcap profiles, waiting instant messages and
others. 

Our research team is focusing on providing Value Addes
Services for P2P SIP. One of such scenarios is Voice
Mail based on presence.

In the this case we have been thinking of an agent
(say Service Agent) that is responsible for Service
State for one specific user, in this scenario: voice
calls. The Service Agent is selected randomly as usual
in P2P eg. during bootstraping process. Then this
agent could make Call Forwarding decisions. 

To add new services we were thinking of other Agent
(say Profile Agent) that would keep user's profile
(xcap, presence, other parameter). That agent would
provide Service Agents with some parameters that
Service Agents could use to determine Call Forwarding
decisions. 

Each service could have some parameters as URN to
define it's specific behavior. As an example proposed
LOCSER SIP method could be reused to lookup users
Profile Agent and fetch users profile by Service
Agents. It would work like OPTIONS but would query for
user's capabilities rather that users device
capabilities.

End user could publish, update or remove it's profile
by this method. Again LOCSER could be reused.

I know that above solution causes big overhead on
communication and peer node performance but enables
more services to be deployed more quickly. 
Beside this above scenario has lots of security issues
eg. how to allow 3rd party to store data on your peer
node? In addition a open framework for Service to URN
mapping has to be developed.

In GSM Architecture such agents are: Home Location
Register (as PA), Visited MSC (as SA). In IMS
architecture such agents are: Home Subscriber Server
(as PA), S-CSCF (as AS). Do we need to follow this
architecture?

Our team has not yet defined where in the P2P
reference model (concepts-04) all above agents would
be placed. However, architecture it would be
distributed for sure!

Does anyone have thoughts about this vision?

kind regards!
Krzysztof
+48 601 134 075

--- Victor Pascual Ávila
<[email-masked]> wrote:

> Hello,
> As far as I know, DHT is as a distributed database
> used to store the
> information required to provide the mapping between
> AoRs and Contact URIs.
> It is exepected that DHT may also store information
> required to provide
> other services required to form and operate or just
> enhance basic
> functionalities.
> Should these additional services be distributed? So
> that the loss of a peer
> does not result in the loss of a service.
> 
> 
> Thanks in advance,
> Victor Pascual
> > _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 

____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 2 Jul 2007 14:43:02 +0200

Hi Krzysztof,
thank you for your explanation.

> Does anyone have thoughts about this vision?

IMHO, using SOA (service oriented architecture) makes sense. DHT could act
as 'Service broker', 'n' Agents could act as a 'service provider' and 'n*m'
Agents could act as a 'service implementor'. Then 'Service providers' could
be able to publish (using the DHT) services implemented by 'service
implementors'.
Does it make sense???

Thanks in advance,
Victor Pascual

---

From: Krzysztof Hennig <[email-masked]>
Date: Mon, 2 Jul 2007 13:53:17 -0700 (PDT)

Hi Victor Pascual,
I can agree with you. SOA approach makes sense.
However  SOA as it is shown in enterprise environment
in my opinion is not a goot choice. We need something
simpler but also service oriented.

I see that above DHT (routing & storage layer in P2P
SIP) there must exist some entities which may work as
a service provider, service implementor or service
data storage. I may misunderstand the way you
described SOA, but in all systems I learned there has
been always a processing node and storage node. Can
you please describe 'service provider', 'service
implementor' a bit more from functional point of view?
Where in your model are A-party UA and B-party UA? How
do they set up  a service profile?

IMHO we also have to think wether we need only simple
profile/parameter fetch or full orchestration between
controlling peer and service data peer. The latter
scenario seems more flexible however requires more CPU
on service handling peer, more bandwidth to pass all
messages and causes longer delays in processing. In my
opinion the latter case is not suitable for case when
peer is located in radio network (see discussion about
battery life). 

I am also not convinced wether exchanging big XML
documents describing service profile is a good
solution. Issues are the same: CPU, bandwidth and
delays. If we provide a lightweight mechnism for this
(eg. XPath), we could put service controlling entity
in a mobile handset with limited battery capabilities.

Taking into consideration all above I have a feeling
that we are getting closer to C/S model instead of
distributing it among peers. Even worse, it looks like
the control point is somewhere in the network but not
in the end UA's as it is today within the Internet
with HTTP. Do you have the same feeling? 

We can conclude that at least we have to work out a
naming convention for service entities or agents to
understand each other. What do you think ? Is there
already any draft, framework or concept within P2PSIP
covering this?

kind regards!
/Krzysztof

--- Victor Pascual Ávila

       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Tue, 3 Jul 2007 11:34:03 -0400

Krzysztof, 

How about using something like IP Multimedia Subsystem (IMS) from 3GPP, but exactly the same. IMS is SIP based, service orientated, and access independent. It can implement what you asked for, e.g. set up a service profile, orchestration between controlling peer and service data peer, etc. 

It is just a thought, I may misunderstand your intention.

Thanks,
Sherry 

-----Original Message-----
From: Krzysztof Hennig [mailto:[email-masked]] 
Sent: Monday, July 02, 2007 4:53 PM
To: Victor Pascual "Ávila
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Question on additional services

Hi Victor Pascual,
I can agree with you. SOA approach makes sense.
However  SOA as it is shown in enterprise environment in my opinion is not a goot choice. We need something simpler but also service oriented.

I see that above DHT (routing & storage layer in P2P
SIP) there must exist some entities which may work as a service provider, service implementor or service data storage. I may misunderstand the way you described SOA, but in all systems I learned there has been always a processing node and storage node. Can you please describe 'service provider', 'service implementor' a bit more from functional point of view?
Where in your model are A-party UA and B-party UA? How do they set up  a service profile?

IMHO we also have to think wether we need only simple profile/parameter fetch or full orchestration between controlling peer and service data peer. The latter scenario seems more flexible however requires more CPU on service handling peer, more bandwidth to pass all messages and causes longer delays in processing. In my opinion the latter case is not suitable for case when peer is located in radio network (see discussion about battery life). 

I am also not convinced wether exchanging big XML documents describing service profile is a good solution. Issues are the same: CPU, bandwidth and delays. If we provide a lightweight mechnism for this (eg. XPath), we could put service controlling entity in a mobile handset with limited battery capabilities.

Taking into consideration all above I have a feeling that we are getting closer to C/S model instead of distributing it among peers. Even worse, it looks like the control point is somewhere in the network but not in the end UA's as it is today within the Internet with HTTP. Do you have the same feeling? 

We can conclude that at least we have to work out a naming convention for service entities or agents to understand each other. What do you think ? Is there already any draft, framework or concept within P2PSIP covering this?

kind regards!
/Krzysztof

--- Victor Pascual Ávila
<[email-masked]> wrote:

> IMHO, using SOA (service oriented architecture) makes sense. DHT could 
> act as 'Service broker', 'n' Agents could act as a 'service provider' 
> and 'n*m'
> Agents could act as a 'service implementor'. Then 'Service providers' 
> could be able to publish (using the DHT) services implemented by 
> 'service implementors'.
> Does it make sense???
> 
> Thanks in advance,
> Victor Pascual
>

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Tue, 3 Jul 2007 11:40:54 -0400

Ooops, it should be "but NOT the exactly same". 

Thanks,
Sherry 

-----Original Message-----
From: Wang, XiaoXiao (Sherry) [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 11:34 AM
To: Krzysztof Hennig; Victor Pascual "Ávila
Cc: P2PSIP Mailing List
Subject: RE: [P2PSIP] Question on additional services

Krzysztof, 

Thanks,
Sherry 

-----Original Message-----
From: Krzysztof Hennig [mailto:[email-masked]]
Sent: Monday, July 02, 2007 4:53 PM
To: Victor Pascual "Ávila
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Question on additional services

Hi Victor Pascual,

kind regards!
/Krzysztof

--- Victor Pascual Ávila

---

From: Krzysztof Hennig <[email-masked]>
Date: Tue, 3 Jul 2007 14:18:06 -0700 (PDT)

Hi Sherry,

I borrowed my proposal from 3GPP IMS architecture
where you have CSCF and HSS as handling and profile
node respectively. I have even written it as an
example in my first email. Such architecture can be
found in many systems since gives lots of flexibility
and scalability, at least in C/S approach. I haven't
considered it deeply in P2P, but might be
interresting.

To be more general I think we should focus on
orchestration. I haven't considered yet how to
organise it in totally distributed systems. The 3GPP
is working on it within IMS. They have introduced a
SCIM function - service Capability Interaction
Manager. 
http://en.wikipedia.org/wiki/Service_Capability_Interaction_Manager
I will focus on it in my further research and give
some feedback on the mailing list.

Have a nice day!
Krzysztof

--- "Wang, XiaoXiao (Sherry)" <[email-masked]>
wrote:

> Krzysztof, 
> 
> How about using something like IP Multimedia
> Subsystem (IMS) from 3GPP, but exactly the same. IMS
> is SIP based, service orientated, and access
> independent. It can implement what you asked for,
> e.g. set up a service profile, orchestration between
> controlling peer and service data peer, etc. 
> 
> However  SOA as it is shown in enterprise
> environment in my opinion is not a goot choice. We
> need something simpler but also service oriented.
> 
> SIP) there must exist some entities which may work
> as a service provider, service implementor or
> service data storage. I may misunderstand the way
> you described SOA, but in all systems I learned
> there has been always a processing node and storage
> node. Can you please describe 'service provider',
> 'service implementor' a bit more from functional
> point of view?
> IMHO we also have to think wether we need only
> simple profile/parameter fetch or full orchestration
> between controlling peer and service data peer. The
> latter scenario seems more flexible however requires
> more CPU on service handling peer, more bandwidth to
> pass all messages and causes longer delays in
> processing. In my opinion the latter case is not
> suitable for case when peer is located in radio
> network (see discussion about battery life). 
> 
> delays. If we provide a lightweight mechnism for
> this (eg. XPath), we could put service controlling
> entity in a mobile handset with limited battery
> capabilities.
> 
> distributing it among peers. Even worse, it looks
> like the control point is somewhere in the network
> but not in the end UA's as it is today within the
> Internet with HTTP. Do you have the same feeling? 
> 
> already any draft, framework or concept within
> P2PSIP covering this?
> 
> kind regards!
> /Krzysztof
> 
> --- Victor Pascual Ávila
> Boardwalk for $500? In 2007? Ha! Play Monopoly Here
> and Now (it's updated for today's economy) at Yahoo!
> Games.
>

____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Tue, 3 Jul 2007 23:45:54 -0400

Krzysztof,

I totally agree with you. That's why I said "IMS-like", because IMS has some elements that we can borrow. However, its client/server model (centralized) is a major issue. I was fighting it for a while. That is the reason for me to join this P2P mailing list and to get some insights.

Thanks for the link and comments.
Sherry 

-----Original Message-----
From: Krzysztof Hennig [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 5:18 PM
To: Wang, XiaoXiao (Sherry)
Cc: P2PSIP Mailing List
Subject: RE: [P2PSIP] Question on additional services

Hi Sherry,

I borrowed my proposal from 3GPP IMS architecture where you have CSCF and HSS as handling and profile node respectively. I have even written it as an example in my first email. Such architecture can be found in many systems since gives lots of flexibility and scalability, at least in C/S approach. I haven't considered it deeply in P2P, but might be interresting.

To be more general I think we should focus on orchestration. I haven't considered yet how to organise it in totally distributed systems. The 3GPP is working on it within IMS. They have introduced a SCIM function - service Capability Interaction Manager. 
http://en.wikipedia.org/wiki/Service_Capability_Interaction_Manager
I will focus on it in my further research and give some feedback on the mailing list.

Have a nice day!
Krzysztof

wrote:

> Krzysztof,
> 
> How about using something like IP Multimedia Subsystem (IMS) from 
> 3GPP, but exactly the same. IMS is SIP based, service orientated, and 
> access independent. It can implement what you asked for, e.g. set up a 
> service profile, orchestration between controlling peer and service 
> data peer, etc.
> 
> However  SOA as it is shown in enterprise environment in my opinion is 
> not a goot choice. We need something simpler but also service 
> oriented.
> 
> SIP) there must exist some entities which may work as a service 
> provider, service implementor or service data storage. I may 
> misunderstand the way you described SOA, but in all systems I learned 
> there has been always a processing node and storage node. Can you 
> please describe 'service provider', 'service implementor' a bit more 
> from functional point of view?
> profile/parameter fetch or full orchestration between controlling peer 
> and service data peer. The latter scenario seems more flexible however 
> requires more CPU on service handling peer, more bandwidth to pass all 
> messages and causes longer delays in processing. In my opinion the 
> latter case is not suitable for case when peer is located in radio 
> I am also not convinced wether exchanging big XML documents describing 
> service profile is a good solution. Issues are the same: CPU, 
> bandwidth and delays. If we provide a lightweight mechnism for this 
> (eg. XPath), we could put service controlling entity in a mobile 
> handset with limited battery capabilities.
> 
> Taking into consideration all above I have a feeling that we are 
> getting closer to C/S model instead of distributing it among peers. 
> Even worse, it looks like the control point is somewhere in the 
> network but not in the end UA's as it is today within the Internet 
> We can conclude that at least we have to work out a naming convention 
> for service entities or agents to understand each other. What do you 
> think ? Is there already any draft, framework or concept within P2PSIP 
> covering this?
> 
> kind regards!
> /Krzysztof
> 
> --- Victor Pascual Ávila
> Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's 
> updated for today's economy) at Yahoo!
> Games.
>