El Martes, 25 de Noviembre de 2008, vamshi dommeti escribió:
> Hi All ,
> Can any one explain which SIP header could be a better option for
> sending Caller-ID information .
>
> We have a SIP-GSM gateway on which we would like to send the Caller-ID
> information consisting of GSM Mobile Number (Remote Caller ) on to the
> SIP Callee side .
>
> I have googled and found that one of the following can be used for sending
> Caller ID .
> 1) In from header Display name Field.(e.g.
> From:"displayname"<sip:[EMAIL PROTECTED]>)
> 2) In p-asserted Identity header
> 3) In Remote-Party-ID header
Hi, whatever "cool" RFC's/draft's say, the fact is that most of SIP end points
(AKA "phones") use "From" header to render the CallerID to the *human* and
they ignore P-Asserted-Identity or deprecated "Remote-Party-Id" headers.
IMHO, PAI is usefull when sending a request to a gateway SIP/PSTN since,
typically, gateways understand PAI header and use its value as CallerID for
the PSTN leg. This is cool since your proxy doesn't need to change the From
header (that is "dirty").
But when the call comes from a PSTN/SIP gateway to our proxy and we must
deliver the request to our local users (typically phones or PBX's), I don't
use PAI because, as I said before, most of the end points ignore it and
render content of From header.
So, what I do when a request comes from a PSTN/SIP gateway to my proxy and I
must route it to a local user is:
- The gateway sends a request like this to my proxy:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: <sip:[EMAIL PROTECTED]>
P-Asserted-Identity: <sip:[EMAIL PROTECTED]>
- My proxy changes (if's needed) the From and deletes PAI and Privacy headers
(in case it exists):
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: <sip:[EMAIL PROTECTED]>
- So the end point receives a *normal* request without "exotic" headers that
just some SIP devices understand. The CallerID is clear:
sip:[EMAIL PROTECTED]
In case a call from PSTN arrives and the caller asked for privacy (hidden
CallerID) I would do:
- The gateway sends a request like this to my proxy. Note that since I'm a
telephony provider, I get the real callerid even if the caller asked for
privacy:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: <sip:[EMAIL PROTECTED]> <-- each gateways uses its "own" way.
P-Asserted-Identity: <sip:[EMAIL PROTECTED]> <-- Real CallerID.
Privacy: id <-- The caller asked for privacy.
- My proxy detects "Privacy: id" so it must hidde the real CallerID before
routing the requet to the local user:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
From: <sip:[EMAIL PROTECTED]>
- Again, the end point (not so "intelligent" as most RFC's suppose) receives a
*normal* request in which the CallerID is hidden (anonymous).
The above method will work in any scenario, but of course, it is not so cool
as RFC's expect (perhaps RFC's should wait a bit for *real* implementations).
Best regards.
--
Iñaki Baz Castillo
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
