Subject: [BLISS] Welcome! Main question - what services?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Jan 2007 17:14:36 -0500

If you haven't done so already, everyone please take a look at the charter:

http://sip101.net/charter.html

In my mind, the main question to be answered is what features we want to 
work on, and in what order. We've chosen four to begin with - BLA, 
pickup, DND, and CCBS, since these have been reported to be the most 
problematic.

If anyone has comments on different ones they'd like to see worked on, 
please comment. Especially welcome are examples of REAL interop problems 
or hacks that have been put into place in real implementations and 
deployments to make something happen.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Jan 2007 16:50:56 -0600

Looks good.

I'm not sure I like the text for DND equating it to "ingnore an incoming
call".

In some implementations, "Do Not Disturb", "Ignore" and "Decline" are
different concepts. Your 
description after is good because it hints at what the issues are.

I'd suggest item 3 be renamed "Do Not Disturb/Ignore/Decline/Reject" or
something along those 
lines. It's the suttle differences between those that is important.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 14:15
> To: [email-masked]
> Subject: [BLISS] Welcome! Main question - what services?
> 
> In my mind, the main question to be answered is what features 
> we want to work on, and in what order. We've chosen four to 
> begin with - BLA, pickup, DND, and CCBS, since these have 
> been reported to be the most problematic.
> 
> If anyone has comments on different ones they'd like to see 
> worked on, please comment. Especially welcome are examples of 
> REAL interop problems or hacks that have been put into place 
> in real implementations and deployments to make something happen.
> 
> Thanks,
> Jonathan R.
> --

---

From: Alan Johnston <[email-masked]>
Date: Fri, 19 Jan 2007 16:59:13 -0600

Those four are good to start with.

I'm hearing a lot of interest in SIP enabling contact centers (or call 
centers).  This requires a few things:

1. A good description of the problem space and the requirements
2. Remote call control capabilities
3. Ability to pass around call related information between elements

I have not yet attempted #1 yet, although I do plan to work on it with 
others who understand the service well (volunteers?)
For #2, I think draft-mahy-sip-remote-cc-04 is a very good start.  
Perhaps this group can demonstrate that there is interest and need for 
these REFER extensions so they can be worked in the SIP WG.  For #3, I 
wrote a partial solution in draft-johnston-sipping-cc-uui-01.  I think 
if we put effort into #1 it will become clearer what mechanism is best, 
so I would describe this draft as an example mechanism that is out there 
rather than the right mechanism.

I think this is a very interesting problem to work on.  The non-SIP 
solutions today are completely proprietary, so there is a huge 
opportunity to make a big impact on the industry if we can deliver the 
same functionality using open standards and SIP. 

However, I would expect to spend a good deal of time on requirements and 
use cases before we even started on mechanisms.

Thanks,
Alan

Jonathan Rosenberg wrote:
> In my mind, the main question to be answered is what features we want 
> to work on, and in what order. We've chosen four to begin with - BLA, 
> please comment. Especially welcome are examples of REAL interop 
> problems or hacks that have been put into place in real 
> implementations and deployments to make something happen.
>
> Thanks,
> Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Jan 2007 17:26:47 -0600

Sounds reasonable to me. 

> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 14:59
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [BLISS] Welcome! Main question - what services?
> 
> I'm hearing a lot of interest in SIP enabling contact centers 
> (or call centers).  This requires a few things:
> 
> 1. A good description of the problem space and the 
> requirements 2. Remote call control capabilities 3. Ability 
> to pass around call related information between elements
> 
> I have not yet attempted #1 yet, although I do plan to work 
> on it with others who understand the service well 
> (volunteers?) For #2, I think draft-mahy-sip-remote-cc-04 is 
> a very good start.  
> Perhaps this group can demonstrate that there is interest and 
> need for these REFER extensions so they can be worked in the 
> SIP WG.  For #3, I wrote a partial solution in 
> draft-johnston-sipping-cc-uui-01.  I think if we put effort 
> into #1 it will become clearer what mechanism is best, so I 
> would describe this draft as an example mechanism that is out 
> there rather than the right mechanism.
> 
> I think this is a very interesting problem to work on.  The 
> non-SIP solutions today are completely proprietary, so there 
> is a huge opportunity to make a big impact on the industry if 
> we can deliver the same functionality using open standards and SIP. 
> 
> However, I would expect to spend a good deal of time on 
> requirements and use cases before we even started on mechanisms.
> 
> Thanks,
> Alan
> 
> worked on,

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Jan 2007 21:43:41 -0600

I agree with Francois' suggestion for renaming item 3. If we all agreed on 
what DND was, we wouldn't be having this conversation :-)

Spencer

From: "Francois Audet" <[email-masked]>

Looks good.

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 20 Jan 2007 12:41:58 +0200

