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 ; 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 ; Wed, 1 Jun 2005 10:44:51 +0200 Message-Id: <200506010844.j518ipVd023574@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ------=_NextPart_000_0041_01C56696.FB3C5590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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<= /span>

 

------=_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 ; 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 ; 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 ; 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: Thread-Topic: draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Thread-Index: AcVmqB6ZrIlDK1ycSKu2WiNdLoIYzA== From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: "Wijnen, Bert \(Bert\)" , 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 List-Unsubscribe: , List-Post: List-Help: List-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
 
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 'in the = doctors=20 room':
 
A few = issues were=20 found related to the definition of the SipMethodIdentifier TC and its=20 usage:
 
1.=20  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 "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 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.
2. = Another MIB=20 Doctor asked '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 necessary at = this=20 stage, as nothing is broken, but as I would suggest that you provide a = rationale=20 for this design choice.
3. The = TC misses a=20 DISPLAY-HINT (probably "d"), which results into a smilint warning
 
Some = more editorial=20 things.
 
4. = Since the=20 document was published the Intellectual Property boilerplates were = updated. See=20 http://www.ietf.org/= ietf/1id-guidelines.txt for=20 the latest version
5. It = is recommended=20 that the module name of the SIP-TC module be changed to=20 SIP-TC-MIB
6.=20 typo - DESCRIPTION clause of=20 SipStatusCodeNotifTable - "seperate"
7. typo -=20 DESCRIPTION clause of SipMethodIdentifier -=20 "extention"
8. typo - DESCRIPTION clause of sipServiceNotifEnable -=20 "approriate"
9.=20 type - DESCRIPTION clause of sipServiceWarmStart -=20 "adminstrative"
10.=20 There are 129 instances of too long lines in this documents. Please run = idnits=20 for the full list http://ietf.l= evkowetz.com/tools/idnits/idnits.pyht
11.=20 Warnings of weird spacing in lines
tmp/draft-ietf-sip-mib-09.txt(4495): Line has = weird=20 spacing: '...CodeIns  =20 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=20 weird spacing: '...odTable  in th...'
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.
 
Regards,
 
Dan
 

 ------_=_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 ; 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" To: , 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 List-Unsubscribe: , List-Post: List-Help: List-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 List-Unsubscribe: , List-Post: List-Help: List-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 > 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 In a me= ssage dated 5/29/2005 6:05:15 PM Eastern Daylight Time, jmpolk@cisco.com wri= tes:


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

Mike Pierce
 --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 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn 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 List-Unsubscribe: , List-Post: List-Help: List-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 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" To: "Janet P Gunn" , "Henning Schulzrinne" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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 Subject: Re: [Sip] Update to draft-ietf-sip-resource-priority section 4.2 References: In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Thu, 2 Jun 2005 12:56:20 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47EF51BBF@npd-mail.hclt-ntl.co.in> From: "Puneet Kalia - NPD, Chennai" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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

Hi ,

 

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

 

What does SIP standard says about generating = CDR?

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

 

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

 

Thanks

Puneet Kalia

 

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-- --===============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 ; 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 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" 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 List-Unsubscribe: , List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 5/29/2005 6:17:03 PM Eastern Daylight Time, jmpolk@cisco.com wri= tes:


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


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

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.

(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.)

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

the following syntax shall be used:

         Reason: preemption ;cause= =3D1 ;text=3D"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=20= RFC 3326. While it implied that the text part is always used, the formal def= inition 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 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.
Mike Pierce

 --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" Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Ev... In-Reply-To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 List-Unsubscribe: , List-Post: List-Help: List-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 >> 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 ; 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" To: "Dale Worley" , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org "Dale Worley" 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 ; 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 ; Mon, 6 Jun 2005 16:11:18 +0200 Message-Id: <200506061411.j56EBI5O029248@smtp1.clb.oleane.net> From: "Chantal Ladouce" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 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

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

The dead line for turning in abstracts is June = 30.

 

 

------=_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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 5/29/2005 5:39:51 PM Eastern Daylight Time, hgs@cs.columbia.edu=20= 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=20=
> MAY attempt a subsequent request with the same or different resource > value." This is contrary to the policies for using priority values and=20=
> 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=20=
> upon receipt of a 417. Of course, a human user may choose to do whateve= r
> they are authorized to do when trying a new call, but no device can be=20=
> 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 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:

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

Should be changed to:

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

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

Mike Pierce
 --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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 6/2/2005 6:10:09 PM Eastern Daylight Time, jmpolk@cisco.com writ= es:


Because SIP and Q.850 have clea= rly 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 <= BR> 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 <= BR> 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=20=
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.

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 notif= ying the user of something they shouldn't know in our domain. The "Generic P= reemption" was added to deal with this.

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.

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.

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.


