> >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. > >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 > >Ranga > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
