On Wed, Jun 4, 2008 at 1:29 PM, Damian Krzeminski <[EMAIL PROTECTED]> wrote: > M. Ranganathan wrote: >> On Wed, Jun 4, 2008 at 12:17 PM, Andy Spitzer <[EMAIL PROTECTED]> wrote: >>> Woof! >>> >>> On Wed, Jun 4, 2008 at 10:56 AM, Damian Krzeminski <[EMAIL PROTECTED]> >>> wrote: >>>> Naive question warning. >>>> I thought that all sipXconfig would do is to initialize the call. Why >>>> would it restrict or change anything with regard to what you can do with >>>> that call? >>> On Wed, 04 Jun 2008 11:10:36 -0400, M. Ranganathan <[EMAIL PROTECTED]> >>> answered: >>>> The 3pcc controller is going to follow the recommendation of flow 4 >>>> that is defined in http://tools.ietf.org/html/rfc3725 >>>> >>> Super naive question double warning: >>> >>> For click-to-dial, I think it makes more sense to originate a call to the >>> user's phone, >>> and once answered do a blind transfer (REFER) to the destination. That >>> drops the >>> "3pcc controler" out of the loop and everything acts from then on as if the >>> phone >>> originated the call. >>> >>> Even nicer is doing an AutoAnswer call to the user's phone, so it just >>> magically >>> goes off hook, then is magically dialing the destination. >>> >>> What is the reason for using the more complicated B2BUA arrangement of flow >>> IV? >> >> 1. The controller gets to report errors better to the person who >> clicked the call setup link. >> >> 2. It would be possible to do something sensible when the phone on >> the other end reports an error - for example, if the phone is >> disconnected or reports BUSY HERE, bring up an email client. I know >> this is not planned but I think it is an interesting possibility. >> > > But is it really worth the price of having sipXconfig up and running > during the call. The nice thing about sipXconfig now is that you can > restart or even stop it without seriously impacting the system > functionality.
Indeed, if you restart sipxconfig, the ongoing call will be impacted when one needs to signal the other side. Why would you want to restart sipxconfig any more than you would want to restart a standalone controller? You can do all kinds of interesting things by staying in the loop. I would imagine it would be worthwhile making it a standalone service. For example, without user intervention, do things with a configurable rule set could open up interesting possibilities. Why not exploit such possibilities, even if at a later date? > If "staying in the loop" is really required I'd prefer a small, easy to One can stay out of loop at the expense of later functionality, using the scheme proposed by Woof! > maintain, independent service performing this feature when requested by > end user portal. > D. > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
