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

Jeroen van Bemmel <jbemmel@zonnet.nl> Tue, 15 January 2008 17:39 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 1JEpkx-0000oP-0z; Tue, 15 Jan 2008 12:39:23 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JEpkw-0000oK-0s for sip-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:39:22 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpkv-0000oC-LS for sip@ietf.org; Tue, 15 Jan 2008 12:39:21 -0500
Received: from smtp6.versatel.nl ([62.58.50.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEpku-0001FQ-LA for sip@ietf.org; Tue, 15 Jan 2008 12:39:21 -0500
Received: (qmail 9976 invoked by uid 0); 15 Jan 2008 17:40:14 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>) by smtp6.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jan 2008 17:40:14 -0000
Message-ID: <478CEFB4.6070002@zonnet.nl>
Date: Tue, 15 Jan 2008 18:39:00 +0100
From: Jeroen van Bemmel <jbemmel@zonnet.nl>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy
References: <5D1A7985295922448D5550C94DE2918001AC02E9@DEEXC1U01.de.lucent.com> <CA9998CD4A020D418654FCDEF4E707DF040266B1@esealmw113.eemea.ericsson.se> <47878B1E.3010303@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0549A47@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1428F69B@zrc2hxm0.corp.nortel.com> <CA9998CD4A020D418654FCDEF4E707DF04051C9D@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1428F846@zrc2hxm0.corp.nortel.com> <CA9998CD4A020D418654FCDEF4E707DF040960B7@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF1434B83B@zrc2hxm0.corp.nortel.com> A <CA9998CD4A020D418654FCDEF4E707DF040D69C7@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D0549D3F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1438F1B0@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>, Paul Kyzivat <pkyzivat@cisco.com>, "Elwell, John" <john.elwell@siemens.com>, Christer Holmberg <christer.holmberg@ericsson.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>
Errors-To: sip-bounces@ietf.org

I think we'll also need a new response code: 4xx I'm confused, too many 
URIs in request

Seriously, a solution based on yet another header with an URI IMHO 
introduces more complexity/confusion than solving the issue is worth.

Better to limit the scope of the problem we're trying to solve and 
document the known limitations / use cases. If the problem is to deliver 
the request URI to a UAS which is registered with its home proxy, and 
there is a mechanism by which the proxy can detect support by the UAS, 
Jonathan's solution is fine. To other proxies being in the path not 
supporting this mechanism it would still appear as basic loose routing, 
so I don't see the issue there (if needed we could extend the Path 
mechanism with some flag as done for outbound)

Regards,
Jeroen

