[reSIProcate] bug with encoding extensionHeaders on Power_Macintosh

["Bruce Lowekamp" <lowekamp@xxxxxxxxxxxxx>]

I've discovered a processor-dependent issue with how resip is encoding
extension headers when there are multiple fields of the same extension
header name (e.g.:

    m->header(h_Foos).push_back(resip::StringCategory("<first@header>"));
    m->header(h_Foos).push_back(resip::StringCategory("<second@header>"));

on Darwin.i386 will result in the (proper, as I understand 3261) one
header per line in the outgoing message:

FooID: <first@header>
FooID: <second@header>

but on Darwin.Power_Macintosh, the same code produces a (illegal, I
think) comma, separated header:

FooID: <first@header>, <second@header>

Both macs are running Tiger with all of the updates installed.  They
might conceivably have different ssl libraries in use, but I can't
imagine how that would affect anything.

Now, I wouldn't have ever noticed that this was illegal if, when it
parsed it, it actually split them into separate entries such that
header(h_Foos) could be iterated over, but it simply passes the entire
comma-separated string to the application.

I've managed to trace this to an improper setting for
Headers::isCommaEncoding(mType) in ParserContainerBase, although both
platforms have the same mType for the extension header. 
Unfortunately, I'm a bit unsure how to attack trying to debug this
setting in the Headers* macros, so I'm hoping someone else can take a
look at it.



There is also a (possibly related issue) that on the receiving side,
at the application level, the message is printed out with the two
headers comma separated, even though it was received from the wire
with the headers on separate lines, and parsed successfully into
separate items that can be iterated over.  I suspect this is a bug
with how received messages are encoded, but I haven't really tried to
track it down as I don't care that much about the results.

I get the same behavior on Linux.i686 (fedora core 4) as I do on Darwin.i386.

I did have to change a line in Tuple.cxx to get it to compile on
Darwin (doesn't have an s6_addr16 defined), but that's the only change
from svn head.

my configure options are:
gnu, debug, no (shared), no (distcc), no (ccache), no (DTLS), yes
(SSL), yes (popt), no (curl), no (google malloc), no (cpuperf), yes
(ipv6)

The smallest program I can come up with that demonstrates this bug is
below.  On the x86 platforms, the last lines it prints are the two
extension headers on separate lines, on the powermac, they're on the
same line.

I'm happy to spend some more time chasing this down, but if someone
else could duplicate it and/or give me some idea where to look, I'd
appreciate it.

Thanks,
Bruce

#include <resip/stack/SipStack.hxx>
#include <resip/stack/NameAddr.hxx>
#include <resip/dum/DialogUsageManager.hxx>
#include <resip/dum/MasterProfile.hxx>
#include <resip/stack/SipMessage.hxx>

#include <resip/stack/ExtensionHeader.hxx>

static const resip::ExtensionHeader h_Foos("FooID");


using namespace std;

using namespace resip;

int main(){
  SipStack mStack;
  DialogUsageManager mDum(mStack);
  SharedPtr<resip::MasterProfile> mProfile(new MasterProfile);

  mDum.setMasterProfile(mProfile);


  SharedPtr<SipMessage> m =
    mDum.makeOutOfDialogRequest(NameAddr("<sip:127.0.0.1>"),resip::MESSAGE);

    m->header(h_Foos).push_back(resip::StringCategory("<first@header>"));
    m->header(h_Foos).push_back(resip::StringCategory("<second@header>"));

    cout << "pre-send message is " << *m << endl;
}