Subject: RE: [midcom] Interim rev. of the famework draft

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 17 Aug 2001 10:29:54 +0100

Scott, 
I agree with you that there are some states maintained on the agents.
The agents have already flow related states, it's a sort of call-ID and
connection IDs related to the call (dependent on what application we are
talking about). The bundle is related to the the call ID or something
similar.
Once the call or the application session (hope this will not bring some
confusion :-)) ended, the agent will request to take out the bundle related
to the application session or call.
Cedric

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Monday, August 13, 2001 1:51 PM
To: [email-masked]
Subject: Re: [midcom] Interim rev. of the famework draft

On Thu, Aug 09, 2001 at 07:27:46PM -0400, Bob Penfield apparently wrote:
> > > I disagree. It does not have to be mandatory, but it would be nice to
> > > associate all the RTP streams of a SIP session together and be able to
> do
> > > things like extend the timer or delete them with a single
> handle/identifer.
> >
> > I agree with the bundling idea (indeed, I consider it a
> > requirement). What I want to avoid is some CREATE_SESSION method
> > which doesn't do anything except create an empty box to put things
> > in. My preferred approach is to permit the Agents to supply a cookie
> > with meaningful transactions, and then to apply certain operations
> > to 'all the stuff with <this> cookie'
> 
> I think I agree with that. I would want to say to the middlebox "create
this
> ruleset/pin-hole/whatever, oh and by the way, please give me an id for
that,
> and please associate it with bundle X". The bundle should not require a
> separate command/request. Also, I would like to say to the middlebox
"create
> this ruleset, give me an id for it, and give me a new bundle id associated
> with it that I can use to tell you what other rulesets are a part of this
> bundle".

This is the where-to-put-state issue again.  It's convenient for the
agent but not for the middlebox.  In the case of a SIP agent, doesn't
the agent have to retain some state information about all the rtp
streams it has arranged for?  The middlebox has no reason to know what's
bundled, except to purportedly offload the agent, and it can't offload
the agent completely.  This looks like an almost perfect example of the
end-to-end argument
<http://web.mit.edu/Saltzer/www/publications/endtoend/>.  If you believe
that you won't put this state into the middlebox.  (On the other hand,
if Christian is right you're going to want lots of state in the
middlebox and very little in the agent anyway.)

..Scott

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 17 Aug 2001 10:27:29 -0500 (CDT)

> to the application session or call.

	If I understand this right, it won't work at all in many cases.
If I am a SIP proxy handling an INVITE going out from my private network
to the world, I need to come up with a Public Address and a port I
can shove into the INVITE in lieu of the private one the phone put
in there.

	If I have 2 or more middleboxes, and I don't know which one to
use, I cannot simply bind in all of them and somehow resolve the multiple
addresses. I need ONE address to stick in the SDP in the INVITE, and
I need it before I send the INVITE on.

	Solving the topology problem, at least coarsely, is not
optional for Agents. They won't work unless they do.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Aug 2001 10:14:03 -0700

First,

We are now smack in the territory of discovery.  I think it would be
useful for you to read my discovery requirements draft.  However, I now
understand that Jonathan Rosenberg has a proposal that sounds interesting,
involving something that would reflect the publicly viewable address from
"outside" for some value of outside.  This sounds interesting, but I've
not seen it yet.  In particular I'd like to know whether it gets port
information correct.

--
Eliot Lear
[email-masked]