From sip-bounces@ietf.org Wed Jun 01 04:45:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdOqu-0000Ur-Ks; Wed, 01 Jun 2005 04:45:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOqt-0000UV-5s
	for sip@megatron.ietf.org; Wed, 01 Jun 2005 04:45:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05982
	for <sip@ietf.org>; Wed, 1 Jun 2005 04:45:24 -0400 (EDT)
Received: from smtp8.clb.oleane.net ([213.56.31.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdPAd-0005ke-DZ
	for sip@ietf.org; Wed, 01 Jun 2005 05:05:54 -0400
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) (authenticated)
	by smtp8.clb.oleane.net with ESMTP id j518ipVd023574
	for <sip@ietf.org>; Wed, 1 Jun 2005 10:44:51 +0200
Message-Id: <200506010844.j518ipVd023574@smtp8.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <sip@ietf.org>
Date: Wed, 1 Jun 2005 10:45:08 +0200
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: AcVmhjbmhX/7qcvOSN2lnPsYflQvuQ==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Subject: [Sip] International SIP conference/exhibition - Call for proposals
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="===============1685850817=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1685850817==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0041_01C56696.FB3C5590"

This is a multi-part message in MIME format.

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

The International SIP conference/exhibition will stand in Paris next
February 2006, 21-24.

 The call for proposals dead line has been extended to June  17.

 

Get all details at:

 <http://www.upperside.fr/sip2006/sip2006intro.htm>
http://www.upperside.fr/sip2006/sip2006intro.htm

 


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

<html 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>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* 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 International SIP conference/exhibition =
will
stand in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next February 2006, 21-24.</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;</span></font><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>The call for =
proposals
dead line has been extended to June&nbsp; 17.</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'>Get all details at:</span></font><span =
lang=3DEN-GB><o:p></o:p></span></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/sip2006/sip2006intro.htm"
title=3D"http://www.upperside.fr/sip2006/sip2006intro.htm"><span =
lang=3DEN-GB>http://www.upperside.fr/sip2006/sip2006intro.htm</span></a><=
/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>

</div>

</body>

</html>

------=_NextPart_000_0041_01C56696.FB3C5590--



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





From sip-bounces@ietf.org Wed Jun 01 08:48:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdSde-0001ul-G8; Wed, 01 Jun 2005 08:48:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSdc-0001t7-1H
	for sip@megatron.ietf.org; Wed, 01 Jun 2005 08:48:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13140
	for <sip@ietf.org>; Wed, 1 Jun 2005 08:47:56 -0400 (EDT)
Received: from tierw.net.avaya.com ([198.152.13.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSxQ-0001PC-T9
	for sip@ietf.org; Wed, 01 Jun 2005 09:08:29 -0400
Received: from tierw.net.avaya.com (localhost [127.0.0.1])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j51CaMq9007987
	for <sip@ietf.org>; Wed, 1 Jun 2005 08:36:22 -0400 (EDT)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j51CaGq9007861
	for <sip@ietf.org>; Wed, 1 Jun 2005 08:36:20 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 1 Jun 2005 15:47:50 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0896E658@is0004avexu1.global.avaya.com>
Thread-Topic: draft-ietf-sip-mib-09.txt - 'MIB Doctor' review
Thread-Index: AcVmqB6ZrIlDK1ycSKu2WiNdLoIYzA==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <sip@ietf.org>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Cc: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com>, j.schoenwaelder@iu-bremen.de
Subject: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review
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="===============0589313067=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0589313067==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C566A8.1EED3213"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C566A8.1EED3213
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Here are my review comments. I apologize for the delay, but
unfortunately the document is not yet completely problems free, and it
generated some discussions 'in the doctors room':
=20
A few issues were found related to the definition of the
SipMethodIdentifier TC and its usage:
=20
1.  The way it is defined the TC encourages extensibility, and this can
be regarded as a good thing. In order to do this a vendor must invent
some numerical assignment, which is not yet used by the standard, and
the DESCRIPTION requires that this assignment "MUST ensure no collision
with officially assigned method identifier values" but says nothing
about how collision can be avoided. It would be useful to split the
identifiers numbers space into standard and experimental, and create a
second experimental registry where vendors building an extension method
and receive a number in the experimental space. This would ensure that
collisions are avoided, and experimental methods are identified at a
glance.
2. Another MIB Doctor asked 'why the method name has not been used as an
index as this would be the natural naming scheme. Having to go through a
lookup table (in case the SipMethodIdentifier has only local
significance) is painful and the alternative to establish another IANA
registry to number the SIP methods seems also kind of costly.'. I am not
sure that a change is necessary at this stage, as nothing is broken, but
as I would suggest that you provide a rationale for this design choice.=20
3. The TC misses a DISPLAY-HINT (probably "d"), which results into a
smilint warning=20
=20
Some more editorial things.=20
=20
4. Since the document was published the Intellectual Property
boilerplates were updated. See
http://www.ietf.org/ietf/1id-guidelines.txt for the latest version
5. It is recommended that the module name of the SIP-TC module be
changed to SIP-TC-MIB
6. typo - DESCRIPTION clause of SipStatusCodeNotifTable - "seperate"
7. typo - DESCRIPTION clause of SipMethodIdentifier - "extention"
8. typo - DESCRIPTION clause of sipServiceNotifEnable - "approriate"
9. type - DESCRIPTION clause of sipServiceWarmStart - "adminstrative"
10. There are 129 instances of too long lines in this documents. Please
run idnits for the full list
http://ietf.levkowetz.com/tools/idnits/idnits.pyht
11. Warnings of weird spacing in lines=20
tmp/draft-ietf-sip-mib-09.txt(4495): Line has weird spacing: '...CodeIns
rena...'
tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing: '...odeOuts
renam...'
tmp/draft-ietf-sip-mib-09.txt(4789): Line has weird spacing: '...odTable
in th...'
12. As Section 8 including the Log of Changes will be taken out, but
there are other sections after this section it would be better to move
it to an annex and renumber, making sure that proper references from the
text go to the intended place.
=20
Regards,
=20
Dan
=20


------_=_NextPart_001_01C566A8.1EED3213
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>Here =
are my review=20
comments. I apologize for the delay, but unfortunately the document is =
not yet=20
completely problems free, and it generated some discussions&nbsp;'in the =
doctors=20
room':</FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>A few =
issues were=20
found related to the definition of the SipMethodIdentifier TC and its=20
usage:</FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>1.=20
</FONT>&nbsp;<FONT face=3DArial size=3D2>The way it is defined the TC =
encourages=20
extensibility, and this can be regarded as a good thing. In order to do =
this a=20
vendor must invent some numerical assignment, which is not yet used by =
the=20
standard, and the DESCRIPTION requires that this assignment "<FONT =
size=3D2>MUST=20
ensure no collision with officially assigned method identifier values" =
but says=20
nothing about how collision can be avoided. It would be useful to split =
the=20
identifiers numbers space into standard and experimental, and create a =
second=20
experimental registry where&nbsp;vendors building an extension method =
and=20
receive a number in the experimental space. This would ensure that =
collisions=20
are avoided, and experimental methods are identified at a=20
glance.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>2. =
Another MIB=20
Doctor asked '<FONT size=3D2>why the method name has not been used as an =
index as=20
this would be the natural naming scheme. Having to go through a lookup =
table (in=20
case the SipMethodIdentifier has only local significance) is painful and =
the=20
alternative to establish another IANA registry to number the SIP methods =
seems=20
also kind of costly.'. I am not sure that a change is&nbsp;necessary at =
this=20
stage, as nothing is broken, but as I would suggest that you provide a =
rationale=20
for this design choice. </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>3. The =
TC misses a=20
DISPLAY-HINT (probably "d"), which results into a smilint warning<SPAN=20
class=3D153552814-30052005> </SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>Some =
more editorial=20
things. </FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>4. =
Since the=20
document was published the Intellectual Property boilerplates were =
updated. See=20
<A=20
href=3D"http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/=
ietf/1id-guidelines.txt</A>&nbsp;for=20
the latest version</FONT></SPAN></DIV>
<DIV><SPAN class=3D153552814-30052005><FONT face=3DArial size=3D2>5. It =
is recommended=20
that the module name of the SIP-TC module be changed to=20
SIP-TC-MIB</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D153552814-30052005>6.=20
</SPAN>t<SPAN class=3D153552814-30052005>ypo - DESCRIPTION clause of=20
SipStatusCodeNotifTable - "seperate"</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D153552814-30052005>7. typo -=20
DESCRIPTION clause of SipMethodIdentifier -=20
"extention"</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D2><SPAN =
class=3D153552814-30052005><FONT=20
face=3DArial>8. typo - DESCRIPTION clause of sipServiceNotifEnable -=20
"approriate"</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN =
class=3D153552814-30052005>9.=20
type - DESCRIPTION clause of sipServiceWarmStart -=20
"adminstrative"</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN =
class=3D153552814-30052005>10.=20
There are 129 instances of too long lines in this documents. Please run =
idnits=20
for the full list <A=20
href=3D"http://ietf.levkowetz.com/tools/idnits/idnits.pyht">http://ietf.l=
evkowetz.com/tools/idnits/idnits.pyht</A></SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT face=3DArial size=3D2><SPAN =
class=3D153552814-30052005>11.=20
Warnings of weird spacing in lines </SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D153552814-30052005>tmp/draft-ietf-sip-mib-09.txt(4495): Line has =
weird=20
spacing: '...CodeIns&nbsp;&nbsp;=20
rena...'<BR>tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing: =

'...odeOuts&nbsp; renam...'<BR>tmp/draft-ietf-sip-mib-09.txt(4789): Line =
has=20
weird spacing: '...odTable&nbsp; in th...'</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D153552814-30052005>12. As =
Section 8=20
including the Log of Changes will be taken out, but there are other =
sections=20
after this section it would be better to move it to an annex and =
renumber,=20
making sure that proper references from the text go to the intended=20
place.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D153552814-30052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D153552814-30052005>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D153552814-30052005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D153552814-30052005>Dan</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D153552814-30052005>&nbsp;</DIV>
<DIV><BR></DIV></SPAN></FONT></BODY></HTML>

------_=_NextPart_001_01C566A8.1EED3213--


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




From sip-bounces@ietf.org Wed Jun 01 10:01:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdTmX-00012D-Mb; Wed, 01 Jun 2005 10:01:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTmV-000128-Fk
	for sip@megatron.ietf.org; Wed, 01 Jun 2005 10:01:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18148
	for <sip@ietf.org>; Wed, 1 Jun 2005 10:01:13 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdU6K-00053U-18
	for sip@ietf.org; Wed, 01 Jun 2005 10:21:45 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id BE5CF6C017;
	Wed,  1 Jun 2005 10:01:07 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
Date: Wed, 1 Jun 2005 10:00:23 -0400
Message-ID: <005501c566b2$45dcd780$6a01010a@keywest>
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 CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <61024460@web.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Sip] RE: [Sip-implementors] About Invite Server transaction
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: Markus Hofmann [mailto:list.sip@web.de]
>
> There is the same Call-ID, same from tag and CSeq number is
> the same. The UAS should be able to recognise that this is a
> retransmission and should send its last answer (200 OK).

*No*, the Call-Id, From-tag, and CSeq are *not* enough to detect
retransmission -- you have to check the branch-parameter of the top Via as
well.  Otherwise, if you have received two forks of the same INVITE (say),
you will think they are duplicates, when they are not -- each must be
responded to separately.

This is the *single most common error* we have found when testing SIP
phones.  In ordinary office situations, it can cause inexplicable
difficulties for the users.

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 Jun 01 13:23:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdWwQ-0005kO-TX; Wed, 01 Jun 2005 13:23:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdWwL-0005kG-SS; Wed, 01 Jun 2005 13:23:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07049;
	Wed, 1 Jun 2005 13:23:34 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-d05.mx.aol.com ([205.188.157.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DdXGB-0007M8-WA; Wed, 01 Jun 2005 13:44:09 -0400
Received: from Mpierce1@aol.com
	by imo-d05.mx.aol.com (mail_out_v38_r1.7.) id c.201.2c0d17a (4214);
	Wed, 1 Jun 2005 13:21:08 -0400 (EDT)
Message-ID: <201.2c0d17a.2fcf4884@aol.com>
Date: Wed, 1 Jun 2005 13:21:08 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (DSN)
To: jmpolk@cisco.com, hgs@cs.columbia.edu
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: sip@ietf.org, iesg@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="===============1795872486=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============1795872486==
Content-Type: multipart/alternative;
	boundary="part1_201.2c0d17a.2fcf4884_boundary"


--part1_201.2c0d17a.2fcf4884_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 5/29/2005 6:05:15 PM Eastern Daylight Time, 
jmpolk@cisco.com writes:


> This was clearly pointed out by the SIP WG chair with the following message 
> 
> header:
> 
> Date: Wed, 17 Nov 2004 19:17:19 -0600
> From: Dean Willis <dean.willis@softarmor.com>
> To: Mpierce1@aol.com, sip@ietf.org
> Subject: Re: [Sip] Comments on Resource-priority-05
> 
> Mike - you did not comment on the list to this message from Dean, while 
> others did.
> 

I did respond to Dean's e-mail of that date. I simply choose to do so 
privately, since there was no use carrying on a public e-mail discussion on an issue 
after he had stated such absolutes concerning what must be in the document, 
effectively cutting off any discussion.

Mike Pierce

--part1_201.2c0d17a.2fcf4884_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 5/29/2005 6:05:15 PM Eastern Daylight Time, jmpolk@cisco.com wri=
tes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">This was clearly pointed out by=
 the SIP WG chair with the following message <BR>
header:<BR>
<BR>
Date: Wed, 17 Nov 2004 19:17:19 -0600<BR>
From: Dean Willis &lt;dean.willis@softarmor.com&gt;<BR>
To: Mpierce1@aol.com, sip@ietf.org<BR>
Subject: Re: [Sip] Comments on Resource-priority-05<BR>
<BR>
Mike - you did not comment on the list to this message from Dean, while <BR>
others did.<BR>
</BLOCKQUOTE><BR>
<BR>
I did respond to Dean's e-mail of that date. I simply choose to do so privat=
ely, since there was no use carrying on a public e-mail discussion on an iss=
ue after he had stated such absolutes concerning what must be in the documen=
t, effectively cutting off any discussion.<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_201.2c0d17a.2fcf4884_boundary--


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




From sip-bounces@ietf.org Wed Jun 01 14:37:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdY5e-0007of-CK; Wed, 01 Jun 2005 14:37:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdY5c-0007oX-8L; Wed, 01 Jun 2005 14:37:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13453;
	Wed, 1 Jun 2005 14:37:12 -0400 (EDT)
Received: from amer-mta02.csc.com ([20.137.2.248])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DdYPU-0002ns-AM; Wed, 01 Jun 2005 14:57:48 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245])
	by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id
	j51Ib0Md012510; Wed, 1 Jun 2005 14:37:00 -0400 (EDT)
Subject: Re: [Sip] Update to draft-ietf-sip-resource-priority section 4.2
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OF6BF0E11A.A1611918-ON85257013.00658561-85257013.006642E9@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Wed, 1 Jun 2005 14:35:11 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September
	14, 2004) at 06/01/2005 02:36:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: sip@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





Henning,

In fixing section 4.2 (by removing the former step 1 about ignoring the RPH
if there is no congestion), you have gone slightly too far the other way.

The way step 3 reads now, it sounds as if you "preempt or queue" every
time, even when there is no congestion.

Perhaps you could reword 3 as "If the request is authorized, and the
resources are available (no congestion), serve as usual.  If the request is
authorized, but resources are not available (congestion), either premept
other current sessions, or insert the request into a priority queue, as
described in 4.5."

Janet


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

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




                                                                                                                 
                      Henning                                                                                    
                      Schulzrinne <hgs         To:      sip@ietf.org                                             
                      @cs.columbia.edu         cc:                                                               
                      >                        Subject: [Sip] Update to draft-ietf-sip-resource-priority         
                      Sent by:                                                                                   
                      sip-bounces                                                                                
                                                                                                                 
                                                                                                                 
                      05/31/2005 06:36                                                                           
                      PM                                                                                         
                                                                                                                 
                                                                                                                 




http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-09.txt

addresses the working group and IETF last-call comments, at least where
the authors and the commenter were in agreement (see the flood of
messages from the weekend). Hopefully, this update can speed up the
resolution of any remaining issues by avoiding discussion of items that
have been resolved already.

I would appreciate if astute readers could alert me to any omissions or
misunderstandings of comments offered.

Henning

_______________________________________________
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 Jun 01 16:38:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdZyy-0006IA-KR; Wed, 01 Jun 2005 16:38:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdZyw-0006GZ-PI; Wed, 01 Jun 2005 16:38:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07309;
	Wed, 1 Jun 2005 16:38:28 -0400 (EDT)
Received: from mail131.messagelabs.com ([216.82.242.99])
	by ietf-mx.ietf.org with smtp (Exim 4.33)
	id 1DdaIo-0005Hk-0n; Wed, 01 Jun 2005 16:59:04 -0400
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-7.tower-131.messagelabs.com!1117658297!1546229!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [192.128.166.71]
Received: (qmail 26847 invoked from network); 1 Jun 2005 20:38:17 -0000
Received: from almso2.att.com (HELO almso2.proxy.att.com) (192.128.166.71)
	by server-7.tower-131.messagelabs.com with SMTP;
	1 Jun 2005 20:38:17 -0000
Received: from attrh3i.attrh.att.com ([135.38.62.9])
	by almso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id
	j51Kb9uE012702; Wed, 1 Jun 2005 16:38:17 -0400
Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by
	attrh3i.attrh.att.com (7.2.052)
	id 4290ADDF001D26D0; Wed, 1 Jun 2005 16:38:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Update to draft-ietf-sip-resource-priority section 4.2
Date: Wed, 1 Jun 2005 15:38:17 -0500
Message-ID: <28F05913385EAC43AF019413F674A01709F4057F@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: [Sip] Update to draft-ietf-sip-resource-priority section 4.2
Thread-Index: AcVm2TBoURPLaA4aSGSKnetctntnUAAAhu6g
From: "Dolly, Martin C, ALABS" <mdolly@att.com>
To: "Janet P Gunn" <jgunn6@csc.com>,
	"Henning Schulzrinne" <hgs@cs.columbia.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: quoted-printable
Cc: sip@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

Janet,

IP priority queueing occurs for these calls/sessions independent of
congestion status, unlike in circuit switched.

Martin=20
>=20
> Janet Gunn wrote on Wednesday, June 01, 2005 2:35 PM
>=20
> Henning,
>=20
> In fixing section 4.2 (by removing the former step 1 about=20
> ignoring the RPH
> if there is no congestion), you have gone slightly too far=20
> the other way.
>=20
> The way step 3 reads now, it sounds as if you "preempt or queue" every
> time, even when there is no congestion.
>=20
> Perhaps you could reword 3 as "If the request is authorized, and the
> resources are available (no congestion), serve as usual.  If=20
> the request is
> authorized, but resources are not available (congestion),=20
> either premept
> other current sessions, or insert the request into a priority=20
> queue, as
> described in 4.5."
>=20
> Janet
>=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 Jun 01 21:07:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdeBj-0007c1-GY; Wed, 01 Jun 2005 21:07:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdeBh-0007bv-Vt
	for sip@megatron.ietf.org; Wed, 01 Jun 2005 21:07:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25535
	for <sip@ietf.org>; Wed, 1 Jun 2005 21:07:54 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdeVc-0001tc-Q1
	for sip@ietf.org; Wed, 01 Jun 2005 21:28:34 -0400
Received: from [192.168.0.31] (pool-141-153-205-126.mad.east.verizon.net
	[141.153.205.126]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j5217pub015029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 1 Jun 2005 21:07:52 -0400 (EDT)
Message-ID: <429E5BC3.2070407@cs.columbia.edu>
Date: Wed, 01 Jun 2005 21:07:15 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Janet P Gunn <jgunn6@csc.com>
Subject: Re: [Sip] Update to draft-ietf-sip-resource-priority section 4.2
References: <OF6BF0E11A.A1611918-ON85257013.00658561-85257013.006642E9@csc.com>
In-Reply-To: <OF6BF0E11A.A1611918-ON85257013.00658561-85257013.006642E9@csc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
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

Janet P Gunn wrote:

> In fixing section 4.2 (by removing the former step 1 about ignoring the RPH
> if there is no congestion), you have gone slightly too far the other way.
> 
> The way step 3 reads now, it sounds as if you "preempt or queue" every
> time, even when there is no congestion.
> 
> Perhaps you could reword 3 as "If the request is authorized, and the
> resources are available (no congestion), serve as usual.  If the request is
> authorized, but resources are not available (congestion), either premept
> other current sessions, or insert the request into a priority queue, as
> described in 4.5."

Good point; I'll change the wording.

_______________________________________________
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 Jun 02 03:26:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddk6D-0004kN-OB; Thu, 02 Jun 2005 03:26:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddk6C-0004k6-NZ
	for sip@megatron.ietf.org; Thu, 02 Jun 2005 03:26:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13798
	for <sip@ietf.org>; Thu, 2 Jun 2005 03:26:39 -0400 (EDT)
Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdkQ9-0003eR-TZ
	for sip@ietf.org; Thu, 02 Jun 2005 03:47:19 -0400
Received: from npd-disclaim.hclt-ntl.co.in (10.105.1.115 [10.105.1.115]) by
	hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2657.72)
	id K826Y05Q; Thu, 2 Jun 2005 12:56:25 +0530
thread-index: AcVnRF+OC5XRh+GdT6ar1ih0hJu4Yg==
X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai,
	India]
Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by
	npd-disclaim.hclt-ntl.co.in with Microsoft
	SMTPSVC(6.0.2600.2180); Thu, 2 Jun 2005 12:56:20 +0530
Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72)
	id <L84RDC8B>; Thu, 2 Jun 2005 12:56:20 +0530
Message-ID: <4B1D6623CCBD79489DE28D1CA062A47EF51BBF@npd-mail.hclt-ntl.co.in>
From: "Puneet Kalia - NPD, Chennai" <puneetkl@hcltech.com>
To: <sip@ietf.org>
Date: Thu, 2 Jun 2005 12:56:13 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 02 Jun 2005 07:26:20.0807 (UTC)
	FILETIME=[5F875970:01C56744]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Subject: [Sip] CDR for SIP
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="===============1502917864=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1502917864==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C56744.5B5BD830"
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------_=_NextPart_001_01C56744.5B5BD830
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi ,

=20

I am looking at some information on generating CDR's for SIP calls .   =
Can
anybody lhelp me out in these questions

=20

What does SIP standard says about generating CDR?

. Is there any RFCs /Drafts , which talks about  format/contents of CDRs =
?

=20

Or it is something which is left to vendors to implement as they like .

=20

Thanks

Puneet Kalia

=20


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.

------_=_NextPart_001_01C56744.5B5BD830
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
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)">
<style>
<!--
 /* 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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@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 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi ,<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am looking at some information on generating =
CDR&#8217;s
for SIP calls .&nbsp; &nbsp;Can anybody lhelp me out in these =
questions<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What does SIP standard says about generating =
CDR?<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'>. Is there any RFCs /Drafts , which talks about&nbsp; =
format/contents
of CDRs ?<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Or it is something which is left to vendors to =
implement as
they like .<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks<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'>Puneet Kalia<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'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div><p><font size=3D"1">

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.
</font></p></div>
</body>

</html>

------_=_NextPart_001_01C56744.5B5BD830--


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




From sip-bounces@ietf.org Thu Jun 02 04:51:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DdlQL-0004ms-6m; Thu, 02 Jun 2005 04:51:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdlQI-0004j7-7w
	for sip@megatron.ietf.org; Thu, 02 Jun 2005 04:51:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18518
	for <sip@ietf.org>; Thu, 2 Jun 2005 04:51:28 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdlkG-0007tg-Th
	for sip@ietf.org; Thu, 02 Jun 2005 05:12:10 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j528m3dZ013900; Thu, 2 Jun 2005 11:48:07 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 2 Jun 2005 11:51:21 +0300
Received: from [127.0.0.1] ([172.21.35.54]) by esebh003.NOE.Nokia.com with
	Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Jun 2005 11:51:20 +0300
Message-ID: <429EC888.6010806@nokia.com>
Date: Thu, 02 Jun 2005 11:51:20 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: "Puneet Kalia - NPD, Chennai" <puneetkl@hcltech.com>
Subject: Re: [Sip] CDR for SIP
References: <4B1D6623CCBD79489DE28D1CA062A47EF51BBF@npd-mail.hclt-ntl.co.in>
In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47EF51BBF@npd-mail.hclt-ntl.co.in>
Content-Type: text/plain; charset=windows-1252; format=flowed
X-OriginalArrivalTime: 02 Jun 2005 08:51:20.0919 (UTC)
	FILETIME=[3F6EAE70:01C56750]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext04.nokia.com id
	j528m3dZ013900
X-Spam-Score: 0.2 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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

Puneet Kalia:

I am not aware of any IETF spec that describes format of contents of=20
CDRs, I believe those are typically outside the scope of the IETF work.

I am aware, though, of work done in 3GPP, where the contents of CDRs are=20
standardized. You can take a look at 3GPP TS 32.260. Section 6.1.3 will=20
provide you a hint.

The spec is available at:
http://www.3gpp.org/ftp/Specs/archive/32_series/32.260/32260-610.zip

BR,

      Miguel

Puneet Kalia - NPD, Chennai wrote:

> Hi ,
>=20
> =20
>=20
> I am looking at some information on generating CDR=92s for SIP calls . =
=20
>  Can anybody lhelp me out in these questions
>=20
> =20
>=20
> What does SIP standard says about generating CDR?
>=20
> . Is there any RFCs /Drafts , which talks about  format/contents of CDR=
s ?
>=20
> =20
>=20
> Or it is something which is left to vendors to implement as they like .
>=20
> =20
>=20
> Thanks
>=20
> Puneet Kalia
>=20
> =20
>=20
> Disclaimer: This message and any attachment(s) contained here are=20
> information that is confidential, proprietary to HCL Technologies and=20
> its customers, privileged or otherwise protected by law. The informatio=
n=20
> is solely intended for the individual or the entity it is addressed to.=
=20
> If you are not the intended recipient of this message, you are not=20
> authorized to read, forward, print, retain, copy or disseminate this=20
> message or any part of it. If you have received this e-mail in error,=20
> please notify the sender immediately by return e-mail and delete it fro=
m=20
> your computer.
>=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
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
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 Jun 02 09:48:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddq3S-0003FB-BF; Thu, 02 Jun 2005 09:48:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddq3O-0003BR-PH; Thu, 02 Jun 2005 09:48:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14475;
	Thu, 2 Jun 2005 09:48:08 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-m15.mx.aol.com ([64.12.138.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DdqNR-00064U-3S; Thu, 02 Jun 2005 10:08:53 -0400
Received: from Mpierce1@aol.com
	by imo-m15.mx.aol.com (mail_out_v38_r1.7.) id c.e6.6afbda60 (17377);
	Thu, 2 Jun 2005 09:46:57 -0400 (EDT)
Message-ID: <e6.6afbda60.2fd067d1@aol.com>
Date: Thu, 2 Jun 2005 09:46:57 EDT
Subject: Re: [Sip] Comments on Last Call of "Extending Reason-header for
	Preemption Ev...
To: jmpolk@cisco.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
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="===============1588728450=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============1588728450==
Content-Type: multipart/alternative;
	boundary="part1_e6.6afbda60.2fd067d1_boundary"


--part1_e6.6afbda60.2fd067d1_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 5/29/2005 6:17:03 PM Eastern Daylight Time, 
jmpolk@cisco.com writes:


> >Section 7 IANA Considerations
> >As noted above, this section contains an erroneous statement about what 
> >"syntax shall be used". At the same time, it is unclear what the IANA 
> >registration requirements are. For example, this part implies that IANA 
> >needs to register the text strings, when there is clearly no need for that.
> 

You didn't respond to the above comment I submitted. I suspect it requires a 
little better explanation on my part.

Since this draft defines a new reason value, it must be assumed that it is 
based on, and follows everything in, RFC 3326. However, it doesn't make a clear 
statement that the syntax follows what is defined in RFC 3326.

As I read the syntax in Section 2 of RFC 3326, the reason header may contain 
multiple reason-values (e.g., both SIP and Q.850) and for each protocol may 
specify multiple reason-parameters (e.g., cause value and text), and each is 
optional. The syntax defined in Section 2 allows the use of a cause value without 
the accompanying text string, although the examples don't ever show that.

(However, the final paragraph of Section 2 of RFC 3326 implies that multiple 
protocols are indicated by the use on multiple headers - "multiple Reason 
lines" - not by putting multiple protocols into one header.)

This draft, on the other hand, contains statements like:

the following syntax shall be used:

         Reason: preemption ;cause=1 ;text="UA Preemption"

This implies that the text part is mandatory.

It seems that part of the problem is the way that the syntax was defined in 
RFC 3326. While it implied that the text part is always used, the formal 
definition shows it as optional.

Concerning IANA registration, RFC 3326 only required the registration of the 
protocols (SIP and Q.950) since all cause values and text strings were defined 
elsewhere. This draft extends that model by requiring the registration of 
more than the new protocol ("preemption"). It implies that both cause values and 
text strings need to be registered, but this is not clear. Rather than 
containing more description of the procedures for use of these parameters, Section 7 
needs explicit statements about IANA registration requirements.

Mike Pierce


--part1_e6.6afbda60.2fd067d1_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 5/29/2005 6:17:03 PM Eastern Daylight Time, jmpolk@cisco.com wri=
tes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&gt;Section 7 IANA Consideratio=
ns<BR>
&gt;As noted above, this section contains an erroneous statement about what=20=
<BR>
&gt;"syntax shall be used". At the same time, it is unclear what the IANA <B=
R>
&gt;registration requirements are. For example, this part implies that IANA=20=
<BR>
&gt;needs to register the text strings, when there is clearly no need for th=
at.<BR>
</BLOCKQUOTE><BR>
<BR>
You didn't respond to the above comment I submitted. I suspect it requires a=
 little better explanation on my part.<BR>
<BR>
Since this draft defines a new reason value, it must be assumed that it is b=
ased on, and follows everything in, RFC 3326. However, it doesn't make a cle=
ar statement that the syntax follows what is defined in RFC 3326.<BR>
<BR>
As I read the syntax in Section 2 of RFC 3326, the reason header may contain=
 multiple reason-values (e.g., both SIP and Q.850) and for each protocol may=
 specify multiple reason-parameters (e.g., cause value and text), and each i=
s optional. The syntax defined in Section 2 allows the use of a cause value=20=
without the accompanying text string, although the examples don't ever show=20=
that.<BR>
<BR>
(However, the final paragraph of Section 2 of RFC 3326 implies that multiple=
 protocols are indicated by the use on multiple headers - "multiple Reason l=
ines" - not by putting multiple protocols into one header.)<BR>
<BR>
This draft, on the other hand, contains statements like:<BR>
<BR>
the following syntax shall be used:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reason: preemption ;cause=
=3D1 ;text=3D"UA Preemption"<BR>
<BR>
This implies that the text part is mandatory.<BR>
<BR>
It seems that part of the problem is the way that the syntax was defined in=20=
RFC 3326. While it implied that the text part is always used, the formal def=
inition shows it as optional.<BR>
<BR>
Concerning IANA registration, RFC 3326 only required the registration of the=
 protocols (SIP and Q.950) since all cause values and text strings were defi=
ned elsewhere. This draft extends that model by requiring the registration o=
f more than the new protocol ("preemption"). It implies that both cause valu=
es and text strings need to be registered, but this is not clear. Rather tha=
n containing more description of the procedures for use of these parameters,=
 Section 7 needs explicit statements about IANA registration requirements.<B=
R>
<BR>
Mike Pierce<BR>
<BR>
</FONT></HTML>
--part1_e6.6afbda60.2fd067d1_boundary--


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




From sip-bounces@ietf.org Thu Jun 02 18:09:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddxsv-00011P-Oa; Thu, 02 Jun 2005 18:09:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddxst-000119-AW; Thu, 02 Jun 2005 18:09:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05475;
	Thu, 2 Jun 2005 18:09:48 -0400 (EDT)
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.33)
	id 1DdyD0-0002kh-0R; Thu, 02 Jun 2005 18:30:38 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 15:09:42 -0700
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52M9abw003229;
	Thu, 2 Jun 2005 15:09:37 -0700 (PDT)
Received: from jmpolk-wxp.cisco.com (sjc-vpn1-488.cisco.com [10.21.97.232]) by
	wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with
	ESMTP id PAA02261; Thu, 2 Jun 2005 15:09:37 -0700 (PDT)
Message-Id: <4.3.2.7.2.20050602170857.033486d8@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 Jun 2005 17:09:36 -0500
To: Mpierce1@aol.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending
	Reason-header for Preemption Ev...
In-Reply-To: <e6.6afbda60.2fd067d1@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
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

At 09:46 AM 6/2/2005 -0400, Mpierce1@aol.com wrote:
>In a message dated 5/29/2005 6:17:03 PM Eastern Daylight Time, 
>jmpolk@cisco.com writes:
>
>
>> >Section 7 IANA Considerations
>> >As noted above, this section contains an erroneous statement about what
>> >"syntax shall be used". At the same time, it is unclear what the IANA
>> >registration requirements are. For example, this part implies that IANA
>> >needs to register the text strings, when there is clearly no need for that.
>
>
>You didn't respond to the above comment I submitted.

Because SIP and Q.850 have clearly defined meanings for their cause 
numbers, and this extension does not, I believe the text string should be 
maintained through IANA.

 From an IANA point of view, at 
http://www.iana.org/assignments/sip-parameters you can see the text string 
for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used 
if the SIP protocol were used in a 3326 Reason header. As IANA is where to 
first look up these things, I'm not sure why you have an issue with IANA 
having the same text string explaining what each cause is in the Preemption 
protocol of the Reason header. If the text string were removed in the IANA 
registration, there would be no clue there what each cause number meant.

This is not the case right now at 
http://www.iana.org/assignments/sip-parameters for all other SIP parameters.

I believe one of your concerns is the user learning/reading the reason in 
the Reason header within your domain, and I believe that is a local 
configuration decision.

In the document, I do not believe I ever made it a MUST, SHOULD, 
RECOMMENDED or even a MAY be presented to the user of the UA who is being 
preempted. I believe this is up to the implementation and local policy to 
show, or not to show.

>I suspect it requires a little better explanation on my part.
>
>Since this draft defines a new reason value, it must be assumed that it is 
>based on, and follows everything in, RFC 3326. However, it doesn't make a 
>clear statement that the syntax follows what is defined in RFC 3326.
>
>As I read the syntax in Section 2 of RFC 3326, the reason header may 
>contain multiple reason-values (e.g., both SIP and Q.850) and for each 
>protocol may specify multiple reason-parameters (e.g., cause value and 
>text), and each is optional. The syntax defined in Section 2 allows the 
>use of a cause value without the accompanying text string, although the 
>examples don't ever show that.
>
>(However, the final paragraph of Section 2 of RFC 3326 implies that 
>multiple protocols are indicated by the use on multiple headers - 
>"multiple Reason lines" - not by putting multiple protocols into one header.)
>
>This draft, on the other hand, contains statements like:
>
>the following syntax shall be used:
>
>          Reason: preemption ;cause=1 ;text="UA Preemption"
>
>This implies that the text part is mandatory.
>
>It seems that part of the problem is the way that the syntax was defined 
>in RFC 3326. While it implied that the text part is always used, the 
>formal definition shows it as optional.
>
>Concerning IANA registration, RFC 3326 only required the registration of 
>the protocols (SIP and Q.950) since all cause values and text strings were 
>defined elsewhere. This draft extends that model by requiring the 
>registration of more than the new protocol ("preemption"). It implies that 
>both cause values and text strings need to be registered, but this is not 
>clear. Rather than containing more description of the procedures for use 
>of these parameters, Section 7 needs explicit statements about IANA 
>registration requirements.
>
>Mike Pierce
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sip@ietf.org for new developments of core SIP


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
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 Jun 02 19:30:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddz8q-0000lL-E6; Thu, 02 Jun 2005 19:30:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ddz8l-0000kX-Pp; Thu, 02 Jun 2005 19:30:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11337;
	Thu, 2 Jun 2005 19:30:16 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DdzSs-0004XU-9A; Thu, 02 Jun 2005 19:51:07 -0400
Received: from [64.101.139.203] ([64.101.139.203]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j52NXEeC014576
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 2 Jun 2005 18:33:15 -0500
In-Reply-To: <201.2c0d17a.2fcf4884@aol.com>
References: <201.2c0d17a.2fcf4884@aol.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <088641976cecea1d59c6a80aaa16d58b@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Comments on Resource Priority -08 (DSN)
Date: Thu, 2 Jun 2005 18:29:56 -0500
To: Mpierce1@aol.com
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, jmpolk@cisco.com, iesg@ietf.org, hgs@cs.columbia.edu
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 Jun 1, 2005, at 12:21 PM, Mpierce1@aol.com wrote:

> In a message dated 5/29/2005 6:05:15 PM Eastern Daylight Time, 
> jmpolk@cisco.com writes:
>
>
>> This was clearly pointed out by the SIP WG chair with the following 
>> message
>>  header:
>>
>>  Date: Wed, 17 Nov 2004 19:17:19 -0600
>>  From: Dean Willis <dean.willis@softarmor.com>
>>  To: Mpierce1@aol.com, sip@ietf.org
>>  Subject: Re: [Sip] Comments on Resource-priority-05
>>
>>  Mike - you did not comment on the list to this message from Dean, 
>> while
>>  others did.
>
>
>  I did respond to Dean's e-mail of that date. I simply choose to do so 
> privately, since there was no use carrying on a public e-mail 
> discussion on an issue after he had stated such absolutes concerning 
> what must be in the document, effectively cutting off any discussion.
>

yes, Mike responded. He's very reliable that way.

--
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 Mon Jun 06 01:30:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfABc-0000hl-7M; Mon, 06 Jun 2005 01:30:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DdPXH-0006dD-K6
	for sip@megatron.ietf.org; Wed, 01 Jun 2005 05:29:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10473
	for <sip@ietf.org>; Wed, 1 Jun 2005 05:29:13 -0400 (EDT)
Received: from fmmailgate04.web.de ([217.72.192.242])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdPqz-0007nW-FA
	for sip@ietf.org; Wed, 01 Jun 2005 05:49:43 -0400
Received: by fmmailgate04.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP
	id j519Smod007601; Wed, 1 Jun 2005 11:28:48 +0200
Received: from [213.144.13.202] by freemailng2204.web.de with HTTP;
	Wed, 01 Jun 2005 11:28:44 +0200
Date: Wed, 01 Jun 2005 11:28:44 +0200
Message-Id: <61024460@web.de>
MIME-Version: 1.0
From: "Markus Hofmann" <list.sip@web.de>
To: "Dale Worley" <dworley@pingtel.com>, sip-implementors@cs.columbia.edu,
	sip@ietf.org
Precedence: fm-user
Organization: http://freemail.web.de/
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 06 Jun 2005 01:30:04 -0400
Cc: 
Subject: [Sip] RE: [Sip-implementors] About Invite Server transaction
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
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

"Dale Worley" <dworley@pingtel.com> schrieb am 01.06.05 10:51:35:
> 
> > From: Anil Bollineni
> > 
> > Assume 100, 200 responses are sent from UAS to client, and
> > they are lost. Then INVITE is retransmitted to UAS. As soon 
> > as UAS send
> > 200 OK it destroys the server transaction. Per UAS, the 
> > dialog state is
> > already created after sending 200 response. If INVITE is passed to TU
> > from transport layer, then how this INVITE is been treated as
> > retransmission of INVITE, since the TU, will  not able to match any
> > existing dialog (since no to-tag in INVITE), and will it 
> > treat as a new
> > call. Is the assumption correct? Or where in RFC this scenario will be
> > treated.
> 
> I believe that the correct handling is that the transport layer will
> discover that it is a retransmission of the original INVITE because of the
> Via branch-parameter, etc.  So the transport layer will re-send its 200
> response, and not notify the TU.
> 
> Dale
> 
Yes, I think so too.

There is the same Call-ID, same from tag and CSeq number is the same. The UAS should be able to recognise that this is a retransmission and should send its last answer (200 OK).

Markus
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 


__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201


_______________________________________________
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 Jun 06 10:13:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfIKD-00069c-2H; Mon, 06 Jun 2005 10:11:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIKA-000682-If
	for sip@megatron.ietf.org; Mon, 06 Jun 2005 10:11:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03563
	for <sip@ietf.org>; Mon, 6 Jun 2005 10:11:28 -0400 (EDT)
Received: from smtp1.clb.oleane.net ([213.56.31.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfIf0-0001n7-Ja
	for sip@ietf.org; Mon, 06 Jun 2005 10:33:04 -0400
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) (authenticated)
	by smtp1.clb.oleane.net with ESMTP id j56EBI5O029248
	for <sip@ietf.org>; Mon, 6 Jun 2005 16:11:18 +0200
Message-Id: <200506061411.j56EBI5O029248@smtp1.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <sip@ietf.org>
Date: Mon, 6 Jun 2005 16:11:08 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcVqoZXnN6eb73lwROymi518boj5sg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Subject: [Sip] WiMAX Summit - Paris - France - Call for proposals
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="===============1702380754=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1702380754==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01C56AB2.5BFDA680"

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C56AB2.5BFDA680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The third edition of the WiMAX Summit, the most important European event
dedicated to this technology, will stand in Paris next February 21-24, 2006.

A call for proposals is online at:

 <http://www.upperside.fr/wimax2006/wimax2006intro.htm>
http://www.upperside.fr/wimax2006/wimax2006intro.htm

The dead line for turning in abstracts is June 30.

 

 


------=_NextPart_000_0022_01C56AB2.5BFDA680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html 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"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* 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 WiMAX Summit, the =
most
important European event dedicated to this technology, will stand in =
<st1:place
w:st=3D"on"><st1:City w:st=3D"on">Paris</st1:City></st1:place> next =
February 21-24,
2006.</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'>A call for proposals is online =
at:</span></font><span
lang=3DEN-GB><o:p></o:p></span></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/wimax2006/wimax2006intro.htm"
title=3D"http://www.upperside.fr/wimax2006/wimax2006intro.htm"><span =
lang=3DEN-GB><span
title=3D"http://www.upperside.fr/wimax2006/wimax2006intro.htm">http://www=
.upperside.fr/wimax2006/wimax2006intro.htm</span></span></a></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'>The dead line for turning in abstracts is June =
30.</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'><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_0022_01C56AB2.5BFDA680--



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





From sip-bounces@ietf.org Mon Jun 06 10:13:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfILO-0006S6-Lt; Mon, 06 Jun 2005 10:12:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfILL-0006RJ-Nh; Mon, 06 Jun 2005 10:12:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03739;
	Mon, 6 Jun 2005 10:12:41 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-d04.mx.aol.com ([205.188.157.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfIgB-0001p3-Tz; Mon, 06 Jun 2005 10:34:17 -0400
Received: from Mpierce1@aol.com
	by imo-d04.mx.aol.com (mail_out_v38_r1.7.) id 7.ac.74a88ff8 (4214);
	Mon, 6 Jun 2005 10:12:19 -0400 (EDT)
Message-ID: <ac.74a88ff8.2fd5b3c2@aol.com>
Date: Mon, 6 Jun 2005 10:12:18 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
To: hgs@cs.columbia.edu
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: sip@ietf.org, iesg@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="===============0267818513=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============0267818513==
Content-Type: multipart/alternative;
	boundary="part1_ac.74a88ff8.2fd5b3c2_boundary"


--part1_ac.74a88ff8.2fd5b3c2_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 5/29/2005 5:39:51 PM Eastern Daylight Time, 
hgs@cs.columbia.edu writes:


> Note that it says "a subsequent request". This does not imply that the 
> UAC "redials". It simply tells the UAC and its user what values are 
> permitted for future calls, for example. A user agent could, for 
> example, display such values where known. The user interface is clearly 
> beyond the scope of the draft.
> 
> I don't see the need to change this.
> 
> > Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC 
> > MAY attempt a subsequent request with the same or different resource 
> > value." This is contrary to the policies for using priority values and 
> > should not be mentioned. The user (human) is supposed to select the 
> > correct value before requested a call setup. A UAC must never 
> > automatically attempt another request using a different resource value 
> > upon receipt of a 417. Of course, a human user may choose to do whatever 
> > they are authorized to do when trying a new call, but no device can be 
> > allowed to do this automatically, since it would be violating the 
> > policies for the use of priority levels.
> > 
> 
> 
As I commented, the text clearly indicates that the "UAC" (i.e., the physical 
device, not the human) may attempt a subsequent request. There should be no 
implication that it is permissable for the UAC to do this while text that says 
that a human user might do this is okay. It should describe only what the UAC 
"MAY" do in support of this. The current paragraph which says:

   Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
   MAY attempt a subsequent request with the same or different resource
   value.  If available, it SHOULD choose authorized resource values
   from the set of values returned in the 'Accept-Resource-Priority'
   header field.

Should be changed to:

   Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
   MAY display to the user a list of the authorized resource values returned 
in the 'Accept-Resource-Priority'
   header field. The user may then attempt a subsequent request with the same 
or different resource
   value.

Then it is clear that it is the human user, not the device, which is making 
the decision and attempting another call.

Mike Pierce

--part1_ac.74a88ff8.2fd5b3c2_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 5/29/2005 5:39:51 PM Eastern Daylight Time, hgs@cs.columbia.edu=20=
writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Note that it says "a subsequent=
 request". This does not imply that the <BR>
UAC "redials". It simply tells the UAC and its user what values are <BR>
permitted for future calls, for example. A user agent could, for <BR>
example, display such values where known. The user interface is clearly <BR>
beyond the scope of the draft.<BR>
<BR>
I don't see the need to change this.<BR>
<BR>
&gt; Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC=20=
<BR>
&gt; MAY attempt a subsequent request with the same or different resource <B=
R>
&gt; value." This is contrary to the policies for using priority values and=20=
<BR>
&gt; should not be mentioned. The user (human) is supposed to select the <BR=
>
&gt; correct value before requested a call setup. A UAC must never <BR>
&gt; automatically attempt another request using a different resource value=20=
<BR>
&gt; upon receipt of a 417. Of course, a human user may choose to do whateve=
r <BR>
&gt; they are authorized to do when trying a new call, but no device can be=20=
<BR>
&gt; allowed to do this automatically, since it would be violating the <BR>
&gt; policies for the use of priority levels.<BR>
&gt; <BR>
<BR>
</BLOCKQUOTE><BR>
As I commented, the text clearly indicates that the "UAC" (i.e., the physica=
l device, not the human) may attempt a subsequent request. There should be n=
o implication that it is permissable for the UAC to do this while text that=20=
says that a human user might do this is okay. It should describe only what t=
he UAC "MAY" do in support of this. The current paragraph which says:<BR>
<BR>
&nbsp;&nbsp; Upon receiving a 417 (Unknown Resource-Priority) response, the=20=
UAC<BR>
&nbsp;&nbsp; MAY attempt a subsequent request with the same or different res=
ource<BR>
&nbsp;&nbsp; value.&nbsp; If available, it SHOULD choose authorized resource=
 values<BR>
&nbsp;&nbsp; from the set of values returned in the 'Accept-Resource-Priorit=
y'<BR>
&nbsp;&nbsp; header field.<BR>
<BR>
Should be changed to:<BR>
<BR>
&nbsp;&nbsp; Upon receiving a 417 (Unknown Resource-Priority) response, the=20=
UAC<BR>
&nbsp;&nbsp; MAY display to the user a list of the authorized resource value=
s returned in the 'Accept-Resource-Priority'<BR>
&nbsp;&nbsp; header field. The user may then attempt a subsequent request wi=
th the same or different resource<BR>
&nbsp;&nbsp; value.<BR>
<BR>
Then it is clear that it is the human user, not the device, which is making=20=
the decision and attempting another call.<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_ac.74a88ff8.2fd5b3c2_boundary--


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




From sip-bounces@ietf.org Mon Jun 06 10:13:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfILK-0006Qx-9B; Mon, 06 Jun 2005 10:12:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfILF-0006OU-As; Mon, 06 Jun 2005 10:12:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03709;
	Mon, 6 Jun 2005 10:12:34 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-m27.mx.aol.com ([64.12.137.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfIg4-0001of-Kt; Mon, 06 Jun 2005 10:34:10 -0400
Received: from Mpierce1@aol.com
	by imo-m27.mx.aol.com (mail_out_v38_r1.7.) id c.7a.74d87318 (4214);
	Mon, 6 Jun 2005 10:12:17 -0400 (EDT)
Message-ID: <7a.74d87318.2fd5b3c1@aol.com>
Date: Mon, 6 Jun 2005 10:12:17 EDT
Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending
	Reason-header for...
To: jmpolk@cisco.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
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="===============0144885261=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============0144885261==
Content-Type: multipart/alternative;
	boundary="part1_7a.74d87318.2fd5b3c1_boundary"


--part1_7a.74d87318.2fd5b3c1_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/2/2005 6:10:09 PM Eastern Daylight Time, 
jmpolk@cisco.com writes:


> Because SIP and Q.850 have clearly defined meanings for their cause 
> numbers, and this extension does not, I believe the text string should be 
> maintained through IANA.
> 
> From an IANA point of view, at 
> http://www.iana.org/assignments/sip-parameters you can see the text string 
> for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used 
> if the SIP protocol were used in a 3326 Reason header. As IANA is where to 
> first look up these things, I'm not sure why you have an issue with IANA 
> having the same text string explaining what each cause is in the Preemption 
> protocol of the Reason header. If the text string were removed in the IANA 
> registration, there would be no clue there what each cause number meant.
> 
> This is not the case right now at 
> http://www.iana.org/assignments/sip-parameters for all other SIP parameters.
> 
> I believe one of your concerns is the user learning/reading the reason in 
> the Reason header within your domain, and I believe that is a local 
> configuration decision.
> 
> In the document, I do not believe I ever made it a MUST, SHOULD, 
> RECOMMENDED or even a MAY be presented to the user of the UA who is being 
> preempted. I believe this is up to the implementation and local policy to 
> show, or not to show.
> 


I guess I didn't explain my concern well enough. It isn't the issue of 
notifying the user of something they shouldn't know in our domain. The "Generic 
Preemption" was added to deal with this.

I have no problem with the (default) text string being registered with IANA 
for each defined preemption cause as was done for each SIP response code. The 
concern is that the IANA considerations section does not make it clear that 
this is what IANA is expected to do.

I don't understand why this is called the "default" text. It would seem that 
any device could put in any text string it wanted, for example, the same thing 
in another langauage. I believe RFC 3261 is rather vague on this issue. While 
the ABNF requires that a Reason-phrase be included in every message and it 
provides "default" text for each and includes it in the IANA registration, I 
don't believe it requires that this exact text string be used.

My comment is mostly that there appears to be a conflict between the text in 
this draft and the formal syntax definition in RFC 3326. I don't know which is 
correct. It would seem to me that, if this new preemption cause is used, that 
the numeric cause value is mandatory and the text string is optional. Neither 
RFC 3326 nor this draft says that. The formal definition in RFC 3326 says 
both are optional. This draft indicates that both are required.


Mike Pierce

--part1_7a.74d87318.2fd5b3c1_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 6/2/2005 6:10:09 PM Eastern Daylight Time, jmpolk@cisco.com writ=
es:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Because SIP and Q.850 have clea=
rly defined meanings for their cause <BR>
numbers, and this extension does not, I believe the text string should be <B=
R>
maintained through IANA.<BR>
<BR>
>From an IANA point of view, at <BR>
http://www.iana.org/assignments/sip-parameters you can see the text string <=
BR>
for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used <B=
R>
if the SIP protocol were used in a 3326 Reason header. As IANA is where to <=
BR>
first look up these things, I'm not sure why you have an issue with IANA <BR=
>
having the same text string explaining what each cause is in the Preemption=20=
<BR>
protocol of the Reason header. If the text string were removed in the IANA <=
BR>
registration, there would be no clue there what each cause number meant.<BR>
<BR>
This is not the case right now at <BR>
http://www.iana.org/assignments/sip-parameters for all other SIP parameters.=
<BR>
<BR>
I believe one of your concerns is the user learning/reading the reason in <B=
R>
the Reason header within your domain, and I believe that is a local <BR>
configuration decision.<BR>
<BR>
In the document, I do not believe I ever made it a MUST, SHOULD, <BR>
RECOMMENDED or even a MAY be presented to the user of the UA who is being <B=
R>
preempted. I believe this is up to the implementation and local policy to <B=
R>
show, or not to show.<BR>
</BLOCKQUOTE><BR>
<BR>
<BR>
I guess I didn't explain my concern well enough. It isn't the issue of notif=
ying the user of something they shouldn't know in our domain. The "Generic P=
reemption" was added to deal with this.<BR>
<BR>
I have no problem with the (default) text string being registered with IANA=20=
for each defined preemption cause as was done for each SIP response code. Th=
e concern is that the IANA considerations section does not make it clear tha=
t this is what IANA is expected to do.<BR>
<BR>
I don't understand why this is called the "default" text. It would seem that=
 any device could put in any text string it wanted, for example, the same th=
ing in another langauage. I believe RFC 3261 is rather vague on this issue.=20=
While the ABNF requires that a Reason-phrase be included in every message an=
d it provides "default" text for each and includes it in the IANA registrati=
on, I don't believe it requires that this exact text string be used.<BR>
<BR>
My comment is mostly that there appears to be a conflict between the text in=
 this draft and the formal syntax definition in RFC 3326. I don't know which=
 is correct. It would seem to me that, if this new preemption cause is used,=
 that the numeric cause value is mandatory and the text string is optional.=20=
Neither RFC 3326 nor this draft says that. The formal definition in RFC 3326=
 says both are optional. This draft indicates that both are required.<BR>
<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_7a.74d87318.2fd5b3c1_boundary--


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




From sip-bounces@ietf.org Mon Jun 06 10:58:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfJ3d-0004f5-KT; Mon, 06 Jun 2005 10:58:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfJ3b-0004eu-6o; Mon, 06 Jun 2005 10:58:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07854;
	Mon, 6 Jun 2005 10:58:25 -0400 (EDT)
Received: from syd-iport-1.cisco.com ([64.104.193.196])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfJOP-0002sY-I9; Mon, 06 Jun 2005 11:20:01 -0400
Received: from syd-core-1.cisco.com (64.104.193.198)
	by syd-iport-1.cisco.com with ESMTP; 07 Jun 2005 01:18:37 +1000
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56EvXOd021750; 
	Tue, 7 Jun 2005 00:57:34 +1000 (EST)
Received: from [192.168.1.126] (sjc-vpn5-659.cisco.com [10.21.90.147])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j56EkDJt013718;
	Mon, 6 Jun 2005 07:46:13 -0700
In-Reply-To: <ac.74a88ff8.2fd5b3c2@aol.com>
References: <ac.74a88ff8.2fd5b3c2@aol.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C92ACD85-AF5D-4720-B2B6-A0DB91FE60DE@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David R. Oran" <oran@cisco.com>
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
Date: Mon, 6 Jun 2005 10:57:59 -0400
To: Mpierce1@aol.com
X-Mailer: Apple Mail (2.730)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1118069174.167871"; x:"432200"; a:"rsa-sha1"; b:"nofws:2505";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"W+zRzZ7mAxaw4b1QjF51le6zGH/ax//0f76cCfYxs/HF6QPRjSlHSJy8rJcVx+UAWZ6vbSnh"
	"PNwnSl1YnkZmyw4FAVC28dl3eg247q+paBuEr95mkrkK3AMx0S19f9wh93M52MuUHBCOkJe9WLf"
	"acU0kPUk9twsnecr31DiJg3U=";
	c:"From: =22David R. Oran=22 <oran@cisco.com>";
	c:"Subject: Re: [Sip] Comments on Resource Priority -08 (417)";
	c:"Date: Mon, 6 Jun 2005 10:57:59 -0400"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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 Jun 6, 2005, at 10:12 AM, Mpierce1@aol.com wrote:

> In a message dated 5/29/2005 5:39:51 PM Eastern Daylight Time,  
> hgs@cs.columbia.edu writes:
>
>
>> Note that it says "a subsequent request". This does not imply that  
>> the
>> UAC "redials". It simply tells the UAC and its user what values are
>> permitted for future calls, for example. A user agent could, for
>> example, display such values where known. The user interface is  
>> clearly
>> beyond the scope of the draft.
>>
>> I don't see the need to change this.
>>
>> > Section 4.7.1 2nd paragraph states that "Upon receiving a 417,  
>> the UAC
>> > MAY attempt a subsequent request with the same or different  
>> resource
>> > value." This is contrary to the policies for using priority  
>> values and
>> > should not be mentioned. The user (human) is supposed to select the
>> > correct value before requested a call setup. A UAC must never
>> > automatically attempt another request using a different resource  
>> value
>> > upon receipt of a 417. Of course, a human user may choose to do  
>> whatever
>> > they are authorized to do when trying a new call, but no device  
>> can be
>> > allowed to do this automatically, since it would be violating the
>> > policies for the use of priority levels.
>> >
>>
>
> As I commented, the text clearly indicates that the "UAC" (i.e.,  
> the physical device, not the human) may attempt a subsequent  
> request. There should be no implication that it is permissable for  
> the UAC to do this while text that says that a human user might do  
> this is okay. It should describe only what the UAC "MAY" do in  
> support of this. The current paragraph which says:
>
>    Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
>    MAY attempt a subsequent request with the same or different  
> resource
>    value.  If available, it SHOULD choose authorized resource values
>    from the set of values returned in the 'Accept-Resource-Priority'
>    header field.
>
This seems perfectly reasonable to me.

> Should be changed to:
>
>    Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
>    MAY display to the user a list of the authorized resource values  
> returned in the 'Accept-Resource-Priority'
>    header field. The user may then attempt a subsequent request  
> with the same or different resource
>    value.
>
This is significantly worse, and treads pretty directly into the  
freight train of trying to mandate user interfaces. For example, what  
if the user is blind?

> Then it is clear that it is the human user, not the device, which  
> is making the decision and attempting another call.
>
What if there isn't a human user? What if it's a robot?

I strongly prefer the existing text and frankly don't see what the  
problem is.

> Mike Pierce
> _______________________________________________
> 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 Jun 06 11:10:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfJFF-0006bi-BW; Mon, 06 Jun 2005 11:10:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfJFD-0006bS-BU; Mon, 06 Jun 2005 11:10:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08850;
	Mon, 6 Jun 2005 11:10:25 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfJa5-0003A2-En; Mon, 06 Jun 2005 11:32:01 -0400
Received: from [193.208.138.36] (pc-n36.wlan.inet.fi [193.208.138.36])
	(user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j56FANSq028695
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Mon, 6 Jun 2005 11:10:24 -0400 (EDT)
In-Reply-To: <C92ACD85-AF5D-4720-B2B6-A0DB91FE60DE@cisco.com>
References: <ac.74a88ff8.2fd5b3c2@aol.com>
	<C92ACD85-AF5D-4720-B2B6-A0DB91FE60DE@cisco.com>
Mime-Version: 1.0 (Apple Message framework v728)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <60ED8118-E0EF-457B-B5E0-567E3AD8C028@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
Date: Mon, 6 Jun 2005 11:10:51 -0400
To: "David R. Oran" <oran@cisco.com>
X-Mailer: Apple Mail (2.728)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, iesg@ietf.org, Mpierce1@aol.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

> What if there isn't a human user? What if it's a robot?
>
> I strongly prefer the existing text and frankly don't see what the  
> problem is.
>
>

I'm obviously with David here.

In general, my philosophy is that we should stick, to the extent  
possible, with observable behavior. If an external observer can't  
tell if a human or a robot made the decision to call again, it seems  
futile to try to have the protocol spec mandate human intervention. I  
understand the need to preserve a place for humans in the world, but  
protocol specs are probably the wrong place to prevent human-to-robot  
outsourcing. (Similarities to the Turing test are noted.)

I suspect a better place for this is a requisition document that  
describes how a device should indicate failures and how a user (or  
robot) is allowed to act on these.

Henning



_______________________________________________
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 Jun 06 12:14:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfKF5-0006Kz-Br; Mon, 06 Jun 2005 12:14:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfKF3-0006IQ-7I; Mon, 06 Jun 2005 12:14:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13632;
	Mon, 6 Jun 2005 12:14:18 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfKZu-0004XS-3z; Mon, 06 Jun 2005 12:35:55 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id E9C7C6C01F;
	Mon,  6 Jun 2005 12:14:06 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: <sip@ietf.org>, <iesg@ietf.org>
Subject: RE: [Sip] Comments on Resource Priority -08 (417)
Date: Mon, 6 Jun 2005 12:13:10 -0400
Message-ID: <009601c56ab2$a2b597e0$6a01010a@keywest>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <C92ACD85-AF5D-4720-B2B6-A0DB91FE60DE@cisco.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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

> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> David R. Oran
>
> What if there isn't a human user? What if it's a robot?

In that case, the UA should be making the request at the priority level that
policy sets for that robot.  (If there is no resource shortage, submitting a
request at a high priority has the same effect as submitting it at a low
priority.  If there is a resource shortage, submitting it at a low priority
first is a duplication of effort.  Like in a "Vickrey auction", the optimal
behavior is to submit your first request with the highest priority you're
willing to request.)

> I strongly prefer the existing text and frankly don't see what the
> problem is.

On one hand, as Henning says, this isn't really a protocol question.  On the
other hand, what one says in the protocol documents does influence how
people implement the agents that perform the protocol.  From a protocol
point of view, it is OK to say "If a request is rejected due to inadequate
priority, it is acceptable for the UA to submit it again at a higher
priority".  But in practice, these words will cause some idiot to write a UA
that will automatically rachet a request from "routine" to "priority" and
all the way up to "strategic nuclear attack notice" until it gets accepted.

In think that within the human context of this document, we really want to
have some wording that makes it clear that a UA is not allowed to upgrade a
request "on its own", but only under the direction of a user or an
administrative policy.  But most of the time, that should only happen
because a user normally omits to specify the priority of a high-priority
message because normally there is no resource shortage, and it saves dialing
effort.

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 Jun 06 13:13:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfLAj-00059r-My; Mon, 06 Jun 2005 13:13:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfLAi-00059j-1k; Mon, 06 Jun 2005 13:13:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18385;
	Mon, 6 Jun 2005 13:13:52 -0400 (EDT)
Message-Id: <200506061713.NAA18385@ietf.org>
Received: from athena.hosts.co.uk ([212.84.175.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfLVZ-0005rl-U9; Mon, 06 Jun 2005 13:35:31 -0400
Received: from [69.138.71.61] (helo=albers)
	by athena.hosts.co.uk with esmtpa (Exim 4.44)
	id 1DfLAZ-0002v0-FF; Mon, 06 Jun 2005 18:13:50 +0100
From: "Ken Carlberg" <carlberg@g11.org.uk>
To: "'Dale Worley'" <dworley@pingtel.com>, <sip@ietf.org>, <iesg@ietf.org>
Subject: RE: [Sip] Comments on Resource Priority -08 (417)
Date: Mon, 6 Jun 2005 13:13:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-reply-to: <009601c56ab2$a2b597e0$6a01010a@keywest>
Thread-Index: AcVqsx0cKrYDWLDdRL2g1ztiUhYLkQABfygg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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

 
> > I strongly prefer the existing text and frankly don't see what the
> > problem is.
> 
> On one hand, as Henning says, this isn't really a protocol question.  
> On the other hand, what one says in the protocol documents does 
> influence how people implement the agents that perform the protocol.  
> From a protocol point of view, it is OK to say "If a request is 
> rejected due to inadequate priority, it is acceptable for the UA 
> to submit it again at a higher priority".  But in practice, these 
> words will cause some idiot to write a UA that will automatically 
> rachet a request from "routine" to "priority" and all the way up 
> to "strategic nuclear attack notice" until it gets accepted.

I sympathize with your concern, but there is no assurance that human
discipline (following an organizational policy) will avoid racheting
up the requests.  Systems like AUTODIN, GTPS, etc. were specifically
engineered to take that ability out of the user's hands.  hopefully,
we can do better than those systems in the future.

security credentials, non-user-manipulated distributed policy, and
RFPs are the avenues that will address your concern -- all being 
outside whether new attempts are automated or a function of user
decision.

I'm with Dave and Henning in leaving the text as is.

-ken



_______________________________________________
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 Jun 06 15:36:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfNOV-00063V-51; Mon, 06 Jun 2005 15:36:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfNOT-00063I-3D; Mon, 06 Jun 2005 15:36:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02164;
	Mon, 6 Jun 2005 15:36:15 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-m14.mx.aol.com ([64.12.138.204])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfNjM-0001BF-Dd; Mon, 06 Jun 2005 15:57:53 -0400
Received: from Mpierce1@aol.com
	by imo-m14.mx.aol.com (mail_out_v38_r2.2.) id 7.54.45b4a36e (3924);
	Mon, 6 Jun 2005 15:35:51 -0400 (EDT)
Message-ID: <54.45b4a36e.2fd5ff97@aol.com>
Date: Mon, 6 Jun 2005 15:35:51 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (new labels)
To: hgs@cs.columbia.edu
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Flag: NO
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org, iesg@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="===============1860646732=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============1860646732==
Content-Type: multipart/alternative;
	boundary="part1_54.45b4a36e.2fd5ff97_boundary"


--part1_54.45b4a36e.2fd5ff97_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 5/29/2005 6:08:13 PM Eastern Daylight Time, 
hgs@cs.columbia.edu writes:


> I'm happy to use SHOULD NOT, but I believe the MUST NOT reflected 
> working group consensus, given that specs issues by the IETF have the 
> obligation to avoid interoperability issues. A "SHOULD NOT" would only 
> make sense, I believe, if we were to state when and where such additions 
> are "safe". Just leaving the implementor, IANA and future standardizers 
> with a vague "yellow flag" (SHOULD NOT) seems imprudent.
> 
> Earlier drafts had more unknown-namespace handling, so this might now 
> have become simpler. Adding a new value in a namespace could, however, 
> cause problems, for example, if a proxy ignored the namespace/priority 
> value as being unknown, while a UAS relied on the proxy to have 
> authenticated and authorized the request. That seems brittle.
> 
> In other words, before allowing a change, we need to understand whether 
> this requires special care in IANA registration. If additions are 
> allowed, we may have to change the proxy behavior description to be more 
> picky for known namespaces and unknown labels. This error condition 
> cannot occur at the moment.
> 

Whether or not additions to namespaces are allowed, there must still be the 
same complexity of defining how unknown priority values are handled.

Yes, adding a priority value could cause problems, but that is the concern of 
the organization using that namespace. There can not be an RFC that says the 
US Defense Department can't ever add a 6th precedence level to its DSN. No one 
else should care. (Remember that a 6th level was added to the DRSN somewhat 
recently.)

Mike Pierce

--part1_54.45b4a36e.2fd5ff97_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 5/29/2005 6:08:13 PM Eastern Daylight Time, hgs@cs.columbia.edu=20=
writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">I'm happy to use SHOULD NOT, bu=
t I believe the MUST NOT reflected <BR>
working group consensus, given that specs issues by the IETF have the <BR>
obligation to avoid interoperability issues. A "SHOULD NOT" would only <BR>
make sense, I believe, if we were to state when and where such additions <BR=
>
are "safe". Just leaving the implementor, IANA and future standardizers <BR>
with a vague "yellow flag" (SHOULD NOT) seems imprudent.<BR>
<BR>
Earlier drafts had more unknown-namespace handling, so this might now <BR>
have become simpler. Adding a new value in a namespace could, however, <BR>
cause problems, for example, if a proxy ignored the namespace/priority <BR>
value as being unknown, while a UAS relied on the proxy to have <BR>
authenticated and authorized the request. That seems brittle.<BR>
<BR>
In other words, before allowing a change, we need to understand whether <BR>
this requires special care in IANA registration. If additions are <BR>
allowed, we may have to change the proxy behavior description to be more <BR=
>
picky for known namespaces and unknown labels. This error condition <BR>
cannot occur at the moment.<BR>
</BLOCKQUOTE><BR>
<BR>
Whether or not additions to namespaces are allowed, there must still be the=20=
same complexity of defining how unknown priority values are handled.<BR>
<BR>
Yes, adding a priority value could cause problems, but that is the concern o=
f the organization using that namespace. There can not be an RFC that says t=
he US Defense Department can't ever add a 6th precedence level to its DSN. N=
o one else should care. (Remember that a 6th level was added to the DRSN som=
ewhat recently.)<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_54.45b4a36e.2fd5ff97_boundary--


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




From sip-bounces@ietf.org Mon Jun 06 15:51:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfNdR-0000uF-Rc; Mon, 06 Jun 2005 15:51:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfNdP-0000rm-JL; Mon, 06 Jun 2005 15:51:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04598;
	Mon, 6 Jun 2005 15:51:41 -0400 (EDT)
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.33)
	id 1DfNyH-000212-Dx; Mon, 06 Jun 2005 16:13:20 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 06 Jun 2005 12:51:30 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56JpPbw012110;
	Mon, 6 Jun 2005 12:51:25 -0700 (PDT)
Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com
	[10.32.245.152])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j56JdZ3B016497;
	Mon, 6 Jun 2005 12:39:36 -0700
In-Reply-To: <54.45b4a36e.2fd5ff97@aol.com>
References: <54.45b4a36e.2fd5ff97@aol.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <77F30E97-54DC-42A1-911A-41881E77B7A1@cisco.com>
Content-Transfer-Encoding: 7bit
From: "David R. Oran" <oran@cisco.com>
Subject: Re: [Sip] Comments on Resource Priority -08 (new labels)
Date: Mon, 6 Jun 2005 15:51:21 -0400
To: Mpierce1@aol.com
X-Mailer: Apple Mail (2.730)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1118086777.31083"; x:"432200"; a:"rsa-sha1"; b:"nofws:2233";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"LQAX+sIzJ5zYR/jMwsV1ILsnBnHIJgriwgoLi/g4TkiPFKGj4tEvxIo5faSpqvF5IZBWIxDw"
	"qzvd1uYZcDanbVIwc4pgDryesj5f5DT5pW9omf4SEXGpsUlWUdXXstNVhSh0OYpsl4IB4Vu4fVJ"
	"MBZeX4LPwX7Hltwj0XJ2R9pw=";
	c:"From: =22David R. Oran=22 <oran@cisco.com>";
	c:"Subject: Re: [Sip] Comments on Resource Priority -08 (new labels)"; 
	c:"Date: Mon, 6 Jun 2005 15:51:21 -0400"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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 Jun 6, 2005, at 3:35 PM, Mpierce1@aol.com wrote:

> In a message dated 5/29/2005 6:08:13 PM Eastern Daylight Time,  
> hgs@cs.columbia.edu writes:
>
>
>> I'm happy to use SHOULD NOT, but I believe the MUST NOT reflected
>> working group consensus, given that specs issues by the IETF have the
>> obligation to avoid interoperability issues. A "SHOULD NOT" would  
>> only
>> make sense, I believe, if we were to state when and where such  
>> additions
>> are "safe". Just leaving the implementor, IANA and future  
>> standardizers
>> with a vague "yellow flag" (SHOULD NOT) seems imprudent.
>>
>> Earlier drafts had more unknown-namespace handling, so this might now
>> have become simpler. Adding a new value in a namespace could,  
>> however,
>> cause problems, for example, if a proxy ignored the namespace/ 
>> priority
>> value as being unknown, while a UAS relied on the proxy to have
>> authenticated and authorized the request. That seems brittle.
>>
>> In other words, before allowing a change, we need to understand  
>> whether
>> this requires special care in IANA registration. If additions are
>> allowed, we may have to change the proxy behavior description to  
>> be more
>> picky for known namespaces and unknown labels. This error condition
>> cannot occur at the moment.
>
>
> Whether or not additions to namespaces are allowed, there must  
> still be the same complexity of defining how unknown priority  
> values are handled.
>
> Yes, adding a priority value could cause problems, but that is the  
> concern of the organization using that namespace. There can not be  
> an RFC that says the US Defense Department can't ever add a 6th  
> precedence level to its DSN.
It doesn't say that, I don't think. It says that since the DSN  
namespace is registered with IANA and it has certain properties, If  
those properties change the IANA registration either has to change,  
or at least some IETF-sanctioned expert review should determine if  
the change is safe. Seems perfectly appropriate and such language is  
used for all sorts of IANA registrations by non-IETF groups. There's  
nothing special about the U.S. DoD in that sense.

> No one else should care. (Remember that a 6th level was added to  
> the DRSN somewhat recently.)
>
An implementer building a product engineered to work with multiple  
namespaces MIGHT care, depending on the nature of the change.

Dave.

> Mike Pierce
> _______________________________________________
> 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 Jun 06 18:07:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfPl7-00064C-1t; Mon, 06 Jun 2005 18:07:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfPl4-00063z-VG; Mon, 06 Jun 2005 18:07:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22484;
	Mon, 6 Jun 2005 18:07:44 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DfQ5z-0007nP-Fg; Mon, 06 Jun 2005 18:29:24 -0400
Received: from [64.101.149.222] ([64.101.149.222]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j56MAoqp019334
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 6 Jun 2005 17:10:51 -0500
In-Reply-To: <ac.74a88ff8.2fd5b3c2@aol.com>
References: <ac.74a88ff8.2fd5b3c2@aol.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <238c493aefa441624c098a219c13d60b@softarmor.com>
Content-Transfer-Encoding: quoted-printable
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
Date: Mon, 6 Jun 2005 17:07:38 -0500
To: Mpierce1@aol.com
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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 Jun 6, 2005, at 9:12 AM, Mpierce1@aol.com wrote:
>
>  As I commented, the text clearly indicates that the "UAC" (i.e., the=20=

> physical device, not the human) may attempt a subsequent request.=20
> There should be no implication that it is permissable for the UAC to=20=

> do this while text that says that a human user might do this is okay.=20=

> It should describe only what the UAC "MAY" do in support of this. The=20=

> current paragraph which says:
>
>  =A0=A0 Upon receiving a 417 (Unknown Resource-Priority) response, the =
UAC
>  =A0=A0 MAY attempt a subsequent request with the same or different=20
> resource
>  =A0=A0 value.=A0 If available, it SHOULD choose authorized resource =
values
>  =A0=A0 from the set of values returned in the =
'Accept-Resource-Priority'
>  =A0=A0 header field.
>
>  Should be changed to:
>
>  =A0=A0 Upon receiving a 417 (Unknown Resource-Priority) response, the =
UAC
>  =A0=A0 MAY display to the user a list of the authorized resource =
values=20
> returned in the 'Accept-Resource-Priority'
>  =A0=A0 header field. The user may then attempt a subsequent request =
with=20
> the same or different resource
>  =A0=A0 value.
>
>  Then it is clear that it is the human user, not the device, which is=20=

> making the decision and attempting another call.


If we're talking about an automated UA (for example, the=20
thermal-overload sensor on a nuclear missile), what keeps local policy=20=

(instead of a human user) from making this decision? Is there something=20=

about resource-priority that prevents it from being applicable to=20
automated UAs in all possible priority spaces?

--
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 Mon Jun 06 19:22:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfQvX-0001UK-Ay; Mon, 06 Jun 2005 19:22:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfQvW-0001TW-0N; Mon, 06 Jun 2005 19:22:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29308;
	Mon, 6 Jun 2005 19:22:34 -0400 (EDT)
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.33)
	id 1DfRGR-00015X-6s; Mon, 06 Jun 2005 19:44:16 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 06 Jun 2005 16:22:26 -0700
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j56NMOlq022140;
	Mon, 6 Jun 2005 16:22:24 -0700 (PDT)
Received: from jmpolk-wxp.cisco.com (rtp-vpn1-296.cisco.com [10.82.225.40]) by
	wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with
	ESMTP id QAA08863; Mon, 6 Jun 2005 16:22:18 -0700 (PDT)
Message-Id: <4.3.2.7.2.20050606182015.02fa1b38@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 06 Jun 2005 18:22:13 -0500
To: "Dale Worley" <dworley@pingtel.com>, <sip@ietf.org>, <iesg@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Sip] Comments on Resource Priority -08 (417)
In-Reply-To: <009601c56ab2$a2b597e0$6a01010a@keywest>
References: <C92ACD85-AF5D-4720-B2B6-A0DB91FE60DE@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

At 12:13 PM 6/6/2005 -0400, Dale Worley wrote:
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> > David R. Oran
> >
> > What if there isn't a human user? What if it's a robot?
>
> From a protocol
>point of view, it is OK to say "If a request is rejected due to inadequate
>priority, it is acceptable for the UA to submit it again at a higher
>priority".  But in practice, these words will cause some idiot to write a UA
>that will automatically rachet a request from "routine" to "priority" and
>all the way up to "strategic nuclear attack notice" until it gets accepted.

We can write the protocol spec perfectly that can still result in an idiot 
coding it incorrectly. Specs don't prevent this idiocy from occurring 
(unfortunately)

>Dale


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
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 Jun 06 19:53:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfRP4-0006wX-PZ; Mon, 06 Jun 2005 19:53:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DfRP2-0006w0-T5; Mon, 06 Jun 2005 19:53:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02506;
	Mon, 6 Jun 2005 19:53:07 -0400 (EDT)
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.33)
	id 1DfRjx-00021n-7O; Mon, 06 Jun 2005 20:14:47 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 06 Jun 2005 16:53:05 -0700
X-IronPort-AV: i="3.93,175,1115017200"; 
	d="scan'208"; a="275098655:sNHT64106602"
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56Nr0lw020867;
	Mon, 6 Jun 2005 16:53:00 -0700 (PDT)
Received: from jmpolk-wxp.cisco.com (rcdn-vpn-cluster-1-14.cisco.com
	[10.89.16.14]) by wells.cisco.com (8.8.6
	(PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA07093;
	Mon, 6 Jun 2005 16:53:00 -0700 (PDT)
Message-Id: <4.3.2.7.2.20050606183828.033fd790@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 06 Jun 2005 18:52:47 -0500
To: Mpierce1@aol.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending
	Reason-header for...
In-Reply-To: <7a.74d87318.2fd5b3c1@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
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

comments lower in the message

At 10:12 AM 6/6/2005 -0400, Mpierce1@aol.com wrote:
>In a message dated 6/2/2005 6:10:09 PM Eastern Daylight Time, 
>jmpolk@cisco.com writes:
>
>
>>Because SIP and Q.850 have clearly defined meanings for their cause
>>numbers, and this extension does not, I believe the text string should be
>>maintained through IANA.
>>
>> >From an IANA point of view, at
>>http://www.iana.org/assignments/sip-parameters you can see the text string
>>for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used
>>if the SIP protocol were used in a 3326 Reason header. As IANA is where to
>>first look up these things, I'm not sure why you have an issue with IANA
>>having the same text string explaining what each cause is in the Preemption
>>protocol of the Reason header. If the text string were removed in the IANA
>>registration, there would be no clue there what each cause number meant.
>>
>>This is not the case right now at
>>http://www.iana.org/assignments/sip-parameters for all other SIP parameters.
>>
>>I believe one of your concerns is the user learning/reading the reason in
>>the Reason header within your domain, and I believe that is a local
>>configuration decision.
>>
>>In the document, I do not believe I ever made it a MUST, SHOULD,
>>RECOMMENDED or even a MAY be presented to the user of the UA who is being
>>preempted. I believe this is up to the implementation and local policy to
>>show, or not to show.
>
>I guess I didn't explain my concern well enough.

I think I now understand your original comment differently

>It isn't the issue of notifying the user of something they shouldn't know 
>in our domain. The "Generic Preemption" was added to deal with this.

yes


>I have no problem with the (default) text string being registered with 
>IANA for each defined preemption cause as was done for each SIP response 
>code. The concern is that the IANA considerations section does not make it 
>clear that this is what IANA is expected to do.

fair point - and one I have asked our chair to clarify for the revision of 
this document.


>I don't understand why this is called the "default" text.

well... because the text string is optional, and the text can be something 
other than the exact string listed as the default in this document.

>It would seem that any device could put in any text string it wanted, for 
>example, the same thing in another langauage.

yes, but this is guidance - ala "if you use a text string, we recommend 
this one for consistency"

>I believe RFC 3261 is rather vague on this issue. While the ABNF requires 
>that a Reason-phrase be included in every message and it provides 
>"default" text for each and includes it in the IANA registration, I don't 
>believe it requires that this exact text string be used.

nope it doesn't, you're right, and that is why the word "default" is used 
for guidance reasons. The doc specifies the exact reason for each code, but 
the string can be some variant. I can give more explanation in that part of 
the document to this affect.


>My comment is mostly that there appears to be a conflict between the text 
>in this draft and the formal syntax definition in RFC 3326. I don't know 
>which is correct.

I attempted to take the 3326 text a bit further without overstepping the 
gist of the RFC.

>It would seem to me that, if this new preemption cause is used, that the 
>numeric cause value is mandatory and the text string is optional.

yes, as long as the new cause code act exactly as is specified in that 
extension RFC, and there is a default text string to give *some* guidance 
(which can be omitted or changed per domain).

>Neither RFC 3326 nor this draft says that. The formal definition in RFC 
>3326 says both are optional. This draft indicates that both are required.

I didn't mean to imply the text string is required - I would have used 
SHALL if I meant that. I apologize for the mixed meaning there.

I will clarify that the text string is optional in the document, but a 
guidance/default string is needed for IANA registration. I will add that 
this string can be something other than the exact string given in the doc 
per cause value. Is this agreeable?



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


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
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 Jun 08 19:33:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgA3a-0001yf-Qg; Wed, 08 Jun 2005 19:33:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgA3Y-0001yU-9E; Wed, 08 Jun 2005 19:33:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01872;
	Wed, 8 Jun 2005 19:33:53 -0400 (EDT)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DgAOP-0007d6-1V; Wed, 08 Jun 2005 19:55:30 -0400
Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j58NWIL03078;
	Wed, 8 Jun 2005 16:32:18 -0700 (PDT)
Message-Id: <200506082332.j58NWIL03078@boreas.isi.edu>
To: ietf-announce@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 08 Jun 2005 16:32:18 -0700
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: sip@ietf.org, rfc-editor@rfc-editor.org
Subject: [Sip] RFC 4092 on Usage of the Session Description Protocol (SDP)
	Alternative Network Address Types (ANAT) Semantics in the
	Session Initiation Protocol (SIP)
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 Request for Comments is now available in online RFC libraries.


        RFC 4092

        Title:      Usage of the Session Description Protocol (SDP)
                    Alternative Network Address Types (ANAT) Semantics
                    in the Session Initiation Protocol (SIP)
        Author(s):  G. Camarillo, J. Rosenberg
        Status:     Standards Track
        Date:       June 2005
        Mailbox:    Gonzalo.Camarillo@ericsson.com, jdrosen@cisco.com
        Pages:      6
        Characters: 12624
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sip-anat-usage-00.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4092.txt


This document describes how to use the Alternative Network Address
Types (ANAT) semantics of the Session Description Protocol (SDP)
grouping framework in SIP.  In particular, we define the sdp-anat
SIP option-tag.  This SIP option-tag ensures that SDP session
descriptions that use ANAT are only handled by SIP entities with ANAT
support.  To justify the need for such a SIP option-tag, we describe
what could possibly happen if an ANAT-unaware SIP entity tried to
handle media lines grouped with ANAT.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <050608163052.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc4092

--OtherAccess
Content-Type: Message/External-body; name="rfc4092.txt"; site="ftp.isi.edu";
	access-type="anon-ftp"; directory="in-notes"

Content-Type: text/plain
Content-ID: <050608163052.RFC@RFC-EDITOR.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 Jun 09 10:19:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNse-0002Ph-Ne; Thu, 09 Jun 2005 10:19:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNsc-0002PR-6Z; Thu, 09 Jun 2005 10:19:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05591;
	Thu, 9 Jun 2005 10:19:32 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-m14.mx.aol.com ([64.12.138.204])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DgOE4-0005p1-OU; Thu, 09 Jun 2005 10:41:46 -0400
Received: from Mpierce1@aol.com
	by imo-m14.mx.aol.com (mail_out_v38_r1.7.) id d.1eb.3cb332c5 (4552);
	Thu, 9 Jun 2005 10:19:08 -0400 (EDT)
Message-ID: <1eb.3cb332c5.2fd9a9dc@aol.com>
Date: Thu, 9 Jun 2005 10:19:08 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
To: dean.willis@softarmor.com
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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="===============0150410498=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============0150410498==
Content-Type: multipart/alternative;
	boundary="part1_1eb.3cb332c5.2fd9a9dc_boundary"


--part1_1eb.3cb332c5.2fd9a9dc_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/6/2005 6:07:42 PM Eastern Daylight Time, 
dean.willis@softarmor.com writes:


> If we're talking about an automated UA (for example, the 
> thermal-overload sensor on a nuclear missile), what keeps local policy 
> (instead of a human user) from making this decision? Is there something 
> about resource-priority that prevents it from being applicable to 
> automated UAs in all possible priority spaces?
> 

In every use of this capability, the first session setup attempt must use the 
correct namespace and priority level for the attempted session. There is 
never a need for the UA to try again with different values when the first attempt 
fails. It could retry with the same values (like an auto redial on a FAX 
machine).

Mike Pierce

--part1_1eb.3cb332c5.2fd9a9dc_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 6/6/2005 6:07:42 PM Eastern Daylight Time, dean.willis@softarmor=
.com writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">If we're talking about an autom=
ated UA (for example, the <BR>
thermal-overload sensor on a nuclear missile), what keeps local policy <BR>
(instead of a human user) from making this decision? Is there something <BR>
about resource-priority that prevents it from being applicable to <BR>
automated UAs in all possible priority spaces?<BR>
</BLOCKQUOTE><BR>
<BR>
In every use of this capability, the first session setup attempt must use th=
e correct namespace and priority level for the attempted session. There is n=
ever a need for the UA to try again with different values when the first att=
empt fails. It could retry with the same values (like an auto redial on a FA=
X machine).<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_1eb.3cb332c5.2fd9a9dc_boundary--


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




From sip-bounces@ietf.org Thu Jun 09 10:20:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNtU-0002hF-RB; Thu, 09 Jun 2005 10:20:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNtR-0002eM-HL; Thu, 09 Jun 2005 10:20:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05696;
	Thu, 9 Jun 2005 10:20:23 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-d05.mx.aol.com ([205.188.157.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DgOEu-0005w6-4x; Thu, 09 Jun 2005 10:42:37 -0400
Received: from Mpierce1@aol.com
	by imo-d05.mx.aol.com (mail_out_v38_r1.7.) id c.195.40dc4a45 (4552);
	Thu, 9 Jun 2005 10:19:07 -0400 (EDT)
Message-ID: <195.40dc4a45.2fd9a9da@aol.com>
Date: Thu, 9 Jun 2005 10:19:06 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (417)
To: oran@cisco.com
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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="===============1743378584=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============1743378584==
Content-Type: multipart/alternative;
	boundary="part1_195.40dc4a45.2fd9a9da_boundary"


--part1_195.40dc4a45.2fd9a9da_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/6/2005 11:02:18 AM Eastern Daylight Time, oran@cisco.com 
writes:


> > Should be changed to:
> >
> >    Upon receiving a 417 (Unknown Resource-Priority) response, the UAC
> >    MAY display to the user a list of the authorized resource values  
> > returned in the 'Accept-Resource-Priority'
> >    header field. The user may then attempt a subsequent request  
> > with the same or different resource
> >    value.
> >
> This is significantly worse, and treads pretty directly into the  
> freight train of trying to mandate user interfaces. For example, what  
> if the user is blind?
> 
> > Then it is clear that it is the human user, not the device, which  
> > is making the decision and attempting another call.
> >
> What if there isn't a human user? What if it's a robot?
> 
> I strongly prefer the existing text and frankly don't see what the  
> problem is.
> 

I thought I had explained the problem with the current text sufficiently. 
Obviously, if a blind person using a terminal, the reference above to "display" 
is understood to mean some means appropriate to a blind person.
I don't think we're concerned with "robots". If you mean a software 
application, etc. resident in the same physical device as the UA, then my description 
of the problem remains. All session setup attempts must use the correct 
namespace/priority the first time. There is no case in which a device can decide to 
use a different value if the first attempt fails.

If it helps. the word human can be left out of my suggested text above.


In a message dated 6/6/2005 11:12:45 AM Eastern Daylight Time, 
hgs@cs.columbia.edu writes:


> In general, my philosophy is that we should stick, to the extent  
> possible, with observable behavior. If an external observer can't  
> tell if a human or a robot made the decision to call again, it seems  
> futile to try to have the protocol spec mandate human intervention. I  
> understand the need to preserve a place for humans in the world, but  
> protocol specs are probably the wrong place to prevent human-to-robot  
> outsourcing. (Similarities to the Turing test are noted.)
> 
> I suspect a better place for this is a requisition document that  
> describes how a device should indicate failures and how a user (or  
> robot) is allowed to act on these.
> 


I believe that the above is exactly what my suggested text above did.

Mike Pierce

--part1_195.40dc4a45.2fd9a9da_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 6/6/2005 11:02:18 AM Eastern Daylight Time, oran@cisco.com write=
s:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&gt; Should be changed to:<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp; Upon receiving a 417 (Unknown Resource-Priority) resp=
onse, the UAC<BR>
&gt;&nbsp;&nbsp;&nbsp; MAY display to the user a list of the authorized reso=
urce values&nbsp; <BR>
&gt; returned in the 'Accept-Resource-Priority'<BR>
&gt;&nbsp;&nbsp;&nbsp; header field. The user may then attempt a subsequent=20=
request&nbsp; <BR>
&gt; with the same or different resource<BR>
&gt;&nbsp;&nbsp;&nbsp; value.<BR>
&gt;<BR>
This is significantly worse, and treads pretty directly into the&nbsp; <BR>
freight train of trying to mandate user interfaces. For example, what&nbsp;=20=
<BR>
if the user is blind?<BR>
<BR>
&gt; Then it is clear that it is the human user, not the device, which&nbsp;=
 <BR>
&gt; is making the decision and attempting another call.<BR>
&gt;<BR>
What if there isn't a human user? What if it's a robot?<BR>
<BR>
I strongly prefer the existing text and frankly don't see what the&nbsp; <BR=
>
problem is.<BR>
</BLOCKQUOTE><BR>
<BR>
I thought I had explained the problem with the current text sufficiently. Ob=
viously, if a blind person using a terminal, the reference above to "display=
" is understood to mean some means appropriate to a blind person.<BR>
I don't think we're concerned with "robots". If you mean a software applicat=
ion, etc. resident in the same physical device as the UA, then my descriptio=
n of the problem remains. All session setup attempts must use the correct na=
mespace/priority the first time. There is no case in which a device can deci=
de to use a different value if the first attempt fails.<BR>
<BR>
If it helps. the word human can be left out of my suggested text above.<BR>
<BR>
<BR>
In a message dated 6/6/2005 11:12:45 AM Eastern Daylight Time, hgs@cs.columb=
ia.edu writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">In general, my philosophy is th=
at we should stick, to the extent&nbsp; <BR>
possible, with observable behavior. If an external observer can't&nbsp; <BR>
tell if a human or a robot made the decision to call again, it seems&nbsp; <=
BR>
futile to try to have the protocol spec mandate human intervention. I&nbsp;=20=
<BR>
understand the need to preserve a place for humans in the world, but&nbsp; <=
BR>
protocol specs are probably the wrong place to prevent human-to-robot&nbsp;=20=
<BR>
outsourcing. (Similarities to the Turing test are noted.)<BR>
<BR>
I suspect a better place for this is a requisition document that&nbsp; <BR>
describes how a device should indicate failures and how a user (or&nbsp; <BR=
>
robot) is allowed to act on these.<BR>
</BLOCKQUOTE><BR>
<BR>
<BR>
I believe that the above is exactly what my suggested text above did.<BR>
<BR>
Mike Pierce<BR>
</FONT></HTML>
--part1_195.40dc4a45.2fd9a9da_boundary--


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




From sip-bounces@ietf.org Thu Jun 09 10:20:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNtg-0002ox-Rk; Thu, 09 Jun 2005 10:20:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgNte-0002o1-RO; Thu, 09 Jun 2005 10:20:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAB05709;
	Thu, 9 Jun 2005 10:20:34 -0400 (EDT)
From: Mpierce1@aol.com
Received: from imo-d04.mx.aol.com ([205.188.157.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DgOF2-0005wD-Vs; Thu, 09 Jun 2005 10:42:48 -0400
Received: from Mpierce1@aol.com
	by imo-d04.mx.aol.com (mail_out_v38_r1.7.) id c.ee.14d7ffc5 (4552);
	Thu, 9 Jun 2005 10:19:07 -0400 (EDT)
Message-ID: <ee.14d7ffc5.2fd9a9db@aol.com>
Date: Thu, 9 Jun 2005 10:19:07 EDT
Subject: Re: [Sip] Comments on Resource Priority -08 (new labels)
To: oran@cisco.com
MIME-Version: 1.0
X-Mailer: 7.0 for Windows sub 10689
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: sip@ietf.org, iesg@ietf.org, hgs@cs.columbia.edu
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="===============1743307984=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


--===============1743307984==
Content-Type: multipart/alternative;
	boundary="part1_ee.14d7ffc5.2fd9a9db_boundary"


--part1_ee.14d7ffc5.2fd9a9db_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 6/6/2005 3:51:56 PM Eastern Daylight Time, oran@cisco.com 
writes:


> It doesn't say that, I don't think. It says that since the DSN  
> namespace is registered with IANA and it has certain properties, If  
> those properties change the IANA registration either has to change,  
> or at least some IETF-sanctioned expert review should determine if  
> the change is safe. Seems perfectly appropriate and such language is  
> used for all sorts of IANA registrations by non-IETF groups. There's  
> nothing special about the U.S. DoD in that sense.
> 

I would be happy with text that says this. The current text says 

      New priority-values
      MUST NOT be added to any previously IANA-registered list
      associated with a particular namespace,

Mike Pierce

--part1_ee.14d7ffc5.2fd9a9db_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10>In a me=
ssage dated 6/6/2005 3:51:56 PM Eastern Daylight Time, oran@cisco.com writes=
:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">It doesn't say that, I don't th=
ink. It says that since the DSN&nbsp; <BR>
namespace is registered with IANA and it has certain properties, If&nbsp; <B=
R>
those properties change the IANA registration either has to change,&nbsp; <B=
R>
or at least some IETF-sanctioned expert review should determine if&nbsp; <BR=
>
the change is safe. Seems perfectly appropriate and such language is&nbsp; <=
BR>
used for all sorts of IANA registrations by non-IETF groups. There's&nbsp; <=
BR>
nothing special about the U.S. DoD in that sense.<BR>
</BLOCKQUOTE><BR>
<BR>
I would be happy with text that says this. The current text says <BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; New priority-values<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST NOT be added to any previously IANA-regi=
stered list<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; associated with a particular namespace,<BR>
<BR>
Mike Pierce</FONT></HTML>

--part1_ee.14d7ffc5.2fd9a9db_boundary--


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




From sip-bounces@ietf.org Thu Jun 09 10:34:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgO6r-0006u4-GD; Thu, 09 Jun 2005 10:34:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgO6q-0006tz-CQ
	for sip@megatron.ietf.org; Thu, 09 Jun 2005 10:34:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07054
	for <sip@ietf.org>; Thu, 9 Jun 2005 10:34:14 -0400 (EDT)
Received: from royk.itea.ntnu.no ([129.241.190.230])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgOSJ-0006YZ-V6
	for sip@ietf.org; Thu, 09 Jun 2005 10:56:28 -0400
Received: from localhost (localhost [127.0.0.1])
	by royk.itea.ntnu.no (Postfix) with ESMTP id 6110366CDB
	for <sip@ietf.org>; Thu,  9 Jun 2005 16:34:14 +0200 (CEST)
Received: from [129.241.222.31] (vpn-22231.vpn-s.ntnu.no [129.241.222.31])
	by royk.itea.ntnu.no (Postfix) with ESMTP
	for <sip@ietf.org>; Thu,  9 Jun 2005 16:34:12 +0200 (CEST)
Message-ID: <42A85367.6080508@stud.ntnu.no>
Date: Thu, 09 Jun 2005 16:34:15 +0200
From: =?ISO-8859-1?Q?Egil_=D8sthus?= <egilconr@stud.ntnu.no>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no.
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] SIP and distribution of context information
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: egilconr@gmail.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

Hi,

I'm looking into ways to distribute general context information, and=20
have some questions connected to SIP Events.

SIMPLE is used to transport presence information to a watcher. In the=20
introduction of RFC 3856 it is argued why SIP Events is an appropriate=20
way to distribute presence information. I agree in the arguments given=20
in the RFC, but there are some details that still is not clear to me.=20
Presence status is a special kind of the more general Context=20
Information. What I'm uncertain about, is whether SIP Events should be=20
used for distribution of other kinds of context information as well?=20
Arguments that support this approach is that it is convenient to have=20
only one protocol taking care of distributing all sorts of context=20
information (e.g. Temperature, Light level, geographical location and so=20
on). Also, the arguements given why SIP Events is a proper way for=20
presence info distribution goes for many of the other kinds of context=20
information. Technically speaking, it is not any problem using SIP=20
Events for this matter, what I belive is the problem is that this=20
approach is in conflict with the "Guidelines for Authors of Extensions=20
to the Session Initiation Protocol (SIP)" internet draft=20
(http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-09.txt).=20
Section 3.1 defines SIPs solution space, and I have a hard time=20
convincing myself that distribution of general context information is=20
within the solution space of SIP, in other words SIP is not an=20
appropriate protocol. Then again, it seems kind of strange to me to=20
define one protocol per each kind of context information type. (e.g. one=20
for geographical location, one for temperature and so on). Should SIP=20
Events  be used to distribute all kinds of context information (i.e.=20
breaking the sip guidelines draft)? Should presence be distributed by=20
SIMPLE, and other kinds of context information distributed by other=20
protocols, i.e. creating a great number of context distribution=20
protocols? Or should a general protocol for context information be=20
designed, taking care of all sorts of context information including=20
presence status, i.e.dropping SIMPLE?

Any comments helping to clarify this matter is highly appreciated!

Cheers,
Egil C. =D8sthus

_______________________________________________
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 Jun 09 11:19:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgOob-0007dX-V9; Thu, 09 Jun 2005 11:19:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOoa-0007dK-3G
	for sip@megatron.ietf.org; Thu, 09 Jun 2005 11:19:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11250
	for <sip@ietf.org>; Thu, 9 Jun 2005 11:19:25 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgPA3-00081q-8t
	for sip@ietf.org; Thu, 09 Jun 2005 11:41:40 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id DA6F46C023
	for <sip@ietf.org>; Thu,  9 Jun 2005 11:19:19 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: <sip@ietf.org>
Subject: RE: [Sip] SIP and distribution of context information
Date: Thu, 9 Jun 2005 11:18:12 -0400
Message-ID: <005201c56d06$740679e0$6a01010a@keywest>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <42A85367.6080508@stud.ntnu.no>
Importance: Normal
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: quoted-printable
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: Egil =D8sthus
>
> Presence status is a special kind of the more general Context
> Information. What I'm uncertain about, is whether SIP Events
> should be
> used for distribution of other kinds of context information as well?
> Arguments that support this approach is that it is convenient to have
> only one protocol taking care of distributing all sorts of context
> information (e.g. Temperature, Light level, geographical
> location and so
> on).

I would think the question is the context of the context information, so =
to
speak.  If the purpose is to present, display, or distribute information
about one person/agent so that another person/agent can decide whether it
wants to communicate with the first one, then it would seem to be reasona=
ble
to use SIP events to distribute it.

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 Jun 09 11:49:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgPHc-0006b8-ML; Thu, 09 Jun 2005 11:49:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPHa-0006b2-Gp
	for sip@megatron.ietf.org; Thu, 09 Jun 2005 11:49:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13926
	for <sip@ietf.org>; Thu, 9 Jun 2005 11:49:23 -0400 (EDT)
Received: from oak.research.panasonic.com ([150.169.1.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgPd3-0000YY-Ok
	for sip@ietf.org; Thu, 09 Jun 2005 12:11:39 -0400
Received: from redwood.research.panasonic.com (www.research.panasonic.com
	[150.169.3.2])
	by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j59FnCwA011368;
	Thu, 9 Jun 2005 11:49:12 -0400
Received: from redwood.research.panasonic.com (birch.research.pansonic.com
	[150.169.3.2])
	by testing.research.panasonic.com (Postfix) with ESMTP id 279A41E81B2; 
	Thu,  9 Jun 2005 11:40:49 -0400 (EDT)
Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251])by 
	redwood.research.panasonic.com (Postfix) with SMTP id 1D0481E8196;
	Thu,  9 Jun 2005 11:40:49 -0400 (EDT)
Message-ID: <00c901c56d0b$9fb479c0$01000001@Brijesh2K>
From: "Brijesh Kumar" <kumarb@research.panasonic.com>
To: "Dale Worley" <dworley@pingtel.com>, <sip@ietf.org>
References: <005201c56d06$740679e0$6a01010a@keywest>
Subject: Re: [Sip] SIP and distribution of context information
Date: Thu, 9 Jun 2005 11:55:14 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset=iso-8859-1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-imss-version: 2.8
X-imss-result: Passed
X-imss-scores: Clean:99.90000 C:15 M:0 S:5 R:5
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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




----- Original Message -----=20
From: "Dale Worley" <dworley@pingtel.com>
To: <sip@ietf.org>
Sent: Thursday, June 09, 2005 11:18 AM
Subject: RE: [Sip] SIP and distribution of context information


>> From: Egil =D8sthus
>>
> >Presence status is a special kind of the more general Context
> >Information. What I'm uncertain about, is whether SIP Events
> >should be
> >used for distribution of other kinds of context information as well?
> >Arguments that support this approach is that it is convenient to have
> >only one protocol taking care of distributing all sorts of context
> >information (e.g. Temperature, Light level, geographical
> >location and so
> > on).

>I would think the question is the context of the context information, so=
 to
>speak.  If the purpose is to present, display, or distribute information
>about one person/agent so that another person/agent can decide whether i=
t
>wants to communicate with the first one, then it would seem to be
reasonable
> to use SIP events to distribute it.

>Dale

Hi Dale and Egil:

Yes, you are right.

We have taken the similar approach to monitor device status and
learn about about device context information in our draft: A Session
Initiation Protocol (SIP) Event Package for Device Information
(http://ietfreport.isoc.org/idref/draft-rahman-sipping-device-info/).
A revised version will be submitted to sipping group in a few days.

We have used a event package mechanism (device-info) in the above draft,
however during presentation of the draft to Sipping group in IETF in
Washington
DC, we  mentioned in the future we will introduce the idea of device
presence to
learn the device status and the context in future revision of the draft.


regards,

--brijesh


_______________________________________________
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 Jun 09 13:52:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgRCo-0000Qu-Ff; Thu, 09 Jun 2005 13:52:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgRCm-0000Qh-N9; Thu, 09 Jun 2005 13:52:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28607;
	Thu, 9 Jun 2005 13:52:33 -0400 (EDT)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DgRYE-0007M8-No; Thu, 09 Jun 2005 14:14:48 -0400
Received: from [192.168.1.56] ([212.122.58.178]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j59HpOZ7022703
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 9 Jun 2005 13:51:25 -0400 (EDT)
In-Reply-To: <ee.14d7ffc5.2fd9a9db@aol.com>
References: <ee.14d7ffc5.2fd9a9db@aol.com>
Mime-Version: 1.0 (Apple Message framework v728)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <22579E99-26CD-4436-A966-D2D8CE6B0CF0@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] Comments on Resource Priority -08 (new labels)
Date: Thu, 9 Jun 2005 13:51:56 -0400
To: Mpierce1@aol.com
X-Mailer: Apple Mail (2.728)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, oran@cisco.com, iesg@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 plan to revert to SHOULD NOT unless somebody raises issues that  
force a MUST NOT. I think such addition is sufficiently unlikely that  
we cannot anticipate the concrete cases that may or may not arise and  
their issues. The review process required for registration would then  
be able to illuminate any interoperability problems.

On Jun 9, 2005, at 10:19 AM, Mpierce1@aol.com wrote:

> In a message dated 6/6/2005 3:51:56 PM Eastern Daylight Time,  
> oran@cisco.com writes:
>
>
>> It doesn't say that, I don't think. It says that since the DSN
>> namespace is registered with IANA and it has certain properties, If
>> those properties change the IANA registration either has to change,
>> or at least some IETF-sanctioned expert review should determine if
>> the change is safe. Seems perfectly appropriate and such language is
>> used for all sorts of IANA registrations by non-IETF groups. There's
>> nothing special about the U.S. DoD in that sense.
>
>
> I would be happy with text that says this. The current text says
>
>       New priority-values
>       MUST NOT be added to any previously IANA-registered list
>       associated with a particular namespace,
>
> Mike Pierce


_______________________________________________
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 Jun 09 13:58:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgRIF-0001Xb-Ot; Thu, 09 Jun 2005 13:58:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRIE-0001Vo-GV
	for sip@megatron.ietf.org; Thu, 09 Jun 2005 13:58:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29236
	for <sip@ietf.org>; Thu, 9 Jun 2005 13:58:13 -0400 (EDT)
Received: from merke.itea.ntnu.no ([129.241.7.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgRdk-0000LG-2o
	for sip@ietf.org; Thu, 09 Jun 2005 14:20:28 -0400
Received: from localhost (localhost [127.0.0.1])
	by merke.itea.ntnu.no (Postfix) with ESMTP id 458E513C447;
	Thu,  9 Jun 2005 19:58:07 +0200 (CEST)
Received: from [129.241.222.31] (vpn-22231.vpn-s.ntnu.no [129.241.222.31])
	by merke.itea.ntnu.no (Postfix) with ESMTP;
	Thu,  9 Jun 2005 19:58:06 +0200 (CEST)
Message-ID: <42A88331.3070009@stud.ntnu.no>
Date: Thu, 09 Jun 2005 19:58:09 +0200
From: =?ISO-8859-1?Q?Egil_=D8sthus?= <egilconr@stud.ntnu.no>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dale Worley <dworley@pingtel.com>
Subject: Re: [Sip] SIP and distribution of context information
References: <005201c56d06$740679e0$6a01010a@keywest>
In-Reply-To: <005201c56d06$740679e0$6a01010a@keywest>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no.
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: egilconr@gmail.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


>I would think the question is the context of the context information, so=
 to
>speak.  If the purpose is to present, display, or distribute information
>about one person/agent so that another person/agent can decide whether i=
t
>wants to communicate with the first one, then it would seem to be reason=
able
>to use SIP events to distribute it.
> =20
>
I totally agree about this, but I belive that context information could=20
be used to other applications than those of (human) communication.=20
Examples could be various tourist guides (using geograhical location for=20
information delivery). For this application I find it hard to argue for=20
using SIP, on the other hand in certain cases SIP applications could=20
benefint for using location information (for instance a intelligent=20
screening service, rejecting all work related calls when I'm at home).=20
Should the same information (in this case the geographical location) be=20
carried by to different protocols (requiring two or more implemented=20
protocol stacks at the sensor), or should the same protocol be used=20
(i.e. should each application use a context protocol in addition to=20
other needed protocols)?

Cheers,
Egil =D8sthus


_______________________________________________
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 Jun 10 05:15:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgfbV-0001h7-Lv; Fri, 10 Jun 2005 05:15:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgfbR-0001fl-8O
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 05:15:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27085
	for <sip@ietf.org>; Fri, 10 Jun 2005 05:14:58 -0400 (EDT)
Received: from mxs2.siemens.at ([194.138.12.133])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgfwm-0004ep-Ef
	for sip@ietf.org; Fri, 10 Jun 2005 05:37:23 -0400
Received: from vies1k7x.sie.siemens.at ([158.226.129.83])
	by mxs2.siemens.at  with ESMTP id j5A9AJ8T032043
	for <sip@ietf.org>; Fri, 10 Jun 2005 11:10:19 +0200
Received: from vies141a.sie.siemens.at ([158.226.129.98])
	by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id
	j5A9EJET024012 for <sip@ietf.org>; Fri, 10 Jun 2005 11:14:19 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2655.55)
	id <M4N7VVD3>; Fri, 10 Jun 2005 11:16:01 +0200
Message-ID: <C10F60785AE7D211B6E00800060DA3910AB3B111@vieg128a.gud.siemens.at>
From: Horvath Ernst <ernst.horvath@siemens.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>, "'fluffy@cisco.com'"
	<fluffy@cisco.com>
Date: Fri, 10 Jun 2005 11:13:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
X-Spam-Score: 2.0 (++)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [Sip] Ambiguous response code in "draft-ietf-sip-identity-05"
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="===============0813929106=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0813929106==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C56D9C.A2666EF8"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C56D9C.A2666EF8
Content-Type: text/plain

Jon, Cullen,
 
in section 7 the response code 428 is used with two different meanings:
 
428 'Use Identity Header' - this is in line with section 15.2, IANA
considerations;
 
but 'step 3' in section 7 says
 
... then a 428 'Invalid Identity Header' response MUST be ...

 

I assume "428" is a typo in the latter case, but a response 'Invalid
Identity Header' is not defined anywhere else in the document. 

 

Can you please clarify?

 

 

Thanks

 

Ernst Horvath

Siemens AG


------_=_NextPart_001_01C56D9C.A2666EF8
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1pbm9yIGNvbW1lbnRz
IG9uICJkcmFmdC1pZXRmLXNpcC1pZGVudGl0eS0wNSI8L1RJVExFPg0KDQo8TUVUQSBjb250ZW50
PSJNU0hUTUwgNi4wMC4yODAwLjE0OTgiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0K
PERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g
DQpjbGFzcz00OTAzMjU5MDgtMTAwNjIwMDU+Sm9uLCBDdWxsZW4sPC9TUEFOPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxT
UEFOIA0KY2xhc3M9NDkwMzI1OTA4LTEwMDYyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB
TiANCmNsYXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT5pbiBzZWN0aW9uIDcgdGhlIHJlc3BvbnNlIGNv
ZGUgNDI4IGlzIHVzZWQgd2l0aCB0d28gDQpkaWZmZXJlbnQgbWVhbmluZ3M6PC9TUEFOPjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB
TiANCmNsYXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz00OTAzMjU5MDgtMTAwNjIw
MDU+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIg
TmV3JzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGkt
bGFuZ3VhZ2U6IEFSLVNBIj40MjggDQonVXNlIElkZW50aXR5IEhlYWRlcicgPEZPTlQgY29sb3I9
IzAwMDBmZj4tIHRoaXMgaXMgaW4gbGluZSB3aXRoIHNlY3Rpb24gMTUuMiwgDQpJQU5BIGNvbnNp
ZGVyYXRpb25zOzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg
ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NDkwMzI1OTA4LTEwMDYyMDA1PjxTUEFOIA0K
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6
IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBB
Ui1TQSI+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9
QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NDkwMzI1OTA4LTEwMDYyMDA1
PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2kt
bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxh
bmd1YWdlOiBBUi1TQSI+YnV0IA0KJ3N0ZXAgMycgaW4gc2VjdGlvbiA3IHNheXM8L1NQQU4+PC9T
UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp
emU9Mj48U1BBTiBjbGFzcz00OTAzMjU5MDgtMTAwNjIwMDU+PFNQQU4gDQpzdHlsZT0iRk9OVC1T
SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m
YXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L1NQQU4+
PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBj
bGFzcz00OTAzMjU5MDgtMTAwNjIwMDU+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1l
cyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1
YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj4NCjxQIGNsYXNzPU1zb1BsYWlu
VGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gDQpjbGFzcz00OTAzMjU5MDgt
MTAwNjIwMDU+Li4uIDwvU1BBTj50aGVuIGEgNDI4ICdJbnZhbGlkIElkZW50aXR5IEhlYWRlcicg
DQpyZXNwb25zZSBNVVNUIGJlPFNQQU4gY2xhc3M9NDkwMzI1OTA4LTEwMDYyMDA1PiAuLi48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiANCmNsYXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48L1NQQU4+Jm5ic3A7PC9QPg0KPFAg
Y2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiANCmNs
YXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+PEZP
TlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+SSBhc3N1bWU8L0ZPTlQ+IDxGT05UIGZhY2U9IkNvdXJp
ZXIgTmV3Ij4iNDI4IiBpcyBhIHR5cG8gaW4gDQp0aGUgbGF0dGVyIGNhc2UsIGJ1dCBhIHJlc3Bv
bnNlIDxGT05UIGNvbG9yPSMwMDAwMDA+J0ludmFsaWQgSWRlbnRpdHkgSGVhZGVyJyANCjxGT05U
IGNvbG9yPSMwMDAwZmY+aXMgbm90PC9GT05UPiA8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDBmZj5k
ZWZpbmVkIGFueXdoZXJlIA0KZWxzZSBpbiB0aGUgZG9jdW1lbnQuIDwvRk9OVD48L0ZPTlQ+PC9G
T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjxTUEFOIA0KY2xhc3M9NDkwMzI1OTA4LTEwMDYyMDA1PjxGT05UIGZhY2U9QXJp
YWwgY29sb3I9IzAwMDBmZj48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij48Rk9OVCBjb2xvcj0j
MDAwMGZmPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBjbGFzcz1N
c29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIA0KY2xhc3M9NDkw
MzI1OTA4LTEwMDYyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48Rk9OVCANCmZh
Y2U9IkNvdXJpZXIgTmV3Ij48Rk9OVCBjb2xvcj0jMDAwMGZmPkNhbiB5b3UgcGxlYXNlIA0KY2xh
cmlmeT88L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5U
ZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiANCmNsYXNzPTQ5MDMyNTkwOC0x
MDA2MjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPg0KPFAg
Y2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiANCmNs
YXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+
Jm5ic3A7PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20g
MHB0Ij48U1BBTiANCmNsYXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZm
PlRoYW5rczwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJN
QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiANCmNsYXNzPTQ5MDMyNTkwOC0xMDA2MjAwNT48Rk9O
VCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9QPg0KPFAgY2xhc3M9TXNvUGxh
aW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiANCmNsYXNzPTQ5MDMyNTkw
OC0xMDA2MjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZmPkVybnN0IEhvcnZhdGg8L0ZPTlQ+PC9TUEFO
PjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+
PFNQQU4gDQpjbGFzcz00OTAzMjU5MDgtMTAwNjIwMDU+PEZPTlQgY29sb3I9IzAwMDBmZj5TaWVt
ZW5zIA0KQUc8L0ZPTlQ+PC9TUEFOPjwvUD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0RJVj48L0JP
RFk+PC9IVE1MPg0K

------_=_NextPart_001_01C56D9C.A2666EF8--


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




From sip-bounces@ietf.org Fri Jun 10 07:44:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dghvp-0008So-Ky; Fri, 10 Jun 2005 07:44:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dghvo-0008Sg-7f
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 07:44:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11405
	for <sip@ietf.org>; Fri, 10 Jun 2005 07:44:10 -0400 (EDT)
Received: from p04.nexlink.net ([80.86.195.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgiHP-0005Us-CZ
	for sip@ietf.org; Fri, 10 Jun 2005 08:06:35 -0400
Received: (qmail 25021 invoked from network); 10 Jun 2005 11:40:26 -0000
Received: from localhost (127.0.0.1)
	by localhost with SMTP; 10 Jun 2005 11:40:25 -0000
Received: from d213-103-44-149.cust.tele2.fr (d213-103-44-149.cust.tele2.fr
	[213.103.44.149]) by webmail.tech-invite.com (IMP) with HTTP 
	for <joel.repiquet@tech-invite.com@localhost>;
	Fri, 10 Jun 2005 13:40:25 +0200
Message-ID: <1118403625.42a97c29e5fe5@webmail.tech-invite.com>
Date: Fri, 10 Jun 2005 13:40:25 +0200
From: =?iso-8859-1?b?Sm/rbA==?= Repiquet <joel.repiquet@tech-invite.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.3
X-Originating-IP: 213.103.44.149
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 8bit
Subject: [Sip] SIP parameters at IANA
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,

SIP Parameters at IANA for session timers in SIP (RFC4028) are still registered
with "RFC-ietf-sip-session-timer-15.txt". Could you update it? It will be
easier to see the parameters related to drafts.

Thanks!



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


_______________________________________________
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 Jun 10 08:56:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dgj3I-0006jG-BE; Fri, 10 Jun 2005 08:56:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgj3F-0006i7-7X
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 08:55:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17059
	for <sip@ietf.org>; Fri, 10 Jun 2005 08:55:55 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjOt-00050f-JF
	for sip@ietf.org; Fri, 10 Jun 2005 09:18:20 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by sj-iport-4.cisco.com with ESMTP; 10 Jun 2005 05:55:46 -0700
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 j5ACt35Q027357; 
	Fri, 10 Jun 2005 08:55:43 -0400 (EDT)
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, 10 Jun 2005 08:54:49 -0400
Received: from [192.168.1.110] ([10.86.240.168]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 10 Jun 2005 08:54:48 -0400
Message-ID: <42A98D98.40704@cisco.com>
Date: Fri, 10 Jun 2005 08:54:48 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Jo=EBl_Repiquet?= <joel.repiquet@tech-invite.com>
Subject: Re: [Sip] SIP parameters at IANA
References: <1118403625.42a97c29e5fe5@webmail.tech-invite.com>
In-Reply-To: <1118403625.42a97c29e5fe5@webmail.tech-invite.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 10 Jun 2005 12:54:48.0628 (UTC)
	FILETIME=[959C2F40:01C56DBB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA17059
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

Thanks for pointing this out. I'll ping iana on it.

-Jonathan R.

Jo=EBl Repiquet wrote:
> Hi,
>=20
> SIP Parameters at IANA for session timers in SIP (RFC4028) are still re=
gistered
> with "RFC-ietf-sip-session-timer-15.txt". Could you update it? It will =
be
> easier to see the parameters related to drafts.
>=20
> Thanks!
>=20
>=20
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=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
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Jun 10 12:28:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgmMS-0002px-OP; Fri, 10 Jun 2005 12:28:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgmMR-0002ps-BT
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 12:27:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05818
	for <sip@ietf.org>; Fri, 10 Jun 2005 12:27:56 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgmi7-0000H5-Oa
	for sip@ietf.org; Fri, 10 Jun 2005 12:50:25 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2005 12:27:48 -0400
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 j5AGQXNQ011199; 
	Fri, 10 Jun 2005 12:27:00 -0400 (EDT)
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);
	Fri, 10 Jun 2005 12:27:00 -0400
Received: from [192.168.1.110] ([10.86.240.168]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 10 Jun 2005 12:26:59 -0400
Message-ID: <42A9BF53.1090905@cisco.com>
Date: Fri, 10 Jun 2005 12:26:59 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Sip] SIP parameters at IANA
References: <1118403625.42a97c29e5fe5@webmail.tech-invite.com>
	<42A98D98.40704@cisco.com>
In-Reply-To: <42A98D98.40704@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 10 Jun 2005 16:26:59.0881 (UTC)
	FILETIME=[3A073990:01C56DD9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA05818
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

It is now corrected.

Thanks,
Jonathan R.

Jonathan Rosenberg wrote:

> Thanks for pointing this out. I'll ping iana on it.
>=20
> -Jonathan R.
>=20
> Jo=EBl Repiquet wrote:
>=20
>> Hi,
>>
>> SIP Parameters at IANA for session timers in SIP (RFC4028) are still=20
>> registered
>> with "RFC-ietf-sip-session-timer-15.txt". Could you update it? It will=
 be
>> easier to see the parameters related to drafts.
>>
>> Thanks!
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>> _______________________________________________
>> 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
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Jun 10 12:57:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dgmp3-0001Md-0m; Fri, 10 Jun 2005 12:57:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgmoz-0001MX-2d
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 12:57:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08201
	for <sip@ietf.org>; Fri, 10 Jun 2005 12:57:25 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgnAd-0006VQ-Os
	for sip@ietf.org; Fri, 10 Jun 2005 13:19:55 -0400
Received: from [64.101.149.222] ([64.101.149.222]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5AGwdxJ004356
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 10 Jun 2005 11:58:40 -0500
In-Reply-To: <40AF35183B110B4899DD3221904B6B580111E66A@usashms001.mcilink.com>
References: <40AF35183B110B4899DD3221904B6B580111E66A@usashms001.mcilink.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <179ad7c695ca06859f419956cd9516f5@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Comment on refer-with-norefersub-01
Date: Fri, 10 Jun 2005 11:55:22 -0500
To: sip@ietf.org
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: Alan Johnston <alan.johnston@mci.com>, Cullen Jennings <fluffy@cisco.com>,
	Tom Hiller <tomhiller@lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:

> In most cases (at least for common ones such as transfer and remote 
> call
> control), the UA issuing the REFER has had some kind of SIP message
> exchange with the REFER recipient.  As a result, the UA will know based
> on a previously received Supported header whether the recipient 
> supports
> the extension before it sends the REFER with Require.
>
> True, this doesn't cover all cases, but these cases seem like the most
> common ones that would want to use this feature.  In other words, the
> main reason for suppressing the subscription is that the UA has another
> method of finding out the result of the REFER, and the number of
> messages is trying to be minimized.
>


Ok, so are we concluding that the text is okay as written, or does it 
need the change Cullen suggested?

C'mon folks, OMA wants to use this draft. We need to close it up, one 
way or another.

--
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 Jun 10 14:25:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgoBw-0002cc-ES; Fri, 10 Jun 2005 14:25:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgoBr-0002Zh-BY
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 14:25:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17452
	for <sip@ietf.org>; Fri, 10 Jun 2005 14:25:09 -0400 (EDT)
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.33)
	id 1DgoXW-0000LI-Pv for sip@ietf.org; Fri, 10 Jun 2005 14:47:38 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 10 Jun 2005 11:24:47 -0700
X-IronPort-AV: i="3.93,190,1115017200"; 
	d="scan'208"; a="642742684:sNHT1239805560"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AIOblw029178;
	Fri, 10 Jun 2005 11:24:37 -0700 (PDT)
Received: from 64.101.174.128 ([64.101.174.128]) by
	vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft
	Exchange Server HTTP-DAV ; Fri, 10 Jun 2005 18:26:55 +0000
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 10 Jun 2005 13:24:44 -0500
Subject: Re: [Sip] Comment on refer-with-norefersub-01
From: Cullen Jennings <fluffy@cisco.com>
To: Dean Willis <dean.willis@softarmor.com>, "sip@ietf.org" <sip@ietf.org>
Message-ID: <BECF451C.3D162%fluffy@cisco.com>
In-Reply-To: <179ad7c695ca06859f419956cd9516f5@softarmor.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: Alan Johnston <alan.johnston@mci.com>, Tom Hiller <tomhiller@lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


It seems like a very common case people want to use this is for click to
dial and in that case, there is no previous signaling.

So far, to my knowledge, no one has provided an argument of how the require
helps in any case. It will reduce interoperability between clients that do
and do not support this. Unless someone has an argument why the require is
needed, I think we should drop it.

(And if using the require on call flows with correctly behaving OMA
endpoints somehow reduced the bandwidth, I'd view that as a reason but so
far no one has provided an example of this)

Cullen


On 6/10/05 11:55 AM, "Dean Willis" <dean.willis@softarmor.com> wrote:

> 
> On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:
> 
>> In most cases (at least for common ones such as transfer and remote
>> call
>> control), the UA issuing the REFER has had some kind of SIP message
>> exchange with the REFER recipient.  As a result, the UA will know based
>> on a previously received Supported header whether the recipient
>> supports
>> the extension before it sends the REFER with Require.
>> 
>> True, this doesn't cover all cases, but these cases seem like the most
>> common ones that would want to use this feature.  In other words, the
>> main reason for suppressing the subscription is that the UA has another
>> method of finding out the result of the REFER, and the number of
>> messages is trying to be minimized.
>> 
> 
> 
> Ok, so are we concluding that the text is okay as written, or does it
> need the change Cullen suggested?
> 
> C'mon folks, OMA wants to use this draft. We need to close it up, one
> way or another.
> 
> --
> 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 Jun 10 15:30:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgpCk-0002qB-Nc; Fri, 10 Jun 2005 15:30:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgpCi-0002q3-7L
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 15:30:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23790
	for <sip@ietf.org>; Fri, 10 Jun 2005 15:30:05 -0400 (EDT)
Received: from mail2.microsoft.com ([131.107.3.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpYP-0007OR-RB
	for sip@ietf.org; Fri, 10 Jun 2005 15:52:35 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 10 Jun 2005 12:29:56 -0700
Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 10 Jun 2005 12:29:55 -0700
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] Comment on refer-with-norefersub-01
Date: Fri, 10 Jun 2005 12:29:54 -0700
Message-ID: <DD07841287D0AD428833021705E0D14E05695C65@RED-MSG-52.redmond.corp.microsoft.com>
Thread-Topic: [Sip] Comment on refer-with-norefersub-01
Thread-Index: AcVt6fhvLXOsLmvRT9qI+rRxH4DUnQAB3swg
From: "Orit Levin" <oritl@microsoft.com>
To: "Cullen Jennings" <fluffy@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
X-OriginalArrivalTime: 10 Jun 2005 19:29:55.0729 (UTC)
	FILETIME=[C824B810:01C56DF2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: quoted-printable
Cc: Alan Johnston <alan.johnston@mci.com>, Tom Hiller <tomhiller@lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Why we are reopening this never ending discussion again?
Below is the precise recap of the achieved "compromise" that worked for
everyone back in the last IETF:

----------------------------------------------------------------------
Topic: REFER Extensions=20
by Orit Levin=20
see draft-ietf-sip-refer-with-norefersub-01.txt=20
Slides were presented that should be included in proceedings.=20

Only one open issue remained for the draft since its WGLC. This was=20
"How does a REFER-Issuer enable the feature?". Alternatives include:=20
a) Commonly preceded by OPTIONS, b) supported header in the request,=20
c) required header in the response, d) require header in the request.=20

Discussion agreed that the Supported header is the wrong approach, as=20
it indicates which features are supported by the sender, not required=20
for the respondent.=20

Discussion became prolonged, and the participants were moved to the=20
hallway for a focused discussion. This discussion reached the=20
following conclusion:=20

  1) Add a new header to be used with REFER request and the=20
      corresponding response
  2) Keep option tag=20
  3) Including this option tag in Require header is NOT RECOMMENDED.=20

This conclusion was shared with the WG, and no objections were noted.=20
------------------------------------------------------------------------

Does anyone think that we need to rehash it again? If we are in
agreement, I will revise the draft accordingly and re-submit it ASAP.
Otherwise, lets continue the discussion...

Thanks,
Orit.

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Cullen Jennings
> Sent: Friday, June 10, 2005 11:25 AM
> To: Dean Willis; sip@ietf.org
> Cc: Alan Johnston; Tom Hiller
> Subject: Re: [Sip] Comment on refer-with-norefersub-01
>=20
>=20
> It seems like a very common case people want to use this is=20
> for click to dial and in that case, there is no previous signaling.
>=20
> So far, to my knowledge, no one has provided an argument of=20
> how the require helps in any case. It will reduce=20
> interoperability between clients that do and do not support=20
> this. Unless someone has an argument why the require is=20
> needed, I think we should drop it.
>=20
> (And if using the require on call flows with correctly=20
> behaving OMA endpoints somehow reduced the bandwidth, I'd=20
> view that as a reason but so far no one has provided an=20
> example of this)
>=20
> Cullen
>=20
>=20
> On 6/10/05 11:55 AM, "Dean Willis" <dean.willis@softarmor.com> wrote:
>=20
> >=20
> > On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:
> >=20
> >> In most cases (at least for common ones such as transfer=20
> and remote=20
> >> call control), the UA issuing the REFER has had some kind of SIP=20
> >> message exchange with the REFER recipient.  As a result,=20
> the UA will=20
> >> know based on a previously received Supported header whether the=20
> >> recipient supports the extension before it sends the REFER with=20
> >> Require.
> >>=20
> >> True, this doesn't cover all cases, but these cases seem like the=20
> >> most common ones that would want to use this feature.  In other=20
> >> words, the main reason for suppressing the subscription is=20
> that the=20
> >> UA has another method of finding out the result of the=20
> REFER, and the=20
> >> number of messages is trying to be minimized.
> >>=20
> >=20
> >=20
> > Ok, so are we concluding that the text is okay as written,=20
> or does it=20
> > need the change Cullen suggested?
> >=20
> > C'mon folks, OMA wants to use this draft. We need to close=20
> it up, one=20
> > way or another.
> >=20
> > --
> > Dean
>=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 Jun 10 20:41:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dgu3p-0002Sa-Rz; Fri, 10 Jun 2005 20:41:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgu3l-0002QZ-RG
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 20:41:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28203
	for <sip@ietf.org>; Fri, 10 Jun 2005 20:41:11 -0400 (EDT)
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.33)
	id 1DguPX-00009q-EN for sip@ietf.org; Fri, 10 Jun 2005 21:03:44 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 10 Jun 2005 17:41:04 -0700
X-IronPort-AV: i="3.93,191,1115017200"; 
	d="scan'208"; a="277234895:sNHT29166082"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5B0ewbw008267;
	Fri, 10 Jun 2005 17:40:59 -0700 (PDT)
Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 10 Jun 2005 17:43:12 -0700
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 10 Jun 2005 19:40:59 -0500
Subject: Re: [Sip] Comment on refer-with-norefersub-01
From: Cullen Jennings <fluffy@cisco.com>
To: Orit Levin <oritl@microsoft.com>, Dean Willis <dean.willis@softarmor.com>, 
	"sip@ietf.org" <sip@ietf.org>
Message-ID: <BECF9D4B.3D2C0%fluffy@cisco.com>
In-Reply-To: <DD07841287D0AD428833021705E0D14E05695C65@RED-MSG-52.redmond.corp.microsoft.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2005 00:43:12.0244 (UTC)
	FILETIME=[8BBD4B40:01C56E1E]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit
Cc: Alan Johnston <alan.johnston@mci.com>, Tom Hiller <tomhiller@lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


I'm in 100% agreement with Orit - sounds good to me.

Cullen

On 6/10/05 2:29 PM, "Orit Levin" <oritl@microsoft.com> wrote:

> Why we are reopening this never ending discussion again?
> Below is the precise recap of the achieved "compromise" that worked for
> everyone back in the last IETF:
> 
> ----------------------------------------------------------------------
> Topic: REFER Extensions
> by Orit Levin 
> see draft-ietf-sip-refer-with-norefersub-01.txt
> Slides were presented that should be included in proceedings.
> 
> Only one open issue remained for the draft since its WGLC. This was
> "How does a REFER-Issuer enable the feature?". Alternatives include:
> a) Commonly preceded by OPTIONS, b) supported header in the request,
> c) required header in the response, d) require header in the request.
> 
> Discussion agreed that the Supported header is the wrong approach, as
> it indicates which features are supported by the sender, not required
> for the respondent.
> 
> Discussion became prolonged, and the participants were moved to the
> hallway for a focused discussion. This discussion reached the
> following conclusion:
> 
>   1) Add a new header to be used with REFER request and the
>       corresponding response
>   2) Keep option tag
>   3) Including this option tag in Require header is NOT RECOMMENDED.
> 
> This conclusion was shared with the WG, and no objections were noted.
> ------------------------------------------------------------------------
> 
> Does anyone think that we need to rehash it again? If we are in
> agreement, I will revise the draft accordingly and re-submit it ASAP.
> Otherwise, lets continue the discussion...
> 
> Thanks,
> Orit.
> 
>> -----Original Message-----
>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
>> Behalf Of Cullen Jennings
>> Sent: Friday, June 10, 2005 11:25 AM
>> To: Dean Willis; sip@ietf.org
>> Cc: Alan Johnston; Tom Hiller
>> Subject: Re: [Sip] Comment on refer-with-norefersub-01
>> 
>> 
>> It seems like a very common case people want to use this is
>> for click to dial and in that case, there is no previous signaling.
>> 
>> So far, to my knowledge, no one has provided an argument of
>> how the require helps in any case. It will reduce
>> interoperability between clients that do and do not support
>> this. Unless someone has an argument why the require is
>> needed, I think we should drop it.
>> 
>> (And if using the require on call flows with correctly
>> behaving OMA endpoints somehow reduced the bandwidth, I'd
>> view that as a reason but so far no one has provided an
>> example of this)
>> 
>> Cullen
>> 
>> 
>> On 6/10/05 11:55 AM, "Dean Willis" <dean.willis@softarmor.com> wrote:
>> 
>>> 
>>> On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:
>>> 
>>>> In most cases (at least for common ones such as transfer
>> and remote 
>>>> call control), the UA issuing the REFER has had some kind of SIP
>>>> message exchange with the REFER recipient.  As a result,
>> the UA will 
>>>> know based on a previously received Supported header whether the
>>>> recipient supports the extension before it sends the REFER with
>>>> Require.
>>>> 
>>>> True, this doesn't cover all cases, but these cases seem like the
>>>> most common ones that would want to use this feature.  In other
>>>> words, the main reason for suppressing the subscription is
>> that the 
>>>> UA has another method of finding out the result of the
>> REFER, and the 
>>>> number of messages is trying to be minimized.
>>>> 
>>> 
>>> 
>>> Ok, so are we concluding that the text is okay as written,
>> or does it 
>>> need the change Cullen suggested?
>>> 
>>> C'mon folks, OMA wants to use this draft. We need to close
>> it up, one 
>>> way or another.
>>> 
>>> --
>>> 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
>> 


_______________________________________________
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 Jun 10 22:56:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DgwAw-0001Ls-Mq; Fri, 10 Jun 2005 22:56:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DgwAu-0001Ie-5m
	for sip@megatron.ietf.org; Fri, 10 Jun 2005 22:56:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06855
	for <sip@ietf.org>; Fri, 10 Jun 2005 22:56:41 -0400 (EDT)
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.33)
	id 1DgwWh-0006PP-1R for sip@ietf.org; Fri, 10 Jun 2005 23:19:15 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 10 Jun 2005 19:56:35 -0700
X-IronPort-AV: i="3.93,191,1115017200"; 
	d="scan'208"; a="277263436:sNHT30400388"
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 j5B2uVlq020500;
	Fri, 10 Jun 2005 19:56:31 -0700 (PDT)
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, 10 Jun 2005 22:56:30 -0400
Received: from [192.168.1.100] ([10.86.240.115]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 10 Jun 2005 22:56:30 -0400
Message-ID: <42AA52DD.1080005@cisco.com>
Date: Fri, 10 Jun 2005 22:56:29 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] Comment on refer-with-norefersub-01
References: <BECF9D4B.3D2C0%fluffy@cisco.com>
In-Reply-To: <BECF9D4B.3D2C0%fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2005 02:56:30.0422 (UTC)
	FILETIME=[2B066760:01C56E31]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Alan Johnston <alan.johnston@mci.com>,
	Orit Levin <oritl@microsoft.com>, Tom Hiller <tomhiller@lucent.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

This conclusion also (still) sounds fine to me.

Thanks,
Jonathan R.

Cullen Jennings wrote:

> I'm in 100% agreement with Orit - sounds good to me.
> 
> Cullen
> 
> On 6/10/05 2:29 PM, "Orit Levin" <oritl@microsoft.com> wrote:
> 
> 
>>Why we are reopening this never ending discussion again?
>>Below is the precise recap of the achieved "compromise" that worked for
>>everyone back in the last IETF:
>>
>>----------------------------------------------------------------------
>>Topic: REFER Extensions
>>by Orit Levin 
>>see draft-ietf-sip-refer-with-norefersub-01.txt
>>Slides were presented that should be included in proceedings.
>>
>>Only one open issue remained for the draft since its WGLC. This was
>>"How does a REFER-Issuer enable the feature?". Alternatives include:
>>a) Commonly preceded by OPTIONS, b) supported header in the request,
>>c) required header in the response, d) require header in the request.
>>
>>Discussion agreed that the Supported header is the wrong approach, as
>>it indicates which features are supported by the sender, not required
>>for the respondent.
>>
>>Discussion became prolonged, and the participants were moved to the
>>hallway for a focused discussion. This discussion reached the
>>following conclusion:
>>
>>  1) Add a new header to be used with REFER request and the
>>      corresponding response
>>  2) Keep option tag
>>  3) Including this option tag in Require header is NOT RECOMMENDED.
>>
>>This conclusion was shared with the WG, and no objections were noted.
>>------------------------------------------------------------------------
>>
>>Does anyone think that we need to rehash it again? If we are in
>>agreement, I will revise the draft accordingly and re-submit it ASAP.
>>Otherwise, lets continue the discussion...
>>
>>Thanks,
>>Orit.
>>
>>
>>>-----Original Message-----
>>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
>>>Behalf Of Cullen Jennings
>>>Sent: Friday, June 10, 2005 11:25 AM
>>>To: Dean Willis; sip@ietf.org
>>>Cc: Alan Johnston; Tom Hiller
>>>Subject: Re: [Sip] Comment on refer-with-norefersub-01
>>>
>>>
>>>It seems like a very common case people want to use this is
>>>for click to dial and in that case, there is no previous signaling.
>>>
>>>So far, to my knowledge, no one has provided an argument of
>>>how the require helps in any case. It will reduce
>>>interoperability between clients that do and do not support
>>>this. Unless someone has an argument why the require is
>>>needed, I think we should drop it.
>>>
>>>(And if using the require on call flows with correctly
>>>behaving OMA endpoints somehow reduced the bandwidth, I'd
>>>view that as a reason but so far no one has provided an
>>>example of this)
>>>
>>>Cullen
>>>
>>>
>>>On 6/10/05 11:55 AM, "Dean Willis" <dean.willis@softarmor.com> wrote:
>>>
>>>
>>>>On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:
>>>>
>>>>
>>>>>In most cases (at least for common ones such as transfer
>>>
>>>and remote 
>>>
>>>>>call control), the UA issuing the REFER has had some kind of SIP
>>>>>message exchange with the REFER recipient.  As a result,
>>>
>>>the UA will 
>>>
>>>>>know based on a previously received Supported header whether the
>>>>>recipient supports the extension before it sends the REFER with
>>>>>Require.
>>>>>
>>>>>True, this doesn't cover all cases, but these cases seem like the
>>>>>most common ones that would want to use this feature.  In other
>>>>>words, the main reason for suppressing the subscription is
>>>
>>>that the 
>>>
>>>>>UA has another method of finding out the result of the
>>>
>>>REFER, and the 
>>>
>>>>>number of messages is trying to be minimized.
>>>>>
>>>>
>>>>
>>>>Ok, so are we concluding that the text is okay as written,
>>>
>>>or does it 
>>>
>>>>need the change Cullen suggested?
>>>>
>>>>C'mon folks, OMA wants to use this draft. We need to close
>>>
>>>it up, one 
>>>
>>>>way or another.
>>>>
>>>>--
>>>>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
>>>
> 
> 
> 
> _______________________________________________
> 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
Director, Service Provider VoIP Architecture   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 Sun Jun 12 16:02:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DhYfR-0000WV-HU; Sun, 12 Jun 2005 16:02:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DhYfO-0000WQ-8C
	for sip@megatron.ietf.org; Sun, 12 Jun 2005 16:02:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02971
	for <sip@ietf.org>; Sun, 12 Jun 2005 16:02:44 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhZ1W-0001E1-3m
	for sip@ietf.org; Sun, 12 Jun 2005 16:25:39 -0400
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 j5CK4weH032437
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Sun, 12 Jun 2005 15:04:59 -0500
In-Reply-To: <DD07841287D0AD428833021705E0D14E05695C65@RED-MSG-52.redmond.corp.microsoft.com>
References: <DD07841287D0AD428833021705E0D14E05695C65@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2d32087c46bdad9d0986be9ccf4746a2@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Comment on refer-with-norefersub-01
Date: Sun, 12 Jun 2005 15:01:45 -0500
To: "Orit Levin" <oritl@microsoft.com>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: Alan Johnston <alan.johnston@mci.com>, Cullen Jennings <fluffy@cisco.com>,
	sip@ietf.org, Tom Hiller <tomhiller@lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

On Jun 10, 2005, at 2:29 PM, Orit Levin wrote:

> Why we are reopening this never ending discussion again?
> Below is the precise recap of the achieved "compromise" that worked for
> everyone back in the last IETF:
>

My fault. My brain slipped and I completely forgot about the conclusion 
at the last IETF meeting.

We have a conclusion.

Orit is going to write it up.

When it is written up, we are going to poll the list, and if we still 
have a consensus, send it to the IESG for review.

--
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 Mon Jun 13 06:29:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DhmCL-0001WY-W7; Mon, 13 Jun 2005 06:29:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmC3-0001T9-QC
	for sip@megatron.ietf.org; Mon, 13 Jun 2005 06:29:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27306
	for <sip@ietf.org>; Mon, 13 Jun 2005 06:29:21 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhmYH-0005Sr-5k
	for sip@ietf.org; Mon, 13 Jun 2005 06:52:24 -0400
Received: by rproxy.gmail.com with SMTP id a41so1575286rng
	for <sip@ietf.org>; Mon, 13 Jun 2005 03:29:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=ckWNqdoI5y8GZxmE/gFUe2OowgC9fIpBVBahQfESVdx4X3+wpGtEZOTCbIrtMplQ6o+XKkzLRiLONg4Tba6nDWg71yjhIs5lunIoVvF+khpILc/Bgzv67K8N37gpPVMuTRlyQmm0QGgJAzD4RqR1bFpzFeMszGmmNs57HSkuXxM=
Received: by 10.38.22.32 with SMTP id 32mr882409rnv;
	Mon, 13 Jun 2005 03:29:04 -0700 (PDT)
Received: by 10.38.12.71 with HTTP; Mon, 13 Jun 2005 03:29:04 -0700 (PDT)
Message-ID: <e8193904050613032913985f79@mail.gmail.com>
Date: Mon, 13 Jun 2005 15:59:04 +0530
From: ayan <ayan.kar@gmail.com>
To: sip@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] querry about 481
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ayan <ayan.kar@gmail.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

Hi,

Is it possible to receive a 481, Call Leg/transaction Does Not Exist,
for a dialog initiating request?
For egs. can we get a 481, for a first SUBSCRIBE which initiates a new dial=
og?

Thnx in advnce.
/ayan

_______________________________________________
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 Jun 13 07:10:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dhmpl-0007q6-0P; Mon, 13 Jun 2005 07:10:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmpY-0007ns-H6
	for sip@megatron.ietf.org; Mon, 13 Jun 2005 07:10:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29854
	for <sip@ietf.org>; Mon, 13 Jun 2005 07:10:09 -0400 (EDT)
Received: from motgate2.mot.com ([144.189.100.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhnBn-0007Bp-WD
	for sip@ietf.org; Mon, 13 Jun 2005 07:33:13 -0400
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j5DBKbxo008071
	for <sip@ietf.org>; Mon, 13 Jun 2005 04:20:37 -0700 (MST)
Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1])
	by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j5DBF2Ch026301
	for <sip@ietf.org>; Mon, 13 Jun 2005 06:15:03 -0500 (CDT)
Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72)
	id <K0BZQ0R7>; Mon, 13 Jun 2005 16:39:50 +0530
Message-ID: <772BCEF88A1DD91191F80011856715F303961B91@zin24exm01.ap.mot.com>
From: Chadha Retesh-A19894 <retesh@motorola.com>
To: ayan <ayan.kar@gmail.com>, sip@ietf.org
Subject: RE: [Sip] querry about 481
Date: Mon, 13 Jun 2005 16:39:46 +0530
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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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

Yes, if the SUBSCRIBE/INVITE contains a to tag, not matching any dialog.

Rgds
Retesh

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ayan
Sent: Monday, June 13, 2005 3:59 PM
To: sip@ietf.org
Subject: [Sip] querry about 481


Hi,

Is it possible to receive a 481, Call Leg/transaction Does Not Exist, for a
dialog initiating request? For egs. can we get a 481, for a first SUBSCRIBE
which initiates a new dialog?

Thnx in advnce.
/ayan

_______________________________________________
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 Jun 13 13:45:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dht0G-0008Tt-NA; Mon, 13 Jun 2005 13:45:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dht0F-0008Tf-Ce
	for sip@megatron.ietf.org; Mon, 13 Jun 2005 13:45:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03112
	for <sip@ietf.org>; Mon, 13 Jun 2005 13:45:38 -0400 (EDT)
Received: from web40701.mail.yahoo.com ([66.218.78.158])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhtMS-0008SG-9B
	for sip@ietf.org; Mon, 13 Jun 2005 14:08:44 -0400
Received: (qmail 34502 invoked by uid 60001); 13 Jun 2005 17:45:20 -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=kOrf9wzX8TIcKIUKrPREV6dfLBHZtcOS5GX1ih7jA6zwCRfiKsbAGq+EBmN513NQQfVIdbqresuBira0dDxIvP7YGxsBvvkOWsGM/GeqZO3J23lNfN82beW9HtTPNCeZYOQBmqEf+tiFWdSBZTrdkMHXK605xOUy5PgX0K1gZQE=
	; 
Message-ID: <20050613174520.34500.qmail@web40701.mail.yahoo.com>
Received: from [134.56.105.33] by web40701.mail.yahoo.com via HTTP;
	Mon, 13 Jun 2005 10:45:19 PDT
Date: Mon, 13 Jun 2005 10:45:19 -0700 (PDT)
From: Manish Joshi <mjoshi_blr@yahoo.com>
Subject: RE: [Sip] querry about 481
To: Chadha Retesh-A19894 <retesh@motorola.com>, ayan <ayan.kar@gmail.com>,
	sip@ietf.org
In-Reply-To: <772BCEF88A1DD91191F80011856715F303961B91@zin24exm01.ap.mot.com>
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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="===============1382241608=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============1382241608==
Content-Type: multipart/alternative; boundary="0-1713807817-1118684719=:24007"
Content-Transfer-Encoding: 8bit

--0-1713807817-1118684719=:24007
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Since it is a new Dialog creation request, there is no question of it matching any dialog. So ideally you should not get 481 for a new SUBSCRIBE initiated with a brand new call id and
from tag. You can get this response usually for (RE)SUBSCRIBE or NOTIFY.
 
Regards,
Manish

Chadha Retesh-A19894 <retesh@motorola.com> wrote:
Yes, if the SUBSCRIBE/INVITE contains a to tag, not matching any dialog.

Rgds
Retesh

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ayan
Sent: Monday, June 13, 2005 3:59 PM
To: sip@ietf.org
Subject: [Sip] querry about 481


Hi,

Is it possible to receive a 481, Call Leg/transaction Does Not Exist, for a
dialog initiating request? For egs. can we get a 481, for a first SUBSCRIBE
which initiates a new dialog?

Thnx in advnce.
/ayan

_______________________________________________
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

		
---------------------------------
Discover Yahoo!
 Get on-the-go sports scores, stock quotes, news & more. Check it out!
--0-1713807817-1118684719=:24007
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Since it is a new Dialog creation request, there is no question of it matching any dialog. So ideally you should not get&nbsp;481 for a new SUBSCRIBE initiated with a brand new call id and</DIV>
<DIV>from tag. You can get this response usually for (RE)SUBSCRIBE or NOTIFY.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Manish<BR><BR><B><I>Chadha Retesh-A19894 &lt;retesh@motorola.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Yes, if the SUBSCRIBE/INVITE contains a to tag, not matching any dialog.<BR><BR>Rgds<BR>Retesh<BR><BR>-----Original Message-----<BR>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of ayan<BR>Sent: Monday, June 13, 2005 3:59 PM<BR>To: sip@ietf.org<BR>Subject: [Sip] querry about 481<BR><BR><BR>Hi,<BR><BR>Is it possible to receive a 481, Call Leg/transaction Does Not Exist, for a<BR>dialog initiating request? For egs. can we get a 481, for a first SUBSCRIBE<BR>which initiates a new dialog?<BR><BR>Thnx in advnce.<BR>/ayan<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 Use<BR>sipping@ietf.org for new developments on the application of
 sip<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><p>
		<hr size=1>Discover Yahoo!<br> 
Get on-the-go sports scores, stock quotes, news & more. <a href="http://us.rd.yahoo.com/evt=32661/*http://discover.yahoo.com/mobile.html">Check it out!</a>
--0-1713807817-1118684719=:24007--


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




From sip-bounces@ietf.org Mon Jun 13 15:30:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dhue2-0002Zl-Tc; Mon, 13 Jun 2005 15:30:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dhudw-0002Yx-G1; Mon, 13 Jun 2005 15:30:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13510;
	Mon, 13 Jun 2005 15:30:42 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Dhv0H-0004wS-PB; Mon, 13 Jun 2005 15:53:49 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1Dhudv-0005iv-F8; Mon, 13 Jun 2005 15:30:43 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1Dhudv-0005iv-F8@newodin.ietf.org>
Date: Mon, 13 Jun 2005 15:30:43 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: sip mailing list <sip@ietf.org>, sip chair <rohan@ekabal.com>,
	Internet Architecture Board <iab@iab.org>,
	sip chair <dean.willis@softarmor.com>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Sip] Protocol Action: 'Actions addressing identified issues with 
 the Session Initiation Protocol's non-INVITE Transaction' to
 Proposed Standard 
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 IESG has approved the following documents:

- 'Actions addressing identified issues with the Session Initiation Protocol's 
   non-INVITE Transaction '
   <draft-sparks-sip-nit-actions-03.txt> as a Proposed Standard
- 'Problems identified associated with the Session Initiation Protocol's 
   non-INVITE Transaction '
   <draft-sparks-sip-nit-problems-02.txt> as an Informational RFC

These documents are products of the Session Initiation Protocol Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary

   draft-sparks-sip-nit-problems is an informational description of
   the problems that arise in SIP because the protocol design for
   non-INVITE transactions (message exchanges other than the
   initiation handshake that begins with INVITE) were designed with 
   timing rules which have turned out to cause race conditions, 
   useless traffic and potential storms.  A security issue is
   identified in that these problems could even be exploited by
   a malicious actor.

   draft-sparks-sip-nit-actions describes the solutions for the
   problems described in the companion document.

   These solutions motivate several modifications in normative processing
   in the Session Initiation Protocol (SIP), in RFC 3261, and they
   are shown to address the problems identified with the SIP
   non-INVITE transaction.  These modifications reduce the probability
   of messages losing the race condition inherent in the non-INVITE
   transaction and reduce useless network traffic.  They also improve
   the robustness of SIP networks when elements stop responding. 
  
   draft-sparks-sip-nit-actions updates RFC 3261.
 
 Working Group Summary
 
  It was very difficult for the SIP Working Group to come to consensus on
  the scope of problems with non-INVITE transactions.  Demonstrating
  and narrowing the problem statement required a very careful set of consensus
  discussions related to the differences in perspective of the participants,
  and the difficulty of obtaining a completely clear statement of complex
  issues.  The consensus once won resulted in clear solutions, and both
  documents were forwarded for advancement with strong consensus.
 
Protocol Quality
 
 The initiation of this work was due to the editor's activities with
 implementations in SIP interoperability events.  He has stated that the 
 problem statement and solutions are both implementation-based.

The Responsible Area Director for the documents is Allison Mankin.  
The Working Group Shepherd for these documents is Rohan Mahy.

Notes to the RFC Editor
 
Replace the Security Considerations Section  text of 
draft-ietf-sip-nit-problems-02.txt with:

   This document describes some problems in the core SIP
   specification [1] related to the SIP non-INVITE, the messages other
   than the INVITE handshake that begins transactions.  A few of
   the problems lead to flooding or forgery risk, and could possibly be
   exploited by an adversary in a denial of service attack.  Solutions are
   defined in the companion draft-sip-nit-action-03.txt [RFC Editor - 
   replace this with the corresponding RFC number].
   
   One solution there prohibits proxies and User Agents from sending 408
   responses to non-INVITE transactions.  Without this change, proxies
   automatically generate a storm of useless responses.
   An attacker could capitalize on this by enticing User Agents to
   send non-INVITE requests to a black hole (through social engineering
   or DNS poisoning) or by selectively dropping responses.

   Another solution prohibits proxies from forwarding late responses.
   Without this change, an attacker could easily forge messages which
   appear to be late responses.  All proxies compliant with RFC 3261 are
   required to forward these responses, wasting bandwidth and CPU and
   potentially overwhelming target User Agents (especially those with
   low speed connections).
------
Please change the name of the References sections in draft-sparks-nit-problems
to Informative References, and in draft-sparks-nit-actions-03.txt to 
Normative References.


_______________________________________________
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 Jun 13 22:07:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di0pr-0000S6-FX; Mon, 13 Jun 2005 22:07:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di0pp-0000QQ-UB
	for sip@megatron.ietf.org; Mon, 13 Jun 2005 22:07:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00993
	for <sip@ietf.org>; Mon, 13 Jun 2005 22:07:23 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di1CE-00033v-LD
	for sip@ietf.org; Mon, 13 Jun 2005 22:30:35 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2005 22:07:16 -0400
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 j5E25eNA009682; 
	Mon, 13 Jun 2005 22:05:41 -0400 (EDT)
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, 13 Jun 2005 22:05:39 -0400
Received: from [192.168.1.100] ([10.86.242.183]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 13 Jun 2005 22:05:39 -0400
Message-ID: <42AE3B72.9030507@cisco.com>
Date: Mon, 13 Jun 2005 22:05:38 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manish Joshi <mjoshi_blr@yahoo.com>
Subject: Re: [Sip] querry about 481
References: <20050613174520.34500.qmail@web40701.mail.yahoo.com>
In-Reply-To: <20050613174520.34500.qmail@web40701.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jun 2005 02:05:39.0390 (UTC)
	FILETIME=[8FB51DE0:01C57085]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Cc: Chadha Retesh-A19894 <retesh@motorola.com>, 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

Yes, you should never see a 481 for an initial request.

However, in the interests of being strict on what you send and liberal 
on what you receive, I would advise against an implementation getting 
particularly upset at the receipt of a 481 to a dialog-initiating 
request; it should be treated as any other 4xx response in such a case.

-Jonathan R.

Manish Joshi wrote:

> Since it is a new Dialog creation request, there is no question of it 
> matching any dialog. So ideally you should not get 481 for a new 
> SUBSCRIBE initiated with a brand new call id and
> from tag. You can get this response usually for (RE)SUBSCRIBE or NOTIFY.
>  
> Regards,
> Manish
> 
> */Chadha Retesh-A19894 <retesh@motorola.com>/* wrote:
> 
>     Yes, if the SUBSCRIBE/INVITE contains a to tag, not matching any dialog.
> 
>     Rgds
>     Retesh
> 
>     -----Original Message-----
>     From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf
>     Of ayan
>     Sent: Monday, June 13, 2005 3:59 PM
>     To: sip@ietf.org
>     Subject: [Sip] querry about 481
> 
> 
>     Hi,
> 
>     Is it possible to receive a 481, Call Leg/transaction Does Not
>     Exist, for a
>     dialog initiating request? For egs. can we get a 481, for a first
>     SUBSCRIBE
>     which initiates a new dialog?
> 
>     Thnx in advnce.
>     /ayan
> 
>     _______________________________________________
>     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
> 
> ------------------------------------------------------------------------
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news & more. Check it out! 
> <http://us.rd.yahoo.com/evt=32661/*http://discover.yahoo.com/mobile.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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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 Tue Jun 14 03:58:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di6JV-0007Al-7x; Tue, 14 Jun 2005 03:58:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di6JS-00079x-Aw
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 03:58:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19273
	for <sip@ietf.org>; Tue, 14 Jun 2005 03:58:20 -0400 (EDT)
Received: from rat01038.dc-ratingen.de ([195.233.129.143])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di6fo-0001Qy-Vn
	for sip@ietf.org; Tue, 14 Jun 2005 04:21:34 -0400
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26])
	by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j5E7uxjl013337
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 14 Jun 2005 09:56:59 +0200 (MEST)
Received: from GPSMXR03.gps.internal.vodafone.com ([195.232.231.125])
	by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j5E7uwvv020688; Tue, 14 Jun 2005 09:56:58 +0200 (MEST)
Received: from gpsmx04.gps.internal.vodafone.com ([145.230.32.88]) by
	GPSMXR03.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 09:56:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
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] querry about 481
Date: Tue, 14 Jun 2005 09:56:58 +0200
Message-ID: <71F8E3E31CE37F49B0D7C092EB04FBA907067776@gpsmx04.gps.internal.vodafone.com>
Thread-Topic: [Sip] querry about 481
Thread-Index: AcVwhp3kvhhjFeTpRnypDflIuVe9fAAL/qYA
From: "Cunningham, Stuart, VF-Group" <stuart.cunningham@vodafone.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>,
	"Manish Joshi" <mjoshi_blr@yahoo.com>
X-OriginalArrivalTime: 14 Jun 2005 07:56:54.0211 (UTC)
	FILETIME=[A1479930:01C570B6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: quoted-printable
Cc: Chadha Retesh-A19894 <retesh@motorola.com>, 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,

You can also use the 404 user not found which is useful in this case.

Stuart=20

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Jonathan Rosenberg
Sent: Dienstag, 14. Juni 2005 04:06
To: Manish Joshi
Cc: Chadha Retesh-A19894; sip@ietf.org
Subject: Re: [Sip] querry about 481

Yes, you should never see a 481 for an initial request.

However, in the interests of being strict on what you send and liberal
on what you receive, I would advise against an implementation getting
particularly upset at the receipt of a 481 to a dialog-initiating
request; it should be treated as any other 4xx response in such a case.

-Jonathan R.

Manish Joshi wrote:

> Since it is a new Dialog creation request, there is no question of it=20
> matching any dialog. So ideally you should not get 481 for a new=20
> SUBSCRIBE initiated with a brand new call id and from tag. You can get

> this response usually for (RE)SUBSCRIBE or NOTIFY.
> =20
> Regards,
> Manish
>=20
> */Chadha Retesh-A19894 <retesh@motorola.com>/* wrote:
>=20
>     Yes, if the SUBSCRIBE/INVITE contains a to tag, not matching any
dialog.
>=20
>     Rgds
>     Retesh
>=20
>     -----Original Message-----
>     From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf
>     Of ayan
>     Sent: Monday, June 13, 2005 3:59 PM
>     To: sip@ietf.org
>     Subject: [Sip] querry about 481
>=20
>=20
>     Hi,
>=20
>     Is it possible to receive a 481, Call Leg/transaction Does Not
>     Exist, for a
>     dialog initiating request? For egs. can we get a 481, for a first
>     SUBSCRIBE
>     which initiates a new dialog?
>=20
>     Thnx in advnce.
>     /ayan
>=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=20
> sip
>=20
> ----------------------------------------------------------------------
> --
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news & more. Check it out!=20
> =
<http://us.rd.yahoo.com/evt=3D32661/*http://discover.yahoo.com/mobile.ht
> ml>
>=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
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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

_______________________________________________
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 Jun 14 04:03:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di6Or-0000Sp-O8; Tue, 14 Jun 2005 04:03:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di6Op-0000ST-BH
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 04:03:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19719
	for <sip@ietf.org>; Tue, 14 Jun 2005 04:03:53 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di6lF-0001i6-8D
	for sip@ietf.org; Tue, 14 Jun 2005 04:27:07 -0400
Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com
	[130.144.57.167])
	by gw-eur4.philips.com (Postfix) with ESMTP id 8A01C49734
	for <sip@ietf.org>; Tue, 14 Jun 2005 08:03:36 +0000 (UTC)
Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP id 2ACFC99
	for <sip@ietf.org>; Tue, 14 Jun 2005 08:03:36 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171])
	by smtpscan-eur4.philips.com (Postfix) with ESMTP id 077F650
	for <sip@ietf.org>; Tue, 14 Jun 2005 08:03:36 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125])
	by smtprelay-eur2.philips.com (Postfix) with ESMTP id 0666E41
	for <sip@ietf.org>; Tue, 14 Jun 2005 08:03:34 +0000 (GMT)
MIME-Version: 1.0
To: sip@ietf.org
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF1F9A02BC.2BE29083-ONC125701F.004872B9-C1257020.002C3226@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Tue, 14 Jun 2005 10:02:07 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 14/06/2005 10:02:55,
	Serialize complete at 14/06/2005 10:02:55
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Sip] The logic behind the From tag?
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

RFC 3261 specifies that a dialog is identified by a local tag, a remote 
tag 
and a call identifier, each of which should be "globally unique". The 
sender
of an INVITE adds both the Call-ID and the local tag. The recipients of 
that
INVITE each add their own remote tag (the To tag) to their responses. 

It is clear that the remote tag is necessary to be able to distinguish the
responses from the different recipients. However, there is no obvious need 

for the From tag: the INVITE already contains a unique Call-ID. 

So why is the From tag needed?

Cheers,

Frank

_______________________________________________
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 Jun 14 04:09:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di6U9-0001Yn-Ua; Tue, 14 Jun 2005 04:09:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di6U8-0001YF-1F
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 04:09:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20219
	for <sip@ietf.org>; Tue, 14 Jun 2005 04:09:22 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di6qT-0001zo-Qj
	for sip@ietf.org; Tue, 14 Jun 2005 04:32:36 -0400
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j5E89C9E019228
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 14 Jun 2005 10:09:13 +0200 (MEST)
Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115])
	by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j5E864oA025076; Tue, 14 Jun 2005 10:09:11 +0200 (MEST)
Received: from gpsmx04.gps.internal.vodafone.com ([145.230.32.88]) by
	gpsmxr04.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 14 Jun 2005 10:08:47 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
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] The logic behind the From tag?
Date: Tue, 14 Jun 2005 10:08:45 +0200
Message-ID: <71F8E3E31CE37F49B0D7C092EB04FBA90706779A@gpsmx04.gps.internal.vodafone.com>
Thread-Topic: [Sip] The logic behind the From tag?
Thread-Index: AcVwt9wkUb/z5EmqSm+ZihgtRMKSuQAAFGNA
From: "Cunningham, Stuart, VF-Group" <stuart.cunningham@vodafone.com>
To: "Frank Derks" <frank.derks@philips.com>, <sip@ietf.org>
X-OriginalArrivalTime: 14 Jun 2005 08:08:47.0028 (UTC)
	FILETIME=[4A26D740:01C570B8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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 Frank,

The From Tag is used for routing purposes. The From TAG is the sip
address after it uses the via or route. =20

Br,
Stuart=20

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Frank Derks
Sent: Dienstag, 14. Juni 2005 10:02
To: sip@ietf.org
Subject: [Sip] The logic behind the From tag?

RFC 3261 specifies that a dialog is identified by a local tag, a remote
tag and a call identifier, each of which should be "globally unique".
The sender of an INVITE adds both the Call-ID and the local tag. The
recipients of that INVITE each add their own remote tag (the To tag) to
their responses.=20

It is clear that the remote tag is necessary to be able to distinguish
the responses from the different recipients. However, there is no
obvious need=20

for the From tag: the INVITE already contains a unique Call-ID.=20

So why is the From tag needed?

Cheers,

Frank

_______________________________________________
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 Jun 14 05:04:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di7L4-0004UJ-Js; Tue, 14 Jun 2005 05:04:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di7L2-0004UE-N5
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 05:04:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24101
	for <sip@ietf.org>; Tue, 14 Jun 2005 05:04:02 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di7hU-0004NS-VO
	for sip@ietf.org; Tue, 14 Jun 2005 05:27:17 -0400
Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com
	[130.144.57.168])
	by gw-eur4.philips.com (Postfix) with ESMTP id 1214D49724;
	Tue, 14 Jun 2005 09:03:51 +0000 (UTC)
Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id 01463149; Tue, 14 Jun 2005 09:03:43 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP
	id DE10E139; Tue, 14 Jun 2005 09:03:43 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP
	id B9B9541; Tue, 14 Jun 2005 09:03:43 +0000 (GMT)
In-Reply-To: <71F8E3E31CE37F49B0D7C092EB04FBA90706779A@gpsmx04.gps.internal.vodafone.com>
To: "Cunningham, Stuart, VF-Group" <stuart.cunningham@vodafone.com>
Subject: RE: [Sip] The logic behind the From tag?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF6FE69C04.BD5EBE48-ONC1257020.00314278-C1257020.0031BCE5@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Tue, 14 Jun 2005 11:02:39 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 14/06/2005 11:03:04,
	Serialize complete at 14/06/2005 11:03:04
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
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 Stuart,

I don't quite see how this would work. The Via header is there to route 
a response and the Route header is there to route a request, in both 
cases based on their own contents and not based on the contents of the 
>From and To headers respectively. 

Could you elaborate on what you have in mind?

Cheers,

Frank









"Cunningham, Stuart, VF-Group" 
2005-06-14 10:08 AM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Hi Frank,

The From Tag is used for routing purposes. The From TAG is the sip
address after it uses the via or route. 

Br,
Stuart 

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Frank Derks
Sent: Dienstag, 14. Juni 2005 10:02
To: sip@ietf.org
Subject: [Sip] The logic behind the From tag?

RFC 3261 specifies that a dialog is identified by a local tag, a remote
tag and a call identifier, each of which should be "globally unique".
The sender of an INVITE adds both the Call-ID and the local tag. The
recipients of that INVITE each add their own remote tag (the To tag) to
their responses. 

It is clear that the remote tag is necessary to be able to distinguish
the responses from the different recipients. However, there is no
obvious need 

for the From tag: the INVITE already contains a unique Call-ID. 

So why is the From tag needed?

Cheers,

Frank

_______________________________________________
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 Jun 14 06:02:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di8FW-00077t-VZ; Tue, 14 Jun 2005 06:02:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di8FU-00077l-Kh
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 06:02:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28960
	for <sip@ietf.org>; Tue, 14 Jun 2005 06:02:22 -0400 (EDT)
Received: from nrmail01.netrake.com ([65.119.52.237] helo=nrmail01.netrake.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di8bw-0007AC-LL
	for sip@ietf.org; Tue, 14 Jun 2005 06:25:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] The logic behind the From tag?
Date: Tue, 14 Jun 2005 05:02:20 -0500
Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD927C63@nrmail01.netrake.net>
Thread-Topic: [Sip] The logic behind the From tag?
Thread-Index: AcVwwKceiBCm1vnZTEaYrsOukWp3sgABlVEw
From: "Rob Phillips" <rob@netrake.com>
To: "Frank Derks" <frank.derks@philips.com>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

Actually, I'd say the From tag is there to determine the direction of a =
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no =
>From and no To tag but with a unique call-ID.  No problem so far.  The =
callee receives the call and inserts it's To tag in the response.  =
Again, no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From =
and To to generate the request (so you can tell it's generated from the =
callee and not the caller)...but there's no From tag.  The call-ID is =
the same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do =
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE =
request?  You don't know how to handle it because you don't have the =
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074

_______________________________________________
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 Jun 14 07:21:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Di9Tc-0002jG-Go; Tue, 14 Jun 2005 07:21:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9Ta-0002jB-14
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 07:21:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04067
	for <sip@ietf.org>; Tue, 14 Jun 2005 07:21:01 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di9q3-00026j-EQ
	for sip@ietf.org; Tue, 14 Jun 2005 07:44:15 -0400
Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com
	[130.144.57.168])
	by gw-eur4.philips.com (Postfix) with ESMTP id 4D94D49752;
	Tue, 14 Jun 2005 11:20:52 +0000 (UTC)
Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id 1E77D13D; Tue, 14 Jun 2005 11:20:52 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP
	id 0435E136; Tue, 14 Jun 2005 11:20:52 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP
	id D789941; Tue, 14 Jun 2005 11:20:51 +0000 (GMT)
In-Reply-To: <7221140AD3DA7C4DB2CD49771243D8DD927C63@nrmail01.netrake.net>
To: "Rob Phillips" <rob@netrake.com>
Subject: RE: [Sip] The logic behind the From tag?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OFDFA1C2F0.F0AE96D1-ONC1257020.003D6B37-C1257020.003E4A00@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Tue, 14 Jun 2005 13:19:45 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 14/06/2005 13:20:12,
	Serialize complete at 14/06/2005 13:20:12
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
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 Rob,

The fact that the callee uses the same Call-ID is sufficient information 
to 
have the caller decide that this is a request on the same call. If you are
inferring that the Call-ID, although it is supposed to be unique, does not
provide this information, it is equally true that the From tag does not
provide this either. 

However, I do see a point. The fact that a From tag is present, does 
provide
an indication that this is a request on an exisisting dialog. It does, 
however,
raise the issue about the uniqueness of the To tag, the From tag and the 
Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique and 
that
another, again probably not so unique, parameter is added to determine 
whether 
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips" 
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a 
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no 
>From and no To tag but with a unique call-ID.  No problem so far.  The 
callee receives the call and inserts it's To tag in the response.  Again, 
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From 
and To to generate the request (so you can tell it's generated from the 
callee and not the caller)...but there's no From tag.  The call-ID is the 
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do 
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE 
request?  You don't know how to handle it because you don't have the 
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 14 08:34:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiAcp-0006zC-8d; Tue, 14 Jun 2005 08:34:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAcn-0006z4-Ro
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 08:34:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09624
	for <sip@ietf.org>; Tue, 14 Jun 2005 08:34:36 -0400 (EDT)
Received: from nrmail01.netrake.com ([65.119.52.237] helo=nrmail01.netrake.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAzI-0005Ug-4b
	for sip@ietf.org; Tue, 14 Jun 2005 08:57:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] The logic behind the From tag?
Date: Tue, 14 Jun 2005 07:34:41 -0500
Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD6F249B@nrmail01.netrake.net>
Thread-Topic: [Sip] The logic behind the From tag?
Thread-Index: AcVw08J93wCV6nlsQE6O77SiarxjnwAALHaw
From: "Rob Phillips" <rob@netrake.com>
To: "Frank Derks" <frank.derks@philips.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
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'm not saying the Call-Id can't be trusted to be unique, although it's =
certainly possible (although unlikely) that it might not be unique.  I'm =
saying, having the From and To tag both help determine direction of a =
call and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3D
       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dy
       <----------------- INVITE
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3D

Now the initial INVITE from the caller and the reINVITE from the callee =
look the same.  Suppose your proxy was a parallel forking B2BUA proxy =
who sent the INVITE in several different directions.  You got the 200 OK =
from the callee and ACK from the caller, but it may be that at some =
point after that, one of those other forks comes back though you again =
(on it's way to a destination on the other side of you).  Now how can =
you tell the difference between that forked INVITE and a reINVITE from =
the callee?  You can't, so you have to allow it through.  If, however, =
you had both a known To and From tag, and then you get an INVITE that =
just has a From tag, you instantly know it's not allowed and can return =
an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow =
completes, you would get:

200 OK ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dz
       <----------------- ACK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dz

anyway, and doesn't that just end up specifying a From and To tag?  But =
by specifying the From and To tag up front, it's easier to follow the =
flow from the beginning (in terms of INVITE vs. re-INVITE and caller vs. =
callee).

- rob

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information =
to=20
have the caller decide that this is a request on the same call. If you =
are
inferring that the Call-ID, although it is supposed to be unique, does =
not
provide this information, it is equally true that the From tag does not
provide this either.=20

However, I do see a point. The fact that a From tag is present, does =
provide
an indication that this is a request on an exisisting dialog. It does, =
however,
raise the issue about the uniqueness of the To tag, the From tag and the =

Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique =
and that
another, again probably not so unique, parameter is added to determine =
whether=20
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips"=20
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a=20
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no=20
>From and no To tag but with a unique call-ID.  No problem so far.  The=20
callee receives the call and inserts it's To tag in the response.  =
Again,=20
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From=20
and To to generate the request (so you can tell it's generated from the=20
callee and not the caller)...but there's no From tag.  The call-ID is =
the=20
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do=20
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE =

request?  You don't know how to handle it because you don't have the=20
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 14 13:07:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiEsl-0007CM-C7; Tue, 14 Jun 2005 13:07:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEsj-0007AC-EZ
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 13:07:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04325
	for <sip@ietf.org>; Tue, 14 Jun 2005 13:07:18 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiFFF-00060j-50
	for sip@ietf.org; Tue, 14 Jun 2005 13:30:38 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id AFF116C01E
	for <sip@ietf.org>; Tue, 14 Jun 2005 13:07:12 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: <sip@ietf.org>
Subject: RE: [Sip] querry about 481
Date: Tue, 14 Jun 2005 13:05:43 -0400
Message-ID: <019601c57103$4e67c030$6a01010a@keywest>
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 CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <e8193904050613032913985f79@mail.gmail.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
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: ayan
>
> Is it possible to receive a 481, Call Leg/transaction Does Not Exist,
> for a dialog initiating request?
> For egs. can we get a 481, for a first SUBSCRIBE which
> initiates a new dialog?

If you send an INVITE with a Replaces header, but the dialog info in the
Replaces header matches no dialog at the target UA, it should respond with
481.

But in general, your system should be able to cope with any response code
from a request, as you never know what new behavior will be defined for
various new request types.

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 Jun 14 14:42:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiGMM-00081I-N7; Tue, 14 Jun 2005 14:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiGMK-00081D-TY
	for sip@megatron.ietf.org; Tue, 14 Jun 2005 14:42:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17368
	for <sip@ietf.org>; Tue, 14 Jun 2005 14:41:59 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiGis-0005vZ-74
	for sip@ietf.org; Tue, 14 Jun 2005 15:05:18 -0400
Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com
	[130.144.57.167])
	by gw-eur4.philips.com (Postfix) with ESMTP id EB84049718;
	Tue, 14 Jun 2005 18:41:38 +0000 (UTC)
Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id BE1C09B; Tue, 14 Jun 2005 18:41:38 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP
	id 9F66DCE; Tue, 14 Jun 2005 18:41:38 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP
	id 7DCCF3D; Tue, 14 Jun 2005 18:41:38 +0000 (GMT)
In-Reply-To: <7221140AD3DA7C4DB2CD49771243D8DD6F249B@nrmail01.netrake.net>
To: "Rob Phillips" <rob@netrake.com>
Subject: RE: [Sip] The logic behind the From tag?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
From: Frank Derks <frank.derks@philips.com>
Message-ID: <OF6E0DDDA2.19A0AADC-ONC1257020.005D39CA-C1257020.0066AF7E@philips.com>
Date: Tue, 14 Jun 2005 20:40:58 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 14/06/2005 20:40:59,
	Serialize complete at 14/06/2005 20:40:59
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
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

Rob,

Since the second INVITE does not contain any tags, it does not have the 
same dialog ID as the already existing dialog! The first dialog has a 
dialog ID that consists of an empty From tag, a Call-ID with the value x 
and a To tag with the value y. The second invite will, at the worst, have 
an identical Call-ID and empty From and To tags. So there's no match.

I agree that including a From tag doesn't hurt a bit and we could argue 
about it being an "elegant" to do the same thing for both directions. 
However,I am just trying to understand why it would be necessary, because 
the RFC does not give an explanation for this tag (it does have one for 
the To tag).

Am I missing something in your example?

Cheers,

Frank











"Rob Phillips" 
2005-06-14 02:34 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







I'm not saying the Call-Id can't be trusted to be unique, although it's 
certainly possible (although unlikely) that it might not be unique.  I'm 
saying, having the From and To tag both help determine direction of a call 
and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=x
From-Tag=
To-Tag=
       <----------------- 200 OK
                          CallId=x
                          From-Tag=
                          To-Tag=y
ACK    ------------------>
CallId=x
From-Tag=
To-Tag=y
       <----------------- INVITE
                          CallId=x
                          From-Tag=
                          To-Tag=

Now the initial INVITE from the caller and the reINVITE from the callee 
look the same.  Suppose your proxy was a parallel forking B2BUA proxy who 
sent the INVITE in several different directions.  You got the 200 OK from 
the callee and ACK from the caller, but it may be that at some point after 
that, one of those other forks comes back though you again (on it's way to 
a destination on the other side of you).  Now how can you tell the 
difference between that forked INVITE and a reINVITE from the callee?  You 
can't, so you have to allow it through.  If, however, you had both a known 
To and From tag, and then you get an INVITE that just has a From tag, you 
instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow 
completes, you would get:

200 OK ------------------>
CallId=x
From-Tag=
To-Tag=z
       <----------------- ACK
                          CallId=x
                          From-Tag=
                          To-Tag=z

anyway, and doesn't that just end up specifying a From and To tag?  But by 
specifying the From and To tag up front, it's easier to follow the flow 
from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
callee).

- rob

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information 
to 
have the caller decide that this is a request on the same call. If you are
inferring that the Call-ID, although it is supposed to be unique, does not
provide this information, it is equally true that the From tag does not
provide this either. 

However, I do see a point. The fact that a From tag is present, does 
provide
an indication that this is a request on an exisisting dialog. It does, 
however,
raise the issue about the uniqueness of the To tag, the From tag and the 
Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique and 
that
another, again probably not so unique, parameter is added to determine 
whether 
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips" 
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a 
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no 
>From and no To tag but with a unique call-ID.  No problem so far.  The 
callee receives the call and inserts it's To tag in the response.  Again, 
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From 
and To to generate the request (so you can tell it's generated from the 
callee and not the caller)...but there's no From tag.  The call-ID is the 
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do 
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE 
request?  You don't know how to handle it because you don't have the 
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 15 03:41:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiSWN-0003jV-RR; Wed, 15 Jun 2005 03:41:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiSWG-0003j4-PS
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 03:41:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19366
	for <sip@ietf.org>; Wed, 15 Jun 2005 03:41:03 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiSsu-0004kl-7Q
	for sip@ietf.org; Wed, 15 Jun 2005 04:04:29 -0400
Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com
	[130.144.57.168])
	by gw-eur4.philips.com (Postfix) with ESMTP id C60B149733
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:40:49 +0000 (UTC)
Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP id 9CA4C147
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:40:49 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171])
	by smtpscan-eur5.philips.com (Postfix) with ESMTP id 86BFE143
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:40:49 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125])
	by smtprelay-eur2.philips.com (Postfix) with ESMTP id 5F2303D
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:40:49 +0000 (GMT)
To: sip@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF1AEA2116.61FA3A09-ONC1257021.0029E3C3-C1257021.002A2E79@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Wed, 15 Jun 2005 09:40:08 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 15/06/2005 09:40:10,
	Serialize complete at 15/06/2005 09:40:10
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: [Sip] Whatever became of SIP-B?
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

In 2003 an I-D about SIP-B was published. Although new references to 
SIP-B keep popping up, there is no visible activity on this subject.

Whatever happened to this initiative?

Cheers,

Frank


_______________________________________________
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 Jun 15 06:47:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiVR0-0004bw-KZ; Wed, 15 Jun 2005 06:47:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiVQy-0004br-6r
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 06:47:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00958
	for <sip@ietf.org>; Wed, 15 Jun 2005 06:47:45 -0400 (EDT)
Received: from nrmail01.netrake.com ([65.119.52.237] helo=nrmail01.netrake.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiVnd-0006on-Va
	for sip@ietf.org; Wed, 15 Jun 2005 07:11:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] The logic behind the From tag?
Date: Wed, 15 Jun 2005 05:47:45 -0500
Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD6F249D@nrmail01.netrake.net>
Thread-Topic: [Sip] The logic behind the From tag?
Thread-Index: AcVxEL4aB2r2TswIRNa6uY9JEAT3qgAhTMVw
From: "Rob Phillips" <rob@netrake.com>
To: "Frank Derks" <frank.derks@philips.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8
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

Apparently my description wasn't that clear.  Lemme draw it out:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=3Dx
From-Tag=3D
To-Tag=3D
             INVITE
             CallId=3Dx
             From-Tag=3D
             To-Tag=3D
             ------------->
             INVITE
             CallId=3Dx
             From-Tag=3D
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dy
              <---------- INVITE
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3D
              <-------------------------- INVITE
                                          CallId=3Dx
                                          From-Tag=3D
                                          To-Tag=3D

Now how did you tell the difference between the INVITE from the callee =
and the INVITE from the proxy?  You can't.  You could, though, if you =
had From-tags:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=3Dx
From-Tag=3Dz
To-Tag=3D
             INVITE
             CallId=3Dx
             From-Tag=3Dz
             To-Tag=3D
             ------------->
             INVITE
             CallId=3Dx
             From-Tag=3Dz
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3Dz
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3Dz
To-Tag=3Dy
              <---------- INVITE
                          CallId=3Dx
                          From-Tag=3Dy
                          To-Tag=3Dz
              <-------------------------- INVITE
                                          CallId=3Dx
                                          From-Tag=3Dz
                                          To-Tag=3D

- rob

-----Original Message-----
From: Frank Derks [mailto:frank.derks@philips.com]
Sent: Tuesday, June 14, 2005 1:41 PM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Rob,

Since the second INVITE does not contain any tags, it does not have the=20
same dialog ID as the already existing dialog! The first dialog has a=20
dialog ID that consists of an empty From tag, a Call-ID with the value x =

and a To tag with the value y. The second invite will, at the worst, =
have=20
an identical Call-ID and empty From and To tags. So there's no match.

I agree that including a From tag doesn't hurt a bit and we could argue=20
about it being an "elegant" to do the same thing for both directions.=20
However,I am just trying to understand why it would be necessary, =
because=20
the RFC does not give an explanation for this tag (it does have one for=20
the To tag).

Am I missing something in your example?

Cheers,

Frank











"Rob Phillips"=20
2005-06-14 02:34 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







I'm not saying the Call-Id can't be trusted to be unique, although it's=20
certainly possible (although unlikely) that it might not be unique.  I'm =

saying, having the From and To tag both help determine direction of a =
call=20
and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3D
       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dy
       <----------------- INVITE
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3D

Now the initial INVITE from the caller and the reINVITE from the callee=20
look the same.  Suppose your proxy was a parallel forking B2BUA proxy =
who=20
sent the INVITE in several different directions.  You got the 200 OK =
from=20
the callee and ACK from the caller, but it may be that at some point =
after=20
that, one of those other forks comes back though you again (on it's way =
to=20
a destination on the other side of you).  Now how can you tell the=20
difference between that forked INVITE and a reINVITE from the callee?  =
You=20
can't, so you have to allow it through.  If, however, you had both a =
known=20
To and From tag, and then you get an INVITE that just has a From tag, =
you=20
instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow=20
completes, you would get:

200 OK ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dz
       <----------------- ACK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dz

anyway, and doesn't that just end up specifying a From and To tag?  But =
by=20
specifying the From and To tag up front, it's easier to follow the flow=20
from the beginning (in terms of INVITE vs. re-INVITE and caller vs.=20
callee).

- rob

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information =

to=20
have the caller decide that this is a request on the same call. If you =
are
inferring that the Call-ID, although it is supposed to be unique, does =
not
provide this information, it is equally true that the From tag does not
provide this either.=20

However, I do see a point. The fact that a From tag is present, does=20
provide
an indication that this is a request on an exisisting dialog. It does,=20
however,
raise the issue about the uniqueness of the To tag, the From tag and the =

Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique =
and=20
that
another, again probably not so unique, parameter is added to determine=20
whether=20
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips"=20
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a=20
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no=20
>From and no To tag but with a unique call-ID.  No problem so far.  The=20
callee receives the call and inserts it's To tag in the response.  =
Again,=20
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From=20
and To to generate the request (so you can tell it's generated from the=20
callee and not the caller)...but there's no From tag.  The call-ID is =
the=20
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do=20
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE =

request?  You don't know how to handle it because you don't have the=20
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 15 07:36:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiWC7-0005OZ-C1; Wed, 15 Jun 2005 07:36:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWC5-0005OT-Je
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 07:36:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04186
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:36:28 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiWYj-00014h-B0
	for sip@ietf.org; Wed, 15 Jun 2005 07:59:56 -0400
Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com
	[130.144.57.168])
	by gw-eur4.philips.com (Postfix) with ESMTP id 6763F4977E;
	Wed, 15 Jun 2005 11:36:12 +0000 (UTC)
Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id B8ED07BF; Wed, 15 Jun 2005 11:31:42 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP
	id 9D32B528; Wed, 15 Jun 2005 11:31:42 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP
	id 5E12B3D; Wed, 15 Jun 2005 11:31:42 +0000 (GMT)
In-Reply-To: <7221140AD3DA7C4DB2CD49771243D8DD6F249D@nrmail01.netrake.net>
To: "Rob Phillips" <rob@netrake.com>
Subject: RE: [Sip] The logic behind the From tag?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OFB3188D7A.40A74C11-ONC1257021.003E7E68-C1257021.003F4AFD@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Wed, 15 Jun 2005 13:30:43 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 15/06/2005 13:31:03,
	Serialize complete at 15/06/2005 13:31:03
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d
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 Rob,

I don't know if you saw the response from ""Bala Neelakantan", who refers 
to 
the following expired draft RFC:

http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt

Section 7.1 gives one possible reason why the From tag would be required. 

In your new example I see two things that I do not quite understand:

1) Why would the proxy send an INVITE with no To-tag on the same Call-ID?
   This suggests that some party "behind" the proxy happens to have picked
   an identical Call-ID to establish a call to the Caller.
2) Why doesn't the callee add the To-tag in the INVITE to the caller?
   It was already clear that the To-tag makes sense, so I do not see why
   the callee adds it to the 200 OK, but doesn't add it to the re-INVITE.
   In your example it is not possible to distinguish between the INVITE
   from the Proxy and the Callee because the To-tag is left empty. They
   must be present and have unique and different values.

Cheers,

Frank










"Rob Phillips" 
2005-06-15 12:47 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







Apparently my description wasn't that clear.  Lemme draw it out:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=x
From-Tag=
To-Tag=
             INVITE
             CallId=x
             From-Tag=
             To-Tag=
             ------------->
             INVITE
             CallId=x
             From-Tag=
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=x
                          From-Tag=
                          To-Tag=y
ACK    ------------------>
CallId=x
From-Tag=
To-Tag=y
              <---------- INVITE
                          CallId=x
                          From-Tag=
                          To-Tag=
              <-------------------------- INVITE
                                          CallId=x
                                          From-Tag=
                                          To-Tag=

Now how did you tell the difference between the INVITE from the callee and 
the INVITE from the proxy?  You can't.  You could, though, if you had 
From-tags:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=x
From-Tag=z
To-Tag=
             INVITE
             CallId=x
             From-Tag=z
             To-Tag=
             ------------->
             INVITE
             CallId=x
             From-Tag=z
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=x
                          From-Tag=z
                          To-Tag=y
ACK    ------------------>
CallId=x
From-Tag=z
To-Tag=y
              <---------- INVITE
                          CallId=x
                          From-Tag=y
                          To-Tag=z
              <-------------------------- INVITE
                                          CallId=x
                                          From-Tag=z
                                          To-Tag=

- rob

-----Original Message-----
From: Frank Derks [mailto:frank.derks@philips.com]
Sent: Tuesday, June 14, 2005 1:41 PM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Rob,

Since the second INVITE does not contain any tags, it does not have the 
same dialog ID as the already existing dialog! The first dialog has a 
dialog ID that consists of an empty From tag, a Call-ID with the value x 
and a To tag with the value y. The second invite will, at the worst, have 
an identical Call-ID and empty From and To tags. So there's no match.

I agree that including a From tag doesn't hurt a bit and we could argue 
about it being an "elegant" to do the same thing for both directions. 
However,I am just trying to understand why it would be necessary, because 
the RFC does not give an explanation for this tag (it does have one for 
the To tag).

Am I missing something in your example?

Cheers,

Frank











"Rob Phillips" 
2005-06-14 02:34 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







I'm not saying the Call-Id can't be trusted to be unique, although it's 
certainly possible (although unlikely) that it might not be unique.  I'm 
saying, having the From and To tag both help determine direction of a call 

and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=x
From-Tag=
To-Tag=
       <----------------- 200 OK
                          CallId=x
                          From-Tag=
                          To-Tag=y
ACK    ------------------>
CallId=x
From-Tag=
To-Tag=y
       <----------------- INVITE
                          CallId=x
                          From-Tag=
                          To-Tag=

Now the initial INVITE from the caller and the reINVITE from the callee 
look the same.  Suppose your proxy was a parallel forking B2BUA proxy who 
sent the INVITE in several different directions.  You got the 200 OK from 
the callee and ACK from the caller, but it may be that at some point after 

that, one of those other forks comes back though you again (on it's way to 

a destination on the other side of you).  Now how can you tell the 
difference between that forked INVITE and a reINVITE from the callee?  You 

can't, so you have to allow it through.  If, however, you had both a known 

To and From tag, and then you get an INVITE that just has a From tag, you 
instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow 
completes, you would get:

200 OK ------------------>
CallId=x
From-Tag=
To-Tag=z
       <----------------- ACK
                          CallId=x
                          From-Tag=
                          To-Tag=z

anyway, and doesn't that just end up specifying a From and To tag?  But by 

specifying the From and To tag up front, it's easier to follow the flow 
from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
callee).

- rob

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information 
to 
have the caller decide that this is a request on the same call. If you are
inferring that the Call-ID, although it is supposed to be unique, does not
provide this information, it is equally true that the From tag does not
provide this either. 

However, I do see a point. The fact that a From tag is present, does 
provide
an indication that this is a request on an exisisting dialog. It does, 
however,
raise the issue about the uniqueness of the To tag, the From tag and the 
Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique and 
that
another, again probably not so unique, parameter is added to determine 
whether 
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips" 
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a 
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no 
>From and no To tag but with a unique call-ID.  No problem so far.  The 
callee receives the call and inserts it's To tag in the response.  Again, 
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From 
and To to generate the request (so you can tell it's generated from the 
callee and not the caller)...but there's no From tag.  The call-ID is the 
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do 
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE 
request?  You don't know how to handle it because you don't have the 
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 15 07:43:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiWIb-0006te-8W; Wed, 15 Jun 2005 07:43:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWIa-0006tZ-05
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 07:43:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04703
	for <sip@ietf.org>; Wed, 15 Jun 2005 07:43:11 -0400 (EDT)
Received: from nrmail01.netrake.com ([65.119.52.237] helo=nrmail01.netrake.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiWfG-0001aQ-7y
	for sip@ietf.org; Wed, 15 Jun 2005 08:06:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] The logic behind the From tag?
Date: Wed, 15 Jun 2005 06:43:18 -0500
Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD6F249F@nrmail01.netrake.net>
Thread-Topic: [Sip] The logic behind the From tag?
Thread-Index: AcVxnn7tpo6a/KZqSXi6+qdtlo28eAAABFuQ
From: "Rob Phillips" <rob@netrake.com>
To: "Frank Derks" <frank.derks@philips.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c
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

The callee doesn't add the To-tag, because when the callee sends the =
message, he is now the From, not the To, and you have to swap To and =
>From accordingly.  Since the assertion is we don't have From tags, we =
can't send the original To tag (from the 200 OK response) in the From =
tag.  Voila, no tags.

The reason the proxy sent the INVITE with the same call-ID is because =
it's just the forked request from the original INVITE.  The timing of =
the message (mabye it went through several proxies along the way, you =
don't know for sure) just made it come back through our forking proxy =
again after we had already received a final response.

- rob

-----Original Message-----
From: Frank Derks [mailto:frank.derks@philips.com]
Sent: Wednesday, June 15, 2005 6:31 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

I don't know if you saw the response from ""Bala Neelakantan", who =
refers=20
to=20
the following expired draft RFC:

http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt

Section 7.1 gives one possible reason why the From tag would be =
required.=20

In your new example I see two things that I do not quite understand:

1) Why would the proxy send an INVITE with no To-tag on the same =
Call-ID?
   This suggests that some party "behind" the proxy happens to have =
picked
   an identical Call-ID to establish a call to the Caller.
2) Why doesn't the callee add the To-tag in the INVITE to the caller?
   It was already clear that the To-tag makes sense, so I do not see why
   the callee adds it to the 200 OK, but doesn't add it to the =
re-INVITE.
   In your example it is not possible to distinguish between the INVITE
   from the Proxy and the Callee because the To-tag is left empty. They
   must be present and have unique and different values.

Cheers,

Frank










"Rob Phillips"=20
2005-06-15 12:47 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







Apparently my description wasn't that clear.  Lemme draw it out:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=3Dx
From-Tag=3D
To-Tag=3D
             INVITE
             CallId=3Dx
             From-Tag=3D
             To-Tag=3D
             ------------->
             INVITE
             CallId=3Dx
             From-Tag=3D
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dy
              <---------- INVITE
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3D
              <-------------------------- INVITE
                                          CallId=3Dx
                                          From-Tag=3D
                                          To-Tag=3D

Now how did you tell the difference between the INVITE from the callee =
and=20
the INVITE from the proxy?  You can't.  You could, though, if you had=20
From-tags:

             Parallel
             Forking
-Caller-     -Proxy-      -Callee-      -Proxy-
INVITE --------->
CallId=3Dx
From-Tag=3Dz
To-Tag=3D
             INVITE
             CallId=3Dx
             From-Tag=3Dz
             To-Tag=3D
             ------------->
             INVITE
             CallId=3Dx
             From-Tag=3Dz
             To-Tag
             --------------------------->

       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3Dz
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3Dz
To-Tag=3Dy
              <---------- INVITE
                          CallId=3Dx
                          From-Tag=3Dy
                          To-Tag=3Dz
              <-------------------------- INVITE
                                          CallId=3Dx
                                          From-Tag=3Dz
                                          To-Tag=3D

- rob

-----Original Message-----
From: Frank Derks [mailto:frank.derks@philips.com]
Sent: Tuesday, June 14, 2005 1:41 PM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Rob,

Since the second INVITE does not contain any tags, it does not have the=20
same dialog ID as the already existing dialog! The first dialog has a=20
dialog ID that consists of an empty From tag, a Call-ID with the value x =

and a To tag with the value y. The second invite will, at the worst, =
have=20
an identical Call-ID and empty From and To tags. So there's no match.

I agree that including a From tag doesn't hurt a bit and we could argue=20
about it being an "elegant" to do the same thing for both directions.=20
However,I am just trying to understand why it would be necessary, =
because=20
the RFC does not give an explanation for this tag (it does have one for=20
the To tag).

Am I missing something in your example?

Cheers,

Frank











"Rob Phillips"=20
2005-06-14 02:34 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
<sip@ietf.org>
Subject
RE: [Sip] The logic behind the From tag?
Classification







I'm not saying the Call-Id can't be trusted to be unique, although it's=20
certainly possible (although unlikely) that it might not be unique.  I'm =

saying, having the From and To tag both help determine direction of a =
call=20

and provide additional guarantees to the uniqueness of the call.

Let me give you another thought:

-Caller-     -Proxy-      -Callee-
INVITE ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3D
       <----------------- 200 OK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dy
ACK    ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dy
       <----------------- INVITE
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3D

Now the initial INVITE from the caller and the reINVITE from the callee=20
look the same.  Suppose your proxy was a parallel forking B2BUA proxy =
who=20
sent the INVITE in several different directions.  You got the 200 OK =
from=20
the callee and ACK from the caller, but it may be that at some point =
after=20

that, one of those other forks comes back though you again (on it's way =
to=20

a destination on the other side of you).  Now how can you tell the=20
difference between that forked INVITE and a reINVITE from the callee?  =
You=20

can't, so you have to allow it through.  If, however, you had both a =
known=20

To and From tag, and then you get an INVITE that just has a From tag, =
you=20
instantly know it's not allowed and can return an error accordingly.

In the end, what does sending a From tag hurt, anyway?  After this flow=20
completes, you would get:

200 OK ------------------>
CallId=3Dx
From-Tag=3D
To-Tag=3Dz
       <----------------- ACK
                          CallId=3Dx
                          From-Tag=3D
                          To-Tag=3Dz

anyway, and doesn't that just end up specifying a From and To tag?  But =
by=20

specifying the From and To tag up front, it's easier to follow the flow=20
from the beginning (in terms of INVITE vs. re-INVITE and caller vs.=20
callee).

- rob

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Frank Derks
Sent: Tuesday, June 14, 2005 6:20 AM
To: Rob Phillips
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?


Hi Rob,

The fact that the callee uses the same Call-ID is sufficient information =

to=20
have the caller decide that this is a request on the same call. If you =
are
inferring that the Call-ID, although it is supposed to be unique, does =
not
provide this information, it is equally true that the From tag does not
provide this either.=20

However, I do see a point. The fact that a From tag is present, does=20
provide
an indication that this is a request on an exisisting dialog. It does,=20
however,
raise the issue about the uniqueness of the To tag, the From tag and the =

Call-ID.

What you're saying is that the Call-ID cannot be trusted to be unique =
and=20
that
another, again probably not so unique, parameter is added to determine=20
whether=20
or not a request belongs to an existing dialog.

Cheers,

Frank









"Rob Phillips"=20
2005-06-14 12:02 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
<sip@ietf.org>
cc

Subject
RE: [Sip] The logic behind the From tag?
Classification







Actually, I'd say the From tag is there to determine the direction of a=20
call and it's validity.

Consider if you had no From tag: you send out an initial INVITE with no=20
>From and no To tag but with a unique call-ID.  No problem so far.  The=20
callee receives the call and inserts it's To tag in the response.  =
Again,=20
no problem.

Now the callee wants to put the call on hold.  OK, so it now swaps From=20
and To to generate the request (so you can tell it's generated from the=20
callee and not the caller)...but there's no From tag.  The call-ID is =
the=20
same, but it looks like a new request: no From tag, no To tag.

The original caller gets this request and ... what is he supposed to do=20
with it?  Is it a re-INVITE?  A separate call?  What if was a non-INVITE =

request?  You don't know how to handle it because you don't have the=20
To/From tag combination to tell you what is going on.

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074



_______________________________________________
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 Jun 15 10:14:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiYbA-00076G-4U; Wed, 15 Jun 2005 10:10:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYb9-00075h-1v
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 10:10:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18739
	for <sip@ietf.org>; Wed, 15 Jun 2005 10:10:28 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiYxo-0002Cn-Bp
	for sip@ietf.org; Wed, 15 Jun 2005 10:33:58 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com
	[135.221.14.69])
	by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5FEAJ4q029953; 
	Wed, 15 Jun 2005 09:10:20 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
	(5.5.2657.72) id <KWCQW93K>; Wed, 15 Jun 2005 15:10:18 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00C2904D5@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Frank Derks'" <frank.derks@philips.com>
Subject: RE: [Sip] The logic behind the From tag?
Date: Wed, 15 Jun 2005 15:10:16 +0100
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: 00134749b78ab2213964fc53d03de937
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

Drafts normally expire and get removed from the i-d directory when an RFC is approved.

Please refer to RFC 4028 if you wish to address thus discussion, and given that session-timer reached -15 before being approved as this RFC, it might me wise to ensure that the discussion point still applies after such a large number of revisions.

regards

Keith

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: 15 June 2005 12:31
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> I don't know if you saw the response from ""Bala 
> Neelakantan", who refers 
> to 
> the following expired draft RFC:
> 
> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt
> 
> Section 7.1 gives one possible reason why the From tag would 
> be required. 
> 
> In your new example I see two things that I do not quite understand:
> 
> 1) Why would the proxy send an INVITE with no To-tag on the 
> same Call-ID?
>    This suggests that some party "behind" the proxy happens 
> to have picked
>    an identical Call-ID to establish a call to the Caller.
> 2) Why doesn't the callee add the To-tag in the INVITE to the caller?
>    It was already clear that the To-tag makes sense, so I do 
> not see why
>    the callee adds it to the 200 OK, but doesn't add it to 
> the re-INVITE.
>    In your example it is not possible to distinguish between 
> the INVITE
>    from the Proxy and the Callee because the To-tag is left 
> empty. They
>    must be present and have unique and different values.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-15 12:47 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Apparently my description wasn't that clear.  Lemme draw it out:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=
>                                           To-Tag=
> 
> Now how did you tell the difference between the INVITE from 
> the callee and 
> the INVITE from the proxy?  You can't.  You could, though, if you had 
> From-tags:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=z
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=z
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=z
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=y
>                           To-Tag=z
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=z
>                                           To-Tag=
> 
> - rob
> 
> -----Original Message-----
> From: Frank Derks [mailto:frank.derks@philips.com]
> Sent: Tuesday, June 14, 2005 1:41 PM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Rob,
> 
> Since the second INVITE does not contain any tags, it does 
> not have the 
> same dialog ID as the already existing dialog! The first dialog has a 
> dialog ID that consists of an empty From tag, a Call-ID with 
> the value x 
> and a To tag with the value y. The second invite will, at the 
> worst, have 
> an identical Call-ID and empty From and To tags. So there's no match.
> 
> I agree that including a From tag doesn't hurt a bit and we 
> could argue 
> about it being an "elegant" to do the same thing for both directions. 
> However,I am just trying to understand why it would be 
> necessary, because 
> the RFC does not give an explanation for this tag (it does 
> have one for 
> the To tag).
> 
> Am I missing something in your example?
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 02:34 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> I'm not saying the Call-Id can't be trusted to be unique, 
> although it's 
> certainly possible (although unlikely) that it might not be 
> unique.  I'm 
> saying, having the From and To tag both help determine 
> direction of a call 
> 
> and provide additional guarantees to the uniqueness of the call.
> 
> Let me give you another thought:
> 
> -Caller-     -Proxy-      -Callee-
> INVITE ------------------>
> CallId=x
> From-Tag=
> To-Tag=
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>        <----------------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
> 
> Now the initial INVITE from the caller and the reINVITE from 
> the callee 
> look the same.  Suppose your proxy was a parallel forking 
> B2BUA proxy who 
> sent the INVITE in several different directions.  You got the 
> 200 OK from 
> the callee and ACK from the caller, but it may be that at 
> some point after 
> 
> that, one of those other forks comes back though you again 
> (on it's way to 
> 
> a destination on the other side of you).  Now how can you tell the 
> difference between that forked INVITE and a reINVITE from the 
> callee?  You 
> 
> can't, so you have to allow it through.  If, however, you had 
> both a known 
> 
> To and From tag, and then you get an INVITE that just has a 
> From tag, you 
> instantly know it's not allowed and can return an error accordingly.
> 
> In the end, what does sending a From tag hurt, anyway?  After 
> this flow 
> completes, you would get:
> 
> 200 OK ------------------>
> CallId=x
> From-Tag=
> To-Tag=z
>        <----------------- ACK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=z
> 
> anyway, and doesn't that just end up specifying a From and To 
> tag?  But by 
> 
> specifying the From and To tag up front, it's easier to 
> follow the flow 
> from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
> callee).
> 
> - rob
> 
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: Tuesday, June 14, 2005 6:20 AM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> The fact that the callee uses the same Call-ID is sufficient 
> information 
> to 
> have the caller decide that this is a request on the same 
> call. If you are
> inferring that the Call-ID, although it is supposed to be 
> unique, does not
> provide this information, it is equally true that the From 
> tag does not
> provide this either. 
> 
> However, I do see a point. The fact that a From tag is present, does 
> provide
> an indication that this is a request on an exisisting dialog. 
> It does, 
> however,
> raise the issue about the uniqueness of the To tag, the From 
> tag and the 
> Call-ID.
> 
> What you're saying is that the Call-ID cannot be trusted to 
> be unique and 
> that
> another, again probably not so unique, parameter is added to 
> determine 
> whether 
> or not a request belongs to an existing dialog.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 12:02 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> <sip@ietf.org>
> cc
> 
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Actually, I'd say the From tag is there to determine the 
> direction of a 
> call and it's validity.
> 
> Consider if you had no From tag: you send out an initial 
> INVITE with no 
> >From and no To tag but with a unique call-ID.  No problem so 
> far.  The 
> callee receives the call and inserts it's To tag in the 
> response.  Again, 
> no problem.
> 
> Now the callee wants to put the call on hold.  OK, so it now 
> swaps From 
> and To to generate the request (so you can tell it's 
> generated from the 
> callee and not the caller)...but there's no From tag.  The 
> call-ID is the 
> same, but it looks like a new request: no From tag, no To tag.
> 
> The original caller gets this request and ... what is he 
> supposed to do 
> with it?  Is it a re-INVITE?  A separate call?  What if was a 
> non-INVITE 
> request?  You don't know how to handle it because you don't have the 
> To/From tag combination to tell you what is going on.
> 
> - rob
> 
> --
> Rob Phillips, Sr. Software Engineer                 Netrake 
> Corporation
> mailto: rob@netrake.com                           3000 
> Technology Drive
> voice: (214) 291-1096                                         
> Suite 100
> fax:   (214) 291-1010     http://www.netrake.com     Plano, 
> Texas 75074
> 
> 
> 
> _______________________________________________
> 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 Jun 15 10:18:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiYiy-0000ex-7f; Wed, 15 Jun 2005 10:18:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiYiv-0000eo-Uk; Wed, 15 Jun 2005 10:18:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19936;
	Wed, 15 Jun 2005 10:18:31 -0400 (EDT)
Received: from gw-eur4.philips.com ([161.85.125.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DiZ5d-0002sl-9w; Wed, 15 Jun 2005 10:42:02 -0400
Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com
	[130.144.57.168])
	by gw-eur4.philips.com (Postfix) with ESMTP id 4B62549734;
	Wed, 15 Jun 2005 14:18:23 +0000 (UTC)
Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1])
	by localhost.philips.com (Postfix) with ESMTP
	id 13D63160; Wed, 15 Jun 2005 14:18:23 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com
	[130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP
	id E7E02174; Wed, 15 Jun 2005 14:18:22 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com
	[130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP
	id BA9953F; Wed, 15 Jun 2005 14:18:22 +0000 (GMT)
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2904D5@en0033exch001u.uk.lucent.com>
To: "Drage, Keith (Keith)" <drage@lucent.com>
Subject: RE: [Sip] The logic behind the From tag?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OFEAD8C1AE.A524DB72-ONC1257021.004E54F7-C1257021.004E93EB@philips.com>
From: Frank Derks <frank.derks@philips.com>
Date: Wed, 15 Jun 2005 16:17:40 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release
	6.5.3FP1HF80 | March 11, 2005) at 15/06/2005 16:17:43,
	Serialize complete at 15/06/2005 16:17:43
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3
Cc: sip@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

Keith,

I agree that it is not good practice to refer to expired Internet Drafts, 
however, in this case this was necessary because that draft contains 
information that is no longer present in the RFC!

Cheers,

Frank









"Drage, Keith (Keith)" 
Sent by:
sip-bounces@ietf.org
2005-06-15 04:10 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
sip@ietf.org
Subject
RE: [Sip] The logic behind the From tag?
Classification







Drafts normally expire and get removed from the i-d directory when an RFC 
is approved.

Please refer to RFC 4028 if you wish to address thus discussion, and given 
that session-timer reached -15 before being approved as this RFC, it might 
me wise to ensure that the discussion point still applies after such a 
large number of revisions.

regards

Keith

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: 15 June 2005 12:31
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> I don't know if you saw the response from ""Bala 
> Neelakantan", who refers 
> to 
> the following expired draft RFC:
> 
> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt
> 
> Section 7.1 gives one possible reason why the From tag would 
> be required. 
> 
> In your new example I see two things that I do not quite understand:
> 
> 1) Why would the proxy send an INVITE with no To-tag on the 
> same Call-ID?
>    This suggests that some party "behind" the proxy happens 
> to have picked
>    an identical Call-ID to establish a call to the Caller.
> 2) Why doesn't the callee add the To-tag in the INVITE to the caller?
>    It was already clear that the To-tag makes sense, so I do 
> not see why
>    the callee adds it to the 200 OK, but doesn't add it to 
> the re-INVITE.
>    In your example it is not possible to distinguish between 
> the INVITE
>    from the Proxy and the Callee because the To-tag is left 
> empty. They
>    must be present and have unique and different values.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-15 12:47 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Apparently my description wasn't that clear.  Lemme draw it out:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=
>                                           To-Tag=
> 
> Now how did you tell the difference between the INVITE from 
> the callee and 
> the INVITE from the proxy?  You can't.  You could, though, if you had 
> From-tags:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=z
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=z
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=z
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=y
>                           To-Tag=z
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=z
>                                           To-Tag=
> 
> - rob
> 
> -----Original Message-----
> From: Frank Derks [mailto:frank.derks@philips.com]
> Sent: Tuesday, June 14, 2005 1:41 PM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Rob,
> 
> Since the second INVITE does not contain any tags, it does 
> not have the 
> same dialog ID as the already existing dialog! The first dialog has a 
> dialog ID that consists of an empty From tag, a Call-ID with 
> the value x 
> and a To tag with the value y. The second invite will, at the 
> worst, have 
> an identical Call-ID and empty From and To tags. So there's no match.
> 
> I agree that including a From tag doesn't hurt a bit and we 
> could argue 
> about it being an "elegant" to do the same thing for both directions. 
> However,I am just trying to understand why it would be 
> necessary, because 
> the RFC does not give an explanation for this tag (it does 
> have one for 
> the To tag).
> 
> Am I missing something in your example?
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 02:34 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> I'm not saying the Call-Id can't be trusted to be unique, 
> although it's 
> certainly possible (although unlikely) that it might not be 
> unique.  I'm 
> saying, having the From and To tag both help determine 
> direction of a call 
> 
> and provide additional guarantees to the uniqueness of the call.
> 
> Let me give you another thought:
> 
> -Caller-     -Proxy-      -Callee-
> INVITE ------------------>
> CallId=x
> From-Tag=
> To-Tag=
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>        <----------------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
> 
> Now the initial INVITE from the caller and the reINVITE from 
> the callee 
> look the same.  Suppose your proxy was a parallel forking 
> B2BUA proxy who 
> sent the INVITE in several different directions.  You got the 
> 200 OK from 
> the callee and ACK from the caller, but it may be that at 
> some point after 
> 
> that, one of those other forks comes back though you again 
> (on it's way to 
> 
> a destination on the other side of you).  Now how can you tell the 
> difference between that forked INVITE and a reINVITE from the 
> callee?  You 
> 
> can't, so you have to allow it through.  If, however, you had 
> both a known 
> 
> To and From tag, and then you get an INVITE that just has a 
> From tag, you 
> instantly know it's not allowed and can return an error accordingly.
> 
> In the end, what does sending a From tag hurt, anyway?  After 
> this flow 
> completes, you would get:
> 
> 200 OK ------------------>
> CallId=x
> From-Tag=
> To-Tag=z
>        <----------------- ACK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=z
> 
> anyway, and doesn't that just end up specifying a From and To 
> tag?  But by 
> 
> specifying the From and To tag up front, it's easier to 
> follow the flow 
> from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
> callee).
> 
> - rob
> 
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: Tuesday, June 14, 2005 6:20 AM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> The fact that the callee uses the same Call-ID is sufficient 
> information 
> to 
> have the caller decide that this is a request on the same 
> call. If you are
> inferring that the Call-ID, although it is supposed to be 
> unique, does not
> provide this information, it is equally true that the From 
> tag does not
> provide this either. 
> 
> However, I do see a point. The fact that a From tag is present, does 
> provide
> an indication that this is a request on an exisisting dialog. 
> It does, 
> however,
> raise the issue about the uniqueness of the To tag, the From 
> tag and the 
> Call-ID.
> 
> What you're saying is that the Call-ID cannot be trusted to 
> be unique and 
> that
> another, again probably not so unique, parameter is added to 
> determine 
> whether 
> or not a request belongs to an existing dialog.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 12:02 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> <sip@ietf.org>
> cc
> 
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Actually, I'd say the From tag is there to determine the 
> direction of a 
> call and it's validity.
> 
> Consider if you had no From tag: you send out an initial 
> INVITE with no 
> >From and no To tag but with a unique call-ID.  No problem so 
> far.  The 
> callee receives the call and inserts it's To tag in the 
> response.  Again, 
> no problem.
> 
> Now the callee wants to put the call on hold.  OK, so it now 
> swaps From 
> and To to generate the request (so you can tell it's 
> generated from the 
> callee and not the caller)...but there's no From tag.  The 
> call-ID is the 
> same, but it looks like a new request: no From tag, no To tag.
> 
> The original caller gets this request and ... what is he 
> supposed to do 
> with it?  Is it a re-INVITE?  A separate call?  What if was a 
> non-INVITE 
> request?  You don't know how to handle it because you don't have the 
> To/From tag combination to tell you what is going on.
> 
> - rob
> 
> --
> Rob Phillips, Sr. Software Engineer                 Netrake 
> Corporation
> mailto: rob@netrake.com                           3000 
> Technology Drive
> voice: (214) 291-1096 
> Suite 100
> fax:   (214) 291-1010     http://www.netrake.com     Plano, 
> Texas 75074
> 
> 
> 
> _______________________________________________
> 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 Wed Jun 15 10:39:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiZ2k-0005dc-An; Wed, 15 Jun 2005 10:39:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZ2i-0005dU-LY
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 10:39:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22360
	for <sip@ietf.org>; Wed, 15 Jun 2005 10:38:58 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiZPO-0004Jy-Mc
	for sip@ietf.org; Wed, 15 Jun 2005 11:02:28 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id A034C6C029
	for <sip@ietf.org>; Wed, 15 Jun 2005 10:38:52 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: <sip@ietf.org>
Subject: RE: [Sip] Whatever became of SIP-B?
Date: Wed, 15 Jun 2005 10:37:21 -0400
Message-ID: <006101c571b7$bdf98f50$6a01010a@keywest>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <OF1AEA2116.61FA3A09-ONC1257021.0029E3C3-C1257021.002A2E79@philips.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
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

> From: Frank Derks
>
> In 2003 an I-D about SIP-B was published. Although new references to
> SIP-B keep popping up, there is no visible activity on this subject.
>
> Whatever happened to this initiative?

SIP-B is a collection of features and techniques, so there may be no unique
answer.  That being said, sipX implements "call pick-up" according to the
SIP-B method (which is a straightforward application of SIP techniques).

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 Jun 15 11:24:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiZkG-0007Vy-Ae; Wed, 15 Jun 2005 11:24:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZkD-0007Vq-Rt
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 11:23:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26121
	for <sip@ietf.org>; Wed, 15 Jun 2005 11:23:55 -0400 (EDT)
Received: from sitemail2.everyone.net ([216.200.145.36]
	helo=omta18.mta.everyone.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dia6v-00076o-Oi
	for sip@ietf.org; Wed, 15 Jun 2005 11:47:26 -0400
Received: from pmta02.mta.everyone.net (bigiplb-dsnat [172.16.0.19])
	by omta18.mta.everyone.net (Postfix) with ESMTP
	id 80DC1402DC; Wed, 15 Jun 2005 08:23:50 -0700 (PDT)
X-Eon-Sig: AQIH5JVCsEgG4PucKAIAAAAD,db6d242dac03cf778c55ce5624dee2f2
Received: from NeelLT (207.49.162.2 [207.49.162.2])
	by pmta02.mta.everyone.net (EON-AUTHRELAY) with ESMTP
	id E4D211B3; Wed, 15 Jun 2005 08:23:50 -0700
From: "Bala Neelakantan" <neel@quintum.com>
To: "'Drage, Keith (Keith)'" <drage@lucent.com>,
	"'Frank Derks'" <frank.derks@philips.com>
Subject: RE: [Sip] The logic behind the From tag?
Date: Wed, 15 Jun 2005 10:24:06 -0500
Message-ID: <000c01c571be$457c5bf0$9e02a8c0@NeelLT>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2904D5@en0033exch001u.uk.lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: balasubramanian_neelakantan@quintum.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

Drage,

Yes, I agree that draft should not be referred.  Sorry.  But the
original poster was asking about the reason behind it.  I searched the
SIP mailing list for reference and came across the reference.  The
reference for the logic behind the "from" tag has been removed from the
later drats and RFC.  Also I remember some explanation given about from
Tag in the rfc2543bis.

Thanks,
Neel


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Drage, Keith (Keith)
Sent: Wednesday, June 15, 2005 9:10 AM
To: 'Frank Derks'
Cc: sip@ietf.org
Subject: RE: [Sip] The logic behind the From tag?

Drafts normally expire and get removed from the i-d directory when an
RFC is approved.

Please refer to RFC 4028 if you wish to address thus discussion, and
given that session-timer reached -15 before being approved as this RFC,
it might me wise to ensure that the discussion point still applies after
such a large number of revisions.

regards

Keith

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: 15 June 2005 12:31
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> I don't know if you saw the response from ""Bala 
> Neelakantan", who refers 
> to 
> the following expired draft RFC:
> 
> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-session-timer-06.txt
> 
> Section 7.1 gives one possible reason why the From tag would 
> be required. 
> 
> In your new example I see two things that I do not quite understand:
> 
> 1) Why would the proxy send an INVITE with no To-tag on the 
> same Call-ID?
>    This suggests that some party "behind" the proxy happens 
> to have picked
>    an identical Call-ID to establish a call to the Caller.
> 2) Why doesn't the callee add the To-tag in the INVITE to the caller?
>    It was already clear that the To-tag makes sense, so I do 
> not see why
>    the callee adds it to the 200 OK, but doesn't add it to 
> the re-INVITE.
>    In your example it is not possible to distinguish between 
> the INVITE
>    from the Proxy and the Callee because the To-tag is left 
> empty. They
>    must be present and have unique and different values.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-15 12:47 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Apparently my description wasn't that clear.  Lemme draw it out:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=
>                                           To-Tag=
> 
> Now how did you tell the difference between the INVITE from 
> the callee and 
> the INVITE from the proxy?  You can't.  You could, though, if you had 
> From-tags:
> 
>              Parallel
>              Forking
> -Caller-     -Proxy-      -Callee-      -Proxy-
> INVITE --------->
> CallId=x
> From-Tag=z
> To-Tag=
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag=
>              ------------->
>              INVITE
>              CallId=x
>              From-Tag=z
>              To-Tag
>              --------------------------->
> 
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=z
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=z
> To-Tag=y
>               <---------- INVITE
>                           CallId=x
>                           From-Tag=y
>                           To-Tag=z
>               <-------------------------- INVITE
>                                           CallId=x
>                                           From-Tag=z
>                                           To-Tag=
> 
> - rob
> 
> -----Original Message-----
> From: Frank Derks [mailto:frank.derks@philips.com]
> Sent: Tuesday, June 14, 2005 1:41 PM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Rob,
> 
> Since the second INVITE does not contain any tags, it does 
> not have the 
> same dialog ID as the already existing dialog! The first dialog has a 
> dialog ID that consists of an empty From tag, a Call-ID with 
> the value x 
> and a To tag with the value y. The second invite will, at the 
> worst, have 
> an identical Call-ID and empty From and To tags. So there's no match.
> 
> I agree that including a From tag doesn't hurt a bit and we 
> could argue 
> about it being an "elegant" to do the same thing for both directions. 
> However,I am just trying to understand why it would be 
> necessary, because 
> the RFC does not give an explanation for this tag (it does 
> have one for 
> the To tag).
> 
> Am I missing something in your example?
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 02:34 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> cc
> <sip@ietf.org>
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> I'm not saying the Call-Id can't be trusted to be unique, 
> although it's 
> certainly possible (although unlikely) that it might not be 
> unique.  I'm 
> saying, having the From and To tag both help determine 
> direction of a call 
> 
> and provide additional guarantees to the uniqueness of the call.
> 
> Let me give you another thought:
> 
> -Caller-     -Proxy-      -Callee-
> INVITE ------------------>
> CallId=x
> From-Tag=
> To-Tag=
>        <----------------- 200 OK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=y
> ACK    ------------------>
> CallId=x
> From-Tag=
> To-Tag=y
>        <----------------- INVITE
>                           CallId=x
>                           From-Tag=
>                           To-Tag=
> 
> Now the initial INVITE from the caller and the reINVITE from 
> the callee 
> look the same.  Suppose your proxy was a parallel forking 
> B2BUA proxy who 
> sent the INVITE in several different directions.  You got the 
> 200 OK from 
> the callee and ACK from the caller, but it may be that at 
> some point after 
> 
> that, one of those other forks comes back though you again 
> (on it's way to 
> 
> a destination on the other side of you).  Now how can you tell the 
> difference between that forked INVITE and a reINVITE from the 
> callee?  You 
> 
> can't, so you have to allow it through.  If, however, you had 
> both a known 
> 
> To and From tag, and then you get an INVITE that just has a 
> From tag, you 
> instantly know it's not allowed and can return an error accordingly.
> 
> In the end, what does sending a From tag hurt, anyway?  After 
> this flow 
> completes, you would get:
> 
> 200 OK ------------------>
> CallId=x
> From-Tag=
> To-Tag=z
>        <----------------- ACK
>                           CallId=x
>                           From-Tag=
>                           To-Tag=z
> 
> anyway, and doesn't that just end up specifying a From and To 
> tag?  But by 
> 
> specifying the From and To tag up front, it's easier to 
> follow the flow 
> from the beginning (in terms of INVITE vs. re-INVITE and caller vs. 
> callee).
> 
> - rob
> 
> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Frank Derks
> Sent: Tuesday, June 14, 2005 6:20 AM
> To: Rob Phillips
> Cc: sip@ietf.org
> Subject: RE: [Sip] The logic behind the From tag?
> 
> 
> Hi Rob,
> 
> The fact that the callee uses the same Call-ID is sufficient 
> information 
> to 
> have the caller decide that this is a request on the same 
> call. If you are
> inferring that the Call-ID, although it is supposed to be 
> unique, does not
> provide this information, it is equally true that the From 
> tag does not
> provide this either. 
> 
> However, I do see a point. The fact that a From tag is present, does 
> provide
> an indication that this is a request on an exisisting dialog. 
> It does, 
> however,
> raise the issue about the uniqueness of the To tag, the From 
> tag and the 
> Call-ID.
> 
> What you're saying is that the Call-ID cannot be trusted to 
> be unique and 
> that
> another, again probably not so unique, parameter is added to 
> determine 
> whether 
> or not a request belongs to an existing dialog.
> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Rob Phillips" 
> 2005-06-14 12:02 PM
> 
> To
> Frank Derks/HVS/BE/PHILIPS@PHILIPS
> <sip@ietf.org>
> cc
> 
> Subject
> RE: [Sip] The logic behind the From tag?
> Classification
> 
> 
> 
> 
> 
> 
> 
> Actually, I'd say the From tag is there to determine the 
> direction of a 
> call and it's validity.
> 
> Consider if you had no From tag: you send out an initial 
> INVITE with no 
> >From and no To tag but with a unique call-ID.  No problem so 
> far.  The 
> callee receives the call and inserts it's To tag in the 
> response.  Again, 
> no problem.
> 
> Now the callee wants to put the call on hold.  OK, so it now 
> swaps From 
> and To to generate the request (so you can tell it's 
> generated from the 
> callee and not the caller)...but there's no From tag.  The 
> call-ID is the 
> same, but it looks like a new request: no From tag, no To tag.
> 
> The original caller gets this request and ... what is he 
> supposed to do 
> with it?  Is it a re-INVITE?  A separate call?  What if was a 
> non-INVITE 
> request?  You don't know how to handle it because you don't have the 
> To/From tag combination to tell you what is going on.
> 
> - rob
> 
> --
> Rob Phillips, Sr. Software Engineer                 Netrake 
> Corporation
> mailto: rob@netrake.com                           3000 
> Technology Drive
> voice: (214) 291-1096                                         
> Suite 100
> fax:   (214) 291-1010     http://www.netrake.com     Plano, 
> Texas 75074
> 
> 
> 
> _______________________________________________
> 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 Wed Jun 15 23:34:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dil8w-0007mP-Gt; Wed, 15 Jun 2005 23:34:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dil8u-0007m9-JK
	for sip@megatron.ietf.org; Wed, 15 Jun 2005 23:34:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11205
	for <sip@ietf.org>; Wed, 15 Jun 2005 23:34:06 -0400 (EDT)
Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DilVd-0004yV-LH
	for sip@ietf.org; Wed, 15 Jun 2005 23:57:44 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0II500KAJQUXA6@usaga01-in.huawei.com> for
	sip@ietf.org; Wed, 15 Jun 2005 20:25:45 -0700 (PDT)
Received: from huawei.com ([172.17.1.188])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0II500FRVQUWS0@usaga01-in.huawei.com> for
	sip@ietf.org; Wed, 15 Jun 2005 20:25:45 -0700 (PDT)
Received: from [172.24.1.6] (Forwarded-For: [10.18.3.138])
	by szxmc01-in.huawei.com (mshttpd); Thu, 16 Jun 2005 08:29:51 +0500
Date: Thu, 16 Jun 2005 08:29:51 +0500
From: DarshanBildikar 70559 <darshanb@huawei.com>
To: sip@ietf.org
Message-id: <17a37ad17a3e29.17a3e2917a37ad@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7BIT
Subject: [Sip] Question regarding reliable provisional response
	retransmission
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



----- Reposting on sip as suggested


The SIP RFC says that 

"A proxy has the option of canceling a transaction when there is a gap
of 3 minutes between responses in a transaction.  To prevent
cancellation, the UAS MUST send a non-100 provisional response at every
minute, to handle the possibility of lost provisional responses"

Assume a B2BUA has generated a request on behalf of a caller. When the
callee responds with a 180 Ringing message (with SDP) the B2BUA
negotiates the callee to the caller (who might be connected to a media
server, for example) so that a Ring back tone can be played or an IVR
session ensues. 

My queries are as follows

1) RFC 3262 states that reliable provisional responses are to be
retransmitted every two and a half minutes. Why is this really required
since the response is after all "reliable" !

2) Should the retransmitted provisional response always contain the same
SDP? i.e. Should I only consider the first SDP and ignore SDP's in
subsequent messages?

Any help is appreciated.


Dean Willis <dean.willis@softarmor.com> 
2005-06-16 12:09 AM	
To
DarshanBildikar 70559 <darshanb@huawei.com>
cc
sipping@ietf.org
Subject
Re: [Sipping] Question regarding reliable provisional response retransmission
	

	



On Jun 15, 2005, at 12:18 AM, DarshanBildikar 70559 wrote:
> 1) RFC 3262 states that reliable provisional responses are to be 
> retransmitted every two and a half minutes. Why is this really 
> required since the response is after all "reliable" !
>

Because in addition to being reliable, they're still "provisional", and 
we need a state recovery mechanism to deal with state recovery in the 
cases where a transaction fails after a reliable provisional is 
exchanged.

> 2) Should the retransmitted provisional response always contain the 
> same SDP? i.e. Should I only consider the first SDP and ignore SDP's 
> in subsequent messages?
>

Well, it would be terribly rude to change your offer in midstream, as 
there is a race conditional where an answer might be "in flight" as the 
new offer is being transmitted, so if the repsonse in question 
contained SDP, repeats should contain the same.

It's not clear to me that one actually has to repeat the SAME 
reliable-provisional response sequence in order to maintain the 
transaction in the final-pending state. It would seem to suffice to 
send another reliable provisional (perhaps a 180) without SDP.

Others may think differently.


Question: Shouldn't this really be on the sip-implementors list?

--
Dean


******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************


_______________________________________________
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 Jun 18 06:42:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DjamP-00012a-1V; Sat, 18 Jun 2005 06:42:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DjamN-00012U-9n
	for sip@megatron.ietf.org; Sat, 18 Jun 2005 06:42:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00344
	for <sip@ietf.org>; Sat, 18 Jun 2005 06:42:20 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djb9e-0006yR-IO
	for sip@ietf.org; Sat, 18 Jun 2005 07:06:27 -0400
Received: by wproxy.gmail.com with SMTP id 58so41826wri
	for <sip@ietf.org>; Sat, 18 Jun 2005 03:42:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=gwA/zDixp5T9r3CQpihOvKKvF8hcTW3vUUbRb1oyYXWQzPYYLtXHT9+c40EGCv5tF+TIhgYKaKuuxmXGF8Sg9eTxnm9fSSqrH5H5QnBRcTashdyQJmN8HjsjmqjZL11PLj9jX0VoMhsYLyVOfr30e49Od0xnj/lZu4nDmqk55bE=
Received: by 10.54.25.75 with SMTP id 75mr1590255wry;
	Sat, 18 Jun 2005 03:42:11 -0700 (PDT)
Received: by 10.54.95.16 with HTTP; Sat, 18 Jun 2005 03:42:11 -0700 (PDT)
Message-ID: <52db68bc05061803423306c9cb@mail.gmail.com>
Date: Sat, 18 Jun 2005 16:12:11 +0530
From: Sudhir Kumar Reddy <t.sudhirkumar@gmail.com>
To: sip@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Query about Register
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Sudhir Kumar Reddy <t.sudhirkumar@gmail.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

Hi

I would like to know How authetication is accomplished in REGISTER
request? is there any document other than RFC 3261

thanks in advance=20

warmest regards
--=20
Sudhir Kumar Reddy Thumma
91-986060751

_______________________________________________
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 Jun 18 13:01:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Djgh5-0002Zq-8b; Sat, 18 Jun 2005 13:01:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Djgh3-0002Zl-QQ
	for sip@megatron.ietf.org; Sat, 18 Jun 2005 13:01:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26546
	for <sip@ietf.org>; Sat, 18 Jun 2005 13:01:14 -0400 (EDT)
From: tammi.nguyen@conexant.com
Received: from cnxtsmtp9.conexant.com ([198.62.9.206] helo=nbmime1.bbnet.ad)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djh4O-0000iS-8H
	for sip@ietf.org; Sat, 18 Jun 2005 13:25:25 -0400
Received: Conexant Mail
To: sip@ietf.org
Message-ID: <OFC897A709.2D577217-ON88257024.005D8FE5-88257024.005D8FE5@conexant.com>
Date: Sat, 18 Jun 2005 10:01:56 -0700
X-MIMETrack: Serialize by Router on NBLNBkup1/Server/Conexant 
	(Release 6.5.3|September 14, 2004) at 06/18/2005 10:01:07 AM
MIME-Version: 1.0
X-Spam-Score: 1.1 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [Sip] Tammi K Nguyen/USA/Conexant 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="===============1830169491=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============1830169491==
Content-type: multipart/alternative; 
	Boundary="0__=07BBFAB7DFCE09758f9e8a93df938690918c07BBFAB7DFCE0975"
Content-Disposition: inline

--0__=07BBFAB7DFCE09758f9e8a93df938690918c07BBFAB7DFCE0975
Content-type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

Please see Kyle Rupert for all VoIP DVT-Related Concerns.

Regards,
-tammi



********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************


--0__=07BBFAB7DFCE09758f9e8a93df938690918c07BBFAB7DFCE0975
Content-type: text/html; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

<html><body>
<p>I will be out of the office starting  06/17/2005 and will not return until 06/20/2005.<br>
<br>
Please see Kyle Rupert for all VoIP DVT-Related Concerns.<br>
<br>
Regards,<br>
-tammi
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;"> </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;"> </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">********************** Legal Disclaimer **************************** </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">&quot;This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email and delete the message. Thank you.&quot; </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">********************************************************************** </SPAN> </P></body></html>

--0__=07BBFAB7DFCE09758f9e8a93df938690918c07BBFAB7DFCE0975--


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




From sip-bounces@ietf.org Sun Jun 19 14:43:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dk4lt-0003MG-2w; Sun, 19 Jun 2005 14:43:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk4lr-0003M6-6V
	for sip@megatron.ietf.org; Sun, 19 Jun 2005 14:43:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26127
	for <sip@ietf.org>; Sun, 19 Jun 2005 14:43:49 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk59Q-00030N-3l
	for sip@ietf.org; Sun, 19 Jun 2005 15:08:12 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9621FAAF; 
	Sun, 19 Jun 2005 20:43:49 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 19 Jun 2005 20:43:48 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 19 Jun 2005 20:43:48 +0200
Received: from [131.160.126.14] (rvi2-126-14.lmf.ericsson.se [131.160.126.14])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 38266254F;
	Sun, 19 Jun 2005 21:43:43 +0300 (EEST)
Message-ID: <42B5BCDE.5060802@ericsson.com>
Date: Sun, 19 Jun 2005 21:43:42 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rakhan@hssworld.com
References: <20050618160257.26020.qmail@web54210.mail.yahoo.com>
In-Reply-To: <20050618160257.26020.qmail@web54210.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jun 2005 18:43:48.0714 (UTC)
	FILETIME=[D4977CA0:01C574FE]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, rayees.khan@flextronicssoftware.com
Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02
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,

> 1. In general we have considred two models for
> transcoding service invocation based on 3PCC and
> Bridging model. A hybrid of the two in case of
> transcoding could be considered as an alternate model,
> so that 3PCC as well as the server (T) has control
> over the session. Party A would be interested in
> control for the reason of initiating the session, and
> T would be interested in controlling session to
> effectively manage its resources

Do you have a concrete proposal to realize what you are suggesting?

> 2. There is a typo in the draft in section 3.2
> mentioning 'end-poing' instead of 'end-point'.

I will fix it.

Thanks for your comments,

Gonzalo

_______________________________________________
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 Jun 21 03:05:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkcor-0007vq-Gg; Tue, 21 Jun 2005 03:05:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkcop-0007vi-HE
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 03:05:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18041
	for <sip@ietf.org>; Tue, 21 Jun 2005 03:05:09 -0400 (EDT)
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkdCf-0003Z1-FJ
	for sip@ietf.org; Tue, 21 Jun 2005 03:29:51 -0400
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 j5L74Si09587
	for <sip@ietf.org>; Tue, 21 Jun 2005 12:34:54 +0530
To: sip@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OF1AE1187F.1B3F9299-ON65257027.002604D9-65257027.0026D9E1@flextronicssoftware.com>
From: Rajeev Seth <rajeev.seth@flextronicssoftware.com>
Date: Tue, 21 Jun 2005 12:34:21 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 06/21/2005 12:38:02 PM,
	Serialize complete at 06/21/2005 12:38:02 PM
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: 
Subject: [Sip] Timer G for reliable responses
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="===============0543810344=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0543810344==
Content-Type: multipart/alternative;
	boundary="=_alternative 0026D9DF65257027_="

This is a multipart message in MIME format.
--=_alternative 0026D9DF65257027_=
Content-Type: text/plain; charset="US-ASCII"

Hi,

Section 17.2.1 of RFC 3261 says 

"For unreliable transports,  timer G is set to fire in T1 seconds, and is 
not set to fire for
   reliable transports"

However Table A Table of Timer Values says

Timer G  initially T1     Section 17.2.1       INVITE response
                                               retransmit interval

Table A does not qualify this timer with "For UDP only" which it does for 
other timers like Timer A and Timer E in the same table.

Therefore I looks like that table A contradicts what is said in section 
17.2.1

Regards,

Rajeev



***********************  FSS-Private   ***********************

***********************  FSS-Private   ***********************
--=_alternative 0026D9DF65257027_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Hi,</tt></font>
<br>
<br><font size=2><tt>Section 17.2.1 of RFC 3261 says </tt></font>
<br>
<br><font size=2><tt>&quot;For unreliable transports, &nbsp;timer G is
set to fire in T1 seconds, and is not set to fire for<br>
 &nbsp; reliable transports&quot;</tt></font>
<br>
<br><font size=2><tt>However Table A Table of Timer Values says</tt></font>
<br>
<br><font size=2><tt>Timer G &nbsp;initially T1 &nbsp; &nbsp; Section 17.2.1
&nbsp; &nbsp; &nbsp; INVITE response<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; retransmit interval<br>
</tt></font>
<br><font size=2><tt>Table A does not qualify this timer with &quot;For
UDP only&quot; which it does for other timers like Timer A and Timer E
in the same table.</tt></font>
<br>
<br><font size=2><tt>Therefore I looks like that table A contradicts what
is said in section 17.2.1</tt></font>
<br>
<br><font size=3><tt>Regards,</tt></font>
<br>
<br><font size=3><tt>Rajeev</tt></font>
<br><font size=3><tt><br>
<br>
<br>
*********************** &nbsp;FSS-Private &nbsp; ***********************<br>
<br>
*********************** &nbsp;FSS-Private &nbsp; ***********************</tt></font>
--=_alternative 0026D9DF65257027_=--


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




From sip-bounces@ietf.org Tue Jun 21 03:25:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkd8q-00031f-Bm; Tue, 21 Jun 2005 03:25:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkd8m-00030X-4v
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 03:25:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19357
	for <sip@ietf.org>; Tue, 21 Jun 2005 03:25:46 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkdWb-000443-9l
	for sip@ietf.org; Tue, 21 Jun 2005 03:50:28 -0400
Received: by wproxy.gmail.com with SMTP id 67so1283330wri
	for <sip@ietf.org>; Tue, 21 Jun 2005 00:25:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=c6HbhdsbHLexu1qDcVb6GCa9bnltPsw7/PPXM0yDS6SKkeOFSV6y2UwMKKBLsyjvJgARx3sGYasZIkw0K4WpfZdPfLB4+6L71IFXFu+3puj24shOS5hsHvu+OkUHjh8SKGdm51dpHdKlzyYZyrFFQd3kzuDl6Yf3Yj2F3MaMKoM=
Received: by 10.54.44.58 with SMTP id r58mr3005240wrr;
	Tue, 21 Jun 2005 00:25:33 -0700 (PDT)
Received: by 10.54.95.16 with HTTP; Tue, 21 Jun 2005 00:25:33 -0700 (PDT)
Message-ID: <52db68bc05062100256de0f901@mail.gmail.com>
Date: Tue, 21 Jun 2005 12:55:33 +0530
From: Sudhir Kumar Reddy <t.sudhirkumar@gmail.com>
To: rajeev.seth@flextronicssoftware.com, sip@ietf.org, sip@vovida.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Sip] Query about GUI in LINUX
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Sudhir Kumar Reddy <t.sudhirkumar@gmail.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

Hi

I'm used to work with JAIN SIP, which is developed ny Sun
MicroSystems. I'm planning to work with Stack which devloped on C with
Linux OS. So, could you tell how can i build GUI screenshots for my
applications

thanks in advance


regards
--=20
Sudhir Kumar Reddy Thumma
0986060751

_______________________________________________
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 Jun 21 10:39:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkjuo-0002kw-RD; Tue, 21 Jun 2005 10:39:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkjun-0002ko-2g
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 10:39:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25654
	for <sip@ietf.org>; Tue, 21 Jun 2005 10:39:47 -0400 (EDT)
Received: from sentry.zoom.com ([204.94.248.12]
	helo=southe01.zoommail.zoom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkkIi-0006xS-7C
	for sip@ietf.org; Tue, 21 Jun 2005 11:04:33 -0400
Received: by southe01.zoomtel.com with Internet Mail Service (5.5.2653.19)
	id <C1FDK3R1>; Tue, 21 Jun 2005 10:28:34 -0400
Message-ID: <D1696C471C6CD511A0BE00D0B7A932DE06C87CAC@southe01.zoomtel.com>
From: Hume Vance <HumeV@zoom.com>
To: sip@ietf.org
Date: Tue, 21 Jun 2005 10:28:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: [Sip] Private Headers in SIP
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 wonder if someone could point me to a definition of private headers, and
their prescribed use. I refer to the headers described e.g. in RFCs 3325 &
3455.

Thanks,

Hume 

Hume Vance
Director of Firmware Engineering
Zoom Technologies, Inc.
207 South St.
Boston, MA 02111
(617) 753-0032
(617) 542-8276 fax
humev@zoom.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 Tue Jun 21 10:52:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkk7H-0004yj-7I; Tue, 21 Jun 2005 10:52:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkk7F-0004wo-JC
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 10:52:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27171
	for <sip@ietf.org>; Tue, 21 Jun 2005 10:52:39 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkkVA-0007QI-PP
	for sip@ietf.org; Tue, 21 Jun 2005 11:17:26 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com
	[135.221.14.69])
	by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5LEqa4H004220; 
	Tue, 21 Jun 2005 09:52:37 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
	(5.5.2657.72) id <KWCQ575T>; Tue, 21 Jun 2005 15:52:36 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00C290517@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Hume Vance'" <HumeV@zoom.com>, sip@ietf.org
Subject: RE: [Sip] Private Headers in SIP
Date: Tue, 21 Jun 2005 15:52:34 +0100
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: 769a46790fb42fbb0b0cc700c82f7081
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

RFC 3427: "Change Process for the Session Initiation Protocol (SIP)". In particular section 4.1.

regards

Keith

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Hume Vance
> Sent: 21 June 2005 15:28
> To: sip@ietf.org
> Subject: [Sip] Private Headers in SIP
> 
> 
> Hi,
> 
> I wonder if someone could point me to a definition of private 
> headers, and
> their prescribed use. I refer to the headers described e.g. 
> in RFCs 3325 &
> 3455.
> 
> Thanks,
> 
> Hume 
> 
> Hume Vance
> Director of Firmware Engineering
> Zoom Technologies, Inc.
> 207 South St.
> Boston, MA 02111
> (617) 753-0032
> (617) 542-8276 fax
> humev@zoom.com
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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



From sip-bounces@ietf.org Tue Jun 21 10:55:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkk9o-0005sQ-K2; Tue, 21 Jun 2005 10:55:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkk9l-0005sI-4V
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 10:55:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27585
	for <sip@ietf.org>; Tue, 21 Jun 2005 10:55:14 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkkXg-0007Wv-SR
	for sip@ietf.org; Tue, 21 Jun 2005 11:20:01 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id A11586C01C
	for <sip@ietf.org>; Tue, 21 Jun 2005 10:55:10 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: "Sip (E-mail)" <sip@ietf.org>
Date: Tue, 21 Jun 2005 10:54:01 -0400
Message-ID: <004e01c57671$10484180$6a01010a@keywest>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb
Content-Transfer-Encoding: 7bit
Subject: [Sip] Some comments on GRUUs
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

Thoughts about GRUUs.

After trying to straighten out the problems that we've been having
interpreting and using the contents of dialog event packages, it seems
that the only workable solution is for the contact addresses in
dialogs to be GRUUs -- globally routable URIs that are specific to one
UA.  At first, the "globally routable" constraint seems difficult if
not impossible to satisfy, but of necessity, every registrar/proxy has
already solved it.  draft-ietf-sip-gruu-03 is a good mechanism for
allowing UAs to piggyback off their registrar/proxies to solve the
problem generally.

Within the solution provided by draft-ietf-sip-gruu-03, I have a few
observations and suggestions:

- a way to solve the routing problem discussed in section 8.4.2
- a way to allow UAs without AORs to obtain GRUUs
- how to issue GRUUs when a UA has more than one contact address for a
  given AOR.
- an editorial comment about the syntax of URNs


* Routing problem.

Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem
that can result when a UA uses a GRUU as its target address.  In the
worse case, shown in Figure 5 of the I-D, assume that a User Agent A
in domain "example.com" has established a dialog with User Agent B in
another domain.  Furthermore, domain "example.com" has a home proxy HP
that maintains and interprets GRUUs in "example.com".  But the home
proxy can only contact UA A via an edge proxy EP.

Thus, when UA A established the dialog with UA B, the message flow
was:

	UA B  <---  HP  <---  EP  <---  UA A

Assuming that both HP and EP Record-Route themselves (EP must R-R
itself), at UA B the full routing (route-set plus target URI) is:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:GRUU-A@example.com>

(The domain names "hp.example.com" and "ep.example.com" are more
likely to be absolute IP addresses, but writing them symbolically
makes the example easier to understand.)

When UA B sends an in-dialog request to UA A, EP is unable to use the
target URI to reach UA A and instead sends the request back to HP, the
server for the domain "example.com".  HP resolves the GRUU to the
contact address, and forwards the request through EP to UA A.  The
full flow is:

	UA B  --->  HP  --->  EP
                              |
                     +--------+
                     |
                     v
	            HP  --->  EP  --->  UA A

Fundamentally the problem is that the Contact header in UA A's request
that established the dialog is being overloaded with two distinct
purposes.  On one hand, we want it to be a globally-valid URI for
contacting UA A, a GRUU.  On the other hand, we want it to be the
final item in a list of addresses of waypoints for routing messages
within the dialog.  But these two requirements are contradictory --
because of NATing or AAA (authentication, authorization, accounting),
there may be no URI that is both gobally routable and usable for
direct access to the UA.

There is a fairly simple solution to this:  When establishing the
dialog, UA A needs to insert a Record-Route that provides its locally
usable contact address, so as to mask the GRUU that is its target URI.
Then, the full routing as seen by UA B is:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:a.example.com;lr>
	<sip:GRUU-A@example.com>

Then, when an in-dialog request from UA B reaches EP, it will have
"Route:  <sip:ep.example.com;lr>", "Route: <sip:a.example.com;lr>",
and a request-URI of "GRUU-A@example.com".  EP recognizes
"ep.example.com" as one of its own addresses and deletes it.  EP then
sends the request to the next Route address, "a.example.com", which is
a locally usable address.

In accordance with normal processing rules, UA A recognizes
"a.example.com" as one of its addresses and removes the Route
containing it.  It then recognizes the request-URI
"GRUU-A@example.com" as also being one of its addresses, and processes
the request.

Clearly, this mechanism can be used simultaneously by both ends of a
dialog.

For the benefit of external diagnostic agents, it may be worth
defining two URI-parameters, one to mark URIs that are GRUUs, and one
to mark route-set URIs that are the locally-usable addresses.  For
example:

	<sip:hp.example.com;lr>
	<sip:ep.example.com;lr>
	<sip:a.example.com;lr;local>
	<sip:GRUU-A@example.com;gruu>

This mechanism does have the limitation that the true target URIs for
the dialog are no longer the stated contact URIs and cannot be changed
during the dialog by a re-INVITE.


* GRUUs when you don't have an AOR.

There are times when a UA doesn't really represent a permanent entity,
and yet it would be useful for it to obtain a GRUU.  (Consider a set
of UAs that form a distributed monitoring system.)  The current system
makes obtaining a GRUU inherently part of registration as a contact
for an AOR.  But as an extension, a registration agent could allow
registrations whose only effect is to create GRUUs, and not create
contact points for an AOR.

A plausible mechanism for this operation is a registration whose To
address (normally the AOR to which the contact is to be registered) is
the same as the registration agent's request-URI, "sip:<domain>".

A simplified example of such a registration and its response is:

   REGISTER sip:example.com SIP/2.0
   From: Callee <sip:example.com>;tag=a73kszlfl
   To: Callee <sip:example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Supported: gruu
   Contact: <sip:callee@192.0.2.1>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"


   SIP/2.0 200 OK
   From: Callee <sip:master@example.com>;tag=a73kszlfl
   To: Callee <sip:example.com> ;tag=b88sn
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Contact: <sip:callee@192.0.2.1>
     ;gruu="sip:hha9s8d=-999a@example.com"
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

After that, the UA at "sip:callee@192.0.2.1" could be reached via
"sip:hha9s8d=-999a@example.com".


* GRUUs for multiple contacts.

It seems like there may be situations where a single UA has more than
one contact URI for a given AOR.  This might result if there are
several network paths to the UA from a proxy and the proxy is expected
to select among them based on dynamic routing information.  A
registration for this situation looks like:

       REGISTER sip:registrar.biloxi.com SIP/2.0
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
       Max-Forwards: 70
       To: Bob <sip:bob@biloxi.com>
       From: Bob <sip:bob@biloxi.com>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Contact: <sip:bob@192.0.2.4>
       Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
       Expires: 7200
       Content-Length: 0

In this case, we want to associate both contacts with the GRUU for a
signe instance/AOR pair, and the proxy would route requests to that
GRUU much as it now routes requests to the AOR.  (That is, the routing
decisions would have to be intelligent, but no more intelligent than
routing decisions for the AOR are already.)

But to make this work requires some amendments to the wording of the
I-D.  Consider requesting a GRUU for these contacts:

       REGISTER sip:registrar.biloxi.com SIP/2.0
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
       Max-Forwards: 70
       To: Bob <sip:bob@biloxi.com>
       From: Bob <sip:bob@biloxi.com>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Supported: gruu
       Contact: <sip:bob@192.0.2.4>
           ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
       Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
           ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
       Expires: 7200
       Content-Length: 0

We want to get the response:

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
	;received=192.0.2.4
       To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
       From: Bob <sip:bob@biloxi.com>;tag=456248
       Call-ID: 843817637684230@998sdasdh09
       CSeq: 1826 REGISTER
       Contact: <sip:bob@192.0.2.4>
	   ;gruu="sip:hha9s8d=-999a@biloxi.com"
	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
	   ;expires=3600
       Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
	   ;gruu="sip:hha9s8d=-999a@biloxi.com"
	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
	   ;expires=3600
       Expires: 7200
       Content-Length: 0

Both contacts have the same GRUU (of necessity) and have both contacts
bound to the instance/AOR pair.

To achieve this, we change the ending of this passage:

   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 additionally checks whether each Contact header field
   in the REGISTER message contains a "+sip.instance" header field
   parameter.  If it does, the registrar takes the value of that
   parameter as an instance ID.

to:

   The registrar checks to see if there is any other contact that was
   bound to the same AOR with the same instance ID (...), but was not
   bound in this REGISTER request.  Any such contact MUST be removed
   as if it was de-registered by the REGISTER request, and processing
   continues.

(This leaves unchanged the ability of the UA to obtain different GRUUs
for different contact addresses by providing different instance IDs
for them.)


* Syntax of URNs

The "sip.instance" parameter has a value which is a URN.  However, a
number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
with "<...>", which is not strictly valid.  Though this would be
unlikely to cause functional problems in real implmentations, the
examples should be corrected:

   Contact: <sip:callee@192.0.2.1>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

   Contact: <sip:callee@192.0.2.1>
     ;gruu="sip:hha9s8d=-999a@example.com"
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

   Contact: <sip:callee@192.0.2.2>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

   Contact: <sip:callee@192.0.2.2>
     ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
     ;expires=3600

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 Jun 21 13:53:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkmwH-0008JH-Na; Tue, 21 Jun 2005 13:53:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DkmwF-0008JC-TM
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 13:53:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11977
	for <sip@ietf.org>; Tue, 21 Jun 2005 13:53:30 -0400 (EDT)
Received: from [66.199.180.247] (helo=mail.rodrigues.ca)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DknKA-0003yu-UK
	for sip@ietf.org; Tue, 21 Jun 2005 14:18:18 -0400
Received: from localhost.localdomain ([127.0.0.1])
	by mail.rodrigues.ca with esmtp (Exim 3.36 #5) id 1DkmuB-0000GF-00
	for sip@ietf.org; Tue, 21 Jun 2005 13:51:24 -0400
Date: Tue, 21 Jun 2005 13:51:21 -0400 (EDT)
From: "Marco P. Rodrigues" <marco@rodrigues.ca>
To: sip@ietf.org
Message-ID: <Pine.LNX.4.61.0506211313480.32538@boar.rodrigues.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [Sip] Media Statistics in SIP 200 OK/BYE Message
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Marco P. Rodrigues" <marco@rodrigues.ca>
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is anyone aware of any documented mechanisms to send call statistics
at the end of a SIP conversation? I'm looking for something similar to
the Connection Parameters sent back in an MGCP 250 message when
a delete connection is requested.

I know some UA's (Cisco) send these statistics in the SIP 200 BYE
message but I am unable to find any reference to it in any
standards or drafts.

- -mpr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCuFObfj+BwLdVfecRApksAKCtixt4SoEmPRXYMiigZeVgE/jHjQCgi73E
w5JXLCW5ccN76eRMPbG6gtY=
=gIjU
-----END PGP SIGNATURE-----

_______________________________________________
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 Jun 21 14:50:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DknpW-0002ko-ML; Tue, 21 Jun 2005 14:50:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DknpU-0002kc-9C
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 14:50:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17537
	for <sip@ietf.org>; Tue, 21 Jun 2005 14:50:34 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkoDS-0005ZE-Oq
	for sip@ietf.org; Tue, 21 Jun 2005 15:15:23 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com
	[135.221.14.69])
	by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5LIoKVS025307; 
	Tue, 21 Jun 2005 13:50:25 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
	(5.5.2657.72) id <KWCQ6DYX>; Tue, 21 Jun 2005 19:50:18 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00C290520@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Marco P. Rodrigues'" <marco@rodrigues.ca>, sip@ietf.org
Subject: RE: [Sip] Media Statistics in SIP 200 OK/BYE Message
Date: Tue, 21 Jun 2005 19:50:14 +0100
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: 9ed51c9d1356100bce94f1ae4ec616a9
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

Assuming you mean send the information to the end user, no there is not currently a documented mechanism in IETF.

There is a requirement buried in http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-requirements-01.txt as [REQ-AoC-2] which when a solution is decided will provide what you require. Hopefully this will achieve some discussion in Paris.

regards

Keith

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Marco P. Rodrigues
> Sent: 21 June 2005 18:51
> To: sip@ietf.org
> Subject: [Sip] Media Statistics in SIP 200 OK/BYE Message
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Is anyone aware of any documented mechanisms to send call statistics
> at the end of a SIP conversation? I'm looking for something similar to
> the Connection Parameters sent back in an MGCP 250 message when
> a delete connection is requested.
> 
> I know some UA's (Cisco) send these statistics in the SIP 200 BYE
> message but I am unable to find any reference to it in any
> standards or drafts.
> 
> - -mpr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQFCuFObfj+BwLdVfecRApksAKCtixt4SoEmPRXYMiigZeVgE/jHjQCgi73E
> w5JXLCW5ccN76eRMPbG6gtY=
> =gIjU
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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 Jun 21 15:23:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkoLC-0000Ud-Ty; Tue, 21 Jun 2005 15:23:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DkoLB-0000UT-4A
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 15:23:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22073
	for <sip@ietf.org>; Tue, 21 Jun 2005 15:23:19 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkoj9-0006Yv-Mj
	for sip@ietf.org; Tue, 21 Jun 2005 15:48:08 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 21 Jun 2005 15:23:12 -0400
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 j5LJKOo4021261; 
	Tue, 21 Jun 2005 15:21:34 -0400 (EDT)
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, 21 Jun 2005 15:20:43 -0400
Received: from [192.168.1.100] ([10.86.242.143]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 21 Jun 2005 15:20:35 -0400
Message-ID: <42B86883.904@cisco.com>
Date: Tue, 21 Jun 2005 15:20:35 -0400
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: "Drage, Keith (Keith)" <drage@lucent.com>
Subject: Re: [Sip] Media Statistics in SIP 200 OK/BYE Message
References: <475FF955A05DD411980D00508B6D5FB00C290520@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290520@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jun 2005 19:20:35.0850 (UTC)
	FILETIME=[4CF936A0:01C57696]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, "'Marco P. Rodrigues'" <marco@rodrigues.ca>
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

RFC3611 provides a way to report call quality statistics.

-Jonathan R.

Drage, Keith (Keith) wrote:

> Assuming you mean send the information to the end user, no there is not currently a documented mechanism in IETF.
> 
> There is a requirement buried in http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-requirements-01.txt as [REQ-AoC-2] which when a solution is decided will provide what you require. Hopefully this will achieve some discussion in Paris.
> 
> regards
> 
> Keith
> 
> 
>>-----Original Message-----
>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
>>Marco P. Rodrigues
>>Sent: 21 June 2005 18:51
>>To: sip@ietf.org
>>Subject: [Sip] Media Statistics in SIP 200 OK/BYE Message
>>
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Is anyone aware of any documented mechanisms to send call statistics
>>at the end of a SIP conversation? I'm looking for something similar to
>>the Connection Parameters sent back in an MGCP 250 message when
>>a delete connection is requested.
>>
>>I know some UA's (Cisco) send these statistics in the SIP 200 BYE
>>message but I am unable to find any reference to it in any
>>standards or drafts.
>>
>>- -mpr
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.1 (GNU/Linux)
>>
>>iD8DBQFCuFObfj+BwLdVfecRApksAKCtixt4SoEmPRXYMiigZeVgE/jHjQCgi73E
>>w5JXLCW5ccN76eRMPbG6gtY=
>>=gIjU
>>-----END PGP SIGNATURE-----
>>
>>_______________________________________________
>>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
Director, Service Provider VoIP Architecture   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 Tue Jun 21 18:50:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkrZP-0002an-Eh; Tue, 21 Jun 2005 18:50:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkrZE-0002XP-GK; Tue, 21 Jun 2005 18:50:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22050;
	Tue, 21 Jun 2005 18:50:01 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DkrxE-000196-UE; Tue, 21 Jun 2005 19:14:53 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DkrZB-0004uI-4I; Tue, 21 Jun 2005 18:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DkrZB-0004uI-4I@newodin.ietf.org>
Date: Tue, 21 Jun 2005 18:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-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		: Session Initiation Protocol Location Conveyance
	Author(s)	: J. Polk, B. Rosen
	Filename	: draft-ietf-sip-location-conveyance-00.txt
	Pages		: 43
	Date		: 2005-6-21
	
   This document presents the framework and requirements for usage of 
   the Session Initiation Protocol (SIP) to convey user location 
   information from one Session Initiation Protocol (SIP) entity to 
   another SIP entity.  We consider cases where location information is
   conveyed from end to end, as well as cases where message routing by 
   intermediaries is influenced by the location of the session 
   initiator.  We offer a set of solutions to the requirements, each 
   based on the scenario being addressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-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-location-conveyance-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-location-conveyance-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-6-21163327.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-location-conveyance-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-location-conveyance-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-6-21163327.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 Jun 21 21:03:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkte5-0003A2-Ug; Tue, 21 Jun 2005 21:03:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkte3-00039x-M5
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 21:03:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03262
	for <sip@ietf.org>; Tue, 21 Jun 2005 21:03:09 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dku23-0004vO-6y
	for sip@ietf.org; Tue, 21 Jun 2005 21:28:01 -0400
Received: from [64.101.100.88] ([64.101.100.88]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5M16I7O005971
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 21 Jun 2005 20:06:18 -0500
In-Reply-To: <Pine.LNX.4.61.0506211313480.32538@boar.rodrigues.ca>
References: <Pine.LNX.4.61.0506211313480.32538@boar.rodrigues.ca>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6b92313aeb5e68480d00d2102c2b0ee1@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Media Statistics in SIP 200 OK/BYE Message
Date: Tue, 21 Jun 2005 20:02:53 -0500
To: "Marco P. Rodrigues" <marco@rodrigues.ca>
X-Pgp-Agent: GPGMail 1.1 (Panther)
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Jun 21, 2005, at 12:51 PM, Marco P. Rodrigues wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Is anyone aware of any documented mechanisms to send call statistics
> at the end of a SIP conversation? I'm looking for something similar to
> the Connection Parameters sent back in an MGCP 250 message when
> a delete connection is requested.

You might look at:

http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp- 
summary-06.txt


- --
Dean

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCuLjBSE0vSqCaet8RAl2NAKC63VJHAPrbBV+wDPuyKb4naEvlwACeNa1+
9YOda1ekJAR49cpNdSOvD3U=
=BQpW
-----END PGP SIGNATURE-----


_______________________________________________
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 Jun 21 22:14:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dkukj-00030C-Sa; Tue, 21 Jun 2005 22:14:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkuki-000307-1m
	for sip@megatron.ietf.org; Tue, 21 Jun 2005 22:14:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08652
	for <sip@ietf.org>; Tue, 21 Jun 2005 22:14:06 -0400 (EDT)
Received: from david.siemens.com.cn ([194.138.202.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkv8V-0006dk-LH
	for sip@ietf.org; Tue, 21 Jun 2005 22:38:58 -0400
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52])
	by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id j5M22Gr24139
	for <sip@ietf.org>; Wed, 22 Jun 2005 10:02:17 +0800 (CST)
Received: from pekw096e.cn001.siemens.net (localhost [127.0.0.1])
	by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id j5M28Vf07591
	for <sip@ietf.org>; Wed, 22 Jun 2005 10:08:31 +0800 (CST)
Received: by pekw096e.cn001.siemens.net with Internet Mail Service
	(5.5.2657.72) id <NL6BL0PG>; Wed, 22 Jun 2005 10:13:38 +0800
Message-ID: <54CD3165FCE49A44A9A6F2179B3C36C3065610A3@pekw092a>
From: "Sun Xian Peng, SLC COM CD/MN R&D SE (BJ)"
	 <xianpeng.sun@siemens.com>
To: sip@ietf.org
Date: Wed, 22 Jun 2005 10:13:31 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [Sip] RE: Timer G for reliable responses
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 Rajeev,
 All the timers relevant to retransmition, I think, is valid in UDP transport only.
 So not only Timer G, but also Timer I,J,K..., are only set to non-zero in UDP.
 E.g. when using reliable transports, retransmitted ACK packets will be absorbed by TCP layer ,but not by SIP transactions.

Rgds
Sun Xianpeng

_______________________________________________
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 Jun 22 01:10:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkxVo-0005Tu-E4; Wed, 22 Jun 2005 01:10:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DkxVj-0005SU-Ue
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 01:10:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21910
	for <sip@ietf.org>; Wed, 22 Jun 2005 01:10:50 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkxtn-0002bZ-QW
	for sip@ietf.org; Wed, 22 Jun 2005 01:35:44 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by sj-iport-5.cisco.com with ESMTP; 21 Jun 2005 22:10:42 -0700
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 j5M5Adne019254; 
	Wed, 22 Jun 2005 01:10:39 -0400 (EDT)
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);
	Wed, 22 Jun 2005 01:10:39 -0400
Received: from [192.168.1.100] ([10.86.242.143]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 22 Jun 2005 01:10:23 -0400
Message-ID: <42B8F2CE.70001@cisco.com>
Date: Wed, 22 Jun 2005 01:10:38 -0400
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: "Sun Xian Peng, SLC COM CD/MN R&D SE (BJ)" <xianpeng.sun@siemens.com>
Subject: Re: [Sip] RE: Timer G for reliable responses
References: <54CD3165FCE49A44A9A6F2179B3C36C3065610A3@pekw092a>
In-Reply-To: <54CD3165FCE49A44A9A6F2179B3C36C3065610A3@pekw092a>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jun 2005 05:10:23.0908 (UTC)
	FILETIME=[B1E65640:01C576E8]
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

Not all timers. The timers for retransmitting of the 200 OK to INVITE 
are still applicable for tcp, as they are end-to-end.

The text in section 17 is normative on these timers. The table in the 
appendix is inconsistent in that it mentions the exception for TCP only 
for some of them. That is an error, and I'll log a bug against it.

-Jonathan R.



Sun Xian Peng, SLC COM CD/MN R&D SE (BJ) wrote:

> Hi Rajeev, All the timers relevant to retransmition, I think, is
> valid in UDP transport only. So not only Timer G, but also Timer
> I,J,K..., are only set to non-zero in UDP. E.g. when using reliable
> transports, retransmitted ACK packets will be absorbed by TCP layer
> ,but not by SIP transactions.
> 
> Rgds Sun Xianpeng
> 
> _______________________________________________ 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
Director, Service Provider VoIP Architecture   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 Wed Jun 22 03:46:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DkzwW-0002RL-JA; Wed, 22 Jun 2005 03:46:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzwU-0002Ou-3r
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 03:46:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09080
	for <sip@ietf.org>; Wed, 22 Jun 2005 03:46:35 -0400 (EDT)
Received: from tierw.net.avaya.com ([198.152.13.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl0KY-0006Zz-B5
	for sip@ietf.org; Wed, 22 Jun 2005 04:11:31 -0400
Received: from tierw.net.avaya.com (localhost [127.0.0.1])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j5M7YYAK023181
	for <sip@ietf.org>; Wed, 22 Jun 2005 03:34:34 -0400 (EDT)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j5M7YVAK023138
	for <sip@ietf.org>; Wed, 22 Jun 2005 03:34:32 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: [Sip] Media Statistics in SIP 200 OK/BYE Message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Wed, 22 Jun 2005 10:46:27 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F08B54D9B@is0004avexu1.global.avaya.com>
Thread-Topic: [Sip] Media Statistics in SIP 200 OK/BYE Message
Thread-Index: AcV2iq+gEp2y9V5+R+SHdyEGBBKn1AAczYLw
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Marco P. Rodrigues" <marco@rodrigues.ca>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: quoted-printable
Cc: "Siddiqui, Anwar A \(Anwar\)" <anwars@avaya.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

See the RAQMON drafts:

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raq
mon-framework-11.txt
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raq
mon-pdu-10.txt

RAQMON is not SIP specific only, but I believe that it would do the job
you are asking about. One could also define a SIP transport for RAQMON
PDUs to carry session specific information by the end of the session. =20

Regards,

Dan


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20
> Behalf Of Marco P. Rodrigues
> Sent: Tuesday, June 21, 2005 8:51 PM
> To: sip@ietf.org
> Subject: [Sip] Media Statistics in SIP 200 OK/BYE Message
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Is anyone aware of any documented mechanisms to send call=20
> statistics at the end of a SIP conversation? I'm looking for=20
> something similar to the Connection Parameters sent back in=20
> an MGCP 250 message when a delete connection is requested.
>=20
> I know some UA's (Cisco) send these statistics in the SIP 200=20
> BYE message but I am unable to find any reference to it in=20
> any standards or drafts.
>=20
> - -mpr


_______________________________________________
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 Jun 22 06:12:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl2E2-0006Rr-29; Wed, 22 Jun 2005 06:12:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2E0-0006QS-PO
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 06:12:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20716
	for <sip@ietf.org>; Wed, 22 Jun 2005 06:12:49 -0400 (EDT)
Received: from tiere.net.avaya.com ([198.152.12.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl2c6-0001kG-2v
	for sip@ietf.org; Wed, 22 Jun 2005 06:37:47 -0400
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j5MAAHdd024214
	for <sip@ietf.org>; Wed, 22 Jun 2005 06:10:18 -0400 (EDT)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	j5MAAFdd024184
	for <sip@ietf.org>; Wed, 22 Jun 2005 06:10:16 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Wed, 22 Jun 2005 13:12:43 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F08B54E3B@is0004avexu1.global.avaya.com>
Thread-Topic: Nit in draft-ietf-sip-mib-09.txt
Thread-Index: AcV3Eu1Stai9nP7kRQaIH54uaH7yag==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: <sip@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Subject: [Sip] Nit in draft-ietf-sip-mib-09.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>
Content-Type: multipart/mixed; boundary="===============2026687389=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2026687389==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57712.EDA9B89B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57712.EDA9B89B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Editorial nit in draft-ietf-sip-mib-09.txt: in the DESCRIPTION clause of
sipContactURI:=20
=20
'This object contains either a SIP URI where the user can be contacted.'
=20
I believe that we can get rid of 'either'.=20
=20
Regards,
=20
Dan
=20
=20
=20
=20

------_=_NextPart_001_01C57712.EDA9B89B
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D116590910-22062005>Editorial nit in=20
draft-ietf-sip-mib-09.txt: in the DESCRIPTION clause of <FONT=20
size=3D3>sipContactURI: </FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3><SPAN class=3D116590910-22062005>'This =
object=20
contains either a SIP URI where the user can be =
contacted.'</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3><SPAN class=3D116590910-22062005>I =
believe that we=20
can get rid of 'either'. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005>Dan</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D3><SPAN=20
class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C57712.EDA9B89B--


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




From sip-bounces@ietf.org Wed Jun 22 09:06:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl4vx-0003uS-Ju; Wed, 22 Jun 2005 09:06:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4vq-0003q2-KF
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 09:06:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06472
	for <sip@ietf.org>; Wed, 22 Jun 2005 09:06:16 -0400 (EDT)
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5Jx-00078W-5b
	for sip@ietf.org; Wed, 22 Jun 2005 09:31:14 -0400
Received: from india-core-1.cisco.com (64.104.129.221)
	by ind-iport-1.cisco.com with ESMTP; 22 Jun 2005 18:43:43 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.93,221,1115017200"; 
	d="scan'208"; a="40879003:sNHT27480688"
Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com
	[64.104.140.150])
	by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MIYAs0020367;
	Wed, 22 Jun 2005 18:34:36 GMT
Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by
	xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); 
	Wed, 22 Jun 2005 18:35:30 +0530
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);
	Wed, 22 Jun 2005 09:00:58 -0400
Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 09:00:39 -0400
Message-ID: <42B960F1.8090902@cisco.com>
Date: Wed, 22 Jun 2005 09:00:33 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dale Worley <dworley@pingtel.com>
Subject: Re: [Sip] Some comments on GRUUs
References: <004e01c57671$10484180$6a01010a@keywest>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jun 2005 13:00:39.0253 (UTC)
	FILETIME=[638E5050:01C5772A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
Content-Transfer-Encoding: 7bit
Cc: "Sip \(E-mail\)" <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



Dale Worley wrote:
> Thoughts about GRUUs.
> 
> After trying to straighten out the problems that we've been having
> interpreting and using the contents of dialog event packages, it seems
> that the only workable solution is for the contact addresses in
> dialogs to be GRUUs -- globally routable URIs that are specific to one
> UA.  At first, the "globally routable" constraint seems difficult if
> not impossible to satisfy, but of necessity, every registrar/proxy has
> already solved it.  draft-ietf-sip-gruu-03 is a good mechanism for
> allowing UAs to piggyback off their registrar/proxies to solve the
> problem generally.
> 
> Within the solution provided by draft-ietf-sip-gruu-03, I have a few
> observations and suggestions:
> 
> - a way to solve the routing problem discussed in section 8.4.2
> - a way to allow UAs without AORs to obtain GRUUs
> - how to issue GRUUs when a UA has more than one contact address for a
>   given AOR.
> - an editorial comment about the syntax of URNs
> 
> 
> * Routing problem.
> 
> Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem
> that can result when a UA uses a GRUU as its target address.  In the
> worse case, shown in Figure 5 of the I-D, assume that a User Agent A
> in domain "example.com" has established a dialog with User Agent B in
> another domain.  Furthermore, domain "example.com" has a home proxy HP
> that maintains and interprets GRUUs in "example.com".  But the home
> proxy can only contact UA A via an edge proxy EP.
> 
> Thus, when UA A established the dialog with UA B, the message flow
> was:
> 
> 	UA B  <---  HP  <---  EP  <---  UA A
> 
> Assuming that both HP and EP Record-Route themselves (EP must R-R
> itself), at UA B the full routing (route-set plus target URI) is:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:GRUU-A@example.com>
> 
> (The domain names "hp.example.com" and "ep.example.com" are more
> likely to be absolute IP addresses, but writing them symbolically
> makes the example easier to understand.)
> 
> When UA B sends an in-dialog request to UA A, EP is unable to use the
> target URI to reach UA A and instead sends the request back to HP, the
> server for the domain "example.com".  HP resolves the GRUU to the
> contact address, and forwards the request through EP to UA A.  The
> full flow is:
> 
> 	UA B  --->  HP  --->  EP
>                               |
>                      +--------+
>                      |
>                      v
> 	            HP  --->  EP  --->  UA A
> 
> Fundamentally the problem is that the Contact header in UA A's request
> that established the dialog is being overloaded with two distinct
> purposes.  On one hand, we want it to be a globally-valid URI for
> contacting UA A, a GRUU.  On the other hand, we want it to be the
> final item in a list of addresses of waypoints for routing messages
> within the dialog.  But these two requirements are contradictory --
> because of NATing or AAA (authentication, authorization, accounting),
> there may be no URI that is both gobally routable and usable for
> direct access to the UA.
> 
> There is a fairly simple solution to this:  When establishing the
> dialog, UA A needs to insert a Record-Route that provides its locally
> usable contact address, so as to mask the GRUU that is its target URI.
> Then, the full routing as seen by UA B is:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr>
> 	<sip:GRUU-A@example.com>
> 
> Then, when an in-dialog request from UA B reaches EP, it will have
> "Route:  <sip:ep.example.com;lr>", "Route: <sip:a.example.com;lr>",
> and a request-URI of "GRUU-A@example.com".  EP recognizes
> "ep.example.com" as one of its own addresses and deletes it.  EP then
> sends the request to the next Route address, "a.example.com", which is
> a locally usable address.
> 
> In accordance with normal processing rules, UA A recognizes
> "a.example.com" as one of its addresses and removes the Route
> containing it.  It then recognizes the request-URI
> "GRUU-A@example.com" as also being one of its addresses, and processes
> the request.

This is pretty clever.

> Clearly, this mechanism can be used simultaneously by both ends of a
> dialog.
> 
> For the benefit of external diagnostic agents, it may be worth
> defining two URI-parameters, one to mark URIs that are GRUUs, and one
> to mark route-set URIs that are the locally-usable addresses.  For
> example:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr;local>
> 	<sip:GRUU-A@example.com;gruu>
> 
> This mechanism does have the limitation that the true target URIs for
> the dialog are no longer the stated contact URIs and cannot be changed
> during the dialog by a re-INVITE.

True. That is a theoretical problem, but I'm still looking for a real 
world use case where the target is changed.

> * GRUUs when you don't have an AOR.
> 
> There are times when a UA doesn't really represent a permanent entity,
> and yet it would be useful for it to obtain a GRUU.  (Consider a set
> of UAs that form a distributed monitoring system.)  The current system
> makes obtaining a GRUU inherently part of registration as a contact
> for an AOR.  But as an extension, a registration agent could allow
> registrations whose only effect is to create GRUUs, and not create
> contact points for an AOR.
> 
> A plausible mechanism for this operation is a registration whose To
> address (normally the AOR to which the contact is to be registered) is
> the same as the registration agent's request-URI, "sip:<domain>".
> 
> A simplified example of such a registration and its response is:
> 
>    REGISTER sip:example.com SIP/2.0
>    From: Callee <sip:example.com>;tag=a73kszlfl
>    To: Callee <sip:example.com>
>    Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
>    CSeq: 1 REGISTER
>    Supported: gruu
>    Contact: <sip:callee@192.0.2.1>
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 
> 
>    SIP/2.0 200 OK
>    From: Callee <sip:master@example.com>;tag=a73kszlfl
>    To: Callee <sip:example.com> ;tag=b88sn
>    Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
>    CSeq: 1 REGISTER
>    Contact: <sip:callee@192.0.2.1>
>      ;gruu="sip:hha9s8d=-999a@example.com"
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>      ;expires=3600
> 
> After that, the UA at "sip:callee@192.0.2.1" could be reached via
> "sip:hha9s8d=-999a@example.com".

Yeah, this could work. But I haven't heard of a compelling need for it.

This would require authorization. The registrar may not want to provide 
this service to just anybody. And it might not want to provide it for 
other reasons as well. For reasons of tracability it may not want to 
service requests that don't have an associated AoR.

> * GRUUs for multiple contacts.
> 
> It seems like there may be situations where a single UA has more than
> one contact URI for a given AOR.  This might result if there are
> several network paths to the UA from a proxy and the proxy is expected
> to select among them based on dynamic routing information.  A
> registration for this situation looks like:
> 
>        REGISTER sip:registrar.biloxi.com SIP/2.0
>        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
>        Max-Forwards: 70
>        To: Bob <sip:bob@biloxi.com>
>        From: Bob <sip:bob@biloxi.com>;tag=456248
>        Call-ID: 843817637684230@998sdasdh09
>        CSeq: 1826 REGISTER
>        Contact: <sip:bob@192.0.2.4>
>        Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
>        Expires: 7200
>        Content-Length: 0
> 
> In this case, we want to associate both contacts with the GRUU for a
> signe instance/AOR pair, and the proxy would route requests to that
> GRUU much as it now routes requests to the AOR.  (That is, the routing
> decisions would have to be intelligent, but no more intelligent than
> routing decisions for the AOR are already.)
> 
> But to make this work requires some amendments to the wording of the
> I-D.  Consider requesting a GRUU for these contacts:
> 
>        REGISTER sip:registrar.biloxi.com SIP/2.0
>        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
>        Max-Forwards: 70
>        To: Bob <sip:bob@biloxi.com>
>        From: Bob <sip:bob@biloxi.com>;tag=456248
>        Call-ID: 843817637684230@998sdasdh09
>        CSeq: 1826 REGISTER
>        Supported: gruu
>        Contact: <sip:bob@192.0.2.4>
>            ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>        Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
>            ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>        Expires: 7200
>        Content-Length: 0
> 
> We want to get the response:
> 
>        SIP/2.0 200 OK
>        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> 	;received=192.0.2.4
>        To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
>        From: Bob <sip:bob@biloxi.com>;tag=456248
>        Call-ID: 843817637684230@998sdasdh09
>        CSeq: 1826 REGISTER
>        Contact: <sip:bob@192.0.2.4>
> 	   ;gruu="sip:hha9s8d=-999a@biloxi.com"
> 	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 	   ;expires=3600
>        Contact: <sip:bob@10.103.245.86>;q=0.8;bw=high
> 	   ;gruu="sip:hha9s8d=-999a@biloxi.com"
> 	   ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 	   ;expires=3600
>        Expires: 7200
>        Content-Length: 0
> 
> Both contacts have the same GRUU (of necessity) and have both contacts
> bound to the instance/AOR pair.
> 
> To achieve this, we change the ending of this passage:
> 
>    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 additionally checks whether each Contact header field
>    in the REGISTER message contains a "+sip.instance" header field
>    parameter.  If it does, the registrar takes the value of that
>    parameter as an instance ID.
> 
> to:
> 
>    The registrar checks to see if there is any other contact that was
>    bound to the same AOR with the same instance ID (...), but was not
>    bound in this REGISTER request.  Any such contact MUST be removed
>    as if it was de-registered by the REGISTER request, and processing
>    continues.
> 
> (This leaves unchanged the ability of the UA to obtain different GRUUs
> for different contact addresses by providing different instance IDs
> for them.)

There is other work underway that will do much the same thing, allowing 
the registration of multiple contacts with the same instance id. The 
motivation was to allow registration thru multiple paths for redundancy. 
I think there is a draft, but at the moment I don't recall the name.

> * Syntax of URNs
> 
> The "sip.instance" parameter has a value which is a URN.  However, a
> number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
> with "<...>", which is not strictly valid.  Though this would be
> unlikely to cause functional problems in real implmentations, the
> examples should be corrected:

The <> is part of the syntax defined in 3840.3841 for callerprefs 
feature parameters. It indicates that the enclosed is a string rather 
than a list of tokens.

	Paul

>    Contact: <sip:callee@192.0.2.1>
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 
>    Contact: <sip:callee@192.0.2.1>
>      ;gruu="sip:hha9s8d=-999a@example.com"
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>      ;expires=3600
> 
>    Contact: <sip:callee@192.0.2.2>
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 
>    Contact: <sip:callee@192.0.2.2>
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>      ;expires=3600
> 
> 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 Jun 22 10:35:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl6KR-0008GD-2P; Wed, 22 Jun 2005 10:35:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6KP-0008G8-5c
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 10:35:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16891
	for <sip@ietf.org>; Wed, 22 Jun 2005 10:35:42 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6iW-0001qR-UK
	for sip@ietf.org; Wed, 22 Jun 2005 11:00:42 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 22 Jun 2005 16:35:34 +0200
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	j5MEZ8E2009172; Wed, 22 Jun 2005 16:35:31 +0200 (MEST)
Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by
	xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 22 Jun 2005 16:35:00 +0200
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 22 Jun 2005 10:33:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Nit in draft-ietf-sip-mib-09.txt
Date: Wed, 22 Jun 2005 10:32:39 -0400
Message-ID: <0DEB933345E95A4083C4403CD2E7980C52380C@xmb-rtp-211.amer.cisco.com>
Thread-Topic: [Sip] Nit in draft-ietf-sip-mib-09.txt
Thread-Index: AcV3Eu1Stai9nP7kRQaIH54uaH7yagAJC6fw
From: "Kevin Lingle \(klingle\)" <klingle@cisco.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, <sip@ietf.org>
X-OriginalArrivalTime: 22 Jun 2005 14:33:11.0882 (UTC)
	FILETIME=[512E42A0:01C57737]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
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="===============0123097204=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0123097204==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57737.37A46702"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57737.37A46702
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

agreed, dan.
=20
btw, i have your previous email with review comment on my todo list ;) =20
will try to get to it soon.
=20
thanks,
kevin


________________________________

	From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
Behalf Of Romascanu, Dan (Dan)
	Sent: Wednesday, June 22, 2005 6:13 AM
	To: sip@ietf.org
	Subject: [Sip] Nit in draft-ietf-sip-mib-09.txt
=09
=09
	Editorial nit in draft-ietf-sip-mib-09.txt: in the DESCRIPTION
clause of sipContactURI:=20
	=20
	'This object contains either a SIP URI where the user can be
contacted.'
	=20
	I believe that we can get rid of 'either'.=20
	=20
	Regards,
	=20
	Dan
	=20
	=20
	=20
	=20


------_=_NextPart_001_01C57737.37A46702
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><FONT =
face=3DArial=20
size=3D2><EM>agreed, dan.</EM></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2>btw, i have your previous email with review comment on my todo =
list=20
;)&nbsp; </FONT></EM></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2>will try to get to it soon.</FONT></EM></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2></FONT></EM></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2>thanks,</FONT></EM></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D673423114-22062005><EM><FONT =
face=3DArial=20
size=3D2>kevin</FONT></EM></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> sip-bounces@ietf.org=20
  [mailto:sip-bounces@ietf.org] <B>On Behalf Of </B>Romascanu, Dan=20
  (Dan)<BR><B>Sent:</B> Wednesday, June 22, 2005 6:13 AM<BR><B>To:</B>=20
  sip@ietf.org<BR><B>Subject:</B> [Sip] Nit in=20
  draft-ietf-sip-mib-09.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D116590910-22062005>Editorial nit in=20
  draft-ietf-sip-mib-09.txt: in the DESCRIPTION clause of <FONT=20
  size=3D3>sipContactURI: </FONT></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN =
class=3D116590910-22062005>'This object=20
  contains either a SIP URI where the user can be=20
contacted.'</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN class=3D116590910-22062005>I =
believe that we=20
  can get rid of 'either'. </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005>Dan</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D3><SPAN=20
  class=3D116590910-22062005></SPAN></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C57737.37A46702--


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




From sip-bounces@ietf.org Wed Jun 22 11:03:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl6lN-0004cy-Hi; Wed, 22 Jun 2005 11:03:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6lL-0004a6-U2
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 11:03:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20771
	for <sip@ietf.org>; Wed, 22 Jun 2005 11:03:33 -0400 (EDT)
Received: from [65.220.123.3] (helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl79S-00037s-Vv
	for sip@ietf.org; Wed, 22 Jun 2005 11:28:33 -0400
Received: from keywest (hide.pingtel.com [65.220.123.2])
	by mail.pingtel.com (Postfix) with SMTP id 268E36C019
	for <sip@ietf.org>; Wed, 22 Jun 2005 11:03:26 -0400 (EDT)
From: "Dale Worley" <dworley@pingtel.com>
To: "'Sip (E-mail)'" <sip@ietf.org>
Subject: RE: [Sip] Some comments on GRUUs
Date: Wed, 22 Jun 2005 11:02:13 -0400
Message-ID: <005201c5773b$5fbced40$6a01010a@keywest>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <42B960F1.8090902@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>
> > This mechanism does have the limitation that the true target URIs for
> > the dialog are no longer the stated contact URIs and cannot be changed
> > during the dialog by a re-INVITE.
>
> True. That is a theoretical problem, but I'm still looking for a real
> world use case where the target is changed.

I would expect it to be significant only in high mobility applications.

> Yeah, this could work. But I haven't heard of a compelling need for it.
>
> This would require authorization. The registrar may not want to provide
> this service to just anybody. And it might not want to provide it for
> other reasons as well. For reasons of tracability it may not want to
> service requests that don't have an associated AoR.

Yes.  I don't think it will be of general use, but it struck me that it
would be good to verify that we could construct an extension to create GRUUs
without AORs within the proposed framework, for those uncommon situations
where it would be useful.

> There is other work underway that will do much the same thing, allowing
> the registration of multiple contacts with the same instance id. The
> motivation was to allow registration thru multiple paths for redundancy.
> I think there is a draft, but at the moment I don't recall the name.

In what way is that different from just registering multiple contacts for
the same AOR?

> > * Syntax of URNs
> >
> > The "sip.instance" parameter has a value which is a URN.  However, a
> > number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
> > with "<...>", which is not strictly valid.  Though this would be
> > unlikely to cause functional problems in real implmentations, the
> > examples should be corrected:
>
> The <> is part of the syntax defined in 3840.3841 for callerprefs
> feature parameters. It indicates that the enclosed is a string rather
> than a list of tokens.

OK, thanks for explaining that.  Looking at 3840, I guess I never realized
that the "feature predicates" it discusses were to be used for declaring the
features that a UA possesses, rather than what one would expect from the
name, a predicate *filtering* the features of some arbitrary UA.  And
looking at the definition of "Contact Predicate" in section 3, I notice that
it does not really define what the contact predicate is a predicate *of*.
Has there been any clarification of that?

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 Jun 22 11:35:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dl7G1-000705-O7; Wed, 22 Jun 2005 11:35:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7Fv-0006xp-MR
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 11:35:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23991
	for <sip@ietf.org>; Wed, 22 Jun 2005 11:35:08 -0400 (EDT)
From: Udit_Goyal@3com.com
Received: from ahmler6.mail.eds.com ([192.85.154.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl7dz-0004KD-D9
	for sip@ietf.org; Wed, 22 Jun 2005 12:00:08 -0400
Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133])
	by ahmler6.mail.eds.com (8.13.4/8.12.10) with ESMTP id
	j5MFY2RM029081; Wed, 22 Jun 2005 11:34:05 -0400
Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1])
	by ahmlir3.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5MFXfUO021098; 
	Wed, 22 Jun 2005 11:33:41 -0400
Received: from usut001.3com.com ([205.142.126.149])
	by ahmlir3.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5MFXe3S021093; 
	Wed, 22 Jun 2005 11:33:40 -0400
In-Reply-To: <OFC2A9D537.028F54B8-ON65257028.0020A769-65257028.0031B6A1@flextronicssoftware.com>
To: Aman Arora <aman.arora@flextronicssoftware.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Message-ID: <OF093400F2.776104F4-ON65257028.00559DF0-85257028.00556594@3com.com>
Date: Wed, 22 Jun 2005 11:39:52 -0400
X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26,
	2003) at 06/22/2005 08:33:40 AM,
	Serialize complete at 06/22/2005 08:33:40 AM
X-Spam-Score: 0.9 (/)
X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92
Cc: sip@ietf.org, sip-implementors-bounces@cs.columbia.edu,
	sip-implementors@cs.columbia.edu
Subject: [Sip] Re: [Sip-implementors] Query on Re-transmission of non 2xx
 responses in	an Invite Transaction
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="===============0819510372=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0819510372==
Content-Type: multipart/alternative;
	boundary="=_alternative 0055658D85257028_="

This is a multipart message in MIME format.
--=_alternative 0055658D85257028_=
Content-Type: text/plain; charset="US-ASCII"

Aman,

For INVITE transaction, retransmission of requests will only occur when 
client had not received the provisional responses.
In this case, server needs to send the responses for each retransmitted 
request since client transaction is still inCalling state.

In case, when provisional response had been received, no retransmission of 
request occur, and server transaction needs to retransmit final responses 
till it get an ACK. Timer G basically taking care of the retransmission of 
the final responses till ACK is received. 

Hope it clarifies your doubt.

Regards,
Udit



Aman Arora <aman.arora@flextronicssoftware.com> 
Sent by: sip-implementors-bounces@cs.columbia.edu
06/22/2005 05:03 AM

To
sip@ietf.org, sip-implementors@cs.columbia.edu, 
sip-implementors-bounces@cs.columbia.edu
cc

Subject
[Sip-implementors] Query on Re-transmission of non 2xx responses in     an 
Invite Transaction










Hi all,

Section 17.2.1 of RFC 3261 says the following for the Invite Server
Transaction:

While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state.  For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.

This is a change from RFC 2543, where responses were always
retransmitted, even over reliable transports.

Additionally as per Figure 7 in the RFC, we are also supposed to
re-transmit the responses, on
receiving the re-transmitted request (as in case of the non-Invite
transaction).


|INVITE
|pass INV to TU
INVITE             V send 100 if TU won't in 200ms
send response+-----------+
+--------|           |--------+101-199 from TU
|        | Proceeding|        |send response
+------->|           |<-------+
|           |          Transport Err.
|           |          Inform TU
|           |--------------->+
+-----------+                |
300-699 from TU |     |2xx from TU        |
send response   |     |send response      |
|     +------------------>+
|                         |
INVITE          V          Timer G fires  |
send response+-----------+ send response  |
+--------|           |--------+       |
|        | Completed |        |       |
+------->|           |<-------+       |
+-----------+                |
|     |                   |
ACK |     |                   |
-   |     +------------------>+
|        Timer H fires    |
V        or Transport Err.|
+-----------+  Inform TU     |
|           |                |
| Confirmed |                |
|           |                |
+-----------+                |
|                      |
|Timer I fires         |
|-                     |
|                      |
V                      |
+-----------+                |
|           |                |
| Terminated|<---------------+
|           |
+-----------+


My doubt is that incase the server transaction (say within a Proxy) is
anyways re-transmitting
responses locally (when timer G fires), why do we need to support
re-transmission of responses
for a re-transmitted request, as is suggested in the figure.

One possible situation where this would be required is when, the request
re-transmission timer
at the client transaction is configured to a value less than that of timer
G. But even then when
timer G would fire in the server transaction, we would anyways re-transmit
the response once again.
Thus I feel this additional functionality of re-transmitting responses for
the re-transmitted requests
is not really required.

I would appreciate any clarification on this.

regards
Aman


***********************  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-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--=_alternative 0055658D85257028_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Aman,</font>
<br>
<br><font size=2 face="sans-serif">For INVITE transaction, retransmission
of requests will only occur when client had not received the provisional
responses.</font>
<br><font size=2 face="sans-serif">In this case, server needs to send the
responses for each retransmitted request since client transaction is still
inCalling state.</font>
<br>
<br><font size=2 face="sans-serif">In case, when provisional response had
been received, no retransmission of request occur, and server transaction
needs to retransmit final responses till it get an ACK. Timer G basically
taking care of the retransmission of the final responses till ACK is received.
</font>
<br>
<br><font size=2 face="sans-serif">Hope it clarifies your doubt.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Udit</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Aman Arora &lt;aman.arora@flextronicssoftware.com&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: sip-implementors-bounces@cs.columbia.edu</font>
<p><font size=1 face="sans-serif">06/22/2005 05:03 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">sip@ietf.org, sip-implementors@cs.columbia.edu,
sip-implementors-bounces@cs.columbia.edu</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">[Sip-implementors] Query
on Re-transmission of non 2xx responses in &nbsp; &nbsp; &nbsp; &nbsp;an
Invite Transaction</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2><tt>Hi all,<br>
</tt></font>
<br><font size=2><tt>Section 17.2.1 of RFC 3261 says the following for
the Invite Server<br>
Transaction:<br>
</tt></font>
<br><font size=2><tt>While in the &quot;Proceeding&quot; state, if the
TU passes a response with<br>
status code from 300 to 699 to the server transaction, the response<br>
MUST be passed to the transport layer for transmission, and the state<br>
machine MUST enter the &quot;Completed&quot; state. &nbsp;For unreliable
transports,<br>
timer G is set to fire in T1 seconds, and is not set to fire for<br>
reliable transports.<br>
</tt></font>
<br><font size=2><tt>This is a change from RFC 2543, where responses were
always<br>
retransmitted, even over reliable transports.</tt></font>
<br>
<br><font size=2><tt>Additionally as per Figure 7 in the RFC, we are also
supposed to<br>
re-transmit the responses, on<br>
receiving the re-transmitted request (as in case of the non-Invite<br>
transaction).<br>
</tt></font>
<br>
<br><font size=2><tt>|INVITE<br>
|pass INV to TU</tt></font>
<br><font size=2><tt>INVITE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; V
send 100 if TU won't in 200ms<br>
send response+-----------+</tt></font>
<br><font size=2><tt>+--------| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |--------+101-199
from TU<br>
| &nbsp; &nbsp; &nbsp; &nbsp;| Proceeding| &nbsp; &nbsp; &nbsp; &nbsp;|send
response<br>
+-------&gt;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&lt;-------+</tt></font>
<br><font size=2><tt>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;Transport Err.<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Inform
TU<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |---------------&gt;+<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</tt></font>
<br><font size=2><tt>300-699 from TU | &nbsp; &nbsp; |2xx from TU &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
send response &nbsp; | &nbsp; &nbsp; |send response &nbsp; &nbsp; &nbsp;|</tt></font>
<br><font size=2><tt>| &nbsp; &nbsp; +------------------&gt;+<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; |</tt></font>
<br><font size=2><tt>INVITE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;Timer G fires &nbsp;|<br>
send response+-----------+ send response &nbsp;|</tt></font>
<br><font size=2><tt>+--------| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |--------+
&nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp;| Completed | &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; |<br>
+-------&gt;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&lt;-------+ &nbsp; &nbsp;
&nbsp; |</tt></font>
<br><font size=2><tt>+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
| &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; |</tt></font>
<br><font size=2><tt>ACK | &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
- &nbsp; | &nbsp; &nbsp; +------------------&gt;+</tt></font>
<br><font size=2><tt>| &nbsp; &nbsp; &nbsp; &nbsp;Timer H fires &nbsp;
&nbsp;|<br>
V &nbsp; &nbsp; &nbsp; &nbsp;or Transport Err.|</tt></font>
<br><font size=2><tt>+-----------+ &nbsp;Inform TU &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
| Confirmed | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</tt></font>
<br><font size=2><tt>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;|<br>
|Timer I fires &nbsp; &nbsp; &nbsp; &nbsp; |<br>
|- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;|<br>
V &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;|</tt></font>
<br><font size=2><tt>+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
| Terminated|&lt;---------------+<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
+-----------+</tt></font>
<br>
<br>
<br><font size=2><tt>My doubt is that incase the server transaction (say
within a Proxy) is<br>
anyways re-transmitting<br>
responses locally (when timer G fires), why do we need to support<br>
re-transmission of responses<br>
for a re-transmitted request, as is suggested in the figure.<br>
</tt></font>
<br><font size=2><tt>One possible situation where this would be required
is when, the request<br>
re-transmission timer<br>
at the client transaction is configured to a value less than that of timer<br>
G. But even then when<br>
timer G would fire in the server transaction, we would anyways re-transmit<br>
the response once again.<br>
Thus I feel this additional functionality of re-transmitting responses
for<br>
the re-transmitted requests<br>
is not really required.<br>
</tt></font>
<br><font size=2><tt>I would appreciate any clarification on this.<br>
</tt></font>
<br><font size=2><tt>regards<br>
Aman<br>
</tt></font>
<br>
<br><font size=2><tt>*********************** &nbsp;FSS-Unclassified &nbsp;
***********************<br>
&quot;DISCLAIMER: This message is proprietary to Flextronics Software Systems<br>
Limited (FSS) and is intended solely for the use of the<br>
individual to whom it is addressed. It may contain &nbsp;privileged or<br>
confidential information and should not be circulated or used for<br>
any purpose other than for what it is intended. If you have received this<br>
message in &nbsp;error, please notify the originator immediately.<br>
If you are not the intended recipient, you are notified that you are<br>
strictly &nbsp;prohibited &nbsp;from &nbsp;using, copying, altering, or
disclosing<br>
the contents of this message. &nbsp;FSS &nbsp;accepts no &nbsp;responsibility
&nbsp;for loss or<br>
damage arising from the use of &nbsp;the information transmitted<br>
by this email including damage from virus.&quot;<br>
</tt></font>
<br><font size=2><tt>_______________________________________________<br>
Sip-implementors mailing list<br>
Sip-implementors@cs.columbia.edu</tt></font>
<br><font size=2><tt>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors</tt></font>
<br>
--=_alternative 0055658D85257028_=--


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




From sip-bounces@ietf.org Thu Jun 23 04:12:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlMp4-0001tK-Ur; Thu, 23 Jun 2005 04:12:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlMou-0001qv-Kf
	for sip@megatron.ietf.org; Thu, 23 Jun 2005 04:12:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14488
	for <sip@ietf.org>; Thu, 23 Jun 2005 04:12:18 -0400 (EDT)
Received: from delta.hssblr.co.in ([203.145.155.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlND9-0006DX-8s
	for sip@ietf.org; Thu, 23 Jun 2005 04:37:26 -0400
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 j5N8Bsi14833;
	Thu, 23 Jun 2005 13:41:55 +0530
In-Reply-To: <OFE3F365AC.11F95A55-ON65257029.00280A33-65257029.0028A1CC@flextronicssoftware.com>
To: Aman Arora <aman.arora@flextronicssoftware.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OFDEC04FDE.CA969ED3-ON65257029.002CAAA6-65257029.002D06F6@flextronicssoftware.com>
From: Rajeev Seth <rajeev.seth@flextronicssoftware.com>
Date: Thu, 23 Jun 2005 13:41:41 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 06/23/2005 01:45:19 PM,
	Serialize complete at 06/23/2005 01:45:19 PM
X-Spam-Score: 1.0 (+)
X-Scan-Signature: f1365f29d5c3f875a511b3c836c51021
Cc: sip@ietf.org, sip-implementors-bounces@cs.columbia.edu,
	sip-implementors@cs.columbia.edu
Subject: [Sip] Re: [Sip-implementors] Query on Re-transmission of non 2xx
 responses	in	an Invite Transaction
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="===============0803881616=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0803881616==
Content-Type: multipart/alternative;
	boundary="=_alternative 002D06EE65257029_="

This is a multipart message in MIME format.
--=_alternative 002D06EE65257029_=
Content-Type: text/plain; charset="US-ASCII"

Hi Aman,

As per 17.2.1 the retransmission of the last sent response on receiving a 
retransmitted request is  MUST only  if the Server transaction is in the 
"Proceeding" state ( 1xx is sent).

However  17.2.1 says about *completed* state ( State after sending 
3xx..6xx responses)  ==>>

"while in the "Completed" state, if a request retransmission is  received, 
the server SHOULD pass the response to the transport for retransmission"

In the *completed* state not retransmitting the final response on 
receiving a retransmitted request may only lead to maximum delay of 4 secs 
for the response to reach to the UAC as timer G is MIN(2*T1,T2). Therefore 
it is not a  MUST condition.

Retransmitting the provisional response in the *proceeding* state is MUST 
because client transaction will stop the retransmission of requests ( 
Timer A  will stop in proceeding state) and possibly UAC will start a 
no-answer timer  on receiving a provisional response only.

Regards,

Rajeev




Aman Arora <aman.arora@flextronicssoftware.com> 
Sent by: sip-implementors-bounces@cs.columbia.edu
06/23/2005 12:53 PM


To
Udit_Goyal@3com.com
cc
sip@ietf.org, sip-implementors-bounces@cs.columbia.edu, 
sip-implementors@cs.columbia.edu
Subject
Re: [Sip-implementors] Query on Re-transmission of non 2xx responses    in 
an Invite Transaction










hi Udit,

What will happen in a situation where we send out a non 2xx response to 
the
Invite before sending out any
provisional response?
Though 100 Trying is sent, yet in case of a cross, what is the need to
re-transmit the response for a re-transmitted
request, when anyways we are going to perform self re-transmissions? So 
why
does a server transaction need
to re-transmit a response on receiving a re-transmitted request in the
Confirmed State (as per figure 7 in the RFC)

My query was primarily for non 2xx (final responses) to an INVITE.

rgds
aman


 
             Udit_Goyal@3com.c 
             om 
                                                                        To 

             06/22/2005 09:09          Aman Arora 
             PM                        <aman.arora@flextronicssoftware.com 

                                       > 
                                                                        cc 

                                       sip@ietf.org, 
                                       sip-implementors@cs.columbia.edu, 
                                       sip-implementors-bounces@cs.columbi 

                                       a.edu 
                                                                   Subject 

                                       Re: [Sip-implementors] Query on 
                                       Re-transmission of non 2xx 
                                       responses in  an Invite Transaction 

 
 
 
 
 
 





Aman,

For INVITE transaction, retransmission of requests will only occur when
client had not received the provisional responses.
In this case, server needs to send the responses for each retransmitted
request since client transaction is still inCalling state.

In case, when provisional response had been received, no retransmission of
request occur, and server transaction needs to retransmit final responses
till it get an ACK. Timer G basically taking care of the retransmission of
the final responses till ACK is received.

Hope it clarifies your doubt.

Regards,
Udit

 
 Aman Arora 
 <aman.arora@flextronicssoft 
 ware.com> 
 Sent by:                                                               To 

 sip-implementors-bounces@cs            sip@ietf.org, 
 .columbia.edu                          sip-implementors@cs.columbia.edu, 
                                        sip-implementors-bounces@cs.columb 

                                        ia.edu 
 06/22/2005 05:03 AM                                                    cc 

 
                                                                   Subject 

                                        [Sip-implementors] Query on 
                                        Re-transmission of non 2xx 
                                        responses in        an Invite 
                                        Transaction 
 
 
 
 
 
 
 









Hi all,

Section 17.2.1 of RFC 3261 says the following for the Invite Server
Transaction:

While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state.  For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.

This is a change from RFC 2543, where responses were always
retransmitted, even over reliable transports.

Additionally as per Figure 7 in the RFC, we are also supposed to
re-transmit the responses, on
receiving the re-transmitted request (as in case of the non-Invite
transaction).


|INVITE
|pass INV to TU
INVITE             V send 100 if TU won't in 200ms
send response+-----------+
+--------|           |--------+101-199 from TU
|        | Proceeding|        |send response
+------->|           |<-------+
|           |          Transport Err.
|           |          Inform TU
|           |--------------->+
+-----------+                |
300-699 from TU |     |2xx from TU        |
send response   |     |send response      |
|     +------------------>+
|                         |
INVITE          V          Timer G fires  |
send response+-----------+ send response  |
+--------|           |--------+       |
|        | Completed |        |       |
+------->|           |<-------+       |
+-----------+                |
|     |                   |
ACK |     |                   |
-   |     +------------------>+
|        Timer H fires    |
V        or Transport Err.|
+-----------+  Inform TU     |
|           |                |
| Confirmed |                |
|           |                |
+-----------+                |
|                      |
|Timer I fires         |
|-                     |
|                      |
V                      |
+-----------+                |
|           |                |
| Terminated|<---------------+
|           |
+-----------+


My doubt is that incase the server transaction (say within a Proxy) is
anyways re-transmitting
responses locally (when timer G fires), why do we need to support
re-transmission of responses
for a re-transmitted request, as is suggested in the figure.

One possible situation where this would be required is when, the request
re-transmission timer
at the client transaction is configured to a value less than that of timer
G. But even then when
timer G would fire in the server transaction, we would anyways re-transmit
the response once again.
Thus I feel this additional functionality of re-transmitting responses for
the re-transmitted requests
is not really required.

I would appreciate any clarification on this.

regards
Aman


***********************  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-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


***********************  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-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors



***********************  FSS-Private   ***********************
--=_alternative 002D06EE65257029_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Hi Aman,</tt></font>
<br>
<br><font size=2><tt>As per 17.2.1 the retransmission of the last sent
response on receiving a retransmitted request is &nbsp;MUST only &nbsp;if
the Server transaction is in the &quot;Proceeding&quot; state ( 1xx is
sent).</tt></font>
<br>
<br><font size=2><tt>However &nbsp;17.2.1 says about *completed* state
( State after sending 3xx..6xx responses) &nbsp;==&gt;&gt;</tt></font>
<br>
<br><font size=2><tt>&quot;while in the &quot;Completed&quot; state, if
a request retransmission is &nbsp;received, the server SHOULD pass the
response to the transport for retransmission&quot;</tt></font>
<br>
<br><font size=2><tt>In the *completed* state not retransmitting the final
response on receiving a retransmitted request may only lead to maximum
delay of 4 secs for the response to reach to the UAC as timer G is MIN(2*T1,T2).
Therefore it is not a &nbsp;MUST condition.</tt></font>
<br>
<br><font size=2><tt>Retransmitting the provisional response in the *proceeding*
state is MUST because client transaction will stop the retransmission of
requests ( Timer A &nbsp;will stop in proceeding state) and possibly UAC
will start a no-answer timer &nbsp;on receiving a provisional response
only.</tt></font>
<br>
<br><font size=2><tt>Regards,</tt></font>
<br>
<br><font size=2 face="sans-serif">Rajeev</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Aman Arora &lt;aman.arora@flextronicssoftware.com&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: sip-implementors-bounces@cs.columbia.edu</font>
<p><font size=1 face="sans-serif">06/23/2005 12:53 PM</font>
<br>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Udit_Goyal@3com.com</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">sip@ietf.org, sip-implementors-bounces@cs.columbia.edu,
sip-implementors@cs.columbia.edu</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [Sip-implementors] Query
on Re-transmission of non 2xx responses &nbsp; &nbsp; &nbsp; &nbsp;in
&nbsp; &nbsp; &nbsp; &nbsp;an Invite Transaction</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
<br>
<br>
<br>
hi Udit,<br>
<br>
What will happen in a situation where we send out a non 2xx response to
the<br>
Invite before sending out any<br>
provisional response?<br>
Though 100 Trying is sent, yet in case of a cross, what is the need to<br>
re-transmit the response for a re-transmitted<br>
request, when anyways we are going to perform self re-transmissions? So
why<br>
does a server transaction need<br>
to re-transmit a response on receiving a re-transmitted request in the<br>
Confirmed State (as per figure 7 in the RFC)<br>
<br>
My query was primarily for non 2xx (final responses) to an INVITE.<br>
<br>
rgds<br>
aman<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Udit_Goyal@3com.c &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; om &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;To <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 06/22/2005 09:09 &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;Aman Arora &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PM &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;aman.arora@flextronicssoftware.com
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &gt; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;cc <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sip@ietf.org,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sip-implementors@cs.columbia.edu,
&nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sip-implementors-bounces@cs.columbi
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a.edu &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; Subject <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Re: [Sip-implementors]
Query on &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Re-transmission
of non 2xx &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; responses
in &nbsp;an Invite Transaction <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
<br>
<br>
<br>
<br>
<br>
Aman,<br>
<br>
For INVITE transaction, retransmission of requests will only occur when<br>
client had not received the provisional responses.<br>
In this case, server needs to send the responses for each retransmitted<br>
request since client transaction is still inCalling state.<br>
<br>
In case, when provisional response had been received, no retransmission
of<br>
request occur, and server transaction needs to retransmit final responses<br>
till it get an ACK. Timer G basically taking care of the retransmission
of<br>
the final responses till ACK is received.<br>
<br>
Hope it clarifies your doubt.<br>
<br>
Regards,<br>
Udit<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 Aman Arora &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;<br>
 &lt;aman.arora@flextronicssoft &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 ware.com&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; <br>
 Sent by: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
To <br>
 sip-implementors-bounces@cs &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;sip@ietf.org,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 .columbia.edu &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;sip-implementors@cs.columbia.edu, &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;sip-implementors-bounces@cs.columb
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ia.edu
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
 06/22/2005 05:03 AM &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cc <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; Subject <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[Sip-implementors]
Query on &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Re-transmission
of non 2xx &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;responses
in &nbsp; &nbsp; &nbsp; &nbsp;an Invite &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Transaction
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hi all,<br>
<br>
Section 17.2.1 of RFC 3261 says the following for the Invite Server<br>
Transaction:<br>
<br>
While in the &quot;Proceeding&quot; state, if the TU passes a response
with<br>
status code from 300 to 699 to the server transaction, the response<br>
MUST be passed to the transport layer for transmission, and the state<br>
machine MUST enter the &quot;Completed&quot; state. &nbsp;For unreliable
transports,<br>
timer G is set to fire in T1 seconds, and is not set to fire for<br>
reliable transports.<br>
<br>
This is a change from RFC 2543, where responses were always<br>
retransmitted, even over reliable transports.<br>
<br>
Additionally as per Figure 7 in the RFC, we are also supposed to<br>
re-transmit the responses, on<br>
receiving the re-transmitted request (as in case of the non-Invite<br>
transaction).<br>
<br>
<br>
|INVITE<br>
|pass INV to TU<br>
INVITE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; V send 100 if TU won't
in 200ms<br>
send response+-----------+<br>
+--------| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |--------+101-199 from TU<br>
| &nbsp; &nbsp; &nbsp; &nbsp;| Proceeding| &nbsp; &nbsp; &nbsp; &nbsp;|send
response<br>
+-------&gt;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&lt;-------+<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Transport
Err.<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Inform
TU<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |---------------&gt;+<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
300-699 from TU | &nbsp; &nbsp; |2xx from TU &nbsp; &nbsp; &nbsp; &nbsp;|<br>
send response &nbsp; | &nbsp; &nbsp; |send response &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; +------------------&gt;+<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; |<br>
INVITE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;V &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;Timer G fires &nbsp;|<br>
send response+-----------+ send response &nbsp;|<br>
+--------| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |--------+ &nbsp; &nbsp;
&nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp;| Completed | &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; |<br>
+-------&gt;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&lt;-------+ &nbsp; &nbsp;
&nbsp; |<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; |<br>
ACK | &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; |<br>
- &nbsp; | &nbsp; &nbsp; +------------------&gt;+<br>
| &nbsp; &nbsp; &nbsp; &nbsp;Timer H fires &nbsp; &nbsp;|<br>
V &nbsp; &nbsp; &nbsp; &nbsp;or Transport Err.|<br>
+-----------+ &nbsp;Inform TU &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
| Confirmed | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;|<br>
|Timer I fires &nbsp; &nbsp; &nbsp; &nbsp; |<br>
|- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;|<br>
V &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;|<br>
+-----------+ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
| Terminated|&lt;---------------+<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
+-----------+<br>
<br>
<br>
My doubt is that incase the server transaction (say within a Proxy) is<br>
anyways re-transmitting<br>
responses locally (when timer G fires), why do we need to support<br>
re-transmission of responses<br>
for a re-transmitted request, as is suggested in the figure.<br>
<br>
One possible situation where this would be required is when, the request<br>
re-transmission timer<br>
at the client transaction is configured to a value less than that of timer<br>
G. But even then when<br>
timer G would fire in the server transaction, we would anyways re-transmit<br>
the response once again.<br>
Thus I feel this additional functionality of re-transmitting responses
for<br>
the re-transmitted requests<br>
is not really required.<br>
<br>
I would appreciate any clarification on this.<br>
<br>
regards<br>
Aman<br>
<br>
<br>
*********************** &nbsp;FSS-Unclassified &nbsp; ***********************<br>
&quot;DISCLAIMER: This message is proprietary to Flextronics Software Systems<br>
Limited (FSS) and is intended solely for the use of the<br>
individual to whom it is addressed. It may contain &nbsp;privileged or<br>
confidential information and should not be circulated or used for<br>
any purpose other than for what it is intended. If you have received this<br>
message in &nbsp;error, please notify the originator immediately.<br>
If you are not the intended recipient, you are notified that you are<br>
strictly &nbsp;prohibited &nbsp;from &nbsp;using, copying, altering, or
disclosing<br>
the contents of this message. &nbsp;FSS &nbsp;accepts no &nbsp;responsibility
&nbsp;for loss or<br>
damage arising from the use of &nbsp;the information transmitted<br>
by this email including damage from virus.&quot;<br>
<br>
_______________________________________________<br>
Sip-implementors mailing list<br>
Sip-implementors@cs.columbia.edu<br>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors<br>
<br>
<br>
*********************** &nbsp;FSS-Unclassified &nbsp; ***********************<br>
&quot;DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited<br>
(HSS) and is intended solely for the use of the individual to whom it is<br>
addressed. It may contain &nbsp;privileged or confidential information
and<br>
should not be circulated or used for any purpose other than for what it
is<br>
intended. If you have received this message in error, please notify the<br>
originator immediately. If you are not the intended recipient, you are<br>
notified that you are strictly prohibited from using, copying, altering,
or<br>
disclosing the contents of this message. HSS accepts no responsibility
for<br>
loss or damage arising from the use of the information transmitted by this<br>
email including damage from virus.&quot;<br>
<br>
_______________________________________________<br>
Sip-implementors mailing list<br>
Sip-implementors@cs.columbia.edu<br>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors<br>
</tt></font>
<br><font size=2 face="sans-serif"><br>
<br>
*********************** &nbsp;FSS-Private &nbsp; ***********************</font>
--=_alternative 002D06EE65257029_=--


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




From sip-bounces@ietf.org Thu Jun 23 09:26:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlRjD-0002DR-Qe; Thu, 23 Jun 2005 09:26:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRjB-0002DM-Bj
	for sip@megatron.ietf.org; Thu, 23 Jun 2005 09:26:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09733
	for <sip@ietf.org>; Thu, 23 Jun 2005 09:26:44 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlS7U-0003q3-AP
	for sip@ietf.org; Thu, 23 Jun 2005 09:51:54 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 23 Jun 2005 09:26:34 -0400
X-IronPort-AV: i="3.93,223,1115006400"; 
	d="scan'208"; a="59259037:sNHT29230004"
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 j5NDOucH008848; 
	Thu, 23 Jun 2005 09:26:34 -0400 (EDT)
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, 23 Jun 2005 09:26:12 -0400
Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 09:26:10 -0400
Message-ID: <42BAB869.1070800@cisco.com>
Date: Thu, 23 Jun 2005 09:26:01 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dale Worley <dworley@pingtel.com>
Subject: Re: [Sip] Some comments on GRUUs
References: <005201c5773b$5fbced40$6a01010a@keywest>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2005 13:26:10.0718 (UTC)
	FILETIME=[1ECB13E0:01C577F7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: "'Sip \(E-mail\)'" <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



Dale Worley wrote:

>>There is other work underway that will do much the same thing, allowing
>>the registration of multiple contacts with the same instance id. The
>>motivation was to allow registration thru multiple paths for redundancy.
>>I think there is a draft, but at the moment I don't recall the name.
> 
> In what way is that different from just registering multiple contacts for
> the same AOR?

The draft I was thinking of is draft-jennings-sipping-outbound-01.txt. 
It allows multiple registrations with the same instance id, but 
distinguished by a unique flow id. Only one registration per 
instanceid/flowid pair is permitted.

This doesn't explicitly address GRUU, but the gruu mechanism should work 
with it - the same gruu would be assigned as long as the instanceid 
remains the same. In this draft you wouldn't be registering multiple 
contacts in the same REGISTER call, since the point is to send them over 
different paths.

So this isn't quite the same thing, but the same mechanisms might 
support both. At least it would be helpful for you to coordinate what 
you have in mind with that.

	Paul

>>>* Syntax of URNs
>>>
>>>The "sip.instance" parameter has a value which is a URN.  However, a
>>>number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
>>>with "<...>", which is not strictly valid.  Though this would be
>>>unlikely to cause functional problems in real implmentations, the
>>>examples should be corrected:
>>
>>The <> is part of the syntax defined in 3840.3841 for callerprefs
>>feature parameters. It indicates that the enclosed is a string rather
>>than a list of tokens.
> 
> 
> OK, thanks for explaining that.  Looking at 3840, I guess I never realized
> that the "feature predicates" it discusses were to be used for declaring the
> features that a UA possesses, rather than what one would expect from the
> name, a predicate *filtering* the features of some arbitrary UA.  And
> looking at the definition of "Contact Predicate" in section 3, I notice that
> it does not really define what the contact predicate is a predicate *of*.
> Has there been any clarification of that?
> 
> 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 Sat Jun 25 16:15:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmH3p-0003sT-9U; Sat, 25 Jun 2005 16:15:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmH3n-0003sO-QM
	for sip@megatron.ietf.org; Sat, 25 Jun 2005 16:15:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03636
	for <sip@ietf.org>; Sat, 25 Jun 2005 16:15:26 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmHSa-0007uP-QN
	for sip@ietf.org; Sat, 25 Jun 2005 16:41:06 -0400
Received: from [69.170.1.53] (HELO JMHLap3.stevecrocker.com)
	by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
	with ESMTP id 11104579; Sat, 25 Jun 2005 16:15:25 -0400
Message-Id: <6.2.1.2.0.20050625145843.02eab8a0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sat, 25 Jun 2005 16:09:53 -0400
To: "'General Area Review Team'" <gen-art@alvestrand.no>
From: "Joel M. Halpern" <joel@stevecrocker.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB05312B30@zrc2hxm1.corp.nor
	tel.com>
References: <E3F9D87C63E2774390FE67C924EC99BB05312B30@zrc2hxm1.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: rohan@ekabal.com, mankin@psg.com, sip@ietf.org, jmpolk@cisco.com,
	dean.willis@softarmor.com, hgs@cs.columbia.edu
Subject: [Sip] Re: ETF LC review: draft-ietf-sip-resource-priority-09
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 a general area review.  This review of draft .9 is intended as 
early review for the IESG consideration.
  Details on the general area review team can be found at 
http://www.alvestrand.no/ietf/gen/art/review-guidelines.html
  The reviewer apologizes for not getting these minor comments to the 
relevant parties sooner.]

This document appears ready for publication as a Proposed Standard.  There 
are some minor matters that ought to be attended to.

Section 4.7.1.1 states that "A UAC in an administrative domain that employs 
preemption MUST ..."  I know what administrative domains usually mean, but 
it seems likely that in this case there may be at least three different 
administrative domains that the UAC is "in".  There is the IP domain at and 
near the originating UAC which may have SIP Proxies (either mandated by 
policy or transparently inserted.)  There is the domain of the subscribers 
chosen outbound proxy (if any), and there is the domain of the destination 
UAC.  There may be other domains along the signaling path.  Given the 
multiplicity of domains, and that a client may change domains, one of two 
things seems necessary.
Preferably, just require that ALL UACs supporting this RFC be prepared to 
receive the BYE with sipping reason ....  This does not seem onerous, and 
does seem to solve the issue.
Alternatively, the text needs a clear explanation of what "administrative 
domain" is meant and how a UAC would know whether to be prepared to receive 
the error indication.  Given the difficulty of building client software for 
specific administrative domains, this seems a doubtful choice.


Joel M. Halpern

----
TRANSPORT
     Communications Resource Priority for the Session Initiation Protocol(SIP),
          for Proposed Standard
     draft-ietf-sip-resource-priority-09
AD: Allison Mankin
Reviewer: Joel M. Halpern



_______________________________________________
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 Jun 25 21:02:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmLXk-0002QA-2i; Sat, 25 Jun 2005 21:02:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmLXh-0002Q3-NP
	for sip@megatron.ietf.org; Sat, 25 Jun 2005 21:02:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22974
	for <sip@ietf.org>; Sat, 25 Jun 2005 21:02:33 -0400 (EDT)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmLwU-0005gR-Tt
	for sip@ietf.org; Sat, 25 Jun 2005 21:28:16 -0400
Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net
	[141.153.173.119]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5Q11I0f025821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 25 Jun 2005 21:01:20 -0400 (EDT)
Message-ID: <42BDFE57.2010109@cs.columbia.edu>
Date: Sat, 25 Jun 2005 21:01:11 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Joel M. Halpern" <joel@stevecrocker.com>
References: <E3F9D87C63E2774390FE67C924EC99BB05312B30@zrc2hxm1.corp.nortel.com>
	<6.2.1.2.0.20050625145843.02eab8a0@localhost>
In-Reply-To: <6.2.1.2.0.20050625145843.02eab8a0@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: rohan@ekabal.com, dean.willis@softarmor.com, sip@ietf.org, mankin@psg.com,
	jmpolk@cisco.com, 'General Area Review Team' <gen-art@alvestrand.no>
Subject: [Sip] Re: ETF LC review: draft-ietf-sip-resource-priority-09
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:

thanks for taking the time to review the draft. I agree that words like 
"administrative domain" can be interpreted in multiple ways, 
particularly in the multi-hop cases you mention. (Many of the 
participants in the discussion tend to assume that R-P operates in 
relatively closed environments where this would not be a concern, in 
that UAC, UAS and proxies would be administered by the same authority.)

To address your comment: Since the Reason header causes no protocol 
state transitions, ANY UAC 'must (will) be prepared to receive it' 
(since there are no preparations to be taken - ignoring it will work 
just fine). The header really only makes sense here if the UAC requested 
a resource value that can cause preemption. Thus, I would reword the 
nettlesome sentence as something like

"A UAC that requests a priority value that may cause preemption MUST 
understand a Reason header field in the BYE request explaining why the 
session was terminated, as discussed in []."

If nobody objects, I will replace the sentence.

Henning

Joel M. Halpern wrote:

> Section 4.7.1.1 states that "A UAC in an administrative domain that 
> employs preemption MUST ..."  I know what administrative domains usually 
> mean, but it seems likely that in this case there may be at least three 
> different administrative domains that the UAC is "in".  There is the IP 
> domain at and near the originating UAC which may have SIP Proxies 
> (either mandated by policy or transparently inserted.)  There is the 
> domain of the subscribers chosen outbound proxy (if any), and there is 
> the domain of the destination UAC.  There may be other domains along the 
> signaling path.  Given the multiplicity of domains, and that a client 
> may change domains, one of two things seems necessary.
> Preferably, just require that ALL UACs supporting this RFC be prepared 
> to receive the BYE with sipping reason ....  This does not seem onerous, 
> and does seem to solve the issue.
> Alternatively, the text needs a clear explanation of what 
> "administrative domain" is meant and how a UAC would know whether to be 
> prepared to receive the error indication.  Given the difficulty of 
> building client software for specific administrative domains, this seems 
> a doubtful choice.
> 
> 
> Joel M. Halpern
> 
> ----
> TRANSPORT
>     Communications Resource Priority for the Session Initiation 
> Protocol(SIP),
>          for Proposed Standard
>     draft-ietf-sip-resource-priority-09
> AD: Allison Mankin
> Reviewer: Joel M. Halpern
> 


_______________________________________________
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 Jun 25 21:21:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmLq0-0006xt-Vx; Sat, 25 Jun 2005 21:21:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmLpy-0006xk-GE
	for sip@megatron.ietf.org; Sat, 25 Jun 2005 21:21:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23976
	for <sip@ietf.org>; Sat, 25 Jun 2005 21:21:28 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmMEp-00065U-5H
	for sip@ietf.org; Sat, 25 Jun 2005 21:47:11 -0400
Received: from [69.170.1.53] (HELO JMHLap3.stevecrocker.com)
	by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
	with ESMTP id 11108506; Sat, 25 Jun 2005 21:21:25 -0400
Message-Id: <6.2.1.2.0.20050625212058.02ed7e58@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sat, 25 Jun 2005 21:21:22 -0400
To: Henning Schulzrinne <hgs@cs.columbia.edu>
From: "Joel M. Halpern" <joel@stevecrocker.com>
In-Reply-To: <42BDFE57.2010109@cs.columbia.edu>
References: <E3F9D87C63E2774390FE67C924EC99BB05312B30@zrc2hxm1.corp.nortel.com>
	<6.2.1.2.0.20050625145843.02eab8a0@localhost>
	<42BDFE57.2010109@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: rohan@ekabal.com, dean.willis@softarmor.com, sip@ietf.org, mankin@psg.com,
	jmpolk@cisco.com, 'General Area Review Team' <gen-art@alvestrand.no>
Subject: [Sip] Re: ETF LC review: draft-ietf-sip-resource-priority-09
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

That would take care of my problems with the sentence.

Thank you,
Joel

At 09:01 PM 6/25/2005, Henning Schulzrinne wrote:
>Joel:
>
>thanks for taking the time to review the draft. I agree that words like 
>"administrative domain" can be interpreted in multiple ways, particularly 
>in the multi-hop cases you mention. (Many of the participants in the 
>discussion tend to assume that R-P operates in relatively closed 
>environments where this would not be a concern, in that UAC, UAS and 
>proxies would be administered by the same authority.)
>
>To address your comment: Since the Reason header causes no protocol state 
>transitions, ANY UAC 'must (will) be prepared to receive it' (since there 
>are no preparations to be taken - ignoring it will work just fine). The 
>header really only makes sense here if the UAC requested a resource value 
>that can cause preemption. Thus, I would reword the nettlesome sentence as 
>something like
>
>"A UAC that requests a priority value that may cause preemption MUST 
>understand a Reason header field in the BYE request explaining why the 
>session was terminated, as discussed in []."
>
>If nobody objects, I will replace the sentence.
>
>Henning
>
>Joel M. Halpern wrote:
>
>>Section 4.7.1.1 states that "A UAC in an administrative domain that 
>>employs preemption MUST ..."  I know what administrative domains usually 
>>mean, but it seems likely that in this case there may be at least three 
>>different administrative domains that the UAC is "in".  There is the IP 
>>domain at and near the originating UAC which may have SIP Proxies (either 
>>mandated by policy or transparently inserted.)  There is the domain of 
>>the subscribers chosen outbound proxy (if any), and there is the domain 
>>of the destination UAC.  There may be other domains along the signaling 
>>path.  Given the multiplicity of domains, and that a client may change 
>>domains, one of two things seems necessary.
>>Preferably, just require that ALL UACs supporting this RFC be prepared to 
>>receive the BYE with sipping reason ....  This does not seem onerous, and 
>>does seem to solve the issue.
>>Alternatively, the text needs a clear explanation of what "administrative 
>>domain" is meant and how a UAC would know whether to be prepared to 
>>receive the error indication.  Given the difficulty of building client 
>>software for specific administrative domains, this seems a doubtful choice.
>>
>>Joel M. Halpern
>>----
>>TRANSPORT
>>     Communications Resource Priority for the Session Initiation 
>> Protocol(SIP),
>>          for Proposed Standard
>>     draft-ietf-sip-resource-priority-09
>>AD: Allison Mankin
>>Reviewer: Joel M. Halpern


_______________________________________________
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 Jun 26 12:32:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dma3L-0005yZ-QC; Sun, 26 Jun 2005 12:32:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dma3J-0005yU-Ge
	for sip@megatron.ietf.org; Sun, 26 Jun 2005 12:32:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17398
	for <sip@ietf.org>; Sun, 26 Jun 2005 12:32:09 -0400 (EDT)
Received: from allozyme46.gprs.dnafinland.fi ([62.78.104.46]
	helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DmaSE-0004Pd-Oa for sip@ietf.org; Sun, 26 Jun 2005 12:58:02 -0400
Received: from rautu.tutpro.com (jh@localhost [127.0.0.1])
	by rautu.tutpro.com (8.13.4/8.13.4/Debian-1) with ESMTP id
	j5QGVtvP004369 for <sip@ietf.org>; Sun, 26 Jun 2005 19:31:55 +0300
Received: (from jh@localhost)
	by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j5QGVqLE004366;
	Sun, 26 Jun 2005 19:31:52 +0300
Date: Sun, 26 Jun 2005 19:31:52 +0300
From: Juha Heinanen <jh@tutpro.com>
Message-Id: <200506261631.j5QGVqLE004366@rautu.tutpro.com>
To: sip@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [Sip] comment on draft-ietf-sip-sctp-06.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

draft-ietf-sip-sctp-06.txt has a note:

Note that the value "tls", defined by RFC 3261, is intended for TLS over
TCP.

on the other hand 26.2.2 of rfc3261 has a note:

The use of transport=tls has consequently been deprecated, partly
because it was specific to a single hop of the request.

so if a transport parameter indicating tls over tcp has been deprecated,
why do we now need a transport parameter indicating tls over sctp?  what
makes sctp in this regards special as compared to tcp?

-- 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 Sun Jun 26 13:01:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmaW1-0006Os-GC; Sun, 26 Jun 2005 13:01:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmaVz-0006On-1R
	for sip@megatron.ietf.org; Sun, 26 Jun 2005 13:01:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23330
	for <sip@ietf.org>; Sun, 26 Jun 2005 13:01:47 -0400 (EDT)
From: tammi.nguyen@conexant.com
Received: from cnxtsmtp9.conexant.com ([198.62.9.206] helo=nbmime1.bbnet.ad)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmauv-0005qd-0P
	for sip@ietf.org; Sun, 26 Jun 2005 13:27:40 -0400
Received: Conexant Mail
To: sip@ietf.org
Message-ID: <OFCB6BFB18.213D7AFD-ON8825702C.005D8A0C-8825702C.005D8A0C@conexant.com>
Date: Sun, 26 Jun 2005 10:01:41 -0700
X-MIMETrack: Serialize by Router on NBLNBkup1/Server/Conexant 
	(Release 6.5.3|September 14, 2004) at 06/26/2005 10:01:44 AM
MIME-Version: 1.0
X-Spam-Score: 1.1 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [Sip] Tammi K Nguyen/USA/Conexant 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="===============0695900158=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

--===============0695900158==
Content-type: multipart/alternative; 
	Boundary="0__=07BBFABFDFCE0C9C8f9e8a93df938690918c07BBFABFDFCE0C9C"
Content-Disposition: inline

--0__=07BBFABFDFCE0C9C8f9e8a93df938690918c07BBFABFDFCE0C9C
Content-type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

Please see Kyle Rupert for all VoIP DVT-Related Concerns.

Regards,
-tammi



********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************


--0__=07BBFABFDFCE0C9C8f9e8a93df938690918c07BBFABFDFCE0C9C
Content-type: text/html; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

<html><body>
<p>I will be out of the office starting  06/24/2005 and will not return until 06/27/2005.<br>
<br>
Please see Kyle Rupert for all VoIP DVT-Related Concerns.<br>
<br>
Regards,<br>
-tammi
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;"> </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;"> </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">********************** Legal Disclaimer **************************** </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">&quot;This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email and delete the message. Thank you.&quot; </SPAN>
</P>
<P STYLE="margin-top: 0pt;margin-bottom: 0pt;"><SPAN STYLE="FONT-FAMILY:'Arial';FONT-SIZE:8pt;">********************************************************************** </SPAN> </P></body></html>

--0__=07BBFABFDFCE0C9C8f9e8a93df938690918c07BBFABFDFCE0C9C--


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




From sip-bounces@ietf.org Sun Jun 26 19:06:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmgCw-0002i5-11; Sun, 26 Jun 2005 19:06:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmgCt-0002hs-4w
	for sip@megatron.ietf.org; Sun, 26 Jun 2005 19:06:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21862
	for <sip@ietf.org>; Sun, 26 Jun 2005 19:06:27 -0400 (EDT)
Received: from endor.rfc3261.net ([212.112.227.208])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmgbt-0005yK-Oz
	for sip@ietf.org; Sun, 26 Jun 2005 19:32:23 -0400
Received: from localhost (localhost [127.0.0.1])
	by endor.rfc3261.net (Postfix) with ESMTP id 4143126000F;
	Mon, 27 Jun 2005 01:06:07 +0200 (CEST)
Received: from endor.rfc3261.net ([127.0.0.1])
	by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 21493-05-2; Mon, 27 Jun 2005 01:06:06 +0200 (CEST)
Received: from cloudcity.ohlmeier.home (e178014006.adsl.alicedsl.de
	[85.178.14.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by endor.rfc3261.net (Postfix) with ESMTP id 3A60C26000B;
	Mon, 27 Jun 2005 01:06:06 +0200 (CEST)
From: Nils Ohlmeier <lists@ohlmeier.org>
To: sip@ietf.org
Subject: Re: [Sip] Some comments on GRUUs
Date: Mon, 27 Jun 2005 01:06:03 +0200
User-Agent: KMail/1.8.1
References: <004e01c57671$10484180$6a01010a@keywest>
In-Reply-To: <004e01c57671$10484180$6a01010a@keywest>
X-Dont-Stare: at me
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200506270106.04414.lists@ohlmeier.org>
X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
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 Dale,

On Tuesday 21 June 2005 16:54, Dale Worley wrote:
> Thoughts about GRUUs.
[...] 
> * Routing problem.
>
> Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem
> that can result when a UA uses a GRUU as its target address.  In the
> worse case, shown in Figure 5 of the I-D, assume that a User Agent A
> in domain "example.com" has established a dialog with User Agent B in
> another domain.  Furthermore, domain "example.com" has a home proxy HP
> that maintains and interprets GRUUs in "example.com".  But the home
> proxy can only contact UA A via an edge proxy EP.
>
> Thus, when UA A established the dialog with UA B, the message flow
> was:
>
> 	UA B  <---  HP  <---  EP  <---  UA A
>
> Assuming that both HP and EP Record-Route themselves (EP must R-R
> itself), at UA B the full routing (route-set plus target URI) is:
>
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:GRUU-A@example.com>
>
> (The domain names "hp.example.com" and "ep.example.com" are more
> likely to be absolute IP addresses, but writing them symbolically
> makes the example easier to understand.)
>
> When UA B sends an in-dialog request to UA A, EP is unable to use the
> target URI to reach UA A and instead sends the request back to HP, the
> server for the domain "example.com".  HP resolves the GRUU to the
> contact address, and forwards the request through EP to UA A.  The
> full flow is:
>
> 	UA B  --->  HP  --->  EP
>
>                      +--------+
>
>                      v
> 	            HP  --->  EP  --->  UA A
>
> Fundamentally the problem is that the Contact header in UA A's request
> that established the dialog is being overloaded with two distinct
> purposes.  On one hand, we want it to be a globally-valid URI for
> contacting UA A, a GRUU.  On the other hand, we want it to be the
> final item in a list of addresses of waypoints for routing messages
> within the dialog.  But these two requirements are contradictory --
> because of NATing or AAA (authentication, authorization, accounting),
> there may be no URI that is both gobally routable and usable for
> direct access to the UA.
>
> There is a fairly simple solution to this:  When establishing the
> dialog, UA A needs to insert a Record-Route that provides its locally
> usable contact address, so as to mask the GRUU that is its target URI.
> Then, the full routing as seen by UA B is:
>
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr>
> 	<sip:GRUU-A@example.com>
>
> Then, when an in-dialog request from UA B reaches EP, it will have
> "Route:  <sip:ep.example.com;lr>", "Route: <sip:a.example.com;lr>",
> and a request-URI of "GRUU-A@example.com".  EP recognizes
> "ep.example.com" as one of its own addresses and deletes it.  EP then
> sends the request to the next Route address, "a.example.com", which is
> a locally usable address.
>
> In accordance with normal processing rules, UA A recognizes
> "a.example.com" as one of its addresses and removes the Route
> containing it.  It then recognizes the request-URI
> "GRUU-A@example.com" as also being one of its addresses, and processes
> the request.
>
> Clearly, this mechanism can be used simultaneously by both ends of a
> dialog.
>
> For the benefit of external diagnostic agents, it may be worth
> defining two URI-parameters, one to mark URIs that are GRUUs, and one
> to mark route-set URIs that are the locally-usable addresses.  For
> example:
>
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr;local>
> 	<sip:GRUU-A@example.com;gruu>
>
> This mechanism does have the limitation that the true target URIs for
> the dialog are no longer the stated contact URIs and cannot be changed
> during the dialog by a re-INVITE.

My concerns with such a solution are:
- how can the UA A determine its address a.example.com? Especially with NAT's 
between the UA and the proxies this a big problem again, or?
- the UA needs to implement Route processing logic, which was not necessary up 
to now.

I think it would make more sense to not solve such routing problems not in the 
implementation but by the particular installation, because they know a lot 
better which instance is able to handle what. For the given example two 
possible routing sets could look like this:

  <sip:hp.example.com;lr>
  <sip:GRUU-A@example.com>

Or

  <sip:hp.example.com;lr>
  <sip:ep.example.com;lr>
  <sip:hp.example.com;lr>
  <sip:GRUU-A@example.com>

Both are transparent for the UAs. But I admit that they will result in a new 
connection between the UA A and hp for in-dialog requests (which are send by 
UA A) which might not be desired.

In any case it seems to be a very bad idea to install any required "services" 
which need to see in-dialog requests on proxies which can not resolve the 
GRUU contact (ep in this case.) If accounting etc. is handled at hp and ep is 
not required in the Route this prevents a lot of problems.

Regards
  Nils Ohlmeier

_______________________________________________
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 Jun 27 04:17:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dmoo5-0007g9-T3; Mon, 27 Jun 2005 04:17:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmoo3-0007fs-Mn
	for sip@megatron.ietf.org; Mon, 27 Jun 2005 04:17:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22326
	for <sip@ietf.org>; Mon, 27 Jun 2005 04:17:25 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmpD8-0000cg-HG
	for sip@ietf.org; Mon, 27 Jun 2005 04:43:25 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7293FBEA; 
	Mon, 27 Jun 2005 10:17:07 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 27 Jun 2005 10:17:06 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 27 Jun 2005 10:17:06 +0200
Received: from [131.160.126.95] (rvi2-126-95.lmf.ericsson.se [131.160.126.95])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0C000261F;
	Mon, 27 Jun 2005 11:17:06 +0300 (EEST)
Message-ID: <42BFB600.3000709@ericsson.com>
Date: Mon, 27 Jun 2005 11:17:04 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rakhan@hssworld.com
References: <20050620151017.75759.qmail@web54207.mail.yahoo.com>
In-Reply-To: <20050620151017.75759.qmail@web54207.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2005 08:17:06.0475 (UTC)
	FILETIME=[9B3727B0:01C57AF0]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, rayees.khan@flextronicssoftware.com
Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02
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,

inline:

> One of the things that would improve the draft would
> be to include the message 
> format of the messages that would be exchanged in the
> call flow.

The details are given in the two documents describing the actual models. 
The framework only provides a rough description of both models.

> In section 3.1, there is a link ([10]) to
> the document that describes it all but for 3.2 I could
> not find such link.

Yes, I will add such a reference.

> What I have understood from the two section is
> o section 3.1 - after initial dialog is established by
> A with B and T, it 
>   would manage the exposure of transport address of B
> and T to both
> o section 3.2 - A establishes dialog with T, which
> acts as a B2B UA. However, 
>   it would additionally act as a MiddleBox
> Communication server (RFC 3304) 
>   and establishes dialog with B.
> 
> The alternate model could be a hybrid one. The figure
> below depicts the 
> signaling relationship between the parties. 
> 
> A establishes a signaling dialog with B, and comes to
> know about the capabilites
> of B. It realizes the need for transcoding so
> establishes dialog with T, 
> queries it for resources. If response is positive from
> T it uses REFER method 
> mechanism to inform B about signaling contacts of T. B
> initiates session with C 
> joining the dialog as described in RFC 3911. 
> 
>           +-------+
>           |       |**
>           |   T   |  **
>           |       |\   **
>           +-------+ \\   **
>             ^   *     \\   **
>             |   *       \\   **
>             |   *         SIP  **
>            SIP  *           \\   **
>             |   *             \\   **
>             |   *               \\   **
>             v   *                 \    **
>           +-------+               +-------+
>           |       |               |       |
>           |   A   | < -- SIP  --> |   B   |
>           |       |               |       |
>           +-------+               +-------+
> 
> Does it make sense?

What would be the advantages of this model?

Note that this model would require B to understand a set of extensions 
(e.g., REFER, Replaces) while the existing models work with vanilla SIP 
user agents on the side that does not invoke the transcoder.

Thanks,

Gonzalo

_______________________________________________
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 Jun 27 04:22:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmotO-00006a-NR; Mon, 27 Jun 2005 04:22:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Djfmu-0002na-5y
	for sip@megatron.ietf.org; Sat, 18 Jun 2005 12:03:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22606
	for <sip@ietf.org>; Sat, 18 Jun 2005 12:03:13 -0400 (EDT)
Received: from web54210.mail.yahoo.com ([206.190.39.252])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjgA5-0006Gp-Rf
	for sip@ietf.org; Sat, 18 Jun 2005 12:27:23 -0400
Received: (qmail 26028 invoked by uid 60001); 18 Jun 2005 16:02:57 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=gzn+a/hIvVbu2M7b/QF8oI5JDXPMen6vHY4pms5aTP1NN6bMjkDQS9w2T8dNNXw8EYPNv4xt5chqgpXw8vR6ilM2YXaXyJMKuE46RwBoVM86kQ0knhAQxUBA+dKzN4zkLdIh79vQW+y21SzkO7KbJGIbmagLDoXuSlql8Y4A7Ec=
	; 
Message-ID: <20050618160257.26020.qmail@web54210.mail.yahoo.com>
Received: from [217.45.197.113] by web54210.mail.yahoo.com via HTTP;
	Sat, 18 Jun 2005 09:02:57 PDT
Date: Sat, 18 Jun 2005 09:02:57 -0700 (PDT)
From: Rayees Khan <rakhanhss@yahoo.com>
To: gonzalo.camarillo@ericsson.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 27 Jun 2005 04:22:55 -0400
Cc: sip@ietf.org, rayees.khan@flextronicssoftware.com
Subject: [Sip] Comments draft-ietf-sipping-transc-franework-02
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rakhan@hssworld.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

Hi,

Please find below the comments for the draft mentioned
in the subject.


regards
Rayees
Flextronics Software Systems

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

1. In general we have considred two models for
transcoding service invocation based on 3PCC and
Bridging model. A hybrid of the two in case of
transcoding could be considered as an alternate model,
so that 3PCC as well as the server (T) has control
over the session. Party A would be interested in
control for the reason of initiating the session, and
T would be interested in controlling session to
effectively manage its resources
2. There is a typo in the draft in section 3.2
mentioning 'end-poing' instead of 'end-point'.




		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.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 Mon Jun 27 04:23:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmotQ-000079-Dx; Mon, 27 Jun 2005 04:23:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNv4-0004ng-G2
	for sip@megatron.ietf.org; Mon, 20 Jun 2005 11:10:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08709
	for <sip@ietf.org>; Mon, 20 Jun 2005 11:10:36 -0400 (EDT)
Received: from web54207.mail.yahoo.com ([206.190.39.249])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkOId-00048x-Ru
	for sip@ietf.org; Mon, 20 Jun 2005 11:35:10 -0400
Received: (qmail 75762 invoked by uid 60001); 20 Jun 2005 15:10:18 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=V9zz3G18eZL/UBKkRM3eISYnr7AWUQA5lBW+B56CfkjFVku5kqKn+fsS1iTAfCcXIehgZLGK3ZakodZZKStoG3Z7kzzLJ5MGeaV0kgWnp7ah/0nGd116iRoJOaSEh/oo6v8olLoHaNgL6WVPijQI3CYj28bVGLMrJ3XjTmBFTlA=
	; 
Message-ID: <20050620151017.75759.qmail@web54207.mail.yahoo.com>
Received: from [217.45.197.113] by web54207.mail.yahoo.com via HTTP;
	Mon, 20 Jun 2005 08:10:17 PDT
Date: Mon, 20 Jun 2005 08:10:17 -0700 (PDT)
From: Rayees Khan <rakhanhss@yahoo.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
In-Reply-To: <42B5BCDE.5060802@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 27 Jun 2005 04:22:55 -0400
Cc: sip@ietf.org, rayees.khan@flextronicssoftware.com
Subject: [Sip] Re: Comments draft-ietf-sipping-transc-franework-02
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rakhan@hssworld.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



Hi Gonzalo,

One of the things that would improve the draft would
be to include the message 
format of the messages that would be exchanged in the
call flow. In section 3.1, there is a link ([10]) to
the document that describes it all but for 3.2 I could
not find such link.

What I have understood from the two section is
o section 3.1 - after initial dialog is established by
A with B and T, it 
  would manage the exposure of transport address of B
and T to both
o section 3.2 - A establishes dialog with T, which
acts as a B2B UA. However, 
  it would additionally act as a MiddleBox
Communication server (RFC 3304) 
  and establishes dialog with B.

The alternate model could be a hybrid one. The figure
below depicts the 
signaling relationship between the parties. 

A establishes a signaling dialog with B, and comes to
know about the capabilites
of B. It realizes the need for transcoding so
establishes dialog with T, 
queries it for resources. If response is positive from
T it uses REFER method 
mechanism to inform B about signaling contacts of T. B
initiates session with C 
joining the dialog as described in RFC 3911. 

          +-------+
          |       |**
          |   T   |  **
          |       |\   **
          +-------+ \\   **
            ^   *     \\   **
            |   *       \\   **
            |   *         SIP  **
           SIP  *           \\   **
            |   *             \\   **
            |   *               \\   **
            v   *                 \    **
          +-------+               +-------+
          |       |               |       |
          |   A   | < -- SIP  --> |   B   |
          |       |               |       |
          +-------+               +-------+

Does it make sense?

regards
Rayees
Flextronics Software Systems


--- Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
wrote:

> Hi,
> 
> > 1. In general we have considred two models for
> > transcoding service invocation based on 3PCC and
> > Bridging model. A hybrid of the two in case of
> > transcoding could be considered as an alternate
> model,
> > so that 3PCC as well as the server (T) has control
> > over the session. Party A would be interested in
> > control for the reason of initiating the session,
> and
> > T would be interested in controlling session to
> > effectively manage its resources
> 
> Do you have a concrete proposal to realize what you
> are suggesting?
> 
> > 2. There is a typo in the draft in section 3.2
> > mentioning 'end-poing' instead of 'end-point'.
> 
> I will fix it.
> 
> Thanks for your comments,
> 
> Gonzalo
> 



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.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 Mon Jun 27 04:23:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmotR-00007a-TX; Mon, 27 Jun 2005 04:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl18w-0006II-UF
	for sip@megatron.ietf.org; Wed, 22 Jun 2005 05:03:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15421
	for <sip@ietf.org>; Wed, 22 Jun 2005 05:03:31 -0400 (EDT)
Received: from [61.16.168.135] (helo=delta.hssblr.co.in)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl1X1-0008Tz-4i
	for sip@ietf.org; Wed, 22 Jun 2005 05:28:28 -0400
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 j5M939i29601;
	Wed, 22 Jun 2005 14:33:09 +0530
To: sip@ietf.org, sip-implementors@cs.columbia.edu,
	sip-implementors-bounces@cs.columbia.edu
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OFC2A9D537.028F54B8-ON65257028.0020A769-65257028.0031B6A1@flextronicssoftware.com>
From: Aman Arora <aman.arora@flextronicssoftware.com>
Date: Wed, 22 Jun 2005 14:33:00 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 06/22/2005 02:36:27 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
X-Mailman-Approved-At: Mon, 27 Jun 2005 04:22:55 -0400
Cc: Aman Arora <aman.arora@flextronicssoftware.com>
Subject: [Sip] Query on Re-transmission of non 2xx responses in an Invite
	Transaction
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 all,

Section 17.2.1 of RFC 3261 says the following for the Invite Server
Transaction:

While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state.  For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.

      This is a change from RFC 2543, where responses were always
      retransmitted, even over reliable transports.

Additionally as per Figure 7 in the RFC, we are also supposed to
re-transmit the responses, on
receiving the re-transmitted request (as in case of the non-Invite
transaction).


                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |
            300-699 from TU |     |2xx from TU        |
            send response   |     |send response      |
                            |     +------------------>+
                            |                         |
            INVITE          V          Timer G fires  |
            send response+-----------+ send response  |
                +--------|           |--------+       |
                |        | Completed |        |       |
                +------->|           |<-------+       |
                         +-----------+                |
                            |     |                   |
                        ACK |     |                   |
                        -   |     +------------------>+
                            |        Timer H fires    |
                            V        or Transport Err.|
                         +-----------+  Inform TU     |
                         |           |                |
                         | Confirmed |                |
                         |           |                |
                         +-----------+                |
                               |                      |
                               |Timer I fires         |
                               |-                     |
                               |                      |
                               V                      |
                         +-----------+                |
                         |           |                |
                         | Terminated|<---------------+
                         |           |
                         +-----------+


My doubt is that incase the server transaction (say within a Proxy) is
anyways re-transmitting
responses locally (when timer G fires), why do we need to support
re-transmission of responses
for a re-transmitted request, as is suggested in the figure.

One possible situation where this would be required is when, the request
re-transmission timer
at the client transaction is configured to a value less than that of timer
G. But even then when
timer G would fire in the server transaction, we would anyways re-transmit
the response once again.
Thus I feel this additional functionality of re-transmitting responses for
the re-transmitted requests
is not really required.

I would appreciate any clarification on this.

regards
Aman


***********************  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 Mon Jun 27 04:23:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmotT-000084-DG; Mon, 27 Jun 2005 04:23:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlM4s-0003BZ-15
	for sip@megatron.ietf.org; Thu, 23 Jun 2005 03:24:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11495
	for <sip@ietf.org>; Thu, 23 Jun 2005 03:24:43 -0400 (EDT)
Received: from [61.16.168.135] (helo=delta.hssblr.co.in)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlMT5-00047A-4J
	for sip@ietf.org; Thu, 23 Jun 2005 03:49:51 -0400
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 j5N7O2i14069;
	Thu, 23 Jun 2005 12:54:02 +0530
In-Reply-To: <OF093400F2.776104F4-ON65257028.00559DF0-85257028.00556594@3com.com>
To: Udit_Goyal@3com.com
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OFE3F365AC.11F95A55-ON65257029.00280A33-65257029.0028A1CC@flextronicssoftware.com>
From: Aman Arora <aman.arora@flextronicssoftware.com>
Date: Thu, 23 Jun 2005 12:53:47 +0530
X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18,
	2003) at 06/23/2005 12:57:42 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
X-Mailman-Approved-At: Mon, 27 Jun 2005 04:22:55 -0400
Cc: sip@ietf.org, sip-implementors-bounces@cs.columbia.edu,
	sip-implementors@cs.columbia.edu
Subject: [Sip] Re: [Sip-implementors] Query on Re-transmission of non 2xx
 responses in	an Invite Transaction
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 Udit,

What will happen in a situation where we send out a non 2xx response to the
Invite before sending out any
provisional response?
Though 100 Trying is sent, yet in case of a cross, what is the need to
re-transmit the response for a re-transmitted
request, when anyways we are going to perform self re-transmissions? So why
does a server transaction need
to re-transmit a response on receiving a re-transmitted request in the
Confirmed State (as per figure 7 in the RFC)

My query was primarily for non 2xx (final responses) to an INVITE.

rgds
aman


                                                                           
             Udit_Goyal@3com.c                                             
             om                                                            
                                                                        To 
             06/22/2005 09:09          Aman Arora                          
             PM                        <aman.arora@flextronicssoftware.com 
                                       >                                   
                                                                        cc 
                                       sip@ietf.org,                       
                                       sip-implementors@cs.columbia.edu,   
                                       sip-implementors-bounces@cs.columbi 
                                       a.edu                               
                                                                   Subject 
                                       Re: [Sip-implementors] Query on     
                                       Re-transmission of non 2xx          
                                       responses in  an Invite Transaction 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Aman,

For INVITE transaction, retransmission of requests will only occur when
client had not received the provisional responses.
In this case, server needs to send the responses for each retransmitted
request since client transaction is still inCalling state.

In case, when provisional response had been received, no retransmission of
request occur, and server transaction needs to retransmit final responses
till it get an ACK. Timer G basically taking care of the retransmission of
the final responses till ACK is received.

Hope it clarifies your doubt.

Regards,
Udit

                                                                           
 Aman Arora                                                                
 <aman.arora@flextronicssoft                                               
 ware.com>                                                                 
 Sent by:                                                               To 
 sip-implementors-bounces@cs            sip@ietf.org,                      
 .columbia.edu                          sip-implementors@cs.columbia.edu,  
                                        sip-implementors-bounces@cs.columb 
                                        ia.edu                             
 06/22/2005 05:03 AM                                                    cc 
                                                                           
                                                                   Subject 
                                        [Sip-implementors] Query on        
                                        Re-transmission of non 2xx         
                                        responses in        an Invite      
                                        Transaction                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           









Hi all,

Section 17.2.1 of RFC 3261 says the following for the Invite Server
Transaction:

While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state.  For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.

This is a change from RFC 2543, where responses were always
retransmitted, even over reliable transports.

Additionally as per Figure 7 in the RFC, we are also supposed to
re-transmit the responses, on
receiving the re-transmitted request (as in case of the non-Invite
transaction).


|INVITE
|pass INV to TU
INVITE             V send 100 if TU won't in 200ms
send response+-----------+
+--------|           |--------+101-199 from TU
|        | Proceeding|        |send response
+------->|           |<-------+
|           |          Transport Err.
|           |          Inform TU
|           |--------------->+
+-----------+                |
300-699 from TU |     |2xx from TU        |
send response   |     |send response      |
|     +------------------>+
|                         |
INVITE          V          Timer G fires  |
send response+-----------+ send response  |
+--------|           |--------+       |
|        | Completed |        |       |
+------->|           |<-------+       |
+-----------+                |
|     |                   |
ACK |     |                   |
-   |     +------------------>+
|        Timer H fires    |
V        or Transport Err.|
+-----------+  Inform TU     |
|           |                |
| Confirmed |                |
|           |                |
+-----------+                |
|                      |
|Timer I fires         |
|-                     |
|                      |
V                      |
+-----------+                |
|           |                |
| Terminated|<---------------+
|           |
+-----------+


My doubt is that incase the server transaction (say within a Proxy) is
anyways re-transmitting
responses locally (when timer G fires), why do we need to support
re-transmission of responses
for a re-transmitted request, as is suggested in the figure.

One possible situation where this would be required is when, the request
re-transmission timer
at the client transaction is configured to a value less than that of timer
G. But even then when
timer G would fire in the server transaction, we would anyways re-transmit
the response once again.
Thus I feel this additional functionality of re-transmitting responses for
the re-transmitted requests
is not really required.

I would appreciate any clarification on this.

regards
Aman


***********************  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-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


***********************  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 Mon Jun 27 17:40:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn1LC-0003dt-Uk; Mon, 27 Jun 2005 17:40:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn1LA-0003di-20
	for sip@megatron.ietf.org; Mon, 27 Jun 2005 17:40:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23862
	for <sip@ietf.org>; Mon, 27 Jun 2005 17:40:15 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn1kC-0006Qq-VB
	for sip@ietf.org; Mon, 27 Jun 2005 18:06:22 -0400
Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5RLhZx1018089
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 27 Jun 2005 16:43:39 -0500
In-Reply-To: <200506261631.j5QGVqLE004366@rautu.tutpro.com>
References: <200506261631.j5QGVqLE004366@rautu.tutpro.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ca0fb637c128bc18a709591eebee3f38@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] comment on draft-ietf-sip-sctp-06.txt
Date: Mon, 27 Jun 2005 16:40:09 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Jon Peterson <jon.peterson@neustar.biz>
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 Jun 26, 2005, at 11:31 AM, Juha Heinanen wrote:

> draft-ietf-sip-sctp-06.txt has a note:
>
> Note that the value "tls", defined by RFC 3261, is intended for TLS 
> over
> TCP.
>
> on the other hand 26.2.2 of rfc3261 has a note:
>
> The use of transport=tls has consequently been deprecated, partly
> because it was specific to a single hop of the request.
>
> so if a transport parameter indicating tls over tcp has been 
> deprecated,
> why do we now need a transport parameter indicating tls over sctp?  
> what
> makes sctp in this regards special as compared to tcp?

I wish I knew.

I'd like to ask Jon Peterson to comment, as I think he contributed that 
line of deprecation to 3261. Then again, it was debated during a 
conference call at 3:00 AM as I was attending a 3GPP meeting in Sophia 
Antipolis, so I might remember wrong.

But in any case, it's a good question.

--
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 Wed Jun 29 05:32:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnYvU-0003QE-Oj; Wed, 29 Jun 2005 05:32:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnYvT-0003Q9-45
	for sip@megatron.ietf.org; Wed, 29 Jun 2005 05:32:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26845
	for <sip@ietf.org>; Wed, 29 Jun 2005 05:32:07 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnZKp-0007j8-R6
	for sip@ietf.org; Wed, 29 Jun 2005 05:58:32 -0400
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
	(PMDF V6.0-24 #40642) id <0IIU00G01AA2PZ@siemenscomms.co.uk> for
	sip@ietf.org; Wed, 29 Jun 2005 10:28:16 +0100 (BST)
Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0IIU00D4P9RPO8@siemenscomms.co.uk>; Wed,
	29 Jun 2005 10:16:38 +0100 (BST)
Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service
	(5.5.2657.72)	id <N56WP1JN>; Wed, 29 Jun 2005 10:18:55 +0100
Content-return: allowed
Date: Wed, 29 Jun 2005 10:18:52 +0100
From: "Elwell, John" <john.elwell@siemens.com>
To: jmpolk@cisco.com, br@brianrosen.net
Message-id: <50B1CBA96870A34799A506B2313F266705C2E290@ntht201e.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.7 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: sip@ietf.org
Subject: [Sip] Comment on draft-ietf-sip-location-conveyance-00
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="===============1778067899=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1778067899==
Content-return: allowed
Content-type: multipart/alternative;
	boundary="Boundary_(ID_lA8ubusy7/XDx3EH9vpjbA)"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_lA8ubusy7/XDx3EH9vpjbA)
Content-type: text/plain
Content-Transfer-Encoding: 7BIT

James, Brian,

In section 9 (special provisions for emergency calls) it states:

"In the case where the Proxy knows the location of the UAC and does not
detect the UAC's location information message body in the message (or
determines the LO is bad), the Proxy generates a new 4XX (Retry Location
Body) error message that includes a location information message body for
that UAC to include in the subsequent message.  The user agent MUST include
this message body in the subsequent emergency message."

This places a new requirement on the UAC, which will not be met by UACs that
are not compliant to this document. It seems emergency calls from such UACs
will fail.

Regards,

John


--Boundary_(ID_lA8ubusy7/XDx3EH9vpjbA)
Content-type: text/html
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>Comment on draft-ietf-sip-location-conveyance-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">James, Brian,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">In section 9 (special provisions for emergency calls) it states:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&quot;</FONT><FONT SIZE=2 FACE="Arial">In the case where the Proxy knows the location of the UAC and does not detect the UAC's location information message body in the message (or determines the LO is bad), the Proxy generates a new 4XX (Retry Location Body) error message that includes a location information message body for that UAC to include in the subsequent message.&nbsp; The user agent MUST include this message body in the subsequent emergency message.&quot;</FONT></P>

<P><FONT SIZE=2 FACE="Arial">This places a new requirement on the UAC, which will not be met by UACs that are not compliant to this document. It seems emergency calls from such UACs will fail.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Regards,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">John</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_lA8ubusy7/XDx3EH9vpjbA)--


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




From sip-bounces@ietf.org Thu Jun 30 09:45:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnzMD-0008Hh-2d; Thu, 30 Jun 2005 09:45:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzMA-0008HZ-Ru
	for sip@megatron.ietf.org; Thu, 30 Jun 2005 09:45:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12017
	for <sip@ietf.org>; Thu, 30 Jun 2005 09:45:29 -0400 (EDT)
Received: from sonussf1.sonusnet.com ([208.45.178.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnzlv-0002JQ-8O
	for sip@ietf.org; Thu, 30 Jun 2005 10:12:08 -0400
Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com
	[10.128.32.96])
	by sonussf1.sonusnet.com (8.13.1/8.13.1) with ESMTP id j5UDjE39026703
	for <sip@ietf.org>; Thu, 30 Jun 2005 09:45:14 -0400
Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by
	sonusmail02.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Thu, 30 Jun 2005 09:45:13 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 30 Jun 2005 19:15:08 +0530
Message-ID: <70798CF421F00F4DA018059E5B7EEB8C0359DA@sonusinmail01.sonusnet.com>
Thread-Topic: Why Require: sec-agree
Thread-Index: AcV9ee3J2M2YNvtDTU2DiM6lqyyPBw==
From: "Nayak, Subhash" <sunayak@sonusnet.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 30 Jun 2005 13:45:13.0781 (UTC)
	FILETIME=[F100E650:01C57D79]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Subject: [Sip] Why Require: sec-agree
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="===============1997335701=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1997335701==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57D79.EDEFE78F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57D79.EDEFE78F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

      RFC 3329 (Security Agreement Mechanism for SIP) specifies=20

that a client should insert both a Require and a Proxy-Require=20

header with value "sec-agree" (See Sec 2.3.1 Client Initiated=20

mechanism). Subsequently, after successful processing, the proxy=20

removes this token from *both* the headers.=20

My question is, why does the client need to add a=20

"Require: sec-agree" when only the proxy is required to support=20

this feature in this scenario ? As I understand it, it would have=20

sufficed to only insert a "Proxy-Require: sec-agree" header...

=20

Thanks in advance

Subhash Nayak

Sonus Networks, Inc.

=20


------_=_NextPart_001_01C57D79.EDEFE78F
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=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)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:HE_TERMINAL;
	panose-1:2 11 6 9 2 2 2 2 2 4;}
 /* 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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:HE_TERMINAL;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RFC 3329 =
(Security
Agreement Mechanism for SIP) specifies <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>that a client should insert both a Require and =
a
Proxy-Require <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>header with value &#8220;sec-agree&#8221; (See =
Sec 2.3.1
Client Initiated <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>mechanism). Subsequently, after successful =
processing,
the proxy <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>removes this token from *<b><span =
style=3D'font-weight:
bold'>both</span></b>* the headers. <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:.5in'><font size=3D2 =
face=3D"HE_TERMINAL"><span
style=3D'font-size:10.0pt;font-family:HE_TERMINAL'>My question is, why =
does the client
need to add a <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>&#8220;Require: sec-agree&#8221; when only the =
proxy
is required to support <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>this feature in this scenario ? As I understand =
it, it
would have <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>sufficed to only insert a &#8220;Proxy-Require:
sec-agree&#8221; header...<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>Thanks in advance<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>Subhash Nayak<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'>Sonus Networks, =
Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"HE_TERMINAL"><span =
style=3D'font-size:10.0pt;
font-family:HE_TERMINAL'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C57D79.EDEFE78F--


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




From sip-bounces@ietf.org Thu Jun 30 17:03:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do6Bs-0006YI-F4; Thu, 30 Jun 2005 17:03:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Do6Bq-0006WA-Em
	for sip@megatron.ietf.org; Thu, 30 Jun 2005 17:03:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23496
	for <sip@ietf.org>; Thu, 30 Jun 2005 17:03:16 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.207])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6bf-0003qC-5h
	for sip@ietf.org; Thu, 30 Jun 2005 17:30:00 -0400
Received: by wproxy.gmail.com with SMTP id 36so81240wri
	for <sip@ietf.org>; Thu, 30 Jun 2005 14:03:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=TQAxmcMM6MZVB9wLvXawrYieY8HGcayLS1ud5miuBY8TLPSfaaWC0n3JUYjB4+ilodOg1GAVGMjBLzNthQIfMlRD0LOnOEiVObwFANPMd29mCT5YErtN6WrPOXC5ZwFAzMi/W7x3zVXImV3anM5PiYo3scx2cN53wePKtprwuUc=
Received: by 10.54.59.9 with SMTP id h9mr168541wra;
	Thu, 30 Jun 2005 14:03:05 -0700 (PDT)
Received: by 10.54.17.77 with HTTP; Thu, 30 Jun 2005 14:03:05 -0700 (PDT)
Message-ID: <a9994e94050630140336158cbe@mail.gmail.com>
Date: Thu, 30 Jun 2005 17:03:05 -0400
From: Arjun Roychowdhury <arjunrc@gmail.com>
To: "Nayak, Subhash" <sunayak@sonusnet.com>
Subject: Re: [Sip] Why Require: sec-agree
In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C0359DA@sonusinmail01.sonusnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <70798CF421F00F4DA018059E5B7EEB8C0359DA@sonusinmail01.sonusnet.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Arjun Roychowdhury <arjunrc@gmail.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 reason for this is that, realistically speaking, there is no
possible way for a UA to guess if the node in the next-hop is really a
proxy or a UA. In addition to that, a general Require would work if
you assume that the first message going out is an OPTIONS to its
next-node. It is also possible for the UAC to just start with an
INVITE directly, in which case, the proxy, seeing an INVITE request
not destined for itself will pass it along without complying to the
sec-agree requirements.

Therefore, it was suggested that a UA inserts *both* require and
proxy-require. The downside, however, is that now the next-hop  would
need to strip both headers before sending it out. Its the lesser of
two evils, I guess.

regds
arjun




On 6/30/05, Nayak, Subhash <sunayak@sonusnet.com> wrote:
>=20
>=20
> Hi,
>=20
>       RFC 3329 (Security Agreement Mechanism for SIP) specifies=20
>=20
> that a client should insert both a Require and a Proxy-Require=20
>=20
> header with value "sec-agree" (See Sec 2.3.1 Client Initiated=20
>=20
> mechanism). Subsequently, after successful processing, the proxy=20
>=20
> removes this token from *both* the headers.=20
>=20
> My question is, why does the client need to add a=20
>=20
> "Require: sec-agree" when only the proxy is required to support=20
>=20
> this feature in this scenario ? As I understand it, it would have=20
>=20
> sufficed to only insert a "Proxy-Require: sec-agree" header...
>=20
> =20
>=20
> Thanks in advance
>=20
> Subhash Nayak
>=20
> Sonus Networks, Inc.
>=20
> =20
> _______________________________________________
> Sip mailing list=20
> 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
Arjun Roychowdhury

_______________________________________________
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