Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Organization: SipXecs Forum In-Reply-To: <CAMgKNJWLqN6DBOUnSnJ2DtOeA=drtpjnbd+2rphsp1pe+kl...@mail.gmail.com> 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/
