On Wed, Feb 25, 2009 at 9:39 AM, Gabor Paller <[email protected]> wrote: > " 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
Its a bit painful to explain on a mailing list but that is exactly what sipxbridge does. You may want to check out the design document. Please download the source code from svn and look at sipXbridge/doc/design.tar.gz The document is not 100 % done but its better than 90% done so you can understand it. Regards Ranga >> _______________________________________________ >> 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 > -- 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
