Subject: [Sip] Comments on draft-rosenberg-sip-ua-loose-route-00.txt

From: EKR <[email-masked]>
Date: Sun, 29 Oct 2006 10:44:09 -0800

$Id: draft-rosenberg-sip-ua-loose-route-00-rev.txt,v 1.1 2006/10/29 18:46:14 ekr Exp $

This generally seems like a sound idea and the draft is pretty well
written. The extensive backward compatibility considerations make
me a bit nervous, but not being a real SIP routing expert, I can't
say if there will be problems in practice.

S 2.1:

   sip:[email-masked] and sip:[email-masked].  Rather than
   registering against each of these AORs individually, the user would
   register against just one of them, and the home proxy would
   automatically accept incoming calls for any of the aliases, treating
   them identically and ultimately forwarding them towards the UA. 

This sentence is hard to read. I think it's describing what happens
now, but the use of "Rather...would" suggests that it's what you
want to do after this draft, so..

S 2.3:
   Limited use addresses are used in battling voice spam [6]. 

Well, we'd like them to be. Maybe s/are/can be/

   particular correspondent, and remember that URI locally.  When an
   incoming call arrives, the UAS would examine the parameter in the URI
   and determine whether or not the call should be accepted.

This is one way to do it, but the alternative is a cryptographic
cookie and keeping a blacklist.

S 3:
   There is a common theme across all of the problems in Section 2, and
   this theme is the confounding of names, routes, and addresses.

   A name is a moniker for an entity which refers to it in a way which

I'm not sure you want to use "moniker" here. I would think that you have
"identifiers" (i.e., names), "routes", and "locators" (i.e., addresses)

S 5:
   3.  When a proxy receiving a request identifies a next hop server
       that is needed to process the request, that next hop server is a
       route.  A next hop server is not a UA and would never be able to
       claim its identity.  Its URI is pushed into a Route header field
       and the Request-URI is retained.  An important use case for this
       are proxies that select PSTN gateways for call egress to the
       PSTN.  Such selection would place the SIP URI of the gateway into
       the topmost Route header field value and retain the Request-URI.

I think this could be clearer, but I'm not sure I understand it well
enough to rewrite...

-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip