Nortel 1200 IP Phones also use the conference feature in the same fashion. If the "Conference Server URI" field is set on sipXconfig/Phone GUI, 1200 phone can do N-way conferencing using the conference service URI. For more details please refer Page 49 of the following document: http://www142.nortelnetworks.com/mdfs_app/enterprise/SCS/3.0/1200_SIP_UserGuide_NN30001-001.pdf
Thanks, Tarru Naval Vashistha ipDialog Support ----- Original Message ----- From: "Paul Mossman" <[email protected]> To: <[email protected]> Sent: Wednesday, September 23, 2009 7:24 PM Subject: [sipX-dev] Polycom centralized conference feature > Hi all, > > Polycom has suggested that we make use of their centralized conference > feature. > > A Polycom configured with a conference bridge URI will start conferences > on that bridge, instead of locally, when the user presses the > 'Conference' button/softkey. One advantage of centralized over local > conferences is that the number of participants is not limited by the > Polycom's resources. (Currently 3 or 4 total participants, depending on > the Polycom model.) > > > Here's a user story: User A is in a call with User B, and they decide an > ad-hoc conference is in order. User A calls User C, then joins the two > calls with the 'Conference' button. All users are then connected to > User A's conference bridge. User A can then pull in more participants > by dialing them directly, and joining then after consultation. (Some > users would prefer this to the user portal invite, see > http://list.sipfoundry.org/archive/sipx-dev/msg17880.html.) A's user > portal can of course also be used to control the conference. > > > We could implement a very basic version of this with relatively little > work in sipXecs (see XX-6576): > > 1. When a user is the owner of a conference bridge, then profiles of all > Polycoms assigned to that user will automatically have > 'voIpProt.SIP.conference.address' set to the bridge URI. > > 2. The Contact header in INVITE responses from the conference bridge > will need to have the "isfocus" tag. > > > I refer to this as a basic version, because the usability suffers when > the conference bridge is protected with a PIN. All participants > entering the conference will need the PIN. But you would expect > participants pulled in by the conference owner to be joined directly, > without being prompted for the PIN. > > > This could be solved I'm sure, but it would be challenging. Here's why. > A Polycom with two established calls starts the Conference by sending an > INVITE to the bridge. That call is established when the bridge returns > an OK. The Polycom then Blind Transfers (REFER without Replaces) the > two other parties to the Contact from the bridge OK. > > We want the two REFER'd parties to enter the conference without a PIN. > It may be helpful if the bridge OK uses an obfusticated Contact in lieu > of a PIN. But the main challenge is that the owner is prompted for the > PIN only after the call has been established. That is, the other > participants are REFER'd (and will surely have sent their INVITEs) > before the conference owner has been authenticated. > > The two non-owner INVITEs will need to become established calls before > the conference starts. They should be "held" (with MOH) and then put > into the conference only after the owner has entered the PIN. > > > Thoughts? > > > -Paul > [email protected] > > > > > > > > -Paul > [email protected] > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.112/2390 - Release Date: 09/23/09 05:52:00 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
