The goal of the IETF standard is to fix a broken and problematic function within the standards. On hold at 0.0.0.0 doesn't really cut it. When you are trying to centrally manage a phone system with 500 users, you need standards that you can use to your advantage and will let the UA direct the MOH to a central media server, which might be very specific (i.e per user, group or branch), because this is what we get with the IETF draft. It also brings the UA of of the media stream, which is woefully inadequate (especially in a remote user situation). The IETF draft is also fully set to take advantage of sips: It is much more scalable and places far fewer resources in action with the UA..
Remote users streaming MOH from their PC to a call that came in at the HQ, then the UA trying to make an internal call to handle and perhaps transfer the call. So you have a remote UA with multiple media streams chewing up their remote connection. Then you have to worry about remote user bandwidth quality and latency... When you look at the goal of the IETF draft, it makes a lot of sense to centralize it. I think sipxbridge does an adequate job if you are using an adequate phone (we put out polycoms in most remote environments), so we just don't have this issue. The point is that sipxbridge does this for TRUNKS. What is does for remote users is pass it to the proxy, which refers it to the media server. I'm not sure how sipxbridge works with Audiocodes, as we use Patton gateways in most installs. If the customer needs a MOH solution for softphones, and SBC with that capability should be investigated. There are so many shortcoming with CounterPath interoperability in general, I don't think they are a good example. Spending 20-30 hours with each build of Bria to learn it still has issues and not get adequate support for known bugs is not my idea of a good expenditure. I don't think in an enterprise environment it makes sense to expose the user to being able to change the MOH file on the softphone directly. Perhaps exposing that to the user in their sipxconfig interface like is available for polycoms, but not somewhere it is not centrally provisioned or backed up, would get a lot of traction. But still, they UA is anchoring media that is shouldn't have to anchor. It's like coming to work in rayon bell bottoms (some people still think disco is cool). At some point the disco clothes should just be burned. I think any softphone could support different types of MOH. They just haven't been pushed to go out of that ZERO comfort zone. Now, since sipxbridge is OUT of the picture here, realize this is a function of the trunk or gateway. Even with an ingate I can specify a MOH URI. What does your Audiocodes support, since that is what you have... (hint: sipxbridge has nothing to do with remote users, there is a separate media relay in sipx for remote users), so stop thinking sipxbridge and start thinking UA or GATEWAY in your call flow example... These are just my opinions though. It's been a rough week and it's only Monday. Single malts on me! On Mon, Mar 19, 2012 at 5:51 AM, Emilio Panighetti <[email protected]> wrote: > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > In-Reply-To: <CAMgKNJWLqN6DBOUnSnJ2DtOeA= > [email protected]> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66690> > Message-ID: <[email protected]> > > > > Tony, > > Keep in mind the specification you're referring to is a > draft; incidentally drafted by sipXecs authors, and as such > is has limited support, because it's not a standard at this > point. > > To Counterpath's defense; the most common scenario is to let > the 'core' handle MoH feature: The phone signals the server > that it wants to put the call on-hold with "a=sendonly" or; > the legacy method of "m=0.0.0.0" that only works on IPv4. > The core then can decide whether to refer the media to the > MoH stream instead of actually putting the call on hold. > This is what sipXbridge does; when present. > There are some merits in letting the 'PBX' decide what to do > with a call on-hold. For example; if the phone is using a > conference bridge; it's preferable to actually put the call > on-hold rather than redirecting to the media server. The > local phone has no way of knowing if it's in a conference > call; but the core server can. > I believe Polycom and others supports this; but as a phone > feature rather than a SIP standard. > Since sipXbridge does support this among other features; I > think it would be beneficial to have sipXbridge enabled as > part of the core services; but without having to necessarily > route media. I think that for most but the largest > deployments, this can be handled by a single server as long > as it lets other devices handle NAT traversal and media > routing; but I don't know if it's currently possible to set > sipXbridge this way. > > Of course; this is just my personal opinion. > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
