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

Reply via email to