On Wed, 2010-02-03 at 11:54 -0500, Dale Worley wrote: > 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.
I don't think so - at least not in the sense that it's something we need to change. In order for the sipXbridge to construct a To/From field value that reflected what was on the 'other' side, it would have to either wait for some response from the other side (which would almost certainly mean breaking the rule of sending a 100 response within 100ms), or it would have to change what it sent later (which would require a dialog-updating transaction, and might not be supported well by phones anyway). Add to that the complexity of keeping it correct when calls are transferred and the inherent problems with To/From headers essentially being just decoration that can't be used for routing anyway (which you pointed out), and I'm lead to the conclusion that there's nothing here that needs fixing. _______________________________________________ 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/
