Error parsing Contact like user@domain@x.x.x.x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 3, 2009 at 3:18 PM, Alexei Kuznetsov <eofster at gmail.com> wrote:

> On Fri, Apr 3, 2009 at 3:40 PM, Benny Prijono <bennylp at teluu.com> wrote:
> >> Contact: <sip:john at 10.0.0.24:55134>;expires=4
> >> Contact: <sip:john at example.com <sip%3Ajohn at example.com>@10.0.0.41:5070
> >;q=0.90;expires=31
> >>
> >
> > That's not valid according to the spec. Character "@" is not allowed in
> the
> > user part of URI, so it should have been escaped. FYI
> >
> > SIP-URI          =  "sip:" [ userinfo ] hostport
> >                     uri-parameters [ headers ]
> > userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"
> > user             =  1*( unreserved / escaped / user-unreserved )
> > user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
> > unreserved       =  alphanum / mark
> > mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
> >                      / "(" / ")"
>
> Oh yes, I completely understand that. I'm just trying to survive in
> such cases. Other SIP phone can register with the wrong Contact on the
> other computer, but with the same credentials. And pjsip will fail to
> do its job without even cooperating with that bad SIP phone directly.
> What we get is a failure to register just because some other phone
> registered with the bad Contact somewhere. I just thought it might be
> reasonable for pjsip to survive in such situations and not to be so
> dependent on that. What do you think?
>
>
Ah I see what you mean. Well if other SIP phones can handle that, then good
for them, their design allow them to cope with this situation (I'm thinking
late parsing would help with this situation). But unfortunately (in this
case) we don't have this, as the error occurs very early in the parsing
stage, and we don't have such thing as "hey this is a Contact header
registered by another UA so don't fail miserably if parsing fails on this
header", so yeah we'll fail miserably. We could probably add few hacks in
the parser to handle this particular situation, but that will just be,
hacks. A "proper" solution would need quite major re-engineering. On the
other hand, this is a bad SIP message, so while of course it is nice to be
able to handle this, IMO we don't have to, or at least it's not wrong if we
can't handle it. So from my side, while I'm putting this in my list of
"things to do when you have absolutely nothing to do", I'd say I probably
won't implement this in some near future.

What SIP server are you using, if you don't mind telling.

cheers
 Benny





> Alexei
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090406/f03de5eb/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux