With mixed systems of ITSP and PSTN there is a problem with MOH: If MOH is turned ON for the sipxbridge and OFF on all the phones then any call to/from other Gateways e.g. Audiocodes ISDN PRI/BRI/Analogue/unmanaged SIP trunks then NO MOH will be heard for any of those transfer scenarios.
C. -----Original Message----- From: Steinmann, Martin (BL60:2500) Sent: 25 November 2008 02:10 To: M. Ranganathan Cc: Worley, Dale (BL60:9D30); sipx-dev; Parfitt, Christopher (MOP:9D30) Subject: RE: [sipX-dev] Why does bt.com return 503 on this re-INVITE > >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
