reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature