VS: VS: [Sip] Delivering request-URI and parameters to UAS via proxy

"Christer Holmberg" <christer.holmberg@ericsson.com> Wed, 12 December 2007 12:44 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Qwh-0007bx-5B; Wed, 12 Dec 2007 07:44:15 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2Qwf-0007bs-0g for sip-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 07:44:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Qwe-0007bk-Ll for sip@ietf.org; Wed, 12 Dec 2007 07:44:12 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Qwc-0000fy-1u for sip@ietf.org; Wed, 12 Dec 2007 07:44:12 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD2082143E; Wed, 12 Dec 2007 13:41:28 +0100 (CET)
X-AuditID: c1b4fb3c-af796bb0000030cf-2a-475fd6f83f6e
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C4BF214B7; Wed, 12 Dec 2007 13:41:28 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 13:41:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: VS: VS: [Sip] Delivering request-URI and parameters to UAS via proxy
Date: Wed, 12 Dec 2007 13:41:27 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF039B697D@esealmw113.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: VS: [Sip] Delivering request-URI and parameters to UAS via proxy
Thread-Index: Acg4JGkAop/2ZJQeT3OmQxox75ZkSgAWUS+Y
References: <5D1A7985295922448D5550C94DE29180019B7E52@DEEXC1U01.de.lucent.com><CA9998CD4A020D418654FCDEF4E707DFEE08CD@esealmw113.eemea.ericsson.se> <47572024.9000901@cisco.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>
X-OriginalArrivalTime: 12 Dec 2007 12:41:28.0389 (UTC) FILETIME=[509AA750:01C83CBC]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0258924361=="
Errors-To: sip-bounces@ietf.org

Hi,
 
I have had an off-line discussion with Jonathan about this, but I'll let everyone else know too.
 
One issue with Jonathan's proposed mechanism is that it is assumes that the entity/proxy who wants to use it (instead of modifying the R-URI value) KNOWS whether the next hop device also supports the mechanism or not. I think that assumption makes the usability of the proposed solution extremely limited and "undynamic", and services which rely on the mechanism will be dependent on whether intermediates (which have nothing to do with the service as such) support the mechanism
 
Also, assuming that one or more entities/proxies in the path have already used the mechanism, and now an entity/proxy realizes that the next hop device does NOT support it. This most likely means that that entity/proxy now will have to "fix" the INVITE (e.g put the "correct" URI back into the R-URI etc), in order for the next hop to be able to deal with it correctly (at least the home proxy of the terminating user would need the "fix" in order to find the registered contact, and an MGC to correctly map the called party number).
 
And, yes, I AM thinking about an alternative solution, and my intention IS to submit a draft before the deadline.
 
Regards,
 
Christer

________________________________

Lähettäjä: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
Lähetetty: ke 5.12.2007 23:03
Vastaanottaja: Christer Holmberg
Kopio: sip@ietf.org; DRAGE, Keith (Keith)
Aihe: Re: VS: [Sip] Delivering request-URI and parameters to UAS via proxy





Christer Holmberg wrote:
> Hi,
>
> In order to think about documenting "alternative solutions", I have a
> question for clarifications regarding the scope of the problem we are
> trying to solve.
>
> The MECHANISM part of the draft says that a UA supporting the
> mechanism would indicate it to the registrar, and the registrar would
> only use the mechanism in case the UA has indicated support for it
> (that is also shown in the example in the draft).

For when a proxy is talking to a registered UA, yes.

> It has also been
> claimed that this would be backward compatible with an MGC which uses
> the R-URI to map to ISUP Called Party number, because the MGC does
> not register so the mechanism would not be used towards it.

That is not the intent.

The idea is, any proxy that is translating a request-URI, is doing so
based on some kind of mapping table. There are many ways that this
mapping table can get into the proxy:

1. dynamically through register
2. provisioned
3. through an enum query
etc.

If we take provisioning as an example (i.e., someone enters phone number
routing rules via prefix matching rules), when those rules are
provisioned, they would include a flag which says whether the
destination is loose-route compliant. If they are loose route compliant,
the proxy uses a Route header, else it uses r-uri translation as is
currently done.

>
> My question is: does this mean that the only entity allowed to use
> this mechanism is the registrar, since the mechanism is used based on
> whether the UA supports it or not?

As above, no.

>
> When reading the USE-CASE part of the draft, I would say that the
> answer is "no". Because, as I understand the text, there could be
> non-registrar entities in the path, which today normally would
> re-write the R-URI, but would now instead use this mechanism. Is my
> understanding correct?

Yes.

>
> If so, my next question is: these non-registrar entities have no clue
> about whether the terminating UA supports the mechanism or not, or
> whether the call will be routed towards an MGC. So, what happens if
> the request is routed towards an UA that has not indicated support,
> or towards an MGC? The MGC may not be able to map the R-URI.

Hopefully the above paragraph answers your question.

-Jonathan R.


--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (408) 902-3084
http://www.cisco.com <http://www.cisco.com/> 


_______________________________________________
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


_______________________________________________
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