[reSIProcate] RFC 3455 headers and parameters

[Dario Bozzali]

Hi Scott,
Following suggestions that John sent us in his mail, I created a patch file for new headers and parameters contained in RFC 3455.
Moreover I included changes for User-to-User header and corresponding parameters as indicated in draft-johnston-sipping-cc-uui-09 and draft-ietf-cuss-sip-uui-17 drafts.
I encountered some problems using gperf under Windows since I obtained an error using option -k "*" and I had to use --key-positions="*".
Could you please, or anyone else that is interested in these changes, have a look at attached patch file and give me your opinion?
Note that “purpose” parameter is already present since it is used for GenericUri, but not for Token, so in some place I commented it out.
Thank you in advance and best regards,
Dario.

From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of Scott Godin
Sent: venerdì 12 settembre 2014 14.51
To: Dario Bozzali
Cc: resiprocate-devel at resiprocate.org
Subject: Re: [reSIProcate] RFC 3455 headers and parameters

Hi Dario,

We haven't had the cycles to integrate these changes yet.  It would be great if John could provide a patch file.

Keep in mind you can always support headers and parameters that aren't officially called out in the stack parser by using ExtensionParamater and ExtensionHeaders logic.

https://www.resiprocate.org/Use_Overview#Extension_Header
https://www.resiprocate.org/Extending_the_stack

Scott

On Fri, Sep 12, 2014 at 8:31 AM, Dario Bozzali <Dario.Bozzali at ifmgroup.it<mailto:Dario.Bozzali at ifmgroup.it>> wrote:
Hi all,
I am interested in RFC 3455 and I was wondering if there are any news about integration of these features in main line.
John, if they will not be added to main line, could you please post the patch file?

I am also concerned about User-to-User information transport over SIP (draft-johnston-sipping-cc-uui-09, draft-ietf-cuss-sip-uui-17).
Could I use a similar approach to add support for User-to-User header in Resiprocate?

Thank you in advance.

Best regards, Dario.

-----Original Message-----
From: resiprocate-devel [mailto:resiprocate-devel-bounces at resiprocate.org<mailto:resiprocate-devel-bounces at resiprocate.org>] On Behalf Of John Gregg
Sent: lunedì 2 giugno 2014 22.03
To: resiprocate-devel at resiprocate.org<mailto:resiprocate-devel at resiprocate.org>
Subject: [reSIProcate] RFC 3455 headers and parameters


I changed the following files:

M       Token.cxx
M       ParameterTypes.cxx
M       Headers.hxx
M       SipMessage.cxx
M       HeaderTypes.hxx
M       ParameterTypeEnums.hxx
M       HeaderHash.cxx
M       ParameterHash.cxx
M       Token.hxx
M       Headers.cxx
M       HeaderHash.gperf
M       ParameterHash.gperf
M       ParameterTypes.hxx
M       SipMessage.hxx

All I did was add the following header definitions, where appropriate:

defineHeader(PAccessNetworkInfo, "P-Access-Network-Info", Token, "RFC 3455"); defineHeader(PChargingVector, "P-Charging-Vector", Token, "RFC 3455"); defineHeader(PChargingFunctionAddresses,
"P-Charging-Function-Addresses", Token, "RFC 3455"); defineMultiHeader(PVisitedNetworkID, "P-Visited-Network-ID", Token, "RFC 3455");

And the following parameters:

       defineParam(description, "description", QuotedDataParameter, "RFC 3840");
       defineParam(utranCellId3gpp, "utran-cell-id-3gpp", DataParameter, "RFC 3455");  // P-Access-Network-Info
       defineParam(cgi3gpp, "cgi-3gpp", DataParameter, "RFC 3455"); // P-Access-Network-Info
       defineParam(ccf, "ccf", DataParameter, "RFC 3455"); // P-Charging-Function-Addresses
       defineParam(ecf, "ecf", DataParameter, "RFC 3455"); // P-Charging-Function-Addresses
       defineParam(icidValue, "icid-value", DataParameter, "RFC 3455"); // P-Charging-Vector
       defineParam(icidGeneratedAt, "icid-generated-at", DataParameter, "RFC 3455"); // P-Charging-Vector
       defineParam(origIoi, "orig-ioi", DataParameter, "RFC 3455"); // P-Charging-Vector
       defineParam(termIoi, "term-ioi", DataParameter, "RFC 3455"); // P-Charging-Vector


I figured it would be less confusing to just describe the changes than to include diff files for all the files involved, but I can do that upon request. I think it would be a good idea to incorporate this change into the next resiprocate release, and I can't see a downside. I'm not completely sure that Token is the right object type to use for all of them, but it worked for me.

-John Gregg

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org<mailto:resiprocate-devel at resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org<mailto:resiprocate-devel at resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140916/c69eb92a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewHeadersAndParameters.patch
Type: application/octet-stream
Size: 62566 bytes
Desc: NewHeadersAndParameters.patch
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140916/c69eb92a/attachment.obj>