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

["Hans Erik van Elburg" <[e-mail]>]

Paul Kyzivat wrote:
> From the point of view of the registrar this seems similar to IMS implicit registration, 
> except that the scale is much larger - there may be *very many* implicit registrations 
> generated by this one explicit registration.

For this reason the Wildcarded Public User Identity concept is introduced in IMS. This allows efficient implicit registration of ranges of numbers or sets of sip uri's.

Best Regards,
/Hans Erik

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: Wednesday, January 30, 2008 4:12 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Sip] Delivering request-URI and parameters to UAS via proxy



[e-mail] wrote:
> I think there is a misunderstanding on these use cases:

Quite possible.

>  - The intermediate entity in the customer side does perform only one registration to the network.
>    The AoRs associated to the served terminals inside the client domain are registred automatically
>    by the home network, using implicit registration for example. In fact, it's not conceivable to
>    register individually all the users of a corporate network for example.

You seem to be describing one of the models covered by the SIPForum in their SIPConnect specification. Is that what you mean?

 From the point of view of the registrar this seems similar to IMS implicit registration, except that the scale is much larger - there may be *very many* implicit registrations generated by this one explicit registration.

> - The "intermediate entity" should be able to route incoming requests inside its domain based on
>   standard RFC3261 behaviour, that is, based on the Request-URI.

I find the case much less compelling than the IMS case.

IMO this is an abuse of REGISTER to a purpose for which it is not well suited.

Treating it as registration means that there is an *expectation* that the R-URI will be translated. That isn't really appropriate in this case. The registration doesn't specify the mapping anyway - it is configuration in the network of all the addresses that belong to the "pbx" that does that. This is more appropriately viewed as just a routing operation, and so pushing the address of the enterprise server as a Route header is by far the best choice. Its only because this has been done using REGISTER that brings up how to preserve the old address when it is translated.

	Thanks,
	Paul

> Best regards
> 
> Youssef
> 
> 
>   
>  
> 
>> -----Message d'origine-----
>> De : Paul Kyzivat [mailto:[e-mail]] Envoyé : lundi 28 
>> janvier 2008 21:46 À : CHADLI Youssef RD-CORE-ISS Cc : 
>> [e-mail]; [e-mail] Objet : Re: [Sip] Delivering 
>> request-URI and parameters to UAS via proxy
>>
>> These cases can all be handled by having intermediate entity use a 
>> unique user part, together with its own domain name, to construct a 
>> contact address for each terminal UA that it is registering. Then 
>> when it receives an incoming request to one of these uris it can 
>> simply translate it, using the user part as a key to its own local 
>> mappings.
>>
>> We don't need anything new to solve these cases.
>>
>> 	Paul
>>
>> [e-mail] wrote:
>>>  
>>> There are other cases similar to what is described in
>> section  2.1 Unknown Aliases of J. Rosenberg draft that should be 
>> taken into account.
>>> Those cases are where the customer side is composed of
>> several SIP terminals that access the network through an intermediate 
>> entity which registers their associated aliases with its contact 
>> address. Thus, such client side is seen from the network as a single 
>> client having several aliases (aggregated endpoints). Moreover, such 
>> client side may be a mini private network composed of several 
>> entities. In these configurations, the intermediate entity is in 
>> charge of routeing incoming calls inside the client domain and may 
>> need to behave as a SIP proxy for incoming SIP messages.
>>> As examples of such configuration:
>>> - Corporate networks: in that case the PBX register all the
>> served individual user identities with its contact address and routes 
>> incoming calls toward the individual called users.
>>> - Home networks: the Home Gateway may need to register on
>> behalf of all the served terminals.  The Home Gateway is in charge of 
>> routeing incoming calls toward the individual called users.
>>> J. Rosenberg draft seems give a good solution to take into
>> account these configurations.
>>>    
>>> Best regards,
>>>
>>> Youssef
>>>
>>>
>>>> -----Message d'origine-----
>>>> De : DRAGE, Keith (Keith)
>> [mailto:[e-mail]] Envoyé : 
>>>> lundi 14 janvier 2008 17:58 À : [e-mail] Objet : [Sip]
>> Delivering
>>>> request-URI and parameters to UAS via proxy
>>>>
>>>> (As WG chair)
>>>>
>>>> In fulfilment of our charter items of
>>>>
>>>> Dec 2007    Delivering request-URI and parameters to UAS 
>> via proxy to
>>>> WGLC  
>>>> Feb 2008    Delivering request-URI and parameters to UAS 
>> via proxy to
>>>> IESG (PS)
>>>>
>>>> We now have a couple of proposals on the table for solving the 
>>>> problem.
>>>>
>>>> The original draft from Jonathan and which led to the
>> creation of the
>>>> charter items by the WG is unfortunately expired, but is at:
>>>>
>>>> http://tools.ietf.org/id/draft-rosenberg-sip-ua-loose-route-01.txt
>>>>
>>>> The alternative document from Christer, etc is at:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-holmberg-sip-target-
>>>> uri-delive
>>>> ry-00.txt
>>>>
>>>> We obviously need to make a decision between the two approaches so 
>>>> please attempt to address the following specific points via the 
>>>> mailing
>>>> list:
>>>>
>>>> 1)	Problem cases: These are summarised in section 4.4 of
>>>> draft-rosenberg-sip-ua-loose-route-01 and from my read of
>> the other
>>>> draft, I don't believe that this draft adds any others.
>>>> If you believe there are other cases that should be covered by the 
>>>> solution, then please identify them. If there is support
>> on any new
>>>> problem cases, I would encourage the authors of both drafts to add 
>>>> text concerning these problem cases.
>>>>
>>>> 2)	Clarifications: If for any reason you don't understand either
>>>> draft, or believe that there are technical issues that are not 
>>>> represented in the current draft, please post your questions / 
>>>> comments to the list. I would encourage authors of both drafts to 
>>>> revise as frequently as appropriate to reflect the current
>> state of
>>>> discussion.
>>>>
>>>> 3)	Support for either position. If you wish to indicate support for
>>>> either position please do so, but please accompany this is
>> technical
>>>> reasoning as to why you have this position, as that will
>> help other
>>>> members of the WG form a position.
>>>>
>>>> I would encourage as much list discussion as possible before 
>>>> Philadelphia. I suspect we will need to have a discussion at the 
>>>> face-to-face meeting in Philadephia, but list discussion
>> is essential
>>>> prior to that. If we can solve this positions on list,
>> then well and
>>>> good, and even better (that is how we are meant to make decisions).
>>>>
>>>> Regards
>>>>
>>>>
>>>> Keith
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol Use 
>>>> [e-mail] for questions on current sip Use 
>>>> [e-mail] 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 
>>> [e-mail] for questions on current sip Use 
>>> [e-mail] 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 [e-mail] for questions on current sip Use [e-mail] for new developments on the application of sip
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip
From [e-mail]  Fri Feb  1 02:54:49 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 44BC43A6913
	for <[e-mail]>; Fri,  1 Feb 2008 02:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 35.568
X-Spam-Level: ***********************************
X-Spam-Status: Yes, score5.568 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FB_MORE_SIZE.357, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144,
	FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426,
	HELO_EQ_VERIZON_POOL=1.495, NORMAL_HTTP_TO_IP=0.001,
	RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5,
	RAZOR2_CHECK=0.5, RCVD_ILLEGAL_IP=1.908, RCVD_IN_BL_SPAMCOP_NET=1.96,
	RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033,
	RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001]
X-Spam-Report:
 *  3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
 *      [score: 1.0000]
 *  2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net
 *  0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d
 *  2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
 *      1)
 *  1.5 HELO_EQ_VERIZON_POOL HELO_EQ_VERIZON_POOL
 *  1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
 *  0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE
 *  1.9 RCVD_ILLEGAL_IP Received: contains illegal IP address
 *   10 FB_MORE_SIZE BODY: Phrase: more size
 *  0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL
 *  1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
 *      above 50%
 *      [cf: 100]
 *  0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
 *  0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
 *      [cf: 100]
 *  0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
 *      [72.89.150.238 listed in zen.spamhaus.org]
 *  3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
 *  2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 *      [Blocked - see <http://www.spamcop.net/bl.shtml?72.89.150.238>]
 *  0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
 *      [72.89.150.238 listed in dnsbl.sorbs.net]
 *  2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d
 *  0.1 RDNS_DYNAMIC Delivered to trusted network by host with
 *      dynamic-looking rDNS
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GaE00hg91v4V for <[e-mail]>;
	Fri,  1 Feb 2008 02:54:48 -0800 (PST)
Received: from pool-72-89-150-238.nycmny.fios.verizon.net (pool-72-89-150-238.nycmny.fios.verizon.net [72.89.150.238])
	by core3.amsl.com (Postfix) with SMTP id 530333A690F
	for <[e-mail]>; Fri,  1 Feb 2008 02:54:47 -0800 (PST)
Received: from [224.167.187.83] (helo=pcr)
	by pool-72-89-150-238.nycmny.fios.verizon.net with smtp (Exim 4.62 (FreeBSD))
	id 1JLTdC-0001ht-Eh; Fri, 1 Feb 2008 06:00:26 -0500
Message-ID: <001601c864c1$1409a020$53bba7e0@pcr>
From: <[e-mail]>
To: <[e-mail]>
Subject: ***SPAM*** 35.568 (5) Convenient and private ordering!
Date: Fri, 1 Feb 2008 05:56:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="windows-1250";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

Get more size for your enjoyment! http://125.179.156.23/qoohjp/