" It does the signaling translation from REFER to re-INVITE." How does it do it? What is the exact call flow of this translation?
I ask because in some scenarios REFER degenerate to 3pcc call control. For example: 1. User1 places a call to target1. Target1 is a PSTN number (handled by the SBC). 2. Call is established. 3. User1 transfers to target2. This will result in a REFER sent to the SBC. If the SBC does the translation, it must INVITE target2 then re-INVITE target1 so that the media stream is built between target1 and target2. Are RFC 3725 call flows used? Many soft phones have compatibility problems with those call flows. Regards, Gabor -----Original Message----- From: M. Ranganathan [mailto:[email protected]] Sent: 25 February 2009 14:30 To: Gabor Paller Cc: Tony Graziano; [email protected] Subject: Re: [sipx-users] Best practices for transfer On Wed, Feb 25, 2009 at 6:16 AM, Gabor Paller <[email protected]> wrote: > "Once the call is answered, your PSTN gateway shouldn't be involved in the > transfer process." > > > > Well, I understand it works like this (actually, I checked with my test > system and it does J. Devices: Snom300, Cisco 2651 ISDn router) > > PSTN gateway sends an INVITE to target1. > Target1 answers with OK to the PSTN gateway and establishes the call > Transfer starts. Target1 sends a REFER to the PSTN gateway with target2 as > Refer-To. > The PSTN gateway INVITEs target2. > > > > Since I sent the mail, we made it working with the Cisco. The solution > involved a new dial peer matching the short internal numbers. If the > destination pattern matches the internal numbering plan, the dial peer sends > back the call to SipX. This way the Cisco gateway can handle the internal > SipX users when they are targeted with Refer-To. > > > > Funny how much the Cisco gateway does not care about domains. > > > > I am interested in experiences with SIP trunks. Do I understand correctly > that the Ingate device handles REFER if the trunk is not able to? > > > > Regards, > > Gabor > Gabor, you may also wish to check out sipxbridge in 3.11. It does the signaling translation from REFER to re-INVITE. It is not production ready yet quite close. Ranga > > > ________________________________ > > From: Tony Graziano [mailto:[email protected]] > Sent: 25 February 2009 11:08 > To: [email protected]; Gabor Paller > Subject: Re: [sipx-users] Best practices for transfer > > > > Once the call is answered, your PSTN gateway shouldn't be involved in the > transfer process. When a call is transferred it is handled by the proxy, and > your UA's (phones, target1/target2) should be able to handle this procedure. > > If ANY call comes in from the PSTN and hits an AA, and then can transfer to > an extension successfully, it means your PSTN gateway handles the refer > properly. Once audio is established with a target, you should be able to > tarnsfer repeatedly. > > If it is a siptrunking device, Ingate for example, you should make sure the > ITSP supports the feature, and your SBC or siptrunk gateway does as well. > > I has "subsequent transfer failures" with an Ingate using a siptrunk, but > solved it here: http://track.sipfoundry.org/browse/XECS-2098 > >>>> "Gabor Paller" <[email protected]> 02/25/09 3:58 AM >>> > Hi, > > I am curious about the best practices for transferring external incoming > calls. > > The scenario is very common: Source (an external number) calls target1 > (an internal number, SipX user). Target1 transfers the call to target2 > (another internal number). This models a common case of a secretary > transferring calls. > > I understand that SIP-wise, the scenario depends on REFER request sent > from target1 device to the device representing the source. As the source > is a PSTN number, the device representing the source is either a gateway > or a SIP trunking equipment which don't know about the target2 internal > number. What is the best way of getting the gateway/trunking equipment > to know about target2? > > Regards, > Gabor > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > -- M. Ranganathan _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
