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]> wrote: > Yes, of course HelpDesk could be the Boss instead. > > ------------------------------ > *From:* Venkatesh [mailto:[email protected]] > *Sent:* Wednesday, July 15, 2009 08:46 > *To:* Hutton, Andrew > *Cc:* Audet, Francois (SC100:3055); Alan Johnston; [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]> 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] <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 SIP/2.0 >> Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 >> From: <sip:[email protected] <sip%[email protected]> >> >;tag=CDF9A668-909E2BDD >> To: <sip:[email protected] <sip%[email protected]>> >> CSeq: 2 REGISTER >> Call-ID: d3281184-518783de-cc23d6bb >> Contact: <sip:[email protected] <sip%[email protected]> >> > >> >> Regards >> Andy >> >> >> >-----Original Message----- >> >From: [email protected] [mailto:[email protected]] >> >On Behalf Of Francois Audet >> >Sent: 14 July 2009 23:30 >> >To: Alan Johnston >> >Cc: [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] >> >https://www.ietf.org/mailman/listinfo/bliss >> > >> _______________________________________________ >> BLISS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bliss >> > >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
