From bliss-bounces@ietf.org Thu Feb 01 04:09:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXwT-0001MD-Fh; Thu, 01 Feb 2007 04:09:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXwS-0001M8-KT for bliss@ietf.org; Thu, 01 Feb 2007 04:09:16 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXwM-00047Y-Su for bliss@ietf.org; Thu, 01 Feb 2007 04:09:16 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l11993PB021775; Thu, 1 Feb 2007 03:09:03 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 03:09:03 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:09:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fw: [BLISS] Welcome! Main question - what services? Date: Thu, 1 Feb 2007 10:09:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180C14A3C@DEEXC1U01.de.lucent.com> In-Reply-To: <45C10B3F.4070507@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: [BLISS] Welcome! Main question - what services? Thread-Index: AcdFf6VpYQo0SMfyQaixD2ieSvCLuQAX0Csw References: <015901c74576$75c85830$6501a8c0@china.huawei.com> <45C10B3F.4070507@ntt-at.com> From: "Drage, Keith \(Keith\)" To: , "Spencer Dawkins" X-OriginalArrivalTime: 01 Feb 2007 09:09:00.0710 (UTC) FILETIME=[9CAFB460:01C745E0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.9 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I don't think this statement helps. What should happen is that if BLISS identifies the need for any of your list, it develops the requirements and passes the requirements to each of those groups you have mentioned. Keith=20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 31 January 2007 21:34 > To: Spencer Dawkins > Cc: bliss@ietf.org > Subject: Re: Fw: [BLISS] Welcome! Main question - what services? >=20 >=20 > Hi Spencer; >=20 > Yes you are right. I will change the text to say.. >=20 > "SIP applications such as configuration, presence and IM, and=20 > session policy are clearly out of scope for BLISS and remain=20 > the sole province of SIPPING and SIMPLE." >=20 > Thanks > Shida >=20 >=20 > Spencer Dawkins wrote: > > Hi, Jonathan and Shida, > > > > And now that Peili jogged me to read the actual words in=20 > the charter,=20 > > isn't presence the sole province of SIMPLE? > > > > Thanks, > > > > Spencer > > > > > >> After looking at the following sentences in the draft charger "The=20 > >> difference between SIPPING and BLISS, is that BLISS is=20 > focused on a=20 > >> particular type of SIP application - call features, and in=20 > >> particular, advanced call features requiring non-trivial call=20 > >> control. SIP applications such as configuration, presence=20 > and IM, and=20 > >> session policy are clearly out of scope for BLISS and=20 > remain the sole=20 > >> province of SIPPING. " > >> > >> It seems the WG will actually focus on features initiated=20 > by INVITE=20 > >> and these features are more or less related to traditional=20 > PSTN/ISDN=20 > >> supplementary services. > >> If I am correct, what about session mode messaging service=20 > which is=20 > >> also a call initiated by INVITE? > >> > >> thanks > >> Peili > > > > > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > > > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 04:09:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXwy-0001PN-0Z; Thu, 01 Feb 2007 04:09:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXww-0001PH-IP for bliss@ietf.org; Thu, 01 Feb 2007 04:09:46 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXwp-0004LC-EI for bliss@ietf.org; Thu, 01 Feb 2007 04:09:46 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l11996p0021319; Thu, 1 Feb 2007 03:09:07 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 03:09:06 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:09:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Welcome! Main question - what services? Date: Thu, 1 Feb 2007 10:09:00 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> In-Reply-To: <45C10E86.3010006@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdFgYnFTNTecbkkQBakk2iRcYIlOwAWxcqQ References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> From: "Drage, Keith \(Keith\)" To: , "Peili Xu" X-OriginalArrivalTime: 01 Feb 2007 09:09:00.0567 (UTC) FILETIME=[9C99E270:01C745E0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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.=20 If the service makes sense for any SIP capability, then define it for that.=20 DND can be applied (if desired) for any request that is not in an existing dialog.=20 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 [mailto:shida@ntt-at.com]=20 > Sent: 31 January 2007 21:48 > To: Peili Xu > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? >=20 >=20 > Hi Peili; >=20 > Session mode messaging service as I mentioned in the response=20 > to Spencer is not in scope of BLISS. I will modify the text=20 > that raised this question. >=20 > Thanks. > Shida >=20 > Peili Xu wrote: > > After looking at the following sentences in the draft charger "The=20 > > difference between SIPPING and BLISS, is that BLISS is focused on a=20 > > particular type of SIP application - call features, and in=20 > particular,=20 > > advanced call features requiring non-trivial call control. SIP=20 > > applications such as configuration, presence and IM, and session=20 > > policy are clearly out of scope for BLISS and remain the=20 > sole province of SIPPING. " > > > > It seems the WG will actually focus on features initiated by INVITE=20 > > and these features are more or less related to traditional=20 > PSTN/ISDN=20 > > supplementary services. > > If I am correct, what about session mode messaging service which is=20 > > also a call initiated by INVITE? > > > > thanks > > Peili > > > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Saturday, January 27, 2007 2:29 AM > > To: Jonathan Rosenberg > > Cc: Miguel Garcia; bliss@ietf.org > > Subject: Re: [BLISS] Welcome! Main question - what services? > > > > > > I tried to incorporate some of the comments provided in the=20 > last week=20 > > 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: > > =20 > >> OK, I think this is a reasonable change to the charter. > >> > >> -Jonathan R. > >> > >> Miguel Garcia wrote: > >> > >> =20 > >>> Jonathan Rosenberg wrote: > >>> > >>> =20 > >>>> Miguel Garcia wrote: > >>>> > >>>> =20 > >>>>> I think it is reasonable to work on the approach that=20 > you propose,=20 > >>>>> Jonathan. I have a couple of questions and comments about the=20 > >>>>> proposed charter. > >>>>> > >>>>> 1) When the charter speaks about heterogeneous=20 > networks, does it=20 > >>>>> refer only to SIP networks or does it consider interoperability=20 > >>>>> across, say, the PSTN. I am sure the TISPAN guys will ask this=20 > >>>>> question sooner or later, so better to write the=20 > answer, whatever=20 > >>>>> it is, in the charter. > >>>>> =20 > >>>> Its referring to SIP neworks. The heterogeneity refers to=20 > >>>> endpoints, which includes gateways to the PSTN. Thus,=20 > the idea was=20 > >>>> most definitely to take into considerating how a gateway might=20 > >>>> implement these services due to the fact that it is a=20 > gateway, and=20 > >>>> 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=20 > >>>> work across many types of SIP endpoints, including SIP=20 > hardphones,=20 > >>>> softphones, and gateways to the PSTN and other VoIP=20 > networks, and=20 > >>>> for the desire to work across domain boundaries." > >>>> > >>>> Can you suggest some additional text to clarify? > >>>> =20 > >>> I am satisfied with your explanation. When I read the charter I=20 > >>> interpreted "domain boundaries" as in "SIP domain=20 > boundaries", but I=20 > >>> understand now that you mean crossing to the PSTN, for=20 > example. If=20 > >>> you want, you could add make the sentence to read "...=20 > and for the=20 > >>> desire to work across domain boundaries and to seamless interwork=20 > >>> with the PSTN, when applicable". > >>> > >>> /Miguel > >>> > >>> > >>> > >>> =20 > > > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > > > > > > > =20 >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 05:36:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZJ4-0003GK-Dq; Thu, 01 Feb 2007 05:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZH8-0008Dk-5K for bliss@ietf.org; Thu, 01 Feb 2007 05:34:42 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZH5-0006m1-Ab for bliss@ietf.org; Thu, 01 Feb 2007 05:34:42 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l11AV57I023576; Thu, 1 Feb 2007 03:31:06 -0700 Message-ID: <45C1C16B.2060208@ntt-at.com> Date: Thu, 01 Feb 2007 02:31:07 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: Fw: [BLISS] Welcome! Main question - what services? References: <015901c74576$75c85830$6501a8c0@china.huawei.com> <45C10B3F.4070507@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180C14A3C@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Keith; That is the intention. I think the following text in the charter under "guiding principles for this working group will include" covers your comments. " Where extensions to standards are required, bring the analysis and need for new extensions to the appropriate working group (SIP or SIPPING). " I guess SIMPLE is missing from the list. Drage, Keith (Keith) wrote: > I don't think this statement helps. > > What should happen is that if BLISS identifies the need for any of your > list, it develops the requirements and passes the requirements to each > of those groups you have mentioned. > > Keith > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: 31 January 2007 21:34 >> To: Spencer Dawkins >> Cc: bliss@ietf.org >> Subject: Re: Fw: [BLISS] Welcome! Main question - what services? >> >> >> Hi Spencer; >> >> Yes you are right. I will change the text to say.. >> >> "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 and SIMPLE." >> >> Thanks >> Shida >> >> >> Spencer Dawkins wrote: >> >>> Hi, Jonathan and Shida, >>> >>> And now that Peili jogged me to read the actual words in >>> >> the charter, >> >>> isn't presence the sole province of SIMPLE? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>> >>>> 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 >>>> >>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >>> >>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 06:03:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZjF-0002uJ-Ne; Thu, 01 Feb 2007 06:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZjF-0002uA-6H for bliss@ietf.org; Thu, 01 Feb 2007 06:03:45 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZjD-0006lB-LX for bliss@ietf.org; Thu, 01 Feb 2007 06:03:45 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l11B3KKR006768; Thu, 1 Feb 2007 04:03:21 -0700 Message-ID: <45C1C8F9.5090705@ntt-at.com> Date: Thu, 01 Feb 2007 03:03:21 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I do think the argument can work, I believe optimally BLISS should always keep various capabilities in mind when conducting the analysis and documenting the variations. We should also make sure we get the best out of what SIP has to offer, and not limit the possibilities just because the pre-existing service is offered in a certain way. (I do want to stress though that I don't want to hinder the work for "nice to have" or "may be nice to have" feature that never gets implemented.) If the variations include different media such as MSRP or the call feature is best served by using presence, I do think we should look into them and ask appropriate workgroup for an extensions if one is needed. I have no problems with that and rather supportive of that.. But defining services solely used by session based messaging and presence has a home called SIMPLE at this present moment, and I see no reasons why BLISS should take on them as long as SIMPLE exists. Thought? Regards Shida 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 [mailto:shida@ntt-at.com] >> Sent: 31 January 2007 21:48 >> To: Peili Xu >> Cc: bliss@ietf.org >> 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 [mailto:shida@ntt-at.com] >>> Sent: Saturday, January 27, 2007 2:29 AM >>> To: Jonathan Rosenberg >>> Cc: Miguel Garcia; bliss@ietf.org >>> 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 >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >>> >>> >>> >>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 09:10:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcdM-0005Je-Ta; Thu, 01 Feb 2007 09:09:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCcdL-0005JX-Pm for bliss@ietf.org; Thu, 01 Feb 2007 09:09:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCcdH-0005xe-MP for bliss@ietf.org; Thu, 01 Feb 2007 09:09:51 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 06:09:46 -0800 X-IronPort-AV: i="4.13,267,1167638400"; d="scan'208"; a="384708132:sNHT57926672" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l11E9kST012689; Thu, 1 Feb 2007 06:09:46 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l11E9hnF021733; Thu, 1 Feb 2007 06:09:44 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:09:44 -0500 Received: from [161.44.183.228] ([161.44.183.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:09:43 -0500 Message-ID: <45C1F4A6.9040704@cisco.com> Date: Thu, 01 Feb 2007 09:09:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 14:09:43.0047 (UTC) FILETIME=[9EC1D970:01C7460A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6542; t=1170338986; x=1171202986; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=suBgOSG/BWBXgpb3kWBOA2d2/q0bSQcVsyGVsJHsaGM=; b=xt+QhBIEBLjEoQlOu361xcchjPYq7sfS2StlI2kWSMl9AGpW6wMvY1kltWfkJmxGjI9yiIZa b7xPC8+GqShi5N59a7EJKj/U7G8IqtxQwxhtbRfTrL1eIvh/j7E/HF3G; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 [mailto:shida@ntt-at.com] >> Sent: 31 January 2007 21:48 >> To: Peili Xu >> Cc: bliss@ietf.org >> 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 [mailto:shida@ntt-at.com] >>> Sent: Saturday, January 27, 2007 2:29 AM >>> To: Jonathan Rosenberg >>> Cc: Miguel Garcia; bliss@ietf.org >>> 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 >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >>> >>> >>> >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 09:58:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdOO-0005hI-EV; Thu, 01 Feb 2007 09:58:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdON-0005gL-UM for bliss@ietf.org; Thu, 01 Feb 2007 09:58:27 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdOM-0000zY-MP for bliss@ietf.org; Thu, 01 Feb 2007 09:58:27 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070201145825m120036ugge>; Thu, 1 Feb 2007 14:58:25 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l11EwO98027412 for ; Thu, 1 Feb 2007 09:58:24 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l11EwOB3027408; Thu, 1 Feb 2007 09:58:24 -0500 Date: Thu, 1 Feb 2007 09:58:24 -0500 Message-Id: <200702011458.l11EwOB3027408@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45C1C8F9.5090705@ntt-at.com> (shida@ntt-at.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1C8F9.5090705@ntt-at.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Shida Schubert But defining services solely used by session based messaging and presence has a home called SIMPLE at this present moment, and I see no reasons why BLISS should take on them as long as SIMPLE exists. I don't know about presence. But within the SIP philosophy, session-based messaging is "just another media type" when compared to audio calling. So it seems to me that if we discern an apparent difference in "calling features" between session-based messaging and audio calling, we are probably misunderstanding the situation. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:02:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdSI-0006w4-1O; Thu, 01 Feb 2007 10:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdSH-0006tg-5x for bliss@ietf.org; Thu, 01 Feb 2007 10:02:29 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdSE-0001eY-GT for bliss@ietf.org; Thu, 01 Feb 2007 10:02:29 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l11Ex7TA008770; Thu, 1 Feb 2007 16:59:29 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:01:57 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:01:57 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:01:56 +0200 Message-ID: <45C200DF.2020908@nokia.com> Date: Thu, 01 Feb 2007 17:01:51 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> In-Reply-To: <45C1F4A6.9040704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 15:01:57.0002 (UTC) FILETIME=[EABD6EA0:01C74611] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070201165929-21852BB0-66700607/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org DND can also apply to a particular media stream. In particular, if I am in a meeting, I may want to activate the DND for audio and video, but not for messaging. I guess in general, you need to consider all the different media streams that can apply to service. It would be a big mistake just to restrict to audio or to "things that are initiated with an INVITE" because this is what the PSTN did. /Miguel Paul Kyzivat wrote: > 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 > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:08:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdYY-0000GO-4U; Thu, 01 Feb 2007 10:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdYW-0000Fv-95 for bliss@ietf.org; Thu, 01 Feb 2007 10:08:56 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdYU-0002Xu-Mw for bliss@ietf.org; Thu, 01 Feb 2007 10:08:56 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l11F8YBf021458; Thu, 1 Feb 2007 09:08:38 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:08:37 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 16:08:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Welcome! Main question - what services? Date: Thu, 1 Feb 2007 16:08:34 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180C14D3A@DEEXC1U01.de.lucent.com> In-Reply-To: <45C200DF.2020908@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdGEf1KwCV3fCBlQWqzjXSb7ngPWwAACfkw References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> From: "Drage, Keith \(Keith\)" To: "Miguel Garcia" , "Paul Kyzivat" X-OriginalArrivalTime: 01 Feb 2007 15:08:35.0681 (UTC) FILETIME=[D85F0510:01C74612] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.9 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I assume that you mean you wish to be DND to a request with a SIP offer of a particular media stream, rather than just DND to a particular media stream. Regards Keith=20 > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 > Sent: 01 February 2007 15:02 > To: Paul Kyzivat > Cc: Drage, Keith (Keith); bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? >=20 > DND can also apply to a particular media stream. In=20 > particular, if I am in a meeting, I may want to activate the=20 > DND for audio and video, but not for messaging. >=20 > I guess in general, you need to consider all the different=20 > media streams that can apply to service. It would be a big=20 > mistake just to restrict to audio or to "things that are=20 > initiated with an INVITE" because this is what the PSTN did. >=20 > /Miguel >=20 > Paul Kyzivat wrote: > > I have been inovlved in an exercise of trying to map=20 > traditional PSTN=20 > > services to SIP, and make them apply more generally to the=20 > broader set=20 > > of things that can happen in SIP. > >=20 > > Some services seem to apply to an AOR, others to a UA, and some=20 > > potentially to a particular media stream. And in some cases=20 > there are=20 > > multiple meaningful ways to apply the service. For instance: > >=20 > > - DND can meaningfully apply at either the AOR level or the=20 > UA level. > > You could consider these to be different services. > >=20 > > - HOLD can apply to a whole dialog, or to a particular media stream > > within a dialog. > >=20 > > Its important to consider these things. > >=20 > > Paul > >=20 >=20 >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:13:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdd6-0001L3-O0; Thu, 01 Feb 2007 10:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdd6-0001Ky-6u for bliss@ietf.org; Thu, 01 Feb 2007 10:13:40 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdd4-0003ia-PB for bliss@ietf.org; Thu, 01 Feb 2007 10:13:40 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l11FAclx011789; Thu, 1 Feb 2007 17:10:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:13:06 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:13:06 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:13:06 +0200 Message-ID: <45C2037B.5020408@nokia.com> Date: Thu, 01 Feb 2007 17:12:59 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <5D1A7985295922448D5550C94DE29180C14D3A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180C14D3A@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 15:13:06.0364 (UTC) FILETIME=[79B5F7C0:01C74613] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070201171042-2DCE8BB0-3BB599D3/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Right... the capability of indicating a DND for SIP offers that contain certain media streams. Similarly with SIP methods. /Miguel Drage, Keith (Keith) wrote: > I assume that you mean you wish to be DND to a request with a SIP offer > of a particular media stream, rather than just DND to a particular media > stream. > > Regards > > Keith > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >> Sent: 01 February 2007 15:02 >> To: Paul Kyzivat >> Cc: Drage, Keith (Keith); bliss@ietf.org >> Subject: Re: [BLISS] Welcome! Main question - what services? >> >> DND can also apply to a particular media stream. In >> particular, if I am in a meeting, I may want to activate the >> DND for audio and video, but not for messaging. >> >> I guess in general, you need to consider all the different >> media streams that can apply to service. It would be a big >> mistake just to restrict to audio or to "things that are >> initiated with an INVITE" because this is what the PSTN did. >> >> /Miguel >> >> Paul Kyzivat wrote: >>> 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 >>> >> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.garcia@neonsite.net >> Nokia Research Center Helsinki, Finland >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:21:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdl7-0008Nz-Lp; Thu, 01 Feb 2007 10:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdl6-0008Ij-It for bliss@ietf.org; Thu, 01 Feb 2007 10:21:56 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdl4-0005Kd-6a for bliss@ietf.org; Thu, 01 Feb 2007 10:21:56 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCS00E40IOHZW@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 01 Feb 2007 07:21:53 -0800 (PST) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCS00I3AIOCD8@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 01 Feb 2007 07:21:53 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [219.134.239.111]) by szxmc04-in.huawei.com (mshttpd); Thu, 01 Feb 2007 23:21:48 +0800 Date: Thu, 01 Feb 2007 23:21:48 +0800 From: xupeili 18916 Subject: Re: [BLISS] Welcome! Main question - what services? To: Paul Kyzivat Message-id: <17e430f17e91c2.17e91c217e430f@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 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 [shida@ntt-at.com] > >> Sent: 31 January 2007 21:48 > >> To: Peili Xu > >> Cc: bliss@ietf.org > >> 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 [shida@ntt-at.com] > >>> Sent: Saturday, January 27, 2007 2:29 AM > >>> To: Jonathan Rosenberg > >>> Cc: Miguel Garcia; bliss@ietf.org > >>> 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 > >>> BLISS@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/bliss > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:27:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdqp-0001nw-Af; Thu, 01 Feb 2007 10:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdqn-0001mX-AC for bliss@ietf.org; Thu, 01 Feb 2007 10:27:49 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdql-0006m6-44 for bliss@ietf.org; Thu, 01 Feb 2007 10:27:49 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007020115274601400henf3e>; Thu, 1 Feb 2007 15:27:46 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l11FRk98029574 for ; Thu, 1 Feb 2007 10:27:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l11FRg7o029565; Thu, 1 Feb 2007 10:27:42 -0500 Date: Thu, 1 Feb 2007 10:27:42 -0500 Message-Id: <200702011527.l11FRg7o029565@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45C200DF.2020908@nokia.com> (Miguel.An.Garcia@nokia.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Miguel Garcia DND can also apply to a particular media stream. In particular, if I am in a meeting, I may want to activate the DND for audio and video, but not for messaging. I assume you mean "media type" here -- a media stream is what is established by an m line in the SDP of an existing dialog. But you couldn't apply DND to a media *stream* until it exists, and at that point, it's too late. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:31:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdty-0007GN-Th; Thu, 01 Feb 2007 10:31:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCdtx-0007Es-F0 for bliss@ietf.org; Thu, 01 Feb 2007 10:31:05 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCdtv-0007c3-TT for bliss@ietf.org; Thu, 01 Feb 2007 10:31:05 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l11FUug8005520; Thu, 1 Feb 2007 09:30:59 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:30:56 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 16:30:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Welcome! Main question - what services? Date: Thu, 1 Feb 2007 16:30:44 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180C14D73@DEEXC1U01.de.lucent.com> In-Reply-To: <45C1F4A6.9040704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdGCqfpNHNLeKEzStm3uRP963OLIQACaTlQ References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> From: "Drage, Keith \(Keith\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 01 Feb 2007 15:30:45.0803 (UTC) FILETIME=[F12F87B0:01C74615] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.9 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Agreed. It is these type of considerations that allow to actually know whether the service makes sense in its new environment. They do need to form part of any requirements analysis in the proposed BLISS. Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 01 February 2007 14:10 > To: Drage, Keith (Keith) > Cc: shida@ntt-at.com; Peili Xu; bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? >=20 > I have been inovlved in an exercise of trying to map=20 > traditional PSTN services to SIP, and make them apply more=20 > generally to the broader set of things that can happen in SIP. >=20 > Some services seem to apply to an AOR, others to a UA, and=20 > some potentially to a particular media stream. And in some=20 > cases there are multiple meaningful ways to apply the=20 > service. For instance: >=20 > - DND can meaningfully apply at either the AOR level or the UA level. > You could consider these to be different services. >=20 > - HOLD can apply to a whole dialog, or to a particular media stream > within a dialog. >=20 > Its important to consider these things. >=20 > Paul >=20 > Drage, Keith (Keith) wrote: > > For all the services when used in the PSTN/ISDN the general=20 > intent has=20 > > to make these services more generally available to all services AS=20 > > APPROPRIATE. > >=20 > > Thus to take for example DND, on the PSTN, there it was primarily=20 > > applicable to voice, because voice was the main service used on the=20 > > PSTN. In fact it would be more correct to say when activated it=20 > > applied generally to all services, thus if you had a fax machine on=20 > > the same line, that was also affected by invocation of the service. > >=20 > > With the introduction of the ISDN, and the ability to recognise the=20 > > requested service or communication type in the network and the=20 > > terminal, the service expanded to allow it to be invoked=20 > for specific=20 > > services or communication types, whereas for example DND=20 > would not apply on others. > >=20 > > I don't see why we cannot extend this argument to the work=20 > in BLISS.=20 > >=20 > > If the service makes sense for any SIP capability, then=20 > define it for=20 > > that. > >=20 > > DND can be applied (if desired) for any request that is not in an=20 > > existing dialog. > >=20 > > Taking call park as an example, it obviously cannot be applied as=20 > > currently understood to capabilities supported by MESSAGE requests,=20 > > due to the transitory nature of such capabilities, but there is no=20 > > reason why it cannot be applied, either generically or for specific=20 > > SDPs, to any INVITE initiated dialog. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Shida Schubert [mailto:shida@ntt-at.com] > >> Sent: 31 January 2007 21:48 > >> To: Peili Xu > >> Cc: bliss@ietf.org > >> Subject: Re: [BLISS] Welcome! Main question - what services? > >> > >> > >> Hi Peili; > >> > >> Session mode messaging service as I mentioned in the response to=20 > >> Spencer is not in scope of BLISS. I will modify the text=20 > that raised=20 > >> this question. > >> > >> Thanks. > >> Shida > >> > >> Peili Xu wrote: > >>> After looking at the following sentences in the draft=20 > charger "The=20 > >>> difference between SIPPING and BLISS, is that BLISS is=20 > focused on a=20 > >>> particular type of SIP application - call features, and in > >> particular, > >>> advanced call features requiring non-trivial call control. SIP=20 > >>> applications such as configuration, presence and IM, and session=20 > >>> 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=20 > by INVITE=20 > >>> and these features are more or less related to traditional > >> PSTN/ISDN > >>> supplementary services. > >>> If I am correct, what about session mode messaging=20 > service which is=20 > >>> also a call initiated by INVITE? > >>> > >>> thanks > >>> Peili > >>> > >>> -----Original Message----- > >>> From: Shida Schubert [mailto:shida@ntt-at.com] > >>> Sent: Saturday, January 27, 2007 2:29 AM > >>> To: Jonathan Rosenberg > >>> Cc: Miguel Garcia; bliss@ietf.org > >>> 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: > >>> =20 > >>>> OK, I think this is a reasonable change to the charter. > >>>> > >>>> -Jonathan R. > >>>> > >>>> Miguel Garcia wrote: > >>>> > >>>> =20 > >>>>> Jonathan Rosenberg wrote: > >>>>> > >>>>> =20 > >>>>>> Miguel Garcia wrote: > >>>>>> > >>>>>> =20 > >>>>>>> I think it is reasonable to work on the approach that > >> you propose, > >>>>>>> Jonathan. I have a couple of questions and comments about the=20 > >>>>>>> proposed charter. > >>>>>>> > >>>>>>> 1) When the charter speaks about heterogeneous > >> networks, does it > >>>>>>> refer only to SIP networks or does it consider=20 > interoperability=20 > >>>>>>> across, say, the PSTN. I am sure the TISPAN guys will=20 > ask this=20 > >>>>>>> question sooner or later, so better to write the > >> answer, whatever > >>>>>>> it is, in the charter. > >>>>>>> =20 > >>>>>> Its referring to SIP neworks. The heterogeneity refers to=20 > >>>>>> endpoints, which includes gateways to the PSTN. Thus, > >> the idea was > >>>>>> most definitely to take into considerating how a gateway might=20 > >>>>>> 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=20 > features to=20 > >>>>>> 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? > >>>>>> =20 > >>>>> I am satisfied with your explanation. When I read the charter I=20 > >>>>> 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 "...=20 > >> and for the > >>>>> desire to work across domain boundaries and to seamless=20 > interwork=20 > >>>>> with the PSTN, when applicable". > >>>>> > >>>>> /Miguel > >>>>> > >>>>> > >>>>> > >>>>> =20 > >>> > >>> _______________________________________________ > >>> BLISS mailing list > >>> BLISS@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/bliss > >>> > >>> > >>> > >>> =20 > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:38:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCe1Z-0002hf-BG; Thu, 01 Feb 2007 10:38:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCe1Y-0002h9-Ef for bliss@ietf.org; Thu, 01 Feb 2007 10:38:56 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCe1V-0000WD-GG for bliss@ietf.org; Thu, 01 Feb 2007 10:38:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l11FZn2f020753; Thu, 1 Feb 2007 17:35:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:38:46 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:38:46 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:38:46 +0200 Message-ID: <45C20980.8060605@nokia.com> Date: Thu, 01 Feb 2007 17:38:40 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: dale.worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> In-Reply-To: <200702011527.l11FRg7o029565@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 15:38:46.0039 (UTC) FILETIME=[0F6DBA70:01C74617] X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Correct, s/media stream/media type /Miguel bliss-bounces@ietf.org wrote: > From: Miguel Garcia > > DND can also apply to a particular media stream. In particular, if I am > in a meeting, I may want to activate the DND for audio and video, but > not for messaging. > > I assume you mean "media type" here -- a media stream is what is > established by an m line in the SDP of an existing dialog. But you > couldn't apply DND to a media *stream* until it exists, and at that > point, it's too late. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 10:59:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeKu-0001kP-U4; Thu, 01 Feb 2007 10:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeKt-0001gQ-JP for bliss@ietf.org; Thu, 01 Feb 2007 10:58:55 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeKq-0004wt-8L for bliss@ietf.org; Thu, 01 Feb 2007 10:58:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCS00E8WKDZZW@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 01 Feb 2007 07:58:48 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCS004CEKDYK8@usaga01-in.huawei.com> for bliss@ietf.org; Thu, 01 Feb 2007 07:58:47 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCS00BD7KWEU2@usaml03-in.huawei.com> for bliss@ietf.org; Thu, 01 Feb 2007 08:09:51 -0800 (PST) Date: Thu, 01 Feb 2007 09:58:38 -0600 From: Spencer Dawkins Subject: Re: [BLISS] Welcome! Main question - what services? To: bliss@ietf.org Message-id: <03f101c74619$d7219ee0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <5D1A7985295922448D5550C94DE29180C14D73@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree with Keith, Peili, and Paul here. I am sympathetic to the need to get something out quickly, but also see the need for requirements analysis, so we don't codify patterns that don't work in situations that we weren't thinking about. Spencer From: "Drage, Keith (Keith)" Sent: Thursday, February 01, 2007 9:30 AM Subject: RE: [BLISS] Welcome! Main question - what services? Agreed. It is these type of considerations that allow to actually know whether the service makes sense in its new environment. They do need to form part of any requirements analysis in the proposed BLISS. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 01 February 2007 14:10 > To: Drage, Keith (Keith) > Cc: shida@ntt-at.com; Peili Xu; bliss@ietf.org > 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 12:15:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfWl-0002UJ-JB; Thu, 01 Feb 2007 12:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfWk-0002UC-ST for bliss@ietf.org; Thu, 01 Feb 2007 12:15:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCfWj-0007Vi-4x for bliss@ietf.org; Thu, 01 Feb 2007 12:15:14 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 09:14:49 -0800 X-IronPort-AV: i="4.13,268,1167638400"; d="scan'208"; a="384763761:sNHT63847868182" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l11HEmRn011917; Thu, 1 Feb 2007 09:14:48 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l11HEVnX002035; Thu, 1 Feb 2007 09:14:43 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:14:28 -0500 Received: from [161.44.183.228] ([161.44.183.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:14:26 -0500 Message-ID: <45C21FF0.5020805@cisco.com> Date: Thu, 01 Feb 2007 12:14:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> <45C20980.8060605@nokia.com> In-Reply-To: <45C20980.8060605@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 17:14:26.0810 (UTC) FILETIME=[6D31DDA0:01C74624] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2109; t=1170350088; x=1171214088; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=i//fXqU1IGGDM4QY1Wit2dDQymEVD5g66u60CFI33S0=; b=MUlLivgXUbyj3bULSgTCAaa3IGCU0jIuZbdwi/UG4c1ZQfbAFZysrALxfuvOfnPoIpEoIxOh EWkuCkBkFGZc3ymeVVODXoJCCnqF5xz0Om8xMMdMx6weKa6NFgf2V2Sy; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: bliss@ietf.org, dale.worley@comcast.net X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I don't think I buy this flavor of DND. I think it will cause interop problems. IMO the key aspect of DND is about alerting. Which media that are eligible to be used may also be relevant, but I think it is an orthogonal issue. For instance, if you are willing to use MSRP, but not audio or video, then your UA can reject offered audio and video media streams while accepting msrp streams. If rejecting audio and video means that no offered streams are being accepted, then the UA may indeed want to reject the call without alerting. But I don't think that is DND. AFAIK DND only applies during session establishment. Willingness to use media streams applies to mid-call changes as well. I think there is a very interesting subject of how media in a call are negotiated and changed. This is relatively clear from an O/A perspective, but when you start to consider user preferences at each end and how they can change mid call it gets much less clear. (E.g. when you have audio/video capable UAs you often will want to start with video disabled, and then maybe enable it later. But both ends need to enable before it can be used. Requires a little more that existing O/A to support a plausible UI.) While interesting, I think this probably falls into the category of "advanced" features. Paul Miguel Garcia wrote: > Correct, s/media stream/media type > > /Miguel > > bliss-bounces@ietf.org wrote: >> From: Miguel Garcia >> >> DND can also apply to a particular media stream. In particular, if >> I am in a meeting, I may want to activate the DND for audio and >> video, but not for messaging. >> >> I assume you mean "media type" here -- a media stream is what is >> established by an m line in the SDP of an existing dialog. But you >> couldn't apply DND to a media *stream* until it exists, and at that >> point, it's too late. >> >> Dale >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Feb 01 14:43:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChqW-00027q-FR; Thu, 01 Feb 2007 14:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChqU-000236-O8 for bliss@ietf.org; Thu, 01 Feb 2007 14:43:46 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HChqS-0006aw-DO for bliss@ietf.org; Thu, 01 Feb 2007 14:43:46 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l11JhgoF025177; Thu, 1 Feb 2007 12:43:43 -0700 Message-ID: <45C242F0.402@ntt-at.com> Date: Thu, 01 Feb 2007 11:43:44 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1C8F9.5090705@ntt-at.com> <200702011458.l11EwOB3027408@dragon.ariadne.com> In-Reply-To: <200702011458.l11EwOB3027408@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Dale; I think we are on the same page. As I mentioned in another e-mail, I see session based messaging as just another media, and I don't think special attention is needed for the session based messaging as it's just another media, the service invocation would doubtfully be different.. What I was trying to state below is if there is a service needed to be defined which is to be utilized only by session based messaging(a specific media), I don't think BLISS is the place to do it(chat based on session based messaging for example). Regards Shida Dale.Worley@comcast.net wrote: > From: Shida Schubert > > But defining services solely used by session based messaging and > presence has a home called SIMPLE at this present moment, and I see > no reasons why BLISS should take on them as long as SIMPLE exists. > > I don't know about presence. But within the SIP philosophy, > session-based messaging is "just another media type" when compared to > audio calling. So it seems to me that if we discern an apparent > difference in "calling features" between session-based messaging and > audio calling, we are probably misunderstanding the situation. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 03:34:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCts9-00018v-Rv; Fri, 02 Feb 2007 03:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCts8-00018f-9a for bliss@ietf.org; Fri, 02 Feb 2007 03:34:16 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCts4-0001EQ-U4 for bliss@ietf.org; Fri, 02 Feb 2007 03:34:16 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JCT00MDUUG9C7@siemenscomms.co.uk> for bliss@ietf.org; Fri, 02 Feb 2007 08:33:46 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 02 Feb 2007 08:33:44 +0000 Content-return: allowed Date: Fri, 02 Feb 2007 08:33:39 +0000 From: "Elwell, John" Subject: RE: [BLISS] Welcome! Main question - what services? To: Miguel Garcia , "Drage, Keith (Keith)" Message-id: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Miguel, An entity providing a DND service should be able filter based on any number of criteria. One criterion might be the set of media requested (e.g., DND to any offer involving audio). This filtering doesn't need to be standardised, unless some sort of reason (e.g., can't accept audio) needs to be returned to the caller. John > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: 01 February 2007 15:13 > To: Drage, Keith (Keith) > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? > > Right... the capability of indicating a DND for SIP offers > that contain > certain media streams. Similarly with SIP methods. > > /Miguel > > Drage, Keith (Keith) wrote: > > I assume that you mean you wish to be DND to a request with > a SIP offer > > of a particular media stream, rather than just DND to a > particular media > > stream. > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > >> Sent: 01 February 2007 15:02 > >> To: Paul Kyzivat > >> Cc: Drage, Keith (Keith); bliss@ietf.org > >> Subject: Re: [BLISS] Welcome! Main question - what services? > >> > >> DND can also apply to a particular media stream. In > >> particular, if I am in a meeting, I may want to activate the > >> DND for audio and video, but not for messaging. > >> > >> I guess in general, you need to consider all the different > >> media streams that can apply to service. It would be a big > >> mistake just to restrict to audio or to "things that are > >> initiated with an INVITE" because this is what the PSTN did. > >> > >> /Miguel > >> > >> Paul Kyzivat wrote: > >>> 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 > >>> > >> > >> -- > >> Miguel A. Garcia tel:+358-50-4804586 > >> sip:miguel.garcia@neonsite.net > >> Nokia Research Center Helsinki, Finland > >> > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 08:00:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCy1l-0005zS-00; Fri, 02 Feb 2007 08:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCy1k-0005xS-Aa for bliss@ietf.org; Fri, 02 Feb 2007 08:00:28 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCy1h-00028V-58 for bliss@ietf.org; Fri, 02 Feb 2007 08:00:28 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l12Cv1xo018466; Fri, 2 Feb 2007 14:57:25 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 14:59:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:00:04 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 14:59:46 +0200 Message-ID: <45C335C1.1060205@nokia.com> Date: Fri, 02 Feb 2007 14:59:45 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> <45C20980.8060605@nokia.com> <45C21FF0.5020805@cisco.com> In-Reply-To: <45C21FF0.5020805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 12:59:46.0922 (UTC) FILETIME=[0415BCA0:01C746CA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202145725-474DABB0-3AE8253F/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: bliss@ietf.org, dale.worley@comcast.net X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Inline discussion. Paul Kyzivat wrote: > I don't think I buy this flavor of DND. I think it will cause interop > problems. This is exactly what BLISS has to solve, avoid interop problems. > > IMO the key aspect of DND is about alerting. Which media that are > eligible to be used may also be relevant, but I think it is an > orthogonal issue. I agree that DND is about alerting. The conditions to indicate such alerting cases are driven by the user, and the user should be able to set such conditions based on whatever parameters he wants. Perhaps based on time (connected to calendar), based on present media types in the Offer as we discussed earlier, etc. > > For instance, if you are willing to use MSRP, but not audio or video, > then your UA can reject offered audio and video media streams while > accepting msrp streams. If rejecting audio and video means that no > offered streams are being accepted, then the UA may indeed want to > reject the call without alerting. But I don't think that is DND. I agree that rejecting media is not DND, and I agree that DND is about alerting. So I don't think we shouldn't be discussing the rejecting aspects, which are not DND. We should be discussing when the alert is delivered to the end user, and I am saying that this not a binary operation, but they are many inputs to that decision. > > AFAIK DND only applies during session establishment. Willingness to use > media streams applies to mid-call changes as well. Agreed too. > > I think there is a very interesting subject of how media in a call are > negotiated and changed. This is relatively clear from an O/A > perspective, but when you start to consider user preferences at each end > and how they can change mid call it gets much less clear. (E.g. when you > have audio/video capable UAs you often will want to start with video > disabled, and then maybe enable it later. But both ends need to enable > before it can be used. Requires a little more that existing O/A to > support a plausible UI.) While interesting, I think this probably falls > into the category of "advanced" features. Agreed too. /Miguel > > Paul > > Miguel Garcia wrote: >> Correct, s/media stream/media type >> >> /Miguel >> >> bliss-bounces@ietf.org wrote: >>> From: Miguel Garcia >>> >>> DND can also apply to a particular media stream. In particular, if >>> I am in a meeting, I may want to activate the DND for audio and >>> video, but not for messaging. >>> >>> I assume you mean "media type" here -- a media stream is what is >>> established by an m line in the SDP of an existing dialog. But you >>> couldn't apply DND to a media *stream* until it exists, and at that >>> point, it's too late. >>> >>> Dale >>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www1.ietf.org/mailman/listinfo/bliss >>> >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 08:03:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCy4m-0007g7-5V; Fri, 02 Feb 2007 08:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCy4k-0007fT-Hs for bliss@ietf.org; Fri, 02 Feb 2007 08:03:34 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCy4X-0002pj-HT for bliss@ietf.org; Fri, 02 Feb 2007 08:03:34 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l12D05EV019377; Fri, 2 Feb 2007 15:00:21 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:02:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:03:03 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:02:45 +0200 Message-ID: <45C33674.3000508@nokia.com> Date: Fri, 02 Feb 2007 15:02:44 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 13:02:45.0834 (UTC) FILETIME=[6EB98AA0:01C746CA] X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org John: We agree that one possible criterion to DND is the media type(s) requested in the offer. While this does not need to be standardized itself, perhaps we need to standardize the interface from the endpoint to the application server that executes the DND server. This depends basically on how the service is implemented, and in particular, on whether the service is network provided or not. But I think it is worth having a discussion on how the service can work in such circumstances. /Miguel Elwell, John wrote: > Miguel, > > An entity providing a DND service should be able filter based on any number > of criteria. One criterion might be the set of media requested (e.g., DND to > any offer involving audio). This filtering doesn't need to be standardised, > unless some sort of reason (e.g., can't accept audio) needs to be returned > to the caller. > > John > >> -----Original Message----- >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >> Sent: 01 February 2007 15:13 >> To: Drage, Keith (Keith) >> Cc: bliss@ietf.org >> Subject: Re: [BLISS] Welcome! Main question - what services? >> >> Right... the capability of indicating a DND for SIP offers >> that contain >> certain media streams. Similarly with SIP methods. >> >> /Miguel >> >> Drage, Keith (Keith) wrote: >>> I assume that you mean you wish to be DND to a request with >> a SIP offer >>> of a particular media stream, rather than just DND to a >> particular media >>> stream. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>>> Sent: 01 February 2007 15:02 >>>> To: Paul Kyzivat >>>> Cc: Drage, Keith (Keith); bliss@ietf.org >>>> Subject: Re: [BLISS] Welcome! Main question - what services? >>>> >>>> DND can also apply to a particular media stream. In >>>> particular, if I am in a meeting, I may want to activate the >>>> DND for audio and video, but not for messaging. >>>> >>>> I guess in general, you need to consider all the different >>>> media streams that can apply to service. It would be a big >>>> mistake just to restrict to audio or to "things that are >>>> initiated with an INVITE" because this is what the PSTN did. >>>> >>>> /Miguel >>>> >>>> Paul Kyzivat wrote: >>>>> 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 >>>>> >>>> -- >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> sip:miguel.garcia@neonsite.net >>>> Nokia Research Center Helsinki, Finland >>>> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.garcia@neonsite.net >> Nokia Research Center Helsinki, Finland >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 10:56:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0lo-0005mh-G0; Fri, 02 Feb 2007 10:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0ln-0005mQ-9q for bliss@ietf.org; Fri, 02 Feb 2007 10:56:11 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0le-000446-DS for bliss@ietf.org; Fri, 02 Feb 2007 10:56:11 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070202155601b1400itb6ge>; Fri, 2 Feb 2007 15:56:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l12Fu098007257 for ; Fri, 2 Feb 2007 10:56:00 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l12Fu0Ht007253; Fri, 2 Feb 2007 10:56:00 -0500 Date: Fri, 2 Feb 2007 10:56:00 -0500 Message-Id: <200702021556.l12Fu0Ht007253@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> (john.elwell@siemens.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Elwell, John" An entity providing a DND service should be able filter based on any number of criteria. One criterion might be the set of media requested (e.g., DND to any offer involving audio). I don't quite see what the dispute is here -- Certainly, it's possible to put a UA into a state where it doesn't accept a media type that it normally would. Whether we want to call this a form of "Do Not Disturb" seems to be entirely a matter of definition. And since all the machinery needed to implement it already exists, I see no need for further standardization. This filtering doesn't need to be standardised, unless some sort of reason (e.g., can't accept audio) needs to be returned to the caller. I'm not up on the offer/answer machinery, but isn't there a way to indicate this, by declining every offered m-line in the INVITE's SDP in a 200 response? I know that there is a standard indication for "all of the codecs/media you have offered are unacceptable to me". My belief is that 488 is restricted to meaning "I can't process application/sdp [or whatever content-type was in the request]", but I might very well be wrong about that. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 11:05:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0uZ-0001aX-I9; Fri, 02 Feb 2007 11:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0uY-0001aP-I7 for bliss@ietf.org; Fri, 02 Feb 2007 11:05:14 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0uP-0005rc-R7 for bliss@ietf.org; Fri, 02 Feb 2007 11:05:14 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007020216050501400q7qdne>; Fri, 2 Feb 2007 16:05:05 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l12G5498007918 for ; Fri, 2 Feb 2007 11:05:04 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l12G54YS007914; Fri, 2 Feb 2007 11:05:04 -0500 Date: Fri, 2 Feb 2007 11:05:04 -0500 Message-Id: <200702021605.l12G54YS007914@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45C21FF0.5020805@cisco.com> (pkyzivat@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> <45C20980.8060605@nokia.com> <45C21FF0.5020805@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Paul Kyzivat I think there is a very interesting subject of how media in a call are negotiated and changed. This is relatively clear from an O/A perspective, but when you start to consider user preferences at each end and how they can change mid call it gets much less clear. (E.g. when you have audio/video capable UAs you often will want to start with video disabled, and then maybe enable it later. But both ends need to enable before it can be used. Requires a little more that existing O/A to support a plausible UI.) While interesting, I think this probably falls into the category of "advanced" features. I don't see this as troublesome. Whenever either end changes its "allow video" status, it initiates a re-INVITE cycle. Video will only beenabled when both ends have "allow video" set. For example: A B (no video) (no video) INVITE (audio) --> <-- 200 (audio) only audio passes (user A enables video) reINVITE (audio, video) --> <-- 200 (audio) only audio passes (user B enables video) <-- reINVITE (audio, video) 200 (audio, video) --> audio and video pass (user A disables video) reINVITE (audio) --> <-- 200 (audio) only audio passes Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 13:01:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2ip-0004Ww-Nw; Fri, 02 Feb 2007 13:01:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2in-0004U7-B1 for bliss@ietf.org; Fri, 02 Feb 2007 13:01:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2ij-0001aD-MK for bliss@ietf.org; Fri, 02 Feb 2007 13:01:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2007 13:01:09 -0500 X-IronPort-AV: i="4.13,273,1167627600"; d="scan'208"; a="113033737:sNHT51556348" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l12I19Rc009244; Fri, 2 Feb 2007 13:01:09 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l12I19VT025712; Fri, 2 Feb 2007 13:01:09 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 13:01:08 -0500 Received: from [161.44.183.228] ([161.44.183.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 13:01:08 -0500 Message-ID: <45C37C6B.4030302@cisco.com> Date: Fri, 02 Feb 2007 13:01:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> <45C20980.8060605@nokia.com> <45C21FF0.5020805@cisco.com> <200702021605.l12G54YS007914@dragon.ariadne.com> In-Reply-To: <200702021605.l12G54YS007914@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 18:01:08.0614 (UTC) FILETIME=[1D9CFA60:01C746F4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3635; t=1170439269; x=1171303269; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=Yq2xLVvn+6XheIehgXRI/VQcBC+Nyjj68xClAX55pMk=; b=NyG2xo0/bxPtEqR5hqeMYWkRPRlUwlBnndOEPliWQJjMbbSfPWm0pW8M/vl6rFO5mbOMcHJ+ 7d9VxAeDWb74AjJM+B4XG4iRqh9TGYg+t+njlTEaorytkqNH9QIcVlxq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale, what you outline will work. But when A enabled video he presumably was interested in having it. But B (the human) doesn't know that. So it requires some other jog for B to enable video. There has been some discussion off and on that when the reinvite comes with a video offer, B should alert its user and ask for confirmation. But I think that will cause problems. An alternative is for the device to note that it has been offered something that it could support but that is currently disabled, and to display an indicator to that effect. This gives the user the hint that he might want to enable his end. I'm not suggesting that we want to standardize these kinds of UI behaviors. And I think we have all the signaling mechanisms needed to make this work. But I think we have the potential for poor interop unless some use cases are worked through, and some best practices identified. The most obvious problem is if some devices start alerting on reinvite with new media while others depend on reinvites completing immediately without alerting. Another interesting case is whether a device should ever accept a call while rejecting all the media offered in the call. If it does, it might prevent the call from being answered by a different device that supports at least one of the offered media. But in some cases there might be value in answering. (E.g. if you have your audio+im phone set to im-only and a voice-only call comes in, maybe you want it to let you answer without the audio, offer IM back, and if that fails let you know so you can go someplace else and enable the audio.) I expect there are many of these mixed mode use cases, intimately tied to the UI on the device. We need to "let a 1000 flowers bloom" here, but at the same time maximize the interoperability of them all. (I certainly don't want to see every one identified as a separate "service" that can only talk to another device that supports the same service.) Paul Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > I think there is a very interesting subject of how media in a call are > negotiated and changed. This is relatively clear from an O/A > perspective, but when you start to consider user preferences at each end > and how they can change mid call it gets much less clear. (E.g. when you > have audio/video capable UAs you often will want to start with video > disabled, and then maybe enable it later. But both ends need to enable > before it can be used. Requires a little more that existing O/A to > support a plausible UI.) While interesting, I think this probably falls > into the category of "advanced" features. > > I don't see this as troublesome. Whenever either end changes its > "allow video" status, it initiates a re-INVITE cycle. Video will only > beenabled when both ends have "allow video" set. > > For example: > > > A B > > (no video) (no video) > > INVITE (audio) --> > <-- 200 (audio) > > only audio passes > > (user A enables video) > > reINVITE (audio, video) --> > <-- 200 (audio) > > only audio passes > > (user B enables video) > > <-- reINVITE (audio, video) > 200 (audio, video) --> > > audio and video pass > > (user A disables video) > > reINVITE (audio) --> > <-- 200 (audio) > > only audio passes > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 16:08:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5dZ-0007w6-Lo; Fri, 02 Feb 2007 16:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5dX-0007vZ-7Q for bliss@ietf.org; Fri, 02 Feb 2007 16:07:59 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD5d0-0006Ih-Ks for bliss@ietf.org; Fri, 02 Feb 2007 16:07:59 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007020221072501300fshnpe>; Fri, 2 Feb 2007 21:07:25 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l12L6498029753 for ; Fri, 2 Feb 2007 16:06:04 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l12L64c5029749; Fri, 2 Feb 2007 16:06:04 -0500 Date: Fri, 2 Feb 2007 16:06:04 -0500 Message-Id: <200702022106.l12L64c5029749@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45C37C6B.4030302@cisco.com> (pkyzivat@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1F4A6.9040704@cisco.com> <45C200DF.2020908@nokia.com> <200702011527.l11FRg7o029565@dragon.ariadne.com> <45C20980.8060605@nokia.com> <45C21FF0.5020805@cisco.com> <200702021605.l12G54YS007914@dragon.ariadne.com> <45C37C6B.4030302@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Paul Kyzivat But I think we have the potential for poor interop unless some use cases are worked through, and some best practices identified. Ah, yes, a subtle and interesting point -- we have standardized all the mechanisms that we need, but unless we *restrict* them with good BCPs, interoperability suffers. I believe that I didn't notice this because I tend to have strong opinions about how mechanisms should be used, and didn't realize the interop problems if someone else does things differently. Another interesting case is whether a device should ever accept a call while rejecting all the media offered in the call. If it does, it might prevent the call from being answered by a different device that supports at least one of the offered media. But in some cases there might be value in answering. (E.g. if you have your audio+im phone set to im-only and a voice-only call comes in, maybe you want it to let you answer without the audio, offer IM back, and if that fails let you know so you can go someplace else and enable the audio.) Ugh. It seems like rejecting the call will almost always be best (but that assumes that the caller proposes all media that he would be willing to accept under any circumstances). BTW, what error should a UA use in this case? It seems that 488 is correct, but the writeup in 3261 almost makes that sound improper. (Or is this coverd in the new offer/answer I-D?) (I certainly don't want to see every one identified as a separate "service" that can only talk to another device that supports the same service.) Yes, the automatic fallback to the highest-shared-level-of-functionality is one of the strengths of the Internet design philosophy. And this is commercially important, too -- I've seen presentations given to telecomm operators by SIP equipment vendors, and a major selling point is "no profiles are needed", that when you interconnect two vendors' SIP equipment, they figure out what they have in common with no specific configuration. It seems with traditional telecomm equipment, someone sits down and figures out the lowest common denominator, and then configures everything to know that they can only use those features. Which is why the "service identifier" work seems strange to me -- it's clear that the service identifiers are intended to be Requires features, but in most cases that assumes that both endpoints have to know that they both support the same feature before they can interconnect at all. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 17:55:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7Jv-0002MS-KH; Fri, 02 Feb 2007 17:55:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7Ju-0002Ef-Nk for bliss@ietf.org; Fri, 02 Feb 2007 17:55:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD7Jh-0006CK-E8 for bliss@ietf.org; Fri, 02 Feb 2007 17:55:50 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BD985204FB; Fri, 2 Feb 2007 23:55:26 +0100 (CET) X-AuditID: c1b4fb3c-ae7c5bb0000007de-5b-45c3c15ec394 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D76720411; Fri, 2 Feb 2007 23:55:26 +0100 (CET) Received: from esealmw111.eemea.ericsson.se ([130.100.184.156]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 23:55:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Welcome! Main question - what services? Date: Fri, 2 Feb 2007 23:55:25 +0100 Message-ID: In-Reply-To: <45C37C6B.4030302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdG9EQTLEXv8YmpTLuMCgMoSJurlwAIiSdQ From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP_=28KI/EAB=29?= To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Feb 2007 22:55:26.0077 (UTC) FILETIME=[3A4802D0:01C7471D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.9 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Paul, From: Paul Kyzivat I'm not suggesting that we want to standardize these kinds of UI = behaviors.=20 And I think we have all the signaling mechanisms needed to make this = work.=20 But I think we have the potential for poor interop unless some use = cases are=20 worked through, and some best practices identified. You mean defining best practice in the UI design (human-device/system = interaction) for a particular type of "service", right? Assuming You have that in mind, You're saying don't standardise the UI = behaviour but describe best practice. How does that solve the problem (in any way different than standardisation)? Is it that we = will only "standardise", with BCP, a part of the service behaviour (as seen from the end user)? Regards G=F6ran PS.=20 =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: den 2 februari 2007 19:01 To: Dale.Worley@comcast.net Cc: bliss@ietf.org Subject: Re: [BLISS] Welcome! Main question - what services? Dale, what you outline will work. But when A enabled video he presumably was = interested in having it. But B (the human) doesn't know that. So it = requires some other jog for B to enable video. There has been some discussion off and on that when the reinvite comes = with a video offer, B should alert its user and ask for confirmation.=20 But I think that will cause problems. An alternative is for the device = to note that it has been offered something that it could support but = that is currently disabled, and to display an indicator to that effect.=20 This gives the user the hint that he might want to enable his end. I'm not suggesting that we want to standardize these kinds of UI = behaviors. And I think we have all the signaling mechanisms needed to = make this work. But I think we have the potential for poor interop = unless some use cases are worked through, and some best practices = identified. The most obvious problem is if some devices start alerting = on reinvite with new media while others depend on reinvites completing = immediately without alerting. Another interesting case is whether a device should ever accept a call = while rejecting all the media offered in the call. If it does, it might = prevent the call from being answered by a different device that supports = at least one of the offered media. But in some cases there might be = value in answering. (E.g. if you have your audio+im phone set to im-only = and a voice-only call comes in, maybe you want it to let you answer = without the audio, offer IM back, and if that fails let you know so you = can go someplace else and enable the audio.) I expect there are many of these mixed mode use cases, intimately tied = to the UI on the device. We need to "let a 1000 flowers bloom" here, but = at the same time maximize the interoperability of them all. (I certainly = don't want to see every one identified as a separate "service" that can = only talk to another device that supports the same service.) Paul Dale.Worley@comcast.net wrote: > From: Paul Kyzivat >=20 > I think there is a very interesting subject of how media in a call = are=20 > negotiated and changed. This is relatively clear from an O/A=20 > perspective, but when you start to consider user preferences at = each end=20 > and how they can change mid call it gets much less clear. (E.g. = when you=20 > have audio/video capable UAs you often will want to start with = video=20 > disabled, and then maybe enable it later. But both ends need to = enable=20 > before it can be used. Requires a little more that existing O/A to=20 > support a plausible UI.) While interesting, I think this probably = falls=20 > into the category of "advanced" features. >=20 > I don't see this as troublesome. Whenever either end changes its=20 > "allow video" status, it initiates a re-INVITE cycle. Video will only = > beenabled when both ends have "allow video" set. >=20 > For example: >=20 >=20 > A B >=20 > (no video) (no video) >=20 > INVITE (audio) --> > <-- 200 (audio) >=20 > only audio passes >=20 > (user A enables video) >=20 > reINVITE (audio, video) --> > <-- 200 (audio) >=20 > only audio passes >=20 > (user B enables video) >=20 > <-- reINVITE (audio, video) > 200 (audio, video) --> >=20 > audio and video pass >=20 > (user A disables video) >=20 > reINVITE (audio) --> > <-- 200 (audio) >=20 > only audio passes >=20 > Dale >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 18:19:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7h2-0000Nc-WF; Fri, 02 Feb 2007 18:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7h1-0000NO-DY for bliss@ietf.org; Fri, 02 Feb 2007 18:19:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD7gz-0001hD-QS for bliss@ietf.org; Fri, 02 Feb 2007 18:19:43 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2007 15:19:41 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208"; a="37016113:sNHT209838519" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l12NJawa012714; Fri, 2 Feb 2007 15:19:36 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l12NJcnF027053; Fri, 2 Feb 2007 15:19:38 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 18:19:40 -0500 Received: from [161.44.183.228] ([161.44.183.228]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 18:19:39 -0500 Message-ID: <45C3C70C.4050407@cisco.com> Date: Fri, 02 Feb 2007 18:19:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22G=F6ran_Eriksson_AP_=28KI/EAB=29=22?= Subject: Re: [BLISS] Welcome! Main question - what services? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Feb 2007 23:19:39.0711 (UTC) FILETIME=[9CB6F4F0:01C74720] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5142; t=1170458376; x=1171322376; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=gylPu4ymvTOoV8Lv5hu8RVLxoN95x4/zmNw+gogGuvY=; b=I5u6DtVjXpCYPVgQoSiFxqAQCaRUuZM1lyqWicICG5NhhDHQyhzkSk5cNeuzMj3cGK+yIVWd bneL3cN1oi87VJXmKobch+4r3Q+Fwmps9o+IE7ZSJysx8SaN8x+cIGoa; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Göran Eriksson AP (KI/EAB) wrote: > Hi Paul, > > From: Paul Kyzivat > > I'm not suggesting that we want to standardize these kinds of UI behaviors. > And I think we have all the signaling mechanisms needed to make this work. > But I think we have the potential for poor interop unless some use cases are > worked through, and some best practices identified. > > You mean defining best practice in the UI design (human-device/system interaction) for a particular type of "service", right? No. I mean defining best practice in sip (and sdp o/a) usage so that the various scenarios that people come up with can work and interoperate reasonably when the two ends don't have the same UI. > Assuming You have that in mind, You're saying don't standardise the UI behaviour but describe best practice. How does that solve > the problem (in any way different than standardisation)? Is it that we will only "standardise", with BCP, a part of the > service behaviour (as seen from the end user)? > > Regards > Göran > > PS. > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: den 2 februari 2007 19:01 > To: Dale.Worley@comcast.net > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? > > Dale, > > what you outline will work. But when A enabled video he presumably was interested in having it. But B (the human) doesn't know that. So it requires some other jog for B to enable video. > > There has been some discussion off and on that when the reinvite comes with a video offer, B should alert its user and ask for confirmation. > But I think that will cause problems. An alternative is for the device to note that it has been offered something that it could support but that is currently disabled, and to display an indicator to that effect. > This gives the user the hint that he might want to enable his end. > > I'm not suggesting that we want to standardize these kinds of UI behaviors. And I think we have all the signaling mechanisms needed to make this work. But I think we have the potential for poor interop unless some use cases are worked through, and some best practices identified. The most obvious problem is if some devices start alerting on reinvite with new media while others depend on reinvites completing immediately without alerting. > > Another interesting case is whether a device should ever accept a call while rejecting all the media offered in the call. If it does, it might prevent the call from being answered by a different device that supports at least one of the offered media. But in some cases there might be value in answering. (E.g. if you have your audio+im phone set to im-only and a voice-only call comes in, maybe you want it to let you answer without the audio, offer IM back, and if that fails let you know so you can go someplace else and enable the audio.) > > I expect there are many of these mixed mode use cases, intimately tied to the UI on the device. We need to "let a 1000 flowers bloom" here, but at the same time maximize the interoperability of them all. (I certainly don't want to see every one identified as a separate "service" that can only talk to another device that supports the same service.) > > Paul > > Dale.Worley@comcast.net wrote: >> From: Paul Kyzivat >> >> I think there is a very interesting subject of how media in a call are >> negotiated and changed. This is relatively clear from an O/A >> perspective, but when you start to consider user preferences at each end >> and how they can change mid call it gets much less clear. (E.g. when you >> have audio/video capable UAs you often will want to start with video >> disabled, and then maybe enable it later. But both ends need to enable >> before it can be used. Requires a little more that existing O/A to >> support a plausible UI.) While interesting, I think this probably falls >> into the category of "advanced" features. >> >> I don't see this as troublesome. Whenever either end changes its >> "allow video" status, it initiates a re-INVITE cycle. Video will only >> beenabled when both ends have "allow video" set. >> >> For example: >> >> >> A B >> >> (no video) (no video) >> >> INVITE (audio) --> >> <-- 200 (audio) >> >> only audio passes >> >> (user A enables video) >> >> reINVITE (audio, video) --> >> <-- 200 (audio) >> >> only audio passes >> >> (user B enables video) >> >> <-- reINVITE (audio, video) >> 200 (audio, video) --> >> >> audio and video pass >> >> (user A disables video) >> >> reINVITE (audio) --> >> <-- 200 (audio) >> >> only audio passes >> >> Dale >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 18:26:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7ng-0008PX-0P; Fri, 02 Feb 2007 18:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7nf-0008PK-9k for bliss@ietf.org; Fri, 02 Feb 2007 18:26:35 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD7nY-0002Ua-J5 for bliss@ietf.org; Fri, 02 Feb 2007 18:26:35 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F2E1B200EA; Sat, 3 Feb 2007 00:26:23 +0100 (CET) X-AuditID: c1b4fb3e-b0ed5bb0000007e1-23-45c3c89f06a3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CEBA8200BE; Sat, 3 Feb 2007 00:26:23 +0100 (CET) Received: from esealmw111.eemea.ericsson.se ([130.100.184.156]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 00:26:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Welcome! Main question - what services? Date: Sat, 3 Feb 2007 00:26:15 +0100 Message-ID: In-Reply-To: <45C3C70C.4050407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Welcome! Main question - what services? Thread-Index: AcdHIJ8H/diybd3JRsmz/tXxlJujbgAABDyw From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP_=28KI/EAB=29?= To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Feb 2007 23:26:23.0469 (UTC) FILETIME=[8D5F89D0:01C74721] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.9 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org interoperate reasonably=20 Sorry for being picky or perhaps just a bit slow this late in the = evening in the dark Nordic night, but interoperate from which = perspective? OK, not the way interaction design details like buttons color, etc, but = at least interaction design in terms of what the user expects from the "system", read device, and how he/she = interacts with it to achieve some result, right? Let's not call it UI design but it is then getting us into defining the = user-system interaction, or rather describing a best practice for it? BR G=F6ran -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: den 3 februari 2007 00:20 To: G=F6ran Eriksson AP (KI/EAB) Cc: bliss@ietf.org; Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? G=F6ran Eriksson AP (KI/EAB) wrote: > Hi Paul, >=20 > From: Paul Kyzivat >=20 > I'm not suggesting that we want to standardize these kinds of UI = behaviors.=20 > And I think we have all the signaling mechanisms needed to make this = work.=20 > But I think we have the potential for poor interop unless some use = cases are=20 > worked through, and some best practices identified. >=20 > You mean defining best practice in the UI design (human-device/system = interaction) for a particular type of "service", right? No. I mean defining best practice in sip (and sdp o/a) usage so that the = various scenarios that people come up with can work and interoperate = reasonably when the two ends don't have the same UI. > Assuming You have that in mind, You're saying don't standardise the UI = > behaviour but describe best practice. How does that solve the problem=20 > (in any way different than standardisation)? Is it that we will only = "standardise", with BCP, a part of the service behaviour (as seen from = the end user)? >=20 > Regards > G=F6ran >=20 > PS.=20 > =20 >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: den 2 februari 2007 19:01 > To: Dale.Worley@comcast.net > Cc: bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? >=20 > Dale, >=20 > what you outline will work. But when A enabled video he presumably was = interested in having it. But B (the human) doesn't know that. So it = requires some other jog for B to enable video. >=20 > There has been some discussion off and on that when the reinvite comes = with a video offer, B should alert its user and ask for confirmation.=20 > But I think that will cause problems. An alternative is for the device = to note that it has been offered something that it could support but = that is currently disabled, and to display an indicator to that effect.=20 > This gives the user the hint that he might want to enable his end. >=20 > I'm not suggesting that we want to standardize these kinds of UI = behaviors. And I think we have all the signaling mechanisms needed to = make this work. But I think we have the potential for poor interop = unless some use cases are worked through, and some best practices = identified. The most obvious problem is if some devices start alerting = on reinvite with new media while others depend on reinvites completing = immediately without alerting. >=20 > Another interesting case is whether a device should ever accept a call = > while rejecting all the media offered in the call. If it does, it=20 > might prevent the call from being answered by a different device that=20 > supports at least one of the offered media. But in some cases there=20 > might be value in answering. (E.g. if you have your audio+im phone set = > to im-only and a voice-only call comes in, maybe you want it to let=20 > you answer without the audio, offer IM back, and if that fails let you = > know so you can go someplace else and enable the audio.) >=20 > I expect there are many of these mixed mode use cases, intimately tied = > to the UI on the device. We need to "let a 1000 flowers bloom" here,=20 > but at the same time maximize the interoperability of them all. (I=20 > certainly don't want to see every one identified as a separate=20 > "service" that can only talk to another device that supports the same=20 > service.) >=20 > Paul >=20 > Dale.Worley@comcast.net wrote: >> From: Paul Kyzivat >> >> I think there is a very interesting subject of how media in a call = are=20 >> negotiated and changed. This is relatively clear from an O/A=20 >> perspective, but when you start to consider user preferences at = each end=20 >> and how they can change mid call it gets much less clear. (E.g. = when you=20 >> have audio/video capable UAs you often will want to start with = video=20 >> disabled, and then maybe enable it later. But both ends need to = enable=20 >> before it can be used. Requires a little more that existing O/A to = >> support a plausible UI.) While interesting, I think this probably = falls=20 >> into the category of "advanced" features. >> >> I don't see this as troublesome. Whenever either end changes its=20 >> "allow video" status, it initiates a re-INVITE cycle. Video will=20 >> only beenabled when both ends have "allow video" set. >> >> For example: >> >> >> A B >> >> (no video) (no video) >> >> INVITE (audio) --> >> <-- 200 (audio) >> >> only audio passes >> >> (user A enables video) >> >> reINVITE (audio, video) --> >> <-- 200 (audio) >> >> only audio passes >> >> (user B enables video) >> >> <-- reINVITE (audio, video) >> 200 (audio, video) --> >> >> audio and video pass >> >> (user A disables video) >> >> reINVITE (audio) --> >> <-- 200 (audio) >> >> only audio passes >> >> Dale >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 02 21:12:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDANb-0000az-My; Fri, 02 Feb 2007 21:11:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDANZ-0000ao-Nb for bliss@ietf.org; Fri, 02 Feb 2007 21:11:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDANY-000515-G9 for bliss@ietf.org; Fri, 02 Feb 2007 21:11:49 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2007 18:11:47 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208"; a="461955282:sNHT44997082" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l132BeFQ031393; Fri, 2 Feb 2007 18:11:40 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l132BhUx026085; Fri, 2 Feb 2007 18:11:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5AD2C83A-ABB6-44BC-B7E2-AF5D0AA8B168@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 2 Feb 2007 18:11:29 -0800 To: bliss@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=55; t=1170468700; x=1171332700; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Good=20news |Sender:=20 |To:=20bliss@ietf.org |Content-Type:=20text/plain=3B=20charset=3DUS-ASCII=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0=20(Apple=20Message=20framework=20v752.3); bh=VZ+mUqAl/n/ok+ApJnZOCQmlQv3FsVq92YJcniPfGL8=; b=nNOGdQBNQ6RfuTz8KOfmlqZdTRvA1v3yijeMCVK+VDENOn1LaU1MTcSH6XSJtusQKslmCSQc S2u3j98G0pNaxtRwt2i06WcZAEbAaOwA62WY+98eL5prBJiEqxj5PKBRiJqZYSawCrC3dUJVIe EUEKjtv8uKCYfIUAoAqc+kdak=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [BLISS] Good news X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org This BOF is approved. Cullen _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Feb 04 11:38:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkNS-0003Xq-7F; Sun, 04 Feb 2007 11:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkNR-0003XO-GG for bliss@ietf.org; Sun, 04 Feb 2007 11:38:05 -0500 Received: from zimbra.mailvision.net ([212.143.248.123] helo=mvimap.mailvision.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDkNP-0004af-Sh for bliss@ietf.org; Sun, 04 Feb 2007 11:38:05 -0500 Received: from [127.0.0.1] (unknown [192.168.0.34]) by mvimap.mailvision.net (Postfix) with ESMTP id 77466284036 for ; Sun, 4 Feb 2007 15:10:02 +0200 (IST) Message-ID: <45C5DB33.50403@mailvision.com> Date: Sun, 04 Feb 2007 15:10:11 +0200 From: Diego B User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: bliss@ietf.org Subject: RE: [BLISS] Welcome! Main question - what services? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sun Feb 04 22:25:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDuTw-00062c-Oo; Sun, 04 Feb 2007 22:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDuTv-00061y-UJ for bliss@ietf.org; Sun, 04 Feb 2007 22:25:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDuTr-0002u0-KZ for bliss@ietf.org; Sun, 04 Feb 2007 22:25:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 04 Feb 2007 19:25:23 -0800 X-IronPort-AV: i="4.13,279,1167638400"; d="scan'208"; a="37151922:sNHT47581812" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l153PLp1023979; Sun, 4 Feb 2007 19:25:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l153PLUw029926; Sun, 4 Feb 2007 19:25:21 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Feb 2007 19:25:21 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Feb 2007 19:25:20 -0800 Message-ID: <45C6A39D.8020500@cisco.com> Date: Sun, 04 Feb 2007 22:25:17 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: <5AD2C83A-ABB6-44BC-B7E2-AF5D0AA8B168@cisco.com> In-Reply-To: <5AD2C83A-ABB6-44BC-B7E2-AF5D0AA8B168@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 03:25:21.0333 (UTC) FILETIME=[443B7650:01C748D5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=473; t=1170645921; x=1171509921; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Good=20news |Sender:=20 |To:=20Cullen=20Jennings=20 |Content-Type:=20text/plain=3B=20charset=3Dus-ascii=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=kDZBjxy+qVC4etbazilzoQdvh0vZ5isObgz6gTucRBs=; b=fOTSTZqHIKByrQSp2LSNMRD+1HXsihH5ImXIONywHvgS2yeJ9Wv9x1lj9uFS9o5e4Af2gUmI 92OnbhOregmz8o6Hw+x0QfIldfzwZqImEruaFTtaDjXpYSPVEvAONGWG2VWHIgkUHMsQXiYB+A 3YLTYAjwP2ArTgq85G7YkV14c=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: bliss@ietf.org Subject: [BLISS] Re: Good news X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Excellent! Thank you Cullen. -Jonathan R. Cullen Jennings wrote: > > This BOF is approved. > > Cullen > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 16 19:16:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFV-0000Aw-VJ; Fri, 16 Feb 2007 19:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFV-0000AX-69 for bliss@ietf.org; Fri, 16 Feb 2007 19:16:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDFP-0002W8-Hh for bliss@ietf.org; Fri, 16 Feb 2007 19:16:21 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2007 16:16:15 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208"; a="113742829:sNHT53223093" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1H0GFd7003542; Fri, 16 Feb 2007 16:16:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1H0FxnH017514; Fri, 16 Feb 2007 16:16:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:05 -0800 Received: from [192.168.248.89] ([10.21.89.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:05 -0800 Message-ID: <45D624A9.6030503@cisco.com> Date: Fri, 16 Feb 2007 16:39:53 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2007 00:16:05.0296 (UTC) FILETIME=[D076BB00:01C75228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5994; t=1171671375; x=1172535375; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=9KHPGXYXCmez4n4F/Kr/1OjHBqCoBLkc3hqEzpSnzvM=; b=GNqEI/OxSdrDmUQPEpGZko/cjwbQhUfoOutT7zTObuxFRppJ1f9wWzSRRbvnyUavOYhuwqJ1 BBL40bFyvmzXB5jAfKLs+wpBaz/ziWH/dsaxcVPSctS990ZuYrPVsG8k; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Miguel Garcia , bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org There is an issue here, and it has to do with 'invocation' - how does the user signal that they'd like this desired behavior? If DND is being done in the network, and we want a user on a phone to be able to hit the 'DND for Video' button, then we do need a standardized way of communicating from the phone to the network element providing the feature (say, its proxy or IP PBX or CSCF or whatever) that this is the desired intent. We have this kind of problem even if the phone implements the DND processing. In every real system I've seen, there are always multiple ways of setting this DND status - from a user profile web page, from phone keys, from an admin web page, and so on. So even if the processing is implemented in the phone, we'd need a way to communicate the desired criteria from the web server/provisioning system or whatever, to the phone. Indeed, its exactly the same information we'd need to communicate from the phone to the 'network' when the actual call processing is implemented in the network. This (fancy conditions for defining when to block a call) may be an area that we decide to leave alone; that is, BLISS is about *basic* interoperability. We need to define the basic framework needed for this to interoperate, and make sure we leave the hooks in place for vendors to do special stuff when its their phones ontop of their servers, such as a fancier DND service. In the particular case of DND for example, let us say we specify that DND call processing is done in the network, and that the service is invoked by including a body in a REGISTER message that indicates the criteria and desired action (just for arguments sake). We could define a basic format for this object which defines no conditions (i.e., DND is either on or off) and defines three actions (reject, send-to-voicemail, ring-indefinitely). We do a nice job in the XML and leave it extensible for other conditions and actions. We define XML namespace techniques for adding new conditions and actions. We support negotiation of supported namespaces during registration time, so the phone knows whether the server supports the extensions it knows about. Then, it can gray out those buttons on its UI, or not show the menu options for them, etc, when the phone finds its connected to a server that only supports the baseline format. -Jonathan R. Elwell, John wrote: > Miguel, > > An entity providing a DND service should be able filter based on any number > of criteria. One criterion might be the set of media requested (e.g., DND to > any offer involving audio). This filtering doesn't need to be standardised, > unless some sort of reason (e.g., can't accept audio) needs to be returned > to the caller. > > John > > >>-----Original Message----- >>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>Sent: 01 February 2007 15:13 >>To: Drage, Keith (Keith) >>Cc: bliss@ietf.org >>Subject: Re: [BLISS] Welcome! Main question - what services? >> >>Right... the capability of indicating a DND for SIP offers >>that contain >>certain media streams. Similarly with SIP methods. >> >>/Miguel >> >>Drage, Keith (Keith) wrote: >> >>>I assume that you mean you wish to be DND to a request with >> >>a SIP offer >> >>>of a particular media stream, rather than just DND to a >> >>particular media >> >>>stream. >>> >>>Regards >>> >>>Keith >>> >>> >>>>-----Original Message----- >>>>From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>>>Sent: 01 February 2007 15:02 >>>>To: Paul Kyzivat >>>>Cc: Drage, Keith (Keith); bliss@ietf.org >>>>Subject: Re: [BLISS] Welcome! Main question - what services? >>>> >>>>DND can also apply to a particular media stream. In >>>>particular, if I am in a meeting, I may want to activate the >>>>DND for audio and video, but not for messaging. >>>> >>>>I guess in general, you need to consider all the different >>>>media streams that can apply to service. It would be a big >>>>mistake just to restrict to audio or to "things that are >>>>initiated with an INVITE" because this is what the PSTN did. >>>> >>>>/Miguel >>>> >>>>Paul Kyzivat wrote: >>>> >>>>>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 >>>>> >>>> >>>>-- >>>>Miguel A. Garcia tel:+358-50-4804586 >>>>sip:miguel.garcia@neonsite.net >>>>Nokia Research Center Helsinki, Finland >>>> >> >>-- >>Miguel A. Garcia tel:+358-50-4804586 >>sip:miguel.garcia@neonsite.net >>Nokia Research Center Helsinki, Finland >> >>_______________________________________________ >>BLISS mailing list >>BLISS@ietf.org >>https://www1.ietf.org/mailman/listinfo/bliss >> > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 16 19:16:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFY-0000Gq-6k; Fri, 16 Feb 2007 19:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFW-0000FB-UK for bliss@ietf.org; Fri, 16 Feb 2007 19:16:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDFP-0002W9-MS for bliss@ietf.org; Fri, 16 Feb 2007 19:16:22 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 16:16:15 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208"; a="763249487:sNHT50756576" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1H0GF0q032752; Fri, 16 Feb 2007 16:16:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1H0G4Go008928; Fri, 16 Feb 2007 16:16:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:07 -0800 Received: from [192.168.248.89] ([10.21.89.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:06 -0800 Message-ID: <45D62964.8010006@cisco.com> Date: Fri, 16 Feb 2007 17:00:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <45B8BAB9.7020409@cisco.com> <45B95686.90208@cisco.com> <200701282336.l0SNaD49013775@dragon.ariadne.com> In-Reply-To: <200701282336.l0SNaD49013775@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2007 00:16:06.0859 (UTC) FILETIME=[D16539B0:01C75228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4990; t=1171671375; x=1172535375; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=PKKYbiIcML3/dY58OfX7vBAv/0NZkNSiGDNB14yxH4o=; b=VKjeA/taC7tCuLXM3LiWdwjPp3r96fVltM/DOQefwbIPKphXUMA2hAeRxUFEHJm1tl3Y8YuT TMXsNHW5TJ8n4A5LFdWATelH6kIJ0wGFxXsTvD1LG7iWqiZk68c3N5Is; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org inline. Dale.Worley@comcast.net wrote: > From: Jonathan Rosenberg > > 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 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 16 19:16:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFZ-0000I8-Cr; Fri, 16 Feb 2007 19:16:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFY-0000HN-BK for bliss@ietf.org; Fri, 16 Feb 2007 19:16:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDFV-0002W8-TA for bliss@ietf.org; Fri, 16 Feb 2007 19:16:24 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2007 16:16:15 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208"; a="113742830:sNHT47187963" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1H0GFhP015173; Fri, 16 Feb 2007 16:16:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1H0G4Gk008928; Fri, 16 Feb 2007 16:16:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:04 -0800 Received: from [192.168.248.89] ([10.21.89.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:03 -0800 Message-ID: <45D6226B.80509@cisco.com> Date: Fri, 16 Feb 2007 16:30:19 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: Fw: [BLISS] Welcome! Main question - what services? References: <015901c74576$75c85830$6501a8c0@china.huawei.com> <45C10B3F.4070507@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3C@DEEXC1U01.de.lucent.com> <45C1C16B.2060208@ntt-at.com> In-Reply-To: <45C1C16B.2060208@ntt-at.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2007 00:16:03.0752 (UTC) FILETIME=[CF8B2280:01C75228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3530; t=1171671375; x=1172535375; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Fw=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20wh at=20services? |Sender:=20; bh=dSTw2IAqwNpF+Yy497fFaKyo7viNJNkccC61PJPQZYo=; b=FW2YgJMkCd2xM72tZ1dzr7BStsKK4JSbM80bcXb+PK8MushM0a9fB8SAZ+LBCC9gTwSsRxfC THL9hPrPVikWS6vj9Uyh3P13IjWcpg+b+3W2KmPvLm2Rv+052xwJfM89; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes, lets add SIMPLE to the list. Does that address your concern Keith? -Jonathan R. Shida Schubert wrote: > Hi Keith; > > That is the intention. > > I think the following text in the charter under > "guiding principles for this working group will include" covers your > comments. > > " Where extensions to standards are required, bring the analysis and need > for new extensions to the appropriate working group (SIP or SIPPING). " > > I guess SIMPLE is missing from the list. > > > Drage, Keith (Keith) wrote: > >>I don't think this statement helps. >> >>What should happen is that if BLISS identifies the need for any of your >>list, it develops the requirements and passes the requirements to each >>of those groups you have mentioned. >> >>Keith >> >> >> >>>-----Original Message----- >>>From: Shida Schubert [mailto:shida@ntt-at.com] >>>Sent: 31 January 2007 21:34 >>>To: Spencer Dawkins >>>Cc: bliss@ietf.org >>>Subject: Re: Fw: [BLISS] Welcome! Main question - what services? >>> >>> >>>Hi Spencer; >>> >>>Yes you are right. I will change the text to say.. >>> >>>"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 and SIMPLE." >>> >>>Thanks >>>Shida >>> >>> >>>Spencer Dawkins wrote: >>> >>> >>>>Hi, Jonathan and Shida, >>>> >>>>And now that Peili jogged me to read the actual words in >>>> >>> >>>the charter, >>> >>> >>>>isn't presence the sole province of SIMPLE? >>>> >>>>Thanks, >>>> >>>>Spencer >>>> >>>> >>>> >>>> >>>>>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 >>>>> >>>> >>>>_______________________________________________ >>>>BLISS mailing list >>>>BLISS@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/bliss >>>> >>>> >>>> >>> >>>_______________________________________________ >>>BLISS mailing list >>>BLISS@ietf.org >>>https://www1.ietf.org/mailman/listinfo/bliss >>> >>> >> >> >> > > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Feb 16 19:16:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFZ-0000Ij-HE; Fri, 16 Feb 2007 19:16:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDFY-0000HS-Gk for bliss@ietf.org; Fri, 16 Feb 2007 19:16:24 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDFX-0002W9-4Y for bliss@ietf.org; Fri, 16 Feb 2007 19:16:24 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 16:16:16 -0800 X-IronPort-AV: i="4.14,182,1170662400"; d="scan'208"; a="763249488:sNHT44922024" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1H0GFZA023593; Fri, 16 Feb 2007 16:16:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1H0FxnN017514; Fri, 16 Feb 2007 16:16:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:06 -0800 Received: from [192.168.248.89] ([10.21.89.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:16:06 -0800 Message-ID: <45D625C2.5080507@cisco.com> Date: Fri, 16 Feb 2007 16:44:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1C8F9.5090705@ntt-at.com> <200702011458.l11EwOB3027408@dragon.ariadne.com> In-Reply-To: <200702011458.l11EwOB3027408@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2007 00:16:06.0140 (UTC) FILETIME=[D0F783C0:01C75228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1581; t=1171671375; x=1172535375; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=2wdDZ3RDtTznPeYGU7m0dUhA3z2n1IAG4Xkoca0gmeo=; b=dv/g+TUzVk+Ax9aY61uUjZZ/X+g2xCbckQtdeYzhc4vxSJY3VQGLVDeDWd494OyG9YX1cuMZ FeeS/6q4087br6fG4ES5xGP6B2a9/w8ZpmM69+xWZH198SoKtkQ1IuH6; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org To summarize this discussion, I think its fair to say that *anything* that BLISS does will consider multimedia (audio, video, messaging, and of course - text). I also think we should add that explicitly to the charter to be clear. As Paul and others have said, in some cases the flows may really not care at all what the media types are; for others it may matter, or we at least need to think about whether they matter. -Jonathan R. Dale.Worley@comcast.net wrote: > From: Shida Schubert > > But defining services solely used by session based messaging and > presence has a home called SIMPLE at this present moment, and I see > no reasons why BLISS should take on them as long as SIMPLE exists. > > I don't know about presence. But within the SIP philosophy, > session-based messaging is "just another media type" when compared to > audio calling. So it seems to me that if we discern an apparent > difference in "calling features" between session-based messaging and > audio calling, we are probably misunderstanding the situation. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sat Feb 17 15:18:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIW0c-0006Lo-PC; Sat, 17 Feb 2007 15:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIW0b-0006Le-KZ for bliss@ietf.org; Sat, 17 Feb 2007 15:18:13 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIW0a-0005va-3s for bliss@ietf.org; Sat, 17 Feb 2007 15:18:13 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1HKI1Hv013282; Sat, 17 Feb 2007 14:18:02 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 14:18:01 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 21:18:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fw: [BLISS] Welcome! Main question - what services? Date: Sat, 17 Feb 2007 21:17:59 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180CEE8A2@DEEXC1U01.de.lucent.com> In-Reply-To: <45D6226B.80509@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fw: [BLISS] Welcome! Main question - what services? Thread-Index: AcdSKN3CSsuyCgC+RUG2bOdIMXazGQAp78YQ References: <015901c74576$75c85830$6501a8c0@china.huawei.com> <45C10B3F.4070507@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3C@DEEXC1U01.de.lucent.com> <45C1C16B.2060208@ntt-at.com> <45D6226B.80509@cisco.com> From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 17 Feb 2007 20:18:00.0184 (UTC) FILETIME=[B8495F80:01C752D0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.9 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes that would solve it.=20 It may also be appropriate to mention RFC 3427 somewhere around here in regard to the SIP extension. Keith=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 16 February 2007 21:30 > To: shida@ntt-at.com > Cc: Drage, Keith (Keith); bliss@ietf.org > Subject: Re: Fw: [BLISS] Welcome! Main question - what services? >=20 > Yes, lets add SIMPLE to the list. >=20 > Does that address your concern Keith? >=20 > -Jonathan R. >=20 > Shida Schubert wrote: > > Hi Keith; > >=20 > > That is the intention. > >=20 > > I think the following text in the charter under "guiding principles=20 > > for this working group will include" covers your comments. > >=20 > > " Where extensions to standards are required, bring the=20 > analysis and=20 > > need for new extensions to the appropriate working group=20 > (SIP or SIPPING). " > >=20 > > I guess SIMPLE is missing from the list. > >=20 > >=20 > > Drage, Keith (Keith) wrote: > >=20 > >>I don't think this statement helps. > >> > >>What should happen is that if BLISS identifies the need for any of=20 > >>your list, it develops the requirements and passes the=20 > requirements to=20 > >>each of those groups you have mentioned. > >> > >>Keith > >> > >> =20 > >> > >>>-----Original Message----- > >>>From: Shida Schubert [mailto:shida@ntt-at.com] > >>>Sent: 31 January 2007 21:34 > >>>To: Spencer Dawkins > >>>Cc: bliss@ietf.org > >>>Subject: Re: Fw: [BLISS] Welcome! Main question - what services? > >>> > >>> > >>>Hi Spencer; > >>> > >>>Yes you are right. I will change the text to say.. > >>> > >>>"SIP applications such as configuration, presence and IM,=20 > and session=20 > >>>policy are clearly out of scope for BLISS and remain the sole=20 > >>>province of SIPPING and SIMPLE." > >>> > >>>Thanks > >>>Shida > >>> > >>> > >>>Spencer Dawkins wrote: > >>> =20 > >>> > >>>>Hi, Jonathan and Shida, > >>>> > >>>>And now that Peili jogged me to read the actual words in > >>>> =20 > >>> > >>>the charter, > >>> =20 > >>> > >>>>isn't presence the sole province of SIMPLE? > >>>> > >>>>Thanks, > >>>> > >>>>Spencer > >>>> > >>>> > >>>> =20 > >>>> > >>>>>After looking at the following sentences in the draft=20 > charger "The=20 > >>>>>difference between SIPPING and BLISS, is that BLISS is > >>>>> =20 > >>> > >>>focused on a > >>> =20 > >>> > >>>>>particular type of SIP application - call features, and in=20 > >>>>>particular, advanced call features requiring non-trivial call=20 > >>>>>control. SIP applications such as configuration, presence > >>>>> =20 > >>> > >>>and IM, and > >>> =20 > >>> > >>>>>session policy are clearly out of scope for BLISS and > >>>>> =20 > >>> > >>>remain the sole > >>> =20 > >>> > >>>>>province of SIPPING. " > >>>>> > >>>>>It seems the WG will actually focus on features initiated > >>>>> =20 > >>> > >>>by INVITE > >>> =20 > >>> > >>>>>and these features are more or less related to traditional > >>>>> =20 > >>> > >>>PSTN/ISDN > >>> =20 > >>> > >>>>>supplementary services. > >>>>>If I am correct, what about session mode messaging service > >>>>> =20 > >>> > >>>which is > >>> =20 > >>> > >>>>>also a call initiated by INVITE? > >>>>> > >>>>>thanks > >>>>>Peili > >>>>> =20 > >>>> > >>>>_______________________________________________ > >>>>BLISS mailing list > >>>>BLISS@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/bliss > >>>> > >>>> > >>>> =20 > >>> > >>>_______________________________________________ > >>>BLISS mailing list > >>>BLISS@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/bliss > >>> > >>> =20 > >> > >> > >> =20 > >=20 > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 19 02:22:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ2qu-0001jt-8C; Mon, 19 Feb 2007 02:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ2qr-0001jQ-W3 for bliss@ietf.org; Mon, 19 Feb 2007 02:22:22 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ2qo-00006S-L1 for bliss@ietf.org; Mon, 19 Feb 2007 02:22:21 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JDP00N6C8GY4S@siemenscomms.co.uk> for bliss@ietf.org; Mon, 19 Feb 2007 07:22:11 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Feb 2007 07:22:11 +0000 Content-return: allowed Date: Mon, 19 Feb 2007 07:22:10 +0000 From: "Elwell, John" Subject: RE: [BLISS] Welcome! Main question - what services? To: Jonathan Rosenberg Message-id: <50B1CBA96870A34799A506B2313F26670B0F89C4@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.9 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Miguel Garcia , bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Jonathan, I agree with your point about defining a basic but extensible mechanism. What is not clear is whether mechanisms for "invocation" of features like DND should be within scope or not. On the one hand, these can be generally done by web pages and other non-SIP means. The question is whether we need to define a SIP means too or simply leave it out of scope. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 16 February 2007 21:40 > To: Elwell, John > Cc: Miguel Garcia; Drage, Keith (Keith); bliss@ietf.org > Subject: Re: [BLISS] Welcome! Main question - what services? > > There is an issue here, and it has to do with 'invocation' - how does > the user signal that they'd like this desired behavior? > > If DND is being done in the network, and we want a user on a > phone to be > able to hit the 'DND for Video' button, then we do need a > standardized > way of communicating from the phone to the network element > providing the > feature (say, its proxy or IP PBX or CSCF or whatever) that > this is the > desired intent. > > We have this kind of problem even if the phone implements the DND > processing. In every real system I've seen, there are always multiple > ways of setting this DND status - from a user profile web page, from > phone keys, from an admin web page, and so on. So even if the > processing > is implemented in the phone, we'd need a way to communicate > the desired > criteria from the web server/provisioning system or whatever, to the > phone. Indeed, its exactly the same information we'd need to > communicate > from the phone to the 'network' when the actual call processing is > implemented in the network. > > This (fancy conditions for defining when to block a call) may > be an area > that we decide to leave alone; that is, BLISS is about *basic* > interoperability. We need to define the basic framework > needed for this > to interoperate, and make sure we leave the hooks in place > for vendors > to do special stuff when its their phones ontop of their > servers, such > as a fancier DND service. > > In the particular case of DND for example, let us say we specify that > DND call processing is done in the network, and that the service is > invoked by including a body in a REGISTER message that indicates the > criteria and desired action (just for arguments sake). We > could define a > basic format for this object which defines no conditions > (i.e., DND is > either on or off) and defines three actions (reject, > send-to-voicemail, > ring-indefinitely). We do a nice job in the XML and leave it > extensible > for other conditions and actions. We define XML namespace > techniques for > adding new conditions and actions. We support negotiation of > supported > namespaces during registration time, so the phone knows whether the > server supports the extensions it knows about. Then, it can gray out > those buttons on its UI, or not show the menu options for them, etc, > when the phone finds its connected to a server that only supports the > baseline format. > > -Jonathan R. > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 19 12:01:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBsx-00028E-B4; Mon, 19 Feb 2007 12:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBsw-000288-T2 for bliss@ietf.org; Mon, 19 Feb 2007 12:01:06 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBsv-0006aN-Km for bliss@ietf.org; Mon, 19 Feb 2007 12:01:06 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070219170104m11008h1ume>; Mon, 19 Feb 2007 17:01:04 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1JH0x6g005102 for ; Mon, 19 Feb 2007 12:00:59 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1JH0xli005098; Mon, 19 Feb 2007 12:00:59 -0500 Date: Mon, 19 Feb 2007 12:00:59 -0500 Message-Id: <200702191700.l1JH0xli005098@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45D624A9.6030503@cisco.com> (jdrosen@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> <45D624A9.6030503@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org In the particular case of DND for example, let us say we specify that DND call processing is done in the network, and that the service is invoked by including a body in a REGISTER message that indicates the criteria and desired action (just for arguments sake). Um, if I might be so bold to ask, *why* would be want to have DND call processing done in the network? It's true that if we want to have DND done in the network, we need to define some moderately complex mechanism for having the UA report to the network its DND status. But that's really an argument that DND should be done in the phone, and activated by a button (like it is on every SIP phone). If we're really going to try to define such a mechanism, we first need to review that there really is such a requirement, that such an architecture is really the best solution to the DND "problem" in a reasonable fraction of real-world cases. That this is a significant deviation from the end-to-end principle is a warning sign... Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 19 12:04:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBw2-00035h-Pw; Mon, 19 Feb 2007 12:04:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBw1-00035X-QG for bliss@ietf.org; Mon, 19 Feb 2007 12:04:17 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBw0-0007ZA-JK for bliss@ietf.org; Mon, 19 Feb 2007 12:04:17 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007021917041601400s79fhe>; Mon, 19 Feb 2007 17:04:16 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1JH4F6g005350 for ; Mon, 19 Feb 2007 12:04:15 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1JH4FTW005346; Mon, 19 Feb 2007 12:04:15 -0500 Date: Mon, 19 Feb 2007 12:04:15 -0500 Message-Id: <200702191704.l1JH4FTW005346@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45D625C2.5080507@cisco.com> (jdrosen@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <024701c74520$eb25edf0$9acc550a@china.huawei.com> <45C10E86.3010006@ntt-at.com> <5D1A7985295922448D5550C94DE29180C14A3A@DEEXC1U01.de.lucent.com> <45C1C8F9.5090705@ntt-at.com> <200702011458.l11EwOB3027408@dragon.ariadne.com> <45D625C2.5080507@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Jonathan Rosenberg As Paul and others have said, in some cases the flows may really not care at all what the media types are; for others it may matter, or we at least need to think about whether they matter. If the media matters, it's likely we've made a mistake. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 19 18:17:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHlV-0001H1-B4; Mon, 19 Feb 2007 18:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHlU-0001Gw-Qg for bliss@ietf.org; Mon, 19 Feb 2007 18:17:48 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJHlT-0006hI-EE for bliss@ietf.org; Mon, 19 Feb 2007 18:17:48 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l1JNHfHZ029647; Mon, 19 Feb 2007 16:17:41 -0700 Message-ID: <45DA3015.5020206@ntt-at.com> Date: Mon, 19 Feb 2007 15:17:41 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670B0F89C4@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B0F89C4@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Miguel Garcia , bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org John; I personally think it would depend on the feature/service we look into. After exploring the current deployments/implementations, we may realize that certain features are best served with defining a SIP means for "invocation". If that's the case defining a mechanism for "invocation" is likely to be in scope for that specific feature we explore. In contrary, if it is realized that defining SIP means to invocate the feature/service is not appropriate/unnecessary/overkill then text mentioning this approach may be noted that it does exist, but it would not be the recommended approach. Regards Shida Elwell, John wrote: > Jonathan, > > I agree with your point about defining a basic but extensible mechanism. > What is not clear is whether mechanisms for "invocation" of features like > DND should be within scope or not. On the one hand, these can be generally > done by web pages and other non-SIP means. The question is whether we need > to define a SIP means too or simply leave it out of scope. > > John > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 16 February 2007 21:40 >> To: Elwell, John >> Cc: Miguel Garcia; Drage, Keith (Keith); bliss@ietf.org >> Subject: Re: [BLISS] Welcome! Main question - what services? >> >> There is an issue here, and it has to do with 'invocation' - how does >> the user signal that they'd like this desired behavior? >> >> If DND is being done in the network, and we want a user on a >> phone to be >> able to hit the 'DND for Video' button, then we do need a >> standardized >> way of communicating from the phone to the network element >> providing the >> feature (say, its proxy or IP PBX or CSCF or whatever) that >> this is the >> desired intent. >> >> We have this kind of problem even if the phone implements the DND >> processing. In every real system I've seen, there are always multiple >> ways of setting this DND status - from a user profile web page, from >> phone keys, from an admin web page, and so on. So even if the >> processing >> is implemented in the phone, we'd need a way to communicate >> the desired >> criteria from the web server/provisioning system or whatever, to the >> phone. Indeed, its exactly the same information we'd need to >> communicate >> from the phone to the 'network' when the actual call processing is >> implemented in the network. >> >> This (fancy conditions for defining when to block a call) may >> be an area >> that we decide to leave alone; that is, BLISS is about *basic* >> interoperability. We need to define the basic framework >> needed for this >> to interoperate, and make sure we leave the hooks in place >> for vendors >> to do special stuff when its their phones ontop of their >> servers, such >> as a fancier DND service. >> >> In the particular case of DND for example, let us say we specify that >> DND call processing is done in the network, and that the service is >> invoked by including a body in a REGISTER message that indicates the >> criteria and desired action (just for arguments sake). We >> could define a >> basic format for this object which defines no conditions >> (i.e., DND is >> either on or off) and defines three actions (reject, >> send-to-voicemail, >> ring-indefinitely). We do a nice job in the XML and leave it >> extensible >> for other conditions and actions. We define XML namespace >> techniques for >> adding new conditions and actions. We support negotiation of >> supported >> namespaces during registration time, so the phone knows whether the >> server supports the extensions it knows about. Then, it can gray out >> those buttons on its UI, or not show the menu options for them, etc, >> when the phone finds its connected to a server that only supports the >> baseline format. >> >> -Jonathan R. >> >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 19 22:43:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLuV-0005ov-QA; Mon, 19 Feb 2007 22:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJLuT-0005oj-E2 for bliss@ietf.org; Mon, 19 Feb 2007 22:43:21 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJLuR-0005gv-U9 for bliss@ietf.org; Mon, 19 Feb 2007 22:43:21 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDQ0032USZ8MK@szxga01-in.huawei.com> for bliss@ietf.org; Tue, 20 Feb 2007 11:42:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDQ00JMDSZ7DW@szxga01-in.huawei.com> for bliss@ietf.org; Tue, 20 Feb 2007 11:42:44 +0800 (CST) Received: from JAIMINCL5132 ([10.18.8.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDQ00KH2SZ18R@szxml03-in.huawei.com> for bliss@ietf.org; Tue, 20 Feb 2007 11:42:43 +0800 (CST) Date: Tue, 20 Feb 2007 09:12:36 +0530 From: Jaimin Pancholi Subject: RE: [BLISS] Welcome! Main question - what services? In-reply-to: <200702191700.l1JH0xli005098@dragon.ariadne.com> To: bliss@ietf.org Message-id: <003e01c754a1$29e43d00$6908120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdUR6H1sg8nPWluTQydT8Iqw6CowAAWOGiw X-Spam-Score: 0.9 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaiminp@huawei.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi , I may be a junior in this area but as per my understanding the problem that the circuit switched network has is the centralized logic for almost everything. The end terminal does not have any intelligence at all, making deployment of the service / application a big issue ! In general, SIP network (VoIP) network provides a advantage i.e. it has decentralized the logic and had proposed some intelligence in the end terminal. I think, I would agree with Dale that intelligence in end terminal is good for basic services like DND, Call forward Cheers Jaimin 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! >-----Original Message----- >From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >Sent: Monday, February 19, 2007 10:31 PM >To: bliss@ietf.org >Subject: Re: [BLISS] Welcome! Main question - what services? > > In the particular case of DND for example, let us say we >specify that > DND call processing is done in the network, and that the service is > invoked by including a body in a REGISTER message that >indicates the > criteria and desired action (just for arguments sake). > >Um, if I might be so bold to ask, *why* would be want to have >DND call processing done in the network? It's true that if we >want to have DND done in the network, we need to define some >moderately complex mechanism for having the UA report to the >network its DND status. But that's really an argument that >DND should be done in the phone, and activated by a button >(like it is on every SIP phone). > >If we're really going to try to define such a mechanism, we >first need to review that there really is such a requirement, >that such an architecture is really the best solution to the >DND "problem" in a reasonable fraction of real-world cases. >That this is a significant deviation from the end-to-end >principle is a warning sign... > >Dale > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 20 13:49:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa37-0001WH-1L; Tue, 20 Feb 2007 13:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa36-0001W9-0x for bliss@ietf.org; Tue, 20 Feb 2007 13:49:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJa33-0001fE-LU for bliss@ietf.org; Tue, 20 Feb 2007 13:49:12 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 10:49:09 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="391280162:sNHT46598740" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1KIn9ZR000591; Tue, 20 Feb 2007 10:49:09 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1KImlnf001118; Tue, 20 Feb 2007 10:49:08 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 13:48:54 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 13:48:54 -0500 Message-ID: <45DB4296.5090707@cisco.com> Date: Tue, 20 Feb 2007 13:48:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> <45D624A9.6030503@cisco.com> <200702191700.l1JH0xli005098@dragon.ariadne.com> In-Reply-To: <200702191700.l1JH0xli005098@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 18:48:54.0311 (UTC) FILETIME=[C5232370:01C7551F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2410; t=1171997349; x=1172861349; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Welcome!=20Main=20question=20-=20what=20ser vices? |Sender:=20; bh=5adyaDjomKuMsyqhbr1qU5Lk/f4X7gGDktqj3B4I2FU=; b=Xa9sI07wOoip/fWME3A96oPoqNCfTrAE7tW8h6VFeFRCn3hbvvYKDRtP/PGRedqhCYlrUyH7 SfNfof3aLlL7YSANy8QsQLalwVA95dWikk0wC95EjUHqV7qxBJblrtuu; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale.Worley@comcast.net wrote: > In the particular case of DND for example, let us say we specify that > DND call processing is done in the network, and that the service is > invoked by including a body in a REGISTER message that indicates the > criteria and desired action (just for arguments sake). > > Um, if I might be so bold to ask, *why* would be want to have DND call > processing done in the network? It's true that if we want to have DND > done in the network, we need to define some moderately complex > mechanism for having the UA report to the network its DND status. But > that's really an argument that DND should be done in the phone, and > activated by a button (like it is on every SIP phone). > > If we're really going to try to define such a mechanism, we first need > to review that there really is such a requirement, that such an > architecture is really the best solution to the DND "problem" in a > reasonable fraction of real-world cases. That this is a significant > deviation from the end-to-end principle is a warning sign... If I have multiple phones all registered to the same AOR, then I may want the DND to prevent them all from ringing. A DND implemented in the phone on my desk won't prevent the phones in the living room and bedroom and kitchen from ringing. A network based DND will. Of course there are other ways to skin this cat. For instance, I could send a DND feature activation notice to all the other phones. That would only work for phones that were on at the time, so I would have to monitor for other phones registering, and send notifications to them when they do. And if a phone reboots I might have to send it again. (Not sure how I would detect that.) When there are common policies that should be applied to any and all registered devices then there is some potential value in implementing that policy at the common point. Of course it may be that I don't want my DND applied to the other registered phones. Specifically, if I am in my hotel room in Prague and have registered a phone to my home phone number, then I probably don't want DND selected by someone at home to affect me. IMO this says that DND isn't just one feature. Instead, there is DND-device, and DND-AOR. They both have value in different cases. And both can be implemented in different ways. Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 20 15:06:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbG4-0000Aw-Ln; Tue, 20 Feb 2007 15:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbG2-0000Al-VI for bliss@ietf.org; Tue, 20 Feb 2007 15:06:38 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbG1-00015m-PU for bliss@ietf.org; Tue, 20 Feb 2007 15:06:38 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <20070220200636013007tivle>; Tue, 20 Feb 2007 20:06:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1KK6a6g027216 for ; Tue, 20 Feb 2007 15:06:36 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1KK6YAt027207; Tue, 20 Feb 2007 15:06:34 -0500 Date: Tue, 20 Feb 2007 15:06:34 -0500 Message-Id: <200702202006.l1KK6YAt027207@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45DB4296.5090707@cisco.com> (pkyzivat@cisco.com) Subject: Re: [BLISS] Welcome! Main question - what services? References: <50B1CBA96870A34799A506B2313F26670AEDF1A1@ntht201e.siemenscomms.co.uk> <45D624A9.6030503@cisco.com> <200702191700.l1JH0xli005098@dragon.ariadne.com> <45DB4296.5090707@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Paul Kyzivat Of course it may be that I don't want my DND applied to the other registered phones. Specifically, if I am in my hotel room in Prague and have registered a phone to my home phone number, then I probably don't want DND selected by someone at home to affect me. IMO this says that DND isn't just one feature. Instead, there is DND-device, and DND-AOR. They both have value in different cases. And both can be implemented in different ways. So there are various "scopes" to which the DND might apply, which superficially seem to be the same AOR. I've seen this phenomenon in other places, particularly SUBSCRIBEs to obtain status information. Often, the scope of forking that I want is not quite the same as all the contacts for an AOR. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 20 21:22:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJh7p-0005mF-1b; Tue, 20 Feb 2007 21:22:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJh7o-0005m8-1X for bliss@ietf.org; Tue, 20 Feb 2007 21:22:32 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJh7k-0000F5-N4 for bliss@ietf.org; Tue, 20 Feb 2007 21:22:29 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070221022207b14008ju0te>; Wed, 21 Feb 2007 02:22:17 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1L2Lk6g022129 for ; Tue, 20 Feb 2007 21:21:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1L2LkJR022125; Tue, 20 Feb 2007 21:21:46 -0500 Date: Tue, 20 Feb 2007 21:21:46 -0500 Message-Id: <200702210221.l1L2LkJR022125@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [BLISS] I-D on implementing GRUU X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I've updated an Internet-Draft giving condensed instructions for UA implementors on how to implement GRUU support. (This is updated for version -11 of the GRUU I-D, but it only discusses "public GRUUs", which is what we need for our environment.) In our product's environment (a "true SIP", proxy-based PBX), we've found that to do call control well, the UAs need to implement (public) GRUU. This I-D summarizes what UAs need to do Guidelines for Implementing the GRUU Support in User Agents draft-worley-sip-gruu-implement-02 http://www.ietf.org/internet-drafts/draft-worley-sip-gruu-implement-02.txt Abstract Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a request to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). An Internet-Draft is progressing toward standardization that specifies procedures for proxies and UAs by which proxies can construct and delver GRUUs to UAs that request them. This document summarizes for UA implementors how to obtain "public" GRUUs and gives guidance on effectively using public GRUUs. Feel free to contact me with any comments. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 20 22:52:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiWG-0007FT-4J; Tue, 20 Feb 2007 22:51:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiWE-0007FO-VG for bliss@ietf.org; Tue, 20 Feb 2007 22:51:50 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJiWD-0001ZW-Mf for bliss@ietf.org; Tue, 20 Feb 2007 22:51:50 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070221035109b110030tlde>; Wed, 21 Feb 2007 03:51:49 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1L2Hg6g021837 for ; Tue, 20 Feb 2007 21:17:42 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1L2Hguw021833; Tue, 20 Feb 2007 21:17:42 -0500 Date: Tue, 20 Feb 2007 21:17:42 -0500 Message-Id: <200702210217.l1L2Hguw021833@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [BLISS] I-D on practical requirements for the dialog event package X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I've submitted an Internet-Draft giving guidelines for UAs that want to implement the dialog event package. In our product's environment (a "true SIP", proxy-based PBX), we've found that to do call control well, the UAs need to implement the dialog event package well. This I-D describes the needed requirements. (If you want to test your UA against the guidelines, you can use our interoperability server at http://interop.pingtel.com.) Guidelines for Implementing the Dialog Event Package in User Agents draft-worley-sip-dialog-03 http://www.ietf.org/internet-drafts/draft-worley-sip-dialog-03.txt Abstract This document sets out guidelines for how Session Initiation Protocol (SIP) user agents (UAs) should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. The guidelines are in addition to the basic requirements for dialog event package implementation in RFC 3265 and RFC 4235. Feel free to contact me with any comments. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 26 06:03:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLddK-0001qc-CP; Mon, 26 Feb 2007 06:03:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLddI-0001op-Hi for bliss@ietf.org; Mon, 26 Feb 2007 06:03:04 -0500 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLddH-0007xR-8U for bliss@ietf.org; Mon, 26 Feb 2007 06:03:04 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HLddP-0006Nq-IB for bliss@ietf.org; Mon, 26 Feb 2007 03:03:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Feb 2007 03:03:02 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCBA17AD@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call Park/Retrieve thread-index: AcdZla7dQunyjiHgQW+fkxiOLMdB1w== From: "Michael Procter" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [BLISS] Call Park/Retrieve X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I have just submitted an Internet-Draft concerning call park/retrieve. It is actually a draft I wrote almost 3 years ago, but which sank without trace. Given the BLISS charter, I think that it may be time to revisit it. Until it appears, you can see the original one at: http://tools.ietf.org/html/draft-procter-sipping-call-park-extension-00 (The new version only updates the dates and references and the like). The draft documents a real problem associated with parking calls in a multi-vendor environment. The solution is based upon the service-examples document and is workable, although refinements are clearly possible. I'd be interested to hear comments on the draft, both the scope of the problem and the approach taken. I'd also be interested in how other people have solved this problem, or even if they have avoided it entirely. Regards, Michael Procter _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Feb 26 17:18:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoAS-00047V-8Q; Mon, 26 Feb 2007 17:18:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoAC-0003vr-Ee for bliss@ietf.org; Mon, 26 Feb 2007 17:17:44 -0500 Received: from usnwksmtp02e.usa.siemens.com ([12.46.135.31] helo=usnwk220srv.usa.siemens.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLoA5-0006K2-RI for bliss@ietf.org; Mon, 26 Feb 2007 17:17:44 -0500 Received: from usnwk206a.ww017.siemens.net ([155.45.111.74]) by usnwk220srv.usa.siemens.com with InterScan Messaging Security Suite; Mon, 26 Feb 2007 14:17:09 -0800 Received: from USNWK101MSX.ww017.siemens.net ([155.45.111.55]) by usnwk206a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:17:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Call Park/Retrieve Date: Mon, 26 Feb 2007 14:17:04 -0800 Message-ID: <55AF62549C5C4049B13A2A273445C486274C12B0@USNWK101MSX.ww017.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call Park/Retrieve thread-index: AcdZla7dQunyjiHgQW+fkxiOLMdB1wAWgtTA From: "Kucmerowski, Dennis \(Com US\)" To: "Michael Procter" , X-OriginalArrivalTime: 26 Feb 2007 22:17:05.0394 (UTC) FILETIME=[D8E1A520:01C759F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Michael, The Park to orbit (aka. park to server or park to system) whereby the User must input a orbit number is old feature operation which may result in the user entering an already used orbit. This form of Park to server is somewhat limited. Enhanced feature Park to Server operation should allow the user to request the server to park a call and the server should allocate the first available park orbit. The response could be given to the user in two forms: announcement and additional information i.e.., park orbit number given back to the end user.=20 Both Old and Enhanced may require a bit different implementation e.g., if park orbit not given then selects the first orbit or if park orbit given, attempt to park in the requested orbit.=20 For Call Retrieve the orbit must be specified. I did not see a Recall from park, whereby the Park exceeds a given time and will attempt to notify or redistribute the parked party back to the UA that parked the call to the server. In the case of redistributing the parked party back to the UA, it would be nice for the UA to know the call coming back was a parked call and not a new incoming call. Is recall from park in the plans? The old park to server feature whereby the user enters a park destination is more in tune with the Park to Subscriber feature. In this case one UA parks the call to another UI by indicating park to subscriber and the destination to be parked-to (not orbit). Best Regards, =20 Dennis L. Kucmerowski=20 561-923-1703 Systems Engineering =20 -----Original Message----- From: Michael Procter [mailto:michael.procter@citel.com]=20 Sent: Monday, February 26, 2007 6:03 AM To: bliss@ietf.org Subject: [BLISS] Call Park/Retrieve I have just submitted an Internet-Draft concerning call park/retrieve. It is actually a draft I wrote almost 3 years ago, but which sank without trace. Given the BLISS charter, I think that it may be time to revisit it. Until it appears, you can see the original one at: http://tools.ietf.org/html/draft-procter-sipping-call-park-extension-00 (The new version only updates the dates and references and the like). The draft documents a real problem associated with parking calls in a multi-vendor environment. The solution is based upon the service-examples document and is workable, although refinements are clearly possible. I'd be interested to hear comments on the draft, both the scope of the problem and the approach taken. I'd also be interested in how other people have solved this problem, or even if they have avoided it entirely. Regards, Michael Procter _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 27 10:56:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4hA-0007rO-MR; Tue, 27 Feb 2007 10:56:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4h9-0007rJ-Dj for bliss@ietf.org; Tue, 27 Feb 2007 10:56:51 -0500 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4h7-0006Ry-PE for bliss@ietf.org; Tue, 27 Feb 2007 10:56:51 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070227155648m1500avj7ce>; Tue, 27 Feb 2007 15:56:48 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l1RFulbV024338 for ; Tue, 27 Feb 2007 10:56:47 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l1RFuloF024334; Tue, 27 Feb 2007 10:56:47 -0500 Date: Tue, 27 Feb 2007 10:56:47 -0500 Message-Id: <200702271556.l1RFuloF024334@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <55AF62549C5C4049B13A2A273445C486274C12B0@USNWK101MSX.ww017.siemens.net> (dennis.kucmerowski@siemens.com) Subject: Re: [BLISS] Call Park/Retrieve References: <55AF62549C5C4049B13A2A273445C486274C12B0@USNWK101MSX.ww017.siemens.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Kucmerowski, Dennis \(Com US\)" Enhanced feature Park to Server operation should allow the user to request the server to park a call and the server should allocate the first available park orbit. The response could be given to the user in two forms: announcement and additional information i.e.., park orbit number given back to the end user. Do you know of any implementations of this scheme? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 27 11:28:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5BT-0001Jm-Ge; Tue, 27 Feb 2007 11:28:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5BR-0001El-U2 for bliss@ietf.org; Tue, 27 Feb 2007 11:28:09 -0500 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM5BQ-0002YU-IS for bliss@ietf.org; Tue, 27 Feb 2007 11:28:09 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HM5Bi-0004Mh-2c; Tue, 27 Feb 2007 08:28:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Call Park/Retrieve Date: Tue, 27 Feb 2007 08:28:04 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BCBA1AE2@sea02-mxc01.citel.com> In-Reply-To: <55AF62549C5C4049B13A2A273445C486274C12B0@USNWK101MSX.ww017.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call Park/Retrieve thread-index: AcdZla7dQunyjiHgQW+fkxiOLMdB1wAWgtTAACZVrSA= References: <55AF62549C5C4049B13A2A273445C486274C12B0@USNWK101MSX.ww017.siemens.net> From: "Michael Procter" To: "Kucmerowski, Dennis \(Com US\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dennis, Thanks for your comments. My responses are inline. Kucmerowski, Dennis (Com US) wrote:=20 > Michael, >=20 > The Park to orbit (aka. park to server or park to system) whereby the > User must input a orbit number is old feature operation which may result > in the user entering an already used orbit. This form of Park to server > is somewhat limited. I agree that the model is not new. This isn't necessarily bad, in my opinion. And whilst the selected orbit might be in use, this is not necessarily a limitation. A Park Server may choose to accept multiple calls and form a queue. This is an implementation issue and not a protocol issue though. > Enhanced feature Park to Server operation should allow the user to > request the server to park a call and the server should allocate the > first available park orbit. The response could be given to the user in > two forms: announcement and additional information i.e.., park orbit > number given back to the end user. Yes, this is the other normal model. I discuss this briefly in section 4, except I don't mention announcements. Further elaboration could be added. > Both Old and Enhanced may require a bit different implementation e.g., > if park orbit not given then selects the first orbit or if park orbit > given, attempt to park in the requested orbit. Both these approaches are possible, and could be implemented by combining the approaches taken in sections 2 and 4. In this scenario, the initial orbit given in the REFER request-uri might be considered 'advisory' until a confirmed one was returned by the Park Server. > For Call Retrieve the orbit must be specified. >=20 > I did not see a Recall from park, whereby the Park exceeds a given time > and will attempt to notify or redistribute the parked party back to the > UA that parked the call to the server. In the case of redistributing the > parked party back to the UA, it would be nice for the UA to know the > call coming back was a parked call and not a new incoming call. Is > recall from park in the plans? My draft initially began as a way to resolve the apparent (in my opinion) weakness in addressing associated with the service-examples park/retrieve approach. There are plenty of other areas surrounding park/retrieve that could be addressed with a view to standardising them somewhat, and I think that this forum is probably the best place to discuss what needs attention and what can be left as implementation defined. > The old park to server feature whereby the user enters a park > destination is more in tune with the Park to Subscriber feature. In > this case one UA parks the call to another UI by indicating park to > subscriber and the destination to be parked-to (not orbit). That is certainly one implementation that I have seen. Parking against a subscriber is not always appropriate though, especially when the ultimate destination UA is not known when parking. One thing that is clear is that people have different expectations of a park/retrieve service. Any attempt to codify one set of implementation choices is likely to be counter-productive. Instead, we need to identify the missing building blocks that can be used in multiple ways whilst still offering some level of interoperability between vendors. Regards, Michael Procter _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 27 13:37:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7CR-0002qq-8D; Tue, 27 Feb 2007 13:37:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7CQ-0002ql-73 for bliss@ietf.org; Tue, 27 Feb 2007 13:37:18 -0500 Received: from usnwksmtp02e.usa.siemens.com ([12.46.135.31] helo=usnwk220srv.usa.siemens.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7CO-0002Be-P0 for bliss@ietf.org; Tue, 27 Feb 2007 13:37:18 -0500 Received: from usnwk202a.ww017.siemens.net ([155.45.111.47]) by usnwk220srv.usa.siemens.com with InterScan Messaging Security Suite; Tue, 27 Feb 2007 10:37:19 -0800 Received: from USNWK101MSX.ww017.siemens.net ([155.45.111.55]) by usnwk202a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:37:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Call Park/Retrieve Date: Tue, 27 Feb 2007 10:37:13 -0800 Message-ID: <55AF62549C5C4049B13A2A273445C486274C1AA1@USNWK101MSX.ww017.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call Park/Retrieve thread-index: Acdah/HkE7YzOtzpQdKXv3TKknX6mQAFd1ww From: "Kucmerowski, Dennis \(Com US\)" To: , X-OriginalArrivalTime: 27 Feb 2007 18:37:14.0984 (UTC) FILETIME=[4D328E80:01C75A9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale, In the non-SIP world yes. Siemens supports this form of operation for Park to Server. The user requests to park the call via a park request. The user at the endpoint receives indication of what park slot the call was parked in. Best Regards, =20 Dennis L. Kucmerowski=20 561-923-1703 Systems Engineering =20 -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Tuesday, February 27, 2007 10:57 AM To: bliss@ietf.org Subject: Re: [BLISS] Call Park/Retrieve From: "Kucmerowski, Dennis \(Com US\)" Enhanced feature Park to Server operation should allow the user to request the server to park a call and the server should allocate the first available park orbit. The response could be given to the user in two forms: announcement and additional information i.e.., park orbit number given back to the end user.=20 Do you know of any implementations of this scheme? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Feb 27 17:09:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAW2-0000Za-9F; Tue, 27 Feb 2007 17:09:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAKg-0004er-Lv for bliss@ietf.org; Tue, 27 Feb 2007 16:58:02 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAG4-00064O-VT for bliss@ietf.org; Tue, 27 Feb 2007 16:53:18 -0500 Received: from 24-107-197-43.dhcp.stls.mo.charter.com ([24.107.197.43] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HM9dY-000Ckx-Lr; Tue, 27 Feb 2007 16:13:28 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.43 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45E49EF7.6060306@sipstation.com> Date: Tue, 27 Feb 2007 15:13:27 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Mohsen Soroush-nejad , Venkatesh Venkataramanan , Anil Kumar Subject: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org All, The authors of draft-anil-sipping-bla (which will be revised as -04 next week) have put together this draft discussing requirements and implementation options for set of features known as Bridged Line Appearance (BLA), Multiple Line Appearance (MLA), Single Line Extension, etc. Comments are most welcome. Thanks, Alan -------- Original Message -------- Subject: I-D ACTION:draft-johnston-bliss-mla-req-00.txt Date: Tue, 27 Feb 2007 15:50:03 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements and Implementation Options for the Multiple Line Appearance Feature using the Session Initiation Protocol (SIP) Author(s) : A. Johnston, et al. Filename : draft-johnston-bliss-mla-req-00.txt Pages : 16 Date : 2007-2-27 This document describes the requirements for implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance, or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-bliss-mla-req-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johnston-bliss-mla-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johnston-bliss-mla-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss