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/

Reply via email to