Re: [reSIProcate] Remote-Party-Id Header - Should it be a part of theStack
Byron,
I have a fair idea of the changes required to add a new header to the
stack. I can make the changes and submit them or send the changed file
to you.
Mehul.
-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Thursday, April 19, 2007 11:54 AM
To: Justin Matthews
Cc: Mehul Jain; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Remote-Party-Id Header - Should it be a part
of theStack
Well, if possible, we should probably add native support
instead.
This can be a temporary workaround until someone who knows how to do
this comes free. (We have some catch-up to do regarding headers and
parameters, so at some point I may take on this task)
Best regards,
Byron Campen
> Mehul,
>
> The following should work. Others can comment on if this is correct
> usage of the stack.
>
> //http://www3.ietf.org/proceedings/02mar/I-D/draft-ietf-sip-
> privacy-04.txt
> //Extensions for this expired draft:
> static const resip::ExtensionHeader h_RemotePartyId("Remote-Party-
> ID"); static const resip::ExtensionParameter p_rpi_screen("screen");
> static const resip::ExtensionParameter p_rpi_pty_type("party"); static
> const resip::ExtensionParameter p_rpi_id_type("id-type"); static const
> resip::ExtensionParameter p_rpi_privacy("privacy");
>
> -------
>
> if( true == msg.exists(h_RemotePartyId) ) {
> resip::StringCategories rpid = msg.header(h_RemotePartyId);
> if( false == rpid.empty() )
> {
> resip::NameAddr resipNameAddr(rpid.front().value());
>
> resip::Data params;
> if( resipNameAddr.exists(p_rpi_screen) )
> {
> params+=p_rpi_screen.getName();
> params+="=";
> params+=resipNameAddr.param(p_rpi_screen);
> params+=';';
> }
>
> if( resipNameAddr.exists(p_rpi_pty_type) )
> {
> params+=p_rpi_pty_type.getName();
> params+="=";
> params+=resipNameAddr.param(p_rpi_pty_type);
> params+=';';
> }
>
> if( resipNameAddr.exists(p_rpi_id_type) )
> {
> params+=p_rpi_id_type.getName();
> params+="=";
> params+=resipNameAddr.param(p_rpi_id_type);
> params+=';';
> }
>
> if( resipNameAddr.exists(p_rpi_privacy) )
> {
> params+=p_rpi_privacy.getName();
> params+="=";
> params+=resipNameAddr.param(p_rpi_privacy);
> params+=';';
> }
> }
> } ________________________________________
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
> Mehul Jain
> Sent: Thursday, April 19, 2007 2:22 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] Remote-Party-Id Header - Should it be a part of
> theStack
>
> 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.
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel