On Wed, Feb 3, 2010 at 12:13 PM, Scott Lawrence <[email protected]> wrote: > 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.
Thanks Dale and Scott for the analysis. Since this is a gray area, I will refrain from making any changes in the short term. I did things this way to allow for the right caller-id to show up (or what I considered to be "right" ). Perhaps we need an override ( configuration parameter) for this behavior that we can consider in 5.0 > > > > _______________________________________________ > 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/ -- 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 sipXecs IP PBX -- http://www.sipfoundry.org/