Francois Audet wrote:
> I think we should charge customers per URI in the protocol.
>
> We'd be rich. 
>
>   
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell@siemens.com] 
>> Sent: Tuesday, January 15, 2008 01:20
>> To: Christer Holmberg; Audet, Francois (SC100:3055)
>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat
>> Subject: RE: [Sip] RE: Delivering request-URI and parameters 
>> to UAS via proxy
>>
>> Christer,
>>
>> I guess what still confuses me is, when both Target and P-CPI 
>> are used, which comes first, i.e., which represents the 
>> earlier target? When I read the draft, I thought Target was 
>> earlier. From various clarifying emails I now get the 
>> impression that Target is later. Can you confirm?
>>
>> Picking up on Francois' point about History-Info, with the 
>> introduction of Target and P-CPI we do indeed have a lot of 
>> URIs, and of course History-Info can already convey all these 
>> URIs and any others. The difference is that History-Info does 
>> not give particular semantics to each of the URIs it conveys 
>> - they are simply a succession of targets.
>> With Target and P-CPI we are aiming to define specific 
>> semantics. I am concerned whether we will be able to define 
>> these semantics tightly enough to ensure consistent 
>> implementations. The more URIs we try to define, the harder 
>> it will be to assign each one a clearly distinguishable 
>> meaning. I hope the next draft will help.
>>
>> John
>>
>>     
>>> -----Original Message-----
>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>> Sent: 15 January 2008 08:48
>>> To: Francois Audet
>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John
>>> Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS 
>>> via proxy
>>>
>>>
>>> Hi,
>>>
>>> P-CPI could probably be useful in some cases, in addition to Loose 
>>> Route/Target. And, as the draft says, P-CPI will still have 
>>>       
>> to be used 
>>     
>>> in IMS, because there are procedures defined for it.
>>>
>>> However, again, the purpose of the draft was to provide an 
>>>       
>> alternative 
>>     
>>> to the Loose Route alternative, and that alternative is Target only.
>>>
>>> I am working on an updated version of the draft to make that more 
>>> clear.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>       
>>>> Hum. I guess then P-Called-ID would then be useful with 
>>>>         
>> Loose-route 
>>     
>>>> as well (although now I'm thinking that History-Info covers it).
>>>>
>>>> I think explaining all that in great and precise details, with a 
>>>> concrete example would be very useful.
>>>>
>>>> And then we could compare P-Target with Loose-route. 
>>>>         
>>>
>>>
>>>
>>>       
>>>>> -----Original Message-----
>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>>>>> Sent: Monday, January 14, 2008 03:56
>>>>> To: Audet, Francois (SC100:3055)
>>>>> Cc: sip@ietf.org; DRAGE, Keith (Keith); Paul Kyzivat; 
>>>>>           
>> Elwell, John
>>     
>>>>> Subject: RE: [Sip] RE: Delivering request-URI and
>>>>>           
>>> parameters to UAS
>>>       
>>>>> via proxy
>>>>>
>>>>>
>>>>> Hi Francois,
>>>>>
>>>>>           
>>>>>> I think what you meant by Target was more the "Current" 
>>>>>> target as opposed to the Initiatl Target.
>>>>>>             
>>>>> Yes.
>>>>>  
>>>>>           
>>>>>> And if that's the case, then I don't see why it is
>>>>>>             
>>> different from
>>>       
>>>>>> P-Called-ID (although I might be missing something 
>>>>>>             
>> with what the 
>>     
>>>>>> P-Called_ID is supposed to be).
>>>>>>             
>>>>> In the draft we try to explain the difference. But, we are
>>>>>           
>>>> working on
>>>>         
>>>>> the text to make it more clear.
>>>>>
>>>>> The P-CPI is inserted when the R-URI is rewritten by 
>>>>>           
>> the Contact 
>>     
>>>>> address of the UAS. RFC3455 calls that operation
>>>>>           
>>>> "retargeting", but we
>>>>         
>>>>> don't think that is the definition for retarget used in the 
>>>>> ua-loose-route draft, which says:
>>>>>
>>>>> "When a home proxy receives a request and accesses a
>>>>>           
>>>> location service,
>>>>         
>>>>> the resulting contact(s) obtained from the location service are 
>>>>> considered the last hop in the route towards the entity
>>>>>           
>>>> addressed by
>>>>         
>>>>> the Request-URI.  Since that target, almost by definition,
>>>>>           
>>>> can claim
>>>>         
>>>>> the identity of the URI prior to translation, the operation
>>>>>           
>>>> is one of
>>>>         
>>>>> routing and not retargeting."
>>>>>
>>>>> So, if we follow the definitions in the ua-loose-route
>>>>>           
>>> draft, P-CPI
>>>       
>>>>> would be inserted due to a reroute - not retarget.
>>>>>
>>>>> But, no matter whether we call it retarget or reroute,
>>>>>           
>>> the point is
>>>       
>>>>> that the P-CPI is inserted when the R-URI is rewritten with the 
>>>>> Contact address of the UAS. The scope of Target is wider
>>>>>           
>>> than that,
>>>       
>>>>> and can be used in any retargeting situation.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>           
>
>
> _______________________________________________
> 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