On Sun, 2009-12-13 at 11:12 -0500, Gertsvolf, Mark (CAR:9D30) wrote:

> I think I see an inconsistency in the CallerID behavior for external
> calls.
> Assuming I am using gateway A with "specify CallerID" option, which
> translated into wildcard entry for the gateway domain.
> A call from whate...@sipxdomain routed to the gateway gets the CallerId
> overwritten.

> If I have an analog/digital gateway (such as Audiocodes), I receive a
> call from PSTN and send it to gateway A. Audiocodes formats the "from"
> header as <PSTNCaller>@<sipXdomain>. Since the caller domain is local
> the caller ID rewrite takes place.
> 
> Compared to that if I receive a call from SIP trunk gateway B (B may be
> the same as A) sipXbridge formats the "from" header as
> <ITSPCaller>@<gatewayBdomain>. Since the caller domain is NOT local the
> caller ID rewrite does NOT take place.
> 
> Can this inconsistency be resolved simply by setting the sipXdomain in
> the "from" header rather then using the gateway domain? Are there any
> other reasons why the gateway domain is used?

Hmmm... I suspect you'll disagree with me, but I think the right way to
resolve that inconsistency is to not rewrite the caller whose gateway
used the proxy domain in its From header.  The intent of the caller-id
rewriting was to only rewrite the addresses of local users; at the time,
the best approximation of that we had was to base the choice on the From
header domain.  Since we now have authentication for all local callers,
we could change that part of the decision from 'if the From header
domain is our domain' to 'if the caller is authenticated as a local
user'.

> Another problem with wildcard CallerId rewrite as it is related to
> multiple ITSP accounts with the same domain: If more then one SIP trunk
> gateway with the same domain use "specify CallerID" option then the two
> settings clash. The key of the CallerId wildcard entry is domain and two
> SIP trunk gateways with the same domain result in two colliding entries
> in caller-alias.xml database.

That's a known issue - I don't have the tracker id handy, but I'm pretty
sure there is one.



_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to