Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Organization: SipXecs Forum In-Reply-To: <CAMgKNJW=_gtfevracaaz6pqbx9-yria5ofpjenafassmplf...@mail.gmail.com> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66702> Message-ID: <[email protected]>
Tony, a=sendonly is part of RFC 3264; which I understand Bria supports. My reference to the M line was to a previous post whixh mentions that it's *also* supported by the softphone. I agree that the phone should not be handling the MoH stream itself; I'm not sure how my post was interpreted that way, but from previous experiences; the core proxy device that handles MoH can achieve it by rewriting the SDP in the INVITE; so the new SDP points to a media server. instead of forwarding the sendonly attribute. Of course in practice it's more complicated than that. Then, I don't understnad how MoH can be a function of the trunk. This is the device receiving the call; and MoH is a decission of the far end user (Or PBX in this case). As an analogy, my PSTN line does not play my choice MoH if a remote caller puts me on-hold; not should it. Putting this functionality on sipXbridge cna still be considered part of the core proxy; from the perspective of the terminating carrier or terminating gateway; who sees sipXbridge as its originator. The fact that sipXbridge handles this with any phone that's able to send an SDP with a sendonly attribute and with any unsuspecting; but standards compliant SIP termination device or carrier; means that's a workable practical solution. The caveat is that sipXbridge is doing a lot more than asked for (media routing and NAT traversal) that cannot be unbundled. >From a more pragmatic perspective, I think the signaling (NAT) traversal could be separated from media routing. So, to me; the phones SHOULD support the 'hold' feature (a=sendonly); but I think it's an undue burden having to be provisioned to support MoH. A Polycom phone is centrally provisioned and a fully configured provisioning XML for these phones often exceed 3000 lines of code; that are managed and pushed by the central server. A softphone only requires basic connectivity parameters and not necessarily have to be centrally provisioned; and for the most part works just fine by entering authentication credentials. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
