From sip-bounces@ietf.org Thu Dec 01 01:49:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhiGD-00081V-Nx; Thu, 01 Dec 2005 01:49:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhR6Q-0006ms-S1
	for sip@megatron.ietf.org; Wed, 30 Nov 2005 07:30:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07797
	for <sip@ietf.org>; Wed, 30 Nov 2005 07:29:39 -0500 (EST)
From: khairunnisa.hassanali@flextronicssoftware.com
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhRQa-0000PQ-Lq
	for sip@ietf.org; Wed, 30 Nov 2005 07:51:23 -0500
Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21])
	by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jAUCTLx27403;
	Wed, 30 Nov 2005 17:59:22 +0530
Subject: Re:[Sip] [SIP Cacel Method]
To: Chen Shuping <shuping.chen@cecwireless.com.cn>
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OFCC668737.73FA4767-ON652570C9.0044051D-652570C9.004497CA@flextronicssoftware.com>
Date: Wed, 30 Nov 2005 17:55:31 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 11/30/2005 05:59:37 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
X-Mailman-Approved-At: Thu, 01 Dec 2005 01:49:40 -0500
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org





Hi,
                           Please find my response within <Nisha> </Nisha>
Regards
Nisha
                                                                           
             Chen Shuping                                                  
             <shuping.chen@cec                                             
             wireless.com.cn>                                           To 
             Sent by:                  sip@ietf.org                        
             sip-bounces@ietf.                                          cc 
             org                                                           
                                                                   Subject 
                                       [Sip] [SIP Cacel Method]            
             11/30/2005 11:50                                              
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           



Hi,All

  I have such a doubt:

   In RFC 3261 17.1.1.2  Time_B timeout in Calling state,Invite transaction
transit to terminated

state,What if Timer_B timeout in Proceeding  state(this could happen when
the callee is not in office,

his softphone keep ringring until caller's timer_b timeout).

In my implementation my call flow like this:

CASE 1:

caller                                          callee
------------INVITE------------------->
<-----------100 Trying-----------------
<-----------180 Ringing--------------

caller hang up

--------------Cancel----------------->
<-------------200 for Cancel--------
<-------------487----------------------
---------------ACK------------------>

CASE 2:

INVITE------------------->
<-----------100 Trying-----------------
<-----------180 Ringing--------------

caller keep waiting ,Timer_b time out

--------------Cancel----------------->
<-------------200 for Cancel--------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------

My question is should I generate ACK for the second case.

<Nisha>
      According to Section 13.1 of RFC, a UAC should respond with an ACK
for every final
response that it receives. In this case, 487 is a final response therefore
an ACK must be generated in the
CASE 2 described above.

----------------------Extract from RFC
3261----------------------------------------------------------
After possibly receiving one or more provisional responses, the UAC will
get one or more 2xx responses or
one non-2xx final response. Because of the protracted amount of time it can
take to receive final responses
to INVITE, the reliability mechanisms for INVITE transactions differ from
those of other requests (like
OPTIONS). Once it receives a final response, the UAC needs to send an ACK
for every final response
it receives. The procedure for sending this ACK depends on the type of
response. For final responses
between 300 and 699, the ACK processing is done in the transaction layer
and follows one set of rules (See
Section 17). For 2xx responses, the ACK is generated by the UAC core.

---------------------------End of extract from RFC
3261---------------------------------------------------
</Nisha>

Thanks


***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain  privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this
message in  error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted
by this email including damage from virus."


_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 01 07:44:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ehno3-0002c0-Mf; Thu, 01 Dec 2005 07:44:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehno1-0002aG-TK
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 07:44:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15282
	for <sip@ietf.org>; Thu, 1 Dec 2005 07:44:11 -0500 (EST)
Received: from i-83-67-107-30.freedom2surf.net ([83.67.107.30]
	helo=feynman.croczilla.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eho8U-0003yI-Oc
	for sip@ietf.org; Thu, 01 Dec 2005 08:06:08 -0500
Received: from [192.168.1.100] (unknown [192.168.1.100])
	by feynman.croczilla.com (Postfix) with ESMTP
	id E4CA1275C96; Thu,  1 Dec 2005 12:44:25 +0000 (GMT)
Message-ID: <438EF028.2020303@croczilla.com>
Date: Thu, 01 Dec 2005 12:44:24 +0000
From: Alex Fritze <alex@croczilla.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: Marc Petit-Huguenin <petithug@8x8.com>
Subject: [Sip] draft-ietf-sip-outbound-01, Service-Route and flows
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

draft-ietf-sip-outbound-01 isn't very explicit about when exactly a UA 
should monitor a particular flow for failures; in particular when a 
REGISTER request returns a Service-Route with an outbound proxy that is 
different from the configured outbound proxy. In this case, the 
Service-Route will replace the configured route, as per 
draft-rosenberg-sip-route-construct-00. (From the IETF64 sip-outbound 
minutes, I gather that this is also the current consensus).
In such a scenario, should the UA a) keep alive the original flow to the 
registrar or b) perform DNS resolution on the first proxy in the new 
route and start sending STUN requests to it?

Thanks,
Alex

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 01 09:13:32 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhpBk-00073o-En; Thu, 01 Dec 2005 09:13:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBi-00071p-18
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 09:13:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24948
	for <sip@ietf.org>; Thu, 1 Dec 2005 09:12:42 -0500 (EST)
Received: from smtp7.clb.oleane.net ([213.56.31.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpWC-0006yS-2R
	for sip@ietf.org; Thu, 01 Dec 2005 09:34:40 -0500
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp7.clb.oleane.net with ESMTP id jB1ED6sj002514
	for <sip@ietf.org>; Thu, 1 Dec 2005 15:13:07 +0100
Message-Id: <200512011413.jB1ED6sj002514@smtp7.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <sip@ietf.org>
Date: Thu, 1 Dec 2005 15:12:34 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX2gUY6cyMNvcQVQjqnn8emA+Ys3Q==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Subject: [Sip] Wireless/WiFi Convergence Conference - Call for Papers 
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="===============0555103555=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0555103555==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0125_01C5F689.A8785CE0"

This is a multi-part message in MIME format.

------=_NextPart_000_0125_01C5F689.A8785CE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to
May 19, 2006

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm

 

It is still time to submit proposals. Organizers are looking for UMA papers.

 


------=_NextPart_000_0125_01C5F689.A8785CE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The <strong><b><font face=3DArial><span
style=3D'font-family:Arial'>Wireless/WiFi Convergence =
Conference</span></font></b></strong>
will be held in <st1:place w:st=3D"on"><st1:City w:st=3D"on"><span =
class=3Dstyle24>Paris</span></st1:City></st1:place><span
class=3Dstyle24> on May 16 to May 19, 2006</span></span></font><font =
size=3D2><span
lang=3DEN-GB style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a
href=3D"http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006=
cfp.htm">http://www.upperside.fr/wirelessconvergence2006/wwconvergence200=
6cfp.htm</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to submit proposals. =
Organizers are
looking for UMA papers.</span></font><font size=3D2><span lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0125_01C5F689.A8785CE0--



--===============0555103555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0555103555==--





From sip-bounces@ietf.org Thu Dec 01 09:14:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhpCn-0007c4-Nn; Thu, 01 Dec 2005 09:14:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpCm-0007bz-Ou
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 09:14:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25115
	for <sip@ietf.org>; Thu, 1 Dec 2005 09:13:49 -0500 (EST)
Received: from smtp4.clb.oleane.net ([213.56.31.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpXE-00071P-Cp
	for sip@ietf.org; Thu, 01 Dec 2005 09:35:48 -0500
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp4.clb.oleane.net with ESMTP id jB1EENdV030915
	for <sip@ietf.org>; Thu, 1 Dec 2005 15:14:23 +0100
Message-Id: <200512011414.jB1EENdV030915@smtp4.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <sip@ietf.org>
Date: Thu, 1 Dec 2005 15:13:49 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX2gXMsOVCIwM1tR66pF8kwHwOEXA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Subject: [Sip] Wireless/WiFi Convergence Conference - Call for Papers 
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="===============0173560328=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0173560328==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_015D_01C5F689.D578BFA0"

This is a multi-part message in MIME format.

------=_NextPart_000_015D_01C5F689.D578BFA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to
May 19, 2006

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm

 

It is still time to submit proposals. Organizers are looking for UMA papers.

 

 


------=_NextPart_000_015D_01C5F689.D578BFA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The <strong><b><font face=3DArial><span
style=3D'font-family:Arial'>Wireless/WiFi Convergence =
Conference</span></font></b></strong>
will be held in <st1:place w:st=3D"on"><st1:City w:st=3D"on"><span =
class=3Dstyle24>Paris</span></st1:City></st1:place><span
class=3Dstyle24> on May 16 to May 19, 2006</span></span></font><font =
size=3D2><span
lang=3DEN-GB style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a
href=3D"http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006=
cfp.htm"
title=3D"http://www.upperside.fr/wirelessconvergence2006/wwconvergence200=
6cfp.htm">http://www.upperside.fr/wirelessconvergence2006/wwconvergence20=
06cfp.htm</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to submit proposals. =
Organizers are
looking for UMA papers.</span></font><font size=3D2><span lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_015D_01C5F689.D578BFA0--



--===============0173560328==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0173560328==--





From sip-bounces@ietf.org Thu Dec 01 09:40:17 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ehpbd-0001uP-LM; Thu, 01 Dec 2005 09:40:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehpbc-0001sJ-0A
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 09:40:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27948
	for <sip@ietf.org>; Thu, 1 Dec 2005 09:39:28 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehpw7-00081y-2d
	for sip@ietf.org; Thu, 01 Dec 2005 10:01:27 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id jB1EdwH20831; Thu, 1 Dec 2005 09:39:59 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] ABNF rule used in RFC 4244
Date: Thu, 1 Dec 2005 08:39:56 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0AB3D455@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Sip] ABNF rule used in RFC 4244
Thread-Index: AcXwIxxrqZUPcYeRTmqfbVjiyKoWKwFqqAHA
From: "Mary Barnes" <mary.barnes@nortel.com>
To: <joel.repiquet@tech-invite.com>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Joel,

You are correct, this is an error.  I backtracked to see how it got =
introduced and it's been that way for 3 years.  RFC 2832 does define the =
DOT, but that's not a reference for this RFC nor for any that it =
references.  I have filed an errata with the RFC Editor and once it gets =
entered in the database, it will show up here: =
http://www.rfc-editor.org/errata.html

Thanks for pointing this out.=20

Mary=20

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =
joel.repiquet@tech-invite.com
Sent: Wednesday, November 23, 2005 5:37 AM
To: sip@ietf.org
Cc: Barnes, Mary [RICH2:B601:EXCH]
Subject: [Sip] ABNF rule used in RFC 4244


Hi,

In RFC 4244 (An Extension to SIP for Request History Information) there =
is the following ABNF rule:
       hi-index =3D "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)=20
DOT is not defined as an ABNF core rule in RFC  4234 (ABNF) and is not =
defined as a basic rule in RFC 3261.
It is only used and defined in RFC 3525 (Gateway Control Protocol =
Version 1).

Is it defined elsewhere?=20

This could be a problem for parsers.

This rule should be:
       hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT)=20


Regards
Jo=EBl=20

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 01 10:52:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ehqj6-0008Hw-IT; Thu, 01 Dec 2005 10:52:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqj5-0008Hp-Cl
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 10:52:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07660
	for <sip@ietf.org>; Thu, 1 Dec 2005 10:51:17 -0500 (EST)
Received: from smtp.persistent.co.in ([202.54.11.65])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehr3N-0002Vo-1l
	for sip@ietf.org; Thu, 01 Dec 2005 11:13:02 -0500
Received: from mail.persistent.co.in ([10.12.0.1])
	by smtp.persistent.co.in (8.12.9/) with ESMTP id jB1FpiuV023261
	for <sip@ietf.org>; Thu, 1 Dec 2005 21:21:50 +0530
Received: from ps0692 ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR)
	with ESMTP id AFR84348; Thu, 1 Dec 2005 21:21:26 +0530 (IST)
From: "Manjeet Soodan" <manjeet_soodan@persistent.co.in>
To: "Sip" <sip@ietf.org>
Date: Thu, 1 Dec 2005 21:22:25 +0530
Message-ID: <FJEHJDAEBPFKHPAKBFJGOEBECEAA.manjeet_soodan@persistent.co.in>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-Whitelist: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: [Sip] Diversion Header Question
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

Below is the scenario i am trying in case of Voice Mail :-

1) A,B,C are MGCP subscribers.
2) B has CFNA to C, C has CFNA to Voice Mail server(over SIP).
3) A calls B, B doesn't Answer and Call gets forwarded to C, C remains
OnHook and Call gets diverted to the Voice Mail server over SIP.

A INVITE message goes to the Voice Mail Server with a Diversion header
containing B's Number. But i think the Diversion header should contain C's
number because it's
C from where the Call finally got diverted to the Voice Mail server. Am i
right?


Thanks,
-Manjeet





_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 01 13:09:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ehsrz-00058u-2i; Thu, 01 Dec 2005 13:09:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehsrx-00056D-7t
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 13:09:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26515
	for <sip@ietf.org>; Thu, 1 Dec 2005 13:08:33 -0500 (EST)
Received: from mx01.net.com ([134.56.3.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhtCS-0007r0-Ds
	for sip@ietf.org; Thu, 01 Dec 2005 13:30:33 -0500
Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13])
	by mx01.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	jB1I90es028994; Thu, 1 Dec 2005 10:09:00 -0800 (PST)
Received: from fmt-ex01.net.com (fmt-exchange.net.com [134.56.112.251])
	by mx01-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	jB1I8q5C009819; Thu, 1 Dec 2005 10:08:52 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Diversion Header Question
Date: Thu, 1 Dec 2005 10:08:51 -0800
Message-ID: <E5CB8BF27E39374ABE7C56E1FF20497C76F5C9@fmt-ex01.net.com>
Thread-Topic: [Sip] Diversion Header Question
Thread-Index: AcX2j773O0XO0KeiROeznTBoTCksygAElPqA
From: "Sreedhar Pampati" <Sreedhar_Pampati@net.com>
To: "Manjeet Soodan" <manjeet_soodan@persistent.co.in>, "Sip" <sip@ietf.org>
X-Spam-Status: No, hits=-0.1 required=8.0 tests=AWL autolearn=ham version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fmt-spam02.net.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi Manjeet,
  I am not sure which draft you are going by. If you refer to the
section "7.5 Multiple Diversions" in draft-levy-sip-diversion-08.txt you
will find that adding multiple diversion headers is useful in scenarios
like you described.
HTH
Sreedhar


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Manjeet Soodan
Sent: Thursday, December 01, 2005 7:52 AM
To: Sip
Subject: [Sip] Diversion Header Question

Hi,

Below is the scenario i am trying in case of Voice Mail :-

1) A,B,C are MGCP subscribers.
2) B has CFNA to C, C has CFNA to Voice Mail server(over SIP).
3) A calls B, B doesn't Answer and Call gets forwarded to C, C remains
OnHook and Call gets diverted to the Voice Mail server over SIP.

A INVITE message goes to the Voice Mail Server with a Diversion header
containing B's Number. But i think the Diversion header should contain
C's
number because it's
C from where the Call finally got diverted to the Voice Mail server. Am
i
right?


Thanks,
-Manjeet





_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 01 17:40:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ehx6K-0006dR-QM; Thu, 01 Dec 2005 17:40:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehx6I-0006dJ-EO
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 17:40:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26477
	for <sip@ietf.org>; Thu, 1 Dec 2005 17:39:40 -0500 (EST)
Received: from web31514.mail.mud.yahoo.com ([68.142.198.143])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhxQr-0001KF-LL
	for sip@ietf.org; Thu, 01 Dec 2005 18:01:42 -0500
Received: (qmail 61580 invoked by uid 60001); 1 Dec 2005 22:40:15 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=ZmANJ7xKkv0BBwQWXud2hGCghm6yY3YmgRpPMwjR3xj4KSEyPQIgzJeiNqybEayrQo0HpV3cU4jRfH9/Sh23vQkpAHJUF4mTL1yV1yKTVrwg/BK6H3cndRonxQ0QIgjh93qFmNzk2yd26QhTnt7qmDBHI30Gb85fUaCW9eXz3so=
	; 
Message-ID: <20051201224015.61578.qmail@web31514.mail.mud.yahoo.com>
Received: from [198.152.12.67] by web31514.mail.mud.yahoo.com via HTTP;
	Thu, 01 Dec 2005 22:40:15 GMT
Date: Thu, 1 Dec 2005 22:40:15 +0000 (GMT)
From: Kapil Nayar <kapilnayar@yahoo.com>
Subject: RE: [Sip] [SIP Cacel Method]
To: "Prakash  Maria susai  - NPD, Chennai" <uprakash@npd.hcltech.com>,
	sreeram.kanumuri@wipro.com, shuping.chen@cecwireless.com.cn, sip@ietf.org
In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47E016BCA9A@npd-mail.hclt-ntl.co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Content-Transfer-Encoding: 8bit
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi

I guess you are confusing the timerB with timerA - 
timerB(64xT1) is the transaction timeout timer started
to receive the final response to INVITE. If it
expires, the UAC should consider the transaction
cancelled and may destroy the local context. While
some implementations would like to send CANCEL just to
make sure the INVITE is indeed cancelled.

The situation may occur in case where the UAC sent the
CANCEL on timeout and also destroyed the local context
(though this shouldn't occur in normal circumstances).
The 200OK to CANCEL completes the CANCEL transaction.
However, the 487 response (from UAS) to INVITE (which
doesnot exist at UAC) would result in retransmissions
from the UAS.

Well I guess upon timerH timeout on UAS the 487
response retransmissions should stop.

Let me know if I missed something here....

thanks,
-kapil nayar  

 
--- "Prakash  Maria susai  - NPD, Chennai"
<uprakash@npd.hcltech.com> wrote:

> Hi,
>  
> As Sreeram has mentioned, it cannot be Timer B,
> since Timer B is not active
> once 1xx is got.
> The some other timer could be a Timer started
> through Expires Header
> indicated in INVITE request.
>  
> Thanks,
> Prakash.
> 
> -----Original Message-----
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org]On Behalf Of
> sreeram.kanumuri@wipro.com
> Sent: Wednesday, November 30, 2005 1:04 PM
> To: shuping.chen@cecwireless.com.cn; sip@ietf.org
> Subject: RE: [Sip] [SIP Cacel Method]
> 
> 
> Yes you must generate ACK in second case also.
>  
> also, in case2) it is not "timerb timeout" as the
> caller received
> provisional response its state machine goes to
> "proceeding state"
> It should be some other timer implemented  at the
> uac to handle the case
> when there is no final response in the "proceeding
> state"    
>  
> HTH,
> Sreeram.
> 
>   _____  
> 
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org] On Behalf Of Chen
> Shuping
> Sent: Wednesday, November 30, 2005 11:50 AM
> To: sip@ietf.org
> Subject: [Sip] [SIP Cacel Method]
> 
> 
> Hi,All
>  
>   I have such a doubt:
>  
>    In RFC 3261 17.1.1.2  Time_B timeout in Calling
> state,Invite transaction
> transit to terminated
>  
> state,What if Timer_B timeout in Proceeding 
> state(this could happen when
> the callee is not in office,
>  
> his softphone keep ringring until caller's timer_b
> timeout).
>  
> In my implementation my call flow like this:
>  
> CASE 1:
>  
> caller                                         
> callee
> ------------INVITE------------------->
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller hang up
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> ---------------ACK------------------>
>  
> CASE 2:
>  
> INVITE-------------------> 
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller keep waiting ,Timer_b time out
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
>  
> My question is should I generate ACK for the second
> case.
>  
>  
> Thanks
>  
>  
>  
>  
> 
> 
> Disclaimer:
> 
> This message and any attachment(s) contained here
> are information that is confidential, proprietary to
> HCL Technologies and its customers, privileged or
> otherwise protected by law. The information is
> solely intended for the individual or the entity it
> is addressed to. If you are not the intended
> recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate
> this message or any part of it. If you have received
> this e-mail in error, please notify the sender
> immediately by return e-mail and delete it from your
> computer.
> > _______________________________________________
> 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



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.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



From sip-bounces@ietf.org Thu Dec 01 18:37:17 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhxzJ-0000Vy-35; Thu, 01 Dec 2005 18:37:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxzH-0000UY-Mm
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 18:37:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02108
	for <sip@ietf.org>; Thu, 1 Dec 2005 18:36:29 -0500 (EST)
Received: from web34710.mail.mud.yahoo.com ([209.191.68.159])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhyJq-0003LG-6S
	for sip@ietf.org; Thu, 01 Dec 2005 18:58:31 -0500
Received: (qmail 61803 invoked by uid 60001); 1 Dec 2005 23:37:02 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=EodCxKSjmjmd0omZ7j0LroncXDLD0TTmEYlqwKKFyXbM7KFsTQzb/MzgwnrYbYhQ24zM3pr+Q6IQaAwvnYfEPdHiEPfAutJXzPbNsFOi7MBXHeYQ79UZDHrAy5XdvPwHzQ6xapzQdwW6LqawE3tdBGSXtUE/cN4HlleJEaUZKcc=
	; 
Message-ID: <20051201233702.61801.qmail@web34710.mail.mud.yahoo.com>
Received: from [134.56.105.33] by web34710.mail.mud.yahoo.com via HTTP;
	Thu, 01 Dec 2005 15:37:02 PST
Date: Thu, 1 Dec 2005 15:37:02 -0800 (PST)
From: Manish Joshi <mjoshi_blr@yahoo.com>
Subject: Re: [Sip] Diversion Header Question
To: Manjeet Soodan <manjeet_soodan@persistent.co.in>, Sip <sip@ietf.org>
In-Reply-To: <FJEHJDAEBPFKHPAKBFJGOEBECEAA.manjeet_soodan@persistent.co.in>
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: 
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="===============1666629898=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============1666629898==
Content-Type: multipart/alternative; boundary="0-1019154595-1133480222=:61464"
Content-Transfer-Encoding: 8bit

--0-1019154595-1133480222=:61464
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Actually in this case it should contain two Diversion Headers since there are two hops involved. The lower one should contain B's number and upper one should contain C's.
   
  B is actually an Original Called Number. I guess if only one Diversion Header is present, its more of an implementation option regarding which Hope information should be present.

  -Manish
  
Manjeet Soodan <manjeet_soodan@persistent.co.in> wrote:
  Hi,

Below is the scenario i am trying in case of Voice Mail :-

1) A,B,C are MGCP subscribers.
2) B has CFNA to C, C has CFNA to Voice Mail server(over SIP).
3) A calls B, B doesn't Answer and Call gets forwarded to C, C remains
OnHook and Call gets diverted to the Voice Mail server over SIP.

A INVITE message goes to the Voice Mail Server with a Diversion header
containing B's Number. But i think the Diversion header should contain C's
number because it's
C from where the Call finally got diverted to the Voice Mail server. Am i
right?


Thanks,
-Manjeet





_______________________________________________
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
  


		
---------------------------------
 Yahoo! Personals
 Single? There's someone we'd like you to meet.
 Lots of someones, actually. Yahoo! Personals
--0-1019154595-1133480222=:61464
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Actually in this case it should contain two Diversion Headers since there are two hops involved. The lower one should contain B's number and upper one should contain C's.</DIV>  <DIV>&nbsp;</DIV>  <DIV>B is actually an Original Called Number. I guess if only one Diversion Header is present, its more of an implementation option regarding which&nbsp;Hope information&nbsp;should be present.<BR></DIV>  <DIV>-Manish</DIV>  <DIV><BR><B><I>Manjeet Soodan &lt;manjeet_soodan@persistent.co.in&gt;</I></B> wrote:</DIV>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi,<BR><BR>Below is the scenario i am trying in case of Voice Mail :-<BR><BR>1) A,B,C are MGCP subscribers.<BR>2) B has CFNA to C, C has CFNA to Voice Mail server(over SIP).<BR>3) A calls B, B doesn't Answer and Call gets forwarded to C, C remains<BR>OnHook and Call gets diverted to the Voice Mail server over SIP.<BR><BR>A INVITE message goes to the Voice Mail Server!
  with a
 Diversion header<BR>containing B's Number. But i think the Diversion header should contain C's<BR>number because it's<BR>C from where the Call finally got diverted to the Voice Mail server. Am i<BR>right?<BR><BR><BR>Thanks,<BR>-Manjeet<BR><BR><BR><BR><BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>This list is for NEW development of the core SIP Protocol<BR>Use sip-implementors@cs.columbia.edu for questions on current sip<BR>Use sipping@ietf.org for new developments on the application of sip<BR></BLOCKQUOTE>  <DIV><BR></DIV><p>
		<hr size=1> <B>Yahoo! Personals</B><BR> 
Single? There's someone we'd like you to meet.<BR> 
Lots of someones, actually. <a href="http://us.rd.yahoo.com/evt=36108/*http://personals.yahoo.com 
">Yahoo! Personals</a>
--0-1019154595-1133480222=:61464--


--===============1666629898==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1666629898==--




From sip-bounces@ietf.org Thu Dec 01 20:26:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhzhL-0003Bz-Ke; Thu, 01 Dec 2005 20:26:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhzhK-0003Bp-9C
	for sip@megatron.ietf.org; Thu, 01 Dec 2005 20:26:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15223
	for <sip@ietf.org>; Thu, 1 Dec 2005 20:26:02 -0500 (EST)
Received: from [219.141.250.5] (helo=mail)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei01u-00080Q-72
	for sip@ietf.org; Thu, 01 Dec 2005 20:48:07 -0500
Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.5.48])
	by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May
	7 2001)) with ESMTPA id <0IQU00J2MJZP4Z@mail.cecwireless.com.cn> for
	sip@ietf.org; Fri, 02 Dec 2005 09:26:17 +0800 (CST)
Date: Fri, 02 Dec 2005 09:26:20 +0800
From: Chen Shuping <shuping.chen@cecwireless.com.cn>
Subject: =?gb2312?B?tPC4tDogW1NpcF0gW1NJUCBDYWNlbCBNZXRob2Rd?=
In-reply-to: <20051201224015.61578.qmail@web31514.mail.mud.yahoo.com>
To: "'Kapil Nayar'" <kapilnayar@yahoo.com>,
	"'Prakash  Maria susai  - NPD, Chennai'" <uprakash@npd.hcltech.com>,
	sreeram.kanumuri@wipro.com, shuping.chen@cecwireless.com.cn
Message-id: <001e01c5f6df$6661ea00$3005020a@cecwireless.com.cn>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: AcX2yD5bXQO5JaA4T4mSQF8C8aLIBQAFkl4w
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--inline=20

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Kapil Nayar [mailto:kapilnayar@yahoo.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA12=D4=C22=C8=D5 6:40
=CA=D5=BC=FE=C8=CB: Prakash Maria susai - NPD, Chennai; =
sreeram.kanumuri@wipro.com;
shuping.chen@cecwireless.com.cn; sip@ietf.org
=D6=F7=CC=E2: RE: [Sip] [SIP Cacel Method]

Hi

I guess you are confusing the timerB with timerA -
timerB(64xT1) is the transaction timeout timer started to receive the =
final
response to INVITE. If it expires, the UAC should consider the =
transaction
cancelled and may destroy the local context. While some implementations
would like to send CANCEL just to make sure the INVITE is indeed =
cancelled.

The situation may occur in case where the UAC sent the CANCEL on timeout =
and
also destroyed the local context (though this shouldn't occur in normal
circumstances).
The 200OK to CANCEL completes the CANCEL transaction.
However, the 487 response (from UAS) to INVITE (which doesnot exist at =
UAC)
would result in retransmissions from the UAS.

--It is excacly my case,I use Timer_B as Invitie Transaction =
Timer_B,When
Timer_B fires,if no final response arrived,I
--send cancel to confirm the transaction cacelation.
--Thank all of you,Now,I introduce a session timer to proect call time
out,And Keep timer_b a sip stack layer to
--keep a call manager from error or wrong implementation.

--Thank you

Well I guess upon timerH timeout on UAS the 487 response retransmissions
should stop.

Let me know if I missed something here....

thanks,
-kapil nayar =20

=20
--- "Prakash  Maria susai  - NPD, Chennai"
<uprakash@npd.hcltech.com> wrote:

> Hi,
> =20
> As Sreeram has mentioned, it cannot be Timer B, since Timer B is not=20
> active once 1xx is got.
> The some other timer could be a Timer started through Expires Header=20
> indicated in INVITE request.
> =20
> Thanks,
> Prakash.
>=20
> -----Original Message-----
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org]On Behalf Of sreeram.kanumuri@wipro.com
> Sent: Wednesday, November 30, 2005 1:04 PM
> To: shuping.chen@cecwireless.com.cn; sip@ietf.org
> Subject: RE: [Sip] [SIP Cacel Method]
>=20
>=20
> Yes you must generate ACK in second case also.
> =20
> also, in case2) it is not "timerb timeout" as the caller received=20
> provisional response its state machine goes to "proceeding state"
> It should be some other timer implemented  at the uac to handle the=20
> case when there is no final response in the "proceeding
> state"   =20
> =20
> HTH,
> Sreeram.
>=20
>   _____
>=20
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org] On Behalf Of Chen Shuping
> Sent: Wednesday, November 30, 2005 11:50 AM
> To: sip@ietf.org
> Subject: [Sip] [SIP Cacel Method]
>=20
>=20
> Hi,All
> =20
>   I have such a doubt:
> =20
>    In RFC 3261 17.1.1.2  Time_B timeout in Calling state,Invite=20
> transaction transit to terminated
> =20
> state,What if Timer_B timeout in Proceeding state(this could happen=20
> when the callee is not in office,
> =20
> his softphone keep ringring until caller's timer_b timeout).
> =20
> In my implementation my call flow like this:
> =20
> CASE 1:
> =20
> caller                                        =20
> callee
> ------------INVITE------------------->
> <-----------100 Trying----------------- <-----------180=20
> Ringing--------------
> =20
> caller hang up
> =20
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> ---------------ACK------------------>
> =20
> CASE 2:
> =20
> INVITE------------------->=20
> <-----------100 Trying----------------- <-----------180=20
> Ringing--------------
> =20
> caller keep waiting ,Timer_b time out
> =20
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
>=20
> <-------------487----------------------
>=20
> <-------------487----------------------
>=20
> <-------------487----------------------
>=20
> <-------------487----------------------
> =20
> My question is should I generate ACK for the second case.
> =20
> =20
> Thanks
> =20
> =20
> =20
> =20
>=20
>=20
> Disclaimer:
>=20
> This message and any attachment(s) contained here are information that =

> is confidential, proprietary to HCL Technologies and its customers,=20
> privileged or otherwise protected by law. The information is solely=20
> intended for the individual or the entity it is addressed to. If you=20
> are not the intended recipient of this message, you are not authorized =

> to read, forward, print, retain, copy or disseminate this message or=20
> any part of it. If you have received this e-mail in error, please=20
> notify the sender immediately by return e-mail and delete it from your =

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



=09
=09
	=09
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.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



From sip-bounces@ietf.org Fri Dec 02 06:34:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei9Bo-0003ul-7P; Fri, 02 Dec 2005 06:34:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei9Bl-0003uY-Mu
	for sip@megatron.ietf.org; Fri, 02 Dec 2005 06:34:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10562
	for <sip@ietf.org>; Fri, 2 Dec 2005 06:34:06 -0500 (EST)
Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei9WR-0003G8-38
	for sip@ietf.org; Fri, 02 Dec 2005 06:56:15 -0500
Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by
	hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2657.72)
	id WFGCQLT7; Fri, 2 Dec 2005 17:04:42 +0530
Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72)
	id <YDGNMFWQ>; Fri, 2 Dec 2005 17:04:41 +0530
Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E016BCFA2@npd-mail.hclt-ntl.co.in>
From: "Prakash  Maria susai  - NPD, Chennai" <uprakash@npd.hcltech.com>
To: Kapil Nayar <kapilnayar@yahoo.com>,
	"Prakash  Maria susai  - NPD, Chennai" <uprakash@npd.hcltech.com>,
	sreeram.kanumuri@wipro.com, shuping.chen@cecwireless.com.cn, sip@ietf.org
Subject: RE: [Sip] [SIP Cacel Method]
Date: Fri, 2 Dec 2005 17:04:41 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi Kapil,

Please see my comments inline....

-----Original Message-----
From: Kapil Nayar [mailto:kapilnayar@yahoo.com]
Sent: Friday, December 02, 2005 4:10 AM
To: Prakash Maria susai - NPD, Chennai; sreeram.kanumuri@wipro.com;
shuping.chen@cecwireless.com.cn; sip@ietf.org
Subject: RE: [Sip] [SIP Cacel Method]


Hi

I guess you are confusing the timerB with timerA - 
timerB(64xT1) is the transaction timeout timer started
to receive the final response to INVITE. 
[Prakash]=> It is true, that timer B is the transaction timeout.

If it
expires, the UAC should consider the transaction
cancelled and may destroy the local context. While
some implementations would like to send CANCEL just to
make sure the INVITE is indeed cancelled.
[Prakash]=> When timer B fires, implementations may send a CANCEL, though it
is not mentioned so in the RFC.
What I meant to convey was that it is not a MUST to send CANCEL when timer B
fires.
Section 17.1.1.2 does NOT mention that transaction must inform the TU, when
timeout has occurred in "Proceeding" state.
It however, mentions that transaction should inform the TU, when timeout has
occurred in "Calling" state.

The Expires header serves this purpose. It would start a timer on sending
INVITE, and on expiry, would send CANCEL.
 
Please let me know if the understanding is wrong.
Thanks,
Prakash.


 
--- "Prakash  Maria susai  - NPD, Chennai"
<uprakash@npd.hcltech.com> wrote:

> Hi,
>  
> As Sreeram has mentioned, it cannot be Timer B,
> since Timer B is not active
> once 1xx is got.
> The some other timer could be a Timer started
> through Expires Header
> indicated in INVITE request.
>  
> Thanks,
> Prakash.
> 
> -----Original Message-----
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org]On Behalf Of
> sreeram.kanumuri@wipro.com
> Sent: Wednesday, November 30, 2005 1:04 PM
> To: shuping.chen@cecwireless.com.cn; sip@ietf.org
> Subject: RE: [Sip] [SIP Cacel Method]
> 
> 
> Yes you must generate ACK in second case also.
>  
> also, in case2) it is not "timerb timeout" as the
> caller received
> provisional response its state machine goes to
> "proceeding state"
> It should be some other timer implemented  at the
> uac to handle the case
> when there is no final response in the "proceeding
> state"    
>  
> HTH,
> Sreeram.
> 
>   _____  
> 
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org] On Behalf Of Chen
> Shuping
> Sent: Wednesday, November 30, 2005 11:50 AM
> To: sip@ietf.org
> Subject: [Sip] [SIP Cacel Method]
> 
> 
> Hi,All
>  
>   I have such a doubt:
>  
>    In RFC 3261 17.1.1.2  Time_B timeout in Calling
> state,Invite transaction
> transit to terminated
>  
> state,What if Timer_B timeout in Proceeding 
> state(this could happen when
> the callee is not in office,
>  
> his softphone keep ringring until caller's timer_b
> timeout).
>  
> In my implementation my call flow like this:
>  
> CASE 1:
>  
> caller                                         
> callee
> ------------INVITE------------------->
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller hang up
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> ---------------ACK------------------>
>  
> CASE 2:
>  
> INVITE-------------------> 
> <-----------100 Trying-----------------
> <-----------180 Ringing--------------
>  
> caller keep waiting ,Timer_b time out
>  
> --------------Cancel----------------->
> <-------------200 for Cancel--------
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
> 
> <-------------487----------------------
>  
> My question is should I generate ACK for the second
> case.
>  
>  
> Thanks
>  
>  
>  
>  
> 
> 
> Disclaimer:
> 
> This message and any attachment(s) contained here
> are information that is confidential, proprietary to
> HCL Technologies and its customers, privileged or
> otherwise protected by law. The information is
> solely intended for the individual or the entity it
> is addressed to. If you are not the intended
> recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate
> this message or any part of it. If you have received
> this e-mail in error, please notify the sender
> immediately by return e-mail and delete it from your
> computer.
> > _______________________________________________
> 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



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.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



From sip-bounces@ietf.org Fri Dec 02 13:51:14 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiG01-0001GY-U9; Fri, 02 Dec 2005 13:51:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFzz-0001GO-Pb
	for sip@megatron.ietf.org; Fri, 02 Dec 2005 13:51:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01006
	for <sip@ietf.org>; Fri, 2 Dec 2005 13:50:24 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiGKi-00021O-Kv
	for sip@ietf.org; Fri, 02 Dec 2005 14:12:38 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-4.cisco.com with ESMTP; 02 Dec 2005 10:51:01 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB2Io3Qg006235;
	Fri, 2 Dec 2005 10:50:59 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 2 Dec 2005 13:50:57 -0500
Received: from [161.44.79.90] ([161.44.79.90]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 13:50:56 -0500
Message-ID: <43909790.2080101@cisco.com>
Date: Fri, 02 Dec 2005 13:50:56 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Karthik Kamaraj - NPD, Chennai" <karthikk@npd.hcltech.com>
Subject: Re: [Sip] Regarding Registrar behaviour in GRUU draft
References: <4B1D6623CCBD79489DE28D1CA062A47E0160902B@npd-mail.hclt-ntl.co.in>
In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47E0160902B@npd-mail.hclt-ntl.co.in>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Dec 2005 18:50:56.0892 (UTC)
	FILETIME=[5460C3C0:01C5F771]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Did anyone respond to this?

Karthik Kamaraj - NPD, Chennai wrote:
> 
>> -----Original Message-----
>>From: 	Karthik Kamaraj - NPD, Chennai  
>>Sent:	Saturday, November 19, 2005 1:18 PM
>>To:	'sip-bounces@ietf.org'
>>Subject:	RE: Regarding Registrar behaviour in GRUU draft
>>
>>Hi,
>>       I have one more doubt regarding this.Suppose Consider a case where
>>UA Sends REGISTER request with Supported header has option tag as "gruu"
>>and two Contact header one has "+sip.instance" header param another
>>doesn't have it.
>>       I want to know the behaviour of registrar in this case.
>>Thanks in advance,

IMO it should register both contacts and return a response containing 
them. The one with the instance should come back with a GRUU, while the 
one without an instance should be returned without a GRUU.

	Paul

>>Karthik
>>
>>	 -----Original Message-----
>>	From: 	Karthik Kamaraj - NPD, Chennai  
>>	Sent:	Friday, November 18, 2005 8:46 PM
>>	To:	'sip-bounces@ietf.org'
>>	Subject:	Regarding Registrar behaviour in GRUU draft
>>
>>	Hi,
>>	       Section in draft-ietf-sip-gruu-06 states that "As the
>>registrar is processing the contacts in the REGISTER   request according
>>to the procedures of step 7 in Section 10.3 of RFC 3261,
>>	the registrar checks whether each Contact header field in the
>>REGISTER message contains a "+sip.instance" header field parameter.If
>>present, the contact is processed further. "
>>
>>	I want to know the behaviour of Registrar if it received REGISTER
>>request with Supported header has option tag as "gruu", but Contact header
>>doesn't have "+sip.instance" header parameter. 
>>
>>	Thanks,
>>	Karthik 
>>
> 
> 
> 
> Disclaimer:
> 
> This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Fri Dec 02 21:04:55 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiMli-00075Z-VW; Fri, 02 Dec 2005 21:04:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiMlh-00075U-QH
	for sip@megatron.ietf.org; Fri, 02 Dec 2005 21:04:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29841
	for <sip@ietf.org>; Fri, 2 Dec 2005 21:04:04 -0500 (EST)
Message-Id: <200512030204.VAA29841@ietf.org>
Received: from [202.205.253.249] (helo=sammy.buptnet.edu.cn)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiN6O-0005CQ-Mf
	for sip@ietf.org; Fri, 02 Dec 2005 21:26:22 -0500
Received: (qmail 31525 invoked by uid 89); 3 Dec 2005 02:03:56 -0000
Received: by simscan 1.1.0 ppid: 31518, pid: 31521, t: 0.5186s
	scanners: attach: 1.1.0 clamav: 0.85.1/m:31/d:897 spam: 3.0.2
Received: from unknown (HELO WANGY) (wangy@61.51.67.186)
	by 0 with SMTP; 3 Dec 2005 02:03:56 -0000
From: "??" <wangy@buptnet.edu.cn>
To: <sip@ietf.org>
Date: Sat, 3 Dec 2005 10:03:58 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcX3rdLFGFVgHg9rShSLowfs5u79bA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sammy
X-Spam-Status: No, score=-100.9 required=5.0 tests=AWL,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.0.2
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31
Content-Transfer-Encoding: 7bit
Subject: [Sip] unsubcribe
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org




_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 05 02:05:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjAPY-000111-VC; Mon, 05 Dec 2005 02:05:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjAPX-0000zY-DB
	for sip@megatron.ietf.org; Mon, 05 Dec 2005 02:05:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08350
	for <sip@ietf.org>; Mon, 5 Dec 2005 02:04:28 -0500 (EST)
Received: from nproxy.gmail.com ([64.233.182.193])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjAkk-0004q5-Sw
	for sip@ietf.org; Mon, 05 Dec 2005 02:27:17 -0500
Received: by nproxy.gmail.com with SMTP id b2so465188nfe
	for <sip@ietf.org>; Sun, 04 Dec 2005 23:05:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=A2O/fvBYG7YrZKqQJAsSGitsLaG7iSpK6Vux5HrAF6gY9wLBxAT0CpcC6RhjMwWtDH15ju5zDneXmyiL3QeXIzaxSdUbRVhX5w8fZdasRxxoPIihZa62sCGxxxnQZuGrPwd4zFHts8+Ad0uRKG2asPXJUNWelxIYG9RnMw8cU/s=
Received: by 10.48.232.13 with SMTP id e13mr1706023nfh;
	Sun, 04 Dec 2005 23:05:13 -0800 (PST)
Received: by 10.48.215.16 with HTTP; Sun, 4 Dec 2005 23:05:13 -0800 (PST)
Message-ID: <52db68bc0512042305g1725c8e3oe864c036829909c2@mail.gmail.com>
Date: Mon, 5 Dec 2005 12:35:13 +0530
From: Sudhir Kumar Reddy <t.sudhirkumar@gmail.com>
To: sip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Subject: [Sip] Query in mutliple Subscribes
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="===============1299249407=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============1299249407==
Content-Type: multipart/alternative; 
	boundary="----=_Part_10818_26259257.1133766313040"

------=_Part_10818_26259257.1133766313040
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

If I want to Subscribe to multilple Users i.e. If I Subscribe to User A and
User B respectively. Is that Ok if i had same call-ID with User A and User
B.

thanks in advance

regards
Sudhir



--
-----------------------------------------------
"The mathematical precision of the universe reveals the mathematical mind o=
f
God." --- Albert Einstein
-----------------------------------------------

------=_Part_10818_26259257.1133766313040
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><br clear=3D"all">Hi all,</div>
<div>&nbsp;</div>
<div>If I want to Subscribe to multilple Users i.e. If I Subscribe to&nbsp;=
User A&nbsp;and User B respectively. Is that Ok if i had same call-ID with =
User A and User B.</div>
<div>&nbsp;</div>
<div>thanks in advance</div>
<div>&nbsp;</div>
<div>regards</div>
<div>Sudhir</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><br>-- <br>-----------------------------------------------<br>&quot;Th=
e mathematical precision of the universe reveals the mathematical mind of G=
od.&quot; --- Albert Einstein <br>-----------------------------------------=
------
<br><br>&nbsp;</div>

------=_Part_10818_26259257.1133766313040--


--===============1299249407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1299249407==--




From sip-bounces@ietf.org Mon Dec 05 10:17:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjI5l-0007pn-Vw; Mon, 05 Dec 2005 10:17:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjI5h-0007nn-5q; Mon, 05 Dec 2005 10:17:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01337;
	Mon, 5 Dec 2005 10:16:31 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjIQz-0005Js-V0; Mon, 05 Dec 2005 10:39:23 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 05 Dec 2005 07:17:02 -0800
X-IronPort-AV: i="3.99,217,1131350400"; 
	d="scan'208"; a="373984109:sNHT1666046576"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB5FGaQc004612;
	Mon, 5 Dec 2005 07:17:00 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 5 Dec 2005 10:16:21 -0500
Received: from [192.168.1.102] ([10.86.242.24]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 10:16:20 -0500
Message-ID: <439459C4.7000808@cisco.com>
Date: Mon, 05 Dec 2005 10:16:20 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Midcom <midcom@ietf.org>, Behave <ietf-behave@list.sipfoundry.org>,
	IETF MMUSIC WG <mmusic@ietf.org>, IETF SIP List <sip@ietf.org>,
	IETF Sipping List <sipping@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Dec 2005 15:16:20.0864 (UTC)
	FILETIME=[D8E81000:01C5F9AE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Sip] Fora for TURN discussion: BEHAVE list
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Sorry for the broad distribution here, but I wanted to let folks know 
that I'm going to be moving discussions on TURN over to the behave list 
(http://www.ietf.org/html.charters/behave-charter.html).   I'll be 
posting some issues shortly which require discussion, so if you are 
interested, please subscribe there.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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



From sip-bounces@ietf.org Mon Dec 05 15:56:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjNO3-00083c-Jr; Mon, 05 Dec 2005 15:56:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNO2-00082B-Fo
	for sip@megatron.ietf.org; Mon, 05 Dec 2005 15:56:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09849
	for <sip@ietf.org>; Mon, 5 Dec 2005 15:55:48 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjNjN-0000d7-NB
	for sip@ietf.org; Mon, 05 Dec 2005 16:18:42 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id B0D146C023
	for <sip@ietf.org>; Mon,  5 Dec 2005 15:56:27 -0500 (EST)
Subject: Re: [Sip] Query in mutliple Subscribes
From: "Dale R. Worley" <dworley@pingtel.com>
To: Sip <sip@ietf.org>
In-Reply-To: <52db68bc0512042305g1725c8e3oe864c036829909c2@mail.gmail.com>
References: <52db68bc0512042305g1725c8e3oe864c036829909c2@mail.gmail.com>
Content-Type: text/plain
Date: Mon, 05 Dec 2005 15:56:27 -0500
Message-Id: <1133816187.22520.51.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Mon, 2005-12-05 at 12:35 +0530, Sudhir Kumar Reddy wrote:
> If I want to Subscribe to multilple Users i.e. If I Subscribe to User
> A and User B respectively. Is that Ok if i had same call-ID with User
> A and User B.

No.

Call-Id's should be unique for each dialog that you set up.  In this
regard, each of these SUBSCRIBEs is a different dialog.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 05 16:17:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjNgY-0004mr-G5; Mon, 05 Dec 2005 16:15:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNgV-0004mf-Dq
	for sip@megatron.ietf.org; Mon, 05 Dec 2005 16:15:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11784
	for <sip@ietf.org>; Mon, 5 Dec 2005 16:14:53 -0500 (EST)
Received: from mail.siemenscom.com ([12.146.131.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjO1r-0001Eb-4h
	for sip@ietf.org; Mon, 05 Dec 2005 16:37:48 -0500
Received: from fdns2.rolm.com (imail2.icn.siemens.com [165.218.1.59])
	by mail.siemenscom.com (8.13.4/8.13.4) with ESMTP id jB5LGLdj027655
	for <sip@ietf.org>; Mon, 5 Dec 2005 13:16:21 -0800 (PST)
Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com
	[165.218.68.180])
	by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id jB5LFbiL001124
	for <sip@ietf.org>; Mon, 5 Dec 2005 13:15:38 -0800 (PST)
Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72)
	id <XF9GZLST>; Mon, 5 Dec 2005 13:15:36 -0800
Message-ID: <4B8DD52AB570D311BEDE0008C7E619880D6D21F4@BOCA212A>
From: "Vaidya, Maulik" <maulik.vaidya@siemens.com>
To: Sip <sip@ietf.org>
Subject: RE: [Sip] Query in mutliple Subscribes
Date: Mon, 5 Dec 2005 13:13:15 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Either that or you could put A and B in a group and subscribe to that group
thereby having only one call-ID.

Maulik

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale
R. Worley
Sent: Monday, December 05, 2005 3:56 PM
To: Sip
Subject: Re: [Sip] Query in mutliple Subscribes

On Mon, 2005-12-05 at 12:35 +0530, Sudhir Kumar Reddy wrote:
> If I want to Subscribe to multilple Users i.e. If I Subscribe to User
> A and User B respectively. Is that Ok if i had same call-ID with User
> A and User B.

No.

Call-Id's should be unique for each dialog that you set up.  In this
regard, each of these SUBSCRIBEs is a different dialog.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 04:50:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjZTH-0006qb-0t; Tue, 06 Dec 2005 04:50:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjZTE-0006pS-QO; Tue, 06 Dec 2005 04:50:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00682;
	Tue, 6 Dec 2005 04:49:57 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EjZof-0001hE-Kn; Tue, 06 Dec 2005 05:12:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Dec 2005 10:54:12 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D461B227B@oefeg-s04.oefeg.loc>
Thread-Topic: SIP AoR, tel and ENUM
Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoA==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <voipeer@lists.uoregon.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, sip@ietf.org
Subject: [Sip] SIP AoR, tel and ENUM
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Folks,

This post is primarily to SPEER, but since it also concerns ENUM and SIP
I cross-post it.

I need (urgently) some guidance on the question what SIP URIs to
use in Infrastructure ENUM.

User ENUM as defined in RFC 3761 provides a mapping from E.164 numbers
to SIP URIs for primarily for end-users. So what you get back is the
AoR pointing to the destination SIP server.

If you get something back on the ENUM query such as
sip:Richard@stastny.com,
this is definetely an AoR. Because of privacy reasons, more and more
people
start using SIP URI such as
sip:4319793321@provider.net or (an AoR)
sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even
sip:+4319793321@provider.net

IMHO the last one should not be used, and some guidance
is also needed here. but it only concerns the destination
server and if the destination servers can deal with it, fine.

Now with Infrastructure ENUM (and especially in combination
with private ENUMs) the situation is different.

The purpose of Infrastructure ENUM is according to the
re-chartered ENUM WG "to discover points of interconnection necessary to
terminate communications sessions identified by a E164 number,
in addition to identifying end point protocols and services."

This translates to: Infrastructure ENUM does not necessarily contain
end-point information (AoR), but routing information. Routing, in my
definition here, is basically to provide you with the information what
the next hop is.

A very common scenario is the following one: a walled garden network
is using private ENUM to detect the border element for a given number,
Some border element may lead to another private (extranet), using
a federated ENUM for this number, another may be connected to the=20
Internet using public Infrastructure ENUM for another number.
Public Infrastructure ENUM is giving back the ingress border
element, which in turn uses private ENUM again to find the
SIP server hosting the user with this number.

In addition, again for privacy reasons, in most cases the above
mentioned SIP URIs containing E.164 numbers are used.

This raises two issues, an architectural one and a BCP one:

To principally different scenarios are possible

Scenario A

ENUM is providing ONLY the mapping from the E.164 number
to an AoR. (=3D name to address mapping)
The above described routing between the networks
to find the destination network is done via the AoR. How this
is done is completely within the scope of SPEER.

Note: this is the only future proof way, because a user may
use the AoR in the first place and then the routing MUST work
anyway. So any additional routing information in ENUM would
be duplicated and therefore error-prone.

I propose in addition to use in this case a SIP in the format
sip:4319793321@provider.net, to clearly indicate that this
has no relationship to an E.164 number.

Scenario B:

This is the scenario proposed in most current implementations
and also in the RFI on ENUM popping up everywhere. The reason
is that most scenarios currently concentrate solely on
the peering with E.164 numbers and completely forget the
peering with SIP URIs

The ENUM entry is giving you the next hop: This is in case
of the walled garden originating network either the server
hosting the end-user or the egress border element (e.g. IBCF,
THIG, or whatchamacallit). This element is again querying another
kind of ENUM, getting back the ingress border element of the
destination network (or even of a "transit" L5 network), and so
on. The ingress border element is the again calling its private ENUM
to finally find the hosting server.

Note: I have a sub-question here: Some implementations are
even proposing here to skip the SRV query and directly pointing
to the SIP server(s) in ENUM. Does this make sense?

If this scenario is used, I propose to use only SIP URIs
in the format
sip:+4319793321@provider.net;user=3Dphone or better
SIP:+4319793321@sbc.prov.net; user=3Dphone

to clearly indicate that this is still basically a=20
tel: URI combined with a routing info and that it may=20
be used in another ENUM query.

My questions to the crowd are the following:

1. is this proposed use of SIP URIs within the context
of ENUM ok?

2. What should be the preferred scenario for
VoIP peering?=20
Is some kind of combination between the scenarios
feasible?=20
And what are the arguments pro and con?

I consider the outcome of this discussion as
substantial input to the deliverables of SPEER,
but some first guidance is urgently required now,
because many entities are making basic decisions
in this direction NOW.

Please also excuse and correct incorrect use of terminology.

Regards
Richard Stastny









_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 10:21:38 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjedN-0006IS-U2; Tue, 06 Dec 2005 10:21:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjedN-0006HO-2X; Tue, 06 Dec 2005 10:21:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12188;
	Tue, 6 Dec 2005 10:20:45 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejeys-0005oJ-5P; Tue, 06 Dec 2005 10:43:51 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 07:21:27 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB6FLHMi027262;
	Tue, 6 Dec 2005 07:21:24 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 10:21:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 10:21:19 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0353@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+Q
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <voipeer@lists.uoregon.edu>
X-OriginalArrivalTime: 06 Dec 2005 15:21:20.0835 (UTC)
	FILETIME=[B61DC130:01C5FA78]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Richard et al,

Before going down this path too far, can we ask where the results of the
ENUM queries will go in the SIP message to control routing?
Hypothetically, the egress and ingress gateways could be identified in
Route headers rather than in the Request-URI.  An external ENUM dip and
an internal ENUM dip might lead to something along the lines of:

INVITE tel:+17775551111 SIP/2.0
...
Route: <sip:egress11.provider3.com;lr>
Route: <sip:ingress39.provider17.com;lr>
...

I am also suggesting that the ENUM result be an AoR, since one might
want some reliability in choosing which server in the gateway cluster to
go to based on further DNS queries, load balancing, etc.

Mike

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Stastny Richard
> Sent: Tuesday, December 06, 2005 4:54 AM
> To: voipeer@lists.uoregon.edu
> Cc: enum@ietf.org; sip@ietf.org
> Subject: [Sip] SIP AoR, tel and ENUM
>=20
> Folks,
>=20
> This post is primarily to SPEER, but since it also concerns=20
> ENUM and SIP I cross-post it.
>=20
> I need (urgently) some guidance on the question what SIP URIs=20
> to use in Infrastructure ENUM.
>=20
> User ENUM as defined in RFC 3761 provides a mapping from=20
> E.164 numbers to SIP URIs for primarily for end-users. So=20
> what you get back is the AoR pointing to the destination SIP server.
>=20
> If you get something back on the ENUM query such as=20
> sip:Richard@stastny.com, this is definetely an AoR. Because=20
> of privacy reasons, more and more people start using SIP URI=20
> such as sip:4319793321@provider.net or (an AoR)=20
> sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or=20
> even sip:+4319793321@provider.net
>=20
> IMHO the last one should not be used, and some guidance is=20
> also needed here. but it only concerns the destination server=20
> and if the destination servers can deal with it, fine.
>=20
> Now with Infrastructure ENUM (and especially in combination=20
> with private ENUMs) the situation is different.
>=20
> The purpose of Infrastructure ENUM is according to the=20
> re-chartered ENUM WG "to discover points of interconnection=20
> necessary to terminate communications sessions identified by=20
> a E164 number, in addition to identifying end point protocols=20
> and services."
>=20
> This translates to: Infrastructure ENUM does not necessarily=20
> contain end-point information (AoR), but routing information.=20
> Routing, in my definition here, is basically to provide you=20
> with the information what the next hop is.
>=20
> A very common scenario is the following one: a walled garden=20
> network is using private ENUM to detect the border element=20
> for a given number, Some border element may lead to another=20
> private (extranet), using a federated ENUM for this number,=20
> another may be connected to the Internet using public=20
> Infrastructure ENUM for another number.
> Public Infrastructure ENUM is giving back the ingress border=20
> element, which in turn uses private ENUM again to find the=20
> SIP server hosting the user with this number.
>=20
> In addition, again for privacy reasons, in most cases the=20
> above mentioned SIP URIs containing E.164 numbers are used.
>=20
> This raises two issues, an architectural one and a BCP one:
>=20
> To principally different scenarios are possible
>=20
> Scenario A
>=20
> ENUM is providing ONLY the mapping from the E.164 number to=20
> an AoR. (=3D name to address mapping) The above described=20
> routing between the networks to find the destination network=20
> is done via the AoR. How this is done is completely within=20
> the scope of SPEER.
>=20
> Note: this is the only future proof way, because a user may=20
> use the AoR in the first place and then the routing MUST work=20
> anyway. So any additional routing information in ENUM would=20
> be duplicated and therefore error-prone.
>=20
> I propose in addition to use in this case a SIP in the format=20
> sip:4319793321@provider.net, to clearly indicate that this=20
> has no relationship to an E.164 number.
>=20
> Scenario B:
>=20
> This is the scenario proposed in most current implementations=20
> and also in the RFI on ENUM popping up everywhere. The reason=20
> is that most scenarios currently concentrate solely on the=20
> peering with E.164 numbers and completely forget the peering=20
> with SIP URIs
>=20
> The ENUM entry is giving you the next hop: This is in case of=20
> the walled garden originating network either the server=20
> hosting the end-user or the egress border element (e.g. IBCF,=20
> THIG, or whatchamacallit). This element is again querying=20
> another kind of ENUM, getting back the ingress border element=20
> of the destination network (or even of a "transit" L5=20
> network), and so on. The ingress border element is the again=20
> calling its private ENUM to finally find the hosting server.
>=20
> Note: I have a sub-question here: Some implementations are=20
> even proposing here to skip the SRV query and directly=20
> pointing to the SIP server(s) in ENUM. Does this make sense?
>=20
> If this scenario is used, I propose to use only SIP URIs in=20
> the format sip:+4319793321@provider.net;user=3Dphone or better=20
> SIP:+4319793321@sbc.prov.net; user=3Dphone
>=20
> to clearly indicate that this is still basically a
> tel: URI combined with a routing info and that it may be used=20
> in another ENUM query.
>=20
> My questions to the crowd are the following:
>=20
> 1. is this proposed use of SIP URIs within the context of ENUM ok?
>=20
> 2. What should be the preferred scenario for VoIP peering?=20
> Is some kind of combination between the scenarios feasible?=20
> And what are the arguments pro and con?
>=20
> I consider the outcome of this discussion as substantial=20
> input to the deliverables of SPEER, but some first guidance=20
> is urgently required now, because many entities are making=20
> basic decisions in this direction NOW.
>=20
> Please also excuse and correct incorrect use of terminology.
>=20
> Regards
> Richard Stastny
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 10:44:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejez3-0004fS-FA; Tue, 06 Dec 2005 10:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejez2-0004eJ-5I; Tue, 06 Dec 2005 10:44:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14876;
	Tue, 6 Dec 2005 10:43:07 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EjfKX-0006ag-Bn; Tue, 06 Dec 2005 11:06:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 16:47:29 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+QAAEpMrU=
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>,
	<voipeer@lists.uoregon.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Mike wrote:

>Before going down this path too far, can we ask where the results of =
the
>ENUM queries will go in the SIP message to control routing?
>Hypothetically, the egress and ingress gateways could be identified in
>Route headers rather than in the Request-URI.  An external ENUM dip and
>an internal ENUM dip might lead to something along the lines of:
=20
Correct,
=20
Jonathan proposed this some time ago, but this thread somewhere stranded
=20
So basically an interneal ENUM entry of

sip:+1777555111@egress.provider3.com;user=3Dphone
=20
would result in

INVITE tel:+17775551111 SIP/2.0
...
Route: <sip:egress11.provider3.com;lr>
=20
an the external ENUM entry would be
sip:+1777555111@provider17.com
=20
result in
Route: <sip:ingress39.provider17.com;lr>
=20
This is basically what I am after
...

>I am also suggesting that the ENUM result be an AoR, since one might
>want some reliability in choosing which server in the gateway cluster =
to
>go to based on further DNS queries, load balancing, etc.
=20
Now this is in contradiction to the above
=20
Richard

>Mike

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
> Behalf Of Stastny Richard
> Sent: Tuesday, December 06, 2005 4:54 AM
> To: voipeer@lists.uoregon.edu
> Cc: enum@ietf.org; sip@ietf.org
> Subject: [Sip] SIP AoR, tel and ENUM
>
> Folks,
>
> This post is primarily to SPEER, but since it also concerns
> ENUM and SIP I cross-post it.
>
> I need (urgently) some guidance on the question what SIP URIs
> to use in Infrastructure ENUM.
>
> User ENUM as defined in RFC 3761 provides a mapping from
> E.164 numbers to SIP URIs for primarily for end-users. So
> what you get back is the AoR pointing to the destination SIP server.
>
> If you get something back on the ENUM query such as
> sip:Richard@stastny.com, this is definetely an AoR. Because
> of privacy reasons, more and more people start using SIP URI
> such as sip:4319793321@provider.net or (an AoR)
> sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or
> even sip:+4319793321@provider.net
>
> IMHO the last one should not be used, and some guidance is
> also needed here. but it only concerns the destination server
> and if the destination servers can deal with it, fine.
>
> Now with Infrastructure ENUM (and especially in combination
> with private ENUMs) the situation is different.
>
> The purpose of Infrastructure ENUM is according to the
> re-chartered ENUM WG "to discover points of interconnection
> necessary to terminate communications sessions identified by
> a E164 number, in addition to identifying end point protocols
> and services."
>
> This translates to: Infrastructure ENUM does not necessarily
> contain end-point information (AoR), but routing information.
> Routing, in my definition here, is basically to provide you
> with the information what the next hop is.
>
> A very common scenario is the following one: a walled garden
> network is using private ENUM to detect the border element
> for a given number, Some border element may lead to another
> private (extranet), using a federated ENUM for this number,
> another may be connected to the Internet using public
> Infrastructure ENUM for another number.
> Public Infrastructure ENUM is giving back the ingress border
> element, which in turn uses private ENUM again to find the
> SIP server hosting the user with this number.
>
> In addition, again for privacy reasons, in most cases the
> above mentioned SIP URIs containing E.164 numbers are used.
>
> This raises two issues, an architectural one and a BCP one:
>
> To principally different scenarios are possible
>
> Scenario A
>
> ENUM is providing ONLY the mapping from the E.164 number to
> an AoR. (=3D name to address mapping) The above described
> routing between the networks to find the destination network
> is done via the AoR. How this is done is completely within
> the scope of SPEER.
>
> Note: this is the only future proof way, because a user may
> use the AoR in the first place and then the routing MUST work
> anyway. So any additional routing information in ENUM would
> be duplicated and therefore error-prone.
>
> I propose in addition to use in this case a SIP in the format
> sip:4319793321@provider.net, to clearly indicate that this
> has no relationship to an E.164 number.
>
> Scenario B:
>
> This is the scenario proposed in most current implementations
> and also in the RFI on ENUM popping up everywhere. The reason
> is that most scenarios currently concentrate solely on the
> peering with E.164 numbers and completely forget the peering
> with SIP URIs
>
> The ENUM entry is giving you the next hop: This is in case of
> the walled garden originating network either the server
> hosting the end-user or the egress border element (e.g. IBCF,
> THIG, or whatchamacallit). This element is again querying
> another kind of ENUM, getting back the ingress border element
> of the destination network (or even of a "transit" L5
> network), and so on. The ingress border element is the again
> calling its private ENUM to finally find the hosting server.
>
> Note: I have a sub-question here: Some implementations are
> even proposing here to skip the SRV query and directly
> pointing to the SIP server(s) in ENUM. Does this make sense?
>
> If this scenario is used, I propose to use only SIP URIs in
> the format sip:+4319793321@provider.net;user=3Dphone or better
> SIP:+4319793321@sbc.prov.net; user=3Dphone
>
> to clearly indicate that this is still basically a
> tel: URI combined with a routing info and that it may be used
> in another ENUM query.
>
> My questions to the crowd are the following:
>
> 1. is this proposed use of SIP URIs within the context of ENUM ok?
>
> 2. What should be the preferred scenario for VoIP peering?
> Is some kind of combination between the scenarios feasible?
> And what are the arguments pro and con?
>
> I consider the outcome of this discussion as substantial
> input to the deliverables of SPEER, but some first guidance
> is urgently required now, because many entities are making
> basic decisions in this direction NOW.
>
> Please also excuse and correct incorrect use of terminology.
>
> Regards
> Richard Stastny
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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



From sip-bounces@ietf.org Tue Dec 06 11:49:24 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejg0K-0000dw-4R; Tue, 06 Dec 2005 11:49:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejg0H-0000c7-RO; Tue, 06 Dec 2005 11:49:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22487;
	Tue, 6 Dec 2005 11:48:31 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjgLo-0000WW-0u; Tue, 06 Dec 2005 12:11:36 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1Ejfzm-0003N0-00; Tue, 06 Dec 2005 17:48:50 +0100
Message-ID: <4395C0DA.4040206@pernau.at>
Date: Tue, 06 Dec 2005 17:48:26 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] SIP AoR, tel and ENUM
References: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 325b777e1a3a618c889460b612a65510
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard wrote:
> Mike wrote:
> 
> 
>>Before going down this path too far, can we ask where the results of the
>>ENUM queries will go in the SIP message to control routing?
>>Hypothetically, the egress and ingress gateways could be identified in
>>Route headers rather than in the Request-URI.  An external ENUM dip and
>>an internal ENUM dip might lead to something along the lines of:
> 
>  
> Correct,
>  
> Jonathan proposed this some time ago, but this thread somewhere stranded
>  
> So basically an interneal ENUM entry of
> 
> sip:+1777555111@egress.provider3.com;user=phone
>  
> would result in
> 
> INVITE tel:+17775551111 SIP/2.0
> ...
> Route: <sip:egress11.provider3.com;lr>
>  
> an the external ENUM entry would be
> sip:+1777555111@provider17.com
>  
> result in
> Route: <sip:ingress39.provider17.com;lr>
>  
> This is basically what I am after
> ...
> 

Hi folks.

What is the benefit of splitting the ENUM result (the SIP URI) into a 
Route header and into a request URI?

IMO there should be no semantic for the internal routing (the routing 
from the main proxy to the egress proxy). This should be out of scope of 
all WGs. Also the internal routing of the ingress provider should be out 
of scope. The ingress provider should have SIP URI which can be used to 
address its customers.

If this URI is sip:431505641636@in.mydomain.com or 
foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com is the 
ingress provider's choice. Maybe the ingress provider also allows all of 
the previous SIP URIs to reach a certain user. The incoming provider 
just has to make sure that these SIP URIs map to the corresponding user 
(to the user's AoR). If this user also has an E.164 number which is in 
I-ENUM, then it's again the ingress provider's choice which URI to put 
into the NAPTR.

IMO there should not not be any semantics how to create a request URI 
and a pre-loaded route set of the SIP URI received from ENUM. The egress 
proxy sends the request to the ingress proxy in the format choosen by 
the ingress provider (e.g. publish via ENUM or an business cards).

We should not complicate things. I do not see any problems with this 
simple approach. If there are some problems, please correct me.

regards
klaus



> 
>>I am also suggesting that the ENUM result be an AoR, since one might
>>want some reliability in choosing which server in the gateway cluster to
>>go to based on further DNS queries, load balancing, etc.
> 
>  
> Now this is in contradiction to the above
>  
> Richard
> 
> 
>>Mike
> 
> 
>>-----Original Message-----
>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
>>Behalf Of Stastny Richard
>>Sent: Tuesday, December 06, 2005 4:54 AM
>>To: voipeer@lists.uoregon.edu
>>Cc: enum@ietf.org; sip@ietf.org
>>Subject: [Sip] SIP AoR, tel and ENUM
>>
>>Folks,
>>
>>This post is primarily to SPEER, but since it also concerns
>>ENUM and SIP I cross-post it.
>>
>>I need (urgently) some guidance on the question what SIP URIs
>>to use in Infrastructure ENUM.
>>
>>User ENUM as defined in RFC 3761 provides a mapping from
>>E.164 numbers to SIP URIs for primarily for end-users. So
>>what you get back is the AoR pointing to the destination SIP server.
>>
>>If you get something back on the ENUM query such as
>>sip:Richard@stastny.com, this is definetely an AoR. Because
>>of privacy reasons, more and more people start using SIP URI
>>such as sip:4319793321@provider.net or (an AoR)
>>sip:+4319793321@provider.net;user=phone (IMHO not an AoR) or
>>even sip:+4319793321@provider.net
>>
>>IMHO the last one should not be used, and some guidance is
>>also needed here. but it only concerns the destination server
>>and if the destination servers can deal with it, fine.
>>
>>Now with Infrastructure ENUM (and especially in combination
>>with private ENUMs) the situation is different.
>>
>>The purpose of Infrastructure ENUM is according to the
>>re-chartered ENUM WG "to discover points of interconnection
>>necessary to terminate communications sessions identified by
>>a E164 number, in addition to identifying end point protocols
>>and services."
>>
>>This translates to: Infrastructure ENUM does not necessarily
>>contain end-point information (AoR), but routing information.
>>Routing, in my definition here, is basically to provide you
>>with the information what the next hop is.
>>
>>A very common scenario is the following one: a walled garden
>>network is using private ENUM to detect the border element
>>for a given number, Some border element may lead to another
>>private (extranet), using a federated ENUM for this number,
>>another may be connected to the Internet using public
>>Infrastructure ENUM for another number.
>>Public Infrastructure ENUM is giving back the ingress border
>>element, which in turn uses private ENUM again to find the
>>SIP server hosting the user with this number.
>>
>>In addition, again for privacy reasons, in most cases the
>>above mentioned SIP URIs containing E.164 numbers are used.
>>
>>This raises two issues, an architectural one and a BCP one:
>>
>>To principally different scenarios are possible
>>
>>Scenario A
>>
>>ENUM is providing ONLY the mapping from the E.164 number to
>>an AoR. (= name to address mapping) The above described
>>routing between the networks to find the destination network
>>is done via the AoR. How this is done is completely within
>>the scope of SPEER.
>>
>>Note: this is the only future proof way, because a user may
>>use the AoR in the first place and then the routing MUST work
>>anyway. So any additional routing information in ENUM would
>>be duplicated and therefore error-prone.
>>
>>I propose in addition to use in this case a SIP in the format
>>sip:4319793321@provider.net, to clearly indicate that this
>>has no relationship to an E.164 number.
>>
>>Scenario B:
>>
>>This is the scenario proposed in most current implementations
>>and also in the RFI on ENUM popping up everywhere. The reason
>>is that most scenarios currently concentrate solely on the
>>peering with E.164 numbers and completely forget the peering
>>with SIP URIs
>>
>>The ENUM entry is giving you the next hop: This is in case of
>>the walled garden originating network either the server
>>hosting the end-user or the egress border element (e.g. IBCF,
>>THIG, or whatchamacallit). This element is again querying
>>another kind of ENUM, getting back the ingress border element
>>of the destination network (or even of a "transit" L5
>>network), and so on. The ingress border element is the again
>>calling its private ENUM to finally find the hosting server.
>>
>>Note: I have a sub-question here: Some implementations are
>>even proposing here to skip the SRV query and directly
>>pointing to the SIP server(s) in ENUM. Does this make sense?
>>
>>If this scenario is used, I propose to use only SIP URIs in
>>the format sip:+4319793321@provider.net;user=phone or better
>>SIP:+4319793321@sbc.prov.net; user=phone
>>
>>to clearly indicate that this is still basically a
>>tel: URI combined with a routing info and that it may be used
>>in another ENUM query.
>>
>>My questions to the crowd are the following:
>>
>>1. is this proposed use of SIP URIs within the context of ENUM ok?
>>
>>2. What should be the preferred scenario for VoIP peering?
>>Is some kind of combination between the scenarios feasible?
>>And what are the arguments pro and con?
>>
>>I consider the outcome of this discussion as substantial
>>input to the deliverables of SPEER, but some first guidance
>>is urgently required now, because many entities are making
>>basic decisions in this direction NOW.
>>
>>Please also excuse and correct incorrect use of terminology.
>>
>>Regards
>>Richard Stastny
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>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
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 13:11:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjhHV-0007Ph-MJ; Tue, 06 Dec 2005 13:11:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjhHO-0007FZ-1Z; Tue, 06 Dec 2005 13:11:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02594;
	Tue, 6 Dec 2005 13:10:15 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejhcv-0003Y2-ME; Tue, 06 Dec 2005 13:33:22 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 10:10:57 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,222,1131350400"; 
	d="scan'208"; a="16694417:sNHT26910960"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB6IAAV5002126; 
	Tue, 6 Dec 2005 13:10:53 -0500 (EST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 13:10:44 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 13:10:43 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6hPf2sLmw0BxGQvS5LPQgRR8+DwAClYDg
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>,
	"Stastny Richard" <Richard.Stastny@oefeg.at>
X-OriginalArrivalTime: 06 Dec 2005 18:10:44.0665 (UTC)
	FILETIME=[603B2290:01C5FA90]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Klaus,

It has to do with the difference between re-targeting and routing.  Is
the point of interconnect the real target of the request or just a
waypoint in the route to get to the target?  In the User ENUM case, it
seems as though the addresses are all about the target users and their
devices.  But, here it seemed a bit different.  It is a route through an
intermediate point.  It seems like the semantic and syntactical element
would be more coherent and no more complicated.  Thus, I posed the
question.

Mike


> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20
> Sent: Tuesday, December 06, 2005 11:48 AM
> To: Stastny Richard
> Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20
> enum@ietf.org; sip@ietf.org
> Subject: Re: [Sip] SIP AoR, tel and ENUM
>=20
> Stastny Richard wrote:
> > Mike wrote:
> >=20
> >=20
> >>Before going down this path too far, can we ask where the=20
> results of=20
> >>the ENUM queries will go in the SIP message to control routing?
> >>Hypothetically, the egress and ingress gateways could be=20
> identified in=20
> >>Route headers rather than in the Request-URI.  An external ENUM dip=20
> >>and an internal ENUM dip might lead to something along the lines of:
> >=20
> > =20
> > Correct,
> > =20
> > Jonathan proposed this some time ago, but this thread somewhere=20
> > stranded
> > =20
> > So basically an interneal ENUM entry of
> >=20
> > sip:+1777555111@egress.provider3.com;user=3Dphone
> > =20
> > would result in
> >=20
> > INVITE tel:+17775551111 SIP/2.0
> > ...
> > Route: <sip:egress11.provider3.com;lr>
> > =20
> > an the external ENUM entry would be
> > sip:+1777555111@provider17.com
> > =20
> > result in
> > Route: <sip:ingress39.provider17.com;lr>
> > =20
> > This is basically what I am after
> > ...
> >=20
>=20
> Hi folks.
>=20
> What is the benefit of splitting the ENUM result (the SIP=20
> URI) into a Route header and into a request URI?
>=20
> IMO there should be no semantic for the internal routing (the=20
> routing from the main proxy to the egress proxy). This should=20
> be out of scope of all WGs. Also the internal routing of the=20
> ingress provider should be out of scope. The ingress provider=20
> should have SIP URI which can be used to address its customers.
>=20
> If this URI is sip:431505641636@in.mydomain.com or=20
> foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com=20
> is the ingress provider's choice. Maybe the ingress provider=20
> also allows all of the previous SIP URIs to reach a certain=20
> user. The incoming provider just has to make sure that these=20
> SIP URIs map to the corresponding user (to the user's AoR).=20
> If this user also has an E.164 number which is in I-ENUM,=20
> then it's again the ingress provider's choice which URI to=20
> put into the NAPTR.
>=20
> IMO there should not not be any semantics how to create a=20
> request URI and a pre-loaded route set of the SIP URI=20
> received from ENUM. The egress proxy sends the request to the=20
> ingress proxy in the format choosen by the ingress provider=20
> (e.g. publish via ENUM or an business cards).
>=20
> We should not complicate things. I do not see any problems=20
> with this simple approach. If there are some problems, please=20
> correct me.
>=20
> regards
> klaus
>=20
>=20
>=20
> >=20
> >>I am also suggesting that the ENUM result be an AoR, since=20
> one might=20
> >>want some reliability in choosing which server in the=20
> gateway cluster=20
> >>to go to based on further DNS queries, load balancing, etc.
> >=20
> > =20
> > Now this is in contradiction to the above
> > =20
> > Richard
> >=20
> >=20
> >>Mike
> >=20
> >=20
> >>-----Original Message-----
> >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of=20
> >>Stastny Richard
> >>Sent: Tuesday, December 06, 2005 4:54 AM
> >>To: voipeer@lists.uoregon.edu
> >>Cc: enum@ietf.org; sip@ietf.org
> >>Subject: [Sip] SIP AoR, tel and ENUM
> >>
> >>Folks,
> >>
> >>This post is primarily to SPEER, but since it also concerns=20
> ENUM and=20
> >>SIP I cross-post it.
> >>
> >>I need (urgently) some guidance on the question what SIP=20
> URIs to use=20
> >>in Infrastructure ENUM.
> >>
> >>User ENUM as defined in RFC 3761 provides a mapping from
> >>E.164 numbers to SIP URIs for primarily for end-users. So=20
> what you get=20
> >>back is the AoR pointing to the destination SIP server.
> >>
> >>If you get something back on the ENUM query such as=20
> >>sip:Richard@stastny.com, this is definetely an AoR. Because=20
> of privacy=20
> >>reasons, more and more people start using SIP URI such as=20
> >>sip:4319793321@provider.net or (an AoR)=20
> >>sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even=20
> >>sip:+4319793321@provider.net
> >>
> >>IMHO the last one should not be used, and some guidance is=20
> also needed=20
> >>here. but it only concerns the destination server and if the=20
> >>destination servers can deal with it, fine.
> >>
> >>Now with Infrastructure ENUM (and especially in combination with=20
> >>private ENUMs) the situation is different.
> >>
> >>The purpose of Infrastructure ENUM is according to the re-chartered=20
> >>ENUM WG "to discover points of interconnection necessary to=20
> terminate=20
> >>communications sessions identified by a E164 number, in addition to=20
> >>identifying end point protocols and services."
> >>
> >>This translates to: Infrastructure ENUM does not=20
> necessarily contain=20
> >>end-point information (AoR), but routing information.
> >>Routing, in my definition here, is basically to provide you=20
> with the=20
> >>information what the next hop is.
> >>
> >>A very common scenario is the following one: a walled=20
> garden network=20
> >>is using private ENUM to detect the border element for a=20
> given number,=20
> >>Some border element may lead to another private (extranet), using a=20
> >>federated ENUM for this number, another may be connected to the=20
> >>Internet using public Infrastructure ENUM for another number.
> >>Public Infrastructure ENUM is giving back the ingress=20
> border element,=20
> >>which in turn uses private ENUM again to find the SIP=20
> server hosting=20
> >>the user with this number.
> >>
> >>In addition, again for privacy reasons, in most cases the above=20
> >>mentioned SIP URIs containing E.164 numbers are used.
> >>
> >>This raises two issues, an architectural one and a BCP one:
> >>
> >>To principally different scenarios are possible
> >>
> >>Scenario A
> >>
> >>ENUM is providing ONLY the mapping from the E.164 number to=20
> an AoR. (=3D=20
> >>name to address mapping) The above described routing between the=20
> >>networks to find the destination network is done via the=20
> AoR. How this=20
> >>is done is completely within the scope of SPEER.
> >>
> >>Note: this is the only future proof way, because a user may use the=20
> >>AoR in the first place and then the routing MUST work=20
> anyway. So any=20
> >>additional routing information in ENUM would be duplicated and=20
> >>therefore error-prone.
> >>
> >>I propose in addition to use in this case a SIP in the format=20
> >>sip:4319793321@provider.net, to clearly indicate that this has no=20
> >>relationship to an E.164 number.
> >>
> >>Scenario B:
> >>
> >>This is the scenario proposed in most current=20
> implementations and also=20
> >>in the RFI on ENUM popping up everywhere. The reason is that most=20
> >>scenarios currently concentrate solely on the peering with E.164=20
> >>numbers and completely forget the peering with SIP URIs
> >>
> >>The ENUM entry is giving you the next hop: This is in case of the=20
> >>walled garden originating network either the server hosting the=20
> >>end-user or the egress border element (e.g. IBCF, THIG, or=20
> >>whatchamacallit). This element is again querying another=20
> kind of ENUM,=20
> >>getting back the ingress border element of the destination=20
> network (or=20
> >>even of a "transit" L5 network), and so on. The ingress=20
> border element=20
> >>is the again calling its private ENUM to finally find the hosting=20
> >>server.
> >>
> >>Note: I have a sub-question here: Some implementations are even=20
> >>proposing here to skip the SRV query and directly pointing=20
> to the SIP=20
> >>server(s) in ENUM. Does this make sense?
> >>
> >>If this scenario is used, I propose to use only SIP URIs in=20
> the format=20
> >>sip:+4319793321@provider.net;user=3Dphone or better=20
> >>SIP:+4319793321@sbc.prov.net; user=3Dphone
> >>
> >>to clearly indicate that this is still basically a
> >>tel: URI combined with a routing info and that it may be used in=20
> >>another ENUM query.
> >>
> >>My questions to the crowd are the following:
> >>
> >>1. is this proposed use of SIP URIs within the context of ENUM ok?
> >>
> >>2. What should be the preferred scenario for VoIP peering?
> >>Is some kind of combination between the scenarios feasible?
> >>And what are the arguments pro and con?
> >>
> >>I consider the outcome of this discussion as substantial=20
> input to the=20
> >>deliverables of SPEER, but some first guidance is urgently required=20
> >>now, because many entities are making basic decisions in this=20
> >>direction NOW.
> >>
> >>Please also excuse and correct incorrect use of terminology.
> >>
> >>Regards
> >>Richard Stastny
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol Use=20
> >>sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>sipping@ietf.org for new developments on the application of sip
> >>
> >=20
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
> >=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 13:24:25 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjhUG-0004xI-UT; Tue, 06 Dec 2005 13:24:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjhUF-0004v1-GS; Tue, 06 Dec 2005 13:24:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04578;
	Tue, 6 Dec 2005 13:23:31 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejhpl-00047h-CM; Tue, 06 Dec 2005 13:46:38 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2005 13:24:12 -0500
X-IronPort-AV: i="3.99,222,1131339600"; 
	d="scan'208"; a="77229485:sNHT35272500"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB6IO64Z003451; 
	Tue, 6 Dec 2005 13:24:10 -0500 (EST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 13:24:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 13:24:08 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA043B@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6SwJitdWYiDMnQBa1ILCKsfjKoAAK+G+QAAEpMrUABUXZ0A==
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <voipeer@lists.uoregon.edu>
X-OriginalArrivalTime: 06 Dec 2005 18:24:09.0561 (UTC)
	FILETIME=[3FFC8490:01C5FA92]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hmmm...  should I have said?:

Route: <sip:egress-farm-11.provider3.com;lr>

Mike


> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20
> Sent: Tuesday, December 06, 2005 10:47 AM
> To: Michael Hammer (mhammer); voipeer@lists.uoregon.edu
> Cc: enum@ietf.org; sip@ietf.org
> Subject: Re: [Sip] SIP AoR, tel and ENUM
>=20
> Mike wrote:
>=20
> >Before going down this path too far, can we ask where the results of=20
> >the ENUM queries will go in the SIP message to control routing?
> >Hypothetically, the egress and ingress gateways could be=20
> identified in=20
> >Route headers rather than in the Request-URI.  An external=20
> ENUM dip and=20
> >an internal ENUM dip might lead to something along the lines of:
> =20
> Correct,
> =20
> Jonathan proposed this some time ago, but this thread=20
> somewhere stranded
> =20
> So basically an interneal ENUM entry of
>=20
> sip:+1777555111@egress.provider3.com;user=3Dphone
> =20
> would result in
>=20
> INVITE tel:+17775551111 SIP/2.0
> ...
> Route: <sip:egress11.provider3.com;lr>
> =20
> an the external ENUM entry would be
> sip:+1777555111@provider17.com
> =20
> result in
> Route: <sip:ingress39.provider17.com;lr>
> =20
> This is basically what I am after
> ...
>=20
> >I am also suggesting that the ENUM result be an AoR, since one might=20
> >want some reliability in choosing which server in the=20
> gateway cluster=20
> >to go to based on further DNS queries, load balancing, etc.
> =20
> Now this is in contradiction to the above
> =20
> Richard
>=20
> >Mike
>=20
> > -----Original Message-----
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of=20
> > Stastny Richard
> > Sent: Tuesday, December 06, 2005 4:54 AM
> > To: voipeer@lists.uoregon.edu
> > Cc: enum@ietf.org; sip@ietf.org
> > Subject: [Sip] SIP AoR, tel and ENUM
> >
> > Folks,
> >
> > This post is primarily to SPEER, but since it also concerns=20
> ENUM and=20
> > SIP I cross-post it.
> >
> > I need (urgently) some guidance on the question what SIP=20
> URIs to use=20
> > in Infrastructure ENUM.
> >
> > User ENUM as defined in RFC 3761 provides a mapping from
> > E.164 numbers to SIP URIs for primarily for end-users. So=20
> what you get=20
> > back is the AoR pointing to the destination SIP server.
> >
> > If you get something back on the ENUM query such as=20
> > sip:Richard@stastny.com, this is definetely an AoR. Because=20
> of privacy=20
> > reasons, more and more people start using SIP URI such as=20
> > sip:4319793321@provider.net or (an AoR)=20
> > sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or even=20
> > sip:+4319793321@provider.net
> >
> > IMHO the last one should not be used, and some guidance is=20
> also needed=20
> > here. but it only concerns the destination server and if the=20
> > destination servers can deal with it, fine.
> >
> > Now with Infrastructure ENUM (and especially in combination with=20
> > private ENUMs) the situation is different.
> >
> > The purpose of Infrastructure ENUM is according to the re-chartered=20
> > ENUM WG "to discover points of interconnection necessary to=20
> terminate=20
> > communications sessions identified by a E164 number, in addition to=20
> > identifying end point protocols and services."
> >
> > This translates to: Infrastructure ENUM does not=20
> necessarily contain=20
> > end-point information (AoR), but routing information.
> > Routing, in my definition here, is basically to provide you=20
> with the=20
> > information what the next hop is.
> >
> > A very common scenario is the following one: a walled=20
> garden network=20
> > is using private ENUM to detect the border element for a=20
> given number,=20
> > Some border element may lead to another private (extranet), using a=20
> > federated ENUM for this number, another may be connected to the=20
> > Internet using public Infrastructure ENUM for another number.
> > Public Infrastructure ENUM is giving back the ingress=20
> border element,=20
> > which in turn uses private ENUM again to find the SIP=20
> server hosting=20
> > the user with this number.
> >
> > In addition, again for privacy reasons, in most cases the above=20
> > mentioned SIP URIs containing E.164 numbers are used.
> >
> > This raises two issues, an architectural one and a BCP one:
> >
> > To principally different scenarios are possible
> >
> > Scenario A
> >
> > ENUM is providing ONLY the mapping from the E.164 number to=20
> an AoR. (=3D=20
> > name to address mapping) The above described routing between the=20
> > networks to find the destination network is done via the=20
> AoR. How this=20
> > is done is completely within the scope of SPEER.
> >
> > Note: this is the only future proof way, because a user may use the=20
> > AoR in the first place and then the routing MUST work=20
> anyway. So any=20
> > additional routing information in ENUM would be duplicated and=20
> > therefore error-prone.
> >
> > I propose in addition to use in this case a SIP in the format=20
> > sip:4319793321@provider.net, to clearly indicate that this has no=20
> > relationship to an E.164 number.
> >
> > Scenario B:
> >
> > This is the scenario proposed in most current=20
> implementations and also=20
> > in the RFI on ENUM popping up everywhere. The reason is that most=20
> > scenarios currently concentrate solely on the peering with E.164=20
> > numbers and completely forget the peering with SIP URIs
> >
> > The ENUM entry is giving you the next hop: This is in case of the=20
> > walled garden originating network either the server hosting the=20
> > end-user or the egress border element (e.g. IBCF, THIG, or=20
> > whatchamacallit). This element is again querying another=20
> kind of ENUM,=20
> > getting back the ingress border element of the destination=20
> network (or=20
> > even of a "transit" L5 network), and so on. The ingress=20
> border element=20
> > is the again calling its private ENUM to finally find the hosting=20
> > server.
> >
> > Note: I have a sub-question here: Some implementations are even=20
> > proposing here to skip the SRV query and directly pointing=20
> to the SIP=20
> > server(s) in ENUM. Does this make sense?
> >
> > If this scenario is used, I propose to use only SIP URIs in=20
> the format=20
> > sip:+4319793321@provider.net;user=3Dphone or better=20
> > SIP:+4319793321@sbc.prov.net; user=3Dphone
> >
> > to clearly indicate that this is still basically a
> > tel: URI combined with a routing info and that it may be used in=20
> > another ENUM query.
> >
> > My questions to the crowd are the following:
> >
> > 1. is this proposed use of SIP URIs within the context of ENUM ok?
> >
> > 2. What should be the preferred scenario for VoIP peering?
> > Is some kind of combination between the scenarios feasible?
> > And what are the arguments pro and con?
> >
> > I consider the outcome of this discussion as substantial=20
> input to the=20
> > deliverables of SPEER, but some first guidance is urgently required=20
> > now, because many entities are making basic decisions in this=20
> > direction NOW.
> >
> > Please also excuse and correct incorrect use of terminology.
> >
> > Regards
> > Richard Stastny
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >
>=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 16:17:05 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejk4k-0006X7-42; Tue, 06 Dec 2005 16:10:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejk4i-0006W3-NB
	for sip@megatron.ietf.org; Tue, 06 Dec 2005 16:10:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22761
	for <sip@ietf.org>; Tue, 6 Dec 2005 16:09:20 -0500 (EST)
From: Shimshon.Lapushner@ecitele.com
Received: from ilsmtp01.ecitele.com ([147.234.1.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjkQG-0001be-2A
	for sip@ietf.org; Tue, 06 Dec 2005 16:32:30 -0500
To: sip@ietf.org
Message-ID: <OF7883AE3D.DFDEA86F-ONC22570CF.00744828-C22570CF.00744828@ecitele.com>
Date: Tue, 6 Dec 2005 23:10:06 +0200
X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 |
	December 22, 2004) at 12/06/2005 23:16:52
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Subject: [Sip] Shimshon Lapushner/ECI Telecom is out of the office.
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I will be out of the office starting  06/12/2005 and will not return until
08/12/2005.

I could be reached by Mobile: +972 54 578-8113


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 16:36:58 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjkUc-0000Te-Ij; Tue, 06 Dec 2005 16:36:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjkUa-0000Rh-Kl; Tue, 06 Dec 2005 16:36:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25366;
	Tue, 6 Dec 2005 16:36:04 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejkq9-0002TX-6y; Tue, 06 Dec 2005 16:59:14 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 13:36:47 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB6LZTAE026366;
	Tue, 6 Dec 2005 13:36:30 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 16:36:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 16:36:14 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0533@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpA
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 06 Dec 2005 21:36:17.0617 (UTC)
	FILETIME=[173E4410:01C5FAAD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I am having trouble parsing these statements.

A provider is a provider.  I used the terms ingress and egress to
indicate some server that sits on the edge of a provider's network and
does peering to some other provider.  The usage below seems to mix
egress with originating being the network where the caller is attached.

I was noting that the called party terminal and the interconnect points
were different hosts and therefore may have different identities.  To
keep maximum flexibility, the format of those identities would need to
be fully under the control of the domain of each provider.  However,
conflating all that into a single URI in the Request-URI seemed
constraining to me.  Having three URIs in separate headers seemed the
most flexible.

Splitting.  I don't understand what got split or how.  ENUM -- Tel:URI
in, Point-of-interconnect URI out.  Put in Route header.  I only
suggested that there might be two route headers because the terminating
provider would indicate in ENUM, to get to this end-user, go to this
entrance first.  But, to get to that entrance, the originating provider
needs to determine what the corresponding exit point is from his
network, i.e. another Route header.  The format and content of that URI
is up to each provider.  The advertised entrance point is I think by
definition the (Inter-) Carrier ENUM.  The internal determination of the
exit point could be termed (Intra-) Carrier ENUM.  Maybe peering is
concerned only with the inter-carrier aspect.

The Request-URI could be a normalized public identity of the user
totally independent of interconnect naming schemes.  I was just teasing
out what are the assumptions and constraints in the original email.

Mike


> -----Original Message-----
> From: Thilo Salmon [mailto:salmon@sipgate.de]=20
> Sent: Tuesday, December 06, 2005 2:06 PM
> To: Klaus Darilion
> Cc: Michael Hammer (mhammer); sip@ietf.org;=20
> voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard
> Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Richard, Klaus, et al.
>=20
> Apparently, I have missed an important developlement lately.=20
>=20
> > What is the benefit of splitting the ENUM result (the SIP=20
> URI) into a=20
> > Route header and into a request URI?
> [...]
> > IMO there should be no semantic for the internal routing=20
> (the routing=20
> > from the main proxy to the egress proxy). This should be=20
> out of scope=20
> > of all WGs. Also the internal routing of the ingress=20
> provider should=20
> > be out of scope. The ingress provider should have SIP URI=20
> which can be=20
> > used to address its customers.
>=20
> I absolutely second that statement. If for any reason (we all=20
> have enough a vivid enough phantasy to imagine a good reason,=20
> I suppose) an ingress provider wishes to feed a different set=20
> of SIP URIs to each and every of his egress partners, he=20
> should not be stripped of this option.
> The scenario I have in mind is one in which an ingress=20
> provider chooses to encrypt the user part of all his SIP URIs=20
> with a key uniquely assigns to his egress partner.
>=20
> Just as Klaus I feel this complicates things and takes=20
> authority over internal adressing away from the ingress=20
> provider for no reason apparent (to me).
>=20
> Thilo
>=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 18:24:10 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjmAM-0005VU-1X; Tue, 06 Dec 2005 18:24:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjmAJ-0005TM-8C; Tue, 06 Dec 2005 18:24:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06277;
	Tue, 6 Dec 2005 18:23:16 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjmVt-0005zM-JA; Tue, 06 Dec 2005 18:46:26 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 06 Dec 2005 15:23:58 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB6NN7N6014376;
	Tue, 6 Dec 2005 15:23:51 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 18:23:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 18:23:47 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA058E@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAAi0/IA==
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <henry@pulver.com>, "Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 06 Dec 2005 23:23:48.0210 (UTC)
	FILETIME=[1C18A520:01C5FABC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

My looking glass is smudged today.

What does one call a provider of service? =20
I don't understand the aversion to service provider.=20

I thought it was only the "carrier" word that invoked regulatory burdens
(or PATS!).  I'd rather leave legal word games to lawyers and lobbyists.

Mike


> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com]=20
> Sent: Tuesday, December 06, 2005 5:30 PM
> To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> 'Stastny Richard'
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Sorry for nitpicking:
>=20
> >A provider is a provider.
>=20
> A provider is a business model and att/SBC may differ from=20
> Google who uses a different business model (which is more=20
> significant measured in $$$?).
>=20
> Didn't we agree to use the term "Internet domain owner" (we=20
> could shorten to IDOM or such)?=20
>=20
> Internet domains are well defined in the IETF.=20
> Business models for VoIP are better suited for other=20
> organizations, consortia or innovators who work to disrupt them :-)
>=20
> Thanks, Henry
>=20
> -----Original Message-----
> From: owner-voipeer@lists.uoregon.edu
> [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer
> (mhammer)
> Sent: Tuesday, December 06, 2005 3:36 PM
> To: Thilo Salmon; Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> I am having trouble parsing these statements.
>=20
> A provider is a provider.  I used the terms ingress and=20
> egress to indicate some server that sits on the edge of a=20
> provider's network and does peering to some other provider. =20
> The usage below seems to mix egress with originating being=20
> the network where the caller is attached.
>=20
> I was noting that the called party terminal and the=20
> interconnect points were different hosts and therefore may=20
> have different identities.  To keep maximum flexibility, the=20
> format of those identities would need to be fully under the=20
> control of the domain of each provider.  However, conflating=20
> all that into a single URI in the Request-URI seemed=20
> constraining to me.  Having three URIs in separate headers=20
> seemed the most flexible.
>=20
> Splitting.  I don't understand what got split or how.  ENUM=20
> -- Tel:URI in, Point-of-interconnect URI out.  Put in Route=20
> header.  I only suggested that there might be two route=20
> headers because the terminating provider would indicate in=20
> ENUM, to get to this end-user, go to this entrance first. =20
> But, to get to that entrance, the originating provider needs=20
> to determine what the corresponding exit point is from his=20
> network, i.e. another Route header.  The format and content=20
> of that URI is up to each provider.  The advertised entrance=20
> point is I think by definition the (Inter-) Carrier ENUM. =20
> The internal determination of the exit point could be termed=20
> (Intra-) Carrier ENUM.  Maybe peering is concerned only with=20
> the inter-carrier aspect.
>=20
> The Request-URI could be a normalized public identity of the=20
> user totally independent of interconnect naming schemes.  I=20
> was just teasing out what are the assumptions and constraints=20
> in the original email.
>=20
> Mike
>=20
>=20
> > -----Original Message-----
> > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > Sent: Tuesday, December 06, 2005 2:06 PM
> > To: Klaus Darilion
> > Cc: Michael Hammer (mhammer); sip@ietf.org;=20
> voipeer@lists.uoregon.edu;=20
> > enum@ietf.org; Stastny Richard
> > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > Richard, Klaus, et al.
> >=20
> > Apparently, I have missed an important developlement lately.=20
> >=20
> > > What is the benefit of splitting the ENUM result (the SIP
> > URI) into a
> > > Route header and into a request URI?
> > [...]
> > > IMO there should be no semantic for the internal routing
> > (the routing
> > > from the main proxy to the egress proxy). This should be
> > out of scope
> > > of all WGs. Also the internal routing of the ingress
> > provider should
> > > be out of scope. The ingress provider should have SIP URI
> > which can be
> > > used to address its customers.
> >=20
> > I absolutely second that statement. If for any reason (we all have=20
> > enough a vivid enough phantasy to imagine a good reason, I=20
> suppose) an=20
> > ingress provider wishes to feed a different set of SIP URIs to each=20
> > and every of his egress partners, he should not be stripped of this=20
> > option.
> > The scenario I have in mind is one in which an ingress provider=20
> > chooses to encrypt the user part of all his SIP URIs with a key=20
> > uniquely assigns to his egress partner.
> >=20
> > Just as Klaus I feel this complicates things and takes=20
> authority over=20
> > internal adressing away from the ingress provider for no reason=20
> > apparent (to me).
> >=20
> > Thilo
> >=20
>=20
> ______________________________________________________________
> ______________
> _
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
>=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 06 20:18:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjnqQ-0007iM-9U; Tue, 06 Dec 2005 20:11:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjnqM-0007hE-3Z; Tue, 06 Dec 2005 20:11:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16450;
	Tue, 6 Dec 2005 20:10:46 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjoBx-0000z4-Hd; Tue, 06 Dec 2005 20:33:57 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2005 17:11:29 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,223,1131350400"; 
	d="scan'208"; a="16740014:sNHT24720444"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB71BOUR018672; 
	Tue, 6 Dec 2005 20:11:25 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 20:11:24 -0500
Received: from jmpolk-wxp.cisco.com ([10.86.242.192]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 6 Dec 2005 20:11:24 -0500
Message-Id: <4.3.2.7.2.20051206190139.0325d688@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Dec 2005 19:11:22 -0600
To: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>, <henry@pulver.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA058E@xmb-rtp-20b.amer.ci
	sco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 07 Dec 2005 01:11:24.0129 (UTC)
	FILETIME=[241FB510:01C5FACB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Mike

This seems to be creeping into more than one WG at about the same time.

ISP used to be (roughly) the company you or you employer bought service 
from to gain access to the Internet.  Now that is a little too generic for 
a lot of people's tastes as there are different SPs that an individual many 
have now that weren't available not so long ago.  Hence the recent push to 
separate them somehow.

Application Providers, to me, include a Vonage for Voice services, and a 
Yahoo for IM.

Service Providers or Internet Providers, to me, connect one to the Internet 
for L3 access

Access Providers, to me, are the organizations like the DSL and Cable and 
WiFi connectivity providers.

Often times, to me, the Internet Providers and the Access Providers are 
either the same company - while perhaps different divisions, but they can 
be totally different companies too.

The separation I'm seeing is between the organization that gives you you 
Internet access and the organizations that provider you with all the 
services required for a particular application - such as Voice or Video.

Everything used to be best effort, and services were either at your device 
or at the provider's server.  Now there's an overlay at layer 7 (typically) 
and we're struggling with how to name and describe it.



At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
>My looking glass is smudged today.
>
>What does one call a provider of service?
>I don't understand the aversion to service provider.
>
>I thought it was only the "carrier" word that invoked regulatory burdens
>(or PATS!).  I'd rather leave legal word games to lawyers and lobbyists.
>
>Mike
>
>
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry@pulver.com]
> > Sent: Tuesday, December 06, 2005 5:30 PM
> > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;
> > 'Stastny Richard'
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >
> > Sorry for nitpicking:
> >
> > >A provider is a provider.
> >
> > A provider is a business model and att/SBC may differ from
> > Google who uses a different business model (which is more
> > significant measured in $$$?).
> >
> > Didn't we agree to use the term "Internet domain owner" (we
> > could shorten to IDOM or such)?
> >
> > Internet domains are well defined in the IETF.
> > Business models for VoIP are better suited for other
> > organizations, consortia or innovators who work to disrupt them :-)
> >
> > Thanks, Henry
> >
> > -----Original Message-----
> > From: owner-voipeer@lists.uoregon.edu
> > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer
> > (mhammer)
> > Sent: Tuesday, December 06, 2005 3:36 PM
> > To: Thilo Salmon; Klaus Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;
> > Stastny Richard
> > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >
> > I am having trouble parsing these statements.
> >
> > A provider is a provider.  I used the terms ingress and
> > egress to indicate some server that sits on the edge of a
> > provider's network and does peering to some other provider.
> > The usage below seems to mix egress with originating being
> > the network where the caller is attached.
> >
> > I was noting that the called party terminal and the
> > interconnect points were different hosts and therefore may
> > have different identities.  To keep maximum flexibility, the
> > format of those identities would need to be fully under the
> > control of the domain of each provider.  However, conflating
> > all that into a single URI in the Request-URI seemed
> > constraining to me.  Having three URIs in separate headers
> > seemed the most flexible.
> >
> > Splitting.  I don't understand what got split or how.  ENUM
> > -- Tel:URI in, Point-of-interconnect URI out.  Put in Route
> > header.  I only suggested that there might be two route
> > headers because the terminating provider would indicate in
> > ENUM, to get to this end-user, go to this entrance first.
> > But, to get to that entrance, the originating provider needs
> > to determine what the corresponding exit point is from his
> > network, i.e. another Route header.  The format and content
> > of that URI is up to each provider.  The advertised entrance
> > point is I think by definition the (Inter-) Carrier ENUM.
> > The internal determination of the exit point could be termed
> > (Intra-) Carrier ENUM.  Maybe peering is concerned only with
> > the inter-carrier aspect.
> >
> > The Request-URI could be a normalized public identity of the
> > user totally independent of interconnect naming schemes.  I
> > was just teasing out what are the assumptions and constraints
> > in the original email.
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > To: Klaus Darilion
> > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > voipeer@lists.uoregon.edu;
> > > enum@ietf.org; Stastny Richard
> > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > Richard, Klaus, et al.
> > >
> > > Apparently, I have missed an important developlement lately.
> > >
> > > > What is the benefit of splitting the ENUM result (the SIP
> > > URI) into a
> > > > Route header and into a request URI?
> > > [...]
> > > > IMO there should be no semantic for the internal routing
> > > (the routing
> > > > from the main proxy to the egress proxy). This should be
> > > out of scope
> > > > of all WGs. Also the internal routing of the ingress
> > > provider should
> > > > be out of scope. The ingress provider should have SIP URI
> > > which can be
> > > > used to address its customers.
> > >
> > > I absolutely second that statement. If for any reason (we all have
> > > enough a vivid enough phantasy to imagine a good reason, I
> > suppose) an
> > > ingress provider wishes to feed a different set of SIP URIs to each
> > > and every of his egress partners, he should not be stripped of this
> > > option.
> > > The scenario I have in mind is one in which an ingress provider
> > > chooses to encrypt the user part of all his SIP URIs with a key
> > > uniquely assigns to his egress partner.
> > >
> > > Just as Klaus I feel this complicates things and takes
> > authority over
> > > internal adressing away from the ingress provider for no reason
> > > apparent (to me).
> > >
> > > Thilo
> > >
> >
> > ______________________________________________________________
> > ______________
> > _
> > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> >
> >
>
>_____________________________________________________________________________
>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 03:34:05 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjukX-0003Yp-AW; Wed, 07 Dec 2005 03:34:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjukU-0003XN-Rm; Wed, 07 Dec 2005 03:34:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01511;
	Wed, 7 Dec 2005 03:33:10 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejv69-0006GQ-An; Wed, 07 Dec 2005 03:56:26 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1Ejujs-0003YJ-00; Wed, 07 Dec 2005 09:33:24 +0100
Message-ID: <43969E3E.4060207@pernau.at>
Date: Wed, 07 Dec 2005 09:33:02 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>
Subject: Re: [Sip] SIP AoR, tel and ENUM
References: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA042E@xmb-rtp-20b.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 58b614506802734014829a093beb6879
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi Michael!

As there are some concerns about the terminology. Thus I will use AD 
(adminsitrative domain, from the SPEERMINT charter) as synonym for ITSP, 
carrier, telco, VoIP enabled enterprise .....

Michael Hammer (mhammer) wrote:
> Klaus,
> 
> It has to do with the difference between re-targeting and routing.  Is
> the point of interconnect the real target of the request or just a
> waypoint in the route to get to the target?  In the User ENUM case, it
> seems as though the addresses are all about the target users and their
> devices.  But, here it seemed a bit different.  It is a route through an
> intermediate point.  It seems like the semantic and syntactical element
> would be more coherent and no more complicated.  Thus, I posed the
> question.

I can not really see a difference to user ENUM. There is only one 
Infrastructure ENUM tree. Thus, all ADs which query this tree will get 
the same URI back from ENUM. Thus, the ingress point announced by the 
receiving AD is the same for all outgoing ADs.

Further, if the outgoing AD does not send the request directly to the 
announced ingress point (maybe no peering relationship), but to an 
intermediate point (transit provider, clearinghouse, ....), this routing 
is different for each AD. Thus, such kind of routing information can not 
be in ENUM.

Once the request reaches the ingress point of the receiving AD, there 
will be further routing inside the receiving AD. Maybe the route is for 
example:
  1. ingresspoint1.ad
  2. accountingbox.ad
  3. mainproxy.ad
  4. .....

Publishing such a route in ENUM makes no sense, as the route is the same 
for all incoming requests. Thus, the route should be applied by the 
previous hop. That means, ingresspoint1.ad knows that it should formward 
to accountingbox.ad, and so on.

IMO, ENUM is a simple routing and re-targeting in one step. If complex 
re-routing and re-targeting is required it should be done by the 
receiving AD. The outoing AD is not interested in the internal routing 
of the receiving AD.

Maybe you can give me an example of a scenario were my model does not fit.

regards
klaus



> 
> Mike
> 
> 
> 
>>-----Original Message-----
>>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] 
>>Sent: Tuesday, December 06, 2005 11:48 AM
>>To: Stastny Richard
>>Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu; 
>>enum@ietf.org; sip@ietf.org
>>Subject: Re: [Sip] SIP AoR, tel and ENUM
>>
>>Stastny Richard wrote:
>>
>>>Mike wrote:
>>>
>>>
>>>
>>>>Before going down this path too far, can we ask where the 
>>
>>results of 
>>
>>>>the ENUM queries will go in the SIP message to control routing?
>>>>Hypothetically, the egress and ingress gateways could be 
>>
>>identified in 
>>
>>>>Route headers rather than in the Request-URI.  An external ENUM dip 
>>>>and an internal ENUM dip might lead to something along the lines of:
>>>
>>> 
>>>Correct,
>>> 
>>>Jonathan proposed this some time ago, but this thread somewhere 
>>>stranded
>>> 
>>>So basically an interneal ENUM entry of
>>>
>>>sip:+1777555111@egress.provider3.com;user=phone
>>> 
>>>would result in
>>>
>>>INVITE tel:+17775551111 SIP/2.0
>>>...
>>>Route: <sip:egress11.provider3.com;lr>
>>> 
>>>an the external ENUM entry would be
>>>sip:+1777555111@provider17.com
>>> 
>>>result in
>>>Route: <sip:ingress39.provider17.com;lr>
>>> 
>>>This is basically what I am after
>>>...
>>>
>>
>>Hi folks.
>>
>>What is the benefit of splitting the ENUM result (the SIP 
>>URI) into a Route header and into a request URI?
>>
>>IMO there should be no semantic for the internal routing (the 
>>routing from the main proxy to the egress proxy). This should 
>>be out of scope of all WGs. Also the internal routing of the 
>>ingress provider should be out of scope. The ingress provider 
>>should have SIP URI which can be used to address its customers.
>>
>>If this URI is sip:431505641636@in.mydomain.com or 
>>foobar666@in.mydomain.com, or sip:klaus.darilion@mydomain.com 
>>is the ingress provider's choice. Maybe the ingress provider 
>>also allows all of the previous SIP URIs to reach a certain 
>>user. The incoming provider just has to make sure that these 
>>SIP URIs map to the corresponding user (to the user's AoR). 
>>If this user also has an E.164 number which is in I-ENUM, 
>>then it's again the ingress provider's choice which URI to 
>>put into the NAPTR.
>>
>>IMO there should not not be any semantics how to create a 
>>request URI and a pre-loaded route set of the SIP URI 
>>received from ENUM. The egress proxy sends the request to the 
>>ingress proxy in the format choosen by the ingress provider 
>>(e.g. publish via ENUM or an business cards).
>>
>>We should not complicate things. I do not see any problems 
>>with this simple approach. If there are some problems, please 
>>correct me.
>>
>>regards
>>klaus
>>
>>
>>
>>
>>>>I am also suggesting that the ENUM result be an AoR, since 
>>
>>one might 
>>
>>>>want some reliability in choosing which server in the 
>>
>>gateway cluster 
>>
>>>>to go to based on further DNS queries, load balancing, etc.
>>>
>>> 
>>>Now this is in contradiction to the above
>>> 
>>>Richard
>>>
>>>
>>>
>>>>Mike
>>>
>>>
>>>>-----Original Message-----
>>>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
>>
>>Behalf Of 
>>
>>>>Stastny Richard
>>>>Sent: Tuesday, December 06, 2005 4:54 AM
>>>>To: voipeer@lists.uoregon.edu
>>>>Cc: enum@ietf.org; sip@ietf.org
>>>>Subject: [Sip] SIP AoR, tel and ENUM
>>>>
>>>>Folks,
>>>>
>>>>This post is primarily to SPEER, but since it also concerns 
>>
>>ENUM and 
>>
>>>>SIP I cross-post it.
>>>>
>>>>I need (urgently) some guidance on the question what SIP 
>>
>>URIs to use 
>>
>>>>in Infrastructure ENUM.
>>>>
>>>>User ENUM as defined in RFC 3761 provides a mapping from
>>>>E.164 numbers to SIP URIs for primarily for end-users. So 
>>
>>what you get 
>>
>>>>back is the AoR pointing to the destination SIP server.
>>>>
>>>>If you get something back on the ENUM query such as 
>>>>sip:Richard@stastny.com, this is definetely an AoR. Because 
>>
>>of privacy 
>>
>>>>reasons, more and more people start using SIP URI such as 
>>>>sip:4319793321@provider.net or (an AoR) 
>>>>sip:+4319793321@provider.net;user=phone (IMHO not an AoR) or even 
>>>>sip:+4319793321@provider.net
>>>>
>>>>IMHO the last one should not be used, and some guidance is 
>>
>>also needed 
>>
>>>>here. but it only concerns the destination server and if the 
>>>>destination servers can deal with it, fine.
>>>>
>>>>Now with Infrastructure ENUM (and especially in combination with 
>>>>private ENUMs) the situation is different.
>>>>
>>>>The purpose of Infrastructure ENUM is according to the re-chartered 
>>>>ENUM WG "to discover points of interconnection necessary to 
>>
>>terminate 
>>
>>>>communications sessions identified by a E164 number, in addition to 
>>>>identifying end point protocols and services."
>>>>
>>>>This translates to: Infrastructure ENUM does not 
>>
>>necessarily contain 
>>
>>>>end-point information (AoR), but routing information.
>>>>Routing, in my definition here, is basically to provide you 
>>
>>with the 
>>
>>>>information what the next hop is.
>>>>
>>>>A very common scenario is the following one: a walled 
>>
>>garden network 
>>
>>>>is using private ENUM to detect the border element for a 
>>
>>given number, 
>>
>>>>Some border element may lead to another private (extranet), using a 
>>>>federated ENUM for this number, another may be connected to the 
>>>>Internet using public Infrastructure ENUM for another number.
>>>>Public Infrastructure ENUM is giving back the ingress 
>>
>>border element, 
>>
>>>>which in turn uses private ENUM again to find the SIP 
>>
>>server hosting 
>>
>>>>the user with this number.
>>>>
>>>>In addition, again for privacy reasons, in most cases the above 
>>>>mentioned SIP URIs containing E.164 numbers are used.
>>>>
>>>>This raises two issues, an architectural one and a BCP one:
>>>>
>>>>To principally different scenarios are possible
>>>>
>>>>Scenario A
>>>>
>>>>ENUM is providing ONLY the mapping from the E.164 number to 
>>
>>an AoR. (= 
>>
>>>>name to address mapping) The above described routing between the 
>>>>networks to find the destination network is done via the 
>>
>>AoR. How this 
>>
>>>>is done is completely within the scope of SPEER.
>>>>
>>>>Note: this is the only future proof way, because a user may use the 
>>>>AoR in the first place and then the routing MUST work 
>>
>>anyway. So any 
>>
>>>>additional routing information in ENUM would be duplicated and 
>>>>therefore error-prone.
>>>>
>>>>I propose in addition to use in this case a SIP in the format 
>>>>sip:4319793321@provider.net, to clearly indicate that this has no 
>>>>relationship to an E.164 number.
>>>>
>>>>Scenario B:
>>>>
>>>>This is the scenario proposed in most current 
>>
>>implementations and also 
>>
>>>>in the RFI on ENUM popping up everywhere. The reason is that most 
>>>>scenarios currently concentrate solely on the peering with E.164 
>>>>numbers and completely forget the peering with SIP URIs
>>>>
>>>>The ENUM entry is giving you the next hop: This is in case of the 
>>>>walled garden originating network either the server hosting the 
>>>>end-user or the egress border element (e.g. IBCF, THIG, or 
>>>>whatchamacallit). This element is again querying another 
>>
>>kind of ENUM, 
>>
>>>>getting back the ingress border element of the destination 
>>
>>network (or 
>>
>>>>even of a "transit" L5 network), and so on. The ingress 
>>
>>border element 
>>
>>>>is the again calling its private ENUM to finally find the hosting 
>>>>server.
>>>>
>>>>Note: I have a sub-question here: Some implementations are even 
>>>>proposing here to skip the SRV query and directly pointing 
>>
>>to the SIP 
>>
>>>>server(s) in ENUM. Does this make sense?
>>>>
>>>>If this scenario is used, I propose to use only SIP URIs in 
>>
>>the format 
>>
>>>>sip:+4319793321@provider.net;user=phone or better 
>>>>SIP:+4319793321@sbc.prov.net; user=phone
>>>>
>>>>to clearly indicate that this is still basically a
>>>>tel: URI combined with a routing info and that it may be used in 
>>>>another ENUM query.
>>>>
>>>>My questions to the crowd are the following:
>>>>
>>>>1. is this proposed use of SIP URIs within the context of ENUM ok?
>>>>
>>>>2. What should be the preferred scenario for VoIP peering?
>>>>Is some kind of combination between the scenarios feasible?
>>>>And what are the arguments pro and con?
>>>>
>>>>I consider the outcome of this discussion as substantial 
>>
>>input to the 
>>
>>>>deliverables of SPEER, but some first guidance is urgently required 
>>>>now, because many entities are making basic decisions in this 
>>>>direction NOW.
>>>>
>>>>Please also excuse and correct incorrect use of terminology.
>>>>
>>>>Regards
>>>>Richard Stastny
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>>>
>>>
>>
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 05:45:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejwng-00048g-SU; Wed, 07 Dec 2005 05:45:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjWK3-0003sE-Lq; Tue, 06 Dec 2005 01:29:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12326;
	Tue, 6 Dec 2005 01:28:16 -0500 (EST)
From: thangarajan.i@flextronicssoftware.com
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjWfQ-0004GV-Bk; Tue, 06 Dec 2005 01:51:17 -0500
Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21])
	by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jB66Snx14633;
	Tue, 6 Dec 2005 11:58:49 +0530
In-Reply-To: <200512051704.jB5H4EHv015293@spark.hss.co.in>
Subject: Re: [Sip] Query in mutliple Subscribes
To: sip@ietf.org
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OF6D9A4FD4.DDF7EF85-ON652570CF.00225C56-652570CF.002396CA@flextronicssoftware.com>
Date: Tue, 6 Dec 2005 11:54:20 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 12/06/2005 12:00:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
X-Mailman-Approved-At: Wed, 07 Dec 2005 05:45:27 -0500
Cc: sip-bounces@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org





HI Sudhir,

>From RFC 3261

"the Call-ID header field MUST be selected by the UAC as a globally unique
identifier over space and time unless overridden by method-specific
behavior."

      RFC 3265 is not overriding this behavior. So Subscribe Call-ID should
be unique.

>>Hi all,

>>If I want to Subscribe to multilple Users i.e. If I Subscribe to User A
and
>>User B respectively. Is that Ok if i had same call-ID with User A and
User
>>B.

>>thanks in advance

>>regards
>>Sudhir



                                                                           
             sip-request@ietf.                                             
             org                                                           
             Sent by:                                                   To 
             sip-bounces@ietf.         sip@ietf.org                        
             org                                                        cc 
                                                                           
                                                                   Subject 
             12/05/2005 10:34          Sip Digest, Vol 20, Issue 4         
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
               sip@ietf.org                                                
                                                                           
                                                                           




Send Sip mailing list submissions to
             sip@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
             https://www1.ietf.org/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
             sip-request@ietf.org

You can reach the person managing the list at
             sip-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip digest..."


Today's Topics:

   1. Query in mutliple Subscribes (Sudhir Kumar Reddy)
   2. Fora for TURN discussion: BEHAVE list (Jonathan Rosenberg)


----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Dec 2005 12:35:13 +0530
From: Sudhir Kumar Reddy <t.sudhirkumar@gmail.com>
Subject: [Sip] Query in mutliple Subscribes
To: sip@ietf.org
Message-ID:
             <52db68bc0512042305g1725c8e3oe864c036829909c2@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

If I want to Subscribe to multilple Users i.e. If I Subscribe to User A and
User B respectively. Is that Ok if i had same call-ID with User A and User
B.

thanks in advance

regards
Sudhir



--
-----------------------------------------------
"The mathematical precision of the universe reveals the mathematical mind
of
God." --- Albert Einstein
-----------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sip/attachments/20051205/3320947d/attachment.htm


------------------------------

Message: 2
Date: Mon, 05 Dec 2005 10:16:20 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: [Sip] Fora for TURN discussion: BEHAVE list
To: Midcom <midcom@ietf.org>, Behave
             <ietf-behave@list.sipfoundry.org>,        IETF MMUSIC WG
<mmusic@ietf.org>,
             IETF SIP List <sip@ietf.org>,             IETF Sipping List
<sipping@ietf.org>
Message-ID: <439459C4.7000808@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed

Sorry for the broad distribution here, but I wanted to let folks know
that I'm going to be moving discussions on TURN over to the behave list
(http://www.ietf.org/html.charters/behave-charter.html).   I'll be
posting some issues shortly which require discussion, so if you are
interested, please subscribe there.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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

End of Sip Digest, Vol 20, Issue 4
**********************************



***********************  FSS-Private   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 05:45:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejwni-00049C-H0; Wed, 07 Dec 2005 05:45:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejfe6-0001sU-Uk
	for sip@megatron.ietf.org; Tue, 06 Dec 2005 11:26:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19755
	for <sip@ietf.org>; Tue, 6 Dec 2005 11:25:36 -0500 (EST)
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejfzb-00088o-Li
	for sip@ietf.org; Tue, 06 Dec 2005 11:48:42 -0500
Received: from [131.161.248.94] (open-131-161-248-94.cliq.com [131.161.248.94])
	(authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id jB6GQGW07317;
	Tue, 6 Dec 2005 08:26:18 -0800
In-Reply-To: <BF952908.5EA03%fluffy@cisco.com>
References: <BF952908.5EA03%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <be010ebb79384cf96a4b415729e8a44a@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Date: Tue, 6 Dec 2005 08:26:13 -0800
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Dec 2005 05:45:26 -0500
Cc: SIP WG <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>,
	"Vijay K. Gurbani" <vkg@lucent.com>
Subject: [Sip] Re: Comment on draft-ietf-sip-connect-reuse-04
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


On Nov 7, 2005, at 15:53, Cullen Jennings wrote:

>
> Two issues...
>
> This is very difficult to implement for most people. If you do a DNS 
> lookup
> of an A record, this requires you to get every IP address then look at 
> your
> alias to see if you have one that matches - and not do load balancing. 
> This
> is hard unless you have your own DNS resolve library which most people 
> do
> not.

You don't need to lookup every IP address, you do need to consult a 
list of "named" connections before you do SRV lookup however.

> Second, I don't think it works. If a server runs two virtual domain 
> a.com
> and b.com both on 1.2.3.4:5060 and use the TLS extended hello to 
> separate
> them, then if it connects to C as A.com, and later C wants to send a 
> sips
> message to B.com, it will deliver it over the connection to A.com 
> which is
> totally broken from a security point of view.

This does not result in a problem.  A.com connects to C *from* an 
ephemeral port. The connection reuse causes C to reuse a connection to 
A.com when contacting A.com.  A new connection from B.com would use a 
different ephemeral port.

thanks,
-rohan


_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 05:45:32 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejwnj-0004Ae-Vd; Wed, 07 Dec 2005 05:45:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eji5N-0003kw-Vz; Tue, 06 Dec 2005 14:02:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09074;
	Tue, 6 Dec 2005 14:01:54 -0500 (EST)
Received: from erdbert.netzquadrat.de ([217.10.64.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EjiQu-0005Yv-M1; Tue, 06 Dec 2005 14:25:02 -0500
Received: from [217.10.64.186] (helo=workstation-186.netzquadrat.de
	ident=salmon)
	by erdbert.netzquadrat.de with esmtp (Exim 3.12 #1 (Debian))
	id 1Eji53-00056v-00; Tue, 06 Dec 2005 20:02:25 +0100
Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
From: Thilo Salmon <salmon@sipgate.de>
To: Klaus Darilion <klaus.mailinglists@pernau.at>
In-Reply-To: <4395C0DA.4040206@pernau.at>
References: <32755D354E6B65498C3BD9FD496C7D462C46F4@oefeg-s04.oefeg.loc>
	<4395C0DA.4040206@pernau.at>
Content-Type: text/plain
Date: Tue, 06 Dec 2005 20:05:35 +0100
Message-Id: <1133895935.21571.170.camel@gw12>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Dec 2005 05:45:27 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Richard, Klaus, et al.

Apparently, I have missed an important developlement lately. 

> What is the benefit of splitting the ENUM result (the SIP URI) into a 
> Route header and into a request URI?
[...]
> IMO there should be no semantic for the internal routing (the routing 
> from the main proxy to the egress proxy). This should be out of scope of 
> all WGs. Also the internal routing of the ingress provider should be out 
> of scope. The ingress provider should have SIP URI which can be used to 
> address its customers.

I absolutely second that statement. If for any reason (we all have
enough a vivid enough phantasy to imagine a good reason, I suppose) an
ingress provider wishes to feed a different set of SIP URIs to each and
every of his egress partners, he should not be stripped of this option.
The scenario I have in mind is one in which an ingress provider chooses
to encrypt the user part of all his SIP URIs with a key uniquely assigns
to his egress partner.

Just as Klaus I feel this complicates things and takes authority over
internal adressing away from the ingress provider for no reason apparent
(to me).

Thilo


_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 05:45:33 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejwnl-0004B6-B5; Wed, 07 Dec 2005 05:45:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjlJi-0006pN-FA
	for sip@megatron.ietf.org; Tue, 06 Dec 2005 17:29:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00583
	for <sip@ietf.org>; Tue, 6 Dec 2005 17:28:55 -0500 (EST)
Message-Id: <200512062228.RAA00583@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjlfH-00041n-Rq
	for sip@ietf.org; Tue, 06 Dec 2005 17:52:04 -0500
Received: (qmail 27888 invoked by uid 510); 6 Dec 2005 17:34:07 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 0.942406 secs); 06 Dec 2005 22:34:07 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	0.942406 secs Process 27881)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Tue, 06 Dec 2005 22:34:06 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Tue, 6 Dec 2005 16:29:34 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0533@xmb-rtp-20b.amer.cisco.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEA=
X-Antivirus-MYDOMAIN-Message-ID: <113390844683527881@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Dec 2005 05:45:27 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Sorry for nitpicking:

>A provider is a provider.

A provider is a business model and att/SBC may differ from Google who uses a
different business model (which is more significant measured in $$$?).

Didn't we agree to use the term "Internet domain owner" (we could shorten to
IDOM or such)? 

Internet domains are well defined in the IETF. 
Business models for VoIP are better suited for other organizations,
consortia or innovators who work to disrupt them :-)

Thanks, Henry

-----Original Message-----
From: owner-voipeer@lists.uoregon.edu
[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer
(mhammer)
Sent: Tuesday, December 06, 2005 3:36 PM
To: Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard
Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

I am having trouble parsing these statements.

A provider is a provider.  I used the terms ingress and egress to
indicate some server that sits on the edge of a provider's network and
does peering to some other provider.  The usage below seems to mix
egress with originating being the network where the caller is attached.

I was noting that the called party terminal and the interconnect points
were different hosts and therefore may have different identities.  To
keep maximum flexibility, the format of those identities would need to
be fully under the control of the domain of each provider.  However,
conflating all that into a single URI in the Request-URI seemed
constraining to me.  Having three URIs in separate headers seemed the
most flexible.

Splitting.  I don't understand what got split or how.  ENUM -- Tel:URI
in, Point-of-interconnect URI out.  Put in Route header.  I only
suggested that there might be two route headers because the terminating
provider would indicate in ENUM, to get to this end-user, go to this
entrance first.  But, to get to that entrance, the originating provider
needs to determine what the corresponding exit point is from his
network, i.e. another Route header.  The format and content of that URI
is up to each provider.  The advertised entrance point is I think by
definition the (Inter-) Carrier ENUM.  The internal determination of the
exit point could be termed (Intra-) Carrier ENUM.  Maybe peering is
concerned only with the inter-carrier aspect.

The Request-URI could be a normalized public identity of the user
totally independent of interconnect naming schemes.  I was just teasing
out what are the assumptions and constraints in the original email.

Mike


> -----Original Message-----
> From: Thilo Salmon [mailto:salmon@sipgate.de] 
> Sent: Tuesday, December 06, 2005 2:06 PM
> To: Klaus Darilion
> Cc: Michael Hammer (mhammer); sip@ietf.org; 
> voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard
> Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> Richard, Klaus, et al.
> 
> Apparently, I have missed an important developlement lately. 
> 
> > What is the benefit of splitting the ENUM result (the SIP 
> URI) into a 
> > Route header and into a request URI?
> [...]
> > IMO there should be no semantic for the internal routing 
> (the routing 
> > from the main proxy to the egress proxy). This should be 
> out of scope 
> > of all WGs. Also the internal routing of the ingress 
> provider should 
> > be out of scope. The ingress provider should have SIP URI 
> which can be 
> > used to address its customers.
> 
> I absolutely second that statement. If for any reason (we all 
> have enough a vivid enough phantasy to imagine a good reason, 
> I suppose) an ingress provider wishes to feed a different set 
> of SIP URIs to each and every of his egress partners, he 
> should not be stripped of this option.
> The scenario I have in mind is one in which an ingress 
> provider chooses to encrypt the user part of all his SIP URIs 
> with a key uniquely assigns to his egress partner.
> 
> Just as Klaus I feel this complicates things and takes 
> authority over internal adressing away from the ingress 
> provider for no reason apparent (to me).
> 
> Thilo
> 

____________________________________________________________________________
_
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html




_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 06:58:06 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejxvy-0007ZS-8E; Wed, 07 Dec 2005 06:58:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejxvv-0007ZF-NN; Wed, 07 Dec 2005 06:58:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24781;
	Wed, 7 Dec 2005 06:57:12 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EjyHb-00052g-Bv; Wed, 07 Dec 2005 07:20:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Dec 2005 13:01:28 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc>
Thread-Topic: SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsA==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <sip@ietf.org>, <voipeer@lists.uoregon.edu>, <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Sip] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi folks,

thanks for the statements sofar, but I am still confused
(maybe even more ;-)

It seems also that my first post was not too well formulated

The basic question was:
Should Infrastructure ENUM contain a routing information
to the next hop only (the ingress border element of Provider B
(or administrative domain B)=20
or simply a mapping from an E.164 number to an AoR?

I will try to give another example and start from
within the scope of SPEERMINT (I hope this is the
last iteration before the name gets too lomg ;-)


I subscribe with provider B and get a default public
user identity (AoR) from this provider:
e.g. sip:foo@provB.net

This "foo" can be anything the provider chooses it to be:
e.g. an alphanumeric string such as ywzabcd,
a numeric string such as 16241 (my FWD number)
or 019793321 or 4319793321

Any other provider A having a peering agreement
with Provider B must be able to route a SIP call
given this SIP AoR to provider B, either to the
SIP proxy hosting this account or at least to
the ingress proxy(s) in provider B network.

On way to do so is to use SRV records within
the zone of provB.net pointing to e.g

ingress14.provB.net
and
ingress21.provB.net

Question: is this correct?

Note: after the ingress proxy provider B
may use another mapping mechanism to find
the real hosting server e.g. srv21.provB.net

Now I as a user are not happy with this default
public user identity, I want to have some aliases

eg:=20
1)sip:richard@stastny.com and
2) +43 1 9793321

In case 1) I assume that provider B needs
to provide me with redirect server(s), and I
need to enter in stastny.com SRV records
to point to these redirect servers
e.g. redirect.provB.net

sip:richard.stastny.com is redirected to
sip:foo@provB.net

Question: is this correct?

In case 2) we need Infrastructure ENUM
[Side note; in my user ENUM I would either enter
sip:richard@stastny.com or sip:foo@provB.net
this is my choice]

Now the question is: what goes into Infrastructure
ENUM for say +4319793321?

Is it:
Sip:foo@provB.net (if plain sip:foo@provB.net works
this must also work)
OR
sip:+4319793321@provB.net;user=3Dphone (correct?)
OR
sip:+4319793321@provB.net (wrong?)
OR
sip:4319793321@provB.net (valid only if 4319793321 =3D foo)

OR is it
sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
AND
sip:+4319793321@ingress21.provB.net;user=3Dphone

In this last case one would not need to query the
SRV records in provB.net

I hope I did not confuse the issue even more

Richard



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 07:40:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejyaz-0000Er-3b; Wed, 07 Dec 2005 07:40:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejyax-0000EB-HQ; Wed, 07 Dec 2005 07:40:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29126;
	Wed, 7 Dec 2005 07:39:36 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ejywe-0006co-RM; Wed, 07 Dec 2005 08:02:53 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1Ejyac-0003c6-00; Wed, 07 Dec 2005 13:40:06 +0100
Message-ID: <4396D807.8000406@pernau.at>
Date: Wed, 07 Dec 2005 13:39:35 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi Richard!

comments inline

Stastny Richard wrote:
> Should Infrastructure ENUM contain a routing information
> to the next hop only (the ingress border element of Provider B
> (or administrative domain B) 
> or simply a mapping from an E.164 number to an AoR?

IMHO it should be a mapping to an AoR as in user ENUM.

> I will try to give another example and start from
...
> I subscribe with provider B and get a default public
> user identity (AoR) from this provider:
> e.g. sip:foo@provB.net
> 
> This "foo" can be anything the provider chooses it to be:
> e.g. an alphanumeric string such as ywzabcd,
> a numeric string such as 16241 (my FWD number)
> or 019793321 or 4319793321
> 
> Any other provider A having a peering agreement
> with Provider B must be able to route a SIP call
> given this SIP AoR to provider B, either to the
> SIP proxy hosting this account or at least to
> the ingress proxy(s) in provider B network.
> 
> On way to do so is to use SRV records within
> the zone of provB.net pointing to e.g
> 
> ingress14.provB.net
> and
> ingress21.provB.net
> 
> Question: is this correct?

IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net

> Note: after the ingress proxy provider B
> may use another mapping mechanism to find
> the real hosting server e.g. srv21.provB.net
> 
> Now I as a user are not happy with this default
> public user identity, I want to have some aliases
> 
> eg: 
> 1)sip:richard@stastny.com and
> 2) +43 1 9793321
> 
> In case 1) I assume that provider B needs
> to provide me with redirect server(s), and I
> need to enter in stastny.com SRV records
> to point to these redirect servers
> e.g. redirect.provB.net
> 
> sip:richard.stastny.com is redirected to
> sip:foo@provB.net
> 
> Question: is this correct?

This is a working scenario. But a redirect server is not mandatory. It 
may also be a proxy which forwards the request "INVITE 
sip:richard.stastny.com" to "INVITE sip:foo@provB.net".

It is also possbile that SRV for stastny.com points directly to 
ingress12.provB.net and ingress12 knows about all hosted SIP domains and 
knows how to forward the request to the end user.

But this is a design decision of the provB and IMO should be out of 
scope of SPEERMINT. provB may use redirect server, provC may accept all 
hosted SIP domains directly on their ingress points, .....

I personally prefer relaying instead of redirect. E.g. redirect raises 
questions like: How should intercept the redirect response and forward 
to the new URI? The UA client or the SIP proxy of provA or the egress proxy?

The important thing is that the originator (provA) should not have to 
take care how provB implemented the hosting of SIP domains.

> In case 2) we need Infrastructure ENUM
> [Side note; in my user ENUM I would either enter
> sip:richard@stastny.com or sip:foo@provB.net
> this is my choice]
> 
> Now the question is: what goes into Infrastructure
> ENUM for say +4319793321?
> 
> Is it:
> Sip:foo@provB.net (if plain sip:foo@provB.net works
> this must also work)
> OR
> sip:+4319793321@provB.net;user=phone (correct?)
> OR
> sip:+4319793321@provB.net (wrong?)
> OR
> sip:4319793321@provB.net (valid only if 4319793321 = foo)
> 
> OR is it
> sip:+4319793321@ingress14.provB.net;user=phone (and the above variants)
> AND
> sip:+4319793321@ingress21.provB.net;user=phone

IMO all of these are valid. It's up to the choice of provB. provB can 
put anything into ENUM as long as provB is able to map from the URI in 
I-ENUM to the end user.

If I would design the network for provB, I would use version 2 (without 
user=phone as the user are not limited to phones).

> In this last case one would not need to query the
> SRV records in provB.net

Also in the last case (if beeing conform with RFC3263), the egress proxy 
has to perform NAPTR and SRV lookups. If you want to avoid them, just 
put the IP address or the port into the host part, e.g.

sip:+4319793321@ingress21.provB.net:5060;user=phone

regards
klaus

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 10:21:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek16h-0004jN-PD; Wed, 07 Dec 2005 10:21:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek16f-0004iK-LM; Wed, 07 Dec 2005 10:21:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19202;
	Wed, 7 Dec 2005 10:20:29 -0500 (EST)
From: santosh@renintech.com
Received: from [70.86.188.194] (helo=m9.hamarashehar.com
	ident=[U2FsdGVkX1/HB08wgYvEK8DicGSGRjH6EEKy5pxY7js=])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek1SN-0003jY-Ok; Wed, 07 Dec 2005 10:43:48 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by m9.hamarashehar.com (Postfix) with ESMTP id 028437C40A0;
	Wed,  7 Dec 2005 09:22:11 -0600 (CST)
Received: from m9.hamarashehar.com ([127.0.0.1])
	by localhost (m9.hamarashehar.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 32151-05; Wed,  7 Dec 2005 09:22:10 -0600 (CST)
Received: by m9.hamarashehar.com (Postfix, from userid 48)
	id 2FDC47C408D; Wed,  7 Dec 2005 09:22:10 -0600 (CST)
Received: from 202.63.110.45
	(SquirrelMail authenticated user santosh@renintech.com);
	by webmail.hamarashehar.com with HTTP;
	Wed, 7 Dec 2005 09:22:10 -0600 (CST)
Message-ID: <1090.202.63.110.45.1133968930.squirrel@webmail.hamarashehar.com>
Date: Wed, 7 Dec 2005 09:22:10 -0600 (CST)
To: sip-request@ietf.org, sip@ietf.org
User-Agent: SquirrelMail/1.4.3a-11.EL3
X-Mailer: SquirrelMail/1.4.3a-11.EL3
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 1 (Highest)
Importance: High
X-Virus-Scanned: by amavisd-new at hamarashehar.com
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.8 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] SIP on Mobile
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

  Is it possible for JSR 180 client to communicate with Jain SIP Stack. I=
f
it is possible anyone please someone help me out on how to achieve it.

Thanking in Advance.

Santosh.



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 11:23:18 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek24b-0001j4-Vu; Wed, 07 Dec 2005 11:23:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek24a-0001iK-3B; Wed, 07 Dec 2005 11:23:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25522;
	Wed, 7 Dec 2005 11:22:22 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Ek2QI-0005jj-M0; Wed, 07 Dec 2005 11:45:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Dec 2005 17:23:52 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX7K+OV505wavEbRymxIc1sIbE0oQAHrk1p
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Thanx Klaus

Also for answering a question I did not (yet) ask
regarding redirect vs proxy


>I personally prefer relaying instead of redirect.

Me too and I see your arguments.
Are there any arguments out there why to prefer redriect?
=20
Richard

________________________________

Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Mi 07.12.2005 13:39
An: Stastny Richard
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try



Hi Richard!

comments inline

Stastny Richard wrote:
> Should Infrastructure ENUM contain a routing information
> to the next hop only (the ingress border element of Provider B
> (or administrative domain B)
> or simply a mapping from an E.164 number to an AoR?

IMHO it should be a mapping to an AoR as in user ENUM.

> I will try to give another example and start from
...
> I subscribe with provider B and get a default public
> user identity (AoR) from this provider:
> e.g. sip:foo@provB.net
>
> This "foo" can be anything the provider chooses it to be:
> e.g. an alphanumeric string such as ywzabcd,
> a numeric string such as 16241 (my FWD number)
> or 019793321 or 4319793321
>
> Any other provider A having a peering agreement
> with Provider B must be able to route a SIP call
> given this SIP AoR to provider B, either to the
> SIP proxy hosting this account or at least to
> the ingress proxy(s) in provider B network.
>
> On way to do so is to use SRV records within
> the zone of provB.net pointing to e.g
>
> ingress14.provB.net
> and
> ingress21.provB.net
>
> Question: is this correct?

IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net

> Note: after the ingress proxy provider B
> may use another mapping mechanism to find
> the real hosting server e.g. srv21.provB.net
>
> Now I as a user are not happy with this default
> public user identity, I want to have some aliases
>
> eg:
> 1)sip:richard@stastny.com and
> 2) +43 1 9793321
>
> In case 1) I assume that provider B needs
> to provide me with redirect server(s), and I
> need to enter in stastny.com SRV records
> to point to these redirect servers
> e.g. redirect.provB.net
>
> sip:richard.stastny.com is redirected to
> sip:foo@provB.net
>
> Question: is this correct?

This is a working scenario. But a redirect server is not mandatory. It
may also be a proxy which forwards the request "INVITE
sip:richard.stastny.com" to "INVITE sip:foo@provB.net".

It is also possbile that SRV for stastny.com points directly to
ingress12.provB.net and ingress12 knows about all hosted SIP domains and
knows how to forward the request to the end user.

But this is a design decision of the provB and IMO should be out of
scope of SPEERMINT. provB may use redirect server, provC may accept all
hosted SIP domains directly on their ingress points, .....

I personally prefer relaying instead of redirect. E.g. redirect raises
questions like: How should intercept the redirect response and forward
to the new URI? The UA client or the SIP proxy of provA or the egress =
proxy?

The important thing is that the originator (provA) should not have to
take care how provB implemented the hosting of SIP domains.

> In case 2) we need Infrastructure ENUM
> [Side note; in my user ENUM I would either enter
> sip:richard@stastny.com or sip:foo@provB.net
> this is my choice]
>
> Now the question is: what goes into Infrastructure
> ENUM for say +4319793321?
>
> Is it:
> Sip:foo@provB.net (if plain sip:foo@provB.net works
> this must also work)
> OR
> sip:+4319793321@provB.net;user=3Dphone (correct?)
> OR
> sip:+4319793321@provB.net (wrong?)
> OR
> sip:4319793321@provB.net (valid only if 4319793321 =3D foo)
>
> OR is it
> sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
> AND
> sip:+4319793321@ingress21.provB.net;user=3Dphone

IMO all of these are valid. It's up to the choice of provB. provB can
put anything into ENUM as long as provB is able to map from the URI in
I-ENUM to the end user.

If I would design the network for provB, I would use version 2 (without
user=3Dphone as the user are not limited to phones).

> In this last case one would not need to query the
> SRV records in provB.net

Also in the last case (if beeing conform with RFC3263), the egress proxy
has to perform NAPTR and SRV lookups. If you want to avoid them, just
put the IP address or the port into the host part, e.g.

sip:+4319793321@ingress21.provB.net:5060;user=3Dphone

regards
klaus



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 11:27:31 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek28h-0002xq-1r; Wed, 07 Dec 2005 11:27:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek28f-0002wF-In; Wed, 07 Dec 2005 11:27:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25823;
	Wed, 7 Dec 2005 11:26:36 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Ek2UO-0005te-Mq; Wed, 07 Dec 2005 11:49:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Dec 2005 17:27:27 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX7K+OV505wavEbRymxIc1sIbE0oQAHzluu
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Klaus wrote:
>If I would design the network for provB, I would use version 2 (without
>user=3Dphone as the user are not limited to phones).
You mean:
> sip:+4319793321@provB.net;user=3Dphone=20
=20
IMHO this does not imply that the user uses a phone,
it implies that the user-part is a Tel URI !
=20
=20
Richard



________________________________

Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Mi 07.12.2005 13:39
An: Stastny Richard
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try



Hi Richard!

comments inline

Stastny Richard wrote:
> Should Infrastructure ENUM contain a routing information
> to the next hop only (the ingress border element of Provider B
> (or administrative domain B)
> or simply a mapping from an E.164 number to an AoR?

IMHO it should be a mapping to an AoR as in user ENUM.

> I will try to give another example and start from
...
> I subscribe with provider B and get a default public
> user identity (AoR) from this provider:
> e.g. sip:foo@provB.net
>
> This "foo" can be anything the provider chooses it to be:
> e.g. an alphanumeric string such as ywzabcd,
> a numeric string such as 16241 (my FWD number)
> or 019793321 or 4319793321
>
> Any other provider A having a peering agreement
> with Provider B must be able to route a SIP call
> given this SIP AoR to provider B, either to the
> SIP proxy hosting this account or at least to
> the ingress proxy(s) in provider B network.
>
> On way to do so is to use SRV records within
> the zone of provB.net pointing to e.g
>
> ingress14.provB.net
> and
> ingress21.provB.net
>
> Question: is this correct?

IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net

> Note: after the ingress proxy provider B
> may use another mapping mechanism to find
> the real hosting server e.g. srv21.provB.net
>
> Now I as a user are not happy with this default
> public user identity, I want to have some aliases
>
> eg:
> 1)sip:richard@stastny.com and
> 2) +43 1 9793321
>
> In case 1) I assume that provider B needs
> to provide me with redirect server(s), and I
> need to enter in stastny.com SRV records
> to point to these redirect servers
> e.g. redirect.provB.net
>
> sip:richard.stastny.com is redirected to
> sip:foo@provB.net
>
> Question: is this correct?

This is a working scenario. But a redirect server is not mandatory. It
may also be a proxy which forwards the request "INVITE
sip:richard.stastny.com" to "INVITE sip:foo@provB.net".

It is also possbile that SRV for stastny.com points directly to
ingress12.provB.net and ingress12 knows about all hosted SIP domains and
knows how to forward the request to the end user.

But this is a design decision of the provB and IMO should be out of
scope of SPEERMINT. provB may use redirect server, provC may accept all
hosted SIP domains directly on their ingress points, .....

I personally prefer relaying instead of redirect. E.g. redirect raises
questions like: How should intercept the redirect response and forward
to the new URI? The UA client or the SIP proxy of provA or the egress =
proxy?

The important thing is that the originator (provA) should not have to
take care how provB implemented the hosting of SIP domains.

> In case 2) we need Infrastructure ENUM
> [Side note; in my user ENUM I would either enter
> sip:richard@stastny.com or sip:foo@provB.net
> this is my choice]
>
> Now the question is: what goes into Infrastructure
> ENUM for say +4319793321?
>
> Is it:
> Sip:foo@provB.net (if plain sip:foo@provB.net works
> this must also work)
> OR
> sip:+4319793321@provB.net;user=3Dphone (correct?)
> OR
> sip:+4319793321@provB.net (wrong?)
> OR
> sip:4319793321@provB.net (valid only if 4319793321 =3D foo)
>
> OR is it
> sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
> AND
> sip:+4319793321@ingress21.provB.net;user=3Dphone

IMO all of these are valid. It's up to the choice of provB. provB can
put anything into ENUM as long as provB is able to map from the URI in
I-ENUM to the end user.

If I would design the network for provB, I would use version 2 (without
user=3Dphone as the user are not limited to phones).

> In this last case one would not need to query the
> SRV records in provB.net

Also in the last case (if beeing conform with RFC3263), the egress proxy
has to perform NAPTR and SRV lookups. If you want to avoid them, just
put the IP address or the port into the host part, e.g.

sip:+4319793321@ingress21.provB.net:5060;user=3Dphone

regards
klaus



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 14:50:10 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek5Io-0006bN-3R; Wed, 07 Dec 2005 14:50:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek5Ik-0006Y7-S8; Wed, 07 Dec 2005 14:50:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19261;
	Wed, 7 Dec 2005 14:49:14 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek5eU-00050N-VI; Wed, 07 Dec 2005 15:12:35 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2005 11:49:56 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,226,1131350400"; 
	d="scan'208"; a="16795355:sNHT28643328"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB7JnR4t000270; 
	Wed, 7 Dec 2005 14:49:53 -0500 (EST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 14:49:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIP AoR, tel and ENUM
Date: Wed, 7 Dec 2005 14:49:05 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA080A@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX7CP/OGhXFobDjTDK4lvWZXNCGcQAXeDow
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 07 Dec 2005 19:49:06.0042 (UTC)
	FILETIME=[48238DA0:01C5FB67]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 00134749b78ab2213964fc53d03de937
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I don't have issues with what you have said.  I was trying to discover
what was objectionable in what I had said, but thre doesn't seem to be
anything.

Mike
=20

> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20
> Sent: Wednesday, December 07, 2005 3:33 AM
> To: Michael Hammer (mhammer)
> Cc: Stastny Richard; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; sip@ietf.org
> Subject: Re: [Sip] SIP AoR, tel and ENUM
>=20
> Hi Michael!
>=20
> As there are some concerns about the terminology. Thus I will=20
> use AD (adminsitrative domain, from the SPEERMINT charter) as=20
> synonym for ITSP, carrier, telco, VoIP enabled enterprise .....
>=20
> Michael Hammer (mhammer) wrote:
> > Klaus,
> >=20
> > It has to do with the difference between re-targeting and=20
> routing.  Is=20
> > the point of interconnect the real target of the request or just a=20
> > waypoint in the route to get to the target?  In the User=20
> ENUM case, it=20
> > seems as though the addresses are all about the target=20
> users and their=20
> > devices.  But, here it seemed a bit different.  It is a=20
> route through=20
> > an intermediate point.  It seems like the semantic and syntactical=20
> > element would be more coherent and no more complicated. =20
> Thus, I posed=20
> > the question.
>=20
> I can not really see a difference to user ENUM. There is only=20
> one Infrastructure ENUM tree. Thus, all ADs which query this=20
> tree will get the same URI back from ENUM. Thus, the ingress=20
> point announced by the receiving AD is the same for all outgoing ADs.
>=20
> Further, if the outgoing AD does not send the request=20
> directly to the announced ingress point (maybe no peering=20
> relationship), but to an intermediate point (transit=20
> provider, clearinghouse, ....), this routing is different for=20
> each AD. Thus, such kind of routing information can not be in ENUM.
>=20
> Once the request reaches the ingress point of the receiving=20
> AD, there will be further routing inside the receiving AD.=20
> Maybe the route is for
> example:
>   1. ingresspoint1.ad
>   2. accountingbox.ad
>   3. mainproxy.ad
>   4. .....
>=20
> Publishing such a route in ENUM makes no sense, as the route=20
> is the same for all incoming requests. Thus, the route should=20
> be applied by the previous hop. That means, ingresspoint1.ad=20
> knows that it should formward to accountingbox.ad, and so on.
>=20
> IMO, ENUM is a simple routing and re-targeting in one step.=20
> If complex re-routing and re-targeting is required it should=20
> be done by the receiving AD. The outoing AD is not interested=20
> in the internal routing of the receiving AD.
>=20
> Maybe you can give me an example of a scenario were my model=20
> does not fit.
>=20
> regards
> klaus
>=20
>=20
>=20
> >=20
> > Mike
> >=20
> >=20
> >=20
> >>-----Original Message-----
> >>From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> >>Sent: Tuesday, December 06, 2005 11:48 AM
> >>To: Stastny Richard
> >>Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20
> >>enum@ietf.org; sip@ietf.org
> >>Subject: Re: [Sip] SIP AoR, tel and ENUM
> >>
> >>Stastny Richard wrote:
> >>
> >>>Mike wrote:
> >>>
> >>>
> >>>
> >>>>Before going down this path too far, can we ask where the
> >>
> >>results of
> >>
> >>>>the ENUM queries will go in the SIP message to control routing?
> >>>>Hypothetically, the egress and ingress gateways could be
> >>
> >>identified in
> >>
> >>>>Route headers rather than in the Request-URI.  An=20
> external ENUM dip=20
> >>>>and an internal ENUM dip might lead to something along=20
> the lines of:
> >>>
> >>>=20
> >>>Correct,
> >>>=20
> >>>Jonathan proposed this some time ago, but this thread somewhere=20
> >>>stranded
> >>>=20
> >>>So basically an interneal ENUM entry of
> >>>
> >>>sip:+1777555111@egress.provider3.com;user=3Dphone
> >>>=20
> >>>would result in
> >>>
> >>>INVITE tel:+17775551111 SIP/2.0
> >>>...
> >>>Route: <sip:egress11.provider3.com;lr>
> >>>=20
> >>>an the external ENUM entry would be
> >>>sip:+1777555111@provider17.com
> >>>=20
> >>>result in
> >>>Route: <sip:ingress39.provider17.com;lr>
> >>>=20
> >>>This is basically what I am after
> >>>...
> >>>
> >>
> >>Hi folks.
> >>
> >>What is the benefit of splitting the ENUM result (the SIP
> >>URI) into a Route header and into a request URI?
> >>
> >>IMO there should be no semantic for the internal routing=20
> (the routing=20
> >>from the main proxy to the egress proxy). This should be=20
> out of scope=20
> >>of all WGs. Also the internal routing of the ingress=20
> provider should=20
> >>be out of scope. The ingress provider should have SIP URI=20
> which can be=20
> >>used to address its customers.
> >>
> >>If this URI is sip:431505641636@in.mydomain.com or=20
> >>foobar666@in.mydomain.com, or=20
> sip:klaus.darilion@mydomain.com is the=20
> >>ingress provider's choice. Maybe the ingress provider also=20
> allows all=20
> >>of the previous SIP URIs to reach a certain user. The incoming=20
> >>provider just has to make sure that these SIP URIs map to the=20
> >>corresponding user (to the user's AoR).
> >>If this user also has an E.164 number which is in I-ENUM, then it's=20
> >>again the ingress provider's choice which URI to put into the NAPTR.
> >>
> >>IMO there should not not be any semantics how to create a=20
> request URI=20
> >>and a pre-loaded route set of the SIP URI received from ENUM. The=20
> >>egress proxy sends the request to the ingress proxy in the format=20
> >>choosen by the ingress provider (e.g. publish via ENUM or=20
> an business=20
> >>cards).
> >>
> >>We should not complicate things. I do not see any problems=20
> with this=20
> >>simple approach. If there are some problems, please correct me.
> >>
> >>regards
> >>klaus
> >>
> >>
> >>
> >>
> >>>>I am also suggesting that the ENUM result be an AoR, since
> >>
> >>one might
> >>
> >>>>want some reliability in choosing which server in the
> >>
> >>gateway cluster
> >>
> >>>>to go to based on further DNS queries, load balancing, etc.
> >>>
> >>>=20
> >>>Now this is in contradiction to the above
> >>>=20
> >>>Richard
> >>>
> >>>
> >>>
> >>>>Mike
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
> >>
> >>Behalf Of
> >>
> >>>>Stastny Richard
> >>>>Sent: Tuesday, December 06, 2005 4:54 AM
> >>>>To: voipeer@lists.uoregon.edu
> >>>>Cc: enum@ietf.org; sip@ietf.org
> >>>>Subject: [Sip] SIP AoR, tel and ENUM
> >>>>
> >>>>Folks,
> >>>>
> >>>>This post is primarily to SPEER, but since it also concerns
> >>
> >>ENUM and
> >>
> >>>>SIP I cross-post it.
> >>>>
> >>>>I need (urgently) some guidance on the question what SIP
> >>
> >>URIs to use
> >>
> >>>>in Infrastructure ENUM.
> >>>>
> >>>>User ENUM as defined in RFC 3761 provides a mapping from
> >>>>E.164 numbers to SIP URIs for primarily for end-users. So
> >>
> >>what you get
> >>
> >>>>back is the AoR pointing to the destination SIP server.
> >>>>
> >>>>If you get something back on the ENUM query such as=20
> >>>>sip:Richard@stastny.com, this is definetely an AoR. Because
> >>
> >>of privacy
> >>
> >>>>reasons, more and more people start using SIP URI such as=20
> >>>>sip:4319793321@provider.net or (an AoR)=20
> >>>>sip:+4319793321@provider.net;user=3Dphone (IMHO not an AoR) or =
even=20
> >>>>sip:+4319793321@provider.net
> >>>>
> >>>>IMHO the last one should not be used, and some guidance is
> >>
> >>also needed
> >>
> >>>>here. but it only concerns the destination server and if the=20
> >>>>destination servers can deal with it, fine.
> >>>>
> >>>>Now with Infrastructure ENUM (and especially in combination with=20
> >>>>private ENUMs) the situation is different.
> >>>>
> >>>>The purpose of Infrastructure ENUM is according to the=20
> re-chartered=20
> >>>>ENUM WG "to discover points of interconnection necessary to
> >>
> >>terminate
> >>
> >>>>communications sessions identified by a E164 number, in=20
> addition to=20
> >>>>identifying end point protocols and services."
> >>>>
> >>>>This translates to: Infrastructure ENUM does not
> >>
> >>necessarily contain
> >>
> >>>>end-point information (AoR), but routing information.
> >>>>Routing, in my definition here, is basically to provide you
> >>
> >>with the
> >>
> >>>>information what the next hop is.
> >>>>
> >>>>A very common scenario is the following one: a walled
> >>
> >>garden network
> >>
> >>>>is using private ENUM to detect the border element for a
> >>
> >>given number,
> >>
> >>>>Some border element may lead to another private=20
> (extranet), using a=20
> >>>>federated ENUM for this number, another may be connected to the=20
> >>>>Internet using public Infrastructure ENUM for another number.
> >>>>Public Infrastructure ENUM is giving back the ingress
> >>
> >>border element,
> >>
> >>>>which in turn uses private ENUM again to find the SIP
> >>
> >>server hosting
> >>
> >>>>the user with this number.
> >>>>
> >>>>In addition, again for privacy reasons, in most cases the above=20
> >>>>mentioned SIP URIs containing E.164 numbers are used.
> >>>>
> >>>>This raises two issues, an architectural one and a BCP one:
> >>>>
> >>>>To principally different scenarios are possible
> >>>>
> >>>>Scenario A
> >>>>
> >>>>ENUM is providing ONLY the mapping from the E.164 number to
> >>
> >>an AoR. (=3D
> >>
> >>>>name to address mapping) The above described routing between the=20
> >>>>networks to find the destination network is done via the
> >>
> >>AoR. How this
> >>
> >>>>is done is completely within the scope of SPEER.
> >>>>
> >>>>Note: this is the only future proof way, because a user=20
> may use the=20
> >>>>AoR in the first place and then the routing MUST work
> >>
> >>anyway. So any
> >>
> >>>>additional routing information in ENUM would be duplicated and=20
> >>>>therefore error-prone.
> >>>>
> >>>>I propose in addition to use in this case a SIP in the format=20
> >>>>sip:4319793321@provider.net, to clearly indicate that this has no=20
> >>>>relationship to an E.164 number.
> >>>>
> >>>>Scenario B:
> >>>>
> >>>>This is the scenario proposed in most current
> >>
> >>implementations and also
> >>
> >>>>in the RFI on ENUM popping up everywhere. The reason is that most=20
> >>>>scenarios currently concentrate solely on the peering with E.164=20
> >>>>numbers and completely forget the peering with SIP URIs
> >>>>
> >>>>The ENUM entry is giving you the next hop: This is in case of the=20
> >>>>walled garden originating network either the server hosting the=20
> >>>>end-user or the egress border element (e.g. IBCF, THIG, or=20
> >>>>whatchamacallit). This element is again querying another
> >>
> >>kind of ENUM,
> >>
> >>>>getting back the ingress border element of the destination
> >>
> >>network (or
> >>
> >>>>even of a "transit" L5 network), and so on. The ingress
> >>
> >>border element
> >>
> >>>>is the again calling its private ENUM to finally find the hosting=20
> >>>>server.
> >>>>
> >>>>Note: I have a sub-question here: Some implementations are even=20
> >>>>proposing here to skip the SRV query and directly pointing
> >>
> >>to the SIP
> >>
> >>>>server(s) in ENUM. Does this make sense?
> >>>>
> >>>>If this scenario is used, I propose to use only SIP URIs in
> >>
> >>the format
> >>
> >>>>sip:+4319793321@provider.net;user=3Dphone or better=20
> >>>>SIP:+4319793321@sbc.prov.net; user=3Dphone
> >>>>
> >>>>to clearly indicate that this is still basically a
> >>>>tel: URI combined with a routing info and that it may be used in=20
> >>>>another ENUM query.
> >>>>
> >>>>My questions to the crowd are the following:
> >>>>
> >>>>1. is this proposed use of SIP URIs within the context of ENUM ok?
> >>>>
> >>>>2. What should be the preferred scenario for VoIP peering?
> >>>>Is some kind of combination between the scenarios feasible?
> >>>>And what are the arguments pro and con?
> >>>>
> >>>>I consider the outcome of this discussion as substantial
> >>
> >>input to the
> >>
> >>>>deliverables of SPEER, but some first guidance is=20
> urgently required=20
> >>>>now, because many entities are making basic decisions in this=20
> >>>>direction NOW.
> >>>>
> >>>>Please also excuse and correct incorrect use of terminology.
> >>>>
> >>>>Regards
> >>>>Richard Stastny
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>>>This list is for NEW development of the core SIP Protocol Use=20
> >>>>sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>>>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=20
> >>>sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>>sipping@ietf.org for new developments on the application of sip
> >>>
> >>>
> >>
> >=20
> >=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 15:23:35 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek5p9-0007Fj-B8; Wed, 07 Dec 2005 15:23:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek5p6-0007DV-NQ; Wed, 07 Dec 2005 15:23:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22515;
	Wed, 7 Dec 2005 15:22:40 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek6As-00068b-2D; Wed, 07 Dec 2005 15:46:02 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 12:23:23 -0800
X-IronPort-AV: i="3.99,226,1131350400"; 
	d="scan'208"; a="375315478:sNHT1282961368"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB7KM5Bt017107;
	Wed, 7 Dec 2005 12:23:19 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 15:23:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Wed, 7 Dec 2005 15:23:06 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA082B@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3g
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "James Polk \(jmpolk\)" <jmpolk@cisco.com>, <henry@pulver.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 07 Dec 2005 20:23:07.0752 (UTC)
	FILETIME=[0917C680:01C5FB6C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

James,

This is d=E9j=E0 vu from the FG-NGN discussion on the exact same topic.  =
I have no issues with making distinctions of this type.  It was just not =
clear to me which of these various types (or the ones that Henry =
mentions) was in scope or not, but that seemed secondary to the point =
being made at the time that had to do with what the X entity did with an =
ENUM response that affected the constraints on what could be contained =
in such responses.

Mike


> -----Original Message-----
> From: James Polk (jmpolk)=20
> Sent: Tuesday, December 06, 2005 8:11 PM
> To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Mike
>=20
> This seems to be creeping into more than one WG at about the=20
> same time.
>=20
> ISP used to be (roughly) the company you or you employer=20
> bought service from to gain access to the Internet.  Now that=20
> is a little too generic for a lot of people's tastes as there=20
> are different SPs that an individual many have now that=20
> weren't available not so long ago.  Hence the recent push to=20
> separate them somehow.
>=20
> Application Providers, to me, include a Vonage for Voice=20
> services, and a Yahoo for IM.
>=20
> Service Providers or Internet Providers, to me, connect one=20
> to the Internet for L3 access
>=20
> Access Providers, to me, are the organizations like the DSL=20
> and Cable and WiFi connectivity providers.
>=20
> Often times, to me, the Internet Providers and the Access=20
> Providers are either the same company - while perhaps=20
> different divisions, but they can be totally different companies too.
>=20
> The separation I'm seeing is between the organization that=20
> gives you you Internet access and the organizations that=20
> provider you with all the services required for a particular=20
> application - such as Voice or Video.
>=20
> Everything used to be best effort, and services were either=20
> at your device or at the provider's server.  Now there's an=20
> overlay at layer 7 (typically) and we're struggling with how=20
> to name and describe it.
>=20
>=20
>=20
> At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> >My looking glass is smudged today.
> >
> >What does one call a provider of service?
> >I don't understand the aversion to service provider.
> >
> >I thought it was only the "carrier" word that invoked regulatory=20
> >burdens (or PATS!).  I'd rather leave legal word games to=20
> lawyers and lobbyists.
> >
> >Mike
> >
> >
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry@pulver.com]
> > > Sent: Tuesday, December 06, 2005 5:30 PM
> > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; 'Stastny=20
> > > Richard'
> > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > Sorry for nitpicking:
> > >
> > > >A provider is a provider.
> > >
> > > A provider is a business model and att/SBC may differ from Google=20
> > > who uses a different business model (which is more significant=20
> > > measured in $$$?).
> > >
> > > Didn't we agree to use the term "Internet domain owner" (we could=20
> > > shorten to IDOM or such)?
> > >
> > > Internet domains are well defined in the IETF.
> > > Business models for VoIP are better suited for other=20
> organizations,=20
> > > consortia or innovators who work to disrupt them :-)
> > >
> > > Thanks, Henry
> > >
> > > -----Original Message-----
> > > From: owner-voipeer@lists.uoregon.edu=20
> > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20
> Michael Hammer
> > > (mhammer)
> > > Sent: Tuesday, December 06, 2005 3:36 PM
> > > To: Thilo Salmon; Klaus Darilion
> > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; Stastny=20
> > > Richard
> > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > I am having trouble parsing these statements.
> > >
> > > A provider is a provider.  I used the terms ingress and egress to=20
> > > indicate some server that sits on the edge of a=20
> provider's network=20
> > > and does peering to some other provider.
> > > The usage below seems to mix egress with originating being the=20
> > > network where the caller is attached.
> > >
> > > I was noting that the called party terminal and the interconnect=20
> > > points were different hosts and therefore may have different=20
> > > identities.  To keep maximum flexibility, the format of those=20
> > > identities would need to be fully under the control of=20
> the domain of=20
> > > each provider.  However, conflating all that into a single URI in=20
> > > the Request-URI seemed constraining to me.  Having three URIs in=20
> > > separate headers seemed the most flexible.
> > >
> > > Splitting.  I don't understand what got split or how.  ENUM
> > > -- Tel:URI in, Point-of-interconnect URI out.  Put in=20
> Route header. =20
> > > I only suggested that there might be two route headers=20
> because the=20
> > > terminating provider would indicate in ENUM, to get to this=20
> > > end-user, go to this entrance first.
> > > But, to get to that entrance, the originating provider needs to=20
> > > determine what the corresponding exit point is from his network,=20
> > > i.e. another Route header.  The format and content of=20
> that URI is up=20
> > > to each provider.  The advertised entrance point is I think by=20
> > > definition the (Inter-) Carrier ENUM.
> > > The internal determination of the exit point could be termed
> > > (Intra-) Carrier ENUM.  Maybe peering is concerned only with the=20
> > > inter-carrier aspect.
> > >
> > > The Request-URI could be a normalized public identity of the user=20
> > > totally independent of interconnect naming schemes.  I was just=20
> > > teasing out what are the assumptions and constraints in=20
> the original=20
> > > email.
> > >
> > > Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > > To: Klaus Darilion
> > > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > > voipeer@lists.uoregon.edu;
> > > > enum@ietf.org; Stastny Richard
> > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > >
> > > > Richard, Klaus, et al.
> > > >
> > > > Apparently, I have missed an important developlement lately.
> > > >
> > > > > What is the benefit of splitting the ENUM result (the SIP
> > > > URI) into a
> > > > > Route header and into a request URI?
> > > > [...]
> > > > > IMO there should be no semantic for the internal routing
> > > > (the routing
> > > > > from the main proxy to the egress proxy). This should be
> > > > out of scope
> > > > > of all WGs. Also the internal routing of the ingress
> > > > provider should
> > > > > be out of scope. The ingress provider should have SIP URI
> > > > which can be
> > > > > used to address its customers.
> > > >
> > > > I absolutely second that statement. If for any reason=20
> (we all have=20
> > > > enough a vivid enough phantasy to imagine a good reason, I
> > > suppose) an
> > > > ingress provider wishes to feed a different set of SIP URIs to=20
> > > > each and every of his egress partners, he should not be=20
> stripped=20
> > > > of this option.
> > > > The scenario I have in mind is one in which an ingress provider=20
> > > > chooses to encrypt the user part of all his SIP URIs with a key=20
> > > > uniquely assigns to his egress partner.
> > > >
> > > > Just as Klaus I feel this complicates things and takes
> > > authority over
> > > > internal adressing away from the ingress provider for no reason=20
> > > > apparent (to me).
> > > >
> > > > Thilo
> > > >
> > >
> > > ______________________________________________________________
> > > ______________
> > > _
> > > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > >
> > >
> >
> >_____________________________________________________________
> __________
> >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
>=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 18:28:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek8iG-0000ni-GN; Wed, 07 Dec 2005 18:28:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8iF-0000nc-6H
	for sip@megatron.ietf.org; Wed, 07 Dec 2005 18:28:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16300
	for <sip@ietf.org>; Wed, 7 Dec 2005 18:27:47 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek941-0005XU-EK for sip@ietf.org; Wed, 07 Dec 2005 18:51:10 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-1.cisco.com with ESMTP; 07 Dec 2005 15:28:29 -0800
X-IronPort-AV: i="3.99,227,1131350400"; 
	d="scan'208"; a="682548923:sNHT30791032"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB7NS1Qg011206;
	Wed, 7 Dec 2005 15:28:27 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 15:28:22 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.88.254]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 15:28:22 -0800
Message-Id: <4.3.2.7.2.20051207171954.02adf928@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 07 Dec 2005 17:28:21 -0600
To: MonicaIngudam@aol.com
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <21d.4f3c202.30c8c453@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 07 Dec 2005 23:28:22.0339 (UTC)
	FILETIME=[E9E72930:01C5FB85]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org
Subject: [Sip] Re: Info required for transporting LK (Location Key)
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Monica

I've changed WG lists here because this document moved from the SIPPING WG 
to the SIP WG last winter. The current document is here:
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-01.txt

and it does not support a location key, per se.

It proposes conveyance of:

#1 - Location-by-value (the PIDF-LO message body in the message), and

#2 - Location-by-Reference (a URI to a record on a server that has the 
PIDF-LO for that UA)

The next version of the document will not be published until at least 
January 06.

We have a goal of having this document ready (i.e. done) for IESG review by 
May 06.


At 06:03 PM 12/7/2005 -0500, MonicaIngudam@aol.com wrote:
>All,
>
>NENA refers to draft-ietf-sipping-location-requirements-02 for 
>transporting the location or location key. This draft seems to refer 
>details on LO. This draft seems to have expired on 25th October 2004. 
>Please refer me to the latest document available. I am interested in 
>transporting LK (Location Key). Is there any specific header or tag 
>defined to carry LK ? Any pointers to this question will be helpful.
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>Thanks & Regards
>Monica Ingudam

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 18:34:19 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek8nj-0002T5-KT; Wed, 07 Dec 2005 18:34:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8ni-0002T0-CD
	for sip@megatron.ietf.org; Wed, 07 Dec 2005 18:34:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16937
	for <sip@ietf.org>; Wed, 7 Dec 2005 18:33:27 -0500 (EST)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek99U-0005kU-NY
	for sip@ietf.org; Wed, 07 Dec 2005 18:56:50 -0500
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 17:33:57 -0600
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Wed, 07 Dec 2005 17:33:56 -0600
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 17:33:56 -0600
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC10485BC0@aopex5.andrew.com>
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "James M. Polk" <jmpolk@cisco.com>, <MonicaIngudam@aol.com>
Date: Wed, 7 Dec 2005 17:33:55 -0600
Subject: RE: [Sip] Re: Info required for transporting LK (Location Key)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 07 Dec 2005 23:33:56.0105 (UTC)
	FILETIME=[B0D7CF90:01C5FB86]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: [Sip] Re: Info required for transporting LK (Location Key)
Thread-Index: AcX7hifQOsrqVssqQKyNHXDusPusQgAAG7GQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Just to be clear.
A location-Key (LK) as described in the NENA i2 specification is a
location-by-reference.

Cheers
James

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
> James M. Polk
> Sent: Thursday, 8 December 2005 10:28 AM
> To: MonicaIngudam@aol.com
> Cc: sip@ietf.org
> Subject: [Sip] Re: Info required for transporting LK (Location Key)
>=20
> Monica
>=20
> I've changed WG lists here because this document moved from the
SIPPING WG
> to the SIP WG last winter. The current document is here:
>
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-
> 01.txt
>=20
> and it does not support a location key, per se.
>=20
> It proposes conveyance of:
>=20
> #1 - Location-by-value (the PIDF-LO message body in the message), and
>=20
> #2 - Location-by-Reference (a URI to a record on a server that has the
> PIDF-LO for that UA)
>=20
> The next version of the document will not be published until at least
> January 06.
>=20
> We have a goal of having this document ready (i.e. done) for IESG
review
> by
> May 06.
>=20
>=20
> At 06:03 PM 12/7/2005 -0500, MonicaIngudam@aol.com wrote:
> >All,
> >
> >NENA refers to draft-ietf-sipping-location-requirements-02 for
> >transporting the location or location key. This draft seems to refer
> >details on LO. This draft seems to have expired on 25th October 2004.
> >Please refer me to the latest document available. I am interested in
> >transporting LK (Location Key). Is there any specific header or tag
> >defined to carry LK ? Any pointers to this question will be helpful.
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
> >Thanks & Regards
> >Monica Ingudam
>=20
> _______________________________________________
> 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

---------------------------------------------------------------------------=
---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information. =20
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------=
---------------------
[mf2]

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 18:49:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek92W-0006NG-I7; Wed, 07 Dec 2005 18:49:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek92V-0006N8-IV
	for sip@megatron.ietf.org; Wed, 07 Dec 2005 18:49:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18528
	for <sip@ietf.org>; Wed, 7 Dec 2005 18:48:44 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek9OJ-0006B0-0o for sip@ietf.org; Wed, 07 Dec 2005 19:12:07 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 15:49:06 -0800
X-IronPort-AV: i="3.99,227,1131350400"; 
	d="scan'208"; a="375408758:sNHT6424576960"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB7NmUQm022030;
	Wed, 7 Dec 2005 15:49:02 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 15:49:01 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.88.254]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 15:49:01 -0800
Message-Id: <4.3.2.7.2.20051207174707.0295ab38@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 07 Dec 2005 17:48:59 -0600
To: "Winterbottom, James" <James.Winterbottom@andrew.com>,
	<MonicaIngudam@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Sip] Re: Info required for transporting LK (Location Key)
In-Reply-To: <AF9FCF3C02DB264EAF9872DFB6040FCC10485BC0@aopex5.andrew.com
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 07 Dec 2005 23:49:01.0315 (UTC)
	FILETIME=[CC63E530:01C5FB88]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

At 05:33 PM 12/7/2005 -0600, Winterbottom, James wrote:
>Just to be clear.
>A location-Key (LK) as described in the NENA i2 specification is a
>location-by-reference.

that's why I said "per se", as the LK wasn't always described as a URI, but 
of a sequence or string instead.  A URI has a known-to-many base structure.


>Cheers
>James
>
> > -----Original Message-----
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
> > James M. Polk
> > Sent: Thursday, 8 December 2005 10:28 AM
> > To: MonicaIngudam@aol.com
> > Cc: sip@ietf.org
> > Subject: [Sip] Re: Info required for transporting LK (Location Key)
> >
> > Monica
> >
> > I've changed WG lists here because this document moved from the
>SIPPING WG
> > to the SIP WG last winter. The current document is here:
> >
>http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-
> > 01.txt
> >
> > and it does not support a location key, per se.
> >
> > It proposes conveyance of:
> >
> > #1 - Location-by-value (the PIDF-LO message body in the message), and
> >
> > #2 - Location-by-Reference (a URI to a record on a server that has the
> > PIDF-LO for that UA)
> >
> > The next version of the document will not be published until at least
> > January 06.
> >
> > We have a goal of having this document ready (i.e. done) for IESG
>review
> > by
> > May 06.
> >
> >
> > At 06:03 PM 12/7/2005 -0500, MonicaIngudam@aol.com wrote:
> > >All,
> > >
> > >NENA refers to draft-ietf-sipping-location-requirements-02 for
> > >transporting the location or location key. This draft seems to refer
> > >details on LO. This draft seems to have expired on 25th October 2004.
> > >Please refer me to the latest document available. I am interested in
> > >transporting LK (Location Key). Is there any specific header or tag
> > >defined to carry LK ? Any pointers to this question will be helpful.
> > >
> > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>- -
> > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>- -
> > >Thanks & Regards
> > >Monica Ingudam
> >
> > _______________________________________________
> > 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
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 18:52:35 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek95P-00076c-0E; Wed, 07 Dec 2005 18:52:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ek95M-00075u-BQ; Wed, 07 Dec 2005 18:52:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18942;
	Wed, 7 Dec 2005 18:51:40 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ek9R8-0006Jw-Pb; Wed, 07 Dec 2005 19:15:03 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	jB7Nmqx05052; Wed, 7 Dec 2005 18:48:52 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIP AoR, tel and ENUM - Second Try
Date: Wed, 7 Dec 2005 18:51:54 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA3086FC261@zcarhxm0.corp.nortel.com>
Thread-Topic: [Sip] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsAAZVNyQ
From: "James McEachern" <jmce@nortel.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <sip@ietf.org>,
	<voipeer@lists.uoregon.edu>, <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: quoted-printable
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Richard,
It seems to me there are two basic options here, both of which are =
roughly equivalent.

1. I-ENUM contains an AoR, (probably in a format like =
sip:+4319793321@provB.net;user=3Dphone, rather than something like =
sip:richard@stastny.com, to protect user privacy).  The SRV records for =
provB could then point to ingress14.provB.net and ingress21.provB.net.

OR

2. I-ENUM contains "sip:+4319793321@ingress14.provB.net;user=3Dphone" =
AND
"sip:+4319793321@ingress21.provB.net;user=3Dphone".

Presumably provB controls the content of its information in both I-ENUM =
and its SRV records, so it could even be left up to provB to decide =
which method to use.

The main difference I can see is that option 2 would allow provB to =
identify different ingress gateways for different customers, which might =
be useful. However, option 2 would result in different treatment =
depending on whether the call was originated with an E.164 number or a =
SIP URI, which seems undesirable.

Does this sound reasonable?

Jim



-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =
Stastny Richard
Sent: Wednesday, December 07, 2005 7:01 AM
To: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Subject: [Sip] SIP AoR, tel and ENUM - Second Try

Hi folks,

thanks for the statements sofar, but I am still confused
(maybe even more ;-)

It seems also that my first post was not too well formulated

The basic question was:
Should Infrastructure ENUM contain a routing information
to the next hop only (the ingress border element of Provider B
(or administrative domain B)=20
or simply a mapping from an E.164 number to an AoR?

I will try to give another example and start from
within the scope of SPEERMINT (I hope this is the
last iteration before the name gets too lomg ;-)


I subscribe with provider B and get a default public
user identity (AoR) from this provider:
e.g. sip:foo@provB.net

This "foo" can be anything the provider chooses it to be:
e.g. an alphanumeric string such as ywzabcd,
a numeric string such as 16241 (my FWD number)
or 019793321 or 4319793321

Any other provider A having a peering agreement
with Provider B must be able to route a SIP call
given this SIP AoR to provider B, either to the
SIP proxy hosting this account or at least to
the ingress proxy(s) in provider B network.

On way to do so is to use SRV records within
the zone of provB.net pointing to e.g

ingress14.provB.net
and
ingress21.provB.net

Question: is this correct?

Note: after the ingress proxy provider B
may use another mapping mechanism to find
the real hosting server e.g. srv21.provB.net

Now I as a user are not happy with this default
public user identity, I want to have some aliases

eg:=20
1)sip:richard@stastny.com and
2) +43 1 9793321

In case 1) I assume that provider B needs
to provide me with redirect server(s), and I
need to enter in stastny.com SRV records
to point to these redirect servers
e.g. redirect.provB.net

sip:richard.stastny.com is redirected to
sip:foo@provB.net

Question: is this correct?

In case 2) we need Infrastructure ENUM
[Side note; in my user ENUM I would either enter
sip:richard@stastny.com or sip:foo@provB.net
this is my choice]

Now the question is: what goes into Infrastructure
ENUM for say +4319793321?

Is it:
Sip:foo@provB.net (if plain sip:foo@provB.net works
this must also work)
OR
sip:+4319793321@provB.net;user=3Dphone (correct?)
OR
sip:+4319793321@provB.net (wrong?)
OR
sip:4319793321@provB.net (valid only if 4319793321 =3D foo)

OR is it
sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
AND
sip:+4319793321@ingress21.provB.net;user=3Dphone

In this last case one would not need to query the
SRV records in provB.net

I hope I did not confuse the issue even more

Richard



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 07 22:56:45 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkCth-0007yE-Dw; Wed, 07 Dec 2005 22:56:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkCtd-0007wp-FC; Wed, 07 Dec 2005 22:56:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18686;
	Wed, 7 Dec 2005 22:55:48 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkDFS-0007gK-Kn; Wed, 07 Dec 2005 23:19:15 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 19:56:31 -0800
X-IronPort-AV: i="3.99,228,1131350400"; 
	d="scan'208"; a="375500539:sNHT36091340"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB83uBBV025379;
	Wed, 7 Dec 2005 19:56:28 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 7 Dec 2005 19:56:26 -0800
Received: from [10.21.80.55] ([10.21.80.55]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 19:56:24 -0800
Message-ID: <4397AEE7.8020303@cisco.com>
Date: Wed, 07 Dec 2005 22:56:23 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Klaus Darilion <klaus.mailinglists@pernau.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D461B228B@oefeg-s04.oefeg.loc>
	<4396D807.8000406@pernau.at>
In-Reply-To: <4396D807.8000406@pernau.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Dec 2005 03:56:25.0246 (UTC)
	FILETIME=[5C1003E0:01C5FBAB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Richard - this second try is much more successful than the first!

	Paul

Klaus Darilion wrote:
> Hi Richard!
> 
> comments inline
> 
> Stastny Richard wrote:
> 
>> Should Infrastructure ENUM contain a routing information
>> to the next hop only (the ingress border element of Provider B
>> (or administrative domain B) or simply a mapping from an E.164 number 
>> to an AoR?
> 
> IMHO it should be a mapping to an AoR as in user ENUM.

I think Richard has some specific ideas about what form of sip URI may 
be an AOR ans which may not. I am not entirely sure what those are, but 
suspect I disagree at least somewhat.

For this application, it should be something known to be stable by 
whoever is making the entry. Beyond that I don't see there is a need to 
be very specific.

If the user "owning" this number also has an "email-style" AOR that is 
intended to be fully equivalent to the phone number then that is 
probably one good choice. But it may be that a provider would rather set 
up the ENUM to simply route the numbers to itself using the user=phone 
form. I see nothing wrong with that either.

>> I will try to give another example and start from
> 
> ...
> 
>> I subscribe with provider B and get a default public
>> user identity (AoR) from this provider:
>> e.g. sip:foo@provB.net

>> This "foo" can be anything the provider chooses it to be:
>> e.g. an alphanumeric string such as ywzabcd,
>> a numeric string such as 16241 (my FWD number)
>> or 019793321 or 4319793321

If it is a telephony-oriented provider, there may be no reason to assign 
such an AOR. It might prefer simply to assign an AOR of the form: 
sip:+4319793321@provB.net;user=phone.

>> Any other provider A having a peering agreement
>> with Provider B must be able to route a SIP call
>> given this SIP AoR to provider B, either to the
>> SIP proxy hosting this account or at least to
>> the ingress proxy(s) in provider B network.
>>
>> On way to do so is to use SRV records within
>> the zone of provB.net pointing to e.g
>>
>> ingress14.provB.net
>> and
>> ingress21.provB.net
>>
>> Question: is this correct?
> 
> 
> IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net
> 
>> Note: after the ingress proxy provider B
>> may use another mapping mechanism to find
>> the real hosting server e.g. srv21.provB.net
>>
>> Now I as a user are not happy with this default
>> public user identity, I want to have some aliases
>>
>> eg: 1)sip:richard@stastny.com and
>> 2) +43 1 9793321

I guess (2) is really: tel:+4319793321

>> In case 1) I assume that provider B needs
>> to provide me with redirect server(s), and I
>> need to enter in stastny.com SRV records
>> to point to these redirect servers
>> e.g. redirect.provB.net
>>
>> sip:richard.stastny.com is redirected to
>> sip:foo@provB.net
>>
>> Question: is this correct?
> 
> This is a working scenario. But a redirect server is not mandatory. It 
> may also be a proxy which forwards the request "INVITE 
> sip:richard.stastny.com" to "INVITE sip:foo@provB.net".
> 
> It is also possbile that SRV for stastny.com points directly to 
> ingress12.provB.net and ingress12 knows about all hosted SIP domains and 
> knows how to forward the request to the end user.
> 
> But this is a design decision of the provB and IMO should be out of 
> scope of SPEERMINT. provB may use redirect server, provC may accept all 
> hosted SIP domains directly on their ingress points, .....

I agree with the above. It also depends on how you got stastny.com as 
your own domain. Is it hosted by somebody that can provide the 
forwarding service for you? Do they manage the DNS for you? Perhaps 
provB provides this service for you. If so there are many things it can do.

> I personally prefer relaying instead of redirect. E.g. redirect raises 
> questions like: How should intercept the redirect response and forward 
> to the new URI? The UA client or the SIP proxy of provA or the egress 
> proxy?
> 
> The important thing is that the originator (provA) should not have to 
> take care how provB implemented the hosting of SIP domains.
> 
>> In case 2) we need Infrastructure ENUM

You need for than that! You need for the number +43 1 9793321 to be 
assigned to you and set up so that pstn calls are routed to provB.

>> [Side note; in my user ENUM I would either enter
>> sip:richard@stastny.com or sip:foo@provB.net
>> this is my choice]

You only get to do this if *you* have control over your entry in the 
user ENUM. Will that always be the case, or will the provider manage it 
on your behalf?

One way to get the number would be for provB to get it for you. It might 
do as you suggest. Or it might consider this to be a separate AOR. In 
that case it might use something like IMS implicit registration sets to 
ensure that your same UA gets calls to both address forms.

>> Now the question is: what goes into Infrastructure
>> ENUM for say +4319793321?
>>
>> Is it:
>> Sip:foo@provB.net (if plain sip:foo@provB.net works
>> this must also work)
>> OR
>> sip:+4319793321@provB.net;user=phone (correct?)
>> OR
>> sip:+4319793321@provB.net (wrong?)

This is ok I guess. I think this is a provider option. I like it less 
because it is less explicit about what it means.

>> OR
>> sip:4319793321@provB.net (valid only if 4319793321 = foo)
>>
>> OR is it
>> sip:+4319793321@ingress14.provB.net;user=phone (and the above variants)
>> AND
>> sip:+4319793321@ingress21.provB.net;user=phone
> 
> IMO all of these are valid. It's up to the choice of provB. provB can 
> put anything into ENUM as long as provB is able to map from the URI in 
> I-ENUM to the end user.
> 
> If I would design the network for provB, I would use version 2 (without 
> user=phone as the user are not limited to phones).

(Isn't the one without user=phone option 3?)

I would use use sip:+4319793321@provB.net;user=phone

The presence of user=phone in no way prevents use for things other than 
phones. Of course it is not very convenient to type for those that enter 
URIs from a keyboard. If use for purposes like IM on a PC is expected, 
then sip:foo@provB.net may be preferred. Or else sip:foo@provB.net can 
just be supported also on the same device.

I also hope that as we go forward, pc apps will allow either sip URIs 
phone numbers (entered as a dial string and represented as a tel uri) to 
be used. So the "caller" would be using tel:+4319793321 and that will be 
appropriately routed.

>> In this last case one would not need to query the
>> SRV records in provB.net
> 
> 
> Also in the last case (if beeing conform with RFC3263), the egress proxy 
> has to perform NAPTR and SRV lookups. If you want to avoid them, just 
> put the IP address or the port into the host part, e.g.
> 
> sip:+4319793321@ingress21.provB.net:5060;user=phone
> 
> regards
> klaus
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Thu Dec 08 09:52:35 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkN8N-00061m-4m; Thu, 08 Dec 2005 09:52:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkN8G-0005yT-68; Thu, 08 Dec 2005 09:52:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23116;
	Thu, 8 Dec 2005 09:51:30 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkN8A-0002z9-LX; Thu, 08 Dec 2005 09:52:23 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 08 Dec 2005 06:52:13 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB8EpJNG003428;
	Thu, 8 Dec 2005 06:52:09 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 8 Dec 2005 09:52:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Thu, 8 Dec 2005 09:52:02 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA09F8@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AA==
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <henry@pulver.com>, "James Polk \(jmpolk\)" <jmpolk@cisco.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 08 Dec 2005 14:52:03.0638 (UTC)
	FILETIME=[F3924560:01C5FC06]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Henry,

An IT department of an enterprise that operates VoIP servers is a =
service provider, albeit a private versus a public one.  Thus, I don't =
see the limit you speak of.

Adding an additional adjective "public" and you get a PATS or Carrier =
that has narrower connotations.

Mike


> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com]=20
> Sent: Wednesday, December 07, 2005 7:10 PM
> To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20
> Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> 'Stastny Richard'
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> The VoIP calls in our offices can go directly between the two=20
> enterprise networks without any VoIP service providers being=20
> involved and this is as valid VoIP peering as any other. This=20
> is one of the reasons not to limit the VoIP peering models to=20
> only one, that with VoIP service providers in the middle.=20
>=20
> Sorry, I was not sure if the attached has taken this=20
> enterprise-enterprise into consideration and obviously there=20
> are other user scenarios as well.
>=20
> Thanks, Henry
>=20
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Wednesday, December 07, 2005 2:23 PM
> To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> James,
>=20
> This is d=E9j=E0 vu from the FG-NGN discussion on the exact same=20
> topic.  I have no issues with making distinctions of this=20
> type.  It was just not clear to me which of these various=20
> types (or the ones that Henry mentions) was in scope or not,=20
> but that seemed secondary to the point being made at the time=20
> that had to do with what the X entity did with an ENUM=20
> response that affected the constraints on what could be=20
> contained in such responses.
>=20
> Mike
>=20
>=20
> > -----Original Message-----
> > From: James Polk (jmpolk)
> > Sent: Tuesday, December 06, 2005 8:11 PM
> > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus=20
> > Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20
> > Richard
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > Mike
> >=20
> > This seems to be creeping into more than one WG at about the same=20
> > time.
> >=20
> > ISP used to be (roughly) the company you or you employer bought=20
> > service from to gain access to the Internet.  Now that is a=20
> little too=20
> > generic for a lot of people's tastes as there are different=20
> SPs that=20
> > an individual many have now that weren't available not so=20
> long ago. =20
> > Hence the recent push to separate them somehow.
> >=20
> > Application Providers, to me, include a Vonage for Voice=20
> services, and=20
> > a Yahoo for IM.
> >=20
> > Service Providers or Internet Providers, to me, connect one to the=20
> > Internet for L3 access
> >=20
> > Access Providers, to me, are the organizations like the DSL=20
> and Cable=20
> > and WiFi connectivity providers.
> >=20
> > Often times, to me, the Internet Providers and the Access Providers=20
> > are either the same company - while perhaps different=20
> divisions, but=20
> > they can be totally different companies too.
> >=20
> > The separation I'm seeing is between the organization that=20
> gives you=20
> > you Internet access and the organizations that provider you=20
> with all=20
> > the services required for a particular application - such=20
> as Voice or=20
> > Video.
> >=20
> > Everything used to be best effort, and services were either at your=20
> > device or at the provider's server.  Now there's an overlay=20
> at layer 7=20
> > (typically) and we're struggling with how to name and describe it.
> >=20
> >=20
> >=20
> > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> > >My looking glass is smudged today.
> > >
> > >What does one call a provider of service?
> > >I don't understand the aversion to service provider.
> > >
> > >I thought it was only the "carrier" word that invoked regulatory=20
> > >burdens (or PATS!).  I'd rather leave legal word games to=20
> > lawyers and lobbyists.
> > >
> > >Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry@pulver.com]
> > > > Sent: Tuesday, December 06, 2005 5:30 PM
> > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> > enum@ietf.org; 'Stastny=20
> > > > Richard'
> > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR,=20
> tel and ENUM
> > > >
> > > > Sorry for nitpicking:
> > > >
> > > > >A provider is a provider.
> > > >
> > > > A provider is a business model and att/SBC may differ=20
> from Google=20
> > > > who uses a different business model (which is more significant=20
> > > > measured in $$$?).
> > > >
> > > > Didn't we agree to use the term "Internet domain owner"=20
> (we could=20
> > > > shorten to IDOM or such)?
> > > >
> > > > Internet domains are well defined in the IETF.
> > > > Business models for VoIP are better suited for other=20
> > organizations,=20
> > > > consortia or innovators who work to disrupt them :-)
> > > >
> > > > Thanks, Henry
> > > >
> > > > -----Original Message-----
> > > > From: owner-voipeer@lists.uoregon.edu=20
> > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20
> > Michael Hammer
> > > > (mhammer)
> > > > Sent: Tuesday, December 06, 2005 3:36 PM
> > > > To: Thilo Salmon; Klaus Darilion
> > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> > enum@ietf.org; Stastny=20
> > > > Richard
> > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > >
> > > > I am having trouble parsing these statements.
> > > >
> > > > A provider is a provider.  I used the terms ingress and=20
> egress to=20
> > > > indicate some server that sits on the edge of a=20
> > provider's network=20
> > > > and does peering to some other provider.
> > > > The usage below seems to mix egress with originating being the=20
> > > > network where the caller is attached.
> > > >
> > > > I was noting that the called party terminal and the=20
> interconnect=20
> > > > points were different hosts and therefore may have different=20
> > > > identities.  To keep maximum flexibility, the format of those=20
> > > > identities would need to be fully under the control of=20
> > the domain of=20
> > > > each provider.  However, conflating all that into a=20
> single URI in=20
> > > > the Request-URI seemed constraining to me.  Having=20
> three URIs in=20
> > > > separate headers seemed the most flexible.
> > > >
> > > > Splitting.  I don't understand what got split or how.  ENUM
> > > > -- Tel:URI in, Point-of-interconnect URI out.  Put in=20
> > Route header. =20
> > > > I only suggested that there might be two route headers=20
> > because the=20
> > > > terminating provider would indicate in ENUM, to get to this=20
> > > > end-user, go to this entrance first.
> > > > But, to get to that entrance, the originating provider needs to=20
> > > > determine what the corresponding exit point is from his=20
> network,=20
> > > > i.e. another Route header.  The format and content of=20
> > that URI is up=20
> > > > to each provider.  The advertised entrance point is I think by=20
> > > > definition the (Inter-) Carrier ENUM.
> > > > The internal determination of the exit point could be termed
> > > > (Intra-) Carrier ENUM.  Maybe peering is concerned only=20
> with the=20
> > > > inter-carrier aspect.
> > > >
> > > > The Request-URI could be a normalized public identity=20
> of the user=20
> > > > totally independent of interconnect naming schemes.  I was just=20
> > > > teasing out what are the assumptions and constraints in=20
> > the original=20
> > > > email.
> > > >
> > > > Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > > > To: Klaus Darilion
> > > > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > > > voipeer@lists.uoregon.edu;
> > > > > enum@ietf.org; Stastny Richard
> > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > > >
> > > > > Richard, Klaus, et al.
> > > > >
> > > > > Apparently, I have missed an important developlement lately.
> > > > >
> > > > > > What is the benefit of splitting the ENUM result (the SIP
> > > > > URI) into a
> > > > > > Route header and into a request URI?
> > > > > [...]
> > > > > > IMO there should be no semantic for the internal routing
> > > > > (the routing
> > > > > > from the main proxy to the egress proxy). This should be
> > > > > out of scope
> > > > > > of all WGs. Also the internal routing of the ingress
> > > > > provider should
> > > > > > be out of scope. The ingress provider should have SIP URI
> > > > > which can be
> > > > > > used to address its customers.
> > > > >
> > > > > I absolutely second that statement. If for any reason=20
> > (we all have=20
> > > > > enough a vivid enough phantasy to imagine a good reason, I
> > > > suppose) an
> > > > > ingress provider wishes to feed a different set of=20
> SIP URIs to=20
> > > > > each and every of his egress partners, he should not be=20
> > stripped=20
> > > > > of this option.
> > > > > The scenario I have in mind is one in which an=20
> ingress provider=20
> > > > > chooses to encrypt the user part of all his SIP URIs=20
> with a key=20
> > > > > uniquely assigns to his egress partner.
> > > > >
> > > > > Just as Klaus I feel this complicates things and takes
> > > > authority over
> > > > > internal adressing away from the ingress provider for=20
> no reason=20
> > > > > apparent (to me).
> > > > >
> > > > > Thilo
> > > > >
> > > >
> > > > ______________________________________________________________
> > > > ______________
> > > > _
> > > > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > > >
> > > >
> > >
> > >_____________________________________________________________
> > __________
> > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> >=20
> >=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 08 10:55:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkO6t-0005CK-2X; Thu, 08 Dec 2005 10:55:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkO6j-000590-5D; Thu, 08 Dec 2005 10:55:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02186;
	Thu, 8 Dec 2005 10:53:49 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EkO6T-0005bu-JR; Thu, 08 Dec 2005 10:54:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] SIP AoR, tel and ENUM - Second Try
Date: Thu, 8 Dec 2005 16:58:08 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4704@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX6l7ng7d5gWyzJReGGP+c21C99TwAEhbpAAAJAsEAAGzinsAAZVNyQACKAXZA=
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "James McEachern" <jmce@nortel.com>, <sip@ietf.org>,
	<voipeer@lists.uoregon.edu>, <enum@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Content-Transfer-Encoding: quoted-printable
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Jim wrote:
>Presumably provB controls the content of its information in both I-ENUM =
and its SRV records, so it could even be left up >to provB to decide =
which method to use.

This seems to be the consensus we are converging here

There are only two caveats:
1. This is only easy if ProvB controls the NAPTRs directly
(in a multi-Tier approach)
If the data are held in a central DB (say a Peering Provider) and
the provisioning is done via other means, a common approach may=20
be required for the whole DB.

2. All ProvAs querying the tree need also have a common understanding
how to interpret the NAPTRs retrieved.

So according to Klaus, the second entry should look:

2. I-ENUM contains =
"sip:+4319793321@ingress14.provB.net:5060;user=3Dphone" AND
"sip:+4319793321@ingress21.provB.net:5060;user=3Dphone".

Richard


________________________________

Von: James McEachern [mailto:jmce@nortel.com]
Gesendet: Do 08.12.2005 00:51
An: Stastny Richard; sip@ietf.org; voipeer@lists.uoregon.edu; =
enum@ietf.org
Betreff: RE: [Sip] SIP AoR, tel and ENUM - Second Try



Richard,
It seems to me there are two basic options here, both of which are =
roughly equivalent.

1. I-ENUM contains an AoR, (probably in a format like =
sip:+4319793321@provB.net;user=3Dphone, rather than something like =
sip:richard@stastny.com, to protect user privacy).  The SRV records for =
provB could then point to ingress14.provB.net and ingress21.provB.net.

OR

2. I-ENUM contains "sip:+4319793321@ingress14.provB.net;user=3Dphone" =
AND
"sip:+4319793321@ingress21.provB.net;user=3Dphone".

Presumably provB controls the content of its information in both I-ENUM =
and its SRV records, so it could even be left up to provB to decide =
which method to use.

The main difference I can see is that option 2 would allow provB to =
identify different ingress gateways for different customers, which might =
be useful. However, option 2 would result in different treatment =
depending on whether the call was originated with an E.164 number or a =
SIP URI, which seems undesirable.

Does this sound reasonable?

Jim



-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =
Stastny Richard
Sent: Wednesday, December 07, 2005 7:01 AM
To: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Subject: [Sip] SIP AoR, tel and ENUM - Second Try

Hi folks,

thanks for the statements sofar, but I am still confused
(maybe even more ;-)

It seems also that my first post was not too well formulated

The basic question was:
Should Infrastructure ENUM contain a routing information
to the next hop only (the ingress border element of Provider B
(or administrative domain B)
or simply a mapping from an E.164 number to an AoR?

I will try to give another example and start from
within the scope of SPEERMINT (I hope this is the
last iteration before the name gets too lomg ;-)


I subscribe with provider B and get a default public
user identity (AoR) from this provider:
e.g. sip:foo@provB.net

This "foo" can be anything the provider chooses it to be:
e.g. an alphanumeric string such as ywzabcd,
a numeric string such as 16241 (my FWD number)
or 019793321 or 4319793321

Any other provider A having a peering agreement
with Provider B must be able to route a SIP call
given this SIP AoR to provider B, either to the
SIP proxy hosting this account or at least to
the ingress proxy(s) in provider B network.

On way to do so is to use SRV records within
the zone of provB.net pointing to e.g

ingress14.provB.net
and
ingress21.provB.net

Question: is this correct?

Note: after the ingress proxy provider B
may use another mapping mechanism to find
the real hosting server e.g. srv21.provB.net

Now I as a user are not happy with this default
public user identity, I want to have some aliases

eg:
1)sip:richard@stastny.com and
2) +43 1 9793321

In case 1) I assume that provider B needs
to provide me with redirect server(s), and I
need to enter in stastny.com SRV records
to point to these redirect servers
e.g. redirect.provB.net

sip:richard.stastny.com is redirected to
sip:foo@provB.net

Question: is this correct?

In case 2) we need Infrastructure ENUM
[Side note; in my user ENUM I would either enter
sip:richard@stastny.com or sip:foo@provB.net
this is my choice]

Now the question is: what goes into Infrastructure
ENUM for say +4319793321?

Is it:
Sip:foo@provB.net (if plain sip:foo@provB.net works
this must also work)
OR
sip:+4319793321@provB.net;user=3Dphone (correct?)
OR
sip:+4319793321@provB.net (wrong?)
OR
sip:4319793321@provB.net (valid only if 4319793321 =3D foo)

OR is it
sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
AND
sip:+4319793321@ingress21.provB.net;user=3Dphone

In this last case one would not need to query the
SRV records in provB.net

I hope I did not confuse the issue even more

Richard



_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 08 12:08:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkPFt-00007j-L5; Thu, 08 Dec 2005 12:08:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkPFh-0008VL-Rv; Thu, 08 Dec 2005 12:08:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11643;
	Thu, 8 Dec 2005 12:07:16 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkPFX-00008y-VP; Thu, 08 Dec 2005 12:08:10 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 09:07:57 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB8H7oQM017111;
	Thu, 8 Dec 2005 09:07:53 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 8 Dec 2005 12:07:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Thu, 8 Dec 2005 12:07:47 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0ADF@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AAABkrKgAAM2ItA=
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <henry@pulver.com>, "James Polk \(jmpolk\)" <jmpolk@cisco.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 08 Dec 2005 17:07:48.0455 (UTC)
	FILETIME=[EA42B770:01C5FC19]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Would it be possible to leverage through reference to and adoption of =
the work of that other group rather than repeat the time-consuming =
(painful) process of defining terms in this group?

Mike
=20

> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com]=20
> Sent: Thursday, December 08, 2005 10:57 AM
> To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20
> Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> 'Stastny Richard'
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Mike,
>=20
> I agree. If you want to say "service provider", the term has=20
> to be defined (as you have just contributed) to include cable=20
> networks, IT departments, government organizations, community=20
> networks, family/home networks, etc.=20
>=20
> Without a definition there is ample room for different=20
> meanings, technically, legally and commercial. But should=20
> such a definition be done in this WG?
>=20
> The technical meaning is _Internet domain_ in all cases.
>=20
> Thanks, Henry
>=20
> =20
>=20
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Thursday, December 08, 2005 8:52 AM
> To: henry@pulver.com; James Polk (jmpolk); Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Henry,
>=20
> An IT department of an enterprise that operates VoIP servers=20
> is a service provider, albeit a private versus a public one. =20
> Thus, I don't see the limit you speak of.
>=20
> Adding an additional adjective "public" and you get a PATS or=20
> Carrier that has narrower connotations.
>=20
> Mike
>=20
>=20
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry@pulver.com]
> > Sent: Wednesday, December 07, 2005 7:10 PM
> > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo Salmon';=20
> > 'Klaus Darilion'
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> 'Stastny=20
> > Richard'
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > The VoIP calls in our offices can go directly between the two=20
> > enterprise networks without any VoIP service providers=20
> being involved=20
> > and this is as valid VoIP peering as any other. This is one of the=20
> > reasons not to limit the VoIP peering models to only one, that with=20
> > VoIP service providers in the middle.
> >=20
> > Sorry, I was not sure if the attached has taken this=20
> > enterprise-enterprise into consideration and obviously=20
> there are other=20
> > user scenarios as well.
> >=20
> > Thanks, Henry
> >=20
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > Sent: Wednesday, December 07, 2005 2:23 PM
> > To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon; Klaus=20
> > Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20
> > Richard
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > James,
> >=20
> > This is d=E9j=E0 vu from the FG-NGN discussion on the exact=20
> same topic.  I=20
> > have no issues with making distinctions of this type.  It=20
> was just not=20
> > clear to me which of these various types (or the ones that Henry=20
> > mentions) was in scope or not, but that seemed secondary to=20
> the point=20
> > being made at the time that had to do with what the X=20
> entity did with=20
> > an ENUM response that affected the constraints on what could be=20
> > contained in such responses.
> >=20
> > Mike
> >=20
> >=20
> > > -----Original Message-----
> > > From: James Polk (jmpolk)
> > > Sent: Tuesday, December 06, 2005 8:11 PM
> > > To: Michael Hammer (mhammer); henry@pulver.com; Thilo=20
> Salmon; Klaus=20
> > > Darilion
> > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; Stastny=20
> > > Richard
> > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >=20
> > > Mike
> > >=20
> > > This seems to be creeping into more than one WG at about the same=20
> > > time.
> > >=20
> > > ISP used to be (roughly) the company you or you employer bought=20
> > > service from to gain access to the Internet.  Now that is a
> > little too
> > > generic for a lot of people's tastes as there are different
> > SPs that
> > > an individual many have now that weren't available not so
> > long ago. =20
> > > Hence the recent push to separate them somehow.
> > >=20
> > > Application Providers, to me, include a Vonage for Voice
> > services, and
> > > a Yahoo for IM.
> > >=20
> > > Service Providers or Internet Providers, to me, connect=20
> one to the=20
> > > Internet for L3 access
> > >=20
> > > Access Providers, to me, are the organizations like the DSL
> > and Cable
> > > and WiFi connectivity providers.
> > >=20
> > > Often times, to me, the Internet Providers and the Access=20
> Providers=20
> > > are either the same company - while perhaps different
> > divisions, but
> > > they can be totally different companies too.
> > >=20
> > > The separation I'm seeing is between the organization that
> > gives you
> > > you Internet access and the organizations that provider you
> > with all
> > > the services required for a particular application - such
> > as Voice or
> > > Video.
> > >=20
> > > Everything used to be best effort, and services were=20
> either at your=20
> > > device or at the provider's server.  Now there's an overlay
> > at layer 7
> > > (typically) and we're struggling with how to name and describe it.
> > >=20
> > >=20
> > >=20
> > > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> > > >My looking glass is smudged today.
> > > >
> > > >What does one call a provider of service?
> > > >I don't understand the aversion to service provider.
> > > >
> > > >I thought it was only the "carrier" word that invoked regulatory=20
> > > >burdens (or PATS!).  I'd rather leave legal word games to
> > > lawyers and lobbyists.
> > > >
> > > >Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Henry Sinnreich [mailto:henry@pulver.com]
> > > > > Sent: Tuesday, December 06, 2005 5:30 PM
> > > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;
> > > enum@ietf.org; 'Stastny
> > > > > Richard'
> > > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR,
> > tel and ENUM
> > > > >
> > > > > Sorry for nitpicking:
> > > > >
> > > > > >A provider is a provider.
> > > > >
> > > > > A provider is a business model and att/SBC may differ
> > from Google
> > > > > who uses a different business model (which is more=20
> significant=20
> > > > > measured in $$$?).
> > > > >
> > > > > Didn't we agree to use the term "Internet domain owner"=20
> > (we could
> > > > > shorten to IDOM or such)?
> > > > >
> > > > > Internet domains are well defined in the IETF.
> > > > > Business models for VoIP are better suited for other
> > > organizations,
> > > > > consortia or innovators who work to disrupt them :-)
> > > > >
> > > > > Thanks, Henry
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-voipeer@lists.uoregon.edu=20
> > > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of
> > > Michael Hammer
> > > > > (mhammer)
> > > > > Sent: Tuesday, December 06, 2005 3:36 PM
> > > > > To: Thilo Salmon; Klaus Darilion
> > > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;
> > > enum@ietf.org; Stastny
> > > > > Richard
> > > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > > >
> > > > > I am having trouble parsing these statements.
> > > > >
> > > > > A provider is a provider.  I used the terms ingress and
> > egress to
> > > > > indicate some server that sits on the edge of a
> > > provider's network
> > > > > and does peering to some other provider.
> > > > > The usage below seems to mix egress with originating=20
> being the=20
> > > > > network where the caller is attached.
> > > > >
> > > > > I was noting that the called party terminal and the
> > interconnect
> > > > > points were different hosts and therefore may have different=20
> > > > > identities.  To keep maximum flexibility, the format of those=20
> > > > > identities would need to be fully under the control of
> > > the domain of
> > > > > each provider.  However, conflating all that into a
> > single URI in
> > > > > the Request-URI seemed constraining to me.  Having
> > three URIs in
> > > > > separate headers seemed the most flexible.
> > > > >
> > > > > Splitting.  I don't understand what got split or how.  ENUM
> > > > > -- Tel:URI in, Point-of-interconnect URI out.  Put in
> > > Route header. =20
> > > > > I only suggested that there might be two route headers
> > > because the
> > > > > terminating provider would indicate in ENUM, to get to this=20
> > > > > end-user, go to this entrance first.
> > > > > But, to get to that entrance, the originating=20
> provider needs to=20
> > > > > determine what the corresponding exit point is from his
> > network,
> > > > > i.e. another Route header.  The format and content of
> > > that URI is up
> > > > > to each provider.  The advertised entrance point is I=20
> think by=20
> > > > > definition the (Inter-) Carrier ENUM.
> > > > > The internal determination of the exit point could be termed
> > > > > (Intra-) Carrier ENUM.  Maybe peering is concerned only
> > with the
> > > > > inter-carrier aspect.
> > > > >
> > > > > The Request-URI could be a normalized public identity
> > of the user
> > > > > totally independent of interconnect naming schemes. =20
> I was just=20
> > > > > teasing out what are the assumptions and constraints in
> > > the original
> > > > > email.
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > > > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > > > > To: Klaus Darilion
> > > > > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > > > > voipeer@lists.uoregon.edu;
> > > > > > enum@ietf.org; Stastny Richard
> > > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > > > >
> > > > > > Richard, Klaus, et al.
> > > > > >
> > > > > > Apparently, I have missed an important developlement lately.
> > > > > >
> > > > > > > What is the benefit of splitting the ENUM result (the SIP
> > > > > > URI) into a
> > > > > > > Route header and into a request URI?
> > > > > > [...]
> > > > > > > IMO there should be no semantic for the internal routing
> > > > > > (the routing
> > > > > > > from the main proxy to the egress proxy). This should be
> > > > > > out of scope
> > > > > > > of all WGs. Also the internal routing of the ingress
> > > > > > provider should
> > > > > > > be out of scope. The ingress provider should have SIP URI
> > > > > > which can be
> > > > > > > used to address its customers.
> > > > > >
> > > > > > I absolutely second that statement. If for any reason
> > > (we all have
> > > > > > enough a vivid enough phantasy to imagine a good reason, I
> > > > > suppose) an
> > > > > > ingress provider wishes to feed a different set of
> > SIP URIs to
> > > > > > each and every of his egress partners, he should not be
> > > stripped
> > > > > > of this option.
> > > > > > The scenario I have in mind is one in which an
> > ingress provider
> > > > > > chooses to encrypt the user part of all his SIP URIs
> > with a key
> > > > > > uniquely assigns to his egress partner.
> > > > > >
> > > > > > Just as Klaus I feel this complicates things and takes
> > > > > authority over
> > > > > > internal adressing away from the ingress provider for
> > no reason
> > > > > > apparent (to me).
> > > > > >
> > > > > > Thilo
> > > > > >
> > > > >
> > > > > ______________________________________________________________
> > > > > ______________
> > > > > _
> > > > > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > > > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > > > >
> > > > >
> > > >
> > > >_____________________________________________________________
> > > __________
> > > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > >=20
> > >=20
> >=20
>=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 08 14:04:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkR4a-0004E1-FF; Thu, 08 Dec 2005 14:04:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkR4Y-0004D8-SX
	for sip@megatron.ietf.org; Thu, 08 Dec 2005 14:04:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25536
	for <sip@ietf.org>; Thu, 8 Dec 2005 14:04:02 -0500 (EST)
Received: from bdsoft10.vwh.net ([130.94.149.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkR4a-0004Zu-75
	for sip@ietf.org; Thu, 08 Dec 2005 14:04:57 -0500
Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2])
	(authenticated bits=0)
	by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id jB8J4ONv046677;
	Thu, 8 Dec 2005 14:04:30 -0500 (EST)
From: "Brett Tate" <brett@broadsoft.com>
To: "'Rohan Mahy'" <rohan@ekabal.com>
Subject: RE: [Sip] Re: Comment on draft-ietf-sip-connect-reuse-04
Date: Thu, 8 Dec 2005 14:05:00 -0500
Message-ID: <002a01c5fc2a$4a39dfe0$2c28a8c0@brett1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <be010ebb79384cf96a4b415729e8a44a@ekabal.com>
X-PMX-IsInternal: True
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: 'SIP WG' <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

> > This is very difficult to implement for most people.=20
> > If you do a DNS lookup of an A record, this requires=20
> > you to get every IP address then look at your
> > alias to see if you have one that matches - and not=20
> > do load balancing. This is hard unless you have your=20
> > own DNS resolve library which most people do not.
>=20
> You don't need to lookup every IP address, you do need=20
> to consult a list of "named" connections before you=20
> do SRV lookup however.

Rohan,

Thanks for answering Cullen's question.

I understand "You don't need to lookup every IP address".  However I =
don't
fully understand when to query the alias list and what all should be
included within the query.  The answer only mentioned the portion prior =
to
the SRV query.  This would indicate transport successfully determined =
via
NAPTR or transport parameter and there was no port.  This example is
partially included within the draft. =20

Are there other locations within the DNS NAPTR, SRV, A-record resolution
process when the alias query should occur? =20

And if an alias not found during first query, should more queries occur
during DNS resolution process? =20

And if so, what should be the contents used for each query (port added =
by
SRV, handling of trailing dot added by NAPTR or SRV, etcetera)?

Just trying to extrapolate the response to understand how it fits some =
of my
questions within an earlier posting...

http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html


Thanks,
Brett



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 02:46:20 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkcxQ-00049I-AL; Fri, 09 Dec 2005 02:46:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek0xg-0002mp-3p
	for sip@megatron.ietf.org; Wed, 07 Dec 2005 10:12:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17709
	for <sip@ietf.org>; Wed, 7 Dec 2005 10:11:11 -0500 (EST)
Message-Id: <200512071511.KAA17709@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek1JO-0003QE-HT
	for sip@ietf.org; Wed, 07 Dec 2005 10:34:31 -0500
Received: (qmail 18523 invoked by uid 510); 7 Dec 2005 10:16:40 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 1.221155 secs); 07 Dec 2005 15:16:40 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	1.221155 secs Process 18514)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Wed, 07 Dec 2005 15:16:38 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'James M. Polk'" <jmpolk@cisco.com>,
	"'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Wed, 7 Dec 2005 09:11:53 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX6zl2SX6z2UfpvRNe3OEvi6GgSqAAbpzmA
In-Reply-To: <4.3.2.7.2.20051206190139.0325d688@email.cisco.com>
X-Antivirus-MYDOMAIN-Message-ID: <113396859983518514@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 09 Dec 2005 02:46:18 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

James,

> Now there's an overlay at layer 7 (typically) and we're struggling 
> with how to name and describe it.

How about the following business models for domain administrators:

- Individuals (Henry's residential network)
- Enterprises (the Cisco IT network, including VoIP)
- "Web (add 2.0)" companies: AOL, Apple, IBM, Google, Microsoft, Yahoo,
- Facility based "Carriers" (ATT, Verizon)
- Government, military,
- VoIP and IM companies: FWD, Skype, Vonage.

The last ones (VoIP and IM companies) carry most of the public VoIP traffic
anyway, while the residential network domain may be clearly the preference
of some users.

Mike Hammer writes:

> I don't understand the aversion to service provider.
No need to elaborate :-)
Besides, I just happen to like my own network domain better!

The above is only another attempt to stay out of business/legal models in
this IETF WG. Just say: Network Domains and/or Network Administrators.

Thanks, Henry

 

-----Original Message-----
From: owner-voipeer@lists.uoregon.edu
[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of James M. Polk
Sent: Tuesday, December 06, 2005 7:11 PM
To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny Richard
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

Mike

This seems to be creeping into more than one WG at about the same time.

ISP used to be (roughly) the company you or you employer bought service 
from to gain access to the Internet.  Now that is a little too generic for 
a lot of people's tastes as there are different SPs that an individual many 
have now that weren't available not so long ago.  Hence the recent push to 
separate them somehow.

Application Providers, to me, include a Vonage for Voice services, and a 
Yahoo for IM.

Service Providers or Internet Providers, to me, connect one to the Internet 
for L3 access

Access Providers, to me, are the organizations like the DSL and Cable and 
WiFi connectivity providers.

Often times, to me, the Internet Providers and the Access Providers are 
either the same company - while perhaps different divisions, but they can 
be totally different companies too.

The separation I'm seeing is between the organization that gives you you 
Internet access and the organizations that provider you with all the 
services required for a particular application - such as Voice or Video.

Everything used to be best effort, and services were either at your device 
or at the provider's server.  Now there's an overlay at layer 7 (typically) 
and we're struggling with how to name and describe it.



At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
>My looking glass is smudged today.
>
>What does one call a provider of service?
>I don't understand the aversion to service provider.
>
>I thought it was only the "carrier" word that invoked regulatory burdens
>(or PATS!).  I'd rather leave legal word games to lawyers and lobbyists.
>
>Mike
>
>
> > -----Original Message-----
> > From: Henry Sinnreich [mailto:henry@pulver.com]
> > Sent: Tuesday, December 06, 2005 5:30 PM
> > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;
> > 'Stastny Richard'
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >
> > Sorry for nitpicking:
> >
> > >A provider is a provider.
> >
> > A provider is a business model and att/SBC may differ from
> > Google who uses a different business model (which is more
> > significant measured in $$$?).
> >
> > Didn't we agree to use the term "Internet domain owner" (we
> > could shorten to IDOM or such)?
> >
> > Internet domains are well defined in the IETF.
> > Business models for VoIP are better suited for other
> > organizations, consortia or innovators who work to disrupt them :-)
> >
> > Thanks, Henry
> >
> > -----Original Message-----
> > From: owner-voipeer@lists.uoregon.edu
> > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Hammer
> > (mhammer)
> > Sent: Tuesday, December 06, 2005 3:36 PM
> > To: Thilo Salmon; Klaus Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;
> > Stastny Richard
> > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >
> > I am having trouble parsing these statements.
> >
> > A provider is a provider.  I used the terms ingress and
> > egress to indicate some server that sits on the edge of a
> > provider's network and does peering to some other provider.
> > The usage below seems to mix egress with originating being
> > the network where the caller is attached.
> >
> > I was noting that the called party terminal and the
> > interconnect points were different hosts and therefore may
> > have different identities.  To keep maximum flexibility, the
> > format of those identities would need to be fully under the
> > control of the domain of each provider.  However, conflating
> > all that into a single URI in the Request-URI seemed
> > constraining to me.  Having three URIs in separate headers
> > seemed the most flexible.
> >
> > Splitting.  I don't understand what got split or how.  ENUM
> > -- Tel:URI in, Point-of-interconnect URI out.  Put in Route
> > header.  I only suggested that there might be two route
> > headers because the terminating provider would indicate in
> > ENUM, to get to this end-user, go to this entrance first.
> > But, to get to that entrance, the originating provider needs
> > to determine what the corresponding exit point is from his
> > network, i.e. another Route header.  The format and content
> > of that URI is up to each provider.  The advertised entrance
> > point is I think by definition the (Inter-) Carrier ENUM.
> > The internal determination of the exit point could be termed
> > (Intra-) Carrier ENUM.  Maybe peering is concerned only with
> > the inter-carrier aspect.
> >
> > The Request-URI could be a normalized public identity of the
> > user totally independent of interconnect naming schemes.  I
> > was just teasing out what are the assumptions and constraints
> > in the original email.
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > To: Klaus Darilion
> > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > voipeer@lists.uoregon.edu;
> > > enum@ietf.org; Stastny Richard
> > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > Richard, Klaus, et al.
> > >
> > > Apparently, I have missed an important developlement lately.
> > >
> > > > What is the benefit of splitting the ENUM result (the SIP
> > > URI) into a
> > > > Route header and into a request URI?
> > > [...]
> > > > IMO there should be no semantic for the internal routing
> > > (the routing
> > > > from the main proxy to the egress proxy). This should be
> > > out of scope
> > > > of all WGs. Also the internal routing of the ingress
> > > provider should
> > > > be out of scope. The ingress provider should have SIP URI
> > > which can be
> > > > used to address its customers.
> > >
> > > I absolutely second that statement. If for any reason (we all have
> > > enough a vivid enough phantasy to imagine a good reason, I
> > suppose) an
> > > ingress provider wishes to feed a different set of SIP URIs to each
> > > and every of his egress partners, he should not be stripped of this
> > > option.
> > > The scenario I have in mind is one in which an ingress provider
> > > chooses to encrypt the user part of all his SIP URIs with a key
> > > uniquely assigns to his egress partner.
> > >
> > > Just as Klaus I feel this complicates things and takes
> > authority over
> > > internal adressing away from the ingress provider for no reason
> > > apparent (to me).
> > >
> > > Thilo
> > >
> >
> > ______________________________________________________________
> > ______________
> > _
> > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> >
> >
>
>___________________________________________________________________________
__
>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
____________________________________________________________________________
_
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html




_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 02:46:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkcxR-00049j-Dz; Fri, 09 Dec 2005 02:46:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9MZ-0005HA-1l
	for sip@megatron.ietf.org; Wed, 07 Dec 2005 19:10:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24742
	for <sip@ietf.org>; Wed, 7 Dec 2005 19:09:26 -0500 (EST)
Message-Id: <200512080009.TAA24742@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek9iL-0008G2-D9
	for sip@ietf.org; Wed, 07 Dec 2005 19:32:50 -0500
Received: (qmail 31894 invoked by uid 510); 7 Dec 2005 19:14:58 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 2.825078 secs); 08 Dec 2005 00:14:58 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	2.825078 secs Process 31835)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Thu, 08 Dec 2005 00:14:54 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>,
	"'James Polk \(jmpolk\)'" <jmpolk@cisco.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Wed, 7 Dec 2005 18:09:51 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserA=
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA082B@xmb-rtp-20b.amer.cisco.com>
X-Antivirus-MYDOMAIN-Message-ID: <113400089583531835@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 09 Dec 2005 02:46:18 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

The VoIP calls in our offices can go directly between the two enterprise
networks without any VoIP service providers being involved and this is =
as
valid VoIP peering as any other. This is one of the reasons not to limit =
the
VoIP peering models to only one, that with VoIP service providers in the
middle.=20

Sorry, I was not sure if the attached has taken this =
enterprise-enterprise
into consideration and obviously there are other user scenarios as well.

Thanks, Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20
Sent: Wednesday, December 07, 2005 2:23 PM
To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny =
Richard
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

James,

This is d=E9j=E0 vu from the FG-NGN discussion on the exact same topic.  =
I have
no issues with making distinctions of this type.  It was just not clear =
to
me which of these various types (or the ones that Henry mentions) was in
scope or not, but that seemed secondary to the point being made at the =
time
that had to do with what the X entity did with an ENUM response that
affected the constraints on what could be contained in such responses.

Mike


> -----Original Message-----
> From: James Polk (jmpolk)=20
> Sent: Tuesday, December 06, 2005 8:11 PM
> To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Mike
>=20
> This seems to be creeping into more than one WG at about the=20
> same time.
>=20
> ISP used to be (roughly) the company you or you employer=20
> bought service from to gain access to the Internet.  Now that=20
> is a little too generic for a lot of people's tastes as there=20
> are different SPs that an individual many have now that=20
> weren't available not so long ago.  Hence the recent push to=20
> separate them somehow.
>=20
> Application Providers, to me, include a Vonage for Voice=20
> services, and a Yahoo for IM.
>=20
> Service Providers or Internet Providers, to me, connect one=20
> to the Internet for L3 access
>=20
> Access Providers, to me, are the organizations like the DSL=20
> and Cable and WiFi connectivity providers.
>=20
> Often times, to me, the Internet Providers and the Access=20
> Providers are either the same company - while perhaps=20
> different divisions, but they can be totally different companies too.
>=20
> The separation I'm seeing is between the organization that=20
> gives you you Internet access and the organizations that=20
> provider you with all the services required for a particular=20
> application - such as Voice or Video.
>=20
> Everything used to be best effort, and services were either=20
> at your device or at the provider's server.  Now there's an=20
> overlay at layer 7 (typically) and we're struggling with how=20
> to name and describe it.
>=20
>=20
>=20
> At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> >My looking glass is smudged today.
> >
> >What does one call a provider of service?
> >I don't understand the aversion to service provider.
> >
> >I thought it was only the "carrier" word that invoked regulatory=20
> >burdens (or PATS!).  I'd rather leave legal word games to=20
> lawyers and lobbyists.
> >
> >Mike
> >
> >
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:henry@pulver.com]
> > > Sent: Tuesday, December 06, 2005 5:30 PM
> > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; 'Stastny=20
> > > Richard'
> > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > Sorry for nitpicking:
> > >
> > > >A provider is a provider.
> > >
> > > A provider is a business model and att/SBC may differ from Google=20
> > > who uses a different business model (which is more significant=20
> > > measured in $$$?).
> > >
> > > Didn't we agree to use the term "Internet domain owner" (we could=20
> > > shorten to IDOM or such)?
> > >
> > > Internet domains are well defined in the IETF.
> > > Business models for VoIP are better suited for other=20
> organizations,=20
> > > consortia or innovators who work to disrupt them :-)
> > >
> > > Thanks, Henry
> > >
> > > -----Original Message-----
> > > From: owner-voipeer@lists.uoregon.edu=20
> > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20
> Michael Hammer
> > > (mhammer)
> > > Sent: Tuesday, December 06, 2005 3:36 PM
> > > To: Thilo Salmon; Klaus Darilion
> > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> enum@ietf.org; Stastny=20
> > > Richard
> > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > >
> > > I am having trouble parsing these statements.
> > >
> > > A provider is a provider.  I used the terms ingress and egress to=20
> > > indicate some server that sits on the edge of a=20
> provider's network=20
> > > and does peering to some other provider.
> > > The usage below seems to mix egress with originating being the=20
> > > network where the caller is attached.
> > >
> > > I was noting that the called party terminal and the interconnect=20
> > > points were different hosts and therefore may have different=20
> > > identities.  To keep maximum flexibility, the format of those=20
> > > identities would need to be fully under the control of=20
> the domain of=20
> > > each provider.  However, conflating all that into a single URI in=20
> > > the Request-URI seemed constraining to me.  Having three URIs in=20
> > > separate headers seemed the most flexible.
> > >
> > > Splitting.  I don't understand what got split or how.  ENUM
> > > -- Tel:URI in, Point-of-interconnect URI out.  Put in=20
> Route header. =20
> > > I only suggested that there might be two route headers=20
> because the=20
> > > terminating provider would indicate in ENUM, to get to this=20
> > > end-user, go to this entrance first.
> > > But, to get to that entrance, the originating provider needs to=20
> > > determine what the corresponding exit point is from his network,=20
> > > i.e. another Route header.  The format and content of=20
> that URI is up=20
> > > to each provider.  The advertised entrance point is I think by=20
> > > definition the (Inter-) Carrier ENUM.
> > > The internal determination of the exit point could be termed
> > > (Intra-) Carrier ENUM.  Maybe peering is concerned only with the=20
> > > inter-carrier aspect.
> > >
> > > The Request-URI could be a normalized public identity of the user=20
> > > totally independent of interconnect naming schemes.  I was just=20
> > > teasing out what are the assumptions and constraints in=20
> the original=20
> > > email.
> > >
> > > Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > > To: Klaus Darilion
> > > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > > voipeer@lists.uoregon.edu;
> > > > enum@ietf.org; Stastny Richard
> > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > >
> > > > Richard, Klaus, et al.
> > > >
> > > > Apparently, I have missed an important developlement lately.
> > > >
> > > > > What is the benefit of splitting the ENUM result (the SIP
> > > > URI) into a
> > > > > Route header and into a request URI?
> > > > [...]
> > > > > IMO there should be no semantic for the internal routing
> > > > (the routing
> > > > > from the main proxy to the egress proxy). This should be
> > > > out of scope
> > > > > of all WGs. Also the internal routing of the ingress
> > > > provider should
> > > > > be out of scope. The ingress provider should have SIP URI
> > > > which can be
> > > > > used to address its customers.
> > > >
> > > > I absolutely second that statement. If for any reason=20
> (we all have=20
> > > > enough a vivid enough phantasy to imagine a good reason, I
> > > suppose) an
> > > > ingress provider wishes to feed a different set of SIP URIs to=20
> > > > each and every of his egress partners, he should not be=20
> stripped=20
> > > > of this option.
> > > > The scenario I have in mind is one in which an ingress provider=20
> > > > chooses to encrypt the user part of all his SIP URIs with a key=20
> > > > uniquely assigns to his egress partner.
> > > >
> > > > Just as Klaus I feel this complicates things and takes
> > > authority over
> > > > internal adressing away from the ingress provider for no reason=20
> > > > apparent (to me).
> > > >
> > > > Thilo
> > > >
> > >
> > > ______________________________________________________________
> > > ______________
> > > _
> > > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > >
> > >
> >
> >_____________________________________________________________
> __________
> >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
>=20
>=20



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 02:46:22 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkcxS-0004AA-Eo; Fri, 09 Dec 2005 02:46:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO9c-0005oI-3C
	for sip@megatron.ietf.org; Thu, 08 Dec 2005 10:57:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02409
	for <sip@ietf.org>; Thu, 8 Dec 2005 10:56:42 -0500 (EST)
Message-Id: <200512081556.KAA02409@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkO9H-0005hl-MJ
	for sip@ietf.org; Thu, 08 Dec 2005 10:57:36 -0500
Received: (qmail 3668 invoked by uid 510); 8 Dec 2005 11:02:27 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 1.018343 secs); 08 Dec 2005 16:02:27 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	1.018343 secs Process 3660)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Thu, 08 Dec 2005 16:02:26 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>,
	"'James Polk \(jmpolk\)'" <jmpolk@cisco.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Thu, 8 Dec 2005 09:57:18 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA09F8@xmb-rtp-20b.amer.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX6yySCxyyxZ86zQZWvC9QFGn/uPQAoDi3gAAbserAAH9g8AAABkrKg
X-Antivirus-MYDOMAIN-Message-ID: <11340577468353660@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 09 Dec 2005 02:46:18 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Mike,

I agree. If you want to say "service provider", the term has to be =
defined
(as you have just contributed) to include cable networks, IT =
departments,
government organizations, community networks, family/home networks, etc. =


Without a definition there is ample room for different meanings,
technically, legally and commercial. But should such a definition be =
done in
this WG?

The technical meaning is _Internet domain_ in all cases.

Thanks, Henry

=20

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20
Sent: Thursday, December 08, 2005 8:52 AM
To: henry@pulver.com; James Polk (jmpolk); Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny =
Richard
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

Henry,

An IT department of an enterprise that operates VoIP servers is a =
service
provider, albeit a private versus a public one.  Thus, I don't see the =
limit
you speak of.

Adding an additional adjective "public" and you get a PATS or Carrier =
that
has narrower connotations.

Mike


> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com]=20
> Sent: Wednesday, December 07, 2005 7:10 PM
> To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo=20
> Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> 'Stastny Richard'
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> The VoIP calls in our offices can go directly between the two=20
> enterprise networks without any VoIP service providers being=20
> involved and this is as valid VoIP peering as any other. This=20
> is one of the reasons not to limit the VoIP peering models to=20
> only one, that with VoIP service providers in the middle.=20
>=20
> Sorry, I was not sure if the attached has taken this=20
> enterprise-enterprise into consideration and obviously there=20
> are other user scenarios as well.
>=20
> Thanks, Henry
>=20
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Wednesday, December 07, 2005 2:23 PM
> To: James Polk (jmpolk); henry@pulver.com; Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org;=20
> Stastny Richard
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> James,
>=20
> This is d=E9j=E0 vu from the FG-NGN discussion on the exact same=20
> topic.  I have no issues with making distinctions of this=20
> type.  It was just not clear to me which of these various=20
> types (or the ones that Henry mentions) was in scope or not,=20
> but that seemed secondary to the point being made at the time=20
> that had to do with what the X entity did with an ENUM=20
> response that affected the constraints on what could be=20
> contained in such responses.
>=20
> Mike
>=20
>=20
> > -----Original Message-----
> > From: James Polk (jmpolk)
> > Sent: Tuesday, December 06, 2005 8:11 PM
> > To: Michael Hammer (mhammer); henry@pulver.com; Thilo Salmon; Klaus=20
> > Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org; Stastny=20
> > Richard
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > Mike
> >=20
> > This seems to be creeping into more than one WG at about the same=20
> > time.
> >=20
> > ISP used to be (roughly) the company you or you employer bought=20
> > service from to gain access to the Internet.  Now that is a=20
> little too=20
> > generic for a lot of people's tastes as there are different=20
> SPs that=20
> > an individual many have now that weren't available not so=20
> long ago. =20
> > Hence the recent push to separate them somehow.
> >=20
> > Application Providers, to me, include a Vonage for Voice=20
> services, and=20
> > a Yahoo for IM.
> >=20
> > Service Providers or Internet Providers, to me, connect one to the=20
> > Internet for L3 access
> >=20
> > Access Providers, to me, are the organizations like the DSL=20
> and Cable=20
> > and WiFi connectivity providers.
> >=20
> > Often times, to me, the Internet Providers and the Access Providers=20
> > are either the same company - while perhaps different=20
> divisions, but=20
> > they can be totally different companies too.
> >=20
> > The separation I'm seeing is between the organization that=20
> gives you=20
> > you Internet access and the organizations that provider you=20
> with all=20
> > the services required for a particular application - such=20
> as Voice or=20
> > Video.
> >=20
> > Everything used to be best effort, and services were either at your=20
> > device or at the provider's server.  Now there's an overlay=20
> at layer 7=20
> > (typically) and we're struggling with how to name and describe it.
> >=20
> >=20
> >=20
> > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> > >My looking glass is smudged today.
> > >
> > >What does one call a provider of service?
> > >I don't understand the aversion to service provider.
> > >
> > >I thought it was only the "carrier" word that invoked regulatory=20
> > >burdens (or PATS!).  I'd rather leave legal word games to=20
> > lawyers and lobbyists.
> > >
> > >Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:henry@pulver.com]
> > > > Sent: Tuesday, December 06, 2005 5:30 PM
> > > > To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> > enum@ietf.org; 'Stastny=20
> > > > Richard'
> > > > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR,=20
> tel and ENUM
> > > >
> > > > Sorry for nitpicking:
> > > >
> > > > >A provider is a provider.
> > > >
> > > > A provider is a business model and att/SBC may differ=20
> from Google=20
> > > > who uses a different business model (which is more significant=20
> > > > measured in $$$?).
> > > >
> > > > Didn't we agree to use the term "Internet domain owner"=20
> (we could=20
> > > > shorten to IDOM or such)?
> > > >
> > > > Internet domains are well defined in the IETF.
> > > > Business models for VoIP are better suited for other=20
> > organizations,=20
> > > > consortia or innovators who work to disrupt them :-)
> > > >
> > > > Thanks, Henry
> > > >
> > > > -----Original Message-----
> > > > From: owner-voipeer@lists.uoregon.edu=20
> > > > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of=20
> > Michael Hammer
> > > > (mhammer)
> > > > Sent: Tuesday, December 06, 2005 3:36 PM
> > > > To: Thilo Salmon; Klaus Darilion
> > > > Cc: sip@ietf.org; voipeer@lists.uoregon.edu;=20
> > enum@ietf.org; Stastny=20
> > > > Richard
> > > > Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > >
> > > > I am having trouble parsing these statements.
> > > >
> > > > A provider is a provider.  I used the terms ingress and=20
> egress to=20
> > > > indicate some server that sits on the edge of a=20
> > provider's network=20
> > > > and does peering to some other provider.
> > > > The usage below seems to mix egress with originating being the=20
> > > > network where the caller is attached.
> > > >
> > > > I was noting that the called party terminal and the=20
> interconnect=20
> > > > points were different hosts and therefore may have different=20
> > > > identities.  To keep maximum flexibility, the format of those=20
> > > > identities would need to be fully under the control of=20
> > the domain of=20
> > > > each provider.  However, conflating all that into a=20
> single URI in=20
> > > > the Request-URI seemed constraining to me.  Having=20
> three URIs in=20
> > > > separate headers seemed the most flexible.
> > > >
> > > > Splitting.  I don't understand what got split or how.  ENUM
> > > > -- Tel:URI in, Point-of-interconnect URI out.  Put in=20
> > Route header. =20
> > > > I only suggested that there might be two route headers=20
> > because the=20
> > > > terminating provider would indicate in ENUM, to get to this=20
> > > > end-user, go to this entrance first.
> > > > But, to get to that entrance, the originating provider needs to=20
> > > > determine what the corresponding exit point is from his=20
> network,=20
> > > > i.e. another Route header.  The format and content of=20
> > that URI is up=20
> > > > to each provider.  The advertised entrance point is I think by=20
> > > > definition the (Inter-) Carrier ENUM.
> > > > The internal determination of the exit point could be termed
> > > > (Intra-) Carrier ENUM.  Maybe peering is concerned only=20
> with the=20
> > > > inter-carrier aspect.
> > > >
> > > > The Request-URI could be a normalized public identity=20
> of the user=20
> > > > totally independent of interconnect naming schemes.  I was just=20
> > > > teasing out what are the assumptions and constraints in=20
> > the original=20
> > > > email.
> > > >
> > > > Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Thilo Salmon [mailto:salmon@sipgate.de]
> > > > > Sent: Tuesday, December 06, 2005 2:06 PM
> > > > > To: Klaus Darilion
> > > > > Cc: Michael Hammer (mhammer); sip@ietf.org;
> > > > voipeer@lists.uoregon.edu;
> > > > > enum@ietf.org; Stastny Richard
> > > > > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > > > >
> > > > > Richard, Klaus, et al.
> > > > >
> > > > > Apparently, I have missed an important developlement lately.
> > > > >
> > > > > > What is the benefit of splitting the ENUM result (the SIP
> > > > > URI) into a
> > > > > > Route header and into a request URI?
> > > > > [...]
> > > > > > IMO there should be no semantic for the internal routing
> > > > > (the routing
> > > > > > from the main proxy to the egress proxy). This should be
> > > > > out of scope
> > > > > > of all WGs. Also the internal routing of the ingress
> > > > > provider should
> > > > > > be out of scope. The ingress provider should have SIP URI
> > > > > which can be
> > > > > > used to address its customers.
> > > > >
> > > > > I absolutely second that statement. If for any reason=20
> > (we all have=20
> > > > > enough a vivid enough phantasy to imagine a good reason, I
> > > > suppose) an
> > > > > ingress provider wishes to feed a different set of=20
> SIP URIs to=20
> > > > > each and every of his egress partners, he should not be=20
> > stripped=20
> > > > > of this option.
> > > > > The scenario I have in mind is one in which an=20
> ingress provider=20
> > > > > chooses to encrypt the user part of all his SIP URIs=20
> with a key=20
> > > > > uniquely assigns to his egress partner.
> > > > >
> > > > > Just as Klaus I feel this complicates things and takes
> > > > authority over
> > > > > internal adressing away from the ingress provider for=20
> no reason=20
> > > > > apparent (to me).
> > > > >
> > > > > Thilo
> > > > >
> > > >
> > > > ______________________________________________________________
> > > > ______________
> > > > _
> > > > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > > > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> > > >
> > > >
> > >
> > >_____________________________________________________________
> > __________
> > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> >=20
> >=20
>=20




_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 06:32:55 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkgUh-00055j-6C; Fri, 09 Dec 2005 06:32:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkgUe-00053w-Ol; Fri, 09 Dec 2005 06:32:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20935;
	Fri, 9 Dec 2005 06:31:46 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkgUb-0007ox-6g; Fri, 09 Dec 2005 06:32:51 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1EkgTz-0004CX-00; Fri, 09 Dec 2005 12:32:12 +0100
Message-ID: <43996B20.9040908@pernau.at>
Date: Fri, 09 Dec 2005 12:31:44 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46FD@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard wrote:
> Klaus wrote:
> 
>>If I would design the network for provB, I would use version 2 (without
>>user=phone as the user are not limited to phones).
> 
> You mean:
> 
>>sip:+4319793321@provB.net;user=phone 
> 
>  
> IMHO this does not imply that the user uses a phone,
> it implies that the user-part is a Tel URI !

Yes. This makes more sense. (I've never knowed what the user=phone 
parameter is really for).

Thus, IMO the paramter is more interesting for the outgoing provider. If 
the proxy of provA receives a request from its customer for
   sip:+4312345@provA.com
this would adress the lokal user +4312345. A request for
   sip:+4312345@provA.com;user=phone
would address the E.164 phone number +4312345

Thanks for clarification,
Klaus


>  
> Richard
> 
> 
> 
> ________________________________
> 
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Mi 07.12.2005 13:39
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> Hi Richard!
> 
> comments inline
> 
> Stastny Richard wrote:
> 
>>Should Infrastructure ENUM contain a routing information
>>to the next hop only (the ingress border element of Provider B
>>(or administrative domain B)
>>or simply a mapping from an E.164 number to an AoR?
> 
> 
> IMHO it should be a mapping to an AoR as in user ENUM.
> 
> 
>>I will try to give another example and start from
> 
> ...
> 
>>I subscribe with provider B and get a default public
>>user identity (AoR) from this provider:
>>e.g. sip:foo@provB.net
>>
>>This "foo" can be anything the provider chooses it to be:
>>e.g. an alphanumeric string such as ywzabcd,
>>a numeric string such as 16241 (my FWD number)
>>or 019793321 or 4319793321
>>
>>Any other provider A having a peering agreement
>>with Provider B must be able to route a SIP call
>>given this SIP AoR to provider B, either to the
>>SIP proxy hosting this account or at least to
>>the ingress proxy(s) in provider B network.
>>
>>On way to do so is to use SRV records within
>>the zone of provB.net pointing to e.g
>>
>>ingress14.provB.net
>>and
>>ingress21.provB.net
>>
>>Question: is this correct?
> 
> 
> IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to ingress14.provB.net
> 
> 
>>Note: after the ingress proxy provider B
>>may use another mapping mechanism to find
>>the real hosting server e.g. srv21.provB.net
>>
>>Now I as a user are not happy with this default
>>public user identity, I want to have some aliases
>>
>>eg:
>>1)sip:richard@stastny.com and
>>2) +43 1 9793321
>>
>>In case 1) I assume that provider B needs
>>to provide me with redirect server(s), and I
>>need to enter in stastny.com SRV records
>>to point to these redirect servers
>>e.g. redirect.provB.net
>>
>>sip:richard.stastny.com is redirected to
>>sip:foo@provB.net
>>
>>Question: is this correct?
> 
> 
> This is a working scenario. But a redirect server is not mandatory. It
> may also be a proxy which forwards the request "INVITE
> sip:richard.stastny.com" to "INVITE sip:foo@provB.net".
> 
> It is also possbile that SRV for stastny.com points directly to
> ingress12.provB.net and ingress12 knows about all hosted SIP domains and
> knows how to forward the request to the end user.
> 
> But this is a design decision of the provB and IMO should be out of
> scope of SPEERMINT. provB may use redirect server, provC may accept all
> hosted SIP domains directly on their ingress points, .....
> 
> I personally prefer relaying instead of redirect. E.g. redirect raises
> questions like: How should intercept the redirect response and forward
> to the new URI? The UA client or the SIP proxy of provA or the egress proxy?
> 
> The important thing is that the originator (provA) should not have to
> take care how provB implemented the hosting of SIP domains.
> 
> 
>>In case 2) we need Infrastructure ENUM
>>[Side note; in my user ENUM I would either enter
>>sip:richard@stastny.com or sip:foo@provB.net
>>this is my choice]
>>
>>Now the question is: what goes into Infrastructure
>>ENUM for say +4319793321?
>>
>>Is it:
>>Sip:foo@provB.net (if plain sip:foo@provB.net works
>>this must also work)
>>OR
>>sip:+4319793321@provB.net;user=phone (correct?)
>>OR
>>sip:+4319793321@provB.net (wrong?)
>>OR
>>sip:4319793321@provB.net (valid only if 4319793321 = foo)
>>
>>OR is it
>>sip:+4319793321@ingress14.provB.net;user=phone (and the above variants)
>>AND
>>sip:+4319793321@ingress21.provB.net;user=phone
> 
> 
> IMO all of these are valid. It's up to the choice of provB. provB can
> put anything into ENUM as long as provB is able to map from the URI in
> I-ENUM to the end user.
> 
> If I would design the network for provB, I would use version 2 (without
> user=phone as the user are not limited to phones).
> 
> 
>>In this last case one would not need to query the
>>SRV records in provB.net
> 
> 
> Also in the last case (if beeing conform with RFC3263), the egress proxy
> has to perform NAPTR and SRV lookups. If you want to avoid them, just
> put the IP address or the port into the host part, e.g.
> 
> sip:+4319793321@ingress21.provB.net:5060;user=phone
> 
> regards
> klaus
> 
> 
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Fri Dec 09 06:41:15 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekgcl-0006Hd-0P; Fri, 09 Dec 2005 06:41:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekgcj-0006Gf-NO; Fri, 09 Dec 2005 06:41:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21680;
	Fri, 9 Dec 2005 06:40:11 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Ekgcm-00082K-AP; Fri, 09 Dec 2005 06:41:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 12:41:11 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX8tLvugOQOUjqsTLG48DzXFpRL8wAALf62
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

>Thus, IMO the paramter is more interesting for the outgoing provider. =
If
>the proxy of provA receives a request from its customer for
>   sip:+4312345@provA.com
>this would adress the lokal user +4312345. A request for
>   sip:+4312345@provA.com;user=3Dphone
>would address the E.164 phone number +4312345

Yesss, exactly ;-)

And since you rarely have local users start with +,
sip:4312345@provA.com is more usual

and
sip:+4312345@provA.com
should not happen, causeing always confusion

Richard



________________________________

Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Fr 09.12.2005 12:31
An: Stastny Richard
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try



Stastny Richard wrote:
> Klaus wrote:
>
>>If I would design the network for provB, I would use version 2 =
(without
>>user=3Dphone as the user are not limited to phones).
>
> You mean:
>
>>sip:+4319793321@provB.net;user=3Dphone
>
>=20
> IMHO this does not imply that the user uses a phone,
> it implies that the user-part is a Tel URI !

Yes. This makes more sense. (I've never knowed what the user=3Dphone
parameter is really for).

Thus, IMO the paramter is more interesting for the outgoing provider. If
the proxy of provA receives a request from its customer for
   sip:+4312345@provA.com
this would adress the lokal user +4312345. A request for
   sip:+4312345@provA.com;user=3Dphone
would address the E.164 phone number +4312345

Thanks for clarification,
Klaus


>=20
> Richard
>
>
>
> ________________________________
>
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Mi 07.12.2005 13:39
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try
>
>
>
> Hi Richard!
>
> comments inline
>
> Stastny Richard wrote:
>
>>Should Infrastructure ENUM contain a routing information
>>to the next hop only (the ingress border element of Provider B
>>(or administrative domain B)
>>or simply a mapping from an E.164 number to an AoR?
>
>
> IMHO it should be a mapping to an AoR as in user ENUM.
>
>
>>I will try to give another example and start from
>
> ...
>
>>I subscribe with provider B and get a default public
>>user identity (AoR) from this provider:
>>e.g. sip:foo@provB.net
>>
>>This "foo" can be anything the provider chooses it to be:
>>e.g. an alphanumeric string such as ywzabcd,
>>a numeric string such as 16241 (my FWD number)
>>or 019793321 or 4319793321
>>
>>Any other provider A having a peering agreement
>>with Provider B must be able to route a SIP call
>>given this SIP AoR to provider B, either to the
>>SIP proxy hosting this account or at least to
>>the ingress proxy(s) in provider B network.
>>
>>On way to do so is to use SRV records within
>>the zone of provB.net pointing to e.g
>>
>>ingress14.provB.net
>>and
>>ingress21.provB.net
>>
>>Question: is this correct?
>
>
> IMO yes. Thus, A sends "INVITE sip:foo@provB.net" to =
ingress14.provB.net
>
>
>>Note: after the ingress proxy provider B
>>may use another mapping mechanism to find
>>the real hosting server e.g. srv21.provB.net
>>
>>Now I as a user are not happy with this default
>>public user identity, I want to have some aliases
>>
>>eg:
>>1)sip:richard@stastny.com and
>>2) +43 1 9793321
>>
>>In case 1) I assume that provider B needs
>>to provide me with redirect server(s), and I
>>need to enter in stastny.com SRV records
>>to point to these redirect servers
>>e.g. redirect.provB.net
>>
>>sip:richard.stastny.com is redirected to
>>sip:foo@provB.net
>>
>>Question: is this correct?
>
>
> This is a working scenario. But a redirect server is not mandatory. It
> may also be a proxy which forwards the request "INVITE
> sip:richard.stastny.com" to "INVITE sip:foo@provB.net".
>
> It is also possbile that SRV for stastny.com points directly to
> ingress12.provB.net and ingress12 knows about all hosted SIP domains =
and
> knows how to forward the request to the end user.
>
> But this is a design decision of the provB and IMO should be out of
> scope of SPEERMINT. provB may use redirect server, provC may accept =
all
> hosted SIP domains directly on their ingress points, .....
>
> I personally prefer relaying instead of redirect. E.g. redirect raises
> questions like: How should intercept the redirect response and forward
> to the new URI? The UA client or the SIP proxy of provA or the egress =
proxy?
>
> The important thing is that the originator (provA) should not have to
> take care how provB implemented the hosting of SIP domains.
>
>
>>In case 2) we need Infrastructure ENUM
>>[Side note; in my user ENUM I would either enter
>>sip:richard@stastny.com or sip:foo@provB.net
>>this is my choice]
>>
>>Now the question is: what goes into Infrastructure
>>ENUM for say +4319793321?
>>
>>Is it:
>>Sip:foo@provB.net (if plain sip:foo@provB.net works
>>this must also work)
>>OR
>>sip:+4319793321@provB.net;user=3Dphone (correct?)
>>OR
>>sip:+4319793321@provB.net (wrong?)
>>OR
>>sip:4319793321@provB.net (valid only if 4319793321 =3D foo)
>>
>>OR is it
>>sip:+4319793321@ingress14.provB.net;user=3Dphone (and the above =
variants)
>>AND
>>sip:+4319793321@ingress21.provB.net;user=3Dphone
>
>
> IMO all of these are valid. It's up to the choice of provB. provB can
> put anything into ENUM as long as provB is able to map from the URI in
> I-ENUM to the end user.
>
> If I would design the network for provB, I would use version 2 =
(without
> user=3Dphone as the user are not limited to phones).
>
>
>>In this last case one would not need to query the
>>SRV records in provB.net
>
>
> Also in the last case (if beeing conform with RFC3263), the egress =
proxy
> has to perform NAPTR and SRV lookups. If you want to avoid them, just
> put the IP address or the port into the host part, e.g.
>
> sip:+4319793321@ingress21.provB.net:5060;user=3Dphone
>
> regards
> klaus
>
>
>
> _______________________________________________
> 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



From sip-bounces@ietf.org Fri Dec 09 06:53:31 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekgod-000280-9B; Fri, 09 Dec 2005 06:53:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekgob-00027g-18; Fri, 09 Dec 2005 06:53:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23030;
	Fri, 9 Dec 2005 06:52:26 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ekgod-0008UW-V8; Fri, 09 Dec 2005 06:53:32 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1EkgoO-0004Ci-00; Fri, 09 Dec 2005 12:53:16 +0100
Message-ID: <43997011.7000805@pernau.at>
Date: Fri, 09 Dec 2005 12:52:49 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C46FC@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard wrote:
> Thanx Klaus
> 
> Also for answering a question I did not (yet) ask
> regarding redirect vs proxy
> 
> 
> 
>>I personally prefer relaying instead of redirect.
> 
> 
> Me too and I see your arguments.
> Are there any arguments out there why to prefer redriect?

I just made some signaling pictures to visualize the difference:
 From the signaling, there is no big difference. Both versions do need 
approximately the same amount of signaling packets sent (depends onthe 
actual SIP network design).

I do not see any technical reason why to prefer one version over the 
other. It's just a personal preference.

regards
klaus


UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
|        |          |                  |             |        |      |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |                  |             |        |        |
|        |          |<------302--------|             |        |        |
|        |<-302-----|-------ACK------->|             |        |        |
|        |--ACK---->|                  |             |        |        |
|        |--INVITE->|                  |             |        |        |
|        |<-100-----|--------------INVITE----------->|        |        |
|        |          |<--------------100--------------|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |<---------------180-------------|        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |<---------------200-------------|        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |

32 Packets


UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
|        |          |                  |             |        |        |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |<-------100-------|---INVITE--->|        |        |
|        |          |                  |<----100-----|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |                  |<---180------|        |        |
|        |          |<----- -180-------|             |        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |                  |<---200------|        |        |
|        |          |<-------200-------|             |        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|

29 Packets


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 07:15:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekh9W-00009t-Ts; Fri, 09 Dec 2005 07:15:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekh9T-00007L-6W; Fri, 09 Dec 2005 07:15:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25218;
	Fri, 9 Dec 2005 07:14:00 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Ekh9W-0000jf-2I; Fri, 09 Dec 2005 07:15:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Dec 2005 13:17:27 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc>
Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX8t62w821JMsoqQGCdm3aV0mJTAAAAtcKN
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Thanx Klaus

for the work ;-)

Now the next question:
What are the implications proxy vs redirect
if you are using TLS?
=20
Richard

________________________________

Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Fr 09.12.2005 12:52
An: Stastny Richard
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try



Stastny Richard wrote:
> Thanx Klaus
>
> Also for answering a question I did not (yet) ask
> regarding redirect vs proxy
>
>
>
>>I personally prefer relaying instead of redirect.
>
>
> Me too and I see your arguments.
> Are there any arguments out there why to prefer redriect?

I just made some signaling pictures to visualize the difference:
 From the signaling, there is no big difference. Both versions do need
approximately the same amount of signaling packets sent (depends onthe
actual SIP network design).

I do not see any technical reason why to prefer one version over the
other. It's just a personal preference.

regards
klaus


UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
|        |          |                  |             |        |      |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |                  |             |        |        |
|        |          |<------302--------|             |        |        |
|        |<-302-----|-------ACK------->|             |        |        |
|        |--ACK---->|                  |             |        |        |
|        |--INVITE->|                  |             |        |        |
|        |<-100-----|--------------INVITE----------->|        |        |
|        |          |<--------------100--------------|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |<---------------180-------------|        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |<---------------200-------------|        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |
|        |          |                  |             |        |        |

32 Packets


UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
|        |          |                  |             |        |        |
|-INVITE>|          |                  |             |        |        |
|<-100---|-INVITE-->|                  |             |        |        |
|        |<--100----|-------INVITE---->|             |        |        |
|        |          |<-------100-------|---INVITE--->|        |        |
|        |          |                  |<----100-----|-INVITE>|        |
|        |          |                  |             |<-100---|-INVITE>|
|        |          |                  |             |        |<-100---|
|        |          |                  |             |        |        |
|        |          |                  |             |        |<-180---|
|        |          |                  |             |<--180--|        |
|        |          |                  |<---180------|        |        |
|        |          |<----- -180-------|             |        |        |
|        |<--180----|                  |             |        |        |
|<--180--|          |                  |             |        |<--200--|
|        |          |                  |             |<--200--|        |
|        |          |                  |<---200------|        |        |
|        |          |<-------200-------|             |        |        |
|        |<---200---|                  |             |        |        |
|<---200-|          |                  |             |        |        |
|        |          |                  |             |        |        |
|--ACK-->|          |                  |             |        |        |
|        |----ACK-->|                  |             |        |        |
|        |          |--------------ACK-------------->|        |        |
|        |          |                  |             |--ACK-->|        |
|        |          |                  |             |        |--ACK-->|

29 Packets




_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 07:42:09 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkhZh-0006nA-7D; Fri, 09 Dec 2005 07:42:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkhZS-0006m6-F5; Fri, 09 Dec 2005 07:42:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27799;
	Fri, 9 Dec 2005 07:40:48 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkhZS-0001XS-Jw; Fri, 09 Dec 2005 07:41:55 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1EkhYv-0004F2-00; Fri, 09 Dec 2005 13:41:21 +0100
Message-ID: <43997B56.1000208@pernau.at>
Date: Fri, 09 Dec 2005 13:40:54 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard wrote:
> Thanx Klaus
> 
> for the work ;-)
> 
> Now the next question:
> What are the implications proxy vs redirect
> if you are using TLS?

Now it's getting complicated ;-)

With the redirect server, there will be 2 TLS handshakes:
   1. borderProxyA       redirectProxy
   2. borderProxyA       borderProxyB

With the forwarding proxy, one TLS connection is mandatory:
   1. borderProxyA       forwardingProxy

If the forwardin proxy is within the network of provB, there is no need 
to use TLS inside the network of prov if other means can be used to 
authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of 
signaling for in-dialog messages, there is also a must for the second 
TLS conenction between
   2. borderProxyA       borderProxyB

The more complicated thing is the certificate validation. RFC 3263 
mandates, that the SIP domain (before NAPTR, SRV lookups) must be 
identical to the domain in the certificate. If provB hosts thousands of 
SIP domains for its clients, e.g. sip:fobar@stastny.com, 
sip:foobar@darilion.com, .... and requires TLS for incoming connections, 
provB must present a valid certificate for all hosted domains. Thus, you 
have to give your private key for stastny.com to you SIP provider. 
Furthermore, plain TLS requires the server to send the certificate 
without any knowledge of which domain the UAC is trying to contact. 
Thus, provB needs a dedicated socket for each hosted domain on its 
border proxy to differ the requests and present the proper certificate. 
IMO that does not scale. It can be avoided using the "server_name" TLS 
extension, but this is e.g. not supported in openssl which is used most 
for proxy servers.

This could be also solved by changing RFC 3263 to validate the 
certificate against the domain name revealed after SRV lookups. This was 
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed 
in DNS, not in SIP.

regards
klaus

>  
> Richard
> 
> ________________________________
> 
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Fr 09.12.2005 12:52
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> Stastny Richard wrote:
> 
>>Thanx Klaus
>>
>>Also for answering a question I did not (yet) ask
>>regarding redirect vs proxy
>>
>>
>>
>>
>>>I personally prefer relaying instead of redirect.
>>
>>
>>Me too and I see your arguments.
>>Are there any arguments out there why to prefer redriect?
> 
> 
> I just made some signaling pictures to visualize the difference:
>  From the signaling, there is no big difference. Both versions do need
> approximately the same amount of signaling packets sent (depends onthe
> actual SIP network design).
> 
> I do not see any technical reason why to prefer one version over the
> other. It's just a personal preference.
> 
> regards
> klaus
> 
> 
> UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
> |        |          |                  |             |        |      |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |                  |             |        |        |
> |        |          |<------302--------|             |        |        |
> |        |<-302-----|-------ACK------->|             |        |        |
> |        |--ACK---->|                  |             |        |        |
> |        |--INVITE->|                  |             |        |        |
> |        |<-100-----|--------------INVITE----------->|        |        |
> |        |          |<--------------100--------------|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |<---------------180-------------|        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |<---------------200-------------|        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
> 
> 32 Packets
> 
> 
> UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
> |        |          |                  |             |        |        |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |<-------100-------|---INVITE--->|        |        |
> |        |          |                  |<----100-----|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |                  |<---180------|        |        |
> |        |          |<----- -180-------|             |        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |                  |<---200------|        |        |
> |        |          |<-------200-------|             |        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
> 
> 29 Packets
> 
> 
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 09:09:14 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekivy-00068p-OK; Fri, 09 Dec 2005 09:09:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekivj-00064Z-OY; Fri, 09 Dec 2005 09:09:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08515;
	Fri, 9 Dec 2005 09:07:58 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ekivm-0004lL-1k; Fri, 09 Dec 2005 09:09:04 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 06:08:39 -0800
X-IronPort-AV: i="3.99,234,1131350400"; 
	d="scan'208"; a="239225149:sNHT34114880"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB9E84Qo015297;
	Fri, 9 Dec 2005 06:08:37 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 06:08:24 -0800
Received: from [10.21.88.169] ([10.21.88.169]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 06:08:23 -0800
Message-ID: <43998FD7.20207@cisco.com>
Date: Fri, 09 Dec 2005 09:08:23 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2005 14:08:24.0066 (UTC)
	FILETIME=[04990E20:01C5FCCA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Klaus Darilion <klaus.mailinglists@pernau.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Stastny Richard wrote:
>>Thus, IMO the paramter is more interesting for the outgoing provider. If
>>the proxy of provA receives a request from its customer for
>>  sip:+4312345@provA.com
>>this would adress the lokal user +4312345. A request for
>>  sip:+4312345@provA.com;user=phone
>>would address the E.164 phone number +4312345
> 
> 
> Yesss, exactly ;-)
> 
> And since you rarely have local users start with +,
> sip:4312345@provA.com is more usual
> 
> and
> sip:+4312345@provA.com
> should not happen, causeing always confusion

It seems that many people intend to use a namespace for usernames where 
there is no overlap of names and numbers: there is no possibility for a 
*name* +4312345 that has a different meaning than the E.164 number 
+4312345. In that case the presence or absence of the ";user=phone" is 
irrelevant as far as its meaning within the owning domain. In that case 
the ";user=phone" is more a matter of informing the world that this is 
intended to be a phone number.

Also, as it happens, while
	sip:+4312345@provA.com
	sip:+4312345@provA.com;user=phone
are not equal by uri comparison rules, they are equal according to the 
rules that 3261 applies to the targets of registration. So, you can't 
really have them mean different things.

	Paul

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 09:28:49 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjEv-0005A6-B7; Fri, 09 Dec 2005 09:28:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjEt-00059l-OF; Fri, 09 Dec 2005 09:28:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10783;
	Fri, 9 Dec 2005 09:27:54 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EkjF6-0005Uc-00; Fri, 09 Dec 2005 09:29:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Dec 2005 15:28:59 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc>
Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX8vmW1+WGge9X1TxeEkgJLJ9ThNgADn8Gt
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Now my next question:
=20
Is the problem Klaus described below a problem to be sovled within
the SPEERMINT problem (scope) space?
=20
"The more complicated thing is the certificate validation. RFC 3263
mandates, that the SIP domain (before NAPTR, SRV lookups) must be
identical to the domain in the certificate. If provB hosts thousands of
SIP domains for its clients, e.g. sip:fobar@stastny.com,
sip:foobar@darilion.com, .... and requires TLS for incoming connections,
provB must present a valid certificate for all hosted domains. Thus, you
have to give your private key for stastny.com to you SIP provider.
Furthermore, plain TLS requires the server to send the certificate
without any knowledge of which domain the UAC is trying to contact.
Thus, provB needs a dedicated socket for each hosted domain on its
border proxy to differ the requests and present the proper certificate.
IMO that does not scale. It can be avoided using the "server_name" TLS
extension, but this is e.g. not supported in openssl which is used most
for proxy servers.

This could be also solved by changing RFC 3263 to validate the
certificate against the domain name revealed after SRV lookups. This was
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
in DNS, not in SIP."

Richard



________________________________

Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Fr 09.12.2005 13:40
An: Stastny Richard
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try



Stastny Richard wrote:
> Thanx Klaus
>
> for the work ;-)
>
> Now the next question:
> What are the implications proxy vs redirect
> if you are using TLS?

Now it's getting complicated ;-)

With the redirect server, there will be 2 TLS handshakes:
   1. borderProxyA       redirectProxy
   2. borderProxyA       borderProxyB

With the forwarding proxy, one TLS connection is mandatory:
   1. borderProxyA       forwardingProxy

If the forwardin proxy is within the network of provB, there is no need
to use TLS inside the network of prov if other means can be used to
authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of
signaling for in-dialog messages, there is also a must for the second
TLS conenction between
   2. borderProxyA       borderProxyB

The more complicated thing is the certificate validation. RFC 3263
mandates, that the SIP domain (before NAPTR, SRV lookups) must be
identical to the domain in the certificate. If provB hosts thousands of
SIP domains for its clients, e.g. sip:fobar@stastny.com,
sip:foobar@darilion.com, .... and requires TLS for incoming connections,
provB must present a valid certificate for all hosted domains. Thus, you
have to give your private key for stastny.com to you SIP provider.
Furthermore, plain TLS requires the server to send the certificate
without any knowledge of which domain the UAC is trying to contact.
Thus, provB needs a dedicated socket for each hosted domain on its
border proxy to differ the requests and present the proper certificate.
IMO that does not scale. It can be avoided using the "server_name" TLS
extension, but this is e.g. not supported in openssl which is used most
for proxy servers.

This could be also solved by changing RFC 3263 to validate the
certificate against the domain name revealed after SRV lookups. This was
forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
in DNS, not in SIP.

regards
klaus

>=20
> Richard
>
> ________________________________
>
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Fr 09.12.2005 12:52
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>
>
>
> Stastny Richard wrote:
>
>>Thanx Klaus
>>
>>Also for answering a question I did not (yet) ask
>>regarding redirect vs proxy
>>
>>
>>
>>
>>>I personally prefer relaying instead of redirect.
>>
>>
>>Me too and I see your arguments.
>>Are there any arguments out there why to prefer redriect?
>
>
> I just made some signaling pictures to visualize the difference:
>  From the signaling, there is no big difference. Both versions do need
> approximately the same amount of signaling packets sent (depends onthe
> actual SIP network design).
>
> I do not see any technical reason why to prefer one version over the
> other. It's just a personal preference.
>
> regards
> klaus
>
>
> UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  =
UAS
> |        |          |                  |             |        |      |
> |-INVITE>|          |                  |             |        |        =
|
> |<-100---|-INVITE-->|                  |             |        |        =
|
> |        |<--100----|-------INVITE---->|             |        |        =
|
> |        |          |                  |             |        |        =
|
> |        |          |<------302--------|             |        |        =
|
> |        |<-302-----|-------ACK------->|             |        |        =
|
> |        |--ACK---->|                  |             |        |        =
|
> |        |--INVITE->|                  |             |        |        =
|
> |        |<-100-----|--------------INVITE----------->|        |        =
|
> |        |          |<--------------100--------------|-INVITE>|        =
|
> |        |          |                  |             =
|<-100---|-INVITE>|
> |        |          |                  |             |        =
|<-100---|
> |        |          |                  |             |        |        =
|
> |        |          |                  |             |        =
|<-180---|
> |        |          |                  |             |<--180--|        =
|
> |        |          |<---------------180-------------|        |        =
|
> |        |<--180----|                  |             |        |        =
|
> |<--180--|          |                  |             |        =
|<--200--|
> |        |          |                  |             |<--200--|        =
|
> |        |          |<---------------200-------------|        |        =
|
> |        |<---200---|                  |             |        |        =
|
> |<---200-|          |                  |             |        |        =
|
> |        |          |                  |             |        |        =
|
> |--ACK-->|          |                  |             |        |        =
|
> |        |----ACK-->|                  |             |        |        =
|
> |        |          |--------------ACK-------------->|        |        =
|
> |        |          |                  |             |--ACK-->|        =
|
> |        |          |                  |             |        =
|--ACK-->|
> |        |          |                  |             |        |        =
|
> |        |          |                  |             |        |        =
|
> |        |          |                  |             |        |        =
|
>
> 32 Packets
>
>
> UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  =
UAS
> |        |          |                  |             |        |        =
|
> |-INVITE>|          |                  |             |        |        =
|
> |<-100---|-INVITE-->|                  |             |        |        =
|
> |        |<--100----|-------INVITE---->|             |        |        =
|
> |        |          |<-------100-------|---INVITE--->|        |        =
|
> |        |          |                  |<----100-----|-INVITE>|        =
|
> |        |          |                  |             =
|<-100---|-INVITE>|
> |        |          |                  |             |        =
|<-100---|
> |        |          |                  |             |        |        =
|
> |        |          |                  |             |        =
|<-180---|
> |        |          |                  |             |<--180--|        =
|
> |        |          |                  |<---180------|        |        =
|
> |        |          |<----- -180-------|             |        |        =
|
> |        |<--180----|                  |             |        |        =
|
> |<--180--|          |                  |             |        =
|<--200--|
> |        |          |                  |             |<--200--|        =
|
> |        |          |                  |<---200------|        |        =
|
> |        |          |<-------200-------|             |        |        =
|
> |        |<---200---|                  |             |        |        =
|
> |<---200-|          |                  |             |        |        =
|
> |        |          |                  |             |        |        =
|
> |--ACK-->|          |                  |             |        |        =
|
> |        |----ACK-->|                  |             |        |        =
|
> |        |          |--------------ACK-------------->|        |        =
|
> |        |          |                  |             |--ACK-->|        =
|
> |        |          |                  |             |        =
|--ACK-->|
>
> 29 Packets
>
>
>
>




_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 09:35:44 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjLb-0008K5-Uu; Fri, 09 Dec 2005 09:35:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjLY-0008Gh-UN; Fri, 09 Dec 2005 09:35:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12095;
	Fri, 9 Dec 2005 09:34:47 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkjLi-0005kq-6m; Fri, 09 Dec 2005 09:35:53 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1EkjL8-0004GR-00; Fri, 09 Dec 2005 15:35:14 +0100
Message-ID: <43999607.7060900@pernau.at>
Date: Fri, 09 Dec 2005 15:34:47 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com>
In-Reply-To: <43998FD7.20207@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi Paul!

Thanks for clarification. I always had problem to understand the proper 
meaning of this parameter. Is this somewhere described in detail? I also 
rememeber a discussion to remove this parameter completly.

regards
klaus

Paul Kyzivat wrote:
> 
> 
> Stastny Richard wrote:
> 
>>> Thus, IMO the paramter is more interesting for the outgoing provider. If
>>> the proxy of provA receives a request from its customer for
>>>  sip:+4312345@provA.com
>>> this would adress the lokal user +4312345. A request for
>>>  sip:+4312345@provA.com;user=phone
>>> would address the E.164 phone number +4312345
>>
>>
>>
>> Yesss, exactly ;-)
>>
>> And since you rarely have local users start with +,
>> sip:4312345@provA.com is more usual
>>
>> and
>> sip:+4312345@provA.com
>> should not happen, causeing always confusion
> 
> 
> It seems that many people intend to use a namespace for usernames where 
> there is no overlap of names and numbers: there is no possibility for a 
> *name* +4312345 that has a different meaning than the E.164 number 
> +4312345. In that case the presence or absence of the ";user=phone" is 
> irrelevant as far as its meaning within the owning domain. In that case 
> the ";user=phone" is more a matter of informing the world that this is 
> intended to be a phone number.
> 
> Also, as it happens, while
>     sip:+4312345@provA.com
>     sip:+4312345@provA.com;user=phone
> are not equal by uri comparison rules, they are equal according to the 
> rules that 3261 applies to the targets of registration. So, you can't 
> really have them mean different things.
> 
>     Paul
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Fri Dec 09 09:40:50 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjQY-0001ms-5s; Fri, 09 Dec 2005 09:40:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjQV-0001fm-LW; Fri, 09 Dec 2005 09:40:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12780;
	Fri, 9 Dec 2005 09:39:49 -0500 (EST)
Received: from nat.labs.nic.at ([83.136.33.3] helo=whistler)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkjQc-0005yL-Qx; Fri, 09 Dec 2005 09:40:55 -0500
Received: from klauspc.intern ([10.10.0.50])
	by whistler with esmtp (Exim 3.36 #1 (Debian))
	id 1EkjQL-0004Gb-00; Fri, 09 Dec 2005 15:40:37 +0100
Message-ID: <4399974A.30104@pernau.at>
Date: Fri, 09 Dec 2005 15:40:10 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4712@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard wrote:
> Now my next question:
>  
> Is the problem Klaus described below a problem to be sovled within
> the SPEERMINT problem (scope) space?

IMHO yes, as long as the SIP WGs do not provide a solution which fit 
real life scenarios.

klaus

> "The more complicated thing is the certificate validation. RFC 3263
> mandates, that the SIP domain (before NAPTR, SRV lookups) must be
> identical to the domain in the certificate. If provB hosts thousands of
> SIP domains for its clients, e.g. sip:fobar@stastny.com,
> sip:foobar@darilion.com, .... and requires TLS for incoming connections,
> provB must present a valid certificate for all hosted domains. Thus, you
> have to give your private key for stastny.com to you SIP provider.
> Furthermore, plain TLS requires the server to send the certificate
> without any knowledge of which domain the UAC is trying to contact.
> Thus, provB needs a dedicated socket for each hosted domain on its
> border proxy to differ the requests and present the proper certificate.
> IMO that does not scale. It can be avoided using the "server_name" TLS
> extension, but this is e.g. not supported in openssl which is used most
> for proxy servers.
> 
> This could be also solved by changing RFC 3263 to validate the
> certificate against the domain name revealed after SRV lookups. This was
> forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
> in DNS, not in SIP."
> 
> Richard
> 
> 
> 
> ________________________________
> 
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Fr 09.12.2005 13:40
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> Stastny Richard wrote:
> 
>>Thanx Klaus
>>
>>for the work ;-)
>>
>>Now the next question:
>>What are the implications proxy vs redirect
>>if you are using TLS?
> 
> 
> Now it's getting complicated ;-)
> 
> With the redirect server, there will be 2 TLS handshakes:
>    1. borderProxyA       redirectProxy
>    2. borderProxyA       borderProxyB
> 
> With the forwarding proxy, one TLS connection is mandatory:
>    1. borderProxyA       forwardingProxy
> 
> If the forwardin proxy is within the network of provB, there is no need
> to use TLS inside the network of prov if other means can be used to
> authetnicate (e.g. src_IP). But, if the forwarding proxy stays of of
> signaling for in-dialog messages, there is also a must for the second
> TLS conenction between
>    2. borderProxyA       borderProxyB
> 
> The more complicated thing is the certificate validation. RFC 3263
> mandates, that the SIP domain (before NAPTR, SRV lookups) must be
> identical to the domain in the certificate. If provB hosts thousands of
> SIP domains for its clients, e.g. sip:fobar@stastny.com,
> sip:foobar@darilion.com, .... and requires TLS for incoming connections,
> provB must present a valid certificate for all hosted domains. Thus, you
> have to give your private key for stastny.com to you SIP provider.
> Furthermore, plain TLS requires the server to send the certificate
> without any knowledge of which domain the UAC is trying to contact.
> Thus, provB needs a dedicated socket for each hosted domain on its
> border proxy to differ the requests and present the proper certificate.
> IMO that does not scale. It can be avoided using the "server_name" TLS
> extension, but this is e.g. not supported in openssl which is used most
> for proxy servers.
> 
> This could be also solved by changing RFC 3263 to validate the
> certificate against the domain name revealed after SRV lookups. This was
> forbidden to detect DNS spoofing, but IMO DNS problems should be fixed
> in DNS, not in SIP.
> 
> regards
> klaus
> 
> 
>>Richard
>>
>>________________________________
>>
>>Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
>>Gesendet: Fr 09.12.2005 12:52
>>An: Stastny Richard
>>Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
>>Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>>
>>
>>
>>Stastny Richard wrote:
>>
>>
>>>Thanx Klaus
>>>
>>>Also for answering a question I did not (yet) ask
>>>regarding redirect vs proxy
>>>
>>>
>>>
>>>
>>>
>>>>I personally prefer relaying instead of redirect.
>>>
>>>
>>>Me too and I see your arguments.
>>>Are there any arguments out there why to prefer redriect?
>>
>>
>>I just made some signaling pictures to visualize the difference:
>> From the signaling, there is no big difference. Both versions do need
>>approximately the same amount of signaling packets sent (depends onthe
>>actual SIP network design).
>>
>>I do not see any technical reason why to prefer one version over the
>>other. It's just a personal preference.
>>
>>regards
>>klaus
>>
>>
>>UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
>>|        |          |                  |             |        |      |
>>|-INVITE>|          |                  |             |        |        |
>>|<-100---|-INVITE-->|                  |             |        |        |
>>|        |<--100----|-------INVITE---->|             |        |        |
>>|        |          |                  |             |        |        |
>>|        |          |<------302--------|             |        |        |
>>|        |<-302-----|-------ACK------->|             |        |        |
>>|        |--ACK---->|                  |             |        |        |
>>|        |--INVITE->|                  |             |        |        |
>>|        |<-100-----|--------------INVITE----------->|        |        |
>>|        |          |<--------------100--------------|-INVITE>|        |
>>|        |          |                  |             |<-100---|-INVITE>|
>>|        |          |                  |             |        |<-100---|
>>|        |          |                  |             |        |        |
>>|        |          |                  |             |        |<-180---|
>>|        |          |                  |             |<--180--|        |
>>|        |          |<---------------180-------------|        |        |
>>|        |<--180----|                  |             |        |        |
>>|<--180--|          |                  |             |        |<--200--|
>>|        |          |                  |             |<--200--|        |
>>|        |          |<---------------200-------------|        |        |
>>|        |<---200---|                  |             |        |        |
>>|<---200-|          |                  |             |        |        |
>>|        |          |                  |             |        |        |
>>|--ACK-->|          |                  |             |        |        |
>>|        |----ACK-->|                  |             |        |        |
>>|        |          |--------------ACK-------------->|        |        |
>>|        |          |                  |             |--ACK-->|        |
>>|        |          |                  |             |        |--ACK-->|
>>|        |          |                  |             |        |        |
>>|        |          |                  |             |        |        |
>>|        |          |                  |             |        |        |
>>
>>32 Packets
>>
>>
>>UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
>>|        |          |                  |             |        |        |
>>|-INVITE>|          |                  |             |        |        |
>>|<-100---|-INVITE-->|                  |             |        |        |
>>|        |<--100----|-------INVITE---->|             |        |        |
>>|        |          |<-------100-------|---INVITE--->|        |        |
>>|        |          |                  |<----100-----|-INVITE>|        |
>>|        |          |                  |             |<-100---|-INVITE>|
>>|        |          |                  |             |        |<-100---|
>>|        |          |                  |             |        |        |
>>|        |          |                  |             |        |<-180---|
>>|        |          |                  |             |<--180--|        |
>>|        |          |                  |<---180------|        |        |
>>|        |          |<----- -180-------|             |        |        |
>>|        |<--180----|                  |             |        |        |
>>|<--180--|          |                  |             |        |<--200--|
>>|        |          |                  |             |<--200--|        |
>>|        |          |                  |<---200------|        |        |
>>|        |          |<-------200-------|             |        |        |
>>|        |<---200---|                  |             |        |        |
>>|<---200-|          |                  |             |        |        |
>>|        |          |                  |             |        |        |
>>|--ACK-->|          |                  |             |        |        |
>>|        |----ACK-->|                  |             |        |        |
>>|        |          |--------------ACK-------------->|        |        |
>>|        |          |                  |             |--ACK-->|        |
>>|        |          |                  |             |        |--ACK-->|
>>
>>29 Packets
>>
>>
>>
>>
> 
> 
> 
> 
> 


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 10:02:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjlN-0001fD-O1; Fri, 09 Dec 2005 10:02:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkjlL-0001ZW-4E; Fri, 09 Dec 2005 10:02:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16382;
	Fri, 9 Dec 2005 10:01:25 -0500 (EST)
Received: from vivo117.gprs.dnafinland.fi ([62.78.127.117]
	helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkjlR-0006xm-Nh; Fri, 09 Dec 2005 10:02:31 -0500
Received: from rautu.tutpro.com (jh@localhost [127.0.0.1])
	by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id
	jB9ExnPC004394; Fri, 9 Dec 2005 16:59:49 +0200
Received: (from jh@localhost)
	by rautu.tutpro.com (8.13.4/8.13.4/Submit) id jB9ExnC0004391;
	Fri, 9 Dec 2005 16:59:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17305.39909.629606.843484@rautu.tutpro.com>
Date: Fri, 9 Dec 2005 16:59:49 +0200
From: Juha Heinanen <jh@tutpro.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
In-Reply-To: <43998FD7.20207@cisco.com>
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > Also, as it happens, while
 > 	sip:+4312345@provA.com
 > 	sip:+4312345@provA.com;user=phone
 > are not equal by uri comparison rules, they are equal according to the 
 > rules that 3261 applies to the targets of registration. So, you can't 
 > really have them mean different things.

if UA is to send a request to sip:+4312345@provA.com, it MUST send it to
provA.com.  in case of sip:+4312345@provA.com;user=phone, it can (and
usually MUST) send it wherever it is sending requests to e.164 numbers,
i.e., where it would send tel:+4312345, because the UA may not have any
deal to use provA.com as its outbound proxy.

  -- 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



From sip-bounces@ietf.org Fri Dec 09 10:29:08 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkkBI-0008Tw-CJ; Fri, 09 Dec 2005 10:29:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkkBG-0008LU-Tc; Fri, 09 Dec 2005 10:29:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19327;
	Fri, 9 Dec 2005 10:28:05 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkkBK-0007rT-PS; Fri, 09 Dec 2005 10:29:12 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 09 Dec 2005 07:28:47 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB9FSBQm000204;
	Fri, 9 Dec 2005 07:28:44 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 07:28:43 -0800
Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 07:28:42 -0800
Message-ID: <4399A2AA.1020506@cisco.com>
Date: Fri, 09 Dec 2005 10:28:42 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>	<43998FD7.20207@cisco.com>
	<17305.39909.629606.843484@rautu.tutpro.com>
In-Reply-To: <17305.39909.629606.843484@rautu.tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2005 15:28:42.0751 (UTC)
	FILETIME=[3CC208F0:01C5FCD5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Juha Heinanen wrote:
> Paul Kyzivat writes:
> 
>  > Also, as it happens, while
>  > 	sip:+4312345@provA.com
>  > 	sip:+4312345@provA.com;user=phone
>  > are not equal by uri comparison rules, they are equal according to the 
>  > rules that 3261 applies to the targets of registration. So, you can't 
>  > really have them mean different things.
> 
> if UA is to send a request to sip:+4312345@provA.com, it MUST send it to
> provA.com.  in case of sip:+4312345@provA.com;user=phone, it can (and
> usually MUST) send it wherever it is sending requests to e.164 numbers,
> i.e., where it would send tel:+4312345, because the UA may not have any
> deal to use provA.com as its outbound proxy.

I disagree with you Juha. AFAIK the routing of *either* form MUST be 
routed solely based on the provA.com domain. Unless you are responsible 
for the domain in question you are not to interpret the user part in any 
way. There is no dispensation to violate this when the user=phone 
parameter is present.

	Paul

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 10:52:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkkXc-0007fO-Jm; Fri, 09 Dec 2005 10:52:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkXa-0007cm-TM
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 10:52:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22023
	for <sip@ietf.org>; Fri, 9 Dec 2005 10:51:11 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkkXg-0000HK-DT
	for sip@ietf.org; Fri, 09 Dec 2005 10:52:18 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id C7ADC6C01D
	for <sip@ietf.org>; Fri,  9 Dec 2005 10:51:52 -0500 (EST)
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
From: "Dale R. Worley" <dworley@pingtel.com>
To: Sip <sip@ietf.org>
In-Reply-To: <4399A2AA.1020506@cisco.com>
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com>
	<4399A2AA.1020506@cisco.com>
Content-Type: text/plain
Date: Fri, 09 Dec 2005 10:51:52 -0500
Message-Id: <1134143512.919.1.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Fri, 2005-12-09 at 10:28 -0500, Paul Kyzivat wrote:
> > if UA is to send a request to sip:+4312345@provA.com, it MUST send it to
> > provA.com.  in case of sip:+4312345@provA.com;user=phone, it can (and
> > usually MUST) send it wherever it is sending requests to e.164 numbers,
> > i.e., where it would send tel:+4312345, because the UA may not have any
> > deal to use provA.com as its outbound proxy.
> 
> I disagree with you Juha. AFAIK the routing of *either* form MUST be 
> routed solely based on the provA.com domain. Unless you are responsible 
> for the domain in question you are not to interpret the user part in any 
> way. There is no dispensation to violate this when the user=phone 
> parameter is present.

RFC 3273 seems to me to come down very strongly in favor of Paul's
position.  The only escape would be a later RFC that specifically
authorized an agent that is not authoritative for provA.com to interpret
the URI differently.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 11:12:55 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekkrf-0006RO-NZ; Fri, 09 Dec 2005 11:12:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkrN-00068N-Uj
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 11:12:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24678
	for <sip@ietf.org>; Fri, 9 Dec 2005 11:11:34 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkkrR-0000wb-2W
	for sip@ietf.org; Fri, 09 Dec 2005 11:12:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 17:15:56 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX82ntLLNtCwKkDQmisOIOn/tkR3gAAHdcV
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Dale R. Worley" <dworley@pingtel.com>, "Sip" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

My take on this:
=20
A user enters a phone number, the UA sends it by default
to his provider A with
sip:+4312345@provA.com;user=3Dphone
=20
proxy A of Provider A interprets this as an E.164 number and
does whatever he is programmed to do with this:
=20
1. forward it to his own gateway sip:+4312345@gw.provA.com;user=3Dphone
2. forward it to another proxy with a gateway =
sip:+4312345@GWprov.com;user=3Dphone
3. query ENUM
in this case he may either get back sip:foo@provB.com
or
sip:+4312345@provB.com;user=3Dphone
or
sip:+4312345@ingress14.provB.com;user=3Dphone
=20
Richard

________________________________

Von: sip-bounces@ietf.org im Auftrag von Dale R. Worley
Gesendet: Fr 09.12.2005 16:51
An: Sip
Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try



On Fri, 2005-12-09 at 10:28 -0500, Paul Kyzivat wrote:
> > if UA is to send a request to sip:+4312345@provA.com, it MUST send =
it to
> > provA.com.  in case of sip:+4312345@provA.com;user=3Dphone, it can =
(and
> > usually MUST) send it wherever it is sending requests to e.164 =
numbers,
> > i.e., where it would send tel:+4312345, because the UA may not have =
any
> > deal to use provA.com as its outbound proxy.
>
> I disagree with you Juha. AFAIK the routing of *either* form MUST be
> routed solely based on the provA.com domain. Unless you are =
responsible
> for the domain in question you are not to interpret the user part in =
any
> way. There is no dispensation to violate this when the user=3Dphone
> parameter is present.

RFC 3273 seems to me to come down very strongly in favor of Paul's
position.  The only escape would be a later RFC that specifically
authorized an agent that is not authoritative for provA.com to interpret
the URI differently.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 11:43:08 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EklKu-000896-9r; Fri, 09 Dec 2005 11:43:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EklKo-000835-NV; Fri, 09 Dec 2005 11:43:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29004;
	Fri, 9 Dec 2005 11:41:57 -0500 (EST)
Received: from dhcp6.tutpro.com
	([192.98.100.133] helo=rautu.tutpro.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EklKk-000268-TT; Fri, 09 Dec 2005 11:43:05 -0500
Received: from rautu.tutpro.com (jh@localhost [127.0.0.1])
	by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id
	jB9FhvpK010229; Fri, 9 Dec 2005 17:43:57 +0200
Received: (from jh@localhost)
	by rautu.tutpro.com (8.13.4/8.13.4/Submit) id jB9FhBt9010224;
	Fri, 9 Dec 2005 17:43:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17305.42511.328358.495586@rautu.tutpro.com>
Date: Fri, 9 Dec 2005 17:43:11 +0200
From: Juha Heinanen <jh@tutpro.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
In-Reply-To: <4399A2AA.1020506@cisco.com>
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com>
	<17305.39909.629606.843484@rautu.tutpro.com>
	<4399A2AA.1020506@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > I disagree with you Juha. AFAIK the routing of *either* form MUST be 
 > routed solely based on the provA.com domain. Unless you are responsible 
 > for the domain in question you are not to interpret the user part in any 
 > way. There is no dispensation to violate this when the user=phone 
 > parameter is present.

i'm pretty sure that i have read in some rfc that
sip:+<digits>@<domain>;user=phone is EQUIVALENT with tel:+<number>,
i.e., they are two textual representations of the same thing, but can't
check it now, because i'm travelling in train.

i have seen some SIP UAs to use sip:+<digits>@<domain>;user=phone format
in 302, when the user has made call redirect to a PSTN number.  if this
302 is received by someone in another domain, it cannot reach pstn via
the proxy of the other domain.  so it must interpret
sip:+<digits>@<domain>;user=phone as a tel uri and use its own proxy.

-- 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



From sip-bounces@ietf.org Fri Dec 09 11:58:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EklZv-0005so-4J; Fri, 09 Dec 2005 11:58:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EklZt-0005s9-Pw
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 11:58:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00612
	for <sip@ietf.org>; Fri, 9 Dec 2005 11:57:43 -0500 (EST)
Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekla6-0002Yg-Rv
	for sip@ietf.org; Fri, 09 Dec 2005 11:58:52 -0500
Received: from jh by harjus.tutpro.com with local (Exim 4.50)
	id 1EklZm-0000Zz-4y; Fri, 09 Dec 2005 18:58:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17305.47030.91954.594814@harjus.tutpro.com>
Date: Fri, 9 Dec 2005 18:58:30 +0200
To: "Stastny Richard" <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
References: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: Juha Heinanen <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Stastny Richard writes:

 > A user enters a phone number, the UA sends it by default
 > to his provider A with
 > sip:+4312345@provA.com;user=phone

that is fine if the user is placing the call, but how about when the
user wants to refer the calling party with 302 to his number on pstn
network?  

last time i checked, phones from paul's company use sip uri format,
which according to paul's interpretation must be routed to whatever host
part is listed there, which for sure get blocked by the proxy if the
caller belongs to a different domain.

-- 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



From sip-bounces@ietf.org Fri Dec 09 12:55:17 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmSi-0000xK-UD; Fri, 09 Dec 2005 12:55:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmSH-0000tr-Uu; Fri, 09 Dec 2005 12:55:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07681;
	Fri, 9 Dec 2005 12:53:43 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkmSJ-0004fO-9W; Fri, 09 Dec 2005 12:54:52 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id 60CB86C017;
	Fri,  9 Dec 2005 12:54:29 -0500 (EST)
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
From: "Dale R. Worley" <dworley@pingtel.com>
To: Juha Heinanen <jh@tutpro.com>
In-Reply-To: <17305.42511.328358.495586@rautu.tutpro.com>
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com> <17305.39909.629606.843484@rautu.tutpro.com>
	<4399A2AA.1020506@cisco.com>
	<17305.42511.328358.495586@rautu.tutpro.com>
Content-Type: text/plain
Date: Fri, 09 Dec 2005 12:54:29 -0500
Message-Id: <1134150869.919.18.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, Sip <sip@ietf.org>,
	Paul Kyzivat <pkyzivat@cisco.com>,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Fri, 2005-12-09 at 17:43 +0200, Juha Heinanen wrote:
> i'm pretty sure that i have read in some rfc that
> sip:+<digits>@<domain>;user=phone is EQUIVALENT with tel:+<number>,
> i.e., they are two textual representations of the same thing, but can't
> check it now, because i'm travelling in train.

A lot of RFCs hint at such a thing.  The closest I've seen is section 3
of RFC 3824.  But the general drift is not that they are *equivalent*,
but that the tel: URI can be mapped into the sip: URI; there seems to be
no hint that the mapping can be reversed.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 12:55:43 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmT9-00012o-FI; Fri, 09 Dec 2005 12:55:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmT1-0000zu-Tl; Fri, 09 Dec 2005 12:55:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07886;
	Fri, 9 Dec 2005 12:54:41 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkmTD-0004h5-Qb; Fri, 09 Dec 2005 12:55:50 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 09:55:22 -0800
X-IronPort-AV: i="3.99,235,1131350400"; 
	d="scan'208"; a="239305897:sNHT1541909740"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB9HseBn013616;
	Fri, 9 Dec 2005 09:55:18 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 09:55:16 -0800
Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 09:55:15 -0800
Message-ID: <4399C502.1060702@cisco.com>
Date: Fri, 09 Dec 2005 12:55:14 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>	<43998FD7.20207@cisco.com>	<17305.39909.629606.843484@rautu.tutpro.com>	<4399A2AA.1020506@cisco.com>
	<17305.42511.328358.495586@rautu.tutpro.com>
In-Reply-To: <17305.42511.328358.495586@rautu.tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2005 17:55:15.0670 (UTC)
	FILETIME=[B5BEFF60:01C5FCE9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Juha Heinanen wrote:
> Paul Kyzivat writes:
> 
>  > I disagree with you Juha. AFAIK the routing of *either* form MUST be 
>  > routed solely based on the provA.com domain. Unless you are responsible 
>  > for the domain in question you are not to interpret the user part in any 
>  > way. There is no dispensation to violate this when the user=phone 
>  > parameter is present.
> 
> i'm pretty sure that i have read in some rfc that
> sip:+<digits>@<domain>;user=phone is EQUIVALENT with tel:+<number>,

I forget where that is. 3261 isn't the full story - it got clarified 
somewhere.

The point is that if the user=phone parameter is present, then the user 
part MUST conform to the tel syntax. But that is really a constraint on 
the owner of the domain, because others shouldn't be interpretting the 
user part, even to determine its validity.

> i.e., they are two textual representations of the same thing, but can't
> check it now, because i'm travelling in train.
> 
> i have seen some SIP UAs to use sip:+<digits>@<domain>;user=phone format
> in 302, when the user has made call redirect to a PSTN number.  if this
> 302 is received by someone in another domain, it cannot reach pstn via
> the proxy of the other domain.  so it must interpret
> sip:+<digits>@<domain>;user=phone as a tel uri and use its own proxy.

This is a good argument for not doing this.

Putting this form in the 302 is exactly the right thing to do if you 
want to *force* the recipient to go to the specified domain. And there 
could be reasons why you might want to do that. E.g. you want to use 
media only available via SIP, or you want to use SIPS for security.

If you don't want to force the caller to do that, and want to allow the 
option for the caller to reach you indirectly via the PSTN, then you 
ought to use a tel uri. Then the user that gets it has lots of options.

	Paul

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 12:57:48 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmVA-0001Cr-Ou; Fri, 09 Dec 2005 12:57:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmV8-0001Ch-6W
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 12:57:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08152
	for <sip@ietf.org>; Fri, 9 Dec 2005 12:56:43 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkmVD-0004mB-LK
	for sip@ietf.org; Fri, 09 Dec 2005 12:57:52 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id DE8816C021;
	Fri,  9 Dec 2005 12:57:35 -0500 (EST)
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
From: "Dale R. Worley" <dworley@pingtel.com>
To: Juha Heinanen <jh@tutpro.com>
In-Reply-To: <17305.47030.91954.594814@harjus.tutpro.com>
References: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
	<17305.47030.91954.594814@harjus.tutpro.com>
Content-Type: text/plain
Date: Fri, 09 Dec 2005 12:57:35 -0500
Message-Id: <1134151055.919.23.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Stastny Richard <Richard.Stastny@oefeg.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Fri, 2005-12-09 at 18:58 +0200, Juha Heinanen wrote:
> that is fine if the user is placing the call, but how about when the
> user wants to refer the calling party with 302 to his number on pstn
> network?  

It seems to me that if the referrer wants the calling party to try to
get to a PSTN number with the best routing as seen from the calling
party's UA, it should send a tel: URI.  If a UA cannot send a tel: URI,
that is a deficiency in the UA.

This seems to be the same sort of problem as the dichotomy between a
host name and the IP address of one of its network interfaces -- if you
mean a specific interface (and hence specific network path), use the IP
address; if you mean to permit any route to the host, use its name.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:03:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmaS-0001jH-Bu; Fri, 09 Dec 2005 13:03:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmaL-0001iz-Ux; Fri, 09 Dec 2005 13:03:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08490;
	Fri, 9 Dec 2005 13:02:15 -0500 (EST)
Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EkmaZ-0004vc-6q; Fri, 09 Dec 2005 13:03:24 -0500
Received: from jh by harjus.tutpro.com with local (Exim 4.50)
	id 1Ekma8-00017x-JK; Fri, 09 Dec 2005 20:02:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17305.50896.571552.38180@harjus.tutpro.com>
Date: Fri, 9 Dec 2005 20:02:56 +0200
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
In-Reply-To: <4399C502.1060702@cisco.com>
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com>
	<17305.39909.629606.843484@rautu.tutpro.com>
	<4399A2AA.1020506@cisco.com>
	<17305.42511.328358.495586@rautu.tutpro.com>
	<4399C502.1060702@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: Juha Heinanen <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > If you don't want to force the caller to do that, and want to allow the 
 > option for the caller to reach you indirectly via the PSTN, then you 
 > ought to use a tel uri. Then the user that gets it has lots of
 > options.

yes, that is what i have figured out too.  the problem is that there is
lots of sip phones on the market that don't support tel uris although
this application clearly requires the use of them.  

the root of the problem lies with rfc3261 that doesn't mandate that sip
ua support tel uris (it is MAY) although this application clearly shows
that tel uri support is mandatory in any sip ua.

-- 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



From sip-bounces@ietf.org Fri Dec 09 13:19:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmqZ-0006Ps-Gm; Fri, 09 Dec 2005 13:19:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkmqW-0006FM-Ec; Fri, 09 Dec 2005 13:19:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10269;
	Fri, 9 Dec 2005 13:18:53 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ekmqd-0005d5-VN; Fri, 09 Dec 2005 13:20:02 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 10:19:28 -0800
X-IronPort-AV: i="3.99,235,1131350400"; 
	d="scan'208"; a="239319519:sNHT1182596242"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB9IIxMu020501;
	Fri, 9 Dec 2005 10:19:25 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 13:19:05 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 13:19:03 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0E93@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX84WOnltFqCuSbSHKDfno6PulYyQAC3mPQ
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Juha Heinanen" <jh@tutpro.com>,
	"Paul Kyzivat \(pkyzivat\)" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 09 Dec 2005 18:19:05.0430 (UTC)
	FILETIME=[09F30F60:01C5FCED]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org,
	Klaus Darilion <klaus.mailinglists@pernau.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Juha,

That was in the yu-np-08 draft now dead, but did not survive to the
present draft np-07.  Even so, it described how to map from tel: into
sip: but not vice versa.

Mike


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Juha Heinanen
> Sent: Friday, December 09, 2005 10:43 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20
> enum@ietf.org; Klaus Darilion
> Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>=20
> Paul Kyzivat writes:
>=20
>  > I disagree with you Juha. AFAIK the routing of *either*=20
> form MUST be  > routed solely based on the provA.com domain.=20
> Unless you are responsible  > for the domain in question you=20
> are not to interpret the user part in any  > way. There is no=20
> dispensation to violate this when the user=3Dphone  > parameter=20
> is present.
>=20
> i'm pretty sure that i have read in some rfc that=20
> sip:+<digits>@<domain>;user=3Dphone is EQUIVALENT with=20
> tel:+<number>, i.e., they are two textual representations of=20
> the same thing, but can't check it now, because i'm=20
> travelling in train.
>=20
> i have seen some SIP UAs to use=20
> sip:+<digits>@<domain>;user=3Dphone format in 302, when the=20
> user has made call redirect to a PSTN number.  if this
> 302 is received by someone in another domain, it cannot reach=20
> pstn via the proxy of the other domain.  so it must interpret=20
> sip:+<digits>@<domain>;user=3Dphone as a tel uri and use its own =
proxy.
>=20
> -- juha
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:36:15 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekn6N-0007FH-JT; Fri, 09 Dec 2005 13:36:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekn6I-00073b-Cd; Fri, 09 Dec 2005 13:36:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12543;
	Fri, 9 Dec 2005 13:35:15 -0500 (EST)
Received: from 65-118-85-140.dia.cust.qwest.net ([65.118.85.140]
	helo=FILEVAULT.windows.deltel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ekn6V-0006JS-K0; Fri, 09 Dec 2005 13:36:25 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 10:35:48 -0800
Message-ID: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
thread-index: AcX84nHqNtMi51ZnRp+QvykWgs7kWAACqElA
From: "Tolga Tarhan" <Tolga.Tarhan@deltel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
Cc: Sip <sip@ietf.org>, enum@ietf.org,
	Stastny Richard <Richard.Stastny@oefeg.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

All,

Just to be clear, let me define my understanding of Juha's scenario:

1) UserA@provA sends an invite to his local proxy (provA) for
UserB@provB.

2) UserB has told his provider that he wants all of his calls redirected
to his PSTN number.  Clearly, userB's intent is that the call be
completed through a media gateway to the PSTN.  For this example, let's
say the number was +17205551212.

3) provB receives the request from provA and now needs to send a
redirect to the PSTN number.  Assume for this example that provA and
provB have no business relationship, and therefore, provB will not
accept a call to the PSTN from provA.


That being said, probably the simplest thing that provB can do is use a
tel: URI in the redirect.  That avoids all ambiguity and logically
requests that provA use a local media gateway to complete the call to
the PSTN.

If the tel: URI is not an option for some reason, then provB should send
the redirect to sip:+17205551212@provA;user=3Dphone.  Notice the use of
provA, which the proxy at provB would have to derive, presumably using
the "From" header.  I don't think this is a good option, because there
may be no reliable way to consistently derive the correct URI.

I have to side with Paul, however, in saying that IF the redirect from
provB actually refers to sip:+17205551212@provB (regardless of the
presence of a user attribute), then the RFC is fairly clear -- the
request that results from the redirect must be sent to provB, which will
almost certainly fail.

--
Tolga Tarhan

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Juha Heinanen
Sent: Friday, December 09, 2005 8:59 AM
To: Stastny Richard
Cc: Sip
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard writes:

 > A user enters a phone number, the UA sends it by default
 > to his provider A with
 > sip:+4312345@provA.com;user=3Dphone

that is fine if the user is placing the call, but how about when the
user wants to refer the calling party with 302 to his number on pstn
network? =20

last time i checked, phones from paul's company use sip uri format,
which according to paul's interpretation must be routed to whatever host
part is listed there, which for sure get blocked by the proxy if the
caller belongs to a different domain.

-- 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

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:44:27 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknEJ-0002eZ-6R; Fri, 09 Dec 2005 13:44:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EknEF-0002dY-Dt
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 13:44:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13556
	for <sip@ietf.org>; Fri, 9 Dec 2005 13:43:20 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EknEK-0006b5-PI for sip@ietf.org; Fri, 09 Dec 2005 13:44:30 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 09 Dec 2005 10:44:05 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB9IhQBh023048;
	Fri, 9 Dec 2005 10:44:02 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 10:43:50 -0800
Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 10:43:50 -0800
Message-ID: <4399D065.9040506@cisco.com>
Date: Fri, 09 Dec 2005 13:43:49 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2005 18:43:50.0570 (UTC)
	FILETIME=[7F2970A0:01C5FCF0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Stastny Richard wrote:
> My take on this:
>  
> A user enters a phone number, the UA sends it by default
> to his provider A with
> sip:+4312345@provA.com;user=phone

The key here is that the phone is *creating* a uri in this domain. To do 
so it must be considered part of the domain in order to interpret the 
user part of the uri. It then sends it to a server that is also 
permitted to interpret the user part.

It *could* also just use tel:+4312345. In that case anybody can 
interpret the number because its meaning is defined by a standard.

> proxy A of Provider A interprets this as an E.164 number and
> does whatever he is programmed to do with this:
>  
> 1. forward it to his own gateway sip:+4312345@gw.provA.com;user=phone
> 2. forward it to another proxy with a gateway sip:+4312345@GWprov.com;user=phone

In other words, if it wants to pass this to another domain using the sip 
form, and wants the other domain to interpret it as a phone number, then 
it needs to rewrite the URI to a form that the receiving network uses to 
represent phone numbers. Knowing if/how/when this can be done requires 
some kind of agreement (implicit or explicit) between the source network 
and the destination network.

Again, this *could* also be done by rewriting as a tel uri before 
passing to the other network.

	Paul

> 3. query ENUM
> in this case he may either get back sip:foo@provB.com
> or
> sip:+4312345@provB.com;user=phone
> or
> sip:+4312345@ingress14.provB.com;user=phone
>  
> Richard
> 
> ________________________________
> 
> Von: sip-bounces@ietf.org im Auftrag von Dale R. Worley
> Gesendet: Fr 09.12.2005 16:51
> An: Sip
> Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> On Fri, 2005-12-09 at 10:28 -0500, Paul Kyzivat wrote:
> 
>>>if UA is to send a request to sip:+4312345@provA.com, it MUST send it to
>>>provA.com.  in case of sip:+4312345@provA.com;user=phone, it can (and
>>>usually MUST) send it wherever it is sending requests to e.164 numbers,
>>>i.e., where it would send tel:+4312345, because the UA may not have any
>>>deal to use provA.com as its outbound proxy.
>>
>>I disagree with you Juha. AFAIK the routing of *either* form MUST be
>>routed solely based on the provA.com domain. Unless you are responsible
>>for the domain in question you are not to interpret the user part in any
>>way. There is no dispensation to violate this when the user=phone
>>parameter is present.
> 
> 
> RFC 3273 seems to me to come down very strongly in favor of Paul's
> position.  The only escape would be a later RFC that specifically
> authorized an agent that is not authoritative for provA.com to interpret
> the URI differently.
> 
> Dale
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:49:45 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknJR-0004F8-NA; Fri, 09 Dec 2005 13:49:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EknJP-0004Eg-6D
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 13:49:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14220
	for <sip@ietf.org>; Fri, 9 Dec 2005 13:48:40 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EknJU-0006nU-Uw
	for sip@ietf.org; Fri, 09 Dec 2005 13:49:50 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 10:49:23 -0800
X-IronPort-AV: i="3.99,235,1131350400"; 
	d="scan'208"; a="239329946:sNHT310135730"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB9Imrq5028304;
	Fri, 9 Dec 2005 10:49:22 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 10:49:20 -0800
Received: from [10.21.121.11] ([10.21.121.11]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 10:49:19 -0800
Message-ID: <4399D1AE.4040804@cisco.com>
Date: Fri, 09 Dec 2005 13:49:18 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>
	<17305.47030.91954.594814@harjus.tutpro.com>
In-Reply-To: <17305.47030.91954.594814@harjus.tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2005 18:49:19.0679 (UTC)
	FILETIME=[43537CF0:01C5FCF1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Stastny Richard <Richard.Stastny@oefeg.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Juha Heinanen wrote:
> Stastny Richard writes:
> 
>  > A user enters a phone number, the UA sends it by default
>  > to his provider A with
>  > sip:+4312345@provA.com;user=phone
> 
> that is fine if the user is placing the call, but how about when the
> user wants to refer the calling party with 302 to his number on pstn
> network?  
> 
> last time i checked, phones from paul's company use sip uri format,

yes, I know they do. Maybe someday I will prevail. :-(

> which according to paul's interpretation must be routed to whatever host
> part is listed there, which for sure get blocked by the proxy if the
> caller belongs to a different domain.

There is no requirement for the UA to deliver the request *directly* to 
that address. It is perfectly free to put this request into the R-URI 
and then deliver the request to its own proxy. Then that proxy can deal 
with the routing.

	Paul

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:51:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknLD-0004bE-W0; Fri, 09 Dec 2005 13:51:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknLA-0004b1-LP; Fri, 09 Dec 2005 13:51:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14543;
	Fri, 9 Dec 2005 13:50:37 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EknLO-0006rZ-0b; Fri, 09 Dec 2005 13:51:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 19:52:35 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C471E@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX84nHqNtMi51ZnRp+QvykWgs7kWAACqElAAAEpSZw=
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Tolga Tarhan" <Tolga.Tarhan@deltel.com>, "Juha Heinanen" <jh@tutpro.com>, 
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: quoted-printable
Cc: Sip <sip@ietf.org>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

The example below is very interesting, but not a very realistic one.
=20
As long a calls to the PSTN are charged, this will never work
with re-direct, only with forwarding (as it is now in the PSTN with
all such scenarios). In case of forwarding User B gets charged
=20
Richard

________________________________

Von: Tolga Tarhan [mailto:Tolga.Tarhan@deltel.com]
Gesendet: Fr 09.12.2005 19:35
An: Juha Heinanen; Paul Kyzivat
Cc: Sip; enum@ietf.org; Stastny Richard
Betreff: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try



All,

Just to be clear, let me define my understanding of Juha's scenario:

1) UserA@provA sends an invite to his local proxy (provA) for
UserB@provB.

2) UserB has told his provider that he wants all of his calls redirected
to his PSTN number.  Clearly, userB's intent is that the call be
completed through a media gateway to the PSTN.  For this example, let's
say the number was +17205551212.

3) provB receives the request from provA and now needs to send a
redirect to the PSTN number.  Assume for this example that provA and
provB have no business relationship, and therefore, provB will not
accept a call to the PSTN from provA.


That being said, probably the simplest thing that provB can do is use a
tel: URI in the redirect.  That avoids all ambiguity and logically
requests that provA use a local media gateway to complete the call to
the PSTN.

If the tel: URI is not an option for some reason, then provB should send
the redirect to sip:+17205551212@provA;user=3Dphone.  Notice the use of
provA, which the proxy at provB would have to derive, presumably using
the "From" header.  I don't think this is a good option, because there
may be no reliable way to consistently derive the correct URI.

I have to side with Paul, however, in saying that IF the redirect from
provB actually refers to sip:+17205551212@provB (regardless of the
presence of a user attribute), then the RFC is fairly clear -- the
request that results from the redirect must be sent to provB, which will
almost certainly fail.

--
Tolga Tarhan

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Juha Heinanen
Sent: Friday, December 09, 2005 8:59 AM
To: Stastny Richard
Cc: Sip
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard writes:

 > A user enters a phone number, the UA sends it by default
 > to his provider A with
 > sip:+4312345@provA.com;user=3Dphone

that is fine if the user is placing the call, but how about when the
user wants to refer the calling party with 302 to his number on pstn
network?=20

last time i checked, phones from paul's company use sip uri format,
which according to paul's interpretation must be routed to whatever host
part is listed there, which for sure get blocked by the proxy if the
caller belongs to a different domain.

-- 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



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:55:53 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknPN-0005RA-39; Fri, 09 Dec 2005 13:55:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknPH-0005Of-I4; Fri, 09 Dec 2005 13:55:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15185;
	Fri, 9 Dec 2005 13:54:52 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EknPV-00072Z-Kl; Fri, 09 Dec 2005 13:56:02 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 09 Dec 2005 10:55:36 -0800
X-IronPort-AV: i="3.99,235,1131350400"; 
	d="scan'208"; a="376241480:sNHT35167866"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9It1AA022619;
	Fri, 9 Dec 2005 10:55:32 -0800 (PST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 13:55:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip] SIP
	AoR, tel and ENUM
Date: Fri, 9 Dec 2005 13:55:28 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0EB9@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip]
	SIP AoR, tel and ENUM
Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQ
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <royrr@us.saic.com>, <henry@pulver.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 09 Dec 2005 18:55:29.0412 (UTC)
	FILETIME=[1FB44440:01C5FCF2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Is it not possible to be a domain owner and not provide any services?
(cyber-squatter?)

Being a domain owner is a bit removed from focus at hand.  The relevant
matter is that some entity is providing a service, be it data transport
or session setup, an application, or whatever.  I don't understand what
the hang up is with using plain English to describe what it is.  What
happens when you take the next step and start to distinguish between
public domain owners and private domain owners?  Do we start saying that
one entity is a transport domain owner versus a session setup domain
owner?  And what is it when they are both?  A session transport domain
owner?  What happens when the entity operates or supports many domains?

This could get really obtuse quickly.  I don't object to using the
domain owner as a litmus test for sorting out who is targeted with
requests.  But, let's not invent some affected form of speech just to
confuse the uninitiated.

Mike


> -----Original Message-----
> From: royrr@us.saic.com [mailto:royrr@us.saic.com]=20
> Sent: Friday, December 09, 2005 1:08 PM
> To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon;=20
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20
> enum@ietf.org
> Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum]=20
> Re: [Sip] SIP AoR, tel and ENUM
>=20
> Henry:
> =20
> I think that it is the time to write an informational RFC on=20
> this because it is confusing to use the loose words like=20
> "service providers" in the context of the public Internet in the IETF.
> =20
> Let us focus on the RFC what it should be like "Internet=20
> Domain Owner" and others in the context of IETF standardization works.
> =20
> Best regards,
> Radhika
>=20
>   _____ =20
>=20
> From: enum-bounces@ietf.org on behalf of Henry Sinnreich
> Sent: Tue 12/6/2005 5:29 PM
> To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny=20
> Richard'; enum@ietf.org
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
>=20
>=20
> Sorry for nitpicking:
>=20
> >A provider is a provider.
>=20
> A provider is a business model and att/SBC may differ from=20
> Google who uses a different business model (which is more=20
> significant measured in $$$?).
>=20
> Didn't we agree to use the term "Internet domain owner" (we=20
> could shorten to IDOM or such)?
>=20
> Internet domains are well defined in the IETF.
> Business models for VoIP are better suited for other=20
> organizations, consortia or innovators who work to disrupt them :-)
>=20
> Thanks, Henry
>=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 13:59:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EknT2-0006Fp-Fo; Fri, 09 Dec 2005 13:59:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EknSy-0006En-SS
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 13:59:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15625
	for <sip@ietf.org>; Fri, 9 Dec 2005 13:58:34 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EknT5-0007Cg-9I
	for sip@ietf.org; Fri, 09 Dec 2005 13:59:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Date: Fri, 9 Dec 2005 20:03:08 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C471F@oefeg-s04.oefeg.loc>
Thread-Topic: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX88RH6XS+vJH0VS0W2nlvA4uEPpgAAUFQH
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Paul,
=20
of course in all cases I mentioned a tel: URI could
(should?) be used.
=20
I made the examples with the sip URI=20

1. to show how it works with sip URI containing
tel Uris to make the point
=20
2. because this seems to be the currently used method,
because most UA and also most SIP proxys do not
interpret tel URI (I have no reason why)
=20
Richard

________________________________

Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Gesendet: Fr 09.12.2005 19:43
An: Stastny Richard
Cc: Dale R. Worley; Sip
Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try





Stastny Richard wrote:
> My take on this:
>=20
> A user enters a phone number, the UA sends it by default
> to his provider A with
> sip:+4312345@provA.com;user=3Dphone

The key here is that the phone is *creating* a uri in this domain. To do
so it must be considered part of the domain in order to interpret the
user part of the uri. It then sends it to a server that is also
permitted to interpret the user part.

It *could* also just use tel:+4312345. In that case anybody can
interpret the number because its meaning is defined by a standard.

> proxy A of Provider A interprets this as an E.164 number and
> does whatever he is programmed to do with this:
>=20
> 1. forward it to his own gateway =
sip:+4312345@gw.provA.com;user=3Dphone
> 2. forward it to another proxy with a gateway =
sip:+4312345@GWprov.com;user=3Dphone

In other words, if it wants to pass this to another domain using the sip
form, and wants the other domain to interpret it as a phone number, then
it needs to rewrite the URI to a form that the receiving network uses to
represent phone numbers. Knowing if/how/when this can be done requires
some kind of agreement (implicit or explicit) between the source network
and the destination network.

Again, this *could* also be done by rewriting as a tel uri before
passing to the other network.

        Paul

> 3. query ENUM
> in this case he may either get back sip:foo@provB.com
> or
> sip:+4312345@provB.com;user=3Dphone
> or
> sip:+4312345@ingress14.provB.com;user=3Dphone
>=20
> Richard
>
> ________________________________
>
> Von: sip-bounces@ietf.org im Auftrag von Dale R. Worley
> Gesendet: Fr 09.12.2005 16:51
> An: Sip
> Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>
>
>
> On Fri, 2005-12-09 at 10:28 -0500, Paul Kyzivat wrote:
>
>>>if UA is to send a request to sip:+4312345@provA.com, it MUST send it =
to
>>>provA.com.  in case of sip:+4312345@provA.com;user=3Dphone, it can =
(and
>>>usually MUST) send it wherever it is sending requests to e.164 =
numbers,
>>>i.e., where it would send tel:+4312345, because the UA may not have =
any
>>>deal to use provA.com as its outbound proxy.
>>
>>I disagree with you Juha. AFAIK the routing of *either* form MUST be
>>routed solely based on the provA.com domain. Unless you are =
responsible
>>for the domain in question you are not to interpret the user part in =
any
>>way. There is no dispensation to violate this when the user=3Dphone
>>parameter is present.
>
>
> RFC 3273 seems to me to come down very strongly in favor of Paul's
> position.  The only escape would be a later RFC that specifically
> authorized an agent that is not authoritative for provA.com to =
interpret
> the URI differently.
>
> Dale
>
>
>
> _______________________________________________
> 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
>



_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 09 19:47:31 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekstf-0007ZY-9O; Fri, 09 Dec 2005 19:47:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkstY-0007YE-SP; Fri, 09 Dec 2005 19:47:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16171;
	Fri, 9 Dec 2005 19:46:22 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eksti-00011k-A6; Fri, 09 Dec 2005 19:47:35 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2005 16:47:06 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,236,1131350400"; 
	d="scan'208"; a="16959432:sNHT26028828"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBA0ks4X008587; 
	Fri, 9 Dec 2005 19:46:54 -0500 (EST)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 9 Dec 2005 19:46:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Fri, 9 Dec 2005 19:46:53 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3DA0FC4@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0AAAUUlwA==
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: <henry@pulver.com>, <royrr@us.saic.com>,
	"Thilo Salmon" <salmon@sipgate.de>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>
X-OriginalArrivalTime: 10 Dec 2005 00:46:54.0373 (UTC)
	FILETIME=[3751FD50:01C5FD23]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Henry,

I try to follow discussion through the mail list and in what gets
reported in meeting notes, but must have missed where this terminology
was discussed and decided.  Could you provide me a pointer to which WG
meeting notes to review on this.

For the benefit of those that need to know this long after IETF 64 is
forgotten, this should be documented, so I support the idea of an
informational RFC.  It would be good to share this with other groups, so
we are all on the same sheet of music.  And I will be sure to use
initial caps to highlight use of the formal term.


> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com]=20
> Sent: Friday, December 09, 2005 7:11 PM
> To: Michael Hammer (mhammer); royrr@us.saic.com; 'Thilo=20
> Salmon'; 'Klaus Darilion'; royrr@us.saic.com
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny=20
> Richard'; enum@ietf.org
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Radhika has a good proposal:
>=20
> > I think that it is the time to write an informational RFC on this=20
> > because it is confusing to use the loose words like "service=20
> > providers" in the context of the public Internet in the IETF.
>=20
> I disagree with Mike:
>=20
> > But, let's not invent some affected form of speech just to=20
> confuse the=20
> > uninitiated.
>=20
> This list is followed by experts who understand the principle=20
> of peering services layer by layer, independently. This was=20
> discussed and agreed in the WG during the 64 IETF. It is also=20
> related to "Internet Neutrality".
>=20
> Service provider at what layer?
> 	- Internet access, or
> 	- Application layer (L5 for SIP and RTP) for VoIP?

Your own words indicate that services are provided at multiple layers.

> There are scenarios without any VoIP service provider, such=20
> as when two IT networks exchange VoIP traffic and much other=20
> stuff, and they have different ISPs as well. Lots of people=20
> do happily VoIP without a service provider (a la carrier=20
> offering VoIP in some "triple play").

"without a SP" with example of "carrier offering VoIP" seems
self-contradictory

> Neither does a home network or a community network qualify as=20
> a service provider though they are using VoIP outside their network.

So, if a service (e.g. Internet access) is provided for free, there is
no service provider?
But, if a service (e.g. Internet access) is provided for cost, an ISP is
a service provider?

This is when I feel like Alice in Wonderland.

But, I guess we can agree to disagree, and move on with what the
"experts" have chosen.

Mike

> The proposed informational RFC (by Radhika) needs to=20
> accommodate such scenarious and an _IT network_ or a _home=20
> network_ are not _VoIP service providers_ even if you may=20
> want to make it sound like it is.=20
>=20
> Thanks, Henry
> =20
>=20
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Friday, December 09, 2005 12:55 PM
> To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20
> enum@ietf.org
> Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE:=20
> [Enum] Re: [Sip] SIP AoR, tel and ENUM
>=20
> Is it not possible to be a domain owner and not provide any services?
> (cyber-squatter?)
>=20
> Being a domain owner is a bit removed from focus at hand. =20
> The relevant matter is that some entity is providing a=20
> service, be it data transport or session setup, an=20
> application, or whatever.  I don't understand what the hang=20
> up is with using plain English to describe what it is.  What=20
> happens when you take the next step and start to distinguish=20
> between public domain owners and private domain owners?  Do=20
> we start saying that one entity is a transport domain owner=20
> versus a session setup domain owner?  And what is it when=20
> they are both?  A session transport domain owner?  What=20
> happens when the entity operates or supports many domains?
>=20
> This could get really obtuse quickly.  I don't object to=20
> using the domain owner as a litmus test for sorting out who=20
> is targeted with requests.  But, let's not invent some=20
> affected form of speech just to confuse the uninitiated.
>=20
> Mike
>=20
>=20
> > -----Original Message-----
> > From: royrr@us.saic.com [mailto:royrr@us.saic.com]
> > Sent: Friday, December 09, 2005 1:08 PM
> > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; Klaus=20
> > Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard;=20
> > enum@ietf.org
> > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum]
> > Re: [Sip] SIP AoR, tel and ENUM
> >=20
> > Henry:
> > =20
> > I think that it is the time to write an informational RFC on this=20
> > because it is confusing to use the loose words like "service=20
> > providers" in the context of the public Internet in the IETF.
> > =20
> > Let us focus on the RFC what it should be like "Internet=20
> Domain Owner"=20
> > and others in the context of IETF standardization works.
> > =20
> > Best regards,
> > Radhika
> >=20
> >   _____
> >=20
> > From: enum-bounces@ietf.org on behalf of Henry Sinnreich
> > Sent: Tue 12/6/2005 5:29 PM
> > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard';=20
> > enum@ietf.org
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> >=20
> >=20
> >=20
> > Sorry for nitpicking:
> >=20
> > >A provider is a provider.
> >=20
> > A provider is a business model and att/SBC may differ from=20
> Google who=20
> > uses a different business model (which is more significant=20
> measured in=20
> > $$$?).
> >=20
> > Didn't we agree to use the term "Internet domain owner" (we could=20
> > shorten to IDOM or such)?
> >=20
> > Internet domains are well defined in the IETF.
> > Business models for VoIP are better suited for other organizations,=20
> > consortia or innovators who work to disrupt them :-)
> >=20
> > Thanks, Henry
> >=20
> >=20
>=20
>=20

_______________________________________________
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



From sip-bounces@ietf.org Sat Dec 10 12:13:45 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1El8I5-0002tu-PF; Sat, 10 Dec 2005 12:13:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1El8I3-0002tm-Gw
	for sip@megatron.ietf.org; Sat, 10 Dec 2005 12:13:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17067
	for <sip@ietf.org>; Sat, 10 Dec 2005 12:12:49 -0500 (EST)
From: rachel.anitha@flextronicssoftware.com
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1El8IS-0004fv-NU
	for sip@ietf.org; Sat, 10 Dec 2005 12:14:10 -0500
Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21])
	by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jBAHDPx01418
	for <sip@ietf.org>; Sat, 10 Dec 2005 22:43:25 +0530
To: sip@ietf.org
Message-ID: <OF50A18C9E.05BB9246-ON652570D3.005E9A01-652570D3.005E9A09@flextronicssoftware.com>
Date: Sat, 10 Dec 2005 22:43:18 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 12/10/2005 10:46:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [Sip] Rachel Anitha Ganapathy is out of the office.
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org





I will be out of the office starting  12/10/2005 and will not return until
12/14/2005.

Hello,

Thank you for your mail.

Please note that, i shall be out of office on 12th of Dec 2005 and 13th of
Dec 2005.

Should you need to contact me immediately, pleae call me on 9342247723.


I shall respond to your message after my return.

Apologies for the delay.

Thanks and regards
Rachel
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain  privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this
message in  error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted
by this email including damage from virus."


_______________________________________________
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



From sip-bounces@ietf.org Sun Dec 11 22:03:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EldyW-0006mb-No; Sun, 11 Dec 2005 22:03:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EldyU-0006ix-Gd
	for sip@megatron.ietf.org; Sun, 11 Dec 2005 22:03:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12143
	for <sip@ietf.org>; Sun, 11 Dec 2005 22:02:29 -0500 (EST)
Received: from [219.141.250.5] (helo=mail)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eldyz-0007OA-9s
	for sip@ietf.org; Sun, 11 Dec 2005 22:04:10 -0500
Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.5.23])
	by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May
	7 2001)) with ESMTPA id <0IRD0087W70KEW@mail.cecwireless.com.cn> for
	sip@ietf.org; Mon, 12 Dec 2005 11:00:22 +0800 (CST)
Date: Mon, 12 Dec 2005 11:00:28 +0800
From: Chen Shuping <shuping.chen@cecwireless.com.cn>
To: sip@ietf.org
Message-id: <0IRD0087Y70MEW@mail.cecwireless.com.cn>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-index: AcX+yDTvIdL/m1dSTA6R/EGEuxGcsQ==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [Sip] [help] waht [H14.4] or other [Hxx.xx] means in RFC document
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="===============0780714542=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0780714542==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_PdwzO1A4zUrII7rh9Hik5w)"

This is a multi-part message in MIME format.

--Boundary_(ID_PdwzO1A4zUrII7rh9Hik5w)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

Hi,all
 
    I am new comer,does anybody could tell me what doc the [Hxx.xx]
indiactes.
 
Thanks
 
Robert.Chen

--Boundary_(ID_PdwzO1A4zUrII7rh9Hik5w)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=671335802-12122005><FONT size=2>Hi,all</FONT></SPAN></DIV>
<DIV><SPAN class=671335802-12122005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=671335802-12122005><FONT size=2>&nbsp;&nbsp;&nbsp; I am new 
comer,does anybody could tell me what doc the [Hxx.xx] 
indiactes.</FONT></SPAN></DIV>
<DIV><SPAN class=671335802-12122005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=671335802-12122005><FONT size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=671335802-12122005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=671335802-12122005><FONT 
size=2>Robert.Chen</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_PdwzO1A4zUrII7rh9Hik5w)--


--===============0780714542==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0780714542==--




From sip-bounces@ietf.org Mon Dec 12 02:55:33 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EliWy-0004gh-Ur; Mon, 12 Dec 2005 02:55:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EliWx-0004fE-24
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 02:55:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12805
	for <sip@ietf.org>; Mon, 12 Dec 2005 02:54:34 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EliXg-0000L2-Pk for sip@ietf.org; Mon, 12 Dec 2005 02:56:18 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 11 Dec 2005 23:55:20 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBC7t3QW010961;
	Sun, 11 Dec 2005 23:55:18 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sun, 11 Dec 2005 23:55:13 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.96.119]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sun, 11 Dec 2005 23:55:12 -0800
Message-Id: <4.3.2.7.2.20051212015501.0363bdd8@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 12 Dec 2005 01:55:10 -0600
To: Chen Shuping <shuping.chen@cecwireless.com.cn>, sip@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] [help] waht [H14.4] or other [Hxx.xx] means in RFC document
In-Reply-To: <0IRD0087Y70MEW@mail.cecwireless.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 12 Dec 2005 07:55:13.0110 (UTC)
	FILETIME=[61C98F60:01C5FEF1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

see RFC 2616

At 11:00 AM 12/12/2005 +0800, Chen Shuping wrote:
>Hi,all
>
>     I am new comer,does anybody could tell me what doc the [Hxx.xx] 
> indiactes.
>
>Thanks
>
>Robert.Chen
>_______________________________________________
>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



From sip-bounces@ietf.org Mon Dec 12 02:58:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EliZN-0004r0-KE; Mon, 12 Dec 2005 02:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekmkj-0004Er-Cy; Fri, 09 Dec 2005 13:13:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09821;
	Fri, 9 Dec 2005 13:12:57 -0500 (EST)
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ekmku-0005Q9-Vf; Fri, 09 Dec 2005 13:14:06 -0500
Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by
	mclmx.mail.saic.com; Fri, 9 Dec 2005 13:13:18 -0500
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12])
	by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id
	M2005120913131726881 ; Fri, 09 Dec 2005 13:13:18 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service
	(5.5.2657.72) id <XLDBSLDL>; Fri, 9 Dec 2005 13:13:13 -0500
Message-Id: <84E5D7F15F52D34DA84C9C90ACE6554F623382@0591-its-exmp01.us.saic.com>
From: "Roy, Radhika R." <royrr@us.saic.com>
To: henry@pulver.com, "Michael Hammer (mhammer)" <mhammer@cisco.com>,
	Thilo Salmon <salmon@sipgate.de>,
	Klaus Darilion <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Fri, 9 Dec 2005 13:07:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-Mailman-Approved-At: Mon, 12 Dec 2005 02:57:59 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Henry:
 
I think that it is the time to write an informational RFC on this because it
is confusing to use the loose words like "service providers" in the context
of the public Internet in the IETF.
 
Let us focus on the RFC what it should be like "Internet Domain Owner" and
others in the context of IETF standardization works.
 
Best regards,
Radhika

  _____  

From: enum-bounces@ietf.org on behalf of Henry Sinnreich
Sent: Tue 12/6/2005 5:29 PM
To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard';
enum@ietf.org
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM



Sorry for nitpicking:

>A provider is a provider.

A provider is a business model and att/SBC may differ from Google who uses a
different business model (which is more significant measured in $$$?).

Didn't we agree to use the term "Internet domain owner" (we could shorten to
IDOM or such)?

Internet domains are well defined in the IETF.
Business models for VoIP are better suited for other organizations,
consortia or innovators who work to disrupt them :-)

Thanks, Henry




_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 12 02:58:02 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EliZO-0004rU-Lk; Mon, 12 Dec 2005 02:58:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EksKb-0001wO-24
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 19:11:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04878
	for <sip@ietf.org>; Fri, 9 Dec 2005 19:10:22 -0500 (EST)
Message-Id: <200512100010.TAA04878@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EksKq-0005iy-P3
	for sip@ietf.org; Fri, 09 Dec 2005 19:11:34 -0500
Received: (qmail 23723 invoked by uid 510); 9 Dec 2005 19:16:32 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 0.960981 secs); 10 Dec 2005 00:16:32 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	0.960981 secs Process 23718)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 00:16:31 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>, <royrr@us.saic.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>, <royrr@us.saic.com>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Fri, 9 Dec 2005 18:11:00 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0A=
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0EB9@xmb-rtp-20b.amer.cisco.com>
X-Antivirus-MYDOMAIN-Message-ID: <113417379183523718@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 12 Dec 2005 02:58:00 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Radhika has a good proposal:

> I think that it is the time to write an informational RFC on 
> this because it is confusing to use the loose words like 
> "service providers" in the context of the public Internet in the IETF.

I disagree with Mike:

> But, let's not invent some affected form of speech just to
> confuse the uninitiated.

This list is followed by experts who understand the principle of peering
services layer by layer, independently. This was discussed and agreed in the
WG during the 64 IETF. It is also related to "Internet Neutrality".

Service provider at what layer?
	- Internet access, or
	- Application layer (L5 for SIP and RTP) for VoIP?

There are scenarios without any VoIP service provider, such as when two IT
networks exchange VoIP traffic and much other stuff, and they have different
ISPs as well. Lots of people do happily VoIP without a service provider (a
la carrier offering VoIP in some "triple play").

Neither does a home network or a community network qualify as a service
provider though they are using VoIP outside their network.

The proposed informational RFC (by Radhika) needs to accommodate such
scenarious and an _IT network_ or a _home network_ are not _VoIP service
providers_ even if you may want to make it sound like it is. 

Thanks, Henry
 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] 
Sent: Friday, December 09, 2005 12:55 PM
To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org
Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] Re: [Sip]
SIP AoR, tel and ENUM

Is it not possible to be a domain owner and not provide any services?
(cyber-squatter?)

Being a domain owner is a bit removed from focus at hand.  The relevant
matter is that some entity is providing a service, be it data transport
or session setup, an application, or whatever.  I don't understand what
the hang up is with using plain English to describe what it is.  What
happens when you take the next step and start to distinguish between
public domain owners and private domain owners?  Do we start saying that
one entity is a transport domain owner versus a session setup domain
owner?  And what is it when they are both?  A session transport domain
owner?  What happens when the entity operates or supports many domains?

This could get really obtuse quickly.  I don't object to using the
domain owner as a litmus test for sorting out who is targeted with
requests.  But, let's not invent some affected form of speech just to
confuse the uninitiated.

Mike


> -----Original Message-----
> From: royrr@us.saic.com [mailto:royrr@us.saic.com] 
> Sent: Friday, December 09, 2005 1:08 PM
> To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; 
> Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; 
> enum@ietf.org
> Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum] 
> Re: [Sip] SIP AoR, tel and ENUM
> 
> Henry:
>  
> I think that it is the time to write an informational RFC on 
> this because it is confusing to use the loose words like 
> "service providers" in the context of the public Internet in the IETF.
>  
> Let us focus on the RFC what it should be like "Internet 
> Domain Owner" and others in the context of IETF standardization works.
>  
> Best regards,
> Radhika
> 
>   _____  
> 
> From: enum-bounces@ietf.org on behalf of Henry Sinnreich
> Sent: Tue 12/6/2005 5:29 PM
> To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny 
> Richard'; enum@ietf.org
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> 
> 
> Sorry for nitpicking:
> 
> >A provider is a provider.
> 
> A provider is a business model and att/SBC may differ from 
> Google who uses a different business model (which is more 
> significant measured in $$$?).
> 
> Didn't we agree to use the term "Internet domain owner" (we 
> could shorten to IDOM or such)?
> 
> Internet domains are well defined in the IETF.
> Business models for VoIP are better suited for other 
> organizations, consortia or innovators who work to disrupt them :-)
> 
> Thanks, Henry
> 
> 




_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 12 02:58:03 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EliZP-0004ry-O9; Mon, 12 Dec 2005 02:58:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EktsO-0002Hj-CK
	for sip@megatron.ietf.org; Fri, 09 Dec 2005 20:50:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23796
	for <sip@ietf.org>; Fri, 9 Dec 2005 20:49:12 -0500 (EST)
Message-Id: <200512100149.UAA23796@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EktsX-0003DB-JE
	for sip@ietf.org; Fri, 09 Dec 2005 20:50:26 -0500
Received: (qmail 28388 invoked by uid 510); 9 Dec 2005 20:55:31 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.34):. 
	Processed in 0.987271 secs); 10 Dec 2005 01:55:31 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in
	0.987271 secs Process 28383)
Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.34)
	by 192.246.69.184 with SMTP; Sat, 10 Dec 2005 01:55:30 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Michael Hammer \(mhammer\)'" <mhammer@cisco.com>, <royrr@us.saic.com>,
	"'Thilo Salmon'" <salmon@sipgate.de>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
Date: Fri, 9 Dec 2005 19:49:57 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX87Gb2NcBxC9lLRMGN4H2K6f935wAAzTQQAAq3O0AAAUUlwAACZzOg
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3DA0FC4@xmb-rtp-20b.amer.cisco.com>
X-Antivirus-MYDOMAIN-Message-ID: <113417973083528383@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 12 Dec 2005 02:58:00 -0500
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	'Stastny Richard' <Richard.Stastny@oefeg.at>, enum@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Mike,

I am happy there are three of us in agreement and I suppose we can conclude
the trail on this topic:

>For the benefit of those that need to know this long after IETF 64 is
>forgotten, this should be documented, so I support the idea of an
>informational RFC.

Thanks, Henry

 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] 
Sent: Friday, December 09, 2005 6:47 PM
To: henry@pulver.com; royrr@us.saic.com; Thilo Salmon; Klaus Darilion
Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; enum@ietf.org
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

Henry,

I try to follow discussion through the mail list and in what gets
reported in meeting notes, but must have missed where this terminology
was discussed and decided.  Could you provide me a pointer to which WG
meeting notes to review on this.

For the benefit of those that need to know this long after IETF 64 is
forgotten, this should be documented, so I support the idea of an
informational RFC.  It would be good to share this with other groups, so
we are all on the same sheet of music.  And I will be sure to use
initial caps to highlight use of the formal term.


> -----Original Message-----
> From: Henry Sinnreich [mailto:henry@pulver.com] 
> Sent: Friday, December 09, 2005 7:11 PM
> To: Michael Hammer (mhammer); royrr@us.saic.com; 'Thilo 
> Salmon'; 'Klaus Darilion'; royrr@us.saic.com
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny 
> Richard'; enum@ietf.org
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> Radhika has a good proposal:
> 
> > I think that it is the time to write an informational RFC on this 
> > because it is confusing to use the loose words like "service 
> > providers" in the context of the public Internet in the IETF.
> 
> I disagree with Mike:
> 
> > But, let's not invent some affected form of speech just to 
> confuse the 
> > uninitiated.
> 
> This list is followed by experts who understand the principle 
> of peering services layer by layer, independently. This was 
> discussed and agreed in the WG during the 64 IETF. It is also 
> related to "Internet Neutrality".
> 
> Service provider at what layer?
> 	- Internet access, or
> 	- Application layer (L5 for SIP and RTP) for VoIP?

Your own words indicate that services are provided at multiple layers.

> There are scenarios without any VoIP service provider, such 
> as when two IT networks exchange VoIP traffic and much other 
> stuff, and they have different ISPs as well. Lots of people 
> do happily VoIP without a service provider (a la carrier 
> offering VoIP in some "triple play").

"without a SP" with example of "carrier offering VoIP" seems
self-contradictory

> Neither does a home network or a community network qualify as 
> a service provider though they are using VoIP outside their network.

So, if a service (e.g. Internet access) is provided for free, there is
no service provider?
But, if a service (e.g. Internet access) is provided for cost, an ISP is
a service provider?

This is when I feel like Alice in Wonderland.

But, I guess we can agree to disagree, and move on with what the
"experts" have chosen.

Mike

> The proposed informational RFC (by Radhika) needs to 
> accommodate such scenarious and an _IT network_ or a _home 
> network_ are not _VoIP service providers_ even if you may 
> want to make it sound like it is. 
> 
> Thanks, Henry
>  
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> Sent: Friday, December 09, 2005 12:55 PM
> To: royrr@us.saic.com; henry@pulver.com; Thilo Salmon; Klaus Darilion
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; 
> enum@ietf.org
> Subject: RE: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: 
> [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> Is it not possible to be a domain owner and not provide any services?
> (cyber-squatter?)
> 
> Being a domain owner is a bit removed from focus at hand.  
> The relevant matter is that some entity is providing a 
> service, be it data transport or session setup, an 
> application, or whatever.  I don't understand what the hang 
> up is with using plain English to describe what it is.  What 
> happens when you take the next step and start to distinguish 
> between public domain owners and private domain owners?  Do 
> we start saying that one entity is a transport domain owner 
> versus a session setup domain owner?  And what is it when 
> they are both?  A session transport domain owner?  What 
> happens when the entity operates or supports many domains?
> 
> This could get really obtuse quickly.  I don't object to 
> using the domain owner as a litmus test for sorting out who 
> is targeted with requests.  But, let's not invent some 
> affected form of speech just to confuse the uninitiated.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: royrr@us.saic.com [mailto:royrr@us.saic.com]
> > Sent: Friday, December 09, 2005 1:08 PM
> > To: henry@pulver.com; Michael Hammer (mhammer); Thilo Salmon; Klaus 
> > Darilion
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; 
> > enum@ietf.org
> > Subject: [WARNING: A/V UNSCANNABLE] RE: [voipeer] RE: [Enum]
> > Re: [Sip] SIP AoR, tel and ENUM
> > 
> > Henry:
> >  
> > I think that it is the time to write an informational RFC on this 
> > because it is confusing to use the loose words like "service 
> > providers" in the context of the public Internet in the IETF.
> >  
> > Let us focus on the RFC what it should be like "Internet 
> Domain Owner" 
> > and others in the context of IETF standardization works.
> >  
> > Best regards,
> > Radhika
> > 
> >   _____
> > 
> > From: enum-bounces@ietf.org on behalf of Henry Sinnreich
> > Sent: Tue 12/6/2005 5:29 PM
> > To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
> > Cc: sip@ietf.org; voipeer@lists.uoregon.edu; 'Stastny Richard'; 
> > enum@ietf.org
> > Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > 
> > 
> > 
> > Sorry for nitpicking:
> > 
> > >A provider is a provider.
> > 
> > A provider is a business model and att/SBC may differ from 
> Google who 
> > uses a different business model (which is more significant 
> measured in 
> > $$$?).
> > 
> > Didn't we agree to use the term "Internet domain owner" (we could 
> > shorten to IDOM or such)?
> > 
> > Internet domains are well defined in the IETF.
> > Business models for VoIP are better suited for other organizations, 
> > consortia or innovators who work to disrupt them :-)
> > 
> > Thanks, Henry
> > 
> > 
> 
> 



_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 12 05:12:22 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElkfO-0007cy-Cf; Mon, 12 Dec 2005 05:12:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElkfB-0007cV-ME
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 05:12:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27996
	for <sip@ietf.org>; Mon, 12 Dec 2005 05:10:52 -0500 (EST)
Received: from philipp.labs.nic.at ([83.136.32.80] helo=graham.labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elkfb-0005DT-Fb
	for sip@ietf.org; Mon, 12 Dec 2005 05:12:37 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50])
	by graham.labs.nic.at with esmtp (Exim 3.36 #1 (Debian))
	id 1ElkeD-00022D-00; Mon, 12 Dec 2005 11:11:09 +0100
Message-ID: <439D4CC4.6090402@pernau.at>
Date: Mon, 12 Dec 2005 11:11:16 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C4714@oefeg-s04.oefeg.loc>	<17305.47030.91954.594814@harjus.tutpro.com>
	<4399D1AE.4040804@cisco.com>
In-Reply-To: <4399D1AE.4040804@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Juha Heinanen <jh@tutpro.com>,
	Stastny Richard <Richard.Stastny@oefeg.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi!

As we all see, there are several problems which can be avoided using tel 
URIs instead of SIP URIs. The problem is: I've never seen any 
implementation yet using/supporting tel URIs.

Does somebody know SIP clients, proxies, gateways which do support tel URIs?

regards
klaus

Paul Kyzivat wrote:
> 
> 
> Juha Heinanen wrote:
> 
>> Stastny Richard writes:
>>
>>  > A user enters a phone number, the UA sends it by default
>>  > to his provider A with
>>  > sip:+4312345@provA.com;user=phone
>>
>> that is fine if the user is placing the call, but how about when the
>> user wants to refer the calling party with 302 to his number on pstn
>> network? 
>> last time i checked, phones from paul's company use sip uri format,
> 
> 
> yes, I know they do. Maybe someday I will prevail. :-(
> 
>> which according to paul's interpretation must be routed to whatever host
>> part is listed there, which for sure get blocked by the proxy if the
>> caller belongs to a different domain.
> 
> 
> There is no requirement for the UA to deliver the request *directly* to 
> that address. It is perfectly free to put this request into the R-URI 
> and then deliver the request to its own proxy. Then that proxy can deal 
> with the routing.
> 
>     Paul
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Mon Dec 12 09:07:34 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EloL0-0007U0-4O; Mon, 12 Dec 2005 09:07:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EloKx-0007To-EK
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 09:07:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26311
	for <sip@ietf.org>; Mon, 12 Dec 2005 09:06:35 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EloLl-0005Vd-L7
	for sip@ietf.org; Mon, 12 Dec 2005 09:08:22 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 12 Dec 2005 06:07:22 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,243,1131350400"; 
	d="scan'208"; a="17049337:sNHT25208752"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBCE6d57012985; 
	Mon, 12 Dec 2005 09:07:20 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 12 Dec 2005 09:07:16 -0500
Received: from [161.44.79.233] ([161.44.79.233]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 12 Dec 2005 09:07:16 -0500
Message-ID: <439D8414.3080307@cisco.com>
Date: Mon, 12 Dec 2005 09:07:16 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C471F@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C471F@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Dec 2005 14:07:16.0388 (UTC)
	FILETIME=[5B7F7640:01C5FF25]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Stastny Richard wrote:
> Paul,
>  
> of course in all cases I mentioned a tel: URI could
> (should?) be used.
>  
> I made the examples with the sip URI 
> 
> 1. to show how it works with sip URI containing
> tel Uris to make the point
>  
> 2. because this seems to be the currently used method,
> because most UA and also most SIP proxys do not
> interpret tel URI (I have no reason why)

OK. Understood. And I agree that what you proposed can work. But when 
doing the rewriting at the border between domains, it is necessary for 
the sender to know the conventions of the receiver regarding the 
representation of phone numbers in sip uris. Really this is true in all 
cases, but it would be easier if everybody agreed on the same form (the 
tel uri) for representation of phone numbers.

	Paul

> Richard
> 
> ________________________________
> 
> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Gesendet: Fr 09.12.2005 19:43
> An: Stastny Richard
> Cc: Dale R. Worley; Sip
> Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> 
> 
> Stastny Richard wrote:
> 
>>My take on this:
>>
>>A user enters a phone number, the UA sends it by default
>>to his provider A with
>>sip:+4312345@provA.com;user=phone
> 
> 
> The key here is that the phone is *creating* a uri in this domain. To do
> so it must be considered part of the domain in order to interpret the
> user part of the uri. It then sends it to a server that is also
> permitted to interpret the user part.
> 
> It *could* also just use tel:+4312345. In that case anybody can
> interpret the number because its meaning is defined by a standard.
> 
> 
>>proxy A of Provider A interprets this as an E.164 number and
>>does whatever he is programmed to do with this:
>>
>>1. forward it to his own gateway sip:+4312345@gw.provA.com;user=phone
>>2. forward it to another proxy with a gateway sip:+4312345@GWprov.com;user=phone
> 
> 
> In other words, if it wants to pass this to another domain using the sip
> form, and wants the other domain to interpret it as a phone number, then
> it needs to rewrite the URI to a form that the receiving network uses to
> represent phone numbers. Knowing if/how/when this can be done requires
> some kind of agreement (implicit or explicit) between the source network
> and the destination network.
> 
> Again, this *could* also be done by rewriting as a tel uri before
> passing to the other network.
> 
>         Paul
> 
> 
>>3. query ENUM
>>in this case he may either get back sip:foo@provB.com
>>or
>>sip:+4312345@provB.com;user=phone
>>or
>>sip:+4312345@ingress14.provB.com;user=phone
>>
>>Richard
>>
>>________________________________
>>
>>Von: sip-bounces@ietf.org im Auftrag von Dale R. Worley
>>Gesendet: Fr 09.12.2005 16:51
>>An: Sip
>>Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
>>
>>
>>
>>On Fri, 2005-12-09 at 10:28 -0500, Paul Kyzivat wrote:
>>
>>
>>>>if UA is to send a request to sip:+4312345@provA.com, it MUST send it to
>>>>provA.com.  in case of sip:+4312345@provA.com;user=phone, it can (and
>>>>usually MUST) send it wherever it is sending requests to e.164 numbers,
>>>>i.e., where it would send tel:+4312345, because the UA may not have any
>>>>deal to use provA.com as its outbound proxy.
>>>
>>>I disagree with you Juha. AFAIK the routing of *either* form MUST be
>>>routed solely based on the provA.com domain. Unless you are responsible
>>>for the domain in question you are not to interpret the user part in any
>>>way. There is no dispensation to violate this when the user=phone
>>>parameter is present.
>>
>>
>>RFC 3273 seems to me to come down very strongly in favor of Paul's
>>position.  The only escape would be a later RFC that specifically
>>authorized an agent that is not authoritative for provA.com to interpret
>>the URI differently.
>>
>>Dale
>>
>>
>>
>>_______________________________________________
>>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
>>
> 
> 

_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 12 09:13:47 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EloR1-0000ik-6J; Mon, 12 Dec 2005 09:13:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EloQv-0000gh-06; Mon, 12 Dec 2005 09:13:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26983;
	Mon, 12 Dec 2005 09:12:36 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EloRb-0005h9-0C; Mon, 12 Dec 2005 09:14:23 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 12 Dec 2005 09:13:23 -0500
X-IronPort-AV: i="3.99,243,1131339600"; 
	d="scan'208"; a="77582927:sNHT32373192"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBCED0Ub008016; 
	Mon, 12 Dec 2005 09:13:17 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 12 Dec 2005 09:13:08 -0500
Received: from [161.44.79.233] ([161.44.79.233]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 12 Dec 2005 09:13:07 -0500
Message-ID: <439D8572.1050909@cisco.com>
Date: Mon, 12 Dec 2005 09:13:06 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tolga Tarhan <Tolga.Tarhan@deltel.com>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com>
In-Reply-To: <383A9E7C48D9694FAD43334A7563AA6C8C4170@FILEVAULT.windows.deltel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Dec 2005 14:13:07.0843 (UTC)
	FILETIME=[2CFB3D30:01C5FF26]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, enum@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Stastny Richard <Richard.Stastny@oefeg.at>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Tolga Tarhan wrote:
> All,
> 
> Just to be clear, let me define my understanding of Juha's scenario:
> 
> 1) UserA@provA sends an invite to his local proxy (provA) for
> UserB@provB.
> 
> 2) UserB has told his provider that he wants all of his calls redirected
> to his PSTN number.  Clearly, userB's intent is that the call be
> completed through a media gateway to the PSTN.  For this example, let's
> say the number was +17205551212.
> 
> 3) provB receives the request from provA and now needs to send a
> redirect to the PSTN number.  Assume for this example that provA and
> provB have no business relationship, and therefore, provB will not
> accept a call to the PSTN from provA.
> 
> 
> That being said, probably the simplest thing that provB can do is use a
> tel: URI in the redirect.  That avoids all ambiguity and logically
> requests that provA use a local media gateway to complete the call to
> the PSTN.
> 
> If the tel: URI is not an option for some reason, then provB should send
> the redirect to sip:+17205551212@provA;user=phone. 

If provA and provB have no business relationship, then it is 
inappropriate for provB to create a uri in the domain of provA.

This is different from the case Richard gave, where a uri is rewritten 
to the domain of the target when forwarding, because that presumes a 
business relationship.

> Notice the use of
> provA, which the proxy at provB would have to derive, presumably using
> the "From" header.  I don't think this is a good option, because there
> may be no reliable way to consistently derive the correct URI.

Right!

> I have to side with Paul, however, in saying that IF the redirect from
> provB actually refers to sip:+17205551212@provB (regardless of the
> presence of a user attribute), then the RFC is fairly clear -- the
> request that results from the redirect must be sent to provB, which will
> almost certainly fail.

	Paul

> --
> Tolga Tarhan
> 
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
> Juha Heinanen
> Sent: Friday, December 09, 2005 8:59 AM
> To: Stastny Richard
> Cc: Sip
> Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> Stastny Richard writes:
> 
>  > A user enters a phone number, the UA sends it by default
>  > to his provider A with
>  > sip:+4312345@provA.com;user=phone
> 
> that is fine if the user is placing the call, but how about when the
> user wants to refer the calling party with 302 to his number on pstn
> network?  
> 
> last time i checked, phones from paul's company use sip uri format,
> which according to paul's interpretation must be routed to whatever host
> part is listed there, which for sure get blocked by the proxy if the
> caller belongs to a different domain.
> 
> -- 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
> 

_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 12 09:19:03 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EloW7-0001LF-82; Mon, 12 Dec 2005 09:19:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EloW2-0001Jk-VJ; Mon, 12 Dec 2005 09:19:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27490;
	Mon, 12 Dec 2005 09:18:02 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EloWq-0005rx-6N; Mon, 12 Dec 2005 09:19:49 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 12 Dec 2005 06:18:48 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBCEIGMw000075;
	Mon, 12 Dec 2005 06:18:43 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 12 Dec 2005 09:18:40 -0500
Received: from [161.44.79.233] ([161.44.79.233]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 12 Dec 2005 09:18:40 -0500
Message-ID: <439D86BF.1090506@cisco.com>
Date: Mon, 12 Dec 2005 09:18:39 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Klaus Darilion <klaus.mailinglists@pernau.at>
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
References: <32755D354E6B65498C3BD9FD496C7D462C470D@oefeg-s04.oefeg.loc>
	<43998FD7.20207@cisco.com> <43999607.7060900@pernau.at>
In-Reply-To: <43999607.7060900@pernau.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Dec 2005 14:18:40.0040 (UTC)
	FILETIME=[F2FC7A80:01C5FF26]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, voipeer@lists.uoregon.edu,
	Stastny Richard <Richard.Stastny@oefeg.at>, enum@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org



Klaus Darilion wrote:
> Hi Paul!
> 
> Thanks for clarification. I always had problem to understand the proper 
> meaning of this parameter. Is this somewhere described in detail? I also 
> rememeber a discussion to remove this parameter completly.

I'm not sure there is a good description anywhere. It has been debated 
many times. What I wrote is my best understanding given all the 
discussion that has gone on in the past.

	Paul

> regards
> klaus
> 
> Paul Kyzivat wrote:
> 
>>
>>
>> Stastny Richard wrote:
>>
>>>> Thus, IMO the paramter is more interesting for the outgoing 
>>>> provider. If
>>>> the proxy of provA receives a request from its customer for
>>>>  sip:+4312345@provA.com
>>>> this would adress the lokal user +4312345. A request for
>>>>  sip:+4312345@provA.com;user=phone
>>>> would address the E.164 phone number +4312345
>>>
>>>
>>>
>>>
>>> Yesss, exactly ;-)
>>>
>>> And since you rarely have local users start with +,
>>> sip:4312345@provA.com is more usual
>>>
>>> and
>>> sip:+4312345@provA.com
>>> should not happen, causeing always confusion
>>
>>
>>
>> It seems that many people intend to use a namespace for usernames 
>> where there is no overlap of names and numbers: there is no 
>> possibility for a *name* +4312345 that has a different meaning than 
>> the E.164 number +4312345. In that case the presence or absence of the 
>> ";user=phone" is irrelevant as far as its meaning within the owning 
>> domain. In that case the ";user=phone" is more a matter of informing 
>> the world that this is intended to be a phone number.
>>
>> Also, as it happens, while
>>     sip:+4312345@provA.com
>>     sip:+4312345@provA.com;user=phone
>> are not equal by uri comparison rules, they are equal according to the 
>> rules that 3261 applies to the targets of registration. So, you can't 
>> really have them mean different things.
>>
>>     Paul
>>
>> _______________________________________________
>> 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



From sip-bounces@ietf.org Mon Dec 12 20:06:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElycS-0006iu-AC; Mon, 12 Dec 2005 20:06:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElycR-0006iU-13
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 20:06:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01582
	for <sip@ietf.org>; Mon, 12 Dec 2005 20:05:10 -0500 (EST)
From: shi.hao2@zte.com.cn
Received: from [202.103.147.144] (helo=mail2.zte.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Elyd7-0000DL-Pv
	for sip@ietf.org; Mon, 12 Dec 2005 20:07:00 -0500
Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id
	95265.1112621526; Tue, 13 Dec 2005 10:05:30 +0800 (CST)
In-Reply-To: <OF6F3B78D1.30319E7B-ON482570D5.005EE63C@LocalDomain>
To: sip@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: <OFC214C953.AAD8EFF9-ON482570D6.00061423-482570D6.0006544E@zte.com.cn>
Date: Tue, 13 Dec 2005 09:07:24 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September
	14, 2004) at 2005-12-13 09:09:26,
	Serialize complete at 2005-12-13 09:09:26
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Subject: [Sip] one question on the authentication for third-party
	registration
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="===============1164007906=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1164007906==
Content-Type: multipart/alternative;
	boundary="=_alternative 0006543D482570D6_="

This is a multipart message in MIME format.
--=_alternative 0006543D482570D6_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by ietf.org id UAA01582

SGksDQoNCkkgYW0gY29uZnVzZWQgYnkgdGhlIGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1w
YXJ0eSByZWdpc3RyYXRpb24uIA0KDQpXZSBhc3N1bWUgdGhhdCBCb2IgcmVnaXN0cmVycyBm
b3IgQWxpY2UsIHNvIHRoZSBSRUdJU1RFUiByZXF1ZXN0IG1heSBiZSANCmxpa2UgdGhpczoN
Cg0KUkVHSVNURVIgc2lwOnJlZ2lzdHJhci5iaWxveGkuY29tIFNJUC8yLjANClZpYTogU0lQ
LzIuMC9VRFAgYm9ic3BjLmJpbG94aS5jb206NTA2MDticmFuY2g9ejloRzRiS25hc2hkczcN
Ck1heC1Gb3J3YXJkczogNzANClRvOiBBbGljZSA8c2lwOmFsaWNlQGJpbG94aS5jb20+DQpG
cm9tOiBCb2IgPHNpcDpib2JAYmlsb3hpLmNvbT47dGFnPTQ1NjI0OA0KQ2FsbC1JRDogODQz
ODE3NjM3Njg0MjMwQDk5OHNkYXNkaDA5DQpDU2VxOiAxODI2IFJFR0lTVEVSDQpDb250YWN0
OiA8c2lwOmJvYkAxOTIuMC4yLjQ+DQpFeHBpcmVzOiA3MjAwDQpDb250ZW50LUxlbmd0aDog
MA0KDQoNCkFzIFJGQzMyNjEgU2VjdGlvbiAxMC4zIChwYWdlIDY0KSBkZXNjcmliZWQsIHJl
Z2lzdHJhciBTSE9VTEQgYXV0aGVudGljYXRlIA0KdGhlIFVBQyB1c2luZyANCnRoZSBtZWNo
YW5pc21zIGRlc2NyaWJlZCBpbiBSRkMzMjYxIFNlY3Rpb24gMjIsIHNvIHRoZSB1c2VybmFt
ZSBvZiB0aGUgDQpjcmVkZW50aWFsIHNob3VsZCANCmJlICJib2IiLCB3aGlsZSBSRkMzMjYx
IFNlY3Rpb24gMjYuMy4yLjEgKHBhZ2UgMjQzKSBzYWlkIHRoYXQgdXNlcm5hbWUgb2YgDQp0
aGlzIGNyZWRlbnRpYWwgDQpTSE9VTEQgY29ycmVzcG9uZCB3aXRoIHRoZSAidXNlcmluZm8i
IHBvcnRpb24gb2YgdGhlIFVSSSBpbiB0aGUgVG8gaGVhZGVyIA0KZmllbGQgb2YgdGhlIA0K
UkVHSVNURVIgcmVxdWVzdCwgdGhhdCBpcyAiYWxpY2UiLCB0aGlzIG1lYW5zIGF1dGhlbnRp
Y2F0aW9uIGlzIGZvciBBbGljZSwgDQpub3QgQm9iLg0KDQpXaGljaCBvbmUgaXMgdGhlIGNv
cnJlY3Q/DQoNCkJlc3QgUmVnYXJkcywNCkxpb25FYWdsZQ0KDQoNCg0KDQoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K5L+h5oGv5a6J5YWo5aOw
5piO77ya5pys6YKu5Lu25YyF5ZCr5L+h5oGv5b2SWlRF5omA5pyJ77yMDQpaVEXlr7nor6Xp
gq7ku7bmi6XmnInmiYDmnInmnYPliKnjgILor7fmjqXmlLbogIXms6jmhI8NCuS/neWvhu+8
jOacque7j+WPkeS7tuS6uuS5pumdouiuuOWPr++8jOS4jeW+l+WQkeS7u+S9leesrA0K5LiJ
5pa557uE57uH5ZKM5Liq5Lq66YCP6Zyy5pys6YKu5Lu25omA5ZCr5L+h5oGv55qE5YWo6YOo
DQrmiJbpg6jliIbjgILku6XkuIrlo7DmmI7ku4XpgILnlKjkuo7lt6XkvZzpgq7ku7bjgIIN
CkluZm9ybWF0aW9uIFNlY3VyaXR5ICBOb3RpY2XvvJoNClRoZSBpbmZvcm1hdGlvbiBjb250
YWluZWQgaW4gdGhpcyBtYWlsIGlzDQpzb2xlbHkgcHJvcGVydHkgb2YgIFpURSBDb3Jwb3Jh
dGlvbi4gDQpUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuDQpSZWNp
cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8NCm1haW50YWluIHNlY3JlY3kg
YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvDQpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp
cyBjb21tdW5pY2F0aW9uDQp0byBvdGhlcnMuDQoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKg0K
--=_alternative 0006543D482570D6_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA01582


<br><font size=3D2 face=3D"sans-serif">Hi,</font>
<br>
<br><font size=3D2 face=3D"sans-serif">I am confused by the authenticatio=
n
for third-party registration. </font>
<br>
<br><font size=3D2 face=3D"sans-serif">We assume that Bob registrers for =
Alice,
so the REGISTER request may be like this:</font>
<br>
<br><font size=3D2 face=3D"sans-serif">REGISTER sip:registrar.biloxi.com =
SIP/2.0</font>
<br><font size=3D2 face=3D"sans-serif">Via: SIP/2.0/UDP bobspc.biloxi.com=
:5060;branch=3Dz9hG4bKnashds7</font>
<br><font size=3D2 face=3D"sans-serif">Max-Forwards: 70</font>
<br><font size=3D2 face=3D"sans-serif">To: Alice &lt;sip:alice@biloxi.com=
&gt;</font>
<br><font size=3D2 face=3D"sans-serif">From: Bob &lt;sip:bob@biloxi.com&g=
t;;tag=3D456248</font>
<br><font size=3D2 face=3D"sans-serif">Call-ID: 843817637684230@998sdasdh=
09</font>
<br><font size=3D2 face=3D"sans-serif">CSeq: 1826 REGISTER</font>
<br><font size=3D2 face=3D"sans-serif">Contact: &lt;sip:bob@192.0.2.4&gt;=
</font>
<br><font size=3D2 face=3D"sans-serif">Expires: 7200</font>
<br><font size=3D2 face=3D"sans-serif">Content-Length: 0</font>
<br>
<br>
<br><font size=3D2 face=3D"sans-serif">As RFC3261 Section 10.3 (page 64) =
described,
registrar SHOULD authenticate the UAC using </font>
<br><font size=3D2 face=3D"sans-serif">the mechanisms described in RFC326=
1
Section 22, so the username of the credential should </font>
<br><font size=3D2 face=3D"sans-serif">be &quot;bob&quot;, while RFC3261 =
Section
26.3.2.1 (page 243) said that username of this credential </font>
<br><font size=3D2 face=3D"sans-serif">SHOULD correspond with the &quot;u=
serinfo&quot;
portion of the URI in the To header field of the </font>
<br><font size=3D2 face=3D"sans-serif">REGISTER request, that is &quot;al=
ice&quot;,
this means authentication is for Alice, not Bob.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Which one is the correct?</font>
<br>
<br><font size=3D2><tt>Best Regards,</tt></font>
<br><font size=3D2><tt>LionEagle</tt></font>
<br>
<br><br><br><br>
***********************************************<br>
=E4=BF=A1=E6=81=AF=E5=AE=89=E5=85=A8=E5=A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC=E9=
=82=AE=E4=BB=B6=E5=8C=85=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD=92ZTE=E6=89=80=E6=
=9C=89=EF=BC=8C<br>
ZTE=E5=AF=B9=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=8B=A5=E6=9C=89=E6=89=80=E6=9C=89=
=E6=9D=83=E5=88=A9=E3=80=82=E8=AF=B7=E6=8E=A5=E6=94=B6=E8=80=85=E6=B3=A8=E6=
=84=8F<br>
=E4=BF=9D=E5=AF=86=EF=BC=8C=E6=9C=AA=E7=BB=8F=E5=8F=91=E4=BB=B6=E4=BA=BA=E4=
=B9=A6=E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BC=8C=E4=B8=8D=E5=BE=97=E5=90=91=E4=BB=
=BB=E4=BD=95=E7=AC=AC<br>
=E4=B8=89=E6=96=B9=E7=BB=84=E7=BB=87=E5=92=8C=E4=B8=AA=E4=BA=BA=E9=80=8F=E9=
=9C=B2=E6=9C=AC=E9=82=AE=E4=BB=B6=E6=89=80=E5=90=AB=E4=BF=A1=E6=81=AF=E7=9A=
=84=E5=85=A8=E9=83=A8<br>
=E6=88=96=E9=83=A8=E5=88=86=E3=80=82=E4=BB=A5=E4=B8=8A=E5=A3=B0=E6=98=8E=E4=
=BB=85=E9=80=82=E7=94=A8=E4=BA=8E=E5=B7=A5=E4=BD=9C=E9=82=AE=E4=BB=B6=E3=80=
=82<br>
Information&nbsp;Security&nbsp;&nbsp;Notice=EF=BC=9A<br>
The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is<b=
r>
solely&nbsp;property&nbsp;of&nbsp;&nbsp;ZTE&nbsp;Corporation.&nbsp;<br>
This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.<br>
Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to<br>
maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to<b=
r>
disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication<br>
to&nbsp;others.<br>
***********************************************<br>

--=_alternative 0006543D482570D6_=--


--===============1164007906==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1164007906==--




From sip-bounces@ietf.org Mon Dec 12 20:20:32 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElyqF-00026g-Vo; Mon, 12 Dec 2005 20:20:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElyqE-00026M-0H
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 20:20:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03358
	for <sip@ietf.org>; Mon, 12 Dec 2005 20:19:33 -0500 (EST)
Message-Id: <200512130119.UAA03358@ietf.org>
Received: from smtp103.biz.mail.mud.yahoo.com ([68.142.200.238])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Elyr7-0000jr-C6
	for sip@ietf.org; Mon, 12 Dec 2005 20:21:26 -0500
Received: (qmail 46281 invoked from network); 13 Dec 2005 01:20:13 -0000
Received: from unknown (HELO PC244461808863) (knarayan@sipera.com@69.15.249.65
	with login)
	by smtp103.biz.mail.mud.yahoo.com with SMTP; 13 Dec 2005 01:20:12 -0000
From: "Kasturi Narayanan" <knarayan@sipera.com>
To: <shi.hao2@zte.com.cn>, <sip@ietf.org>
Subject: RE: [Sip] one question on the authentication for
	third-partyregistration
Date: Mon, 12 Dec 2005 19:20:20 -0600
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <OFC214C953.AAD8EFF9-ON482570D6.00061423-482570D6.0006544E@zte.com.cn>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX/giKG9QmibyvuQq63ZKdu5cv1iAAAGGZg
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 32604d42645517c44d778f1d111b40a6
Cc: 
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="===============1983316973=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1983316973==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0073_01C5FF51.181C5130"

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01C5FF51.181C5130
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ideally the intention is to authenticate the originator of the Register
regardless of whom that person is registering.

Once authenticated there may be authorization needed (local policy)
regarding whom all this person can register if the person to be =
registered
is a valid user of this network.

So authentication is done for the originator of the request.=20

=20

And also in your example if Alice is being registered u may want the =
contact
to look like alice@192.0.2.4 unless u intentionally meant that.

=20

If what u mentioned below is true then it needs to be looked into.

=20

Kasturi

  _____ =20

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
shi.hao2@zte.com.cn
Sent: Monday, December 12, 2005 7:07 PM
To: sip@ietf.org
Subject: [Sip] one question on the authentication for
third-partyregistration

=20


Hi,=20

I am confused by the authentication for third-party registration.=20

We assume that Bob registrers for Alice, so the REGISTER request may be =
like
this:=20

REGISTER sip:registrar.biloxi.com SIP/2.0=20
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20
Max-Forwards: 70=20
To: Alice <sip:alice@biloxi.com>=20
From: Bob <sip:bob@biloxi.com>;tag=3D456248=20
Call-ID: 843817637684230@998sdasdh09=20
CSeq: 1826 REGISTER=20
Contact: <sip:bob@192.0.2.4>=20
Expires: 7200=20
Content-Length: 0=20


As RFC3261 Section 10.3 (page 64) described, registrar SHOULD =
authenticate
the UAC using=20
the mechanisms described in RFC3261 Section 22, so the username of the
credential should=20
be "bob", while RFC3261 Section 26.3.2.1 (page 243) said that username =
of
this credential=20
SHOULD correspond with the "userinfo" portion of the URI in the To =
header
field of the=20
REGISTER request, that is "alice", this means authentication is for =
Alice,
not Bob.=20

Which one is the correct?=20

Best Regards,=20
LionEagle=20




***********************************************
d?!f/e. e(e#0f
o<=1Af=1C,i=02.d;6e=0C=05e=10+d?!f=01/e=3D=12ZTEf f=1C o><

ZTEe/9h/%i[1].d;6f
%f=1C f f=1C f=20

  _____ =20

e=08)c[1]h/7f
%f=146hf3(f=20
  _____ =20


d?e/=06o<
f=1C*g;e=11d;6d::d9&i"h.8e/o<=0Cd8e>e=11d;;d=3D=15g,,
d8 f9g;=20
  _____ =20

g;e=12
d8*d::ii=1C2f=1C,i[1].d;6f e+d?!f/g=20
  _____ =20

e(i=20
  _____ =20

(
f=08i=20
  _____ =20

(e=08=06c[1]d;%d8 e#0f
d;i[1]g=14(d:
e7%d=3D=1Ci[1].d;6c
Information Security  Noticeo<
The information contained in this mail is
solely property of  ZTE Corporation.=20
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************


------=_NextPart_000_0073_01C5FF51.181C5130
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"
 downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ideally the intention is to =
authenticate
the originator of the Register regardless of whom that person is =
registering.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Once authenticated there may be =
authorization
needed (local policy) regarding whom all this person can register if the =
person
to be registered is a valid user of this =
network.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So authentication is done for the
originator of the request. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>And also in your example if =
<st1:City
w:st=3D"on"><st1:place w:st=3D"on">Alice</st1:place></st1:City> is being =
registered
u may want the contact to look like <a =
href=3D"mailto:alice@192.0.2.4">alice@192.0.2.4</a>
unless u intentionally meant that.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If what u mentioned below is true =
then it
needs to be looked into.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Kasturi<o:p></o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b>shi.hao2@zte.com.cn<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, December =
12, 2005
7:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] one =
question on the
authentication for third-partyregistration</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>Hi,</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>I
am confused by the authentication for third-party registration. =
</span></font><br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>We
assume that Bob registrers for Alice, so the REGISTER request may be =
like this:</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>REGISTER
sip:registrar.biloxi.com SIP/2.0</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Via:
SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7</span></font> =
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Max-Forwards:
70</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>To:
Alice &lt;sip:alice@biloxi.com&gt;</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>From:
Bob &lt;sip:bob@biloxi.com&gt;;tag=3D456248</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Call-ID:
843817637684230@998sdasdh09</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>CSeq:
1826 REGISTER</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Contact:
&lt;sip:bob@192.0.2.4&gt;</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Expires:
7200</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Content-Length:
0</span></font> <br>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>As
RFC3261 Section 10.3 (page 64) described, registrar SHOULD authenticate =
the UAC
using </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>the
mechanisms described in RFC3261 Section 22, so the username of the =
credential
should </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>be
&quot;bob&quot;, while RFC3261 Section 26.3.2.1 (page 243) said that =
username
of this credential </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>SHOULD
correspond with the &quot;userinfo&quot; portion of the URI in the To =
header
field of the </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>REGISTER
request, that is &quot;<st1:City w:st=3D"on"><st1:place =
w:st=3D"on">alice</st1:place></st1:City>&quot;,
this means authentication is for Alice, not Bob.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Which
one is the correct?</span></font> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Best
Regards,</span></font></tt> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>LionEagle</span></font></tt>
<br>
<br>
<br>
<br>
<br>
***********************************************<br>
d?!f/e. e(e#0f<br clear=3Dall>
o<=1Af=1C,i=02.d;6e=0C=05e=10+d?!f=01/e=3D=12ZTEf f=1C o>&lt;<br =
clear=3Dall style=3D'page-break-before:
always'>
<br>
ZTEe/9h/%i<font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'>[1]</span></font>.d;6f<br>
%f&#28; f f&#28; f

<hr align=3Dleft size=3D1 width=3D"33%">

e&#8;)c<font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'>[1]</span></font>h/7f<br clear=3Dall>
%f&#20;6hf3(f

<hr align=3Dleft size=3D1>

<br>
d?e/&#6;o&lt;<br clear=3Dall style=3D'page-break-before:always'>
f&#28;*g;e&#17;d;6d::d9&amp;i&quot;h.8e/o<=0Cd8e>e&#17;d;;d=3D&#21;g,,<br=
>
d8 f9g;

<hr align=3Dleft size=3D1>

g;e&#18;<br clear=3Dall style=3D'page-break-before:always'>
d8*d::ii&#28;2f&#28;,i<font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'>[1]</span></font>.d;6f e+d?!f/g

<hr align=3Dleft size=3D1>

e(i

<hr align=3Dleft size=3D1 width=3D"33%">

(<br>
f&#8;i

<hr align=3Dleft size=3D1 width=3D"33%">

(e&#8;&#6;c<font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'>[1]</span></font>d;%d8 e#0f<br =
clear=3Dall>
d;i<font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'>[1]</span></font>g&#20;(d:<br =
clear=3Dall>
e7%d=3D&#28;i<font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'>[1]</span></font>.d;6c<br>
Information&nbsp;Security&nbsp;&nbsp;Noticeo&lt;<br>
The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is<b=
r>
solely&nbsp;property&nbsp;of&nbsp;&nbsp;ZTE&nbsp;Corporation.&nbsp;<br>
This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.<br>
Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to<br>
maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to<b=
r>
disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication<br>
to&nbsp;others.<br>
***********************************************<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0073_01C5FF51.181C5130--




--===============1983316973==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1983316973==--






From sip-bounces@ietf.org Mon Dec 12 20:45:52 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElzEm-0000ah-JK; Mon, 12 Dec 2005 20:45:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElzEk-0000aY-Ay
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 20:45:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06699
	for <sip@ietf.org>; Mon, 12 Dec 2005 20:44:53 -0500 (EST)
From: shi.hao2@zte.com.cn
Received: from [202.103.147.144] (helo=mail2.zte.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElzFb-0001l6-Tr
	for sip@ietf.org; Mon, 12 Dec 2005 20:46:46 -0500
Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id
	95265.1989961890; Tue, 13 Dec 2005 10:45:14 +0800 (CST)
In-Reply-To: <OF45A15C3D.5A592F20-ON482570D6.0007DB22@LocalDomain>
To: "Kasturi Narayanan" <knarayan@sipera.com>
Subject: =?GB2312?B?tPC4tDogUkU6IFtTaXBdIG9uZSBxdWVzdGlvbiBvbiB0aGU=?=
	=?GB2312?B?IGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24=?=
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: <OF8B6FA05D.AD08866F-ON482570D6.0008F74D-482570D6.0009F742@zte.com.cn>
Date: Tue, 13 Dec 2005 09:47:07 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September
	14, 2004) at 2005-12-13 09:49:09,
	Serialize complete at 2005-12-13 09:49:09
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae
Cc: sip@ietf.org
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="===============0580273139=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0580273139==
Content-Type: multipart/alternative;
	boundary="=_alternative 0009F734482570D6_="

This is a multipart message in MIME format.
--=_alternative 0009F734482570D6_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgS2FzdHVyaaOsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4gDQoNClRoZXJlIGlzIGEgbWlz
dGFrZSBpbiB0aGUgZXhhbXBsZSwgdGhlbiB1c2VyLWluZm8gaW4gQ29udGFjdCB1cmkgc2hvdWxk
IGJlIA0KImFsaWNlIiBub3QgImJvYiIuDQoNCk15IGNvbmZ1c2lvbiBpcyB0aGUgdXNlcm5hbWUg
b2YgdGhlIGNyZWRlbnRpYWwgbm90IHRoZSBDb250YWN0IGluIA0KUkVHSVNURVIuIEkgdGhpbmsg
dGhlIHVzZXJuYW1lIG9mIHRoZSBjcmVkZW50aWFsIHNob3VsZCBiZSAiYm9iIiBzaW5jZSB0aGUg
DQpvcmlnaW5hdG9yIG9mIFJFR0lTVEVSIGlzIGJvYiwgYnV0IFJGQzMyNjEgU2VjdGlvbiAyNi4z
LjIuMSAocGFnZSAyNDMpIA0Kc2FpZCB0aGF0IHVzZXJuYW1lIG9mIHRoaXMgY3JlZGVudGlhbCAN
ClNIT1VMRCBjb3JyZXNwb25kIHdpdGggdGhlICJ1c2VyaW5mbyIgcG9ydGlvbiBvZiB0aGUgVVJJ
IGluIHRoZSBUbyBoZWFkZXIgDQpmaWVsZCBvZiB0aGUgUkVHSVNURVIgcmVxdWVzdC4NCg0KQmVz
dCBSZWdhcmRzLCANCkxpb25FYWdsZSANCg0KDQoNCg0KDQoiS2FzdHVyaSBOYXJheWFuYW4iIDxr
bmFyYXlhbkBzaXBlcmEuY29tPg0KDQoyMDA1LTEyLTEzIMnPzucgMDk6MjANCiANCiAgICAgICAg
ytW8/sjLo7ogICAgICAgIDxzaGkuaGFvMkB6dGUuY29tLmNuPiwgPHNpcEBpZXRmLm9yZz4NCiAg
ICAgICAgs63LzaO6IA0KICAgICAgICDW98zio7ogIFJFOiBbU2lwXSBvbmUgcXVlc3Rpb24gb24g
dGhlIGF1dGhlbnRpY2F0aW9uIGZvciANCnRoaXJkLXBhcnR5cmVnaXN0cmF0aW9uDQoNCg0KSWRl
YWxseSB0aGUgaW50ZW50aW9uIGlzIHRvIGF1dGhlbnRpY2F0ZSB0aGUgb3JpZ2luYXRvciBvZiB0
aGUgUmVnaXN0ZXIgDQpyZWdhcmRsZXNzIG9mIHdob20gdGhhdCBwZXJzb24gaXMgcmVnaXN0ZXJp
bmcuDQpPbmNlIGF1dGhlbnRpY2F0ZWQgdGhlcmUgbWF5IGJlIGF1dGhvcml6YXRpb24gbmVlZGVk
IChsb2NhbCBwb2xpY3kpIA0KcmVnYXJkaW5nIHdob20gYWxsIHRoaXMgcGVyc29uIGNhbiByZWdp
c3RlciBpZiB0aGUgcGVyc29uIHRvIGJlIHJlZ2lzdGVyZWQgDQppcyBhIHZhbGlkIHVzZXIgb2Yg
dGhpcyBuZXR3b3JrLg0KU28gYXV0aGVudGljYXRpb24gaXMgZG9uZSBmb3IgdGhlIG9yaWdpbmF0
b3Igb2YgdGhlIHJlcXVlc3QuIA0KIA0KQW5kIGFsc28gaW4geW91ciBleGFtcGxlIGlmIEFsaWNl
IGlzIGJlaW5nIHJlZ2lzdGVyZWQgdSBtYXkgd2FudCB0aGUgDQpjb250YWN0IHRvIGxvb2sgbGlr
ZSBhbGljZUAxOTIuMC4yLjQgdW5sZXNzIHUgaW50ZW50aW9uYWxseSBtZWFudCB0aGF0Lg0KIA0K
SWYgd2hhdCB1IG1lbnRpb25lZCBiZWxvdyBpcyB0cnVlIHRoZW4gaXQgbmVlZHMgdG8gYmUgbG9v
a2VkIGludG8uDQogDQpLYXN0dXJpDQoNCkZyb206IHNpcC1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCnNoaS5oYW8yQHp0ZS5jb20u
Y24NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTIsIDIwMDUgNzowNyBQTQ0KVG86IHNpcEBpZXRm
Lm9yZw0KU3ViamVjdDogW1NpcF0gb25lIHF1ZXN0aW9uIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBm
b3IgDQp0aGlyZC1wYXJ0eXJlZ2lzdHJhdGlvbg0KIA0KDQpIaSwgDQoNCkkgYW0gY29uZnVzZWQg
YnkgdGhlIGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24uIA0KDQpX
ZSBhc3N1bWUgdGhhdCBCb2IgcmVnaXN0cmVycyBmb3IgQWxpY2UsIHNvIHRoZSBSRUdJU1RFUiBy
ZXF1ZXN0IG1heSBiZSANCmxpa2UgdGhpczogDQoNClJFR0lTVEVSIHNpcDpyZWdpc3RyYXIuYmls
b3hpLmNvbSBTSVAvMi4wIA0KVmlhOiBTSVAvMi4wL1VEUCBib2JzcGMuYmlsb3hpLmNvbTo1MDYw
O2JyYW5jaD16OWhHNGJLbmFzaGRzNyANCk1heC1Gb3J3YXJkczogNzAgDQpUbzogQWxpY2UgPHNp
cDphbGljZUBiaWxveGkuY29tPiANCkZyb206IEJvYiA8c2lwOmJvYkBiaWxveGkuY29tPjt0YWc9
NDU2MjQ4IA0KQ2FsbC1JRDogODQzODE3NjM3Njg0MjMwQDk5OHNkYXNkaDA5IA0KQ1NlcTogMTgy
NiBSRUdJU1RFUiANCkNvbnRhY3Q6IDxzaXA6Ym9iQDE5Mi4wLjIuND4gDQpFeHBpcmVzOiA3MjAw
IA0KQ29udGVudC1MZW5ndGg6IDAgDQoNCg0KQXMgUkZDMzI2MSBTZWN0aW9uIDEwLjMgKHBhZ2Ug
NjQpIGRlc2NyaWJlZCwgcmVnaXN0cmFyIFNIT1VMRCBhdXRoZW50aWNhdGUgDQp0aGUgVUFDIHVz
aW5nIA0KdGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIFJGQzMyNjEgU2VjdGlvbiAyMiwgc28g
dGhlIHVzZXJuYW1lIG9mIHRoZSANCmNyZWRlbnRpYWwgc2hvdWxkIA0KYmUgImJvYiIsIHdoaWxl
IFJGQzMyNjEgU2VjdGlvbiAyNi4zLjIuMSAocGFnZSAyNDMpIHNhaWQgdGhhdCB1c2VybmFtZSBv
ZiANCnRoaXMgY3JlZGVudGlhbCANClNIT1VMRCBjb3JyZXNwb25kIHdpdGggdGhlICJ1c2VyaW5m
byIgcG9ydGlvbiBvZiB0aGUgVVJJIGluIHRoZSBUbyBoZWFkZXIgDQpmaWVsZCBvZiB0aGUgDQpS
RUdJU1RFUiByZXF1ZXN0LCB0aGF0IGlzICJhbGljZSIsIHRoaXMgbWVhbnMgYXV0aGVudGljYXRp
b24gaXMgZm9yIEFsaWNlLCANCm5vdCBCb2IuIA0KDQpXaGljaCBvbmUgaXMgdGhlIGNvcnJlY3Q/
IA0KDQpCZXN0IFJlZ2FyZHMsIA0KTGlvbkVhZ2xlIA0KDQoNCg0KDQoqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KZD8hZi9lLiBlKGUjMGYNCm88DQoNClpU
RWUvOWgvJWlbMV0uZDs2Zg0KJWZ/IGYgZn8gZiBlfyljWzFdaC83Zg0KJWZ/NmhmMyhmIA0KZD9l
L39vPA0KZn8qZztlf2Q7NmQ6OmQ5JmkiaC44ZS9vZX9kOztkPX9nLCwNCmQ4IGY5ZzsgZztlfw0K
ZDgqZDo6aWl/MmZ/LGlbMV0uZDs2ZiBlK2Q/IWYvZyBlKGkgKA0KZn9pIChlf39jWzFdZDslZDgg
ZSMwZg0KZDtpWzFdZ38oZDoNCmU3JWQ9f2lbMV0uZDs2Yw0KSW5mb3JtYXRpb24gU2VjdXJpdHkg
IE5vdGljZW88DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcw0Kc29s
ZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uIA0KVGhpcyBtYWlsIGNvbW11bmljYXRp
b24gaXMgY29uZmlkZW50aWFsLg0KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVk
IHRvDQptYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0bw0KZGlzY2xvc2Ug
dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbg0KdG8gb3RoZXJzLg0KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoNCioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhlIGVtYWlsIGhhcyAgYmVl
biBzY2FubmVkIGJ5IEFudGktU3BhbQ0Kc3lzdGVtLCAgaWYgeW91IGZpbmQgU3BhbSBvciBWaXJ1
cyBpbiB0aGlzIG1haWwsDQpwbGVhc2UgZm9yd2FyZCBpdCB0bzogaGVscGRlc2tAenRlLmNvbS5j
bg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCgoK
CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCtDFz6Kwssir
yfnD96O6sb7Tyrz+sPy6rNDFz6K56VpURcv509CjrApaVEW21LjD08q8/tO109DL+dPQyKjA+6Gj
x+u908rV1d/XotLiCrGjw9yjrM60vq23orz+yMvK6cPm0O2/yaOssru1w8/yyM66zrXaCsj9t73X
6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTIq7K/Crvysr+31qGj0tTJz8n5w/e99srK08PT
2rmk1/fTyrz+oaMKSW5mb3JtYXRpb24gU2VjdXJpdHkgIE5vdGljZaO6ClRoZSBpbmZvcm1hdGlv
biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzCnNvbGVseSBwcm9wZXJ0eSBvZiAgWlRFIENvcnBv
cmF0aW9uLiAKVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLgpSZWNpcGll
bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8KbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl
IG5vdCBwZXJtaXR0ZWQgdG8KZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh
dGlvbgp0byBvdGhlcnMuCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqCg==
--=_alternative 0009F734482570D6_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthc3R1cmmjrDwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3Vy
IHJlcGx5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PlRoZXJlIGlzIGEgbWlzdGFrZSBpbiB0aGUgZXhhbXBsZSwgdGhlbg0KdXNlci1pbmZvIGluIENv
bnRhY3QgdXJpIHNob3VsZCBiZSAmcXVvdDthbGljZSZxdW90OyBub3QgJnF1b3Q7Ym9iJnF1b3Q7
LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TXkgY29u
ZnVzaW9uIGlzIHRoZSB1c2VybmFtZSBvZiB0aGUNCmNyZWRlbnRpYWwgbm90IHRoZSBDb250YWN0
IGluIFJFR0lTVEVSLiBJIHRoaW5rIHRoZSB1c2VybmFtZSBvZiB0aGUgY3JlZGVudGlhbA0Kc2hv
dWxkIGJlICZxdW90O2JvYiZxdW90OyBzaW5jZSB0aGUgb3JpZ2luYXRvciBvZiBSRUdJU1RFUiBp
cyBib2IsIGJ1dA0KUkZDMzI2MSBTZWN0aW9uIDI2LjMuMi4xIChwYWdlIDI0Mykgc2FpZCB0aGF0
IHVzZXJuYW1lIG9mIHRoaXMgY3JlZGVudGlhbA0KPGJyPg0KU0hPVUxEIGNvcnJlc3BvbmQgd2l0
aCB0aGUgJnF1b3Q7dXNlcmluZm8mcXVvdDsgcG9ydGlvbiBvZiB0aGUgVVJJIGluIHRoZQ0KVG8g
aGVhZGVyIGZpZWxkIG9mIHRoZSBSRUdJU1RFUiByZXF1ZXN0LjwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkJlc3QgUmVnYXJkcyw8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
IkNvdXJpZXIgTmV3Ij48YnI+DQpMaW9uRWFnbGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+IDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3
aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPjxiPiZxdW90O0thc3R1cmkgTmFyYXlhbmFuJnF1b3Q7ICZsdDtrbmFyYXlh
bkBzaXBlcmEuY29tJmd0OzwvYj48L2ZvbnQ+DQo8YnI+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i
c2Fucy1zZXJpZiI+MjAwNS0xMi0xMyDJz87nIDA5OjIwPC9mb250Pg0KPHRkPjxmb250IHNpemU9
MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD4NCjxicj48
Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IMrVvP7Iy6O6DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c2hpLmhhbzJAenRlLmNv
bS5jbiZndDssICZsdDtzaXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm
YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgs63LzaO6DQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDW98zio7oNCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO1JFOiBbU2lwXSBvbmUgcXVlc3Rpb24gb24gdGhlIGF1dGhlbnRpY2F0
aW9uDQpmb3IgdGhpcmQtcGFydHlyZWdpc3RyYXRpb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+SWRlYWxseSB0
aGUgaW50ZW50aW9uIGlzIHRvDQphdXRoZW50aWNhdGUgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIFJl
Z2lzdGVyIHJlZ2FyZGxlc3Mgb2Ygd2hvbSB0aGF0IHBlcnNvbg0KaXMgcmVnaXN0ZXJpbmcuPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5PbmNlIGF1
dGhlbnRpY2F0ZWQgdGhlcmUgbWF5DQpiZSBhdXRob3JpemF0aW9uIG5lZWRlZCAobG9jYWwgcG9s
aWN5KSByZWdhcmRpbmcgd2hvbSBhbGwgdGhpcyBwZXJzb24gY2FuDQpyZWdpc3RlciBpZiB0aGUg
cGVyc29uIHRvIGJlIHJlZ2lzdGVyZWQgaXMgYSB2YWxpZCB1c2VyIG9mIHRoaXMgbmV0d29yay48
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPlNvIGF1
dGhlbnRpY2F0aW9uIGlzIGRvbmUgZm9yDQp0aGUgb3JpZ2luYXRvciBvZiB0aGUgcmVxdWVzdC4g
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJz
cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPkFu
ZCBhbHNvIGluIHlvdXIgZXhhbXBsZSBpZg0KQWxpY2UgaXMgYmVpbmcgcmVnaXN0ZXJlZCB1IG1h
eSB3YW50IHRoZSBjb250YWN0IHRvIGxvb2sgbGlrZSA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86YWxp
Y2VAMTkyLjAuMi40Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5hbGlj
ZUAxOTIuMC4yLjQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNl
PSJBcmlhbCI+DQp1bmxlc3MgdSBpbnRlbnRpb25hbGx5IG1lYW50IHRoYXQuPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPklmIHdoYXQgdSBtZW50
aW9uZWQgYmVsb3cgaXMNCnRydWUgdGhlbiBpdCBuZWVkcyB0byBiZSBsb29rZWQgaW50by48L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+S2FzdHVy
aTwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0KPGJyPg0KPGhyPjwvZGl2Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBzaXAtYm91bmNlc0BpZXRmLm9yZyBb
bWFpbHRvOnNpcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5zaGkuaGFv
MkB6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMTIsIDIwMDUg
NzowNyBQTTxiPjxicj4NClRvOjwvYj4gc2lwQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+
IFtTaXBdIG9uZSBxdWVzdGlvbiBvbiB0aGUgYXV0aGVudGljYXRpb24gZm9yIHRoaXJkLXBhcnR5
cmVnaXN0cmF0aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy
Pg0KSGksPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8
L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkgYW0gY29uZnVzZWQg
YnkgdGhlIGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24uIDwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCldlIGFzc3VtZSB0aGF0IEJvYiByZWdpc3Ry
ZXJzIGZvciBBbGljZSwgc28gdGhlIFJFR0lTVEVSIHJlcXVlc3QgbWF5IGJlDQpsaWtlIHRoaXM6
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClJFR0lTVEVSIHNpcDpyZWdpc3Ry
YXIuYmlsb3hpLmNvbSBTSVAvMi4wPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpWaWE6
IFNJUC8yLjAvVURQIGJvYnNwYy5iaWxveGkuY29tOjUwNjA7YnJhbmNoPXo5aEc0YktuYXNoZHM3
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNYXgtRm9yd2FyZHM6IDcwPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPjxicj4NClRvOiBBbGljZSAmbHQ7c2lwOmFsaWNlQGJpbG94aS5jb20m
Z3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpGcm9tOiBCb2IgJmx0O3NpcDpib2JA
Ymlsb3hpLmNvbSZndDs7dGFnPTQ1NjI0ODwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K
Q2FsbC1JRDogODQzODE3NjM3Njg0MjMwQDk5OHNkYXNkaDA5PC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj48YnI+DQpDU2VxOiAxODI2IFJFR0lTVEVSPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi
cj4NCkNvbnRhY3Q6ICZsdDtzaXA6Ym9iQDE5Mi4wLjIuNCZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPjxicj4NCkV4cGlyZXM6IDcyMDA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K
Q29udGVudC1MZW5ndGg6IDA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy
Pg0KQXMgUkZDMzI2MSBTZWN0aW9uIDEwLjMgKHBhZ2UgNjQpIGRlc2NyaWJlZCwgcmVnaXN0cmFy
IFNIT1VMRCBhdXRoZW50aWNhdGUNCnRoZSBVQUMgdXNpbmcgPGJyPg0KdGhlIG1lY2hhbmlzbXMg
ZGVzY3JpYmVkIGluIFJGQzMyNjEgU2VjdGlvbiAyMiwgc28gdGhlIHVzZXJuYW1lIG9mIHRoZQ0K
Y3JlZGVudGlhbCBzaG91bGQgPGJyPg0KYmUgJnF1b3Q7Ym9iJnF1b3Q7LCB3aGlsZSBSRkMzMjYx
IFNlY3Rpb24gMjYuMy4yLjEgKHBhZ2UgMjQzKSBzYWlkIHRoYXQNCnVzZXJuYW1lIG9mIHRoaXMg
Y3JlZGVudGlhbCA8YnI+DQpTSE9VTEQgY29ycmVzcG9uZCB3aXRoIHRoZSAmcXVvdDt1c2VyaW5m
byZxdW90OyBwb3J0aW9uIG9mIHRoZSBVUkkgaW4gdGhlDQpUbyBoZWFkZXIgZmllbGQgb2YgdGhl
IDxicj4NClJFR0lTVEVSIHJlcXVlc3QsIHRoYXQgaXMgJnF1b3Q7YWxpY2UmcXVvdDssIHRoaXMg
bWVhbnMgYXV0aGVudGljYXRpb24NCmlzIGZvciBBbGljZSwgbm90IEJvYi48L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KV2hpY2ggb25lIGlzIHRoZSBjb3JyZWN0PzwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KQmVzdCBSZWdhcmRzLDwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD
b3VyaWVyIE5ldyI+PGJyPg0KTGlvbkVhZ2xlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l
cyBOZXcgUm9tYW4iPiA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCmQ/IWYvZS4gZShlIzBmPGJy
Pg0KbyZsdDs8YnI+DQo8YnI+DQpaVEVlLzloLyVpWzFdLmQ7NmY8YnI+DQolZn8gZiBmfyBmIDwv
Zm9udD4NCjxocj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5lfyljWzFdaC83
Zjxicj4NCiVmfzZoZjMoZiA8L2ZvbnQ+DQo8aHI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+PGJyPg0KZD9lL39vJmx0Ozxicj4NCmZ/Kmc7ZX9kOzZkOjpkOSZhbXA7aSZxdW90
O2guOGUvb2V/ZDs7ZD1/ZywsPGJyPg0KZDggZjlnOyA8L2ZvbnQ+DQo8aHI+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Zztlfzxicj4NCmQ4KmQ6OmlpfzJmfyxpWzFdLmQ7NmYg
ZStkPyFmL2cgPC9mb250Pg0KPGhyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PmUoaSA8L2ZvbnQ+DQo8aHI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+KDxi
cj4NCmZ/aSA8L2ZvbnQ+DQo8aHI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
KGV/f2NbMV1kOyVkOCBlIzBmPGJyPg0KZDtpWzFdZ38oZDo8YnI+DQplNyVkPX9pWzFdLmQ7NmM8
YnI+DQpJbmZvcm1hdGlvbiBTZWN1cml0eSAmbmJzcDtOb3RpY2VvJmx0Ozxicj4NClRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzPGJyPg0Kc29sZWx5IHByb3BlcnR5IG9m
ICZuYnNwO1pURSBDb3Jwb3JhdGlvbi4gPGJyPg0KVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMg
Y29uZmlkZW50aWFsLjxicj4NClJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0
bzxicj4NCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvPGJyPg0KZGlz
Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbjxicj4NCnRvIG90aGVycy48
YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvZm9u
dD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGUg
ZW1haWwgaGFzICZuYnNwO2JlZW4gc2Nhbm5lZCBieSBBbnRpLVNwYW08YnI+DQpzeXN0ZW0sICZu
YnNwO2lmIHlvdSBmaW5kIFNwYW0gb3IgVmlydXMgaW4gdGhpcyBtYWlsLDxicj4NCnBsZWFzZSBm
b3J3YXJkIGl0IHRvOiBoZWxwZGVza0B6dGUuY29tLmNuPGJyPg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHA+DQo8YnI+PGJyPjxicj4K
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+CtDFz6Kw
ssiryfnD96O6sb7Tyrz+sPy6rNDFz6K56VpURcv509CjrDxicj4KWlRFttS4w9PKvP7TtdPQy/nT
0MiowPuho8frvdPK1dXf16LS4jxicj4KsaPD3KOszrS+rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LI
zrrOtdo8YnI+Csj9t73X6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTIq7K/PGJyPgq78rK/
t9aho9LUyc/J+cP3vfbKytPD09q5pNf308q8/qGjPGJyPgpJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy
aXR5Jm5ic3A7Jm5ic3A7Tm90aWNlo7o8YnI+ClRoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u
dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzPGJyPgpzb2xlbHkmbmJz
cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7Jm5ic3A7WlRFJm5ic3A7Q29ycG9yYXRpb24uJm5ic3A7
PGJyPgpUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp
ZGVudGlhbC48YnI+ClJlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i
c3A7b2JsaWdhdGVkJm5ic3A7dG88YnI+Cm1haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZu
YnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvPGJyPgpkaXNjbG9zZSZuYnNw
O3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbjxi
cj4KdG8mbmJzcDtvdGhlcnMuPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKjxicj4K
--=_alternative 0009F734482570D6_=--


--===============0580273139==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0580273139==--




From sip-bounces@ietf.org Mon Dec 12 20:45:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElzEq-0000bJ-9Z; Mon, 12 Dec 2005 20:45:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElzEn-0000bC-Jz
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 20:45:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06705
	for <sip@ietf.org>; Mon, 12 Dec 2005 20:44:56 -0500 (EST)
Received: from mailout3.samsung.com ([203.254.224.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElzFR-0001kU-4S
	for sip@ietf.org; Mon, 12 Dec 2005 20:46:49 -0500
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IRE00L5CY7MP6@mailout3.samsung.com> for sip@ietf.org;
	Tue, 13 Dec 2005 10:45:22 +0900 (KST)
Received: from mahesh ([165.213.203.251])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IRE00FQVY7M3T@mmp1.samsung.com> for sip@ietf.org; Tue,
	13 Dec 2005 10:45:22 +0900 (KST)
Date: Tue, 13 Dec 2005 10:44:16 +0900
From: Mahesh Govind <mahesh.govind@samsung.com>
Subject: RE: [Sip] one question on the authentication for third-party
	registration
In-reply-to: <OFC214C953.AAD8EFF9-ON482570D6.00061423-482570D6.0006544E@zte.com.cn>
To: shi.hao2@zte.com.cn, sip@ietf.org
Message-id: <004901c5ff86$ba1b0280$fbcbd5a5@mahesh>
Organization: Samsung
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a
Cc: 
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="===============1222461141=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1222461141==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_RBP2quZxtBlH1TD8ACTMMA)"

This is a multi-part message in MIME format.

--Boundary_(ID_RBP2quZxtBlH1TD8ACTMMA)
Content-type: text/plain; charset=ks_c_5601-1987
Content-Transfer-Encoding: quoted-printable

HI,

=20

If  bob can use his credentials for registering for alice ,  If =
required,
he can hijack the calls to alice ???

So I think one have to authenticate REGISTER against the userinfo in To:

=20

With regards

Mahesh

=20

=20

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
shi.hao2@zte.com.cn
Sent: Tuesday, December 13, 2005 10:07 AM
To: sip@ietf.org
Subject: [Sip] one question on the authentication for third-party
registration

=20


Hi,=20

I am confused by the authentication for third-party registration.=20

We assume that Bob registrers for Alice, so the REGISTER request may be
like this:=20

REGISTER sip:registrar.biloxi.com SIP/2.0=20
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20
Max-Forwards: 70=20
To: Alice <sip:alice@biloxi.com>=20
From: Bob <sip:bob@biloxi.com>;tag=3D456248=20
Call-ID: 843817637684230@998sdasdh09=20
CSeq: 1826 REGISTER=20
Contact: <sip:bob@192.0.2.4>=20
Expires: 7200=20
Content-Length: 0=20


As RFC3261 Section 10.3 (page 64) described, registrar SHOULD =
authenticate
the UAC using=20
the mechanisms described in RFC3261 Section 22, so the username of the
credential should=20
be "bob", while RFC3261 Section 26.3.2.1 (page 243) said that username =
of
this credential=20
SHOULD correspond with the "userinfo" portion of the URI in the To =
header
field of the=20
REGISTER request, that is "alice", this means authentication is for =
Alice,
not Bob.=20

Which one is the correct?=20

Best Regards,=20
LionEagle=20




***********************************************
=E4=BF=A1=E6=81=AF=E5=AE=89=E5=85=A8=E5=A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC?=
?=BB=B6?=85=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD=92ZTE?=A2=E6?=89=EF=BC=8C
ZTE=E5=AF=B9=E8???=BB=B6?=A5=E6=9C=89?=A2=E6?=89=E6=9D=83?=A9=E3=A2=E6=82=
=E8??=A5=E6=94=B6?=85=E6=B3=A8??br>
=E4=BF=9D=E5=AF=86=EF=BC=8C=E6=9C=AA=E7=BB=8F=E5=8F=91=E4=BB=B6=E4=BA=BA=E4=
=B9?=9D=A2=E8=AE=B8=E5=8F=AF=EF=BC=8C=E4=B8=8D=E5=BE=97=E5=90=91=E4=BB=BB=
=E4=BD=95=E7=AC?br>
=E4=B8=89=E6=96=B9=E7=BB=84=E7=BB=87?=8C=E4=B8=AA=E4=BA=BA=E9=A2=E6=8F=E9=
=9C=B2?=AC=E9=82=AE=E4=BB=B6=E6??=AB=E4=BF=A1??=9A=84?=A8=E9=83=A8
?=96=E9=83=A8?=86=E3=A2=E6=82=E4=BB=A5=E4=B8=8A=E5=A3=B0?=8E=E4=BB=85?=82=
=E7=94=A8=E4=BA=8E=E5=B7=A5=E4=BD=9C=E9=82=AE=E4=BB=B6=E3=A2=E6?br> =
Information Security
Notice=EF=BC?br> The information contained in this mail is
solely property of  ZTE Corporation.=20
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************


--Boundary_(ID_RBP2quZxtBlH1TD8ACTMMA)
Content-type: text/html; charset=ks_c_5601-1987
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dks_c_5601-1987">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=B9=D9=C5=C1;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@=B9=D9=C5=C1";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>HI,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If &nbsp;bob can use his =
credentials for registering
for </span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
  10.0pt;font-family:Arial;color:navy'>alice</span></font><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> , &nbsp;If required, he can hijack the calls to =
</span></font><font
  size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>alice</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'> =
???</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So I think one have to authenticate
REGISTER against the userinfo in To:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>With regards</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Mahesh</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
sip-bounces@ietf.org
[mailto:sip-bounces@ietf.org] <b><span style=3D'font-weight:bold'>On =
Behalf Of </span></b>shi.hao2@zte.com.cn<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, December =
13, 2005
10:07 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] one =
question on the
authentication for third-party registration</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>Hi,</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>I
am confused by the authentication for third-party registration. =
</span></font><br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>We
assume that Bob registrers for Alice, so the REGISTER request may be =
like this:</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>REGISTER
sip:registrar.biloxi.com SIP/2.0</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Via:
SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7</span></font> =
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Max-Forwards:
70</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>To:
Alice &lt;sip:alice@biloxi.com&gt;</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>From:
Bob &lt;sip:bob@biloxi.com&gt;;tag=3D456248</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Call-ID:
843817637684230@998sdasdh09</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>CSeq:
1826 REGISTER</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Contact:
&lt;sip:bob@192.0.2.4&gt;</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Expires:
7200</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Content-Length:
0</span></font> <br>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>As
RFC3261 Section 10.3 (page 64) described, registrar SHOULD authenticate =
the UAC
using </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>the
mechanisms described in RFC3261 Section 22, so the username of the =
credential
should </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>be
&quot;bob&quot;, while RFC3261 Section 26.3.2.1 (page 243) said that =
username
of this credential </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>SHOULD
correspond with the &quot;userinfo&quot; portion of the URI in the To =
header
field of the </span></font><br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>REGISTER
request, that is &quot;alice&quot;, this means authentication is for =
Alice, not
Bob.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Which
one is the correct?</span></font> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Best Regards,</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>LionEagle</span></font></tt>
<br>
<br>
<br>
<br>
<br>
***********************************************<br>
<font face=3DSimSun><span lang=3DKO =
style=3D'font-family:SimSun'>=E4=BF</span></font>=A1=E6<font
face=3D=B9=D9=C5=C1><span lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=81=AF=E5=AE=89=E5=85=A8</span></font>=
<font
face=3DSimSun><span lang=3DKO =
style=3D'font-family:SimSun'>=E5=A3</span></font><font
face=3D=B9=D9=C5=C1><span lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=B0=E6=98=8E</span></font><font =
face=3DSimSun><span
lang=3DKO style=3D'font-family:SimSun'>=EF=BC</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9A=E6=9C=AC</span></font>??<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=BB=B6</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=85=E5=90=AB</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BF</span></font>=A1=E6<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=81=AF</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E5=BD</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=92Z</span></font>TE?=A2=E6?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=89=EF=BC=8C</span></font><br>
ZTE<font face=3DSimSun><span lang=3DKO =
style=3D'font-family:SimSun'>=E5=AF</span></font><font
face=3D=B9=D9=C5=C1><span lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=B9=E8</span></font>???<font =
face=3D=B9=D9=C5=C1><span
lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=BB=B6</span></font>?=A5=E6<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9C=89</span></font>?=A2=E6?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=89=E6=9D=83</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=A9=E3</span></font>=A2=E6<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=82=E8</span></font>??=A5=E6<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=94=B6</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=85=E6=B3=A8</span></font>??br&gt; =
<font face=3DSimSun><span
lang=3DKO style=3D'font-family:SimSun'>=E4=BF</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9D=E5=AF=86</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=EF=BC</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8C=E6=9C=AA</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E7=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8F=E5=8F=91</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=B6=E4=BA=BA</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=B9</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9D=A2</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E8=AE</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=B8=E5=8F=AF</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=EF=BC</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8C=E4=B8=8D</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E5=BE</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=97=E5=90=91</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=BB=E4=BD=95=E7=AC</span></font>?br&gt=
; <font face=3DSimSun><span
lang=3DKO style=3D'font-family:SimSun'>=E4=B8</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=89=E6=96=B9</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E7=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=84=E7=BB=87</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8C=E4=B8=AA</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BA</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=BA=E9</span></font>=A2=E6<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8F=E9=9C=B2</span></font>?=AC=E9<font=
 face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=82=AE</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=B6=E6</span></font>??<font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=AB=E4</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=BF=A1</span></font>??<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9A=84</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=A8=E9=83=A8</span></font><br>
?<font face=3D=B9=D9=C5=C1><span lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=96=E9=83=A8</span></font>?<font
face=3D=B9=D9=C5=C1><span lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=86=E3</span></font>=A2=E6<font =
face=3D=B9=D9=C5=C1><span
lang=3DKO =
style=3D'font-family:=B9=D9=C5=C1'>=82=E4=BB=A5</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=B8</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8A=E5</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=A3=B0</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8E=E4=BB=85</span></font>?<font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=82=E7=94=A8</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BA</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=8E=E5=B7=A5</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BD</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=9C=E9=82=AE</span></font><font =
face=3DSimSun><span lang=3DKO
style=3D'font-family:SimSun'>=E4=BB</span></font><font =
face=3D=B9=D9=C5=C1><span lang=3DKO
style=3D'font-family:=B9=D9=C5=C1'>=B6=E3</span></font>=A2=E6?br&gt;
Information&nbsp;Security&nbsp;&nbsp;Notice<font face=3DSimSun><span =
lang=3DKO
style=3D'font-family:SimSun'>=EF=BC</span></font>?br&gt;
The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;is<b=
r>
solely&nbsp;property&nbsp;of&nbsp;&nbsp;ZTE&nbsp;Corporation.&nbsp;<br>
This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidential.<br>
Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to<br>
maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to<b=
r>
disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication<br>
to&nbsp;others.<br>
***********************************************</p>

</div>

</body>

</html>

--Boundary_(ID_RBP2quZxtBlH1TD8ACTMMA)--


--===============1222461141==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1222461141==--




From sip-bounces@ietf.org Mon Dec 12 20:49:48 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElzIa-0000yQ-QA; Mon, 12 Dec 2005 20:49:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElzIS-0000xY-MG
	for sip@megatron.ietf.org; Mon, 12 Dec 2005 20:49:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07065
	for <sip@ietf.org>; Mon, 12 Dec 2005 20:48:36 -0500 (EST)
From: shi.hao2@zte.com.cn
Received: from [202.103.147.144] (helo=mail2.zte.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElzJB-0001sr-B5
	for sip@ietf.org; Mon, 12 Dec 2005 20:50:29 -0500
Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id
	95265.1495943728; Tue, 13 Dec 2005 10:48:57 +0800 (CST)
In-Reply-To: <004901c5ff86$ba1b0280$fbcbd5a5@mahesh>
To: Mahesh Govind <mahesh.govind@samsung.com>
Subject: =?GB2312?B?tPC4tDogUkU6IFtTaXBdIG9uZSBxdWVzdGlvbiBvbiB0aGU=?=
	=?GB2312?B?IGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eQlyZWdpc3RyYXRpb24=?=
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: <OFF8885FA2.060BE95E-ON482570D6.0009F81A-482570D6.000A4E25@zte.com.cn>
Date: Tue, 13 Dec 2005 09:50:49 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September
	14, 2004) at 2005-12-13 09:52:52,
	Serialize complete at 2005-12-13 09:52:52
X-Spam-Score: 1.8 (+)
X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac
Cc: sip@ietf.org
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="===============0670313117=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0670313117==
Content-Type: multipart/alternative;
	boundary="=_alternative 000A4E1D482570D6_="

This is a multipart message in MIME format.
--=_alternative 000A4E1D482570D6_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGksIE1haGVzaA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuDQoNClRoZXJlIGlzIGEgbWlz
dGFrZSBpbiB0aGUgZXhhbXBsZSwgdGhlbiB1c2VyLWluZm8gaW4gQ29udGFjdCB1cmkgc2hvdWxk
IGJlIA0KImFsaWNlIiBub3QgImJvYiIuDQoNCk15IGNvbmZ1c2lvbiBpcyB0aGUgdXNlcm5hbWUg
b2YgdGhlIGNyZWRlbnRpYWwgbm90IHRoZSBDb250YWN0IGluIA0KUkVHSVNURVIuIEkgdGhpbmsg
dGhlIHVzZXJuYW1lIG9mIHRoZSBjcmVkZW50aWFsIHNob3VsZCBiZSAiYm9iIiBzaW5jZSB0aGUg
DQpvcmlnaW5hdG9yIG9mIFJFR0lTVEVSIGlzIGJvYiwgYnV0IFJGQzMyNjEgU2VjdGlvbiAyNi4z
LjIuMSAocGFnZSAyNDMpIA0Kc2FpZCB0aGF0IHVzZXJuYW1lIG9mIHRoaXMgY3JlZGVudGlhbCAN
ClNIT1VMRCBjb3JyZXNwb25kIHdpdGggdGhlICJ1c2VyaW5mbyIgcG9ydGlvbiBvZiB0aGUgVVJJ
IGluIHRoZSBUbyBoZWFkZXIgDQpmaWVsZCBvZiB0aGUgUkVHSVNURVIgcmVxdWVzdC4NCg0KQmVz
dCBSZWdhcmRzLCANCkxpb25FYWdsZSANCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PQ0K5a6e6LSo5oCn55qE5Lic6KW/77yM55So55y8552b5piv
55yL5LiN6KeB55qE77yM5Y+q5pyJ55So5b+D5omN6IO955yL5b6X5riFDQo9PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgIG5vdGhpbmcgbGVm
dCBldmVuIHRoZSBkZWF0aCANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NCiAgICAgICAgICAgICAg5pa95rWpMTExNTQzDQogICAgIOS4reW/g+eg
lOeptumZoiAg5Zu6572R6L2v5Lu25byA5Y+R6YOoDQpUZWw6ICAgICs4Ni0yNS01Mjg3MTM2MQ0K
RS1tYWlsOiBzaGkuaGFvMkBtYWlsLnp0ZS5jb20uY24NCk1TTjogICAgTGlvbkVhZ2xlNzRAaG90
bWFpbC5jb20NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0NCg0KDQoNCg0KTWFoZXNoIEdvdmluZCA8bWFoZXNoLmdvdmluZEBzYW1zdW5nLmNvbT4N
Cg0KMjAwNS0xMi0xMyDkuIrljYggMDk6NDQNCiANCiAgICAgICAg5pS25Lu25Lq677yaICAgICAg
ICBzaGkuaGFvMkB6dGUuY29tLmNuLCBzaXBAaWV0Zi5vcmcNCiAgICAgICAg5oqE6YCB77yaIA0K
ICAgICAgICDkuLvpopjvvJogIFJFOiBbU2lwXSBvbmUgcXVlc3Rpb24gb24gdGhlIGF1dGhlbnRp
Y2F0aW9uIGZvciANCnRoaXJkLXBhcnR5ICAgICByZWdpc3RyYXRpb24NCg0KDQpISSwNCiANCklm
ICBib2IgY2FuIHVzZSBoaXMgY3JlZGVudGlhbHMgZm9yIHJlZ2lzdGVyaW5nIGZvciBhbGljZSAs
ICBJZiByZXF1aXJlZCwgDQpoZSBjYW4gaGlqYWNrIHRoZSBjYWxscyB0byBhbGljZSA/Pz8NClNv
IEkgdGhpbmsgb25lIGhhdmUgdG8gYXV0aGVudGljYXRlIFJFR0lTVEVSIGFnYWluc3QgdGhlIHVz
ZXJpbmZvIGluIFRvOg0KIA0KV2l0aCByZWdhcmRzDQpNYWhlc2gNCiANCiANCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcC1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpzaGkuaGFvMkB6dGUuY29tLmNuDQpTZW50
OiBUdWVzZGF5LCBEZWNlbWJlciAxMywgMjAwNSAxMDowNyBBTQ0KVG86IHNpcEBpZXRmLm9yZw0K
U3ViamVjdDogW1NpcF0gb25lIHF1ZXN0aW9uIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBmb3IgdGhp
cmQtcGFydHkgDQpyZWdpc3RyYXRpb24NCiANCg0KSGksIA0KDQpJIGFtIGNvbmZ1c2VkIGJ5IHRo
ZSBhdXRoZW50aWNhdGlvbiBmb3IgdGhpcmQtcGFydHkgcmVnaXN0cmF0aW9uLiANCg0KV2UgYXNz
dW1lIHRoYXQgQm9iIHJlZ2lzdHJlcnMgZm9yIEFsaWNlLCBzbyB0aGUgUkVHSVNURVIgcmVxdWVz
dCBtYXkgYmUgDQpsaWtlIHRoaXM6IA0KDQpSRUdJU1RFUiBzaXA6cmVnaXN0cmFyLmJpbG94aS5j
b20gU0lQLzIuMCANClZpYTogU0lQLzIuMC9VRFAgYm9ic3BjLmJpbG94aS5jb206NTA2MDticmFu
Y2g9ejloRzRiS25hc2hkczcgDQpNYXgtRm9yd2FyZHM6IDcwIA0KVG86IEFsaWNlIDxzaXA6YWxp
Y2VAYmlsb3hpLmNvbT4gDQpGcm9tOiBCb2IgPHNpcDpib2JAYmlsb3hpLmNvbT47dGFnPTQ1NjI0
OCANCkNhbGwtSUQ6IDg0MzgxNzYzNzY4NDIzMEA5OThzZGFzZGgwOSANCkNTZXE6IDE4MjYgUkVH
SVNURVIgDQpDb250YWN0OiA8c2lwOmJvYkAxOTIuMC4yLjQ+IA0KRXhwaXJlczogNzIwMCANCkNv
bnRlbnQtTGVuZ3RoOiAwIA0KDQoNCkFzIFJGQzMyNjEgU2VjdGlvbiAxMC4zIChwYWdlIDY0KSBk
ZXNjcmliZWQsIHJlZ2lzdHJhciBTSE9VTEQgYXV0aGVudGljYXRlIA0KdGhlIFVBQyB1c2luZyAN
CnRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiBSRkMzMjYxIFNlY3Rpb24gMjIsIHNvIHRoZSB1
c2VybmFtZSBvZiB0aGUgDQpjcmVkZW50aWFsIHNob3VsZCANCmJlICJib2IiLCB3aGlsZSBSRkMz
MjYxIFNlY3Rpb24gMjYuMy4yLjEgKHBhZ2UgMjQzKSBzYWlkIHRoYXQgdXNlcm5hbWUgb2YgDQp0
aGlzIGNyZWRlbnRpYWwgDQpTSE9VTEQgY29ycmVzcG9uZCB3aXRoIHRoZSAidXNlcmluZm8iIHBv
cnRpb24gb2YgdGhlIFVSSSBpbiB0aGUgVG8gaGVhZGVyIA0KZmllbGQgb2YgdGhlIA0KUkVHSVNU
RVIgcmVxdWVzdCwgdGhhdCBpcyAiYWxpY2UiLCB0aGlzIG1lYW5zIGF1dGhlbnRpY2F0aW9uIGlz
IGZvciBBbGljZSwgDQpub3QgQm9iLiANCg0KV2hpY2ggb25lIGlzIHRoZSBjb3JyZWN0PyANCg0K
QmVzdCBSZWdhcmRzLCANCkxpb25FYWdsZSANCg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioNCuWys+KGkuqymO+ltOuQp+uAsum2r+qyveyCh+er
iuyLqOyRjT8/67uRP+uBu+unnOWys+KGkuqymOWjpOutklRFP+KCrD/rkLXtjr0NClpURemHjuuw
sD8/P+u7kT/OtuyQoz/igqw/65Cq7JOiP+KSsuKCrOq3nz8/zrbrtbg/64G+64KPPz9icj4g5bKz
7JWt7Lmz56uK65qn7JGL54Cv66S366OV6aST65y467O2DQrpmL8/7JSK5rqr66mo66O+56uK65ql
7YiW5a2D7ICl66ay6aST7IKh7ZCs76aqP2JyPiDoqJ3rkKrrvLbngK/qvqTtjZA/65ql66aJ6ZuF
67iF4oKs66S77JGTP9GH6raZ6aST65y7Pz8NCuODpOyXkD8/7ImqP+KRouq5vw0KP+u9req5vz/r
hbTigqzqt5rrubPoqJ3rk7/vvJA/66Gj7Y2OP+q3nuu1qumbheuhpeueqOm1neySkuq2memkk+uc
sOKCrD9icj4gSW5mb3JtYXRpb24gU2VjdXJpdHkgDQpOb3RpY2Xnq4o/YnI+IFRoZSBpbmZvcm1h
dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzDQpzb2xlbHkgcHJvcGVydHkgb2YgIFpURSBD
b3Jwb3JhdGlvbi4gDQpUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuDQpS
ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8NCm1haW50YWluIHNlY3JlY3kg
YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvDQpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj
b21tdW5pY2F0aW9uDQp0byBvdGhlcnMuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqDQpUaGUgZW1haWwgaGFzICBiZWVuIHNjYW5uZWQgYnkgQW50aS1TcGFt
DQpzeXN0ZW0sICBpZiB5b3UgZmluZCBTcGFtIG9yIFZpcnVzIGluIHRoaXMgbWFpbCwNCnBsZWFz
ZSBmb3J3YXJkIGl0IHRvOiBoZWxwZGVza0B6dGUuY29tLmNuDQoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KCgoKKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioK0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornp
WlRFy/nT0KOsClpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uIKsaPD3KOszrS+
rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoKyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6
rNDFz6K1xMirsr8Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6howpJbmZvcm1hdGlv
biBTZWN1cml0eSAgTm90aWNlo7oKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h
aWwgaXMKc29sZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uIApUaGlzIG1haWwgY29t
bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuClJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i
bGlnYXRlZCB0bwptYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0bwpkaXNj
bG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uCnRvIG90aGVycy4KKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK
--=_alternative 000A4E1D482570D6_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBNYWhlc2g8L2ZvbnQ+DQo8
YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBmb3IgeW91
ciByZXBseS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PlRoZXJlIGlzIGEgbWlzdGFrZSBpbiB0aGUgZXhhbXBsZSwgdGhlbg0KdXNlci1pbmZvIGluIENv
bnRhY3QgdXJpIHNob3VsZCBiZSAmcXVvdDthbGljZSZxdW90OyBub3QgJnF1b3Q7Ym9iJnF1b3Q7
LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TXkgY29u
ZnVzaW9uIGlzIHRoZSB1c2VybmFtZSBvZiB0aGUNCmNyZWRlbnRpYWwgbm90IHRoZSBDb250YWN0
IGluIFJFR0lTVEVSLiBJIHRoaW5rIHRoZSB1c2VybmFtZSBvZiB0aGUgY3JlZGVudGlhbA0Kc2hv
dWxkIGJlICZxdW90O2JvYiZxdW90OyBzaW5jZSB0aGUgb3JpZ2luYXRvciBvZiBSRUdJU1RFUiBp
cyBib2IsIGJ1dA0KUkZDMzI2MSBTZWN0aW9uIDI2LjMuMi4xIChwYWdlIDI0Mykgc2FpZCB0aGF0
IHVzZXJuYW1lIG9mIHRoaXMgY3JlZGVudGlhbA0KPGJyPg0KU0hPVUxEIGNvcnJlc3BvbmQgd2l0
aCB0aGUgJnF1b3Q7dXNlcmluZm8mcXVvdDsgcG9ydGlvbiBvZiB0aGUgVVJJIGluIHRoZQ0KVG8g
aGVhZGVyIGZpZWxkIG9mIHRoZSBSRUdJU1RFUiByZXF1ZXN0LjwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkJlc3QgUmVnYXJkcyw8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
IkNvdXJpZXIgTmV3Ij48YnI+DQpMaW9uRWFnbGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PTxicj4NCuWunui0qOaAp+eahOS4nOilv++8jOeUqOecvOedm+aYr+eci+S4jeingeeahO+8
jOWPquacieeUqOW/g+aJjeiDveeci+W+l+a4hTxicj4NCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogJm5ic3A7ICZuYnNwOyBub3RoaW5n
IGxlZnQgZXZlbiB0aGUgZGVhdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg
Jm5ic3A7IDxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT08YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A75pa95rWpMTExNTQzPGJyPg0KICZuYnNwOyAmbmJzcDsg5Lit5b+D56CU56m26ZmiICZu
YnNwO+Wbuue9kei9r+S7tuW8gOWPkemDqDxicj4NClRlbDogJm5ic3A7ICZuYnNwOys4Ni0yNS01
Mjg3MTM2MTxicj4NCkUtbWFpbDogc2hpLmhhbzJAbWFpbC56dGUuY29tLmNuPGJyPg0KTVNOOiAm
bmJzcDsgJm5ic3A7TGlvbkVhZ2xlNzRAaG90bWFpbC5jb208YnI+DQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0K
PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TWFoZXNoIEdvdmluZCAmbHQ7bWFoZXNoLmdv
dmluZEBzYW1zdW5nLmNvbSZndDs8L2I+PC9mb250Pg0KPGJyPg0KPHA+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPjIwMDUtMTItMTMg5LiK5Y2IIDA5OjQ0PC9mb250Pg0KPHRkPjxmb250
IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD4N
Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IOaUtuS7tuS6uu+8mg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2hpLmhhbzJA
enRlLmNvbS5jbiwgc2lwQGlldGYub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg5oqE6YCB77yaDQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt
c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDkuLvpopjvvJoNCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO1JFOiBbU2lwXSBvbmUgcXVlc3Rpb24gb24gdGhlIGF1dGhlbnRpY2F0
aW9uDQpmb3IgdGhpcmQtcGFydHkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVnaXN0cmF0
aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw
MDAwODAgZmFjZT0iQXJpYWwiPkhJLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAw
MDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j
MDAwMDgwIGZhY2U9IkFyaWFsIj5JZiAmbmJzcDtib2IgY2FuIHVzZSBoaXMgY3JlZGVudGlhbHMN
CmZvciByZWdpc3RlcmluZyBmb3IgYWxpY2UgLCAmbmJzcDtJZiByZXF1aXJlZCwgaGUgY2FuIGhp
amFjayB0aGUgY2FsbHMNCnRvIGFsaWNlID8/PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s
b3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+U28gSSB0aGluayBvbmUgaGF2ZSB0byBhdXRoZW50aWNh
dGUNClJFR0lTVEVSIGFnYWluc3QgdGhlIHVzZXJpbmZvIGluIFRvOjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5XaXRoIHJlZ2FyZHM8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPk1haGVzaDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08Yj48YnI+DQpGcm9tOjwvYj4gc2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz
aXAtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmDQpPZiA8L2I+c2hpLmhhbzJAenRlLmNv
bS5jbjxiPjxicj4NClNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAxMywgMjAwNSAxMDowNyBB
TTxiPjxicj4NClRvOjwvYj4gc2lwQGlldGYub3JnPGI+PGJyPg0KU3ViamVjdDo8L2I+IFtTaXBd
IG9uZSBxdWVzdGlvbiBvbiB0aGUgYXV0aGVudGljYXRpb24gZm9yIHRoaXJkLXBhcnR5IHJlZ2lz
dHJhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4m
bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhp
LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIGFtIGNvbmZ1c2VkIGJ5IHRo
ZSBhdXRoZW50aWNhdGlvbiBmb3IgdGhpcmQtcGFydHkgcmVnaXN0cmF0aW9uLiA8L2ZvbnQ+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpXZSBhc3N1bWUgdGhhdCBCb2IgcmVnaXN0cmVycyBm
b3IgQWxpY2UsIHNvIHRoZSBSRUdJU1RFUiByZXF1ZXN0IG1heSBiZQ0KbGlrZSB0aGlzOjwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSRUdJU1RFUiBzaXA6cmVnaXN0cmFyLmJp
bG94aS5jb20gU0lQLzIuMDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVmlhOiBTSVAv
Mi4wL1VEUCBib2JzcGMuYmlsb3hpLmNvbTo1MDYwO2JyYW5jaD16OWhHNGJLbmFzaGRzNzwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KTWF4LUZvcndhcmRzOiA3MDwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz
YW5zLXNlcmlmIj48YnI+DQpUbzogQWxpY2UgJmx0O3NpcDphbGljZUBiaWxveGkuY29tJmd0Ozwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRnJvbTogQm9iICZsdDtzaXA6Ym9iQGJpbG94
aS5jb20mZ3Q7O3RhZz00NTYyNDg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS
b21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkNhbGwt
SUQ6IDg0MzgxNzYzNzY4NDIzMEA5OThzZGFzZGgwOTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
PGJyPg0KQ1NlcTogMTgyNiBSRUdJU1RFUjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpD
b250YWN0OiAmbHQ7c2lwOmJvYkAxOTIuMC4yLjQmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij48YnI+DQpFeHBpcmVzOiA3MjAwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkNvbnRl
bnQtTGVuZ3RoOiAwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8
YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFz
IFJGQzMyNjEgU2VjdGlvbiAxMC4zIChwYWdlIDY0KSBkZXNjcmliZWQsIHJlZ2lzdHJhciBTSE9V
TEQgYXV0aGVudGljYXRlDQp0aGUgVUFDIHVzaW5nIDxicj4NCnRoZSBtZWNoYW5pc21zIGRlc2Ny
aWJlZCBpbiBSRkMzMjYxIFNlY3Rpb24gMjIsIHNvIHRoZSB1c2VybmFtZSBvZiB0aGUNCmNyZWRl
bnRpYWwgc2hvdWxkIDxicj4NCmJlICZxdW90O2JvYiZxdW90Oywgd2hpbGUgUkZDMzI2MSBTZWN0
aW9uIDI2LjMuMi4xIChwYWdlIDI0Mykgc2FpZCB0aGF0DQp1c2VybmFtZSBvZiB0aGlzIGNyZWRl
bnRpYWwgPGJyPg0KU0hPVUxEIGNvcnJlc3BvbmQgd2l0aCB0aGUgJnF1b3Q7dXNlcmluZm8mcXVv
dDsgcG9ydGlvbiBvZiB0aGUgVVJJIGluIHRoZQ0KVG8gaGVhZGVyIGZpZWxkIG9mIHRoZSA8YnI+
DQpSRUdJU1RFUiByZXF1ZXN0LCB0aGF0IGlzICZxdW90O2FsaWNlJnF1b3Q7LCB0aGlzIG1lYW5z
IGF1dGhlbnRpY2F0aW9uDQppcyBmb3IgQWxpY2UsIG5vdCBCb2IuPC9mb250Pjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPjxicj4NCldoaWNoIG9uZSBpcyB0aGUgY29ycmVjdD88L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg
ZmFjZT0iQ291cmllciBOZXciPjxicj4NCkJlc3QgUmVnYXJkcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll
ciBOZXciPjxicj4NCkxpb25FYWdsZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh
bnMtc2VyaWYiPjxicj4NCuWyszwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv
bWFuIj7ihpI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuqymO+ltOuQp+uA
sum2r+qyveyCh+eriuyLqOyRjTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv
bWFuIj4/PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+67uRPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPj88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9InNhbnMtc2VyaWYiPuuBu+unnOWyszwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj7ihpI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuqymOWj
pOutkjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5URT/igqw/PC9m
b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj7rkLXtjr08L2ZvbnQ+PGZvbnQgc2l6
ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KWlRFPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJzYW5zLXNlcmlmIj7ph47rsLA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+Pz8/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj7ru5E8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+P862PC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJzYW5zLXNlcmlmIj7skKM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+P+KCrD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuuQ
quyTojwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4/PC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj7ikrI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+4oKsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm
Ij7qt588L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Pz/OtjwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+67W4PC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPj88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy
aWYiPuuBvuuCjzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4/P2Jy
Jmd0Ow0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj7lsrPsla3subPnq4rr
mqfskYvngK/rpLfro5XppJPrnLjrs7bpmL88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+7JSK5rqr
66mo66O+56uK65ql7YiW5a2D7ICl66ay6aST7IKh7ZCs76aqPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPj9iciZndDsNCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i
c2Fucy1zZXJpZiI+6Kid65Cq67y254Cv6r6k7Y2QPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPj88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuua
peumiembheu4hTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj7igqw8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuuku+yRkzwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4/0Yc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9
InNhbnMtc2VyaWYiPuq2memkk+ucuzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4/PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+44Ok7JeQPC9m
b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPj8/PC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJzYW5zLXNlcmlmIj7siao8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+4pGi6rm/
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCj88L2ZvbnQ+
PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuu9req5vzwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl
cmlmIj7rhbQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+4oKsPC9m
b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj7qt5rrubPoqJ3rk7/vvJA8L2ZvbnQ+
PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PzwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0ic2Fucy1zZXJpZiI+66Gj7Y2OPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPj88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuq3nuu1qumb
heuhpeueqOm1neySkuq2memkk+ucsDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj7igqw/YnImZ3Q7DQpJbmZvcm1hdGlvbiBTZWN1cml0eSAmbmJzcDtOb3RpY2U8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPuerijwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4/YnImZ3Q7DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMgbWFpbCBpczxicj4NCnNvbGVseSBwcm9wZXJ0eSBvZiAmbmJzcDtaVEUgQ29ycG9y
YXRpb24uIDxicj4NClRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC48YnI+
DQpSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG88YnI+DQptYWludGFpbiBz
ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0bzxicj4NCmRpc2Nsb3NlIHRoZSBjb250ZW50
cyBvZiB0aGlzIGNvbW11bmljYXRpb248YnI+DQp0byBvdGhlcnMuPGJyPg0KKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl
PTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhlIGVtYWlsIGhhcyAmbmJzcDti
ZWVuIHNjYW5uZWQgYnkgQW50aS1TcGFtPGJyPg0Kc3lzdGVtLCAmbmJzcDtpZiB5b3UgZmluZCBT
cGFtIG9yIFZpcnVzIGluIHRoaXMgbWFpbCw8YnI+DQpwbGVhc2UgZm9yd2FyZCBpdCB0bzogaGVs
cGRlc2tAenRlLmNvbS5jbjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKjwvZm9udD4NCjxwPg0KPGJyPjxicj48YnI+CioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgrQxc+isLLIq8n5w/ejurG+08q8/rD8
uqzQxc+iuelaVEXL+dPQo6w8YnI+ClpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei
0uI8YnI+CrGjw9yjrM60vq23orz+yMvK6cPm0O2/yaOssru1w8/yyM66zrXaPGJyPgrI/be91+nW
r7rNuPbIy824wraxvtPKvP7L+bqs0MXPorXEyKuyvzxicj4Ku/Kyv7fWoaPS1MnPyfnD9732ysrT
w9PauaTX99PKvP6hozxicj4KSW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwOyZuYnNwO05v
dGljZaO6PGJyPgpUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5i
c3A7dGhpcyZuYnNwO21haWwmbmJzcDtpczxicj4Kc29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtv
ZiZuYnNwOyZuYnNwO1pURSZuYnNwO0NvcnBvcmF0aW9uLiZuYnNwOzxicj4KVGhpcyZuYnNwO21h
aWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuPGJyPgpSZWNp
cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw
O3RvPGJyPgptYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm
bmJzcDtwZXJtaXR0ZWQmbmJzcDt0bzxicj4KZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50
cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb248YnI+CnRvJm5ic3A7b3RoZXJz
Ljxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+
Cg==
--=_alternative 000A4E1D482570D6_=--


--===============0670313117==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0670313117==--




From sip-bounces@ietf.org Tue Dec 13 05:17:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Em7Dl-00005X-3q; Tue, 13 Dec 2005 05:17:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Em7Di-0008WO-GU
	for sip@megatron.ietf.org; Tue, 13 Dec 2005 05:17:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00493
	for <sip@ietf.org>; Tue, 13 Dec 2005 05:16:13 -0500 (EST)
Received: from web52913.mail.yahoo.com ([206.190.49.23])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Em7EQ-0001Sq-Hu
	for sip@ietf.org; Tue, 13 Dec 2005 05:18:11 -0500
Received: (qmail 66369 invoked by uid 60001); 13 Dec 2005 10:16:52 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=DE4Ypl7/NdVEBATcIGVuOFX3beI4Qq5r+3CBKXZBsKavwvn+qW65MpySJcl9+1jHHX6/iLc4dePCl5gJpPxSZH0D0Bdy1G6llWLePg2CLN0G5V5z3Dxc4sc9ldzB/jhRwmakW4pc8+25jgAxcu6+EvrY6xm0kvTdDZ8FVmN6sng=
	; 
Message-ID: <20051213101652.66367.qmail@web52913.mail.yahoo.com>
Received: from [163.167.62.58] by web52913.mail.yahoo.com via HTTP;
	Tue, 13 Dec 2005 02:16:52 PST
Date: Tue, 13 Dec 2005 02:16:52 -0800 (PST)
From: sulayman camara <sulaymanborry@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA00493
Subject: [Sip] Re: Sip Digest, Vol 20, Issue 16
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I don't want to receive any more mail from you please.

--- sip-request@ietf.org wrote:

> Send Sip mailing list submissions to
> 	sip@ietf.org
>=20
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	https://www1.ietf.org/mailman/listinfo/sip
> or, via email, send a message with subject or body
> 'help' to
> 	sip-request@ietf.org
>=20
> You can reach the person managing the list at
> 	sip-owner@ietf.org
>=20
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Sip digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. one question on the authentication for
> third-party
>       registration (shi.hao2@zte.com.cn)
>    2. RE: one question on the authentication for
>       third-partyregistration (Kasturi Narayanan)
>    3.
>
=3D?GB2312?B?tPC4tDogUkU6IFtTaXBdIG9uZSBxdWVzdGlvbiBvbiB0aGU=3D?=3D
>     =20
>
=3D?GB2312?B?IGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24=3D=
?=3D
>       (shi.hao2@zte.com.cn)
>    4. RE: one question on the authentication for
> third-party
>       registration (Mahesh Govind)
>=20
>=20
>
----------------------------------------------------------------------
>=20
> Message: 1
> Date: Tue, 13 Dec 2005 09:07:24 +0800
> From: shi.hao2@zte.com.cn
> Subject: [Sip] one question on the authentication
> for third-party
> 	registration
> To: sip@ietf.org
> Message-ID:
>=20
>
<OFC214C953.AAD8EFF9-ON482570D6.00061423-482570D6.0006544E@zte.com.cn>
> Content-Type: text/plain; charset=3D"us-ascii"
>=20
> Hi,
>=20
> I am confused by the authentication for third-party
> registration.=20
>=20
> We assume that Bob registrers for Alice, so the
> REGISTER request may be=20
> like this:
>=20
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP
> bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7
> Max-Forwards: 70
> To: Alice <sip:alice@biloxi.com>
> From: Bob <sip:bob@biloxi.com>;tag=3D456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact: <sip:bob@192.0.2.4>
> Expires: 7200
> Content-Length: 0
>=20
>=20
> As RFC3261 Section 10.3 (page 64) described,
> registrar SHOULD authenticate=20
> the UAC using=20
> the mechanisms described in RFC3261 Section 22, so
> the username of the=20
> credential should=20
> be "bob", while RFC3261 Section 26.3.2.1 (page 243)
> said that username of=20
> this credential=20
> SHOULD correspond with the "userinfo" portion of the
> URI in the To header=20
> field of the=20
> REGISTER request, that is "alice", this means
> authentication is for Alice,=20
> not Bob.
>=20
> Which one is the correct?
>=20
> Best Regards,
> LionEagle
>=20
>=20
>=20
>=20
> ***********************************************
>
=E4=BF=A1=E6=81=AF=E5=AE=89=E5=85=A8=E5=A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC=E9=
=82=AE=E4=BB=B6=E5=8C=85=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD=92ZTE=E6=89=80=E6=
=9C=89=EF=BC=8C
>
ZTE=E5=AF=B9=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=8B=A5=E6=9C=89=E6=89=80=E6=9C=89=
=E6=9D=83=E5=88=A9=E3=80=82=E8=AF=B7=E6=8E=A5=E6=94=B6=E8=80=85=E6=B3=A8=E6=
=84=8F
>
=E4=BF=9D=E5=AF=86=EF=BC=8C=E6=9C=AA=E7=BB=8F=E5=8F=91=E4=BB=B6=E4=BA=BA=E4=
=B9=A6=E9=9D=A2=E8=AE=B8=E5=8F=AF=EF=BC=8C=E4=B8=8D=E5=BE=97=E5=90=91=E4=BB=
=BB=E4=BD=95=E7=AC=AC
>
=E4=B8=89=E6=96=B9=E7=BB=84=E7=BB=87=E5=92=8C=E4=B8=AA=E4=BA=BA=E9=80=8F=E9=
=9C=B2=E6=9C=AC=E9=82=AE=E4=BB=B6=E6=89=80=E5=90=AB=E4=BF=A1=E6=81=AF=E7=9A=
=84=E5=85=A8=E9=83=A8
> =E6=88=96=E9=83=A8=E5=88=86=E3=80=82=E4=BB=A5=E4=B8=8A=E5=A3=B0=E6=98=8E=
=E4=BB=85=E9=80=82=E7=94=A8=E4=BA=8E=E5=B7=A5=E4=BD=9C=E9=82=AE=E4=BB=B6=E3=
=80=82
> Information Security  Notice=EF=BC=9A
> The information contained in this mail is
> solely property of  ZTE Corporation.=20
> This mail communication is confidential.
> Recipients named above are obligated to
> maintain secrecy and are not permitted to
> disclose the contents of this communication
> to others.
> ***********************************************
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://www1.ietf.org/pipermail/sip/attachments/20051213/1b49dc50/attachme=
nt.htm
>=20
> ------------------------------
>=20
> Message: 2
> Date: Mon, 12 Dec 2005 19:20:20 -0600
> From: "Kasturi Narayanan" <knarayan@sipera.com>
> Subject: RE: [Sip] one question on the
> authentication for
> 	third-partyregistration
> To: <shi.hao2@zte.com.cn>, <sip@ietf.org>
> Message-ID: <200512130119.UAA03358@ietf.org>
> Content-Type: text/plain; charset=3D"us-ascii"
>=20
> Ideally the intention is to authenticate the
> originator of the Register
> regardless of whom that person is registering.
>=20
> Once authenticated there may be authorization needed
> (local policy)
> regarding whom all this person can register if the
> person to be registered
> is a valid user of this network.
>=20
> So authentication is done for the originator of the
> request.=20
>=20
> =20
>=20
> And also in your example if Alice is being
> registered u may want the contact
> to look like alice@192.0.2.4 unless u intentionally
> meant that.
>=20
> =20
>=20
> If what u mentioned below is true then it needs to
> be looked into.
>=20
> =20
>=20
> Kasturi
>=20
>   _____ =20
>=20
> From: sip-bounces@ietf.org
> [mailto:sip-bounces@ietf.org] On Behalf Of
> shi.hao2@zte.com.cn
> Sent: Monday, December 12, 2005 7:07 PM
> To: sip@ietf.org
> Subject: [Sip] one question on the authentication
> for
> third-partyregistration
>=20
> =20
>=20
>=20
> Hi,=20
>=20
> I am confused by the authentication for third-party
> registration.=20
>=20
> We assume that Bob registrers for Alice, so the
> REGISTER request may be like
> this:=20
>=20
> REGISTER sip:registrar.biloxi.com SIP/2.0=20
> Via: SIP/2.0/UDP
> bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20
> Max-Forwards: 70=20
> To: Alice <sip:alice@biloxi.com>=20
> From: Bob <sip:bob@biloxi.com>;tag=3D456248=20
> Call-ID: 843817637684230@998sdasdh09=20
> CSeq: 1826 REGISTER=20
> Contact: <sip:bob@192.0.2.4>=20
> Expires: 7200=20
> Content-Length: 0=20
>=20
>=20
> As RFC3261 Section 10.3 (page 64) described,
> registrar SHOULD authenticate
> the UAC using=20
> the mechanisms described in RFC3261 Section 22, so
> the username of the
> credential should=20
> be "bob", while RFC3261 Section 26.3.2.1 (page 243)
> said that username of
> this credential=20
>=20
=3D=3D=3D message truncated =3D=3D=3D


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 13 16:33:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmHm2-0007RL-0F; Tue, 13 Dec 2005 16:33:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmHm0-0007R7-S5
	for sip@megatron.ietf.org; Tue, 13 Dec 2005 16:33:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01684
	for <sip@ietf.org>; Tue, 13 Dec 2005 16:32:15 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmHmr-0003Ur-O1
	for sip@ietf.org; Tue, 13 Dec 2005 16:34:19 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id A623E6C017
	for <sip@ietf.org>; Tue, 13 Dec 2005 16:32:59 -0500 (EST)
Subject: Re: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= RE: [Sip] one question on
	the authentication for third-party registration
From: "Dale R. Worley" <dworley@pingtel.com>
To: Sip <sip@ietf.org>
In-Reply-To: <OF8B6FA05D.AD08866F-ON482570D6.0008F74D-482570D6.0009F742@zte.com.cn>
References: <OF8B6FA05D.AD08866F-ON482570D6.0008F74D-482570D6.0009F742@zte.com.cn>
Content-Type: text/plain
Date: Tue, 13 Dec 2005 16:32:58 -0500
Message-Id: <1134509579.26809.14.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Tue, 2005-12-13 at 09:47 +0800, shi.hao2@zte.com.cn wrote:
> My confusion is the username of the credential not the Contact in
> REGISTER. I think the username of the credential should be "bob" since
> the originator of REGISTER is bob, but RFC3261 Section 26.3.2.1 (page
> 243) said that username of this credential 
> SHOULD correspond with the "userinfo" portion of the URI in the To
> header field of the REGISTER request. 

There is no single answer, as it depends on local policy -- What
credentials does a request have to present in order to be allowed to
modify the bindings for alice@...?

A safe choice seems to be "the UA must present alice's credentials".
But that might not work, or it might not be desirable for bob to have
alice's credentials.  But in order for bob's credentials to be adequate
to update alice's bindings, the registrar needs to know which
credentials are sufficient for modifying which bindings.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 13 19:45:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmKmF-0003Mm-5f; Tue, 13 Dec 2005 19:45:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKm9-0003Lb-3q
	for sip@megatron.ietf.org; Tue, 13 Dec 2005 19:45:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26708
	for <sip@ietf.org>; Tue, 13 Dec 2005 19:44:34 -0500 (EST)
Received: from mailout3.samsung.com ([203.254.224.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmKn1-0003L7-I7
	for sip@ietf.org; Tue, 13 Dec 2005 19:46:41 -0500
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33])
	by mailout3.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IRG0021UQ3F1Y@mailout3.samsung.com> for sip@ietf.org;
	Wed, 14 Dec 2005 09:45:15 +0900 (KST)
Received: from mahesh ([165.213.203.251])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IRG007WMQ3FBQ@mmp1.samsung.com> for sip@ietf.org; Wed,
	14 Dec 2005 09:45:15 +0900 (KST)
Date: Wed, 14 Dec 2005 09:44:13 +0900
From: Mahesh Govind <mahesh.govind@samsung.com>
Subject: =?iso-2022-jp?B?UkU6IBskQiViJVgbKEI/OiBSRTogW1NpcF0gb25lIHF1ZXN0aW9uIA==?=
	=?iso-2022-jp?B?b24JdGhlIGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdp?=
	=?iso-2022-jp?B?c3RyYXRpb24=?=
In-reply-to: <1134509579.26809.14.camel@cdhcp139.pingtel.com>
To: "'Dale R. Worley'" <dworley@pingtel.com>, "'Sip'" <sip@ietf.org>
Message-id: <000501c60047$80f69700$fbcbd5a5@mahesh>
Organization: Samsung
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7BIT
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,
If the protocol is not providing a fool proof mechanism  for third party
registrations , will it lead to hacking ?

-mahesh

  

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale
R. Worley
Sent: Wednesday, December 14, 2005 6:33 AM
To: Sip
Subject: Re: $BEz(B?: RE: [Sip] one question on the authentication for
third-party registration

On Tue, 2005-12-13 at 09:47 +0800, shi.hao2@zte.com.cn wrote:
> My confusion is the username of the credential not the Contact in
> REGISTER. I think the username of the credential should be "bob" since
> the originator of REGISTER is bob, but RFC3261 Section 26.3.2.1 (page
> 243) said that username of this credential 
> SHOULD correspond with the "userinfo" portion of the URI in the To
> header field of the REGISTER request. 

There is no single answer, as it depends on local policy -- What
credentials does a request have to present in order to be allowed to
modify the bindings for alice@...?

A safe choice seems to be "the UA must present alice's credentials".
But that might not work, or it might not be desirable for bob to have
alice's credentials.  But in order for bob's credentials to be adequate
to update alice's bindings, the registrar needs to know which
credentials are sufficient for modifying which bindings.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 13 22:55:46 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmNk2-0003cd-7u; Tue, 13 Dec 2005 22:55:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmNk0-0003bg-Hy
	for sip@megatron.ietf.org; Tue, 13 Dec 2005 22:55:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18611
	for <sip@ietf.org>; Tue, 13 Dec 2005 22:54:47 -0500 (EST)
Received: from nproxy.gmail.com ([64.233.182.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmNl7-0001sz-Li
	for sip@ietf.org; Tue, 13 Dec 2005 22:56:54 -0500
Received: by nproxy.gmail.com with SMTP id h2so5538nfe
	for <sip@ietf.org>; Tue, 13 Dec 2005 19:55:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=XcItQE186m/hUyvQWA7ujcWayM5ffD7i39xO6ThzaRj/lkEhCooHD9ux1fPCv6kROR59C6jIhpNkSYd9SEwFswuxH6mulFQniothRkrZBm8EnoJBmxcQ+9Xf8wKQRGrtDCalDODDTxgY2HPXmxwUrTn7jift6WF40n0hg8U5QBs=
Received: by 10.48.229.9 with SMTP id b9mr4436nfh;
	Tue, 13 Dec 2005 19:55:41 -0800 (PST)
Received: by 10.48.215.16 with HTTP; Tue, 13 Dec 2005 19:55:41 -0800 (PST)
Message-ID: <52db68bc0512131955m15eced4i2c99a0eb24be8767@mail.gmail.com>
Date: Wed, 14 Dec 2005 09:25:41 +0530
From: Sudhir Kumar Reddy <t.sudhirkumar@gmail.com>
To: sip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Subject: [Sip] Query about REFER request
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="===============1577813751=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============1577813751==
Content-Type: multipart/alternative; 
	boundary="----=_Part_46130_25234027.1134532541503"

------=_Part_46130_25234027.1134532541503
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Everyone,

  I'm working on REFER request, could anyone tell how to processes the
sucess and failure of REFER.

  I've read RFC 3515 REFER but it was not that much clear..


  Any feedback is appericated..

  thanks in advance

  regards
  Sudhir

------=_Part_46130_25234027.1134532541503
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Everyone,<br>&nbsp;&nbsp; <br>&nbsp; I'm working on REFER request, could=
 anyone tell how to processes the <br>sucess and failure of REFER.<br>&nbsp=
;&nbsp; <br>&nbsp; I've read RFC 3515 REFER but it was not that much clear.=
.<br>&nbsp;&nbsp; <br>&nbsp;&nbsp; <br>&nbsp; Any feedback is appericated..
<br>&nbsp;&nbsp; <br>&nbsp; thanks in advance<br>&nbsp;&nbsp; <br>&nbsp; re=
gards<br>&nbsp; Sudhir<br>

------=_Part_46130_25234027.1134532541503--


--===============1577813751==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1577813751==--




From sip-bounces@ietf.org Wed Dec 14 00:48:25 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmPV2-0002eK-Os; Wed, 14 Dec 2005 00:48:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmPUt-0002T1-RX; Wed, 14 Dec 2005 00:48:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29512;
	Wed, 14 Dec 2005 00:47:12 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EmPVv-0005sy-5g; Wed, 14 Dec 2005 00:49:21 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 21:47:25 -0800
X-IronPort-AV: i="3.99,250,1131350400"; 
	d="scan'208"; a="240735957:sNHT8437282708"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBE5lMpf001883;
	Tue, 13 Dec 2005 21:47:23 -0800 (PST)
Received: from 10.21.96.130 ([10.21.96.130]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 14 Dec 2005 05:47:22 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 13 Dec 2005 21:47:29 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: Stastny Richard <Richard.Stastny@oefeg.at>,
	Klaus Darilion <klaus.mailinglists@pernau.at>
Message-ID: <BFC4F1F1.65473%fluffy@cisco.com>
Thread-Topic: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
Thread-Index: AcX8t62w821JMsoqQGCdm3aV0mJTAAAAtcKNAO3WbuI=
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C470E@oefeg-s04.oefeg.loc>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, VoIPeer <voipeer@lists.uoregon.edu>,
	enum@ietf.org
Subject: [Sip] Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


Seems to me that the redirect model, with TLS, provide much more information
to the parties about the level of trust. It allows a two separate trust
transaction between two parties instead of a three way transitive trust
problem that TLS has no machinery to deal with.


On 12/9/05 4:17 AM, "Stastny Richard" <Richard.Stastny@oefeg.at> wrote:

> Thanx Klaus
> 
> for the work ;-)
> 
> Now the next question:
> What are the implications proxy vs redirect
> if you are using TLS?
>  
> Richard
> 
> ________________________________
> 
> Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Gesendet: Fr 09.12.2005 12:52
> An: Stastny Richard
> Cc: sip@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org
> Betreff: Re: [voipeer] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> 
> 
> Stastny Richard wrote:
>> Thanx Klaus
>> 
>> Also for answering a question I did not (yet) ask
>> regarding redirect vs proxy
>> 
>> 
>> 
>>> I personally prefer relaying instead of redirect.
>> 
>> 
>> Me too and I see your arguments.
>> Are there any arguments out there why to prefer redriect?
> 
> I just made some signaling pictures to visualize the difference:
>  From the signaling, there is no big difference. Both versions do need
> approximately the same amount of signaling packets sent (depends onthe
> actual SIP network design).
> 
> I do not see any technical reason why to prefer one version over the
> other. It's just a personal preference.
> 
> regards
> klaus
> 
> 
> UAC  proxyA  borderProxyA       redirectProxy borderProxyB  proxyB  UAS
> |        |          |                  |             |        |      |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |                  |             |        |        |
> |        |          |<------302--------|             |        |        |
> |        |<-302-----|-------ACK------->|             |        |        |
> |        |--ACK---->|                  |             |        |        |
> |        |--INVITE->|                  |             |        |        |
> |        |<-100-----|--------------INVITE----------->|        |        |
> |        |          |<--------------100--------------|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |<---------------180-------------|        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |<---------------200-------------|        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |        |
> 
> 32 Packets
> 
> 
> UAC   proxyA  borderProxyA       forwardProxy  borderProxyB  proxyB  UAS
> |        |          |                  |             |        |        |
> |-INVITE>|          |                  |             |        |        |
> |<-100---|-INVITE-->|                  |             |        |        |
> |        |<--100----|-------INVITE---->|             |        |        |
> |        |          |<-------100-------|---INVITE--->|        |        |
> |        |          |                  |<----100-----|-INVITE>|        |
> |        |          |                  |             |<-100---|-INVITE>|
> |        |          |                  |             |        |<-100---|
> |        |          |                  |             |        |        |
> |        |          |                  |             |        |<-180---|
> |        |          |                  |             |<--180--|        |
> |        |          |                  |<---180------|        |        |
> |        |          |<----- -180-------|             |        |        |
> |        |<--180----|                  |             |        |        |
> |<--180--|          |                  |             |        |<--200--|
> |        |          |                  |             |<--200--|        |
> |        |          |                  |<---200------|        |        |
> |        |          |<-------200-------|             |        |        |
> |        |<---200---|                  |             |        |        |
> |<---200-|          |                  |             |        |        |
> |        |          |                  |             |        |        |
> |--ACK-->|          |                  |             |        |        |
> |        |----ACK-->|                  |             |        |        |
> |        |          |--------------ACK-------------->|        |        |
> |        |          |                  |             |--ACK-->|        |
> |        |          |                  |             |        |--ACK-->|
> 
> 29 Packets
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 14 10:29:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmYZA-0006LH-Kg; Wed, 14 Dec 2005 10:29:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYZ9-0006KI-El
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 10:29:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10196
	for <sip@ietf.org>; Wed, 14 Dec 2005 10:28:05 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYa6-0003Bd-Ua
	for sip@ietf.org; Wed, 14 Dec 2005 10:30:16 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id 1A4B16C01C
	for <sip@ietf.org>; Wed, 14 Dec 2005 10:28:46 -0500 (EST)
Subject: RE: =?UTF-8?Q?=E3=83=A2=E3=83=98=3F=3A?= RE: [Sip] one question
	on	the authentication for third-party registration
From: "Dale R. Worley" <dworley@pingtel.com>
To: Sip <sip@ietf.org>
In-Reply-To: <000501c60047$80f69700$fbcbd5a5@mahesh>
References: <000501c60047$80f69700$fbcbd5a5@mahesh>
Content-Type: text/plain
Date: Wed, 14 Dec 2005 10:28:46 -0500
Message-Id: <1134574126.25240.7.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
> If the protocol is not providing a fool proof mechanism  for third party
> registrations , will it lead to hacking ?

My point is that the critical factor isn't the protocol, but the
registrar.  If the registrar does not have sound policies, it can be
hacked.  If the registrar does not allow third-party registrations, and
validates all request credentials against the sender name, then it can
in a sense "depend on the protocol".  Otherwise, the registrar's
policies are crucial.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 14 11:28:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmZUU-0008Iz-NW; Wed, 14 Dec 2005 11:28:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmZUS-0008Ij-KL
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 11:28:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18788
	for <sip@ietf.org>; Wed, 14 Dec 2005 11:27:30 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmZVh-0005w5-3w
	for sip@ietf.org; Wed, 14 Dec 2005 11:29:45 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2005 11:28:20 -0500
X-IronPort-AV: i="3.99,252,1131339600"; 
	d="scan'208"; a="77738999:sNHT31598696"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBEGRm4x017185; 
	Wed, 14 Dec 2005 11:28:17 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 14 Dec 2005 11:28:09 -0500
Received: from [10.86.240.38] ([10.86.240.38]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 14 Dec 2005 11:28:09 -0500
Message-ID: <43A04819.2020401@cisco.com>
Date: Wed, 14 Dec 2005 11:28:09 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Dale R. Worley" <dworley@pingtel.com>
Subject: Re: =?UTF-8?B?44Oi44OYPzogUkU6IFtTaXBdIG9uZSBxdWVzdGlvbiBvbiB0aGU=?=
	=?UTF-8?B?IGF1dGhlbnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24=?=
References: <000501c60047$80f69700$fbcbd5a5@mahesh>
	<1134574126.25240.7.camel@cdhcp139.pingtel.com>
In-Reply-To: <1134574126.25240.7.camel@cdhcp139.pingtel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2005 16:28:09.0743 (UTC)
	FILETIME=[5EEA91F0:01C600CB]
X-Spam-Score: 0.0 (/)
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This should be considered a two step process:

1) the requestor is authenticated. The From header
    may or may not have anything to do with this.
    The end result of this is that the registrar
    should know "this is Bob requesting to register".

2) the request is authorized. The question to be
    answered is: "is Bob permitted to register using
    Alice's AOR?" A simple answer to this might be:
    "NO - only alice may register for Alice." A more
    flexible registrar may have an ACL for each AOR
    specifying who may register to it. It might say
    "both Alice and Bob may register for Alice".

Both of these steps are driven by policy in the registrar, and not 
specified by the sip standards. (An authentication *mechanism* - digest 
- is specified. But it doesn't say anything about *who* can successfully 
authenticate, nor does it say whether this has anything to do with the 
contents of the From header.)

	Paul

Dale R. Worley wrote:
> On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
> 
>>If the protocol is not providing a fool proof mechanism  for third party
>>registrations , will it lead to hacking ?
> 
> 
> My point is that the critical factor isn't the protocol, but the
> registrar.  If the registrar does not have sound policies, it can be
> hacked.  If the registrar does not allow third-party registrations, and
> validates all request credentials against the sender name, then it can
> in a sense "depend on the protocol".  Otherwise, the registrar's
> policies are crucial.
> 
> Dale
> 
> 
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Wed Dec 14 17:59:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emfaq-0003QN-M5; Wed, 14 Dec 2005 17:59:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emfap-0003Om-4n
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 17:59:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09913
	for <sip@ietf.org>; Wed, 14 Dec 2005 17:58:28 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emfc4-0005GJ-5K
	for sip@ietf.org; Wed, 14 Dec 2005 18:00:47 -0500
Received: from [64.101.172.230] ([64.101.172.230]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBEN4hOO009632
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <sip@ietf.org>; Wed, 14 Dec 2005 17:05:10 -0600
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <34A83287-8FCA-44F2-8DDC-40CB67E29105@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Sip <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Wed, 14 Dec 2005 16:59:21 -0600
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Subject: [Sip] Revised answermode draft
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


I've made the changes requested to the answermode draft and submitted  
a revision. Until it appears in the archive, you can retrieve it from:

http://www.softarmor.com/wgdb/docs/draft-ietf-sip-answermode-00.txt
http://www.softarmor.com/wgdb/docs/draft-ietf-sip-answermode-00.xml
http://www.softarmor.com/wgdb/docs/draft-ietf-sip-answermode-00.ht

--
Dean Willis

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 14 19:45:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmhFq-0000SV-RV; Wed, 14 Dec 2005 19:45:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhFo-0000Ra-U3
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 19:45:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20343
	for <sip@ietf.org>; Wed, 14 Dec 2005 19:44:54 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmhH7-0000lI-Tr
	for sip@ietf.org; Wed, 14 Dec 2005 19:47:14 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 14 Dec 2005 16:45:43 -0800
X-IronPort-AV: i="3.99,255,1131350400"; 
	d="scan'208"; a="241049342:sNHT31319422"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0jfpf014102;
	Wed, 14 Dec 2005 16:45:41 -0800 (PST)
Received: from 128.107.139.242 ([128.107.139.242]) by
	vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft
	Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:45:40 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 14 Dec 2005 16:45:49 -0800
Subject: Re: =?ISO-2022-JP?B?GyRCJWIlWBsoQg==?=?: RE: [Sip] one question
	on the authentication for third-party registration
From: Cullen Jennings <fluffy@cisco.com>
To: Paul H Kyzivat <pkyzivat@cisco.com>, "Dale R. Worley" <dworley@pingtel.com>
Message-ID: <BFC5FCBD.65799%fluffy@cisco.com>
Thread-Topic: =?ISO-2022-JP?B?GyRCJWIlWBsoQg==?=?: RE: [Sip] one question
	on the authentication for third-party registration
Thread-Index: AcYBEORrItQOxm0EEdqJKAARJEEJ/A==
In-Reply-To: <43A04819.2020401@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


Has anyone build a proxy that allows the configuration of a policy that says
Bob is allowed to register for Alice's AOR?



On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> This should be considered a two step process:
> 
> 1) the requestor is authenticated. The From header
>     may or may not have anything to do with this.
>     The end result of this is that the registrar
>     should know "this is Bob requesting to register".
> 
> 2) the request is authorized. The question to be
>     answered is: "is Bob permitted to register using
>     Alice's AOR?" A simple answer to this might be:
>     "NO - only alice may register for Alice." A more
>     flexible registrar may have an ACL for each AOR
>     specifying who may register to it. It might say
>     "both Alice and Bob may register for Alice".
> 
> Both of these steps are driven by policy in the registrar, and not
> specified by the sip standards. (An authentication *mechanism* - digest
> - is specified. But it doesn't say anything about *who* can successfully
> authenticate, nor does it say whether this has anything to do with the
> contents of the From header.)
> 
> Paul
> 
> Dale R. Worley wrote:
>> On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
>> 
>>> If the protocol is not providing a fool proof mechanism  for third party
>>> registrations , will it lead to hacking ?
>> 
>> 
>> My point is that the critical factor isn't the protocol, but the
>> registrar.  If the registrar does not have sound policies, it can be
>> hacked.  If the registrar does not allow third-party registrations, and
>> validates all request credentials against the sender name, then it can
>> in a sense "depend on the protocol".  Otherwise, the registrar's
>> policies are crucial.
>> 
>> Dale
>> 
>> 
>> 
>> _______________________________________________
>> 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

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 14 20:42:51 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emi8x-0007rZ-Qo; Wed, 14 Dec 2005 20:42:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emi8r-0007qG-RP
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 20:42:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25164
	for <sip@ietf.org>; Wed, 14 Dec 2005 20:41:36 -0500 (EST)
Received: from mailout1.samsung.com ([203.254.224.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emi9g-0002dq-47
	for sip@ietf.org; Wed, 14 Dec 2005 20:43:57 -0500
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IRI00999NE4GM@mailout1.samsung.com> for sip@ietf.org;
	Thu, 15 Dec 2005 10:42:04 +0900 (KST)
Received: from mahesh ([165.213.203.251])
	by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built
	Jun 23 2003)) with ESMTPA id <0IRI00JBNNE3A4@mmp2.samsung.com> for
	sip@ietf.org; Thu, 15 Dec 2005 10:42:04 +0900 (KST)
Date: Thu, 15 Dec 2005 10:41:04 +0900
From: Mahesh Govind <mahesh.govind@samsung.com>
Subject: =?utf-8?B?UkU6IOq4vuq4tj86IFJFOiBbU2lwXSBvbmUgcXVlc3Rpb24Jb24gdGhlIGF1dGhl?=
	=?utf-8?B?bnRpY2F0aW9uIGZvciB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24=?=
In-reply-to: <BFC5FCBD.65799%fluffy@cisco.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>,
	"'Paul H Kyzivat'" <pkyzivat@cisco.com>,
	"'Dale R. Worley'" <dworley@pingtel.com>
Message-id: <001901c60118$9d51e270$fbcbd5a5@mahesh>
Organization: Samsung
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

HI,
I have one more query related to this .
In such cases can I expect 100% interoperability.
Will I be able to buy a sip phone from market and=20
do a third party registration successfully , with any operator ?
If a registrar rejects a request, what exact reason it will give?

-Mahesh


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =
Cullen Jennings
Sent: Thursday, December 15, 2005 9:46 AM
To: Paul H Kyzivat; Dale R. Worley
Cc: sip@ietf.org
Subject: Re: =C6=92=E2=80=9A=C6=92w?: RE: [Sip] one question on the =
authentication for third-party registration


Has anyone build a proxy that allows the configuration of a policy that =
says
Bob is allowed to register for Alice's AOR?



On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> This should be considered a two step process:
>=20
> 1) the requestor is authenticated. The From header
>     may or may not have anything to do with this.
>     The end result of this is that the registrar
>     should know "this is Bob requesting to register".
>=20
> 2) the request is authorized. The question to be
>     answered is: "is Bob permitted to register using
>     Alice's AOR?" A simple answer to this might be:
>     "NO - only alice may register for Alice." A more
>     flexible registrar may have an ACL for each AOR
>     specifying who may register to it. It might say
>     "both Alice and Bob may register for Alice".
>=20
> Both of these steps are driven by policy in the registrar, and not
> specified by the sip standards. (An authentication *mechanism* - =
digest
> - is specified. But it doesn't say anything about *who* can =
successfully
> authenticate, nor does it say whether this has anything to do with the
> contents of the From header.)
>=20
> Paul
>=20
> Dale R. Worley wrote:
>> On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
>>=20
>>> If the protocol is not providing a fool proof mechanism  for third =
party
>>> registrations , will it lead to hacking ?
>>=20
>>=20
>> My point is that the critical factor isn't the protocol, but the
>> registrar.  If the registrar does not have sound policies, it can be
>> hacked.  If the registrar does not allow third-party registrations, =
and
>> validates all request credentials against the sender name, then it =
can
>> in a sense "depend on the protocol".  Otherwise, the registrar's
>> policies are crucial.
>>=20
>> Dale
>>=20
>>=20
>>=20
>> _______________________________________________
>> 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
>>=20
>=20
> _______________________________________________
> 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



_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 14 23:39:00 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmktQ-000190-NH; Wed, 14 Dec 2005 23:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmktO-00014H-UD
	for sip@megatron.ietf.org; Wed, 14 Dec 2005 23:38:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11088
	for <sip@ietf.org>; Wed, 14 Dec 2005 23:38:00 -0500 (EST)
Received: from mail.pingtel.com ([65.220.123.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emkuj-0008G2-1c
	for sip@ietf.org; Wed, 14 Dec 2005 23:40:22 -0500
Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2])
	by mail.pingtel.com (Postfix) with ESMTP id B5A696C017
	for <sip@ietf.org>; Wed, 14 Dec 2005 23:38:50 -0500 (EST)
Subject: RE: =?UTF-8?Q?=EA=B8=BE=EA=B8=B6=3F=3A?= RE: [Sip] one question	on
	the authentication for third-party registration
From: "Dale R. Worley" <dworley@pingtel.com>
To: Sip <sip@ietf.org>
In-Reply-To: <001901c60118$9d51e270$fbcbd5a5@mahesh>
References: <001901c60118$9d51e270$fbcbd5a5@mahesh>
Content-Type: text/plain
Date: Wed, 14 Dec 2005 23:38:50 -0500
Message-Id: <1134621530.14083.3.camel@cdhcp139.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-NONENGLISH: Subject contains non-English characters
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Thu, 2005-12-15 at 10:41 +0900, Mahesh Govind wrote:
> Will I be able to buy a sip phone from market and 
> do a third party registration successfully , with any operator ?

I do not recall any phone that does third-party registrations.

> If a registrar rejects a request, what exact reason it will give?

Some SIP agents give reasons when they return an error, but most do not.

Dale



_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 15 00:06:49 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmlKL-0000Ig-CI; Thu, 15 Dec 2005 00:06:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmlKF-0000IR-G2
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 00:06:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13303
	for <sip@ietf.org>; Thu, 15 Dec 2005 00:05:37 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EmlLR-0000m9-NI for sip@ietf.org; Thu, 15 Dec 2005 00:07:59 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 21:06:25 -0800
X-IronPort-AV: i="3.99,256,1131350400"; 
	d="scan'208"; a="684811697:sNHT32792664"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBF56JQM029012;
	Wed, 14 Dec 2005 21:06:22 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 15 Dec 2005 00:06:19 -0500
Received: from [10.86.240.38] ([10.86.240.38]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 15 Dec 2005 00:06:19 -0500
Message-ID: <43A0F9CA.3000301@cisco.com>
Date: Thu, 15 Dec 2005 00:06:18 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication for
	third-party registration
References: <BFC5FCBD.65799%fluffy@cisco.com>
In-Reply-To: <BFC5FCBD.65799%fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2005 05:06:19.0477 (UTC)
	FILETIME=[48E92050:01C60135]
X-Spam-Score: 2.7 (++)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I'm not aware of any. But I've been discussing use cases for it for 
years. One is for a boss/secretary arrangement, where the secretary can 
register for the boss' AOR, but doesn't need the boss' own credentials 
to do it.

Somebody has to be first. Go for it!

	Paul

Cullen Jennings wrote:
> Has anyone build a proxy that allows the configuration of a policy that says
> Bob is allowed to register for Alice's AOR?
> 
> 
> 
> On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> 
> 
>>This should be considered a two step process:
>>
>>1) the requestor is authenticated. The From header
>>    may or may not have anything to do with this.
>>    The end result of this is that the registrar
>>    should know "this is Bob requesting to register".
>>
>>2) the request is authorized. The question to be
>>    answered is: "is Bob permitted to register using
>>    Alice's AOR?" A simple answer to this might be:
>>    "NO - only alice may register for Alice." A more
>>    flexible registrar may have an ACL for each AOR
>>    specifying who may register to it. It might say
>>    "both Alice and Bob may register for Alice".
>>
>>Both of these steps are driven by policy in the registrar, and not
>>specified by the sip standards. (An authentication *mechanism* - digest
>>- is specified. But it doesn't say anything about *who* can successfully
>>authenticate, nor does it say whether this has anything to do with the
>>contents of the From header.)
>>
>>Paul
>>
>>Dale R. Worley wrote:
>>
>>>On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
>>>
>>>
>>>>If the protocol is not providing a fool proof mechanism  for third party
>>>>registrations , will it lead to hacking ?
>>>
>>>
>>>My point is that the critical factor isn't the protocol, but the
>>>registrar.  If the registrar does not have sound policies, it can be
>>>hacked.  If the registrar does not allow third-party registrations, and
>>>validates all request credentials against the sender name, then it can
>>>in a sense "depend on the protocol".  Otherwise, the registrar's
>>>policies are crucial.
>>>
>>>Dale
>>>
>>>
>>>
>>>_______________________________________________
>>>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
> 
> 

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 15 05:12:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emq6X-0001p4-Ia; Thu, 15 Dec 2005 05:12:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emq6V-0001oW-VQ
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 05:12:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13188
	for <sip@ietf.org>; Thu, 15 Dec 2005 05:11:53 -0500 (EST)
Received: from ptr-64-201-174-137.ptr.terago.ca
	([64.201.174.137] helo=cgy01-fw.citel.com ident=daemon)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emq7t-00031p-AR
	for sip@ietf.org; Thu, 15 Dec 2005 05:14:17 -0500
Received: from [10.7.1.3] (helo=not01-mxc01.citel.com)
	by cgy01-fw01.citel.com with esmtp (Exim 4.43)
	id 1Emq6J-0000Bx-J4; Thu, 15 Dec 2005 03:12:39 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: =?us-ascii?Q?RE=3A_=1B=24B=25b=25X=1B=28B=3F=3A_RE=3A_=5BSip=5D_one_quest?=
	=?us-ascii?Q?ion_on_the_authentication_forthird-party_registration?=
Date: Thu, 15 Dec 2005 10:12:39 -0000
Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE0318F7@not01-mxc01.citel.com>
Thread-Topic: =?us-ascii?Q?=1B=24B=25b=25X=1B=28B=3F=3A_RE=3A_=5BSip=5D_one_question_on?=
	=?us-ascii?Q?_the_authentication_forthird-party_registration?=
Thread-Index: AcYBNh1NBjCfkezVTZiCrmief1sVugAJ51yw
From: "Paul Pepper" <paul.pepper@citel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Citel's product allows 3rd party registration for the very reason that
Paul gives, i.e. in shared line configurations. It works well for us.
The ID http://www.ietf.org/internet-drafts/draft-anil-sipping-bla-02.txt
defines a shared line mechanism and describes the use of third party
registration with respect to their use. I would expect organisations
that support this draft to also support third party registration.

Paul.

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Paul Kyzivat
> Sent: Thursday, December 15, 2005 5:06 AM
> To: Cullen Jennings
> Cc: sip@ietf.org
> Subject: Re: =1B$B%b%X=1B(B?: RE: [Sip] one question on the=20
> authentication forthird-party registration
>=20
>=20
> I'm not aware of any. But I've been discussing use cases for it for=20
> years. One is for a boss/secretary arrangement, where the=20
> secretary can=20
> register for the boss' AOR, but doesn't need the boss' own=20
> credentials=20
> to do it.
>=20
> Somebody has to be first. Go for it!
>=20
> 	Paul
>=20
> Cullen Jennings wrote:
> > Has anyone build a proxy that allows the configuration of a=20
> policy that says
> > Bob is allowed to register for Alice's AOR?
> >=20
> >=20
> >=20
> > On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> >=20
> >=20
> >>This should be considered a two step process:
> >>
> >>1) the requestor is authenticated. The From header
> >>    may or may not have anything to do with this.
> >>    The end result of this is that the registrar
> >>    should know "this is Bob requesting to register".
> >>
> >>2) the request is authorized. The question to be
> >>    answered is: "is Bob permitted to register using
> >>    Alice's AOR?" A simple answer to this might be:
> >>    "NO - only alice may register for Alice." A more
> >>    flexible registrar may have an ACL for each AOR
> >>    specifying who may register to it. It might say
> >>    "both Alice and Bob may register for Alice".
> >>
> >>Both of these steps are driven by policy in the registrar, and not
> >>specified by the sip standards. (An authentication=20
> *mechanism* - digest
> >>- is specified. But it doesn't say anything about *who* can=20
> successfully
> >>authenticate, nor does it say whether this has anything to=20
> do with the
> >>contents of the From header.)
> >>
> >>Paul
> >>
> >>Dale R. Worley wrote:
> >>
> >>>On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
> >>>
> >>>
> >>>>If the protocol is not providing a fool proof mechanism =20
> for third party
> >>>>registrations , will it lead to hacking ?
> >>>
> >>>
> >>>My point is that the critical factor isn't the protocol, but the
> >>>registrar.  If the registrar does not have sound policies,=20
> it can be
> >>>hacked.  If the registrar does not allow third-party=20
> registrations, and
> >>>validates all request credentials against the sender name,=20
> then it can
> >>>in a sense "depend on the protocol".  Otherwise, the registrar's
> >>>policies are crucial.
> >>>
> >>>Dale
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>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
> >=20
> >=20
>=20
> _______________________________________________
> 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
>=20

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 15 05:46:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmqdX-0002Cz-LR; Thu, 15 Dec 2005 05:46:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmqdV-0002Cu-Ee
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 05:46:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17288
	for <sip@ietf.org>; Thu, 15 Dec 2005 05:45:59 -0500 (EST)
Received: from philipp.labs.nic.at ([83.136.32.80] helo=graham.labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emqer-0004Ka-GN
	for sip@ietf.org; Thu, 15 Dec 2005 05:48:24 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50])
	by graham.labs.nic.at with esmtp (Exim 3.36 #1 (Debian))
	id 1Emqcs-0001F0-00; Thu, 15 Dec 2005 11:46:18 +0100
Message-ID: <43A1497A.4060802@pernau.at>
Date: Thu, 15 Dec 2005 11:46:18 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication for
	third-party registration
References: <BFC5FCBD.65799%fluffy@cisco.com>
In-Reply-To: <BFC5FCBD.65799%fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.7 (++)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Cullen Jennings wrote:
> Has anyone build a proxy that allows the configuration of a policy that says
> Bob is allowed to register for Alice's AOR?

I never did it yet, but I'm sure this can be done with openser (using 
pseudo variables and the AVPOPS module)

regards
klaus

> 
> 
> 
> On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> 
> 
>>This should be considered a two step process:
>>
>>1) the requestor is authenticated. The From header
>>    may or may not have anything to do with this.
>>    The end result of this is that the registrar
>>    should know "this is Bob requesting to register".
>>
>>2) the request is authorized. The question to be
>>    answered is: "is Bob permitted to register using
>>    Alice's AOR?" A simple answer to this might be:
>>    "NO - only alice may register for Alice." A more
>>    flexible registrar may have an ACL for each AOR
>>    specifying who may register to it. It might say
>>    "both Alice and Bob may register for Alice".
>>
>>Both of these steps are driven by policy in the registrar, and not
>>specified by the sip standards. (An authentication *mechanism* - digest
>>- is specified. But it doesn't say anything about *who* can successfully
>>authenticate, nor does it say whether this has anything to do with the
>>contents of the From header.)
>>
>>Paul
>>
>>Dale R. Worley wrote:
>>
>>>On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
>>>
>>>
>>>>If the protocol is not providing a fool proof mechanism  for third party
>>>>registrations , will it lead to hacking ?
>>>
>>>
>>>My point is that the critical factor isn't the protocol, but the
>>>registrar.  If the registrar does not have sound policies, it can be
>>>hacked.  If the registrar does not allow third-party registrations, and
>>>validates all request credentials against the sender name, then it can
>>>in a sense "depend on the protocol".  Otherwise, the registrar's
>>>policies are crucial.
>>>
>>>Dale
>>>
>>>
>>>
>>>_______________________________________________
>>>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
> 
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Thu Dec 15 09:54:32 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmuV6-00076m-5m; Thu, 15 Dec 2005 09:54:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuV3-00076B-O1
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 09:54:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16888
	for <sip@ietf.org>; Thu, 15 Dec 2005 09:53:21 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmuWK-0004ty-MQ
	for sip@ietf.org; Thu, 15 Dec 2005 09:55:50 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 15 Dec 2005 09:54:09 -0500
X-IronPort-AV: i="3.99,257,1131339600"; 
	d="scan'208"; a="77793711:sNHT33026076"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBFErI53006279
	for <sip@ietf.org>; Thu, 15 Dec 2005 09:54:07 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 15 Dec 2005 09:53:52 -0500
Received: from [192.168.1.102] ([10.86.242.16]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 15 Dec 2005 09:53:52 -0500
Message-ID: <43A1837F.60806@cisco.com>
Date: Thu, 15 Dec 2005 09:53:51 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication for
	third-party registration
References: <BFC5FCBD.65799%fluffy@cisco.com> <43A0F9CA.3000301@cisco.com>
In-Reply-To: <43A0F9CA.3000301@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2005 14:53:52.0617 (UTC)
	FILETIME=[5D6B6590:01C60187]
X-Spam-Score: 2.7 (++)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, "sip@ietf.org" <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I think these use cases are better handled through configuration of a 
forwarding feature that runs on the proxy. I had always envisioned xcap 
being used for this kind of thing too; we need only define schema for 
the forwarding numbers.

Note that, with draft-ietf-sip-outbound, third-party registrations are 
not possible anymore. I think thats a good thing; it allows us to 
separate routing from retargeting, per the discussion we had at ietf.

-Jonathan R.

Paul Kyzivat wrote:

> I'm not aware of any. But I've been discussing use cases for it for 
> years. One is for a boss/secretary arrangement, where the secretary can 
> register for the boss' AOR, but doesn't need the boss' own credentials 
> to do it.
> 
> Somebody has to be first. Go for it!
> 
>     Paul
> 
> Cullen Jennings wrote:
> 
>> Has anyone build a proxy that allows the configuration of a policy 
>> that says
>> Bob is allowed to register for Alice's AOR?
>>
>>
>>
>> On 12/14/05 8:28 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
>>
>>
>>> This should be considered a two step process:
>>>
>>> 1) the requestor is authenticated. The From header
>>>    may or may not have anything to do with this.
>>>    The end result of this is that the registrar
>>>    should know "this is Bob requesting to register".
>>>
>>> 2) the request is authorized. The question to be
>>>    answered is: "is Bob permitted to register using
>>>    Alice's AOR?" A simple answer to this might be:
>>>    "NO - only alice may register for Alice." A more
>>>    flexible registrar may have an ACL for each AOR
>>>    specifying who may register to it. It might say
>>>    "both Alice and Bob may register for Alice".
>>>
>>> Both of these steps are driven by policy in the registrar, and not
>>> specified by the sip standards. (An authentication *mechanism* - digest
>>> - is specified. But it doesn't say anything about *who* can successfully
>>> authenticate, nor does it say whether this has anything to do with the
>>> contents of the From header.)
>>>
>>> Paul
>>>
>>> Dale R. Worley wrote:
>>>
>>>> On Wed, 2005-12-14 at 09:44 +0900, Mahesh Govind wrote:
>>>>
>>>>
>>>>> If the protocol is not providing a fool proof mechanism  for third 
>>>>> party
>>>>> registrations , will it lead to hacking ?
>>>>
>>>>
>>>>
>>>> My point is that the critical factor isn't the protocol, but the
>>>> registrar.  If the registrar does not have sound policies, it can be
>>>> hacked.  If the registrar does not allow third-party registrations, and
>>>> validates all request credentials against the sender name, then it can
>>>> in a sense "depend on the protocol".  Otherwise, the registrar's
>>>> policies are crucial.
>>>>
>>>> Dale
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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



From sip-bounces@ietf.org Thu Dec 15 12:18:25 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmwkL-0007X4-CZ; Thu, 15 Dec 2005 12:18:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmwkI-0007WW-PE
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 12:18:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05663
	for <sip@ietf.org>; Thu, 15 Dec 2005 12:17:23 -0500 (EST)
Received: from fox.iptel.org ([195.37.77.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emwli-0001no-KG
	for sip@ietf.org; Thu, 15 Dec 2005 12:19:51 -0500
Received: from localhost.localdomain (fox.iptel.org [195.37.77.101])
	by fox.iptel.org (Postfix) with SMTP
	id 0DD842961; Thu, 15 Dec 2005 18:18:03 +0100 (CET)
Received: by localhost.localdomain (sSMTP sendmail emulation);
	Thu, 15 Dec 2005 18:24:56 +0100
Date: Thu, 15 Dec 2005 18:24:55 +0100
From: Jan Janak <jan@iptel.org>
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication for
	third-party registration
Message-ID: <20051215172455.GA5327@localhost.localdomain>
Mail-Followup-To: Paul Kyzivat <pkyzivat@cisco.com>,
	Cullen Jennings <fluffy@cisco.com>, "sip@ietf.org" <sip@ietf.org>
References: <BFC5FCBD.65799%fluffy@cisco.com> <43A0F9CA.3000301@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
In-Reply-To: <43A0F9CA.3000301@cisco.com>
User-Agent: Mutt/1.5.11
X-Spam-Score: 2.7 (++)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Cullen Jennings <fluffy@cisco.com>, "sip@ietf.org" <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On 15-12-2005 00:06, Paul Kyzivat wrote:
> I'm not aware of any. But I've been discussing use cases for it for 
> years. One is for a boss/secretary arrangement, where the secretary can 
> register for the boss' AOR, but doesn't need the boss' own credentials 
> to do it.
> 
> Somebody has to be first. Go for it!

  SER ( http://iptel.org/ser ) supports this. It was developed exactly
  for the scenario described above -- to have the possibility to register
  the AoR of someone else without having his/her credentials.

    Jan.

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 15 15:35:24 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emzow-0002kz-0z; Thu, 15 Dec 2005 15:35:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emzoa-0002aa-QJ
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 15:35:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01418
	for <sip@ietf.org>; Thu, 15 Dec 2005 15:34:00 -0500 (EST)
Received: from mail.stalker.com ([64.173.55.169] helo=stalker.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emzpy-0000ra-Vr
	for sip@ietf.org; Thu, 15 Dec 2005 15:36:30 -0500
Received: from [64.173.55.167] (account thom HELO [10.0.1.66])
	by mail.stalker.com (CommuniGate Pro SMTP 5.0.4)
	with ESMTPSA id 34108166; Thu, 15 Dec 2005 12:34:39 -0800
Message-ID: <43A1D35B.3040508@communigate.com>
Date: Thu, 15 Dec 2005 12:34:35 -0800
From: "Thom O'Connor" <thom@communigate.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Subject: RE: [Sip] one question on the authentication for third-party
	registration
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

From: Cullen Jennings <fluffy at cisco.com>
> Has anyone build a proxy that allows the configuration of a policy that says
> Bob is allowed to register for Alice's AOR?

Dear Cullen and the Sip list,

CommuniGate Pro version 5.0 provides such a feature called the 
"CanImpersonate" access right - if Bob has the CanImpersonate access 
right for Alice's domain, then Bob can register for Alice's AOR.

In situations where an individual needs access to another's calls (such 
as the boss/secretary example), this can be achieved in CommuniGate Pro 
by providing the Fork setting in the boss account: if there is no answer 
within X seconds (where X can be 0) the call is forked to the specified 
AOR (secretary), while it continues to ring the boss' devices. If the 
boss is busy or not available, forking happens immediately.

Fully-functional trial downloads of CGatePro are available here:
   http://www.communigate.com/download

Sincerely,

-t

-- 
Thom O'Connor
Director, Product Architecture
CommuniGate Systems
http://www.communigate.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



From sip-bounces@ietf.org Thu Dec 15 15:50:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En03h-0006Ia-2M; Thu, 15 Dec 2005 15:50:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En03A-00063M-Cn; Thu, 15 Dec 2005 15:50:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03247;
	Thu, 15 Dec 2005 15:49:03 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1En04c-0001c6-Gi; Thu, 15 Dec 2005 15:51:35 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1En038-0001Oc-82; Thu, 15 Dec 2005 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1En038-0001Oc-82@newodin.ietf.org>
Date: Thu, 15 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-answermode-00.txt 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Requesting Answering Modes for the Session Initiation Protocol (SIP)
	Author(s)	: D. Willis, A. Allen
	Filename	: draft-ietf-sip-answermode-00.txt
	Pages		: 25
	Date		: 2005-12-15
	
   This document defines two SIP extension header fields and associated
   option tags that can be used in INVITE requests to convey the
   requester's preference for user-interface handling related to
   answering of that request.  The first header, "Answer-Mode",
   expresses a preference as to whether the target node's user interface
   waits for user input before accepting the request or instead accepts
   the request without waiting on user input.  The second header, "Priv-
   Answer-Mode" is similar to the first, except that it requests
   administrative-level access and has consequent additional
   authentication and authorization requirements.  These behaviors have
   applicability to applications such as Push-to-Talk and to diagnostics
   like loop-back.  Usage of each header field in a response to indicate
   how the request was handled is also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-answermode-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-answermode-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-12-15135448.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-answermode-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-answermode-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-12-15135448.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Thu Dec 15 20:36:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En4WW-00023o-4a; Thu, 15 Dec 2005 20:36:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1En4WU-00022j-Fe
	for sip@megatron.ietf.org; Thu, 15 Dec 2005 20:36:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12746
	for <sip@ietf.org>; Thu, 15 Dec 2005 20:35:38 -0500 (EST)
Received: from szinterscan.utstar.com.cn ([210.21.224.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En4Xy-0007b6-Lk
	for sip@ietf.org; Thu, 15 Dec 2005 20:38:12 -0500
Received: from szsmtp.utstar.com.cn ([172.19.224.12]) by
	szinterscan.utstar.com.cn with InterScan Messaging Security
	Suite; Fri, 16 Dec 2005 09:41:27 +0800
Received: from SZMAIL11.cn.utstarcom.com (szmail03.cn.utstarcom.com
	[172.19.30.102] (may be forged))
	by szsmtp.utstar.com.cn (8.11.6/8.11.1) with ESMTP id jBG1a5927956;
	Fri, 16 Dec 2005 09:36:05 +0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.32
Date: Fri, 16 Dec 2005 09:36:45 +0800
Message-ID: <F00B060D0226A4418CEF506B97F4260801AAA60B@SZMAIL11.cn.utstarcom.com>
Thread-Topic: a question of refuseing an offer in RFC3312
Thread-Index: AcYBBCJtW1Z7lf/yR7a9xQfEH+/MWAA2yaTg
From: "Gerald Yan" <gerald.yan@utstar.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>, "Sip" <sip@ietf.org>
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: quoted-printable
Cc: Gonzalo.Camarillo@ericsson.com
Subject: [Sip] a question of refuseing an offer in RFC3312
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


Hi:
I have a question about RFC3312-Integration of Resource Management.
In section 8:
   580 (Precondition Failure) responses and BYE and CANCEL requests,
   indicating failure to meet certain preconditions, SHOULD contain an
   SDP description, indicating which desired status triggered the
   failure.
My question is that if there are PROXYs between offerer and answerer,the
SDP contained in CANCEL could not reach the answerer for CANCEL is
hop-by-hop message. Is it right?


Best regards
Gerald

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 04:19:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnBdc-0000yk-Nb; Fri, 16 Dec 2005 04:12:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBcf-0000YG-N0
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 04:11:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20284
	for <sip@ietf.org>; Fri, 16 Dec 2005 04:10:29 -0500 (EST)
Received: from mail.fgmicrotec.com ([195.30.252.244])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnBeF-0005uP-1V
	for sip@ietf.org; Fri, 16 Dec 2005 04:13:07 -0500
Received: (qmail 17261 invoked by uid 10158); 16 Dec 2005 09:11:13 -0000
X-SpaceNet-Virusscan: Sophos Version: 4.00; Last IDE Update: 2005-12-16 05:01
	FILE NOT INFECTED: [1134724273.17256-0.mail.fgmicrotec.com]
	FILE NOT INFECTED: [1134724273.17256-1.mail.fgmicrotec.com]
Received: from port-213-160-23-250.static.qsc.de (HELO
	medusa.muc.corp.fgmicrotec.com) (213.160.23.250)
	by mail.fgmicrotec.com with SMTP; 16 Dec 2005 09:11:13 -0000
X-SpaceNet-Authentification: SMTP AUTH verified <postmaster@fgmicrotec.com>
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: AW: [Sip] IMS at the International SIP 2006 - Paris - France
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 16 Dec 2005 10:11:12 +0100
Message-ID: <BE0B30B741E59846BBD4EB0C5320028649654F@medusa.muc.corp.fgmicrotec.com>
Thread-Topic: [Sip] IMS at the International SIP 2006 - Paris - France
Thread-Index: AcXsLKMTqUh8cMRuRGCzYMU+byEpCgV8fmMQ
From: "Olaf Braune" <olaf.braune@fgmicrotec.com>
To: "Chantal Ladouce" <chantal.ladouce@upperside.fr>, <sip@ietf.org>,
	"Robert Mirbaha" <robert.mirbaha@fgmicrotec.com>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf
Cc: olafbraune@web.de
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="===============1270861840=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1270861840==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C60220.A909649C"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C60220.A909649C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Chantal,
=20
as I am leaving fg microtec end of this year in order to take another =
opportunity, I will not be able to give my presentation at your SIP 2006 =
conference Feb., 22 2006 @3pm 'SIP for Presence, Instant Messaging and =
Push-to-Talk'. I regret this but our CEO, Robert Mirbaha, wants to =
substitute me. So please follow-up with him for the presentation.
=20
I hope to stay in contact with you also with my new company.
=20
Best regards,
            Olaf Braune
=20



________________________________=20
Olaf Braune=20
VP Product Management & Development=20
fg microtec GmbH.=20
Kronstadter Strasse 9=20
81677 Munich, Germany=20
fon +49 89 99 26 95 21=20
fax +49 89 99 26 95 19=20
mobile +49 174 3105 194=20
www.fgmicrotec.com=20
_______________________________=20

This e-mail and any files transmitted with it may contain privileged and =
confidential information intended for the use of the addressee. The =
confidentiality and/or privilege in this e-mail is not waived, lost or =
destroyed if it has been transmitted to you in error. If you have =
received this e-mail in error you must (a) not disseminate, copy or take =
any action in reliance on it; (b) please notify fg microtec immediately =
by return e-mail to the sender; and (c) please delete the original =
e-mail and any copies thereof from your system. Furthermore, this e-mail =
may contain personal views which may not be the views of fg microtec =
unless specifically stated.

=20
	=09
=20

-----Urspr=FCngliche Nachricht-----
Von: Chantal Ladouce [mailto:chantal.ladouce@upperside.fr]
Gesendet: Freitag, 18. November 2005 11:42
An: sip@ietf.org
Betreff: [Sip] IMS at the International SIP 2006 - Paris - France



Carriers Experience on SIP based IMS Real Size Experiments

. Extending SIP IMS Architecture from Wireless to Wireline Networks

. Challenges in IMS Testing

=20

Everything you need to know on IMS and SIP will be delivered at the =
International SIP conference to be held in Paris next 21-24 February =
2006.

=20

Get all details at:

=20

http://www.upperside.fr/sip2006/sip2006program.htm#day2

=20

=20


------_=_NextPart_001_01C60220.A909649C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR><o:SmartTagType =

downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Batang;
}
@font-face {
	font-family: @Batang;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DFR vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D963325608-16122005><FONT face=3DArial color=3D#0000ff =
size=3D2>Dear=20
Chantal,</FONT></SPAN></DIV>
<DIV><SPAN class=3D963325608-16122005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D963325608-16122005><FONT color=3D#0000ff =
size=3D2><FONT=20
face=3DArial>as I am leaving fg microtec end of this year in order to =
take another=20
opportunity, I will not be able to give my presentation at your SIP 2006 =

conference Feb., 22 2006 @3pm 'SIP for Presence, Instant Messaging and=20
Push-to-Talk'. I regret this but our CEO, Robert Mirbaha, wants to =
substitute=20
me. So please follow-up with him for the=20
presentation.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D963325608-16122005><FONT color=3D#0000ff =
size=3D2><FONT=20
face=3DArial></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D963325608-16122005><FONT color=3D#0000ff =
size=3D2><FONT=20
face=3DArial>I hope to stay in contact with you also with my new=20
company.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D963325608-16122005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D963325608-16122005><FONT face=3DArial color=3D#0000ff =
size=3D2>Best=20
regards,</FONT></SPAN></DIV>
<DIV><SPAN=20
class=3D963325608-16122005>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial color=3D#0000ff size=3D2>Olaf =
Braune</FONT></SPAN></DIV>
<DIV><SPAN class=3D963325608-16122005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D963325608-16122005><BR>
<P><FONT face=3DArial size=3D2>________________________________</FONT> =
<BR><FONT=20
face=3DArial size=3D2>Olaf Braune</FONT> <BR><FONT face=3DArial =
size=3D2>VP Product=20
Management &amp; Development</FONT> <BR><FONT face=3DArial size=3D2>fg =
microtec=20
GmbH.</FONT> <BR><FONT face=3DArial size=3D2>Kronstadter Strasse =
9</FONT> <BR><FONT=20
face=3DArial size=3D2>81677 Munich, Germany</FONT> <BR><FONT =
face=3DArial size=3D2>fon=20
+49 89 99 26 95 21</FONT> <BR><FONT face=3DArial size=3D2>fax +49 89 99 =
26 95=20
19</FONT> <BR><FONT face=3DArial size=3D2>mobile +49 174 3105 194</FONT> =
<BR><FONT=20
face=3DArial size=3D2>www.fgmicrotec.com</FONT> <BR><FONT face=3DArial=20
size=3D2>_______________________________</FONT> </P>
<P><FONT face=3DArial size=3D2>This e-mail and any files transmitted =
with it may=20
contain privileged and confidential information intended for the use of =
the=20
addressee. The confidentiality and/or privilege in this e-mail is not =
waived,=20
lost or destroyed if it has been transmitted to you in error. If you =
have=20
received this e-mail in error you must (a) not disseminate, copy or take =
any=20
action in reliance on it; (b) please notify fg microtec immediately by =
return=20
e-mail to the sender; and (c) please delete the original e-mail and any =
copies=20
thereof from your system. Furthermore, this e-mail may contain personal =
views=20
which may not be the views of fg microtec unless specifically=20
stated.</FONT></P></SPAN></DIV>
<DIV><SPAN class=3D963325608-16122005><FONT color=3D#0000ff =
size=3D2><FONT=20
face=3DArial></FONT>&nbsp;</DIV>
<DIV>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D625 border=3D0>
  <TBODY>
  <TR>
    <TD class=3Dtexte vAlign=3Dtop align=3Dright><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT></TD>
    <TD><FONT face=3DArial color=3D#0000ff size=3D2></FONT></TD>
    <TD class=3Dtexte vAlign=3Dtop>
      <DIV><SPAN class=3Dtitrerangdeux><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
      size=3D2><SPAN=20
      =
class=3D963325608-16122005></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
></TD></TR></TBODY></TABLE></DIV></FONT></SPAN>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Urspr=FCngliche Nachricht-----<BR><B>Von:</B> Chantal =
Ladouce=20
  [mailto:chantal.ladouce@upperside.fr]<BR><B>Gesendet:</B> Freitag, 18. =

  November 2005 11:42<BR><B>An:</B> sip@ietf.org<BR><B>Betreff:</B> =
[Sip] IMS at=20
  the International SIP 2006 - Paris - France<BR><BR></DIV></FONT>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN class=3Dtitrerangdeux><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">Carriers =
Experience on=20
  SIP based </SPAN></FONT></SPAN><STRONG><B><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">IMS Real =
Size=20
  Experiments</SPAN></FONT></B></STRONG><FONT face=3DArial =
size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN class=3Dtitrerangdeux><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">. Extending=20
  </SPAN></FONT></SPAN><STRONG><B><FONT face=3DArial size=3D1><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">SIP IMS=20
  Architecture</SPAN></FONT></B></STRONG><SPAN =
class=3Dtitrerangdeux><FONT=20
  face=3DArial size=3D1><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 9pt; =
FONT-FAMILY: Arial">=20
  from Wireless to Wireline Networks</SPAN></FONT></SPAN><FONT =
face=3DArial=20
  size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN class=3Dtitrerangdeux><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">. Challenges =
in=20
  </SPAN></FONT></SPAN><STRONG><B><FONT face=3DArial size=3D1><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">IMS=20
  Testing</SPAN></FONT></B></STRONG><FONT face=3DArial size=3D1><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN class=3Dtitrerangdeux><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">Everything =
you need to=20
  know on IMS and SIP will be delivered at the International SIP =
conference to=20
  be held in <st1:place w:st=3D"on"><st1:City=20
  w:st=3D"on">Paris</st1:City></st1:place> next 21-24 February=20
  2006.</SPAN></FONT></SPAN><FONT face=3DArial size=3D1><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><SPAN class=3Dtitrerangdeux><FONT face=3DArial =
size=3D1><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">Get all =
details=20
  at:</SPAN></FONT></SPAN><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB =

  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial"><A=20
  =
href=3D"http://www.upperside.fr/sip2006/sip2006program.htm#day2">http://w=
ww.upperside.fr/sip2006/sip2006program.htm#day2</A><o:p></o:p></SPAN></FO=
NT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D1><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C60220.A909649C--


--===============1270861840==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1270861840==--




From sip-bounces@ietf.org Fri Dec 16 07:38:11 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnEqh-0006cb-Hw; Fri, 16 Dec 2005 07:38:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnEqf-0006cI-UP
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 07:38:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12466
	for <sip@ietf.org>; Fri, 16 Dec 2005 07:37:10 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnEsD-0004sR-9s
	for sip@ietf.org; Fri, 16 Dec 2005 07:39:49 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B21E140B;
	Fri, 16 Dec 2005 13:35:26 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 16 Dec 2005 13:35:26 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 16 Dec 2005 13:35:25 +0100
Received: from [131.160.36.33] (EGQAD00202EIE3F.lmf.ericsson.se
	[131.160.36.33])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id ACE2F255A;
	Fri, 16 Dec 2005 14:35:25 +0200 (EET)
Message-ID: <43A2B48D.7000305@ericsson.com>
Date: Fri, 16 Dec 2005 14:35:25 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gerald Yan <gerald.yan@utstar.com>
References: <F00B060D0226A4418CEF506B97F4260801AAA60B@SZMAIL11.cn.utstarcom.com>
In-Reply-To: <F00B060D0226A4418CEF506B97F4260801AAA60B@SZMAIL11.cn.utstarcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2005 12:35:25.0918 (UTC)
	FILETIME=[30A777E0:01C6023D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
Subject: [Sip] Re: a question of refuseing an offer in RFC3312
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

yes, CANCEL is a hop-by-hop transaction. Proxies do not typically copy 
bodies from an incoming CANCEL to an outgoing one.

Cheers,

Gonzalo

Gerald Yan wrote:
> Hi:
> I have a question about RFC3312-Integration of Resource Management.
> In section 8:
>    580 (Precondition Failure) responses and BYE and CANCEL requests,
>    indicating failure to meet certain preconditions, SHOULD contain an
>    SDP description, indicating which desired status triggered the
>    failure.
> My question is that if there are PROXYs between offerer and answerer,the
> SDP contained in CANCEL could not reach the answerer for CANCEL is
> hop-by-hop message. Is it right?
> 
> 
> Best regards
> Gerald

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 13:02:20 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnJuO-0002zs-Ms; Fri, 16 Dec 2005 13:02:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJuM-0002zn-P9
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 13:02:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24448
	for <sip@ietf.org>; Fri, 16 Dec 2005 13:01:19 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnJvv-0000YK-MH
	for sip@ietf.org; Fri, 16 Dec 2005 13:04:01 -0500
Received: from [64.101.172.188] ([64.101.172.188]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBGI7gKv029874
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 16 Dec 2005 12:07:44 -0600
In-Reply-To: <437B9F3B.8010107@lucent.com>
References: <001601c5eaee$e0ce9c40$2c28a8c0@brett1>
	<437B9F3B.8010107@lucent.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8BBD0203-B7B9-4513-BA9B-FD9E63D0BE2E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt
Date: Fri, 16 Dec 2005 12:01:51 -0600
To: "Vijay K. Gurbani" <vkg@lucent.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, 'Rohan Mahy' <rohan@ekabal.com>,
	Brett Tate <brett@broadsoft.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


So, how are we doing on this last call?

I think Vijay proposed including some text last month and was waiting  
on a consensus, or at least somebody to comment on it.

--
dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 13:13:08 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnK4q-0006A3-Km; Fri, 16 Dec 2005 13:13:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnK4p-00069v-0O
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 13:13:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25591
	for <sip@ietf.org>; Fri, 16 Dec 2005 13:12:07 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnK6T-0000x9-H7
	for sip@ietf.org; Fri, 16 Dec 2005 13:14:49 -0500
Received: from [64.101.172.188] ([64.101.172.188]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBGIIloU029933
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 16 Dec 2005 12:18:49 -0600
In-Reply-To: <BF885810.5D2D1%fluffy@cisco.com>
References: <BF885810.5D2D1%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
Date: Fri, 16 Dec 2005 12:12:55 -0600
To: Sip <sip@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


So, where are we at on the new-and-improved WGLC for the new and  
improved GRUU?

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 13:15:11 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnK6p-0006NW-26; Fri, 16 Dec 2005 13:15:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnK6m-0006NL-TP
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 13:15:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25953
	for <sip@ietf.org>; Fri, 16 Dec 2005 13:14:09 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnK8Q-00013R-5s
	for sip@ietf.org; Fri, 16 Dec 2005 13:16:51 -0500
Received: from [64.101.172.188] ([64.101.172.188]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBGIKshT029950
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <sip@ietf.org>; Fri, 16 Dec 2005 12:20:55 -0600
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <186F9B3E-2F42-4F7D-955D-8D0699972AEA@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Sip <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Fri, 16 Dec 2005 12:15:02 -0600
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: [Sip] Status query: Target Dialog
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


My notes show Rohan last-called target dialog last summer. My hunch  
is we're not quite done yet.

Opinions?

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 14:25:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnLCV-0007ln-52; Fri, 16 Dec 2005 14:25:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLCS-0007lc-5m
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 14:25:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03488
	for <sip@ietf.org>; Fri, 16 Dec 2005 14:24:03 -0500 (EST)
Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnLE5-0003cN-Vm
	for sip@ietf.org; Fri, 16 Dec 2005 14:26:47 -0500
Received: from jh by harjus.tutpro.com with local (Exim 4.50)
	id 1EnLC1-0000rB-HF; Fri, 16 Dec 2005 21:24:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17315.5237.497697.781249@harjus.tutpro.com>
Date: Fri, 16 Dec 2005 21:24:37 +0200
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
In-Reply-To: <151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com>
References: <BF885810.5D2D1%fluffy@cisco.com>
	<151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: Juha Heinanen <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Rohan Mahy <rohan@ekabal.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > So, where are we at on the new-and-improved WGLC for the new and  
 > improved GRUU?

dean,

if you by "improved" mean a version that doesn't anymore support
mobility of SIP UAs from one network to another, i don't want to see
such a version.

-- 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



From sip-bounces@ietf.org Fri Dec 16 14:29:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnLGv-00019y-2a; Fri, 16 Dec 2005 14:29:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLGt-00017G-OL
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 14:29:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03946
	for <sip@ietf.org>; Fri, 16 Dec 2005 14:28:39 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnLIX-0003n6-S9
	for sip@ietf.org; Fri, 16 Dec 2005 14:31:23 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 16 Dec 2005 11:29:28 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,262,1131350400"; 
	d="scan'208"; a="17497690:sNHT22494844"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBGJTHUZ000855; 
	Fri, 16 Dec 2005 14:29:26 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 16 Dec 2005 14:29:14 -0500
Received: from [161.44.55.129] ([161.44.55.129]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 16 Dec 2005 14:29:14 -0500
Message-ID: <43A3158A.40202@cisco.com>
Date: Fri, 16 Dec 2005 14:29:14 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Status query: Target Dialog
References: <186F9B3E-2F42-4F7D-955D-8D0699972AEA@softarmor.com>
In-Reply-To: <186F9B3E-2F42-4F7D-955D-8D0699972AEA@softarmor.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Dec 2005 19:29:14.0161 (UTC)
	FILETIME=[FF70B210:01C60276]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

The conclusion from IETF was all we need is to clarify the relationship 
with Reply-To, and then we're done. I just need to get around to 
submitting a rev with that change.

-Jonathan R.

Dean Willis wrote:

> 
> My notes show Rohan last-called target dialog last summer. My hunch  is 
> we're not quite done yet.
> 
> Opinions?
> 
> -- 
> Dean
> 
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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



From sip-bounces@ietf.org Fri Dec 16 14:36:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnLNP-00028v-6w; Fri, 16 Dec 2005 14:36:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLNN-00028n-64
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 14:36:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04638
	for <sip@ietf.org>; Fri, 16 Dec 2005 14:35:21 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnLP1-00041M-KK
	for sip@ietf.org; Fri, 16 Dec 2005 14:38:04 -0500
Received: from [64.101.172.188] ([64.101.172.188]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBGJg6Sv030217
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 16 Dec 2005 13:42:08 -0600
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <828FF70C-E02A-4DD0-B892-F793FE54716B@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Fri, 16 Dec 2005 13:36:15 -0600
To: Sip <sip@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: Allison Mankin <mankin@psg.com>
Subject: [Sip] WGLC for End-to-Middle draft-ietf-sip-e2m-sec-01.txt
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


Just so you folks don't think they're nothing to keep you busy over  
the holidays, I'd like to start working group last call of the End to  
Middle draft:

http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt

I'd also like to request additional-cross area review from the  
Security area on this document.

Given the cross-area review, I'd like to conclude the WGLC by January  
20, 2006.

--
Dean
SIP co-chair

_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 14:47:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnLYK-0005Ww-QB; Fri, 16 Dec 2005 14:47:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLYI-0005Tu-4C
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 14:47:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05998
	for <sip@ietf.org>; Fri, 16 Dec 2005 14:46:37 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnLZx-0004RW-CU
	for sip@ietf.org; Fri, 16 Dec 2005 14:49:21 -0500
Received: from [64.101.172.188] ([64.101.172.188]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBGJrMdV030243
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 16 Dec 2005 13:53:24 -0600
In-Reply-To: <17315.5237.497697.781249@harjus.tutpro.com>
References: <BF885810.5D2D1%fluffy@cisco.com>
	<151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com>
	<17315.5237.497697.781249@harjus.tutpro.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D0550E7F-8493-4415-B1B7-8F4C071E4EA1@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
Date: Fri, 16 Dec 2005 13:47:31 -0600
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Rohan Mahy <rohan@ekabal.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


On Dec 16, 2005, at 1:24 PM, Juha Heinanen wrote:

> Dean Willis writes:
>
>> So, where are we at on the new-and-improved WGLC for the new and
>> improved GRUU?
>
> dean,
>
> if you by "improved" mean a version that doesn't anymore support
> mobility of SIP UAs from one network to another, i don't want to see
> such a version.
>

I'm going to hate myself for asking this, I'm sure, but . . .

What do you mean, Juha? Are you saying we should solve the case that  
allows a SIP UA behind one "unfriendly" SBC to register to a  
registrar that is behind another "unfriendly" SBC, but still take  
"calls" from a UA hidden behind a third "unfriendly" SBC? My head  
hurts just thinking about it . . .

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 16:19:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnMrH-0005Fj-K7; Fri, 16 Dec 2005 16:11:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMr7-00055N-Eg
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 16:11:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18748
	for <sip@ietf.org>; Fri, 16 Dec 2005 16:10:08 -0500 (EST)
From: fwmiller@cornfed.com
Received: from [66.113.136.12] (helo=smapp01.siteprotect.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMsj-0000MZ-Fr
	for sip@ietf.org; Fri, 16 Dec 2005 16:12:53 -0500
Received: from smapp01.siteprotect.com (localhost [127.0.0.1])
	by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id jBGLAc911208
	for <sip@ietf.org>; Fri, 16 Dec 2005 15:10:38 -0600
Date: Fri, 16 Dec 2005 15:10:38 -0600
Message-Id: <200512162110.jBGLAc911208@smapp01.siteprotect.com>
To: sip@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: [Sip] Jabber VoIP specs
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


For those that may not have seen this, the Jabber Foundation has published their VoIP signaling and media encoding specs.  These specs have been reconciled with Google Talk if I read the introductory comments correctly.  I'd be interested in any discussion of the design of these protocols by the SIP gurus here...

http://www.jabber.org/jeps/jep-0166.html
http://www.jabber.org/jeps/jep-0167.html

FM


_______________________________________________
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



From sip-bounces@ietf.org Fri Dec 16 16:39:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnNIX-0007fJ-Uv; Fri, 16 Dec 2005 16:39:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnNIW-0007fE-5T
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 16:39:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21766
	for <sip@ietf.org>; Fri, 16 Dec 2005 16:38:27 -0500 (EST)
Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnNKB-0001Og-4A
	for sip@ietf.org; Fri, 16 Dec 2005 16:41:12 -0500
Received: from jh by harjus.tutpro.com with local (Exim 4.50)
	id 1EnNIJ-0000uY-78; Fri, 16 Dec 2005 23:39:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17315.13315.120286.663804@harjus.tutpro.com>
Date: Fri, 16 Dec 2005 23:39:15 +0200
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
In-Reply-To: <D0550E7F-8493-4415-B1B7-8F4C071E4EA1@softarmor.com>
References: <BF885810.5D2D1%fluffy@cisco.com>
	<151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com>
	<17315.5237.497697.781249@harjus.tutpro.com>
	<D0550E7F-8493-4415-B1B7-8F4C071E4EA1@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: Juha Heinanen <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Rohan Mahy <rohan@ekabal.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > What do you mean, Juha? Are you saying we should solve the case that  
 > allows a SIP UA behind one "unfriendly" SBC to register to a  
 > registrar that is behind another "unfriendly" SBC, but still take  
 > "calls" from a UA hidden behind a third "unfriendly" SBC? My head  
 > hurts just thinking about it . . .

no, i was referring to this discussion:

http://www1.ietf.org/mail-archive/web/sip/current/msg12415.html

http://www1.ietf.org/mail-archive/web/sip/current/msg12434.html

gruu MUST support session level mobility so that ietf is not at the
mercy of 3gpp and ims for it.

-- 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



From sip-bounces@ietf.org Fri Dec 16 17:34:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnO9i-0004dy-BU; Fri, 16 Dec 2005 17:34:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnO9g-0004di-Me
	for sip@megatron.ietf.org; Fri, 16 Dec 2005 17:34:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26320
	for <sip@ietf.org>; Fri, 16 Dec 2005 17:33:23 -0500 (EST)
Received: from smtp2.versatel.nl ([62.58.50.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnOBK-0002zj-Ek
	for sip@ietf.org; Fri, 16 Dec 2005 17:36:10 -0500
Received: (qmail 4244 invoked by uid 0); 16 Dec 2005 22:34:03 -0000
Received: from unknown (HELO BEMBUSTER) ([81.59.101.130])
	(envelope-sender <jbemmel@zonnet.nl>)
	by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 16 Dec 2005 22:34:03 -0000
Message-ID: <021101c60290$caac1820$6402a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Dean Willis" <dean.willis@softarmor.com>, "Juha Heinanen" <jh@tutpro.com>
References: <BF885810.5D2D1%fluffy@cisco.com><151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com><17315.5237.497697.781249@harjus.tutpro.com><D0550E7F-8493-4415-B1B7-8F4C071E4EA1@softarmor.com>
	<17315.13315.120286.663804@harjus.tutpro.com>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
Date: Fri, 16 Dec 2005 23:33:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 1.2 (+)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Rohan Mahy <rohan@ekabal.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Juha,

I agree with you. What about the folloing options:

1) If instead of inserting a Record-Route header with its IP address the UAS 
would somehow communicate its IP address to the UAC (e.g. as a newly defined 
parameter in the Contact header. say "host"), the rule could be changed to 
say that the UAC adds a Route header with that IP address as the last entry. 
This would allow a reINVITE (or UPDATE) with an updated Contact header and a 
different IP address parameter

So:
SIP/2.0 200 OK
   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8
   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a
   From: Caller <sip:caller@example.com>;tag=n88ah
   To: Callee <sip:callee@example.com> ;tag=a0z8
   Call-ID: 1j9FpLxk3uxtma7@host.example.com
   CSeq: 1 INVITE
   Supported: gruu
   Allow: INVITE, OPTIONS, CANCEL, BYE, ACK
   <allOneLine>
   Contact:
   <sip:callee@example.com
   ;opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;host=1.2.3.4
   </allOneLine>
   Content-Length: --
   Content-Type: application/sdp

   [SDP Not shown]
2) do session mobility using REFER (either to a newly obtained GRUU or the 
AoR)Regards,

Jeroen

----- Original Message ----- 
From: "Juha Heinanen" <jh@tutpro.com>
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: "Sip" <sip@ietf.org>; "Rohan Mahy" <rohan@ekabal.com>
Sent: Friday, December 16, 2005 10:39 PM
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06


> Dean Willis writes:
>
> > What do you mean, Juha? Are you saying we should solve the case that
> > allows a SIP UA behind one "unfriendly" SBC to register to a
> > registrar that is behind another "unfriendly" SBC, but still take
> > "calls" from a UA hidden behind a third "unfriendly" SBC? My head
> > hurts just thinking about it . . .
>
> no, i was referring to this discussion:
>
> http://www1.ietf.org/mail-archive/web/sip/current/msg12415.html
>
> http://www1.ietf.org/mail-archive/web/sip/current/msg12434.html
>
> gruu MUST support session level mobility so that ietf is not at the
> mercy of 3gpp and ims for it.
>
> -- 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 


_______________________________________________
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



From sip-bounces@ietf.org Sat Dec 17 08:36:11 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EncEN-0002rj-KQ; Sat, 17 Dec 2005 08:36:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EncEL-0002re-6t
	for sip@megatron.ietf.org; Sat, 17 Dec 2005 08:36:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25084
	for <sip@ietf.org>; Sat, 17 Dec 2005 08:35:09 -0500 (EST)
Received: from smtp1.versatel.nl ([62.58.50.88])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EncG9-00064c-04
	for sip@ietf.org; Sat, 17 Dec 2005 08:38:02 -0500
Received: (qmail 14609 invoked by uid 0); 17 Dec 2005 13:35:56 -0000
Received: from unknown (HELO BEMBUSTER) ([81.59.101.130])
	(envelope-sender <jbemmel@zonnet.nl>)
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 17 Dec 2005 13:35:56 -0000
Message-ID: <020401c6030e$c7dcf550$6402a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: <sip@ietf.org>
Date: Sat, 17 Dec 2005 14:35:44 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 1.7 (+)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Subject: [Sip] RFC3261 SIP DoS protection additions
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="===============0694381630=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0694381630==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0201_01C60317.298019B0"

This is a multi-part message in MIME format.

------=_NextPart_000_0201_01C60317.298019B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

2 comments on RFC3261 (in particular: section 26.3.2.4 on DoS =
protection):

1. IMO it should be recommended (i.e. SHOULD) to send 487 responses for =
CANCEL statelessly. If not, a DoS attack using CANCEL messages with =
non-existing via branches could be used to make a server run out of =
transaction resources (since each servertransaction will linger for 32 =
seconds). CANCEL cannot be challenged, so the recommendation of section =
26.3.2.4 to challenge questionable requests does not apply here

2. For the same reason, IMO it should be recommended to not do loop =
detection for CANCEL requests (i.e. SHOULD NOT) in stateful proxies. =
Loop detection processing can be relatively expensive, and is not needed =
for CANCELs in this case as stateful proxies forward them hop-by-hop =
(any loop would end with a 487)

Regards,

jeroen
------=_NextPart_000_0201_01C60317.298019B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>2 comments on RFC3261 (in particular: =
section=20
26.3.2.4 on DoS protection):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. IMO it should be recommended (i.e. =
SHOULD) to=20
send 487 responses for CANCEL statelessly. If not,&nbsp;a DoS attack =
using=20
CANCEL messages with non-existing via branches could be used to make a =
server=20
run out of transaction resources (since each servertransaction will =
linger for=20
32 seconds). CANCEL cannot be challenged, so the recommendation of =
section=20
26.3.2.4 to challenge questionable requests does not apply =
here</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. For the same reason, IMO it should =
be=20
recommended to not do loop detection for CANCEL requests (i.e. SHOULD =
NOT) in=20
stateful proxies. Loop detection processing can be relatively expensive, =
and is=20
not needed for CANCELs in this case as stateful proxies forward them =
hop-by-hop=20
(any loop would end with a 487)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>jeroen</FONT></DIV></BODY></HTML>

------=_NextPart_000_0201_01C60317.298019B0--



--===============0694381630==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0694381630==--





From sip-bounces@ietf.org Sat Dec 17 09:01:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EncdI-0000Cz-Ol; Sat, 17 Dec 2005 09:01:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EncdH-0000Cu-As
	for sip@megatron.ietf.org; Sat, 17 Dec 2005 09:01:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27003
	for <sip@ietf.org>; Sat, 17 Dec 2005 09:00:55 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Encf5-0006kB-HE
	for sip@ietf.org; Sat, 17 Dec 2005 09:03:48 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-4.cisco.com with ESMTP; 17 Dec 2005 06:01:45 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBHE1jQK020489;
	Sat, 17 Dec 2005 06:01:46 -0800 (PST)
Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com
	[10.32.245.156])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id jBHE8FWb014624;
	Sat, 17 Dec 2005 06:08:26 -0800
In-Reply-To: <020401c6030e$c7dcf550$6402a8c0@BEMBUSTER>
References: <020401c6030e$c7dcf550$6402a8c0@BEMBUSTER>
Mime-Version: 1.0 (Apple Message framework v746.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4EB90148-5AAA-42DF-A2B0-893C91A65D72@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: [Sip] RFC3261 SIP DoS protection additions
Date: Sat, 17 Dec 2005 09:01:16 -0500
To: Jeroen van Bemmel <jbemmel@zonnet.nl>
X-Mailer: Apple Mail (2.746.2)
DKIM-Signature: a=rsa-sha1;  q=dns; l=1156; t=1134828511; x=1135260711;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=oran@cisco.com; 
	z=Subject:Re=3A=20[Sip]=20RFC3261=20SIP=20DoS=20protection=20additions|
	From:David=20R=20Oran=20<oran@cisco.com>|
	Date:Sat,=2017=20Dec=202005=2009=3A01=3A16=20-0500|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=Q7Su/V025gMnG9+bj3mVCHk8d7bZmKNwTjoCsQBhrdcvJj7kZanMCQ6X+2xmHGY2cuAAd+0B
	nZxpZV5RIH4Ua0tq6GuSrezIwq71YybZAG8d+2wUtTGq3jFzJgcuoiVQHJlMLJSCExX1MrpR8yz
	2JpL44oPO9gLJ2xO1lx3c5Lw=
Authentication-Results: imail.cisco.com; header.From=oran@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


On Dec 17, 2005, at 8:35 AM, Jeroen van Bemmel wrote:

> 2 comments on RFC3261 (in particular: section 26.3.2.4 on DoS  
> protection):
>
> 1. IMO it should be recommended (i.e. SHOULD) to send 487 responses  
> for CANCEL statelessly. If not, a DoS attack using CANCEL messages  
> with non-existing via branches could be used to make a server run  
> out of transaction resources (since each servertransaction will  
> linger for 32 seconds). CANCEL cannot be challenged, so the  
> recommendation of section 26.3.2.4 to challenge questionable  
> requests does not apply here
>
I agree.

> 2. For the same reason, IMO it should be recommended to not do loop  
> detection for CANCEL requests (i.e. SHOULD NOT) in stateful  
> proxies. Loop detection processing can be relatively expensive, and  
> is not needed for CANCELs in this case as stateful proxies forward  
> them hop-by-hop (any loop would end with a 487)
>
Here I disagree, since the cost of loop detect (depending on  
implementation technique) can be nearly free if integrated with the  
dialog matching code.

>
> Regards,
>
> jeroen
> _______________________________________________
> 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



From sip-bounces@ietf.org Sat Dec 17 09:06:05 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnchJ-0001dr-Qe; Sat, 17 Dec 2005 09:06:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnchH-0001dm-LM
	for sip@megatron.ietf.org; Sat, 17 Dec 2005 09:06:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27390
	for <sip@ietf.org>; Sat, 17 Dec 2005 09:05:03 -0500 (EST)
Received: from smtp2.versatel.nl ([62.58.50.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Encj5-0006t4-AF
	for sip@ietf.org; Sat, 17 Dec 2005 09:07:57 -0500
Received: (qmail 28592 invoked by uid 0); 17 Dec 2005 14:05:48 -0000
Received: from unknown (HELO BEMBUSTER) ([81.59.101.130])
	(envelope-sender <jbemmel@zonnet.nl>)
	by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 17 Dec 2005 14:05:48 -0000
Message-ID: <021801c60312$f42a37e0$6402a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "David R Oran" <oran@cisco.com>
References: <020401c6030e$c7dcf550$6402a8c0@BEMBUSTER>
	<4EB90148-5AAA-42DF-A2B0-893C91A65D72@cisco.com>
Subject: Re: [Sip] RFC3261 SIP DoS protection additions
Date: Sat, 17 Dec 2005 15:05:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 1.2 (+)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

David,

>> 2. For the same reason, IMO it should be recommended to not do loop 
>> detection for CANCEL requests (i.e. SHOULD NOT) in stateful  proxies. 
>> Loop detection processing can be relatively expensive, and  is not needed 
>> for CANCELs in this case as stateful proxies forward  them hop-by-hop 
>> (any loop would end with a 487)
>>
> Here I disagree, since the cost of loop detect (depending on 
> implementation technique) can be nearly free if integrated with the 
> dialog matching code.

Sorry, I should have been more specific here: I had a transaction-stateful, 
dialog-stateless proxy in mind

Regards,

jeroen


_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 19 06:37:33 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoJKf-0007RT-1q; Mon, 19 Dec 2005 06:37:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoJKc-0007RA-PE
	for sip@megatron.ietf.org; Mon, 19 Dec 2005 06:37:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29823
	for <sip@ietf.org>; Mon, 19 Dec 2005 06:36:27 -0500 (EST)
Received: from smtp14.clb.oleane.net ([213.56.31.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoJMo-0000zM-1f
	for sip@ietf.org; Mon, 19 Dec 2005 06:39:47 -0500
Received: from Pavillonquatre ([194.3.133.88]) 
	by smtp14.clb.oleane.net with ESMTP id jBJBb8Sw013438
	for <sip@ietf.org>; Mon, 19 Dec 2005 12:37:12 +0100
Message-Id: <200512191137.jBJBb8Sw013438@smtp14.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <sip@ietf.org>
Date: Mon, 19 Dec 2005 12:36:27 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYEkHKZOKsHLeasSJ2/F7EwLX1yhw==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Subject: [Sip] TVoDSL conference 2006 - Paris - France
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="===============1993013153=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1993013153==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_041F_01C60498.D4A79390"

This is a multi-part message in MIME format.

------=_NextPart_000_041F_01C60498.D4A79390
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The third edition of the TVoDSL conference will start in one month in Paris
next 24-27 January:

 

 <http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm>
http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm

 

FastWeb, France Telecom, Telefonica, VideoNetwork representants will propose
an impressive set of return from experiences, while key industrial players
will address all the technical issues, from network architecture to content
delivery.

It is still time to register to the conference at:

 

 <http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm>
http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm

 

Close to the conference, the Triple Play Showcase is sold out. More than 60
international exhibitors will demonstrate their offerings.

 

 


------=_NextPart_000_041F_01C60498.D4A79390
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The third edition of the <strong><b><font =
face=3DArial><span
style=3D'font-family:Arial'>TVoDSL conference</span></font></b></strong> =
will
start in one month in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next 24-27 January:</span></font><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm"
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm"><span
lang=3DEN-GB><span =
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm">http://w=
ww.upperside.fr/tvodsl2006/tvodsl2006intro.htm</span></span></a></span></=
font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>FastWeb</span></font></st1:C=
ity><font
 size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>,
 <st1:country-region =
w:st=3D"on">France</st1:country-region></span></font></st1:place><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>
Telecom, Telefonica, VideoNetwork representants will propose an =
impressive set
of return from experiences, while key industrial players will address =
all the
technical issues, from network architecture to content =
delivery.</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to register to the conference =
at:</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm"
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm"><=
span
lang=3DEN-GB><span
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm">h=
ttp://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm</span></span=
></a></span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Close to the conference, the <strong><b><font
face=3DArial><span style=3D'font-family:Arial'>Triple Play =
Showcase</span></font></b></strong>
is <strong><b><font face=3DArial><span style=3D'font-family:Arial'>sold =
out</span></font></b></strong>.
More than 60 international exhibitors will demonstrate their =
offerings.</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_041F_01C60498.D4A79390--



--===============1993013153==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============1993013153==--





From sip-bounces@ietf.org Mon Dec 19 08:00:32 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoKcx-0007tZ-UX; Mon, 19 Dec 2005 08:00:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoKcq-0007tO-EE
	for sip@megatron.ietf.org; Mon, 19 Dec 2005 08:00:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10465
	for <sip@ietf.org>; Mon, 19 Dec 2005 07:59:21 -0500 (EST)
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoKf2-00042Y-HZ
	for sip@ietf.org; Mon, 19 Dec 2005 08:02:42 -0500
Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr
	[155.132.251.35])
	by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id
	jBJD0CWr005973 for <sip@ietf.org>; Mon, 19 Dec 2005 14:00:12 +0100
Received: from [172.25.79.32] ([172.25.79.32])
	by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a)
	with ESMTP id 2005121914001141:5989 ;
	Mon, 19 Dec 2005 14:00:11 +0100 
Message-ID: <43A6AEDB.5080105@alcatel.fr>
Date: Mon, 19 Dec 2005 13:00:11 +0000
From: Thomas.Levy@alcatel.fr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR;
	rv:1.7.7) Gecko/20050414
X-Accept-Language: fr, en
MIME-Version: 1.0
To: sip@ietf.org
X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a
	|January 7, 2002) at 12/19/2005 14:00:11,
	Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7,
	2002) at 12/19/2005 14:00:12,
	Serialize complete at 12/19/2005 14:00:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: [Sip] Question about draft-ietf-sip-connect-reuse-04 with natted UAs
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Rohan and al,

It is not clear to me how connection reuse with natted UAs will allow to 
re-use the connection for successive request to a UA.
I am considering a case with 2 user agents (UA1 and UA2) and a proxy 
server P1.
UA1 and UA2 are in a distinct private network but are using the same 
private address (e.g: 10.0.0.1) and they issued a SIP request to P1 
using TCP and connection reuse. (If needed, I can send a slide that 
describes the network configuration).
I understand in the draft that the address used to create a transport 
layer alias is the address placed in the Via by the UAs (i.e:10.0.0.1).
Thus, it seems to me that there will be 2 entries for 10.0.0.1 in the 
alias table.
How could the proxy choose to use the appropriate connection when a 
request comes to UA1 or UA2?
Thanks in advance for any clarifications or comments.


Thomas

_______________________________________________
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



From sip-bounces@ietf.org Mon Dec 19 09:00:53 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoLZN-0004MN-Bg; Mon, 19 Dec 2005 09:00:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoLZL-0004Lk-2v
	for sip@megatron.ietf.org; Mon, 19 Dec 2005 09:00:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18326
	for <sip@ietf.org>; Mon, 19 Dec 2005 08:59:47 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EoLbY-0006Fy-1l for sip@ietf.org; Mon, 19 Dec 2005 09:03:09 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 19 Dec 2005 06:00:40 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBJE0YR6001723;
	Mon, 19 Dec 2005 06:00:40 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 19 Dec 2005 09:00:38 -0500
Received: from [192.168.1.102] ([10.86.240.56]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 19 Dec 2005 09:00:38 -0500
Message-ID: <43A6BD05.4090802@cisco.com>
Date: Mon, 19 Dec 2005 09:00:37 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas.Levy@alcatel.fr
Subject: Re: [Sip] Question about draft-ietf-sip-connect-reuse-04 with natted
	UAs
References: <43A6AEDB.5080105@alcatel.fr>
In-Reply-To: <43A6AEDB.5080105@alcatel.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Dec 2005 14:00:38.0708 (UTC)
	FILETIME=[975A8F40:01C604A4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

connect-reuse is meant for usage between proxies. The draft you want is 
draft-ietf-sip-outbound.

-Jonathan R.

Thomas.Levy@alcatel.fr wrote:

> Rohan and al,
> 
> It is not clear to me how connection reuse with natted UAs will allow to 
> re-use the connection for successive request to a UA.
> I am considering a case with 2 user agents (UA1 and UA2) and a proxy 
> server P1.
> UA1 and UA2 are in a distinct private network but are using the same 
> private address (e.g: 10.0.0.1) and they issued a SIP request to P1 
> using TCP and connection reuse. (If needed, I can send a slide that 
> describes the network configuration).
> I understand in the draft that the address used to create a transport 
> layer alias is the address placed in the Via by the UAs (i.e:10.0.0.1).
> Thus, it seems to me that there will be 2 entries for 10.0.0.1 in the 
> alias table.
> How could the proxy choose to use the appropriate connection when a 
> request comes to UA1 or UA2?
> Thanks in advance for any clarifications or comments.
> 
> 
> Thomas
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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



From sip-bounces@ietf.org Mon Dec 19 09:47:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoMIx-00075o-1l; Mon, 19 Dec 2005 09:47:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoMIr-00075K-4f
	for sip@megatron.ietf.org; Mon, 19 Dec 2005 09:47:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24736
	for <sip@ietf.org>; Mon, 19 Dec 2005 09:46:51 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoML5-00085D-IH
	for sip@ietf.org; Mon, 19 Dec 2005 09:50:12 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 19 Dec 2005 06:47:43 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,268,1131350400"; 
	d="scan'208"; a="17689563:sNHT25407540"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBJElRUd019155; 
	Mon, 19 Dec 2005 09:47:40 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 19 Dec 2005 09:47:29 -0500
Received: from [192.168.1.102] ([10.86.240.56]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 19 Dec 2005 09:47:28 -0500
Message-ID: <43A6C7FF.7000406@cisco.com>
Date: Mon, 19 Dec 2005 09:47:27 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeroen van Bemmel <jbemmel@zonnet.nl>
Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
References: <BF885810.5D2D1%fluffy@cisco.com><151CE785-1125-4CA6-987E-5CA79E10FA4F@softarmor.com><17315.5237.497697.781249@harjus.tutpro.com><D0550E7F-8493-4415-B1B7-8F4C071E4EA1@softarmor.com>	<17315.13315.120286.663804@harjus.tutpro.com>
	<021101c60290$caac1820$6402a8c0@BEMBUSTER>
In-Reply-To: <021101c60290$caac1820$6402a8c0@BEMBUSTER>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Dec 2005 14:47:28.0768 (UTC)
	FILETIME=[2247B000:01C604AB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Content-Transfer-Encoding: 7bit
Cc: Sip <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

One of my takeaways from the meetings at IETF and subsequent thinking on 
the topic, is that we have a set of requirements which are fundamentally 
contradictory. Some folks want the system to work in one way (no route 
pinning to allow mobility), others want it anothter way (pin routes for 
purposes of resolving state references). I suspect we need to have some 
flexibility here. I have some ideas on how to do this via 
Require/Supported mechanisms, without radical surgery to the way 
record-routing and contact works. I have a half-completed draft on this, 
wihch is on my list for the christmas break to polish off..

-Jonathan R.

Jeroen van Bemmel wrote:

> Juha,
> 
> I agree with you. What about the folloing options:
> 
> 1) If instead of inserting a Record-Route header with its IP address the 
> UAS would somehow communicate its IP address to the UAC (e.g. as a newly 
> defined parameter in the Contact header. say "host"), the rule could be 
> changed to say that the UAC adds a Route header with that IP address as 
> the last entry. This would allow a reINVITE (or UPDATE) with an updated 
> Contact header and a different IP address parameter
> 
> So:
> SIP/2.0 200 OK
>   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8
>   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a
>   From: Caller <sip:caller@example.com>;tag=n88ah
>   To: Callee <sip:callee@example.com> ;tag=a0z8
>   Call-ID: 1j9FpLxk3uxtma7@host.example.com
>   CSeq: 1 INVITE
>   Supported: gruu
>   Allow: INVITE, OPTIONS, CANCEL, BYE, ACK
>   <allOneLine>
>   Contact:
>   <sip:callee@example.com
>   
> ;opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;host=1.2.3.4 
> 
>   </allOneLine>
>   Content-Length: --
>   Content-Type: application/sdp
> 
>   [SDP Not shown]
> 2) do session mobility using REFER (either to a newly obtained GRUU or 
> the AoR)Regards,
> 
> Jeroen
> 
> ----- Original Message ----- From: "Juha Heinanen" <jh@tutpro.com>
> To: "Dean Willis" <dean.willis@softarmor.com>
> Cc: "Sip" <sip@ietf.org>; "Rohan Mahy" <rohan@ekabal.com>
> Sent: Friday, December 16, 2005 10:39 PM
> Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06
> 
> 
>> Dean Willis writes:
>>
>> > What do you mean, Juha? Are you saying we should solve the case that
>> > allows a SIP UA behind one "unfriendly" SBC to register to a
>> > registrar that is behind another "unfriendly" SBC, but still take
>> > "calls" from a UA hidden behind a third "unfriendly" SBC? My head
>> > hurts just thinking about it . . .
>>
>> no, i was referring to this discussion:
>>
>> http://www1.ietf.org/mail-archive/web/sip/current/msg12415.html
>>
>> http://www1.ietf.org/mail-archive/web/sip/current/msg12434.html
>>
>> gruu MUST support session level mobility so that ietf is not at the
>> mercy of 3gpp and ims for it.
>>
>> -- 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 
> 
> 
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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



From sip-bounces@ietf.org Mon Dec 19 12:48:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoP7k-0003eI-KU; Mon, 19 Dec 2005 12:48:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoP7h-0003dx-2T
	for sip@megatron.ietf.org; Mon, 19 Dec 2005 12:48:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18921
	for <sip@ietf.org>; Mon, 19 Dec 2005 12:47:30 -0500 (EST)
Received: from [203.199.83.35] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoP9t-0006Eo-BI
	for sip@ietf.org; Mon, 19 Dec 2005 12:50:53 -0500
Received: (qmail 9385 invoked by uid 510); 19 Dec 2005 17:48:12 -0000
Date: 19 Dec 2005 17:48:12 -0000
Message-ID: <20051219174812.9383.qmail@webmail49.rediffmail.com>
Received: from unknown (59.145.65.2) by rediffmail.com via HTTP;
	19 dec 2005 17:48:12 -0000
MIME-Version: 1.0
From: "das sena" <das57@rediffmail.com>
To: sip@ietf.org
Cc: sip-request@ietf.org
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Sip] Diameter Protocol
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: das sena <das57@rediffmail.com>
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="===============0177627662=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

 This is a multipart mime message


--===============0177627662==
Content-type: multipart/alternative;
	boundary="Next_1135014492---0-203.199.83.35-9370"

 This is a multipart mime message


--Next_1135014492---0-203.199.83.35-9370
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Folks,=0A=0A=0A   If anyone have any online tutorial or information abou=
t Diameter Protocol,  please help me out.=0A=0A=0ACheers,=0APrasad.=0A =A0=
=0A
--Next_1135014492---0-203.199.83.35-9370
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AHi Folks,<BR>=0A<BR>=0A<BR>=0A&nbsp;  If anyone have any online tutor=
ial or information about Diameter Protocol,&nbsp; please help me out.<BR>=
=0A<BR>=0A<BR>=0ACheers,<BR>=0APrasad.<BR>=0A&nbsp; <BR>=0A=0A</P>=0A<br><b=
r>=0A<a href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.=
rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG SRC=3D"h=
ttp://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/sign=
ature-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BORDER=3D0 =
VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1135014492---0-203.199.83.35-9370--



--===============0177627662==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0177627662==--





From sip-bounces@ietf.org Mon Dec 19 22:45:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoYRK-0000xU-FT; Mon, 19 Dec 2005 22:45:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoYRH-0000xB-EO; Mon, 19 Dec 2005 22:45:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02287;
	Mon, 19 Dec 2005 22:44:20 -0500 (EST)
From: nagendra.swamy@flextronicssoftware.com
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EoYTZ-0002wk-FF; Mon, 19 Dec 2005 22:47:48 -0500
Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21])
	by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jBK3iwx27906;
	Tue, 20 Dec 2005 09:14:58 +0530
In-Reply-To: <20051219174812.9383.qmail@webmail49.rediffmail.com>
Subject: Re: [Sip] Diameter Protocol
To: das sena <das57@rediffmail.com>
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OF36305BE7.BA00E9AD-ON652570DD.0014562F-652570DD.001494D0@flextronicssoftware.com>
Date: Tue, 20 Dec 2005 09:14:48 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 12/20/2005 09:19:45 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: sip@ietf.org, sip-request@ietf.org, sip-bounces@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org





Hi Das,

Check out the RFC 3588 and the draft  "Diameter Session Initiation Protocol
(SIP) Application
(draft-ietf-aaa-diameter-sip-app-10)" for the required info


Regards
Nagendra



                                                                           
             "das sena"                                                    
             <das57@rediffmail                                             
             .com>                                                      To 
             Sent by:                  sip@ietf.org                        
             sip-bounces@ietf.                                          cc 
             org                       sip-request@ietf.org                
                                                                   Subject 
                                       [Sip] Diameter Protocol             
             12/19/2005 11:18                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
                 das sena                                                  
             <das57@rediffmail                                             
                   .com>                                                   
                                                                           
                                                                           




Hi Folks,


  If anyone have any online tutorial or information about Diameter
Protocol,  please help me out.


Cheers,
Prasad.





_______________________________________________
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




***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 01:20:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eoaqv-0002pL-RX; Tue, 20 Dec 2005 01:20:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoaqu-0002pB-71
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 01:20:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15741
	for <sip@ietf.org>; Tue, 20 Dec 2005 01:18:57 -0500 (EST)
Received: from [219.141.250.5] (helo=mail)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoatF-0007R6-PQ
	for sip@ietf.org; Tue, 20 Dec 2005 01:22:27 -0500
Received: from asechenshuping (top_haoqian.cecwireless.com.cn [10.2.5.26])
	by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7
	2001)) with ESMTPA id <0IRS00IQO9K5QU@mail.cecwireless.com.cn> for
	sip@ietf.org; Tue, 20 Dec 2005 14:19:20 +0800 (CST)
Date: Tue, 20 Dec 2005 14:19:29 +0800
From: Chen Shuping <shuping.chen@cecwireless.com.cn>
To: sip@ietf.org
Message-id: <0IRS00IQQ9K8QU@mail.cecwireless.com.cn>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-index: AcYFLVVgKmDvmmITSSGNnTvUIHRHCw==
X-Spam-Score: 0.4 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Sip] [INFO-method] Is there any RFC on carrying DTMF with INFO in
	mid-call
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="===============2043024462=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2043024462==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_KqwQawn4i6NySKzKTEsPRg)"

This is a multi-part message in MIME format.

--Boundary_(ID_KqwQawn4i6NySKzKTEsPRg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

Hi,All
 
    Is there any RFC on carrying DTMF in INFO during mid-call.

--Boundary_(ID_KqwQawn4i6NySKzKTEsPRg)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=882151806-20122005><FONT size=2>Hi,All</FONT></SPAN></DIV>
<DIV><SPAN class=882151806-20122005><FONT size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=882151806-20122005><FONT size=2>&nbsp;&nbsp;&nbsp; Is there any 
RFC on carrying DTMF&nbsp;in INFO&nbsp;during 
mid-call.</FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_KqwQawn4i6NySKzKTEsPRg)--


--===============2043024462==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============2043024462==--




From sip-bounces@ietf.org Tue Dec 20 01:23:20 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eoau8-0003S1-0W; Tue, 20 Dec 2005 01:23:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoau6-0003Rt-7s
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 01:23:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16077
	for <sip@ietf.org>; Tue, 20 Dec 2005 01:22:15 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoawQ-0007YT-3Q
	for sip@ietf.org; Tue, 20 Dec 2005 01:25:45 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 19 Dec 2005 22:23:06 -0800
X-IronPort-AV: i="3.99,270,1131350400"; 
	d="scan'208"; a="243032085:sNHT32368004"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBK6N2pf020017;
	Mon, 19 Dec 2005 22:23:03 -0800 (PST)
Received: from 10.21.144.68 ([10.21.144.68]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue, 20 Dec 2005 06:23:02 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 19 Dec 2005 22:23:11 -0800
Subject: Re: [Sip] draft-ietf-sip-outbound-01, Service-Route and flows
From: Cullen Jennings <fluffy@cisco.com>
To: Alex Fritze <alex@croczilla.com>, "sip@ietf.org" <sip@ietf.org>
Message-ID: <BFCCE34F.661F0%fluffy@cisco.com>
Thread-Topic: [Sip] draft-ietf-sip-outbound-01, Service-Route and flows
Thread-Index: AcYFLdmoGGTADXEhEdqFpgARJEEJ/A==
In-Reply-To: <438EF028.2020303@croczilla.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: Marc Petit-Huguenin <petithug@8x8.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On 12/1/05 4:44 AM, "Alex Fritze" <alex@croczilla.com> wrote:

> Hi,
> 
> draft-ietf-sip-outbound-01 isn't very explicit about when exactly a UA
> should monitor a particular flow for failures; in particular when a
> REGISTER request returns a Service-Route with an outbound proxy that is
> different from the configured outbound proxy. In this case, the
> Service-Route will replace the configured route, as per
> draft-rosenberg-sip-route-construct-00. (From the IETF64 sip-outbound
> minutes, I gather that this is also the current consensus).
> In such a scenario, should the UA a) keep alive the original flow to the
> registrar or b) perform DNS resolution on the first proxy in the new
> route and start sending STUN requests to it?
> 

It should do b. I need to update the draft to be clear on this. It would
only send the stun requests if the URI of the proxy had a ;sip-stun

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 05:12:35 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoeTz-0000va-3a; Tue, 20 Dec 2005 05:12:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoeTx-0000vC-3d
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 05:12:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05910
	for <sip@ietf.org>; Tue, 20 Dec 2005 05:11:29 -0500 (EST)
Received: from i-83-67-107-30.freedom2surf.net ([83.67.107.30]
	helo=feynman.croczilla.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoeWJ-0005sg-PP
	for sip@ietf.org; Tue, 20 Dec 2005 05:15:01 -0500
Received: from [192.168.1.101] (unknown [192.168.1.101])
	by feynman.croczilla.com (Postfix) with ESMTP
	id 57ECE3EAC5D; Tue, 20 Dec 2005 10:12:12 +0000 (GMT)
Message-ID: <43A7D8FB.2020806@croczilla.com>
Date: Tue, 20 Dec 2005 10:12:11 +0000
From: Alex Fritze <alex@croczilla.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] draft-ietf-sip-outbound-01, Service-Route and flows
References: <BFCCE34F.661F0%fluffy@cisco.com>
In-Reply-To: <BFCCE34F.661F0%fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Marc Petit-Huguenin <petithug@8x8.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Cullen Jennings wrote:

>On 12/1/05 4:44 AM, "Alex Fritze" <alex@croczilla.com> wrote:
>  
>
>>Hi,
>>
>>draft-ietf-sip-outbound-01 isn't very explicit about when exactly a UA
>>should monitor a particular flow for failures; in particular when a
>>REGISTER request returns a Service-Route with an outbound proxy that is
>>different from the configured outbound proxy. In this case, the
>>Service-Route will replace the configured route, as per
>>draft-rosenberg-sip-route-construct-00. (From the IETF64 sip-outbound
>>minutes, I gather that this is also the current consensus).
>>In such a scenario, should the UA a) keep alive the original flow to the
>>registrar or b) perform DNS resolution on the first proxy in the new
>>route and start sending STUN requests to it?
>>    
>>
>It should do b. I need to update the draft to be clear on this. It would
>only send the stun requests if the URI of the proxy had a ;sip-stun
>
>  
>

Given that the Service-Route might contain names that each resolve to 
several addresses, I still see a problem of pinning down the exact route 
and making sure that inbound requests traverse the flows that are 
actually being kept alive.
Maybe the UA should send a new REGISTER request over a service route 
returned by an initial REGISTER if its first hop differs from the hop 
over which the original REGISTER was sent? Or maybe there should be a 
restriction of only allowing ip addresses (or at least names that 
resolve to single addresses) in Service-Route?

- Alex


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 05:32:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eoemq-0005gG-Dt; Tue, 20 Dec 2005 05:32:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoemo-0005gB-PG
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 05:32:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07942
	for <sip@ietf.org>; Tue, 20 Dec 2005 05:31:00 -0500 (EST)
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoepC-0006bx-N7
	for sip@ietf.org; Tue, 20 Dec 2005 05:34:32 -0500
Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr
	[155.132.251.35])
	by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id
	jBKAVmEs028870; Tue, 20 Dec 2005 11:31:48 +0100
Received: from [172.25.79.32] ([172.25.79.32])
	by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a)
	with ESMTP id 2005122011314739:2585 ;
	Tue, 20 Dec 2005 11:31:47 +0100 
Message-ID: <43A7DD93.3050905@alcatel.fr>
Date: Tue, 20 Dec 2005 10:31:47 +0000
From: Thomas.Levy@alcatel.fr
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR;
	rv:1.7.7) Gecko/20050414
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Sip] Question about draft-ietf-sip-connect-reuse-04 with natted
	UAs
References: <43A6AEDB.5080105@alcatel.fr> <43A6BD05.4090802@cisco.com>
In-Reply-To: <43A6BD05.4090802@cisco.com>
X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a
	|January 7, 2002) at 12/20/2005 11:31:47,
	Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7,
	2002) at 12/20/2005 11:31:48
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I see.
The draft-ietf-sip-outbound-01 provides appropriate SIP routing in the=20
case I described previously.
Thanks,

Thomas LEVY

Jonathan Rosenberg a =E9crit :

> connect-reuse is meant for usage between proxies. The draft you want=20
> is draft-ietf-sip-outbound.
>
> -Jonathan R.
>
> Thomas.Levy@alcatel.fr wrote:
>
>> Rohan and al,
>>
>> It is not clear to me how connection reuse with natted UAs will allow=20
>> to re-use the connection for successive request to a UA.
>> I am considering a case with 2 user agents (UA1 and UA2) and a proxy=20
>> server P1.
>> UA1 and UA2 are in a distinct private network but are using the same=20
>> private address (e.g: 10.0.0.1) and they issued a SIP request to P1=20
>> using TCP and connection reuse. (If needed, I can send a slide that=20
>> describes the network configuration).
>> I understand in the draft that the address used to create a transport=20
>> layer alias is the address placed in the Via by the UAs (i.e:10.0.0.1).
>> Thus, it seems to me that there will be 2 entries for 10.0.0.1 in the=20
>> alias table.
>> How could the proxy choose to use the appropriate connection when a=20
>> request comes to UA1 or UA2?
>> Thanks in advance for any clarifications or comments.
>>
>>
>> Thomas
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>> 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



From sip-bounces@ietf.org Tue Dec 20 09:22:34 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoiNu-00025A-44; Tue, 20 Dec 2005 09:22:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiNr-000252-Rs
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 09:22:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02935
	for <sip@ietf.org>; Tue, 20 Dec 2005 09:21:28 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoiQH-0005f7-IR
	for sip@ietf.org; Tue, 20 Dec 2005 09:25:03 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBKEML2w010063; Tue, 20 Dec 2005 16:22:22 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Dec 2005 16:22:19 +0200
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Dec 2005 16:22:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Dec 2005 16:22:18 +0200
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816E28@esebe101.NOE.Nokia.com>
In-Reply-To: <BFCCE34F.661F0%fluffy@cisco.com>
Thread-Topic: [Sip] draft-ietf-sip-outbound-01, Service-Route and flows
Thread-Index: AcYFLdmoGGTADXEhEdqFpgARJEEJ/AAQb4Tg
To: <fluffy@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 20 Dec 2005 14:22:19.0665 (UTC)
	FILETIME=[C9329810:01C60570]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Sip] draft-ietf-sip-outbound-01: determining STUN support
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

Is it so that the only way for a UA to know if the proxy supports STUN =
for keep-alive purposes is so that the UA needs to be configured to know =
it? Is the only reason for the existence of sip-stun URI parameter that =
it is a convenient way to represent the configuration information, i.e. =
it makes no difference if the parameter is present in the actual SIP =
requests sent by the UA?

Would there be any problem for the UA to test the support by sending a =
STUN request to proxy IP address and port? If it does not succeed, it =
can start using e.g. SIP OPTIONS as  a keep-alive mechanism. Perhaps =
this kind of thing could be mentioned in the draft.

Regards,
	Markus =20

_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 14:34:55 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EonGB-00082C-Cu; Tue, 20 Dec 2005 14:34:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EonG8-00081d-5o
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 14:34:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23439
	for <sip@ietf.org>; Tue, 20 Dec 2005 14:33:48 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EonIY-0002Vi-M7
	for sip@ietf.org; Tue, 20 Dec 2005 14:37:26 -0500
Received: from [192.168.2.101] ([128.107.236.177]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBKJeVgm024178
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 20 Dec 2005 13:40:32 -0600
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1CAE86C0-1F49-4BE7-9B78-9ACFB697F4CA@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Tue, 20 Dec 2005 13:34:38 -0600
To: Sip <sip@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: Andrew Allen <aallen@RIM.COM>, Cullen Jennings <fluffy@cisco.com>
Subject: [Sip] Expert review for
	draft-allen-sipping-poc-p-answer-state-header-01
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


Andrew has submitted the new OMA PoC P-header draft  draft-allen- 
sipping-poc-p-answer-state-header-01.

We've been asked by OMA to complete an expert review of this draft  
according to the process specified in RFC 3427, the SIP Change Process.

I've asked Cullen Jennings to take a look at the draft and see if  
he'll be willing to provide the expert review.

In conjunction with that, it would be nice if we could all read the  
draft, and send any pertinent comments to the list and the author.

Thanks,

--
Dean Willis
SIP co-chair


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 15:43:03 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EooEc-0003XT-98; Tue, 20 Dec 2005 15:37:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EooEZ-0003X9-FX
	for sip@megatron.ietf.org; Tue, 20 Dec 2005 15:37:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02591
	for <sip@ietf.org>; Tue, 20 Dec 2005 15:36:15 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EooGx-00053z-Ea
	for sip@ietf.org; Tue, 20 Dec 2005 15:39:50 -0500
Received: from [192.168.2.101] ([128.107.236.177]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBKKgumu024490
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 20 Dec 2005 14:42:57 -0600
In-Reply-To: <0IRS00IQQ9K8QU@mail.cecwireless.com.cn>
References: <0IRS00IQQ9K8QU@mail.cecwireless.com.cn>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7CD5710B-2134-4D84-9097-6873868BBEF4@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] [INFO-method] Is there any RFC on carrying DTMF with INFO
	in mid-call
Date: Tue, 20 Dec 2005 14:37:04 -0600
To: Chen Shuping <shuping.chen@cecwireless.com.cn>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


On Dec 20, 2005, at 12:19 AM, Chen Shuping wrote:

> Hi,All
>
>     Is there any RFC on carrying DTMF in INFO during mid-call.

No. In fact, the IETF SIP community has decided this is a Bad Idea.

The currently recommended procedure is to use RFC 2833 for DTMF as  
media, and KPML (http://www.ietf.org/internet-drafts/draft-ietf- 
sipping-kpml-07.txt) for DTMF as signaling to applications.

--
Dean


_______________________________________________
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



From sip-bounces@ietf.org Tue Dec 20 15:51:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EooSS-0007bA-I7; Tue, 20 Dec 2005 15:51:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EooQx-0006t8-9T; Tue, 20 Dec 2005 15:50:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04332;
	Tue, 20 Dec 2005 15:49:02 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EooTN-0005Y3-9f; Tue, 20 Dec 2005 15:52:39 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EooQs-0008Sh-1L; Tue, 20 Dec 2005 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EooQs-0008Sh-1L@newodin.ietf.org>
Date: Tue, 20 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-target-dialog-03.txt 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-target-dialog-03.txt
	Pages		: 17
	Date		: 2005-12-20
	
This specification defines the Target-Dialog header field for the
   Session Initiation Protocol (SIP), and the corresponding option tag,
   tdialog.  This header field is used in requests that create SIP
   dialogs.  It indicates to the recipient that the sender is aware of
   an existing dialog with the recipient, either because the sender is
   on the other side of that dialog, or because it has access to the
   dialog identifiers.  The recipient can then authorize the request
   based on this awareness.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-target-dialog-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-target-dialog-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-12-20133239.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-target-dialog-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-target-dialog-03.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-12-20133239.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--NextPart--





From sip-bounces@ietf.org Tue Dec 20 17:06:40 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eopd2-0003um-Rw; Tue, 20 Dec 2005 17:06:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eopcx-0003tU-Lu; Tue, 20 Dec 2005 17:06:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04742;
	Tue, 20 Dec 2005 17:05:31 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EopfS-0007pR-SR; Tue, 20 Dec 2005 17:09:11 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1Eopcw-0006Lu-UM; Tue, 20 Dec 2005 17:06:34 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1Eopcw-0006Lu-UM@newodin.ietf.org>
Date: Tue, 20 Dec 2005 17:06:34 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: sip@ietf.org
Subject: [Sip] Last Call: 'Request Authorization through Dialog
 Identification in the 
 Session Initiation Protocol (SIP)' to Proposed Standard 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

The IESG has received a request from the Session Initiation Protocol WG to 
consider the following document:

- 'Request Authorization through Dialog Identification in the Session 
   Initiation Protocol (SIP) '
   <draft-ietf-sip-target-dialog-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt


_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 22 21:10:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpcOZ-0006Xj-Qr; Thu, 22 Dec 2005 21:10:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpcOX-0006XX-3F
	for sip@megatron.ietf.org; Thu, 22 Dec 2005 21:10:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10468
	for <sip@ietf.org>; Thu, 22 Dec 2005 21:09:52 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpcRR-0005kK-AJ for sip@ietf.org; Thu, 22 Dec 2005 21:13:59 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 22 Dec 2005 18:10:45 -0800
Received: from dwingwxp (sjc-vpn4-140.cisco.com [10.21.80.140])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBN2AfQK006363;
	Thu, 22 Dec 2005 18:10:42 -0800 (PST)
Message-Id: <200512230210.jBN2AfQK006363@sj-core-5.cisco.com>
From: "Dan Wing" <dwing@cisco.com>
To: <fwmiller@cornfed.com>, <sip@ietf.org>
Subject: RE: [Sip] Jabber VoIP specs
Date: Thu, 22 Dec 2005 18:10:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYChfFd4V/s9yO0SyO2Uz+x189nhgE31tvA
In-Reply-To: <200512162110.jBGLAc911208@smapp01.siteprotect.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
> Behalf Of fwmiller@cornfed.com
> Sent: Friday, December 16, 2005 1:11 PM
> To: sip@ietf.org
> Subject: [Sip] Jabber VoIP specs
> 
> 
> For those that may not have seen this, the Jabber Foundation 
> has published their VoIP signaling and media encoding specs.  
> These specs have been reconciled with Google Talk if I read 
> the introductory comments correctly.  I'd be interested in 
> any discussion of the design of these protocols by the SIP 
> gurus here...

Thanks for mentioning the specifications.

> http://www.jabber.org/jeps/jep-0166.html

This specification describes a 'dribble' mode and a 'burst'
mode to exchange endpoint candidate addresses.  Only 
'burst' mode is compatible with ICE (draft-ietf-mmusic-ice).

Section 6.5.2 says that both modes are only SHOULDs.

If we want to have compatibility with Jingle, they'll have 
to make 'burst' mode a MUST.

-d

> http://www.jabber.org/jeps/jep-0167.html
> 
> FM
> 
> 
> _______________________________________________
> 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



From sip-bounces@ietf.org Sat Dec 24 22:44:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EqMo8-0003wJ-3W; Sat, 24 Dec 2005 22:44:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EqMo5-0003wB-MH
	for sip@megatron.ietf.org; Sat, 24 Dec 2005 22:44:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23542
	for <sip@ietf.org>; Sat, 24 Dec 2005 22:43:17 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqMrR-0003mV-1v
	for sip@ietf.org; Sat, 24 Dec 2005 22:47:54 -0500
Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net
	[24.1.177.214]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jBP3o8ZK012679
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Sat, 24 Dec 2005 21:50:09 -0600
In-Reply-To: <200512230210.jBN2AfQK006363@sj-core-5.cisco.com>
References: <200512230210.jBN2AfQK006363@sj-core-5.cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2CD3A3A9-8921-4B03-A356-A73AD66FA3F5@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Jabber VoIP specs
Date: Sat, 24 Dec 2005 21:44:10 -0600
To: Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, fwmiller@cornfed.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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

If I'm reading this right, interworking between SIP and Jabber using   
ICE is going to require "burst" mode in the Jabber implementations  
every time. Without it, interworking failure appears to be very likely.

This is a good point. Anybody here working on the jingle stuff and  
can get a change made? Rohan?
--
Dean


On Dec 22, 2005, at 8:10 PM, Dan Wing wrote:

>> -----Original Message-----
>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
>> Behalf Of fwmiller@cornfed.com
>> Sent: Friday, December 16, 2005 1:11 PM
>> To: sip@ietf.org
>> Subject: [Sip] Jabber VoIP specs
>>
>>
>> For those that may not have seen this, the Jabber Foundation
>> has published their VoIP signaling and media encoding specs.
>> These specs have been reconciled with Google Talk if I read
>> the introductory comments correctly.  I'd be interested in
>> any discussion of the design of these protocols by the SIP
>> gurus here...
>
> Thanks for mentioning the specifications.
>
>> http://www.jabber.org/jeps/jep-0166.html
>
> This specification describes a 'dribble' mode and a 'burst'
> mode to exchange endpoint candidate addresses.  Only
> 'burst' mode is compatible with ICE (draft-ietf-mmusic-ice).
>
> Section 6.5.2 says that both modes are only SHOULDs.
>
> If we want to have compatibility with Jingle, they'll have
> to make 'burst' mode a MUST.
>
> -d


_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 28 19:59:52 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Erm91-0007sv-V1; Wed, 28 Dec 2005 19:59:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Erm90-0007sk-76
	for sip@megatron.ietf.org; Wed, 28 Dec 2005 19:59:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13612
	for <sip@ietf.org>; Wed, 28 Dec 2005 19:58:39 -0500 (EST)
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErmD8-0005Gv-Kg
	for sip@ietf.org; Wed, 28 Dec 2005 20:04:07 -0500
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109])
	by kremlin.juniper.net with ESMTP; 28 Dec 2005 16:59:37 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,305,1131350400"; 
	d="scan'208"; a="518382975:sNHT22080228"
Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Dec 2005 16:59:36 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Dec 2005 16:59:36 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A02138E71@hadron.jnpr.net>
Thread-Topic: [Sip-implementors] 'User'  syntax clarification
Thread-Index: AcYL8TMwFRHrplAGQbKcRGl7SGOfHQAIeBMQ
From: "Anil Bollineni" <ABollineni@juniper.net>
To: "Anil Bollineni" <ABollineni@juniper.net>, <sip@ietf.org>
X-OriginalArrivalTime: 29 Dec 2005 00:59:36.0967 (UTC)
	FILETIME=[23B5D970:01C60C13]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Sip] [Sip-implementors] 'User'  syntax clarification
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

  =20

            According to RFC 3261 19.1.1

     "The set of valid telephone-subscriber strings is a subset of valid
user strings."

=20

     Since the 'user' info part of SIP URL does not cover "#" symbol
according rfc 3261 syntax for 'user'.

According to RFC 2806, the syntax for telephone-subscriber is

telephone-subscriber=3D 1*dtmf-digit

dtmf-digit            =3D "*" / "#" / "A" / "B" / "C" / "D"

=20

=20

How can telephone-subscriber string is a subset of valid user string?=20

=20

Can you please help to resolve the above statement?

=20

Thanks & Regards,

Anil

=20

=20

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
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



From sip-bounces@ietf.org Wed Dec 28 20:41:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErmnP-0003C6-Uh; Wed, 28 Dec 2005 20:41:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ErmnN-0003Bs-Pf
	for sip@megatron.ietf.org; Wed, 28 Dec 2005 20:41:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18091
	for <sip@ietf.org>; Wed, 28 Dec 2005 20:40:21 -0500 (EST)
Received: from mailout2.samsung.com ([203.254.224.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErmrE-0006kw-Dr
	for sip@ietf.org; Wed, 28 Dec 2005 20:45:51 -0500
Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IS8000ZBKOF8T@mailout2.samsung.com> for sip@ietf.org;
	Thu, 29 Dec 2005 10:41:03 +0900 (KST)
Received: from mahesh ([165.213.203.251])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IS8007QBKOFSH@mmp1.samsung.com> for sip@ietf.org; Thu,
	29 Dec 2005 10:41:03 +0900 (KST)
Date: Thu, 29 Dec 2005 10:40:28 +0900
From: Mahesh Govind <mahesh.govind@samsung.com>
Subject: RE: [Sip] [Sip-implementors] 'User'  syntax clarification
In-reply-to: <F07F17B61B7FF545BC7D7E4BFBE15D2A02138E71@hadron.jnpr.net>
To: "'Anil Bollineni'" <ABollineni@juniper.net>, sip@ietf.org
Message-id: <000001c60c18$d900bb10$fbcbd5a5@mahesh>
Organization: Samsung
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7BIT
Cc: 
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

HI,
The following link may  help you.
http://www.mail-archive.com/sip-implementors@cs.columbia.edu/msg02405.html
With regards
Mahesh


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Anil
Bollineni
Sent: Thursday, December 29, 2005 10:00 AM
To: Anil Bollineni; sip@ietf.org
Subject: [Sip] [Sip-implementors] 'User' syntax clarification

Hi,

   

            According to RFC 3261 19.1.1

     "The set of valid telephone-subscriber strings is a subset of valid
user strings."

 

     Since the 'user' info part of SIP URL does not cover "#" symbol
according rfc 3261 syntax for 'user'.

According to RFC 2806, the syntax for telephone-subscriber is

telephone-subscriber= 1*dtmf-digit

dtmf-digit            = "*" / "#" / "A" / "B" / "C" / "D"

 

 

How can telephone-subscriber string is a subset of valid user string? 

 

Can you please help to resolve the above statement?

 

Thanks & Regards,

Anil

 

 

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
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



From sip-bounces@ietf.org Thu Dec 29 12:55:52 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Es20G-0002lV-6N; Thu, 29 Dec 2005 12:55:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Es20E-0002lQ-4H
	for sip@megatron.ietf.org; Thu, 29 Dec 2005 12:55:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24682
	for <sip@ietf.org>; Thu, 29 Dec 2005 12:54:38 -0500 (EST)
Received: from ausmtp03.au.ibm.com ([202.81.18.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es24U-0005Ss-Oa
	for sip@ietf.org; Thu, 29 Dec 2005 13:00:16 -0500
Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202])
	by ausmtp03.au.ibm.com (8.12.10/8.12.10) with ESMTP id jBTHwcsM026956
	for <sip@ietf.org>; Fri, 30 Dec 2005 04:58:38 +1100
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243])
	by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id
	jBTHwS94226840 for <sip@ietf.org>; Fri, 30 Dec 2005 04:58:28 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.12.11/8.13.3) with ESMTP id jBTHtOai029814
	for <sip@ietf.org>; Fri, 30 Dec 2005 04:55:24 +1100
Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105])
	by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id jBTHtOHh029792
	for <sip@ietf.org>; Fri, 30 Dec 2005 04:55:24 +1100
From: Ke Ke Qi <qikeke@cn.ibm.com>
To: sip@ietf.org
Message-ID: <OFBD8052E4.08749113-ON482570E6.0062A3A4-482570E6.0062A3A4@cn.ibm.com>
Date: Fri, 30 Dec 2005 01:57:24 +0800
X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0HF90 |
	November 16, 2005) at 12/30/2005 01:57:26
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Sip] Ke Ke Qi/China/IBM is out of the office.
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="===============0507896034=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============0507896034==
Content-type: multipart/alternative; 
	Boundary="0__=C7BBFA75DFF125348f9e8a93df938690918cC7BBFA75DFF12534"
Content-Disposition: inline

--0__=C7BBFA75DFF125348f9e8a93df938690918cC7BBFA75DFF12534
Content-type: text/plain; charset=US-ASCII


I will be out of the office starting  2005-12-28 and will not return until
2005-12-31.

I will respond to you when I return.
--0__=C7BBFA75DFF125348f9e8a93df938690918cC7BBFA75DFF12534
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>I will be out of the office starting  2005-12-28 and will not return until 2005-12-31.<br>
<br>
I will respond to you when I return. </body></html>
--0__=C7BBFA75DFF125348f9e8a93df938690918cC7BBFA75DFF12534--



--===============0507896034==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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
--===============0507896034==--