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

[Byron Campen]

	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 at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf  
> Of Mehul
> Jain
> Sent: Thursday, April 19, 2007 2:22 PM
> To: resiprocate-devel at list.resiprocate.org
> 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 at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070419/35c6772c/attachment.bin>