On Fri, Mar 6, 2009 at 7:49 AM, Elwell, John <[email protected]> wrote:
Hi John, thank you very much for your feedback. > 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 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. > 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. 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, > where target could be null (resulting in call rejection)? 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? > 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. These items were identified by the design team as we were (iirc) targeting the same functionality as the GSM initially. > 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. 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. > 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. 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 _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
