On Thu, 2010-02-18 at 12:37 +0530, Naveen Krishna wrote:
> Hi All 
> 
> This is the query regarding call details of URL dialing .
> 
> Consider the scenario - User "206" (registered to SCS machine1) calls
> user "144" (registered to SCS machine2) through URL dialing .
> Call details for the above call are displayed as follows ,
> 
> 
> 
> Query : Here 206 is the user of SCS machine1 (not SCS machine2) , but
> there is no indication in the CDR table to show that this is an
> outside user . This "From" user detail confuses the administrator and
> also user . IMHO CDR should display user with FQDN (for URL dialing),
> then it will be easy to find out the outside user .
> 
> Please let me know if I am wrong here , else I will raise an issue for
> the same .

The general issue here is that the CDR display is always removing the
domain part of the address, whether or not that domain matches the local
domain.

It makes sense to remove the local domain, because normally that leaves
the local user part, which is usually a number - exactly what CDR
readers expect to see.   

The real address (which is in the underlying CDR database record) is the
fully qualified SIP URL (sip:u...@domain).  It might make sense to only
remove the domain part if it matches the local domain - that would
prevent the confusion you demonstrated, but it's probably not quite that
simple.   When calls are coming from a gateway or an ITSP, they will
normally have a PSTN address in the user part, and so removing the
domain part produces a human-friendly display.

The right solution is probably to either have some explicit list of
domain parts that are to be removed for display, or to develop some
heuristic for recognizing them.

File a Minor issue with a summary something like "Removing domain in CDR
display can produce ambiguous results".


_______________________________________________
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