Absolutely bizarre. Now, see... we were originally handling it the way you're
handling it (and it didn't work).
I tried it as a separate block, though (as you described) and it works like a
charm. Thanks a bunch, Evan.
Now I have to go through and figure out why it wansn't working the other way.
N.
On Thu, 17 Aug 2006 10:18:10 -0400, Evan Borgström wrote
How are you handling the MESSAGE packets? You should
be able to
simply do;
if (method == "MESSAGE") {
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
t_relay();
break;
};
It all really depends on your config. We don't handle MESSAGE
explicitly, instead we explicitly handle methods that require special
handling (INVITE, REGISTER, etc) and then all other messages pass
through the bottom of route[0] which looks like:
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
}
t_relay();
-Evan
sip wrote:
> That appears to be exactly what's happening.... it loops because there
doesn't
> seem to be any part of the code where MESSAGE is handled. It's ignored by the
> t_relay, and doesn't have a specific handling block of any kind, so it's
just
> looped around until it's too big to deal with.
>
> I just don't know what portion of the code is SUPPOSED to handle it, so I'm
> not sure where to go about looking for the source of why everything
ignores
it.
>
> N.
>
>
> On Wed, 16 Aug 2006 14:32:41 -0400, Andres wrote
>> sip wrote:
>>
>>> There is a check for message size (which is the same as it's always
>>> been):
>>>
>>> if (msg:len >= 2048 ) {
>>> sl_send_reply("513", "Message too big");
>>> break;
>>> };
>>>
>> Why don't you capture the SIP packet with Ethereal an verify if it
>> is indeed greater that 2048 bytes. I really doubt it. I suspect
>> your packet is looping several times on the same SER and growing in
>> size as more headers are added until it eventually reaches this huge
>> size.
>>
>>> Modifying this has no real effect on the return, and the MESSAGE being
>>> sent shouldn't in any way have gone beyond that size. That check's
>>> always been there, though, and I know this has worked before... so I'm
>>> wondering what might have changed, if anything... or if there's a
>>> 'standard' way of handling SIP MESSAGE methods that I'm
completely
>>> missing.
>>>
>>> N.
>>> *
>>> *
>> --
>> Andres
>> Technical Support
>>
http://www.telesip.net
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
>
http://lists.iptel.org/mailman/listinfo/serusers