Subject: [SIP] More arbitrary limits

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Sep 2000 17:57:32 -0400

Folks,

It has just come to my attention that the vendor of a shipping SIP based
system has SIP UAs that barf when a message arrives with more than 9 Via
headers.

Again, I cannot emphasize enough how much of a recipe for disaster this is.
The system will work for small to mid size deployments, and then, all of a
sudden, once we are really rolling, completely break in the middle of an
operational deployment.

I suggest we add this to the torture tests at the bakeoffs.

Thanks,

Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Fri, 29 Sep 2000 10:00:10 +0530

Jonathan,
in principle I agree with you.
However, I would like to know what exactly you connotate by 'barf' - does
it mean the UA crashes, or does it mean it
gracefully declines ?

I have worked with people on the embedded side who simply cannot allocate
more than Xk for SIP messages and
by policy, their application rejects any message greater than this, by
returning a message too long bad response( I think its a 413). While this
may not be desirable, at times it can be a practical limitation.

If the UA crashes, I would say its certainly a no-no. If it declines by
saying 'sorry, I can't handle your message', then its certainly
a scenario that should be still in line. I would say that this approach is
still inter-operable .

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 09/29/2000 03:27:32 AM

To:   "[email-masked]'"
      <[email-masked]>, "'sip (E-mail)'"
      <[email-masked]>
cc:

Subject:  More arbitrary limits

Folks,

Thanks,

Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Sep 2000 11:28:59 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 29, 2000 12:30 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; 'sip (E-mail)'
> Subject: [SIP] Re: More arbitrary limits
> 
> 
> 
> 
> Jonathan,

Not sure. Either way the call is not established.

> may not be desirable, at times it can be a practical limitation.

Well, I would encourage them to set X to at least 2 or 3 for now. SIP
messages are getting bigger all the time.

In any case, that is different from the arbitrary limit imposed on a
particular header. In this case, requests were being rejected (or causing
the system to crash or something) even though the total length was within
reasonable bounds.

> a scenario that should be still in line. I would say that 

Not really. Interoperability means that communications is successfully set
up. It has not been here.

-Jonathan R.
---

---

From: [email-masked]
Date: Sat, 30 Sep 2000 17:04:36 +0530

arjun>>> I have worked with people on the embedded side who simply
arjun>>> cannot allocate
arjun>>> more than Xk for SIP messages and
arjun>>> by policy, their application rejects any message greater than
this, by
arjun>>> returning a message too long bad response( I think its a
arjun>>> 413). While this
arjun>>> may not be desirable, at times it can be a practical limitation.

jdr>> Well, I would encourage them to set X to at least 2 or 3 for now. SIP
jdr>> messages are getting bigger all the time.

jdr>> In any case, that is different from the arbitrary limit imposed on a
jdr>> particular header. In this case, requests were being rejected (or
causing
jdr>> the system to crash or something) even though the total length was
within
jdr>> reasonable bounds.

Agree here. As I mentioned in a prev. mail, per header limits is imho,
unjustified.
Per message, well, that you can't do without in many cases.

arjun>>> If the UA crashes, I would say its certainly a no-no. If it
arjun>>> declines by
arjun>>> saying 'sorry, I can't handle your message', then its certainly
arjun>>> a scenario that should be still in line. I would say that
arjun>>> this approach is
arjun>>>> still inter-operable .

jdr>> Not really. Interoperability means that communications is
successfully set
jdr>> up. It has not been here.

Actually yes - however  if a client does not accept a message > Xk,it is
still SIP compliant.
As long as it can move back to a steady state giving the other side a valid
protocol message saying why it failed.
I think 'compliant to SIP' would have been  a more appropriate term for me
to use, rather than 'interoperable'. In this case its just the client
policy to say msg>X is a reject.

(Note that I am not talking about this specific case of that vendor's
client barfing )

Regds
Arjun