Subject: RE: [SIP] SIP feature services

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 5 Sep 2000 12:42:15 -0500

The answer to all this that I'm seeing in my admittedly limited experience
is that individual networks define how they want services to operate and
expect vendors to support the resulting information flows.

> -----Original Message-----
> From: Hong Chen [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2000 1:33 PM
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; Anders Kristensen; [email-masked]
> Subject: Re: [SIP] SIP feature services
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > Hong Chen wrote:
> > >
> > > Jonathan Rosenberg wrote:
> >
> > > I agree that additional standardization may not be 
> necessary, but  a standard call
> > > model
> > > for sip proxy may help for the feature developments and 
> interpretability.
> >
> > Attempts at a call model have been made by various people. 
> See the draft
> > archives. Whether they are useful is another question.
> >
> > >
> > > EX.. of features which need network controls and hard to 
> define trigs in sip proxy.
> > > (1) Call Park (Park a call and then pick the call later 
> somewhere else).
> > > (2) Call Pick Up (Answer a call which is ringing 
> somewhere else in a call pick up
> > > group).
> > > (3) Adhoc conference using centralized conference bridge.
> > >  and more.
> >
> > These services were discussed extensively on this list a 
> number of weeks
> > ago (see the list archives), with different solutions 
> proposed, since it
> > doesn't make sense to translate the behavior exactly from 
> PSTN to IP.
> > Conferencing is also addressed in the SIP FAQ and requires 
> no SIP proxy.
> >
> 
> (1) It may not make sense to translate the behavior exactly 
> from PSTN to IP, but people
> are still looking for
> those traditional services.
> 
> (2) The key point here is:
>         There may be hundred suggested different ways for 
> some service by SIP signaling.
>         The question is which is the best systematic 
> mechanism we should follow and we
> can also easily
>         use this same systematic mechanism for any new 
> feature service later.
> 
> 
> 
> >
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>

---

From: Hong Chen <[email-masked]>
Date: Wed, 06 Sep 2000 11:42:45 -0500

Tom-PT Taylor wrote:

>
>
> The answer to all this that I'm seeing in my admittedly limited
> experience is that individual networks define how they want services
> to operate and expect vendors to support the resulting information
> flows.

You might be right.  But we do not want to break one of the promising
SIP principals by feature services: Interoperability.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 06 Sep 2000 10:41:50 -0700

Henry,

Different web browsers do not all display the same content in exactly the 
same way, but they the server still interoperates with all of these browsers.

Likewise SIP UAs don't have to act exactly the same way, as long as the 
right parties end up communicating.  That said, I think the *example* call 
flow work is extremely important, but I feel that the examples plus the 
bakeoff is sufficient guidance to yield interoperable product.

Ultimately, the market will decide what variations people like.

thanks,
-rohan

At 09:42 AM 9/6/00 , Hong Chen wrote:
>>experience is that individual networks define how they want services to 
>>operate and expect vendors to support the resulting information flows.
>You might be right.  But we do not want to break one of the promising SIP 
>principals by feature services: Interoperability.
>>
>> > From: Hong Chen [<mailto:[email-masked]>mailto:[email-masked]]
>> > > Henning 
>> Schulzrinne   <http://www.cs.columbia.edu/~hgs>http://www.cs.columbia.edu/~hgs
>> >
>> >
>> >
>> <http://lists.bell-labs.com/mailman/listinfo/sip>http://lists.bell-labs.c 
>> om/mailman/listinfo/sip
>> >

---

From: "Alex Hardisty" <[email-masked]>
Date: Thu, 7 Sep 2000 14:00:07 +0100

> Ultimately, the market will decide what variations people like.

No! Ultimately, what the market has to put up with is the lowest common
denominator of functionality that can be made to work between equipments
that purport to support a particular capability but whose vendors have
implemented it in different ways!

--
Alex Hardisty
PQM Consultants

---

From: Hong Chen <[email-masked]>
Date: Thu, 07 Sep 2000 09:32:30 -0500

> bakeoff is sufficient guidance to yield interoperable product.

I agree, " the *example* call flow work is extremely important" for the success
of SIP and expect to have it ASAP, plus I hope it will have some guideline of
the systematic mechanism we can use for features not included in example and
features in the future.