I think it is reasonable to work on the approach that you propose, 
Jonathan. I have a couple of questions and comments about the proposed 
charter.

1) When the charter speaks about heterogeneous networks, does it refer 
only to SIP networks or does it consider interoperability across, say, 
the PSTN. I am sure the TISPAN guys will ask this question sooner or 
later, so better to write the answer, whatever it is, in the charter.

2) About DND. By reading the description I wasn't able to find any 
interoperability issues. Well, it is later described in the Issue. 
Perhaps the description should also add "... and associated triggers for 
other services" or something like that. A

3) A question on DND... I suspect that some people are implementing DND 
in a server... I think PoC has something similar, so the question is 
whether this service is going to consider also a "service that allows a 
callee to provide instructions to a server to ignore certain types of 
calls" or does it consider only a device centric approach?

I am fine with the initial set of proposed services.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sun, 21 Jan 2007 11:32:01 -0600

We are very interested in Call Centers and I would be willing to help. 

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 5:59 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

Thanks,
Alan

---

From: [email-masked]
Date: Sun, 21 Jan 2007 12:59:57 -0500

Hi,

It is really a good idea to have well-defined service behaviour for better 
interoperability among SIP implementation.

I think the major problem that has been faced by almost every PBX vendor 
is how to make particular service working using feature codes. There is no 
clear method in SIP to communicate feature codes from SIP UA to PBX. Some 
uses INFO method, some NOTIFY ,and generally proprietary extensions to 
communicate that information. Since SIP recommends using RFC 2833 for DTMF 
digits, some guidelines should be provided for SIP UA as well as PBX 
provider to pass this information.

For example, call park and unpark example given simply says call is put on 
hold and retrieve from nay other extension. But generally service 
providers ask user to dial particular park extension to park the call and 
another extension can dial that number to unpark the call. Again question 
arises how user dial park extension while call is active. If we can 
resolve this basic issue, it will really interop features easily among PBX 
vendors.

We have mentioned Call park/pickup service, generally it is call 
park/unpark service. There is another directed pickup service available 
where user can pickup a call ringing on another extension by dialing 
pickup code.

ACD/HG definitely requires attention as part of call center applications 
as it is getting more popular because of SIP wifi phones becoming as ACD 
agents roaming around in office. We are also willing to help for call 
center applications.

What about MWB service (monitor whisper and barge-in)?

-Udit

"Dolly, Martin C, ALABS" <[email-masked]> 
01/21/2007 12:32 PM

To
"Alan Johnston" <[email-masked]>, "Jonathan Rosenberg" 
<[email-masked]>
cc
[email-masked]
Subject
RE: [BLISS] Welcome! Main question - what services?

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]]
Sent: Friday, January 19, 2007 5:59 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

Thanks,
Alan

---

From: "Mohammad Al-Taraireh \(maltarai\)" <[email-masked]>
Date: Mon, 22 Jan 2007 10:01:07 -0500

Hi Jonathan,

The charter looks good, I am wondering if charter should also include
identifying the minimum set of primitives, and SIP functionality that a
UA must support to build the services that charter highlights. For
example the support for basic call using early or delayed offer,
Hold/Resume,..etc.

Thanks,

Mo

-----Original Message-----
From: Jonathan Rosenberg (jdrosen) 
Sent: Friday, January 19, 2007 5:15 PM
To: [email-masked]
Subject: [BLISS] Welcome! Main question - what services?

If you haven't done so already, everyone please take a look at the
charter:

Thanks,
Jonathan R.

---

From: "Sunil Veluvali" <[email-masked]>
Date: Mon, 22 Jan 2007 10:00:26 -0800

Hi,

One approach to consider is to discuss a set of core user agent services
that can help solve some of the common interoperability issues.  This
will allow vendors to effectively interoperate and at the same time
satisfy their own unique feature variants (which is going to be the
case) that their product/solution demands. 

I see the need for interoperability in the following four broad
categories (w/capabilities) that an UA should offer:

1. Dial-Out Services:

-- The ability for an UA to place a call from an external agent on
behalf of the user.
-- An interoperable mechanism to describe local data like redial
numbers, last call return, etc. 
-- An agreed upon approach to hotline or warmline capabilities.
-- A common language for describing star codes. They are not going away.

2. "Ring" or Alerting Services:

-- An agreed upon way to define and signal "ring types". Other
specializations include beep, flash (no ring).
-- Intercom/CallCenter type applications would require support for
auto-answer.
-- DND as already being discussed. If you consider mobile user agents,
we might also want to describe an interoperable mechanism for describing
an "offline" state.
-- A presence mechanism to allow network applications to signal calls
routed by the server due to a CPL instruction or other application.  

3. Digit Collection Services:

-- We need a simple mechanism for UAs to collect additional input from
the user based on the needs for network applications. Most applications
today route the call to a VXML server for additional dialog with the UA.

4. Applications Signaling:

-- Shared Line Appearances as discussed in the charter.
-- Support for ACD/CallCenter semantics: A common mechanism to
log-in/log-out of an ACD and makes oneself available/unavailable to take
calls.

Thanks,

Sunil Veluvali
Director of Engineering
Sylantro Systems
+1-408-626-2309

-----Original Message-----
From: Jonathan Rosenberg (jdrosen) 
Sent: Friday, January 19, 2007 5:15 PM
To: [email-masked]
Subject: [BLISS] Welcome! Main question - what services?

Thanks,
Jonathan R.

---

From: [email-masked]
Date: Mon, 22 Jan 2007 17:00:32 -0500

From: [email-masked]

In the sipX PBX, we haven't had much trouble with this.  As long as a
call isn't currently active on the phone, anything the user dials is
inserted into the outgoing request-URI, which the proxy can interpret
as it chooses.  For an example of using a dialing prefix (feature
code) to perform a call pickup, look at section 7 of
draft-worley-sipping-pickup-02.

Of course, if there is a call active, a user dial string can't be
interpreted by the proxy.  But in my experience, using a user dial
string to manipulate a current call is uncommon in traditional PBXs as
well, probably for the same reason -- the PBX digit listener is not
active at that time.

Dale

---

From: [email-masked]
Date: Mon, 22 Jan 2007 18:47:51 -0500

Hi Dale,

My main concern was for mid-call feature codes only. For example, call 
park will be done by dialing feature code followed by park extension when 
call is active, MWB etc.

For out of call, it is not a problem since Req-uri can always be used.

-Udit

[email-masked] 
01/22/2007 05:00 PM

To
[email-masked]
cc

Subject
Re: [BLISS] Welcome! Main question - what services?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jan 2007 19:24:32 -0500

[email-masked] wrote:
> park will be done by dialing feature code followed by park extension 
> when call is active, MWB etc.

Unless you mandate a particular service architecture (e.g. with a B2BUA 
feature server in every call, that is responsible for carrying out all 
features), I don't see how you can have a single mechanism for conveying 
"mid-call feature codes". In general the feature may be:
- fully implemented by the UA
- mostly implemented by some server in the signaling path,
   with the UA simply conveying an indication of request
- mostly implemented by some server not in the signaling
   path, with the UA signaling it in some way
- some combination of the above.

IMO you need an assortment of techniques, and the UA needs to know 
enough to choose which thing to do.

	Paul

> [email-masked]*
> 
> 01/22/2007 05:00 PM
> 
> 	
> To
> 	[email-masked]
> cc
> 	
> Subject
> ------------------------------------------------------------------------
>

---

From: "Sunil Veluvali" <[email-masked]>
Date: Mon, 22 Jan 2007 09:54:44 -0800

Hi,

1. Dial-Out Services:

Thanks,

Sunil Veluvali
Director of Engineering
Sylantro Systems
+1-408-626-2309

-----Original Message-----
From: Jonathan Rosenberg (jdrosen) 
Sent: Friday, January 19, 2007 5:15 PM
To: [email-masked]
Subject: [BLISS] Welcome! Main question - what services?

Thanks,
Jonathan R.

---

From: Jaimin Pancholi <[email-masked]>
Date: Tue, 23 Jan 2007 09:49:52 +0530

Some thoughts:

I think first we should list the services we need to address as part of this
forum !

After which we can divide them based on the Network Entity who need to
support the same.
i.e. some services can work by UA supporting it, Some services can work by
Server supporting it.

Once this categorization is done, it should be Okay to define the details.
For supporting complex services like IN services, I would prefer a B2BUA
with application logic
as it gives great freedom. The problem comes in inter-operatibility as the
related SIP Signaling and usage
of headers / content is not well defined due to which there are lot of
proprietary solutions available.

Cheers
Jaimin
System Architect
Huawei India R&D
Bangalore

Email Privacy Declaration
****************************************************************************
***********
	This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

>From: Sunil Veluvali [mailto:[email-masked]] 
>Sent: Monday, January 22, 2007 11:25 PM
>To: Jonathan Rosenberg (jdrosen); [email-masked]
>Subject: RE: [BLISS] Welcome! Main question - what services?
>
>Hi,
>
>One approach to consider is to discuss a set of core user 
>agent services that can help solve some of the common 
>interoperability issues.  This will allow vendors to 
>effectively interoperate and at the same time satisfy their 
>own unique feature variants (which is going to be the
>I see the need for interoperability in the following four 
>broad categories (w/capabilities) that an UA should offer:
>
>1. Dial-Out Services:
>
>-- The ability for an UA to place a call from an external 
>agent on behalf of the user.
>-- An interoperable mechanism to describe local data like 
>redial numbers, last call return, etc. 
>-- Intercom/CallCenter type applications would require support 
>for auto-answer.
>-- DND as already being discussed. If you consider mobile user 
>agents, we might also want to describe an interoperable 
>mechanism for describing an "offline" state.
>-- A presence mechanism to allow network applications to 
>signal calls routed by the server due to a CPL instruction or 
>other application.  
>
>-- We need a simple mechanism for UAs to collect additional 
>input from the user based on the needs for network 
>applications. Most applications today route the call to a VXML 
>server for additional dialog with the UA.
>
>
>log-in/log-out of an ACD and makes oneself 
>available/unavailable to take calls.
>
>Thanks,
>
>Sunil Veluvali
>Director of Engineering
>Sylantro Systems
>+1-408-626-2309
>
>begin with - BLA, pickup, DND, and CCBS, since these have been 
>reported to be the most problematic.
>

---

From: [email-masked]
Date: Tue, 23 Jan 2007 12:21:05 -0500

My main concern was for mid-call feature codes only. For example,
   call park will be done by dialing feature code followed by park
   extension when call is active, MWB etc.

I've never seen a system that did this.

What I've seen is systems where you "flash" (thus putting the current
call on hold, and getting a dial tone), and then dial a feature code
to operate on the call you just put on hold.

So in a sense, this is a mid-call feature code, but in another sense
(and closer to the protocol question), it's a new call.

If one wanted to implement such operations, the central question would
be associating the INVITE bearing the feature code as its request-URI
with the call on hold at the same UA.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:08:26 -0500

I think this discussion is indicative of EXACTLY the problem we are 
trying to solve.

Call park requires some kind of 'indication' to be emitted by the phone 
that signals a park request. There are many ways to do this:

1. Assuming PBX is a b2bua, the phone emits a DTMF feature code 
(rfc2833) on the call; this is captured by the PBX, interpreted as an 
invocation request, mapped to the park feature. The call is then parked 
at the PBX, and can be picked up elsewhere. I *think* this is the 
mechanism Udit is talking about.

2. Similar to 1, except invocation is done via some kind of signaling 
channel mechanism (INFO, proprietary methods, etc.)

3. Phone is a bit more intelligent, and knows the user wants to invoke 
Park. So, it REFERs to the park server, having it replace its call with 
the participant (as described in the service-examples draft)

4. conference mechanism; park is implemented by viewing the park server 
as a conference bridge. So, the invoking UA creates an ad-hoc conference 
bridge, transfers the correspondent into it.

and there are more.

I think its easy to see in this case how we have interop failures when a 
UA assumes one mechanism, and the PBX and other phones assume different 
ones, we have no hope of interop.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:15:11 -0500

> later, so better to write the answer, whatever it is, in the charter.

Its referring to SIP neworks. The heterogeneity refers to endpoints, 
which includes gateways to the PSTN. Thus, the idea was most definitely 
to take into considerating how a gateway might implement these services 
due to the fact that it is a gateway, and is trying to interwork to 
another network.

This is captured in the charter already here:

"The problem is exacerbated by the desire for these features to work 
across many types of SIP endpoints, including SIP hardphones, 
softphones, and gateways to the PSTN and other VoIP networks, and for 
the desire to work across domain boundaries."

Can you suggest some additional text to clarify?

> other services" or something like that. A

I don't think the charter needs to review the reaasons for interop 
failures in detail. DND is problematic in my mind because some devices 
assume its entirely a UA function, others assume its in the network and 
invoked in some way, others assume its derived from presence, and 
invoking it is done by PUBLISH to update your presence status to DND.

We need to document the variations that exist in the wild and then 
figure out what a minimum baseline requirement would be for a UA.

> calls" or does it consider only a device centric approach?

Right! Exactly the problem. My sense is, the way we get interoperability 
is to definge minimum requirements for a device. In this particular 
case, we have several options:

1. mandate that servers always provide DND, but that it can be disabled 
by configuration. Define a standard invocation mechanism. This way, if a 
phone connects to it which implements it on the phone, it need not be 
used in the network. We might need some capability exchanges or 
something to make this determination.

2. mandate that clients can do it locally, but they also implement a 
well-defined set of invocation techniques (ideally just one). This 
allows for variation in the capabilities of the server.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:20:45 -0500

> I think first we should list the services we need to address as part of this

Right. The proposed charter identifies four. We can expand this to more 
later, but I think we need to start with a small number of the highest 
priority services, and demonstrate that we can usefully solve the 
problem. Then we can move on to more.

> i.e. some services can work by UA supporting it, Some services can work by