Mike Pierce
 --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: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" 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 "; 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 List-Unsubscribe: , List-Post: List-Help: List-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: References: 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 Subject: Re: [Sip] Comments on Resource Priority -08 (417) Date: Mon, 6 Jun 2005 11:10:51 -0400 To: "David R. Oran" 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 List-Unsubscribe: , List-Post: List-Help: List-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" To: , 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: 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 List-Unsubscribe: , List-Post: List-Help: List-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" To: "'Dale Worley'" , , 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 List-Unsubscribe: , List-Post: List-Help: List-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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 5/29/2005 6:08:13 PM Eastern Daylight Time, hgs@cs.columbia.edu=20= writes:


I'm happy to use SHOULD NOT, bu= t 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=20= same complexity of defining how unknown priority values are handled.

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

Mike Pierce
 --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" 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 "; 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 List-Unsubscribe: , List-Post: List-Help: List-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: References: 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 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 List-Unsubscribe: , List-Post: List-Help: List-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" , , From: "James M. Polk" Subject: RE: [Sip] Comments on Resource Priority -08 (417) In-Reply-To: <009601c56ab2$a2b597e0$6a01010a@keywest> References: 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 List-Unsubscribe: , List-Post: List-Help: List-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" 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 List-Unsubscribe: , List-Post: List-Help: List-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 List-Unsubscribe: , List-Post: List-Help: List-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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 6/6/2005 6:07:42 PM Eastern Daylight Time, dean.willis@softarmor= .com writes:


If we're talking about an autom= ated 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 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).

Mike Pierce
 --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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 6/6/2005 11:02:18 AM Eastern Daylight Time, oran@cisco.com write= s:


> Should be changed to:
>
>    Upon receiving a 417 (Unknown Resource-Priority) resp= onse, the UAC
>    MAY display to the user a list of the authorized reso= urce values 
> returned in the 'Accept-Resource-Priority'
>    header field. The user may then attempt a subsequent=20= 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 =20=
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. 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.
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.

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.columb= ia.edu writes:


In general, my philosophy is th= at 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  <= BR> futile to try to have the protocol spec mandate human intervention. I =20=
understand the need to preserve a place for humans in the world, but  <= BR> protocol specs are probably the wrong place to prevent human-to-robot =20=
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-- --===============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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 In a me= ssage dated 6/6/2005 3:51:56 PM Eastern Daylight Time, oran@cisco.com writes= :


It doesn't say that, I don't th= ink. 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  <= BR> used for all sorts of IANA registrations by non-IETF groups. There's  <= BR> 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-regi= stered list
      associated with a particular namespace,

