Thanks for all the good advice guys. We solved it by adding a tag to the Refer-To URI. The INVITE that eventually comes from the sipXBridge contained that tagged and our algorithm worked well.
We still need a generic solution that will work on all GW's, with and without sipXbridge, but we have good control over that now. Thanks again, Sven -----Original Message----- From: Dale Worley [mailto:[email protected]] Sent: 03 February 2010 16:55 To: Sven Evensen Cc: sipXecs users Subject: Re: [sipx-users] sipXbridge and REFER On Wed, 2010-02-03 at 10:18 +0000, Sven Evensen wrote: > The scenario is as follows: > > A calls B, B answers > > Our appl. sends a REFER to transfer from A to C > > The REFER has From : A, To : B, Refer-To : C, Referred-By : A > > When using unmanaged GW (Cisco IOS GW), it replies with > > INVITE From : B, To C > > sipXBridge replies with > > INVITE From : A*, To C > > > > A - 8116 (phantom user) > > A* - 01225581810 (DDI of A) > > B - 07795951717 (mobile) > > C - 8216 (phantom user) > > > > The question is: Is Cisco GW doing right or is sipXBridge doing right? > Or maybe both? As a general rule, the initial INVITE from A to B will establish the From/To URIs of the dialog, and when B sends the new INVITE to C, it will use as its From URI a URI which represents B in some way. Usually phones have an AOR for this purpose, but I suppose a B2BUA could create a URI based on what the "real" UA is on the "other side" of the dialog, or it can use the From/To URI that was used in the original dialog. In this case, sipXbridge seems to be using the From address of the original INVITE that it received, which isn't expected to describe B in any way. So that's a bug. All of this is qualified by the fact that the From and To URIs are understood to be unreliable and essentially of the nature of documentation. They certainly shouldn't be used for routing calls, as the originator of the call can deliberately or accidentally use a URI that is unrecognizable by the destination. If the referrer wants to control the routing of the INVITE from B to C, that should be done entirely by its request-URI, which is determined by the Refer-To URI of the REFER request. Depending on your application, a special user-part or a special URI-parameter are probably the best approaches. Dale _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
