RE: [Sip] Path header vs. pre-loaded route in Contact

jh@lohi.eng.song.fi Thu, 07 March 2002 07:14 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12286 for <sip-archive@odin.ietf.org>; Thu, 7 Mar 2002 02:14:33 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01044 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 02:14:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29164; Thu, 7 Mar 2002 01:42:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29133 for <sip@optimus.ietf.org>; Thu, 7 Mar 2002 01:42:33 -0500 (EST)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03503 for <sip@ietf.org>; Thu, 7 Mar 2002 01:42:30 -0500 (EST)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16irbj-0007sZ-00; Thu, 07 Mar 2002 08:42:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <15495.3030.996329.314148@harjus.eng.song.fi>
Date: Thu, 07 Mar 2002 08:42:30 +0200
To: "George Foti (LMC)" <George.Foti@ericsson.ca>
Cc: 'Rohan Mahy' <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Path header vs. pre-loaded route in Contact
In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se>
References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

George Foti (LMC) writes:

 > I am concerned about outgoing calls, which have  to be handled by the home
 > proxy of the originating sub. The request will get to the I-CSCF for the
 > home, but after that,  the I-CSCF has no way of routing it any further and
 > it would have to interrogate a data base to find out the proxy assigned to
 > the sub. for further routing.

it is good that you now admit that your previous email about this topic
was bogus and that in fact we don't need to do anything to the sip
protocol in order to make the 3gpp ims service work.  it is just a
question of implementation efficiency and i simply don't believe that a
single database query can be any issue at all.

currently when my proxy gets an invite message, it needs to make lots of
database queries, for example, to check if caller belongs to one of my
home domains, if so, to check that the from address belongs to the user,
to check that the user has the right to place a call to the to address,
to check what long distance or international carrier the caller want to
use, if it is emergency number, to check where the user is located,
etc., etc.

there are several possibilities to speed up the simple query that the
3gpp ims entry proxy needs to do.  first is of course load balancing to
keep the load of a single entry proxy low.  then you could, for example,
cash the next hop proxy in the memory of the entry proxy when the user
registers and then make the query in a few milliseconds.  i just bought
512 mb of ram for my computer and it costed me about usd 75.

 > We would have to do that for every originating request, since the I-CSCF is
 > stateless. Now that will lengthen the call set up time and is inefficient.

see above.  this is all bogus.

 > By being able to return the proxy assigned to the mobile in a resgistration
 > response, it can be pre-loaded by the P-CSCF for originating calls and we
 > would save the step of I-CSCF interrogating the database for the proxy
 > assigned  to the sub.

and what happens if the preloaded proxy dies?  this kind of pinning down
a particular proxy is a very bad idea in general.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip