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

From: xupeili 18916 <[email-masked]>
Date: Thu, 01 Feb 2007 23:21:48 +0800

I fully agree with Paul.

When we are talking about service, we are looking at  the things from user's point of view.

I would rather treat the services listed in the Charter as kinds of "Service Pattern", e.g DND means rejecting sth when the user don't want to accept it.

Here, the "sth" can be a voice call, a message or whatever (of course implemented by SIP).

we can always find several key points for a "Service Pattern", e.g the entity, the time, the media......

We may get more general solution if we consider the pattern instead of a specific service instance.

Peili

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
Date: Thursday, February 1, 2007 10:09 pm
Subject: Re: [BLISS] Welcome! Main question - what services?

> I have been inovlved in an exercise of trying to map traditional 
> PSTN 
> services to SIP, and make them apply more generally to the broader 
> set 
> of things that can happen in SIP.
> 
> Some services seem to apply to an AOR, others to a UA, and some 
> potentially to a particular media stream. And in some cases there 
> are 
> multiple meaningful ways to apply the service. For instance:
> 
> - DND can meaningfully apply at either the AOR level or the UA level.
>   You could consider these to be different services.
> 
> - HOLD can apply to a whole dialog, or to a particular media stream
>   within a dialog.
> 
> Its important to consider these things.
> 
> 	Paul
> 
> Drage, Keith (Keith) wrote:
> > For all the services when used in the PSTN/ISDN the general 
> intent has
> > to make these services more generally available to all services AS
> > APPROPRIATE.
> > 
> > Thus to take for example DND, on the PSTN, there it was primarily
> > applicable to voice, because voice was the main service used on the
> > PSTN. In fact it would be more correct to say when activated it 
> applied> generally to all services, thus if you had a fax machine 
> on the same
> > line, that was also affected  by invocation of the service.
> > 
> > With the introduction of the ISDN, and the ability to recognise the
> > requested service or communication type in the network and the 
> terminal,> the service expanded to allow it to be invoked for 
> specific services or
> > communication types, whereas for example DND would not apply on 
> others.> 
> > I don't see why we cannot extend this argument to the work in 
> BLISS. 
> > 
> > If the service makes sense for any SIP capability, then define it 
> for> that. 
> > 
> > DND can be applied (if desired) for any request that is not in an
> > existing dialog. 
> > 
> > Taking call park as an example, it obviously cannot be applied as
> > currently understood to capabilities supported by MESSAGE 
> requests, due
> > to the transitory nature of such capabilities, but there is no 
> reason> why it cannot be applied, either generically or for 
> specific SDPs, to
> > any INVITE initiated dialog.
> > 
> > Regards
> > 
> > Keith
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: Shida Schubert [[email-masked]] 
> >> Sent: 31 January 2007 21:48
> >> To: Peili Xu
> >> Cc: [email-masked]
> >> Subject: Re: [BLISS] Welcome! Main question - what services?
> >>
> >>
> >> 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
> >>
> >> Peili Xu wrote:
> >>> 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 [[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
> >>>
> >>> http://www.bliss-ietf.org/charter.html
> >>>
> >>> diff is available at http://www.bliss-ietf.org/diff1.html
> >>>
> >>> Shida
> >>>
> >>>
> >>> Jonathan Rosenberg wrote:
> >>>   
> >>>> OK, I think this is a reasonable change to the charter.
> >>>>
> >>>> -Jonathan R.
> >>>>
> >>>> Miguel Garcia wrote:
> >>>>
> >>>>     
> >>>>> Jonathan Rosenberg wrote:
> >>>>>
> >>>>>       
> >>>>>> Miguel Garcia wrote:
> >>>>>>
> >>>>>>         
> >>>>>>> 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.
> >>>>>>>           
> >>>>>> 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?
> >>>>>>         
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>       
> >>>
> >>> _______________________________________________
> >>> BLISS mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/bliss
> >>>
> >>>
> >>>
> >>>   
> >>
> >> _______________________________________________
> >> BLISS mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/bliss
> >>
> > 
> > _______________________________________________
> > BLISS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/bliss
> > 
> 

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

---

From: Diego B <[email-masked]>
Date: Sun, 04 Feb 2007 15:10:11 +0200

Hi;
Can we split the discussion to several threads ?
We are talking about different issues but all of them under the same 
Subject.
It is very difficult to track posts  and response when everything 
appears in the same thread.

Thanks
Diego B

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Feb 2007 17:00:04 -0500

inline.

[email-masked] wrote:
>    From: Jonathan Rosenberg <[email-masked]>
> 
>    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.
> 
> 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.

Yes - with the caveat as I've stated that the "B" in BLISS is important. 
I don't think its within our scope to spec out how to do the most 
uber-complicated variant on DND we are able to think of. I think we need 
to make the basic stuff work and leave hooks that allow extensibility 
and vendor proprietary tricks, with all of the capabilitiy negotiation 
and discovery necessary to make that work.

> 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

Right. So here are some other variations that you might see, which can 
illustrate the interop failures we might see:

1. instead of having phone B implement the dialog package, phone B uses 
PUBLISH to push its dialog state into the network, so that the SUBSCRIBE 
terminates on a state server in the network.

2. instead of that, in another implementation, phone B does nothing 
since it assumes that its IP-PBX/proxy/call agent is watching the SIP 
messages and knows the dialog state by inspection.

3. instead of PUBLISH with the dialog event package, the phone publishes 
presence status which includes a service describing its call status.

If you add to that the two variants that Dale describes for phone C, we 
have a total of 8 different combinations of how this can be done, and 
most will not interoperate with each other.

So what I'd expect in the 'park and pickup' document is thta it would 
list exactly these different cases, showing some call flows on how it 
can fail, and then make a concrete recommendation. For example, we could 
say something like:

1. All user agents MUST support the receiving subscriptions to the 
dialog event package
2. All user agents MUST be capable of invoking pickup by sending an 
INVITE with Replaces, and all user agents MUST be capable of subscrining 
to the dialog package for their own AOR.

Whats interesting is that this approach still allows for flexibility on 
what you do both in the phone and in the network. For example, vendor X 
decides to still use the publish mechanism with an event server in the 
IP-PBX.  So, its phones do PUBLISH and its server handles the 
subscriptions. However, to be be compliant to our spec, the phone still 
supports receipt of SUBSCRIBE. Now, when vendor X's phones and IP-PBX 
are paired up, the phone would never even receive the SUBSCRIBE request 
and it would be processed in the network. However, if vendor X's phone 
is paired with IP-PBX from vendor Y, and vendor Y assumed the endpoint 
handled subscriptions, things would still work. Vendor Y's IP PBX would 
reject the PUBLISH operations, and would proxy dialog subscriptions to 
the phone. The phone would be able to process them since its compliant 
to our spec, and things still work.

> 
> 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.

Right. I think we want to look at that kind of stuff too.

-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