On Tue, Nov 25, 2008 at 2:49 AM, Christopher Parfitt <[EMAIL PROTECTED]> wrote: > 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.
I guess we will need to bring up the re-INVITE issue with bt.com. If they can maybe tell us why they are sending 503 that would help. I'll send a wireshark capture to you. Ranga > > > > -----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 >> >> > > > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