Right, this is one of the things which leads to interop problems - 
different solutions for who implements what. As I alluded to in my 
previous message, there are a few ways one can solve this. One way is to 
standardize a single approach. Another way, as I suggested in my note, 
is to allow variation but require some of the participants to support 
more than one mechanism to support variation in the capabilities of the 
others. The third is to demonstrate that you can still interoperate 
successfully even when all of the entities do the service differently.

This is why the key part of working on each of these services is to have 
a section in the document for each that is an EXHAUSTIVE enumeration of 
the various ways in which the feature has been implemented, so we can 
figure out what the right path is to take for that feature.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:25:02 -0500

Absolutely. The kind of enumeration of things you have to do is what I 
had in mind with:

"The focus will not be on rigorous definition of what the specific 
service is and exactly how it works. Rather, the focus will be on 
definining minimum levels of functionality required to realize a broad 
class of related services.."

i.e., the things you mention below would appear on our list of minimum 
level of functionality that are required.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:26:42 -0500

I think this is on the right path, and is similar to what Mohammad 
suggested. We achieve basic levels of interoperability by outlining a 
set of functions that are required on any UA (and/or other components), 
which can include specific extensions, oft-overlooked parts of the SIP 
spec, new extensions that we think need to be defined, and so on. We 
then make sure there are capability determination exchanges as needed, 
since we still want to allow variation in how things are done. For 
example, vendor X could have a proprietary implementation for some 
feature that adds their special sauce, and also implement the baseline 
mechanism in the spec. It would use capability discovery mechanisms 
(OPTIONS, feature tags, Allow, etc.) to determine which one it needs to 
do for a particular call.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jan 2007 10:28:38 -0500

Alan,

I agree this would be interesting to work on, and I would support it. 
However, I think it would be better suited as a set of next-step 
services after we complete the initial chartered ones. In the meantime 
if you want to start work on a problem space and requirements doc, that 
would be great; we can let that bake and gel for a little bit, and then 
hopefully when we get done with our initial items, that work is solid 
enough to help us with a recharter.

-Jonathan R.

---

From: Alan Johnston <[email-masked]>
Date: Wed, 24 Jan 2007 09:36:52 -0600

Jonathan,

I'm fine with leaving it off the charter for now.  It would be most 
useful if we could continue to discuss the preliminary work in this area 
on this mailing list and even have some time at meetings to help move 
the work forward to the point where it could be added to the charter.

Thanks,
Alan

Jonathan Rosenberg wrote:
> if you want to start work on a problem space and requirements doc, 
> that would be great; we can let that bake and gel for a little bit, 
> and then hopefully when we get done with our initial items, that work 
> is solid enough to help us with a recharter.
>
> -Jonathan R.
>
> Alan Johnston wrote:
>
>> I'm hearing a lot of interest in SIP enabling contact centers (or 
>> call centers).  This requires a few things:
>>
>> I have not yet attempted #1 yet, although I do plan to work on it 
>> with others who understand the service well (volunteers?)
>> Perhaps this group can demonstrate that there is interest and need 
>> for these REFER extensions so they can be worked in the SIP WG.  For 
>> #3, I wrote a partial solution in draft-johnston-sipping-cc-uui-01.  
>> I think if we put effort into #1 it will become clearer what 
>> mechanism is best, so I would describe this draft as an example 
>> mechanism that is out there rather than the right mechanism.
>>
>> opportunity to make a big impact on the industry if we can deliver 
>> the same functionality using open standards and SIP.
>> However, I would expect to spend a good deal of time on requirements 
>> and use cases before we even started on mechanisms.
>>
>> Thanks,
>> Alan
>>
>>> In my mind, the main question to be answered is what features we 
>>> want to work on, and in what order. We've chosen four to begin with 
>>> - BLA, pickup, DND, and CCBS, since these have been reported to be 
>>> the most problematic.
>>>
>>> If anyone has comments on different ones they'd like to see worked 
>>> on, please comment. Especially welcome are examples of REAL interop

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 24 Jan 2007 09:40:33 -0600

Hi, Jonathan,

This note was one of the most helpful statements on the general topic I've 
seen.

The example probably doesn't need to go in a proposed charter, but if there 
is any kind of problem statement draft required, your text is definitely 
worth preserving there.

Thanks,

Spencer

>I think this discussion is indicative of EXACTLY the problem we are trying 
>to solve.
>
> 1. Assuming PBX is a b2bua, the phone emits a DTMF feature code (rfc2833) 
> on the call; this is captured by the PBX, interpreted as an invocation 
> request, mapped to the park feature. The call is then parked at the PBX, 
> and can be picked up elsewhere. I *think* this is the mechanism Udit is 
> talking about.
>
> 4. conference mechanism; park is implemented by viewing the park server as 
> a conference bridge. So, the invoking UA creates an ad-hoc conference

