Subject: [BLISS] Comments on draft-zourzouvillys-bliss-ach-http-api-00

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Mar 2009 07:49:22 +0000

1. Concerning the question of call forwarding unconditional versus no
answer, one drawback of using no answer with timeout of 0 for
unconditional is that it forces you to use the same destination for
both.

So for example, if I permanently have no answer forwarding set to
forward to my voicemail after 15s, but when I go away I want to set
forwarding unconditional to an assistant, I have to change 2 parameters.
Also when I return I have to remember not only to cancel unconditional
but also to set no answer again.

Another drawback is that forwarding busy or not reachable normally take
precedence over forwarding no answer, yet forwarding unconditional
normally takes precedence over forwarding busy and not reachable.
Although the different timeout values could be used to change the order
of precedence, it would be rather ugly.

So I would prefer to keep the two forwarding types separate.

2. "DND could be achived by defining some service URNs that return
   the status code, for example 480. e.g: urn:sip:status:unavailable,
   and then setting unconditional call forward to it, for example?"
This sounds like a rather convoluted way of doing it, and I am not sure
I understand it. Why not just have two settings: target and status,
where target could be null (resulting in call rejection)?

3. I am not entirely clear about the motivation for including outgoing
call barring. First, it has not been considered under the topic ACH,
because ACH concerns itself only with inbound calls. Second, it could be
done at the UA (the not-registered case clearly doesn't apply). I
suppose an advantage of doing it at the proxy is that you can do it once
and it covers all UAs. My next comment is also related.

4. What credentials are used for HTTP digest authentication - the same
as for SIP? I suppose one advantage of using separate credentials is
that a user with multiple UAs can supply SIP credentials to all those
UAs, but only supply (or unlock) HTTP credentials on the one he is
actually using to do configuration changes. Therefore other individuals
using other UAs on behalf of that user would not be able to change
configuration settings, and in particular would not be able to change
outgoing call barring. On the other hand, it is more information to
configure.

John

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 6 Mar 2009 16:35:54 +0000

On Fri, Mar 6, 2009 at 7:49 AM, Elwell, John <[email-masked]> wrote:

Hi John,

thank you very much for your feedback.

> So I would prefer to keep the two forwarding types separate.

Yup - the design team has also raised this, and i've added a
'noanswer' mode into the -01-pre version.

> I understand it.

My point was that (logically), DND is actually just the same as
unconditionally forwarding to something that always returns the status
code you want, for example:

  A -> B INVITE sip:responder.proxy.com;status=480;reason="Out to lunch" SIP/2.0
  B -> A SIP/2.0 480 Out to lunch

> Why not just have two settings: target and status,

Because it would be nice to be able to configure the reason phrase and
possibly also the status code that is returned.  We could of course
instead have a 'response' node that contains the status code and
reason phrase that is always returned.

What are other peoples thoughts on this?

> because ACH concerns itself only with inbound calls.

These items were identified by the design team as we were (iirc)
targeting the same functionality as the GSM initially.

> Second, it could be

When the UA and HTTP credentials are separate, it has some great uses.
 It would also be possible for this node to be read only unless using
credentials other than the HTTP ones, at which point it becomes
read/write.

> outgoing call barring. On the other hand, it is more information to

I think my personal preference to that is "network defined" - SIP
credentials would of course be a good candidate for many, however
there are scenarios as you mention where it's preferable to have
separate.

my view is that all UAs MUST support HTTP digest, using the SIP
credentials, as well as a way to let a user/administrator configure
alternative Digest credentials.

of course, auto provisioning only works if the SIP credentials are used.

another option that i'd be more than happy with is client certificate
over SSL, although it seems vendors run away screaming as soon as
anything related to PKI is mentioned :-)

 ~ Theo