So you are proposing that Bob would register like this:
REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
but when challenged, provide the credentials for user Bob instead of the
HelpDesk? This seems like a bad idea to me. Why isn't this 3rd party
registration:
REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
And when challenged, Bob provides his credentials. The Registrar is
provisioned to allow Bob to register against HelpDesk and everything
works. Alternatively, you could have Bob register using:
REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
But he will need to have the credentials for HelpDesk when challenged.
Anyway, we and other vendors already implement this feature this way, so
the draft must support it. A given system can choose not to use it.
Thanks,
Alan
Francois Audet wrote:
Well, yes.
However, as per my email, that's not the only alternative.
You could use "user=alice" for authentication in HTTP digest if, for
whatever reason, you prefer to have users authenticating as themselves
instead of using the shared appearance. That advantage is that users
don't need to know 2 username/passwords. The disadvantage is that you
need more infrastructure in the back-end to allow Alice to log in as
Boss with her own credential.
I was thinking that both model should be allowed. Like in most SIP
client today, you can put a different HTTP credential (if required).
Otherwise, it would default to the one used for registering (i.e., the
From).
So in both cases, there is no 3rd party registration per se (as per
the definition in 3261).
That was my thought
------------------------------------------------------------------------
*From:* Venkatesh [mailto:[email protected]]
*Sent:* Wednesday, July 15, 2009 09:36
*To:* Audet, Francois (SC100:3055)
*Cc:* Hutton, Andrew; Alan Johnston; [email protected]
*Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances:
Provisioningconsiderations
Sure, but it means the secretary is now using HelpDesk (or "boss"
in the example) credentials to register if you didn't have 3rd
party registration semantics?
Venkatesh
On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet <[email protected]
<mailto:[email protected]>> wrote:
Yes, of course HelpDesk could be the Boss instead.
------------------------------------------------------------------------
*From:* Venkatesh [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Wednesday, July 15, 2009 08:46
*To:* Hutton, Andrew
*Cc:* Audet, Francois (SC100:3055); Alan Johnston;
[email protected] <mailto:[email protected]>
*Subject:* Re: [BLISS]
draft-ietf-bliss-shared-appearances:
Provisioningconsiderations
Andrew:
Thanks for pointing it out. I missed the change as well.
Honestly, one of the main use cases for BLA/SLA was to
address a boss/secretary scenario. In these cases, the
secretary is really monitoring a "Boss" extension; so from
a "ownership" purpose, the AoR is really that of the boss
and not a "common" address.
Venkatesh
On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew
<[email protected]
<mailto:[email protected]>> wrote:
Indeed this getting interesting.
In version -02 the REGISTER in section 10.1 showed a
normal 1st party
registration by alice but -03 shows a third party
registration which is
a significant change.
I must admit I missed the text in -02 which stated
"Bob and Alice are in
an appearance group identified by Alice's AOR. Bob
REGISTERs using
contact sip:[email protected]
<mailto:sip%[email protected]>" and I should have
commented on that
earlier.
As the draft is about sharing appearances of a single
AOR then surely
third party registration is not necessary as it could
be that there is
simply two helpdesk phones using a single AOR and
there is no "alice" or
"bob" AOR's. So in the simplest case the REGISTER
would be:
REGISTER sip:registrar.example.com
<http://registrar.example.com> SIP/2.0
Via: SIP/2.0/UDP ua1.example.com
<http://ua1.example.com>;branch=z9hG4bK527b54da8ACC7B09
From: <sip:[email protected]
<mailto:sip%[email protected]>>;tag=CDF9A668-909E2BDD
To: <sip:[email protected]
<mailto:sip%[email protected]>>
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb
Contact: <sip:[email protected]
<mailto:sip%[email protected]>>
Regards
Andy
>-----Original Message-----
>From: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>]
>On Behalf Of Francois Audet
>Sent: 14 July 2009 23:30
>To: Alan Johnston
>Cc: [email protected] <mailto:[email protected]>
>Subject: [BLISS] draft-ietf-bliss-shared-appearances:
>Provisioningconsiderations
>
>
>> > Section 9:
>> >
>> > Delete first paragraph.
>> >
>> > Clarify the UA also REGISTERs to the AOR. Discuss the
>> security implications, i.e.,
>> > you either use the same shared username/password,
or you
>> use a different username/password
>> > for HTTP digest, per user. Perhaps the security
>> considerations can be described in section 15.
>> >
>> >
>>
>> I added text about authorization for third party
registrations and
>> publication. A little more text on this would be
helpful.
>
>Ah-ah... Now we are getting down to business.
>
>I am now looking at new section 10.1 on registration,
and I see that
>you are using indeed third-party registration (with
To=HelpDesk,
>From=Alice).
>
>So, this would be one way to to it.
>
>Another way would be to NOT use third-party
registration at all. In
>other words, Alice would send a first party
registration on behalf
>of HelpDesk (ie.., To=HelpDesk, From=Alice).
>
>Wouldn't that work?
>
>Then there is the whole issue of authentication with
HTTP-Digest.
>I guess one could use username="HelpDesk". In this
case, the
>idea is that
>Alice would need to know the credentials for HelpDesk.
>Another way would be to use username="alice" instead
(i.e.,
>her own credentials).
>The decisions on which authentication you use would
depend on
>need of the
>administrator.
>
>Have you tought about this? Am I off based?
>_______________________________________________
>BLISS mailing list
>[email protected] <mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
