RE: Test message

Volker Hilt <volkerh@bell-labs.com> · 01/15/2010 09:47 AM

> To address the use cases we have on the table, E2M is a straight forward

> solution. Other use cases need to be solved by other means/protocal.

Agree 100%, +1, etc :)
I need E2M or similar for some of my own work to progress.
Ray
Ken,
On reading your mail I am continually reminded of
the mantra that perfection is the enemy of the good.  By trying to
be all things to all people, we end up making something that's too complicated
for anyone to use - just look what we did in DRINKS :(.
Sure, there are use cases for such things as non-E164
to URI (for e-mail-style AoRs, for example), and all that other stuff.
 However those are hard problems which will take years of IETF effort
to solve.
There's a specific need for particular forms of (meta-)data
which would fit perfectly well inside E2U, were it not that the _semantics_
of that data are unacceptable to the ENUM purists.
The E2M proposal is a very minor adaption of the _proven_
RFC 3761 technology, but without the semantic limitations.
Taking those drafts that are struggling to find a
home in ENUM and updating them for E2M would be completely trivial, and
IMHO should be done without delay.
Ray
-- 

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: ray@nominet.org.uk, t: +44 1865 332211

Ken,
=
On reading your mail I am continually reminded of the mantra that perfectio=
n is the enemy of the good.  By trying to be all things to all people,=
 we end up making something that's too complicated
 for anyone to use - just look what we did in DRINKS :(.
=
Sure, there are use cases for such things as non-E164 to URI (for e-mail-st=
yle AoRs, for example), and all that other stuff.  However those are h=
ard problems which will take years of IETF
 effort to solve.
=
There's a specific need for particular forms of (meta-)data which would fit=
 perfectly well inside E2U, were it not that the _semantics_ of that data a=
re unacceptable to the ENUM purists.
=
The E2M proposal is a very minor adaption of the _proven_ RFC 3761 technolo=
gy, but without the semantic limitations.
=
Taking those drafts that are struggling to find a home in ENUM and updating=
 them for E2M would be completely trivial, and IMHO should be done without =
delay.
=
Ray
=
-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nomi=
net
e: ray@nominet.org.uk, t: +44 1865 33221=
1
> I hear ya on the time frame.  Your need for
something *now* for a 

> specific sub-set of use cases can certainly trump a broader desire

> to cover the additional use cases that the three items in my 

> previous response would cover.
Looking at those three items:
> 1) Telephone calls and the services that surrou=
nd
them (e.g. calling
>    name, e911, etc, etc) need to work
for both TN and URI lookup key
>    use cases.  If I understand
your E2M/DDDS proposal, it will only
>    be usable if a TN (turned into a
domain name) is the lookup key.
>    Do I understand your proposal corr=
ectly
here?  It seems that allowing
>    a lookup key to be an arbitrarily
formed string (rather than a
>    domain name) is a relatively minor
change, so maybe E2M can be
>    designed to support that.

I've been involved with an NICC study on use of non-=
E.164
identifiers in next-generation-networks, which should be published shortly
- it's real hard, particularly where portability is a requirement.

If this is a goal then there should be =5Fseparate=5F
and very wide ranging work at IETF about peering and routing for non-E.164-=
based
calling.  I believe Otmar has called for this before.

In any event, the three known use cases for E2M are
rather E.164 specific.  Send-N and Void are certainly 100% E.164 speci=
fic.
 I'm not so sure about CNAM.

> 2) The response structure of a meta-data protoc=
ol
should be allowed

>    to be fairly rich and nested (e.g.
XML like).  Otherwise folks will

>    find yucky hacks in order to accom=
plish
that within a protocol that

>    does not support it.  Perhaps
E2M can be designed to support this.

Yes, trivially, by mirroring E2U+vcard, and allowing
indirection to "rich" data sources.

> 3) It would be very good to be able to identify
and use the source of a

>    lookup when formulating the respon=
se.
 So at a *minimum*, it would

>    good to make sure that the solution
proposed allows for a source

>    identification scheme to be overla=
id.
 This seems like a feasible feature

>    that perhaps E2M could support.

Umm, why, exactly?  E2U doesn't have it, so why
should E2M?  None of the three established use cases need it.

If you're thinking of DRINKS, didn't the design team
ultimately conclude that the LUF (which happens to map nicely to ENUM)
doesn't need this feature?

> ... snipped ...  

> However, these monikers do not mean that one should not attempt to

> solve the problem.  So we’ve basically debating *what* sub-=
set
of 

> problems need to be solved in what time frame.

>

> So getting back to the point, perhaps an approa=
ch
would be a phased 

> one, where the first phase is to solve what folks determine to be

> the immediate needs, and the second phase is to build on that to 

> meet a broader set of use cases.  Because I think you are right
that

> E2M as proposed does definitely meet the need of some important use
cases.

I think that we need to determine whether those other
potential problems are in the same class as those that E2M is designed
to solve.

I don't believe that they are even remotely in the
same class, and would not like to see E2M being held up because of unrelated
(and frankly, far larger) issues.

kind regards,

Ray

--=_alternative 00619969802576A8_=--

From richard@shockey.us  Mon Jan 11 11:01:39 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84593A68AC for ; Mon, 11 Jan 2010 11:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWiHXxHfWch7 for ; Mon, 11 Jan 2010 11:01:33 -0800 (PST)
Received: from outbound-mail-27.bluehost.com (outbound-mail-27.bluehost.com [69.89.17.193]) by core3.amsl.com (Postfix) with SMTP id 2C4B83A6882 for ; Mon, 11 Jan 2010 11:01:33 -0800 (PST)
Received: (qmail 12964 invoked by uid 0); 11 Jan 2010 19:01:28 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 11 Jan 2010 19:01:28 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=GQnbOBNm8rRZwUHinTvVqvmgdFiJ3S8Apf/nzEIk+OWW+ntLkdFcKQv7zri40aj+6wWvDLWFRwjbK6G4nbVnEe3h2O1I1jS1Egytzgu2dVa4smOo5z3OU4S9Q2Djplwa;
Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NUPW3-0002EE-FZ; Mon, 11 Jan 2010 12:01:27 -0700
From: "Richard Shockey" 
To: , "'Cartwright, Kenneth'" 
References: <754963199212404AB8E9CFCA6C3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com>		<754963199212404AB8E9CFCA6C3D0CDA0A38DA5861@TNS-MAIL-NA.win2k.corp.tnsi.com>		<754963199212404AB8E9CFCA6C3D0CDA0A38DA594F@TNS-MAIL-NA.win2k.corp.tnsi.com> 
In-Reply-To: 
Date: Mon, 11 Jan 2010 14:01:24 -0500
Message-ID: <00af01ca92f0$79443540$6bcc9fc0$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01CA92C6.906E2D40"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqS5fdwhRl8wflNT8CDkQA7MEZMXgACaTQg
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us}
Cc: 'Bernie Hoeneisen' , dispatch@ietf.org
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Jan 2010 19:01:40 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00B0_01CA92C6.906E2D40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In line..

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Ray.Bellis@nominet.org.uk
Sent: Monday, January 11, 2010 12:46 PM
To: Cartwright, Kenneth
Cc: dispatch-bounces@ietf.org; Bernie Hoeneisen; dispatch@ietf.org
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)

> I hear ya on the time frame.  Your need for something *now* for a 
> specific sub-set of use cases can certainly trump a broader desire 
> to cover the additional use cases that the three items in my 
> previous response would cover. 

Looking at those three items: 

> 1) Telephone calls and the services that surround them (e.g. calling 
>    name, e911, etc, etc) need to work for both TN and URI lookup key 
>    use cases.  If I understand your E2M/DDDS proposal, it will only 
>    be usable if a TN (turned into a domain name) is the lookup key. 
>    Do I understand your proposal correctly here?  It seems that allowing 
>    a lookup key to be an arbitrarily formed string (rather than a 
>    domain name) is a relatively minor change, so maybe E2M can be 
>    designed to support that. 

I've been involved with an NICC study on use of non-E.164 identifiers in
next-generation-networks, which should be published shortly - it's real
hard, particularly where portability is a requirement. 

If this is a goal then there should be _separate_ and very wide ranging work
at IETF about peering and routing for non-E.164-based calling.  I believe
Otmar has called for this before. 

Don't hold your breath on that one. 

In any event, the three known use cases for E2M are rather E.164 specific.
Send-N and Void are certainly 100% E.164 specific.  I'm not so sure about
CNAM. 

It actually is and in fact it is the major market driver for using the E2M
ENUM LUF. 

> 2) The response structure of a meta-data protocol should be allowed 
>    to be fairly rich and nested (e.g. XML like).  Otherwise folks will 
>    find yucky hacks in order to accomplish that within a protocol that 
>    does not support it.  Perhaps E2M can be designed to support this. 

E2M+foo defines what you may ultimately look at. 

Yes, trivially, by mirroring E2U+vcard, and allowing indirection to "rich"
data sources. 

Right ..

> 3) It would be very good to be able to identify and use the source of a 
>    lookup when formulating the response.  So at a *minimum*, it would 
>    good to make sure that the solution proposed allows for a source 
>    identification scheme to be overlaid.  This seems like a feasible
feature 
>    that perhaps E2M could support. 

Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None of the
three established use cases need it. 

If you're thinking of DRINKS, didn't the design team ultimately conclude
that the LUF (which happens to map nicely to ENUM) doesn't need this
feature? 

Not necessarily .. for the peering function the LUF might return a different
URI based on the source. 

I don't believe that they are even remotely in the same class, and would not
like to see E2M being held up because of unrelated (and frankly, far larger)
issues. 

IMHO put the E2M structure in place and let people see what they want to use
if for. Any one of these preliminary use cases justifies the Development of
E2M. 

kind regards, 

Ray 

------=_NextPart_000_00B0_01CA92C6.906E2D40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In line..

From:=

dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Ray.Bellis@nominet.org.uk

Sent: Monday, January 11, 2010 12:46 PM

To: Cartwright, Kenneth

Cc: dispatch-bounces@ietf.org; Bernie Hoeneisen; =
dispatch@ietf.org

Subject: Re: [dispatch] E2M: Proposed Charter (draft version =
only)

> I hear ya on the time frame.  Your need for something =
*now*
for a 

> specific sub-set of use cases can certainly trump a broader =
desire 

> to cover the additional use cases that the three items in my =

> previous response would cover. 

Looking at those three =
items: 

> 1) Telephone calls and the =
services
that surround them (e.g. calling 

>    name, e911, etc, =
etc) need
to work for both TN and URI lookup key 

>    use cases. =
 If I
understand your E2M/DDDS proposal, it will only 

>    be usable if a TN =
(turned
into a domain name) is the lookup key. 

>    Do I understand =
your
proposal correctly here?  It seems that allowing 

>    a lookup key to =
be an
arbitrarily formed string (rather than a 

>    domain name) is a
relatively minor change, so maybe E2M can be 

>    designed to =
support that.

I've been involved with an NICC =
study on use
of non-E.164 identifiers in next-generation-networks, which should be =
published
shortly - it's real hard, particularly where portability is a =
requirement.

If this is a goal then there should =
be
_separate_ and very wide ranging work at IETF about peering and routing =
for
non-E.164-based calling.  I believe Otmar has called for this =
before.

Don’t hold your =
breath on
that one. 

In any event, the three known use =
cases for
E2M are rather E.164 specific.  Send-N and Void are certainly 100% =
E.164
specific.  I'm not so sure about CNAM. 

It actually is and in =
fact it
is the major market driver for using the E2M ENUM LUF. =

> 2) The response structure of a
meta-data protocol should be allowed 

>    to be fairly rich =
and
nested (e.g. XML like).  Otherwise folks will 

>    find yucky hacks =
in order
to accomplish that within a protocol that 

>    does not support =
it.
 Perhaps E2M can be designed to support this. 

E2M+foo defines what =
you may
ultimately look at. 

Yes, trivially, by mirroring =
E2U+vcard, and
allowing indirection to "rich" data sources. 

Right =
..

> 3) It would be very good to be =
able to
identify and use the source of a 

>    lookup when =
formulating
the response.  So at a *minimum*, it would 

>    good to make sure =
that the
solution proposed allows for a source 

>    identification =
scheme to
be overlaid.  This seems like a feasible feature 

>    that perhaps E2M =
could
support. 

Umm, why, exactly?  E2U =
doesn't have
it, so why should E2M?  None of the three established use cases =
need it.

If you're thinking of DRINKS, =
didn't the
design team ultimately conclude that the LUF (which happens to map =
nicely to
ENUM) doesn't need this feature? 

Not necessarily .. for =
the peering
function the LUF might return a different URI based on the source. =

I don't believe that they are even =
remotely
in the same class, and would not like to see E2M being held up because =
of
unrelated (and frankly, far larger) issues. 

IMHO put the E2M =
structure in
place and let people see what they want to use if for. Any one of these
preliminary use cases justifies the Development of E2M. =

kind regards, 

Ray 

------=_NextPart_000_00B0_01CA92C6.906E2D40--

From Ray.Bellis@nominet.org.uk  Mon Jan 11 12:12:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8073A694F for ; Mon, 11 Jan 2010 12:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level: 
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMofZG11+dZd for ; Mon, 11 Jan 2010 12:12:18 -0800 (PST)
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 3082E3A6969 for ; Mon, 11 Jan 2010 12:12:06 -0800 (PST)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=n+uBCAHvcNtl923jRxV2yD7DE5Khar1qWyJhw0TosHGFyxUaTVY4ffti UtgRum+ySPZq/IBhvomEzG2aKybkjSSXJ71yhgM3ZCjXcDcV1yAZpbSbO plYqmwGcf9ypBu7;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1263240725; x=1294776725; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[disp atch]=20E2M:=20Proposed=20Charter=20(draft=20version=20on ly)|Date:=20Mon,=2011=20Jan=202010=2020:12:02=20+0000 |Message-ID:=20|To:=20"Richard=20Shockey "=20|Cc:=20"'Bernie=20Hoeneisen'"=20< bernie@ietf.hoeneisen.ch>,=0D=0A=09dispatch@ietf.org,=0D =0A=09"'Cartwright,=20Kenneth'"=20 |MIME-Version:=201.0|In-Reply-To:=20<00af01ca92f0$7944354 0$6bcc9fc0$@us>|References:=20<754963199212404AB8E9CFCA6C 3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com>=0D=0A =09=09<754963199212404AB8E9CFCA6C3D0CDA0A38DA5861@TNS -MAIL-NA.win2k.corp.tnsi.com>=0D=0A=09 =0D=0A=09<754963199212404AB8E9CFCA6C3D0CDA0A38DA594F@TNS- MAIL-NA.win2k.corp.tnsi.com>=20=20<00af0 1ca92f0$79443540$6bcc9fc0$@us>; bh=zQxh61MwnM4A0mFjToAhg4xOUm0dCuWiBu4kneaSwmE=; b=FJ1rOHGLwpQnEqwt3MXuHjTT50WhMnGZ1RPcc1S6E/3RyXVpt9wPwpMS XsFIb0mGMl2/WyZwvVowlDaDSg2sJ3m9Dzv8HiofT6ZxDruRwk00vG50k uMkZ9LPWftBWNxG;
X-IronPort-AV: E=Sophos;i="4.49,257,1262563200"; d="scan'208";a="20767043"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 11 Jan 2010 20:12:03 +0000
In-Reply-To: <00af01ca92f0$79443540$6bcc9fc0$@us>
References: <754963199212404AB8E9CFCA6C3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com> 	<754963199212404AB8E9CFCA6C3D0CDA0A38DA5861@TNS-MAIL-NA.win2k.corp.tnsi.com>  <754963199212404AB8E9CFCA6C3D0CDA0A38DA594F@TNS-MAIL-NA.win2k.corp.tnsi.com>  <00af01ca92f0$79443540$6bcc9fc0$@us>
To: "Richard Shockey" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID: 
From: Ray.Bellis@nominet.org.uk
Date: Mon, 11 Jan 2010 20:12:02 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/01/2010 08:12:03 PM, Serialize complete at 11/01/2010 08:12:03 PM
Content-Type: multipart/alternative; boundary="=_alternative 006EF73F802576A8_="
Cc: 'Bernie Hoeneisen' , dispatch@ietf.org
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Jan 2010 20:12:40 -0000

This is a multipart message in MIME format.
--=_alternative 006EF73F802576A8_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

PiB8IElmIHRoaXMgaXMgYSBnb2FsIHRoZW4gdGhlcmUgc2hvdWxkIGJlIF9zZXBhcmF0ZV8gYW5k
IHZlcnkgd2lkZSANCj4gfCByYW5naW5nIHdvcmsgYXQgSUVURiBhYm91dCBwZWVyaW5nIGFuZCBy
b3V0aW5nIGZvciBub24tRS4xNjQtYmFzZWQgDQo+IHwgY2FsbGluZy4gIEkgYmVsaWV2ZSBPdG1h
ciBoYXMgY2FsbGVkIGZvciB0aGlzIGJlZm9yZS4gDQo+IA0KPiBEb27igJl0IGhvbGQgeW91ciBi
cmVhdGggb24gdGhhdCBvbmUuIA0KDQpUaGF0J3Mga2luZCBvZiBteSBwb2ludC4gIFBvcnRhYmls
aXR5IG9mIG5vbi1FLjE2NCBpcyBhIG1hc3NpdmUgdG9waWMgYW5kIA0KSSwgZm9yIG9uZSwgZG9u
J3Qgd2FudCB0byBzZWUgRTJNIGNhdWdodCB1cCBpbiBpdC4NCiANCj4gfCBJbiBhbnkgZXZlbnQs
IHRoZSB0aHJlZSBrbm93biB1c2UgY2FzZXMgZm9yIEUyTSBhcmUgcmF0aGVyIEUuMTY0IA0KPiB8
IHNwZWNpZmljLiAgU2VuZC1OIGFuZCBWb2lkIGFyZSBjZXJ0YWlubHkgMTAwJSBFLjE2NCBzcGVj
aWZpYy4gIEknbSANCj4gfCBub3Qgc28gc3VyZSBhYm91dCBDTkFNLiANCj4gSXQgYWN0dWFsbHkg
aXMgYW5kIGluIGZhY3QgaXQgaXMgdGhlIG1ham9yIG1hcmtldCBkcml2ZXIgZm9yIHVzaW5nIA0K
PiB0aGUgRTJNIEVOVU0gTFVGLiANCg0KSSB0aG91Z2h0IHRoYXQgd2FzIHByb2JhYmx5IHRoZSBj
YXNlIC0gdGhhbmtzIGZvciBjbGFyaWZ5aW5nLg0KIA0KPiBFMk0rZm9vIGRlZmluZXMgd2hhdCB5
b3UgbWF5IHVsdGltYXRlbHkgbG9vayBhdC4gDQoNCkluZGVlZC4NCg0KPiB8IFllcywgdHJpdmlh
bGx5LCBieSBtaXJyb3JpbmcgRTJVK3ZjYXJkLCBhbmQgYWxsb3dpbmcgaW5kaXJlY3Rpb24gdG8g
DQo+IHwgInJpY2giIGRhdGEgc291cmNlcy4gDQo+IA0KPiBSaWdodCAuLg0KDQpJcyB0aGF0IGFj
dHVhbCBhZ3JlZW1lbnQsIG9yIGRvIHlvdSBtZWFuICJyaWdodCIgaW4gdGhlIHNlbnNlIHRoYXQg
eW91IA0KY291bGQsIGJ1dCBwcm9iYWJseSBzaG91bGRuJ3Q/IDstKQ0KDQo+IHwgSWYgeW91J3Jl
IHRoaW5raW5nIG9mIERSSU5LUywgZGlkbid0IHRoZSBkZXNpZ24gdGVhbSB1bHRpbWF0ZWx5IA0K
PiB8IGNvbmNsdWRlIHRoYXQgdGhlIExVRiAod2hpY2ggaGFwcGVucyB0byBtYXAgbmljZWx5IHRv
IEVOVU0pIGRvZXNuJ3QgDQo+IHwgbmVlZCB0aGlzIGZlYXR1cmU/IA0KPiBOb3QgbmVjZXNzYXJp
bHkgLi4gZm9yIHRoZSBwZWVyaW5nIGZ1bmN0aW9uIHRoZSBMVUYgbWlnaHQgcmV0dXJuIGEgDQo+
IGRpZmZlcmVudCBVUkkgYmFzZWQgb24gdGhlIHNvdXJjZS4gDQoNCk9LLCB1c2VmdWwgdG8ga25v
dywgYnV0IHN0aWxsIG5vIGNhc2UgKElNSE8pIGZvciBlbmN1bWJlcmluZyBFMk0gd2l0aCBpdCAN
CndoZW4gRTJVIGRvZXNuJ3QuDQoNCj4gSU1ITyBwdXQgdGhlIEUyTSBzdHJ1Y3R1cmUgaW4gcGxh
Y2UgYW5kIGxldCBwZW9wbGUgc2VlIHdoYXQgdGhleSANCj4gd2FudCB0byB1c2UgaWYgZm9yLiBB
bnkgb25lIG9mIHRoZXNlIHByZWxpbWluYXJ5IHVzZSBjYXNlcyBqdXN0aWZpZXMNCj4gdGhlIERl
dmVsb3BtZW50IG9mIEUyTS4gDQoNCisxLCBidXQgZG9uJ3QgY29tcGxpY2F0ZSBpdCB3aXRoIHVu
c3BlY2lmaWVkIGZ1dHVyZSB1c2UgY2FzZXMuICBUaGV5J2xsIA0KbGlrZWx5IG5lZWQgc29tZXRo
aW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50Lg0KDQpSYXkNCg0K
--=_alternative 006EF73F802576A8_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IHwgSWYgdGhpcyBpcyBhIGdvYWwgdGhlbiB0aGVy
ZSBzaG91bGQgYmUgX3NlcGFyYXRlXyBhbmQgdmVyeSB3aWRlDQo8YnI+DQomZ3Q7IHwgcmFuZ2lu
ZyB3b3JrIGF0IElFVEYgYWJvdXQgcGVlcmluZyBhbmQgcm91dGluZyBmb3Igbm9uLUUuMTY0LWJh
c2VkDQo8YnI+DQomZ3Q7IHwgY2FsbGluZy4gJm5ic3A7SSBiZWxpZXZlIE90bWFyIGhhcyBjYWxs
ZWQgZm9yIHRoaXMgYmVmb3JlLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERvbuKAmXQg
aG9sZCB5b3VyIGJyZWF0aCBvbiB0aGF0IG9uZS4gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj5UaGF0J3Mga2luZCBvZiBteSBwb2ludC4gJm5ic3A7UG9ydGFiaWxpdHkg
b2Ygbm9uLUUuMTY0DQppcyBhIG1hc3NpdmUgdG9waWMgYW5kIEksIGZvciBvbmUsIGRvbid0IHdh
bnQgdG8gc2VlIEUyTSBjYXVnaHQgdXAgaW4gaXQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mbmJzcDs8YnI+DQomZ3Q7IHwgSW4gYW55IGV2ZW50LCB0aGUgdGhyZWUga25vd24g
dXNlIGNhc2VzIGZvciBFMk0gYXJlIHJhdGhlciBFLjE2NA0KPGJyPg0KJmd0OyB8IHNwZWNpZmlj
LiAmbmJzcDtTZW5kLU4gYW5kIFZvaWQgYXJlIGNlcnRhaW5seSAxMDAlIEUuMTY0IHNwZWNpZmlj
Lg0KJm5ic3A7SSdtIDxicj4NCiZndDsgfCBub3Qgc28gc3VyZSBhYm91dCBDTkFNLiA8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSXQgYWN0dWFsbHkgaXMgYW5kIGluIGZh
Y3QgaXQgaXMgdGhlIG1ham9yIG1hcmtldA0KZHJpdmVyIGZvciB1c2luZyA8YnI+DQomZ3Q7IHRo
ZSBFMk0gRU5VTSBMVUYuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
SSB0aG91Z2h0IHRoYXQgd2FzIHByb2JhYmx5IHRoZSBjYXNlIC0gdGhhbmtzIGZvcg0KY2xhcmlm
eWluZy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBFMk0rZm9vIGRlZmluZXMgd2hhdCB5b3UgbWF5
IHVsdGltYXRlbHkgbG9vaw0KYXQuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+SW5kZWVkLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0
OyB8IFllcywgdHJpdmlhbGx5LCBieSBtaXJyb3JpbmcgRTJVK3ZjYXJkLCBhbmQgYWxsb3dpbmcg
aW5kaXJlY3Rpb24NCnRvIDxicj4NCiZndDsgfCAmcXVvdDtyaWNoJnF1b3Q7IGRhdGEgc291cmNl
cy4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSaWdodCAuLjwvZm9udD48L3R0Pg0KPGJy
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SXMgdGhhdCBhY3R1YWwgYWdyZWVtZW50LCBvciBkbyB5
b3UgbWVhbiAmcXVvdDtyaWdodCZxdW90Ow0KaW4gdGhlIHNlbnNlIHRoYXQgeW91IGNvdWxkLCBi
dXQgcHJvYmFibHkgc2hvdWxkbid0PyA7LSk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPjxicj4NCiZndDsgfCBJZiB5b3UncmUgdGhpbmtpbmcgb2YgRFJJTktTLCBkaWRuJ3QgdGhl
IGRlc2lnbiB0ZWFtIHVsdGltYXRlbHkNCjxicj4NCiZndDsgfCBjb25jbHVkZSB0aGF0IHRoZSBM
VUYgKHdoaWNoIGhhcHBlbnMgdG8gbWFwIG5pY2VseSB0byBFTlVNKSBkb2Vzbid0DQo8YnI+DQom
Z3Q7IHwgbmVlZCB0aGlzIGZlYXR1cmU/IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyBOb3QgbmVjZXNzYXJpbHkgLi4gZm9yIHRoZSBwZWVyaW5nIGZ1bmN0aW9uIHRoZQ0K
TFVGIG1pZ2h0IHJldHVybiBhIDxicj4NCiZndDsgZGlmZmVyZW50IFVSSSBiYXNlZCBvbiB0aGUg
c291cmNlLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk9LLCB1c2Vm
dWwgdG8ga25vdywgYnV0IHN0aWxsIG5vIGNhc2UgKElNSE8pIGZvciBlbmN1bWJlcmluZw0KRTJN
IHdpdGggaXQgd2hlbiBFMlUgZG9lc24ndC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgSU1ITyBwdXQgdGhlIEUyTSBzdHJ1Y3R1cmUgaW4gcGxhY2UgYW5kIGxl
dCBwZW9wbGUNCnNlZSB3aGF0IHRoZXkgPGJyPg0KJmd0OyB3YW50IHRvIHVzZSBpZiBmb3IuIEFu
eSBvbmUgb2YgdGhlc2UgcHJlbGltaW5hcnkgdXNlIGNhc2VzIGp1c3RpZmllczxicj4NCiZndDsg
dGhlIERldmVsb3BtZW50IG9mIEUyTS4gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4rMSwgYnV0IGRvbid0IGNvbXBsaWNhdGUgaXQgd2l0aCB1bnNwZWNpZmllZCBmdXR1
cmUNCnVzZSBjYXNlcy4gJm5ic3A7VGhleSdsbCBsaWtlbHkgbmVlZCBzb21ldGhpbmcgY29tcGxl
dGVseSBkaWZmZXJlbnQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5S
YXk8L2ZvbnQ+PC90dD4NCjxicj4NCg==
--=_alternative 006EF73F802576A8_=--

From kcartwright@tnsi.com  Mon Jan 11 15:28:43 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2D43A67F5; Mon, 11 Jan 2010 15:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.695
X-Spam-Level: 
X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.903,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL8SYP1CMS-7; Mon, 11 Jan 2010 15:28:34 -0800 (PST)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 06A533A6819; Mon, 11 Jan 2010 15:28:33 -0800 (PST)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.39391237; Mon, 11 Jan 2010 18:28:07 -0500
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 11 Jan 2010 18:28:07 -0500
From: "Cartwright, Kenneth" 
To: "Ray.Bellis@nominet.org.uk" 
Date: Mon, 11 Jan 2010 18:28:05 -0500
Thread-Topic: [dispatch] E2M: Proposed Charter (draft version only)
Thread-Index: AcqS5fXN3xO9qXVmStCDg5UNz7flZAAK4TjA
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0A38DA5D03@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: <754963199212404AB8E9CFCA6C3D0CDA091AB63873@TNS-MAIL-NA.win2k.corp.tnsi.com>  <754963199212404AB8E9CFCA6C3D0CDA0A38DA5861@TNS-MAIL-NA.win2k.corp.tnsi.com>  <754963199212404AB8E9CFCA6C3D0CDA0A38DA594F@TNS-MAIL-NA.win2k.corp.tnsi.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0A38DA5D03TNSMAILNAwin2_"
MIME-Version: 1.0
Cc: "dispatch-bounces@ietf.org" , Bernie Hoeneisen , "dispatch@ietf.org" 
Subject: Re: [dispatch] E2M: Proposed Charter (draft version only)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Jan 2010 23:28:43 -0000

--_000_754963199212404AB8E9CFCA6C3D0CDA0A38DA5D03TNSMAILNAwin2_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

a)       On Non-TN lookup keys, what you refer to as the "use of non-E.164 =
identifiers in next-generation-networks ... where portability is a requirem=
ent" is not on my radar screen.  So I'm not sure what you are referring to =
there.  What I was getting as was, for example, how would you envision look=
ing up a calling name or a vcard using an email address, as apposed to a te=
lephone number?  Having to have a separate protocol and a separate registry=
 just because the lookup key takes a different form is not good.  Imo, E2M =
would necessitate the review of all the ENUM services that have been approv=
ed, and those currently under evaluation, such that all those services that=
 are more appropriately under the e2m rather than e2u are moved over to e2m=
.  Aren't there many current and future ENUM services that are useful even =
for non-telephone-number lookup keys?  For example, wouldn't you want the a=
bility to lookup a vcard or a calling name for an email like URI, just like=
 you might want to look one up for a telephone number?
b)       On source identification, there is not yet a standardized approach=
 to it for ENUM, but it is certainly commonly "hacked in" and done in pract=
ice using a couple different means.  As you alluded to, Drinks discussed a =
couple approaches that are used in practice.  And with respect to your ques=
tion about the LUF, I do not think that source identification can be *disal=
lowed* for a LUF service.  However, it is certainly true that some LUF serv=
ices may not need/want to use it.
c)       On more rich response structures and query criteria, I guess there=
 are they types of partial solutions and workarounds like those used in vca=
rd that can be made to work for some cases.

On the whole, however, it sounds like you have your path set, and I see you=
 have a need for urgency to get the solution in place to meet the uses case=
 identified asap (which I can certainly sympathize with).  So as long as th=
e distinction between E2U and E2M name spaces are clear then I guess the ne=
ed that I see for a more full featured address-to-metadata-lookup-protocol =
is more appropriately somewhere other than the immediate E2M name space.

Ken

________________________________
From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
Sent: Monday, January 11, 2010 12:46 PM
To: Cartwright, Kenneth
Cc: Bernie Hoeneisen; dispatch@ietf.org; dispatch-bounces@ietf.org
Subject: RE: [dispatch] E2M: Proposed Charter (draft version only)

> I hear ya on the time frame.  Your need for something *now* for a
> specific sub-set of use cases can certainly trump a broader desire
> to cover the additional use cases that the three items in my
> previous response would cover.

Looking at those three items:

> 1) Telephone calls and the services that surround them (e.g. calling
>    name, e911, etc, etc) need to work for both TN and URI lookup key
>    use cases.  If I understand your E2M/DDDS proposal, it will only
>    be usable if a TN (turned into a domain name) is the lookup key.
>    Do I understand your proposal correctly here?  It seems that allowing
>    a lookup key to be an arbitrarily formed string (rather than a
>    domain name) is a relatively minor change, so maybe E2M can be
>    designed to support that.

I've been involved with an NICC study on use of non-E.164 identifiers in ne=
xt-generation-networks, which should be published shortly - it's real hard,=
 particularly where portability is a requirement.

If this is a goal then there should be _separate_ and very wide ranging wor=
k at IETF about peering and routing for non-E.164-based calling.  I believe=
 Otmar has called for this before.

In any event, the three known use cases for E2M are rather E.164 specific. =
 Send-N and Void are certainly 100% E.164 specific.  I'm not so sure about =
CNAM.

> 2) The response structure of a meta-data protocol should be allowed
>    to be fairly rich and nested (e.g. XML like).  Otherwise folks will
>    find yucky hacks in order to accomplish that within a protocol that
>    does not support it.  Perhaps E2M can be designed to support this.

Yes, trivially, by mirroring E2U+vcard, and allowing indirection to "rich" =
data sources.

> 3) It would be very good to be able to identify and use the source of a
>    lookup when formulating the response.  So at a *minimum*, it would
>    good to make sure that the solution proposed allows for a source
>    identification scheme to be overlaid.  This seems like a feasible feat=
ure
>    that perhaps E2M could support.

Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None of the th=
ree established use cases need it.

If you're thinking of DRINKS, didn't the design team ultimately conclude th=
at the LUF (which happens to map nicely to ENUM) doesn't need this feature?

> ... snipped ...
> However, these monikers do not mean that one should not attempt to
> solve the problem.  So we've basically debating *what* sub-set of
> problems need to be solved in what time frame.
>
> So getting back to the point, perhaps an approach would be a phased
> one, where the first phase is to solve what folks determine to be
> the immediate needs, and the second phase is to build on that to
> meet a broader set of use cases.  Because I think you are right that
> E2M as proposed does definitely meet the need of some important use cases=
.

I think that we need to determine whether those other potential problems ar=
e in the same class as those that E2M is designed to solve.

I don't believe that they are even remotely in the same class, and would no=
t like to see E2M being held up because of unrelated (and frankly, far larg=
er) issues.

kind regards,

Ray

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.

--_000_754963199212404AB8E9CFCA6C3D0CDA0A38DA5D03TNSMAILNAwin2_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

a) &=
nbsp;    
On Non-TN lookup keys, what you refer to as the “<=
/font>use
 of non-E.164 identifiers in next-generation-networks … where portabi=
lity is a requirement”
is not on my radar screen.  So I’m not sure what you=
 are referring to there.  What I was getting as was, for example, how =
would you
 envision looking up a calling name or a vcard using an email address, as a=
pposed to a telephone number?  Having to have a separate protocol and =
a separate registry just because the lookup key takes a different form is n=
ot good.<=
span style=3D"font-size:10.0pt;font-family:Arial;
color:navy"> 
 Imo, E2M would necessitate the review of all the ENUM services that have b=
een approved, and those currently under evaluation, such that all those ser=
vices that are more appropriately under the e2m rather than e2u are moved o=
ver to e2m.  Aren’t there many current
 and future ENUM services that are useful even for non-telephone-number loo=
kup keys?  For example, wouldn’t you want the ability to lookup =
a vcard or a calling name for an email like URI, just like you might want t=
o look one up for a telephone number?

b) &=
nbsp;    
On source identification, there is not yet a standardized appro=
ach to it for ENUM, but it is certainly commonly
 “hacked in” and done in practice using a couple different mean=
s.  As you alluded to, Drinks discussed a couple approaches that are u=
sed in practice.  And with respect to your question about the LUF, I d=
o not think that source identification can be *disallowed*
 for a LUF service.  However, it is certainly true that some LUF servi=
ces may not need/want to use it.

c) &=
nbsp;    
On more rich response structures and query criteria, I guess th=
ere are they types of partial solutions and workarounds
 like those used in vcard that can be made to work for some cases.

On the whole, however, it sounds like =
you have your path set, and I see you have a need for urgency to get the so=
lution in place to meet
 the uses case identified asap (which I can certainly sympathize with).&nbs=
p; So as long as the distinction between E2U and E2M name spaces are clear =
then I guess the need that I see for a more full featured address-to-metada=
ta-lookup-protocol is more appropriately
 somewhere other than the immediate E2M name space.

Ken

From: Ray.=
Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]

Sent: Monday, January 11, 20=
10 12:46 PM

To: Cartwright, Kenneth

Cc: Bernie Hoeneisen; dispat=
ch@ietf.org; dispatch-bounces@ietf.org

Subject: RE: [dispatch] E2M:=
 Proposed Charter (draft version only)

> I hear ya on the=
 time frame.  Your need for something *now* for a

> specific sub-set of use cases can certa=
inly trump a broader desire

> to cover the additional use cases that =
the three items in my

> previous response would cover.

=
Looking at those three items:

=
> 1) Telephone calls and the services that surround them (e.g. calling

=
>    name, e911, etc, etc) need to work for both TN and URI lo=
okup key

=
>    use cases.  If I understand your E2M/DDDS proposal, =
it will only

=
>    be usable if a TN (turned into a domain name) is the look=
up key.

=
>    Do I understand your proposal correctly here?  It se=
ems that allowing

=
>    a lookup key to be an arbitrarily formed string (rather t=
han a

=
>    domain name) is a relatively minor change, so maybe E2M c=
an be

=
>    designed to support that.

=
I've been involved with an NICC study on use of non-E.164 identifiers in ne=
xt-generation-networks, which should be published shortly - it's real hard,=
 particularly where portability is a requirement.

=
If this is a goal then there should be _separate_ and very wide ranging wor=
k at IETF about peering and routing for non-E.164-based calling.  I be=
lieve Otmar has called for this before.

=
In any event, the three known use cases for E2M are rather E.164 specific. =
 Send-N and Void are certainly 100% E.164 specific.  I'm not so s=
ure about CNAM.

=
> 2) The response structure of a meta-data protocol should be allowed

=
>    to be fairly rich and nested (e.g. XML like).  Other=
wise folks will

=
>    find yucky hacks in order to accomplish that within a pro=
tocol that

=
>    does not support it.  Perhaps E2M can be designed to=
 support this.

=
Yes, trivially, by mirroring E2U+vcard, and allowing indirection to &qu=
ot;rich" data sources.

=
> 3) It would be very good to be able to identify and use the source of =
a

=
>    lookup when formulating the response.  So at a *mini=
mum*, it would

=
>    good to make sure that the solution proposed allows for a=
 source

=
>    identification scheme to be overlaid.  This seems li=
ke a feasible feature

=
>    that perhaps E2M could support.

=
Umm, why, exactly?  E2U doesn't have it, so why should E2M?  None=
 of the three established use cases need it.

=
If you're thinking of DRINKS, didn't the design team ultimately conclude th=
at the LUF (which happens to map nicely to ENUM) doesn't need this feature?=

=
> ... snipped ...  

> However, these monikers do not mean tha=
t one should not attempt to

> solve the problem.  So we’ve=
 basically debating *what* sub-set of

> problems need to be solved in what time=
 frame.

=
>

=
> So getting back to the point, perhaps an approach would be a phased

> one, where the first phase is to solve =
what folks determine to be

> the immediate needs, and the second pha=
se is to build on that to

> meet a broader set of use cases.  =
Because I think you are right that

> E2M as proposed does definitely meet th=
e need of some important use cases.

=
I think that we need to determine whether those other potential problems ar=
e in the same class as those that E2M is designed to solve.

=
I don't believe that they are even remotely in the same class, and would no=
t like to see E2M being held up because of unrelated (and frankly, far larg=
er) issues.

=
kind regards,

=
Ray

This e-mail message is for t=
he sole use of the intended recipient(s)and may

contain confidential and privileged information of Transaction Network Serv=
ices.

Any unauthorised review, use, disclosure or distribution is prohibited. If =
you

are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.

--_000_754963199212404AB8E9CFCA6C3D0CDA0A38DA5D03TNSMAILNAwin2_--

From gonzalo.camarillo@ericsson.com  Thu Jan 14 03:54:27 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D7B3A68A8; Thu, 14 Jan 2010 03:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.141
X-Spam-Level: 
X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRjBJ-LN2PQK; Thu, 14 Jan 2010 03:54:26 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E9C093A683D; Thu, 14 Jan 2010 03:54:25 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-02-4b4f05de8cc9
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.2F.04178.ED50F4B4; Thu, 14 Jan 2010 12:54:07 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 12:52:41 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 12:52:41 +0100
Message-ID: <4B4F0589.6090202@ericsson.com>
Date: Thu, 14 Jan 2010 13:52:41 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Paul E. Jones" ,  Richard Shockey 
References: <013401ca679d$3a926700$afb73500$@us>	<00cd01ca8387$9b46ea20$d1d4be60$@com>	<4B32DEE9.5000302@softarmor.com>	<007301ca84b7$343dd6f0$9cb984d0$@us>	<4B33D01C.9000006@cisco.com>	<4B39AE2C.9090304@softarmor.com>	<503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com>	<1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com>	<4B433B4B.1030407@digium.com>	<80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com>	<4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com>	<4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com>
In-Reply-To: <00d101ca8f15$c91915b0$5b4b4110$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jan 2010 11:52:41.0080 (UTC) FILETIME=[1363BF80:01CA9510]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" , "sipcore@ietf.org" 
Subject: Re: [dispatch] [sipcore] I-D	Action:draft-jones-sip-forum-fax-problem-statement-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 11:54:27 -0000

Hi,

> We've had a number of exchanges and some people have missed a few messages
> as the thread bounced around two lists.  I'm sending this to both sipcore
> and dispatch so that people do not miss the discussion.

that is why we do not want people to cross-post to multiple lists and 
that is also why Dean, showing great wisdom (as usual ;o) ), removed one 
of the lists from the cc: when following up. Things can get confusing 
between lists and people subscribed to both get a lot of duplicate 
messages. In the future, please stick to only one list.

Thanks,

Gonzalo
DISPATCH and SIPCORE co-chair

From gonzalo.camarillo@ericsson.com  Thu Jan 14 06:02:49 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EC33A67FF for ; Thu, 14 Jan 2010 06:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.149
X-Spam-Level: 
X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5lQ2i12RLiV for ; Thu, 14 Jan 2010 06:02:49 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C14AE3A67D9 for ; Thu, 14 Jan 2010 06:02:48 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-b9-4b4f2404fa58
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FE.9D.04178.4042F4B4; Thu, 14 Jan 2010 15:02:44 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 15:02:43 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 15:02:43 +0100
Message-ID: <4B4F2403.7010200@ericsson.com>
Date: Thu, 14 Jan 2010 16:02:43 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: DISPATCH 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jan 2010 14:02:43.0823 (UTC) FILETIME=[3E2FD7F0:01CA9522]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Comments requested on draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 14:02:50 -0000

Hi,

we would like to ask for comments on the following draft. Do you find it 
useful? Do you think it should be published as an RFC?

http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-02

Based on the comments received, we will talk to our ADs about this piece 
of work.

Thanks,

Gonzalo
DISPATCH co-chair

From gonzalo.camarillo@ericsson.com  Thu Jan 14 07:08:13 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B02E3A6813 for ; Thu, 14 Jan 2010 07:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.156
X-Spam-Level: 
X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoSy5fXbjjbm for ; Thu, 14 Jan 2010 07:08:11 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 75EC03A6817 for ; Thu, 14 Jan 2010 07:08:11 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-9b-4b4f3354640b
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id DD.EC.04178.4533F4B4; Thu, 14 Jan 2010 16:08:04 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 16:08:04 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 16:08:03 +0100
Message-ID: <4B4F3353.9010507@ericsson.com>
Date: Thu, 14 Jan 2010 17:08:03 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Spencer Dawkins 
References: 	<4B32DC9B.3040406@softarmor.com> <36D784AAD47343248BE3274F64A101ED@china.huawei.com>
In-Reply-To: <36D784AAD47343248BE3274F64A101ED@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jan 2010 15:08:03.0880 (UTC) FILETIME=[5EB91280:01CA952B]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" , Hadriel Kaplan 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 15:08:13 -0000

Hi,

the requirement for session correlation has appeared a number of times:

1) We have Hadriel's draft.

2) We also have the following draft, which eventually led to the 
disaggregated media work:

http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-correlation-01.txt

3) We also have the SIP-XMPP work, which may also need to correlate 
sessions somehow.

What we need to understand is whether or not the requirements for these 
different use cases are similar enough so that a single correlation 
mechanism is enough to meet all of them. If we can kill two birds (in 
this case more than two) with one stone, it would be a good thing. On 
the other hand, if the requirements are sufficiently different to be met 
by a single mechanism, then we would need more than one solution.

I know there have been informal conversations about this among the 
proponents of these three topics. Let's try and conclude those 
discussions on the list so that we can make a decision on how to proceed 
with this.

Cheers,

Gonzalo

Spencer Dawkins wrote:
> Speaking as sipclf co-chair, I've been assured by my AD that session ID is 
> not part of what sipclf is currently chartered to do.
> 
> I believe the "dispatching" part is for DISPATCH to say (1) this work 
> matters, and (2) the right way to proceed is $PLAN... where $PLAN could be 
> sending it to sipclf and adding it to the sipclf charter, but there can also 
> be other $PLANs.
> 
> I'm not clear what the boundaries of what needs to be dispatched are - but 
> session ID isn't close to those boundaries!
> 
> Spencer
> 
>>> I'd like to have this dispatched to the appropriate WG, preferably the 
>>> SIP-CLF WG (since they're a prime customer of it).
>> Process question: If we think it is roughly in-scope for the CLF working 
>> group, do we need to "dispatch" it? Or just ask on their list and let them 
>> decide on whether to get the AD to add it to their charter?
>>
>> And for what it is worth, I think we do need a session-correlator. 
>> Although I expect that somebody's SBC will remove it just for fun...
>>
>> --
>> Dean
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From spencer@wonderhamster.org  Thu Jan 14 07:48:22 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CB93A684C for ; Thu, 14 Jan 2010 07:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level: 
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e94syUd5zu0s for ; Thu, 14 Jan 2010 07:48:20 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CADC93A6837 for ; Thu, 14 Jan 2010 07:48:20 -0800 (PST)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MIdsG-1NTEzv31s8-002O04; Thu, 14 Jan 2010 10:47:40 -0500
Message-ID: 
From: "Spencer Dawkins" 
To: "Gonzalo Camarillo" 
References: 	<4B32DC9B.3040406@softarmor.com> <36D784AAD47343248BE3274F64A101ED@china.huawei.com> <4B4F3353.9010507@ericsson.com>
Date: Thu, 14 Jan 2010 09:47:16 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX19y8m85epKtnawT/FTGUEebd1tOpLGx1dy6lxA cjhUHurCulZzK+p0SPRYMbKSopwxz4gBnaC419IkKBJP5tB0Tw L7+SK7qLB1GnuQD8NDXOSnnmI9HgjdGRNybu+8d/oc=
Cc: dispatch@ietf.org, Hadriel Kaplan 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 15:48:22 -0000

Gonzalo was replying to my e-mail, listed three additional possible 
applications of session ID, and then referred to "these three topics" later 
in his e-mail. So, just to make sure the fourth of these three topics also 
stays on the radar :D

Again, speaking as SIPCLF co-chair... the following comments were extracted 
from the minutes from our Hiroshima meeting (available at 
http://www.ietf.org/proceedings/76/minutes/sipclf.htm).

I note that Adam proposed capturing before-and-after IDs if we DON'T have a 
session ID, but (speaking as an individual) that sounds like a good plan B - 
where session ID could be plan A.

Thanks,

Spencer

------------------

Laura Liess: Deutche Telecom: People use Wireshark for tracing and
analysis, troubleshooting. They need end-to-end session id. CLF is useless
without session-ID.

Daryl: Goal is a common format that can correlate, so there has to be some
identifier. Session ID is a dependency if this stuff is going to be real -
not going to be able to tell another carrier "show me your logs", but need
to troubleshoot end-to-end.

Vijay: Important to look at message as it crosses mesh, and have some sort
of global string that identifies messages.

Spencer (channeling Robert): Session ID may be important for us, but not in
scope now. We can talk about it if we find that helpful, but we can't put it
in a document _yet_.

Eric: What exists today often works for that product, but not across
multiple products, or products without CDR. There's a bunch of almost
compatible stuff that exists that may be useful (example Apache CLF).

Eric, restating for minutes: We need language on how log data is captured by
existing products in almost compatible ways. Our experience with Apache CLF
shows value in being able to correlate records across various pieces of
network equipment. Lots of open source tools have sprung up around Apache
CLF.

Daryl: For this to be useful, we need session ID. Most of these devices are
B2BUAs. Without a session ID you can only look at one system at a time. What
value is that over proprietary formats? Is this defining just CLF, or a
correlation methodology?

Vijay: Just the format.

Adam: Lots of SBCs out there, ability to correlate is absolutely necessary.
More than one way to skin the cat. One is an identifier, another is to
define the format to show before and after IDs. This is not intractable and
should not block starting the work.

Spencer: Chartering discussion allowed for inserting a session id later,
just not in scope for our work today. My previous gig was correlating SIP
calls monitored at multiple points as they moved through a network--it's a
hard problem and the heuristics sometime fail. Wants to make this a simple
problem.

Daryl: Problem does span beyond SBCs. Now more application servers are
b2buas that break signaling info.

Adam: Mean b2buas in general, not just SBCs.

> Hi,
>
> the requirement for session correlation has appeared a number of times:
>
> 1) We have Hadriel's draft.
>
> 2) We also have the following draft, which eventually led to the
> disaggregated media work:
>
> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-correlation-01.txt
>
> 3) We also have the SIP-XMPP work, which may also need to correlate
> sessions somehow.
>
> What we need to understand is whether or not the requirements for these
> different use cases are similar enough so that a single correlation
> mechanism is enough to meet all of them. If we can kill two birds (in this
> case more than two) with one stone, it would be a good thing. On the other
> hand, if the requirements are sufficiently different to be met by a single
> mechanism, then we would need more than one solution.
>
> I know there have been informal conversations about this among the
> proponents of these three topics. Let's try and conclude those discussions
> on the list so that we can make a decision on how to proceed with this.
>
> Cheers,
>
> Gonzalo
>
>
> Spencer Dawkins wrote:
>> Speaking as sipclf co-chair, I've been assured by my AD that session ID
>> is not part of what sipclf is currently chartered to do.
>>
>> I believe the "dispatching" part is for DISPATCH to say (1) this work
>> matters, and (2) the right way to proceed is $PLAN... where $PLAN could
>> be sending it to sipclf and adding it to the sipclf charter, but there
>> can also be other $PLANs.
>>
>> I'm not clear what the boundaries of what needs to be dispatched are -
>> but session ID isn't close to those boundaries!
>>
>> Spencer
>>
>>>> I'd like to have this dispatched to the appropriate WG, preferably the
>>>> SIP-CLF WG (since they're a prime customer of it).
>>> Process question: If we think it is roughly in-scope for the CLF working
>>> group, do we need to "dispatch" it? Or just ask on their list and let
>>> them decide on whether to get the AD to add it to their charter?
>>>
>>> And for what it is worth, I think we do need a session-correlator.
>>> Although I expect that somebody's SBC will remove it just for fun...
>>>
>>> --
>>> Dean
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>

From L.Liess@telekom.de  Thu Jan 14 08:28:11 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948A33A67A3 for ; Thu, 14 Jan 2010 08:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVgSzI0zZRPl for ; Thu, 14 Jan 2010 08:28:10 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id DBDD33A6905 for ; Thu, 14 Jan 2010 08:28:09 -0800 (PST)
Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 14 Jan 2010 17:28:01 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 17:28: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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Jan 2010 17:28:00 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003DD5ED9@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <4B4F3353.9010507@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqVK2obp2qEgZRRTk2mHMFrZLxxlwABKrVg
References: 	<4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com> <4B4F3353.9010507@ericsson.com>
From: 
To: , 
X-OriginalArrivalTime: 14 Jan 2010 16:28:00.0707 (UTC) FILETIME=[89DAC930:01CA9536]
Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, HKaplan@acmepacket.com
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 16:28:11 -0000

Gonzalo,

My personal opinion is, that the Session-ID draft and the =
dialog-correlation draft cover quite different use cases. Session-ID is =
used for traffic monitoring and is needed to correlate the legs of the =
same e2e session across B2BUAs. The dialog-correlation is used to =
logically correlate two e2e sessions. I think we should not mix them and =
use different identifiers.=20

One comment on the dialog-correlation draft:=20
If I understood the draft corectly, the "Same-Session"-Header contains =
the Call-ID and implicitly the ED IP-address. In most cases, SBCs drop =
or change anything which contains the ED IP-address. Session-ID uses the =
hashed Call-ID to be able to cross SBCs.  =20

Kind regards
Laura

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> Sent: Thursday, January 14, 2010 4:08 PM
> To: Spencer Dawkins
> Cc: dispatch@ietf.org; Hadriel Kaplan
> Subject: Re: [dispatch] FW:=20
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>=20
> Hi,
>=20
> the requirement for session correlation has appeared a number=20
> of times:
>=20
> 1) We have Hadriel's draft.
>=20
> 2) We also have the following draft, which eventually led to the=20
> disaggregated media work:
>=20
> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog
> -correlation-01.txt
>=20
> 3) We also have the SIP-XMPP work, which may also need to correlate=20
> sessions somehow.
>=20
> What we need to understand is whether or not the requirements=20
> for these=20
> different use cases are similar enough so that a single correlation=20
> mechanism is enough to meet all of them. If we can kill two birds (in=20
> this case more than two) with one stone, it would be a good thing. On=20
> the other hand, if the requirements are sufficiently=20
> different to be met=20
> by a single mechanism, then we would need more than one solution.
>=20
> I know there have been informal conversations about this among the=20
> proponents of these three topics. Let's try and conclude those=20
> discussions on the list so that we can make a decision on how=20
> to proceed=20
> with this.
>=20
> Cheers,
>=20
> Gonzalo
>=20
>=20
> Spencer Dawkins wrote:
> > Speaking as sipclf co-chair, I've been assured by my AD=20
> that session ID is=20
> > not part of what sipclf is currently chartered to do.
> >=20
> > I believe the "dispatching" part is for DISPATCH to say (1)=20
> this work=20
> > matters, and (2) the right way to proceed is $PLAN... where=20
> $PLAN could be=20
> > sending it to sipclf and adding it to the sipclf charter,=20
> but there can also=20
> > be other $PLANs.
> >=20
> > I'm not clear what the boundaries of what needs to be=20
> dispatched are - but=20
> > session ID isn't close to those boundaries!
> >=20
> > Spencer
> >=20
> >>> I'd like to have this dispatched to the appropriate WG,=20
> preferably the=20
> >>> SIP-CLF WG (since they're a prime customer of it).
> >> Process question: If we think it is roughly in-scope for=20
> the CLF working=20
> >> group, do we need to "dispatch" it? Or just ask on their=20
> list and let them=20
> >> decide on whether to get the AD to add it to their charter?
> >>
> >> And for what it is worth, I think we do need a session-correlator.=20
> >> Although I expect that somebody's SBC will remove it just=20
> for fun...
> >>
> >> --
> >> Dean
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch=20
> >=20
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From HKaplan@acmepacket.com  Thu Jan 14 08:55:29 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503E33A67D6 for ; Thu, 14 Jan 2010 08:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVG4ZhbjxGKN for ; Thu, 14 Jan 2010 08:55:28 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 385563A6405 for ; Thu, 14 Jan 2010 08:55:28 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 14 Jan 2010 11:55:21 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 14 Jan 2010 11:55:21 -0500
From: Hadriel Kaplan 
To: Gonzalo Camarillo , Spencer Dawkins 
Date: Thu, 14 Jan 2010 11:55:19 -0500
Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqVK2zByx0wUKjQRz+ZDHm3u4nKrQADSDaA
Message-ID: 
References:  <4B32DC9B.3040406@softarmor.com> <36D784AAD47343248BE3274F64A101ED@china.huawei.com> <4B4F3353.9010507@ericsson.com>
In-Reply-To: <4B4F3353.9010507@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2010 16:55:29 -0000

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Thursday, January 14, 2010 10:08 AM
> To: Spencer Dawkins
> Cc: Dean Willis; Hadriel Kaplan; dispatch@ietf.org
> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-
> 00.txt
>=20
> Hi,
>=20
> the requirement for session correlation has appeared a number of times:
>=20
> 1) We have Hadriel's draft.
>=20
> 2) We also have the following draft, which eventually led to the
> disaggregated media work:
>=20
> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-
> correlation-01.txt

I think those two are very different, with different requirements.
The session-id concept is to provide an identifier which stays untouched/un=
modified through any number of b2bua's, 3pcc controllers, whatever.  In oth=
er words both the UAC and UAS side of a b2bua need to use the same session-=
id value.  And it needs to do it in the initial messages of the initial dia=
log, not some later INVITE. =20

The same can't be said of a same-session header value - it identifies a spe=
cific "side" of the b2bua, by identifying the specific callid+tags. =20

I guess one question is if same-session could use a session-id kind of valu=
e instead of callid+tags.  For example, does it *need* to identify a specif=
ic side of a b2bua - if it goes to a b2bua which handled the initial dialog=
 this same-session is referring to, how does the b2bua know which dialog "h=
alf" of its b2bua function the same-session is referring to?  Does it matte=
r?

-hadriel

From pkyzivat@cisco.com  Thu Jan 14 16:43:17 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084C13A6836 for ; Thu, 14 Jan 2010 16:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.388
X-Spam-Level: 
X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNoZ8IDjkL46 for ; Thu, 14 Jan 2010 16:43:16 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 160073A6878 for ; Thu, 14 Jan 2010 16:43:16 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAKdIT0urRN+J/2dsb2JhbADDOZUGhDAE
X-IronPort-AV: E=Sophos;i="4.49,278,1262563200"; d="scan'208";a="74593348"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Jan 2010 00:39:07 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0F0d7rc003741; Fri, 15 Jan 2010 00:39:07 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 18:39:07 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 18:39:07 -0600
Message-ID: <4B4FB92A.4040701@cisco.com>
Date: Thu, 14 Jan 2010 19:39:06 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <4B4F2403.7010200@ericsson.com>
In-Reply-To: <4B4F2403.7010200@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 00:39:07.0509 (UTC) FILETIME=[256FF250:01CA957B]
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requested on	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 00:43:17 -0000

I've provided comments on earlier versions of this document.
Most of my concerns expressed before remain with this version.
I can post them again if desired. (I think they may have been private 
rather than on the list before.)

My main concern with this document is that it seems to have been 
designed for a very specific architecture (based on IMS I presume),
yet the applicability statement doesn't make that clear. The 
applicability statement says:

    The event package defined in this document is intended for use with
    network-based application servers that provide a CDIV service

(where CDIV is then defined as "CDIV: Communication Diversion".) This 
seems pretty generic (*a* CDIV service, not *the IMS* CDIV service), 
such as might be within the scope of the BLISS WG. But in fact, as one 
reads the details, it becomes apparent that a very specific architecture 
is being addressed. Yet that architecture is never spelled out.

The document never specifies what URL the subscriber is to use in the 
subscription request, or how it relates to the URLs for which the 
subscriber wishes diversion information. The subscribe request contains 
a body, acting as a filter, that selects the URLs for which diversion 
information is requested. That implies to me that the subscription is 
not addressed to the URL for which diversion information is requested. 
That is part of my concern about the unstated architecture.

Beyond that, the design is not to my taste. But that need not be 
relevant if it is to the taste of those concerned with the scope of 
applicability.

So, IMO this doc should not be published by the IETF unless its 
applicability is scoped to the garden in which its unstated architecture 
holds, or else the architecture for which it applies is thoroughly 
specified.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> Hi,
> 
> we would like to ask for comments on the following draft. Do you find it 
> useful? Do you think it should be published as an RFC?
> 
> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-02 
> 
> 
> Based on the comments received, we will talk to our ADs about this piece 
> of work.
> 
> Thanks,
> 
> Gonzalo
> DISPATCH co-chair
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From dean.willis@softarmor.com  Thu Jan 14 17:28:03 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F773A6A15 for ; Thu, 14 Jan 2010 17:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f3znCilkPHA for ; Thu, 14 Jan 2010 17:28:03 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2448B3A6A1C for ; Thu, 14 Jan 2010 17:28:03 -0800 (PST)
Received: from [10.58.96.138] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0F1RlNk016506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jan 2010 19:27:51 -0600
Message-ID: <4B4FC48D.9090505@softarmor.com>
Date: Thu, 14 Jan 2010 19:27:41 -0600
From: Dean Willis 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <4B4F2403.7010200@ericsson.com>
In-Reply-To: <4B4F2403.7010200@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requested on	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 01:28:04 -0000

Gonzalo Camarillo wrote:
> Hi,
>
> we would like to ask for comments on the following draft. Do you find
> it useful? Do you think it should be published as an RFC?
Looks mostly harmless. Of course, I said that about presidential
candidate George W. Bush too, so what do I know?

I'm not sure I would find it useful. I'm still facing challenges getting
basic  security working with SIP service providers. I find it less than
likely that something with this level of complexity will be widely
implemented. On the other hand, having the specification published isn't
likely to negatively impact anything in the real world either.

--
dean

From gonzalo.camarillo@ericsson.com  Thu Jan 14 23:39:43 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174BE3A6917 for ; Thu, 14 Jan 2010 23:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.162
X-Spam-Level: 
X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ8UtonEkRC5 for ; Thu, 14 Jan 2010 23:39:42 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 22E0B3A68FE for ; Thu, 14 Jan 2010 23:39:41 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-c6-4b501bb9836a
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BF.CD.04178.9BB105B4; Fri, 15 Jan 2010 08:39:37 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:39:37 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:39:37 +0100
Message-ID: <4B501BB8.5090702@ericsson.com>
Date: Fri, 15 Jan 2010 09:39:36 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Paul Kyzivat 
References: <4B4F2403.7010200@ericsson.com> <4B4FB92A.4040701@cisco.com>
In-Reply-To: <4B4FB92A.4040701@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 07:39:37.0105 (UTC) FILETIME=[E372C810:01CA95B5]
X-Brightmail-Tracker: AAAAAA==
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requested on	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 07:39:43 -0000

Hi Paul,

> I've provided comments on earlier versions of this document.
> Most of my concerns expressed before remain with this version.
> I can post them again if desired. (I think they may have been private 
> rather than on the list before.)

if you could post them again, that would be great. In that way, we would 
have all possible information when making a decision.

Thanks,

Gonzalo

From gonzalo.camarillo@ericsson.com  Fri Jan 15 00:21:52 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AF03A692A for ; Fri, 15 Jan 2010 00:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.825
X-Spam-Level: 
X-Spam-Status: No, score=-105.825 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpEGtuivywVX for ; Fri, 15 Jan 2010 00:21:50 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8A1C13A686E for ; Fri, 15 Jan 2010 00:21:50 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-59-4b50259a7f9b
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CD.48.04178.A95205B4; Fri, 15 Jan 2010 09:21:46 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 09:21:45 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 09:21:45 +0100
Message-ID: <4B502599.2070404@ericsson.com>
Date: Fri, 15 Jan 2010 10:21:45 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Hadriel Kaplan 
References: 	<4B32DC9B.3040406@softarmor.com> <36D784AAD47343248BE3274F64A101ED@china.huawei.com> <4B4F3353.9010507@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 08:21:45.0686 (UTC) FILETIME=[C6999F60:01CA95BB]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 08:21:52 -0000

Hi,

thanks Spencer for pointing to yet another use cases where something 
like this is needed.

Answering to Hadriel and Laura, I know the approaches the drafts take to 
meet their particular requirements are different. What I am asking 
people is to step back and think whether or not the requirements are 
similar.

In all the use cases we have so far we need to correlate several 
sessions that terminate/originate in an entity. The differences are that 
in some use cases we are dealing with two sessions while in others we 
may have more than two. In some use cases all sessions are SIP while in 
others other protocols may be used (e.g., XMPP). In some use cases the 
correlation information tells the entity how the correlation needs to be 
performed. In others, the entity performs the session correlation and 
provides this information to other parties... etc.

This is the type of analysis I would like folks to think about. Let's 
focus on requirements instead of technical solutions at this point. If 
after such an analysis the WG decides that the requirements are 
sufficiently different, we can develop several mechanisms. If the 
requirements are sufficiently similar, we may be able to cover several 
use cases with a single mechanism.

Cheers,

Gonzalo

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Thursday, January 14, 2010 10:08 AM
>> To: Spencer Dawkins
>> Cc: Dean Willis; Hadriel Kaplan; dispatch@ietf.org
>> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-
>> 00.txt
>>
>> Hi,
>>
>> the requirement for session correlation has appeared a number of times:
>>
>> 1) We have Hadriel's draft.
>>
>> 2) We also have the following draft, which eventually led to the
>> disaggregated media work:
>>
>> http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-
>> correlation-01.txt
> 
> I think those two are very different, with different requirements.
> The session-id concept is to provide an identifier which stays untouched/unmodified through any number of b2bua's, 3pcc controllers, whatever.  In other words both the UAC and UAS side of a b2bua need to use the same session-id value.  And it needs to do it in the initial messages of the initial dialog, not some later INVITE.  
> 
> The same can't be said of a same-session header value - it identifies a specific "side" of the b2bua, by identifying the specific callid+tags.  
> 
> I guess one question is if same-session could use a session-id kind of value instead of callid+tags.  For example, does it *need* to identify a specific side of a b2bua - if it goes to a b2bua which handled the initial dialog this same-session is referring to, how does the b2bua know which dialog "half" of its b2bua function the same-session is referring to?  Does it matter?
> 
> -hadriel

From ranjit@motorola.com  Fri Jan 15 00:43:06 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC1B3A67A6 for ; Fri, 15 Jan 2010 00:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwl-psqexD05 for ; Fri, 15 Jan 2010 00:43:04 -0800 (PST)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id B74B63A689C for ; Fri, 15 Jan 2010 00:42:55 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-6.tower-55.messagelabs.com!1263544971!18234174!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 3703 invoked from network); 15 Jan 2010 08:42:51 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 08:42:51 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0F8gobu004644 for ; Fri, 15 Jan 2010 01:42:50 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o0F8go0S020466 for ; Fri, 15 Jan 2010 02:42:50 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o0F8gmpU020456 for ; Fri, 15 Jan 2010 02:42:49 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA95BE.AA5B5716"
Date: Fri, 15 Jan 2010 16:42:25 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2456D6@ZMY16EXM66.ds.mot.com>
In-Reply-To: <4B501BB8.5090702@ericsson.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
thread-index: AcqVtetqGRg42C1rTkuco0pnHrR59AABuwjA
References: <4B4F2403.7010200@ericsson.com> <4B4FB92A.4040701@cisco.com> <4B501BB8.5090702@ericsson.com>
From: "Avasarala Ranjit-A20990" 
To: "Gonzalo Camarillo" , "Paul Kyzivat" 
X-CFilter-Loop: Reflected
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 08:43:06 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA95BE.AA5B5716
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CA95BE.AA5B5716"

------_=_NextPart_002_01CA95BE.AA5B5716
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Gonzalo

To give a brief,

This I-D defines a new SIP event package on lines of RFC 3265 for the =
Communication Diversion notification information (CDIV) that is defined =
in 3GPP TS 24.504 and 3GPP TS 24.604.=20

So the applicability of the event package would be for conveying the =
CDIV Notification Information by the Notifies (which could be =
Application Servers in IMS) to the subscriber UEs (UAC in SIP =
terminology). Now this could be re-worded as

"The event package defined in this document is intended for use with SIP =
based network servers that provide CDIV service." to make it more =
general.

Below are Paul's initial comments on this I-D

John-Luc,

This sounds like a useful capability. Based on a quick scan, this =
proposal seems off to a good start.

For some of us that aren't actively involved with 3gpp, the references =
to 3gpp documents are somewhat inconvenient. Of particular note, I would

like to see the xml schema for application/comm-div-info+xml included in

this draft.

I'm also a bit confused, because you call for the same doc format to be =
used in both subscriptions and notifications. That at least seems odd, =
though perhaps it will become clear when I see the actual schema. Since =
it will perform a different role in these differing cases, it would be =
helpful if you could explain more about that.

Also I found the references to "user" somewhat ambiguous. I see a =
definition of Diverting User, and a note that "user" when not qualified =
should mean Diverting User. But I then also see "user" used in contexts =
discussing the subscriber.

For SUBSCRIBE, the R-URI identifies the "resource" to which a =
subscription is addressed. I would hope to see a very clear relationship

spelled out between the subscription resource and the processing of =
requests that are "diverted". My assumption is that "diversion" is =
performed with respect to a particular R-URI in an INVITE request, and =
that to be notified of such a diversion one would need be subscribed to =
this event package addressed to the same URI. If that is so, it should =
be spelled out. And if that isn't quite what you mean then its even more

important to spell out what you do mean.

    Thanks,
    Paul

The above comments are addressed in -02 version of the I-D.=20

More comments welcome

Thanks
Ranjit

  =20

Regards
Ranjit

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Gonzalo Camarillo
Sent: Friday, January 15, 2010 1:10 PM
To: Paul Kyzivat
Cc: DISPATCH
Subject: Re: [dispatch] Comments requestedon =
draft-avasarala-dispatch-comm-div-notification

Hi Paul,

> I've provided comments on earlier versions of this document.
> Most of my concerns expressed before remain with this version.
> I can post them again if desired. (I think they may have been private=20
> rather than on the list before.)
 o
if you could post them again, that would be great. In that way, we would =
have all possible information when making a decision.

Thanks,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch <>=20

------_=_NextPart_002_01CA95BE.AA5B5716
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [dispatch] Comments requestedon	=
draft-avasarala-dispatch-comm-div-notification

Hi Gonzalo

To give a brief,

This I-D defines a new SIP event package on lines of RFC =
3265 for the Communication Diversion notification information (CDIV) =
that is defined in 3GPP TS 24.504 and 3GPP TS 24.604. 

So the applicability of the event package would be for =
conveying the CDIV Notification Information by the Notifies (which could =
be Application Servers in IMS) to the subscriber UEs (UAC in SIP =
terminology). Now this could be re-worded as

"The event package defined in this document is =
intended for use with SIP based network servers that provide CDIV =
service." to make it more general.

Below are Paul's initial comments on this =
I-D

John-Luc,

This sounds like a =
useful capability. Based on a quick scan, this proposal seems off to a =
good start.

For some of us =
that aren't actively involved with 3gpp, the references to 3gpp =
documents are somewhat inconvenient. Of particular note, I =
would

like to see the =
xml schema for application/comm-div-info+xml included in

this =
draft.

I'm also a bit =
confused, because you call for the same doc format to be used in both =
subscriptions and notifications. That at least seems odd, though perhaps =
it will become clear when I see the actual schema. Since it will perform =
a different role in these differing cases, it would be helpful if you =
could explain more about that.

Also I found the =
references to "user" somewhat ambiguous. I see a definition of =
Diverting User, and a note that "user" when not qualified =
should mean Diverting User. But I then also see "user" used in =
contexts discussing the subscriber.

For SUBSCRIBE, the =
R-URI identifies the "resource" to which a subscription is =
addressed. I would hope to see a very clear =
relationship

spelled out =
between the subscription resource and the processing of requests that =
are "diverted". My assumption is that "diversion" is =
performed with respect to a particular R-URI in an INVITE request, and =
that to be notified of such a diversion one would need be subscribed to =
this event package addressed to the same URI. If that is so, it should =
be spelled out. And if that isn't quite what you mean then its even =
more

important to spell =
out what you do mean.

=A0=A0=A0 =
Thanks,

=A0=A0=A0 =
Paul

The above comments are addressed in -02 version of the =
I-D. 

More comments welcome

Thanks

Ranjit

Regards

Ranjit

-----Original Message-----

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Gonzalo Camarillo

Sent: Friday, January 15, 2010 1:10 PM

To: Paul Kyzivat

Cc: DISPATCH

Subject: Re: [dispatch] Comments requestedon =
draft-avasarala-dispatch-comm-div-notification

Hi Paul,

> I've provided comments on earlier versions of this =
document.

> Most of my concerns expressed before remain with =
this version.

> I can post them again if desired. (I think they may =
have been private 

> rather than on the list before.)

 o

if you could post them again, that would be great. In =
that way, we would have all possible information when making a =
decision.

Thanks,

Gonzalo

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch<=
/SPAN> <<FW: [dispatch] comm-div-notification event =
package update>> 

------_=_NextPart_002_01CA95BE.AA5B5716--

------_=_NextPart_001_01CA95BE.AA5B5716
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_003_01CA95BE.13ADD85B"
Subject: FW: [dispatch] comm-div-notification event package update
Date: Fri, 15 Jan 2010 16:38:13 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2456D4@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] comm-div-notification event package update
thread-index: AcoOgUwf5wfZ0tb7Q7yrMpJ6vlxjZyHPKn4g
From: "Avasarala Ranjit-A20990" 
To: 

This is a multi-part message in MIME format.

------_=_NextPart_003_01CA95BE.13ADD85B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Thursday, June 04, 2009 10:24 AM
To: John-Luc Bakker
Cc: dispatch@ietf.org
Subject: Re: [dispatch] comm-div-notification event package update

John-Luc,

This sounds like a useful capability. Based on a quick scan, this =
proposal seems off to a good start.

For some of us that aren't actively involved with 3gpp, the references =
to 3gpp documents are somewhat inconvenient. Of particular note, I would

like to see the xml schema for application/comm-div-info+xml included in

this draft.

I'm also a bit confused, because you call for the same doc format to be =
used in both subscriptions and notifications. That at least seems odd, =
though perhaps it will become clear when I see the actual schema. Since =
it will perform a different role in these differing cases, it would be =
helpful if you could explain more about that.

Also I found the references to "user" somewhat ambiguous. I see a =
definition of Diverting User, and a note that "user" when not qualified =
should mean Diverting User. But I then also see "user" used in contexts =
discussing the subscriber.

For SUBSCRIBE, the R-URI identifies the "resource" to which a =
subscription is addressed. I would hope to see a very clear relationship

spelled out between the subscription resource and the processing of =
requests that are "diverted". My assumption is that "diversion" is =
performed with respect to a particular R-URI in an INVITE request, and =
that to be notified of such a diversion one would need be subscribed to =
this event package addressed to the same URI. If that is so, it should =
be spelled out. And if that isn't quite what you mean then its even more

important to spell out what you do mean.

=A0=A0=A0 Thanks,
=A0=A0=A0 Paul

John-Luc Bakker wrote:
> Hi,
>
> We have submitted a draft which proposes registration of an event=20
> package, based on work ongoing in 3GPP (and TISPAN).
>
> (The most likely protocol output is going to be a new event package).
>
> The document can also be found in:
>
>
http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch-comm-di
v-notification-00.txt
>
> Updates since last version:
>
>=A0 =A0 Changes from draft-avasarala-sipping-comm-div-notification-01
>
>
>
>=A0 =A0 o=A0 Changed contact details for co-author Subir Saha
>
>
>
>=A0 =A0 o=A0 Moved from SIPPING to DISPATCH WG
>
> Regards,
>
> John-Luc
>
>
>
>
>
> ---
> John-Luc Bakker
> Standards Manager
> Research In Motion
> BlackBerry: +1 (908) 463 7321
> Office: +1 (972) 373-1761
> Internal: (820) 63761
> E-mail: jbakker@rim.com
>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential

> information, privileged material (including material protected by the=20
> solicitor-client or other applicable privileges), or constitute=20
> non-public information. Any use of this information by anyone other
than
> the intended recipient is prohibited. If you have received this=20
> transmission in error, please immediately reply to the sender and
delete
> this information from your system. Use, dissemination, distribution,
or
> reproduction of this transmission by unintended recipients is not=20
> authorized and may be unlawful.
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.

      See the Web's breaking stories, chosen by people like you. =
Check out Yahoo! Buzz. http://in.buzz.yahoo.com/

------_=_NextPart_003_01CA95BE.13ADD85B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FW: [dispatch] comm-div-notification event package update

-----Original Message-----

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

Sent: Thursday, June 04, 2009 10:24 AM

To: John-Luc Bakker

Cc: dispatch@ietf.org

Subject: Re: [dispatch] comm-div-notification event =
package update

John-Luc,

This sounds like a useful capability. Based on a quick =
scan, this proposal seems off to a good start.

For some of us that aren't actively involved with =
3gpp, the references to 3gpp documents are somewhat inconvenient. Of =
particular note, I would

like to see the xml schema for =
application/comm-div-info+xml included in

this draft.

I'm also a bit confused, because you call for the same =
doc format to be used in both subscriptions and notifications. That at =
least seems odd, though perhaps it will become clear when I see the =
actual schema. Since it will perform a different role in these differing =
cases, it would be helpful if you could explain more about =
that.

Also I found the references to "user" =
somewhat ambiguous. I see a definition of Diverting User, and a note =
that "user" when not qualified should mean Diverting User. But =
I then also see "user" used in contexts discussing the =
subscriber.

For SUBSCRIBE, the R-URI identifies the =
"resource" to which a subscription is addressed. I would hope =
to see a very clear relationship

spelled out between the subscription resource and the =
processing of requests that are "diverted". My assumption is =
that "diversion" is performed with respect to a particular =
R-URI in an INVITE request, and that to be notified of such a diversion =
one would need be subscribed to this event package addressed to the same =
URI. If that is so, it should be spelled out. And if that isn't quite =
what you mean then its even more

important to spell out what you do mean.

=A0=A0=A0 Thanks,

=A0=A0=A0 Paul

John-Luc Bakker wrote:

> Hi,

>

> We have submitted a draft which proposes =
registration of an event 

> package, based on work ongoing in 3GPP (and =
TISPAN).

>

> (The most likely protocol output is going to be =
a new event package).

>

> The document can also be found in:

>

>

http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch=
-comm-di

v-notification-00.txt

>

> Updates since last version:

>

>=A0 =A0 Changes from =
draft-avasarala-sipping-comm-div-notification-01

>

>

>

>=A0 =A0 o=A0 Changed contact details for =
co-author Subir Saha

>

>

>

>=A0 =A0 o=A0 Moved from SIPPING to DISPATCH =
WG

>

> Regards,

>

> John-Luc

>

>

>

>

>

> ---

> John-Luc Bakker

> Standards Manager

> Research In Motion

> BlackBerry: +1 (908) 463 7321

> Office: +1 (972) 373-1761

> Internal: (820) 63761

> E-mail: jbakker@rim.com

>

>

>

> =
---------------------------------------------------------------------

> This transmission (including any attachments) =
may contain confidential

> information, privileged material (including =
material protected by the 

> solicitor-client or other applicable =
privileges), or constitute 

> non-public information. Any use of this =
information by anyone other

than

> the intended recipient is prohibited. If you =
have received this 

> transmission in error, please immediately reply =
to the sender and

delete

> this information from your system. Use, =
dissemination, distribution,

or

> reproduction of this transmission by unintended =
recipients is not 

> authorized and may be unlawful.

>

>

>

----------------------------------------------------------------=
--------

>

> =
_______________________________________________

> dispatch mailing list

> dispatch@ietf.org

> https://www.ietf.=
org/mailman/listinfo/dispatch

----------------------------------------------------------------=
-----

This transmission (including any attachments) may =
contain confidential information, privileged material (including =
material protected by the solicitor-client or other applicable =
privileges), or constitute non-public information. Any use of this =
information by anyone other than the intended recipient is prohibited. =
If you have received this transmission in error, please immediately =
reply to the sender and delete this information from your system. Use, =
dissemination, distribution, or reproduction of this transmission by =
unintended recipients is not authorized and may be unlawful.

----------------------------------------------------------------=
-----

This transmission (including any attachments) may =
contain confidential information, privileged material (including =
material protected by the solicitor-client or other applicable =
privileges), or constitute non-public information. Any use of this =
information by anyone other than the intended recipient is prohibited. =
If you have received this transmission in error, please immediately =
reply to the sender and delete this information from your system. Use, =
dissemination, distribution, or reproduction of this transmission by =
unintended recipients is not authorized and may be unlawful.

      See the Web&#39;s =
breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/

------_=_NextPart_003_01CA95BE.13ADD85B--

------_=_NextPart_001_01CA95BE.AA5B5716--

From john.elwell@siemens-enterprise.com  Fri Jan 15 01:27:33 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204173A6951 for ; Fri, 15 Jan 2010 01:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7lclOled9wC for ; Fri, 15 Jan 2010 01:27:32 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EF0053A693A for ; Fri, 15 Jan 2010 01:27:31 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-549527; Fri, 15 Jan 2010 10:27:28 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id DE24423F028E; Fri, 15 Jan 2010 10:27:27 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 15 Jan 2010 10:27:27 +0100
From: "Elwell, John" 
To: Gonzalo Camarillo , DISPATCH 
Date: Fri, 15 Jan 2010 10:27:26 +0100
Thread-Topic: [dispatch] Comments requested on draft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqVIkQP17cwxJWzT5ugzjq4oZuHfwAn9g5g
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>
In-Reply-To: <4B4F2403.7010200@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Comments requested on	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 09:27:33 -0000

I reserve judgement on how useful this would be. Concerning comments from P=
aul, I could imagine that the SUBSCRIBE request is addressed to the AOR URI=
 for which notifications of diverted inbound requests are required, and tha=
t information from that AOR's domain proxy would be used as the basis for n=
otifications. So the notifier would need somehow to be coupled to the domai=
n proxy. This could certainly do with clarification.

It is unclear to me how one would handle a subscription in the following ci=
rcumstances. The subscription is to alice@example.com. At any given time, t=
here might be several contacts registered against alice@example.com. Accord=
ing to relative priorities of those contacts, scripting rules at the proxy,=
 caller preferences, etc., a given inbound request to Alice would go to one=
 or more of those contacts. Is it the intention that those contacts that do=
 not receive that inbound request would receive a notification within the c=
ontext of this event package? So if Alice's deskphone is one contact and he=
r cellphone is another contact, if her current rules are for calls to go to=
 her cellphone, her deskphone would receive notifications, and vice versa?

Or is that out of scope? Is the intention to limit the scope to cases where=
 an inbound communication is diverted away from the AOR concerned?

John

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> Sent: 14 January 2010 14:03
> To: DISPATCH
> Subject: [dispatch] Comments requested on=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> Hi,
>=20
> we would like to ask for comments on the following draft. Do=20
> you find it=20
> useful? Do you think it should be published as an RFC?
>=20
> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
> otification-02
>=20
> Based on the comments received, we will talk to our ADs about=20
> this piece=20
> of work.
>=20
> Thanks,
>=20
> Gonzalo
> DISPATCH co-chair
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From ranjit@motorola.com  Fri Jan 15 01:50:27 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE7E3A682A for ; Fri, 15 Jan 2010 01:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itIgX2bSXmHd for ; Fri, 15 Jan 2010 01:50:26 -0800 (PST)
Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id EB5A03A6816 for ; Fri, 15 Jan 2010 01:50:25 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-12.tower-153.messagelabs.com!1263549021!20431898!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 25731 invoked from network); 15 Jan 2010 09:50:22 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 09:50:22 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0F9oLer015660 for ; Fri, 15 Jan 2010 02:50:21 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o0F9oL0e006861 for ; Fri, 15 Jan 2010 03:50:21 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o0F9oJmc006854 for ; Fri, 15 Jan 2010 03:50:20 -0600 (CST)
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: Fri, 15 Jan 2010 17:49:56 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
thread-index: AcqVIkQP17cwxJWzT5ugzjq4oZuHfwAn9g5gAADwvNA=
References: <4B4F2403.7010200@ericsson.com> 
From: "Avasarala Ranjit-A20990" 
To: "Elwell, John" , "Gonzalo Camarillo" , "DISPATCH" 
X-CFilter-Loop: Reflected
Subject: Re: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 09:50:27 -0000

Hi John

Yes the notifications are generated for the AoR (contact) for which the
diversion has occurred.=20

So even though there could be multiple contacts registered for a
particular AoR, if the diversion has occurred for a particular contact
say alice at cellphone, then the notification information would go only
to her cellphone and not to all registered contacts.  This way we would
be limiting the number of notifications that are sent.

In current call diversion service configurations, there is no concept of
notifying subscribers when a particular call gets diverted based on a
particular rule.=20

Considering the case of Alice@example.com. Lets say Alice has setup a
call diversion rule for her cellphone to divert all calls from a
particular caller between 9 AM and 10 AM to her voicemail. But for some
reason she could have wrongly configured the rule as 9 to 10 AM or could
have put the caller id as wrong one. So it would be very difficult for
her to manually spot this error by reviewing the complete set of call
diversion services. So in order to facilitate Alice to effectively find
out the error, a notification mechanism is required.

So here th URI for subscription would be the URI that is associated with
diversion . E.g. Alice@cellhone or Alice@deskphone, etc.

Thanks

Regards
Ranjit

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Elwell, John
Sent: Friday, January 15, 2010 2:57 PM
To: Gonzalo Camarillo; DISPATCH
Subject: Re: [dispatch] Comments requestedon
draft-avasarala-dispatch-comm-div-notification

I reserve judgement on how useful this would be. Concerning comments
from Paul, I could imagine that the SUBSCRIBE request is addressed to
the AOR URI for which notifications of diverted inbound requests are
required, and that information from that AOR's domain proxy would be
used as the basis for notifications. So the notifier would need somehow
to be coupled to the domain proxy. This could certainly do with
clarification.

It is unclear to me how one would handle a subscription in the following
circumstances. The subscription is to alice@example.com. At any given
time, there might be several contacts registered against
alice@example.com. According to relative priorities of those contacts,
scripting rules at the proxy, caller preferences, etc., a given inbound
request to Alice would go to one or more of those contacts. Is it the
intention that those contacts that do not receive that inbound request
would receive a notification within the context of this event package?
So if Alice's deskphone is one contact and her cellphone is another
contact, if her current rules are for calls to go to her cellphone, her
deskphone would receive notifications, and vice versa?

Or is that out of scope? Is the intention to limit the scope to cases
where an inbound communication is diverted away from the AOR concerned?

John

> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> Sent: 14 January 2010 14:03
> To: DISPATCH
> Subject: [dispatch] Comments requested on=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> Hi,
>=20
> we would like to ask for comments on the following draft. Do you find=20
> it useful? Do you think it should be published as an RFC?
>=20
> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
> otification-02
>=20
> Based on the comments received, we will talk to our ADs about this=20
> piece of work.
>=20
> Thanks,
>=20
> Gonzalo
> DISPATCH co-chair
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From john.elwell@siemens-enterprise.com  Fri Jan 15 02:03:41 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD883A685A for ; Fri, 15 Jan 2010 02:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+Gg3Zi2amV1 for ; Fri, 15 Jan 2010 02:03:40 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 200133A682A for ; Fri, 15 Jan 2010 02:03:39 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-549855; Fri, 15 Jan 2010 11:03:35 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D523023F0278; Fri, 15 Jan 2010 11:03:35 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 15 Jan 2010 11:03:35 +0100
From: "Elwell, John" 
To: Avasarala Ranjit-A20990 , Gonzalo Camarillo , DISPATCH 
Date: Fri, 15 Jan 2010 11:03:34 +0100
Thread-Topic: [dispatch] Comments requestedon draft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqVIkQP17cwxJWzT5ugzjq4oZuHfwAn9g5gAADwvNAAAMpm4A==
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 10:03:41 -0000

Ranjit,

> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20
> Sent: 15 January 2010 09:50
> To: Elwell, John; Gonzalo Camarillo; DISPATCH
> Cc: jbakker@rim.com
> Subject: RE: [dispatch] Comments requestedon=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> Hi John
>=20
> Yes the notifications are generated for the AoR (contact) for=20
> which the
> diversion has occurred.=20
>=20
> So even though there could be multiple contacts registered for a
> particular AoR, if the diversion has occurred for a particular contact
> say alice at cellphone, then the notification information=20
> would go only
> to her cellphone and not to all registered contacts.  This=20
> way we would
> be limiting the number of notifications that are sent.
>=20
> In current call diversion service configurations, there is no=20
> concept of
> notifying subscribers when a particular call gets diverted based on a
> particular rule.=20
>=20
> Considering the case of Alice@example.com. Lets say Alice has setup a
> call diversion rule for her cellphone to divert all calls from a
> particular caller between 9 AM and 10 AM to her voicemail.=20
> But for some
> reason she could have wrongly configured the rule as 9 to 10=20
> AM or could
> have put the caller id as wrong one. So it would be very difficult for
> her to manually spot this error by reviewing the complete set of call
> diversion services. So in order to facilitate Alice to=20
> effectively find
> out the error, a notification mechanism is required.
>=20
> So here th URI for subscription would be the URI that is=20
> associated with
> diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
[JRE] This worries me. Requests initially are going to be targeted at alice=
@example.com, not alice@cellphone or alice@deskphone. The last two are the =
registered contacts for alice@example.com (I assume). I had not imagined a =
service at the domain proxy where I can divert based on particular contacts=
 - only the phones themselves would be authoritative for that, e.g., if con=
tact alice@deskphone is selected, the deskphone host would be responsible f=
or any diversion, and that would not require an event package, since the in=
formation is already at the UA.

This certainly means we need a much clearer illustration of the proposed ar=
chitecture, to ensure it is compatible with RFC 3261.

John

>=20
> Thanks
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Elwell, John
> Sent: Friday, January 15, 2010 2:57 PM
> To: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments requestedon
> draft-avasarala-dispatch-comm-div-notification
>=20
> I reserve judgement on how useful this would be. Concerning comments
> from Paul, I could imagine that the SUBSCRIBE request is addressed to
> the AOR URI for which notifications of diverted inbound requests are
> required, and that information from that AOR's domain proxy would be
> used as the basis for notifications. So the notifier would=20
> need somehow
> to be coupled to the domain proxy. This could certainly do with
> clarification.
>=20
> It is unclear to me how one would handle a subscription in=20
> the following
> circumstances. The subscription is to alice@example.com. At any given
> time, there might be several contacts registered against
> alice@example.com. According to relative priorities of those contacts,
> scripting rules at the proxy, caller preferences, etc., a=20
> given inbound
> request to Alice would go to one or more of those contacts. Is it the
> intention that those contacts that do not receive that inbound request
> would receive a notification within the context of this event package?
> So if Alice's deskphone is one contact and her cellphone is another
> contact, if her current rules are for calls to go to her=20
> cellphone, her
> deskphone would receive notifications, and vice versa?
>=20
> Or is that out of scope? Is the intention to limit the scope to cases
> where an inbound communication is diverted away from the AOR=20
> concerned?
>=20
> John
>=20
>=20
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org
> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > Sent: 14 January 2010 14:03
> > To: DISPATCH
> > Subject: [dispatch] Comments requested on=20
> > draft-avasarala-dispatch-comm-div-notification
> >=20
> > Hi,
> >=20
> > we would like to ask for comments on the following draft.=20
> Do you find=20
> > it useful? Do you think it should be published as an RFC?
> >=20
> > http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
> > otification-02
> >=20
> > Based on the comments received, we will talk to our ADs about this=20
> > piece of work.
> >=20
> > Thanks,
> >=20
> > Gonzalo
> > DISPATCH co-chair
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From gonzalo.camarillo@ericsson.com  Fri Jan 15 03:24:03 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375DA3A6960 for ; Fri, 15 Jan 2010 03:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.123
X-Spam-Level: 
X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6o0+my1j3CD for ; Fri, 15 Jan 2010 03:24:02 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E493D3A68AB for ; Fri, 15 Jan 2010 03:24:01 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-6a-4b50504df3c9
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 2F.38.04178.D40505B4; Fri, 15 Jan 2010 12:23:57 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 12:23:06 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 12:23:06 +0100
Message-ID: <4B505018.7020504@ericsson.com>
Date: Fri, 15 Jan 2010 13:23:04 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: DISPATCH 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 11:23:06.0168 (UTC) FILETIME=[1BDF6B80:01CA95D5]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 11:24:03 -0000

Folks,

as you know, we agreed to charter the SIP overload work a while ago. 
Below you can find the proposed charter.

We have gotten some comments back from the IESG. There are some concerns 
about the effects of the proposed solutions in real networks. It seems 
that those concerns would disappear if we chartered the WG to develop 
Experimental proposals, at least at the beginning. Those proposals would 
be able to eventually move to the standards track once we got 
operational experience with them. Comments?

Thanks,

Gonzalo

SIP Overload Control WG Charter
-------------------------------

As with any network element, a Session Initiation Protocol (SIP) server
can suffer from overload when the number of SIP messages it receives
exceeds the number of messages it can process. Overload is said to occur
when a SIP server does not have sufficient resources to process all
incoming SIP messages.  These resources can include CPU, memory, network
bandwidth, input/output, or disk resources.

Overload can pose a serious problem for a network of SIP servers. During
periods of overload, the throughput of a network of SIP servers can be
significantly degraded.  In fact, overload may lead to a situation in
which the throughput drops down to zero or a small fraction of the
original processing capacity.  This is often called congestion collapse.

The objective of a SIP overload control mechanism is to enable SIP
servers to operate close to their capacity limit during times of overload.

The SIP protocol provides a limited mechanism for overload control
through its 503 (Service Unavailable) response code and the Retry-After
header.  However, this mechanism cannot fully prevent overload of a SIP
server and it cannot prevent congestion collapse.  In fact, its on/off
behavior may cause traffic to oscillate and shift between SIP servers
and thereby worsen an overload condition.  A detailed discussion of the
SIP overload problem, the problems with the 503 (Service Unavailable)
response code and the Retry-After header and the requirements for a SIP
overload control mechanism can be found in RFC5390.

The objective of the proposed working group is to develop mechanisms for
SIP overload control. Two complementary approaches exist for handling
overload situations:
- The first mechanism aims at preventing overload in SIP servers by
adjusting the incoming load to a level that is acceptable for this
server. This mechanism uses implicit and/or explicit feedback to
determine when an overload condition occurs in a SIP server and a
reduction in load is required.
- The second mechanism aims at preventing overload in SIP servers by
distributing load control filters to SIP servers that throttle calls
based on their destination domain, telephone number prefix or for a
specific user. Such filters can be used, for example, to throttle calls
to a hotline during a ticket-giveaway event.

Specifically, the proposed working group will develop the following
deliverables:
1. A document describing key design considerations for a SIP overload
control mechanism.
2. A specification for an SIP overload control mechanism based on
implicit/explicit feedback.
3. A specification for a SIP load filtering mechanism.

From ranjit@motorola.com  Fri Jan 15 03:45:50 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6D43A6952 for ; Fri, 15 Jan 2010 03:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn8nYj2EmTTR for ; Fri, 15 Jan 2010 03:45:50 -0800 (PST)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id A5A163A6960 for ; Fri, 15 Jan 2010 03:45:49 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-11.tower-55.messagelabs.com!1263555945!35544404!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [136.182.1.14]
Received: (qmail 29295 invoked from network); 15 Jan 2010 11:45:45 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-11.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 11:45:45 -0000
Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id o0FBjjk6024435 for ; Fri, 15 Jan 2010 04:45:45 -0700 (MST)
Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o0FBjjvL021041 for ; Fri, 15 Jan 2010 05:45:45 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o0FBjhq9021015 for ; Fri, 15 Jan 2010 05:45:44 -0600 (CST)
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: Fri, 15 Jan 2010 19:45:21 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqVIkQP17cwxJWzT5ugzjq4oZuHfwAn9g5gAADwvNAAAMpm4AADi91Q
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com> 
From: "Avasarala Ranjit-A20990" 
To: "Elwell, John" , "Gonzalo Camarillo" , "DISPATCH" 
X-CFilter-Loop: Reflected
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 11:45:51 -0000

Hi John

Completely agree with you. The subscribe requests will be towards the
public AoR i.e alice@example. But the diversion rules could be set for
specific registered contact Uris so that diversions for that particular
URI are notified.=20

For e.g. if a call diversion rule for Alice is something like: "If call
from Bob's cellphone comes between 9 AM and 10 AM to Alice's sell phone,
divert the call to Alice's voicemail". So now if when the call from Bob
gets diverted to Alice voicemail, notification message is sent to
Alice's cellphone.

Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20
Sent: Friday, January 15, 2010 3:34 PM
To: Avasarala Ranjit-A20990; Gonzalo Camarillo; DISPATCH
Cc: jbakker@rim.com
Subject: RE: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

Ranjit,
betwee
> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
> Sent: 15 January 2010 09:50
> To: Elwell, John; Gonzalo Camarillo; DISPATCH
> Cc: jbakker@rim.com
> Subject: RE: [dispatch] Comments requestedon=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> Hi John
>=20
> Yes the notifications are generated for the AoR (contact) for which=20
> the diversion has occurred.
>=20
> So even though there could be multiple contacts registered for a=20
> particular AoR, if the diversion has occurred for a particular contact

> say alice at cellphone, then the notification information would go=20
> only to her cellphone and not to all registered contacts.  This way we

> would be limiting the number of notifications that are sent.
>=20
> In current call diversion service configurations, there is no concept=20
> of notifying subscribers when a particular call gets diverted based on

> a particular rule.
>=20
> Considering the case of Alice@example.com. Lets say Alice has setup a=20
> call diversion rule for her cellphone to divert all calls from a=20
> particular caller between 9 AM and 10 AM to her voicemail.
> But for some
> reason she could have wrongly configured the rule as 9 to 10 AM or=20
> could have put the caller id as wrong one. So it would be very=20
> difficult for her to manually spot this error by reviewing the=20
> complete set of call diversion services. So in order to facilitate=20
> Alice to effectively find out the error, a notification mechanism is=20
> required.
>=20
> So here th URI for subscription would be the URI that is associated=20
> with diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
[JRE] This worries me. Requests initially are going to be targeted at
alice@example.com, not alice@cellphone or alice@deskphone. The last two
are the registered contacts for alice@example.com (I assume). I had not
imagined a service at the domain proxy where I can divert based on
particular contacts - only the phones themselves would be authoritative
for that, e.g., if contact alice@deskphone is selected, the deskphone
host would be responsible for any diversion, and that would not require
an event package, since the information is already at the UA.

This certainly means we need a much clearer illustration of the proposed
architecture, to ensure it is compatible with RFC 3261.

John

>=20
> Thanks
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20
> Behalf Of Elwell, John
> Sent: Friday, January 15, 2010 2:57 PM
> To: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments requestedon=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> I reserve judgement on how useful this would be. Concerning comments=20
> from Paul, I could imagine that the SUBSCRIBE request is addressed to=20
> the AOR URI for which notifications of diverted inbound requests are=20
> required, and that information from that AOR's domain proxy would be=20
> used as the basis for notifications. So the notifier would need=20
> somehow to be coupled to the domain proxy. This could certainly do=20
> with clarification.
>=20
> It is unclear to me how one would handle a subscription in the=20
> following circumstances. The subscription is to alice@example.com. At=20
> any given time, there might be several contacts registered against=20
> alice@example.com. According to relative priorities of those contacts,

> scripting rules at the proxy, caller preferences, etc., a given=20
> inbound request to Alice would go to one or more of those contacts. Is

> it the intention that those contacts that do not receive that inbound=20
> request would receive a notification within the context of this event=20
> package?
> So if Alice's deskphone is one contact and her cellphone is another=20
> contact, if her current rules are for calls to go to her cellphone,=20
> her deskphone would receive notifications, and vice versa?
>=20
> Or is that out of scope? Is the intention to limit the scope to cases=20
> where an inbound communication is diverted away from the AOR=20
> concerned?
>=20
> John
>=20
>=20
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org
> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > Sent: 14 January 2010 14:03
> > To: DISPATCH
> > Subject: [dispatch] Comments requested on=20
> > draft-avasarala-dispatch-comm-div-notification
> >=20
> > Hi,
> >=20
> > we would like to ask for comments on the following draft.=20
> Do you find
> > it useful? Do you think it should be published as an RFC?
> >=20
> > http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
> > otification-02
> >=20
> > Based on the comments received, we will talk to our ADs about this=20
> > piece of work.
> >=20
> > Thanks,
> >=20
> > Gonzalo
> > DISPATCH co-chair
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From gonzalo.camarillo@ericsson.com  Fri Jan 15 03:57:29 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FD03A67B3 for ; Fri, 15 Jan 2010 03:57:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.129
X-Spam-Level: 
X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHyoFoVh8xm5 for ; Fri, 15 Jan 2010 03:57:29 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C7AC33A6A81 for ; Fri, 15 Jan 2010 03:57:28 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-0d-4b505824af85
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 2F.F0.04178.428505B4; Fri, 15 Jan 2010 12:57:24 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 12:57:24 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 12:57:23 +0100
Message-ID: <4B505823.5070909@ericsson.com>
Date: Fri, 15 Jan 2010 13:57:23 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: DISPATCH 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 11:57:23.0989 (UTC) FILETIME=[E66DFC50:01CA95D9]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Information to provide together with your agreed-to-be-chartered proposals
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 11:57:29 -0000

Folks,

we are gaining some experience in the dispatching process. Based on that 
experience, when people send us (the DISPATCH chairs) the charter 
proposals for new working groups, we would like to ask them to send us, 
together with the charter text:

1) an acronym proposal for the group (coming up with the acronym can be 
a fun thing to do :o) ), and

2) one or two people who could act as chairs of the WG. In general, we 
are looking for people who will not be the main technical contributors 
in the newly formed WG. Note that the ADs may choose different people as 
chairs at the end of the day. However, making sure that we have people 
willing to do the administrative stuff associated with the WG proposal 
is an essential piece of information we need to have before chartering 
anything.

Thanks,

Gonzalo
DISPATCH co-chair

From john.elwell@siemens-enterprise.com  Fri Jan 15 03:59:34 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB15B3A6A83 for ; Fri, 15 Jan 2010 03:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kshdd149xmtp for ; Fri, 15 Jan 2010 03:59:33 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 627713A67B3 for ; Fri, 15 Jan 2010 03:59:33 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-551939; Fri, 15 Jan 2010 12:59:29 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7A0F223F0278; Fri, 15 Jan 2010 12:59:29 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 15 Jan 2010 12:59:29 +0100
From: "Elwell, John" 
To: Avasarala Ranjit-A20990 , Gonzalo Camarillo , DISPATCH 
Date: Fri, 15 Jan 2010 12:59:28 +0100
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqVIkQP17cwxJWzT5ugzjq4oZuHfwAn9g5gAADwvNAAAMpm4AADi91QAAB5EyA=
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 11:59:34 -0000

=20

> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20
> Sent: 15 January 2010 11:45
> To: Elwell, John; Gonzalo Camarillo; DISPATCH
> Cc: jbakker@rim.com
> Subject: RE: [dispatch] Comments=20
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Hi John
>=20
> Completely agree with you. The subscribe requests will be towards the
> public AoR i.e alice@example. But the diversion rules could be set for
> specific registered contact Uris so that diversions for that=20
> particular
> URI are notified.=20
>=20
> For e.g. if a call diversion rule for Alice is something=20
> like: "If call
> from Bob's cellphone comes between 9 AM and 10 AM to Alice's=20
> sell phone,
> divert the call to Alice's voicemail". So now if when the=20
> call from Bob
> gets diverted to Alice voicemail, notification message is sent to
> Alice's cellphone.
[JRE] This is the problem I am having. The call is originally is to Alice, =
not specifically to Alices's cellphone. We seem to have a 2-step approach h=
ere. The entity responsible for Alice determines that the appropriate conta=
ct is Alice's cellphone, and the entity responsible for Alice's cellphone t=
hen determines that it needs instead to go to Alice's voicemail. So the net=
 result is that, when a call comes in to Alice, it is determined that the c=
ontact to which it should be sent is Alice's voicemail.

So what you are proposing is that if somebody subscribes to this event pack=
age for Alice, they will be notified when any call targeted at Alice is rou=
ted to any contact of Alice, say Alice's cellphone, Alice's voicemail, Alic=
e's deskphone or Alice's homephone?

John

>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20
> Sent: Friday, January 15, 2010 3:34 PM
> To: Avasarala Ranjit-A20990; Gonzalo Camarillo; DISPATCH
> Cc: jbakker@rim.com
> Subject: RE: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Ranjit,
> betwee
> > -----Original Message-----
> > From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
> > Sent: 15 January 2010 09:50
> > To: Elwell, John; Gonzalo Camarillo; DISPATCH
> > Cc: jbakker@rim.com
> > Subject: RE: [dispatch] Comments requestedon=20
> > draft-avasarala-dispatch-comm-div-notification
> >=20
> > Hi John
> >=20
> > Yes the notifications are generated for the AoR (contact) for which=20
> > the diversion has occurred.
> >=20
> > So even though there could be multiple contacts registered for a=20
> > particular AoR, if the diversion has occurred for a=20
> particular contact
>=20
> > say alice at cellphone, then the notification information would go=20
> > only to her cellphone and not to all registered contacts. =20
> This way we
>=20
> > would be limiting the number of notifications that are sent.
> >=20
> > In current call diversion service configurations, there is=20
> no concept=20
> > of notifying subscribers when a particular call gets=20
> diverted based on
>=20
> > a particular rule.
> >=20
> > Considering the case of Alice@example.com. Lets say Alice=20
> has setup a=20
> > call diversion rule for her cellphone to divert all calls from a=20
> > particular caller between 9 AM and 10 AM to her voicemail.
> > But for some
> > reason she could have wrongly configured the rule as 9 to 10 AM or=20
> > could have put the caller id as wrong one. So it would be very=20
> > difficult for her to manually spot this error by reviewing the=20
> > complete set of call diversion services. So in order to facilitate=20
> > Alice to effectively find out the error, a notification=20
> mechanism is=20
> > required.
> >=20
> > So here th URI for subscription would be the URI that is associated=20
> > with diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
> [JRE] This worries me. Requests initially are going to be targeted at
> alice@example.com, not alice@cellphone or alice@deskphone.=20
> The last two
> are the registered contacts for alice@example.com (I assume).=20
> I had not
> imagined a service at the domain proxy where I can divert based on
> particular contacts - only the phones themselves would be=20
> authoritative
> for that, e.g., if contact alice@deskphone is selected, the deskphone
> host would be responsible for any diversion, and that would=20
> not require
> an event package, since the information is already at the UA.
>=20
> This certainly means we need a much clearer illustration of=20
> the proposed
> architecture, to ensure it is compatible with RFC 3261.
>=20
> John
>=20
> >=20
> > Thanks
> >=20
> >=20
> > Regards
> > Ranjit
> >=20
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On=20
> > Behalf Of Elwell, John
> > Sent: Friday, January 15, 2010 2:57 PM
> > To: Gonzalo Camarillo; DISPATCH
> > Subject: Re: [dispatch] Comments requestedon=20
> > draft-avasarala-dispatch-comm-div-notification
> >=20
> > I reserve judgement on how useful this would be. Concerning=20
> comments=20
> > from Paul, I could imagine that the SUBSCRIBE request is=20
> addressed to=20
> > the AOR URI for which notifications of diverted inbound=20
> requests are=20
> > required, and that information from that AOR's domain proxy=20
> would be=20
> > used as the basis for notifications. So the notifier would need=20
> > somehow to be coupled to the domain proxy. This could certainly do=20
> > with clarification.
> >=20
> > It is unclear to me how one would handle a subscription in the=20
> > following circumstances. The subscription is to=20
> alice@example.com. At=20
> > any given time, there might be several contacts registered against=20
> > alice@example.com. According to relative priorities of=20
> those contacts,
>=20
> > scripting rules at the proxy, caller preferences, etc., a given=20
> > inbound request to Alice would go to one or more of those=20
> contacts. Is
>=20
> > it the intention that those contacts that do not receive=20
> that inbound=20
> > request would receive a notification within the context of=20
> this event=20
> > package?
> > So if Alice's deskphone is one contact and her cellphone is another=20
> > contact, if her current rules are for calls to go to her cellphone,=20
> > her deskphone would receive notifications, and vice versa?
> >=20
> > Or is that out of scope? Is the intention to limit the=20
> scope to cases=20
> > where an inbound communication is diverted away from the AOR=20
> > concerned?
> >=20
> > John
> >=20
> >=20
> > > -----Original Message-----
> > > From: dispatch-bounces@ietf.org
> > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > > Sent: 14 January 2010 14:03
> > > To: DISPATCH
> > > Subject: [dispatch] Comments requested on=20
> > > draft-avasarala-dispatch-comm-div-notification
> > >=20
> > > Hi,
> > >=20
> > > we would like to ask for comments on the following draft.=20
> > Do you find
> > > it useful? Do you think it should be published as an RFC?
> > >=20
> > > http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
> > > otification-02
> > >=20
> > > Based on the comments received, we will talk to our ADs=20
> about this=20
> > > piece of work.
> > >=20
> > > Thanks,
> > >=20
> > > Gonzalo
> > > DISPATCH co-chair
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >=20
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
> =

From pkyzivat@cisco.com  Fri Jan 15 06:12:22 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95273A6AA4 for ; Fri, 15 Jan 2010 06:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.101
X-Spam-Level: 
X-Spam-Status: No, score=-10.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tukA5KkIRYx for ; Fri, 15 Jan 2010 06:12:18 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B271C3A6407 for ; Fri, 15 Jan 2010 06:12:17 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: Attached Message : None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAE0GUEurRN+J/2dsb2JhbADETYkkAQcBi0wCgikBGwEMgV0EjW8
X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="133718264"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2010 14:12:14 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0FECE3A008039; Fri, 15 Jan 2010 14:12:14 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:12:14 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:12:13 -0600
Message-ID: <4B5077BD.3070608@cisco.com>
Date: Fri, 15 Jan 2010 09:12:13 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <4B4F2403.7010200@ericsson.com> <4B4FB92A.4040701@cisco.com> <4B501BB8.5090702@ericsson.com>
In-Reply-To: <4B501BB8.5090702@ericsson.com>
Content-Type: multipart/mixed; boundary="------------080101080405010301070009"
X-OriginalArrivalTime: 15 Jan 2010 14:12:14.0027 (UTC) FILETIME=[BC77D1B0:01CA95EC]
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requested on	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 14:12:23 -0000

This is a multi-part message in MIME format.
--------------080101080405010301070009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gonzalo Camarillo wrote:
> Hi Paul,
> 
>> I've provided comments on earlier versions of this document.
>> Most of my concerns expressed before remain with this version.
>> I can post them again if desired. (I think they may have been private 
>> rather than on the list before.)
> 
> if you could post them again, that would be great. In that way, we would 
> have all possible information when making a decision.

Attached. These were comments made against a copy sent to me privately. 
I believe it was a pre-release of the -01 version. The current -02 
version isn't dramatically different.

	Thanks,
	Paul

--------------080101080405010301070009
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

X-Account-Key: account2
X-Mozilla-Keys: $label5                                                                         
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xmb-rtp-213.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 18 Jun 2009 15:48:16 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 18 Jun 2009 15:48:16 -0400
Message-ID: <4A3A9A00.9@cisco.com>
Date: Thu, 18 Jun 2009 15:48:16 -0400
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Al-Bakri Ban-QBA002 
CC: John-Luc Bakker , 
 Ranjit Avasarala 
Subject: Re: [dispatch] comm-div-notification event package update
References:  <4A27E6F5.1090707@cisco.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: pkyzivat@cisco.com
X-OriginalArrivalTime: 18 Jun 2009 19:48:16.0467 (UTC) FILETIME=[B90EC230:01C9F04D]

Ban,

I skimmed over the new version. Its better in that I now have a better 
sense of what you are trying to do. But of course, with that comes new 
questions. You were asking before posting the new version. I have quite 
a number of comments. But I think you should go ahead and post anyway, 
so others can comment as well. If you do, then I will repost these 
comments to the list. It makes no sense to do so if the doc isn't 
available to all.

One thing that is becoming more apparent now is that you have a 
particular implementation architecture in mind. It doesn't seem to be 
your intent to force use of that architecture, yet it colors the way you 
describe things, probably without you realizing it. And it is confusing 
to someone with a different conceptual model of how this might be 
implemented. I have a vague idea of what your model is, based on the IMS 
approach to things, but even so I'm not certain. It might be helpful if 
you gave an example of what you have in mind, perhaps as a non-normative 
appendix. Or else you can try to scrub the doc of any such assumptions. 
I will call out places where this was an issue for me.

I also think there are still issues around the distinction, or lack of 
one, between the subscriber and the diverting user. I think you have in 
mind that these are always the same, and word things with that 
assumption in mind. But I don't think these need always be the same. I 
can think of useful cases when they are not. So I think more care is 
needed here.

Another thing, that I mentioned before, is still hazy. That is regarding 
what the R-URI of the subscribe identifies. Is it the URI of the 
diverting user? Or is it just the URI of some server that can get access 
to information about the diverting user(s) the subscriber is interested 
in? Initially I thought it was the URI of the diverting user. But when I 
saw the description of the schema I found that a filter can select which 
diverting user(s?) are of interest. That suggests that the target of the 
subscribe is something else. This needs serious clarification. If it is 
just some server, how is the subscriber supposed to know what the URI 
is? And if multiple diverting users can be referenced by a single 
subscription, then how does the subscriber know the chosen server can 
access the complete set of users of interest?

Now some section by section comments:

Section 1:

>    In this document, We define a SIP event package that allows a SIP
>    Event Publication Agent (EPA) to be notified about communication
>    diversions enacted on their behalf.  This allows subscribers to
>    subscribe to this event package to gather this information.  When

Above is confusing to me. It isn't the EPA that is being notified is it? 
You don't otherwise use the term EPA in the document.

> 4.2.  Definitions
> 
>       Subscriber - The user who has subscribed to the Communication
>       diversion notification service and on whose behalf the
>       Communication diversions occur in the network.

Its the "and on whose behalf" that has me bothered in the above.
This implies equivalence of function that may or may not be present in 
practice.

>       Diverting User - The user who has configured a Communication.

This implies that this is a person. But I think what is of interest is 
not a person, but a URI (AOR) for which incoming calls might be diverted.

>       This could be the subsriber who has configured the Communication
>       DIversion service rules in the network.  Diversion mechanism via
>       subscription to a CDIV service.  The subscriber is the original
>       target of the incoming communication, before it is diverted to
>       another destination.  When not qualified, the term "user" or
>       "subscriber" should be referred to as the Diverting User.

The above doesn't parse correctly as an English paragraph. The second 
"sentence" is not a complete sentence.

It also doesn't make much sense to me otherwise because of the confusion 
of roles that I mentioned earlier. *Somebody* presumably configured the 
diversion rules. But we have no reason to believe that it was the 
subscriber. The subscriber is presumably identified by the From-uri of 
the subscribe. The entity that did the configuration may not even have a 
URI.

Event notification, or state change notification? Recent evolution of 
event service is to define it in terms of state change notification. But 
that doesn't work for this usage. Here we have real events. The 
occurrence of these events doesn't imply any change in state. This could 
present a problem in rate limiting.

Section 6.7:

>    In the case of a pending subscription, when final authorization is
>    determined, a NOTIFY can be sent.  If the result of the authorization
>    was success and a communication diversion is enacted on behalf of the
>    subscriber, a NOTIFY SHOULD be sent and SHOULD contain a complete
>    comm-div-info document subject to any rules specified by the
>    authorization policy that governs the subscription and to preferences
>    indicated at the time of subscription.

How is this supposed to work? Unless there is a diversion at *exactly* 
the same time that final authorization is obtained, what would the 
notification contain? Would it be the *last* diversion that occurred? 
Does that imply that the "last" diversion should be retained as state 
and returned any time a new subscription is established?

The work on 3265bis has surfaced a more refined view of what the event 
service deals with. The current thinking seems to be that the event 
notifications are really reporting on the state of some resource - 
either the complete state or the change in state since the last 
notification.

I'm not certain if your usage fits that model or not. On the surface it 
doesn't, since the events seem to be "diversions", and there is no 
permanent state of those. But perhaps the above paragraph implies that 
there *is* some retained state of diversions that can be reported on at 
a later time. And the later description of the xml schema is, I think, 
consistent with a model of retained history of diversions. But if so 
there is a lot missing to describe that.

>    Notifiers will typically detect that a communication diversion was
>    enacted on behalf of the subscriber via a "History-Info" header field
>    value, per [2] or [1], sent from an application server hosting the
>    CDIV application.

The "typically" above reflects an assumption about the architecture of 
systems that support this event package. I don't agree that this is an 
architecture that is widely used outside the IMS world. If you want to 
want to say it (and I have no problem with that), I think you need to 
expound on the architecture in which it applies. I don't think that 
would be normative material. It might be useful to have an appendix that 
discusses this architecture.

Section 6.10:

>    Comm-div-info notifiers SHOULD NOT generate notifications for a
>    single user at a rate of more than once every five seconds.

This could be clearer. How about:

    Comm-div-info notifiers SHOULD NOT generate notifications for a
    single subscription at a rate of more than once every five seconds.

Then I think you need to specify what happens when the rate of 
diversions exceeds this rate. Do you just drop any that occur too soon? 
Or do you delay them and combine with later ones in a single NOTIFY?

Section 8:

>    o  state: This attribute indicates whether the document contains the
>       full communication diversion information, or whether it contains
>       only information of those communication diversions that have
>       occured since the previous document (partial).

This is what I was referring to earlier. This seems to imply that full 
state includes a list of all diversions that have occurred. But that is 
an unbounded set. Surely you don't intend the state to include a history 
of *all* diversions. But if it is some and not all, then describing what 
it is gets harder.

>    o  entity: This attribute contains a URI that identifies the
>       subscriber whose Communication diversion information is reported
>       in the remainder of the document.

I would expect it to identify the URI for which diversions occurred. 
Saying it identifies the subscriber implies some things that probably 
should not be implied:
- an authorization rule - that subscriptions will only be
   authorized when the identity of the subscribe matches that
   of the Diverting User.

- that only the diverting user would be interested in this info.

A particular implementation may indeed have authorization rules that are 
restrictive in that way. But the design of the package shouldn't make 
such assumptions.

>    The comm-div-info element has a series of elements describing the
>    particular communication diversion or the filter criteria for
>    receiving the communication diversion information.

Now that I see the definition I remain unconvinced that it makes sense 
to use the same format for filters in subscriptions and for 
notifications. As defined there are definitely values conforming to this 
syntax that would only make sense as filters, and others that would only 
make sense as notifications. But they will be permitted in the wrong 
context - leaving issues about what should be done in such a case. It 
would be much clearer to have two different formats, one for filters to 
be supplied in a SUBSCRIBE, and another to be used in notifies. If there 
are elements that make sense in body, that can be defined and used in both.

> 8.1.1.1.1.1.  user-info
> 
>    This element gives user details like username and URI.  This element
>    has further sub-elements for describing username and user URI
> 
> 8.1.1.1.1.1.1.  User-name
> 
>    This element gives Username.  E.g "Alice".
> 
> 8.1.1.1.1.1.2.  User-URI
> 
>    This element gives User URI.  E.g "sip:Alice@domain.com".

So is the intent here that I could specify User-name of Alice, and it 
would trigger on any SIP URI that has a user part of Alice? I question 
the value of such a thing, but if you want it I guess it is ok. But then 
I think you had better specify the matching rules. Does it apply only to 
sip/sips URIs? Is it a full case-sensitive match on the user name? Is 
there punctuation that might be ignored? Or parameters in the user part 
that might be ignored? Can it apply to tel URIs as well? Should it be 
able to match phone numbers?

> 8.1.1.1.2.1.1.  start-time
> 
>    This element specifies the start time for receiving notifications.
>    Its value is expressed in YYYY:MM:DDTHH:MM:SS format.

What about timezones? Unless the subscriber knows the timezone that is 
being used there will be a mess. I think you either need to specify that 
it is always GMT/UTC that is used, or else you need to include the 
timezone in the specification.

> 8.1.1.1.3.  diverting-user-selection-criteria
> 
>    This element gives details of diverting user.  This element consists
>    of sub-elements defined for "user-info" element
>    Section 8.1.1.1.1.1.1.

Presumably this only applies to filters. This decouples the selection of 
the Diverting User from the R-URI of the subscription. In that case, 
what is the significance of the R-URI of the subscription? And how does 
one know where to subscribe that will have access to the info about the 
desired diverting user(s)?

> 8.1.1.1.5.1.  diversion-reason-info
> 
>    This element gives the actual reason for the communication diversion.
>    E.g reason codes like 3xx or Type of communication diversions like
>    CFX - CFB, CFNA, etc.

I see that this ultimately comes down to diversion-reason-info-type, 
which is an enumeration of sip response codes, and 
diversion-rule-info-type, which seems to be an unconstrained string. If 
that string is unconstrained, how does anyone know what to put? And how 
do creators of new rule types chose values that don't conflict with 
existing values.

> 8.1.1.2.1.  notification-time-selection-criteria
> 
>    This element informs the server about the time at which the
>    notification should be triggered.  This notification trigger time is
>    expressed using the element "time-range" defined in
>    Section 8.1.1.1.2.1.

How does this differ from 8.1.1.1.2.1.  time-range???

> 8.1.1.2.2.  presence-status-selection-criteria
> 
>    This element gives the presence status of the subscriber, based on
>    which the decision can be made, whether the user wishes to receive
>    notification information or not.
> 
> 8.1.1.2.2.1.  presence-selection-info
> 
>    This element gives the presence status of the subscriber as per
>    Presence event package defined in [10].

I don't understand this. Does it mean that the notifier is supposed to 
subscribe to the presence status of the subscriber, and make decisions 
about whether to send notifications as the subscriber presence state 
changes? I guess that is *possible* but why would you do that. The 
subscriber can change its own subscription as its presence status changes.

And assuming you want to do this, how does the presence-selection-info 
influence notifications? Are they sent when the presence status matches? 
Or are they suppressed when the presence status matches? And what 
constitutes a match?

> 8.1.1.2.3.  notification-buffer-interval

There is no description of this. What is it?

	Thanks for opportunity to comment,
	Paul

Al-Bakri Ban-QBA002 wrote:
> John-Luc and Paul,
> 
> Please find the updated version of this IETF draft provided by Ranjit,
> with the following updates:
> 1. Added the Comm-div-info document structure and scheme.
> 2. Incorporated Paul Kyzivat's comments on clarification of "user" and
> subscriptions.
> 
> If these changes are ok with you, we can submit the draft to the
> DISPATCH reflector.
> 
> Thank you,
> 
> Best regards,
> 
> Ban and Ranjit
> 
> 
> 
> -----Original Message-----
> From: John-Luc Bakker [mailto:jbakker@rim.com] 
> Sent: 04 June 2009 17:37
> To: Paul Kyzivat
> Cc: Al-Bakri Ban-QBA002
> Subject: RE: [dispatch] comm-div-notification event package update
> 
> Paul,
> 
> Thanks for the comments.
> I am busy finding and packing my swimsuit today to go to the beach for a
> week. :) A response shall be somewhat delayed ...
> 
> Kind regards,
> 
> 	John-Luc
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, June 04, 2009 10:24 AM
> To: John-Luc Bakker
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] comm-div-notification event package update
> 
> John-Luc,
> 
> This sounds like a useful capability. Based on a quick scan, this
> proposal seems off to a good start.
> 
> For some of us that aren't actively involved with 3gpp, the references
> to 3gpp documents are somewhat inconvenient. Of particular note, I would
> 
> like to see the xml schema for application/comm-div-info+xml included in
> 
> this draft.
> 
> I'm also a bit confused, because you call for the same doc format to be
> used in both subscriptions and notifications. That at least seems odd,
> though perhaps it will become clear when I see the actual schema. Since
> it will perform a different role in these differing cases, it would be
> helpful if you could explain more about that.
> 
> Also I found the references to "user" somewhat ambiguous. I see a
> definition of Diverting User, and a note that "user" when not qualified
> should mean Diverting User. But I then also see "user" used in contexts
> discussing the subscriber.
> 
> For SUBSCRIBE, the R-URI identifies the "resource" to which a
> subscription is addressed. I would hope to see a very clear relationship
> 
> spelled out between the subscription resource and the processing of
> requests that are "diverted". My assumption is that "diversion" is
> performed with respect to a particular R-URI in an INVITE request, and
> that to be notified of such a diversion one would need be subscribed to
> this event package addressed to the same URI. If that is so, it should
> be spelled out. And if that isn't quite what you mean then its even more
> 
> important to spell out what you do mean.
> 
> 	Thanks,
> 	Paul
> 
> John-Luc Bakker wrote:
>> Hi,
>>
>> We have submitted a draft which proposes registration of an event 
>> package, based on work ongoing in 3GPP (and TISPAN).
>>
>> (The most likely protocol output is going to be a new event package).
>>
>> The document can also be found in:
>>
>>
> http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch-comm-di
> v-notification-00.txt
>> Updates since last version:
>>
>>    Changes from draft-avasarala-sipping-comm-div-notification-01
>>
>>  
>>
>>    o  Changed contact details for co-author Subir Saha
>>
>>  
>>
>>    o  Moved from SIPPING to DISPATCH WG
>>
>> Regards,
>>
>> John-Luc
>>
>>  
>>
>>  
>>
>> ---
>> John-Luc Bakker
>> Standards Manager
>> Research In Motion
>> BlackBerry: +1 (908) 463 7321
>> Office: +1 (972) 373-1761
>> Internal: (820) 63761
>> E-mail: jbakker@rim.com
>>
>>  
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
> 
>> information, privileged material (including material protected by the 
>> solicitor-client or other applicable privileges), or constitute 
>> non-public information. Any use of this information by anyone other
> than 
>> the intended recipient is prohibited. If you have received this 
>> transmission in error, please immediately reply to the sender and
> delete 
>> this information from your system. Use, dissemination, distribution,
> or 
>> reproduction of this transmission by unintended recipients is not 
>> authorized and may be unlawful.
>>
>>
>>
> ------------------------------------------------------------------------
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> 

--------------080101080405010301070009--

From pkyzivat@cisco.com  Fri Jan 15 06:28:20 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929A43A67BE for ; Fri, 15 Jan 2010 06:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.404
X-Spam-Level: 
X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNWdMLUn0O3 for ; Fri, 15 Jan 2010 06:28:19 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5DA103A68B2 for ; Fri, 15 Jan 2010 06:28:19 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAFMKUEtAZnwM/2dsb2JhbADET5R9gjKBfwQ
X-IronPort-AV: E=Sophos;i="4.49,282,1262563200"; d="scan'208";a="80424006"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2010 14:28:15 +0000
Received: from xbh-rcd-102.cisco.com ([72.163.62.173]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0FESFcd011056; Fri, 15 Jan 2010 14:28:15 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:28:15 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 08:28:15 -0600
Message-ID: <4B507B7D.5040002@cisco.com>
Date: Fri, 15 Jan 2010 09:28:13 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Avasarala Ranjit-A20990 
References: <4B4F2403.7010200@ericsson.com>	 <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 14:28:15.0417 (UTC) FILETIME=[F9804A90:01CA95EE]
Cc: DISPATCH 
Subject: Re: [dispatch] Comments	requestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 14:28:20 -0000

Avasarala Ranjit-A20990 wrote:
> Hi John
> 
> Yes the notifications are generated for the AoR (contact) for which the
> diversion has occurred. 

John asked some follow up questions on this, and I will too.

In my experience, routing to registered contacts is not considered to be 
diversion.

This just points up the need for a much clearer explanation of the 
assumed environment in which this feature is expected to work.

	Thanks,
	Paul

> So even though there could be multiple contacts registered for a
> particular AoR, if the diversion has occurred for a particular contact
> say alice at cellphone, then the notification information would go only
> to her cellphone and not to all registered contacts.  This way we would
> be limiting the number of notifications that are sent.
> 
> In current call diversion service configurations, there is no concept of
> notifying subscribers when a particular call gets diverted based on a
> particular rule. 
> 
> Considering the case of Alice@example.com. Lets say Alice has setup a
> call diversion rule for her cellphone to divert all calls from a
> particular caller between 9 AM and 10 AM to her voicemail. But for some
> reason she could have wrongly configured the rule as 9 to 10 AM or could
> have put the caller id as wrong one. So it would be very difficult for
> her to manually spot this error by reviewing the complete set of call
> diversion services. So in order to facilitate Alice to effectively find
> out the error, a notification mechanism is required.
> 
> So here th URI for subscription would be the URI that is associated with
> diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
> 
> Thanks
> 
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Elwell, John
> Sent: Friday, January 15, 2010 2:57 PM
> To: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments requestedon
> draft-avasarala-dispatch-comm-div-notification
> 
> I reserve judgement on how useful this would be. Concerning comments
> from Paul, I could imagine that the SUBSCRIBE request is addressed to
> the AOR URI for which notifications of diverted inbound requests are
> required, and that information from that AOR's domain proxy would be
> used as the basis for notifications. So the notifier would need somehow
> to be coupled to the domain proxy. This could certainly do with
> clarification.
> 
> It is unclear to me how one would handle a subscription in the following
> circumstances. The subscription is to alice@example.com. At any given
> time, there might be several contacts registered against
> alice@example.com. According to relative priorities of those contacts,
> scripting rules at the proxy, caller preferences, etc., a given inbound
> request to Alice would go to one or more of those contacts. Is it the
> intention that those contacts that do not receive that inbound request
> would receive a notification within the context of this event package?
> So if Alice's deskphone is one contact and her cellphone is another
> contact, if her current rules are for calls to go to her cellphone, her
> deskphone would receive notifications, and vice versa?
> 
> Or is that out of scope? Is the intention to limit the scope to cases
> where an inbound communication is diverted away from the AOR concerned?
> 
> John
> 
> 
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
>> Sent: 14 January 2010 14:03
>> To: DISPATCH
>> Subject: [dispatch] Comments requested on 
>> draft-avasarala-dispatch-comm-div-notification
>>
>> Hi,
>>
>> we would like to ask for comments on the following draft. Do you find 
>> it useful? Do you think it should be published as an RFC?
>>
>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
>> otification-02
>>
>> Based on the comments received, we will talk to our ADs about this 
>> piece of work.
>>
>> Thanks,
>>
>> Gonzalo
>> DISPATCH co-chair
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From volker.hilt@alcatel-lucent.com  Fri Jan 15 06:47:06 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0B428C0E2; Fri, 15 Jan 2010 06:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJoGTJesUg08; Fri, 15 Jan 2010 06:47:05 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8FEF728C0D6; Fri, 15 Jan 2010 06:47:05 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o0FEkxli029764;  Fri, 15 Jan 2010 08:46:59 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0FEkxUh013241; Fri, 15 Jan 2010 08:46:59 -0600 (CST)
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 08:46:58 -0600
Message-ID: <4B507FD9.4010407@bell-labs.com>
Date: Fri, 15 Jan 2010 09:46:49 -0500
From: Volker Hilt 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <4B505018.7020504@ericsson.com>
In-Reply-To: <4B505018.7020504@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 14:47:06 -0000

Gonzalo,

it would be great to understand what the specific concerns are.

We had a design team working on simulations on SIP overload control for 
a substantial period of time. The group has produced many results and 
has published these results at scientific conferences and status reports 
to the IETF. Some of the drafts have been implemented and tested in 
prototypes or products by multiple vendors. What else is needed?

I'm worried that we are taking yet another detour which will further 
delay the process.

Volker

Gonzalo Camarillo wrote:
> Folks,
> 
> as you know, we agreed to charter the SIP overload work a while ago. 
> Below you can find the proposed charter.
> 
> We have gotten some comments back from the IESG. There are some concerns 
> about the effects of the proposed solutions in real networks. It seems 
> that those concerns would disappear if we chartered the WG to develop 
> Experimental proposals, at least at the beginning. Those proposals would 
> be able to eventually move to the standards track once we got 
> operational experience with them. Comments?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> 
> SIP Overload Control WG Charter
> -------------------------------
> 
> As with any network element, a Session Initiation Protocol (SIP) server
> can suffer from overload when the number of SIP messages it receives
> exceeds the number of messages it can process. Overload is said to occur
> when a SIP server does not have sufficient resources to process all
> incoming SIP messages.  These resources can include CPU, memory, network
> bandwidth, input/output, or disk resources.
> 
> Overload can pose a serious problem for a network of SIP servers. During
> periods of overload, the throughput of a network of SIP servers can be
> significantly degraded.  In fact, overload may lead to a situation in
> which the throughput drops down to zero or a small fraction of the
> original processing capacity.  This is often called congestion collapse.
> 
> The objective of a SIP overload control mechanism is to enable SIP
> servers to operate close to their capacity limit during times of overload.
> 
> The SIP protocol provides a limited mechanism for overload control
> through its 503 (Service Unavailable) response code and the Retry-After
> header.  However, this mechanism cannot fully prevent overload of a SIP
> server and it cannot prevent congestion collapse.  In fact, its on/off
> behavior may cause traffic to oscillate and shift between SIP servers
> and thereby worsen an overload condition.  A detailed discussion of the
> SIP overload problem, the problems with the 503 (Service Unavailable)
> response code and the Retry-After header and the requirements for a SIP
> overload control mechanism can be found in RFC5390.
> 
> The objective of the proposed working group is to develop mechanisms for
> SIP overload control. Two complementary approaches exist for handling
> overload situations:
> - The first mechanism aims at preventing overload in SIP servers by
> adjusting the incoming load to a level that is acceptable for this
> server. This mechanism uses implicit and/or explicit feedback to
> determine when an overload condition occurs in a SIP server and a
> reduction in load is required.
> - The second mechanism aims at preventing overload in SIP servers by
> distributing load control filters to SIP servers that throttle calls
> based on their destination domain, telephone number prefix or for a
> specific user. Such filters can be used, for example, to throttle calls
> to a hotline during a ticket-giveaway event.
> 
> Specifically, the proposed working group will develop the following
> deliverables:
> 1. A document describing key design considerations for a SIP overload
> control mechanism.
> 2. A specification for an SIP overload control mechanism based on
> implicit/explicit feedback.
> 3. A specification for a SIP load filtering mechanism.
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From gonzalo.camarillo@ericsson.com  Fri Jan 15 07:02:08 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B459628C0D9; Fri, 15 Jan 2010 07:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.1
X-Spam-Level: 
X-Spam-Status: No, score=-106.1 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVqExx9tkm1S; Fri, 15 Jan 2010 07:02:08 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3BB5828C0D6; Fri, 15 Jan 2010 07:02:07 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-f5-4b50836a7125
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 31.59.04178.A63805B4; Fri, 15 Jan 2010 16:02:03 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 16:02:02 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 Jan 2010 16:02:02 +0100
Message-ID: <4B50836A.4020607@ericsson.com>
Date: Fri, 15 Jan 2010 17:02:02 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Volker Hilt 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com>
In-Reply-To: <4B507FD9.4010407@bell-labs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jan 2010 15:02:02.0613 (UTC) FILETIME=[B1CDDA50:01CA95F3]
X-Brightmail-Tracker: AAAAAA==
Cc: DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:02:08 -0000

Hi,

> I'm worried that we are taking yet another detour which will further 
> delay the process.

this would not delay the process in any way. If something, it could 
speed it up, because the requirements to review Experimental RFCs are 
lower than to review standards track RFCs... at the end of the day, I do 
not expect this to influence the time it takes to publish the specs 
because I am sure the group will make sure the quality of the specs as 
high as for a standards-track RFC.

Cheers,

Gonzalo

From volker.hilt@alcatel-lucent.com  Fri Jan 15 07:02:27 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A68428C0F8 for ; Fri, 15 Jan 2010 07:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKE+jcaQEzOQ for ; Fri, 15 Jan 2010 07:02:25 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id BE19328C0D6 for ; Fri, 15 Jan 2010 07:02:25 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o0FF2KRL019165;  Fri, 15 Jan 2010 09:02:20 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0FF2KNC004144; Fri, 15 Jan 2010 09:02:20 -0600 (CST)
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 09:02:19 -0600
Message-ID: <4B508372.2030403@bell-labs.com>
Date: Fri, 15 Jan 2010 10:02:10 -0500
From: Volker Hilt 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <1260393285.4277.31.camel@khone.us.nortel.com> <4B2A559F.9040606@ericsson.com>
In-Reply-To: <4B2A559F.9040606@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: DISPATCH 
Subject: Re: [dispatch] XML questions about	draft-ietf-sipping-media-policy-dataset-08
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:02:27 -0000

Gonzalo, All,

the -08 version is now available at:

http://www.ietf.org/id/draft-ietf-sipping-media-policy-dataset-08.txt

Thanks,

Volker

Gonzalo Camarillo wrote:
> Hi Volker,
> 
> could you please submit 08 per Dale's email below so that people on this 
> list can follow the discussions? Right now, the last revision that was 
> submitted is 07:
> 
> http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-07
> 
> Thanks,
> 
> Gonzalo
> 
> Dale Worley wrote:
>> I've edited my questions about the XML in
>> draft-ietf-sipping-media-policy-dataset-08 into better order.  They are
>> appended to this message.
>>
>> Dale
>> -----------------------------------------------------------------------------
>> This is based on a copy of the
>> draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a
>> private directory.  Apparently, the -08 version was never published.
>> I assume that the authors have an archival copy of -08.  The MD5 of my
>> copy of the text version of -08 (with LF as EOL) is
>> dfd01da655ee324727a0f0fbe6ff69a8.
>>
>> - Section 1
>>
>> Are merging rules still needed?  We are no longer using
>> session-policy-dataset, which required merging, but IIRC someone
>> mentioned an additional need for merging.
>>
>> - Section 4.2
>>
>> Section 4.2 contains:
>>
>>    If a UA has an SDP offer as well as an answer [RFC3264] and wants to
>>    create a session info document, the UA MUST use the answer to fill in
>>    the elements of the session info document except for the remote-host-
>>    port and local-host-port elements, which are taken from the remote
>>    and local session description respectively.  The local session
>>    description is the one created locally by the UA (i.e., the offer if
>>    the UA has initiated the offer/answer exchange).  The remote session
>>    description is the one received from the remote UA.
>>
>>    If a UA has an SDP offer as well as an answer [RFC3264] and wants to
>>    create a session info document, the UA MUST use the answer to fill in
>>    the elements of the session info document except for the local-host-port
>>    and remote-host-port elements, which are taken from the SDP generated
>>    by the UA and the SDP received by the UA, respectively (regardless of
>>    which is the offer and which is the answer).
>>
>> However, this process doesn't seem to allow for the possibility that
>> the locally-provided and remote-provided SDP may differ.  (Although I
>> think the relevant differences are restricted to which codecs may be
>> used.)  It seems that directionality attributes could/should be used
>> to have the media-policy specify the admitted codecs in each direction
>> appropriately.
>>
>> The specification of codecs in SDP is strange in that an answer may
>> contain codecs that are not given in the offer, but they are not
>> usable in the session.  How should they be encoded in session-info?
>>
>> Section 4.2 seems to envision that an offer SDP can be mapped into a
>> media-policy, which can then be restricted or subsetted to give a new
>> media-policy, which can then be translated into an answer SDP.  But
>> the transformation of SDP into media-policy XML seems to lose the
>> sequencing of the m= lines, in that there is no semantics specified
>> for the  elements of a media-policy.  Perhaps the intention is
>> that the  elements correspond in order to the m= lines, but
>> that does not seem to be stated.
>>
>> Note that SDP can contain zero m= lines, which would seem to map to a
>>  with a  with no .  But that is not
>> allowed by 6.3.
>>
>> - Section 5
>>
>> Perhaps this change of wording would be clearer:
>>
>>    Session policy documents describe a policy for SIP sessions.  Session
>>    policy documents are independent of >>any<< specific session description
>>    and express general policies for SIP sessions.
>>
>> - Section 5.1
>>
>> The  element is not being used any more.
>>
>> - Section 6.2
>>
>> Section 6.2 says that at least one codec must be allowed per media
>> type (see second sentence), but the correspondence between codec and
>> media type isn't explicit, and it would be a difficult validity
>> constraint to verify.  Also, the text does not specify that we're only
>> concerned with media types that are admitted by the 
>> element.  And worse, what if the  are a set-complement
>> construction (excluded-policy="allow"), in which case the set of
>> admitted media-types is not knowable?  I would suggest removing the
>> restriction, and understanding that an allowed media-type with no
>> allowable codecs is unusable in practice.
>>
>> - Section 6.2.1.1
>>
>> The  and  elements want to specify the codec via a
>> mime-type, but that isn't what SDP uses.  The translation between the
>> two is described in RFC 4855 section 3, which should be referenced.
>>
>> - Section 6.3.1
>>
>> How are 0 port values encoded?  Semantically, it identifies a
>> "sendonly" mode.  Should it be encoded as a zero value of
>>  or (better) by appropriate direction attributes.
>> In any case, this should be specified clearly to avoid interoperation
>> problems.
>>
>> - Section 6.4
>>
>> Section 6.4 uses the phrase "sessions a UA may set up in parallel".
>> Does this refer to the set of sessions for a single dialog?  Or the
>> set of all sessions of all dialogs that the UA is participating in at
>> one time?
>>
>> - Section 6.10
>>
>> Do we want  to be subordinate to ?  This is
>> arguably a layer violation:   and  could be
>> siblings under an element that declares that the policy applies to the
>> context.  This allows  to have defined semantics, but
>> allowing its containing element/message to determine what those
>> semantics apply to.
>>
>> - Section 8
>>
>> The TBD note at the beginning of section 8 (and the task it described)
>> can be removed now that sipping-profile-datasets has been abandoned.
>>
>> Where is the up-to-date version of "uaprofile.rng"?  What is the
>> proper URL to access it?
>>
>> - Imported from ietf-sipping-profile-datasets
>>
>> The 'policy' and 'excluded-policy' attributes are quite grotty, as
>> they can be used only in specific combinations among several related
>> elements, and are quite verbose in any case.  It would be much better
>> to define a "set" construct (to specify a finite set of permitted
>> values) and a "set-complement" construct (to specify all values are
>> permitted except a finite set of values).  These constructs have the
>> same expressive power as the existing attributes.  E.g.:
>>
>>       
>>         audio
>>         video
>>       
>>       
>>         
>>           audio/G729
>>         
>>         
>>           audio/G723
>>         
>>       
>>
>> becomes
>>
>>       
>>         
>> 	  audio
>> 	  video
>> 	
>>       
>>       
>>         
>> 	  
>> 	    audio/G729
>> 	  
>> 	  
>> 	    audio/G723
>> 	  
>>         
>>       
>>
>> but correct usage of this form is much easier to describe in the schema.
>>
>> (Looking at the example, perhaps we want to replace the  and
>>  elements with "set" and "set-complement" attributes
>> on its parent element.  That is less mathematically pure, but has the
>> same expressive power and is more terse.)
>>
>> As far as I can tell, there are nine "container" types which use the
>> set/complement mechanism:
>>
>>     6.1  container of 
>>     6.2 
>>     6.3 
>>     6.4 
>>     6.5 
>>     6.6 
>>     6.7 
>>     6.8 
>>     6.9 
>>
>> The "direction" attribute seems to be weakly defined.  As far as I can
>> tell, in a policy one can have, for any of the nine container types,
>> (1) no element, (2) one element with the value "sendrecv", or (3)
>> optionally one element with the value "sendonly" and optionally one
>> element with the value "recvonly".  But this is not stated in either
>> this draft or draft-petrie-sipping-profile-datasets and I might well
>> be wrong.
>>
>> Also, if we still utilize merging, we need to state that case (2) is
>> equivalent to duplicating the value, with one copy marked "sendonly"
>> and one marked "recvonly", so that we have explicitly shown how to
>> align two containers with direction attributes in order to merge
>> (intersect) them.
>>
>> - Empty elements
>>
>> There are a lot of situations where it is sensible for an element to
>> have zero sub-elements, in that the stated rules give a clear meaning
>> to the element.  In particular, any "set" construct with zero elements
>> permits nothing, and any "set-complement" construct with zero elements
>> permits everything.  But most of the relevant elements (including all
>> the container types) are defined to require at least one sub-element.
>>
>> However, there is currently a special case in section 4: It states
>> that an empty  rejects a session.  (If it wasn't for the
>> defined special case, a session with *no* streams would be admissible
>> under this policy.)  It would be better if the "reject everything"
>> state could be described in a different manner, so as to avoid the
>> special case.
>>
>> - The word "container"
>>
>> Beware of the use of the word "container".  In the
>> session-policy-dataset, "container" is (mostly) used to describe
>> elements which inherit from .  I suggest that we
>> restrict the use in media-policy-dataset in that way.
>>
>> Although now that we are removing session-policy-dataset, "container"
>> is no longer defined by , but it still means the
>> elements which carry "direction", "policy", etc.
>>
>> That change would require rewriting these paragraphs of 6.1:
>>
>>    The  element can only be used in session policy document
>>    (i.e., inside the  >>element<<).
>>
>>    This element MAY have the following attributes (see Section 3.3):
>>    direction, visibility, excluded-policy.
>>
>>    Multiple  elements MAY only be present in a 
>>    element if each applies to a different set of streams (i.e., one
>>     element for incoming and one for outgoing streams).
>>    The  element MUST contain one or more 
>>    elements.
>>
>> There may be other uses of "container" that should be changed.
>>
>> - "Registered" requirements
>>
>> In a number of places, parameters are required to have values that are
>> appropriately registered.  On the face of it, this prevents
>> experimental or private-use values from being used at all.  This is
>> probably not what we intend.  Given that there is general knowledge of
>> how to create private-use values, these registration requirements
>> should just be deleted.
>>

From volker.hilt@alcatel-lucent.com  Fri Jan 15 07:08:19 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2D73A67FB; Fri, 15 Jan 2010 07:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqoCoyllPmDw; Fri, 15 Jan 2010 07:08:18 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id AD3ED3A690B; Fri, 15 Jan 2010 07:08:18 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o0FF8D11025893;  Fri, 15 Jan 2010 09:08:13 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0FF8DaX012133; Fri, 15 Jan 2010 09:08:13 -0600 (CST)
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 09:08:12 -0600
Message-ID: <4B5084D3.5020606@bell-labs.com>
Date: Fri, 15 Jan 2010 10:08:03 -0500
From: Volker Hilt 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Gonzalo Camarillo 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com>
In-Reply-To: <4B50836A.4020607@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:08:19 -0000

Gonzalo,
> 
>> I'm worried that we are taking yet another detour which will further 
>> delay the process.
> 
> this would not delay the process in any way. If something, it could 
> speed it up, because the requirements to review Experimental RFCs are 
> lower than to review standards track RFCs... at the end of the day, I do 
> not expect this to influence the time it takes to publish the specs 
> because I am sure the group will make sure the quality of the specs as 
> high as for a standards-track RFC.
> 
I'd like to understand the concerns that lead to the proposal of putting 
this work through the experimental track.

What are we missing that prevents us from creating a standards track 
document?

Volker

From jgunn6@csc.com  Fri Jan 15 07:19:04 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8223A6A5D; Fri, 15 Jan 2010 07:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fPGb74Arat6; Fri, 15 Jan 2010 07:19:03 -0800 (PST)
Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id 7A6093A6A87; Fri, 15 Jan 2010 07:18:59 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-15.tower-145.messagelabs.com!1263568734!15868952!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 21546 invoked from network); 15 Jan 2010 15:18:55 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-15.tower-145.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 15:18:55 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o0FFIfKP014477; Fri, 15 Jan 2010 10:18:41 -0500
In-Reply-To: <4B507FD9.4010407@bell-labs.com>
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com>
To: Volker Hilt 
MIME-Version: 1.0
X-KeepSent: 73848687:E2EFB750-852576AC:0053E618; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1  CCH2 April 23, 2009
From: Janet P Gunn 
Message-ID: 
Date: Fri, 15 Jan 2010 10:18:52 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 01/15/2010 10:20:04 AM, Serialize complete at 01/15/2010 10:20:04 AM
Content-Type: multipart/alternative; boundary="=_alternative 00541FF7852576AC_="
Cc: sip-overload-bounces@ietf.org, DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] [sip-overload]  Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:19:04 -0000

This is a multipart message in MIME format.
--=_alternative 00541FF7852576AC_=
Content-Type: text/plain; charset="US-ASCII"

Is the concern "real networks" vs "simulated networks"?

Or is the concern "the (open) Internet" vs "(closed, walled-garden) 
carrier networks"?

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

From:
Volker Hilt 
To:
Gonzalo Camarillo 
Cc:
DISPATCH , "sip-overload@ietf.org" 

Date:
01/15/2010 09:47 AM
Subject:
Re: [sip-overload] [dispatch] Chartering SIP Overload

Gonzalo,

it would be great to understand what the specific concerns are.

We had a design team working on simulations on SIP overload control for 
a substantial period of time. The group has produced many results and 
has published these results at scientific conferences and status reports 
to the IETF. Some of the drafts have been implemented and tested in 
prototypes or products by multiple vendors. What else is needed?

I'm worried that we are taking yet another detour which will further 
delay the process.

Volker

Gonzalo Camarillo wrote:
> Folks,
> 
> as you know, we agreed to charter the SIP overload work a while ago. 
> Below you can find the proposed charter.
> 
> We have gotten some comments back from the IESG. There are some concerns 

> about the effects of the proposed solutions in real networks. It seems 
> that those concerns would disappear if we chartered the WG to develop 
> Experimental proposals, at least at the beginning. Those proposals would 

> be able to eventually move to the standards track once we got 
> operational experience with them. Comments?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> 
> SIP Overload Control WG Charter
> -------------------------------
> 
> As with any network element, a Session Initiation Protocol (SIP) server
> can suffer from overload when the number of SIP messages it receives
> exceeds the number of messages it can process. Overload is said to occur
> when a SIP server does not have sufficient resources to process all
> incoming SIP messages.  These resources can include CPU, memory, network
> bandwidth, input/output, or disk resources.
> 
> Overload can pose a serious problem for a network of SIP servers. During
> periods of overload, the throughput of a network of SIP servers can be
> significantly degraded.  In fact, overload may lead to a situation in
> which the throughput drops down to zero or a small fraction of the
> original processing capacity.  This is often called congestion collapse.
> 
> The objective of a SIP overload control mechanism is to enable SIP
> servers to operate close to their capacity limit during times of 
overload.
> 
> The SIP protocol provides a limited mechanism for overload control
> through its 503 (Service Unavailable) response code and the Retry-After
> header.  However, this mechanism cannot fully prevent overload of a SIP
> server and it cannot prevent congestion collapse.  In fact, its on/off
> behavior may cause traffic to oscillate and shift between SIP servers
> and thereby worsen an overload condition.  A detailed discussion of the
> SIP overload problem, the problems with the 503 (Service Unavailable)
> response code and the Retry-After header and the requirements for a SIP
> overload control mechanism can be found in RFC5390.
> 
> The objective of the proposed working group is to develop mechanisms for
> SIP overload control. Two complementary approaches exist for handling
> overload situations:
> - The first mechanism aims at preventing overload in SIP servers by
> adjusting the incoming load to a level that is acceptable for this
> server. This mechanism uses implicit and/or explicit feedback to
> determine when an overload condition occurs in a SIP server and a
> reduction in load is required.
> - The second mechanism aims at preventing overload in SIP servers by
> distributing load control filters to SIP servers that throttle calls
> based on their destination domain, telephone number prefix or for a
> specific user. Such filters can be used, for example, to throttle calls
> to a hotline during a ticket-giveaway event.
> 
> Specifically, the proposed working group will develop the following
> deliverables:
> 1. A document describing key design considerations for a SIP overload
> control mechanism.
> 2. A specification for an SIP overload control mechanism based on
> implicit/explicit feedback.
> 3. A specification for a SIP load filtering mechanism.
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 00541FF7852576AC_=
Content-Type: text/html; charset="US-ASCII"

Is the concern "real networks"
vs "simulated networks"?

Or is the concern "the (open) Internet"
vs "(closed, walled-garden) carrier networks"?

Janet

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. 

NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.

From:
Volker Hilt <volkerh@bell-labs.com>

To:
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

Cc:
DISPATCH <dispatch@ietf.org>,
"sip-overload@ietf.org" <sip-overload@ietf.org>

Date:
01/15/2010 09:47 AM

Subject:
Re: [sip-overload] [dispatch] Chartering
SIP Overload

Gonzalo,

it would be great to understand what the specific concerns are.

We had a design team working on simulations on SIP overload control for

a substantial period of time. The group has produced many results and 

has published these results at scientific conferences and status reports

to the IETF. Some of the drafts have been implemented and tested in 

prototypes or products by multiple vendors. What else is needed?

I'm worried that we are taking yet another detour which will further 

delay the process.

Volker

Gonzalo Camarillo wrote:

> Folks,

> 

> as you know, we agreed to charter the SIP overload work a while ago.

> Below you can find the proposed charter.

> 

> We have gotten some comments back from the IESG. There are some concerns

> about the effects of the proposed solutions in real networks. It seems

> that those concerns would disappear if we chartered the WG to develop

> Experimental proposals, at least at the beginning. Those proposals
would 

> be able to eventually move to the standards track once we got 

> operational experience with them. Comments?

> 

> Thanks,

> 

> Gonzalo

> 

> 

> 

> SIP Overload Control WG Charter

> -------------------------------

> 

> As with any network element, a Session Initiation Protocol (SIP) server

> can suffer from overload when the number of SIP messages it receives

> exceeds the number of messages it can process. Overload is said to
occur

> when a SIP server does not have sufficient resources to process all

> incoming SIP messages.  These resources can include CPU, memory,
network

> bandwidth, input/output, or disk resources.

> 

> Overload can pose a serious problem for a network of SIP servers.
During

> periods of overload, the throughput of a network of SIP servers can
be

> significantly degraded.  In fact, overload may lead to a situation
in

> which the throughput drops down to zero or a small fraction of the

> original processing capacity.  This is often called congestion
collapse.

> 

> The objective of a SIP overload control mechanism is to enable SIP

> servers to operate close to their capacity limit during times of overload.

> 

> The SIP protocol provides a limited mechanism for overload control

> through its 503 (Service Unavailable) response code and the Retry-After

> header.  However, this mechanism cannot fully prevent overload
of a SIP

> server and it cannot prevent congestion collapse.  In fact, its
on/off

> behavior may cause traffic to oscillate and shift between SIP servers

> and thereby worsen an overload condition.  A detailed discussion
of the

> SIP overload problem, the problems with the 503 (Service Unavailable)

> response code and the Retry-After header and the requirements for
a SIP

> overload control mechanism can be found in RFC5390.

> 

> The objective of the proposed working group is to develop mechanisms
for

> SIP overload control. Two complementary approaches exist for handling

> overload situations:

> - The first mechanism aims at preventing overload in SIP servers by

> adjusting the incoming load to a level that is acceptable for this

> server. This mechanism uses implicit and/or explicit feedback to

> determine when an overload condition occurs in a SIP server and a

> reduction in load is required.

> - The second mechanism aims at preventing overload in SIP servers
by

> distributing load control filters to SIP servers that throttle calls

> based on their destination domain, telephone number prefix or for
a

> specific user. Such filters can be used, for example, to throttle
calls

> to a hotline during a ticket-giveaway event.

> 

> Specifically, the proposed working group will develop the following

> deliverables:

> 1. A document describing key design considerations for a SIP overload

> control mechanism.

> 2. A specification for an SIP overload control mechanism based on

> implicit/explicit feedback.

> 3. A specification for a SIP load filtering mechanism.

> 

> 

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.org

> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________

sip-overload mailing list

sip-overload@ietf.org

https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 00541FF7852576AC_=--

From rjsparks@nostrum.com  Fri Jan 15 07:34:25 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30093A6A33; Fri, 15 Jan 2010 07:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy7CmezjycnE; Fri, 15 Jan 2010 07:34:24 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 68CBD3A6856; Fri, 15 Jan 2010 07:34:24 -0800 (PST)
Received: from [192.168.2.2] (pool-173-71-49-137.dllstx.fios.verizon.net [173.71.49.137]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0FFYCNt026772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jan 2010 09:34:13 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-Id: <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com>
From: Robert Sparks 
To: Volker Hilt 
In-Reply-To: <4B5084D3.5020606@bell-labs.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 15 Jan 2010 09:34:12 -0600
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com> <4B5084D3.5020606@bell-labs.com>
X-Mailer: Apple Mail (2.936)
Received-SPF: pass (nostrum.com: 173.71.49.137 is authenticated by a trusted mechanism)
Cc: DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:34:25 -0000

(Copying Lars - please preserve him on the CC for this thread).

The big concern, as I understand it, is that the state of what the  
team's explored so far
reduces the degradation of throughput as load increases, but still  
eventually collapses.
Is that accurate? (I might have missed something the team's done that  
manages to converge
to a stable point.)

RjS

On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:

> Gonzalo,
>>> I'm worried that we are taking yet another detour which will  
>>> further delay the process.
>> this would not delay the process in any way. If something, it could  
>> speed it up, because the requirements to review Experimental RFCs  
>> are lower than to review standards track RFCs... at the end of the  
>> day, I do not expect this to influence the time it takes to publish  
>> the specs because I am sure the group will make sure the quality of  
>> the specs as high as for a standards-track RFC.
> I'd like to understand the concerns that lead to the proposal of  
> putting this work through the experimental track.
>
> What are we missing that prevents us from creating a standards track  
> document?
>
> Volker
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From hgs@cs.columbia.edu  Fri Jan 15 07:38:36 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B990B3A6AE0; Fri, 15 Jan 2010 07:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Igi+gPGJIMER; Fri, 15 Jan 2010 07:38:36 -0800 (PST)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id C800C3A6829; Fri, 15 Jan 2010 07:38:35 -0800 (PST)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0FFcOTj000182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jan 2010 10:38:25 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne 
In-Reply-To: <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com>
Date: Fri, 15 Jan 2010 10:38:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <199BC2E4-B4E7-4447-95B8-BA67CE7061F8@cs.columbia.edu>
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com> <4B5084D3.5020606@bell-labs.com> <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:38:36 -0000

At least according to our measurements and simulations, that is not the =
case. The throughput stays at ~100% until infinity.

Henning

On Jan 15, 2010, at 10:34 AM, Robert Sparks wrote:

> (Copying Lars - please preserve him on the CC for this thread).
>=20
> The big concern, as I understand it, is that the state of what the =
team's explored so far
> reduces the degradation of throughput as load increases, but still =
eventually collapses.
> Is that accurate? (I might have missed something the team's done that =
manages to converge
> to a stable point.)
>=20
> RjS
>=20
>=20
> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:
>=20
>> Gonzalo,
>>>> I'm worried that we are taking yet another detour which will =
further delay the process.
>>> this would not delay the process in any way. If something, it could =
speed it up, because the requirements to review Experimental RFCs are =
lower than to review standards track RFCs... at the end of the day, I do =
not expect this to influence the time it takes to publish the specs =
because I am sure the group will make sure the quality of the specs as =
high as for a standards-track RFC.
>> I'd like to understand the concerns that lead to the proposal of =
putting this work through the experimental track.
>>=20
>> What are we missing that prevents us from creating a standards track =
document?
>>=20
>> Volker
>>=20
>>=20
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From volker.hilt@alcatel-lucent.com  Fri Jan 15 07:58:01 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81A03A6AFE; Fri, 15 Jan 2010 07:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbAoYdAC9Ccd; Fri, 15 Jan 2010 07:58:00 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C0AD23A6AE1; Fri, 15 Jan 2010 07:57:59 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o0FFvmTS022774;  Fri, 15 Jan 2010 09:57:48 -0600 (CST)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0FFvkVB019031; Fri, 15 Jan 2010 09:57:47 -0600 (CST)
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 15 Jan 2010 09:57:47 -0600
Message-ID: <4B509071.8090904@bell-labs.com>
Date: Fri, 15 Jan 2010 10:57:37 -0500
From: Volker Hilt 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Henning Schulzrinne 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com> <4B5084D3.5020606@bell-labs.com> <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com> <199BC2E4-B4E7-4447-95B8-BA67CE7061F8@cs.columbia.edu>
In-Reply-To: <199BC2E4-B4E7-4447-95B8-BA67CE7061F8@cs.columbia.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: DISPATCH , "sip-overload@ietf.org" , Lars Eggert 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:58:01 -0000

Yes, we have the same results - the throughput stays at the capacity
limit and remains stable.

Volker

Henning Schulzrinne wrote:
> At least according to our measurements and simulations, that is not the case. The throughput stays at ~100% until infinity.
> 
> Henning
> 
> On Jan 15, 2010, at 10:34 AM, Robert Sparks wrote:
> 
>> (Copying Lars - please preserve him on the CC for this thread).
>>
>> The big concern, as I understand it, is that the state of what the team's explored so far
>> reduces the degradation of throughput as load increases, but still eventually collapses.
>> Is that accurate? (I might have missed something the team's done that manages to converge
>> to a stable point.)
>>
>> RjS
>>
>>
>> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:
>>
>>> Gonzalo,
>>>>> I'm worried that we are taking yet another detour which will further delay the process.
>>>> this would not delay the process in any way. If something, it could speed it up, because the requirements to review Experimental RFCs are lower than to review standards track RFCs... at the end of the day, I do not expect this to influence the time it takes to publish the specs because I am sure the group will make sure the quality of the specs as high as for a standards-track RFC.
>>> I'd like to understand the concerns that lead to the proposal of putting this work through the experimental track.
>>>
>>> What are we missing that prevents us from creating a standards track document?
>>>
>>> Volker
>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> 

From jgunn6@csc.com  Fri Jan 15 08:09:38 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E0F3A6945; Fri, 15 Jan 2010 08:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPvUBFFFQwXx; Fri, 15 Jan 2010 08:09:35 -0800 (PST)
Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id CBE113A6966; Fri, 15 Jan 2010 08:09:34 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-5.tower-86.messagelabs.com!1263571769!11810786!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 19429 invoked from network); 15 Jan 2010 16:09:30 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-5.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 16:09:30 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o0FG9IcB025993; Fri, 15 Jan 2010 11:09:26 -0500
In-Reply-To: <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com>
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com>	<4B50836A.4020607@ericsson.com> <4B5084D3.5020606@bell-labs.com> <0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com>
To: Robert Sparks 
MIME-Version: 1.0
X-KeepSent: 9BE099C4:F5D46763-852576AC:0058AA28; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1  CCH2 April 23, 2009
From: Janet P Gunn 
Message-ID: 
Date: Fri, 15 Jan 2010 11:09:22 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 01/15/2010 11:10:37 AM, Serialize complete at 01/15/2010 11:10:37 AM
Content-Type: multipart/alternative; boundary="=_alternative 0058BFD7852576AC_="
Cc: sip-overload-bounces@ietf.org, DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] [sip-overload]  Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 16:09:38 -0000

This is a multipart message in MIME format.
--=_alternative 0058BFD7852576AC_=
Content-Type: text/plain; charset="US-ASCII"

That was a concern with the very first work done by the SIP overload 
group.  But all the results presented recently have avoided that problem.

Janet

sip-overload-bounces@ietf.org wrote on 01/15/2010 10:34:12 AM:

> [image removed] 
> 
> Re: [sip-overload] [dispatch] Chartering SIP Overload
> 
> Robert Sparks 
> 
> to:
> 
> Volker Hilt
> 
> 01/15/2010 10:41 AM
> 
> Sent by:
> 
> sip-overload-bounces@ietf.org
> 
> Cc:
> 
> DISPATCH, sip-overload, Gonzalo Camarillo, Lars Eggert
> 
> (Copying Lars - please preserve him on the CC for this thread).
> 
> The big concern, as I understand it, is that the state of what the 
> team's explored so far
> reduces the degradation of throughput as load increases, but still 
> eventually collapses.
> Is that accurate? (I might have missed something the team's done that 
> manages to converge
> to a stable point.)
> 
> RjS
> 
> 
> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:
> 
> > Gonzalo,
> >>> I'm worried that we are taking yet another detour which will 
> >>> further delay the process.
> >> this would not delay the process in any way. If something, it could 
> >> speed it up, because the requirements to review Experimental RFCs 
> >> are lower than to review standards track RFCs... at the end of the 
> >> day, I do not expect this to influence the time it takes to publish 
> >> the specs because I am sure the group will make sure the quality of 
> >> the specs as high as for a standards-track RFC.
> > I'd like to understand the concerns that lead to the proposal of 
> > putting this work through the experimental track.
> >
> > What are we missing that prevents us from creating a standards track 
> > document?
> >
> > Volker
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 0058BFD7852576AC_=
Content-Type: text/html; charset="US-ASCII"

That was a concern with the very first work done by the SIP overload group.
 But all the results presented recently have avoided that problem.

Janet

sip-overload-bounces@ietf.org wrote on 01/15/2010
10:34:12 AM:

> [image removed] 

> 

> Re: [sip-overload] [dispatch] Chartering SIP Overload

> 

> Robert Sparks 

> 

> to:

> 

> Volker Hilt

> 

> 01/15/2010 10:41 AM

> 

> Sent by:

> 

> sip-overload-bounces@ietf.org

> 

> Cc:

> 

> DISPATCH, sip-overload, Gonzalo Camarillo, Lars Eggert

> 

> (Copying Lars - please preserve him on the CC for this thread).

> 

> The big concern, as I understand it, is that the state of what the

> team's explored so far

> reduces the degradation of throughput as load increases, but still

> eventually collapses.

> Is that accurate? (I might have missed something the team's done that

> manages to converge

> to a stable point.)

> 

> RjS

> 

> 

> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:

> 

> > Gonzalo,

> >>> I'm worried that we are taking yet another detour which
will  

> >>> further delay the process.

> >> this would not delay the process in any way. If something,
it could  

> >> speed it up, because the requirements to review Experimental
RFCs  

> >> are lower than to review standards track RFCs... at the end
of the  

> >> day, I do not expect this to influence the time it takes
to publish  

> >> the specs because I am sure the group will make sure the
quality of  

> >> the specs as high as for a standards-track RFC.

> > I'd like to understand the concerns that lead to the proposal
of  

> > putting this work through the experimental track.

> >

> > What are we missing that prevents us from creating a standards
track  

> > document?

> >

> > Volker

> >

> >

> >

> > _______________________________________________

> > dispatch mailing list

> > dispatch@ietf.org

> > https://www.ietf.org/mailman/listinfo/dispatch

> 

> _______________________________________________

> sip-overload mailing list

> sip-overload@ietf.org

> https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 0058BFD7852576AC_=--

From aabdelal@sonusnet.com  Fri Jan 15 14:06:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF743A6857; Fri, 15 Jan 2010 14:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOrPbsptdkue; Fri, 15 Jan 2010 14:06:52 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 0F1B23A67FC; Fri, 15 Jan 2010 14:06:51 -0800 (PST)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id o0FM6alS016599;  Fri, 15 Jan 2010 17:06:36 -0500
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: Fri, 15 Jan 2010 17:04:26 -0500
Message-ID: <30CC59382F8B084DA5EEC4F7A26001FB0120776D@sonusmail06.sonusnet.com>
In-Reply-To: <5DA01D2CA74FAF40ADF71DB4177D345A04841C08@misout7msgusr7b.ugd.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [sip-overload] [dispatch] Chartering SIP Overload
Thread-Index: AcqV+4lvdMnDQtMPS26qpIxgo/BZ8AAAE3GAAAw7RfA=
References: <4B509071.8090904@bell-labs.com> <5DA01D2CA74FAF40ADF71DB4177D345A04841C08@misout7msgusr7b.ugd.att.com>
From: "Abdelal, Ahmed" 
To: "NOEL, ERIC C (ATTLABS)" , "Volker Hilt" , "Henning Schulzrinne" 
X-Mailman-Approved-At: Fri, 15 Jan 2010 14:30:41 -0800
Cc: DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] [sip-overload]  Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 22:06:53 -0000

We (Sonus) have implemented the SIP overload control and extensively
tested it. The results show that it mainatins the goodput under
different overload levels.

--Ahmed

-----Original Message-----
From: sip-overload-bounces@ietf.org
[mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C
(ATTLABS)
Sent: Friday, January 15, 2010 10:57 AM
To: Volker Hilt; Henning Schulzrinne
Cc: DISPATCH; sip-overload@ietf.org; Lars Eggert; Robert Sparks
Subject: Re: [sip-overload] [dispatch] Chartering SIP Overload

Same here at AT&T.

Eric

-----Original Message-----
From: sip-overload-bounces@ietf.org
[mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt
Sent: Friday, January 15, 2010 10:58 AM
To: Henning Schulzrinne
Cc: DISPATCH; sip-overload@ietf.org; Lars Eggert; Robert Sparks
Subject: Re: [sip-overload] [dispatch] Chartering SIP Overload

Yes, we have the same results - the throughput stays at the capacity
limit and remains stable.

Volker

Henning Schulzrinne wrote:
> At least according to our measurements and simulations, that is not
the case. The throughput stays at ~100% until infinity.
>=20
> Henning
>=20
> On Jan 15, 2010, at 10:34 AM, Robert Sparks wrote:
>=20
>> (Copying Lars - please preserve him on the CC for this thread).
>>
>> The big concern, as I understand it, is that the state of what the
team's explored so far
>> reduces the degradation of throughput as load increases, but still
eventually collapses.
>> Is that accurate? (I might have missed something the team's done that
manages to converge
>> to a stable point.)
>>
>> RjS
>>
>>
>> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:
>>
>>> Gonzalo,
>>>>> I'm worried that we are taking yet another detour which will
further delay the process.
>>>> this would not delay the process in any way. If something, it could
speed it up, because the requirements to review Experimental RFCs are
lower than to review standards track RFCs... at the end of the day, I do
not expect this to influence the time it takes to publish the specs
because I am sure the group will make sure the quality of the specs as
high as for a standards-track RFC.
>>> I'd like to understand the concerns that lead to the proposal of
putting this work through the experimental track.
>>>
>>> What are we missing that prevents us from creating a standards track
document?
>>>
>>> Volker
>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>=20

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

From en5192@att.com  Fri Jan 15 07:59:19 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4E93A6AFD; Fri, 15 Jan 2010 07:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtFEK8NG4JYA; Fri, 15 Jan 2010 07:59:19 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 017723A6AE1; Fri, 15 Jan 2010 07:59:18 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: en5192@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1263571154!51028866!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 31218 invoked from network); 15 Jan 2010 15:59:15 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jan 2010 15:59:15 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o0FFx9e8000694; Fri, 15 Jan 2010 10:59:10 -0500
Received: from misout7msgusr7b.ugd.att.com (misout7msgusr7b.ugd.att.com [144.155.43.104]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o0FFx7fr000687; Fri, 15 Jan 2010 10:59:07 -0500
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: Fri, 15 Jan 2010 10:56:44 -0500
Message-ID: <5DA01D2CA74FAF40ADF71DB4177D345A04841C08@misout7msgusr7b.ugd.att.com>
In-Reply-To: <4B509071.8090904@bell-labs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [sip-overload] [dispatch] Chartering SIP Overload
Thread-Index: AcqV+4lvdMnDQtMPS26qpIxgo/BZ8AAAE3GA
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com> <4B5084D3.5020606@bell-labs.com><0D5387FA-749B-4EF4-9C44-53668CBAB9E0@nostrum.com><199BC2E4-B4E7-4447-95B8-BA67CE7061F8@cs.columbia.edu> <4B509071.8090904@bell-labs.com>
From: "NOEL, ERIC C (ATTLABS)" 
To: "Volker Hilt" , "Henning Schulzrinne" 
X-Mailman-Approved-At: Fri, 15 Jan 2010 14:30:50 -0800
Cc: DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] [sip-overload]  Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2010 15:59:20 -0000

Same here at AT&T.

Eric

-----Original Message-----
From: sip-overload-bounces@ietf.org
[mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt
Sent: Friday, January 15, 2010 10:58 AM
To: Henning Schulzrinne
Cc: DISPATCH; sip-overload@ietf.org; Lars Eggert; Robert Sparks
Subject: Re: [sip-overload] [dispatch] Chartering SIP Overload

Yes, we have the same results - the throughput stays at the capacity
limit and remains stable.

Volker

Henning Schulzrinne wrote:
> At least according to our measurements and simulations, that is not
the case. The throughput stays at ~100% until infinity.
>=20
> Henning
>=20
> On Jan 15, 2010, at 10:34 AM, Robert Sparks wrote:
>=20
>> (Copying Lars - please preserve him on the CC for this thread).
>>
>> The big concern, as I understand it, is that the state of what the
team's explored so far
>> reduces the degradation of throughput as load increases, but still
eventually collapses.
>> Is that accurate? (I might have missed something the team's done that
manages to converge
>> to a stable point.)
>>
>> RjS
>>
>>
>> On Jan 15, 2010, at 9:08 AM, Volker Hilt wrote:
>>
>>> Gonzalo,
>>>>> I'm worried that we are taking yet another detour which will
further delay the process.
>>>> this would not delay the process in any way. If something, it could
speed it up, because the requirements to review Experimental RFCs are
lower than to review standards track RFCs... at the end of the day, I do
not expect this to influence the time it takes to publish the specs
because I am sure the group will make sure the quality of the specs as
high as for a standards-track RFC.
>>> I'd like to understand the concerns that lead to the proposal of
putting this work through the experimental track.
>>>
>>> What are we missing that prevents us from creating a standards track
document?
>>>
>>> Volker
>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>=20

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

From dean.willis@softarmor.com  Fri Jan 15 21:57:05 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30DF3A68D0 for ; Fri, 15 Jan 2010 21:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fve-gbepzoMI for ; Fri, 15 Jan 2010 21:57:05 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DB44F3A68C6 for ; Fri, 15 Jan 2010 21:57:04 -0800 (PST)
Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0G5uwLG030177; Fri, 15 Jan 2010 23:56:58 -0600
Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Sat, 16 Jan 2010 05:56:58 -0000 (UTC)
Message-ID: <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>
Date: Sat, 16 Jan 2010 05:56:58 -0000 (UTC)
From: "Dean Willis" 
To: "Avasarala Ranjit-A20990" 
User-Agent: SquirrelMail/1.4.15
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2010 05:57:05 -0000

On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> Hi John
>
> Completely agree with you. The subscribe requests will be towards the
> public AoR i.e alice@example. But the diversion rules could be set for
> specific registered contact Uris so that diversions for that particular
> URI are notified.

What isn't clear here is the underlying diversion architecture.

I believe John has in mind a model where each UA has local divert
capability; that is, it can receive an INVITE request and divert to
another location without the registrar having knowledge of this diversion.
Thus, diversion subscriptions have to be serviced by the UAs themselves,
which are the notifiers. This means a "forked SUBSCRIBE" scenario with
multiple 200s, which is a bit messy (i.e., it isn't likely to work very
well).

However, the CDIV architecture as I understand it assumes diversion is
handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
first determines a routing for the INVITE to various contacts, then
executes diversion on a per-contact basis if needed. Consequently, the
S-CSCF has full knowledge of diversion status, and can serve as the
notifier for the diversion notification package. This all requires some
way for a UA to inform an S-CSCF to invoke diversion, which is outside the
scope of this document.

And this is exactly the description of architectural model that is
apparently not adequately disclosed in the draft, and probably should be.

--
Dean

From pkyzivat@cisco.com  Sat Jan 16 07:43:42 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0CE3A691C for ; Sat, 16 Jan 2010 07:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AqKexxabQAT for ; Sat, 16 Jan 2010 07:43:40 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 837CF3A67FB for ; Sat, 16 Jan 2010 07:43:40 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEANVtUUurR7H+/2dsb2JhbADDZ5UHhDIE
X-IronPort-AV: E=Sophos;i="4.49,286,1262563200"; d="scan'208";a="468005226"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2010 15:43:37 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0GFhbpr013444; Sat, 16 Jan 2010 15:43:37 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 16 Jan 2010 09:43:37 -0600
Received: from [10.86.253.8] ([10.86.253.8]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 Jan 2010 09:43:36 -0600
Message-ID: <4B51DEA4.3040106@cisco.com>
Date: Sat, 16 Jan 2010 10:43:32 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Dean Willis 
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
In-Reply-To: <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jan 2010 15:43:36.0788 (UTC) FILETIME=[AADC8140:01CA96C2]
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2010 15:43:42 -0000

Dean is on the track that I was thinking.

But I also can't reconcile Ranjit's statement, that the subscription 
would be addressed to the AOR of the diverted user, with the syntax of 
the filter, which has a separate selector for the diverted users to 
notify about. That only makes sense if the subscription is to an entity 
that has visibility to a variety of diverted users.

I also continue to question whether contact routing should be considered 
diversion. That did not seem to be the common understanding during the 
long discussions on History-Info. I agree that getting info on which 
contact was selected might be useful, but then I think terms should be 
more carefully defined.

	Thanks,
	Paul

Dean Willis wrote:
> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
>> Hi John
>>
>> Completely agree with you. The subscribe requests will be towards the
>> public AoR i.e alice@example. But the diversion rules could be set for
>> specific registered contact Uris so that diversions for that particular
>> URI are notified.
> 
> What isn't clear here is the underlying diversion architecture.
> 
> I believe John has in mind a model where each UA has local divert
> capability; that is, it can receive an INVITE request and divert to
> another location without the registrar having knowledge of this diversion.
> Thus, diversion subscriptions have to be serviced by the UAs themselves,
> which are the notifiers. This means a "forked SUBSCRIBE" scenario with
> multiple 200s, which is a bit messy (i.e., it isn't likely to work very
> well).
> 
> However, the CDIV architecture as I understand it assumes diversion is
> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
> first determines a routing for the INVITE to various contacts, then
> executes diversion on a per-contact basis if needed. Consequently, the
> S-CSCF has full knowledge of diversion status, and can serve as the
> notifier for the diversion notification package. This all requires some
> way for a UA to inform an S-CSCF to invoke diversion, which is outside the
> scope of this document.
> 
> And this is exactly the description of architectural model that is
> apparently not adequately disclosed in the draft, and probably should be.
> 
> --
> Dean
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From ankriste@cisco.com  Sat Jan 16 11:36:47 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ADA3A67F6 for ; Sat, 16 Jan 2010 11:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDo-zSgXue1X for ; Sat, 16 Jan 2010 11:36:46 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BCDA73A62C1 for ; Sat, 16 Jan 2010 11:36:46 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAIGjUUurR7Hu/2dsb2JhbADCHZR2hDIE
X-IronPort-AV: E=Sophos;i="4.49,287,1262563200"; d="scan'208";a="468062175"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2010 19:36:43 +0000
Received: from [10.21.75.52] ([10.21.75.52]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0GJahC8010634 for ; Sat, 16 Jan 2010 19:36:43 GMT
Message-ID: <4B52154A.5040107@cisco.com>
Date: Sat, 16 Jan 2010 11:36:42 -0800
From: Anders Kristensen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
In-Reply-To: <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2010 19:36:47 -0000

Instead of emphasizing and clarifying how this work is 3gpp specific it 
might be better to focus on how to make it more generally applicable (or 
palatable, if you prefer). ISTM that at its core this could be generally 
useful and need not be tied to 3gpp. The result may be somewhat 
different from what's in the current draft, but it can serve as a 
starting point.

Anders

On 1/15/2010 9:56 PM, Dean Willis wrote:
> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
>> Hi John
>>
>> Completely agree with you. The subscribe requests will be towards the
>> public AoR i.e alice@example. But the diversion rules could be set for
>> specific registered contact Uris so that diversions for that particular
>> URI are notified.
>
> What isn't clear here is the underlying diversion architecture.
>
> I believe John has in mind a model where each UA has local divert
> capability; that is, it can receive an INVITE request and divert to
> another location without the registrar having knowledge of this diversion.
> Thus, diversion subscriptions have to be serviced by the UAs themselves,
> which are the notifiers. This means a "forked SUBSCRIBE" scenario with
> multiple 200s, which is a bit messy (i.e., it isn't likely to work very
> well).
>
> However, the CDIV architecture as I understand it assumes diversion is
> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
> first determines a routing for the INVITE to various contacts, then
> executes diversion on a per-contact basis if needed. Consequently, the
> S-CSCF has full knowledge of diversion status, and can serve as the
> notifier for the diversion notification package. This all requires some
> way for a UA to inform an S-CSCF to invoke diversion, which is outside the
> scope of this document.
>
> And this is exactly the description of architectural model that is
> apparently not adequately disclosed in the draft, and probably should be.
>
> --
> Dean
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From john.elwell@siemens-enterprise.com  Mon Jan 18 01:02:40 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1604A3A6961 for ; Mon, 18 Jan 2010 01:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ockOnBx1yy5 for ; Mon, 18 Jan 2010 01:02:37 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 41F363A68DC for ; Mon, 18 Jan 2010 01:02:36 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-566362; Mon, 18 Jan 2010 10:02:32 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 842D41EB82A7; Mon, 18 Jan 2010 10:02:32 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jan 2010 10:02:32 +0100
From: "Elwell, John" 
To: Dean Willis , Avasarala Ranjit-A20990 
Date: Mon, 18 Jan 2010 10:02:30 +0100
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqWcLvQaLrsQouoQMe/EELMPM49iABrBU1A
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
In-Reply-To: <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 09:02:40 -0000

=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: 16 January 2010 05:57
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments=20
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> > Hi John
> >
> > Completely agree with you. The subscribe requests will be=20
> towards the
> > public AoR i.e alice@example. But the diversion rules could=20
> be set for
> > specific registered contact Uris so that diversions for=20
> that particular
> > URI are notified.
>=20
> What isn't clear here is the underlying diversion architecture.
>=20
> I believe John has in mind a model where each UA has local divert
> capability; that is, it can receive an INVITE request and divert to
> another location without the registrar having knowledge of=20
> this diversion.
> Thus, diversion subscriptions have to be serviced by the UAs=20
> themselves,
> which are the notifiers. This means a "forked SUBSCRIBE" scenario with
> multiple 200s, which is a bit messy (i.e., it isn't likely to=20
> work very
> well).
[JRE] To be clear, I was not advocating that model, but just questioning wh=
ether that was the model the author had in mind.

John

>=20
> However, the CDIV architecture as I understand it assumes diversion is
> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
> first determines a routing for the INVITE to various contacts, then
> executes diversion on a per-contact basis if needed. Consequently, the
> S-CSCF has full knowledge of diversion status, and can serve as the
> notifier for the diversion notification package. This all=20
> requires some
> way for a UA to inform an S-CSCF to invoke diversion, which=20
> is outside the
> scope of this document.
>=20
> And this is exactly the description of architectural model that is
> apparently not adequately disclosed in the draft, and=20
> probably should be.
>=20
> --
> Dean
>=20
>=20
> =

From ranjit@motorola.com  Mon Jan 18 02:07:18 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300A43A68DC for ; Mon, 18 Jan 2010 02:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QETIvwehq6ds for ; Mon, 18 Jan 2010 02:07:17 -0800 (PST)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id E4BAE3A6822 for ; Mon, 18 Jan 2010 02:07:16 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-14.tower-55.messagelabs.com!1263809231!89517617!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13497 invoked from network); 18 Jan 2010 10:07:12 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2010 10:07:12 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0IA7BEC026744 for ; Mon, 18 Jan 2010 03:07:11 -0700 (MST)
Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o0IA7BGW020443 for ; Mon, 18 Jan 2010 04:07:11 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o0IA7AWU020438 for ; Mon, 18 Jan 2010 04:07:10 -0600 (CST)
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, 18 Jan 2010 18:06:48 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>
In-Reply-To: <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqWcMIV3reIhddTSjafq4JSmxEusgBs9H3Q
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>
From: "Avasarala Ranjit-A20990" 
To: "Dean Willis" 
X-CFilter-Loop: Reflected
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 10:07:18 -0000

Hi Dean

The Call diversion architecture and service are explained in 3GPP TS
24.604.  So here the diversion service gets executed in the network by
the CSCFs or the Application Servers on behalf of the individual
subscribers. So here the UA(s) do not do the actual diversion, but set
rules on the server for triggering diversions.=20

So in this model, as users set several call diversion rules based on
several criteria like incoming caller identity or time of day, etc,
there are bound to be some errors in configuration. So in order to
convey the actual outcome of the diversion, there is a need to notify
the actual user i.e on whose behalf the diversion has occurred. This
notification information is expressed as an CDIV notification event
package which is the main purpose of this document.=20

The proposed CDIV notification information event package definition
conform to the standard event package template as defined in RFC 3265
and is applicable to CDIV service that gets executed in the server
rather than by individual User Agents.=20

Thanks and looking forward to more comments and directions to take this
work forward.

Regards
Ranjit

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]=20
Sent: Saturday, January 16, 2010 11:27 AM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> Hi John
>
> Completely agree with you. The subscribe requests will be towards the=20
> public AoR i.e alice@example. But the diversion rules could be set for

> specific registered contact Uris so that diversions for that=20
> particular URI are notified.

What isn't clear here is the underlying diversion architecture.

I believe John has in mind a model where each UA has local divert
capability; that is, it can receive an INVITE request and divert to
another location without the registrar having knowledge of this
diversion.
Thus, diversion subscriptions have to be serviced by the UAs themselves,
which are the notifiers. This means a "forked SUBSCRIBE" scenario with
multiple 200s, which is a bit messy (i.e., it isn't likely to work very
well).

However, the CDIV architecture as I understand it assumes diversion is
handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
first determines a routing for the INVITE to various contacts, then
executes diversion on a per-contact basis if needed. Consequently, the
S-CSCF has full knowledge of diversion status, and can serve as the
notifier for the diversion notification package. This all requires some
way for a UA to inform an S-CSCF to invoke diversion, which is outside
the scope of this document.

And this is exactly the description of architectural model that is
apparently not adequately disclosed in the draft, and probably should
be.

--
Dean

From john.elwell@siemens-enterprise.com  Mon Jan 18 02:23:33 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67963A683F for ; Mon, 18 Jan 2010 02:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzx8QPQKiK-q for ; Mon, 18 Jan 2010 02:23:32 -0800 (PST)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 73CB53A6405 for ; Mon, 18 Jan 2010 02:23:32 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-567818; Mon, 18 Jan 2010 11:23:28 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 14D5A23F0278; Mon, 18 Jan 2010 11:23:28 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jan 2010 11:23:27 +0100
From: "Elwell, John" 
To: Avasarala Ranjit-A20990 , Dean Willis 
Date: Mon, 18 Jan 2010 11:23:27 +0100
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqWcMIV3reIhddTSjafq4JSmxEusgBs9H3QAADIKCA=
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 10:23:33 -0000

Ranjit,

Thanks for your explanation. However, if the IETF is to publish an RFC on d=
iversion notification, it will need to relate it clearly to RFC 3262. So if=
 the scope is just notifications of diversions away from the original targe=
t AOR towards some other target AOR, I am comfortable. If it is to do with =
selection of an appropriate registered contact for the original target AOR,=
 I am uncomfortable and would require further explanation.

John

> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20
> Sent: 18 January 2010 10:07
> To: Dean Willis
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> Subject: RE: [dispatch] Comments=20
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Hi Dean
>=20
> The Call diversion architecture and service are explained in 3GPP TS
> 24.604.  So here the diversion service gets executed in the network by
> the CSCFs or the Application Servers on behalf of the individual
> subscribers. So here the UA(s) do not do the actual diversion, but set
> rules on the server for triggering diversions.=20
>=20
> So in this model, as users set several call diversion rules based on
> several criteria like incoming caller identity or time of day, etc,
> there are bound to be some errors in configuration. So in order to
> convey the actual outcome of the diversion, there is a need to notify
> the actual user i.e on whose behalf the diversion has occurred. This
> notification information is expressed as an CDIV notification event
> package which is the main purpose of this document.=20
>=20
> The proposed CDIV notification information event package definition
> conform to the standard event package template as defined in RFC 3265
> and is applicable to CDIV service that gets executed in the server
> rather than by individual User Agents.=20
>=20
> Thanks and looking forward to more comments and directions to=20
> take this
> work forward.
>=20
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Saturday, January 16, 2010 11:27 AM
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> > Hi John
> >
> > Completely agree with you. The subscribe requests will be=20
> towards the=20
> > public AoR i.e alice@example. But the diversion rules could=20
> be set for
>=20
> > specific registered contact Uris so that diversions for that=20
> > particular URI are notified.
>=20
> What isn't clear here is the underlying diversion architecture.
>=20
> I believe John has in mind a model where each UA has local divert
> capability; that is, it can receive an INVITE request and divert to
> another location without the registrar having knowledge of this
> diversion.
> Thus, diversion subscriptions have to be serviced by the UAs=20
> themselves,
> which are the notifiers. This means a "forked SUBSCRIBE" scenario with
> multiple 200s, which is a bit messy (i.e., it isn't likely to=20
> work very
> well).
>=20
> However, the CDIV architecture as I understand it assumes diversion is
> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
> first determines a routing for the INVITE to various contacts, then
> executes diversion on a per-contact basis if needed. Consequently, the
> S-CSCF has full knowledge of diversion status, and can serve as the
> notifier for the diversion notification package. This all=20
> requires some
> way for a UA to inform an S-CSCF to invoke diversion, which is outside
> the scope of this document.
>=20
> And this is exactly the description of architectural model that is
> apparently not adequately disclosed in the draft, and probably should
> be.
>=20
> --
> Dean
>=20
>=20
> =

From zhouzp@huawei.com  Mon Jan 18 04:55:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77CF3A6869 for ; Mon, 18 Jan 2010 04:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1PAc7pMitxy for ; Mon, 18 Jan 2010 04:55:53 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EF2123A67D7 for ; Mon, 18 Jan 2010 04:55:52 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWG0014418R37@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:55:39 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWG00M8Q18RUC@szxga03-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:55:39 +0800 (CST)
Received: from z54906b ([10.168.86.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWG00FPB18QF3@szxml04-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:55:39 +0800 (CST)
Date: Mon, 18 Jan 2010 20:55:38 +0800
From: zhipeng zhou 
In-reply-to: <20100116121848.907D73A6806@core3.amsl.com>
To: dispatch@ietf.org
Message-id: <000501ca983d$88dbbe90$1556a80a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcqWphEngoFSfaPPQ3KLk4mYGTii5QBl0PVg
Subject: [dispatch] Welcome your kind feedback at "draft-zhipeng-dispatch-dynamic-adaptation".
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 12:55:54 -0000

 Dear all,
 I like to ask for your concern that I have uploaded a new draft at
http://www.ietf.org/staging/draft-zhipeng-dispatch-dynamic-adaptation-00.txt

This work is concerning on the cluster of Servers and the scenario of
Three-Screen service.
I will be happy to know if you have interest on this topic and will be
thankful for your kind comments and suggestions.
Thanks very much.
Zhipeng Zhou 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
Sent: Saturday, January 16, 2010 8:19 PM
To: internet-drafts@ietf.org
Cc: zhouzp@huawei.com
Subject: Manual Post Requested for draft-zhipeng-dispatch-dynamic-adaptation

Manual Posting Requested for following Internet-Draft:

I-D Submission Tool URL:
https://datatracker.ietf.org/idst/status.cgi?submission_id=20614

Filename:	   draft-zhipeng-dispatch-dynamic-adaptation
Version:	   00
Staging URL:
http://www.ietf.org/staging/draft-zhipeng-dispatch-dynamic-adaptation-00.txt
Title:		   draft-zhipeng-dispatch-dynamic-adaptation
Creation_date:	   2010-01-16
WG ID:		   Individual Submission
Number_of_pages: 14
Abstract:
This document describes controls and service flow for Media Server on the
scenarios and requirements for dynamic adaptation of the terminal types,
media format and transport bit rate (Dynamic Bandwidth Allocation), etc.  To
fulfill the requirements above, an Adaptor entity is introduced in the
architecture in the case of the dynamic media adaptation.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other groups may also
distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 20, 2010.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of publication
of this document.  Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.  Code Components
extracted from this document must include Simplified BSD License text as
described in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License.

Submitter: Zhipeng Zhou (zhouzp@huawei.com)

Author(s):
Zhipeng Zhou, zhouzp@huawei.com

From john.elwell@siemens-enterprise.com  Mon Jan 18 05:18:02 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC1C3A68EF for ; Mon, 18 Jan 2010 05:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ6ikvRkoc5A for ; Mon, 18 Jan 2010 05:18:01 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E044A3A659B for ; Mon, 18 Jan 2010 05:18:00 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-571092; Mon, 18 Jan 2010 14:17:56 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 13D2F23F0278; Mon, 18 Jan 2010 14:17:56 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jan 2010 14:17:55 +0100
From: "Elwell, John" 
To: Volker Hilt , Gonzalo Camarillo 
Date: Mon, 18 Jan 2010 14:17:54 +0100
Thread-Topic: [dispatch] XML questions	about draft-ietf-sipping-media-policy-dataset-08
Thread-Index: AcqV89fjA+ZZeLoeQBmBQSJ+amBnHACTFinw
Message-ID: 
References: <1260393285.4277.31.camel@khone.us.nortel.com> <4B2A559F.9040606@ericsson.com> <4B508372.2030403@bell-labs.com>
In-Reply-To: <4B508372.2030403@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH 
Subject: Re: [dispatch] XML questions	about	draft-ietf-sipping-media-policy-dataset-08
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 13:18:03 -0000

This normatively references draft-ietf-sipping-profile-datasets. What is th=
e status of that draft - is it still being pursued?

John

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Volker Hilt
> Sent: 15 January 2010 15:02
> To: Gonzalo Camarillo
> Cc: DISPATCH
> Subject: Re: [dispatch] XML questions about=20
> draft-ietf-sipping-media-policy-dataset-08
>=20
> Gonzalo, All,
>=20
> the -08 version is now available at:
>=20
> http://www.ietf.org/id/draft-ietf-sipping-media-policy-dataset-08.txt
>=20
> Thanks,
>=20
> Volker
>=20
>=20
>=20
>=20
> Gonzalo Camarillo wrote:
> > Hi Volker,
> >=20
> > could you please submit 08 per Dale's email below so that=20
> people on this=20
> > list can follow the discussions? Right now, the last=20
> revision that was=20
> > submitted is 07:
> >=20
> >=20
> http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-07
> >=20
> > Thanks,
> >=20
> > Gonzalo
> >=20
> > Dale Worley wrote:
> >> I've edited my questions about the XML in
> >> draft-ietf-sipping-media-policy-dataset-08 into better=20
> order.  They are
> >> appended to this message.
> >>
> >> Dale
> >>=20
> --------------------------------------------------------------
> ---------------
> >> This is based on a copy of the
> >> draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a
> >> private directory.  Apparently, the -08 version was never=20
> published.
> >> I assume that the authors have an archival copy of -08. =20
> The MD5 of my
> >> copy of the text version of -08 (with LF as EOL) is
> >> dfd01da655ee324727a0f0fbe6ff69a8.
> >>
> >> - Section 1
> >>
> >> Are merging rules still needed?  We are no longer using
> >> session-policy-dataset, which required merging, but IIRC someone
> >> mentioned an additional need for merging.
> >>
> >> - Section 4.2
> >>
> >> Section 4.2 contains:
> >>
> >>    If a UA has an SDP offer as well as an answer [RFC3264]=20
> and wants to
> >>    create a session info document, the UA MUST use the=20
> answer to fill in
> >>    the elements of the session info document except for=20
> the remote-host-
> >>    port and local-host-port elements, which are taken from=20
> the remote
> >>    and local session description respectively.  The local session
> >>    description is the one created locally by the UA (i.e.,=20
> the offer if
> >>    the UA has initiated the offer/answer exchange).  The=20
> remote session
> >>    description is the one received from the remote UA.
> >>
> >>    If a UA has an SDP offer as well as an answer [RFC3264]=20
> and wants to
> >>    create a session info document, the UA MUST use the=20
> answer to fill in
> >>    the elements of the session info document except for=20
> the local-host-port
> >>    and remote-host-port elements, which are taken from the=20
> SDP generated
> >>    by the UA and the SDP received by the UA, respectively=20
> (regardless of
> >>    which is the offer and which is the answer).
> >>
> >> However, this process doesn't seem to allow for the=20
> possibility that
> >> the locally-provided and remote-provided SDP may differ. =20
> (Although I
> >> think the relevant differences are restricted to which=20
> codecs may be
> >> used.)  It seems that directionality attributes=20
> could/should be used
> >> to have the media-policy specify the admitted codecs in=20
> each direction
> >> appropriately.
> >>
> >> The specification of codecs in SDP is strange in that an answer may
> >> contain codecs that are not given in the offer, but they are not
> >> usable in the session.  How should they be encoded in session-info?
> >>
> >> Section 4.2 seems to envision that an offer SDP can be=20
> mapped into a
> >> media-policy, which can then be restricted or subsetted to=20
> give a new
> >> media-policy, which can then be translated into an answer SDP.  But
> >> the transformation of SDP into media-policy XML seems to lose the
> >> sequencing of the m=3D lines, in that there is no semantics specified
> >> for the  elements of a media-policy.  Perhaps the=20
> intention is
> >> that the  elements correspond in order to the m=3D lines, but
> >> that does not seem to be stated.
> >>
> >> Note that SDP can contain zero m=3D lines, which would seem=20
> to map to a
> >>  with a  with no .  But that is not
> >> allowed by 6.3.
> >>
> >> - Section 5
> >>
> >> Perhaps this change of wording would be clearer:
> >>
> >>    Session policy documents describe a policy for SIP=20
> sessions.  Session
> >>    policy documents are independent of >>any<< specific=20
> session description
> >>    and express general policies for SIP sessions.
> >>
> >> - Section 5.1
> >>
> >> The  element is not being used any more.
> >>
> >> - Section 6.2
> >>
> >> Section 6.2 says that at least one codec must be allowed per media
> >> type (see second sentence), but the correspondence between=20
> codec and
> >> media type isn't explicit, and it would be a difficult validity
> >> constraint to verify.  Also, the text does not specify=20
> that we're only
> >> concerned with media types that are admitted by the 
> >> element.  And worse, what if the  are a set-complement
> >> construction (excluded-policy=3D"allow"), in which case the set of
> >> admitted media-types is not knowable?  I would suggest removing the
> >> restriction, and understanding that an allowed media-type with no
> >> allowable codecs is unusable in practice.
> >>
> >> - Section 6.2.1.1
> >>
> >> The  and  elements want to specify the=20
> codec via a
> >> mime-type, but that isn't what SDP uses.  The translation=20
> between the
> >> two is described in RFC 4855 section 3, which should be referenced.
> >>
> >> - Section 6.3.1
> >>
> >> How are 0 port values encoded?  Semantically, it identifies a
> >> "sendonly" mode.  Should it be encoded as a zero value of
> >>  or (better) by appropriate direction attributes.
> >> In any case, this should be specified clearly to avoid=20
> interoperation
> >> problems.
> >>
> >> - Section 6.4
> >>
> >> Section 6.4 uses the phrase "sessions a UA may set up in parallel".
> >> Does this refer to the set of sessions for a single dialog?  Or the
> >> set of all sessions of all dialogs that the UA is=20
> participating in at
> >> one time?
> >>
> >> - Section 6.10
> >>
> >> Do we want  to be subordinate to ?  This is
> >> arguably a layer violation:   and  could be
> >> siblings under an element that declares that the policy=20
> applies to the
> >> context.  This allows  to have defined semantics, but
> >> allowing its containing element/message to determine what those
> >> semantics apply to.
> >>
> >> - Section 8
> >>
> >> The TBD note at the beginning of section 8 (and the task=20
> it described)
> >> can be removed now that sipping-profile-datasets has been=20
> abandoned.
> >>
> >> Where is the up-to-date version of "uaprofile.rng"?  What is the
> >> proper URL to access it?
> >>
> >> - Imported from ietf-sipping-profile-datasets
> >>
> >> The 'policy' and 'excluded-policy' attributes are quite grotty, as
> >> they can be used only in specific combinations among=20
> several related
> >> elements, and are quite verbose in any case.  It would be=20
> much better
> >> to define a "set" construct (to specify a finite set of permitted
> >> values) and a "set-complement" construct (to specify all values are
> >> permitted except a finite set of values).  These=20
> constructs have the
> >> same expressive power as the existing attributes.  E.g.:
> >>
> >>       
> >>         audio
> >>         video
> >>       
> >>       
> >>         
> >>           audio/G729
> >>         
> >>         
> >>           audio/G723
> >>         
> >>       
> >>
> >> becomes
> >>
> >>       
> >>         
> >> 	  audio
> >> 	  video
> >> 	
> >>       
> >>       
> >>         
> >> 	  
> >> 	    audio/G729
> >> 	  
> >> 	  
> >> 	    audio/G723
> >> 	  
> >>         
> >>       
> >>
> >> but correct usage of this form is much easier to describe=20
> in the schema.
> >>
> >> (Looking at the example, perhaps we want to replace the  and
> >>  elements with "set" and "set-complement"=20
> attributes
> >> on its parent element.  That is less mathematically pure,=20
> but has the
> >> same expressive power and is more terse.)
> >>
> >> As far as I can tell, there are nine "container" types=20
> which use the
> >> set/complement mechanism:
> >>
> >>     6.1  container of 
> >>     6.2 
> >>     6.3 
> >>     6.4 
> >>     6.5 
> >>     6.6 
> >>     6.7 
> >>     6.8 
> >>     6.9 
> >>
> >> The "direction" attribute seems to be weakly defined.  As=20
> far as I can
> >> tell, in a policy one can have, for any of the nine=20
> container types,
> >> (1) no element, (2) one element with the value "sendrecv", or (3)
> >> optionally one element with the value "sendonly" and optionally one
> >> element with the value "recvonly".  But this is not stated=20
> in either
> >> this draft or draft-petrie-sipping-profile-datasets and I=20
> might well
> >> be wrong.
> >>
> >> Also, if we still utilize merging, we need to state that=20
> case (2) is
> >> equivalent to duplicating the value, with one copy marked=20
> "sendonly"
> >> and one marked "recvonly", so that we have explicitly shown how to
> >> align two containers with direction attributes in order to merge
> >> (intersect) them.
> >>
> >> - Empty elements
> >>
> >> There are a lot of situations where it is sensible for an=20
> element to
> >> have zero sub-elements, in that the stated rules give a=20
> clear meaning
> >> to the element.  In particular, any "set" construct with=20
> zero elements
> >> permits nothing, and any "set-complement" construct with=20
> zero elements
> >> permits everything.  But most of the relevant elements=20
> (including all
> >> the container types) are defined to require at least one=20
> sub-element.
> >>
> >> However, there is currently a special case in section 4: It states
> >> that an empty  rejects a session.  (If it=20
> wasn't for the
> >> defined special case, a session with *no* streams would be=20
> admissible
> >> under this policy.)  It would be better if the "reject everything"
> >> state could be described in a different manner, so as to avoid the
> >> special case.
> >>
> >> - The word "container"
> >>
> >> Beware of the use of the word "container".  In the
> >> session-policy-dataset, "container" is (mostly) used to describe
> >> elements which inherit from .  I suggest that we
> >> restrict the use in media-policy-dataset in that way.
> >>
> >> Although now that we are removing session-policy-dataset,=20
> "container"
> >> is no longer defined by , but it still means the
> >> elements which carry "direction", "policy", etc.
> >>
> >> That change would require rewriting these paragraphs of 6.1:
> >>
> >>    The  element can only be used in session=20
> policy document
> >>    (i.e., inside the  >>element<<).
> >>
> >>    This element MAY have the following attributes (see=20
> Section 3.3):
> >>    direction, visibility, excluded-policy.
> >>
> >>    Multiple  elements MAY only be present in=20
> a 
> >>    element if each applies to a different set of streams (i.e., one
> >>     element for incoming and one for outgoing=20
> streams).
> >>    The  element MUST contain one or more 
> >>    elements.
> >>
> >> There may be other uses of "container" that should be changed.
> >>
> >> - "Registered" requirements
> >>
> >> In a number of places, parameters are required to have=20
> values that are
> >> appropriately registered.  On the face of it, this prevents
> >> experimental or private-use values from being used at all.  This is
> >> probably not what we intend.  Given that there is general=20
> knowledge of
> >> how to create private-use values, these registration requirements
> >> should just be deleted.
> >>
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From volker.hilt@alcatel-lucent.com  Mon Jan 18 05:54:44 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA033A68E6 for ; Mon, 18 Jan 2010 05:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtEJhwCpHhgp for ; Mon, 18 Jan 2010 05:54:42 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 877D33A68E0 for ; Mon, 18 Jan 2010 05:54:42 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o0IDsW57012141;  Mon, 18 Jan 2010 07:54:32 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0IDsW01019823; Mon, 18 Jan 2010 07:54:32 -0600 (CST)
Received: from [127.0.0.1] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 18 Jan 2010 07:54:32 -0600
Message-ID: <4B54680E.20909@bell-labs.com>
Date: Mon, 18 Jan 2010 08:54:22 -0500
From: Volker Hilt 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Elwell, John" 
References: <1260393285.4277.31.camel@khone.us.nortel.com>	<4B2A559F.9040606@ericsson.com> <4B508372.2030403@bell-labs.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: DISPATCH 
Subject: Re: [dispatch] XML questions	about	draft-ietf-sipping-media-policy-dataset-08
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 13:54:44 -0000

John,

no, it is not. We're preparing a new version that will remove this
reference.

Thanks,

Volker

Elwell, John wrote:
> This normatively references draft-ietf-sipping-profile-datasets. What is the status of that draft - is it still being pursued?
> 
> John
> 
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Volker Hilt
>> Sent: 15 January 2010 15:02
>> To: Gonzalo Camarillo
>> Cc: DISPATCH
>> Subject: Re: [dispatch] XML questions about
>> draft-ietf-sipping-media-policy-dataset-08
>>
>> Gonzalo, All,
>>
>> the -08 version is now available at:
>>
>> http://www.ietf.org/id/draft-ietf-sipping-media-policy-dataset-08.txt
>>
>> Thanks,
>>
>> Volker
>>
>>
>>
>>
>> Gonzalo Camarillo wrote:
>>> Hi Volker,
>>>
>>> could you please submit 08 per Dale's email below so that
>> people on this
>>> list can follow the discussions? Right now, the last
>> revision that was
>>> submitted is 07:
>>>
>>>
>> http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-07
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>> Dale Worley wrote:
>>>> I've edited my questions about the XML in
>>>> draft-ietf-sipping-media-policy-dataset-08 into better
>> order.  They are
>>>> appended to this message.
>>>>
>>>> Dale
>>>>
>> --------------------------------------------------------------
>> ---------------
>>>> This is based on a copy of the
>>>> draft-ietf-sipping-media-policy-dataset-08 draft, which I have in a
>>>> private directory.  Apparently, the -08 version was never
>> published.
>>>> I assume that the authors have an archival copy of -08.
>> The MD5 of my
>>>> copy of the text version of -08 (with LF as EOL) is
>>>> dfd01da655ee324727a0f0fbe6ff69a8.
>>>>
>>>> - Section 1
>>>>
>>>> Are merging rules still needed?  We are no longer using
>>>> session-policy-dataset, which required merging, but IIRC someone
>>>> mentioned an additional need for merging.
>>>>
>>>> - Section 4.2
>>>>
>>>> Section 4.2 contains:
>>>>
>>>>    If a UA has an SDP offer as well as an answer [RFC3264]
>> and wants to
>>>>    create a session info document, the UA MUST use the
>> answer to fill in
>>>>    the elements of the session info document except for
>> the remote-host-
>>>>    port and local-host-port elements, which are taken from
>> the remote
>>>>    and local session description respectively.  The local session
>>>>    description is the one created locally by the UA (i.e.,
>> the offer if
>>>>    the UA has initiated the offer/answer exchange).  The
>> remote session
>>>>    description is the one received from the remote UA.
>>>>
>>>>    If a UA has an SDP offer as well as an answer [RFC3264]
>> and wants to
>>>>    create a session info document, the UA MUST use the
>> answer to fill in
>>>>    the elements of the session info document except for
>> the local-host-port
>>>>    and remote-host-port elements, which are taken from the
>> SDP generated
>>>>    by the UA and the SDP received by the UA, respectively
>> (regardless of
>>>>    which is the offer and which is the answer).
>>>>
>>>> However, this process doesn't seem to allow for the
>> possibility that
>>>> the locally-provided and remote-provided SDP may differ.
>> (Although I
>>>> think the relevant differences are restricted to which
>> codecs may be
>>>> used.)  It seems that directionality attributes
>> could/should be used
>>>> to have the media-policy specify the admitted codecs in
>> each direction
>>>> appropriately.
>>>>
>>>> The specification of codecs in SDP is strange in that an answer may
>>>> contain codecs that are not given in the offer, but they are not
>>>> usable in the session.  How should they be encoded in session-info?
>>>>
>>>> Section 4.2 seems to envision that an offer SDP can be
>> mapped into a
>>>> media-policy, which can then be restricted or subsetted to
>> give a new
>>>> media-policy, which can then be translated into an answer SDP.  But
>>>> the transformation of SDP into media-policy XML seems to lose the
>>>> sequencing of the m= lines, in that there is no semantics specified
>>>> for the  elements of a media-policy.  Perhaps the
>> intention is
>>>> that the  elements correspond in order to the m= lines, but
>>>> that does not seem to be stated.
>>>>
>>>> Note that SDP can contain zero m= lines, which would seem
>> to map to a
>>>>  with a  with no .  But that is not
>>>> allowed by 6.3.
>>>>
>>>> - Section 5
>>>>
>>>> Perhaps this change of wording would be clearer:
>>>>
>>>>    Session policy documents describe a policy for SIP
>> sessions.  Session
>>>>    policy documents are independent of >>any<< specific
>> session description
>>>>    and express general policies for SIP sessions.
>>>>
>>>> - Section 5.1
>>>>
>>>> The  element is not being used any more.
>>>>
>>>> - Section 6.2
>>>>
>>>> Section 6.2 says that at least one codec must be allowed per media
>>>> type (see second sentence), but the correspondence between
>> codec and
>>>> media type isn't explicit, and it would be a difficult validity
>>>> constraint to verify.  Also, the text does not specify
>> that we're only
>>>> concerned with media types that are admitted by the 
>>>> element.  And worse, what if the  are a set-complement
>>>> construction (excluded-policy="allow"), in which case the set of
>>>> admitted media-types is not knowable?  I would suggest removing the
>>>> restriction, and understanding that an allowed media-type with no
>>>> allowable codecs is unusable in practice.
>>>>
>>>> - Section 6.2.1.1
>>>>
>>>> The  and  elements want to specify the
>> codec via a
>>>> mime-type, but that isn't what SDP uses.  The translation
>> between the
>>>> two is described in RFC 4855 section 3, which should be referenced.
>>>>
>>>> - Section 6.3.1
>>>>
>>>> How are 0 port values encoded?  Semantically, it identifies a
>>>> "sendonly" mode.  Should it be encoded as a zero value of
>>>>  or (better) by appropriate direction attributes.
>>>> In any case, this should be specified clearly to avoid
>> interoperation
>>>> problems.
>>>>
>>>> - Section 6.4
>>>>
>>>> Section 6.4 uses the phrase "sessions a UA may set up in parallel".
>>>> Does this refer to the set of sessions for a single dialog?  Or the
>>>> set of all sessions of all dialogs that the UA is
>> participating in at
>>>> one time?
>>>>
>>>> - Section 6.10
>>>>
>>>> Do we want  to be subordinate to ?  This is
>>>> arguably a layer violation:   and  could be
>>>> siblings under an element that declares that the policy
>> applies to the
>>>> context.  This allows  to have defined semantics, but
>>>> allowing its containing element/message to determine what those
>>>> semantics apply to.
>>>>
>>>> - Section 8
>>>>
>>>> The TBD note at the beginning of section 8 (and the task
>> it described)
>>>> can be removed now that sipping-profile-datasets has been
>> abandoned.
>>>> Where is the up-to-date version of "uaprofile.rng"?  What is the
>>>> proper URL to access it?
>>>>
>>>> - Imported from ietf-sipping-profile-datasets
>>>>
>>>> The 'policy' and 'excluded-policy' attributes are quite grotty, as
>>>> they can be used only in specific combinations among
>> several related
>>>> elements, and are quite verbose in any case.  It would be
>> much better
>>>> to define a "set" construct (to specify a finite set of permitted
>>>> values) and a "set-complement" construct (to specify all values are
>>>> permitted except a finite set of values).  These
>> constructs have the
>>>> same expressive power as the existing attributes.  E.g.:
>>>>
>>>>       
>>>>         audio
>>>>         video
>>>>       
>>>>       
>>>>         
>>>>           audio/G729
>>>>         
>>>>         
>>>>           audio/G723
>>>>         
>>>>       
>>>>
>>>> becomes
>>>>
>>>>       
>>>>         
>>>>      audio
>>>>      video
>>>>    
>>>>       
>>>>       
>>>>         
>>>>      
>>>>        audio/G729
>>>>      
>>>>      
>>>>        audio/G723
>>>>      
>>>>         
>>>>       
>>>>
>>>> but correct usage of this form is much easier to describe
>> in the schema.
>>>> (Looking at the example, perhaps we want to replace the  and
>>>>  elements with "set" and "set-complement"
>> attributes
>>>> on its parent element.  That is less mathematically pure,
>> but has the
>>>> same expressive power and is more terse.)
>>>>
>>>> As far as I can tell, there are nine "container" types
>> which use the
>>>> set/complement mechanism:
>>>>
>>>>     6.1  container of 
>>>>     6.2 
>>>>     6.3 
>>>>     6.4 
>>>>     6.5 
>>>>     6.6 
>>>>     6.7 
>>>>     6.8 
>>>>     6.9 
>>>>
>>>> The "direction" attribute seems to be weakly defined.  As
>> far as I can
>>>> tell, in a policy one can have, for any of the nine
>> container types,
>>>> (1) no element, (2) one element with the value "sendrecv", or (3)
>>>> optionally one element with the value "sendonly" and optionally one
>>>> element with the value "recvonly".  But this is not stated
>> in either
>>>> this draft or draft-petrie-sipping-profile-datasets and I
>> might well
>>>> be wrong.
>>>>
>>>> Also, if we still utilize merging, we need to state that
>> case (2) is
>>>> equivalent to duplicating the value, with one copy marked
>> "sendonly"
>>>> and one marked "recvonly", so that we have explicitly shown how to
>>>> align two containers with direction attributes in order to merge
>>>> (intersect) them.
>>>>
>>>> - Empty elements
>>>>
>>>> There are a lot of situations where it is sensible for an
>> element to
>>>> have zero sub-elements, in that the stated rules give a
>> clear meaning
>>>> to the element.  In particular, any "set" construct with
>> zero elements
>>>> permits nothing, and any "set-complement" construct with
>> zero elements
>>>> permits everything.  But most of the relevant elements
>> (including all
>>>> the container types) are defined to require at least one
>> sub-element.
>>>> However, there is currently a special case in section 4: It states
>>>> that an empty  rejects a session.  (If it
>> wasn't for the
>>>> defined special case, a session with *no* streams would be
>> admissible
>>>> under this policy.)  It would be better if the "reject everything"
>>>> state could be described in a different manner, so as to avoid the
>>>> special case.
>>>>
>>>> - The word "container"
>>>>
>>>> Beware of the use of the word "container".  In the
>>>> session-policy-dataset, "container" is (mostly) used to describe
>>>> elements which inherit from .  I suggest that we
>>>> restrict the use in media-policy-dataset in that way.
>>>>
>>>> Although now that we are removing session-policy-dataset,
>> "container"
>>>> is no longer defined by , but it still means the
>>>> elements which carry "direction", "policy", etc.
>>>>
>>>> That change would require rewriting these paragraphs of 6.1:
>>>>
>>>>    The  element can only be used in session
>> policy document
>>>>    (i.e., inside the  >>element<<).
>>>>
>>>>    This element MAY have the following attributes (see
>> Section 3.3):
>>>>    direction, visibility, excluded-policy.
>>>>
>>>>    Multiple  elements MAY only be present in
>> a 
>>>>    element if each applies to a different set of streams (i.e., one
>>>>     element for incoming and one for outgoing
>> streams).
>>>>    The  element MUST contain one or more 
>>>>    elements.
>>>>
>>>> There may be other uses of "container" that should be changed.
>>>>
>>>> - "Registered" requirements
>>>>
>>>> In a number of places, parameters are required to have
>> values that are
>>>> appropriately registered.  On the face of it, this prevents
>>>> experimental or private-use values from being used at all.  This is
>>>> probably not what we intend.  Given that there is general
>> knowledge of
>>>> how to create private-use values, these registration requirements
>>>> should just be deleted.
>>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>

From drage@alcatel-lucent.com  Mon Jan 18 06:05:14 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BEF3A672F; Mon, 18 Jan 2010 06:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=1.053,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn9nhz6fXwMe; Mon, 18 Jan 2010 06:05:14 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CFEF03A6778; Mon, 18 Jan 2010 06:05:13 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0IDo9MX017016 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Jan 2010 15:05:05 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 18 Jan 2010 15:04:34 +0100
From: "DRAGE, Keith (Keith)" 
To: Gonzalo Camarillo , "Hilt, Volker (Volker)" 
Date: Mon, 18 Jan 2010 15:04:32 +0100
Thread-Topic: [dispatch] Chartering SIP Overload
Thread-Index: AcqV89AA79g/BrwHQAi3XXLOVzs8XgCUyaaQ
Message-ID: 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com>
In-Reply-To: <4B50836A.4020607@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83
Cc: DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 14:05:15 -0000

I am worried that we are raising the bar on standards track documents.

I am certainly aware that some of the mechanisms described in the documents=
 have been prototyped and have been shown to work. With that, the documenta=
tion merits standards track deliverables.

regards

Keith=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> Sent: Friday, January 15, 2010 3:02 PM
> To: Hilt, Volker (Volker)
> Cc: DISPATCH; sip-overload@ietf.org
> Subject: Re: [dispatch] Chartering SIP Overload
>=20
> Hi,
>=20
> > I'm worried that we are taking yet another detour which=20
> will further=20
> > delay the process.
>=20
> this would not delay the process in any way. If something, it=20
> could speed it up, because the requirements to review=20
> Experimental RFCs are lower than to review standards track=20
> RFCs... at the end of the day, I do not expect this to=20
> influence the time it takes to publish the specs because I am=20
> sure the group will make sure the quality of the specs as=20
> high as for a standards-track RFC.
>=20
> Cheers,
>=20
> Gonzalo
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From zhouzp@huawei.com  Mon Jan 18 04:42:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9CB3A67F3 for ; Mon, 18 Jan 2010 04:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7RW0yuqShav for ; Mon, 18 Jan 2010 04:42:53 -0800 (PST)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E46D13A672F for ; Mon, 18 Jan 2010 04:42:52 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWG003IZ0N24R@szxga02-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:42:39 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWG00F010N2SF@szxga02-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:42:38 +0800 (CST)
Received: from z54906b ([10.168.86.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWG00FK00N2F3@szxml04-in.huawei.com> for dispatch@ietf.org; Mon, 18 Jan 2010 20:42:38 +0800 (CST)
Date: Mon, 18 Jan 2010 20:42:38 +0800
From: zhipeng zhou 
In-reply-to: <20100116121848.907D73A6806@core3.amsl.com>
To: dispatch@ietf.org
Message-id: <003d01ca983b$b7cc9190$1556a80a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcqWphEngoFSfaPPQ3KLk4mYGTii5QBlPNsA
X-Mailman-Approved-At: Mon, 18 Jan 2010 07:52:12 -0800
Cc: 'Spencer Dawkins' 
Subject: [dispatch] Welcome your kind comments on my "draft-zhipeng-dispatch-dynamic-adaptation".
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 12:42:54 -0000

 Dear all,
 I like to ask for your concern that I have uploaded a new draft at

http://www.ietf.org/staging/draft-zhipeng-dispatch-dynamic-adaptation-00.txt

This work is concern on the cluster of Servers and the scenario of
Three-Screen service.
I will be happy to know if you have interest on this topic and will be
thankful for your kind comments and suggestions.
Thanks very much.
Zhipeng Zhou 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
Sent: Saturday, January 16, 2010 8:19 PM
To: internet-drafts@ietf.org
Cc: zhouzp@huawei.com
Subject: Manual Post Requested for draft-zhipeng-dispatch-dynamic-adaptation

Manual Posting Requested for following Internet-Draft:

I-D Submission Tool URL:
https://datatracker.ietf.org/idst/status.cgi?submission_id=20614

Filename:	   draft-zhipeng-dispatch-dynamic-adaptation
Version:	   00
Staging URL:
http://www.ietf.org/staging/draft-zhipeng-dispatch-dynamic-adaptation-00.txt
Title:		   draft-zhipeng-dispatch-dynamic-adaptation
Creation_date:	   2010-01-16
WG ID:		   Individual Submission
Number_of_pages: 14
Abstract:
This document describes controls and service flow for Media Server on the
scenarios and requirements for dynamic adaptation of the terminal types,
media format and transport bit rate (Dynamic Bandwidth Allocation), etc.  To
fulfill the requirements above, an Adaptor entity is introduced in the
architecture in the case of the dynamic media adaptation.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that other groups may also
distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 20, 2010.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of publication
of this document.  Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.  Code Components
extracted from this document must include Simplified BSD License text as
described in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License.

Submitter: Zhipeng Zhou (zhouzp@huawei.com)

Author(s):
Zhipeng Zhou, zhouzp@huawei.com

From dean.willis@softarmor.com  Mon Jan 18 10:09:07 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3B33A68E6; Mon, 18 Jan 2010 10:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh1yK9LXIfhD; Mon, 18 Jan 2010 10:09:07 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 142183A6877; Mon, 18 Jan 2010 10:09:07 -0800 (PST)
Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0II8q0U022892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jan 2010 12:08:55 -0600
Message-Id: <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com>
From: Dean Willis 
To: "DRAGE, Keith (Keith)" 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 18 Jan 2010 12:08:47 -0600
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com> 
X-Mailer: Apple Mail (2.936)
Cc: "Hilt, Volker \(Volker\)" , DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 18:09:07 -0000

On Jan 18, 2010, at 8:04 AM, DRAGE, Keith (Keith) wrote:

> I am worried that we are raising the bar on standards track documents.
>
> I am certainly aware that some of the mechanisms described in the  
> documents have been prototyped and have been shown to work. With  
> that, the documentation merits standards track deliverables.

Judging from the number of "We have implemented this" responses, it  
might almost be ready to go from Proposed to Draft Standard.

--
Dean

From hgs@cs.columbia.edu  Mon Jan 18 10:25:24 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD21B3A69C9; Mon, 18 Jan 2010 10:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJvXIwYKfh3S; Mon, 18 Jan 2010 10:25:24 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D74AE3A6947; Mon, 18 Jan 2010 10:25:23 -0800 (PST)
Received: from new-host.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0IIPHca021724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jan 2010 13:25:17 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne 
In-Reply-To: <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com>
Date: Mon, 18 Jan 2010 13:25:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E40C0DE-34E3-4F12-A1DE-F3C03CE4103A@cs.columbia.edu>
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com> <4B50836A.4020607@ericsson.com>  <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com>
To: Dean Willis 
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: "Hilt, Volker \(Volker\)" , DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 18:25:24 -0000

In addition, if multiple, independent simulations, published in =
peer-reviewed conferences, are no longer sufficient for standards-track =
designation, I'm at a bit of a loss to figure out what more any =
algorithm-containing protocol spec should do to avoid the "experimental" =
label. We constantly complain that we can't move specs up the maturity =
ladder; now, we can't even get *on* the ladder...

Henning

On Jan 18, 2010, at 1:08 PM, Dean Willis wrote:

>=20
> On Jan 18, 2010, at 8:04 AM, DRAGE, Keith (Keith) wrote:
>=20
>> I am worried that we are raising the bar on standards track =
documents.
>>=20
>> I am certainly aware that some of the mechanisms described in the =
documents have been prototyped and have been shown to work. With that, =
the documentation merits standards track deliverables.
>=20
> Judging from the number of "We have implemented this" responses, it =
might almost be ready to go from Proposed to Draft Standard.
>=20
> --
> Dean
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From spencer@wonderhamster.org  Mon Jan 18 10:57:12 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313593A68FD; Mon, 18 Jan 2010 10:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAkutHLq9YVd; Mon, 18 Jan 2010 10:57:11 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 4B84A3A67FB; Mon, 18 Jan 2010 10:57:11 -0800 (PST)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lnghj-1O3XEu1TkF-00hsAi; Mon, 18 Jan 2010 13:57:03 -0500
Message-ID: <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com>
From: "Spencer Dawkins" 
To: "Dean Willis" , "DRAGE, Keith \(Keith\)" 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com> <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com>
Date: Mon, 18 Jan 2010 12:56:32 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1/GJthCw7kcTYRQJilo0/pE3Lx8J9QJljHyzNt TUPl+RnEN2VxnuHLZVaYj+i7goyPd3LXzaYySQ/8H4f0EKcZlM vjAUfyKqG1qGhZwHDlQQcKNvwar/0HM8/pD+dyqRHA=
Cc: "Hilt, Volker \(Volker\)" , DISPATCH , sip-overload@ietf.org, Lars Eggert 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 18:57:12 -0000

Just following up here...

I sent a private e-mail to Robert, Lars and Magnus that might better have 
gone to the mailing list ...

My point was that

- I understand why TSV detours congestion avoidance drafts through 
Experimental, because we already have congestion avoidance mechanisms that 
actually work, so we should be cautious about dorking with them, but

- our standards-track SIP overload mechanisms have already been observed to 
fail on multiple live networks (I've heard this from two tier-one 
operators), so

- it seems appropriate to use a less restrictive strategy here - we 
shouldn't encourage people to ignore our maturity levels completely, and we 
shouldn't use our maturity levels to encourage people to continue deploying 
standards-track mechanisms that have already been observed to fail, and are 
not self-correcting when they fail, on production networks.

That fails the "first, do no harm" test. IMO, of course.

Spencer, whose first working group was a TSV-classic working group (PILC 
with Aaron Falk), and whose first RFC credit was on TCP congestion avoidance 
behavior ("TCP over Satellite", edited by Mark Allman)

>
> On Jan 18, 2010, at 8:04 AM, DRAGE, Keith (Keith) wrote:
>
>> I am worried that we are raising the bar on standards track documents.
>>
>> I am certainly aware that some of the mechanisms described in the 
>> documents have been prototyped and have been shown to work. With  that, 
>> the documentation merits standards track deliverables.
>
> Judging from the number of "We have implemented this" responses, it  might 
> almost be ready to go from Proposed to Draft Standard.
>
> --
> Dean
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch 

From bernard_aboba@hotmail.com  Mon Jan 18 11:08:41 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B19A3A690B for ; Mon, 18 Jan 2010 11:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.145
X-Spam-Level: 
X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95zhs-y6jXpR for ; Mon, 18 Jan 2010 11:08:37 -0800 (PST)
Received: from blu0-omc4-s16.blu0.hotmail.com (blu0-omc4-s16.blu0.hotmail.com [65.55.111.155]) by core3.amsl.com (Postfix) with ESMTP id 0F35D3A6834 for ; Mon, 18 Jan 2010 11:08:36 -0800 (PST)
Received: from BLU137-DS7 ([65.55.111.137]) by blu0-omc4-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 11:08:33 -0800
X-Originating-IP: [131.107.0.104]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: "Bernard Aboba" 
To: 
Date: Mon, 18 Jan 2010 11:08:33 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0676_01CA982E.930534F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqYcaDulmDEXiWdS8Wlr6i0S3I4VA==
Content-Language: en-us
X-OriginalArrivalTime: 18 Jan 2010 19:08:33.0955 (UTC) FILETIME=[A15EC730:01CA9871]
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 19:08:41 -0000

------=_NextPart_000_0676_01CA982E.930534F0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Henning said:

"In addition, if multiple, independent simulations, published in
peer-reviewed conferences, are no longer sufficient for standards-track
designation, I'm at a bit of a loss to figure out what more any
algorithm-containing protocol spec should do to avoid the "experimental"
label. We constantly complain that we can't move specs up the maturity
ladder; now, we can't even get *on* the ladder..."

[BA] Experimental RFCs can subsequently be placed on the standards track,
based on implementation evidence.  This is routinely done in the Transport
Area, for example.  

IMHO, the major difference between "Experimental" and "Proposed" in this
particular case would be whether the algorithm is considered safe for mass
deployment on the Internet.   If we have enough information from existing
implementations to know that there is no potential for congestive collapse
or other catastrophic failures, then the document should be allowed to be
published as a Proposed Standard.  Rather than writing this into the
charter, the WG and IESG could be allowed to make the determination based on
the evidence presented within the WG.  The process for making this judgment
is relatively well established (at least within the Transport Area). 

------=_NextPart_000_0676_01CA982E.930534F0
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Henning said:

“In addition, if multiple, independent =
simulations,
published in peer-reviewed conferences, are no longer sufficient for
standards-track designation, I'm at a bit of a loss to figure out what =
more any
algorithm-containing protocol spec should do to avoid the
"experimental" label. We constantly complain that we can't =
move specs
up the maturity ladder; now, we can't even get *on* the =
ladder...”

[BA] Experimental RFCs can subsequently be =
placed on the
standards track, based on implementation evidence.  This is =
routinely done
in the Transport Area, for example.  

IMHO, the major difference between =
“Experimental”
and “Proposed” in this particular case would be whether the
algorithm is considered safe for mass deployment on the Internet.  =
 If
we have enough information from existing implementations to know that =
there is no
potential for congestive collapse or other catastrophic failures, then =
the
document should be allowed to be published as a Proposed Standard. =
 Rather
than writing this into the charter, the WG and IESG could be allowed to =
make
the determination based on the evidence presented within the WG.  =
The
process for making this judgment is relatively well established (at =
least
within the Transport Area). 

------=_NextPart_000_0676_01CA982E.930534F0--

From jmpolk@cisco.com  Mon Jan 18 11:21:11 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C864D3A6916 for ; Mon, 18 Jan 2010 11:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.724
X-Spam-Level: 
X-Spam-Status: No, score=-10.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoLYCX8AjgG7 for ; Mon, 18 Jan 2010 11:21:10 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BEEDB3A68C1 for ; Mon, 18 Jan 2010 11:21:10 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8FAKdDVEurR7H+/2dsb2JhbACHBLoylBiEMwQ
X-IronPort-AV: E=Sophos;i="4.49,298,1262563200"; d="scan'208";a="75895024"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2010 19:21:07 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0IJL2gM029844; Mon, 18 Jan 2010 19:21:07 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 11:21:04 -0800
Received: from jmpolk-wxp01.cisco.com ([10.89.8.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 11:21:03 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 18 Jan 2010 13:21:01 -0600
To: "Bernard Aboba" , 
From: "James M. Polk" 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 18 Jan 2010 19:21:03.0891 (UTC) FILETIME=[605DEE30:01CA9873]
Cc: Lars Eggert 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 19:21:12 -0000

At 01:08 PM 1/18/2010, Bernard Aboba wrote:
>Content-Type: multipart/alternative;
>         boundary="----=_NextPart_000_0676_01CA982E.930534F0"
>Content-Language: en-us
>
>Henning said:
>
>"In addition, if multiple, independent simulations, published in 
>peer-reviewed conferences, are no longer sufficient for 
>standards-track designation, I'm at a bit of a loss to figure out 
>what more any algorithm-containing protocol spec should do to avoid 
>the "experimental" label. We constantly complain that we can't move 
>specs up the maturity ladder; now, we can't even get *on* the ladder..."
>
>[BA] Experimental RFCs can subsequently be placed on the standards 
>track, based on implementation evidence.  This is routinely done in 
>the Transport Area, for example.
>
>IMHO, the major difference between "Experimental" and "Proposed" in 
>this particular case would be whether the algorithm is considered 
>safe for mass deployment on the Internet.   If we have enough 
>information from existing implementations to know that there is no 
>potential for congestive collapse or other catastrophic failures, 
>then the document should be allowed to be published as a Proposed 
>Standard.  Rather than writing this into the charter, the WG and 
>IESG could be allowed to make the determination based on the 
>evidence presented within the WG.  The process for making this 
>judgment is relatively well established (at least within the Transport Area).

Bernard

Transport is focus on congestion, sure, but it is focused on 
congestion when a protocol can't do anything about the congestion 
(i.e., something has to be done because the protocol can't react 
appropriately on its own to address or solve congestion -- for 
something like HTTP or FTP, not about TCP vs UDP).

Overload effort is what can be done in SIP to help alleviate the TCP 
vs UDP issues at a SIP entity.  I'd argue that isn't so much about 
TCP or SCTP or DCCP or UDP -- would you?

As far as the protocol is concerned, a SIP server (whether it is 
experiencing congestion or not) is a destination entity, not a 
transit entity like a classic router. That makes this scenario wrt 
Overload special, if not unique compared to other transport protocols.

I don't believe it ought to be treated or thought of in the same 
light as other transport solutions to congestion.

>_______________________________________________
>dispatch mailing list
>dispatch@ietf.org
>https://www.ietf.org/mailman/listinfo/dispatch

From volker.hilt@alcatel-lucent.com  Mon Jan 18 13:25:46 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC1C3A68AB for ; Mon, 18 Jan 2010 13:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7nd9RPHpAF5 for ; Mon, 18 Jan 2010 13:25:45 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5615D3A677C for ; Mon, 18 Jan 2010 13:25:45 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o0ILPc9Q015018 for ; Mon, 18 Jan 2010 15:25:38 -0600 (CST)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0ILPcZT015238 for ; Mon, 18 Jan 2010 15:25:38 -0600 (CST)
Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 18 Jan 2010 15:25:38 -0600
Message-ID: <4B54D16C.1000403@bell-labs.com>
Date: Mon, 18 Jan 2010 16:23:56 -0500
From: Volker Hilt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: DISPATCH 
Content-Type: multipart/mixed; boundary="------------010902000902090805040600"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: [dispatch] Fwd: Re:  Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 21:25:46 -0000

--------------010902000902090805040600
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Re-sending to DISPATCH.

--------------010902000902090805040600
Content-Type: message/rfc822;
	name="Re: [dispatch] Chartering SIP Overload.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Re: [dispatch] Chartering SIP Overload.eml"

From: Volker Hilt 
To: Lars Eggert 
CC: Spencer Dawkins , Dean Willis
	, "DRAGE, Keith (Keith)"
	, DISPATCH ,
	"sip-overload@ietf.org" , Magnus Westerlund

Date: Mon, 18 Jan 2010 14:06:19 -0600
Subject: Re: [dispatch] Chartering SIP Overload
Thread-Topic: [dispatch] Chartering SIP Overload
Message-ID: <4B54BF3B.3020802@alcatel-lucent.com>
References: <4B505018.7020504@ericsson.com>
  <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com>
  <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com>
 <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com>
 <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
In-Reply-To: <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5)
 Gecko/20091204 Thunderbird/3.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Lars,

here is a list of papers on SIP overload that are referenced in=20
http://tools.ietf.org/html/draft-ietf-sipping-overload-design-02:
- Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP=20
Servers", IEEE International Conference on Network Protocols (ICNP'08),=20
Orlando, Florida, October 2008.
- Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP=20
Based VoIP Networks Under Overload", International Teletraffic Congress=20
(ITC'07), Ottawa, Canada, June 2007.
- Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol=20
(SIP) Server Overload Control: Design and Evaluation, Principles",=20
Systems and Applications of IP Telecommunications (IPTComm'08),=20
Heidelberg, Germany, July 2008.

More papers are referenced in these papers.

In addition, there were presentations at IETF meetings including
- IETF 74 SIPPING=20
(http://www.ietf.org/proceedings/74/slides/sipping-11/sipping-11.htm),
- IETF 73 SIPPING=20
(http://www.ietf.org/proceedings/73/slides/sipping-8/sipping-8.htm),
- IETF 71 TSVAREA=20
(http://www.ietf.org/proceedings/71/slides/tsvarea-3/tsvarea-3.htm)

Volker

On 1/18/2010 2:17 PM, Lars Eggert wrote:
> Hi,
>
> could someone send me a pointer to the latest experimental or
> simulation results for the various proposed mechanisms? I want to
> make sure I've seen the latest data.
>
> I'm not on this list, so apologies if I have missed this.
>
> On 2010-1-18, at 20:56, Spencer Dawkins wrote:
>> - it seems appropriate to use a less restrictive strategy here -
>> we shouldn't encourage people to ignore our maturity levels
>> completely, and we shouldn't use our maturity levels to encourage
>> people to continue deploying standards-track mechanisms that have
>> already been observed to fail, and are not self-correcting when
>> they fail, on production networks.
>
> I fully agree that the proposed mechanisms (that I've seen) are
> better than what we currently have (which is almost nothing.) I'm by
> no means opposed to doing this work. It's also extremely encouraging
> that these mechanisms are actively being developed, analyzed,
> deployed and monitored.
>
> My main concern in a nutshell is: Do we have have one mechanism of
> which we are confident that it (1) operates very well in many
> deployment scenarios, (2) degrades gracefully (i.e., doesn't
> oscillate, etc.) in cases where it doesn't work very well and (3) is
> never worse than what we currently have?
>
> If we do, then PS is appropriate. If we don't, then IMO publishing PS
> sends the wrong signal to deployers.
>
> I've personally not seen enough data to convince me of (1) and (2) -
> but maybe I've missed some work, hence the request at the beginning
> of the email.
>
> Lars

--------------010902000902090805040600--

From lars.eggert@nokia.com  Mon Jan 18 11:18:10 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F0D3A659C; Mon, 18 Jan 2010 11:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfATJBaUZVo9; Mon, 18 Jan 2010 11:18:09 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 61EB73A67DA; Mon, 18 Jan 2010 11:18:09 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IJHx9f032675; Mon, 18 Jan 2010 13:18:00 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 21:17:59 +0200
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 21:17:59 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IJHulO007966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 21:17:57 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-5--80254844; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert 
In-Reply-To: <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com>
Date: Mon, 18 Jan 2010 21:17:50 +0200
Message-Id: <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com> <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com> <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com>
To: Spencer Dawkins 
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 18 Jan 2010 21:17:50 +0200 (EET)
X-OriginalArrivalTime: 18 Jan 2010 19:17:59.0082 (UTC) FILETIME=[F23650A0:01CA9872]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Mon, 18 Jan 2010 14:05:37 -0800
Cc: DISPATCH , "sip-overload@ietf.org" , "Hilt, Volker \(Volker\)" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 19:18:10 -0000

--Apple-Mail-5--80254844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

could someone send me a pointer to the latest experimental or simulation =
results for the various proposed mechanisms? I want to make sure I've =
seen the latest data.

I'm not on this list, so apologies if I have missed this.

On 2010-1-18, at 20:56, Spencer Dawkins wrote:
> - it seems appropriate to use a less restrictive strategy here - we=20
> shouldn't encourage people to ignore our maturity levels completely, =
and we=20
> shouldn't use our maturity levels to encourage people to continue =
deploying=20
> standards-track mechanisms that have already been observed to fail, =
and are=20
> not self-correcting when they fail, on production networks.

I fully agree that the proposed mechanisms (that I've seen) are better =
than what we currently have (which is almost nothing.) I'm by no means =
opposed to doing this work. It's also extremely encouraging that these =
mechanisms are actively being developed, analyzed, deployed and =
monitored.

My main concern in a nutshell is: Do we have have one mechanism of which =
we are confident that it (1) operates very well in many deployment =
scenarios, (2) degrades gracefully (i.e., doesn't oscillate, etc.) in =
cases where it doesn't work very well and (3) is never worse than what =
we currently have?

If we do, then PS is appropriate. If we don't, then IMO publishing PS =
sends the wrong signal to deployers.

I've personally not seen enough data to convince me of (1) and (2) - but =
maybe I've missed some work, hence the request at the beginning of the =
email.

Lars=

--Apple-Mail-5--80254844
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw
ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X
uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY
Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB
6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT
VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr
ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu
ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt
I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H
5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80
QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7
n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw
QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl
ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M
Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP
6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTEwMDExODE5MTc1MFowIwYJKoZIhvcNAQkEMRYEFI4o3iwd4iHiUO9uPjknCFFWD3GiMIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD
QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF
AASCAQDMGTwvu61UTLBpttaSX5OWww2bUyoKr3VaGBqMgHSeTohb5YLq4GMVl5vzB0DGG81T/zlu
VbfFJGXgiCEi9SxXfIVfVdTpt1tL3cElM3khNB+O4FLkwfRRUqu0I1GOtrC+dt8epxHFoKu4664S
FzHeyAPyv9ceBl6fLLGJ9qCvJxKV8l3fD86UhUaDFz2OwAWPKKP95pKZma7irr0yhJOmgLohJomJ
IGB8L45YcGF2vvrwDpJFA1l6k4tuXQ0hJXhVXwyl9KqqIp9OvhJ8k+LqiICmNRvWAWSe7TI9rVtN
rvUua8vM35gjryLvcADmSLuVsn+GRmvwES/fbLHO3PYNAAAAAAAA

--Apple-Mail-5--80254844--

From lars.eggert@nokia.com  Mon Jan 18 11:46:50 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EC53A677D for ; Mon, 18 Jan 2010 11:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdtmOofrVZ-x for ; Mon, 18 Jan 2010 11:46:49 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4EA073A6817 for ; Mon, 18 Jan 2010 11:46:49 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IJkUJt002781; Mon, 18 Jan 2010 21:46:38 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Jan 2010 21:46:34 +0200
Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 21:46:34 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0IJkWOP030703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jan 2010 21:46:32 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-8--78542254; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert 
In-Reply-To: 
Date: Mon, 18 Jan 2010 21:46:22 +0200
Message-Id: 
References:  
To: "James M. Polk" 
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 18 Jan 2010 21:46:23 +0200 (EET)
X-OriginalArrivalTime: 18 Jan 2010 19:46:34.0655 (UTC) FILETIME=[F0C5FAF0:01CA9876]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Mon, 18 Jan 2010 14:05:37 -0800
Cc: Bernard Aboba , "dispatch@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 19:46:50 -0000

--Apple-Mail-8--78542254
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

after reading Bernard's email below, I believe we're making the same =
argument using different words.

Some comments below.

On 2010-1-18, at 21:21, James M. Polk wrote:
> At 01:08 PM 1/18/2010, Bernard Aboba wrote:
>> Henning said:
>>=20
>> "In addition, if multiple, independent simulations, published in=20
>> peer-reviewed conferences, are no longer sufficient for=20
>> standards-track designation, I'm at a bit of a loss to figure out=20
>> what more any algorithm-containing protocol spec should do to avoid=20=

>> the "experimental" label. We constantly complain that we can't move=20=

>> specs up the maturity ladder; now, we can't even get *on* the =
ladder..."

It's never been the case that research work, even a very substantial =
effort with multiple simulations and several solid academic publications =
such as the SIP overload work, is somehow preordained for standards =
track publication.

>> [BA] Experimental RFCs can subsequently be placed on the standards=20
>> track, based on implementation evidence.  This is routinely done in=20=

>> the Transport Area, for example.
>>=20
>> IMHO, the major difference between "Experimental" and "Proposed" in=20=

>> this particular case would be whether the algorithm is considered=20
>> safe for mass deployment on the Internet.   If we have enough=20
>> information from existing implementations to know that there is no=20
>> potential for congestive collapse or other catastrophic failures,=20
>> then the document should be allowed to be published as a Proposed=20
>> Standard.

Exactly.

>>  Rather than writing this into the charter, the WG and=20
>> IESG could be allowed to make the determination based on the=20
>> evidence presented within the WG.  The process for making this=20
>> judgment is relatively well established (at least within the =
Transport Area).

I could agree to this approach.=20

(I'm guessing below is what James wrote?)

> Transport is focus on congestion, sure, but it is focused on=20
> congestion when a protocol can't do anything about the congestion=20
> (i.e., something has to be done because the protocol can't react=20
> appropriately on its own to address or solve congestion -- for=20
> something like HTTP or FTP, not about TCP vs UDP).
>=20
> Overload effort is what can be done in SIP to help alleviate the TCP=20=

> vs UDP issues at a SIP entity.  I'd argue that isn't so much about=20
> TCP or SCTP or DCCP or UDP -- would you?

I don't follow. Congestion control is about building a control loop for =
a flow, and doing it in a way such that the entire system (=3D many =
congestion controlled flows) is stable.

The SIP overload work is doing something very similar, except that it's =
trying to control the volume of SIP messages being exchanged between =
servers.

> As far as the protocol is concerned, a SIP server (whether it is=20
> experiencing congestion or not) is a destination entity, not a=20
> transit entity like a classic router. That makes this scenario wrt=20
> Overload special, if not unique compared to other transport protocols.

No, the fact that it's an endpoint at the SIP layer makes this EXACTLY =
like the transport congestion control problem. (Just one level up in the =
stack.)

> I don't believe it ought to be treated or thought of in the same=20
> light as other transport solutions to congestion.

I want to make clear that I wasn't the person who started drawing =
analogies to transport protocols. There are obvious similarities, =
because both mechanisms build control loops, but that is not a reason to =
blindly adopt some standardization "rules" here that we are doing over =
in TSV for congestion control, and that's not at all why I raised the =
issue I raised.

(I realize that I spent the last few paragraphs talking about congestion =
control, but that's because I'm disagreeing what what you wrote about =
congestion control, and not because I think we should simply apply the =
"rules" we use for congestion control standardization to SIP overload.)

In Bernard's words, the issue is that I'm unconvinced that we've seen =
sufficient evidence at this time to decide whether the SIP overload =
mechanism is safe for mass deployment.=20

Lars

--Apple-Mail-8--78542254
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw
ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X
uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY
Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB
6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT
VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr
ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu
ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt
I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H
5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80
QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7
n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw
QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl
ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M
Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP
6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTEwMDExODE5NDYyM1owIwYJKoZIhvcNAQkEMRYEFJmray2lEuRBTwx0CgZBWTK3+kZiMIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD
QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF
AASCAQA7z/+eo0gbBQOUi8GJdbIMuKfSyKH0Z/NkLszEqLnmQL2Zg/m60ztb1dHmjfOd8ic63gBx
TU4tlfm0UOjtagL7QYpLFyghzzTVqKMWI0l84rcFW6lj4Ai0/Jdii4KII38PC2PUYiPXSx8KSPQh
35NOZaZd/U3F3x1yAII91JJ43ZLfAnm2fSUByJo8IpG7d3FSGsqgJWxD7bmFtp8WPXFxqGmaqJ8T
fY9f55kkkkXRJ0HbV7n6yz4Ub2y64PY3BX67o5R4WvCsYo1EqRquHkJB0JtxnEbgaEvURx9N7Xun
UNDhibTivfYUmev+U26Djoq3aQM8/7w/4g1eBDKNhElFAAAAAAAA

--Apple-Mail-8--78542254--

From volker.hilt@alcatel-lucent.com  Mon Jan 18 12:08:09 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2C53A67E1; Mon, 18 Jan 2010 12:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4FWXauneHGX; Mon, 18 Jan 2010 12:08:08 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 62D0D3A67ED; Mon, 18 Jan 2010 12:08:08 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o0IK82xo029521;  Mon, 18 Jan 2010 14:08:02 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o0IK82rH018886; Mon, 18 Jan 2010 14:08:02 -0600 (CST)
Received: from [135.112.131.79] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 18 Jan 2010 14:08:01 -0600
Message-ID: <4B54BF3B.3020802@alcatel-lucent.com>
Date: Mon, 18 Jan 2010 15:06:19 -0500
From: Volker Hilt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Lars Eggert 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com> <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com> <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com> <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
In-Reply-To: <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Mailman-Approved-At: Mon, 18 Jan 2010 14:05:37 -0800
Cc: DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 20:08:09 -0000

Lars,

here is a list of papers on SIP overload that are referenced in 
http://tools.ietf.org/html/draft-ietf-sipping-overload-design-02:
- Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP 
Servers", IEEE International Conference on Network Protocols (ICNP'08), 
Orlando, Florida, October 2008.
- Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP 
Based VoIP Networks Under Overload", International Teletraffic Congress 
(ITC'07), Ottawa, Canada, June 2007.
- Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol 
(SIP) Server Overload Control: Design and Evaluation, Principles", 
Systems and Applications of IP Telecommunications (IPTComm'08), 
Heidelberg, Germany, July 2008.

More papers are referenced in these papers.

In addition, there were presentations at IETF meetings including
- IETF 74 SIPPING 
(http://www.ietf.org/proceedings/74/slides/sipping-11/sipping-11.htm),
- IETF 73 SIPPING 
(http://www.ietf.org/proceedings/73/slides/sipping-8/sipping-8.htm),
- IETF 71 TSVAREA 
(http://www.ietf.org/proceedings/71/slides/tsvarea-3/tsvarea-3.htm)

Volker

On 1/18/2010 2:17 PM, Lars Eggert wrote:
> Hi,
>
> could someone send me a pointer to the latest experimental or
> simulation results for the various proposed mechanisms? I want to
> make sure I've seen the latest data.
>
> I'm not on this list, so apologies if I have missed this.
>
> On 2010-1-18, at 20:56, Spencer Dawkins wrote:
>> - it seems appropriate to use a less restrictive strategy here -
>> we shouldn't encourage people to ignore our maturity levels
>> completely, and we shouldn't use our maturity levels to encourage
>> people to continue deploying standards-track mechanisms that have
>> already been observed to fail, and are not self-correcting when
>> they fail, on production networks.
>
> I fully agree that the proposed mechanisms (that I've seen) are
> better than what we currently have (which is almost nothing.) I'm by
> no means opposed to doing this work. It's also extremely encouraging
> that these mechanisms are actively being developed, analyzed,
> deployed and monitored.
>
> My main concern in a nutshell is: Do we have have one mechanism of
> which we are confident that it (1) operates very well in many
> deployment scenarios, (2) degrades gracefully (i.e., doesn't
> oscillate, etc.) in cases where it doesn't work very well and (3) is
> never worse than what we currently have?
>
> If we do, then PS is appropriate. If we don't, then IMO publishing PS
> sends the wrong signal to deployers.
>
> I've personally not seen enough data to convince me of (1) and (2) -
> but maybe I've missed some work, hence the request at the beginning
> of the email.
>
> Lars

From hgs@cs.columbia.edu  Mon Jan 18 14:43:13 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EE23A67F4; Mon, 18 Jan 2010 14:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCxINmobn4GJ; Mon, 18 Jan 2010 14:43:12 -0800 (PST)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 407813A67D1; Mon, 18 Jan 2010 14:43:12 -0800 (PST)
Received: from upstairs.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0IMh4In014825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jan 2010 17:43:04 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne 
In-Reply-To: <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
Date: Mon, 18 Jan 2010 17:43:04 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4B505018.7020504@ericsson.com> <4B507FD9.4010407@bell-labs.com><4B50836A.4020607@ericsson.com> <465AE87E-B62B-4EC0-A68F-1F5ABD6F5D88@softarmor.com> <3E7B24A71C33413CAE1B6F3D02EBD251@china.huawei.com> <4F5CCE81-E5E6-4550-A737-A33E78F77F36@nokia.com>
To: Lars Eggert 
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6
Cc: "Hilt, Volker \(Volker\)" , DISPATCH , "sip-overload@ietf.org" 
Subject: Re: [dispatch] Chartering SIP Overload
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2010 22:43:13 -0000

>=20
> I fully agree that the proposed mechanisms (that I've seen) are better =
than what we currently have (which is almost nothing.) I'm by no means =
opposed to doing this work. It's also extremely encouraging that these =
mechanisms are actively being developed, analyzed, deployed and =
monitored.
>=20
> My main concern in a nutshell is: Do we have have one mechanism of =
which we are confident that it (1) operates very well in many deployment =
scenarios, (2) degrades gracefully (i.e., doesn't oscillate, etc.) in =
cases where it doesn't work very well and (3) is never worse than what =
we currently have?

I don't see how you can prove a negative, even if we simulate (or =
implement) for another ten years. There's always the theoretical =
possibility that some constellation of the moon and the operating system =
will cause undesirable behavior. Thus, your bar is provably impossible =
to meet.

That said, I think the proponents of various congestion control =
mechanisms can indeed do a better job describing the inherent limitation =
of some of the algorithms. In particular, the issue is with cases of a =
very large number of upstream proxies (say, hundreds to thousands). Just =
as with flow control, you can design for inherent safety, but there's a =
limit of how many active connections you can allow. In a UDP-based =
system where all the world's proxies can theoretically conspire to send =
a SIP INVITE to the "victim" at 5 pm EST today, no SIP congestion =
control can help since the "victim" can't know that universe of senders. =
But TCP (or SCTP) has exactly the same problem, at connection setup. =
This is one instance of the SIP avalanche problem discussed separately, =
but which hasn't received as much attention.

Thus, I think the problem is more usefully scoped, we might make more =
progress and limit what needs to be evaluated.

>=20
> If we do, then PS is appropriate. If we don't, then IMO publishing PS =
sends the wrong signal to deployers.
>=20
> I've personally not seen enough data to convince me of (1) and (2) - =
but maybe I've missed some work, hence the request at the beginning of =
the email.

It would be more productive, I think, if there was a concrete set of =
benchmarks or test cases. In general, not reflecting your particular =
remarks, I find the typical review remark of "the authors of paper X =
should do more measurements" rather unhelpful.

In response to another email: The analogy to congestion control is only =
helpful to a limited extent, in my view. The system (and algorithms) are =
much closer to TCP flow control, since you don't have the third party =
effects ("cross traffic") and the primary limitation is avoiding buffer =
overflow (or, rather, SIP timer triggering, which amounts to roughly the =
same thing).

Henning

>=20
> Lars_______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From L.Liess@telekom.de  Tue Jan 19 02:19:40 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B863A680D for ; Tue, 19 Jan 2010 02:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypYGm+vHUIgn for ; Tue, 19 Jan 2010 02:19:39 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id EBFF43A6A50 for ; Tue, 19 Jan 2010 02:19:38 -0800 (PST)
Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 19 Jan 2010 11:19:30 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 11:19:29 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 19 Jan 2010 11:19:27 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>
In-reply-to: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqVK2zByx0wUKjQRz+ZDHm3u4nKrQADSDaAACxTTEA=
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com> 
From: 
To: , , 
X-OriginalArrivalTime: 19 Jan 2010 10:19:29.0391 (UTC) FILETIME=[E28C77F0:01CA98F0]
Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 10:19:40 -0000

Hi,=20

I think if we can show that having the same identifier for both use
cases has unacceptable consequences we can say that we need two diferent
identifiers.
If I understood the draft-loreto-sipping-dialog-correlation-01
correctly, my feeling is that we get a lot of problems if we try to use
the same identifier for both Session-ID and Dialog-correlation
(Same-Session).  =20

Let's assume we have a same identifier, called Correlation-ID , which
plays both roles, Session-ID and Same-Session. =20

Consequence nr. 1)=20
Significant performance reduction in UAS.=20

When Correlation-ID in it's Session-ID role becomes implemented, every
INVITE received by every UAS will contain a Correlation-ID. The UAS will
have to  search for existing dialogs related to the received
Correlation-ID. For Gateways or Application Servers, this can be very
CPU consuming. They must search for related dialogs for every received
INVITE. If we have two identifiers are different, in most cases the UAS
receives only the Session-ID which it just copies into the Respose. The
search is done only for the use cases described in the dialog-corelation
draft. =20

So I would propose following additional requirenment for the Session-ID
Header:=20
"The mechanism should not lead to unnecessary performance reduction at
the UAS."
This requirement is not fulfilled if we have the same identifier.=20

Consequence nr. 2)

Imprecise monitoring results

Consider the scenario in chapter 4
draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
B2BUA between Alice and Bob and the service provider monitors the trafic
E2E.  The trubleshooting people will want to distinguish which messages
belong to the phone call and which messages belong to  the video call. =20

Alice
Bob

UA_A
-----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>UA_B
=20
Correlation-ID_a
                                                          (based on
call-ID_a)    =20
                                                       =20
=20

   =20
UA_C
-----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>UA_B
          Correlation-ID_a
Correlation-ID_a
         (based on call-ID_a)                         (based on
call-ID_a)

 =20

Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
B2BUA constructs the Correlation-ID_a based on the Call-ID_a.=20
Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
correlated to the existing phone call and the UA_B constructs the
Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
Correlation-ID_a to the UA_B transparently. Because both messages
between the B2BUA and UA_B have the same Correlation-ID, the monitoring
equipment will not be able to distinguish which message belongs to which
call.      =20

So I would propose following additional requirenment for the Session-ID
Header:=20

"Different E2E SIP sessions must have different identifiers."=20

I also would add following Requirement to Session-ID:=20

"It must be possible to use the identifier without upgrading the end
devices software."=20
This requirement is met by the Session-ID proposal but it is not
explicitely stated in the draft.=20

Additional personal opinions on the correlation-draft:
- I think the Same-Session will is usefull for troubleshooting and
should be standardized.=20

- The Same-Session header should use the Session-ID instead of the
call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
change it. (I hope there are no conflicts here with the tags.) =20
=20

Thanks  a lot
Laura

From spencer@wonderhamster.org  Tue Jan 19 05:47:15 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB17D28C0D7 for ; Tue, 19 Jan 2010 05:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.443,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUGbyWVWprRH for ; Tue, 19 Jan 2010 05:47:14 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id ADBE928B23E for ; Tue, 19 Jan 2010 05:47:14 -0800 (PST)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lfkck-1ODObf2I6E-00pAIu; Tue, 19 Jan 2010 08:47:00 -0500
Message-ID: <07947D5B55A44B2DB402AF9122B65A00@china.huawei.com>
From: "Spencer Dawkins" 
To: , , 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>  <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>
Date: Tue, 19 Jan 2010 07:46:39 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1+PvANRE38TC+BzPUuW+tmChXH84H6l85uPNiC pplxDmZKk+miOPlKdC8k2a5CrO4tQZdd9o/EcF9o77yuIZIMw6 D6UxBN+UfbGB2piGS//xoKCdyRnDhuLs4evF9dy6pQ=
Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 13:47:16 -0000

Hi, Laura,

Just to make sure I understand - are you saying something like "The 
mechanism should not lead to performance reduction at the UAS for dialogs 
that are not correlated with other dialogs."?

(I'm just trying to be more precise about "unnecessary performance 
reduction")

If so, that makes sense to me.

Thanks,

Spencer

----- Original Message ----- 
From: 
To: ; ; 

Cc: ; ; 

Sent: Tuesday, January 19, 2010 4:19 AM
Subject: RE: [dispatch] FW: 
I-DAction:draft-kaplan-dispatch-session-id-00.txt

Hi,

I think if we can show that having the same identifier for both use
cases has unacceptable consequences we can say that we need two diferent
identifiers.
If I understood the draft-loreto-sipping-dialog-correlation-01
correctly, my feeling is that we get a lot of problems if we try to use
the same identifier for both Session-ID and Dialog-correlation
(Same-Session).

Let's assume we have a same identifier, called Correlation-ID , which
plays both roles, Session-ID and Same-Session.

Consequence nr. 1)
Significant performance reduction in UAS.

When Correlation-ID in it's Session-ID role becomes implemented, every
INVITE received by every UAS will contain a Correlation-ID. The UAS will
have to  search for existing dialogs related to the received
Correlation-ID. For Gateways or Application Servers, this can be very
CPU consuming. They must search for related dialogs for every received
INVITE. If we have two identifiers are different, in most cases the UAS
receives only the Session-ID which it just copies into the Respose. The
search is done only for the use cases described in the dialog-corelation
draft.

So I would propose following additional requirenment for the Session-ID
Header:
"The mechanism should not lead to unnecessary performance reduction at
the UAS."
This requirement is not fulfilled if we have the same identifier.

Consequence nr. 2)

Imprecise monitoring results

Consider the scenario in chapter 4
draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
B2BUA between Alice and Bob and the service provider monitors the trafic
E2E.  The trubleshooting people will want to distinguish which messages
belong to the phone call and which messages belong to  the video call.

Alice
Bob

UA_A
-----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>UA_B

Correlation-ID_a
                                                          (based on
call-ID_a)

UA_C
-----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>UA_B
          Correlation-ID_a
Correlation-ID_a
         (based on call-ID_a)                         (based on
call-ID_a)

Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
B2BUA constructs the Correlation-ID_a based on the Call-ID_a.
Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
correlated to the existing phone call and the UA_B constructs the
Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
Correlation-ID_a to the UA_B transparently. Because both messages
between the B2BUA and UA_B have the same Correlation-ID, the monitoring
equipment will not be able to distinguish which message belongs to which
call.

So I would propose following additional requirenment for the Session-ID
Header:

"Different E2E SIP sessions must have different identifiers."

I also would add following Requirement to Session-ID:

"It must be possible to use the identifier without upgrading the end
devices software."
This requirement is met by the Session-ID proposal but it is not
explicitely stated in the draft.

Additional personal opinions on the correlation-draft:
- I think the Same-Session will is usefull for troubleshooting and
should be standardized.

- The Same-Session header should use the Session-ID instead of the
call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
change it. (I hope there are no conflicts here with the tags.)

Thanks  a lot
Laura 

From pkyzivat@cisco.com  Tue Jan 19 06:32:14 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BDB3A6A76 for ; Tue, 19 Jan 2010 06:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.43
X-Spam-Level: 
X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.169,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55j+Jc-NybQQ for ; Tue, 19 Jan 2010 06:32:13 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 256A53A693A for ; Tue, 19 Jan 2010 06:32:13 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALdQVUurR7Hu/2dsb2JhbADCV5UThDME
X-IronPort-AV: E=Sophos;i="4.49,303,1262563200"; d="scan'208";a="469237826"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2010 14:32:09 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0JEW9aK007981 for ; Tue, 19 Jan 2010 14:32:09 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 08:32:09 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 08:32:09 -0600
Message-ID: <4B55C268.9070300@cisco.com>
Date: Tue, 19 Jan 2010 09:32:08 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Anders Kristensen 
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>	<4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com> <4B52154A.5040107@cisco.com>
In-Reply-To: <4B52154A.5040107@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jan 2010 14:32:09.0187 (UTC) FILETIME=[2E7DC330:01CA9914]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Comments	requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 14:32:14 -0000

Anders Kristensen wrote:
> Instead of emphasizing and clarifying how this work is 3gpp specific it 
> might be better to focus on how to make it more generally applicable (or 
> palatable, if you prefer). ISTM that at its core this could be generally 
> useful and need not be tied to 3gpp. The result may be somewhat 
> different from what's in the current draft, but it can serve as a 
> starting point.

I agree that something along these lines could be generally useful.
But providing this sort of functionality does impose some constraints on 
the overall system architecture to ensure that there is some entity that 
can serve as notifier that has access to the requested information. (Its 
certainly possible to construct useful sip-based systems that do 
diversion that don't have that property.)

So there is some question whether there is interest in standardizing 
such an architecture, beyond what is already being done for IMS.

If there is not such interest, then I see no reason to object to this 
draft, as long as it is properly scoped as to its applicability.

	Thanks,
	Paul

> Anders
> 
> On 1/15/2010 9:56 PM, Dean Willis wrote:
>> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
>>> Hi John
>>>
>>> Completely agree with you. The subscribe requests will be towards the
>>> public AoR i.e alice@example. But the diversion rules could be set for
>>> specific registered contact Uris so that diversions for that particular
>>> URI are notified.
>>
>> What isn't clear here is the underlying diversion architecture.
>>
>> I believe John has in mind a model where each UA has local divert
>> capability; that is, it can receive an INVITE request and divert to
>> another location without the registrar having knowledge of this 
>> diversion.
>> Thus, diversion subscriptions have to be serviced by the UAs themselves,
>> which are the notifiers. This means a "forked SUBSCRIBE" scenario with
>> multiple 200s, which is a bit messy (i.e., it isn't likely to work very
>> well).
>>
>> However, the CDIV architecture as I understand it assumes diversion is
>> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
>> first determines a routing for the INVITE to various contacts, then
>> executes diversion on a per-contact basis if needed. Consequently, the
>> S-CSCF has full knowledge of diversion status, and can serve as the
>> notifier for the diversion notification package. This all requires some
>> way for a UA to inform an S-CSCF to invoke diversion, which is outside 
>> the
>> scope of this document.
>>
>> And this is exactly the description of architectural model that is
>> apparently not adequately disclosed in the draft, and probably should be.
>>
>> -- 
>> Dean
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From ranjit@motorola.com  Tue Jan 19 09:49:31 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3CF3A6AD7 for ; Tue, 19 Jan 2010 09:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFIOxaI3eXGH for ; Tue, 19 Jan 2010 09:49:30 -0800 (PST)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 3DF153A6A82 for ; Tue, 19 Jan 2010 09:49:30 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-3.tower-55.messagelabs.com!1263923360!12880781!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [136.182.1.13]
Received: (qmail 31243 invoked from network); 19 Jan 2010 17:49:21 -0000
Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-3.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jan 2010 17:49:21 -0000
Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o0JHnFNY000121 for ; Tue, 19 Jan 2010 10:49:20 -0700 (MST)
Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o0JHnFGj005126 for ; Tue, 19 Jan 2010 11:49:15 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o0JHnDmI005089 for ; Tue, 19 Jan 2010 11:49:14 -0600 (CST)
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: Wed, 20 Jan 2010 01:48:51 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqWcMIV3reIhddTSjafq4JSmxEusgBs9H3QAADIKCAAQdmLYA==
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com> 
From: "Avasarala Ranjit-A20990" 
To: "Elwell, John" , "Dean Willis" 
X-CFilter-Loop: Reflected
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 17:49:31 -0000

Hi John

Sorry for the late response. Yes the notifications will be from the
server towards the original AoR with the registered contact specified as
part of the event package (e.g in the element "diverting-user"). So it
would be the job of the notifier to generate appropriate diversion
notification information towards the target AoR.

Thanks

Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20
Sent: Monday, January 18, 2010 3:53 PM
To: Avasarala Ranjit-A20990; Dean Willis
Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
Subject: RE: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

Ranjit,

Thanks for your explanation. However, if the IETF is to publish an RFC
on diversion notification, it will need to relate it clearly to RFC
3262. So if the scope is just notifications of diversions away from the
original target AOR towards some other target AOR, I am comfortable. If
it is to do with selection of an appropriate registered contact for the
original target AOR, I am uncomfortable and would require further
explanation.

John

> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
> Sent: 18 January 2010 10:07
> To: Dean Willis
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> Subject: RE: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Hi Dean
>=20
> The Call diversion architecture and service are explained in 3GPP TS=20
> 24.604.  So here the diversion service gets executed in the network by

> the CSCFs or the Application Servers on behalf of the individual=20
> subscribers. So here the UA(s) do not do the actual diversion, but set

> rules on the server for triggering diversions.
>=20
> So in this model, as users set several call diversion rules based on=20
> several criteria like incoming caller identity or time of day, etc,=20
> there are bound to be some errors in configuration. So in order to=20
> convey the actual outcome of the diversion, there is a need to notify=20
> the actual user i.e on whose behalf the diversion has occurred. This=20
> notification information is expressed as an CDIV notification event=20
> package which is the main purpose of this document.
>=20
> The proposed CDIV notification information event package definition=20
> conform to the standard event package template as defined in RFC 3265=20
> and is applicable to CDIV service that gets executed in the server=20
> rather than by individual User Agents.
>=20
> Thanks and looking forward to more comments and directions to take=20
> this work forward.
>=20
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Saturday, January 16, 2010 11:27 AM
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> > Hi John
> >
> > Completely agree with you. The subscribe requests will be
> towards the
> > public AoR i.e alice@example. But the diversion rules could
> be set for
>=20
> > specific registered contact Uris so that diversions for that=20
> > particular URI are notified.
>=20
> What isn't clear here is the underlying diversion architecture.
>=20
> I believe John has in mind a model where each UA has local divert=20
> capability; that is, it can receive an INVITE request and divert to=20
> another location without the registrar having knowledge of this=20
> diversion.
> Thus, diversion subscriptions have to be serviced by the UAs=20
> themselves, which are the notifiers. This means a "forked SUBSCRIBE"=20
> scenario with multiple 200s, which is a bit messy (i.e., it isn't=20
> likely to work very well).
>=20
> However, the CDIV architecture as I understand it assumes diversion is

> handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF=20
> first determines a routing for the INVITE to various contacts, then=20
> executes diversion on a per-contact basis if needed. Consequently, the

> S-CSCF has full knowledge of diversion status, and can serve as the=20
> notifier for the diversion notification package. This all requires=20
> some way for a UA to inform an S-CSCF to invoke diversion, which is=20
> outside the scope of this document.
>=20
> And this is exactly the description of architectural model that is=20
> apparently not adequately disclosed in the draft, and probably should=20
> be.
>=20
> --
> Dean
>=20
>=20
>=20

From john.elwell@siemens-enterprise.com  Tue Jan 19 10:05:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB8B3A6908 for ; Tue, 19 Jan 2010 10:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEkgCGrWvrG1 for ; Tue, 19 Jan 2010 10:05:36 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DBFFF3A68B3 for ; Tue, 19 Jan 2010 10:05:32 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-591426; Tue, 19 Jan 2010 19:05:27 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F24CB23F0278; Tue, 19 Jan 2010 19:05:26 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 19 Jan 2010 19:05:26 +0100
From: "Elwell, John" 
To: Avasarala Ranjit-A20990 , Dean Willis 
Date: Tue, 19 Jan 2010 19:05:26 +0100
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqWcMIV3reIhddTSjafq4JSmxEusgBs9H3QAADIKCAAQdmLYAAAlv7A
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 18:05:37 -0000

=20

> -----Original Message-----
> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20
> Sent: 19 January 2010 17:49
> To: Elwell, John; Dean Willis
> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> Subject: RE: [dispatch] Comments=20
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Hi John
>=20
> Sorry for the late response. Yes the notifications will be from the
> server towards the original AoR with the registered contact=20
> specified as
> part of the event package (e.g in the element "diverting-user"). So it
> would be the job of the notifier to generate appropriate diversion
> notification information towards the target AoR.
[JRE] This just confuses me again. It first says the notification will be s=
ent from the server to the original AOR, and then it says notification info=
rmation is send towards the target AOR - apparently a contradiction, unless=
 these two terms mean the same thing. Also, why is the registered contact (=
I assume this means contact URI) sent in element "diverting-user" rather th=
an the original AOR?

John

>=20
> Thanks
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20
> Sent: Monday, January 18, 2010 3:53 PM
> To: Avasarala Ranjit-A20990; Dean Willis
> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> Subject: RE: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Ranjit,
>=20
> Thanks for your explanation. However, if the IETF is to publish an RFC
> on diversion notification, it will need to relate it clearly to RFC
> 3262. So if the scope is just notifications of diversions=20
> away from the
> original target AOR towards some other target AOR, I am=20
> comfortable. If
> it is to do with selection of an appropriate registered=20
> contact for the
> original target AOR, I am uncomfortable and would require further
> explanation.
>=20
> John
>=20
>=20
> > -----Original Message-----
> > From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
> > Sent: 18 January 2010 10:07
> > To: Dean Willis
> > Cc: Elwell, John; Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> > Subject: RE: [dispatch] Comments
> > requestedondraft-avasarala-dispatch-comm-div-notification
> >=20
> > Hi Dean
> >=20
> > The Call diversion architecture and service are explained=20
> in 3GPP TS=20
> > 24.604.  So here the diversion service gets executed in the=20
> network by
>=20
> > the CSCFs or the Application Servers on behalf of the individual=20
> > subscribers. So here the UA(s) do not do the actual=20
> diversion, but set
>=20
> > rules on the server for triggering diversions.
> >=20
> > So in this model, as users set several call diversion rules=20
> based on=20
> > several criteria like incoming caller identity or time of day, etc,=20
> > there are bound to be some errors in configuration. So in order to=20
> > convey the actual outcome of the diversion, there is a need=20
> to notify=20
> > the actual user i.e on whose behalf the diversion has=20
> occurred. This=20
> > notification information is expressed as an CDIV notification event=20
> > package which is the main purpose of this document.
> >=20
> > The proposed CDIV notification information event package definition=20
> > conform to the standard event package template as defined=20
> in RFC 3265=20
> > and is applicable to CDIV service that gets executed in the server=20
> > rather than by individual User Agents.
> >=20
> > Thanks and looking forward to more comments and directions to take=20
> > this work forward.
> >=20
> >=20
> >=20
> > Regards
> > Ranjit
> >=20
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Saturday, January 16, 2010 11:27 AM
> > To: Avasarala Ranjit-A20990
> > Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
> > Subject: Re: [dispatch] Comments
> > requestedondraft-avasarala-dispatch-comm-div-notification
> >=20
> > On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
> > > Hi John
> > >
> > > Completely agree with you. The subscribe requests will be
> > towards the
> > > public AoR i.e alice@example. But the diversion rules could
> > be set for
> >=20
> > > specific registered contact Uris so that diversions for that=20
> > > particular URI are notified.
> >=20
> > What isn't clear here is the underlying diversion architecture.
> >=20
> > I believe John has in mind a model where each UA has local divert=20
> > capability; that is, it can receive an INVITE request and divert to=20
> > another location without the registrar having knowledge of this=20
> > diversion.
> > Thus, diversion subscriptions have to be serviced by the UAs=20
> > themselves, which are the notifiers. This means a "forked=20
> SUBSCRIBE"=20
> > scenario with multiple 200s, which is a bit messy (i.e., it isn't=20
> > likely to work very well).
> >=20
> > However, the CDIV architecture as I understand it assumes=20
> diversion is
>=20
> > handled at the S-CSCF on behalf of all UAs. In this model,=20
> the S-CSCF=20
> > first determines a routing for the INVITE to various contacts, then=20
> > executes diversion on a per-contact basis if needed.=20
> Consequently, the
>=20
> > S-CSCF has full knowledge of diversion status, and can serve as the=20
> > notifier for the diversion notification package. This all requires=20
> > some way for a UA to inform an S-CSCF to invoke diversion, which is=20
> > outside the scope of this document.
> >=20
> > And this is exactly the description of architectural model that is=20
> > apparently not adequately disclosed in the draft, and=20
> probably should=20
> > be.
> >=20
> > --
> > Dean
> >=20
> >=20
> >=20
> =

From pkyzivat@cisco.com  Tue Jan 19 10:15:30 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEDD3A6782 for ; Tue, 19 Jan 2010 10:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.363
X-Spam-Level: 
X-Spam-Status: No, score=-10.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49hHnvgkULq3 for ; Tue, 19 Jan 2010 10:15:29 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 34F903A67FC for ; Tue, 19 Jan 2010 10:15:28 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAEGFVUutJV2Y/2dsb2JhbADDApUngi2CBgQ
X-IronPort-AV: E=Sophos;i="4.49,305,1262563200"; d="scan'208";a="81016687"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2010 18:15:21 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0JIFLsc026204;  Tue, 19 Jan 2010 18:15:21 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 12:15:21 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 12:15:21 -0600
Message-ID: <4B55F6B7.60002@cisco.com>
Date: Tue, 19 Jan 2010 13:15:19 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Elwell, John" 
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>	<4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>	<750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jan 2010 18:15:21.0364 (UTC) FILETIME=[5CD9CD40:01CA9933]
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 18:15:30 -0000

Elwell, John wrote:
>  
> 
>> -----Original Message-----
>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] 
>> Sent: 19 January 2010 17:49
>> To: Elwell, John; Dean Willis
>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>> Subject: RE: [dispatch] Comments 
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>> Hi John
>>
>> Sorry for the late response. Yes the notifications will be from the
>> server towards the original AoR with the registered contact 
>> specified as
>> part of the event package (e.g in the element "diverting-user"). So it
>> would be the job of the notifier to generate appropriate diversion
>> notification information towards the target AoR.
> [JRE] This just confuses me again. It first says the notification will be sent from the server to the original AOR, and then it says notification information is send towards the target AOR - apparently a contradiction, unless these two terms mean the same thing. Also, why is the registered contact (I assume this means contact URI) sent in element "diverting-user" rather than the original AOR?

This has confused me from the beginning.
It seems the assumption is that only the "diverting user" will 
subscribe. But in reality that doesn't make much sense if the 
subscription is addressed to the diverting user.

It makes some sense if the subscribers are UAs that have registered with 
the AOR of the diverting user, and the notifier is a server that 
mediates arriving requests to that AOR.

But even then, while its reasonable to expect that the registered 
devices might be interested in subscribing to this, surely they aren't 
the *only* plausible subscribers. Assuming they are is, IMO, a mistake.

	Thanks,
	Paul

> John
> 
> 
>> Thanks
>>
>>
>> Regards
>> Ranjit
>>
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] 
>> Sent: Monday, January 18, 2010 3:53 PM
>> To: Avasarala Ranjit-A20990; Dean Willis
>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>> Subject: RE: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>> Ranjit,
>>
>> Thanks for your explanation. However, if the IETF is to publish an RFC
>> on diversion notification, it will need to relate it clearly to RFC
>> 3262. So if the scope is just notifications of diversions 
>> away from the
>> original target AOR towards some other target AOR, I am 
>> comfortable. If
>> it is to do with selection of an appropriate registered 
>> contact for the
>> original target AOR, I am uncomfortable and would require further
>> explanation.
>>
>> John
>>
>>
>>> -----Original Message-----
>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
>>> Sent: 18 January 2010 10:07
>>> To: Dean Willis
>>> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>> Subject: RE: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>> Hi Dean
>>>
>>> The Call diversion architecture and service are explained 
>> in 3GPP TS 
>>> 24.604.  So here the diversion service gets executed in the 
>> network by
>>
>>> the CSCFs or the Application Servers on behalf of the individual 
>>> subscribers. So here the UA(s) do not do the actual 
>> diversion, but set
>>
>>> rules on the server for triggering diversions.
>>>
>>> So in this model, as users set several call diversion rules 
>> based on 
>>> several criteria like incoming caller identity or time of day, etc, 
>>> there are bound to be some errors in configuration. So in order to 
>>> convey the actual outcome of the diversion, there is a need 
>> to notify 
>>> the actual user i.e on whose behalf the diversion has 
>> occurred. This 
>>> notification information is expressed as an CDIV notification event 
>>> package which is the main purpose of this document.
>>>
>>> The proposed CDIV notification information event package definition 
>>> conform to the standard event package template as defined 
>> in RFC 3265 
>>> and is applicable to CDIV service that gets executed in the server 
>>> rather than by individual User Agents.
>>>
>>> Thanks and looking forward to more comments and directions to take 
>>> this work forward.
>>>
>>>
>>>
>>> Regards
>>> Ranjit
>>>
>>> -----Original Message-----
>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>> Sent: Saturday, January 16, 2010 11:27 AM
>>> To: Avasarala Ranjit-A20990
>>> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
>>> Subject: Re: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>> On Fri, January 15, 2010 11:45 am, Avasarala Ranjit-A20990 wrote:
>>>> Hi John
>>>>
>>>> Completely agree with you. The subscribe requests will be
>>> towards the
>>>> public AoR i.e alice@example. But the diversion rules could
>>> be set for
>>>
>>>> specific registered contact Uris so that diversions for that 
>>>> particular URI are notified.
>>> What isn't clear here is the underlying diversion architecture.
>>>
>>> I believe John has in mind a model where each UA has local divert 
>>> capability; that is, it can receive an INVITE request and divert to 
>>> another location without the registrar having knowledge of this 
>>> diversion.
>>> Thus, diversion subscriptions have to be serviced by the UAs 
>>> themselves, which are the notifiers. This means a "forked 
>> SUBSCRIBE" 
>>> scenario with multiple 200s, which is a bit messy (i.e., it isn't 
>>> likely to work very well).
>>>
>>> However, the CDIV architecture as I understand it assumes 
>> diversion is
>>
>>> handled at the S-CSCF on behalf of all UAs. In this model, 
>> the S-CSCF 
>>> first determines a routing for the INVITE to various contacts, then 
>>> executes diversion on a per-contact basis if needed. 
>> Consequently, the
>>
>>> S-CSCF has full knowledge of diversion status, and can serve as the 
>>> notifier for the diversion notification package. This all requires 
>>> some way for a UA to inform an S-CSCF to invoke diversion, which is 
>>> outside the scope of this document.
>>>
>>> And this is exactly the description of architectural model that is 
>>> apparently not adequately disclosed in the draft, and 
>> probably should 
>>> be.
>>>
>>> --
>>> Dean
>>>
>>>
>>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From salvatore.loreto@ericsson.com  Tue Jan 19 11:46:24 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5A63A67FC for ; Tue, 19 Jan 2010 11:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MymhRdD5xRx8 for ; Tue, 19 Jan 2010 11:46:23 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EF9EA3A65A6 for ; Tue, 19 Jan 2010 11:46:22 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-5d-4b560c09db01
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4D.B9.04178.90C065B4; Tue, 19 Jan 2010 20:46:18 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 20:45:46 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Jan 2010 20:45:46 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1273F24C8; Tue, 19 Jan 2010 21:45:46 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C45B721A39; Tue, 19 Jan 2010 21:45:45 +0200 (EET)
Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 43E63219D0; Tue, 19 Jan 2010 21:45:45 +0200 (EET)
Message-ID: <4B560BE8.30908@ericsson.com>
Date: Tue, 19 Jan 2010 21:45:44 +0200
From: Salvatore Loreto 
User-Agent: Thunderbird 2.0.0.23 (X11/20090825)
MIME-Version: 1.0
To: "L.Liess@telekom.de" 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 19 Jan 2010 19:45:46.0331 (UTC) FILETIME=[FE6212B0:01CA993F]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" , Gonzalo Camarillo , "HKaplan@acmepacket.com" , "Martin.Huelsemann@telekom.de" , "Gerold.Pinker@telekom.de" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 19:46:24 -0000

Hi there,

I have been thinking for a while on this three/four issues

So let me start with the Hadriel question: "same-session could use a 
session-id kind of value instead of callid+tags
the same-session-id is a quite an old draft"?
I do think it should use a session-id kind of value! (the mechanism 
proposed in same-session draft if stale, as it is the
all draft, so it is a waste of time talk about it. Lets instead talk of 
and compare with the disaggregate media one:
http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt )

In my opinion the scenario to correlate an original call with a new 
create by a B2BUA is quite
similar to the one where the calls that are going to be correlate are 
generate by the same UA.
That is even more true if the correlation identifier is generated by the 
UA and not by the B2BUA or any other server
within the network.
So the Hadriel's draft could be a good starting point to draft solution 
for disaggregated media, of course it we get
rid of the limitation for debug purpose.
I wouldn't be worried about about the performance issue raised by Laura, 
at the end it would be enough insert
a tag into the Session-ID header to discriminate the scenario when it is 
used for debugging and when for disaggregated purpose.
Moreover at the end both the disaggregated and especially the debug (I 
hope) will be used rarely.

Coming to the SIP-XMPP scenario: here I don't have a strong idea, but I 
guess that an identifier a la session-id
could work also in this scenario.

of course I may be wrong

cheers
Sal

L.Liess@telekom.de wrote:
> Hi, 
>
> I think if we can show that having the same identifier for both use
> cases has unacceptable consequences we can say that we need two diferent
> identifiers.
> If I understood the draft-loreto-sipping-dialog-correlation-01
> correctly, my feeling is that we get a lot of problems if we try to use
> the same identifier for both Session-ID and Dialog-correlation
> (Same-Session).   
>
> Let's assume we have a same identifier, called Correlation-ID , which
> plays both roles, Session-ID and Same-Session.  
>
>
> Consequence nr. 1) 
> Significant performance reduction in UAS. 
>
> When Correlation-ID in it's Session-ID role becomes implemented, every
> INVITE received by every UAS will contain a Correlation-ID. The UAS will
> have to  search for existing dialogs related to the received
> Correlation-ID. For Gateways or Application Servers, this can be very
> CPU consuming. They must search for related dialogs for every received
> INVITE. If we have two identifiers are different, in most cases the UAS
> receives only the Session-ID which it just copies into the Respose. The
> search is done only for the use cases described in the dialog-corelation
> draft.  
>
> So I would propose following additional requirenment for the Session-ID
> Header: 
> "The mechanism should not lead to unnecessary performance reduction at
> the UAS."
> This requirement is not fulfilled if we have the same identifier. 
>
>
>
> Consequence nr. 2)
>
> Imprecise monitoring results
>
> Consider the scenario in chapter 4
> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> B2BUA between Alice and Bob and the service provider monitors the trafic
> E2E.  The trubleshooting people will want to distinguish which messages
> belong to the phone call and which messages belong to  the video call.  
>
>
>
>
> Alice
> Bob
>
> UA_A
> -----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>   
>> UA_B
>>     
>  
> Correlation-ID_a
>                                                           (based on
> call-ID_a)     
>                                                         
>  
>
>     
> UA_C
> -----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>   
>> UA_B
>>     
>           Correlation-ID_a
> Correlation-ID_a
>          (based on call-ID_a)                         (based on
> call-ID_a)
>
>   
>
>
> Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
> B2BUA constructs the Correlation-ID_a based on the Call-ID_a. 
> Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
> correlated to the existing phone call and the UA_B constructs the
> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> Correlation-ID_a to the UA_B transparently. Because both messages
> between the B2BUA and UA_B have the same Correlation-ID, the monitoring
> equipment will not be able to distinguish which message belongs to which
> call.       
>
>
> So I would propose following additional requirenment for the Session-ID
> Header: 
>
> "Different E2E SIP sessions must have different identifiers." 
>
> I also would add following Requirement to Session-ID: 
>
> "It must be possible to use the identifier without upgrading the end
> devices software." 
> This requirement is met by the Session-ID proposal but it is not
> explicitely stated in the draft. 
>
>
> Additional personal opinions on the correlation-draft:
> - I think the Same-Session will is usefull for troubleshooting and
> should be standardized. 
>
> - The Same-Session header should use the Session-ID instead of the
> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> change it. (I hope there are no conflicts here with the tags.)  
>  
>
> Thanks  a lot
> Laura
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>   

From spencer@wonderhamster.org  Tue Jan 19 12:17:07 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC433A68B0 for ; Tue, 19 Jan 2010 12:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7XHZ+9VK199 for ; Tue, 19 Jan 2010 12:17:05 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CDFC23A687F for ; Tue, 19 Jan 2010 12:17:05 -0800 (PST)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M6kE0-1Njcgs0Mtg-00wdzJ; Tue, 19 Jan 2010 15:17:01 -0500
Message-ID: <7B129E0DC7314431AD92AE229A10F33E@china.huawei.com>
From: "Spencer Dawkins" 
To: , , 
References: <1NXKA7-1y4tAu0@fwd07.aul.t-online.de>
Date: Tue, 19 Jan 2010 14:16:39 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX193owZM2mZqY1cjWX620MFjwbVYU01CJ+W+rs5 d5PxTvXRVsD6go6oFfG2vJjODLbgj5LqDP7vYfdmED3+gO/bT/ T688JAeY2ToJD68YN0+FKker12jrk2lEXAlT6nZ3xA=
Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2010 20:17:07 -0000

Hi, Laura,

Ah - yes, I understand what you're saying here, and why it applies to 
"Same-Session", and agree.

Thank you for confirming and clarifying.

Spencer

> Spencer,
>
> Yes, exactly.   But I mixed-up something in my text , the requirement
> should be for Same-Session (dialog correlation) , not for Session-ID.
>
> Thanks a lot
> Laura
>
>
> --------------------------------------------------------------------------------
>
> From: "Spencer Dawkins" 
> To: , ,
> 
> Cc: dispatch at ietf.org, Martin.Huelsemann at telekom.de, Gerold.Pinker
> at telekom.de
> Date: Tue, 19 Jan 2010 07:46:39 -0600
> References:  mail><4B32DC9B.3040406 at
> softarmor.com><36D784AAD47343248BE3274F64A101ED at
> china.huawei.com><4B4F3353.9010507 at ericsson.com>
> 
> <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B at S4DE9JSAANI.ost.t-com.de>
>
> --------------------------------------------------------------------------------
>
> Hi, Laura,
>
>
> Just to make sure I understand - are you saying something like "The
> mechanism should not lead to performance reduction at the UAS for
> dialogs that are not correlated with other dialogs."?
>
>
> (I'm just trying to be more precise about "unnecessary performance
> reduction")
>
> If so, that makes sense to me.
>
> Thanks,
>
> Spencer
>
>
> ----- Original Message ----- From:  To:  at acmepacket.com>; ;  wonderhamster.org> Cc: ;  telekom.de>; 
> Sent: Tuesday, January 19, 2010 4:19 AM
>
> Subject: RE: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>
>
> Hi,
>
> I think if we can show that having the same identifier for both use
> cases has unacceptable consequences we can say that we need two diferent
> identifiers.
> If I understood the draft-loreto-sipping-dialog-correlation-01
> correctly, my feeling is that we get a lot of problems if we try to use
> the same identifier for both Session-ID and Dialog-correlation
> (Same-Session).
>
> Let's assume we have a same identifier, called Correlation-ID , which
> plays both roles, Session-ID and Same-Session.
>
>
> Consequence nr. 1)
> Significant performance reduction in UAS.
>
> When Correlation-ID in it's Session-ID role becomes implemented, every
> INVITE received by every UAS will contain a Correlation-ID. The UAS will
> have to  search for existing dialogs related to the received
> Correlation-ID. For Gateways or Application Servers, this can be very
> CPU consuming. They must search for related dialogs for every received
> INVITE. If we have two identifiers are different, in most cases the UAS
> receives only the Session-ID which it just copies into the Respose. The
> search is done only for the use cases described in the dialog-corelation
> draft.
>
> So I would propose following additional requirenment for the Session-ID
> Header:
> "The mechanism should not lead to unnecessary performance reduction at
> the UAS."
> This requirement is not fulfilled if we have the same identifier.
>
>
>
> Consequence nr. 2)
>
> Imprecise monitoring results
>
> Consider the scenario in chapter 4
> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> B2BUA between Alice and Bob and the service provider monitors the trafic
> E2E.  The trubleshooting people will want to distinguish which messages
> belong to the phone call and which messages belong to  the video call.
>
>
>
>
> Alice
> Bob
>
> UA_A
> -----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>
> UA_B
>
>
> Correlation-ID_a
>                                                         (based on
> call-ID_a)
>
>
>
>
> UA_C
> -----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>
> UA_B
>
>         Correlation-ID_a
> Correlation-ID_a
>        (based on call-ID_a)                         (based on
> call-ID_a)
>
>
>
>
> Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
> B2BUA constructs the Correlation-ID_a based on the Call-ID_a.
> Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
> correlated to the existing phone call and the UA_B constructs the
> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> Correlation-ID_a to the UA_B transparently. Because both messages
> between the B2BUA and UA_B have the same Correlation-ID, the monitoring
> equipment will not be able to distinguish which message belongs to which
> call.
>
>
> So I would propose following additional requirenment for the Session-ID
> Header:
>
> "Different E2E SIP sessions must have different identifiers."
>
> I also would add following Requirement to Session-ID:
>
> "It must be possible to use the identifier without upgrading the end
> devices software."
> This requirement is met by the Session-ID proposal but it is not
> explicitely stated in the draft.
>
>
> Additional personal opinions on the correlation-draft:
> - I think the Same-Session will is usefull for troubleshooting and
> should be standardized.
>
> - The Same-Session header should use the Session-ID instead of the
> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> change it. (I hope there are no conflicts here with the tags.)
>
>
> Thanks  a lot
>
> Laura
> --------------------------------------------------------------------------------
>
> References:
> [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt
> From: Hadriel Kaplan
> Re: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt
> From: Dean Willis
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Spencer Dawkins
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Gonzalo Camarillo
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Hadriel Kaplan
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: L.Liess
> Prev by Date: Re: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> Next by Date: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
> Previous by thread: Re: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> Next by thread: Re: [dispatch] Test message - please ignore
> Index(es):
> Date
> Thread
> Note Well: Messages sent to this mailing list are the opinions of the
> senders and do not imply endorsement by the IETF.
>
>
> 

From dean.willis@softarmor.com  Tue Jan 19 22:04:59 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFF43A6953 for ; Tue, 19 Jan 2010 22:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRVTiIh5f-MR for ; Tue, 19 Jan 2010 22:04:58 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 226EE3A696D for ; Tue, 19 Jan 2010 22:04:58 -0800 (PST)
Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0K64Srg006388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2010 00:04:30 -0600
Message-Id: 
From: Dean Willis 
To: Paul Kyzivat 
In-Reply-To: <4B55F6B7.60002@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 20 Jan 2010 00:04:22 -0600
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>	<4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>	<750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 06:04:59 -0000

On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:

>
>
> Elwell, John wrote:
>>
>>> -----Original Message-----
>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] Sent:  
>>> 19 January 2010 17:49
>>> To: Elwell, John; Dean Willis
>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala- 
>>> dispatch-comm-div-notification
>>>
>>> Hi John
>>>
>>> Sorry for the late response. Yes the notifications will be from the
>>> server towards the original AoR with the registered contact  
>>> specified as
>>> part of the event package (e.g in the element "diverting-user").  
>>> So it
>>> would be the job of the notifier to generate appropriate diversion
>>> notification information towards the target AoR.
>> [JRE] This just confuses me again. It first says the notification  
>> will be sent from the server to the original AOR, and then it says  
>> notification information is send towards the target AOR -  
>> apparently a contradiction, unless these two terms mean the same  
>> thing. Also, why is the registered contact (I assume this means  
>> contact URI) sent in element "diverting-user" rather than the  
>> original AOR?
>
> This has confused me from the beginning.
> It seems the assumption is that only the "diverting user" will  
> subscribe. But in reality that doesn't make much sense if the  
> subscription is addressed to the diverting user.

The diverting user has multiple user agents. Said user cannot remember  
which user agent is set to divert, or what it is diverting to. So said  
user subscribes to the divnot package in order to find out what the  
heck is happening.

>
> It makes some sense if the subscribers are UAs that have registered  
> with the AOR of the diverting user, and the notifier is a server  
> that mediates arriving requests to that AOR.
>

Yes, I think that's the intent

> But even then, while its reasonable to expect that the registered  
> devices might be interested in subscribing to this, surely they  
> aren't the *only* plausible subscribers. Assuming they are is, IMO,  
> a mistake.

I think your view of the architecture is somewhat larger than the  
author's. This is not unreasonable. Like you, I can envision other use  
cases, such as call center scenarios.

Is there any reason NOT to generalize the specification for broader  
applicability?

--
Dean

From ian.elz@ericsson.com  Wed Jan 20 03:52:33 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79053A68B8 for ; Wed, 20 Jan 2010 03:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level: 
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGTAALoFdU0v for ; Wed, 20 Jan 2010 03:52:32 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 167203A6807 for ; Wed, 20 Jan 2010 03:52:31 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-fc-4b56ee7a95a9
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 39.AE.04178.A7EE65B4; Wed, 20 Jan 2010 12:52:26 +0100 (CET)
Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 20 Jan 2010 12:52:26 +0100
Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 20 Jan 2010 12:52:25 +0100
From: Ian Elz 
To: Salvatore Loreto , "L.Liess@telekom.de" 
Date: Wed, 20 Jan 2010 12:52:25 +0100
Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqZQhI1g4nfchZ1QP6hQzOIYdDAYAAg8NnA
Message-ID: 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>  <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com>
In-Reply-To: <4B560BE8.30908@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" , "Gerold.Pinker@telekom.de" , Gonzalo Camarillo , "HKaplan@acmepacket.com" , "Martin.Huelsemann@telekom.de" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 11:52:33 -0000

Sal,

>From your quote: ' "same-session could use a session-id kind of value inste=
ad of callid+tags..." '

As was commented during the initial discussions on Hadriel's first draft th=
e session-id as proposed will not replace call-id+tags. This occurs as fork=
ing will result in multiple dialogs containing the same session-id. This on=
ly really presents an issue during the early-dialog phase as only one early=
-dialog will result in an established session.

If you need session-id to be able to match early dialogs then you need sess=
ion-id to have a different form.

E.g. Session-id: UAC-part;UAS-parameter

In this scenario for session tracking or established session identification=
 only the UAC-part is required but for identification of an individual earl=
y dialog both parts would be required.

Ian

-----Original Message-----
From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]=20
Sent: 19 January 2010 19:46
To: L.Liess@telekom.de
Cc: dispatch@ietf.org; Gonzalo Camarillo; HKaplan@acmepacket.com; Martin.Hu=
elsemann@telekom.de; Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.t=
xt

Hi there,

I have been thinking for a while on this three/four issues

So let me start with the Hadriel question: "same-session could use a sessio=
n-id kind of value instead of callid+tags the same-session-id is a quite an=
 old draft"?
I do think it should use a session-id kind of value! (the mechanism propose=
d in same-session draft if stale, as it is the all draft, so it is a waste =
of time talk about it. Lets instead talk of and compare with the disaggrega=
te media one:
http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt )

In my opinion the scenario to correlate an original call with a new create =
by a B2BUA is quite similar to the one where the calls that are going to be=
 correlate are generate by the same UA.
That is even more true if the correlation identifier is generated by the UA=
 and not by the B2BUA or any other server within the network.
So the Hadriel's draft could be a good starting point to draft solution for=
 disaggregated media, of course it we get rid of the limitation for debug p=
urpose.
I wouldn't be worried about about the performance issue raised by Laura, at=
 the end it would be enough insert a tag into the Session-ID header to disc=
riminate the scenario when it is used for debugging and when for disaggrega=
ted purpose.
Moreover at the end both the disaggregated and especially the debug (I
hope) will be used rarely.

Coming to the SIP-XMPP scenario: here I don't have a strong idea, but I gue=
ss that an identifier a la session-id could work also in this scenario.

of course I may be wrong

cheers
Sal

L.Liess@telekom.de wrote:
> Hi,=20
>
> I think if we can show that having the same identifier for both use
> cases has unacceptable consequences we can say that we need two diferent
> identifiers.
> If I understood the draft-loreto-sipping-dialog-correlation-01
> correctly, my feeling is that we get a lot of problems if we try to use
> the same identifier for both Session-ID and Dialog-correlation
> (Same-Session).  =20
>
> Let's assume we have a same identifier, called Correlation-ID , which
> plays both roles, Session-ID and Same-Session. =20
>
>
> Consequence nr. 1)=20
> Significant performance reduction in UAS.=20
>
> When Correlation-ID in it's Session-ID role becomes implemented, every
> INVITE received by every UAS will contain a Correlation-ID. The UAS will
> have to  search for existing dialogs related to the received
> Correlation-ID. For Gateways or Application Servers, this can be very
> CPU consuming. They must search for related dialogs for every received
> INVITE. If we have two identifiers are different, in most cases the UAS
> receives only the Session-ID which it just copies into the Respose. The
> search is done only for the use cases described in the dialog-corelation
> draft. =20
>
> So I would propose following additional requirenment for the Session-ID
> Header:=20
> "The mechanism should not lead to unnecessary performance reduction at
> the UAS."
> This requirement is not fulfilled if we have the same identifier.=20
>
>
>
> Consequence nr. 2)
>
> Imprecise monitoring results
>
> Consider the scenario in chapter 4
> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> B2BUA between Alice and Bob and the service provider monitors the trafic
> E2E.  The trubleshooting people will want to distinguish which messages
> belong to the phone call and which messages belong to  the video call. =20
>
>
>
>
> Alice
> Bob
>
> UA_A
> -----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>  =20
>> UA_B
>>    =20
> =20
> Correlation-ID_a
>                                                           (based on
> call-ID_a)    =20
>                                                        =20
> =20
>
>    =20
> UA_C
> -----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>  =20
>> UA_B
>>    =20
>           Correlation-ID_a
> Correlation-ID_a
>          (based on call-ID_a)                         (based on
> call-ID_a)
>
>  =20
>
>
> Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
> B2BUA constructs the Correlation-ID_a based on the Call-ID_a.=20
> Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
> correlated to the existing phone call and the UA_B constructs the
> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> Correlation-ID_a to the UA_B transparently. Because both messages
> between the B2BUA and UA_B have the same Correlation-ID, the monitoring
> equipment will not be able to distinguish which message belongs to which
> call.      =20
>
>
> So I would propose following additional requirenment for the Session-ID
> Header:=20
>
> "Different E2E SIP sessions must have different identifiers."=20
>
> I also would add following Requirement to Session-ID:=20
>
> "It must be possible to use the identifier without upgrading the end
> devices software."=20
> This requirement is met by the Session-ID proposal but it is not
> explicitely stated in the draft.=20
>
>
> Additional personal opinions on the correlation-draft:
> - I think the Same-Session will is usefull for troubleshooting and
> should be standardized.=20
>
> - The Same-Session header should use the Session-ID instead of the
> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> change it. (I hope there are no conflicts here with the tags.) =20
> =20
>
> Thanks  a lot
> Laura
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>  =20

From pkyzivat@cisco.com  Wed Jan 20 06:00:52 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9857F3A6A79 for ; Wed, 20 Jan 2010 06:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.068
X-Spam-Level: 
X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zHNHBnAQTk4 for ; Wed, 20 Jan 2010 06:00:51 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 737A83A6A73 for ; Wed, 20 Jan 2010 06:00:51 -0800 (PST)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPeaVkurR7H+/2dsb2JhbADCSpVNhDYE
X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208";a="208485550"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2010 14:00:47 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0KE0lJ7022696; Wed, 20 Jan 2010 14:00:47 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 08:00:47 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 08:00:46 -0600
Message-ID: <4B570C8D.6030804@cisco.com>
Date: Wed, 20 Jan 2010 09:00:45 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Ian Elz 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>		<40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>	<4B560BE8.30908@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jan 2010 14:00:46.0878 (UTC) FILETIME=[F6F5F3E0:01CA99D8]
Cc: "dispatch@ietf.org" , Gonzalo Camarillo , "HKaplan@acmepacket.com" , "L.Liess@telekom.de" , "Martin.Huelsemann@telekom.de" , "Gerold.Pinker@telekom.de" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 14:00:52 -0000

Ian Elz wrote:
> Sal,
> 
>>From your quote: ' "same-session could use a session-id kind of value instead of callid+tags..." '
> 
> As was commented during the initial discussions on Hadriel's first draft the session-id as proposed will not replace call-id+tags. This occurs as forking will result in multiple dialogs containing the same session-id. This only really presents an issue during the early-dialog phase as only one early-dialog will result in an established session.

While its "normal" that only one final dialog results from an INVITE, it 
is certainly possible to end up with more than one. While in that case 
its common to kill all but one, that isn't necessarily the case either.
(E.g. a conference server that is calling out to a potential participant 
may find that its INVITE is forked, and may well keep all resulting 
dialogs.)

So lets not design anything that depends on their being only one.

	Thanks,
	Paul

> If you need session-id to be able to match early dialogs then you need session-id to have a different form.
> 
> E.g. Session-id: UAC-part;UAS-parameter
> 
> In this scenario for session tracking or established session identification only the UAC-part is required but for identification of an individual early dialog both parts would be required.
> 
> Ian
> 
> -----Original Message-----
> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] 
> Sent: 19 January 2010 19:46
> To: L.Liess@telekom.de
> Cc: dispatch@ietf.org; Gonzalo Camarillo; HKaplan@acmepacket.com; Martin.Huelsemann@telekom.de; Gerold.Pinker@telekom.de
> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> 
> Hi there,
> 
> I have been thinking for a while on this three/four issues
> 
> So let me start with the Hadriel question: "same-session could use a session-id kind of value instead of callid+tags the same-session-id is a quite an old draft"?
> I do think it should use a session-id kind of value! (the mechanism proposed in same-session draft if stale, as it is the all draft, so it is a waste of time talk about it. Lets instead talk of and compare with the disaggregate media one:
> http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt )
> 
> 
> In my opinion the scenario to correlate an original call with a new create by a B2BUA is quite similar to the one where the calls that are going to be correlate are generate by the same UA.
> That is even more true if the correlation identifier is generated by the UA and not by the B2BUA or any other server within the network.
> So the Hadriel's draft could be a good starting point to draft solution for disaggregated media, of course it we get rid of the limitation for debug purpose.
> I wouldn't be worried about about the performance issue raised by Laura, at the end it would be enough insert a tag into the Session-ID header to discriminate the scenario when it is used for debugging and when for disaggregated purpose.
> Moreover at the end both the disaggregated and especially the debug (I
> hope) will be used rarely.
> 
> Coming to the SIP-XMPP scenario: here I don't have a strong idea, but I guess that an identifier a la session-id could work also in this scenario.
> 
> 
> of course I may be wrong
> 
> cheers
> Sal
> 
> L.Liess@telekom.de wrote:
>> Hi, 
>>
>> I think if we can show that having the same identifier for both use
>> cases has unacceptable consequences we can say that we need two diferent
>> identifiers.
>> If I understood the draft-loreto-sipping-dialog-correlation-01
>> correctly, my feeling is that we get a lot of problems if we try to use
>> the same identifier for both Session-ID and Dialog-correlation
>> (Same-Session).   
>>
>> Let's assume we have a same identifier, called Correlation-ID , which
>> plays both roles, Session-ID and Same-Session.  
>>
>>
>> Consequence nr. 1) 
>> Significant performance reduction in UAS. 
>>
>> When Correlation-ID in it's Session-ID role becomes implemented, every
>> INVITE received by every UAS will contain a Correlation-ID. The UAS will
>> have to  search for existing dialogs related to the received
>> Correlation-ID. For Gateways or Application Servers, this can be very
>> CPU consuming. They must search for related dialogs for every received
>> INVITE. If we have two identifiers are different, in most cases the UAS
>> receives only the Session-ID which it just copies into the Respose. The
>> search is done only for the use cases described in the dialog-corelation
>> draft.  
>>
>> So I would propose following additional requirenment for the Session-ID
>> Header: 
>> "The mechanism should not lead to unnecessary performance reduction at
>> the UAS."
>> This requirement is not fulfilled if we have the same identifier. 
>>
>>
>>
>> Consequence nr. 2)
>>
>> Imprecise monitoring results
>>
>> Consider the scenario in chapter 4
>> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
>> B2BUA between Alice and Bob and the service provider monitors the trafic
>> E2E.  The trubleshooting people will want to distinguish which messages
>> belong to the phone call and which messages belong to  the video call.  
>>
>>
>>
>>
>> Alice
>> Bob
>>
>> UA_A
>> -----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>>   
>>> UA_B
>>>     
>>  
>> Correlation-ID_a
>>                                                           (based on
>> call-ID_a)     
>>                                                         
>>  
>>
>>     
>> UA_C
>> -----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>>   
>>> UA_B
>>>     
>>           Correlation-ID_a
>> Correlation-ID_a
>>          (based on call-ID_a)                         (based on
>> call-ID_a)
>>
>>   
>>
>>
>> Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
>> B2BUA constructs the Correlation-ID_a based on the Call-ID_a. 
>> Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
>> correlated to the existing phone call and the UA_B constructs the
>> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
>> Correlation-ID_a to the UA_B transparently. Because both messages
>> between the B2BUA and UA_B have the same Correlation-ID, the monitoring
>> equipment will not be able to distinguish which message belongs to which
>> call.       
>>
>>
>> So I would propose following additional requirenment for the Session-ID
>> Header: 
>>
>> "Different E2E SIP sessions must have different identifiers." 
>>
>> I also would add following Requirement to Session-ID: 
>>
>> "It must be possible to use the identifier without upgrading the end
>> devices software." 
>> This requirement is met by the Session-ID proposal but it is not
>> explicitely stated in the draft. 
>>
>>
>> Additional personal opinions on the correlation-draft:
>> - I think the Same-Session will is usefull for troubleshooting and
>> should be standardized. 
>>
>> - The Same-Session header should use the Session-ID instead of the
>> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
>> change it. (I hope there are no conflicts here with the tags.)  
>>  
>>
>> Thanks  a lot
>> Laura
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>   
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From ranjit@motorola.com  Wed Jan 20 09:45:05 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B39D3A6A7A for ; Wed, 20 Jan 2010 09:45:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDdWowXfixGR for ; Wed, 20 Jan 2010 09:45:04 -0800 (PST)
Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 635F13A6403 for ; Wed, 20 Jan 2010 09:45:00 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-13.tower-153.messagelabs.com!1264009491!14779078!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 18722 invoked from network); 20 Jan 2010 17:44:51 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jan 2010 17:44:51 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0KHijIE007012 for ; Wed, 20 Jan 2010 10:44:50 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o0KHijrG022823 for ; Wed, 20 Jan 2010 11:44:45 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o0KHiima022811 for ; Wed, 20 Jan 2010 11:44:44 -0600 (CST)
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: Thu, 21 Jan 2010 01:44:20 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqZloK+cyEKNhMZSreNF+In1kI2bgAYMttA
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>	<4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>	<750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com> 
From: "Avasarala Ranjit-A20990" 
To: "Dean Willis" , "Paul Kyzivat" 
X-CFilter-Loop: Reflected
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 17:45:05 -0000

Hi Dean

A sample diversion notification document would like =20

      Boss
      sip:boss@office.com

      sip:alice@office.com

      sip:bob@office.com

    1999-06-01T13:20:00-05:00
    404

So here, the subscribing AoR would be alice@domain.com. The
 which is alice@office.com gives the URI that is
actually diverting. While the  element gives the
final target of the call.

So at any point of time, alice@domain.com can check all the
notifications received to determine the set of diversions that have
taken place at various registered contacts of Alice. =20

Now if we take the call centre scenario, then a particular incoming call
could get forked probably sequentially until one of the agents picks the
call. So I feel this is not a valid use case of call diversion, but
would qualify for a use case of sequential or simultaneous forking.=20

Regards
Ranjit

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]=20
Sent: Wednesday, January 20, 2010 11:34 AM
To: Paul Kyzivat
Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH; Gonzalo Camarillo
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:

>
>
> Elwell, John wrote:
>>
>>> -----Original Message-----
>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] Sent: =20
>>> 19 January 2010 17:49
>>> To: Elwell, John; Dean Willis
>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala-=20
>>> dispatch-comm-div-notification
>>>
>>> Hi John
>>>
>>> Sorry for the late response. Yes the notifications will be from the=20
>>> server towards the original AoR with the registered contact=20
>>> specified as part of the event package (e.g in the element=20
>>> "diverting-user").
>>> So it
>>> would be the job of the notifier to generate appropriate diversion=20
>>> notification information towards the target AoR.
>> [JRE] This just confuses me again. It first says the notification=20
>> will be sent from the server to the original AOR, and then it says=20
>> notification information is send towards the target AOR - apparently=20
>> a contradiction, unless these two terms mean the same thing. Also,=20
>> why is the registered contact (I assume this means contact URI) sent=20
>> in element "diverting-user" rather than the original AOR?
>
> This has confused me from the beginning.
> It seems the assumption is that only the "diverting user" will=20
> subscribe. But in reality that doesn't make much sense if the=20
> subscription is addressed to the diverting user.

The diverting user has multiple user agents. Said user cannot remember
which user agent is set to divert, or what it is diverting to. So said
user subscribes to the divnot package in order to find out what the heck
is happening.

>
> It makes some sense if the subscribers are UAs that have registered=20
> with the AOR of the diverting user, and the notifier is a server that=20
> mediates arriving requests to that AOR.
>

Yes, I think that's the intent

> But even then, while its reasonable to expect that the registered=20
> devices might be interested in subscribing to this, surely they aren't

> the *only* plausible subscribers. Assuming they are is, IMO, a=20
> mistake.

I think your view of the architecture is somewhat larger than the
author's. This is not unreasonable. Like you, I can envision other use
cases, such as call center scenarios.

Is there any reason NOT to generalize the specification for broader
applicability?

--
Dean

From pkyzivat@cisco.com  Wed Jan 20 10:10:49 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375463A67AF for ; Wed, 20 Jan 2010 10:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.367
X-Spam-Level: 
X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J5xvuqSmk3v for ; Wed, 20 Jan 2010 10:10:48 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 057863A6844 for ; Wed, 20 Jan 2010 10:10:48 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAAPWVkutJV2b/2dsb2JhbADFCpVVhDYE
X-IronPort-AV: E=Sophos;i="4.49,311,1262563200"; d="scan'208";a="234150594"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2010 18:10:43 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0KIAhXa027584;  Wed, 20 Jan 2010 18:10:43 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 12:10:43 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 12:10:43 -0600
Message-ID: <4B574722.9070108@cisco.com>
Date: Wed, 20 Jan 2010 13:10:42 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Avasarala Ranjit-A20990 
References: <4B4F2403.7010200@ericsson.com>		<750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com>	<4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com>	<750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>		<750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jan 2010 18:10:43.0194 (UTC) FILETIME=[E1762DA0:01CA99FB]
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 18:10:49 -0000

Avasarala Ranjit-A20990 wrote:
> Hi Dean
> 
> A sample diversion notification document would like  
> 
> 
>   
>     
>       Boss
>       sip:boss@office.com
>     
>     
>       sip:alice@office.com
>     
>     
>       sip:bob@office.com
>     
>     1999-06-01T13:20:00-05:00
>     404
>   
> 
> 
> So here, the subscribing AoR would be alice@domain.com. The
>  which is alice@office.com gives the URI that is
> actually diverting. While the  element gives the
> final target of the call.

Hmm. Can you explain further?

Is the AOR sip:alice@domain.com, with sip:alice@office.com being a 
registered Contact for that?

If so, I would expect that sip:alice@domain.com would be the diverting 
user. For sip:alice@office.com to be the diverting user, wouldn't that 
phone have to initiate the diversion? If that were the case, how would 
the notifier for the event discover that the diversion has occurred?

	Thanks,
	Paul

> So at any point of time, alice@domain.com can check all the
> notifications received to determine the set of diversions that have
> taken place at various registered contacts of Alice.  
> 
> Now if we take the call centre scenario, then a particular incoming call
> could get forked probably sequentially until one of the agents picks the
> call. So I feel this is not a valid use case of call diversion, but
> would qualify for a use case of sequential or simultaneous forking. 
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: Wednesday, January 20, 2010 11:34 AM
> To: Paul Kyzivat
> Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH; Gonzalo Camarillo
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
> 
> 
> On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
> 
>>
>> Elwell, John wrote:
>>>> -----Original Message-----
>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] Sent:  
>>>> 19 January 2010 17:49
>>>> To: Elwell, John; Dean Willis
>>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala- 
>>>> dispatch-comm-div-notification
>>>>
>>>> Hi John
>>>>
>>>> Sorry for the late response. Yes the notifications will be from the 
>>>> server towards the original AoR with the registered contact 
>>>> specified as part of the event package (e.g in the element 
>>>> "diverting-user").
>>>> So it
>>>> would be the job of the notifier to generate appropriate diversion 
>>>> notification information towards the target AoR.
>>> [JRE] This just confuses me again. It first says the notification 
>>> will be sent from the server to the original AOR, and then it says 
>>> notification information is send towards the target AOR - apparently 
>>> a contradiction, unless these two terms mean the same thing. Also, 
>>> why is the registered contact (I assume this means contact URI) sent 
>>> in element "diverting-user" rather than the original AOR?
>> This has confused me from the beginning.
>> It seems the assumption is that only the "diverting user" will 
>> subscribe. But in reality that doesn't make much sense if the 
>> subscription is addressed to the diverting user.
> 
> The diverting user has multiple user agents. Said user cannot remember
> which user agent is set to divert, or what it is diverting to. So said
> user subscribes to the divnot package in order to find out what the heck
> is happening.
> 
>> It makes some sense if the subscribers are UAs that have registered 
>> with the AOR of the diverting user, and the notifier is a server that 
>> mediates arriving requests to that AOR.
>>
> 
> Yes, I think that's the intent
> 
>> But even then, while its reasonable to expect that the registered 
>> devices might be interested in subscribing to this, surely they aren't
> 
>> the *only* plausible subscribers. Assuming they are is, IMO, a 
>> mistake.
> 
> I think your view of the architecture is somewhat larger than the
> author's. This is not unreasonable. Like you, I can envision other use
> cases, such as call center scenarios.
> 
> Is there any reason NOT to generalize the specification for broader
> applicability?
> 
> --
> Dean
> 
> 
> 
> 
> 

From john.elwell@siemens-enterprise.com  Wed Jan 20 13:12:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D5E3A67EA for ; Wed, 20 Jan 2010 13:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EcYUt3Ib1NF for ; Wed, 20 Jan 2010 13:12:33 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6EAA23A6920 for ; Wed, 20 Jan 2010 13:12:33 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-612911; Wed, 20 Jan 2010 22:12:28 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id CFE7C23F0278; Wed, 20 Jan 2010 22:12:28 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Jan 2010 22:12:28 +0100
From: "Elwell, John" 
To: Paul Kyzivat , Avasarala Ranjit-A20990 
Date: Wed, 20 Jan 2010 22:12:27 +0100
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
Thread-Index: AcqZ++QOt/hod3d4QxCVED5wzx9u8wAGIvQw
Message-ID: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com> <4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com> <750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com>
In-Reply-To: <4B574722.9070108@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , Gonzalo Camarillo 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2010 21:12:37 -0000

=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: 20 January 2010 18:11
> To: Avasarala Ranjit-A20990
> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
> Subject: Re: [dispatch] Comments=20
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
>=20
>=20
> Avasarala Ranjit-A20990 wrote:
> > Hi Dean
> >=20
> > A sample diversion notification document would like =20
> >=20
> > 
> >   
> >     
> >       Boss
> >       sip:boss@office.com
> >     
> >     
> >       sip:alice@office.com
> >     
> >     
> >       sip:bob@office.com
> >     
> >    =20
> 1999-06-01T13:20:00-05:00
> >     404
> >   
> > 
> >=20
> > So here, the subscribing AoR would be alice@domain.com. The
> >  which is alice@office.com gives the=20
> URI that is
> > actually diverting. While the =20
> element gives the
> > final target of the call.
>=20
> Hmm. Can you explain further?
>=20
> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a=20
> registered Contact for that?
>=20
> If so, I would expect that sip:alice@domain.com would be the=20
> diverting=20
> user. For sip:alice@office.com to be the diverting user,=20
> wouldn't that=20
> phone have to initiate the diversion? If that were the case,=20
> how would=20
> the notifier for the event discover that the diversion has occurred?
[JRE] I have exactly the same questions as Paul, but also an addition quest=
ion. If sip:boss@office.com is the contact URI for AOR sip:boss@domain.com,=
 why would  not contain sip:boss@domain.com? Althoug=
h the contact URI would be available, often the contact URI is not meaningf=
ul, i.e., often it would not explicitly identify boss. Also, from a return =
call perspective, sip:boss@domain.com would be more useful, since it would =
hopefully reach boss on whatever device he happens to be using at the time.

John

>=20
> 	Thanks,
> 	Paul
>=20
> > So at any point of time, alice@domain.com can check all the
> > notifications received to determine the set of diversions that have
> > taken place at various registered contacts of Alice. =20
> >=20
> > Now if we take the call centre scenario, then a particular=20
> incoming call
> > could get forked probably sequentially until one of the=20
> agents picks the
> > call. So I feel this is not a valid use case of call diversion, but
> > would qualify for a use case of sequential or simultaneous forking.=20
> >=20
> > Regards
> > Ranjit
> >=20
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> > Sent: Wednesday, January 20, 2010 11:34 AM
> > To: Paul Kyzivat
> > Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;=20
> Gonzalo Camarillo
> > Subject: Re: [dispatch] Comments
> > requestedondraft-avasarala-dispatch-comm-div-notification
> >=20
> >=20
> > On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
> >=20
> >>
> >> Elwell, John wrote:
> >>>> -----Original Message-----
> >>>> From: Avasarala Ranjit-A20990=20
> [mailto:ranjit@motorola.com] Sent: =20
> >>>> 19 January 2010 17:49
> >>>> To: Elwell, John; Dean Willis
> >>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> >>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala-=20
> >>>> dispatch-comm-div-notification
> >>>>
> >>>> Hi John
> >>>>
> >>>> Sorry for the late response. Yes the notifications will=20
> be from the=20
> >>>> server towards the original AoR with the registered contact=20
> >>>> specified as part of the event package (e.g in the element=20
> >>>> "diverting-user").
> >>>> So it
> >>>> would be the job of the notifier to generate appropriate=20
> diversion=20
> >>>> notification information towards the target AoR.
> >>> [JRE] This just confuses me again. It first says the notification=20
> >>> will be sent from the server to the original AOR, and=20
> then it says=20
> >>> notification information is send towards the target AOR -=20
> apparently=20
> >>> a contradiction, unless these two terms mean the same=20
> thing. Also,=20
> >>> why is the registered contact (I assume this means=20
> contact URI) sent=20
> >>> in element "diverting-user" rather than the original AOR?
> >> This has confused me from the beginning.
> >> It seems the assumption is that only the "diverting user" will=20
> >> subscribe. But in reality that doesn't make much sense if the=20
> >> subscription is addressed to the diverting user.
> >=20
> > The diverting user has multiple user agents. Said user=20
> cannot remember
> > which user agent is set to divert, or what it is diverting=20
> to. So said
> > user subscribes to the divnot package in order to find out=20
> what the heck
> > is happening.
> >=20
> >> It makes some sense if the subscribers are UAs that have=20
> registered=20
> >> with the AOR of the diverting user, and the notifier is a=20
> server that=20
> >> mediates arriving requests to that AOR.
> >>
> >=20
> > Yes, I think that's the intent
> >=20
> >> But even then, while its reasonable to expect that the registered=20
> >> devices might be interested in subscribing to this, surely=20
> they aren't
> >=20
> >> the *only* plausible subscribers. Assuming they are is, IMO, a=20
> >> mistake.
> >=20
> > I think your view of the architecture is somewhat larger than the
> > author's. This is not unreasonable. Like you, I can=20
> envision other use
> > cases, such as call center scenarios.
> >=20
> > Is there any reason NOT to generalize the specification for broader
> > applicability?
> >=20
> > --
> > Dean
> >=20
> >=20
> >=20
> >=20
> >=20
> =

From gonzalo.camarillo@ericsson.com  Thu Jan 21 01:23:32 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BDD3A69F4 for ; Thu, 21 Jan 2010 01:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.051
X-Spam-Level: 
X-Spam-Status: No, score=-106.051 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElB7P1L4rht7 for ; Thu, 21 Jan 2010 01:23:31 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 44DDE3A69F0 for ; Thu, 21 Jan 2010 01:23:30 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-ab-4b581d0d22c7
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EC.A0.11185.D0D185B4; Thu, 21 Jan 2010 10:23:25 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 10:23:25 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 10:23:24 +0100
Message-ID: <4B581D0C.80809@ericsson.com>
Date: Thu, 21 Jan 2010 11:23:24 +0200
From: Gonzalo Camarillo 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "dispatch@ietf.org" 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 09:23:24.0981 (UTC) FILETIME=[6207BE50:01CA9A7B]
X-Brightmail-Tracker: AAAAAA==
Cc: "rai-ads@tools.ietf.org" , Mary Barnes 
Subject: Re: [dispatch] IETF-77 DISPATCH WG deadlines
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 09:23:32 -0000

Folks,

this is just a reminder of the deadlines we are working with for the
next IETF (see email below).

Cheers,

Gonzalo

-------- Original Message --------
Subject: IETF-77 DISPATCH WG deadlines
Date: Wed, 16 Dec 2009 21:06:28 +0100
From: Mary Barnes 
To: dispatch@ietf.org 
CC: Gonzalo Camarillo ,
"rai-ads@tools.ietf.org" 

Hi all,

The following summarizes the deadlines for discussing topics in DISPATCH
prior to the WG session at IETF-77.

We will again work within the deadlines for BoFs:
http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77

This provides enough time to dispatch topics prior to the meeting as
appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs,
mailing lists, etc. Thus, allowing us to have more focused and
constructive discussions on a smaller set of topics prior to the WG
session.

Jan 18th, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to
submit a proposal.
------------------------------------------------------------------------
--------------------

This will help folks with similar topics to work together before the
meeting. If a preliminary charter proposal is available at this point,
please include it.

Note: Jan 25th is BoF proposal request date.

Feb 1st, 2010. Cutoff for charter proposals for topics.
--------------------------------------------------------------

A charter proposal must consist of a minimum of a problem statement and
at least one milestone/deliverable. This deadline will allow time for
consideration of proposals that could potentially be "dispatched" prior
to the WG session.

Feb 8th, 2010. Topics that are to be the focus of IETF-77 are announced.
[AD BoF approval date]
------------------------------------------------------------------------

The idea here is to focus the discussion over the weeks preceding
IETF-77 on these main topics, noting that any new or updates to any
documents are due 3-4 weeks later.  This will ensure we have
constructive discussions before the meeting and are actually able to
determine consensus as to where work should be progressed (e.g.,
separate BoF, a new WG, an existing WG, individual document, etc.) at
IETF-77. Note, that the exact disposition for a topic may (per the usual
process) require follow-up and confirmation by the ADS and/or IESG
(e.g., for a new WG, Bof, individually sponsored document, etc.) or with
another WG to ensure agreement with the DISPATCH WG consensus for the
topic.

March 1st, 2010. -00 draft deadline.
-----------------------------------

March 8th, 2010. Draft deadline.
--------------------------------

As discussed previously, the intention is not necessarily to preclude
folks submitting documents on other topics, however, it is very unlikely
there would be agenda time allocated to documents/topics submitted after
the deadlines. We can include one or two slides on these topics in the
DISPATCH WG chair charts so that the authors can gather other interested
parties to contribute to the work.

Regards,
Mary and Gonzalo
DISPATCH WG co-chairs

From salvatore.loreto@ericsson.com  Thu Jan 21 06:31:44 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21D63A68F7 for ; Thu, 21 Jan 2010 06:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI3CFcvG2f1L for ; Thu, 21 Jan 2010 06:31:43 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E90EC3A68A9 for ; Thu, 21 Jan 2010 06:31:42 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-c3-4b5865493e1a
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 40.88.11185.945685B4; Thu, 21 Jan 2010 15:31:37 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 15:31:37 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 15:31:36 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2393E244F; Thu, 21 Jan 2010 16:31:37 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D3DB221A39; Thu, 21 Jan 2010 16:31:36 +0200 (EET)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8736F219CE; Thu, 21 Jan 2010 16:31:36 +0200 (EET)
Message-ID: <4B586548.4090101@ericsson.com>
Date: Thu, 21 Jan 2010 16:31:36 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: dispatch@ietf.org
Content-Type: multipart/alternative; boundary="------------000809020109010006030708"
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 21 Jan 2010 14:31:37.0062 (UTC) FILETIME=[702B6060:01CA9AA6]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 14:31:44 -0000

This is a multi-part message in MIME format.
--------------000809020109010006030708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

there as been a short discussion in SIP Core ml
about the fact that the OPTIONS method to discovery capabilities is 
pretty broken.

As discovery capabilities is a meaningful mechanism to provide enhanced 
services,
it would be important, at least in my opinion, to do some serious rework 
on it!

Below an initial description of the problem as derived from the exchange 
of mails with Paul.

Comments are very welcome!

Regards
Sal

----------

OPTIONS as discovery capabilities mechanism
=============================

The SIP method OPTIONS allows you to query the capabilities of another 
UA or a proxy server.
The method provides a way to discover information about the supported 
methods,
content types, extensions, codecs, etc. without "ringing" the other party.

The target of the OPTIONS request is identified by the Request-URI, 
which could identify another UA
or a SIP server. However SIP OPTIONS also inherits the "traceroute" 
behaviour from HTTP/1.1, where
a server receiving an OPTIONS request with a Max-Forwards header field 
value of 0 MAY respond
to the request regardless of the Request-URI.
So the original intent and design of OPTIONS seems to be that whoever 
responds to an OPTIONS method
does it for itself.

However in the case the request is addressed to an AoR, and there is a 
proxy responsible for that AoR
(that will typically route requests via contact routing), it is not 
clear the right behaviour of the proxy.

    e.g. Alice sends a SIP OPTIONS request to discover the Bob
    capabilities; if Bob has registered two or more
            UAs, then the proxy responsible for the Bob AoR forks the
    OPTIONS request letting it arrive to all the
            registered UAs. A possible behavior for the proxy
    responsible for the Bob AoR may be to send back
            to Alice only the first response it receives. However this
    is just a possible behaviour, others are also
            possible or at least not prohibited!

A nice thing to be able to learn, through a discovery capabilities 
mechanism, would be the full set of capabilities
associated to the different UAs an user has registered and not just the 
capabilities of the UA that answers more quickly.
The question is whether OPTIONS is the way to achieve it, or it would 
make more sense to leave OPTIONS alone
and create something new.

Moreover the assumption that the capabilities of a UA are stable over 
time and are context free is also pretty broken.
UA capabilities can change for a lot of different reasons: a user switch 
off/on one of his registered UAs; or context changed
than when the query has been received.

    For instance, if Bob's device is handling a call when it receives
    the query, does the response reflect what
    it can do concurrently with the call, or what it will be able to do
    once the call had ended?

So the description of the context and of the reasons that can let 
capabilities to chance over time could provide useful
pieces of information.

--------------000809020109010006030708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi there,

there as been a short discussion in SIP Core ml 

about the fact that the OPTIONS method to discovery capabilities is
pretty broken.

As discovery capabilities is a meaningful mechanism to provide enhanced
services, 

it would be important, at least in my opinion, to do some serious
rework on it!

Below an initial description of the problem as derived from the
exchange of mails with Paul.

Comments are very welcome!

Regards

Sal

----------

OPTIONS as discovery capabilities mechanism

=============================

The SIP method OPTIONS allows you to query the capabilities of another
UA or a proxy server. 

The method provides a way to discover information about the supported
methods,

content types, extensions, codecs, etc. without "ringing" the other
party.

The target of the OPTIONS request is identified by the Request-URI,
which could identify another UA 

or a SIP server. However SIP OPTIONS also inherits the "traceroute" behaviour from HTTP/1.1,
where

a server receiving an OPTIONS request with a Max-Forwards header field
value of 0 MAY respond

to the request regardless of the Request-URI.

So the original intent and design of OPTIONS seems to be that whoever
responds to an OPTIONS method

does it for itself.

However in the case the request is addressed to an AoR, and there is a
proxy responsible for that AoR

(that will typically route requests via contact routing), it is not
clear the right behaviour of the proxy.

e.g. Alice sends a SIP OPTIONS request to discover the Bob
capabilities; if Bob has registered two or more

       UAs, then the proxy responsible for the Bob AoR forks the
OPTIONS request letting it arrive to all the 

       registered UAs. A possible behavior for the proxy responsible
for the Bob AoR may be to send back

       to Alice only the first response it receives. However this is
just a possible behaviour, others are also

       possible or at least not prohibited!

A nice thing to be able to learn, through a discovery capabilities
mechanism, would be the full set of capabilities 

associated to the different UAs an user has registered and not just the
capabilities of the UA that answers more quickly.

The question is whether OPTIONS is the way to achieve it, or it would
make more sense to leave OPTIONS alone

and create something new.

Moreover the assumption that the capabilities of a UA are stable over
time and are context free is also pretty broken.

UA capabilities can change for a lot of different reasons: a user
switch off/on one of his registered UAs; or context changed

than when the query has been received.

For instance, if Bob's device is handling a call when it
receives the query, does the response reflect what 

it can do concurrently with the call, or what it will be able to do
once the call had ended?

So the description of the context and of the reasons that can let
capabilities to chance over time could provide useful 

pieces of information.

--------------000809020109010006030708--

From peter.musgrave@magorcorp.com  Thu Jan 21 06:49:20 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBC228C15F for ; Thu, 21 Jan 2010 06:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-TNKxO0jRNe for ; Thu, 21 Jan 2010 06:49:19 -0800 (PST)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D51A63A6A14 for ; Thu, 21 Jan 2010 06:49:08 -0800 (PST)
Received: by fxm10 with SMTP id 10so48181fxm.14 for ; Thu, 21 Jan 2010 06:49:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.90.78 with SMTP id d56mr579548wef.126.1264085341361; Thu,  21 Jan 2010 06:49:01 -0800 (PST)
In-Reply-To: <4B586548.4090101@ericsson.com>
References: <4B586548.4090101@ericsson.com>
Date: Thu, 21 Jan 2010 09:49:01 -0500
Message-ID: <8e5ec72f1001210649k2c4fcb92lceace97bb07f0493@mail.gmail.com>
From: Peter Musgrave 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=0016e6d7856dbcd652047dadcdcc
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 14:49:20 -0000

--0016e6d7856dbcd652047dadcdcc
Content-Type: text/plain; charset=ISO-8859-1

Hi Sal,

I think the notion of finding different UA capabilities for an AOR is
interesting.

It seems like rich grounds for discussion since:
- I may want to direct messages to specific UAs based on capability (So can
I rely on e.g. sip-instance tags or gruu stuff in the responses? I forget if
OPTIONS does this)
- Can I learn things a user may not want me to know (i.e. is detecting the
registration of a specific UA a security issue? Although I suspect this is
an existing issue with OPTIONS?)
- do I have to do "lowest common denominator" or will a "real-world" proxy
know that e.g. it can forward 100rel stuff to one endpoint but not others
etc.

Peter

On Thu, Jan 21, 2010 at 9:31 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

>  Hi there,
>
> there as been a short discussion in SIP Core ml
> about the fact that the OPTIONS method to discovery capabilities is pretty
> broken.
>
> As discovery capabilities is a meaningful mechanism to provide enhanced
> services,
> it would be important, at least in my opinion, to do some serious rework on
> it!
>
> Below an initial description of the problem as derived from the exchange of
> mails with Paul.
>
> Comments are very welcome!
>
> Regards
> Sal
>
> ----------
>
>
>
> OPTIONS as discovery capabilities mechanism
> =============================
>
> The SIP method OPTIONS allows you to query the capabilities of another UA
> or a proxy server.
> The method provides a way to discover information about the supported
> methods,
> content types, extensions, codecs, etc. without "ringing" the other party.
>
> The target of the OPTIONS request is identified by the Request-URI, which
> could identify another UA
> or a SIP server. However SIP OPTIONS also inherits the "traceroute"
> behaviour from HTTP/1.1, where
> a server receiving an OPTIONS request with a Max-Forwards header field
> value of 0 MAY respond
> to the request regardless of the Request-URI.
> So the original intent and design of OPTIONS seems to be that whoever
> responds to an OPTIONS method
> does it for itself.
>
> However in the case the request is addressed to an AoR, and there is a
> proxy responsible for that AoR
> (that will typically route requests via contact routing), it is not clear
> the right behaviour of the proxy.
>
>  e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities;
> if Bob has registered two or more
>        UAs, then the proxy responsible for the Bob AoR forks the OPTIONS
> request letting it arrive to all the
>        registered UAs. A possible behavior for the proxy responsible for
> the Bob AoR may be to send back
>        to Alice only the first response it receives. However this is just a
> possible behaviour, others are also
>        possible or at least not prohibited!
>
>
> A nice thing to be able to learn, through a discovery capabilities
> mechanism, would be the full set of capabilities
> associated to the different UAs an user has registered and not just the
> capabilities of the UA that answers more quickly.
> The question is whether OPTIONS is the way to achieve it, or it would make
> more sense to leave OPTIONS alone
> and create something new.
>
>
>
> Moreover the assumption that the capabilities of a UA are stable over time
> and are context free is also pretty broken.
> UA capabilities can change for a lot of different reasons: a user switch
> off/on one of his registered UAs; or context changed
> than when the query has been received.
>
> For instance, if Bob's device is handling a call when it receives the
> query, does the response reflect what
> it can do concurrently with the call, or what it will be able to do once
> the call had ended?
>
>
> So the description of the context and of the reasons that can let
> capabilities to chance over time could provide useful
> pieces of information.
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

--0016e6d7856dbcd652047dadcdcc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Sal,=A0
I think the notion of finding different UA ca=
pabilities for an AOR is interesting.=A0

It seems =
like rich grounds for discussion since:- I may want to direct me=
ssages to specific UAs based on capability (So can I rely on e.g. sip-insta=
nce tags or gruu stuff in the responses? I forget if OPTIONS does this)
- Can I learn things a user may not want me to know (i.e. is detecting=
 the registration of a specific UA a security issue? Although I suspect thi=
s is an existing issue with OPTIONS?)- do I have to do "low=
est common denominator" or will a "real-world" proxy know th=
at e.g. it can forward 100rel stuff to one endpoint but not others etc.=A0<=
/div>

Peter

On T=
hu, Jan 21, 2010 at 9:31 AM, Salvatore Loreto <salvatore.loreto@ericsson.com=
> wrote:

Hi there,

there as been a short discussion in SIP Core ml 

about the fact that the OPTIONS method to discovery capabilities is
pretty broken.

As discovery capabilities is a meaningful mechanism to provide enhanced
services, 

it would be important, at least in my opinion, to do some serious
rework on it!

Below an initial description of the problem as derived from the
exchange of mails with Paul.

Comments are very welcome!

Regards

Sal

----------

OPTIONS as discovery capabilities mechanism

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

The SIP method OPTIONS allows you to query the capabilities of another
UA or a proxy server. 

The method provides a way to discover information about the supported
methods,

content types, extensions, codecs, etc. without "ringing" the oth=
er
party.

The target of the OPTIONS request is identified by the Request-URI,
which could identify another UA 

or a SIP server. However SIP OPTIONS also inherits the "traceroute&qu=
ot; behaviour from HTTP/1.1,
where

a server receiving an OPTIONS request with a Max-Forwards header field
value of 0 MAY respond

to the request regardless of the Request-URI.

So the original intent and design of OPTIONS seems to be that whoever
responds to an OPTIONS method

does it for itself.

However in the case the request is addressed to an AoR, and there is a
proxy responsible for that AoR

(that will typically route requests via contact routing), it is not
clear the right behaviour of the proxy.

e.g. Alice sends a SIP OPTIONS request to discover the Bob
capabilities; if Bob has registered two or more

=A0=A0=A0=A0=A0=A0 UAs, then the proxy responsible for the Bob AoR forks th=
e
OPTIONS request letting it arrive to all the 

=A0=A0=A0=A0=A0=A0 registered UAs. A possible behavior for the proxy respon=
sible
for the Bob AoR may be to send back

=A0=A0=A0=A0=A0=A0 to Alice only the first response it receives. However th=
is is
just a possible behaviour, others are also

=A0=A0=A0=A0=A0=A0 possible or at least not prohibited!

=A0=A0=A0=A0=A0 

A nice thing to be able to learn, through a discovery capabilities
mechanism, would be the full set of capabilities 

associated to the different UAs an user has registered and not just the
capabilities of the UA that answers more quickly.

The question is whether OPTIONS is the way to achieve it, or it would
make more sense to leave OPTIONS alone

and create something new.

Moreover the assumption that the capabilities of a UA are stable over
time and are context free is also pretty broken.

UA capabilities can change for a lot of different reasons: a user
switch off/on one of his registered UAs; or context changed

than when the query has been received.

For instance, if Bob's device is handling a call when it
receives the query, does the response reflect what 

it can do concurrently with the call, or what it will be able to do
once the call had ended?

So the description of the context and of the reasons that can let
capabilities to chance over time could provide useful 

pieces of information.

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch

--0016e6d7856dbcd652047dadcdcc--

From L.Liess@telekom.de  Thu Jan 21 07:48:12 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457013A6982 for ; Thu, 21 Jan 2010 07:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsqE4feTGmrG for ; Thu, 21 Jan 2010 07:48:11 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8499A3A6934 for ; Thu, 21 Jan 2010 07:48:09 -0800 (PST)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 21 Jan 2010 16:48:00 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 16:48: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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Jan 2010 16:47:58 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
In-reply-to: <4B560BE8.30908@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqZQBKET50fTOZNS6eUkdLkKidwEwBbtznw
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com>
From: 
To: 
X-OriginalArrivalTime: 21 Jan 2010 15:48:00.0325 (UTC) FILETIME=[1C01CF50:01CA9AB1]
Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 15:48:12 -0000

Sal,

> In my opinion the scenario to correlate an original call with a new=20
> create by a B2BUA is quite
> similar to the one where the calls that are going to be correlate are=20
> generate by the same UA.

I don't think so. While the B2BUA allways correlates an incoming and an =
outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, =
the UA may kill one of the dialogs and continue the other dialog.

> Moreover at the end both the disaggregated and especially the=20
> debug (I=20
> hope) will be used rarely.

The Session-ID will be in every INVITE, not only "on demand".=20

Thanks a lot
Laura  =20

=20
> Coming to the SIP-XMPP scenario: here I don't have a strong=20
> idea, but I=20
> guess that an identifier a la session-id
> could work also in this scenario.
>=20
>=20
> of course I may be wrong
>=20
> cheers
> Sal
>=20
> L.Liess@telekom.de wrote:
> > Hi,=20
> >
> > I think if we can show that having the same identifier for both use
> > cases has unacceptable consequences we can say that we need=20
> two diferent
> > identifiers.
> > If I understood the draft-loreto-sipping-dialog-correlation-01
> > correctly, my feeling is that we get a lot of problems if=20
> we try to use
> > the same identifier for both Session-ID and Dialog-correlation
> > (Same-Session).  =20
> >
> > Let's assume we have a same identifier, called=20
> Correlation-ID , which
> > plays both roles, Session-ID and Same-Session. =20
> >
> >
> > Consequence nr. 1)=20
> > Significant performance reduction in UAS.=20
> >
> > When Correlation-ID in it's Session-ID role becomes=20
> implemented, every
> > INVITE received by every UAS will contain a Correlation-ID.=20
> The UAS will
> > have to  search for existing dialogs related to the received
> > Correlation-ID. For Gateways or Application Servers, this=20
> can be very
> > CPU consuming. They must search for related dialogs for=20
> every received
> > INVITE. If we have two identifiers are different, in most=20
> cases the UAS
> > receives only the Session-ID which it just copies into the=20
> Respose. The
> > search is done only for the use cases described in the=20
> dialog-corelation
> > draft. =20
> >
> > So I would propose following additional requirenment for=20
> the Session-ID
> > Header:=20
> > "The mechanism should not lead to unnecessary performance=20
> reduction at
> > the UAS."
> > This requirement is not fulfilled if we have the same identifier.=20
> >
> >
> >
> > Consequence nr. 2)
> >
> > Imprecise monitoring results
> >
> > Consider the scenario in chapter 4
> > draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> > B2BUA between Alice and Bob and the service provider=20
> monitors the trafic
> > E2E.  The trubleshooting people will want to distinguish=20
> which messages
> > belong to the phone call and which messages belong to  the=20
> video call. =20
> >
> >
> >
> >
> > Alice
> > Bob
> >
> > UA_A
> >=20
> -----call-ID_a-----------B2BUA------------------------call-ID_
b1--------
> >  =20
> >> UA_B
> >>    =20
> > =20
> > Correlation-ID_a
> >                                                           (based on
> > call-ID_a)    =20
> >                                                        =20
> > =20
> >
> >    =20
> > UA_C
> >=20
> -----call-ID_c-----------B2BUA------------------------call-ID_
b2--------
> >  =20
> >> UA_B
> >>    =20
> >           Correlation-ID_a
> > Correlation-ID_a
> >          (based on call-ID_a)                         (based on
> > call-ID_a)
> >
> >  =20
> >
> >
> > Alice's phone client UA_A sends the INVITE to UA_B across=20
> the B2BUA. The
> > B2BUA constructs the Correlation-ID_a based on the Call-ID_a.=20
> > Alice's video client UA_B sends the INVITE to UA_B. This=20
> INVITE must be
> > correlated to the existing phone call and the UA_B constructs the
> > Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> > Correlation-ID_a to the UA_B transparently. Because both messages
> > between the B2BUA and UA_B have the same Correlation-ID,=20
> the monitoring
> > equipment will not be able to distinguish which message=20
> belongs to which
> > call.      =20
> >
> >
> > So I would propose following additional requirenment for=20
> the Session-ID
> > Header:=20
> >
> > "Different E2E SIP sessions must have different identifiers."=20
> >
> > I also would add following Requirement to Session-ID:=20
> >
> > "It must be possible to use the identifier without upgrading the end
> > devices software."=20
> > This requirement is met by the Session-ID proposal but it is not
> > explicitely stated in the draft.=20
> >
> >
> > Additional personal opinions on the correlation-draft:
> > - I think the Same-Session will is usefull for troubleshooting and
> > should be standardized.=20
> >
> > - The Same-Session header should use the Session-ID instead of the
> > call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> > change it. (I hope there are no conflicts here with the tags.) =20
> > =20
> >
> > Thanks  a lot
> > Laura
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >  =20
>=20
>=20

From L.Liess@telekom.de  Thu Jan 21 07:50:29 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F2A3A69C0 for ; Thu, 21 Jan 2010 07:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkYaRya2UzA6 for ; Thu, 21 Jan 2010 07:50:27 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 2120F3A6982 for ; Thu, 21 Jan 2010 07:50:26 -0800 (PST)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 21 Jan 2010 16:50:18 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 16:50:17 +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
Date: Thu, 21 Jan 2010 16:50:16 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003E15566@S4DE9JSAANI.ost.t-com.de>
In-reply-to: <4B570C8D.6030804@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqZ2QpTj7J4E2g0QdeBhcygATJS5QAypGEw
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>		<40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>	<4B560BE8.30908@ericsson.com> <4B570C8D.6030804@cisco.com>
From: 
To: , 
X-OriginalArrivalTime: 21 Jan 2010 15:50:17.0934 (UTC) FILETIME=[6E0746E0:01CA9AB1]
Cc: dispatch@ietf.org, Martin.Huelsemann@telekom.de, HKaplan@acmepacket.com
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 15:50:29 -0000

It's true. And this is a very good example.=20

Thanks a lot
Laura
=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Wednesday, January 20, 2010 3:01 PM
> To: Ian Elz
> Cc: dispatch@ietf.org; Gonzalo Camarillo;=20
> HKaplan@acmepacket.com; Liess, Laura; H=FClsemann, Martin;=20
> Pinker, Gerold
> Subject: Re: [dispatch] FW:=20
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>=20
>=20
>=20
> Ian Elz wrote:
> > Sal,
> >=20
> >>From your quote: ' "same-session could use a session-id=20
> kind of value instead of callid+tags..." '
> >=20
> > As was commented during the initial discussions on=20
> Hadriel's first draft the session-id as proposed will not=20
> replace call-id+tags. This occurs as forking will result in=20
> multiple dialogs containing the same session-id. This only=20
> really presents an issue during the early-dialog phase as=20
> only one early-dialog will result in an established session.
>=20
> While its "normal" that only one final dialog results from an=20
> INVITE, it=20
> is certainly possible to end up with more than one. While in=20
> that case=20
> its common to kill all but one, that isn't necessarily the=20
> case either.
> (E.g. a conference server that is calling out to a potential=20
> participant=20
> may find that its INVITE is forked, and may well keep all resulting=20
> dialogs.)
>=20
> So lets not design anything that depends on their being only one.
>=20
> 	Thanks,
> 	Paul
>=20
> > If you need session-id to be able to match early dialogs=20
> then you need session-id to have a different form.
> >=20
> > E.g. Session-id: UAC-part;UAS-parameter
> >=20
> > In this scenario for session tracking or established=20
> session identification only the UAC-part is required but for=20
> identification of an individual early dialog both parts would=20
> be required.
> >=20
> > Ian
> >=20
> > -----Original Message-----
> > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]=20
> > Sent: 19 January 2010 19:46
> > To: L.Liess@telekom.de
> > Cc: dispatch@ietf.org; Gonzalo Camarillo;=20
> HKaplan@acmepacket.com; Martin.Huelsemann@telekom.de;=20
> Gerold.Pinker@telekom.de
> > Subject: Re: [dispatch] FW:=20
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> >=20
> > Hi there,
> >=20
> > I have been thinking for a while on this three/four issues
> >=20
> > So let me start with the Hadriel question: "same-session=20
> could use a session-id kind of value instead of callid+tags=20
> the same-session-id is a quite an old draft"?
> > I do think it should use a session-id kind of value! (the=20
> mechanism proposed in same-session draft if stale, as it is=20
> the all draft, so it is a waste of time talk about it. Lets=20
> instead talk of and compare with the disaggregate media one:
> >=20
> http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-m
edia-00.txt )
> >=20
> >=20
> > In my opinion the scenario to correlate an original call=20
> with a new create by a B2BUA is quite similar to the one=20
> where the calls that are going to be correlate are generate=20
> by the same UA.
> > That is even more true if the correlation identifier is=20
> generated by the UA and not by the B2BUA or any other server=20
> within the network.
> > So the Hadriel's draft could be a good starting point to=20
> draft solution for disaggregated media, of course it we get=20
> rid of the limitation for debug purpose.
> > I wouldn't be worried about about the performance issue=20
> raised by Laura, at the end it would be enough insert a tag=20
> into the Session-ID header to discriminate the scenario when=20
> it is used for debugging and when for disaggregated purpose.
> > Moreover at the end both the disaggregated and especially=20
> the debug (I
> > hope) will be used rarely.
> >=20
> > Coming to the SIP-XMPP scenario: here I don't have a strong=20
> idea, but I guess that an identifier a la session-id could=20
> work also in this scenario.
> >=20
> >=20
> > of course I may be wrong
> >=20
> > cheers
> > Sal
> >=20
> > L.Liess@telekom.de wrote:
> >> Hi,=20
> >>
> >> I think if we can show that having the same identifier for both use
> >> cases has unacceptable consequences we can say that we=20
> need two diferent
> >> identifiers.
> >> If I understood the draft-loreto-sipping-dialog-correlation-01
> >> correctly, my feeling is that we get a lot of problems if=20
> we try to use
> >> the same identifier for both Session-ID and Dialog-correlation
> >> (Same-Session).  =20
> >>
> >> Let's assume we have a same identifier, called=20
> Correlation-ID , which
> >> plays both roles, Session-ID and Same-Session. =20
> >>
> >>
> >> Consequence nr. 1)=20
> >> Significant performance reduction in UAS.=20
> >>
> >> When Correlation-ID in it's Session-ID role becomes=20
> implemented, every
> >> INVITE received by every UAS will contain a=20
> Correlation-ID. The UAS will
> >> have to  search for existing dialogs related to the received
> >> Correlation-ID. For Gateways or Application Servers, this=20
> can be very
> >> CPU consuming. They must search for related dialogs for=20
> every received
> >> INVITE. If we have two identifiers are different, in most=20
> cases the UAS
> >> receives only the Session-ID which it just copies into the=20
> Respose. The
> >> search is done only for the use cases described in the=20
> dialog-corelation
> >> draft. =20
> >>
> >> So I would propose following additional requirenment for=20
> the Session-ID
> >> Header:=20
> >> "The mechanism should not lead to unnecessary performance=20
> reduction at
> >> the UAS."
> >> This requirement is not fulfilled if we have the same identifier.=20
> >>
> >>
> >>
> >> Consequence nr. 2)
> >>
> >> Imprecise monitoring results
> >>
> >> Consider the scenario in chapter 4
> >> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> >> B2BUA between Alice and Bob and the service provider=20
> monitors the trafic
> >> E2E.  The trubleshooting people will want to distinguish=20
> which messages
> >> belong to the phone call and which messages belong to  the=20
> video call. =20
> >>
> >>
> >>
> >>
> >> Alice
> >> Bob
> >>
> >> UA_A
> >>=20
> -----call-ID_a-----------B2BUA------------------------call-ID_
b1--------
> >>  =20
> >>> UA_B
> >>>    =20
> >> =20
> >> Correlation-ID_a
> >>                                                           (based on
> >> call-ID_a)    =20
> >>                                                        =20
> >> =20
> >>
> >>    =20
> >> UA_C
> >>=20
> -----call-ID_c-----------B2BUA------------------------call-ID_
b2--------
> >>  =20
> >>> UA_B
> >>>    =20
> >>           Correlation-ID_a
> >> Correlation-ID_a
> >>          (based on call-ID_a)                         (based on
> >> call-ID_a)
> >>
> >>  =20
> >>
> >>
> >> Alice's phone client UA_A sends the INVITE to UA_B across=20
> the B2BUA. The
> >> B2BUA constructs the Correlation-ID_a based on the Call-ID_a.=20
> >> Alice's video client UA_B sends the INVITE to UA_B. This=20
> INVITE must be
> >> correlated to the existing phone call and the UA_B constructs the
> >> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> >> Correlation-ID_a to the UA_B transparently. Because both messages
> >> between the B2BUA and UA_B have the same Correlation-ID,=20
> the monitoring
> >> equipment will not be able to distinguish which message=20
> belongs to which
> >> call.      =20
> >>
> >>
> >> So I would propose following additional requirenment for=20
> the Session-ID
> >> Header:=20
> >>
> >> "Different E2E SIP sessions must have different identifiers."=20
> >>
> >> I also would add following Requirement to Session-ID:=20
> >>
> >> "It must be possible to use the identifier without=20
> upgrading the end
> >> devices software."=20
> >> This requirement is met by the Session-ID proposal but it is not
> >> explicitely stated in the draft.=20
> >>
> >>
> >> Additional personal opinions on the correlation-draft:
> >> - I think the Same-Session will is usefull for troubleshooting and
> >> should be standardized.=20
> >>
> >> - The Same-Session header should use the Session-ID instead of the
> >> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> >> change it. (I hope there are no conflicts here with the tags.) =20
> >> =20
> >>
> >> Thanks  a lot
> >> Laura
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >>  =20
> >=20
> >=20
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From spencer@wonderhamster.org  Thu Jan 21 08:40:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4018B3A683C for ; Thu, 21 Jan 2010 08:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level: 
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.362,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8hPTUbNjBD2 for ; Thu, 21 Jan 2010 08:40:52 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 5B1193A6818 for ; Thu, 21 Jan 2010 08:40:52 -0800 (PST)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LfkYc-1O9rv70Y0o-00pBHJ; Thu, 21 Jan 2010 11:40:35 -0500
Message-ID: <8D823DE67CCE436AA78DD79D3AD26ADD@china.huawei.com>
From: "Spencer Dawkins" 
To: , 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
Date: Thu, 21 Jan 2010 10:40:20 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX19qVbiYflv44MBcPlh21WDc/YNFl9ca5mVP0iI X5qT0zFebEPKYX308zV7sFddgq8dqRGPF7PptrFPEFEFJ3ckp7 ZD/89s5ZNcq2FLTK68sdk5tPyCYmNUEL4BYh6pp/xM=
Cc: dispatch@ietf.org, Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 16:40:53 -0000

Laura,

>> Moreover at the end both the disaggregated and especially the
>> debug (I
>> hope) will be used rarely.

> The Session-ID will be in every INVITE, not only "on demand".

Just trying to be careful here - my understanding is that we would encourage 
people to use Session-ID this way (adding it "on demand" doesn't help us 
troubleshoot a call that's already failed), but we would not require that 
(Session-ID at MUST strength for every INVITE).

Am I understanding what you're saying correctly?

Thank you,

Spencer 

From pkyzivat@cisco.com  Thu Jan 21 08:54:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE283A6A24 for ; Thu, 21 Jan 2010 08:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.372
X-Spam-Level: 
X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH9JxsTpiGnf for ; Thu, 21 Jan 2010 08:54:52 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B7FD43A69F3 for ; Thu, 21 Jan 2010 08:54:51 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAEYVWEutJV2Z/2dsb2JhbADEGpYXgjEHggQEjgs
X-IronPort-AV: E=Sophos;i="4.49,318,1262563200"; d="scan'208";a="81310359"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2010 16:54:34 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0LGsY6n023775;  Thu, 21 Jan 2010 16:54:34 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 10:54:34 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 10:54:33 -0600
Message-ID: <4B5886C8.8020609@cisco.com>
Date: Thu, 21 Jan 2010 11:54:32 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Salvatore Loreto 
References: <4B586548.4090101@ericsson.com>
In-Reply-To: <4B586548.4090101@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 16:54:33.0659 (UTC) FILETIME=[683838B0:01CA9ABA]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 16:54:53 -0000

Presence is an existing mechanism that can potentially provide much of 
this functionality.

	Thanks,
	Paul

Salvatore Loreto wrote:
> Hi there,
> 
> there as been a short discussion in SIP Core ml
> about the fact that the OPTIONS method to discovery capabilities is 
> pretty broken.
> 
> As discovery capabilities is a meaningful mechanism to provide enhanced 
> services,
> it would be important, at least in my opinion, to do some serious rework 
> on it!
> 
> Below an initial description of the problem as derived from the exchange 
> of mails with Paul.
> 
> Comments are very welcome!
> 
> Regards
> Sal
> 
> ----------
> 
> 
> 
> OPTIONS as discovery capabilities mechanism
> =============================
> 
> The SIP method OPTIONS allows you to query the capabilities of another 
> UA or a proxy server.
> The method provides a way to discover information about the supported 
> methods,
> content types, extensions, codecs, etc. without "ringing" the other party.
> 
> The target of the OPTIONS request is identified by the Request-URI, 
> which could identify another UA
> or a SIP server. However SIP OPTIONS also inherits the "traceroute" 
> behaviour from HTTP/1.1, where
> a server receiving an OPTIONS request with a Max-Forwards header field 
> value of 0 MAY respond
> to the request regardless of the Request-URI.
> So the original intent and design of OPTIONS seems to be that whoever 
> responds to an OPTIONS method
> does it for itself.
> 
> However in the case the request is addressed to an AoR, and there is a 
> proxy responsible for that AoR
> (that will typically route requests via contact routing), it is not 
> clear the right behaviour of the proxy.
> 
>     e.g. Alice sends a SIP OPTIONS request to discover the Bob
>     capabilities; if Bob has registered two or more
>            UAs, then the proxy responsible for the Bob AoR forks the
>     OPTIONS request letting it arrive to all the
>            registered UAs. A possible behavior for the proxy responsible
>     for the Bob AoR may be to send back
>            to Alice only the first response it receives. However this is
>     just a possible behaviour, others are also
>            possible or at least not prohibited!
>          
> 
> A nice thing to be able to learn, through a discovery capabilities 
> mechanism, would be the full set of capabilities
> associated to the different UAs an user has registered and not just the 
> capabilities of the UA that answers more quickly.
> The question is whether OPTIONS is the way to achieve it, or it would 
> make more sense to leave OPTIONS alone
> and create something new.
> 
> 
> 
> Moreover the assumption that the capabilities of a UA are stable over 
> time and are context free is also pretty broken.
> UA capabilities can change for a lot of different reasons: a user switch 
> off/on one of his registered UAs; or context changed
> than when the query has been received.
> 
>     For instance, if Bob's device is handling a call when it receives
>     the query, does the response reflect what
>     it can do concurrently with the call, or what it will be able to do
>     once the call had ended?
> 
> 
> So the description of the context and of the reasons that can let 
> capabilities to chance over time could provide useful
> pieces of information.
> 
> 
> 

From pkyzivat@cisco.com  Thu Jan 21 09:22:01 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB0A3A6A5F for ; Thu, 21 Jan 2010 09:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.377
X-Spam-Level: 
X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku2CyDDKXFVj for ; Thu, 21 Jan 2010 09:21:59 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C9D3C3A6A2F for ; Thu, 21 Jan 2010 09:21:59 -0800 (PST)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAF0bWEurR7H+/2dsb2JhbADEJZYWhDwE
X-IronPort-AV: E=Sophos;i="4.49,318,1262563200"; d="scan'208";a="208728223"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2010 17:21:56 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0LHLtjK023666; Thu, 21 Jan 2010 17:21:55 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 11:21:55 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 11:21:55 -0600
Message-ID: <4B588D31.8080707@cisco.com>
Date: Thu, 21 Jan 2010 12:21:53 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: L.Liess@telekom.de
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>		<40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>	<4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 17:21:55.0605 (UTC) FILETIME=[3AE54C50:01CA9ABE]
Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 17:22:01 -0000

L.Liess@telekom.de wrote:
> 
> Sal,
> 
>> In my opinion the scenario to correlate an original call with a new 
>> create by a B2BUA is quite
>> similar to the one where the calls that are going to be correlate are 
>> generate by the same UA.
> 
> I don't think so. While the B2BUA allways correlates an incoming and an outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, the UA may kill one of the dialogs and continue the other dialog.

You've identified two extremes that seem different.
There are also cases that fall between those extremes.
For instance I'll fall back on 3pcc (which provides a never ending 
source of counter examples):

Once again the classic 3pp case:

	A ------ B ----- C
  	         |------ D

Initially B connects A and C in a call.
Later, B does a "transfer" by inviting D and reinviting A with D's media 
replacing C's, and sends a BYE to C.

I guess there is a demand that there be a session id that is shared by 
A-B and B-C. After the transfer, there should be a session id shared by 
A-B and B-D. Is there a single session id shared for all of that, or is 
there a different one after the transfer?

What if subsequent to that transfer (that resulted in A-B-D) there is 
another transfer that results in E-B-D?

Another hybrid would be:

	A ------ B
  	|        |------ D
	|--------------- D2

where A, after talking to D, added a separate session to D's separate 
device D2. (I don't know if there is any real use case for this.)

When you want the id's to be common, and when you want them to be 
separate depends on what you want to use them for. The one that is 
useful for billing may not be the one that is useful for correlation of 
behavior at the UA.

	Thanks,
	Paul

>> Moreover at the end both the disaggregated and especially the 
>> debug (I 
>> hope) will be used rarely.
> 
> The Session-ID will be in every INVITE, not only "on demand". 
> 
> Thanks a lot
> Laura   
> 
> 
>  
>> Coming to the SIP-XMPP scenario: here I don't have a strong 
>> idea, but I 
>> guess that an identifier a la session-id
>> could work also in this scenario.
>>
>>
>> of course I may be wrong
>>
>> cheers
>> Sal
>>
>> L.Liess@telekom.de wrote:
>>> Hi, 
>>>
>>> I think if we can show that having the same identifier for both use
>>> cases has unacceptable consequences we can say that we need 
>> two diferent
>>> identifiers.
>>> If I understood the draft-loreto-sipping-dialog-correlation-01
>>> correctly, my feeling is that we get a lot of problems if 
>> we try to use
>>> the same identifier for both Session-ID and Dialog-correlation
>>> (Same-Session).   
>>>
>>> Let's assume we have a same identifier, called 
>> Correlation-ID , which
>>> plays both roles, Session-ID and Same-Session.  
>>>
>>>
>>> Consequence nr. 1) 
>>> Significant performance reduction in UAS. 
>>>
>>> When Correlation-ID in it's Session-ID role becomes 
>> implemented, every
>>> INVITE received by every UAS will contain a Correlation-ID. 
>> The UAS will
>>> have to  search for existing dialogs related to the received
>>> Correlation-ID. For Gateways or Application Servers, this 
>> can be very
>>> CPU consuming. They must search for related dialogs for 
>> every received
>>> INVITE. If we have two identifiers are different, in most 
>> cases the UAS
>>> receives only the Session-ID which it just copies into the 
>> Respose. The
>>> search is done only for the use cases described in the 
>> dialog-corelation
>>> draft.  
>>>
>>> So I would propose following additional requirenment for 
>> the Session-ID
>>> Header: 
>>> "The mechanism should not lead to unnecessary performance 
>> reduction at
>>> the UAS."
>>> This requirement is not fulfilled if we have the same identifier. 
>>>
>>>
>>>
>>> Consequence nr. 2)
>>>
>>> Imprecise monitoring results
>>>
>>> Consider the scenario in chapter 4
>>> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
>>> B2BUA between Alice and Bob and the service provider 
>> monitors the trafic
>>> E2E.  The trubleshooting people will want to distinguish 
>> which messages
>>> belong to the phone call and which messages belong to  the 
>> video call.  
>>>
>>>
>>>
>>> Alice
>>> Bob
>>>
>>> UA_A
>>>
>> -----call-ID_a-----------B2BUA------------------------call-ID_
> b1--------
>>>   
>>>> UA_B
>>>>     
>>>  
>>> Correlation-ID_a
>>>                                                           (based on
>>> call-ID_a)     
>>>                                                         
>>>  
>>>
>>>     
>>> UA_C
>>>
>> -----call-ID_c-----------B2BUA------------------------call-ID_
> b2--------
>>>   
>>>> UA_B
>>>>     
>>>           Correlation-ID_a
>>> Correlation-ID_a
>>>          (based on call-ID_a)                         (based on
>>> call-ID_a)
>>>
>>>   
>>>
>>>
>>> Alice's phone client UA_A sends the INVITE to UA_B across 
>> the B2BUA. The
>>> B2BUA constructs the Correlation-ID_a based on the Call-ID_a. 
>>> Alice's video client UA_B sends the INVITE to UA_B. This 
>> INVITE must be
>>> correlated to the existing phone call and the UA_B constructs the
>>> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
>>> Correlation-ID_a to the UA_B transparently. Because both messages
>>> between the B2BUA and UA_B have the same Correlation-ID, 
>> the monitoring
>>> equipment will not be able to distinguish which message 
>> belongs to which
>>> call.       
>>>
>>>
>>> So I would propose following additional requirenment for 
>> the Session-ID
>>> Header: 
>>>
>>> "Different E2E SIP sessions must have different identifiers." 
>>>
>>> I also would add following Requirement to Session-ID: 
>>>
>>> "It must be possible to use the identifier without upgrading the end
>>> devices software." 
>>> This requirement is met by the Session-ID proposal but it is not
>>> explicitely stated in the draft. 
>>>
>>>
>>> Additional personal opinions on the correlation-draft:
>>> - I think the Same-Session will is usefull for troubleshooting and
>>> should be standardized. 
>>>
>>> - The Same-Session header should use the Session-ID instead of the
>>> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
>>> change it. (I hope there are no conflicts here with the tags.)  
>>>  
>>>
>>> Thanks  a lot
>>> Laura
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>   
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From salvatore.loreto@ericsson.com  Thu Jan 21 10:22:58 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B993A6AD3 for ; Thu, 21 Jan 2010 10:22:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.174
X-Spam-Level: 
X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXHqdFf7Fj67 for ; Thu, 21 Jan 2010 10:22:56 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 8F95C3A6ACF for ; Thu, 21 Jan 2010 10:22:55 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-8b-4b589b6fcfa7
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FB.B1.11185.F6B985B4; Thu, 21 Jan 2010 19:22:39 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 19:22:39 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 19:22:39 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2B621244F; Thu, 21 Jan 2010 20:22:39 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E452021A39; Thu, 21 Jan 2010 20:22:38 +0200 (EET)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7724F219CE; Thu, 21 Jan 2010 20:22:38 +0200 (EET)
Message-ID: <4B589B6E.5010003@ericsson.com>
Date: Thu, 21 Jan 2010 20:22:38 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: "L.Liess@telekom.de" 
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 21 Jan 2010 18:22:39.0331 (UTC) FILETIME=[B6B9C330:01CA9AC6]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" , Gonzalo Camarillo , "HKaplan@acmepacket.com" , "Martin.Huelsemann@telekom.de" , "Gerold.Pinker@telekom.de" 
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 18:22:58 -0000

On 01/21/2010 05:47 PM, L.Liess@telekom.de wrote:
>
> Sal,
>
>    
>> In my opinion the scenario to correlate an original call with a new
>> create by a B2BUA is quite
>> similar to the one where the calls that are going to be correlate are
>> generate by the same UA.
>>      
> I don't think so. While the B2BUA allways correlates an incoming and an outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, the UA may kill one of the dialogs and continue the other dialog.
>
>    
right,
what you really need in the B2BUA scenario is a mechanism to identify 
one single dialog that happens to be split  in two (incoming and 
outgoing) going through the B2BUA.

In the disaggregated media instead is to correlate a session made by two 
or more different outgoing dialogs generated by the same user so that 
they are treated by
the far end of the session as a single media session. Here the 
correlation mechanism should also have the property to pass 
transparently through the B2BUA.

So having thought more on this, thanks also to the mail discussion, I 
think it should be better taking the two Id's separate,
as using the same could generate a lot of confusion in several scenarios.

/Sal

From salvatore.loreto@ericsson.com  Thu Jan 21 10:33:07 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B6F28C175 for ; Thu, 21 Jan 2010 10:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.189
X-Spam-Level: 
X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+7UTk4nc7f6 for ; Thu, 21 Jan 2010 10:33:06 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2E4943A6452 for ; Thu, 21 Jan 2010 10:33:05 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-94-4b589ddc4bd9
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C5.82.11185.CDD985B4; Thu, 21 Jan 2010 19:33:01 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 19:33:00 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 19:33:00 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DD018244F; Thu, 21 Jan 2010 20:32:59 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9759821A39; Thu, 21 Jan 2010 20:32:59 +0200 (EET)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46846219CE; Thu, 21 Jan 2010 20:32:59 +0200 (EET)
Message-ID: <4B589DDB.8030601@ericsson.com>
Date: Thu, 21 Jan 2010 20:32:59 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Paul Kyzivat 
References: <4B586548.4090101@ericsson.com> <4B5886C8.8020609@cisco.com>
In-Reply-To: <4B5886C8.8020609@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 21 Jan 2010 18:33:00.0247 (UTC) FILETIME=[28D20670:01CA9AC8]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 18:33:07 -0000

while I agree that much of the functionalities to discovery the 
capabilities can be potentially provided by Presence,
Presence service is not always present in a Network;
and moreover people tend to use OPTIONS for this kind of work,
perhaps because it gives a flavour of real time information,
but for sure because the definition of OPTIONS is too vague in several 
aspect of what is allowed to do with it
and how OPTIONS is intended to work.

/Sal

On 01/21/2010 06:54 PM, Paul Kyzivat wrote:
> Presence is an existing mechanism that can potentially provide much of
> this functionality.
>
> 	Thanks,
> 	Paul
>
> Salvatore Loreto wrote:
>    
>> Hi there,
>>
>> there as been a short discussion in SIP Core ml
>> about the fact that the OPTIONS method to discovery capabilities is
>> pretty broken.
>>
>> As discovery capabilities is a meaningful mechanism to provide enhanced
>> services,
>> it would be important, at least in my opinion, to do some serious rework
>> on it!
>>
>> Below an initial description of the problem as derived from the exchange
>> of mails with Paul.
>>
>> Comments are very welcome!
>>
>> Regards
>> Sal
>>
>> ----------
>>
>>
>>
>> OPTIONS as discovery capabilities mechanism
>> =============================
>>
>> The SIP method OPTIONS allows you to query the capabilities of another
>> UA or a proxy server.
>> The method provides a way to discover information about the supported
>> methods,
>> content types, extensions, codecs, etc. without "ringing" the other party.
>>
>> The target of the OPTIONS request is identified by the Request-URI,
>> which could identify another UA
>> or a SIP server. However SIP OPTIONS also inherits the "traceroute"
>> behaviour from HTTP/1.1, where
>> a server receiving an OPTIONS request with a Max-Forwards header field
>> value of 0 MAY respond
>> to the request regardless of the Request-URI.
>> So the original intent and design of OPTIONS seems to be that whoever
>> responds to an OPTIONS method
>> does it for itself.
>>
>> However in the case the request is addressed to an AoR, and there is a
>> proxy responsible for that AoR
>> (that will typically route requests via contact routing), it is not
>> clear the right behaviour of the proxy.
>>
>>      e.g. Alice sends a SIP OPTIONS request to discover the Bob
>>      capabilities; if Bob has registered two or more
>>             UAs, then the proxy responsible for the Bob AoR forks the
>>      OPTIONS request letting it arrive to all the
>>             registered UAs. A possible behavior for the proxy responsible
>>      for the Bob AoR may be to send back
>>             to Alice only the first response it receives. However this is
>>      just a possible behaviour, others are also
>>             possible or at least not prohibited!
>>
>>
>> A nice thing to be able to learn, through a discovery capabilities
>> mechanism, would be the full set of capabilities
>> associated to the different UAs an user has registered and not just the
>> capabilities of the UA that answers more quickly.
>> The question is whether OPTIONS is the way to achieve it, or it would
>> make more sense to leave OPTIONS alone
>> and create something new.
>>
>>
>>
>> Moreover the assumption that the capabilities of a UA are stable over
>> time and are context free is also pretty broken.
>> UA capabilities can change for a lot of different reasons: a user switch
>> off/on one of his registered UAs; or context changed
>> than when the query has been received.
>>
>>      For instance, if Bob's device is handling a call when it receives
>>      the query, does the response reflect what
>>      it can do concurrently with the call, or what it will be able to do
>>      once the call had ended?
>>
>>
>> So the description of the context and of the reasons that can let
>> capabilities to chance over time could provide useful
>> pieces of information.
>>
>>
>>
>>      

From pkyzivat@cisco.com  Thu Jan 21 10:53:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27343A6ABF for ; Thu, 21 Jan 2010 10:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.381
X-Spam-Level: 
X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysPGuLtettl8 for ; Thu, 21 Jan 2010 10:53:36 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 96D0D3A69F5 for ; Thu, 21 Jan 2010 10:53:36 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAA4yWEurR7H+/2dsb2JhbADDcJYngjEHggQEjgs
X-IronPort-AV: E=Sophos;i="4.49,319,1262563200"; d="scan'208";a="470616398"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2010 18:53:32 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0LIrWu9018746; Thu, 21 Jan 2010 18:53:32 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 12:53:32 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 12:53:32 -0600
Message-ID: <4B58A2AB.5050404@cisco.com>
Date: Thu, 21 Jan 2010 13:53:31 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Salvatore Loreto 
References: <4B586548.4090101@ericsson.com> <4B5886C8.8020609@cisco.com> <4B589DDB.8030601@ericsson.com>
In-Reply-To: <4B589DDB.8030601@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 18:53:32.0468 (UTC) FILETIME=[07480740:01CA9ACB]
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 18:53:37 -0000

Salvatore Loreto wrote:
> 
> while I agree that much of the functionalities to discovery the 
> capabilities can be potentially provided by Presence,
> Presence service is not always present in a Network;
> and moreover people tend to use OPTIONS for this kind of work,
> perhaps because it gives a flavour of real time information,
> but for sure because the definition of OPTIONS is too vague in several 
> aspect of what is allowed to do with it
> and how OPTIONS is intended to work.

I agree that presence often isn't present, or if present isn't 
accessible to as many callers as OPTIONS might be.

OTOH, if we are talking about *extending* what it is that OPTIONS does, 
in ways that overlap further with presence, then we it may make more 
sense to rely on presence and just expand its availability.

> /Sal
> 
> 
> On 01/21/2010 06:54 PM, Paul Kyzivat wrote:
>> Presence is an existing mechanism that can potentially provide much of
>> this functionality.
>>
>>     Thanks,
>>     Paul
>>
>> Salvatore Loreto wrote:
>>   
>>> Hi there,
>>>
>>> there as been a short discussion in SIP Core ml
>>> about the fact that the OPTIONS method to discovery capabilities is
>>> pretty broken.
>>>
>>> As discovery capabilities is a meaningful mechanism to provide enhanced
>>> services,
>>> it would be important, at least in my opinion, to do some serious rework
>>> on it!
>>>
>>> Below an initial description of the problem as derived from the exchange
>>> of mails with Paul.
>>>
>>> Comments are very welcome!
>>>
>>> Regards
>>> Sal
>>>
>>> ----------
>>>
>>>
>>>
>>> OPTIONS as discovery capabilities mechanism
>>> =============================
>>>
>>> The SIP method OPTIONS allows you to query the capabilities of another
>>> UA or a proxy server.
>>> The method provides a way to discover information about the supported
>>> methods,
>>> content types, extensions, codecs, etc. without "ringing" the other 
>>> party.
>>>
>>> The target of the OPTIONS request is identified by the Request-URI,
>>> which could identify another UA
>>> or a SIP server. However SIP OPTIONS also inherits the "traceroute"
>>> behaviour from HTTP/1.1, where
>>> a server receiving an OPTIONS request with a Max-Forwards header field
>>> value of 0 MAY respond
>>> to the request regardless of the Request-URI.
>>> So the original intent and design of OPTIONS seems to be that whoever
>>> responds to an OPTIONS method
>>> does it for itself.
>>>
>>> However in the case the request is addressed to an AoR, and there is a
>>> proxy responsible for that AoR
>>> (that will typically route requests via contact routing), it is not
>>> clear the right behaviour of the proxy.
>>>
>>>      e.g. Alice sends a SIP OPTIONS request to discover the Bob
>>>      capabilities; if Bob has registered two or more
>>>             UAs, then the proxy responsible for the Bob AoR forks the
>>>      OPTIONS request letting it arrive to all the
>>>             registered UAs. A possible behavior for the proxy 
>>> responsible
>>>      for the Bob AoR may be to send back
>>>             to Alice only the first response it receives. However 
>>> this is
>>>      just a possible behaviour, others are also
>>>             possible or at least not prohibited!
>>>
>>>
>>> A nice thing to be able to learn, through a discovery capabilities
>>> mechanism, would be the full set of capabilities
>>> associated to the different UAs an user has registered and not just the
>>> capabilities of the UA that answers more quickly.
>>> The question is whether OPTIONS is the way to achieve it, or it would
>>> make more sense to leave OPTIONS alone
>>> and create something new.
>>>
>>>
>>>
>>> Moreover the assumption that the capabilities of a UA are stable over
>>> time and are context free is also pretty broken.
>>> UA capabilities can change for a lot of different reasons: a user switch
>>> off/on one of his registered UAs; or context changed
>>> than when the query has been received.
>>>
>>>      For instance, if Bob's device is handling a call when it receives
>>>      the query, does the response reflect what
>>>      it can do concurrently with the call, or what it will be able to do
>>>      once the call had ended?
>>>
>>>
>>> So the description of the context and of the reasons that can let
>>> capabilities to chance over time could provide useful
>>> pieces of information.
>>>
>>>
>>>
>>>      
> 
> 

From mary.barnes@nortel.com  Thu Jan 21 10:56:13 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6FA3A6A74 for ; Thu, 21 Jan 2010 10:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.414
X-Spam-Level: 
X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s3yf5GL3z33 for ; Thu, 21 Jan 2010 10:56:12 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 51C433A6452 for ; Thu, 21 Jan 2010 10:56:12 -0800 (PST)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0LIu0c11526; Thu, 21 Jan 2010 18:56:01 GMT
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: Thu, 21 Jan 2010 12:56:07 -0600
Message-ID: 
In-Reply-To: <2E0DC1184297454CB0FD77E6BB2F01E00109420D72@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] locating spawns of DISPATCH
Thread-Index: Acp40BCNtPXWigy6Q1y/9cBnnuaetgAE/aTwCHlSvZA=
References: <747A6506A991724FB09B129B79D5FEB6145DF116A3@EXMBXCLUS01.citservers.local> <2E0DC1184297454CB0FD77E6BB2F01E00109420D72@zrc2hxm0.corp.nortel.com>
From: "Mary Barnes" 
To: 
X-Mailman-Approved-At: Thu, 21 Jan 2010 10:57:03 -0800
Subject: Re: [dispatch] locating spawns of DISPATCH
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 18:56:13 -0000

Hi all,

I've added a summary of the dispatched items to the Wiki on the DISPATCH
WG tools page:
http://trac.tools.ietf.org/wg/dispatch/trac/wiki

I've included both the work that has been chartered or completely
dispatched along with that for which the chartering work is still
underway. I'll update it with the appropriate WG information as it
becomes available.

Please let me know if the format is useful or if you find any
inaccuracies.

Thanks,
Mary.=20

-----Original Message-----
From: Barnes, Mary (RICH2:AR00)=20
Sent: Wednesday, December 09, 2009 9:33 AM
To: Brett Tate; dispatch@ietf.org
Subject: RE: [dispatch] locating spawns of DISPATCH

Hi Brett,

That's a good point. I had been summarizing such in the status emails,
but can see the value in keeping this in a single place. I'll add a page
to the supplementary webpage on softarmor and send a note to the list
when that's done.

Thanks,
Mary.=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Brett Tate
Sent: Wednesday, December 09, 2009 7:04 AM
To: dispatch@ietf.org
Subject: [dispatch] locating spawns of DISPATCH

Greetings,

Are the working group spawns of DISPATCH collected somewhere to easily
notice them (without searching email archive)?  For instance, will they
be linked somehow to DISPATCH charter, status, or a supplemental
DISPATCH webpage?

Thanks,
Brett

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From salvatore.loreto@ericsson.com  Thu Jan 21 11:08:42 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659B43A6ABF for ; Thu, 21 Jan 2010 11:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.483
X-Spam-Level: 
X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdt3ty4h0qo6 for ; Thu, 21 Jan 2010 11:08:41 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1FD343A6A77 for ; Thu, 21 Jan 2010 11:08:40 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-88-4b58a6339f8e
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F6.95.11185.336A85B4; Thu, 21 Jan 2010 20:08:35 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 20:08:35 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 20:08:34 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E3481244F; Thu, 21 Jan 2010 21:08:34 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A3A7321A39; Thu, 21 Jan 2010 21:08:34 +0200 (EET)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5C6CB219D0; Thu, 21 Jan 2010 21:08:34 +0200 (EET)
Message-ID: <4B58A632.5080601@ericsson.com>
Date: Thu, 21 Jan 2010 21:08:34 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Paul Kyzivat 
References: <4B586548.4090101@ericsson.com> <4B5886C8.8020609@cisco.com> <4B589DDB.8030601@ericsson.com> <4B58A2AB.5050404@cisco.com>
In-Reply-To: <4B58A2AB.5050404@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 21 Jan 2010 19:08:35.0032 (UTC) FILETIME=[21405D80:01CA9ACD]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 19:08:42 -0000

On 01/21/2010 08:53 PM, Paul Kyzivat wrote:
>
> Salvatore Loreto wrote:
>    
>> while I agree that much of the functionalities to discovery the
>> capabilities can be potentially provided by Presence,
>> Presence service is not always present in a Network;
>> and moreover people tend to use OPTIONS for this kind of work,
>> perhaps because it gives a flavour of real time information,
>> but for sure because the definition of OPTIONS is too vague in several
>> aspect of what is allowed to do with it
>> and how OPTIONS is intended to work.
>>      
> I agree that presence often isn't present, or if present isn't
> accessible to as many callers as OPTIONS might be.
>
> OTOH, if we are talking about *extending* what it is that OPTIONS does,
> in ways that overlap further with presence, then we it may make more
> sense to rely on presence and just expand its availability.
>
>    
I am talking only about better define/specify the general philosophy of how
OPTIONS is intended to work.

From christer.holmberg@ericsson.com  Thu Jan 21 11:24:18 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA1028B797 for ; Thu, 21 Jan 2010 11:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level: 
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68MPSZGYHwcH for ; Thu, 21 Jan 2010 11:24:18 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A6A4628C17B for ; Thu, 21 Jan 2010 11:24:17 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-62-4b58a9dc4b04
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A3.07.11185.CD9A85B4; Thu, 21 Jan 2010 20:24:12 +0100 (CET)
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 21 Jan 2010 20:24:12 +0100
From: Christer Holmberg 
To: Salvatore Loreto , "dispatch@ietf.org" 
Date: Thu, 21 Jan 2010 20:24:10 +0100
Thread-Topic: [dispatch] SIP OPTIONS rework proposal
Thread-Index: AcqapnTQ/MVr0a7bSK+2hA0r0i+IzAAJpmwb
Message-ID: 
References: <4B586548.4090101@ericsson.com>
In-Reply-To: <4B586548.4090101@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 19:24:18 -0000

Hi,

>The target of the OPTIONS request is identified by the Request-URI, which =
could identify another UA
>or a SIP server. However SIP OPTIONS also inherits the "traceroute" behavi=
our from HTTP/1.1, where
>a server receiving an OPTIONS request with a Max-Forwards header field val=
ue of 0 MAY respond
>to the request regardless of the Request-URI.
>So the original intent and design of OPTIONS seems to be that whoever resp=
onds to an OPTIONS method
>does it for itself.

I am not sure I understand... If the M-F header field reaches 0 it should b=
e rejected by a 483 response. That is generic SIP behavior.

Or, is it somewhere said that it doesn't apply to OPTIONS?

--------

>However in the case the request is addressed to an AoR, and there is a pro=
xy responsible for that AoR
>(that will typically route requests via contact routing), it is not clear =
the right behaviour of the proxy.
>

e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities; if=
 Bob has registered two or more
       UAs, then the proxy responsible for the Bob AoR forks the OPTIONS re=
quest letting it arrive to all the
       registered UAs. A possible behavior for the proxy responsible for th=
e Bob AoR may be to send back
       to Alice only the first response it receives. However this is just a=
 possible behaviour, others are also
       possible or at least not prohibited!

Do you have something particular other possibility in mind?

--------

>A nice thing to be able to learn, through a discovery capabilities mechani=
sm, would be the full set of capabilities
>associated to the different UAs an user has registered and not just the ca=
pabilities of the UA that answers more quickly.
>The question is whether OPTIONS is the way to achieve it, or it would make=
 more sense to leave OPTIONS alone
>and create something new.

I guess you are talking about a case where I would send a single OPTIONS re=
quest to the registrar which serves you, and it would return the capabiliti=
es that your UA(s) have registered?

That could be a useful feature, but in order to return SDP information for =
the UAs they would have to provide SDP when they register.

--------

>Moreover the assumption that the capabilities of a UA are stable over time=
 and are context free is also pretty broken.
>UA capabilities can change for a lot of different reasons: a user switch o=
ff/on one of his registered UAs; or context changed
>than when the query has been received.
>
For instance, if Bob's device is handling a call when it receives the query=
, does the response reflect what
it can do concurrently with the call, or what it will be able to do once th=
e call had ended?

>So the description of the context and of the reasons that can let capabili=
ties to chance over time could provide useful
>pieces of information.

I don't think OPTIONS was ever used to retrieve information which is expect=
ed to be valid for a long time.

--------

When I read the issues above I think they are more or less related to how O=
PTIONS are treated by the network. I haven't seen anything regarding the de=
finition of OPTIONS as such.

Regards,

Christer

From pkyzivat@cisco.com  Thu Jan 21 11:40:16 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC6128C190 for ; Thu, 21 Jan 2010 11:40:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.386
X-Spam-Level: 
X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74WMqlWl7Yla for ; Thu, 21 Jan 2010 11:40:15 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 88ECF3A6AE3 for ; Thu, 21 Jan 2010 11:40:15 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAOY7WEtAZnwN/2dsb2JhbADEBJYkgjGCCwQ
X-IronPort-AV: E=Sophos;i="4.49,319,1262563200"; d="scan'208";a="81336463"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2010 19:40:10 +0000
Received: from xbh-rcd-102.cisco.com ([72.163.62.175]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0LJddLF028779; Thu, 21 Jan 2010 19:40:10 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 13:40:10 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 13:40:09 -0600
Message-ID: <4B58AD98.7030808@cisco.com>
Date: Thu, 21 Jan 2010 14:40:08 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Christer Holmberg 
References: <4B586548.4090101@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 19:40:10.0058 (UTC) FILETIME=[8AC662A0:01CA9AD1]
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 19:40:16 -0000

Christer Holmberg wrote:
> Hi,
> 
>> The target of the OPTIONS request is identified by the Request-URI, which could identify another UA
>> or a SIP server. However SIP OPTIONS also inherits the "traceroute" behaviour from HTTP/1.1, where
>> a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond
>> to the request regardless of the Request-URI.
>> So the original intent and design of OPTIONS seems to be that whoever responds to an OPTIONS method
>> does it for itself.
> 
> 
> 
> I am not sure I understand... If the M-F header field reaches 0 it should be rejected by a 483 response. That is generic SIP behavior.

3261, section 11:

    Alternatively, a server receiving an OPTIONS request with a Max-
    Forwards header field value of 0 MAY respond to the request
    regardless of the Request-URI.

       This behavior is common with HTTP/1.1.  This behavior can be used
       as a "traceroute" functionality to check the capabilities of
       individual hop servers by sending a series of OPTIONS requests
       with incremented Max-Forwards values.

> Or, is it somewhere said that it doesn't apply to OPTIONS?
> 
> 
> --------
> 
>> However in the case the request is addressed to an AoR, and there is a proxy responsible for that AoR
>> (that will typically route requests via contact routing), it is not clear the right behaviour of the proxy.
>>
> 
> e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities; if Bob has registered two or more
>        UAs, then the proxy responsible for the Bob AoR forks the OPTIONS request letting it arrive to all the
>        registered UAs. A possible behavior for the proxy responsible for the Bob AoR may be to send back
>        to Alice only the first response it receives. However this is just a possible behaviour, others are also
>        possible or at least not prohibited!
> 
> Do you have something particular other possibility in mind?
> 
> 
> 
> --------
> 
> 
> 
>> A nice thing to be able to learn, through a discovery capabilities mechanism, would be the full set of capabilities
>> associated to the different UAs an user has registered and not just the capabilities of the UA that answers more quickly.
>> The question is whether OPTIONS is the way to achieve it, or it would make more sense to leave OPTIONS alone
>> and create something new.
> 
> 
> 
> I guess you are talking about a case where I would send a single OPTIONS request to the registrar which serves you, and it would return the capabilities that your UA(s) have registered?
> 
> 
> 
> That could be a useful feature, but in order to return SDP information for the UAs they would have to provide SDP when they register.

In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
Before responding it could send distinct OPTIONS requests to all 
registered contacts. Then it could assemble the responses of them all 
into a single response to the original request. IOW, it could act as an 
OPTIONS exploder.

The significant word above is *could*. (Perhaps when hell freezes over.)

	Thanks,
	Paul

> --------
> 
>> Moreover the assumption that the capabilities of a UA are stable over time and are context free is also pretty broken.
>> UA capabilities can change for a lot of different reasons: a user switch off/on one of his registered UAs; or context changed
>> than when the query has been received.
>>
> For instance, if Bob's device is handling a call when it receives the query, does the response reflect what
> it can do concurrently with the call, or what it will be able to do once the call had ended?
> 
>> So the description of the context and of the reasons that can let capabilities to chance over time could provide useful
>> pieces of information.
> 
> 
> 
> I don't think OPTIONS was ever used to retrieve information which is expected to be valid for a long time.
> 
> 
> --------
> 
> When I read the issues above I think they are more or less related to how OPTIONS are treated by the network. I haven't seen anything regarding the definition of OPTIONS as such.
> 
> 
> 
> Regards,
> 
> 
> 
> Christer
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From christer.holmberg@ericsson.com  Thu Jan 21 11:53:36 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EE43A68D9 for ; Thu, 21 Jan 2010 11:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.138
X-Spam-Level: 
X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.111,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgaAWoVI4RL2 for ; Thu, 21 Jan 2010 11:53:35 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5BFF33A6823 for ; Thu, 21 Jan 2010 11:53:35 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-70-4b58b0b9169d
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 67.A8.11185.9B0B85B4; Thu, 21 Jan 2010 20:53:29 +0100 (CET)
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 21 Jan 2010 20:53:29 +0100
From: Christer Holmberg 
To: Paul Kyzivat 
Date: Thu, 21 Jan 2010 20:53:27 +0100
Thread-Topic: [dispatch] SIP OPTIONS rework proposal
Thread-Index: Acqa0Y0IYXFsaigwTJOlaY4umrC/nAAANEOI
Message-ID: 
References: <4B586548.4090101@ericsson.com> , <4B58AD98.7030808@cisco.com>
In-Reply-To: <4B58AD98.7030808@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 19:53:36 -0000

Hi,

>>I am not sure I understand... If the M-F header field reaches 0 it should=
 be rejected by a 483 response. That is generic SIP behavior.
>
>3261, section 11:
>
>    Alternatively, a server receiving an OPTIONS request with a Max-
>    Forwards header field value of 0 MAY respond to the request
>    regardless of the Request-URI.
>
>       This behavior is common with HTTP/1.1. This behavior can be used
>       as a "traceroute" functionality to check the capabilities of
>       individual hop servers by sending a series of OPTIONS requests
>       with incremented Max-Forwards values.

True. I guess the ideal would be to be able to indicate whether the UA want=
s a 200 or 483 in this case.

And, if you get 200 for every request, can you be sure that you have actual=
ly reached the node you wanted to reach?

--------

>>>A nice thing to be able to learn, through a discovery capabilities mecha=
nism, would be the full set of capabilities
>>>associated to the different UAs an user has registered and not just the =
capabilities of the UA that answers more quickly.
>>>The question is whether OPTIONS is the way to achieve it, or it would ma=
ke more sense to leave OPTIONS alone
>>>and create something new.
>>
>>I guess you are talking about a case where I would send a single OPTIONS =
request to the registrar which serves you, and it would return the capabili=
ties that your UA(s) have registered?
>>
>>
>>
>>That could be a useful feature, but in order to return SDP information fo=
r the UAs they would have to provide SDP when they register.
>
>In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
>Before responding it could send distinct OPTIONS requests to all
>registered contacts. Then it could assemble the responses of them all
>into a single response to the original request. IOW, it could act as an
>OPTIONS exploder.

Yes, either that, or simply send a reply based on the feature tags that the=
 UAs have registered.

Regards,

Christer

> --------
>
>> Moreover the assumption that the capabilities of a UA are stable over ti=
me and are context free is also pretty broken.
>> UA capabilities can change for a lot of different reasons: a user switch=
 off/on one of his registered UAs; or context changed
>> than when the query has been received.
>>
> For instance, if Bob's device is handling a call when it receives the que=
ry, does the response reflect what
> it can do concurrently with the call, or what it will be able to do once =
the call had ended?
>
>> So the description of the context and of the reasons that can let capabi=
lities to chance over time could provide useful
>> pieces of information.
>
>
>
> I don't think OPTIONS was ever used to retrieve information which is expe=
cted to be valid for a long time.
>
>
> --------
>
> When I read the issues above I think they are more or less related to how=
 OPTIONS are treated by the network. I haven't seen anything regarding the =
definition of OPTIONS as such.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=

From salvatore.loreto@ericsson.com  Thu Jan 21 12:08:10 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509183A67AF for ; Thu, 21 Jan 2010 12:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.457
X-Spam-Level: 
X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm46wdlzMuO1 for ; Thu, 21 Jan 2010 12:08:09 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E84003A6881 for ; Thu, 21 Jan 2010 12:08:08 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-f1-4b58b4234079
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 92.69.11185.324B85B4; Thu, 21 Jan 2010 21:08:03 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 21:08:03 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 21:08:02 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BE562244F; Thu, 21 Jan 2010 22:08:02 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82FEA21A39; Thu, 21 Jan 2010 22:08:02 +0200 (EET)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 29044219CE; Thu, 21 Jan 2010 22:08:02 +0200 (EET)
Message-ID: <4B58B421.40901@ericsson.com>
Date: Thu, 21 Jan 2010 22:08:01 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Paul Kyzivat 
References: <4B586548.4090101@ericsson.com>  <4B58AD98.7030808@cisco.com>
In-Reply-To: <4B58AD98.7030808@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 21 Jan 2010 20:08:02.0963 (UTC) FILETIME=[6FE76E30:01CA9AD5]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 20:08:10 -0000

On 01/21/2010 09:40 PM, Paul Kyzivat wrote:
>
> Christer Holmberg wrote:
>    
>> Hi,
>>
>>      
>>> The target of the OPTIONS request is identified by the Request-URI, which could identify another UA
>>> or a SIP server. However SIP OPTIONS also inherits the "traceroute" behaviour from HTTP/1.1, where
>>> a server receiving an OPTIONS request with a Max-Forwards header field value of 0 MAY respond
>>> to the request regardless of the Request-URI.
>>> So the original intent and design of OPTIONS seems to be that whoever responds to an OPTIONS method
>>> does it for itself.
>>>        
>>
>>
>> I am not sure I understand... If the M-F header field reaches 0 it should be rejected by a 483 response. That is generic SIP behavior.
>>      
> 3261, section 11:
>
>      Alternatively, a server receiving an OPTIONS request with a Max-
>      Forwards header field value of 0 MAY respond to the request
>      regardless of the Request-URI.
>
>         This behavior is common with HTTP/1.1.  This behavior can be used
>         as a "traceroute" functionality to check the capabilities of
>         individual hop servers by sending a series of OPTIONS requests
>         with incremented Max-Forwards values.
>
>    
>> Or, is it somewhere said that it doesn't apply to OPTIONS?
>>
>>
>> --------
>>
>>      
>>> However in the case the request is addressed to an AoR, and there is a proxy responsible for that AoR
>>> (that will typically route requests via contact routing), it is not clear the right behaviour of the proxy.
>>>
>>>        
>> e.g. Alice sends a SIP OPTIONS request to discover the Bob capabilities; if Bob has registered two or more
>>         UAs, then the proxy responsible for the Bob AoR forks the OPTIONS request letting it arrive to all the
>>         registered UAs. A possible behavior for the proxy responsible for the Bob AoR may be to send back
>>         to Alice only the first response it receives. However this is just a possible behaviour, others are also
>>         possible or at least not prohibited!
>>
>> Do you have something particular other possibility in mind?
>>
>>
>>
>> --------
>>
>>
>>
>>      
>>> A nice thing to be able to learn, through a discovery capabilities mechanism, would be the full set of capabilities
>>> associated to the different UAs an user has registered and not just the capabilities of the UA that answers more quickly.
>>> The question is whether OPTIONS is the way to achieve it, or it would make more sense to leave OPTIONS alone
>>> and create something new.
>>>        
>>
>>
>> I guess you are talking about a case where I would send a single OPTIONS request to the registrar which serves you, and it would return the capabilities that your UA(s) have registered?
>>
>>
>>
>> That could be a useful feature, but in order to return SDP information for the UAs they would have to provide SDP when they register.
>>      
> In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
> Before responding it could send distinct OPTIONS requests to all
> registered contacts. Then it could assemble the responses of them all
> into a single response to the original request. IOW, it could act as an
> OPTIONS exploder.
>
> The significant word above is *could*. (Perhaps when hell freezes over.)
>
>    

so what is the right behaviour in this undefined scenario: when the 
request is addressed to an AoR?
that is something we should try to clarify and explicetly allow or forbid

reading the spec is not clear, in theory the "proxy"/registrar can
- forward back the first response (to the forked OPTIONS request) it 
receives: acting as all the other forked request
or
- as the request is targeted to an AoR, and the "proxy"/registrar is in 
some sense responsible for the AoR, it could
   decide: to answer with the information it has stored at the 
registration time or decide to act as an OPTION exploder

/Sal

From tom111.taylor@bell.net  Thu Jan 21 12:08:17 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08A23A6A5D for ; Thu, 21 Jan 2010 12:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzfKcC7cJi0g for ; Thu, 21 Jan 2010 12:08:17 -0800 (PST)
Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by core3.amsl.com (Postfix) with ESMTP id 318823A6881 for ; Thu, 21 Jan 2010 12:08:17 -0800 (PST)
Received: from BLU0-SMTP71 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 12:08:13 -0800
X-Originating-IP: [76.64.156.247]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: 
Received: from [192.168.2.11] ([76.64.156.247]) by BLU0-SMTP71.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 12:08:13 -0800
Date: Thu, 21 Jan 2010 15:08:11 -0500
From: Tom Taylor 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Paul Kyzivat 
References: <4B586548.4090101@ericsson.com>	 <4B58AD98.7030808@cisco.com>
In-Reply-To: <4B58AD98.7030808@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 20:08:13.0239 (UTC) FILETIME=[76076C70:01CA9AD5]
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 20:08:18 -0000

I was thinking about this when the topic came up a few days ago. A consolidated 
response that is a union of the individual responses may not be sufficient, if 
what the OPTIONS sender is looking for is a single UA with a specified set of 
capabilities. On the other hand, a consolidated response that lists capabilities 
by UA may have security implications.

As you said: when hell freezes over.

Paul Kyzivat wrote:
> 
...
> 
> In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
> Before responding it could send distinct OPTIONS requests to all 
> registered contacts. Then it could assemble the responses of them all 
> into a single response to the original request. IOW, it could act as an 
> OPTIONS exploder.
> 
> The significant word above is *could*. (Perhaps when hell freezes over.)
> 
>     Thanks,
>     Paul
> 

From pkyzivat@cisco.com  Thu Jan 21 15:45:10 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15453A68F8 for ; Thu, 21 Jan 2010 15:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.39
X-Spam-Level: 
X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UfvSfls+LeX for ; Thu, 21 Jan 2010 15:45:10 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFAE13A6AF0 for ; Thu, 21 Jan 2010 15:45:09 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAFN1WEtAZnwN/2dsb2JhbADDXZYnhDwE
X-IronPort-AV: E=Sophos;i="4.49,321,1262563200"; d="scan'208";a="81372982"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2010 23:45:05 +0000
Received: from xbh-rcd-102.cisco.com ([72.163.62.171]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0LNj5HM020625; Thu, 21 Jan 2010 23:45:05 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 17:45:04 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 17:45:04 -0600
Message-ID: <4B58E701.4090206@cisco.com>
Date: Thu, 21 Jan 2010 18:45:05 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Salvatore Loreto 
References: <4B586548.4090101@ericsson.com>  <4B58AD98.7030808@cisco.com> <4B58B421.40901@ericsson.com>
In-Reply-To: <4B58B421.40901@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2010 23:45:04.0793 (UTC) FILETIME=[C1850090:01CA9AF3]
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2010 23:45:10 -0000

Salvatore Loreto wrote:

>>> I guess you are talking about a case where I would send a single 
>>> OPTIONS request to the registrar which serves you, and it would 
>>> return the capabilities that your UA(s) have registered?
>>>
>>> That could be a useful feature, but in order to return SDP 
>>> information for the UAs they would have to provide SDP when they 
>>> register.
>>>      
>> In theory, the "proxy"/registrar server could act as a UA for OPTIONS.
>> Before responding it could send distinct OPTIONS requests to all
>> registered contacts. Then it could assemble the responses of them all
>> into a single response to the original request. IOW, it could act as an
>> OPTIONS exploder.
>>
>> The significant word above is *could*. (Perhaps when hell freezes over.)
> 
> so what is the right behaviour in this undefined scenario: when the 
> request is addressed to an AoR?
> that is something we should try to clarify and explicetly allow or forbid
> 
> reading the spec is not clear, in theory the "proxy"/registrar can
> - forward back the first response (to the forked OPTIONS request) it 
> receives: acting as all the other forked request
> or
> - as the request is targeted to an AoR, and the "proxy"/registrar is in 
> some sense responsible for the AoR, it could
>   decide: to answer with the information it has stored at the 
> registration time or decide to act as an OPTION exploder

I think what is right depends on the eye of the beholder.
A lot of people seem to want to use OPTIONS as a ping.
They might be happy to have the proxy return for itself.

Others want and e2e test and perhaps a busy check. They want it to be 
routed as an INVITE would be.

Others ...

I think I would opt for expecting proxies to route it like regular out 
of dialog request (assuming it *is* out of dialog), just because that is 
likely to be the closest to "typical" behavior in the wild today. But if 
the proxy routes to servers based on the method, and there are only 
servers that get routed specially on method then I guess it should 
either route to (one of?) them, or answer on its own.

	Thanks,
	Paul

	Thanks,
	Paul

From zhouzp@huawei.com  Fri Jan 22 01:29:07 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FC63A692E for ; Fri, 22 Jan 2010 01:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.292
X-Spam-Level: **
X-Spam-Status: No, score=2.292 tagged_above=-999 required=5 tests=[AWL=-2.788,  BAYES_50=0.001, CN_BODY_35=0.339, FS_START_DOYOU2=1.633, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04Zm6DuVH7eu for ; Fri, 22 Jan 2010 01:29:06 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 353D63A6921 for ; Fri, 22 Jan 2010 01:29:06 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00MW36CCZS@szxga01-in.huawei.com> for dispatch@ietf.org; Fri, 22 Jan 2010 17:29:00 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWN00CF06CCEJ@szxga01-in.huawei.com> for dispatch@ietf.org; Fri, 22 Jan 2010 17:29:00 +0800 (CST)
Received: from z54906b ([10.168.86.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWN00JKM6CBZG@szxml04-in.huawei.com> for dispatch@ietf.org; Fri, 22 Jan 2010 17:29:00 +0800 (CST)
Date: Fri, 22 Jan 2010 17:28:59 +0800
From: zhipeng zhou 
To: dispatch@ietf.org
Message-id: <005101ca9b45$54180730$1556a80a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_J7EpOtYG49uZd2vjjfE68A)"
Thread-index: AcqbRVON6Rn7Mub6Rl28cxcCkowFuQ==
Subject: [dispatch] Do you have the same confusion.Thks.
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 09:29:07 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_J7EpOtYG49uZd2vjjfE68A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Dear all,
As I read the "draft-rehor-dispatch-session-recording-req" today, some
questions (confusion) remaining in my mind for a long time when I wrote =
my
draft "draft-zhipeng-dispatch-dynamic-adaptation" are awaked. So I like =
to
share them to the group and like to see whether some people can give me =
your
understanding.
In fact, the questions are quite basic for our standard work: how to =
handle
the functionlity granularity and how to define the interface.
For example, in "draft-rehor-dispatch-session-recording-req" an =
independent
Recorder(RS) is set outside from the media server.
As for my experience, an independent entity generally in telecom area =
would
permit the operators to require such devices from different vendors.
While, for how to keep a good balance for the division, is there anybody
have any good experience.
Esp. in the telecom area, the converge or division of functionalities =
are
quite common while somewhat I always feel not much confident whether the
change is rather reasonable. And in some standard processes, this kind =
of
discussion always occupy much time.
=20
The second  big confusion in my mind is the interface. The standard =
always
needs to define new interface or new message. While in some SDOs the new
interface can be defined on XML format (logic message) and leave the
concrete carring technology to the market and some SDOs like to give =
detail
transport message such as some extensions of SIP.
I do feel both ways are available in practice but somehow it seems that  =
the
logic message format will be suitable for wider application area.
=20
Totally, I just raised my rough confusion here and maybe not able to =
give
too many cases for my rough idea.
So, can you pls share with us your good experiences on this issue.
Thanks very much.
Zhipeng
=20
=20

-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail:   zhouzp@huawei.com
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2
=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************

*************************************************************************=
***
***********************************
    This e-mail and its 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.=20

    If you receive this e-mail in error, please notify the sender by =
phone
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

--Boundary_(ID_J7EpOtYG49uZd2vjjfE68A)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

Dear=20
all,
As I read the=20
"draft-rehor-dispatch-session-recording-req" today, some =
 questions=20
(confusion) remaining in my mind for a long time when I wrote my draft=20
"draft-zhipeng-dispatch-dynamic-adaptation" are awaked. So I like to =
share them=20
to the group and like to see whether some people can give me your=20
understanding.
In fact, the =
questions are=20
quite basic for our standard work: how to handle the functionlity =
granularity=20
and how to define the interface.
For example, in =

"draft-rehor-dispatch-session-recording-req" an independent =
Recorder(RS) is=20
set outside from the media server.
As for my =
experience, an=20
independent entity generally in telecom area would permit the operators =
to=20
require such devices from different vendors.
While, for how =
to keep a=20
good balance for the division, is there anybody have any good=20
experience.
Esp. in the =
telecom area,=20
the converge or division of functionalities are quite common=20
while somewhat I always feel not much confident whether the change =
is=20
rather reasonable. And in some standard processes, this kind of =
discussion=20
always occupy much time.

The second=20
 big confusion in my mind is the =
interface. The=20
standard always needs to define new interface or new message. While in =
some SDOs=20
the new interface can be defined on XML format (logic message) and leave =
the=20
concrete carring technology to the market and some SDOs like to give =
detail=20
transport message such as some extensions of SIP.
I do feel both =
ways=20
are available in practice but somehow it seems=20
that  the logic message format will be suitable for wider =
application=20
area.

Totally, I just =
raised my=20
rough confusion here and maybe not able to give too many cases for my =
rough=20
idea.
So, can you pls =
share with=20
us your good experiences on this issue.
Thanks very=20
much.
Zhipeng

-----------------------------------------------------=

Huawei Software Technologies Co.,Ltd.
Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E=
-Mail: zhouzp@huawei.com
Phone:(+86) =

25-82276771
Fax:(+86) 25-82276760
Mobile:(+86)=20
13404162849
-----------------------------------------------------

************************************************************=
***************************************************
=A1=A1=A1=A1=
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=
=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=
=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=
=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3
=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=
=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=
=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3
   =20
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=
=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=
=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
********************************************************=
*******************************************************

********************************************************=
*******************************************************
    This e-mail and its =

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

it!
******************************************************************=
*********************************************

--Boundary_(ID_J7EpOtYG49uZd2vjjfE68A)--

From ranjit@motorola.com  Fri Jan 22 02:32:20 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720543A6896 for ; Fri, 22 Jan 2010 02:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDOSJBg5lEQQ for ; Fri, 22 Jan 2010 02:32:16 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 33AC23A698A for ; Fri, 22 Jan 2010 02:32:14 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-5.tower-119.messagelabs.com!1264156324!35602100!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 26399 invoked from network); 22 Jan 2010 10:32:05 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Jan 2010 10:32:05 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0MAW4xw020763 for ; Fri, 22 Jan 2010 03:32:04 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o0MAW4rP009759 for ; Fri, 22 Jan 2010 04:32:04 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o0MAW2SI009754 for ; Fri, 22 Jan 2010 04:32:03 -0600 (CST)
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: Fri, 22 Jan 2010 18:31:40 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqZ++QOt/hod3d4QxCVED5wzx9u8wAGIvQwAE27U1A=
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com> 
From: "Avasarala Ranjit-A20990" 
To: "Elwell, John" , "Paul Kyzivat" 
X-CFilter-Loop: Reflected
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 10:32:20 -0000

Hi all

The elements have following meaning

       This element would give the details of
subscriber user - E.g. alice@domain.com

 This element gives the details of the call
originator. i.e the caller. Which in the example is sip:boss@domain.com
or=20
                        sip:boss@office.domain.com.
   This element gives the details of the device on
whose behalf diversion is taking place. For e.g. if Alice@domain.com has
set a
                        rule for alice@office.domain.com to divert all
calls from Bob between 9 AM and 10 AM to voice-mail, then the=20
                        Alice@office.domain.com would be the
"diverting-user"
      This element gives the final target of the call.
For e.g. the voice-mail.

   This element gives the actual time of diversion.
E.g. 9.30 AM

,diversion-reason-info> This element gives the reason for diversion.
E.g. Rule-id of Reason like CFB

So based on this a typical subscription document would like

          Alice 
          alice@domain.com 

                Bob

                  sip:Bob@domain.com

                Alice-Office

                  sip:alice@office.domain.com

               2010-01-22T09:00:00-05:00
               2010-01-22T10:00:00-05:00

The above XML document represents a subscription document for notifying
diversiosn that occur between 9 and 10 AM at divering user alice@
Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20
Sent: Thursday, January 21, 2010 2:42 AM
To: Paul Kyzivat; Avasarala Ranjit-A20990
Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
Subject: RE: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: 20 January 2010 18:11
> To: Avasarala Ranjit-A20990
> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
>=20
>=20
> Avasarala Ranjit-A20990 wrote:
> > Hi Dean
> >=20
> > A sample diversion notification document would like
> >=20
> > 
> >   
> >     
> >       Boss
> >       sip:boss@office.com
> >     
> >     
> >       sip:alice@office.com
> >     
> >     
> >       sip:bob@office.com
> >     
> >    =20
> 1999-06-01T13:20:00-05:00
> >     404
> >   
> > 
> >=20
> > So here, the subscribing AoR would be alice@domain.com. The=20
> >  which is alice@office.com gives the
> URI that is
> > actually diverting. While the 
> element gives the
> > final target of the call.
>=20
> Hmm. Can you explain further?
>=20
> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a=20
> registered Contact for that?
>=20
> If so, I would expect that sip:alice@domain.com would be the diverting

> user. For sip:alice@office.com to be the diverting user, wouldn't that

> phone have to initiate the diversion? If that were the case, how would

> the notifier for the event discover that the diversion has occurred?
[JRE] I have exactly the same questions as Paul, but also an addition
question. If sip:boss@office.com is the contact URI for AOR
sip:boss@domain.com, why would  not contain
sip:boss@domain.com? Although the contact URI would be available, often
the contact URI is not meaningful, i.e., often it would not explicitly
identify boss. Also, from a return call perspective, sip:boss@domain.com
would be more useful, since it would hopefully reach boss on whatever
device he happens to be using at the time.

John

>=20
> 	Thanks,
> 	Paul
>=20
> > So at any point of time, alice@domain.com can check all the=20
> > notifications received to determine the set of diversions that have=20
> > taken place at various registered contacts of Alice.
> >=20
> > Now if we take the call centre scenario, then a particular
> incoming call
> > could get forked probably sequentially until one of the
> agents picks the
> > call. So I feel this is not a valid use case of call diversion, but=20
> > would qualify for a use case of sequential or simultaneous forking.
> >=20
> > Regards
> > Ranjit
> >=20
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Wednesday, January 20, 2010 11:34 AM
> > To: Paul Kyzivat
> > Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;
> Gonzalo Camarillo
> > Subject: Re: [dispatch] Comments
> > requestedondraft-avasarala-dispatch-comm-div-notification
> >=20
> >=20
> > On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
> >=20
> >>
> >> Elwell, John wrote:
> >>>> -----Original Message-----
> >>>> From: Avasarala Ranjit-A20990
> [mailto:ranjit@motorola.com] Sent: =20
> >>>> 19 January 2010 17:49
> >>>> To: Elwell, John; Dean Willis
> >>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
> >>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala-=20
> >>>> dispatch-comm-div-notification
> >>>>
> >>>> Hi John
> >>>>
> >>>> Sorry for the late response. Yes the notifications will
> be from the
> >>>> server towards the original AoR with the registered contact=20
> >>>> specified as part of the event package (e.g in the element=20
> >>>> "diverting-user").
> >>>> So it
> >>>> would be the job of the notifier to generate appropriate
> diversion
> >>>> notification information towards the target AoR.
> >>> [JRE] This just confuses me again. It first says the notification=20
> >>> will be sent from the server to the original AOR, and
> then it says
> >>> notification information is send towards the target AOR -
> apparently
> >>> a contradiction, unless these two terms mean the same
> thing. Also,
> >>> why is the registered contact (I assume this means
> contact URI) sent
> >>> in element "diverting-user" rather than the original AOR?
> >> This has confused me from the beginning.
> >> It seems the assumption is that only the "diverting user" will=20
> >> subscribe. But in reality that doesn't make much sense if the=20
> >> subscription is addressed to the diverting user.
> >=20
> > The diverting user has multiple user agents. Said user
> cannot remember
> > which user agent is set to divert, or what it is diverting
> to. So said
> > user subscribes to the divnot package in order to find out
> what the heck
> > is happening.
> >=20
> >> It makes some sense if the subscribers are UAs that have
> registered
> >> with the AOR of the diverting user, and the notifier is a
> server that
> >> mediates arriving requests to that AOR.
> >>
> >=20
> > Yes, I think that's the intent
> >=20
> >> But even then, while its reasonable to expect that the registered=20
> >> devices might be interested in subscribing to this, surely
> they aren't
> >=20
> >> the *only* plausible subscribers. Assuming they are is, IMO, a=20
> >> mistake.
> >=20
> > I think your view of the architecture is somewhat larger than the=20
> > author's. This is not unreasonable. Like you, I can
> envision other use
> > cases, such as call center scenarios.
> >=20
> > Is there any reason NOT to generalize the specification for broader=20
> > applicability?
> >=20
> > --
> > Dean
> >=20
> >=20
> >=20
> >=20
> >=20
>=20

From christer.holmberg@ericsson.com  Fri Jan 22 02:37:53 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF5F3A680E for ; Fri, 22 Jan 2010 02:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.141
X-Spam-Level: 
X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P-zsOkfMAip for ; Fri, 22 Jan 2010 02:37:53 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B76193A67D1 for ; Fri, 22 Jan 2010 02:37:52 -0800 (PST)
X-AuditID: c1b4fb24-b7c57ae000002bb1-2d-4b597feb39f1
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 3D.93.11185.BEF795B4; Fri, 22 Jan 2010 11:37:31 +0100 (CET)
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 22 Jan 2010 11:37:31 +0100
From: Christer Holmberg 
To: Paul Kyzivat , Salvatore Loreto 
Date: Fri, 22 Jan 2010 11:37:30 +0100
Thread-Topic: [dispatch] SIP OPTIONS rework proposal
Thread-Index: Acqa88MHuL8zt23lS2+ZV9HOKL+oOAAWtL1A
Message-ID: 
References: <4B586548.4090101@ericsson.com>  <4B58AD98.7030808@cisco.com> <4B58B421.40901@ericsson.com> <4B58E701.4090206@cisco.com>
In-Reply-To: <4B58E701.4090206@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 10:37:54 -0000

Hi,

I still fail to see any issue which led to the removal of the OPTIONS text =
in the info events draft. The text was about how UAs set the header field i=
n the OPTIONS request/response (in case of 200 OK).

No, I am not suggesting to put the text back, I just have a hard time to un=
derstand what the problem was :)

Regards,

Christer

=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: 22. tammikuuta 2010 1:45
> To: Salvatore Loreto
> Cc: Christer Holmberg; dispatch@ietf.org
> Subject: Re: [dispatch] SIP OPTIONS rework proposal
>=20
>=20
>=20
> Salvatore Loreto wrote:
>=20
> >>> I guess you are talking about a case where I would send a single=20
> >>> OPTIONS request to the registrar which serves you, and it would=20
> >>> return the capabilities that your UA(s) have registered?
> >>>
> >>> That could be a useful feature, but in order to return SDP=20
> >>> information for the UAs they would have to provide SDP when they=20
> >>> register.
> >>>     =20
> >> In theory, the "proxy"/registrar server could act as a UA=20
> for OPTIONS.
> >> Before responding it could send distinct OPTIONS requests to all=20
> >> registered contacts. Then it could assemble the responses=20
> of them all=20
> >> into a single response to the original request. IOW, it=20
> could act as=20
> >> an OPTIONS exploder.
> >>
> >> The significant word above is *could*. (Perhaps when hell freezes=20
> >> over.)
> >=20
> > so what is the right behaviour in this undefined scenario: when the=20
> > request is addressed to an AoR?
> > that is something we should try to clarify and explicetly allow or=20
> > forbid
> >=20
> > reading the spec is not clear, in theory the "proxy"/registrar can
> > - forward back the first response (to the forked OPTIONS request) it
> > receives: acting as all the other forked request or
> > - as the request is targeted to an AoR, and the=20
> "proxy"/registrar is=20
> > in some sense responsible for the AoR, it could
> >   decide: to answer with the information it has stored at the=20
> > registration time or decide to act as an OPTION exploder
>=20
> I think what is right depends on the eye of the beholder.
> A lot of people seem to want to use OPTIONS as a ping.
> They might be happy to have the proxy return for itself.
>=20
> Others want and e2e test and perhaps a busy check. They want=20
> it to be routed as an INVITE would be.
>=20
> Others ...
>=20
> I think I would opt for expecting proxies to route it like=20
> regular out of dialog request (assuming it *is* out of=20
> dialog), just because that is likely to be the closest to=20
> "typical" behavior in the wild today. But if the proxy routes=20
> to servers based on the method, and there are only servers=20
> that get routed specially on method then I guess it should=20
> either route to (one of?) them, or answer on its own.
>=20
> 	Thanks,
> 	Paul
>=20
> 	Thanks,
> 	Paul
> =

From L.Liess@telekom.de  Fri Jan 22 05:35:56 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84093A68CD for ; Fri, 22 Jan 2010 05:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.174
X-Spam-Level: 
X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aXhMTdCm+c1 for ; Fri, 22 Jan 2010 05:35:56 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 5EE253A688A for ; Fri, 22 Jan 2010 05:35:54 -0800 (PST)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 22 Jan 2010 14:35:42 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 14:35:34 +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
Date: Fri, 22 Jan 2010 14:35:33 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003E5168C@S4DE9JSAANI.ost.t-com.de>
In-reply-to: <8D823DE67CCE436AA78DD79D3AD26ADD@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqauH+i9G0QJ/r7QQWyjBz2iHEulQAfscEw
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de> <8D823DE67CCE436AA78DD79D3AD26ADD@china.huawei.com>
From: 
To: , 
X-OriginalArrivalTime: 22 Jan 2010 13:35:34.0445 (UTC) FILETIME=[C64E7DD0:01CA9B67]
Cc: dispatch@ietf.org, Gerold.Pinker@telekom.de, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 13:35:56 -0000

Spencer,=20

>=20
> >> Moreover at the end both the disaggregated and especially the
> >> debug (I
> >> hope) will be used rarely.
>=20
> > The Session-ID will be in every INVITE, not only "on demand".
>=20
> Just trying to be careful here - my understanding is that we=20
> would encourage=20
> people to use Session-ID this way (adding it "on demand"=20
> doesn't help us=20
> troubleshoot a call that's already failed), but we would not=20
> require that=20
> (Session-ID at MUST strength for every INVITE).
>=20
> Am I understanding what you're saying correctly?
>=20

The current Session-ID draft states:=20
" If an out-of-dialog request is received by a B2BUA compliant with
   this document, and the request does *not* contain a Session-ID
   header field, the B2BUA MUST generate a new Session-ID. " =20

Most EDs will probably not generate a Session-ID, but the first B2BUA in =
the path will, if a carrier intends to use Session-ID.

Does this answer your question?=20

Thanks a lot
Laura

From pkyzivat@cisco.com  Fri Jan 22 06:16:29 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49F93A689D for ; Fri, 22 Jan 2010 06:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.398
X-Spam-Level: 
X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI9RMbCtHhcs for ; Fri, 22 Jan 2010 06:16:28 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 798A03A67BD for ; Fri, 22 Jan 2010 06:16:28 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAIFBWUtAZnwM/2dsb2JhbADCO5YuhDwE
X-IronPort-AV: E=Sophos;i="4.49,324,1262563200"; d="scan'208";a="81596277"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2010 14:16:23 +0000
Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0MEGNkN025658; Fri, 22 Jan 2010 14:16:23 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 08:16:23 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 08:16:22 -0600
Message-ID: <4B59B336.2050304@cisco.com>
Date: Fri, 22 Jan 2010 09:16:22 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Christer Holmberg 
References: <4B586548.4090101@ericsson.com>  <4B58AD98.7030808@cisco.com> <4B58B421.40901@ericsson.com> <4B58E701.4090206@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2010 14:16:23.0042 (UTC) FILETIME=[79C8BE20:01CA9B6D]
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] SIP OPTIONS rework proposal
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 14:16:29 -0000

Christer Holmberg wrote:
> Hi,
> 
> I still fail to see any issue which led to the removal of the OPTIONS text in the info events draft. The text was about how UAs set the header field in the OPTIONS request/response (in case of 200 OK).
> 
> No, I am not suggesting to put the text back, I just have a hard time to understand what the problem was :)

I was neutral on whether it be there or not.

> Regards,
> 
> Christer
> 
> 
>  
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
>> Sent: 22. tammikuuta 2010 1:45
>> To: Salvatore Loreto
>> Cc: Christer Holmberg; dispatch@ietf.org
>> Subject: Re: [dispatch] SIP OPTIONS rework proposal
>>
>>
>>
>> Salvatore Loreto wrote:
>>
>>>>> I guess you are talking about a case where I would send a single 
>>>>> OPTIONS request to the registrar which serves you, and it would 
>>>>> return the capabilities that your UA(s) have registered?
>>>>>
>>>>> That could be a useful feature, but in order to return SDP 
>>>>> information for the UAs they would have to provide SDP when they 
>>>>> register.
>>>>>      
>>>> In theory, the "proxy"/registrar server could act as a UA 
>> for OPTIONS.
>>>> Before responding it could send distinct OPTIONS requests to all 
>>>> registered contacts. Then it could assemble the responses 
>> of them all 
>>>> into a single response to the original request. IOW, it 
>> could act as 
>>>> an OPTIONS exploder.
>>>>
>>>> The significant word above is *could*. (Perhaps when hell freezes 
>>>> over.)
>>> so what is the right behaviour in this undefined scenario: when the 
>>> request is addressed to an AoR?
>>> that is something we should try to clarify and explicetly allow or 
>>> forbid
>>>
>>> reading the spec is not clear, in theory the "proxy"/registrar can
>>> - forward back the first response (to the forked OPTIONS request) it
>>> receives: acting as all the other forked request or
>>> - as the request is targeted to an AoR, and the 
>> "proxy"/registrar is 
>>> in some sense responsible for the AoR, it could
>>>   decide: to answer with the information it has stored at the 
>>> registration time or decide to act as an OPTION exploder
>> I think what is right depends on the eye of the beholder.
>> A lot of people seem to want to use OPTIONS as a ping.
>> They might be happy to have the proxy return for itself.
>>
>> Others want and e2e test and perhaps a busy check. They want 
>> it to be routed as an INVITE would be.
>>
>> Others ...
>>
>> I think I would opt for expecting proxies to route it like 
>> regular out of dialog request (assuming it *is* out of 
>> dialog), just because that is likely to be the closest to 
>> "typical" behavior in the wild today. But if the proxy routes 
>> to servers based on the method, and there are only servers 
>> that get routed specially on method then I guess it should 
>> either route to (one of?) them, or answer on its own.
>>
>> 	Thanks,
>> 	Paul
>>
>> 	Thanks,
>> 	Paul
>>

From pkyzivat@cisco.com  Fri Jan 22 06:45:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C391B3A6A20 for ; Fri, 22 Jan 2010 06:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.401
X-Spam-Level: 
X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQcK6ctKVBXI for ; Fri, 22 Jan 2010 06:45:36 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4A2003A68E4 for ; Fri, 22 Jan 2010 06:45:36 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPZIWUutJV2Y/2dsb2JhbADCR5YugjAHggUEjgA
X-IronPort-AV: E=Sophos;i="4.49,324,1262563200"; d="scan'208";a="234774886"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2010 14:45:31 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0MEjVwV002944;  Fri, 22 Jan 2010 14:45:31 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 08:45:31 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 08:45:31 -0600
Message-ID: <4B59BA06.40608@cisco.com>
Date: Fri, 22 Jan 2010 09:45:26 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Avasarala Ranjit-A20990 
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2010 14:45:31.0335 (UTC) FILETIME=[8BD91570:01CA9B71]
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 14:45:37 -0000

Ranjit,

The URLs you are using are suggestive as to their roles, but its still 
not entirely clear to me. Is the following correct?

sip:alice@domain.com		AOR

alice@office.domain.com		Contact registered to
				sip:alice@domain.com

sip:boss@domain.com		AOR

sip:boss@office.domain.com	Contact registered to
				sip:alice@domain.com

More inline

Avasarala Ranjit-A20990 wrote:
> Hi all
> 
> The elements have following meaning
> 
>        This element would give the details of
> subscriber user - E.g. alice@domain.com
> 
>  This element gives the details of the call
> originator. i.e the caller. Which in the example is sip:boss@domain.com
> or 
>                         sip:boss@office.domain.com.

How is the originator of a request determined? Is it from From or 
P-A-ID? How is it that either of the above might be the originator?

>    This element gives the details of the device on
> whose behalf diversion is taking place. For e.g. if Alice@domain.com has
> set a
>                         rule for alice@office.domain.com to divert all
> calls from Bob between 9 AM and 10 AM to voice-mail, then the 
>                         Alice@office.domain.com would be the
> "diverting-user"

Some questions about above:

Assuming sip:alice@office.domain.com is not an AOR, but rather is a 
registered contact to sip:alice@domain.com, where in the routing of the 
call does the server that evaluates this rule get control?

How would it work in cases where the address for Alice's office phone is 
a dynamically assigned ip address rather than a dns name?

>       This element gives the final target of the call.
> For e.g. the voice-mail.

The *final* target? I don't think that is possible.
It can at best be the address last known to the server doing the 
reporting. If the call is diverted again downstream, that won't be 
known. Or am I missing something?

Also, suppose we have an SSP that services multiple AORs. But still the 
subscriptions are on a per-AOR basis. If Alice gives a rule that diverts 
her calls to Charlie, who is also a customer of the same SSP, and 
Charlie has also installed diversion rules for his AOR, do you expect 
the notifications from subscription to Alice to report on the downstream 
diversions performed by Charlie?

>    This element gives the actual time of diversion.
> E.g. 9.30 AM
> 
> ,diversion-reason-info> This element gives the reason for diversion.
> E.g. Rule-id of Reason like CFB
> 
> So based on this a typical subscription document would like
> 
> 
>      
>        
>           Alice 
>           alice@domain.com 
>        
>      
>      
>          
>             
>               
>                 Bob
>                 
>                   sip:Bob@domain.com
>                 
>               
>             
>             
>                
>                 Alice-Office
>                 
>                   sip:alice@office.domain.com
>                 

I thought the user-name was the same as the user portion of the URI. If 
not, how does a server determine what it is in a request in order to do 
matching on it?

	Thanks,
	Paul

>               
>             
>             
>               
>                2010-01-22T09:00:00-05:00
>                2010-01-22T10:00:00-05:00
>               
>             
>             
>               
>             
>           
>       
>    
> 
> The above XML document represents a subscription document for notifying
> diversiosn that occur between 9 and 10 AM at divering user alice@
> Regards
> Ranjit
> 
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] 
> Sent: Thursday, January 21, 2010 2:42 AM
> To: Paul Kyzivat; Avasarala Ranjit-A20990
> Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
> Subject: RE: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
> 
>  
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: 20 January 2010 18:11
>> To: Avasarala Ranjit-A20990
>> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
>> Subject: Re: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>>
>>
>> Avasarala Ranjit-A20990 wrote:
>>> Hi Dean
>>>
>>> A sample diversion notification document would like
>>>
>>> 
>>>   
>>>     
>>>       Boss
>>>       sip:boss@office.com
>>>     
>>>     
>>>       sip:alice@office.com
>>>     
>>>     
>>>       sip:bob@office.com
>>>     
>>>     
>> 1999-06-01T13:20:00-05:00
>>>     404
>>>   
>>> 
>>>
>>> So here, the subscribing AoR would be alice@domain.com. The 
>>>  which is alice@office.com gives the
>> URI that is
>>> actually diverting. While the 
>> element gives the
>>> final target of the call.
>> Hmm. Can you explain further?
>>
>> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a 
>> registered Contact for that?
>>
>> If so, I would expect that sip:alice@domain.com would be the diverting
> 
>> user. For sip:alice@office.com to be the diverting user, wouldn't that
> 
>> phone have to initiate the diversion? If that were the case, how would
> 
>> the notifier for the event discover that the diversion has occurred?
> [JRE] I have exactly the same questions as Paul, but also an addition
> question. If sip:boss@office.com is the contact URI for AOR
> sip:boss@domain.com, why would  not contain
> sip:boss@domain.com? Although the contact URI would be available, often
> the contact URI is not meaningful, i.e., often it would not explicitly
> identify boss. Also, from a return call perspective, sip:boss@domain.com
> would be more useful, since it would hopefully reach boss on whatever
> device he happens to be using at the time.
> 
> John
> 
>> 	Thanks,
>> 	Paul
>>
>>> So at any point of time, alice@domain.com can check all the 
>>> notifications received to determine the set of diversions that have 
>>> taken place at various registered contacts of Alice.
>>>
>>> Now if we take the call centre scenario, then a particular
>> incoming call
>>> could get forked probably sequentially until one of the
>> agents picks the
>>> call. So I feel this is not a valid use case of call diversion, but 
>>> would qualify for a use case of sequential or simultaneous forking.
>>>
>>> Regards
>>> Ranjit
>>>
>>> -----Original Message-----
>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>> Sent: Wednesday, January 20, 2010 11:34 AM
>>> To: Paul Kyzivat
>>> Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;
>> Gonzalo Camarillo
>>> Subject: Re: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>>
>>> On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
>>>
>>>> Elwell, John wrote:
>>>>>> -----Original Message-----
>>>>>> From: Avasarala Ranjit-A20990
>> [mailto:ranjit@motorola.com] Sent:  
>>>>>> 19 January 2010 17:49
>>>>>> To: Elwell, John; Dean Willis
>>>>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>>>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala- 
>>>>>> dispatch-comm-div-notification
>>>>>>
>>>>>> Hi John
>>>>>>
>>>>>> Sorry for the late response. Yes the notifications will
>> be from the
>>>>>> server towards the original AoR with the registered contact 
>>>>>> specified as part of the event package (e.g in the element 
>>>>>> "diverting-user").
>>>>>> So it
>>>>>> would be the job of the notifier to generate appropriate
>> diversion
>>>>>> notification information towards the target AoR.
>>>>> [JRE] This just confuses me again. It first says the notification 
>>>>> will be sent from the server to the original AOR, and
>> then it says
>>>>> notification information is send towards the target AOR -
>> apparently
>>>>> a contradiction, unless these two terms mean the same
>> thing. Also,
>>>>> why is the registered contact (I assume this means
>> contact URI) sent
>>>>> in element "diverting-user" rather than the original AOR?
>>>> This has confused me from the beginning.
>>>> It seems the assumption is that only the "diverting user" will 
>>>> subscribe. But in reality that doesn't make much sense if the 
>>>> subscription is addressed to the diverting user.
>>> The diverting user has multiple user agents. Said user
>> cannot remember
>>> which user agent is set to divert, or what it is diverting
>> to. So said
>>> user subscribes to the divnot package in order to find out
>> what the heck
>>> is happening.
>>>
>>>> It makes some sense if the subscribers are UAs that have
>> registered
>>>> with the AOR of the diverting user, and the notifier is a
>> server that
>>>> mediates arriving requests to that AOR.
>>>>
>>> Yes, I think that's the intent
>>>
>>>> But even then, while its reasonable to expect that the registered 
>>>> devices might be interested in subscribing to this, surely
>> they aren't
>>>> the *only* plausible subscribers. Assuming they are is, IMO, a 
>>>> mistake.
>>> I think your view of the architecture is somewhat larger than the 
>>> author's. This is not unreasonable. Like you, I can
>> envision other use
>>> cases, such as call center scenarios.
>>>
>>> Is there any reason NOT to generalize the specification for broader 
>>> applicability?
>>>
>>> --
>>> Dean
>>>
>>>
>>>
>>>
>>>
> 

From L.Liess@telekom.de  Fri Jan 22 06:59:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775643A67DB for ; Fri, 22 Jan 2010 06:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGEbYXVu2y6N for ; Fri, 22 Jan 2010 06:59:36 -0800 (PST)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id B0AA83A68A9 for ; Fri, 22 Jan 2010 06:59:35 -0800 (PST)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 22 Jan 2010 15:59:25 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 15:59:25 +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
Date: Fri, 22 Jan 2010 15:59:24 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003E5170B@S4DE9JSAANI.ost.t-com.de>
In-reply-to: <4B588D31.8080707@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: Acqavj1ad1Ooab/7RvuNEucOm5m26AAsWQqA
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>		<40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>	<4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de> <4B588D31.8080707@cisco.com>
From: 
To: 
X-OriginalArrivalTime: 22 Jan 2010 14:59:25.0695 (UTC) FILETIME=[7D2A50F0:01CA9B73]
Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 14:59:37 -0000

Paul,

Thank you for the examples. The scenarios can be really complex. I hope =
we can get these correlation identifiers, whatever their names, to work =
correctly in all cases....=20

I am not sure I understood your message correctly. Do you say we should =
have two different identifiers because we use them for two different =
things?=20

Thanks a lot
Laura

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Thursday, January 21, 2010 6:22 PM
> To: Liess, Laura
> Cc: salvatore.loreto@ericsson.com; dispatch@ietf.org;=20
> gonzalo.camarillo@ericsson.com; HKaplan@acmepacket.com;=20
> H=FClsemann, Martin; Pinker, Gerold
> Subject: Re: [dispatch] FW:=20
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>=20
>=20
>=20
> L.Liess@telekom.de wrote:
> >=20
> > Sal,
> >=20
> >> In my opinion the scenario to correlate an original call=20
> with a new=20
> >> create by a B2BUA is quite
> >> similar to the one where the calls that are going to be=20
> correlate are=20
> >> generate by the same UA.
> >=20
> > I don't think so. While the B2BUA allways correlates an=20
> incoming and an outgoing dialog, the UA may correlate two=20
> outgoing dialogs. Additionaly, the UA may kill one of the=20
> dialogs and continue the other dialog.
>=20
> You've identified two extremes that seem different.
> There are also cases that fall between those extremes.
> For instance I'll fall back on 3pcc (which provides a never ending=20
> source of counter examples):
>=20
> Once again the classic 3pp case:
>=20
> 	A ------ B ----- C
>   	         |------ D
>=20
> Initially B connects A and C in a call.
> Later, B does a "transfer" by inviting D and reinviting A=20
> with D's media=20
> replacing C's, and sends a BYE to C.
>=20
> I guess there is a demand that there be a session id that is=20
> shared by=20
> A-B and B-C. After the transfer, there should be a session id=20
> shared by=20
> A-B and B-D. Is there a single session id shared for all of=20
> that, or is=20
> there a different one after the transfer?
>=20
> What if subsequent to that transfer (that resulted in A-B-D) there is=20
> another transfer that results in E-B-D?
>=20
> Another hybrid would be:
>=20
> 	A ------ B
>   	|        |------ D
> 	|--------------- D2
>=20
> where A, after talking to D, added a separate session to D's separate=20
> device D2. (I don't know if there is any real use case for this.)
>=20
> When you want the id's to be common, and when you want them to be=20
> separate depends on what you want to use them for. The one that is=20
> useful for billing may not be the one that is useful for=20
> correlation of=20
> behavior at the UA.
>=20
> 	Thanks,
> 	Paul
>=20
> >> Moreover at the end both the disaggregated and especially the=20
> >> debug (I=20
> >> hope) will be used rarely.
> >=20
> > The Session-ID will be in every INVITE, not only "on demand".=20
> >=20
> > Thanks a lot
> > Laura  =20
> >=20
> >=20
> > =20
> >> Coming to the SIP-XMPP scenario: here I don't have a strong=20
> >> idea, but I=20
> >> guess that an identifier a la session-id
> >> could work also in this scenario.
> >>
> >>
> >> of course I may be wrong
> >>
> >> cheers
> >> Sal
> >>
> >> L.Liess@telekom.de wrote:
> >>> Hi,=20
> >>>
> >>> I think if we can show that having the same identifier=20
> for both use
> >>> cases has unacceptable consequences we can say that we need=20
> >> two diferent
> >>> identifiers.
> >>> If I understood the draft-loreto-sipping-dialog-correlation-01
> >>> correctly, my feeling is that we get a lot of problems if=20
> >> we try to use
> >>> the same identifier for both Session-ID and Dialog-correlation
> >>> (Same-Session).  =20
> >>>
> >>> Let's assume we have a same identifier, called=20
> >> Correlation-ID , which
> >>> plays both roles, Session-ID and Same-Session. =20
> >>>
> >>>
> >>> Consequence nr. 1)=20
> >>> Significant performance reduction in UAS.=20
> >>>
> >>> When Correlation-ID in it's Session-ID role becomes=20
> >> implemented, every
> >>> INVITE received by every UAS will contain a Correlation-ID.=20
> >> The UAS will
> >>> have to  search for existing dialogs related to the received
> >>> Correlation-ID. For Gateways or Application Servers, this=20
> >> can be very
> >>> CPU consuming. They must search for related dialogs for=20
> >> every received
> >>> INVITE. If we have two identifiers are different, in most=20
> >> cases the UAS
> >>> receives only the Session-ID which it just copies into the=20
> >> Respose. The
> >>> search is done only for the use cases described in the=20
> >> dialog-corelation
> >>> draft. =20
> >>>
> >>> So I would propose following additional requirenment for=20
> >> the Session-ID
> >>> Header:=20
> >>> "The mechanism should not lead to unnecessary performance=20
> >> reduction at
> >>> the UAS."
> >>> This requirement is not fulfilled if we have the same identifier.=20
> >>>
> >>>
> >>>
> >>> Consequence nr. 2)
> >>>
> >>> Imprecise monitoring results
> >>>
> >>> Consider the scenario in chapter 4
> >>> draft-loreto-sipping-dialog-correlation-01. Additionaly,=20
> there is a
> >>> B2BUA between Alice and Bob and the service provider=20
> >> monitors the trafic
> >>> E2E.  The trubleshooting people will want to distinguish=20
> >> which messages
> >>> belong to the phone call and which messages belong to  the=20
> >> video call. =20
> >>>
> >>>
> >>>
> >>> Alice
> >>> Bob
> >>>
> >>> UA_A
> >>>
> >> -----call-ID_a-----------B2BUA------------------------call-ID_
> > b1--------
> >>>  =20
> >>>> UA_B
> >>>>    =20
> >>> =20
> >>> Correlation-ID_a
> >>>                                                          =20
> (based on
> >>> call-ID_a)    =20
> >>>                                                        =20
> >>> =20
> >>>
> >>>    =20
> >>> UA_C
> >>>
> >> -----call-ID_c-----------B2BUA------------------------call-ID_
> > b2--------
> >>>  =20
> >>>> UA_B
> >>>>    =20
> >>>           Correlation-ID_a
> >>> Correlation-ID_a
> >>>          (based on call-ID_a)                         (based on
> >>> call-ID_a)
> >>>
> >>>  =20
> >>>
> >>>
> >>> Alice's phone client UA_A sends the INVITE to UA_B across=20
> >> the B2BUA. The
> >>> B2BUA constructs the Correlation-ID_a based on the Call-ID_a.=20
> >>> Alice's video client UA_B sends the INVITE to UA_B. This=20
> >> INVITE must be
> >>> correlated to the existing phone call and the UA_B constructs the
> >>> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> >>> Correlation-ID_a to the UA_B transparently. Because both messages
> >>> between the B2BUA and UA_B have the same Correlation-ID,=20
> >> the monitoring
> >>> equipment will not be able to distinguish which message=20
> >> belongs to which
> >>> call.      =20
> >>>
> >>>
> >>> So I would propose following additional requirenment for=20
> >> the Session-ID
> >>> Header:=20
> >>>
> >>> "Different E2E SIP sessions must have different identifiers."=20
> >>>
> >>> I also would add following Requirement to Session-ID:=20
> >>>
> >>> "It must be possible to use the identifier without=20
> upgrading the end
> >>> devices software."=20
> >>> This requirement is met by the Session-ID proposal but it is not
> >>> explicitely stated in the draft.=20
> >>>
> >>>
> >>> Additional personal opinions on the correlation-draft:
> >>> - I think the Same-Session will is usefull for troubleshooting and
> >>> should be standardized.=20
> >>>
> >>> - The Same-Session header should use the Session-ID instead of the
> >>> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> >>> change it. (I hope there are no conflicts here with the tags.) =20
> >>> =20
> >>>
> >>> Thanks  a lot
> >>> Laura
> >>> _______________________________________________
> >>> dispatch mailing list
> >>> dispatch@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>  =20
> >>
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
>=20

From pkyzivat@cisco.com  Fri Jan 22 08:05:59 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5073A686C for ; Fri, 22 Jan 2010 08:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.405
X-Spam-Level: 
X-Spam-Status: No, score=-10.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-KDhTabzMkW for ; Fri, 22 Jan 2010 08:05:57 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D4D473A682E for ; Fri, 22 Jan 2010 08:05:57 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALZbWUutJV2Y/2dsb2JhbADCVZYuhDwE
X-IronPort-AV: E=Sophos;i="4.49,324,1262563200"; d="scan'208";a="471197558"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 22 Jan 2010 16:05:53 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0MG5rxs021784;  Fri, 22 Jan 2010 16:05:53 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 10:05:53 -0600
Received: from [161.44.182.117] ([161.44.182.117]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Jan 2010 10:05:52 -0600
Message-ID: <4B59CCE5.2010202@cisco.com>
Date: Fri, 22 Jan 2010 11:05:57 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: L.Liess@telekom.de
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>		<40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de>	<4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de> <4B588D31.8080707@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003E5170B@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003E5170B@S4DE9JSAANI.ost.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 22 Jan 2010 16:05:52.0802 (UTC) FILETIME=[C5AA9020:01CA9B7C]
Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de, Gerold.Pinker@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2010 16:05:59 -0000

L.Liess@telekom.de wrote:
> Paul,
> 
> Thank you for the examples. The scenarios can be really complex. I hope we can get these correlation identifiers, whatever their names, to work correctly in all cases.... 
> 
> I am not sure I understood your message correctly. Do you say we should have two different identifiers because we use them for two different things? 

I think there may be more than two distinct usages that will require 
different ones.

IMO use cases should be gathered and then bucketed into sets that can be 
satisfied by a single mechanism, without assuming initially how many 
buckets there will be.

(But I'm still on record as not being convinced that a correlation id is 
needed *at all* for the case when multiple sip UAs are participating on 
behalf of a single user in a call.)

> Thanks a lot
> Laura
> 
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
>> Sent: Thursday, January 21, 2010 6:22 PM
>> To: Liess, Laura
>> Cc: salvatore.loreto@ericsson.com; dispatch@ietf.org; 
>> gonzalo.camarillo@ericsson.com; HKaplan@acmepacket.com; 
>> H�lsemann, Martin; Pinker, Gerold
>> Subject: Re: [dispatch] FW: 
>> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>>
>>
>>
>> L.Liess@telekom.de wrote:
>>> Sal,
>>>
>>>> In my opinion the scenario to correlate an original call 
>> with a new 
>>>> create by a B2BUA is quite
>>>> similar to the one where the calls that are going to be 
>> correlate are 
>>>> generate by the same UA.
>>> I don't think so. While the B2BUA allways correlates an 
>> incoming and an outgoing dialog, the UA may correlate two 
>> outgoing dialogs. Additionaly, the UA may kill one of the 
>> dialogs and continue the other dialog.
>>
>> You've identified two extremes that seem different.
>> There are also cases that fall between those extremes.
>> For instance I'll fall back on 3pcc (which provides a never ending 
>> source of counter examples):
>>
>> Once again the classic 3pp case:
>>
>> 	A ------ B ----- C
>>   	         |------ D
>>
>> Initially B connects A and C in a call.
>> Later, B does a "transfer" by inviting D and reinviting A 
>> with D's media 
>> replacing C's, and sends a BYE to C.
>>
>> I guess there is a demand that there be a session id that is 
>> shared by 
>> A-B and B-C. After the transfer, there should be a session id 
>> shared by 
>> A-B and B-D. Is there a single session id shared for all of 
>> that, or is 
>> there a different one after the transfer?
>>
>> What if subsequent to that transfer (that resulted in A-B-D) there is 
>> another transfer that results in E-B-D?
>>
>> Another hybrid would be:
>>
>> 	A ------ B
>>   	|        |------ D
>> 	|--------------- D2
>>
>> where A, after talking to D, added a separate session to D's separate 
>> device D2. (I don't know if there is any real use case for this.)
>>
>> When you want the id's to be common, and when you want them to be 
>> separate depends on what you want to use them for. The one that is 
>> useful for billing may not be the one that is useful for 
>> correlation of 
>> behavior at the UA.
>>
>> 	Thanks,
>> 	Paul
>>
>>>> Moreover at the end both the disaggregated and especially the 
>>>> debug (I 
>>>> hope) will be used rarely.
>>> The Session-ID will be in every INVITE, not only "on demand". 
>>>
>>> Thanks a lot
>>> Laura   
>>>
>>>
>>>  
>>>> Coming to the SIP-XMPP scenario: here I don't have a strong 
>>>> idea, but I 
>>>> guess that an identifier a la session-id
>>>> could work also in this scenario.
>>>>
>>>>
>>>> of course I may be wrong
>>>>
>>>> cheers
>>>> Sal
>>>>
>>>> L.Liess@telekom.de wrote:
>>>>> Hi, 
>>>>>
>>>>> I think if we can show that having the same identifier 
>> for both use
>>>>> cases has unacceptable consequences we can say that we need 
>>>> two diferent
>>>>> identifiers.
>>>>> If I understood the draft-loreto-sipping-dialog-correlation-01
>>>>> correctly, my feeling is that we get a lot of problems if 
>>>> we try to use
>>>>> the same identifier for both Session-ID and Dialog-correlation
>>>>> (Same-Session).   
>>>>>
>>>>> Let's assume we have a same identifier, called 
>>>> Correlation-ID , which
>>>>> plays both roles, Session-ID and Same-Session.  
>>>>>
>>>>>
>>>>> Consequence nr. 1) 
>>>>> Significant performance reduction in UAS. 
>>>>>
>>>>> When Correlation-ID in it's Session-ID role becomes 
>>>> implemented, every
>>>>> INVITE received by every UAS will contain a Correlation-ID. 
>>>> The UAS will
>>>>> have to  search for existing dialogs related to the received
>>>>> Correlation-ID. For Gateways or Application Servers, this 
>>>> can be very
>>>>> CPU consuming. They must search for related dialogs for 
>>>> every received
>>>>> INVITE. If we have two identifiers are different, in most 
>>>> cases the UAS
>>>>> receives only the Session-ID which it just copies into the 
>>>> Respose. The
>>>>> search is done only for the use cases described in the 
>>>> dialog-corelation
>>>>> draft.  
>>>>>
>>>>> So I would propose following additional requirenment for 
>>>> the Session-ID
>>>>> Header: 
>>>>> "The mechanism should not lead to unnecessary performance 
>>>> reduction at
>>>>> the UAS."
>>>>> This requirement is not fulfilled if we have the same identifier. 
>>>>>
>>>>>
>>>>>
>>>>> Consequence nr. 2)
>>>>>
>>>>> Imprecise monitoring results
>>>>>
>>>>> Consider the scenario in chapter 4
>>>>> draft-loreto-sipping-dialog-correlation-01. Additionaly, 
>> there is a
>>>>> B2BUA between Alice and Bob and the service provider 
>>>> monitors the trafic
>>>>> E2E.  The trubleshooting people will want to distinguish 
>>>> which messages
>>>>> belong to the phone call and which messages belong to  the 
>>>> video call.  
>>>>>
>>>>>
>>>>> Alice
>>>>> Bob
>>>>>
>>>>> UA_A
>>>>>
>>>> -----call-ID_a-----------B2BUA------------------------call-ID_
>>> b1--------
>>>>>   
>>>>>> UA_B
>>>>>>     
>>>>>  
>>>>> Correlation-ID_a
>>>>>                                                           
>> (based on
>>>>> call-ID_a)     
>>>>>                                                         
>>>>>  
>>>>>
>>>>>     
>>>>> UA_C
>>>>>
>>>> -----call-ID_c-----------B2BUA------------------------call-ID_
>>> b2--------
>>>>>   
>>>>>> UA_B
>>>>>>     
>>>>>           Correlation-ID_a
>>>>> Correlation-ID_a
>>>>>          (based on call-ID_a)                         (based on
>>>>> call-ID_a)
>>>>>
>>>>>   
>>>>>
>>>>>
>>>>> Alice's phone client UA_A sends the INVITE to UA_B across 
>>>> the B2BUA. The
>>>>> B2BUA constructs the Correlation-ID_a based on the Call-ID_a. 
>>>>> Alice's video client UA_B sends the INVITE to UA_B. This 
>>>> INVITE must be
>>>>> correlated to the existing phone call and the UA_B constructs the
>>>>> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
>>>>> Correlation-ID_a to the UA_B transparently. Because both messages
>>>>> between the B2BUA and UA_B have the same Correlation-ID, 
>>>> the monitoring
>>>>> equipment will not be able to distinguish which message 
>>>> belongs to which
>>>>> call.       
>>>>>
>>>>>
>>>>> So I would propose following additional requirenment for 
>>>> the Session-ID
>>>>> Header: 
>>>>>
>>>>> "Different E2E SIP sessions must have different identifiers." 
>>>>>
>>>>> I also would add following Requirement to Session-ID: 
>>>>>
>>>>> "It must be possible to use the identifier without 
>> upgrading the end
>>>>> devices software." 
>>>>> This requirement is met by the Session-ID proposal but it is not
>>>>> explicitely stated in the draft. 
>>>>>
>>>>>
>>>>> Additional personal opinions on the correlation-draft:
>>>>> - I think the Same-Session will is usefull for troubleshooting and
>>>>> should be standardized. 
>>>>>
>>>>> - The Same-Session header should use the Session-ID instead of the
>>>>> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
>>>>> change it. (I hope there are no conflicts here with the tags.)  
>>>>>  
>>>>>
>>>>> Thanks  a lot
>>>>> Laura
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> dispatch@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>   
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
> 

From lconroy@insensate.co.uk  Sat Jan 23 15:33:46 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E0D28B56A for ; Sat, 23 Jan 2010 15:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltrVnEuZKP9V for ; Sat, 23 Jan 2010 15:33:46 -0800 (PST)
Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 94BB03A684E for ; Sat, 23 Jan 2010 15:33:42 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 70CF7102FDB for ; Sat, 23 Jan 2010 23:33:40 +0000 (GMT)
Message-Id: 
From: Lawrence Conroy 
To: dispatch@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 23 Jan 2010 23:33:40 +0000
X-Mailer: Apple Mail (2.936)
Subject: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2010 23:33:46 -0000

Hi Folks,
  I've just read through the E2M thread in the archive, and "am  
puzzled".

This is a lookup, mapping from an E.164 number, to stuff. Not from  
email, not from alphabetic SIP URIs, but from phone numbers.
This lookup is extremely likely to be done before, during, or after a  
call. In at least the former two cases, that means now -- both NOW, as  
in the IETF "get off their encounter suited butts and do something",  
and NOW, as in "I do not want to grind through some RDF meta- 
meditation before I can find out who's calling".

Had I not been through years of joy with Void/Unused, I would have  
been amazed at the data: URL being considered unacceptable. I'm all  
out of amazement now. However, suggesting that IRIS might be used for  
these near-real-time lookups is plain silly. Likewise LDAP or other  
means of lookup up vcards or other rich information. These are  
entirely different uses, with entirely different performance  
requirements. It's like saying that DNS is in competition with SOAP.

The folk proposing E2M are playing by the rules rather than just going  
off and doing it anyway. They have immediate requirements -- CNAM (as  
in "who's calling"), the NICC-driven "depends on which operator's  
asking" metadata case, and the stunningly obvious void/unused. These  
use cases are pretty narrow; few people are ever going to be  
interested, but those that are need them badly. Any use case either  
fits to the DNS model or it isn't going to be using E2M and so is out  
of scope for the proposed work.

Of course, if someone wants to go off and do an XML-based Web 2.0  
compliant solution, that's good; yellow pages is useful. It is  
however, not at all what Bernie and the chaps have been talking about.  
In what used to be IETF terms, it's not just a different "small bite",  
it's an entirely different meal. The proposed work is very focused,  
and as long as it stays that way, is eminently do-able in a reasonable  
time (before I retire, I hope). I will be happy to help knock this  
through -- it really should not be hard. I assume that E2M can use all  
of the work already done on E2U, so whilst it doesn't need to be an  
exact clone, it's pretty close.

Do I think that E2U DDDS is perfect? Nah; it's a pain in the parts.  
However, it's the least pain in the parts for a single exchange UDP  
lookup to return useful data, over a system that scales to global  
calling levels (both in volume and in frequency). E2M is very very  
similar.

So ... given that these initial use cases can be spelt out quickly,  
AND that those use cases fit to the (simple metadata, carried over DNS  
in a single query) model, AND that there are folk willing to do the  
work, why is it so hard to find a home for this?

all the best,
   Lawrence
[speaking entirely for myself]

From dean.willis@softarmor.com  Sat Jan 23 18:32:46 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59153A6997 for ; Sat, 23 Jan 2010 18:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGnZ9ZXtG3mD for ; Sat, 23 Jan 2010 18:32:46 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 159D03A67FD for ; Sat, 23 Jan 2010 18:32:45 -0800 (PST)
Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0O2Wg2Q019684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Jan 2010 20:32:45 -0600
Message-Id: 
From: Dean Willis 
To: Lawrence Conroy 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 23 Jan 2010 20:32:33 -0600
References: 
X-Mailer: Apple Mail (2.936)
Cc: DISPATCH 
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 02:32:46 -0000

On Jan 23, 2010, at 5:33 PM, Lawrence Conroy wrote:

> Hi Folks,
> I've just read through the E2M thread in the archive, and "am  
> puzzled".

Not as puzzled as I am.

I'm still tracking a SIP wg milestone for "E2M", which is "end to  
middle". By this we mean data inserted by a SIP UA for consumption at  
a specific intermediate proxy. The SIP working group has been working  
on it for about five years.

So what we have here is an unfortunate acronym collision. Any chance  
we can call this something else?

--
Dean

From bernie@ietf.hoeneisen.ch  Sun Jan 24 02:33:26 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8713A6827 for ; Sun, 24 Jan 2010 02:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIDy+xTwjZXU for ; Sun, 24 Jan 2010 02:33:25 -0800 (PST)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 7AA953A6359 for ; Sun, 24 Jan 2010 02:33:25 -0800 (PST)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NYzmS-0006c6-8z; Sun, 24 Jan 2010 11:33:20 +0100
Date: Sun, 24 Jan 2010 11:33:20 +0100 (CET)
From: Bernie Hoeneisen 
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: Dean Willis 
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Cc: DISPATCH 
Subject: [dispatch] How about: s/E2M/E2MD/g ? (was Re: E2M -- what's the delay?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2010 10:33:26 -0000

Hi Dean

On Sat, 23 Jan 2010, Dean Willis wrote:

> I'm still tracking a SIP wg milestone for "E2M", which is "end to middle". By 
> this we mean data inserted by a SIP UA for consumption at a specific 
> intermediate proxy. The SIP working group has been working on it for about 
> five years.
>
> So what we have here is an unfortunate acronym collision.

Ouuuups! Mea Culpa.
Thanks for spotting this!

> Any chance we can call this something else?

We are not yet fixed on the acronym, so it might be a good idea to change 
the acronym of the proposed new work:

How about to call the new work E2MD (E.164 to MetaData)?
Or do we just run into another conflict, e.g. with DDDS or whatever?
I hope not...otherwise, please holler now!

Have fun!

cheers,
  Bernie

From ranjit@motorola.com  Mon Jan 25 02:17:06 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2061A28C0CE for ; Mon, 25 Jan 2010 02:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level: 
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chseoLW1ROqy for ; Mon, 25 Jan 2010 02:17:04 -0800 (PST)
Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 63EA23A6893 for ; Mon, 25 Jan 2010 02:17:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-4.tower-128.messagelabs.com!1264414628!31864672!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 7215 invoked from network); 25 Jan 2010 10:17:09 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Jan 2010 10:17:09 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o0PAH8t8013098 for ; Mon, 25 Jan 2010 03:17:08 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o0PAH85D021373 for ; Mon, 25 Jan 2010 04:17:08 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o0PAH6QC021360 for ; Mon, 25 Jan 2010 04:17:07 -0600 (CST)
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, 25 Jan 2010 18:16:44 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com>
In-Reply-To: <4B59BA06.40608@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqbcZAfw3I6w3n+RUiYStQywvtnWACMw0lQ
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com>
From: "Avasarala Ranjit-A20990" 
To: "Paul Kyzivat" 
X-CFilter-Loop: Reflected
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 10:17:06 -0000

Hi Paul

My responses inline 

Sip:alice@office.domain.com OR sip:alice@home.domain.com would be the
registered contacts for sip:alice@domain.com. So these two registered
contacts could have individual URIs (using GRUU).=20

The

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Friday, January 22, 2010 8:15 PM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; DISPATCH
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

Ranjit,

The URLs you are using are suggestive as to their roles, but its still
not entirely clear to me. Is the following correct?

sip:alice@domain.com		AOR

alice@office.domain.com		Contact registered to
				sip:alice@domain.com

sip:boss@domain.com		AOR

sip:boss@office.domain.com	Contact registered to
				sip:alice@domain.com

More inline

Avasarala Ranjit-A20990 wrote:
> Hi all
>=20
> The elements have following meaning
>=20
>        This element would give the details of
> subscriber user - E.g. alice@domain.com
>=20
>  This element gives the details of the call=20
> originator. i.e the caller. Which in the example is=20
> sip:boss@domain.com or
>                         sip:boss@office.domain.com.

How is the originator of a request determined? Is it from From or
P-A-ID? How is it that either of the above might be the originator?

 The originating-user-info URL would be the incoming caller
identity that is present in "From" header. So it could be
sip:boss@domain.com OR=20
         sip:boss@ofice.domain.com depending on caller id configuration
and how the caller wants his or her identity to be displayed to the
called user.

         So yes the originator of the request is determined from the
P-Asserted-Identity of the caller.=20

>    This element gives the details of the device
on
> whose behalf diversion is taking place. For e.g. if Alice@domain.com=20
> has set a
>                         rule for alice@office.domain.com to divert all

> calls from Bob between 9 AM and 10 AM to voice-mail, then the
>                         Alice@office.domain.com would be the=20
> "diverting-user"

Some questions about above:

Assuming sip:alice@office.domain.com is not an AOR, but rather is a
registered contact to sip:alice@domain.com, where in the routing of the
call does the server that evaluates this rule get control?

 The server looks for the incoming caller identity and the
destination identity to see if there is a matching rule configured. If
the registered=20
         contact is not an AoR, then the call cannot be routed to it and
hence will be routed to the main AoR i.e sip:alice@domain.com and the
rule would
         not be executed. But if sip:alice@office.domain.com is an AoR
(e.g. GRUU), then the call could be routed and if there is adiversion
rule there,
         the diversion rule would get executed and a notification
generated towards that AoR.

How would it work in cases where the address for Alice's office phone is
a dynamically assigned ip address rather than a dns name?

 Since the notification gets generated dynamically when ever the
diversion occurs, the new ip address is taken prior to sending the
notification.

>       This element gives the final target of the
call.
> For e.g. the voice-mail.

The *final* target? I don't think that is possible.
It can at best be the address last known to the server doing the
reporting. If the call is diverted again downstream, that won't be
known. Or am I missing something?

 True, the final-target here means the next hop from the server.
E.g if the server diverts the call to another server, then that server
would be the final target. Agree with you that getting the final target
of diversion would not be possible if there are multiple entities
involved in the path.

Also, suppose we have an SSP that services multiple AORs. But still the
subscriptions are on a per-AOR basis. If Alice gives a rule that diverts
her calls to Charlie, who is also a customer of the same SSP, and
Charlie has also installed diversion rules for his AOR, do you expect
the notifications from subscription to Alice to report on the downstream
diversions performed by Charlie?

 No. All notifications to Alice indicate that calls to Alice got
diverted to Charlie. What happened beyond that, Alice would not know.=20

>    This element gives the actual time of
diversion.
> E.g. 9.30 AM
>=20
> ,diversion-reason-info> This element gives the reason for diversion.
> E.g. Rule-id of Reason like CFB
>=20
> So based on this a typical subscription document would like
>=20
> 
>      
>        
>           Alice 
>           alice@domain.com 
>        
>      
>      
>          
>             
>               
>                 Bob
>                 
>                   sip:Bob@domain.com
>                 
>               
>             
>             
>                
>                 Alice
>                 
>                   sip:alice@office.domain.com
>                 

I thought the user-name was the same as the user portion of the URI. If
not, how does a server determine what it is in a request in order to do
matching on it?

 Yes. Agree with you. Changed it

	Thanks,
	Paul

>               
>             
>             
>               
>                2010-01-22T09:00:00-05:00
>                2010-01-22T10:00:00-05:00
>               
>             
>             
>               
>             
>           
>       
>    
>=20
> The above XML document represents a subscription document for=20
> notifying diversiosn that occur between 9 and 10 AM at divering user=20
> alice@ Regards Ranjit
>=20
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> Sent: Thursday, January 21, 2010 2:42 AM
> To: Paul Kyzivat; Avasarala Ranjit-A20990
> Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
> Subject: RE: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> =20
>=20
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: 20 January 2010 18:11
>> To: Avasarala Ranjit-A20990
>> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
>> Subject: Re: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>>
>>
>> Avasarala Ranjit-A20990 wrote:
>>> Hi Dean
>>>
>>> A sample diversion notification document would like
>>>
>>> 
>>>   
>>>     
>>>       Boss
>>>       sip:boss@office.com
>>>     
>>>     
>>>       sip:alice@office.com
>>>     
>>>     
>>>       sip:bob@office.com
>>>     
>>>    =20
>> 1999-06-01T13:20:00-05:00
>>>     404
>>>   
>>> 
>>>
>>> So here, the subscribing AoR would be alice@domain.com. The=20
>>>  which is alice@office.com gives the
>> URI that is
>>> actually diverting. While the 
>> element gives the
>>> final target of the call.
>> Hmm. Can you explain further?
>>
>> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a=20
>> registered Contact for that?
>>
>> If so, I would expect that sip:alice@domain.com would be the=20
>> diverting
>=20
>> user. For sip:alice@office.com to be the diverting user, wouldn't=20
>> that
>=20
>> phone have to initiate the diversion? If that were the case, how=20
>> would
>=20
>> the notifier for the event discover that the diversion has occurred?
> [JRE] I have exactly the same questions as Paul, but also an addition=20
> question. If sip:boss@office.com is the contact URI for AOR=20
> sip:boss@domain.com, why would  not contain=20
> sip:boss@domain.com? Although the contact URI would be available,=20
> often the contact URI is not meaningful, i.e., often it would not=20
> explicitly identify boss. Also, from a return call perspective,=20
> sip:boss@domain.com would be more useful, since it would hopefully=20
> reach boss on whatever device he happens to be using at the time.
>=20
> John
>=20
>> 	Thanks,
>> 	Paul
>>
>>> So at any point of time, alice@domain.com can check all the=20
>>> notifications received to determine the set of diversions that have=20
>>> taken place at various registered contacts of Alice.
>>>
>>> Now if we take the call centre scenario, then a particular
>> incoming call
>>> could get forked probably sequentially until one of the
>> agents picks the
>>> call. So I feel this is not a valid use case of call diversion, but=20
>>> would qualify for a use case of sequential or simultaneous forking.
>>>
>>> Regards
>>> Ranjit
>>>
>>> -----Original Message-----
>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>> Sent: Wednesday, January 20, 2010 11:34 AM
>>> To: Paul Kyzivat
>>> Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;
>> Gonzalo Camarillo
>>> Subject: Re: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>>
>>> On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
>>>
>>>> Elwell, John wrote:
>>>>>> -----Original Message-----
>>>>>> From: Avasarala Ranjit-A20990
>> [mailto:ranjit@motorola.com] Sent: =20
>>>>>> 19 January 2010 17:49
>>>>>> To: Elwell, John; Dean Willis
>>>>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>>>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala-=20
>>>>>> dispatch-comm-div-notification
>>>>>>
>>>>>> Hi John
>>>>>>
>>>>>> Sorry for the late response. Yes the notifications will
>> be from the
>>>>>> server towards the original AoR with the registered contact=20
>>>>>> specified as part of the event package (e.g in the element=20
>>>>>> "diverting-user").
>>>>>> So it
>>>>>> would be the job of the notifier to generate appropriate
>> diversion
>>>>>> notification information towards the target AoR.
>>>>> [JRE] This just confuses me again. It first says the notification=20
>>>>> will be sent from the server to the original AOR, and
>> then it says
>>>>> notification information is send towards the target AOR -
>> apparently
>>>>> a contradiction, unless these two terms mean the same
>> thing. Also,
>>>>> why is the registered contact (I assume this means
>> contact URI) sent
>>>>> in element "diverting-user" rather than the original AOR?
>>>> This has confused me from the beginning.
>>>> It seems the assumption is that only the "diverting user" will=20
>>>> subscribe. But in reality that doesn't make much sense if the=20
>>>> subscription is addressed to the diverting user.
>>> The diverting user has multiple user agents. Said user
>> cannot remember
>>> which user agent is set to divert, or what it is diverting
>> to. So said
>>> user subscribes to the divnot package in order to find out
>> what the heck
>>> is happening.
>>>
>>>> It makes some sense if the subscribers are UAs that have
>> registered
>>>> with the AOR of the diverting user, and the notifier is a
>> server that
>>>> mediates arriving requests to that AOR.
>>>>
>>> Yes, I think that's the intent
>>>
>>>> But even then, while its reasonable to expect that the registered=20
>>>> devices might be interested in subscribing to this, surely
>> they aren't
>>>> the *only* plausible subscribers. Assuming they are is, IMO, a=20
>>>> mistake.
>>> I think your view of the architecture is somewhat larger than the=20
>>> author's. This is not unreasonable. Like you, I can
>> envision other use
>>> cases, such as call center scenarios.
>>>
>>> Is there any reason NOT to generalize the specification for broader=20
>>> applicability?
>>>
>>> --
>>> Dean
>>>
>>>
>>>
>>>
>>>
>=20

From lconroy@insensate.co.uk  Mon Jan 25 03:06:31 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B333A68C5 for ; Mon, 25 Jan 2010 03:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exNGVtojGXbw for ; Mon, 25 Jan 2010 03:06:30 -0800 (PST)
Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 75E403A6978 for ; Mon, 25 Jan 2010 03:06:30 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 53E761031FC; Mon, 25 Jan 2010 11:06:34 +0000 (GMT)
Message-Id: <60B9F319-FED4-4871-B14B-52EB97BBD38C@insensate.co.uk>
From: Lawrence Conroy 
To: Bernie Hoeneisen 
In-Reply-To: 
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 25 Jan 2010 11:06:33 +0000
References:   
X-Mailer: Apple Mail (2.936)
Cc: DISPATCH 
Subject: Re: [dispatch] How about: s/E2M/E2MD/g ? (was Re: E2M -- what's the delay?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 11:06:31 -0000

Hi Bernie, Dean, folks,
   I think E2D would be better (E.164 to Data, with aspirate meta :).
That matches the 3 character DAIs (Ddds Application Identifiers) we have
for 2916/3761/3761bis, and 3263.
 From painful exposure to the "million monkey march" approach to coding,
I no longer assume that a 4 character token won't tickle a bug  
somewhere.

Seriously, Dispatch (or its archive) does look a lot like Sipping^2, so
it IS odd having a proposal for a DDDS application here. [Hence my plea
to find it a home soon :].

all the best,
   Lawrence

On 24 Jan 2010, at 10:33, Bernie Hoeneisen wrote:
> Hi Dean
> On Sat, 23 Jan 2010, Dean Willis wrote:
>> I'm still tracking a SIP wg milestone for "E2M", which is "end to  
>> middle". By this we mean data inserted by a SIP UA for consumption  
>> at a specific intermediate proxy. The SIP working group has been  
>> working on it for about five years.
>>
>> So what we have here is an unfortunate acronym collision.
>
> Ouuuups! Mea Culpa.
> Thanks for spotting this!
>
>> Any chance we can call this something else?
>
> We are not yet fixed on the acronym, so it might be a good idea to  
> change the acronym of the proposed new work:
>
> How about to call the new work E2MD (E.164 to MetaData)?
> Or do we just run into another conflict, e.g. with DDDS or whatever?
> I hope not...otherwise, please holler now!
>
> Have fun!
>
> cheers,
> Bernie

From pkyzivat@cisco.com  Mon Jan 25 06:21:23 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4D528C0DC for ; Mon, 25 Jan 2010 06:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89caNXIG1mzf for ; Mon, 25 Jan 2010 06:21:21 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6159C3A68BB for ; Mon, 25 Jan 2010 06:21:21 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAF83XUtAZnwM/2dsb2JhbADDYJVLgi8BBoIFBI4L
X-IronPort-AV: E=Sophos;i="4.49,339,1262563200"; d="scan'208";a="81996859"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2010 14:21:26 +0000
Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0PELO0k012449; Mon, 25 Jan 2010 14:21:26 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Jan 2010 08:21:25 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Jan 2010 08:21:24 -0600
Message-ID: <4B5DA8E3.7050306@cisco.com>
Date: Mon, 25 Jan 2010 09:21:23 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Avasarala Ranjit-A20990 
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jan 2010 14:21:24.0697 (UTC) FILETIME=[ACD2E490:01CA9DC9]
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 14:21:23 -0000

Comments inline.

	Thanks,
	Paul

Avasarala Ranjit-A20990 wrote:
> Hi Paul
> 
> My responses inline 
> 
> 
> Sip:alice@office.domain.com OR sip:alice@home.domain.com would be the
> registered contacts for sip:alice@domain.com. So these two registered
> contacts could have individual URIs (using GRUU). 

OK, I guessed right on that part.

> The
> 
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Friday, January 22, 2010 8:15 PM
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; DISPATCH
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
> 
> Ranjit,
> 
> The URLs you are using are suggestive as to their roles, but its still
> not entirely clear to me. Is the following correct?
> 
> sip:alice@domain.com		AOR
> 
> alice@office.domain.com		Contact registered to
> 				sip:alice@domain.com
> 
> sip:boss@domain.com		AOR
> 
> sip:boss@office.domain.com	Contact registered to
> 				sip:alice@domain.com
> 
> More inline
> 
> Avasarala Ranjit-A20990 wrote:
>> Hi all
>>
>> The elements have following meaning
>>
>>        This element would give the details of
>> subscriber user - E.g. alice@domain.com
>>
>>  This element gives the details of the call 
>> originator. i.e the caller. Which in the example is 
>> sip:boss@domain.com or
>>                         sip:boss@office.domain.com.
> 
> How is the originator of a request determined? Is it from From or
> P-A-ID? How is it that either of the above might be the originator?
> 
>  The originating-user-info URL would be the incoming caller
> identity that is present in "From" header. So it could be
> sip:boss@domain.com OR 
>          sip:boss@ofice.domain.com depending on caller id configuration
> and how the caller wants his or her identity to be displayed to the
> called user.
> 
>          So yes the originator of the request is determined from the
> P-Asserted-Identity of the caller. 

OK, no surprises.

>>    This element gives the details of the device
> on
>> whose behalf diversion is taking place. For e.g. if Alice@domain.com 
>> has set a
>>                         rule for alice@office.domain.com to divert all
> 
>> calls from Bob between 9 AM and 10 AM to voice-mail, then the
>>                         Alice@office.domain.com would be the 
>> "diverting-user"
> 
> Some questions about above:
> 
> Assuming sip:alice@office.domain.com is not an AOR, but rather is a
> registered contact to sip:alice@domain.com, where in the routing of the
> call does the server that evaluates this rule get control?
> 
>  The server looks for the incoming caller identity and the
> destination identity to see if there is a matching rule configured.

I guess my question wasn't clear.
Where in the routing sequence does this server reside?
If it is positioned before the contact routing has occurred, then it 
can't know which contact was chosen.

Since this proposal is coming, more or less, from IMS I assume you are 
imagining this is an IMS Application Server. IIRC, those get control 
*before* contact routing is done by the S-CSCF. So how would the AS know 
if a particular contact was chosen. (I take some issue with calling 
contact routing "diversion", but lets not discuss that right now.)

> If the registered 
>          contact is not an AoR, then the call cannot be routed to it and

Huh? Whether the registered contact is an AOR has no bearing on whether 
its possible to route to it. And, its in general impossible to determine 
by looking whether a URI is an AOR or not.

> hence will be routed to the main AoR i.e sip:alice@domain.com and the
> rule would not be executed.

That statement makes me even more confused. I have no idea what it means.

> But if sip:alice@office.domain.com is an AoR
> (e.g. GRUU), then the call could be routed and if there is adiversion
> rule there,
>          the diversion rule would get executed and a notification
> generated towards that AoR.

This is getting more and more confusing. So I have even more desire for 
at least a detailed use case that shows all the players, their addresses 
and relationships to one another, and the call flow.

> How would it work in cases where the address for Alice's office phone is
> a dynamically assigned ip address rather than a dns name?
> 
>  Since the notification gets generated dynamically when ever the
> diversion occurs, the new ip address is taken prior to sending the
> notification.

Again it seems my question wasn't clear.
You are showing rules that contain the contact addresses of particular 
devices. If the contact URIs registered by those devices contain 
dynamically assigned addresses, how would a subscriber know how to 
construct the rule that selects a particular device? Or if it is 
receiving all the diversions, how would it relate the reported results 
to particular devices?

This relates, in a way, to whether contact routing is diversion or not. 
Typically what I think of as real diversion would be to a URI that *is* 
an AOR, and hence stable and knowable by those formulating rules. But 
typical contact routing would involve URIs that aren't very meaningful.

If you want to be able to write rules like: "let me know when the call 
is routed to the phone in my office rather than the one in my home" 
(where both have the same "phone number"), then you are going to have to 
find a way to give those stable URIs, like sip:alice@office.domain.com 
and sip:alice@home.domain.com. AFAIK that isn't the norm, so if you are 
assuming it then please make that clear.

>>       This element gives the final target of the
> call.
>> For e.g. the voice-mail.
> 
> The *final* target? I don't think that is possible.
> It can at best be the address last known to the server doing the
> reporting. If the call is diverted again downstream, that won't be
> known. Or am I missing something?
> 
>  True, the final-target here means the next hop from the server.
> E.g if the server diverts the call to another server, then that server
> would be the final target. Agree with you that getting the final target
> of diversion would not be possible if there are multiple entities
> involved in the path.
> 
> Also, suppose we have an SSP that services multiple AORs. But still the
> subscriptions are on a per-AOR basis. If Alice gives a rule that diverts
> her calls to Charlie, who is also a customer of the same SSP, and
> Charlie has also installed diversion rules for his AOR, do you expect
> the notifications from subscription to Alice to report on the downstream
> diversions performed by Charlie?
> 
>  No. All notifications to Alice indicate that calls to Alice got
> diverted to Charlie. What happened beyond that, Alice would not know. 

OK. Good.

>>    This element gives the actual time of
> diversion.
>> E.g. 9.30 AM
>>
>> ,diversion-reason-info> This element gives the reason for diversion.
>> E.g. Rule-id of Reason like CFB
>>
>> So based on this a typical subscription document would like
>>
>> 
>>      
>>        
>>           Alice 
>>           alice@domain.com 
>>        
>>      
>>      
>>          
>>             
>>               
>>                 Bob
>>                 
>>                   sip:Bob@domain.com
>>                 
>>               
>>             
>>             
>>                
>>                 Alice
>>                 
>>                   sip:alice@office.domain.com
>>                 
> 
> I thought the user-name was the same as the user portion of the URI. If
> not, how does a server determine what it is in a request in order to do
> matching on it?
> 
>  Yes. Agree with you. Changed it
> 
> 	Thanks,
> 	Paul
> 
>>               
>>             
>>             
>>               
>>                2010-01-22T09:00:00-05:00
>>                2010-01-22T10:00:00-05:00
>>               
>>             
>>             
>>               
>>             
>>           
>>       
>>    
>>
>> The above XML document represents a subscription document for 
>> notifying diversiosn that occur between 9 and 10 AM at divering user 
>> alice@ Regards Ranjit
>>
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
>> Sent: Thursday, January 21, 2010 2:42 AM
>> To: Paul Kyzivat; Avasarala Ranjit-A20990
>> Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
>> Subject: RE: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>>  
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>> Sent: 20 January 2010 18:11
>>> To: Avasarala Ranjit-A20990
>>> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
>>> Subject: Re: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>>
>>>
>>> Avasarala Ranjit-A20990 wrote:
>>>> Hi Dean
>>>>
>>>> A sample diversion notification document would like
>>>>
>>>> 
>>>>   
>>>>     
>>>>       Boss
>>>>       sip:boss@office.com
>>>>     
>>>>     
>>>>       sip:alice@office.com
>>>>     
>>>>     
>>>>       sip:bob@office.com
>>>>     
>>>>     
>>> 1999-06-01T13:20:00-05:00
>>>>     404
>>>>   
>>>> 
>>>>
>>>> So here, the subscribing AoR would be alice@domain.com. The 
>>>>  which is alice@office.com gives the
>>> URI that is
>>>> actually diverting. While the 
>>> element gives the
>>>> final target of the call.
>>> Hmm. Can you explain further?
>>>
>>> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a 
>>> registered Contact for that?
>>>
>>> If so, I would expect that sip:alice@domain.com would be the 
>>> diverting
>>> user. For sip:alice@office.com to be the diverting user, wouldn't 
>>> that
>>> phone have to initiate the diversion? If that were the case, how 
>>> would
>>> the notifier for the event discover that the diversion has occurred?
>> [JRE] I have exactly the same questions as Paul, but also an addition 
>> question. If sip:boss@office.com is the contact URI for AOR 
>> sip:boss@domain.com, why would  not contain 
>> sip:boss@domain.com? Although the contact URI would be available, 
>> often the contact URI is not meaningful, i.e., often it would not 
>> explicitly identify boss. Also, from a return call perspective, 
>> sip:boss@domain.com would be more useful, since it would hopefully 
>> reach boss on whatever device he happens to be using at the time.
>>
>> John
>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> So at any point of time, alice@domain.com can check all the 
>>>> notifications received to determine the set of diversions that have 
>>>> taken place at various registered contacts of Alice.
>>>>
>>>> Now if we take the call centre scenario, then a particular
>>> incoming call
>>>> could get forked probably sequentially until one of the
>>> agents picks the
>>>> call. So I feel this is not a valid use case of call diversion, but 
>>>> would qualify for a use case of sequential or simultaneous forking.
>>>>
>>>> Regards
>>>> Ranjit
>>>>
>>>> -----Original Message-----
>>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>>> Sent: Wednesday, January 20, 2010 11:34 AM
>>>> To: Paul Kyzivat
>>>> Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;
>>> Gonzalo Camarillo
>>>> Subject: Re: [dispatch] Comments
>>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>>
>>>>
>>>> On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
>>>>
>>>>> Elwell, John wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Avasarala Ranjit-A20990
>>> [mailto:ranjit@motorola.com] Sent:  
>>>>>>> 19 January 2010 17:49
>>>>>>> To: Elwell, John; Dean Willis
>>>>>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>>>>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala- 
>>>>>>> dispatch-comm-div-notification
>>>>>>>
>>>>>>> Hi John
>>>>>>>
>>>>>>> Sorry for the late response. Yes the notifications will
>>> be from the
>>>>>>> server towards the original AoR with the registered contact 
>>>>>>> specified as part of the event package (e.g in the element 
>>>>>>> "diverting-user").
>>>>>>> So it
>>>>>>> would be the job of the notifier to generate appropriate
>>> diversion
>>>>>>> notification information towards the target AoR.
>>>>>> [JRE] This just confuses me again. It first says the notification 
>>>>>> will be sent from the server to the original AOR, and
>>> then it says
>>>>>> notification information is send towards the target AOR -
>>> apparently
>>>>>> a contradiction, unless these two terms mean the same
>>> thing. Also,
>>>>>> why is the registered contact (I assume this means
>>> contact URI) sent
>>>>>> in element "diverting-user" rather than the original AOR?
>>>>> This has confused me from the beginning.
>>>>> It seems the assumption is that only the "diverting user" will 
>>>>> subscribe. But in reality that doesn't make much sense if the 
>>>>> subscription is addressed to the diverting user.
>>>> The diverting user has multiple user agents. Said user
>>> cannot remember
>>>> which user agent is set to divert, or what it is diverting
>>> to. So said
>>>> user subscribes to the divnot package in order to find out
>>> what the heck
>>>> is happening.
>>>>
>>>>> It makes some sense if the subscribers are UAs that have
>>> registered
>>>>> with the AOR of the diverting user, and the notifier is a
>>> server that
>>>>> mediates arriving requests to that AOR.
>>>>>
>>>> Yes, I think that's the intent
>>>>
>>>>> But even then, while its reasonable to expect that the registered 
>>>>> devices might be interested in subscribing to this, surely
>>> they aren't
>>>>> the *only* plausible subscribers. Assuming they are is, IMO, a 
>>>>> mistake.
>>>> I think your view of the architecture is somewhat larger than the 
>>>> author's. This is not unreasonable. Like you, I can
>>> envision other use
>>>> cases, such as call center scenarios.
>>>>
>>>> Is there any reason NOT to generalize the specification for broader 
>>>> applicability?
>>>>
>>>> --
>>>> Dean
>>>>
>>>>
>>>>
>>>>
>>>>
> 

From kcartwright@tnsi.com  Mon Jan 25 08:20:22 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9B028C0E4 for ; Mon, 25 Jan 2010 08:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD6F1Z-RvRb6 for ; Mon, 25 Jan 2010 08:20:21 -0800 (PST)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 1A0FB28C0D9 for ; Mon, 25 Jan 2010 08:20:20 -0800 (PST)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.39873414; Mon, 25 Jan 2010 11:20:16 -0500
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 25 Jan 2010 11:20:15 -0500
From: "Cartwright, Kenneth" 
To: Lawrence Conroy , "dispatch@ietf.org" 
Date: Mon, 25 Jan 2010 11:20:14 -0500
Thread-Topic: [dispatch] E2M -- what's the delay?
Thread-Index: AcqchIkll0zCaS2gR1uqB6ttd4ltIwBUOAZA
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 16:20:22 -0000

Hello,
Just to restate and clarify...

0) I have no idea why this work has not found a home.  Perhaps the ENUM WG =
should be re-chartered and re-awakened.  I'm not well schooled in the admin=
istrative practices of IETF and really have no place commenting on that sub=
ject, and did not attempt to do so.
1) I understand the immediate need for this solution.  And if it happens, t=
here is a good likelihood that I/we can or will use it, as it meets part of=
 an immediate need.  And if it does move forward the I/we will certainly re=
ad and review the drafts and provide feedback with that intent in mind.  An=
d may even subsequently propose additional services that fit under an E2M n=
amespace.  So please do not misconstrue my comments as suggesting a vote th=
at this work should not move forward.  That being said, however, I think yo=
u cannot deny that there is a bigger picture here.  So....
2) Not sure why it would be puzzling that DDDS and DNS is not the only viab=
le and good solution to the need to quickly look up information in real tim=
e.  That seems self evident to me.
3) Pointing out a meaningful short-coming or two of ENUM and DDDS and how i=
t is used and proposed to be used should also not be puzzling.
4) Again, using an ENUMish standard to get data that is specific to TNs (e.=
g. to turn a TN into an AOR, to help interpret and traverse a TN number pla=
n, etc) obviously makes perfect sense.  That is of course what ENUM was bui=
lt for.  But to use an ENUMish solution to feed up other important data ele=
ments that have nothing to do with the fact that the lookup key is a TN (or=
 a domain name), such as calling name information, is unfortunate.  Calling=
 Name information, for example, of course exists for addresses that are not=
 TNs.  So why would one propose a calling name lookup protocol that only al=
lows lookup keys to be TNs (that are turned into domain names)?

But again, as you state, these are longer term and broader concerns.  And w=
hat is being proposed is immediate term and focused.  I get that.  However,=
 that fact does not make some broader points "puzzling".

Thanks.
Ken

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Lawrence Conroy
Sent: Saturday, January 23, 2010 6:34 PM
To: dispatch@ietf.org
Subject: [dispatch] E2M -- what's the delay?

Hi Folks,
  I've just read through the E2M thread in the archive, and "am
puzzled".

This is a lookup, mapping from an E.164 number, to stuff. Not from
email, not from alphabetic SIP URIs, but from phone numbers.
This lookup is extremely likely to be done before, during, or after a
call. In at least the former two cases, that means now -- both NOW, as
in the IETF "get off their encounter suited butts and do something",
and NOW, as in "I do not want to grind through some RDF meta-
meditation before I can find out who's calling".

Had I not been through years of joy with Void/Unused, I would have
been amazed at the data: URL being considered unacceptable. I'm all
out of amazement now. However, suggesting that IRIS might be used for
these near-real-time lookups is plain silly. Likewise LDAP or other
means of lookup up vcards or other rich information. These are
entirely different uses, with entirely different performance
requirements. It's like saying that DNS is in competition with SOAP.

The folk proposing E2M are playing by the rules rather than just going
off and doing it anyway. They have immediate requirements -- CNAM (as
in "who's calling"), the NICC-driven "depends on which operator's
asking" metadata case, and the stunningly obvious void/unused. These
use cases are pretty narrow; few people are ever going to be
interested, but those that are need them badly. Any use case either
fits to the DNS model or it isn't going to be using E2M and so is out
of scope for the proposed work.

Of course, if someone wants to go off and do an XML-based Web 2.0
compliant solution, that's good; yellow pages is useful. It is
however, not at all what Bernie and the chaps have been talking about.
In what used to be IETF terms, it's not just a different "small bite",
it's an entirely different meal. The proposed work is very focused,
and as long as it stays that way, is eminently do-able in a reasonable
time (before I retire, I hope). I will be happy to help knock this
through -- it really should not be hard. I assume that E2M can use all
of the work already done on E2U, so whilst it doesn't need to be an
exact clone, it's pretty close.

Do I think that E2U DDDS is perfect? Nah; it's a pain in the parts.
However, it's the least pain in the parts for a single exchange UDP
lookup to return useful data, over a system that scales to global
calling levels (both in volume and in frequency). E2M is very very
similar.

So ... given that these initial use cases can be spelt out quickly,
AND that those use cases fit to the (simple metadata, carried over DNS
in a single query) model, AND that there are folk willing to do the
work, why is it so hard to find a home for this?

all the best,
   Lawrence
[speaking entirely for myself]

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.

From Ray.Bellis@nominet.org.uk  Mon Jan 25 08:31:16 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAA63A689C for ; Mon, 25 Jan 2010 08:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECFampyV68R5 for ; Mon, 25 Jan 2010 08:31:14 -0800 (PST)
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 043D03A68A0 for ; Mon, 25 Jan 2010 08:31:13 -0800 (PST)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=kw9tjGTTmA2Vw7ptt2HOH06AESB249XjG66TmiZ6Eijh8DzhXbFLjwE6 rgVMPQGp2oN7fuRW9fRoAbzrxb+N9zxI8SzV7i7uhQC3AKLiaDtH1Sfrs BKH6pC97r/0me5x;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1264437081; x=1295973081; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[disp atch]=20E2M=20--=20what's=20the=20delay?|Date:=20Mon,=202 5=20Jan=202010=2016:31:17=20+0000|Message-ID:=20|To:=20"Cartwright,=20Kenneth"=20|Cc:=20"dispatch@ietf.org"=20 |MIME-Version:=201.0|In-Reply-To:=20<754963199212404AB8E9 CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com> |References:=20=20<754963199212404AB8E9CFCA6C3D0CDA0D865435A 4@TNS-MAIL-NA.win2k.corp.tnsi.com>; bh=h+Cre1l/5Z+RuRJ7WSKZLLeXj9dlxDMjQq1p/0ghlgU=; b=XKzeN62K9xeXdJb3CLBtp6KN//Wi4OgOl0d6asPlHjA2NQF8y4IETy1I b5axo15REaHZCNf0lY+IWCcblQzOV3lsq2YUfGhtXx46wma+0Ur9PPwqm HMVCXycNaO5ylma;
X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="21161742"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 25 Jan 2010 16:31:19 +0000
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com>
References:  <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com>
To: "Cartwright, Kenneth" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID: 
From: Ray.Bellis@nominet.org.uk
Date: Mon, 25 Jan 2010 16:31:17 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/01/2010 04:31:18 PM, Serialize complete at 25/01/2010 04:31:18 PM
Content-Type: multipart/alternative; boundary="=_alternative 005AC110802576B6_="
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 16:31:16 -0000

This is a multipart message in MIME format.
--=_alternative 005AC110802576B6_=
Content-Type: text/plain; charset="US-ASCII"

> 4) Again, using an ENUMish standard to get data that is specific to 
> TNs (e.g. to turn a TN into an AOR, to help interpret and traverse a
> TN number plan, etc) obviously makes perfect sense.  That is of 
> course what ENUM was built for.  But to use an ENUMish solution to 
> feed up other important data elements that have nothing to do with 
> the fact that the lookup key is a TN (or a domain name), such as 
> calling name information, is unfortunate.  Calling Name information,
> for example, of course exists for addresses that are not TNs.  So 
> why would one propose a calling name lookup protocol that only 
> allows lookup keys to be TNs (that are turned into domain names)?

Ken,

Did my previous e-mail (and Richard's followup) not explain clearly enough 
how all three existing use cases for E2M are _specifically_ related to 
TNs?

kind regards,

Ray

--=_alternative 005AC110802576B6_=
Content-Type: text/html; charset="US-ASCII"

> 4) Again, using an ENUMish standard to get data that is specific to

> TNs (e.g. to turn a TN into an AOR, to help interpret and traverse
a

> TN number plan, etc) obviously makes perfect sense.  That is
of 

> course what ENUM was built for.  But to use an ENUMish solution
to 

> feed up other important data elements that have nothing to do with

> the fact that the lookup key is a TN (or a domain name), such as 

> calling name information, is unfortunate.  Calling Name information,

> for example, of course exists for addresses that are not TNs.  So

> why would one propose a calling name lookup protocol that only 

> allows lookup keys to be TNs (that are turned into domain names)?

Ken,

Did my previous e-mail (and Richard's followup) not
explain clearly enough how all three existing use cases for E2M are _specifically_
related to TNs?

kind regards,

Ray

--=_alternative 005AC110802576B6_=--

From kcartwright@tnsi.com  Mon Jan 25 09:19:35 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3935E3A6877 for ; Mon, 25 Jan 2010 09:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTjM5YCn9aX7 for ; Mon, 25 Jan 2010 09:19:31 -0800 (PST)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id AE9183A6407 for ; Mon, 25 Jan 2010 09:19:30 -0800 (PST)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.39875814; Mon, 25 Jan 2010 12:19:27 -0500
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 25 Jan 2010 12:19:27 -0500
From: "Cartwright, Kenneth" 
To: "Ray.Bellis@nominet.org.uk" 
Date: Mon, 25 Jan 2010 12:19:25 -0500
Thread-Topic: [dispatch] E2M -- what's the delay?
Thread-Index: Acqd29RuGhOynzLyRiy1jxHBH3GZxgABgGsw
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com>
References:  <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0D86543663TNSMAILNAwin2_"
MIME-Version: 1.0
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 17:19:35 -0000

--_000_754963199212404AB8E9CFCA6C3D0CDA0D86543663TNSMAILNAwin2_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ray,

Calling Name was mentioned (which of course is not special to TNs).  But if=
 that was mentioned just *tangentially*, then yes, you've explained how all=
 of your envisioned use cases are specific to TNs as lookup keys.  And give=
n that all of your envisioned use cases are apparently specific to TNs, the=
 argument for an ENUMish solution is of course a strong one.

Thanks.
Ken

________________________________
From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
Sent: Monday, January 25, 2010 11:31 AM
To: Cartwright, Kenneth
Cc: dispatch@ietf.org
Subject: Re: [dispatch] E2M -- what's the delay?

> 4) Again, using an ENUMish standard to get data that is specific to
> TNs (e.g. to turn a TN into an AOR, to help interpret and traverse a
> TN number plan, etc) obviously makes perfect sense.  That is of
> course what ENUM was built for.  But to use an ENUMish solution to
> feed up other important data elements that have nothing to do with
> the fact that the lookup key is a TN (or a domain name), such as
> calling name information, is unfortunate.  Calling Name information,
> for example, of course exists for addresses that are not TNs.  So
> why would one propose a calling name lookup protocol that only
> allows lookup keys to be TNs (that are turned into domain names)?

Ken,

Did my previous e-mail (and Richard's followup) not explain clearly enough =
how all three existing use cases for E2M are _specifically_ related to TNs?

kind regards,

Ray

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.

--_000_754963199212404AB8E9CFCA6C3D0CDA0D86543663TNSMAILNAwin2_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ray,

Calling Name was mentioned (which of c=
ourse is not special to TNs).  But if that was mentioned just *tangentially*,
 then yes, you’ve explained how all of your envisioned use cases are =
specific to TNs as lookup keys.  And given that all of your envisioned=
 use cases are apparently specific to TNs, the argument for an ENUMish solu=
tion is of course a strong one.

Thanks.
Ken

From: Ray.=
Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]

Sent: Monday, January 25, 20=
10 11:31 AM

To: Cartwright, Kenneth

Cc: dispatch@ietf.org

Subject: Re: [dispatch] E2M =
-- what's the delay?

> 4) Again, using an ENUMish standard to =
get data that is specific to

> TNs (e.g. to turn a TN into an AOR, to =
help interpret and traverse a

> TN number plan, etc) obviously makes pe=
rfect sense.  That is of

> course what ENUM was built for.  B=
ut to use an ENUMish solution to

> feed up other important data elements t=
hat have nothing to do with

> the fact that the lookup key is a TN (o=
r a domain name), such as

> calling name information, is unfortunat=
e.  Calling Name information,

> for example, of course exists for addre=
sses that are not TNs.  So

> why would one propose a calling name lo=
okup protocol that only

> allows lookup keys to be TNs (that are =
turned into domain names)?

=
Ken,

=
Did my previous e-mail (and Richard's followup) not explain clearly enough =
how all three existing use cases for E2M are _specifically_ related to TNs?=

=
kind regards,

=
Ray

This e-mail message is for t=
he sole use of the intended recipient(s)and may

contain confidential and privileged information of Transaction Network Serv=
ices.

Any unauthorised review, use, disclosure or distribution is prohibited. If =
you

are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.

--_000_754963199212404AB8E9CFCA6C3D0CDA0D86543663TNSMAILNAwin2_--

From Ray.Bellis@nominet.org.uk  Mon Jan 25 09:36:52 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AD13A6851 for ; Mon, 25 Jan 2010 09:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQr76znkZbQv for ; Mon, 25 Jan 2010 09:36:51 -0800 (PST)
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 52CD33A67E7 for ; Mon, 25 Jan 2010 09:36:50 -0800 (PST)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns;  h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=0oylRaAMmDaiNeJWHAaIDi8gvDvVg+Tyl48mcT52XDrx4pr1Ykt6Pt6c dt6xBQzGZm6hJV4EwDwzlhcZMDqDeM7HbgNBn10We0UFlVOrTmEXtKKem t7M4ZMEL8trNP8M;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1264441018; x=1295977018; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[disp atch]=20E2M=20--=20what's=20the=20delay?|Date:=20Mon,=202 5=20Jan=202010=2017:36:56=20+0000|Message-ID:=20|To:=20"Cartwright,=20Kenneth"=20|Cc:=20"dispatch@ietf.org"=20 |MIME-Version:=201.0|In-Reply-To:=20<754963199212404AB8E9 CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com> |References:=20=20<754963199212404AB8E9CFCA6C3D0CDA0D865435A 4@TNS-MAIL-NA.win2k.corp.tnsi.com>=20=20 <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.w in2k.corp.tnsi.com>; bh=kX6IXJCDmWJAS8oTk9ff0SDcN03pGN5+mBpJL7h6Rts=; b=K9f58dlBWZUQTBHLnGvJnK93SgoSj1N0xOd9wS3EFbl0JKTVbvnqXF6L eEJMF3HNqqsGpIaZKtX2yGBCce5RED5AONKxXcOk3mvM6g2k5BKDEGNZk ulUP8xb25hQbfao;
X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="15789400"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 25 Jan 2010 17:36:56 +0000
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com>
References:  <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com>  <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com>
To: "Cartwright, Kenneth" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID: 
From: Ray.Bellis@nominet.org.uk
Date: Mon, 25 Jan 2010 17:36:56 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/01/2010 05:36:56 PM, Serialize complete at 25/01/2010 05:36:56 PM
Content-Type: multipart/alternative; boundary="=_alternative 0060C3EC802576B6_="
Cc: "dispatch@ietf.org" 
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 17:36:53 -0000

This is a multipart message in MIME format.
--=_alternative 0060C3EC802576B6_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

PiBIaSBSYXksDQo+IA0KPiBDYWxsaW5nIE5hbWUgd2FzIG1lbnRpb25lZCAod2hpY2ggb2YgY291
cnNlIGlzIG5vdCBzcGVjaWFsIHRvIFROcykuIA0KPiBCdXQgaWYgdGhhdCB3YXMgbWVudGlvbmVk
IGp1c3QgKnRhbmdlbnRpYWxseSosIHRoZW4geWVzLCB5b3XigJl2ZSANCj4gZXhwbGFpbmVkIGhv
dyBhbGwgb2YgeW91ciBlbnZpc2lvbmVkIHVzZSBjYXNlcyBhcmUgc3BlY2lmaWMgdG8gVE5zIA0K
PiBhcyBsb29rdXAga2V5cy4gIEFuZCBnaXZlbiB0aGF0IGFsbCBvZiB5b3VyIGVudmlzaW9uZWQg
dXNlIGNhc2VzIGFyZQ0KPiBhcHBhcmVudGx5IHNwZWNpZmljIHRvIFROcywgdGhlIGFyZ3VtZW50
IGZvciBhbiBFTlVNaXNoIHNvbHV0aW9uIGlzIA0KPiBvZiBjb3Vyc2UgYSBzdHJvbmcgb25lLg0K
DQpSaWNoYXJkIGNsYXJpZmllZCB0aGUgIkNOQU0iIHVzZSBjYXNlLCB3aGVyZSBpbiByZXNwb25z
ZSB0byBteSB1bmNlcnRhaW50eSANCmFib3V0IHdoZXRoZXIgaXQgd2FzIEUuMTY0IHNwZWNpZmlj
IGhlIHNhaWQ6DQoNCiJJdCBhY3R1YWxseSBpcyBhbmQgaW4gZmFjdCBpdCBpcyB0aGUgbWFqb3Ig
bWFya2V0IGRyaXZlciBmb3IgdXNpbmcgdGhlIA0KRTJNIEVOVU0gTFVGLiINCg0KRm9yIHRob3Nl
IG5vdCBmYW1pbGlhciB3aXRoICJ2b2lkIiBhbmQgInNlbmQtbiIsIHRoZXkgYm90aCByZWxhdGUg
dG8gdGhlIA0Kc3RydWN0dXJlIGFuZCBoaWVyYXJjaHkgb2YgdGhlIEUuMTY0IG51bWJlcmluZyBw
bGFuLg0KDQpraW5kIHJlZ2FyZHMsDQoNClJheQ0KDQo=
--=_alternative 0060C3EC802576B6_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEhpIFJheSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IENhbGxpbmcgTmFtZSB3YXMgbWVudGlvbmVkICh3aGljaCBvZiBjb3Vyc2UgaXMNCm5v
dCBzcGVjaWFsIHRvIFROcykuIDxicj4NCiZndDsgQnV0IGlmIHRoYXQgd2FzIG1lbnRpb25lZCBq
dXN0ICp0YW5nZW50aWFsbHkqLCB0aGVuIHllcywgeW914oCZdmUgPGJyPg0KJmd0OyBleHBsYWlu
ZWQgaG93IGFsbCBvZiB5b3VyIGVudmlzaW9uZWQgdXNlIGNhc2VzIGFyZSBzcGVjaWZpYyB0byBU
TnMNCjxicj4NCiZndDsgYXMgbG9va3VwIGtleXMuICZuYnNwO0FuZCBnaXZlbiB0aGF0IGFsbCBv
ZiB5b3VyIGVudmlzaW9uZWQgdXNlIGNhc2VzDQphcmU8YnI+DQomZ3Q7IGFwcGFyZW50bHkgc3Bl
Y2lmaWMgdG8gVE5zLCB0aGUgYXJndW1lbnQgZm9yIGFuIEVOVU1pc2ggc29sdXRpb24gaXMNCjxi
cj4NCiZndDsgb2YgY291cnNlIGEgc3Ryb25nIG9uZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPlJpY2hhcmQgY2xhcmlmaWVkIHRoZSAmcXVvdDtDTkFNJnF1b3Q7IHVz
ZSBjYXNlLCB3aGVyZQ0KaW4gcmVzcG9uc2UgdG8gbXkgdW5jZXJ0YWludHkgYWJvdXQgd2hldGhl
ciBpdCB3YXMgRS4xNjQgc3BlY2lmaWMgaGUgc2FpZDo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZxdW90OzwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9
IzAwNDA4MD5JdA0KYWN0dWFsbHkgaXMgYW5kIGluIGZhY3QgaXQgaXMgdGhlIG1ham9yIG1hcmtl
dCBkcml2ZXIgZm9yIHVzaW5nIHRoZSBFMk0NCkVOVU0gTFVGLjwvZm9udD48L3R0Pjx0dD48Zm9u
dCBzaXplPTI+JnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5G
b3IgdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggJnF1b3Q7dm9pZCZxdW90OyBhbmQgJnF1b3Q7c2Vu
ZC1uJnF1b3Q7LA0KdGhleSBib3RoIHJlbGF0ZSB0byB0aGUgc3RydWN0dXJlIGFuZCBoaWVyYXJj
aHkgb2YgdGhlIEUuMTY0IG51bWJlcmluZw0KcGxhbi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPmtpbmQgcmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPlJheTwvZm9udD48L3R0Pg0KPGJyPg0K
--=_alternative 0060C3EC802576B6_=--

From lconroy@insensate.co.uk  Mon Jan 25 14:26:26 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C4C3A68F1 for ; Mon, 25 Jan 2010 14:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUAehOJEd+xl for ; Mon, 25 Jan 2010 14:26:25 -0800 (PST)
Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 671803A68F0 for ; Mon, 25 Jan 2010 14:26:25 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A8F8D1034AB; Mon, 25 Jan 2010 22:26:31 +0000 (GMT)
Message-Id: <41D3BFD2-D4DE-4482-B5DD-FF9F3EC8C46D@insensate.co.uk>
From: Lawrence Conroy 
To: "Cartwright, Kenneth" 
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 25 Jan 2010 22:26:31 +0000
References:  <754963199212404AB8E9CFCA6C3D0CDA0D865435A4@TNS-MAIL-NA.win2k.corp.tnsi.com>  <754963199212404AB8E9CFCA6C3D0CDA0D86543663@TNS-MAIL-NA.win2k.corp.tnsi.com>
X-Mailer: Apple Mail (2.936)
Cc: "Ray.Bellis@nominet.org.uk" , "dispatch@ietf.org" 
Subject: Re: [dispatch] E2M -- what's the delay?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2010 22:26:26 -0000

Hi Folks,
  Me too.
(CNAM, ANI, CLIP, Caller Display) are all directly related to  
telephone numbers.
IMHO, so are other denizens like Calling Party Number, Called Party  
Number, Connected Party Number (and name), ...

They are not related to display names of SIP AORs, or display parts of  
Email addresses, or ...

That reminds me that I have not recently thanked God that we
no longer have COMPUSERVE email addresses, which I hereby do.
However, even these were not telephone numbers.

all the best,
   Lawrence

On 25 Jan 2010, at 17:19, Cartwright, Kenneth wrote:
> Hi Ray,
>
> Calling Name was mentioned (which of course is not special to TNs).   
> But if that was mentioned just *tangentially*, then yes, you've  
> explained how all of your envisioned use cases are specific to TNs  
> as lookup keys.  And given that all of your envisioned use cases are  
> apparently specific to TNs, the argument for an ENUMish solution is  
> of course a strong one.
>
> Thanks.
> Ken
>
> ________________________________
> From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
> Sent: Monday, January 25, 2010 11:31 AM
> To: Cartwright, Kenneth
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] E2M -- what's the delay?
>
>
>> 4) Again, using an ENUMish standard to get data that is specific to
>> TNs (e.g. to turn a TN into an AOR, to help interpret and traverse a
>> TN number plan, etc) obviously makes perfect sense.  That is of
>> course what ENUM was built for.  But to use an ENUMish solution to
>> feed up other important data elements that have nothing to do with
>> the fact that the lookup key is a TN (or a domain name), such as
>> calling name information, is unfortunate.  Calling Name information,
>> for example, of course exists for addresses that are not TNs.  So
>> why would one propose a calling name lookup protocol that only
>> allows lookup keys to be TNs (that are turned into domain names)?
>
> Ken,
>
> Did my previous e-mail (and Richard's followup) not explain clearly  
> enough how all three existing use cases for E2M are _specifically_  
> related to TNs?
>
> kind regards,
>
> Ray
>
> ________________________________
> This e-mail message is for the sole use of the intended  
> recipient(s)and may
> contain confidential and privileged information of Transaction  
> Network Services.
> Any unauthorised review, use, disclosure or distribution is  
> prohibited. If you
> are not the intended recipient, please contact the sender by reply e- 
> mail and destroy all copies of the original message.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From ranjit@motorola.com  Wed Jan 27 07:57:15 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFFF3A6837 for ; Wed, 27 Jan 2010 07:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvKDxmqw9t+g for ; Wed, 27 Jan 2010 07:57:13 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 750693A681A for ; Wed, 27 Jan 2010 07:57:13 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-8.tower-119.messagelabs.com!1264607846!36105809!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [136.182.1.14]
Received: (qmail 19519 invoked from network); 27 Jan 2010 15:57:26 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jan 2010 15:57:26 -0000
Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id o0RFvQDh005711 for ; Wed, 27 Jan 2010 08:57:26 -0700 (MST)
Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o0RFvLSr027965 for ; Wed, 27 Jan 2010 09:57:21 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o0RFvJTK027924 for ; Wed, 27 Jan 2010 09:57:20 -0600 (CST)
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: Wed, 27 Jan 2010 23:56:55 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28B1FD@ZMY16EXM66.ds.mot.com>
In-Reply-To: <4B5DA8E3.7050306@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
thread-index: AcqdybGhVn1iMDO0Slm+MIYFp2NNmgBnid+w
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A245729@ZMY16EXM66.ds.mot.com><4873a6aacb123154f96af62bb241016d.squirrel@www.softarmor.com><750BBC72E178114F9DC4872EBFF29A5B0A28A86E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A28AA39@ZMY16EXM66.ds.mot.com>  <4B55F6B7.60002@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28AB6C@ZMY16EXM66.ds.mot.com> <4B574722.9070108@cisco.com>  <750BBC72E178114F9DC4872EBFF29A5B0A28ADD5@ZMY16EXM66.ds.mot.com> <4B59BA06.40608@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A28AF42@ZMY16EXM66.ds.mot.com> <4B5DA8E3.7050306@cisco.com>
From: "Avasarala Ranjit-A20990" 
To: "Paul Kyzivat" 
X-CFilter-Loop: Reflected
Cc: DISPATCH 
Subject: Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 15:57:15 -0000

Hi Paul

Reply inline =20

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Monday, January 25, 2010 7:51 PM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; DISPATCH
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

Comments inline.

	Thanks,
	Paul

Avasarala Ranjit-A20990 wrote:
> Hi Paul
>=20
> My responses inline 
>=20
>=20
> Sip:alice@office.domain.com OR sip:alice@home.domain.com would be the=20
> registered contacts for sip:alice@domain.com. So these two registered=20
> contacts could have individual URIs (using GRUU).

OK, I guessed right on that part.

> The
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, January 22, 2010 8:15 PM
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; DISPATCH
> Subject: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
>=20
> Ranjit,
>=20
> The URLs you are using are suggestive as to their roles, but its still

> not entirely clear to me. Is the following correct?
>=20
> sip:alice@domain.com		AOR
>=20
> alice@office.domain.com		Contact registered to
> 				sip:alice@domain.com
>=20
> sip:boss@domain.com		AOR
>=20
> sip:boss@office.domain.com	Contact registered to
> 				sip:alice@domain.com
>=20
> More inline
>=20
> Avasarala Ranjit-A20990 wrote:
>> Hi all
>>
>> The elements have following meaning
>>
>>        This element would give the details of
>> subscriber user - E.g. alice@domain.com
>>
>>  This element gives the details of the call=20
>> originator. i.e the caller. Which in the example is=20
>> sip:boss@domain.com or
>>                         sip:boss@office.domain.com.
>=20
> How is the originator of a request determined? Is it from From or=20
> P-A-ID? How is it that either of the above might be the originator?
>=20
>  The originating-user-info URL would be the incoming caller=20
> identity that is present in "From" header. So it could be=20
> sip:boss@domain.com OR
>          sip:boss@ofice.domain.com depending on caller id=20
> configuration and how the caller wants his or her identity to be=20
> displayed to the called user.
>=20
>          So yes the originator of the request is determined from the=20
> P-Asserted-Identity of the caller.

OK, no surprises.

>>    This element gives the details of the device
> on
>> whose behalf diversion is taking place. For e.g. if Alice@domain.com=20
>> has set a
>>                         rule for alice@office.domain.com to divert=20
>> all
>=20
>> calls from Bob between 9 AM and 10 AM to voice-mail, then the
>>                         Alice@office.domain.com would be the=20
>> "diverting-user"
>=20
> Some questions about above:
>=20
> Assuming sip:alice@office.domain.com is not an AOR, but rather is a=20
> registered contact to sip:alice@domain.com, where in the routing of=20
> the call does the server that evaluates this rule get control?
>=20
>  The server looks for the incoming caller identity and the=20
> destination identity to see if there is a matching rule configured.

I guess my question wasn't clear.
Where in the routing sequence does this server reside?

 The server could be the Application Server where the
diversion rules reside and get executed.

If it is positioned before the contact routing has occurred, then it
can't know which contact was chosen.
 No it would be before that.=20

Since this proposal is coming, more or less, from IMS I assume you are
imagining this is an IMS Application Server. IIRC, those get control
*before* contact routing is done by the S-CSCF. So how would the AS know
if a particular contact was chosen. (I take some issue with calling
contact routing "diversion", but lets not discuss that right now.)

 Yes you are right. This proposal is more from a IMS and
3GPP perspective and I am trying to generalize it for IETF.

> If the registered=20
>          contact is not an AoR, then the call cannot be routed to it=20
> and

Huh? Whether the registered contact is an AOR has no bearing on whether
its possible to route to it. And, its in general impossible to determine
by looking whether a URI is an AOR or not.

 Agree with you on this.

> hence will be routed to the main AoR i.e sip:alice@domain.com and the=20
> rule would not be executed.

That statement makes me even more confused. I have no idea what it
means.

 Here I mean, the notifications would be sent to the
main AoR with the details of "diverting-user", "diverted-to-user" being
part
Of the XML package. The notifications need not be sent to the registered
contact. For e.g if sip:alice@domain.com is the AoR and diversions are
taking
Place for sip:alice@office.domain.com, then notifications will be sent
to sip:alice@domain.com only and not to sip:alice@domain.com. This will
simplify things I feel !!

> But if sip:alice@office.domain.com is an AoR (e.g. GRUU), then the=20
> call could be routed and if there is adiversion rule there,
>          the diversion rule would get executed and a notification=20
> generated towards that AoR.

This is getting more and more confusing. So I have even more desire for
at least a detailed use case that shows all the players, their addresses
and relationships to one another, and the call flow.

 as I mentioned above, to simplify things, lets assume
that notifications always go to the main AoR i.e the Public User
Identity (in IMS)
And not to any of the registered AoR irrespective of who the diverting
user is. So here even tough the divering user is sip:alice@office or
sip:alice@home, the notifications always go to sip:alice@domain.com.=20

> How would it work in cases where the address for Alice's office phone=20
> is a dynamically assigned ip address rather than a dns name?
>=20
>  Since the notification gets generated dynamically when ever=20
> the diversion occurs, the new ip address is taken prior to sending the

> notification.

Again it seems my question wasn't clear.
You are showing rules that contain the contact addresses of particular
devices. If the contact URIs registered by those devices contain
dynamically assigned addresses, how would a subscriber know how to
construct the rule that selects a particular device? Or if it is
receiving all the diversions, how would it relate the reported results
to particular devices?

 if the notifications are sent to PUI, then the contact
addresses are specified as URLs. So there is no need to send any
notifications to individual contact adsresses

This relates, in a way, to whether contact routing is diversion or not.=20
Typically what I think of as real diversion would be to a URI that *is*
an AOR, and hence stable and knowable by those formulating rules. But
typical contact routing would involve URIs that aren't very meaningful.

If you want to be able to write rules like: "let me know when the call
is routed to the phone in my office rather than the one in my home"=20
(where both have the same "phone number"), then you are going to have to
find a way to give those stable URIs, like sip:alice@office.domain.com
and sip:alice@home.domain.com. AFAIK that isn't the norm, so if you are
assuming it then please make that clear.

>>       This element gives the final target of the
> call.
>> For e.g. the voice-mail.
>=20
> The *final* target? I don't think that is possible.
> It can at best be the address last known to the server doing the=20
> reporting. If the call is diverted again downstream, that won't be=20
> known. Or am I missing something?
>=20
>  True, the final-target here means the next hop from the
server.
> E.g if the server diverts the call to another server, then that server

> would be the final target. Agree with you that getting the final=20
> target of diversion would not be possible if there are multiple=20
> entities involved in the path.
>=20
> Also, suppose we have an SSP that services multiple AORs. But still=20
> the subscriptions are on a per-AOR basis. If Alice gives a rule that=20
> diverts her calls to Charlie, who is also a customer of the same SSP,=20
> and Charlie has also installed diversion rules for his AOR, do you=20
> expect the notifications from subscription to Alice to report on the=20
> downstream diversions performed by Charlie?
>=20
>  No. All notifications to Alice indicate that calls to Alice=20
> got diverted to Charlie. What happened beyond that, Alice would not
know.

OK. Good.

>>    This element gives the actual time of
> diversion.
>> E.g. 9.30 AM
>>
>> ,diversion-reason-info> This element gives the reason for diversion.
>> E.g. Rule-id of Reason like CFB
>>
>> So based on this a typical subscription document would like
>>
>> 
>>      
>>        
>>           Alice 
>>           alice@domain.com 
>>        
>>      
>>      
>>          
>>             
>>               
>>                 Bob
>>                 
>>                   sip:Bob@domain.com
>>                 
>>               
>>             
>>             
>>                
>>                 Alice
>>                 
>>                   sip:alice@office.domain.com
>>                 
>=20
> I thought the user-name was the same as the user portion of the URI.=20
> If not, how does a server determine what it is in a request in order=20
> to do matching on it?
>=20
>  Yes. Agree with you. Changed it
>=20
> 	Thanks,
> 	Paul
>=20
>>               
>>             
>>             
>>               
>>                2010-01-22T09:00:00-05:00
>>                2010-01-22T10:00:00-05:00
>>               
>>             
>>             
>>               
>>             
>>           
>>       
>>    
>>
>> The above XML document represents a subscription document for=20
>> notifying diversiosn that occur between 9 and 10 AM at divering user=20
>> alice@ Regards Ranjit
>>
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
>> Sent: Thursday, January 21, 2010 2:42 AM
>> To: Paul Kyzivat; Avasarala Ranjit-A20990
>> Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
>> Subject: RE: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>> =20
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>> Sent: 20 January 2010 18:11
>>> To: Avasarala Ranjit-A20990
>>> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
>>> Subject: Re: [dispatch] Comments
>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>
>>>
>>>
>>> Avasarala Ranjit-A20990 wrote:
>>>> Hi Dean
>>>>
>>>> A sample diversion notification document would like
>>>>
>>>> 
>>>>   
>>>>     
>>>>       Boss
>>>>       sip:boss@office.com
>>>>     
>>>>     
>>>>       sip:alice@office.com
>>>>     
>>>>     
>>>>       sip:bob@office.com
>>>>     
>>>>    =20
>>> 1999-06-01T13:20:00-05:00
>>>>     404
>>>>   
>>>> 
>>>>
>>>> So here, the subscribing AoR would be alice@domain.com. The=20
>>>>  which is alice@office.com gives the
>>> URI that is
>>>> actually diverting. While the 
>>> element gives the
>>>> final target of the call.
>>> Hmm. Can you explain further?
>>>
>>> Is the AOR sip:alice@domain.com, with sip:alice@office.com being a=20
>>> registered Contact for that?
>>>
>>> If so, I would expect that sip:alice@domain.com would be the=20
>>> diverting user. For sip:alice@office.com to be the diverting user,=20
>>> wouldn't that phone have to initiate the diversion? If that were the

>>> case, how would the notifier for the event discover that the=20
>>> diversion has occurred?
>> [JRE] I have exactly the same questions as Paul, but also an addition

>> question. If sip:boss@office.com is the contact URI for AOR=20
>> sip:boss@domain.com, why would  not contain=20
>> sip:boss@domain.com? Although the contact URI would be available,=20
>> often the contact URI is not meaningful, i.e., often it would not=20
>> explicitly identify boss. Also, from a return call perspective,=20
>> sip:boss@domain.com would be more useful, since it would hopefully=20
>> reach boss on whatever device he happens to be using at the time.
>>
>> John
>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> So at any point of time, alice@domain.com can check all the=20
>>>> notifications received to determine the set of diversions that have

>>>> taken place at various registered contacts of Alice.
>>>>
>>>> Now if we take the call centre scenario, then a particular
>>> incoming call
>>>> could get forked probably sequentially until one of the
>>> agents picks the
>>>> call. So I feel this is not a valid use case of call diversion, but

>>>> would qualify for a use case of sequential or simultaneous forking.
>>>>
>>>> Regards
>>>> Ranjit
>>>>
>>>> -----Original Message-----
>>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>>> Sent: Wednesday, January 20, 2010 11:34 AM
>>>> To: Paul Kyzivat
>>>> Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH;
>>> Gonzalo Camarillo
>>>> Subject: Re: [dispatch] Comments
>>>> requestedondraft-avasarala-dispatch-comm-div-notification
>>>>
>>>>
>>>> On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:
>>>>
>>>>> Elwell, John wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Avasarala Ranjit-A20990
>>> [mailto:ranjit@motorola.com] Sent: =20
>>>>>>> 19 January 2010 17:49
>>>>>>> To: Elwell, John; Dean Willis
>>>>>>> Cc: Gonzalo Camarillo; DISPATCH; jbakker@rim.com
>>>>>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala-=20
>>>>>>> dispatch-comm-div-notification
>>>>>>>
>>>>>>> Hi John
>>>>>>>
>>>>>>> Sorry for the late response. Yes the notifications will
>>> be from the
>>>>>>> server towards the original AoR with the registered contact=20
>>>>>>> specified as part of the event package (e.g in the element=20
>>>>>>> "diverting-user").
>>>>>>> So it
>>>>>>> would be the job of the notifier to generate appropriate
>>> diversion
>>>>>>> notification information towards the target AoR.
>>>>>> [JRE] This just confuses me again. It first says the notification

>>>>>> will be sent from the server to the original AOR, and
>>> then it says
>>>>>> notification information is send towards the target AOR -
>>> apparently
>>>>>> a contradiction, unless these two terms mean the same
>>> thing. Also,
>>>>>> why is the registered contact (I assume this means
>>> contact URI) sent
>>>>>> in element "diverting-user" rather than the original AOR?
>>>>> This has confused me from the beginning.
>>>>> It seems the assumption is that only the "diverting user" will=20
>>>>> subscribe. But in reality that doesn't make much sense if the=20
>>>>> subscription is addressed to the diverting user.
>>>> The diverting user has multiple user agents. Said user
>>> cannot remember
>>>> which user agent is set to divert, or what it is diverting
>>> to. So said
>>>> user subscribes to the divnot package in order to find out
>>> what the heck
>>>> is happening.
>>>>
>>>>> It makes some sense if the subscribers are UAs that have
>>> registered
>>>>> with the AOR of the diverting user, and the notifier is a
>>> server that
>>>>> mediates arriving requests to that AOR.
>>>>>
>>>> Yes, I think that's the intent
>>>>
>>>>> But even then, while its reasonable to expect that the registered=20
>>>>> devices might be interested in subscribing to this, surely
>>> they aren't
>>>>> the *only* plausible subscribers. Assuming they are is, IMO, a=20
>>>>> mistake.
>>>> I think your view of the architecture is somewhat larger than the=20
>>>> author's. This is not unreasonable. Like you, I can
>>> envision other use
>>>> cases, such as call center scenarios.
>>>>
>>>> Is there any reason NOT to generalize the specification for broader

>>>> applicability?
>>>>
>>>> --
>>>> Dean
>>>>
>>>>
>>>>
>>>>
>>>>
>=20

From fluffy@cisco.com  Wed Jan 27 08:22:15 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A17D3A6AB6 for ; Wed, 27 Jan 2010 08:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.363
X-Spam-Level: 
X-Spam-Status: No, score=-110.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZeu7qNPAMkD for ; Wed, 27 Jan 2010 08:22:14 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5C96D3A6359 for ; Wed, 27 Jan 2010 08:22:14 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALr2X0urR7Hu/2dsb2JhbADCGpcWhDkE
X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="473696304"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2010 16:22:29 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0RGMS3t016677; Wed, 27 Jan 2010 16:22:28 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings 
In-Reply-To: <02ee01ca902b$9e4e5e50$daeb1af0$@com>
Date: Wed, 27 Jan 2010 09:22:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <013401ca679d$3a926700$afb73500$@us>	<00cd01ca8387$9b46ea20$d1d4be60$@com>	<4B32DEE9.5000302@softarmor.com>	<007301ca84b7$343dd6f0$9cb984d0$@us>	<4B33D01C.9000006@cisco.com>	<4B39AE2C.9090304@softarmor.com>	<503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com>	<1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com>	<4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com>  <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com>
To: Paul Jones , Dean Willis 
X-Mailer: Apple Mail (2.1077)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 16:22:15 -0000

I'm trying to think about what we want to accomplish by publishing this =
draft as an RFC. I was very happy to read the draft and think there is =
some good stuff in it. =20

The draft contains a mixture of things. Partially it is a liaison to =
IETF from sipforum about what they are up to with a sipform work group. =
This is great to get but I don't think there is much long term need to =
record that in RFC form. The more important part to publish IMHO is =
documenting some issues, problems, deficiencies and/or bugs in some IETF =
specifications that are leading to lack of interoperability in =
deployments. That type of problem statement would be great information =
to get written down in a concrete form that allows the appropriate WG to =
go fix the problems.=20

I do realize fax works by using protocols from multiple SDOs and that =
does complicate things. I think it would be beneficial to document =
specific problems found with IETF protocols. I'm less interested in the =
IETF publishing problems with some other SDOs protocols.  You've caught =
me at a particularly sensitive time having just spend 1/2 my time for =
the last several months dealing with the IETF relationships with other =
SDOs. And if anyone mentions royalty free fax algorithms my head might =
explode :-)

So what I am getting at is could we move this draft more towards =
something that documents what is observed in real world deployments and =
discuss the problems with the existing IETF protocols, then WG Last Call =
it in the appropriate WG(s) (I'm assuming things like mmusic, fecframe, =
perhaps avt) and publish it as informational? The goal of publishing it =
would be to provide a problem statement for future work in theses WG. =20=

Does that make sense to people? Reasonable path forward? I'm open to =
other ideas but whatever we do, I would want to understand why =
publishing whatever document we published was going to help make things =
work better. And on that note, I'd like to express many thanks to SIP =
Forum and all the people who worked on this effort for helping get fax =
working better.

Cullen

PS - Paul, thanks for trying to make less work and Dean, as punishment =
for your sins I'm nominating you for AD to the next Nomcom :-)=20

On Jan 7, 2010, at 11:27 PM, Paul E. Jones wrote:

> Dean said:
>>> "AD Sponsored submissions represent a significant workload to the
>>> IESG."
>>>=20
>>=20
>> If the document is well enough drafted that it doesn't create a lot =
of
>> work for the AD, then there isn't that much extra work.
>>=20
>> One can also use an external document shepherd to make sure the doc =
is
>> really "IESG ready" before the AD gets deeply into it. PaulK would be
>> good at this ;-).
>>=20
>> Besides, Cullen needs more work to do.
>=20
> So, Paul K. and Cullen should each be made aware that you've given =
them an
> assignment.  They'll thank you at the next meeting. ;-)
>=20
> Paul
>=20
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

From fluffy@cisco.com  Wed Jan 27 09:06:59 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29053A6ABC for ; Wed, 27 Jan 2010 09:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.382
X-Spam-Level: 
X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LPhA5-Yk8yE for ; Wed, 27 Jan 2010 09:06:58 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C2DD83A6ACE for ; Wed, 27 Jan 2010 09:06:58 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAFEBYEurR7Hu/2dsb2JhbADCSJcZgjSCBQQ
X-IronPort-AV: E=Sophos;i="4.49,355,1262563200"; d="scan'208";a="292927236"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2010 17:07:13 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0RH7C3q029612 for ; Wed, 27 Jan 2010 17:07:13 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings 
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
Date: Wed, 27 Jan 2010 10:07:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4B4F2403.7010200@ericsson.com>  <750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com>
To: DISPATCH 
X-Mailer: Apple Mail (2.1077)
Subject: Re: [dispatch] Comments requestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 17:06:59 -0000

There are way to accomplish the same end goals as this draft suggests =
using things that are very likely to predate RIM's IPR on the topic. For =
example the ideas on using things similar to the dialog events package =
or reporting events about call forking on proxies. I have a strong =
preference for doing this in an IPR free way. I strongly encourage the =
WG to explore alternative ways to solve these problems before deciding =
what to do with this draft.=20

Cullen 

On Jan 15, 2010, at 2:49 AM, Avasarala Ranjit-A20990 wrote:

> Hi John
>=20
> Yes the notifications are generated for the AoR (contact) for which =
the
> diversion has occurred.=20
>=20
> So even though there could be multiple contacts registered for a
> particular AoR, if the diversion has occurred for a particular contact
> say alice at cellphone, then the notification information would go =
only
> to her cellphone and not to all registered contacts.  This way we =
would
> be limiting the number of notifications that are sent.
>=20
> In current call diversion service configurations, there is no concept =
of
> notifying subscribers when a particular call gets diverted based on a
> particular rule.=20
>=20
> Considering the case of Alice@example.com. Lets say Alice has setup a
> call diversion rule for her cellphone to divert all calls from a
> particular caller between 9 AM and 10 AM to her voicemail. But for =
some
> reason she could have wrongly configured the rule as 9 to 10 AM or =
could
> have put the caller id as wrong one. So it would be very difficult for
> her to manually spot this error by reviewing the complete set of call
> diversion services. So in order to facilitate Alice to effectively =
find
> out the error, a notification mechanism is required.
>=20
> So here th URI for subscription would be the URI that is associated =
with
> diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
>=20
> Thanks
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Elwell, John
> Sent: Friday, January 15, 2010 2:57 PM
> To: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments requestedon
> draft-avasarala-dispatch-comm-div-notification
>=20
> I reserve judgement on how useful this would be. Concerning comments
> from Paul, I could imagine that the SUBSCRIBE request is addressed to
> the AOR URI for which notifications of diverted inbound requests are
> required, and that information from that AOR's domain proxy would be
> used as the basis for notifications. So the notifier would need =
somehow
> to be coupled to the domain proxy. This could certainly do with
> clarification.
>=20
> It is unclear to me how one would handle a subscription in the =
following
> circumstances. The subscription is to alice@example.com. At any given
> time, there might be several contacts registered against
> alice@example.com. According to relative priorities of those contacts,
> scripting rules at the proxy, caller preferences, etc., a given =
inbound
> request to Alice would go to one or more of those contacts. Is it the
> intention that those contacts that do not receive that inbound request
> would receive a notification within the context of this event package?
> So if Alice's deskphone is one contact and her cellphone is another
> contact, if her current rules are for calls to go to her cellphone, =
her
> deskphone would receive notifications, and vice versa?
>=20
> Or is that out of scope? Is the intention to limit the scope to cases
> where an inbound communication is diverted away from the AOR =
concerned?
>=20
> John
>=20
>=20
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
>> Sent: 14 January 2010 14:03
>> To: DISPATCH
>> Subject: [dispatch] Comments requested on=20
>> draft-avasarala-dispatch-comm-div-notification
>>=20
>> Hi,
>>=20
>> we would like to ask for comments on the following draft. Do you find=20=

>> it useful? Do you think it should be published as an RFC?
>>=20
>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
>> otification-02
>>=20
>> Based on the comments received, we will talk to our ADs about this=20
>> piece of work.
>>=20
>> Thanks,
>>=20
>> Gonzalo
>> DISPATCH co-chair
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From bernard_aboba@hotmail.com  Wed Jan 27 10:20:36 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318923A6869 for ; Wed, 27 Jan 2010 10:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+LdxRNHYVjJ for ; Wed, 27 Jan 2010 10:20:35 -0800 (PST)
Received: from blu0-omc4-s28.blu0.hotmail.com (blu0-omc4-s28.blu0.hotmail.com [65.55.111.167]) by core3.amsl.com (Postfix) with ESMTP id E0B2B3A67D3 for ; Wed, 27 Jan 2010 10:20:34 -0800 (PST)
Received: from BLU137-DS2 ([65.55.111.135]) by blu0-omc4-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Jan 2010 10:20:49 -0800
X-Originating-IP: [24.19.160.219]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: "Bernard Aboba" 
To: 
Date: Wed, 27 Jan 2010 10:22:12 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CA9F3A.977F6AB0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqffaVheNf8ULOrSUuirN7P55BJtQ==
Content-Language: en-us
X-OriginalArrivalTime: 27 Jan 2010 18:20:49.0877 (UTC) FILETIME=[73F6E850:01CA9F7D]
Subject: Re: [dispatch] [sipcore] I-D Action: draft-jones-sip-forum-fax-problem-statement-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 18:20:36 -0000

------=_NextPart_000_005E_01CA9F3A.977F6AB0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Since much of the document relates to T.38, I would agree that the target
audience is more ITU-T than IETF, since that is where the expertise is
likely to lie.   Given that, it's not clear to me how well that target
audience would be served by (or happy with) publication of an RFC. 

In terms of sections relevant to IETF protocols, the most obvious is Section
2.6 (SDP Negotiation).  Maybe one or more WGs might want to weigh in on
that. 

Cullen said:

" I'm trying to think about what we want to accomplish by publishing this
draft as an RFC. I was very happy to read the draft and think there is some
good stuff in it.  

The draft contains a mixture of things. Partially it is a liaison to IETF
from sipforum about what they are up to with a sipform work group. This is
great to get but I don't think there is much long term need to record that
in RFC form. The more important part to publish IMHO is documenting some
issues, problems, deficiencies and/or bugs in some IETF specifications that
are leading to lack of interoperability in deployments. That type of problem
statement would be great information to get written down in a concrete form
that allows the appropriate WG to go fix the problems. 

I do realize fax works by using protocols from multiple SDOs and that does
complicate things. I think it would be beneficial to document specific
problems found with IETF protocols. I'm less interested in the IETF
publishing problems with some other SDOs protocols.  You've caught me at a
particularly sensitive time having just spend 1/2 my time for the last
several months dealing with the IETF relationships with other SDOs. And if
anyone mentions royalty free fax algorithms my head might explode :-)

So what I am getting at is could we move this draft more towards something
that documents what is observed in real world deployments and discuss the
problems with the existing IETF protocols, then WG Last Call it in the
appropriate WG(s) (I'm assuming things like mmusic, fecframe, perhaps avt)
and publish it as informational? The goal of publishing it would be to
provide a problem statement for future work in theses WG.  

Does that make sense to people? Reasonable path forward? I'm open to other
ideas but whatever we do, I would want to understand why publishing whatever
document we published was going to help make things work better. And on that
note, I'd like to express many thanks to SIP Forum and all the people who
worked on this effort for helping get fax working better.

Cullen

PS - Paul, thanks for trying to make less work and Dean, as punishment for
your sins I'm nominating you for AD to the next Nomcom :-) "

------=_NextPart_000_005E_01CA9F3A.977F6AB0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Since much of the document relates to T.38, I would =
agree that
the target audience is more ITU-T than IETF, since that is where the =
expertise
is likely to lie.   Given that, it's not clear to me how well =
that
target audience would be served by (or happy with) publication of an =
RFC. 

In terms of sections relevant to IETF protocols, =
the most
obvious is Section 2.6 (SDP Negotiation).  Maybe one or more WGs =
might
want to weigh in on that. 

Cullen said:

" I'm trying to think about what we want to
accomplish by publishing this draft as an RFC. I was very happy to read =
the
draft and think there is some good stuff in it.  

The draft contains a mixture of things. =
Partially it is a
liaison to IETF from sipforum about what they are up to with a sipform =
work
group. This is great to get but I don't think there is much long term =
need to
record that in RFC form. The more important part to publish IMHO is =
documenting
some issues, problems, deficiencies and/or bugs in some IETF =
specifications
that are leading to lack of interoperability in deployments. That type =
of
problem statement would be great information to get written down in a =
concrete
form that allows the appropriate WG to go fix the problems. =

I do realize fax works by using protocols from =
multiple
SDOs and that does complicate things. I think it would be beneficial to
document specific problems found with IETF protocols. I'm less =
interested in
the IETF publishing problems with some other SDOs protocols.  =
You've
caught me at a particularly sensitive time having just spend 1/2 my time =
for
the last several months dealing with the IETF relationships with other =
SDOs. And
if anyone mentions royalty free fax algorithms my head might explode =
:-)

So what I am getting at is could we move this =
draft more
towards something that documents what is observed in real world =
deployments and
discuss the problems with the existing IETF protocols, then WG Last Call =
it in
the appropriate WG(s) (I'm assuming things like mmusic, fecframe, =
perhaps avt)
and publish it as informational? The goal of publishing it would be to =
provide
a problem statement for future work in theses WG.  

Does that make sense to people? Reasonable path =
forward?
I'm open to other ideas but whatever we do, I would want to understand =
why
publishing whatever document we published was going to help make things =
work
better. And on that note, I'd like to express many thanks to SIP Forum =
and all
the people who worked on this effort for helping get fax working =
better.

Cullen

PS - Paul, thanks for trying to make less work =
and Dean,
as punishment for your sins I'm nominating you for AD to the next Nomcom =
:-) "

------=_NextPart_000_005E_01CA9F3A.977F6AB0--

From mary.ietf.barnes@gmail.com  Wed Jan 27 11:16:19 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0953E3A6927 for ; Wed, 27 Jan 2010 11:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6FDqafhnvF6 for ; Wed, 27 Jan 2010 11:16:17 -0800 (PST)
Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id 91A893A6812 for ; Wed, 27 Jan 2010 11:16:17 -0800 (PST)
Received: by iwn14 with SMTP id 14so1914519iwn.18 for ; Wed, 27 Jan 2010 11:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AkHNO5DsGj1d4mkVfQYnEQDEzcFup4dmafH60xKzCxE=; b=sYIXBzLAgKypTG7PQuDGHubEEOwCUt9LQqT7JpktnNirupROGuhemzY7EdH8qkHOJW f7ZdR5ukkKiH6kVuXulmfGgudkxHe3Zyl7uUAWQLszqXr+BtGFnLwIFBO9LPdLibsnYT o9DT5aZruQo0NFSP6UH4OXx8YMsv8j+HPrS9o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PI2wrfJjsfHVxGFmqVI52Rqx8rlHa/7gcd5i6GMT0HIpjeqTeXH/KB48esNjfPZbCZ 3FcNFMqC7sjJP5rxiPtgtHHjsXMPmsFX7FqkfIpqevUkvnomnwzsvrgAHz3omqJEYo6u B3/n2nA1EWUi4N1qvhLl6gsRZjFFaA/Hz9+8I=
MIME-Version: 1.0
Received: by 10.231.149.10 with SMTP id r10mr8349364ibv.63.1264619786858; Wed,  27 Jan 2010 11:16:26 -0800 (PST)
In-Reply-To: <4B581D0C.80809@ericsson.com>
References:  <4B581D0C.80809@ericsson.com>
Date: Wed, 27 Jan 2010 13:16:26 -0600
Message-ID: <184b5e71001271116j6e1b73enc1b60acffcef96c9@mail.gmail.com>
From: Mary Barnes 
To: dispatch@ietf.org
Content-Type: multipart/alternative; boundary=0016e64135b22bf070047e2a3d15
Cc: "rai-ads@tools.ietf.org" , Mary Barnes , gonzalo.camarillo@ericsson.com
Subject: Re: [dispatch] IETF-77 DISPATCH WG deadlines
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2010 19:16:19 -0000

--0016e64135b22bf070047e2a3d15
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

We did not receive any notifications from folks that they had plans to
submit a topic proposal targetted for the IETF-77 timeframe by the Jan.18th
deadline, nor after this reminder.  Thus, the DISPATCH WG is *not* planning
to meet in Anaheim.

However, we do encourage folks to continue discussion of any topic proposals
on the mailing list since it is not necessary to have f2f discussion in
order to progress work.

As a reminder, the status of items that have been dispatched is available on
the DISPATCH WG wiki:
http://trac.tools.ietf.org/wg/dispatch/trac/wiki

Regards,
Mary
DISPATCH WG co-chair

On Thu, Jan 21, 2010 at 3:23 AM, Gonzalo Camarillo <
Gonzalo.Camarillo@ericsson.com> wrote:

> Folks,
>
> this is just a reminder of the deadlines we are working with for the
> next IETF (see email below).
>
> Cheers,
>
> Gonzalo
>
>
> -------- Original Message --------
> Subject: IETF-77 DISPATCH WG deadlines
> Date: Wed, 16 Dec 2009 21:06:28 +0100
> From: Mary Barnes 
> To: dispatch@ietf.org 
> CC: Gonzalo Camarillo ,
> "rai-ads@tools.ietf.org" 
>
> Hi all,
>
> The following summarizes the deadlines for discussing topics in DISPATCH
> prior to the WG session at IETF-77.
>
> We will again work within the deadlines for BoFs:
> http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77
>
> This provides enough time to dispatch topics prior to the meeting as
> appropriate - e.g., mini-bofs, official bofs, other WGs, new WGs,
> mailing lists, etc. Thus, allowing us to have more focused and
> constructive discussions on a smaller set of topics prior to the WG
> session.
>
>
> Jan 18th, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to
> submit a proposal.
> ------------------------------------------------------------------------
> --------------------
>
> This will help folks with similar topics to work together before the
> meeting. If a preliminary charter proposal is available at this point,
> please include it.
>
> Note: Jan 25th is BoF proposal request date.
>
>
> Feb 1st, 2010. Cutoff for charter proposals for topics.
> --------------------------------------------------------------
>
> A charter proposal must consist of a minimum of a problem statement and
> at least one milestone/deliverable. This deadline will allow time for
> consideration of proposals that could potentially be "dispatched" prior
> to the WG session.
>
>
> Feb 8th, 2010. Topics that are to be the focus of IETF-77 are announced.
> [AD BoF approval date]
> ------------------------------------------------------------------------
>
> The idea here is to focus the discussion over the weeks preceding
> IETF-77 on these main topics, noting that any new or updates to any
> documents are due 3-4 weeks later.  This will ensure we have
> constructive discussions before the meeting and are actually able to
> determine consensus as to where work should be progressed (e.g.,
> separate BoF, a new WG, an existing WG, individual document, etc.) at
> IETF-77. Note, that the exact disposition for a topic may (per the usual
> process) require follow-up and confirmation by the ADS and/or IESG
> (e.g., for a new WG, Bof, individually sponsored document, etc.) or with
> another WG to ensure agreement with the DISPATCH WG consensus for the
> topic.
>
> March 1st, 2010. -00 draft deadline.
> -----------------------------------
>
> March 8th, 2010. Draft deadline.
> --------------------------------
>
>
> As discussed previously, the intention is not necessarily to preclude
> folks submitting documents on other topics, however, it is very unlikely
> there would be agenda time allocated to documents/topics submitted after
> the deadlines. We can include one or two slides on these topics in the
> DISPATCH WG chair charts so that the authors can gather other interested
> parties to contribute to the work.
>
> Regards,
> Mary and Gonzalo
> DISPATCH WG co-chairs
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

--0016e64135b22bf070047e2a3d15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all, 
=A0
We did not receive any notifications from folks that they had plans to=
 submit a topic proposal targetted for the IETF-77 timeframe by the Jan.18t=
h deadline, nor after this reminder.=A0 Thus, the DISPATCH WG is *not* plan=
ning to meet in Anaheim. 

=A0
However, we do encourage folks to continue discussion of any topic pro=
posals on the mailing list since it is not necessary to have f2f discussion=
 in order to progress work.
=A0
As a reminder, the status of items that have been dispatched is availa=
ble on the DISPATCH WG wiki:
http://tr=
ac.tools.ietf.org/wg/dispatch/trac/wiki
=A0
Regards,
Mary
DISPATCH WG co-chair

On Thu, Jan 21, 2010 at 3:23 AM, Gonzalo Camaril=
lo <=
Gonzalo.Camarillo@ericsson.com> wrote:

Folks,

this is just a rem=
inder of the deadlines we are working with for the
next IETF (see email =
below).

Cheers,

Gonzalo

-------- Original Message --------Subject: IETF-77 DISPATCH WG deadlines
Date: Wed, 16 Dec 2009 21:06:28 =
+0100
From: Mary Barnes <ma=
ry.barnes@nortel.com>

To: dispatch@ietf.org <dispatch@ietf.org>
CC: Gonzalo Cama=
rillo <gonzalo.camaril=
lo@ericsson.com>,

"rai-ads@tools.ietf.org&=
quot; <rai-ads@tools.ietf.org<=
/a>>

Hi all,

The following summarizes the deadlines for di=
scussing topics in DISPATCH

prior to the WG session at IETF-77.

We will again work within the de=
adlines for BoFs:
http://www.ietf.org/meeting/cutoff-dates-=
2010.html#IETF77

This provides enough time to dispatch topics prior to the meeting asappropriate - e.g., mini-bofs, official bofs, other WGs, new WGs,
maili=
ng lists, etc. Thus, allowing us to have more focused and
constructive d=
iscussions on a smaller set of topics prior to the WG

session.

Jan 18th, 2010. Cutoff date to notify the chairs/DISPAT=
CH WG of plans to
submit a proposal.
--------------------------------=
----------------------------------------
--------------------

This will help folks with similar topics to work together before the
mee=
ting. If a preliminary charter proposal is available at this point,
plea=
se include it.

Note: Jan 25th is BoF proposal request date.

Feb 1st, 2010. Cutoff for charter proposals for topics.
------------=
--------------------------------------------------

A charter proposa=
l must consist of a minimum of a problem statement and
at least one mile=
stone/deliverable. This deadline will allow time for

consideration of proposals that could potentially be "dispatched"=
 prior
to the WG session.

Feb 8th, 2010. Topics that are to b=
e the focus of IETF-77 are announced.
[AD BoF approval date]
--------=
----------------------------------------------------------------

The idea here is to focus the discussion over the weeks preceding
IE=
TF-77 on these main topics, noting that any new or updates to any
docume=
nts are due 3-4 weeks later. =A0This will ensure we have
constructive di=
scussions before the meeting and are actually able to

determine consensus as to where work should be progressed (e.g.,
separat=
e BoF, a new WG, an existing WG, individual document, etc.) at
IETF-77. =
Note, that the exact disposition for a topic may (per the usual
process)=
 require follow-up and confirmation by the ADS and/or IESG

(e.g., for a new WG, Bof, individually sponsored document, etc.) or withanother WG to ensure agreement with the DISPATCH WG consensus for the
t=
opic.

March 1st, 2010. -00 draft deadline.
----------------------=
-------------

March 8th, 2010. Draft deadline.
--------------------------------

As discussed previously, the intention is not necessarily to precl=
ude
folks submitting documents on other topics, however, it is very unli=
kely

there would be agenda time allocated to documents/topics submitted afterthe deadlines. We can include one or two slides on these topics in the
=
DISPATCH WG chair charts so that the authors can gather other interested
parties to contribute to the work.

Regards,
Mary and Gonzalo
D=
ISPATCH WG co-chairs

_______________________________________=
________
dispatch mailing list
d=
ispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch
=

--0016e64135b22bf070047e2a3d15--

From R.Jesske@telekom.de  Wed Jan 27 23:16:09 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C273A69F1 for ; Wed, 27 Jan 2010 23:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.648
X-Spam-Level: 
X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lNA5sqqE-ee for ; Wed, 27 Jan 2010 23:16:07 -0800 (PST)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 18E803A6917 for ; Wed, 27 Jan 2010 23:16:06 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8BAH7IYEsKl7So/2dsb2JhbAAI12oChDoE
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 28 Jan 2010 08:16:11 +0100
Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 08:16:10 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9FE9.C4718A76"
Date: Thu, 28 Jan 2010 08:16:11 +0100
Message-ID: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
thread-index: Acqf6cQbqABRpT7zRbqNP1YkjuQ6yQ==
From: 
To: 
X-OriginalArrivalTime: 28 Jan 2010 07:16:10.0735 (UTC) FILETIME=[C48E7FF0:01CA9FE9]
Subject: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 07:16:09 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA9FE9.C4718A76
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,
The discussion at the last IETF meeting due to the proposal to use the =
reason header within responses where controversial.

I would like to start the discussion on mentioned concerns.

One concern was that we define an new encapsulation mechanism for ISUP =
elements in parallel to SIP-T.

The Reason header itself is a SIP generic Header defined in RFC3326.

The syntax allows to put in a SIP Response code and/or an ISUP Q.850 =
Cause Code.

As many times mentioned before RFC 3326 (The Reason Header Field for the =
Session Initiation Protocol (SIP)) defines the following.

   Initially, the Reason header field defined here appears to be most
   useful for BYE and CANCEL requests, but it can appear in any request
   within a dialog, in any CANCEL request and in any response whose
   status code explicitly allows the presence of this header field.

   Note that the Reason header field is usually not needed in responses
   because the status code and the reason phrase already provide
   sufficient information.

   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

At that time where RFC3326 was written it was not assumed that a Reason =
in a response is usually not needed but it does not restrict the use of =
the Reason header within responses. It allows the use of the Reason =
header if the status code allows it.

That was the reasoning for writing this draft to allow the Reason header =
within Responses and it is not an new encapsulation mechanism.

Kind regards
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Technical Engineering Center
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany
+49 6151 628-2766 (Phone)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobile)
E-Mail: r.jesske@telekom.de
www.telekom.com

Life is for sharing.

Deutsche Telekom Netzproduktion GmbH
Supervisory Board: Dr. Steffen Roehn (Chairman)
Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, =
Klaus Peren
Commercial register: Local court Bonn HRB 14190
Registered office: Bonn
VAT identification no. DE 814645262

------_=_NextPart_001_01CA9FE9.C4718A76
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use =
Reason in Responses

Dear all,

The discussion at the last IETF =
meeting due to the proposal to use the reason header within responses =
where controversial.

I would like to start the discussion on =
mentioned concerns.

One concern was that we define an new =
encapsulation mechanism for ISUP elements in parallel to SIP-T.

The Reason header itself is a SIP =
generic Header defined in RFC3326.

The syntax allows to put in a SIP =
Response code and/or an ISUP Q.850 Cause Code.

As many times mentioned before RFC 3326 =
(The =
Reason Header Field for the Session Initiation Protocol =
(SIP)) =
defines the following.

   =
Initially, the Reason header field defined here appears to be =
most

   useful for BYE and CANCEL requests, but it can appear =
in any request

   within a dialog, in any CANCEL request and in any =
response whose

   status code explicitly allows the presence of this =
header field.

   =
Note that the Reason header field is usually not needed in =
responses

   because the status code and the reason phrase already =
provide

   sufficient information.

   =
Clients and servers are free to ignore this header field.  It has =
no

   impact on protocol processing.

At that time where =
RFC3326 was written it was not assumed that a Reason in a response is =
usually not needed but it does not restrict the use of the Reason header =
within responses. It allows the use of the Reason header if the status =
code allows it.

That was the =
reasoning for writing this draft to allow the Reason header within =
Responses and it is not an new encapsulation =
mechanism.

Kind =
regards

Roland =
Jesske

Deutsche Telekom Netzproduktion GmbH

Technical Engineering Center

Roland Jesske

Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, =
Germany

+49 6151 628-2766 (Phone)

+49 521 9210-3753  (Fax)

+49 171 8618-445  (Mobile)

E-Mail: r.jesske@telekom.de

www.telekom.com

Life is for sharing.

Deutsche Telekom Netzproduktion GmbH

Supervisory Board: Dr. Steffen Roehn =
(Chairman)

Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), =
Albert Matheis, Klaus Peren

Commercial register: Local court Bonn HRB =
14190

Registered office: Bonn

VAT identification no. DE 814645262

------_=_NextPart_001_01CA9FE9.C4718A76--

From R.Jesske@telekom.de  Thu Jan 28 02:42:38 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1A93A6858 for ; Thu, 28 Jan 2010 02:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7DfLaNm8qzE for ; Thu, 28 Jan 2010 02:42:36 -0800 (PST)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6E7A93A68C5 for ; Thu, 28 Jan 2010 02:42:35 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8BAF/3YEsKl7Sm/2dsb2JhbAAI2HkChDoE
Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 28 Jan 2010 11:40:07 +0100
Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 11:40:05 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA006.412079C6"
Date: Thu, 28 Jan 2010 11:38:38 +0100
Message-ID: <9886E5FCA6D76549A3011068483A4BD4058CE47C@S4DE8PSAAQB.mitte.t-com.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Interworking of Responses
thread-index: AcqgBgyVUCHJIrUbTEOW8Ap4NF2yqQ==
From: 
To: 
X-OriginalArrivalTime: 28 Jan 2010 10:40:05.0974 (UTC) FILETIME=[4153CF60:01CAA006]
Subject: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Interworking of Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 10:42:38 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAA006.412079C6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,
The discussion about the use of the Reason header within responses was =
triggered by the used case where ISUP-SIP-ISUP traversal will happen =
without using SIP-T.
During the discussion at the last IETF meeting it was asked how the pure =
mapping of ISUP Cause to SIP Response and back will cause the ISUP =
network. Here is the consideration of this issue.

The case where a call will be released within a pure ISUP network it =
will cause a announcement based on  the ISUP Release Cause.=20
When the call instead has to traverse a SIP network the ISUP cause will =
change in most of the cases and the related announcement.=20

The figure below shows the principle of such a call ISUP-SIP-ISUP.

 Phone     PTSN SWITCH            Gateway A          Gateway B           =
  B
  =20
 |               |                   |                  |                =
  |
 |  Setup Message|                   |                  |                =
  |
 |  Phone        |        IAM        |                  |                =
  |
 |-------------->|------------------>|     INVITE       |                =
  |
 |               |                   |----------------->|      IAM       =
  |
 |               |                   |     100 Trying   =
|----------------->|
 |               |                   |<-----------------|    100 Trying  =
  |
 |               |                   |   403 Forbidden  |                =
  |
 |               |                   |  Reason Q850 #87 |  REL Cause #87 =
  |
 |  play         |   REL Cause #87   |                  =
|<-----------------|
 |  Announcement |                   |<-----------------|                =
  |
 |<--------------|<----------------- |                  |                =
  |
 |               |                   |                  |                =
  |
 |               |                   |                  |                =
  |
 |               |                   |                  |                =
  |
=20

The table below shows now the mappings of the Cause and the relating =
announcements
Problem is that the mapping regarding RFC 3398 will result in the =
following table.

EXAMPLE:=20
The Call is released with Cause 27 from the user B
This Cause will normally trigger an announcement B.

Due to the rules in ISUP the Announcement/Tone is put into the media =
path at the originating switch.

So the first gateway maps (RFC3398) the ISUP RELEASE message with Cause =
27 to a SIP response 502 Bad Gateway

Now mapping back (RFC3398) to ISUP the release cause 38 will be taken =
and this Release Cause will trigger an congestion tone.

The following table shows now the mapping for our PSTN network and the =
corresponding announcements. =20

         Mapping ISUP SIP  GW-B               Mapping SIP ISUP GW-A
         ------------------------>             ------------------>=20
 =20
ISUP  Tone or                                         ISUP
CAUSE Announcement	       SIP Response                 CAUSE	Tone or =
Announcement

 1	ANNOUNC. A	       404 Not Found	             1	ANNOUNC. A
*2	ANNOUNC. C	       404 Not found	             1	ANNOUNC. A
 3	ANNOUNC. A   	 404 Not found	             1	ANNOUNC. A
 16	Congestion tone    --- (*)		=20
 17	Busy Tone	       486 Busy here	            17	Busy tone
*18	Busy Tone     	 408 Request Timeout	      102	Congestion tone
 19	Busy Tone     	 480 Temporarily unavailable  18	Busy tone
*20	ANNOUNC. B	       480 Temporarily unavailable  18	Busy tone
 21	ANNOUNC. B	       403 Forbidden (+)	      21	ANNOUNC. B
 22	ANNOUNC. A	       410 Gone	                  22	ANNOUNC. A
*23	Congestion tone    410 Gone	                  22	ANNOUNC. A
*26	Congestion tone    404 Not Found (=3D)	       1	ANNOUNC. A

*27	ANNOUNC. B	       502 Bad Gateway	            38	Congestion tone

*28	Congestion tone	 484 Address incomplete	      28	Congestion tone
 29	ANNOUNC. D          501 Not implemented	      79	ANNOUNC. D
*31	Congestion tone    480 Temporarily unavailable	18	Busy tone
 34	Congestion tone    503 Service unavailable	41	Congestion tone=20
 38	Congestion tone    503 Service unavailable	41	Congestion tone
 41	Congestion tone	 503 Service unavailable      41	Congestion tone
*42	ANNOUNC. B	       503 Service unavailable      41	Congestion tone
 47	Congestion tone	 503 Service unavailable      41	Congestion tone
*55	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
*57	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
 58	Congestion tone    503 Service unavailable      41	Congestion tone
*65	ANNOUNC. D	       488 Not Acceptable Here      127	Congestion tone  =
(**) =20
*70	ANNOUNC. D	       488 Not Acceptable Here      127	Congestion tone  =
(**)=20
 79	ANNOUNC. D	       501 Not implemented	      79	ANNOUNC. D
*87	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
*88	ANNOUNC. D	       503 Service unavailable      41	Congestion tone
 102	Congestion tone    504 Gateway timeout	      102	Congestion tone
*111	ANNOUNC. D	       500 Server internal error    41	Congestion tone
 127	Congestion tone    500 Server internal error    41	Congestion tone

(*) Announcement change due to passing the SIP domain
(**)No mapping in RFC 3398 described in the field 127 is used then as =
default mapping.

Half of the mapped Responses will end in a ISUP Cause that will initiate =
an other announcement than intended from the originator of the Release =
cause.

That is why a mapping of a Release Cause into an Reason Header and back =
to the ISUP cause will help in an easy using an existing SIP header that =
is intended to carry ISUP causes.

Kind regards
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Technical Engineering Center
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany
+49 6151 628-2766 (Phone)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobile)
E-Mail: r.jesske@telekom.de
www.telekom.com =20

Life is for sharing.

Deutsche Telekom Netzproduktion GmbH
Supervisory Board: Dr. Steffen Roehn (Chairman)
Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, =
Klaus Peren
Commercial register: Local court Bonn HRB 14190
Registered office: Bonn
VAT identification no. DE 814645262

------_=_NextPart_001_01CAA006.412079C6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- =
Interworking of Responses

Dear all,

The discussion about the use of =
the Reason header within responses was triggered by the used case where =
ISUP-SIP-ISUP traversal will happen without using SIP-T.

During the discussion at the last =
IETF meeting it was asked how the pure mapping of ISUP Cause to SIP =
Response and back will cause the ISUP network. Here is the consideration =
of this issue.

The case where a call will be =
released within a pure ISUP network it will cause a announcement based =
on  the ISUP Release Cause. 

When the call instead has to =
traverse a SIP network the ISUP cause will change in most of the cases =
and the related announcement. 

The figure below shows the =
principle of such a call ISUP-SIP-ISUP.

 Phone     PTSN =
SWITCH            =
Gateway A          Gateway B             B

 |            &=
nbsp;  =
|            =
       =
|            =
      =
|            =
      |

 |  =
Setup Message|                   =
|            =
      =
|            =
      |

 |  =
Phone        |        =
IAM        =
|            =
      =
|            =
      |

 |-------------->|------------------>|     =
INVITE       =
|            =
      |

 |   =
            =
|            =
       =
|----------------->|      =
IAM         |

 |        =
       =
|            =
       |     100 =
Trying   |----------------->|

 |   =
            =
|            =
       =
|<-----------------|    100 Trying    =
|

 |               =
|            =
       |   403 Forbidden  =
|            =
      |

 |               =
|            =
       |  Reason Q850 #87 |  REL =
Cause #87   |

 |  =
play         |   REL Cause =
#87   =
|            =
      |<-----------------|

 |  =
Announcement |           &=
nbsp;       =
|<-----------------|        &n=
bsp;         |

 |<--------------|<----------------- =
|            =
      =
|            =
      |

 |   =
          <=
FONT SIZE=3D2 FACE=3D"Courier New">  =
|            =
       =
|            =
      =
|            =
      |

 |            &=
nbsp;  =
|            =
       =
|            =
      =
|            =
      |

 |    =
           =
|            =
       =
|            =
      =
|            =
      |

The table below shows now the =
mappings of the Cause and the relating announcements

Problem is that the mapping =
regarding RFC 3398 will result in the following table.

EXAMPLE: 

The Call is released with Cause =
27 from the user B

This Cause will normally trigger =
an announcement B.

Due to the rules in ISUP the =
Announcement/Tone is put into the media path at the originating =
switch.

So the first gateway maps =
(RFC3398) the ISUP RELEASE message with Cause 27 to a SIP response 502 =
Bad Gateway

Now mapping back (RFC3398) to =
ISUP the release cause 38 will be taken and this Release Cause will =
trigger an congestion tone.

The following table shows now the =
mapping for our PSTN network and the corresponding announcements.  =

         Mapping ISUP =
SIP  =
GW-B           &nb=
sp;   Mapping SIP ISUP GW-A

         =
------------------------>       &nb=
sp;     ------------------> 

ISUP  Tone =
or            =
;            =
            &=
nbsp;    ISUP

CAUSE =
Announcement      =
       SIP =
Response           =
;      =
CAUSE       Tone or Announcement

 1      ANNOUNC. =
A             404 =
Not Found    =
             =
1  ANNOUNC. A

*2      =
ANNOUNC. C      =
       404 Not found    =
             =
1  ANNOUNC. A

 3      ANNOUNC. A   =
    404 Not found  =
             =
1  ANNOUNC. A

 16     =
Congestion tone    --- (*)      =

 17     =
Busy Tone       =
       486 Busy here    =
            =
17  Busy tone

*18     Busy =
Tone        408 Request =
Timeout          =
102       Congestion tone

 19     =
Busy Tone        480 Temporarily =
unavailable  18        Busy =
tone

*20     =
ANNOUNC. B      =
       480 Temporarily unavailable  =
18  Busy tone

 21     =
ANNOUNC. B      =
       403 Forbidden =
(+)        =
      =
21        ANNOUNC. B

 22     =
ANNOUNC. A      =
       410 Gone =
            &=
nbsp;     22    ANNOUNC. A

*23     =
Congestion tone    410 Gone     =
            &=
nbsp;     22    ANNOUNC. A

*26     =
Congestion tone    404 Not Found (=3D)    =
       =
1        ANNOUNC. A

*27     =
ANNOUNC. B      =
       502 Bad Gateway  =
            =
38  Congestion tone

*28     =
Congestion tone  484 Address incomplete =
      =
28        Congestion tone

 29     =
ANNOUNC. D          501 Not =
implemented       =
79        ANNOUNC. D

*31     =
Congestion tone    480 Temporarily unavailable  =
18      Busy tone

 34     =
Congestion tone    503 Service =
unavailable      =
41      Congestion tone 

 38     =
Congestion tone    503 Service =
unavailable      =
41      Congestion tone

 41     =
Congestion tone  503 Service =
unavailable      =
41        Congestion tone

*42     =
ANNOUNC. B      =
       503 Service =
unavailable      41  Congestion =
tone

 47     =
Congestion tone  503 Service =
unavailable      =
41        Congestion tone

*55     =
ANNOUNC. D      =
       403 Forbidden    =
            =
21  ANNOUNC. B

*57     =
ANNOUNC. D      =
       403 Forbidden    =
            =
21  ANNOUNC. B

 58     =
Congestion tone    503 Service =
unavailable      =
41      Congestion tone

*65     =
ANNOUNC. D      =
       488 Not Acceptable =
Here      127 Congestion tone  (**)  =

*70     =
ANNOUNC. D      =
       488 Not Acceptable =
Here      127 Congestion tone  (**) =

 79     =
ANNOUNC. D      =
       501 Not =
implemented            =
79        ANNOUNC. D

*87     =
ANNOUNC. D      =
       403 Forbidden    =
            =
21  ANNOUNC. B

*88     =
ANNOUNC. D      =
       503 Service =
unavailable      41  Congestion =
tone

 102    =
Congestion tone    504 Gateway timeout  =
      102       =
Congestion tone

*111    ANNOUNC. =
D             500 =
Server internal error    41  Congestion tone

 127    =
Congestion tone    500 Server internal =
error    41      Congestion =
tone

(*) Announcement change due to =
passing the SIP domain

(**)No mapping in RFC 3398 =
described in the field 127 is used then as default mapping.

Half of the mapped Responses will =
end in a ISUP Cause that will initiate an other announcement than =
intended from the originator of the Release cause.

That is why a mapping of a =
Release Cause into an Reason Header and back to the ISUP cause will help =
in an easy using an existing SIP header that is intended to carry ISUP =
causes.

Kind =
regards

Roland =
Jesske

Deutsche Telekom Netzproduktion GmbH

Technical Engineering Center

Roland Jesske

Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, =
Germany

+49 6151 628-2766 (Phone)

+49 521 9210-3753  (Fax)

+49 171 8618-445  (Mobile)

E-Mail: r.jesske@telekom.de

www.telekom.com  

Life is for sharing.

Deutsche Telekom Netzproduktion GmbH

Supervisory Board: Dr. Steffen Roehn =
(Chairman)

Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), =
Albert Matheis, Klaus Peren

Commercial register: Local court Bonn HRB =
14190

Registered office: Bonn

VAT identification no. DE 814645262

------_=_NextPart_001_01CAA006.412079C6--

From john.elwell@siemens-enterprise.com  Thu Jan 28 06:40:01 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942153A685A for ; Thu, 28 Jan 2010 06:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okZKmyUb+-RJ for ; Thu, 28 Jan 2010 06:40:00 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BB32F3A67AC for ; Thu, 28 Jan 2010 06:39:59 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-700966; Thu, 28 Jan 2010 15:40:16 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id C8E101EB82B0; Thu, 28 Jan 2010 15:40:16 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jan 2010 15:40:16 +0100
From: "Elwell, John" 
To: "R.Jesske@telekom.de" , "dispatch@ietf.org" 
Date: Thu, 28 Jan 2010 15:40:15 +0100
Thread-Topic: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
Thread-Index: Acqf6cQbqABRpT7zRbqNP1YkjuQ6yQAPOZXw
Message-ID: 
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 14:40:01 -0000

I think the long discussion we had at IETF#76 was out of all proportion to =
the magnitude of the proposed change.

The Reason header field is a rather ugly solution to a problem brought abou=
t by incompatible sets of reason codes in these two different protocols. Bu=
t given that we have the Reason header field, and that it is already allowe=
d in some requests and responses, I don't really see the harm in opening th=
e door to use in other responses. We could put some caveats around it, to t=
ry to discourage inappropriate uses. However, somebody implementing primari=
ly for a SIP environment is unlikely to use (or abuse) this header field, w=
hich I would expect to be used only where really needed.

Why can't we just let the people who want this get on and do it, and save o=
ur precious discussion time for more important topics?

John=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
> Sent: 28 January 2010 07:16
> To: dispatch@ietf.org
> Subject: [dispatch] ISSUES on=20
> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in=20
> Responses
>=20
> Dear all,=20
> The discussion at the last IETF meeting due to the proposal=20
> to use the reason header within responses where controversial.
>=20
> I would like to start the discussion on mentioned concerns.=20
>=20
> One concern was that we define an new encapsulation mechanism=20
> for ISUP elements in parallel to SIP-T.=20
>=20
> The Reason header itself is a SIP generic Header defined in RFC3326.=20
>=20
> The syntax allows to put in a SIP Response code and/or an=20
> ISUP Q.850 Cause Code.=20
>=20
> As many times mentioned before RFC 3326 (The Reason Header=20
> Field for the Session Initiation Protocol (SIP)) defines the=20
> following.
>=20
>    Initially, the Reason header field defined here appears to be most=20
>    useful for BYE and CANCEL requests, but it can appear in=20
> any request=20
>    within a dialog, in any CANCEL request and in any response whose=20
>    status code explicitly allows the presence of this header field.=20
>=20
>    Note that the Reason header field is usually not needed in=20
> responses=20
>    because the status code and the reason phrase already provide=20
>    sufficient information.=20
>=20
>    Clients and servers are free to ignore this header field. =20
> It has no=20
>    impact on protocol processing.=20
>=20
> At that time where RFC3326 was written it was not assumed=20
> that a Reason in a response is usually not needed but it does=20
> not restrict the use of the Reason header within responses.=20
> It allows the use of the Reason header if the status code allows it.
>=20
> That was the reasoning for writing this draft to allow the=20
> Reason header within Responses and it is not an new=20
> encapsulation mechanism.
>=20
> Kind regards=20
> Roland Jesske=20
>=20
>=20
> Deutsche Telekom Netzproduktion GmbH=20
> Technical Engineering Center=20
> Roland Jesske=20
> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany=20
> +49 6151 628-2766 (Phone)=20
> +49 521 9210-3753  (Fax)=20
> +49 171 8618-445  (Mobile)=20
> E-Mail: r.jesske@telekom.de  =20
> www.telekom.com  =20
>=20
> Life is for sharing.=20
>=20
> Deutsche Telekom Netzproduktion GmbH=20
> Supervisory Board: Dr. Steffen Roehn (Chairman)=20
> Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert=20
> Matheis, Klaus Peren=20
> Commercial register: Local court Bonn HRB 14190=20
> Registered office: Bonn=20
> VAT identification no. DE 814645262=20
>=20
> =

From pkyzivat@cisco.com  Thu Jan 28 07:08:30 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D40E3A6874 for ; Thu, 28 Jan 2010 07:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level: 
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNJfly6p5349 for ; Thu, 28 Jan 2010 07:08:29 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0AB2D3A67D1 for ; Thu, 28 Jan 2010 07:08:29 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALY2YUutJV2Y/2dsb2JhbADDYZcphDwE
X-IronPort-AV: E=Sophos;i="4.49,360,1262563200"; d="scan'208";a="293284627"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 28 Jan 2010 15:08:46 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0SF8kaF020462;  Thu, 28 Jan 2010 15:08:46 GMT
Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 09:08:46 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 09:08:46 -0600
Message-ID: <4B61A87D.8070000@cisco.com>
Date: Thu, 28 Jan 2010 10:08:45 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Elwell, John" 
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 28 Jan 2010 15:08:46.0264 (UTC) FILETIME=[C9C4DB80:01CAA02B]
Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" 
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 15:08:30 -0000

Elwell, John wrote:
> I think the long discussion we had at IETF#76 was out of all proportion to the magnitude of the proposed change.
> 
> The Reason header field is a rather ugly solution to a problem brought about by incompatible sets of reason codes in these two different protocols. But given that we have the Reason header field, and that it is already allowed in some requests and responses, I don't really see the harm in opening the door to use in other responses. We could put some caveats around it, to try to discourage inappropriate uses. However, somebody implementing primarily for a SIP environment is unlikely to use (or abuse) this header field, which I would expect to be used only where really needed.
> 
> Why can't we just let the people who want this get on and do it, and save our precious discussion time for more important topics?

I wasn't there for the discussion. :-(

I generally agree with John that this is pretty benign.

The one concern I have is if somebody implements in such a way that 
these reason codes must be in responses for proper operation, thus 
making native SIP devices understand and populate this data to get good 
results.

	Thanks,
	Paul

> John 
> 
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org 
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
>> Sent: 28 January 2010 07:16
>> To: dispatch@ietf.org
>> Subject: [dispatch] ISSUES on 
>> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in 
>> Responses
>>
>> Dear all, 
>> The discussion at the last IETF meeting due to the proposal 
>> to use the reason header within responses where controversial.
>>
>> I would like to start the discussion on mentioned concerns. 
>>
>> One concern was that we define an new encapsulation mechanism 
>> for ISUP elements in parallel to SIP-T. 
>>
>> The Reason header itself is a SIP generic Header defined in RFC3326. 
>>
>> The syntax allows to put in a SIP Response code and/or an 
>> ISUP Q.850 Cause Code. 
>>
>> As many times mentioned before RFC 3326 (The Reason Header 
>> Field for the Session Initiation Protocol (SIP)) defines the 
>> following.
>>
>>    Initially, the Reason header field defined here appears to be most 
>>    useful for BYE and CANCEL requests, but it can appear in 
>> any request 
>>    within a dialog, in any CANCEL request and in any response whose 
>>    status code explicitly allows the presence of this header field. 
>>
>>    Note that the Reason header field is usually not needed in 
>> responses 
>>    because the status code and the reason phrase already provide 
>>    sufficient information. 
>>
>>    Clients and servers are free to ignore this header field.  
>> It has no 
>>    impact on protocol processing. 
>>
>> At that time where RFC3326 was written it was not assumed 
>> that a Reason in a response is usually not needed but it does 
>> not restrict the use of the Reason header within responses. 
>> It allows the use of the Reason header if the status code allows it.
>>
>> That was the reasoning for writing this draft to allow the 
>> Reason header within Responses and it is not an new 
>> encapsulation mechanism.
>>
>> Kind regards 
>> Roland Jesske 
>>
>>
>> Deutsche Telekom Netzproduktion GmbH 
>> Technical Engineering Center 
>> Roland Jesske 
>> Heinrich-Hertz-Stra�e 3-7, 64295 Darmstadt, Germany 
>> +49 6151 628-2766 (Phone) 
>> +49 521 9210-3753  (Fax) 
>> +49 171 8618-445  (Mobile) 
>> E-Mail: r.jesske@telekom.de   
>> www.telekom.com   
>>
>> Life is for sharing. 
>>
>> Deutsche Telekom Netzproduktion GmbH 
>> Supervisory Board: Dr. Steffen Roehn (Chairman) 
>> Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert 
>> Matheis, Klaus Peren 
>> Commercial register: Local court Bonn HRB 14190 
>> Registered office: Bonn 
>> VAT identification no. DE 814645262 
>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From dworley@avaya.com  Thu Jan 28 10:45:18 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8565C28C0FE for ; Thu, 28 Jan 2010 10:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy7QcjdRZxpY for ; Thu, 28 Jan 2010 10:45:17 -0800 (PST)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id B803028C100 for ; Thu, 28 Jan 2010 10:45:16 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,361,1262581200";  d="scan'208";a="1796465"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 Jan 2010 13:45:34 -0500
Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2010 13:45:33 -0500
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0SIjCE11218; Thu, 28 Jan 2010 18:45:12 GMT
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0SIj9E26142; Thu, 28 Jan 2010 18:45:09 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:45:07 -0500
From: "Dale Worley" 
To: "Scott Lawrence" 
In-Reply-To: <1260708093.30342.131.camel@scott>
References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> <3623C7AE-6491-4D5A-8150-FC2A3E420A91@ntt-at.com> <1260708093.30342.131.camel@scott>
Content-Type: text/plain
Organization: Nortel Networks
Date: Thu, 28 Jan 2010 13:45:07 -0500
Message-Id: <1264704307.5746.62.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jan 2010 18:45:07.0522 (UTC) FILETIME=[0333A220:01CAA04A]
X-Mailman-Approved-At: Thu, 28 Jan 2010 10:59:55 -0800
Cc: DISPATCH 
Subject: Re: [dispatch] New Version Notification for	draft-worley-service-example-04
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 18:45:18 -0000

On Sun, 2009-12-13 at 07:41 -0500, Scott Lawrence wrote:
> The draft doesn't go into much detail on the specifics of the advantages
> over the method described in 5359 (and other methods in use); it could
> probably use some expansion in that area because the advantages are
> real.

The current text is:

   This technique for providing music-on-hold has advantages over other
   methods now in use:

   1.  The original dialog is not transferred to another UA, so the
       "remote endpoint URI" displayed by the remote endpoint's user
       interface and dialog event package[dialog-event] does not change
       during the call.[service-examples]

   2.  Compared to [service-examples], this method does not require use
       of an out-of-dialog REFER, which is not otherwise used much in
       SIP and may not be handled correctly by authorization mechanisms.

   3.  The music-on-hold media are sent directly from the music-on-hold
       source to the remote UA, rather than being relayed through the
       executing UA.

   4.  The remote UA sees, in the incoming SDP, the address/port that
       the MOH source will send MOH media from, thus allowing it to
       render the media, even if it is filtering incoming media based on
       originating address as a media security measure.

   5.  The technique requires relatively simple manipulation of SDP, and
       in particular: (1) does not require a SIP element to modify
       unrelated SDP to be acceptable to be sent within an already
       established sequence of SDP (a problem with
       [service-examples-11]), and (2) does not require converting an
       SDP answer into an SDP offer (which was a problem with the -00
       version of this document, as well as with [service-examples-11]).

   6.  It complies with the payload type number rules.[offer-answer]

What do you think needs to be added or expanded?  In regard to RFC 5359
specifically, items 1 and 2 call out the improved behavior.

Dale

From dworley@avaya.com  Thu Jan 28 10:54:20 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66083A6907 for ; Thu, 28 Jan 2010 10:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7vjfhoNhu1w for ; Thu, 28 Jan 2010 10:54:20 -0800 (PST)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E61373A681F for ; Thu, 28 Jan 2010 10:54:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,362,1262581200";  d="scan'208";a="1796895"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 28 Jan 2010 13:54:38 -0500
Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2010 13:54:37 -0500
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0SIsGE14024 for ; Thu, 28 Jan 2010 18:54:16 GMT
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0SIsES15090 for ; Thu, 28 Jan 2010 18:54:14 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 13:54:13 -0500
From: "Dale Worley" 
To: "Rifaat Shekh-Yusef" 
In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C10021@zcarhxm2.corp.nortel.com>
References: <20091026005148.196193A68EF@core3.amsl.com> <1256581091.3748.9.camel@khone.us.nortel.com> <90243C8A881F8D419D855264D9636F3A02C10021@zcarhxm2.corp.nortel.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Thu, 28 Jan 2010 13:54:13 -0500
Message-Id: <1264704853.5746.66.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jan 2010 18:54:13.0666 (UTC) FILETIME=[48BA9820:01CAA04B]
X-Mailman-Approved-At: Thu, 28 Jan 2010 10:59:55 -0800
Cc: DISPATCH 
Subject: Re: [dispatch] New Version Notification	fordraft-worley-service-example-04
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2010 18:54:21 -0000

On Thu, 2009-12-10 at 15:20 -0500, Shekh-Yusef, Rifaat (BVW:9T16) wrote:
> Question about section 2.8, Dialog/Session Timers:
> 
> You described two approaches to this issue:
> 
> 1. The executing UA supports timer per dialog
> 2. The executing UA forwards the refresh requests to refresh both
> dialogs
> 
> What is the advantage of the second approach over the first one?
> 
> The second approach might be a little challenging.
> For example, think about the scenario where the executing UA has
> established a dialog with the other party with SE: 3600, but the Min-SE
> of the Music Source is 7200. You might have a problem if the Music
> Source is the refresher.

Yes, it does look like it would be difficult to arrange for session
timer updates to be passed through and to be handled correctly in all
cases.  I'm no expert on RFC 4028, and it looks like it is possible to
change the refresh interval during a dialog.  But getting the logic
correct would probably be much harder than having the executing UA
handle session timers in the default way on each of the two dialogs.

Dale

From R.Jesske@telekom.de  Thu Jan 28 23:36:49 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499B33A6970 for ; Thu, 28 Jan 2010 23:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbpaXCs0FKth for ; Thu, 28 Jan 2010 23:36:48 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 59E573A6966 for ; Thu, 28 Jan 2010 23:36:45 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYBAAsdYksKl7So/2dsb2JhbAAI2nGEQAQ
Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 29 Jan 2010 08:36:59 +0100
Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jan 2010 08:36:59 +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
Date: Fri, 29 Jan 2010 08:37:02 +0100
Message-ID: <9886E5FCA6D76549A3011068483A4BD4058CE7C9@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <4B61A87D.8070000@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
thread-topic: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
thread-index: AcqgK9BAJdCEj4TJQ8yIz5tpIJE8xgAiOmSQ
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> <4B61A87D.8070000@cisco.com>
From: 
To: , 
X-OriginalArrivalTime: 29 Jan 2010 07:36:59.0508 (UTC) FILETIME=[D74BE340:01CAA0B5]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 07:36:49 -0000

Hi Paul,
That was never the intend of the draft.

It is already mentioned within RFC 3326:
   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

And we can write something in addition within the draft to clarify that. =

It is NOT the scope that native SIP devices either populate nor act on a =
received Reason with a Q.850 cause.

Kind regards
Roland Jesske

-----Urspr=FCngliche Nachricht-----
Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im =
Auftrag von Paul Kyzivat
Gesendet: Donnerstag, 28. Januar 2010 16:09
An: Elwell, John
Cc: dispatch@ietf.org; Jesske, Roland
Betreff: Re: [dispatch] ISSUES on =
draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

Elwell, John wrote:
> I think the long discussion we had at IETF#76 was out of all =
proportion to the magnitude of the proposed change.
>=20
> The Reason header field is a rather ugly solution to a problem brought =
about by incompatible sets of reason codes in these two different =
protocols. But given that we have the Reason header field, and that it =
is already allowed in some requests and responses, I don't really see =
the harm in opening the door to use in other responses. We could put =
some caveats around it, to try to discourage inappropriate uses. =
However, somebody implementing primarily for a SIP environment is =
unlikely to use (or abuse) this header field, which I would expect to be =
used only where really needed.
>=20
> Why can't we just let the people who want this get on and do it, and =
save our precious discussion time for more important topics?

I wasn't there for the discussion. :-(

I generally agree with John that this is pretty benign.

The one concern I have is if somebody implements in such a way that=20
these reason codes must be in responses for proper operation, thus=20
making native SIP devices understand and populate this data to get good=20
results.

	Thanks,
	Paul

> John=20
>=20
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org=20
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
>> Sent: 28 January 2010 07:16
>> To: dispatch@ietf.org
>> Subject: [dispatch] ISSUES on=20
>> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in=20
>> Responses
>>
>> Dear all,=20
>> The discussion at the last IETF meeting due to the proposal=20
>> to use the reason header within responses where controversial.
>>
>> I would like to start the discussion on mentioned concerns.=20
>>
>> One concern was that we define an new encapsulation mechanism=20
>> for ISUP elements in parallel to SIP-T.=20
>>
>> The Reason header itself is a SIP generic Header defined in RFC3326.=20
>>
>> The syntax allows to put in a SIP Response code and/or an=20
>> ISUP Q.850 Cause Code.=20
>>
>> As many times mentioned before RFC 3326 (The Reason Header=20
>> Field for the Session Initiation Protocol (SIP)) defines the=20
>> following.
>>
>>    Initially, the Reason header field defined here appears to be most =

>>    useful for BYE and CANCEL requests, but it can appear in=20
>> any request=20
>>    within a dialog, in any CANCEL request and in any response whose=20
>>    status code explicitly allows the presence of this header field.=20
>>
>>    Note that the Reason header field is usually not needed in=20
>> responses=20
>>    because the status code and the reason phrase already provide=20
>>    sufficient information.=20
>>
>>    Clients and servers are free to ignore this header field. =20
>> It has no=20
>>    impact on protocol processing.=20
>>
>> At that time where RFC3326 was written it was not assumed=20
>> that a Reason in a response is usually not needed but it does=20
>> not restrict the use of the Reason header within responses.=20
>> It allows the use of the Reason header if the status code allows it.
>>
>> That was the reasoning for writing this draft to allow the=20
>> Reason header within Responses and it is not an new=20
>> encapsulation mechanism.
>>
>> Kind regards=20
>> Roland Jesske=20
>>
>>
>> Deutsche Telekom Netzproduktion GmbH=20
>> Technical Engineering Center=20
>> Roland Jesske=20
>> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany=20
>> +49 6151 628-2766 (Phone)=20
>> +49 521 9210-3753  (Fax)=20
>> +49 171 8618-445  (Mobile)=20
>> E-Mail: r.jesske@telekom.de  =20
>> www.telekom.com  =20
>>
>> Life is for sharing.=20
>>
>> Deutsche Telekom Netzproduktion GmbH=20
>> Supervisory Board: Dr. Steffen Roehn (Chairman)=20
>> Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert=20
>> Matheis, Klaus Peren=20
>> Commercial register: Local court Bonn HRB 14190=20
>> Registered office: Bonn=20
>> VAT identification no. DE 814645262=20
>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From ranjit@motorola.com  Fri Jan 29 00:55:37 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167053A67DD for ; Fri, 29 Jan 2010 00:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz52wRudxrh0 for ; Fri, 29 Jan 2010 00:55:36 -0800 (PST)
Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id E2F873A6452 for ; Fri, 29 Jan 2010 00:55:35 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-5.tower-128.messagelabs.com!1264755356!10095620!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [136.182.1.15]
Received: (qmail 15133 invoked from network); 29 Jan 2010 08:55:56 -0000
Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-5.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jan 2010 08:55:56 -0000
Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o0T8ttT9027349 for ; Fri, 29 Jan 2010 01:55:56 -0700 (MST)
Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o0T8tt2D021235 for ; Fri, 29 Jan 2010 02:55:55 -0600 (CST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o0T8tsmA021221 for ; Fri, 29 Jan 2010 02:55:54 -0600 (CST)
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: Fri, 29 Jan 2010 16:55:31 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A28B452@ZMY16EXM66.ds.mot.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Commentsrequestedon	draft-avasarala-dispatch-comm-div-notification
thread-index: Acqfczyz2U7KPqHRQHS3LaMRUH9MSABS1+Fw
References: <4B4F2403.7010200@ericsson.com><750BBC72E178114F9DC4872EBFF29A5B0A2456ED@ZMY16EXM66.ds.mot.com> 
From: "Avasarala Ranjit-A20990" 
To: "Cullen Jennings" , "DISPATCH" 
X-CFilter-Loop: Reflected
Subject: Re: [dispatch] Commentsrequestedon	draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 08:55:37 -0000

Hi Cullen

This draft is kind of straight forward as it proposes a SIP based XML
event package for reporting call diversions that occur in the network on
behalf of the subscribers that set call forwarding rules based on
various criteria like "incoming caller identity", "time-of-day", etc.

The IPR is essentially based on the proposed event package and the call
diversion notification service that gets triggered whenever a call gets
diverted on behalf of a subscriber. This service is standardized in 3GPP
TS 24.604. Now since 3GPP does not standardize XML packages, there was a
need to submit an IETF draft and get it standardized.  With this intent,
we proposed an informational I-D on communication diversion notification
event package.

So I really do not think there is any other alternate way to accomplish
what we are trying to propose in this I-D.=20

Comments welcome

Thanks

Regards
Ranjit

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Cullen Jennings
Sent: Wednesday, January 27, 2010 10:37 PM
To: DISPATCH
Subject: Re: [dispatch] Commentsrequestedon
draft-avasarala-dispatch-comm-div-notification

There are way to accomplish the same end goals as this draft suggests
using things that are very likely to predate RIM's IPR on the topic. For
example the ideas on using things similar to the dialog events package
or reporting events about call forking on proxies. I have a strong
preference for doing this in an IPR free way. I strongly encourage the
WG to explore alternative ways to solve these problems before deciding
what to do with this draft.=20

Cullen 

On Jan 15, 2010, at 2:49 AM, Avasarala Ranjit-A20990 wrote:

> Hi John
>=20
> Yes the notifications are generated for the AoR (contact) for which=20
> the diversion has occurred.
>=20
> So even though there could be multiple contacts registered for a=20
> particular AoR, if the diversion has occurred for a particular contact

> say alice at cellphone, then the notification information would go=20
> only to her cellphone and not to all registered contacts.  This way we

> would be limiting the number of notifications that are sent.
>=20
> In current call diversion service configurations, there is no concept=20
> of notifying subscribers when a particular call gets diverted based on

> a particular rule.
>=20
> Considering the case of Alice@example.com. Lets say Alice has setup a=20
> call diversion rule for her cellphone to divert all calls from a=20
> particular caller between 9 AM and 10 AM to her voicemail. But for=20
> some reason she could have wrongly configured the rule as 9 to 10 AM=20
> or could have put the caller id as wrong one. So it would be very=20
> difficult for her to manually spot this error by reviewing the=20
> complete set of call diversion services. So in order to facilitate=20
> Alice to effectively find out the error, a notification mechanism is
required.
>=20
> So here th URI for subscription would be the URI that is associated=20
> with diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
>=20
> Thanks
>=20
>=20
> Regards
> Ranjit
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20
> Behalf Of Elwell, John
> Sent: Friday, January 15, 2010 2:57 PM
> To: Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments requestedon=20
> draft-avasarala-dispatch-comm-div-notification
>=20
> I reserve judgement on how useful this would be. Concerning comments=20
> from Paul, I could imagine that the SUBSCRIBE request is addressed to=20
> the AOR URI for which notifications of diverted inbound requests are=20
> required, and that information from that AOR's domain proxy would be=20
> used as the basis for notifications. So the notifier would need=20
> somehow to be coupled to the domain proxy. This could certainly do=20
> with clarification.
>=20
> It is unclear to me how one would handle a subscription in the=20
> following circumstances. The subscription is to alice@example.com. At=20
> any given time, there might be several contacts registered against=20
> alice@example.com. According to relative priorities of those contacts,

> scripting rules at the proxy, caller preferences, etc., a given=20
> inbound request to Alice would go to one or more of those contacts. Is

> it the intention that those contacts that do not receive that inbound=20
> request would receive a notification within the context of this event
package?
> So if Alice's deskphone is one contact and her cellphone is another=20
> contact, if her current rules are for calls to go to her cellphone,=20
> her deskphone would receive notifications, and vice versa?
>=20
> Or is that out of scope? Is the intention to limit the scope to cases=20
> where an inbound communication is diverted away from the AOR
concerned?
>=20
> John
>=20
>=20
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
>> Sent: 14 January 2010 14:03
>> To: DISPATCH
>> Subject: [dispatch] Comments requested on=20
>> draft-avasarala-dispatch-comm-div-notification
>>=20
>> Hi,
>>=20
>> we would like to ask for comments on the following draft. Do you find

>> it useful? Do you think it should be published as an RFC?
>>=20
>> http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-n
>> otification-02
>>=20
>> Based on the comments received, we will talk to our ADs about this=20
>> piece of work.
>>=20
>> Thanks,
>>=20
>> Gonzalo
>> DISPATCH co-chair
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From christer.holmberg@ericsson.com  Fri Jan 29 02:20:19 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B92F3A69FA for ; Fri, 29 Jan 2010 02:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level: 
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.329,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZryli70GZHX for ; Fri, 29 Jan 2010 02:20:17 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 337613A6A01 for ; Fri, 29 Jan 2010 02:20:16 -0800 (PST)
X-AuditID: c1b4fb24-b7c64ae000005cb7-5b-4b62b67441fa
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 47.BC.23735.476B26B4; Fri, 29 Jan 2010 11:20:37 +0100 (CET)
Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 29 Jan 2010 11:20:36 +0100
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 29 Jan 2010 11:20:36 +0100
From: Christer Holmberg 
To: "'Elwell, John'" , "R.Jesske@telekom.de" , "dispatch@ietf.org" 
Date: Fri, 29 Jan 2010 11:20:35 +0100
Thread-Topic: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
Thread-Index: Acqf6cQbqABRpT7zRbqNP1YkjuQ6yQAPOZXwACl/kAA=
Message-ID: 
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 10:20:19 -0000

+1=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Elwell, John
Sent: 28. tammikuuta 2010 16:40
To: R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses=
-01 -- Use Reason in Responses

I think the long discussion we had at IETF#76 was out of all proportion to =
the magnitude of the proposed change.

The Reason header field is a rather ugly solution to a problem brought abou=
t by incompatible sets of reason codes in these two different protocols. Bu=
t given that we have the Reason header field, and that it is already allowe=
d in some requests and responses, I don't really see the harm in opening th=
e door to use in other responses. We could put some caveats around it, to t=
ry to discourage inappropriate uses. However, somebody implementing primari=
ly for a SIP environment is unlikely to use (or abuse) this header field, w=
hich I would expect to be used only where really needed.

Why can't we just let the people who want this get on and do it, and save o=
ur precious discussion time for more important topics?

John=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
> Sent: 28 January 2010 07:16
> To: dispatch@ietf.org
> Subject: [dispatch] ISSUES on
> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in=20
> Responses
>=20
> Dear all,
> The discussion at the last IETF meeting due to the proposal to use the=20
> reason header within responses where controversial.
>=20
> I would like to start the discussion on mentioned concerns.=20
>=20
> One concern was that we define an new encapsulation mechanism for ISUP=20
> elements in parallel to SIP-T.
>=20
> The Reason header itself is a SIP generic Header defined in RFC3326.=20
>=20
> The syntax allows to put in a SIP Response code and/or an ISUP Q.850=20
> Cause Code.
>=20
> As many times mentioned before RFC 3326 (The Reason Header Field for=20
> the Session Initiation Protocol (SIP)) defines the following.
>=20
>    Initially, the Reason header field defined here appears to be most=20
>    useful for BYE and CANCEL requests, but it can appear in any=20
> request
>    within a dialog, in any CANCEL request and in any response whose=20
>    status code explicitly allows the presence of this header field.=20
>=20
>    Note that the Reason header field is usually not needed in=20
> responses
>    because the status code and the reason phrase already provide=20
>    sufficient information.=20
>=20
>    Clients and servers are free to ignore this header field. =20
> It has no=20
>    impact on protocol processing.=20
>=20
> At that time where RFC3326 was written it was not assumed that a=20
> Reason in a response is usually not needed but it does not restrict=20
> the use of the Reason header within responses.
> It allows the use of the Reason header if the status code allows it.
>=20
> That was the reasoning for writing this draft to allow the Reason=20
> header within Responses and it is not an new encapsulation mechanism.
>=20
> Kind regards
> Roland Jesske
>=20
>=20
> Deutsche Telekom Netzproduktion GmbH
> Technical Engineering Center
> Roland Jesske
> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany
> +49 6151 628-2766 (Phone)
> +49 521 9210-3753  (Fax)
> +49 171 8618-445  (Mobile)
> E-Mail: r.jesske@telekom.de =20
> www.telekom.com 
>=20
> Life is for sharing.=20
>=20
> Deutsche Telekom Netzproduktion GmbH
> Supervisory Board: Dr. Steffen Roehn (Chairman) Managing Board: Dr.=20
> Bruno Jacobfeuerborn (Chairman), Albert Matheis, Klaus Peren=20
> Commercial register: Local court Bonn HRB 14190 Registered office:=20
> Bonn VAT identification no. DE 814645262
>=20
>=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From thomas.belling@nsn.com  Fri Jan 29 03:28:20 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51683A6887 for ; Fri, 29 Jan 2010 03:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqV2FfmDbQfJ for ; Fri, 29 Jan 2010 03:28:19 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DC1B33A6853 for ; Fri, 29 Jan 2010 03:28:18 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0TBSdwt025473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 12:28:39 +0100
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0TBScrU010338 for ; Fri, 29 Jan 2010 12:28:39 +0100
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jan 2010 12:28:38 +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
Date: Fri, 29 Jan 2010 12:28:36 +0100
Message-ID: <744A66DF31B5B34EA8B08BBD8187A7220127D451@DEMUEXC014.nsn-intra.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
Thread-Index: Acqf6cQbqABRpT7zRbqNP1YkjuQ6yQAPOZXwACl/kAAAAl0IQA==
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> 
From: "Belling, Thomas (NSN - DE/Munich)" 
To: 
X-OriginalArrivalTime: 29 Jan 2010 11:28:38.0012 (UTC) FILETIME=[33734BC0:01CAA0D6]
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01	-- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 11:28:20 -0000

+1=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of ext Christer Holmberg
Sent: Friday, January 29, 2010 11:21 AM
To: 'Elwell, John'; R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on =
draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

+1

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On =
Behalf Of Elwell, John
Sent: 28. tammikuuta 2010 16:40
To: R.Jesske@telekom.de; dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on =
draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

I think the long discussion we had at IETF#76 was out of all proportion =
to the magnitude of the proposed change.

The Reason header field is a rather ugly solution to a problem brought =
about by incompatible sets of reason codes in these two different =
protocols. But given that we have the Reason header field, and that it =
is already allowed in some requests and responses, I don't really see =
the harm in opening the door to use in other responses. We could put =
some caveats around it, to try to discourage inappropriate uses. =
However, somebody implementing primarily for a SIP environment is =
unlikely to use (or abuse) this header field, which I would expect to be =
used only where really needed.

Why can't we just let the people who want this get on and do it, and =
save our precious discussion time for more important topics?

John=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
> Sent: 28 January 2010 07:16
> To: dispatch@ietf.org
> Subject: [dispatch] ISSUES on
> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in=20
> Responses
>=20
> Dear all,
> The discussion at the last IETF meeting due to the proposal to use the =

> reason header within responses where controversial.
>=20
> I would like to start the discussion on mentioned concerns.=20
>=20
> One concern was that we define an new encapsulation mechanism for ISUP =

> elements in parallel to SIP-T.
>=20
> The Reason header itself is a SIP generic Header defined in RFC3326.=20
>=20
> The syntax allows to put in a SIP Response code and/or an ISUP Q.850=20
> Cause Code.
>=20
> As many times mentioned before RFC 3326 (The Reason Header Field for=20
> the Session Initiation Protocol (SIP)) defines the following.
>=20
>    Initially, the Reason header field defined here appears to be most=20
>    useful for BYE and CANCEL requests, but it can appear in any=20
> request
>    within a dialog, in any CANCEL request and in any response whose=20
>    status code explicitly allows the presence of this header field.=20
>=20
>    Note that the Reason header field is usually not needed in=20
> responses
>    because the status code and the reason phrase already provide=20
>    sufficient information.=20
>=20
>    Clients and servers are free to ignore this header field. =20
> It has no=20
>    impact on protocol processing.=20
>=20
> At that time where RFC3326 was written it was not assumed that a=20
> Reason in a response is usually not needed but it does not restrict=20
> the use of the Reason header within responses.
> It allows the use of the Reason header if the status code allows it.
>=20
> That was the reasoning for writing this draft to allow the Reason=20
> header within Responses and it is not an new encapsulation mechanism.
>=20
> Kind regards
> Roland Jesske
>=20
>=20
> Deutsche Telekom Netzproduktion GmbH
> Technical Engineering Center
> Roland Jesske
> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt, Germany
> +49 6151 628-2766 (Phone)
> +49 521 9210-3753  (Fax)
> +49 171 8618-445  (Mobile)
> E-Mail: r.jesske@telekom.de =20
> www.telekom.com 
>=20
> Life is for sharing.=20
>=20
> Deutsche Telekom Netzproduktion GmbH
> Supervisory Board: Dr. Steffen Roehn (Chairman) Managing Board: Dr.=20
> Bruno Jacobfeuerborn (Chairman), Albert Matheis, Klaus Peren=20
> Commercial register: Local court Bonn HRB 14190 Registered office:
> Bonn VAT identification no. DE 814645262
>=20
>=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From pkyzivat@cisco.com  Fri Jan 29 06:57:45 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC97D3A67F5 for ; Fri, 29 Jan 2010 06:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.519
X-Spam-Level: 
X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtlkpD8DfpCz for ; Fri, 29 Jan 2010 06:57:44 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2AE4E3A67DA for ; Fri, 29 Jan 2010 06:57:44 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAL+GYkutJV2a/2dsb2JhbADEJpdVhEIE
X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="82775123"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2010 14:58:05 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0TEw5IP023116;  Fri, 29 Jan 2010 14:58:05 GMT
Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jan 2010 08:58:05 -0600
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jan 2010 08:58:04 -0600
Message-ID: <4B62F77A.7090704@cisco.com>
Date: Fri, 29 Jan 2010 09:58:02 -0500
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: R.Jesske@telekom.de
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de> <4B61A87D.8070000@cisco.com> <9886E5FCA6D76549A3011068483A4BD4058CE7C9@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4058CE7C9@S4DE8PSAAQB.mitte.t-com.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 29 Jan 2010 14:58:05.0047 (UTC) FILETIME=[75FCA870:01CAA0F3]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 14:57:46 -0000

R.Jesske@telekom.de wrote:
> Hi Paul,
> That was never the intend of the draft.

I didn't think it was the intent.
But its amazing what people will do.

> It is already mentioned within RFC 3326:
>    Clients and servers are free to ignore this header field.  It has no
>    impact on protocol processing.

Ah, I had forgotten that.

> And we can write something in addition within the draft to clarify that. 
> It is NOT the scope that native SIP devices either populate nor act on a received Reason with a Q.850 cause.

Maybe the above is enough. But restating it wouldn't hurt.

	Thanks,
	Paul

> Kind regards
> Roland Jesske
> 
> 
> -----Urspr�ngliche Nachricht-----
> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul Kyzivat
> Gesendet: Donnerstag, 28. Januar 2010 16:09
> An: Elwell, John
> Cc: dispatch@ietf.org; Jesske, Roland
> Betreff: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
> 
> 
> 
> Elwell, John wrote:
>> I think the long discussion we had at IETF#76 was out of all proportion to the magnitude of the proposed change.
>>
>> The Reason header field is a rather ugly solution to a problem brought about by incompatible sets of reason codes in these two different protocols. But given that we have the Reason header field, and that it is already allowed in some requests and responses, I don't really see the harm in opening the door to use in other responses. We could put some caveats around it, to try to discourage inappropriate uses. However, somebody implementing primarily for a SIP environment is unlikely to use (or abuse) this header field, which I would expect to be used only where really needed.
>>
>> Why can't we just let the people who want this get on and do it, and save our precious discussion time for more important topics?
> 
> I wasn't there for the discussion. :-(
> 
> I generally agree with John that this is pretty benign.
> 
> The one concern I have is if somebody implements in such a way that 
> these reason codes must be in responses for proper operation, thus 
> making native SIP devices understand and populate this data to get good 
> results.
> 
> 	Thanks,
> 	Paul
> 
>> John 
>>
>>> -----Original Message-----
>>> From: dispatch-bounces@ietf.org 
>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
>>> Sent: 28 January 2010 07:16
>>> To: dispatch@ietf.org
>>> Subject: [dispatch] ISSUES on 
>>> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in 
>>> Responses
>>>
>>> Dear all, 
>>> The discussion at the last IETF meeting due to the proposal 
>>> to use the reason header within responses where controversial.
>>>
>>> I would like to start the discussion on mentioned concerns. 
>>>
>>> One concern was that we define an new encapsulation mechanism 
>>> for ISUP elements in parallel to SIP-T. 
>>>
>>> The Reason header itself is a SIP generic Header defined in RFC3326. 
>>>
>>> The syntax allows to put in a SIP Response code and/or an 
>>> ISUP Q.850 Cause Code. 
>>>
>>> As many times mentioned before RFC 3326 (The Reason Header 
>>> Field for the Session Initiation Protocol (SIP)) defines the 
>>> following.
>>>
>>>    Initially, the Reason header field defined here appears to be most 
>>>    useful for BYE and CANCEL requests, but it can appear in 
>>> any request 
>>>    within a dialog, in any CANCEL request and in any response whose 
>>>    status code explicitly allows the presence of this header field. 
>>>
>>>    Note that the Reason header field is usually not needed in 
>>> responses 
>>>    because the status code and the reason phrase already provide 
>>>    sufficient information. 
>>>
>>>    Clients and servers are free to ignore this header field.  
>>> It has no 
>>>    impact on protocol processing. 
>>>
>>> At that time where RFC3326 was written it was not assumed 
>>> that a Reason in a response is usually not needed but it does 
>>> not restrict the use of the Reason header within responses. 
>>> It allows the use of the Reason header if the status code allows it.
>>>
>>> That was the reasoning for writing this draft to allow the 
>>> Reason header within Responses and it is not an new 
>>> encapsulation mechanism.
>>>
>>> Kind regards 
>>> Roland Jesske 
>>>
>>>
>>> Deutsche Telekom Netzproduktion GmbH 
>>> Technical Engineering Center 
>>> Roland Jesske 
>>> Heinrich-Hertz-Stra�e 3-7, 64295 Darmstadt, Germany 
>>> +49 6151 628-2766 (Phone) 
>>> +49 521 9210-3753  (Fax) 
>>> +49 171 8618-445  (Mobile) 
>>> E-Mail: r.jesske@telekom.de   
>>> www.telekom.com   
>>>
>>> Life is for sharing. 
>>>
>>> Deutsche Telekom Netzproduktion GmbH 
>>> Supervisory Board: Dr. Steffen Roehn (Chairman) 
>>> Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert 
>>> Matheis, Klaus Peren 
>>> Commercial register: Local court Bonn HRB 14190 
>>> Registered office: Bonn 
>>> VAT identification no. DE 814645262 
>>>
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

From L.Liess@telekom.de  Fri Jan 29 07:14:38 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30253A6921 for ; Fri, 29 Jan 2010 07:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq-vdTRvVOtM for ; Fri, 29 Jan 2010 07:14:33 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 775943A68F3 for ; Fri, 29 Jan 2010 07:14:31 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtwAABGKYksKfbFp/2dsb2JhbAAI23qEQgQ
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 29 Jan 2010 16:14:48 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 29 Jan 2010 16:14:48 +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
Date: Fri, 29 Jan 2010 16:14:47 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003E8C365@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <4B589B6E.5010003@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
Thread-Index: AcqaxrfJMC25Wr4OSiyX+6QNrcLkPAGLh0Lg
References: <4B32DC9B.3040406@softarmor.com><36D784AAD47343248BE3274F64A101ED@china.huawei.com><4B4F3353.9010507@ericsson.com>	 <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B@S4DE9JSAANI.ost.t-com.de> <4B560BE8.30908@ericsson.com> <40FB0FFB97588246A1BEFB05759DC8A003E15564@S4DE9JSAANI.ost.t-com.de> <4B589B6E.5010003@ericsson.com>
From: 
To: 
X-OriginalArrivalTime: 29 Jan 2010 15:14:48.0364 (UTC) FILETIME=[CC02AEC0:01CAA0F5]
Cc: dispatch@ietf.org, gonzalo.camarillo@ericsson.com, HKaplan@acmepacket.com, Martin.Huelsemann@telekom.de
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 15:14:38 -0000

Sal,=20

Sorry for the late answer. Somehow I overlooked your mail.=20

> .... I=20
> think it should be better taking the two Id's separate,
> as using the same could generate a lot of confusion in=20
> several scenarios.

This is also my opinion.=20

Thanks a lot
Laura
>=20
> /Sal
>=20
>=20
>=20

From spencer@wonderhamster.org  Fri Jan 29 08:50:52 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E413A6A31 for ; Fri, 29 Jan 2010 08:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMArGmTGbqtr for ; Fri, 29 Jan 2010 08:50:52 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id D4FFC3A6A2E for ; Fri, 29 Jan 2010 08:50:51 -0800 (PST)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MXZKo-1NFXwb1Pjq-00WYq9; Fri, 29 Jan 2010 11:51:11 -0500
Message-ID: <6C56EB2EA9514E2B9CD93C3BE4C80302@china.huawei.com>
From: "Spencer Dawkins" 
To: "Paul Kyzivat" , 
References: <9886E5FCA6D76549A3011068483A4BD4058CE288@S4DE8PSAAQB.mitte.t-com.de><4B61A87D.8070000@cisco.com><9886E5FCA6D76549A3011068483A4BD4058CE7C9@S4DE8PSAAQB.mitte.t-com.de> <4B62F77A.7090704@cisco.com>
Date: Fri, 29 Jan 2010 10:50:58 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX19YeOnKOfjosoGVZA7Sh3e/FgmW6FC77TQknj2 5ztxoE3Himre1vV6s+NN+Y21/NrjBHw43jjSZsA5McRkMJOGGQ ecAfSRmaCmpkhckhCvoD3DS+Q4X5iSEvXheJvujESg=
Cc: dispatch@ietf.org
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2010 16:50:52 -0000

Hi, Roland,

I agree with Paul here - restating this point, with the pointer to RFC 3326, 
is worth doing.

I wasn't at the mike in Hiroshima on this topic, but I was in the room, and 
anything that reduces the chances of another conversation like that one on 
this topic is well worth doing!

Thanks,

Spencer

----- Original Message ----- 
From: "Paul Kyzivat" 
To: 
Cc: 
Sent: Friday, January 29, 2010 8:58 AM
Subject: Re: [dispatch] ISSUES on 
draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in

> It is already mentioned within RFC 3326:
>    Clients and servers are free to ignore this header field.  It has no
>    impact on protocol processing.

Ah, I had forgotten that.

> And we can write something in addition within the draft to clarify that. 
> It is NOT the scope that native SIP devices either populate nor act on a 
> received Reason with a Q.850 cause.

Maybe the above is enough. But restating it wouldn't hurt. 

From Henry.Lum@alcatel-lucent.com  Sat Jan 30 20:11:08 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9C53A63C9 for ; Sat, 30 Jan 2010 20:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLGLExyzKBX5 for ; Sat, 30 Jan 2010 20:10:59 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 1312C3A6894 for ; Sat, 30 Jan 2010 20:10:58 -0800 (PST)
Received: from horh1.pdc.alcatel-lucent.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id o0V4B04m012547; Sat, 30 Jan 2010 22:11:00 -0600 (CST)
Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by horh1.pdc.alcatel-lucent.com (8.13.8/emsr) with ESMTP id o0V4AxXF027465; Sat, 30 Jan 2010 22:10:59 -0600 (CST)
Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id o0V4Awcc024977; Sat, 30 Jan 2010 20:10:58 -0800 (PST)
Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.3959);  Sat, 30 Jan 2010 20:10:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA22B.62E2E811"
Date: Sat, 30 Jan 2010 20:10:51 -0800
Message-ID: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00
Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQ==
From: "Henry Lum" 
To: 
X-OriginalArrivalTime: 31 Jan 2010 04:10:57.0034 (UTC) FILETIME=[63838EA0:01CAA22B]
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28
Cc: Dave Smith , krehor@cisco.com
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2010 04:11:08 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAA22B.62E2E811
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ken,

=20

I have a bunch of questions and comments on the requirements for SRP
requirements.

=20

-          Section 3 - Recording Client - If the SRP requirement does
not mandate to use SIP as the actual recording protocol, why does the
recording client have to be a SIP user agent or B2BUA?

-          Section 3 - Recorded session - Is a recorded session has to
be a SIP session?

-          Section 3 - Persistent Recording - does recorded session
exist in this context since it seems like the recording session is
persistent from the endpoint perspective.

-          Section 4 - use case 5 - if the recording can include
recording for an IVR application (ie. VoiceXML application), does that
mean the call metadata must include application contexts as well?

-          Section 4, use case 7 - the first sentence has a strange word
"&mdash". This use case somehow implies certain architectural design for
a PBX with regards to media forking. Is that necessary from a
requirement perspective?

-          Section 4, use case 8 - shall we use a more general
terminology such as multi-party call? Depending on the situation, the
supervisor may be conferenced with the agent and customer so the
recording session needs to define how a multi-party session should be
recorded.

-          Section 4, use case 11, does a recorder "must" support some
sort of media processing such as real-time analytics? This is more of a
business application on the recording server side, which is independent
of the session recording protocol itself.

-          Section 6:

o   REQ-001 - what does full-time Recording session mean?

o   REQ-003 - it's unclear what is the target of the recording session
here since this not directly related to a single recorded session
(perhaps many)

o   REQ-006 - I mentioned above that IVR sessions may contain additional
IVR application metadata; should this requirement clarify that the
mechanism should include application metadata?

o   REQ-007 - this wording of the requirement to me is pointing towards
a specific implementation of high-availability or fault-tolerance of a
recording session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the
recorded session represents a multi-party session where there are
multiple media streams from multiple recorded sessions, and the media
streams may be mixed by a conference mixer?

o   REQ-013 - this is only one way of notifying the customer that the
call is being recorded but there are others. I think this requires a bit
more explanation of why this is needed. To me this looks like a
duplicate of REQ-022

o   REQ-015 - what does non-repudiation mean in this context? Isn't this
the same as REQ-017?

o   REQ-021 - what happens with SRTP if recording client simply forks
the media? The recording server would not be able to decrypt the media
unless it gets the private keys from the recorded session.

o   REQ-028 - the wording redirected looks out of context here; the
requirement only applies when recording client initiates a recording
session to an available recorder server?

o   REQ-029/030 - They look very generic and I don't think these should
be requirements for SRP, but rather a product requirement on how OA&M
works for the recording client/server.

=20

Thanks

Henry

				=09
-------------------------------------------------------------------------=
------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co=
nfidential and proprietary information of Alcatel-Lucent and/or its affil=
iated entities. Access by the intended recipient only is authorized. Any =
liability arising from any party acting, or refraining from acting, on an=
y information contained in this e-mail is hereby excluded. If you are not=
 the intended recipient, please notify the sender immediately, destroy th=
e original transmission and its attachments and do not disclose the conte=
nts to any other person, use it for any purpose, or store or copy the inf=
ormation in any medium. Copyright in this e-mail and any attachments belo=
ngs to Alcatel-Lucent and/or its affiliated entities.
				=09

------_=_NextPart_001_01CAA22B.62E2E811
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ken,

I have a bunch of questions and comments on the requ=
irements
for SRP requirements.

-&=
nbsp;        
Section 3 – Recording Client – If the=
 SRP
requirement does not mandate to use SIP as the actual recording protocol,=
 why
does the recording client have to be a SIP user agent or B2BUA?

-&=
nbsp;        
Section 3 - Recorded session – Is a recorde=
d
session has to be a SIP session?

-&=
nbsp;        
Section 3 - Persistent Recording – does rec=
orded
session exist in this context since it seems like the recording session i=
s
persistent from the endpoint perspective.

-&=
nbsp;        
Section 4 – use case 5 – if the recor=
ding
can include recording for an IVR application (ie. VoiceXML application), =
does
that mean the call metadata must include application contexts as well?

-&=
nbsp;        
Section 4, use case 7 – the first sentence =
has a
strange word “&mdash”. This use case somehow implies cert=
ain
architectural design for a PBX with regards to media forking. Is that nec=
essary
from a requirement perspective?

-&=
nbsp;        
Section 4, use case 8 – shall we use a more=

general terminology such as multi-party call? Depending on the situation,=
 the
supervisor may be conferenced with the agent and customer so the recordin=
g
session needs to define how a multi-party session should be recorded.

-&=
nbsp;        
Section 4, use case 11, does a recorder “mu=
st”
support some sort of media processing such as real-time analytics? This i=
s more
of a business application on the recording server side, which is independ=
ent of
the session recording protocol itself.

-&=
nbsp;        
Section 6:

o&=
nbsp; 
REQ-001 – what does full-time Record=
ing
session mean?

o&=
nbsp; 
REQ-003 – it’s unclear what is=
 the target
of the recording session here since this not directly related to a single=
 recorded
session (perhaps many)

o&=
nbsp; 
REQ-006 – I mentioned above that IVR=

sessions may contain additional IVR application metadata; should this
requirement clarify that the mechanism should include application metadat=
a?

o&=
nbsp; 
REQ-007 – this wording of the requir=
ement
to me is pointing towards a specific implementation of high-availability =
or
fault-tolerance of a recording session.

o&=
nbsp; 
REQ-009 – the wording here is a bit
unclear here. Do you mean the recorded session represents a multi-party s=
ession
where there are multiple media streams from multiple recorded sessions, a=
nd the
media streams may be mixed by a conference mixer?

o&=
nbsp; 
REQ-013 – this is only one way of
notifying the customer that the call is being recorded but there are othe=
rs. I
think this requires a bit more explanation of why this is needed. To me t=
his
looks like a duplicate of REQ-022

o&=
nbsp; 
REQ-015 – what does non-repudiation =
mean
in this context? Isn’t this the same as REQ-017?

o&=
nbsp; 
REQ-021 – what happens with SRTP if =
recording
client simply forks the media? The recording server would not be able to
decrypt the media unless it gets the private keys from the recorded sessi=
on.

o&=
nbsp; 
REQ-028 – the wording redirected loo=
ks out
of context here; the requirement only applies when recording client initi=
ates a
recording session to an available recorder server?

o&=
nbsp; 
REQ-029/030 – They look very generic=
 and I
don’t think these should be requirements for SRP, but rather a prod=
uct
requirement on how OA&M works for the recording client/server.

Thanks

Henry

CONFIDENTIALITY NOTICE: This e-mai=
l and any files attached may contain confidential and proprietary informa=
tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte=
nded recipient only is authorized. Any liability arising from any party a=
cting, or refraining from acting, on any information contained in this e-=
mail is hereby excluded. If you are not the intended recipient, please no=
tify the sender immediately, destroy the original transmission and its at=
tachments and do not disclose the contents to any other person, use it fo=
r any purpose, or store or copy the information in any medium. Copyright =
in this e-mail and any attachments belongs to Alcatel-Lucent and/or its a=
ffiliated entities.

------_=_NextPart_001_01CAA22B.62E2E811--

From Leon.Portman@nice.com  Sun Jan 31 03:02:25 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA423A6855 for ; Sun, 31 Jan 2010 03:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO4vh5hZPLWc for ; Sun, 31 Jan 2010 03:02:16 -0800 (PST)
Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 2AE003A6820 for ; Sun, 31 Jan 2010 03:02:14 -0800 (PST)
Received: from tlvcas02.nice.com (172.18.253.6) by tlvcas01.nice.com (192.168.253.111) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sun, 31 Jan 2010 13:02:41 +0200
Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 31 Jan 2010 13:02:41 +0200
From: Leon Portman 
To: Henry Lum , "dispatch@ietf.org" 
Date: Sun, 31 Jan 2010 13:02:40 +0200
Thread-Topic: Comments on draft-rehor-dispatch-session-recording-req-00
Thread-Index: AcqiK2A914H3YQBYSG+i58VmspU3YQAMWHoQ
Message-ID: <07465C1D981ABC41A344374066AE1A2C37D997BE55@TLVMBX01.nice.com>
References: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com>
In-Reply-To: <059AF07365DC474393A19A3AF187DF74053791B5@NAHALD.us.int.genesyslab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C37D997BE55TLVMBX01nicec_"
MIME-Version: 1.0
Cc: Dave Smith , "krehor@cisco.com" 
Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2010 11:02:25 -0000

--_000_07465C1D981ABC41A344374066AE1A2C37D997BE55TLVMBX01nicec_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Henry.

I will try to answer some of the questions. Please see below.

Leon

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: dispatch@ietf.org
Cc: Dave Smith; krehor@cisco.com
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-=
00

Hi Ken,

I have a bunch of questions and comments on the requirements for SRP requir=
ements.

-          Section 3 - Recording Client - If the SRP requirement does not m=
andate to use SIP as the actual recording protocol, why does the recording =
client have to be a SIP user agent or B2BUA?
[LeonP] Actually there is a difference between Recorded session (the actual=
 call to be recorded) that can be not SIP based and Recording Session (part=
 of SRP) that is used for triggering recording and it is SIP based. So both=
 RC and RS are SIP UA.

-          Section 3 - Recorded session - Is a recorded session has to be a=
 SIP session?
[LeonP] No, my comment above

-          Section 3 - Persistent Recording - does recorded session exist i=
n this context since it seems like the recording session is persistent from=
 the endpoint perspective.
[LeonP] No, recorded session are not required to be existing during initiat=
ion of persistent session. Persistent recording session can be initiated on=
 agent logon for example.

-          Section 4 - use case 5 - if the recording can include recording =
for an IVR application (ie. VoiceXML application), does that mean the call =
metadata must include application contexts as well?
[LeonP] Yes, like specific script or input results

-          Section 4, use case 7 - the first sentence has a strange word "&=
mdash". This use case somehow implies certain architectural design for a PB=
X with regards to media forking. Is that necessary from a requirement persp=
ective?
[LeonP] XML convert mistake. We don't want assume any specific configuratio=
ns.

-          Section 4, use case 8 - shall we use a more general terminology =
such as multi-party call? Depending on the situation, the supervisor may be=
 conferenced with the agent and customer so the recording session needs to =
define how a multi-party session should be recorded.
[LeonP] Yes, probably we want to use more generic term then Complex Call

-          Section 4, use case 11, does a recorder "must" support some sort=
 of media processing such as real-time analytics? This is more of a busines=
s application on the recording server side, which is independent of the ses=
sion recording protocol itself.
[LeonP] The main point there was that Recording Protocol must support real =
time streaming for real time analytics

-          Section 6:

o   REQ-001 - what does full-time Recording session mean?
[LeonP] Record all calls

o   REQ-003 - it's unclear what is the target of the recording session here=
 since this not directly related to a single recorded session (perhaps many=
)
[LeonP] To minimize media clipping associated with recording initiation

o   REQ-006 - I mentioned above that IVR sessions may contain additional IV=
R application metadata; should this requirement clarify that the mechanism =
should include application metadata?
[LeonP] Yes, we should

o   REQ-007 - this wording of the requirement to me is pointing towards a s=
pecific implementation of high-availability or fault-tolerance of a recordi=
ng session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the recor=
ded session represents a multi-party session where there are multiple media=
 streams from multiple recorded sessions, and the media streams may be mixe=
d by a conference mixer?
[LeonP]  It is more for trading floor environments where multiple concurren=
t calls on the same device (turret) recorded together. It is not related to=
 summation for conference participants at the same call.

o   REQ-013 - this is only one way of notifying the customer that the call =
is being recorded but there are others. I think this requires a bit more ex=
planation of why this is needed. To me this looks like a duplicate of REQ-0=
22

o   REQ-015 - what does non-repudiation mean in this context? Isn't this th=
e same as REQ-017?
[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session

o   REQ-021 - what happens with SRTP if recording client simply forks the m=
edia? The recording server would not be able to decrypt the media unless it=
 gets the private keys from the recorded session.
[LeonP] It is out of scope of this document.

o   REQ-028 - the wording redirected looks out of context here; the require=
ment only applies when recording client initiates a recording session to an=
 available recorder server?
[LeonP] We want to support both directions

o   REQ-029/030 - They look very generic and I don't think these should be =
requirements for SRP, but rather a product requirement on how OA&M works fo=
r the recording client/server.

Thanks
Henry

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf=
idential and proprietary information of Alcatel-Lucent and/or its affiliate=
d entities. Access by the intended recipient only is authorized. Any liabil=
ity arising from any party acting, or refraining from acting, on any inform=
ation contained in this e-mail is hereby excluded. If you are not the inten=
ded recipient, please notify the sender immediately, destroy the original t=
ransmission and its attachments and do not disclose the contents to any oth=
er person, use it for any purpose, or store or copy the information in any =
medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc=
ent and/or its affiliated entities.

--_000_07465C1D981ABC41A344374066AE1A2C37D997BE55TLVMBX01nicec_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Henry.

I
will try to answer some of the questions. Please see below.

Leon

From:
dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O=
f Henry
Lum

Sent: Sunday, January 31, 2010 6:11 AM

To: dispatch@ietf.org

Cc: Dave Smith; krehor@cisco.com

Subject: [dispatch] Comments on
draft-rehor-dispatch-session-recording-req-00

Hi Ken,

I have a bunch of questions and comments on the requir=
ements
for SRP requirements.

-&nb=
sp;        
Section 3 – Recording =
Client
– If the SRP requirement does not mandate to use SIP as the actual
recording protocol, why does the recording client have to be a SIP user age=
nt
or B2BUA?

[LeonP] Actually there is a difference between Recorded sess=
ion
(the actual call to be recorded) that can be not SIP based and Recording Se=
ssion
(part of SRP) that is used for triggering recording and it is SIP based. So
both RC and RS are SIP UA.

-&nb=
sp;        
Section 3 - Recorded session
– Is a recorded session has to be a SIP session?

[LeonP] No, my comment above=

-&nb=
sp;        
Section 3 - Persistent Recor=
ding
– does recorded session exist in this context since it seems like the
recording session is persistent from the endpoint perspective.

[LeonP] No, recorded session are not required to be existing
during initiation of persistent session. Persistent recording session can b=
e
initiated on agent logon for example.

-&nb=
sp;        
Section 4 – use case 5
– if the recording can include recording for an IVR application (ie.
VoiceXML application), does that mean the call metadata must include
application contexts as well?

[LeonP] Yes, like specific script or input results=

-&nb=
sp;        
Section 4, use case 7 –=
; the
first sentence has a strange word “&mdash”. This use case
somehow implies certain architectural design for a PBX with regards to medi=
a
forking. Is that necessary from a requirement perspective?

[LeonP] XML convert mistake. We don’t want assume any
specific configurations.

-&nb=
sp;        
Section 4, use case 8 –=
;
shall we use a more general terminology such as multi-party call? Depending=
 on
the situation, the supervisor may be conferenced with the agent and custome=
r so
the recording session needs to define how a multi-party session should be
recorded.

[LeonP] Yes, probably we want to use more generic term then
Complex Call

-&nb=
sp;        
Section 4, use case 11, does=
 a
recorder “must” support some sort of media processing such as
real-time analytics? This is more of a business application on the recordin=
g
server side, which is independent of the session recording protocol itself.=

[LeonP] The main point there was that Recording Protocol mus=
t
support real time streaming for real time analytics=

-&nb=
sp;        
Section 6:

o&nb=
sp; 
REQ-001 – what =
does
full-time Recording session mean?

[LeonP] Record all calls

o&nb=
sp; 
REQ-003 – it=
217;s
unclear what is the target of the recording session here since this not
directly related to a single recorded session (perhaps many)

[LeonP] To minimize media clipping associated with recording
initiation

o&nb=
sp; 
REQ-006 – I men=
tioned
above that IVR sessions may contain additional IVR application metadata; sh=
ould
this requirement clarify that the mechanism should include application meta=
data?

[LeonP] Yes, we should

o&nb=
sp; 
REQ-007 – this
wording of the requirement to me is pointing towards a specific implementat=
ion
of high-availability or fault-tolerance of a recording session.<=
/p>

o&nb=
sp; 
REQ-009 – the w=
ording
here is a bit unclear here. Do you mean the recorded session represents a
multi-party session where there are multiple media streams from multiple
recorded sessions, and the media streams may be mixed by a conference mixer=
?

[LeonP]  It is more for trading floor environments where mul=
tiple
concurrent calls on the same device (turret) recorded together. It is not
related to summation for conference participants at the same call.

o&nb=
sp; 
REQ-013 – this =
is
only one way of notifying the customer that the call is being recorded but
there are others. I think this requires a bit more explanation of why this =
is
needed. To me this looks like a duplicate of REQ-022

o&nb=
sp; 
REQ-015 – what =
does
non-repudiation mean in this context? Isn’t this the same as REQ-017?=

[LeonP] REQ-015 talk
regarding media and REQ-017 regarding SRP SIP Session

o&nb=
sp; 
REQ-021 – what
happens with SRTP if recording client simply forks the media? The recording
server would not be able to decrypt the media unless it gets the private ke=
ys
from the recorded session.

[LeonP] It is out of scope of this document. =
=

o&nb=
sp; 
REQ-028 – the w=
ording
redirected looks out of context here; the requirement only applies when
recording client initiates a recording session to an available recorder ser=
ver?

[LeonP] We want to support both directions=

o&nb=
sp; 
REQ-029/030 – T=
hey
look very generic and I don’t think these should be requirements for =
SRP,
but rather a product requirement on how OA&M works for the recording
client/server.

Thanks

Henry

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is authorized. A=
ny
liability arising from any party acting, or refraining from acting, on any
information contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the sender immediately, destroy the origi=
nal
transmission and its attachments and do not disclose the contents to any ot=
her
person, use it for any purpose, or store or copy the information in any med=
ium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/=
or
its affiliated entities.

--_000_07465C1D981ABC41A344374066AE1A2C37D997BE55TLVMBX01nicec_--

From paulej@packetizer.com  Sun Jan 31 23:16:49 2010
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9393A6801 for ; Sun, 31 Jan 2010 23:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm79M2eMa3mm for ; Sun, 31 Jan 2010 23:16:48 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id C0A843A6359 for ; Sun, 31 Jan 2010 23:16:47 -0800 (PST)
Received: from berlin.arid.us (rrcs-98-101-146-143.midsouth.biz.rr.com [98.101.146.143]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o117HDh4018969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Feb 2010 02:17:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1265008639; bh=fxAhlpQr/iPGDccENLUN/wMYdYZYCG+Ug4Lcpo9xnEI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kFPKaSrNxwDTfedg2Mer11gFbxnuY9xCMSdVJOc5bvssFeXz6IseG0MjuAIpW3AKv U171Gtd54ylpA57sq0U8EUkN9NboWnsZtzZKfH2Orbfe6MUgFzmZPVWDxLlDFymBZb Rc9mwzHib/W2fVLosSC7JwEzpR3Rp6/DxICrHF1g=
Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o117HDM8025594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Feb 2010 02:17:13 -0500
From: "Paul E. Jones" 
To: "'Cullen Jennings'" , "'Dean Willis'" 
References: <013401ca679d$3a926700$afb73500$@us>	<00cd01ca8387$9b46ea20$d1d4be60$@com>	<4B32DEE9.5000302@softarmor.com>	<007301ca84b7$343dd6f0$9cb984d0$@us>	<4B33D01C.9000006@cisco.com>	<4B39AE2C.9090304@softarmor.com>	<503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com>	<1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com>	<4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com>  <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> 
In-Reply-To: 
Date: Mon, 1 Feb 2010 02:17:11 -0500
Message-ID: <002501caa30e$92abc240$b80346c0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqfcfofmztKwcepSvC++hqG2H8rnQDl/yTg
Content-Language: en-us
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Feb 2010 07:16:49 -0000

Cullen,

> I'm trying to think about what we want to accomplish by publishing this
> draft as an RFC. I was very happy to read the draft and think there is
> some good stuff in it.

As an informational RFC, the objective would be nothing more than to
document the issues that have been identified.  It does not try to address a
problem, but merely raise awareness to issues in a manner similar to many
other Informational RFCs over the years.

> The draft contains a mixture of things. Partially it is a liaison to
> IETF from sipforum about what they are up to with a sipform work group.

You're right.  I think we should change some of the wording, especially the
abstract.  The intent it not to be a liaison document, but it is intended to
report on current state of affairs to the Internet community.

> This is great to get but I don't think there is much long term need to
> record that in RFC form. The more important part to publish IMHO is
> documenting some issues, problems, deficiencies and/or bugs in some
> IETF specifications that are leading to lack of interoperability in
> deployments. That type of problem statement would be great information
> to get written down in a concrete form that allows the appropriate WG
> to go fix the problems.

The challenge, I suppose, is that there are no IETF documents that we can
fault.  There have been Internet Drafts written in the past that provide
inaccurate information.  Perhaps they didn't at the time, but they have been
implemented by vendors.

Having said that, the reason for wanting to publish this in the IETF is that
there are a number of SIP devices that implement T.38 and problems exist in
many of those implementations.  It's not a fault of SIP, but it is believed
that there is value in providing this information to those developers.  It
would also be of benefit to those deploying equipment.

Longer-term, it would only serve as a historical record in much the same way
many Informational RFCs do.

> I do realize fax works by using protocols from multiple SDOs and that
> does complicate things. I think it would be beneficial to document
> specific problems found with IETF protocols. I'm less interested in the
> IETF publishing problems with some other SDOs protocols.  You've caught
> me at a particularly sensitive time having just spend 1/2 my time for
> the last several months dealing with the IETF relationships with other
> SDOs. And if anyone mentions royalty free fax algorithms my head might
> explode :-)

We already have one: it's called PDF over SMTP. ;-)

I understand your point.  The issue is that, while some problems are
inherent in T.38, there is a bigger issue and perhaps a "lesson to be
learned" here: the Internet and gateways into legacy technology do not
always fit well together.  Some of the problems with T.38 have to do with
timers expiring due to multiple hops between IP network and PSTN network
segments, for example.

While this is not IETF technology, it's not all technology of any SDO.  Fax
issues have been something of joint interest by folks in both the ITU and
IETF.  I recall folks actively working on this in both organizations in 1998
and 1999.  More than a decade later, we see all of these issues with SIP
networks that are now being deployed.

One day, this will all be behind us.  It will either be when the last PSTN
GW is dismantled and buried, or when we all switch to something like the
above mentioned royalty-free IP-based document transmission system. ;-)
Until then (or perhaps as a driver for), we need to document the issues.  We
also need to take steps to try to resolve them and, ideally, some folks in
the IETF will help bring about change.

> So what I am getting at is could we move this draft more towards
> something that documents what is observed in real world deployments and
> discuss the problems with the existing IETF protocols, then WG Last
> Call it in the appropriate WG(s) (I'm assuming things like mmusic,
> fecframe, perhaps avt) and publish it as informational? The goal of
> publishing it would be to provide a problem statement for future work
> in theses WG.

I think we can remove some of the text that makes it sound too much like a
liaison, but I don't think we can highlight issues with existing IETF texts
and I don't think it would be appropriate to drive this through a WG to
produce a standards-track document.

> Does that make sense to people? Reasonable path forward? I'm open to
> other ideas but whatever we do, I would want to understand why
> publishing whatever document we published was going to help make things
> work better. And on that note, I'd like to express many thanks to SIP
> Forum and all the people who worked on this effort for helping get fax
> working better.

I think I heard crickets chirping.  Perhaps that's a bad sign, but I would
like to hear more voices.  Folks who have tried to deploy fax equipment,
either as a manufacturer or the end-user, surely has had some level of
frustration with fax.  So, how do people feel about this document?

Paul

> Cullen
> 
> PS - Paul, thanks for trying to make less work and Dean, as punishment
> for your sins I'm nominating you for AD to the next Nomcom :-)
> 
> On Jan 7, 2010, at 11:27 PM, Paul E. Jones wrote:
> 
> > Dean said:
> >>> "AD Sponsored submissions represent a significant workload to the
> >>> IESG."
> >>>
> >>
> >> If the document is well enough drafted that it doesn't create a lot
> of
> >> work for the AD, then there isn't that much extra work.
> >>
> >> One can also use an external document shepherd to make sure the doc
> is
> >> really "IESG ready" before the AD gets deeply into it. PaulK would
> be
> >> good at this ;-).
> >>
> >> Besides, Cullen needs more work to do.
> >
> > So, Paul K. and Cullen should each be made aware that you've given
> them an
> > assignment.  They'll thank you at the next meeting. ;-)
> >
> > Paul
> >
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 

From:	Volker Hilt <volkerh@bell-labs.com>
To:	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Cc:	DISPATCH <dispatch@ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Date:	01/15/2010 09:47 AM
Subject:	Re: [sip-overload] [dispatch] Chartering SIP Overload