Martin Steinmann wrote: >> On Mon, Nov 24, 2008 at 6:58 PM, Martin Steinmann > <[EMAIL PROTECTED]> >wrote: >>>> >>>> BT.COM : >>>> >>>> By experimentation I have been able to conclude: >>>> >>>> 1. Does not handle REFER although it claims to do so on the basis of >>>> Allow: ( sends BYE right away and no RE-INVITE if I send him the >>>> REFER). >>>> 2. Does not handle codec renegotiation unless I do SDP answer in ACK >>>> before sending a re-invite ( why? ) >>>> 3. I have also found bt.com gives you only about 20 seconds of > ringing >>>> before it hangs up. >>>> >>>> >>>> CONCLUSION: BT.com will only work correctly for all call flows if >>>> sipxbridge handles the transfer. To effect this you have to turn OFF >>>> MOH on the phone and turn it ON for the bridge. Other configurations >>>> will not work for all transfers and besides you will get dead air > when >>>> the transfer target is ringing. You must also turn OFF RTP Keepalive >>>> or your call is dropped when doing the transfer ( media bridge on >>>> their end cannot deal with RTP packets it does not recognize ). >>>> >>> How are we going to either automate or clearly explain dependencies > such >>> as "For BT you have to turn MOH OFF on the phone"? >>> --martin >> >> In general, for ALL ITSPs, since none handle REFER, the requirement is >> that for them to work, without dead air when the phone is ringing on >> blind transfer, you must turn on MOH for the bridge and turn off MOH >> for the phone. This fundamentally changes the way in which the phone >> behaves and allows sipxbridge to handle the transfer. That is the >> recommended configuration. > > That is the fact the admin needs to be told. >
There is currently no easy way to turn the MoH for all the phones. The system default is to configure it for every phone type that supports it. Telling admin to disable it is not going to be a big help. Implementing global MoH off/on switch might be marginally better, but even that does not improve user experience much: calls that are not routed by sipXbridge (local and PST calls) will not have MoH at all. > >> Well behaved ITSPs will work in other configurations ( i.e. MOH turned >> off on both or just on one or even on both if you dont care about >> garbled MOH under certain circumstances), but in the case of BT.com, >> it fails for caller initiated transfer unless you have MOH support >> disabled on the phone and enabled on the bridge, thus forcing the >> phone to interact with the bridge for the transfer and thereby >> allowing the bridge to handle the transfer. I am sure if I tweak >> enough I can improve on this restriction but the correct solution is >> to have BT address the problem with re-INVITE processing for PBX >> initiated blind transfers of outbound calls. I will communicate this >> to their engineer. >> >> >> >> To communicate this configuration clearly to end users : I suggest >> that in the ITSP template for bt.com we place some configuration hints >> (i.e. words) in the wizard page to this effect. > > Could you open an issue on this? Are there other such cases we need to > document in the form of a help text? How about mixed configs with SIP > trunks and traditional PSTN GWs? > --martin > I think we should add an issue for turning MoH support on and off globally - but it's a bit more complicated than just adding a warning on the page. 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
