Subject: [SIP] Re: About Proxy-Supported and Proxy-Unsupported

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Jun 2000 15:25:45 -0400

[email-masked] wrote:

> What do you think about Proxy-Supported and Proxy-Unsupported
> headers to be included into 2543bis ?
> 
> The syntax would be similar to Supported header.
> 
> We will very likely need those (at least Proxy-Supported) in 3G
> registration.

This isn't quite symmetric to Require. Would proxies add or subtract
features from the "Proxy-Supported" and "Proxy-Unsupported" list?
(Presumably subtract and add, respectively...) Would only those proxies
that are on the record-route be allowed to do this? 

> Best Regards,
> --
> Petri Koskelainen
> Nokia Research Center

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2000 16:14:46 -0400

> that are on the record-route be allowed to do this?

We discussed these and other issues in the past on the list (in fact, I
posted a note outlining every possible combination of who needs what
features from who else); it turned out to be overly complicated, and
there were no real applications for it. So, we solved the basic problem
which there was a clear need for.

You mention some application in 3G registration. Can you elaborate on
that?

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: "rafi" <[email-masked]>
Date: Fri, 9 Jun 2000 12:08:53 +0530

Hi,

Consider the following paragraph in RFC 2543,
section 10.4.1

     .......  the server sends a final response, it  cannot
 be sure the client has received the response, and thus
SHOULD  cache the results for at least 10*T2 seconds
to avoid having to, for example, contact the user or location
server again upon receiving a request retransmission.

  Now consider the following scenarios.

Scenario 1 :  Consider a UAS supporting many calls
                   (each call's media stream may terminate
                   at different IP  address). If server caches the
                   final response then in worst case server may be
                   caching all the responses almost at same time. This
caching
                   may  cause the server run out of buffer space thereby
                   preventing the server  from serving  new requests.

Scenario 2:  Consider a misbehaved client which is sending request in
                    such way that each time it sends a request it challenges
the
                    server to send final response.  Client can quickly
                    make the server run out of buffer space and bring down
its
                    operation.

  Any comment are welcome.

Thank You

 Rafi Assadi H.M.
 Silicon Automation Systems
 Bangalore, INDIA.