Hmm.. What you say about length is correct and I totally agree with you. I have also seen rather different lengths, contents of the SIP headers depending upon the vendor/ implementation and that’s why I wanted to have other’s views on this.
Also, w.r.t API design and its parameters, I tend to minimise the argument list to put all intelligence/ automation inside the library and API signature should be as simple as possible. And hence my concern about the length parameters. However, I guess their is no other way than to ask API USER to provide the length as well. A bit-of pain but required for stability of the API (otherwise maintenance is a pain:( ) Thanks, Arun PS: It might be possible to write a configuration-reader wrapper on top of the APIs i.e. function pointers for API-User to implement to handle the implementation specific configurations. But it is very crude idea for now. That’s for later on, if required... On 13/11/15, 6:19 PM, "Joel Gerber" <sip-implementors-boun...@lists.cs.columbia.edu on behalf of joel.ger...@corp.eastlink.ca> wrote: >Hello, > >If you are expecting the user to supply the entirety of the To/From headers, >than the only thing you can do is require the user to provide the length of >each so that you can assign memory storage within your object/function >appropriately. As Brett has said, and I have experienced in the field, you >cannot make any assumptions about the lengths of ANY SIP header field. I have >seen From headers get rather large because some implementations will include >uri-params and like to use rather large from-tags. > >For name-addr and addr-spec, it would probably be easier to make some sane >approximations, but you have to consider that the standard does not impose any >limit on these either. I would say the user of your API should be the one >cognizant of lengths, and provide them to your API appropriately. > > >Joel Gerber >Network Operations Specialist - Telephone >Telephone >Eastlink >joel.ger...@corp.eastlink.ca T: 519.786.1241 > >-----Original Message----- >From: sip-implementors-boun...@lists.cs.columbia.edu >[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Arun Arora >Sent: November-13-15 7:35 AM >To: Brett Tate <br...@broadsoft.com>; sip-implementors@lists.cs.columbia.edu >Subject: Re: [Sip-implementors] Max length of To/ From headers > >Hmm.. That’s true, ‘No max should be there’ to support inter-op. > >However, for API design, I guess their is no way other than asking API-User to >Provide the length of Strings for To and From. > >I am designing the API to receive the To/ From header in form or 'name-addr' >or 'addr-spec' in order to avoid accessing any local db for getting >domain-name to use in To/ From. > >The motivation is to make the library as much agnostic as possible from the >local configurations saved in the implementation specific data-bases/ config >files. > >Any thoughts…? > >Thanks, >Arun > > > > >On 13/11/15, 5:58 PM, "Brett Tate" <br...@broadsoft.com> wrote: > >>> Is their any specific length of To/ From header defined by the >>> standard >> >>No. >> >> >>> In case no specific length is defined, is their any common-practice >>> for max length? >> >>RFC 3261 section 18.1.1 might provide you some guidance for message >>size minimums to support. The common practice is not cap the >>individual header sizes unless using really high maximum. From an >>individual header perspective, the Via, Call-ID, Route, Record-Route, >>and Contact tend to be larger than implementations originally might >>think (especially when using comma-separated format); thus vendors >>attempting to use maximum below 256 bytes for comma-separated segment >>usually have to increase their caps for interoperability reasons. > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors