[reSIProcate] SdpContents rewrite for supporting simcap (RFC3407)

[Zsolt Rizsanyi]

Hi!

We have recently changed from the Vocal SIP stack to resiprocate, and we 
are satisfied with it so far altough we only use it for parsing and 
encoding messages for now.

The most important reasons for the switch were being able to support new 
features. One of the ones we are going to implement is the simple 
capability support as specified in RFC3407 (and probably support for the 
older versions of the capabilities that used the X- prefix before the 
parameters).

Unfortunately I have found that it cannot be done with the current SDP 
implementation of resiprocate. The simcap specification relies on the 
order of the attributes, but resiprocate stores all parsed attributes in a 
hash map which does not keep the order.

I was thinking about adding a list beside the map to keep the order, but 
after some consideration I have decided that it would not work, because if 
attributes with the same key do not appear one after the other, then the 
map could not store them.

So I have decided to drop the map completely and only use a list of 
key,value pairs. This unfortunately means an interface change, but I 
suppose that the attribute map was mostly used for parsing the rtpmap and 
fmtp attributes and of course I have rewritten that part also, so most 
users of the stack won't need to change anything.
Note that the addAttributes method still works almost the same as before.

I'm attaching the svn diff of the change. I would like it if could get into 
svn repository. If you have some suggestions of improvements, then it 
would be good.

Also I have some questions about the coding style I have encountered:
- there are usually almost no comments, not even for the interface - Is 
that intentional, and if so, then where should/is the interface described.
- for some reason inline functions are not used almost nowhere, there are 
many cases where simple one liners are put in the .cxx file - Is there a 
reason for that? I would think that putting those in the header would 
allow more optimizations for the compiler without much negative side 
effects.
I tried to follow this convention, but I'm not sure if it was a good idea.

Regards,
Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdp_attribseq.patch
Type: text/x-diff
Size: 10065 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060128/efa441b9/attachment.patch>