Re: [reSIProcate] Pasring problem for URI with valueless gruu paramer in Contact Header
On Fri, Apr 25, 2008 at 3:16 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
>
> Yep, this is fixed in the gruu branch that I'm code-reviewing right
> now. I expect this to be fixed in main pretty soon.
Recently I have run into this gruu problem and I have checked the code
and realized that there might be a deeper problem here.
I assume that the gruu parameter was introduced in resiprocate
according to some earlier version of draft-ietf-sip-gruu that defines
gruu as a Contact header parameter. In some other versions gruu is
introduced as an URI parameter with different semantics, namely that
it is used as a flag and cannot have a value (we can see this usage in
the original post).
Resiprocate design has only one set of parameters that is used for
both NameAddr and Uri (in fact inherited from ParserCategory) and, in
cases like this where parameters with same name but different
semantics are declared for URIs and headers, this causes problems.
So I was wondering if the changes in the gruu branch will fix this
design problem or they just correct the gruu parameter handling.
OTOH it probably won't happen too often that parameters with the same
name are defined for sip URIs and SIP headers too. So just fixing the
gruu problem might be enough. Especially since fixing the design
problem doesn't sound to be easy.
Regards,
Zsolt
>
> > Hi, guys
> >
> > I believe that there is nothing wrong with having
> > parameter with no value in URI, but resiprocate failed
> > to parse the message with the following contact
> > Unhandled exception: ParseException
> > .\ParseBuffer.cxx:86, Parse failed expected '=' in
> > context:
> > Contact<sip:xxx@xxxxxxxxx;opaque=user:epid:X8tvrsgMJFqlZpaWUIQ-
> > BQAA;gruu>
> >
> > Is it because gruu parameter must have value?
> >
> > Thanks,
> > Boris