---

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 25 Jan 2007 10:27:00 +0530

If the focus is to be on a generic "service" I suggest that we put in some
text defining what exactly a "service" is. 

>From my point of view a "service" will have the following properties

1) It shall conform to a standard interface
(draft-rosenberg-sipping-service-identification?) through which it can be
invoked

2) It MUST be atomic i.e. it must either succeed or fail. Since we are
actually looking at defining how services behave, it would be good to break
them down as much as possible. These building blocks could then be used to
build "SIP SCE's". For example, "park call" or "create a conference with an
initial list of participants (sip-uri-list-conferencing) . 

3) It MUST be able to stand completely on its own i.e. can be used "out of
the box". 

4) It SHOULD be able to integrate seamlessly with other "services" to create
new services. 

What I'm actually trying to say is:-

1) Break down services into as many atomic "sub-services" as possible. 
2) Define BCP (normative) flows for these primitives
3) Design such that these sub-services can be strung together to build
services like call park or BLA.

BR,
Darshan

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, January 24, 2007 8:55 PM
To: Mohammad Al-Taraireh (maltarai)
Cc: [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

-Jonathan R.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 25 Jan 2007 09:36:52 +0200

> Can you suggest some additional text to clarify?

I am satisfied with your explanation. When I read the charter I 
interpreted "domain boundaries" as in "SIP domain boundaries", but I 
understand now that you mean crossing to the PSTN, for example. If you 
want, you could add make the sentence to read "... and for the desire to 
work across domain boundaries and to seamless interwork with the PSTN, 
when applicable".

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jan 2007 09:12:09 -0500

> (draft-rosenberg-sipping-service-identification?) through which it can be

Interesting. I was just about to raise a concern that "service" in BLISS 
and "service" in IMS and draft-rosenberg-sipping-service-identification 
appeared to me to be considerably different concepts.

My understanding of the concept in IMS and 
draft-rosenberg-sipping-service-identification is that one of several 
alternative behaviors that might be selected for a call. It is intended 
to impact the selection of components that are involved in the call - 
both intermediate nodes, UAS, and application within the UAS.

OTOH, I have the impression that the kinds of "services" requiring 
clarification in BLISS, at least in part, have to do with mid-call 
behavior, and with state that affects multiple calls.

I expect that there may be some degree of overlap between these things. 
Perhaps something can be learned about both by trying to understand how 
they are the same and how they differ.

E.g. I think an emergency call (911) might be viewed as a service in 
both the BLISS and IMS sense. Call Park and DND would seem to be 
services in the BLISS sense, but they don't seem to be in the IMS sense.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jan 2007 19:57:34 -0500

OK, I think this is a reasonable change to the charter.

-Jonathan R.

Miguel Garcia wrote:

>>> Jonathan. I have a couple of questions and comments about the 
>>> proposed charter.
>>>
>>> 1) When the charter speaks about heterogeneous networks, does it 
>>> refer only to SIP networks or does it consider interoperability 
>>> across, say, the PSTN. I am sure the TISPAN guys will ask this 
>>> question sooner or later, so better to write the answer, whatever it 
>>> is, in the charter.
>>
>>
>> Its referring to SIP neworks. The heterogeFrom [email-masked] Fri Jan 26 00:11:49 2007
Date: Thu, 25 Jan 2007 19:57:34 -0500
From: Jonathan Rosenberg <[email-masked]>
To: Miguel Garcia <[email-masked]>
Subject: Re: [BLISS] Welcome! Main question - what services?
Cc: [email-masked]

OK, I think this is a reasonable change to the charter.

-Jonathan R.

Miguel Garcia wrote:

>>> Jonathan. I have a couple of questions and comments about the 
>>> proposed charter.
>>>
>>> 1) When the charter speaks about heterogeneous networks, does it 
>>> refer only to SIP networks or does it consider interoperability 
>>> across, say, the PSTN. I am sure the TISPAN guys will ask this 
>>> question sooner or later, so better to write the answer, whatever it 
>>> is, in the charter.
>>
>>
>> which includes gateways to the PSTN. Thus, the idea was most 
>> definitely to take into considerating how a gateway might implement 
>> these services due to the fact that it is a gateway, and is trying to 
>> interwork to another network.
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jan 2007 19:56:56 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jan 2007 19:56:56 -0500

Yes, I think that is appropriate.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-YyJzX0tyrPQp8t29HqkpSsh6FqzZTAQp17K7zs5V;
Cc: [email-masked]

Yes, I think that is appropriate.

-Jonathan R.

2711
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jan 2007 20:16:54 -0500

I agree with Paul; though both of these things involve 'services' they 
are quite distinct. I had not even connected BLISS and the 
service-identification draft in my head until Darshan had suggested it. 
The option tags in service-identification are puposefully constructed as 
'a technique of LAST RESORT' for identifying services, usually at 
initiation time. As Paul indicates, we are worried about things that I 
think are better classified as "features", meaning they are smaller bits 
of functionality that don't represent an entire experience. For example, 
'television' is a service and a wireless remote is a 'feature'. 
'Telephony' is a service and 'DND' is a feature.

Of course everyone has their own definitions of application, service and 
feature and I don't want to get too wrapped up in their definitions.

I have to disagree with some of Darshan's other points here. I don't 
think we want to define our features here as atomic; I think we need to 
evaluate that on a case by case basis. For example even with 
park/pickup, lets say we have an unhappy case where I can park the 
phone, but can't pickup from some phones since they don't support the 
required mecahnism. I'd rather park and allow pickup to work where it 
can, rather than fail the park since a pickup might fail somewhere.

 >> class of related services.."

Let us take DND. There are really many variants on it:

1. if the user is DND the incoming calls get rejected
2. if the user is DND the incoming calls get sent to voicemail
3. if the user is DND the incoming calls get redirected to voicemail 
(i.e., 3xx)
4. if the user is DND the incoming calls get sent to IVR jail where the 
user is told to conitnually wait
5. any one of the above, PLUS the DND status is reflected in presence

I don't want to have a spec that rigorously defines all 8 of the above, 
with specific call flows for each and a name for each. I want vendors to 
be able to implement any one of these 8 and for it to work. Indeed, any 
of the above 8 would work as long as we define how the invocation works, 
since that IMHO is the primary interop problem around this feature. If 
one phone expects the network to do the DND processing, and the 
corresponding IP PBX expects the phone to do it, we have a serious 
interop failure.

The above examples also show how partial failures are OK. Lets say user 
A calls user B. User B invokes DND. Their presence status is updated to 
say DND as well, but user A doesn't do presence. Thats fine; they don't 
support presence, they don't get that bit of value add. This is a 
partial failure but a perfectly acceptable one, IMHO. For this presence 
enhancement to work, we would need to specify responsibility for PUBLISH 
(does the UA PUBLISH? Does the UA just invoke and let the IP PBX 
PUBLISH? Do we negotiate who?) and clarify how it is represented in 
presence (status of <closed>? new flag?). Once we do that, we enable 
lots of variations without rigorously identifying the service.

This is really important to me since the whole idea with SIP is to 
enable service innovation. If we rigorously define the call flows and 
standardize each one, we kill the point of having SIP in the first place.

So, this leads me to my thoughts on the structure of our deliverables. 
Again taking DND as an example, we would have lots of flows in the 
document that give examples of different implementation techniques, and 
show how they fail. We'd show failures like the two I describe above 
(disagreement on invocation, disagreement on who publishes) and also 
demonstrate some of the variants. The document would then indicate that 
the bug here is having an agreed upon invocation technique and define 
what it is, and/or minimal requirements to support interop when it can 
vary. We'd also have to state guidelines on presence too - who PUBLIShes 
and what the presence data looks like.

Thanks,
Jonathan R.

Paul Kyzivat wrote:

>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: Wednesday, 
>> January 24, 2007 8:55 PM
>>> From: Jonathan Rosenberg (jdrosen) Sent: Friday, January 19, 2007 
>>> 5:15 PM
>>> To: [email-masked]

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 26 Jan 2007 12:28:49 +0100

What we need from operator point of view are services that are running
within SIP and has their interoperability with the existing legacy
networks.

Here are some issues:

CCBS/CCNR
COLP/COLR  = TIP/TIR = 2nd untrusted identity in a normal response
(needed for interoperability and to have combined PSTNM/SIP PBX
services)

CPC parameter issue where we need to signal a network provided category
of the user within SIP 
transfer for interoperability reasons release cause values within SIP
(not only in Requests also in Responses) to process announcements

Perhaps some future issues like Closed User Group

Not covered issues in the draft-jesske-sipping-tispan-requirements.

That are my ideas what comes out of myself thinking on issues for BLISS.

Thanks

Roland

---

From: Shida Schubert <[email-masked]>
Date: Fri, 26 Jan 2007 10:28:45 -0800

I tried to incorporate some of the comments provided
in the last week including the one below to the charter.
Updated charter is available at

http://www.bliss-ietf.org/charter.html

diff is available at http://www.bliss-ietf.org/diff1.html

Shida

Jonathan Rosenberg wrote:
>>>> question sooner or later, so better to write the answer, whatever
>>>> it is, in the charter.
>>>
>>>
>>> these services due to the fact that it is a gateway, and is trying
>>> to interwork to another network.
>>>
>>> softphones, and gateways to the PSTN and other VoIP networks, and
>>> for the desire to work across domain boundaries."
>>>
>> understand now that you mean crossing to the PSTN, for example. If
>> you want, you could add make the sentence to read "... and for the
>> desire to work across domain boundaries and to seamless interwork
>> with the PSTN, when applicable".
>>
>> /Miguel
>>
>>
>>
>

