RE: [nmrg] another possible subject for the nmrg workshop on voip management

["Jean-Francois Mule" <[e-mail]>]

Juergen and all,

   Interesting discussion. Here's some personal input.

Juergen asked:
> > a) Is there general interest to have such a workshop?
Yes, on my side: absolutely.

You also asked:
> > I willing to spend cycles to organize such an event. But I need your 
> > help to get the right people together and I need strong indications 
> > that there is enough interest to justify time investment.

   There were good discussions from all about the decoupling of the voip service provider from the network provider and whether we mean "management" in a user-driven model or a service provider-driven model. I would agree wholeheartdly with Cullen, that in either case, consumers would benefit from more "management" capabilities at the application (V in VoIP) and (o in VoIP)network layers (IP in VoIP).
To build on an example from Henry, my cell phone has some kind of indicators of connectivity to the BSC/MSC via those bars that mean something to the end users (remember the cool AT&T wireless ad for the mass during the olympics).

   Topics of interest to me:
	- device provisioning models using web services-like interfaces (that may be where we could plug in the netconf/webdav/sip xcap/sip config framework discussions). Some of the mentioned VoIP services (Vonage, skype) hardcode some info in the devices... There should be models here that could allow users and/or operators to configure pieces of the service definition in a flexible manner (the operator does http download of the config params upon service activation or device boot up - params described in an extensible langage format, while as an end-user, I fire up my firefox browser and for the same device, I allow tell the device that if my personal pref is to use encrypted sig and media for all my communications but if my son logs in on that sip device, he is ok with no sRTP). May be that is bad example but you see the range of options.

	- device management behind NATs and firewalls: 
this is something that is not specific to VoIP.
    a) how can users or service providers get devices behind NATs and firewalls to return some useful information about their status (provisioning status, led status, software upgrade mode, etc.), the service state (SIP, presence, etc.), the network state as perceived by the device (this is where I think we missed some points earlier), the voice quality status (rtcp xr rfc3611), etc. -- equivalent to snmp get/get bulk
    b) how can users or service providers get devices to change an entire config file or just one parameter -- snmp set
SNNP is not going to cut it even in well-"behave"d environments. As an end-user, I basically have to ssh in my home net to then get a view of my ip services using CLI. I can live with it but shouldn't we have higher goals (to manage large scale voip networks with various service control models)?
If this is a done deal and defined somewhere, btw - let me know, this is a priority for us.

In SIP, we're starting to see interesting models: use the established signaling links to trigger the device to push some data back. Is this a viable and scalable model to manage IP-based services behind NATs?
There is a bunch of toolkits using various ietf protocols out there that we can leverage but getting some folks talk about their needs/requirements and some others talk about how they would like to manage networks would help define some directions (and some conclusions may be - do nothing but I highly doubt it).

	- mechanisms to secure software download (device config file, device code image): 
is it: 
http://ietfreport.isoc.org/all-ids/draft-housley-cms-fw-wrap-11.txt
Or, is it what the cable MSOs and CableLabs have defined it for cable modems and packetcable voip devices deployed in millions using the poorly secured tftp or more suitable http/https protocols?
Or something else for sip-based voip networks?
Again, it still matters for user models (I may like to run an open source tool on my linux home server that can serve my pingtel phone as well as my fwd client and my instant messaging client - all of which share what outbound sip proxy they use on my home network, where to send incoming sip event notifications to based on where I am), etc.
As a device manufacturer, some vendors may appreciate having not one way but a number of guidelines for a couple ways of doing those kinds of things the same way for residential/enterprise/service provider environments, whether they sell sip boxes to provider x, enterprise y or to user b. And may be this would allow me to run a cvs diff on all my device config files to make sure nobody hacked into them and uploaded a hacked config file that allows them to make voice calls on my behalf.

All I can say is that I think we would benefit from some guidance on how to do things better here so that we don't develop multiple methods of doing the same thing.

Jean-Francois 
---
Jean-François Mulé
CableLabs
office: [phone]
email: [e-mail]