On Wed, Jun 4, 2008 at 1:23 PM, Andy Spitzer <[EMAIL PROTECTED]> wrote: > Woof! > > On Wed, 04 Jun 2008 12:31:15 -0400, M. Ranganathan <[EMAIL PROTECTED]> wrote: > >> >> 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. > > I'd really like to see us crawl, before we think about landing on the moon.
In fact, this is pretty simple ( and besides, its already done and I am testing it). I see no reason not to do it with the recommendations of the RFC. We sipxconfig can at least report status right now and we can revisit the decision of what we want to do with that status later (i.e. bring up an email client, page the person, or maybe have a configurable set of rules for things like that ). > > If you really need some "sensible" behavor on call failure, then > use consultive transfer. That would be another way to do it but I don't view it as being simpler. Then the UI is in the loop for the destination call, > and can get out once the destination answers. Even in the blind transfer case, > isn't the result of the transfer sent to the originator as a SIP fragment via > NOTIFY? It should be. In that case yes, we can use the body of the NOTIFY to make some sensible error reporting. Out of the blue question : In your scheme, what would you do if the click to dial number is a ITSP supported number ( long distance ) ? I cannot send him anything but the usual INVITE, ACK, OPTIONS, BYE ( no REFER ) would that matter? > > --Woof! > -- 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