Mike Pierce --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 ; 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 ; 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 ; 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?= 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Thu, 9 Jun 2005 11:19:19 -0400 (EDT) From: "Dale Worley" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" To: "Dale Worley" , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ----- Original Message -----=20 From: "Dale Worley" To: 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: References: 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 ; Fri, 10 Jun 2005 11:14:19 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2655.55) id ; Fri, 10 Jun 2005 11:16:01 +0200 Message-ID: From: Horvath Ernst To: "'Peterson, Jon'" , "'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'" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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?= 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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 , Cullen Jennings , Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 To: Dean Willis , "sip@ietf.org" Message-ID: 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 , Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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" 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 ; 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: Thread-Topic: [Sip] Comment on refer-with-norefersub-01 Thread-Index: AcVt6fhvLXOsLmvRT9qI+rRxH4DUnQAB3swg From: "Orit Levin" To: "Cullen Jennings" , "Dean Willis" , 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 , Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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" 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 ; 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 To: Orit Levin , Dean Willis , "sip@ietf.org" Message-ID: In-Reply-To: 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 , Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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" 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" 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 ; 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 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 Subject: Re: [Sip] Comment on refer-with-norefersub-01 References: In-Reply-To: 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" , Alan Johnston , Orit Levin , Tom Hiller , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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" 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" 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 ; 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: References: 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 Subject: Re: [Sip] Comment on refer-with-norefersub-01 Date: Sun, 12 Jun 2005 15:01:45 -0500 To: "Orit Levin" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Alan Johnston , Cullen Jennings , sip@ietf.org, Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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: Date: Mon, 13 Jun 2005 15:59:04 +0530 From: ayan 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 ; Mon, 13 Jun 2005 06:15:03 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Jun 2005 16:39:50 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F303961B91@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: ayan , 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 Subject: RE: [Sip] querry about 481 To: Chadha Retesh-A19894 , ayan , 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 List-Unsubscribe: , List-Post: List-Help: List-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 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
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-- --===============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 To: IETF-Announce Message-Id: Date: Mon, 13 Jun 2005 15:30:43 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor 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 List-Unsubscribe: , List-Post: List-Help: List-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 ' as a Proposed Standard - 'Problems identified associated with the Session Initiation Protocol's non-INVITE Transaction ' 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 ; 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 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 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 , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 /* 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! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 ; 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" To: "Jonathan Rosenberg" , "Manish Joshi" 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 , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 /* 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 > = 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 ; 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 ; 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 ; 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 ; 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 ; 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" To: "Frank Derks" , 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 ; 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" To: "Frank Derks" , 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 ; 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" To: "Frank Derks" 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 ; 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 ; Tue, 14 Jun 2005 13:07:12 -0400 (EDT) From: "Dale Worley" To: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" 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 Message-ID: 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 ; 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 ; 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 ; 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 ; 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 ; 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" To: "Frank Derks" 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 ; 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" 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 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 ; 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" To: "Frank Derks" 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 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 ; 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 ; Wed, 15 Jun 2005 15:10:18 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2904D5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Frank Derks'" 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 List-Unsubscribe: , List-Post: List-Help: List-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 > > 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 > > 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 > > 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)" 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: From: Frank Derks 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 List-Unsubscribe: , List-Post: List-Help: List-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 > > 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 > > 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 > > 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 ; 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 ; Wed, 15 Jun 2005 10:38:52 -0400 (EDT) From: "Dale Worley" To: 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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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" To: "'Drage, Keith (Keith)'" , "'Frank Derks'" 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 List-Unsubscribe: , List-Post: List-Help: List-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 > > 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 > > 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 > > 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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 2005-06-16 12:09 AM To DarshanBildikar 70559 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 ; 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 ; 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 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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: 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 List-Unsubscribe: , List-Post: List-Help: List-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

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-- --===============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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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: From: Rajeev Seth 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 List-Unsubscribe: , List-Post: List-Help: List-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"
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_=-- --===============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 ; 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 ; 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 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Tue, 21 Jun 2005 10:28:34 -0400 Message-ID: From: Hume Vance 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Tue, 21 Jun 2005 15:52:36 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290517@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Hume Vance'" , 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Tue, 21 Jun 2005 10:55:10 -0400 (EDT) From: "Dale Worley" To: "Sip (E-mail)" 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 List-Unsubscribe: , List-Post: List-Help: List-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: (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: Then, when an in-dialog request from UA B reaches EP, it will have "Route: ", "Route: ", 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: 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:". A simplified example of such a registration and its response is: REGISTER sip:example.com SIP/2.0 From: Callee ;tag=a73kszlfl To: Callee Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 CSeq: 1 REGISTER Supported: gruu Contact: ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" SIP/2.0 200 OK From: Callee ;tag=a73kszlfl To: Callee ;tag=b88sn Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 CSeq: 1 REGISTER Contact: ;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 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Contact: ;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 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: gruu Contact: ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Contact: ;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 ;tag=2493k59kd From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;gruu="sip:hha9s8d=-999a@biloxi.com" ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" ;expires=3600 Contact: ;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.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Contact: ;gruu="sip:hha9s8d=-999a@example.com" ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" ;expires=3600 Contact: ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Contact: ;+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 ; 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" To: sip@ietf.org Message-ID: 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" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Tue, 21 Jun 2005 19:50:18 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290520@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Marco P. Rodrigues'" , 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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)" 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'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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: References: 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 Subject: Re: [Sip] Media Statistics in SIP 200 OK/BYE Message Date: Tue, 21 Jun 2005 20:02:53 -0500 To: "Marco P. Rodrigues" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 ; Wed, 22 Jun 2005 10:08:31 +0800 (CST) Received: by pekw096e.cn001.siemens.net with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Jun 2005 10:13:38 +0800 Message-ID: <54CD3165FCE49A44A9A6F2179B3C36C3065610A3@pekw092a> From: "Sun Xian Peng, SLC COM CD/MN R&D SE (BJ)" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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)" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 ; 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: Thread-Topic: [Sip] Media Statistics in SIP 200 OK/BYE Message Thread-Index: AcV2iq+gEp2y9V5+R+SHdyEGBBKn1AAczYLw From: "Romascanu, Dan \(Dan\)" To: "Marco P. Rodrigues" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: "Siddiqui, Anwar A \(Anwar\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 ; 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: Thread-Topic: Nit in draft-ietf-sip-mib-09.txt Thread-Index: AcV3Eu1Stai9nP7kRQaIH54uaH7yag== From: "Romascanu, Dan \(Dan\)" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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
Editorial nit in=20 draft-ietf-sip-mib-09.txt: in the DESCRIPTION clause of sipContactURI:
 
'This = object=20 contains either a SIP URI where the user can be = contacted.'
 
I = believe that we=20 can get rid of 'either'.
 
Regards,
 
Dan
 
 
 
 
------_=_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 ; 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 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 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\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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: > > > > > > (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: > > > > > > > Then, when an in-dialog request from UA B reaches EP, it will have > "Route: ", "Route: ", > 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: > > > > > > > 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:". > > A simplified example of such a registration and its response is: > > REGISTER sip:example.com SIP/2.0 > From: Callee ;tag=a73kszlfl > To: Callee > Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 > CSeq: 1 REGISTER > Supported: gruu > Contact: > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > > SIP/2.0 200 OK > From: Callee ;tag=a73kszlfl > To: Callee ;tag=b88sn > Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 > CSeq: 1 REGISTER > Contact: > ;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 > From: Bob ;tag=456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: > Contact: ;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 > From: Bob ;tag=456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Supported: gruu > Contact: > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > Contact: ;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 ;tag=2493k59kd > From: Bob ;tag=456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: > ;gruu="sip:hha9s8d=-999a@biloxi.com" > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > ;expires=3600 > Contact: ;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.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > Contact: > ;gruu="sip:hha9s8d=-999a@example.com" > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > ;expires=3600 > > Contact: > ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > Contact: > ;+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 ; 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\)" To: "Romascanu, Dan \(Dan\)" , 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 List-Unsubscribe: , List-Post: List-Help: List-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
agreed, dan.
 
btw, i have your previous email with review comment on my todo = list=20 ;) 
will try to get to it soon.
 
thanks,
kevin

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Romascanu, Dan=20 (Dan)
Sent: Wednesday, June 22, 2005 6:13 AM
To:=20 sip@ietf.org
Subject: [Sip] Nit in=20 draft-ietf-sip-mib-09.txt

Editorial nit in=20 draft-ietf-sip-mib-09.txt: in the DESCRIPTION clause of sipContactURI:
 
'This object=20 contains either a SIP URI where the user can be=20 contacted.'
 
I = believe that we=20 can get rid of 'either'.
 
Regards,
 
Dan
 
 
 
 
------_=_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 ; 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 ; Wed, 22 Jun 2005 11:03:26 -0400 (EDT) From: "Dale Worley" To: "'Sip (E-mail)'" 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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: To: Aman Arora MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: 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 List-Unsubscribe: , List-Post: List-Help: List-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 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"
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_=-- --===============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 ; 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: To: Aman Arora MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rajeev Seth 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 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"
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_=-- --===============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 ; 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 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 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\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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'" From: "Joel M. Halpern" In-Reply-To: References: 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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" References: <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' 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 From: "Joel M. Halpern" In-Reply-To: <42BDFE57.2010109@cs.columbia.edu> References: <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' 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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: 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 List-Unsubscribe: , List-Post: List-Help: List-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

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-- --===============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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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: > > > > > > (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: > > > > > > > Then, when an in-dialog request from UA B reaches EP, it will have > "Route: ", "Route: ", > 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: > > > > > > > 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: Or 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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 To: Gonzalo Camarillo 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 ; 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: From: Aman Arora 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 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 List-Unsubscribe: , List-Post: List-Help: List-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 ; 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: To: Udit_Goyal@3com.com X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Aman Arora 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 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 ; 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: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] comment on draft-ietf-sip-sctp-06.txt Date: Mon, 27 Jun 2005 16:40:09 -0500 To: Juha Heinanen 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 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 ; 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 ; Wed, 29 Jun 2005 10:18:55 +0100 Content-return: allowed Date: Wed, 29 Jun 2005 10:18:52 +0100 From: "Elwell, John" 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 List-Unsubscribe: , List-Post: List-Help: List-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 Comment on draft-ietf-sip-location-conveyance-00

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)-- --===============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 ; 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 ; 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" To: 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 List-Unsubscribe: , List-Post: List-Help: List-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

Hi,

      RFC 3329 = (Security Agreement Mechanism for SIP) specifies

that a client should insert both a Require and = a Proxy-Require

header with value “sec-agree” (See = Sec 2.3.1 Client Initiated

mechanism). Subsequently, after successful = processing, the proxy

removes this token from *both* the headers.

My question is, why = does the client need to add a

“Require: sec-agree” when only the = proxy is required to support

this feature in this scenario ? As I understand = it, it would have

sufficed to only insert a “Proxy-Require: sec-agree” header...

 

Thanks in advance

Subhash Nayak

Sonus Networks, = Inc.

 

------_=_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 ; 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 ; 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: Date: Thu, 30 Jun 2005 17:03:05 -0400 From: Arjun Roychowdhury To: "Nayak, Subhash" 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-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 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