Re: [reSIProcate] Remote-Party-Id Header - Should it be a part of theStack

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	As long as you make sure to replicate the changes you make in each  
of HeaderTypes.hxx, Headers.hxx, HeaderHash.gperf, Headers.cxx,  
SipMessage.hxx, SipMessage.cxx, you should be fine. Running  
testParserCategories should highlight any problems. I'll look at your  
patch whenever I get a free moment, and test it out.

Best regards,
Byron Campen

> 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

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