[reSIProcate] Remote-Party-Id Header - Should it be a part of the Stack

[Mehul Jain]

The reSIProcate stack does provide support for "Ability to add new
header fields and parameters without rebuilding the stack" using
ExtensionHeaders but with the limitation that the new header will be of
type StringCategory. 

Im currently dealing with the "Remote-Party-Id" header that provides a
guarantee that even "Anonymous" SIP callers are identified in the PSTN
network based on provider-stored credentials. Carriers like Global
Crossing use this header to convey the ANI for calls where the SS7 and
ISUP to SIP mapping rules prohibit providing the ANI in the From header.

 
Remote-Party-ID is not described in any RFC. It is an old header (The
draft - draft-ietf-sip-privacy-04.txt supports Remote party ID). The
standards-based version of it is RFC3325, which defines P-Asserted-ID.
Softswitches that do ISUP-to-SIP mapping of calling line identity (CLI)
use the SIP Remote Party ID header or the P-Asserted ID header.
 
I wanted to add this header as a NameAddr  (want to use the URI features
etc.) for which I will need to modify the stack. 
I think this header should be a part of the reSIP stack since carriers
use it in regular messaging and pretty soon many folks using the reSIP
stack will need to use it too.
 
Mehul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070419/8120f85c/attachment.htm>