---

From: [email-masked]
Date: Sun, 28 Jan 2007 18:36:13 -0500

Yes, I think that at this point in the discussion, we want to avoid
trying to be too exact about what "services" are.  Really, exploring
the meaning of any given named "service" is part of our charter.
Ideally, the endpoint will be a clear understanding of what services
can be provided, and what the building blocks of the services are, and
how those building blocks interact to provide services, and
consequently, what users need to do to obtain a service.

As an example, the sipX call pick-up operation involves 3 phones:

    A phone A makes a call to a phone B.  From a phone C, intercept the
    ringing call and talk to A.

To do this requires:

    phone A implements INVITE-with-Replaces,

    phone B implements the dialog event package, and

    either:

	phone C implements the pick-up operation natively, or

	the proxy implements a "call pick-up agent" (like sipX does) to
	perform the operation

But it was the result of a lot of analysis to discern that that is
what is needed for call pick-up.  And that has left out a number of
interesting questions in regard to operation across SIP administrative
domains.

Dale

---

From: Peili Xu <[email-masked]>
Date: Wed, 31 Jan 2007 18:16:48 +0800

After looking at the following sentences in the draft charger "The
difference between SIPPING and BLISS, is that BLISS is focused on a
particular type of SIP application - call features, and in particular, 
advanced call features requiring non-trivial call control. SIP applications
such as configuration, presence and IM, and session policy are clearly out
of scope for BLISS and remain the sole province of SIPPING. "

It seems the WG will actually focus on features initiated by INVITE and
these features are more or less related to traditional PSTN/ISDN
supplementary services.
If I am correct, what about session mode messaging service which is also a
call initiated by INVITE?

thanks
Peili

-----Original Message-----
From: Shida Schubert [mailto:[email-masked]] 
Sent: Saturday, January 27, 2007 2:29 AM
To: Jonathan Rosenberg
Cc: Miguel Garcia; [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

I tried to incorporate some of the comments provided in the last week
including the one below to the charter.
Updated charter is available at

Shida

---

From: [email-masked]
Date: Wed, 31 Jan 2007 13:57:47 -0500

From: Peili Xu <[email-masked]>

   If I am correct, what about session mode messaging service which is
   also a call initiated by INVITE?

Looking at the charter, it seems to me that all of the services
mentioned are applicable to messaging sessions in the same way as
audio calls.  Indeed, for the deaf community, I can see all of these
services being useful.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 31 Jan 2007 13:47:50 -0800

Hi Peili;

Session mode messaging service as I mentioned in the
response to Spencer is not in scope of BLISS. I will modify
the text that raised this question.

Thanks.
Shida

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 31 Jan 2007 12:11:02 -0800

> it seems to me that all of the services mentioned are applicable 
> to messaging sessions in the same way as audio calls

Thanks for bringing this up. Using SIP for voice only seems a crippled
approach, since everyone is also using presence and IM. 
Moreover, presence, IM, and voice must be usable on mobile devices that
are part and parcel of enterprise communications. Not to mention video
that is such an important part in many business and consumer
communications.

Besides, the same people on this list are also in the SIMPLE WG.

I hope the energy from SIMPLE is not leaking over to Jabber, since that
would be a sad precedent for BLISS.

Thanks again, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 31, 2007 12:58 PM
To: [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 31 Jan 2007 20:16:24 -0800

I really don't like sending comment to something I sent myself, but here
it is.

I thought about this a bit more, as SIMPLE is aiming to close in August,
by what's advocated by few to include session mode messaging service
may be a reasonable things to do.

As Jonathan mentioned somewhere, we are hoping that when the output of
this group goes out, it would allow variation(more advanced features).
The spec
possibly provides a hooks to realize those variations but may not define
the variations in itself. The session mode messaging service may be one of
the variation.

AFAIK, most of the services we listed as a potential milestones are
facing interop
problems right now. I personally like to get out remedies out there
soon, before
the problems worsen. To ensure this, I want to avoid broadening the scope
for "nice to have", which may hinder the remedies from getting out there.

As for considering session mode messaging, unless we are thinking of
using session
mode messaging for service invocation, I don't think there is really
anything we need
to consider differently for the session mode messaging service..

Anyhow, I personally like to see solutions based on tool-sets that are
regularly
implemented, so wider use of our documents are possible which I believe
would lead
to less interop problems which I believe is the core objective of this
group.

If you see that the session mode messaging service is mandatory, I would
appreciate
it if you can provide some text for the draft charter.

Thanks & Regards
Shida