[sipcore] Comments on draft-barnes-sipcore-rfc4244bis-callflows-00

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 30 August 2010 18:06 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296463A69FA for <sipcore@core3.amsl.com>; Mon, 30 Aug 2010 11:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_20=-0.74]
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 EbWh2qPiyYys for <sipcore@core3.amsl.com>; Mon, 30 Aug 2010 11:06:32 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B97843A6873 for <sipcore@ietf.org>; Mon, 30 Aug 2010 11:06:31 -0700 (PDT)
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; Mon, 30 Aug 2010 14:07:01 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Aug 2010 14:07:01 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Mon, 30 Aug 2010 14:07:00 -0400
Thread-Topic: Comments on draft-barnes-sipcore-rfc4244bis-callflows-00
Thread-Index: ActIbiTsiusbKKBCT5u7IQm4bKboAA==
Message-ID: <52AFB781-AC73-4E69-B2EF-400649555D19@acmepacket.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: [sipcore] Comments on draft-barnes-sipcore-rfc4244bis-callflows-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2010 18:06:34 -0000

Howdy,
While reviewing 4424bis-01, I also reviewed the call-flows I-D.  I found the examples in the call-flows generally more relevant and useful than the example call flows in Appendix B of the 4424bis, btw.  Especially for figuring out why an "rc" param is useful to anyone.

Comments:

1) Section 3.1 on ACD says:
  Upon receipt of the call at the agent assigned to handle the
  incoming call, based upon the History-Info header in the message, the
  application at the agent can provide an indication that this is a
  Gold call by extracting the hi-entry associated with the incoming
  request which is determined by locating the hi-entry whose index is
  reflected in the first hi-entry with an hi-target of "mp".

And yet the example shows that is not in fact the case.  The first hi-entry with "mp" is for Silver, not Gold.  Furthermore, the call could have been diverted multiple times before reaching the ACD system, which means the _first_ called identity may not matter at all.  What it should probably look for is the identity before the _last_ "mp", since the last "mp" (if there are any) is itself, so the identity before that is what it wants (Gold).  


2) Section 3.2 in Alias determination says:
  The alias for the call is determined by the UAS extracting the hi-entry
  prior to the last hi-entry with the "rc" tag.

That's true only because the example shows it to be the case.  If John was one of multiple registered contacts for the Alias, and was tried later in forking, there would be multiple "rc" entries prior to the last one which are not the Alias.  

Furthermore, it is not at all clear that a Proxy, which resolves an Alias to a registered contact for a real AoR, shouldn't in fact add the "real" AoR as another entry.  In other words, it may add a <sip:john@example.com> H-I entry right after <sip:john.smith@example.com>, before the registered contact for john.  This won't be "rc" or "mp" tagged (right?).  


3) Section 3.4 on Call Center Voicemail.  I think this section is mislabeled, or the wrong case - a call to a call center voicemail may or may not use Carol for the voicemail; a clearer case to show the point, which I believe is to show the inverse case of example section 3.1, is to just have the call diverted in a service provider and call it "POTS voicemail" or "consumer voicemail" or some such.


Editorial comments (I think):
1) Section 3.1's ACD example has an error, I believe.  When the INVITE is redirected to Silver, the index is incremented from the base number, even though it's the Proxy recursing the redirect, not the UAC.  Instead of setting it to index=2, it should be index=1.2 (and the next entry be 1.2.1 not 2.1).  Also, the example incorrectly shows the redirect server adding the embedded Reason header in the H-I, vs. the proxy.

2) Section 3.2's example message F4 says INVITE -> Bob, but really it's to John.