Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide

From: James Kempf <[email-masked]>
Date: Tue, 16 May 2000 05:39:58 -0700

Jonathan,

Unfortunately, I have to respectfully disagree.

I don't think the analogy between SIP and HTTP is valid. I see it more
as being between SIP and routing. Suppose I would have to go all the
way back to my home network to get my packets routed. 
I view SIP as being a way of doing the kind of things that routing protocols
do, except at the application layer. The network of SIP proxies is performing
telephone call routing.

Even if you are willing to grant the analogy, HTTP requests nowadays often
don't get routed to the server that somebody set up as their web site.
If your ISP is concerned about service, they may have set up an Inktomi
cache, and if the publisher is concerned, they may have contracted with
Akami to do the same. So the world is not so simple as "let's make it
free and easy for anybody to set up service" on the Web anymore. You can
set up your service, but unless you have a concerned ISP or the money
to pay Akami, the latency in using your service may cause people to
go elsewhere.

I know this isn't going to be a popular viewpoint, but I think we need
to be realistic about the design. SIP already contains support for
telling an incoming caller that a client has moved, I can't see the
harm in using a remote proxy, given the performance concerns.

		jak 

>Let me chime in with strong support of what Mike is saying. One of the
>great strengths of SIP is that there is a complete separation of
>transport (i.e.,voice) from signaling (read: services). This means that
>I can buy my transport and access for VoIp from one provider, but get
>applications and services from one or more other providers. This provide
>disaggregation of what has traditionally been a coupled service
>offering. Such disaggregation opens the door to massive innovation in
>the services area, since any yahoo can buy application hosting services,
>run on application on the hosted providers SIP servers, and provide
>service to anyone in the world, accessing from any IP device, wireless
>included.
>
>This is the model that made the web successful. Would it had evolved if
>ONLY my ISP could provide web content? No way. There would *never* had
>been a web if content and services for web had been coupled to access
>and transport. Never. Please lets not make this mistake with
>communications services.
>
>Efforts to link transport and access with services and signaling on the
>Internet are fundamentally futile, flawed, and will, in the end, reduce
>competition and innovation. But, I suppose thats the point.
>
>So, as it relates to wireless, just because some local provider is
>offering me transport services does not mean I should be forced to use
>them for signaling and features. 
>
>Michael Thomas wrote:
>> 
>> Giuseppe Ricagni writes:
>>  >    * possible optimizations (e.g.: signalling for a basic call to an
>Australian
>>  >      fixed network number from an Italian mobile roaming to Australia could
>be
>>  >      processed locally, without any "tromboning")
>> 
>>    If during call setup there needs to be a round
>>    trip to the home network, it pretty much negates
>>    any advantage of proxying the call locally.
>
>Please note that this service (optimized dial plans based on roaming) is
>still possible even if I go directly to the home network. All I need to
>do is indicate to my home proxy where I am, so it knows what dial plan
>to apply. In fact, dial plan administration is, in general, a service
>that can be outsourced to any ASP (of course, only local ASPs may wish
>to provide it, but the point is anyone can).
>
>> 
>>  >    * some people claim the "proxy" should also perform some kind of
>admission
>>  >      control for the calls. The proxy in the home domain has no information
>on the
>>  >      visited domain
>> 
>>    This is true of the foreign domain too. How does
>>    any proxy have knowledge of network topology?
>
>Call admission control in proxies >>will never work<<. As Mike suggests,
>this belongs in the transport layer, not the signaling layer.
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 May 2000 08:11:40 -0700 (PDT)

> way back to my home network to get my packets routed. 

   This is a pretty dubious analogy. We're talking
   about proxy-routed signaling traffic and that
   alone. You're making it sound like the media
   would do dog-leg routing through the home
   network which is absurd.

 > free and easy for anybody to set up service" on the Web anymore. 

   You're assuming that every thing is going to
   be a gigantic commercial service. I disagree. 
   It's still perfectly possible for me to run a
   web server at home, and in fact I do. We
   haven't engineered walls around that
   possibility. Requiring that I use a foreign
   proxy does, or at least thinks it does.

   Also: you're talking about transparent caching,
   not proxying in the web case. I've not heard
   of any ISP that *require* that I go through 
   their HTTP proxies.

 > You can

   This analogy is fatally flawed. Cache's are 
   great for the mountains of .gif's. There aren't
   similar considerations for SIP. Also: even
   if you're talking about co-lo servers
   distributed geographically, the site owner
   still "owns" the site. What you're talking
   about here is something run by their
   *competition* on your subscriber's behalf.

   Yuck.
 
 > harm in using a remote proxy, given the performance concerns.

   I think we have to demonstrate that there
   are legitimate performance concerns before we
   solve for them.

   Sanity check: we're talking about a
   hypothetical case where the SIP UA is
   in the handset, right? We're not talking
   about the case where you're terminating SIP
   at the next logical hop up (BTS, MSC) for
   legacy, right? I'm talking about the former.
   In the latter, its debatable which proxy
   should do routing.

	   Mike