From sipping-bounces@ietf.org Wed Nov 01 03:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfBbV-0003nI-U0; Wed, 01 Nov 2006 03:37:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfBbP-0003mA-6w for sipping@ietf.org; Wed, 01 Nov 2006 03:37:40 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfBbM-0001DV-Pt for sipping@ietf.org; Wed, 01 Nov 2006 03:37:39 -0500 Received: (qmail 19264 invoked by uid 0); 1 Nov 2006 08:38:43 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Nov 2006 08:38:43 -0000 Message-ID: <003c01c6fd90$fa460a90$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "sipping" Date: Wed, 1 Nov 2006 09:37:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: kevin.summers@sonusnet.com, Robert Sparks , Gonzalo Camarillo , Mary Barnes Subject: [Sipping] Review comments review of sipping-service-examples-11 section 2.13 (Find me) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746097959==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0746097959== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C6FD99.5BBE2750" This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C6FD99.5BBE2750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit With respect to my review comments on the -10 version: http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-service-examples-10-bemmel.txt All have been resolved, except that the added Via header in F14 (point 1) is now missing a 'received' parameter Regards, Jeroen ------=_NextPart_000_0038_01C6FD99.5BBE2750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
With respect to my review comments on = the -10=20 version:
http://www.softarmor.com/sip= ping/process/wg-review/reviews/draft-ietf-sipping-service-examples-10-bem= mel.txt
 
All have been resolved, except that the = added Via=20 header in F14 (point 1) is now missing a 'received' = parameter
 
Regards,
Jeroen
------=_NextPart_000_0038_01C6FD99.5BBE2750-- --===============0746097959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0746097959==-- From sipping-bounces@ietf.org Wed Nov 01 04:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfClX-0004XS-7d; Wed, 01 Nov 2006 04:52:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfClS-0004XL-Gk for sipping@ietf.org; Wed, 01 Nov 2006 04:52:06 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfClQ-0001qD-SZ for sipping@ietf.org; Wed, 01 Nov 2006 04:52:06 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA19q0Lf019863; Wed, 1 Nov 2006 18:52:00 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B8C2C20AE2C; Wed, 1 Nov 2006 18:52:00 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7716A20AE29; Wed, 1 Nov 2006 18:52:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA19q0cH021847; Wed, 1 Nov 2006 18:52:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA19pxNG028567; Wed, 1 Nov 2006 18:51:59 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA19pxoM028562; Wed, 1 Nov 2006 18:51:59 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id kA19pxSh002520; Wed, 1 Nov 2006 18:51:59 +0900 (JST) Message-Id: <200611010951.kA19pxSh002520@imf.m.ecl.ntt.co.jp> To: sipping@ietf.org From: Mayumi Munakata Date: Wed, 01 Nov 2006 18:51:59 +0900 X-Mailer: WebMail V3.5.0 PL4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi all, Thank you for everybody's comments for draft-munakata-sipping-privacy-clarified-00. In order to put together the discussions so far, I try rewriting the latter half of the Table 1 as follows. ----------------------------------------------------------------------- Target headers user header session id history Warning modify Record-Route strip(*1) P-Asserted-Identity delete? delete? delete History-Info not add not add delete Path strip(*1) Referred-By modify(*2) Replaces Service-Route strip(*1) Target-Dialog modify? Identity-Info modify? *1: "strip" means that privacy services operating on requests should remove all Via/Record-Route/Path/Service-Route headers that have been added to the request prior to its arrival at the privacy service and then should add a single Via/Record-Route/Path/ Service-Route header representing themselves. The server doing the stripping must restore the stripped value in the responses. *2: Referred-By header will be modified when it appears in REFER request with Privacy:user that means the referrer's privacy is required. It should not be modified when it appears in INVITE request. ----------------------------------------------------------------------- It seems that Warning, Path, Referred-By, Replaces, and Service-Route headers' manipulations were agreed, so I deleted the question marks. (Empty column of Replaces header means that the header is not a target for any priv-values.) On the other hand, Target-Dialog header likely needs more discussion. I personally agree Paul's opinion that Target-Dialog should not be modified considering the meaning of the header. > - Replaces: this references specific state held by the target of the > request. It is obviously already known to the target, and the > request can't function without it. I don't see what can/should be > modified. > > - Target-Dialog: same as Replaces. A question about P-Asserted-Identity header is asked by Roland. > My interpretation is that the P-Asserted-Identity is also a header > 'which cannot be completely expunged of identifying information > without the assistance of intermediaries'. > So if the user includes 'header' the P-Asserted-Identity' shall > also be anonymised. Another question about Identity-Info header is asked by Shida as well. > BTW, would you think identity-info, location header be a target > as well for some of the priv-value(e.g. header) as it generally > contains the domain name of the caller in URI form? > > Now if identity is provided, one may doubt the motivation of > requesting privacy but let's not forget that user requesting > the privacy may have no idea sip-identity is provided as service. > In which case it is completely reasonable for caller to request > privacy even when the domain serving that user provides sip-identity. I would like to hear people's opinions about these headers to be targets for any priv-values. Thank you, Mayumi _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 10:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGT-0005Gf-2U; Wed, 01 Nov 2006 10:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGR-0005D8-9J for sipping@ietf.org; Wed, 01 Nov 2006 10:44:27 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIAl-0002hc-AT for sipping@ietf.org; Wed, 01 Nov 2006 10:38:39 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kA1FcHfC017801; Wed, 1 Nov 2006 09:38:17 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA1FcF510927; Wed, 1 Nov 2006 09:38:15 -0600 (CST) Message-ID: <4548BF67.7060901@lucent.com> Date: Wed, 01 Nov 2006 09:38:15 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <44830772.4080905@ericsson.com> <454859B5.8090504@ericsson.com> In-Reply-To: <454859B5.8090504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIPPING LIST , Mary Barnes Subject: [Sipping] Re: [Fwd: WGLC of draft-ietf-sipping-service-examples-10.txt] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Gonzalo Camarillo wrote: > Dear reviewers of the service examples draft, > > the authors of the draft have submitted a new revision of the draft that > is supposed to address all your WGLC comments. Could you please have a > look at it and send a note to the SIPPING mailing list, cc:ing the > chairs, stating whether or not you are now OK with the draft? Gonzalo: The comments in the sections I reviewed have been adequately addressed. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 11:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIto-0002tJ-JZ; Wed, 01 Nov 2006 11:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfItm-0002qW-U1 for sipping@ietf.org; Wed, 01 Nov 2006 11:25:06 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfItR-0007ht-DE for sipping@ietf.org; Wed, 01 Nov 2006 11:24:54 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J820044Y87A9H@siemenscomms.co.uk> for sipping@ietf.org; Wed, 01 Nov 2006 16:23:34 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG64FA>; Wed, 01 Nov 2006 16:23:23 +0000 Content-return: allowed Date: Wed, 01 Nov 2006 16:23:23 +0000 From: "Elwell, John" To: sipping , Alan Johnston Message-id: <50B1CBA96870A34799A506B2313F26670A410637@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Gonzalo Camarillo , mary.barnes@nortel.com Subject: [Sipping] RE: RE: WGLC of draft-ietf-sipping-service-examples-10.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments I submitted during WGLC on version 10 have been fixed in = version 11 with the exception of those points highlighted below. John > -----Original Message----- > From: Elwell, John=20 > Sent: 23 June 2006 11:30 > To: 'Gonzalo Camarillo'; 'sipping' > Cc: 'Samuli P=F6ykk=F6'; 'mary.barnes@nortel.com'; 'Alan=20 > Johnston'; 'Robert Sparks'; 'kevin.summers@sonusnet.com' > Subject: RE: WGLC of draft-ietf-sipping-service-examples-10.txt >=20 > My comments resulting from review of assigned sections (2.3,=20 > 2.18, 2.19): >=20 > Section 1: "and will help further the goal of a standard=20 > implementation of RFC 3261 [2]". Add "... and some of its = extensions". >=20 > Section 1: "Other RFCs also comprise the SIP standard and are=20 > used and references in these call flows.". Change to "Other=20 > RFCs also form part of the SIP standard and are used and=20 > referenced in these call flows." [JRE] Still need to change "used and references" to "used and = referenced". >=20 > Section 1: "Some examples make use the GRUU". Change to "Some=20 > examples make use of the GRUU". >=20 > Section 1: "The use of Secure SIP URIs (sips) is shown=20 > throughout this document with assumed certificate validation=20 > for security. However, other security approaches such as=20 > Digest challenges can be used." I have a problem with this=20 > statement, since it seems to assume that SIPS and Digest=20 > challenges are mutually interchangeable. They are not, and=20 > the use of TLS transport in conjunction with Digest=20 > authentication is a likely scenario, particularly between a=20 > UA and its outbound proxy, where only TLS server=20 > authentication is likely to be available. I would propose=20 > "The use of Secure SIP URIs (sips) is shown throughout this=20 > document, implying TLS transport on each hop with assumed=20 > certificate validation. However, other security approaches=20 > can be used. Also the used of Digest authentication is shown=20 > in some examples." >=20 > Section 2.3: "off of hold". Change to "off hold". >=20 > Section 2.3: "Note that if Alice responds to the INVITE with=20 > hold SDP in the 200 OK, this call flow will not work=20 > properly.". I don't understand what this means. Greater=20 > explanation is required. In particular which INVITE=20 > (presumably F7), and what is meant by "hold SDP" here - a=3Dinactive? >=20 > Section 2.3 F1: "Call-ID: 12345600@atlanta.example.com". For=20 > global uniqueness, would "Call-ID:=20 > 12345600@client.atlanta.example.com" be better. This would=20 > impact the other flows too. [JRE] This has not been addressed. Any particular reason? >=20 > Section 2.3 F1: "Contact: "=20 > and "c=3DIN IP4 music.server.example.com". I would normally=20 > expect the host part of the contact URI to be the same as the=20 > host in the SDP c=3D line, although of course it doesn't need to be. [JRE] My mistake, the comment referred to F6, not F1. So the comment = has not been addressed. >=20 > Section 2.3 F8: ";received=3D192.0.2.103". This is the same IP=20 > address as used by Bob in F2, for example. Likewise F14. >=20 > Section 2.18 "A is alerted". Change to "Alice is alerted". >=20 > Section 2.18 F2 "To: Bob=20 > ;tag=3D982039i4". A 486 response=20 > is not dialog-forming, so I am not sure why it contains a To=20 > tag. However, I can't find anything in RFC 3261 that=20 > clarifies this. If the To tag is removed, this will also impact F3. [JRE] This comment has not been addressed. Note that it now applies to = F2 and F3 in section 2.17. >=20 > Section 2.18 F5: This is missing an Expires header. >=20 > Section 2.18 F6 "NOTIFY sips:alice@atlanta.example.com=20 > SIP/2.0". Change to "NOTIFY=20 > sips:alice@atlanta.client.example.com SIP/2.0" >=20 > Section 2.18 F6: This is missing a Contact header. [JRE] Still not quite correct. Change "biloxi.com" to = "biloxi.example.com". This now applies to F6 in section 2.17. >=20 > Section 2.18 F8: "Subscription-State: active;expires=3D3600".=20 > The value of 3600 for the expires parameter is not very=20 > realistic - it has not decreased since the initial NOTIFY request. [JRE] This has been fixed in a different way, which I don't understand. = Why would Bob's UA terminate the subscription to the dialog event package = when it sends the NOTIFY request F8? Bob's UA does not know for what = purposes Alice's UA has subscribed to this package. Note that if it is decided = that this is correct, we at least need to change "terminiated" to = "terminated". >=20 > Section 2.18. It does not show Alice cancelling the=20 > subscription - not essential but likely. [JRE] As per my comment above, I don't believe Bob's UA is in a = position to know that the subscription has to be terminated when it sends a NOTIFY request. Therefore I still believe Alice's UA needs to send a SUBSCRIBE = to cancel the subscription. >=20 > Section 2.18 F10: "o=3Dalice 2890844526 2890844526 IN IP4=20 > client.atlanta.example.com". The session ID and version are=20 > the same as in F1, but this is a new session request. >=20 > Section 2.19 "Note that Bob's SIP phone immediately=20 > terminates the dialog by indicating in the NOTIFY (F3) that=20 > the subscription is terminated.". Although legitimate, this=20 > is not typical behaviour. >=20 > Section 2.19 F1: "Call-ID: 12345601@atlanta.example.com".=20 > This is a curious choice of Call-ID, since the call is=20 > initiated by Bob@biloxy.com. This will impact subsequent=20 > flows too. Similar comment on F5. >=20 > Section 2.19 F1: "Contact:=20 > ". Similarly this seems=20 > wrong. Presumably it should be the value in the Request-URI of F3. [JRE] This has not been addressed. Since the former F3 has now gone, we can't copy the URI from there. Even though a dialog will not be formed = for the suscription, we still need the Contact header field in the request, since support for no-refer-sub at Bob is not know at this stage. I = would propose . >=20 > Section 2.19 F3: "Content-Type: message/sipfrag" - no body is=20 > shown, and I don't think there should be a body. >=20 > Section 2.19 F4: ";received=3D192.0.2.113". This is the same as=20 > in F2 - should be different. Similar comment on F6/F7. >=20 > John >=20 >=20 >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 13:45:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL5N-0001Dq-Lm; Wed, 01 Nov 2006 13:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfL5L-0001Dk-NU for sipping@ietf.org; Wed, 01 Nov 2006 13:45:11 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfL5E-0006Zb-6Y for sipping@ietf.org; Wed, 01 Nov 2006 13:45:11 -0500 Received: from [172.17.1.79] ([172.17.1.79]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kA1IivYS024922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Nov 2006 12:44:57 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4548EB16.1090208@estacado.net> Date: Wed, 01 Nov 2006 12:44:38 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4547A4D0.2060704@ericsson.com> In-Reply-To: <4547A4D0.2060704@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Adam Roach , sipping Subject: [Sipping] Re: Comments on draft-roach-sipping-callcomp-bfcp-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Gonzalo Camarillo wrote: > a few comments on draft-roach-sipping-callcomp-bfcp-00.txt. > > The draft proposes to to establish a SIP session for the BFCP > connection. Once the floor is grated, the callee establishes another SIP > session for the actual call. > > The draft should explain how the callee correlates both SIP sessions. > That is, how does the callee know that the user calling is the same one > as got the floor. The draft should deal with such correlations for > anonymous callers as well, where the caller's identity will not be > available for the correlation. The intention is that the GRID on the GRUU that the caller uses to complete the call will uniquely identify the caller with regards to the CCBS service. (That is, it can't be used to necessarily identify them, but it does correlate them). > A question: the draft talks about the establishment of one or more BFCP > sessions. What do you have in mind? In which cases would UAs establish > more than one BFCP session? That paragraph could be made clearer. The intention is: if the INVITE forks to, say, three terminals (all of which support call completion), then the calling party will set up three BFCP sessions (one with each terminal) for the call completion service. /a _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 14:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLzE-0004gp-Hv; Wed, 01 Nov 2006 14:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLzD-0004gk-0K for sipping@ietf.org; Wed, 01 Nov 2006 14:42:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLz8-0002lH-JQ for sipping@ietf.org; Wed, 01 Nov 2006 14:42:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Nov 2006 11:42:50 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Jgo2v024796; Wed, 1 Nov 2006 14:42:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1JgnDO008779; Wed, 1 Nov 2006 14:42:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:42:49 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:42:49 -0500 Message-ID: <4548F8B8.1060208@cisco.com> Date: Wed, 01 Nov 2006 14:42:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sipping] Re: Comments on draft-roach-sipping-callcomp-bfcp-00.txt References: <4547A4D0.2060704@ericsson.com> <4548EB16.1090208@estacado.net> In-Reply-To: <4548EB16.1090208@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 19:42:49.0371 (UTC) FILETIME=[E987DEB0:01C6FDED] DKIM-Signature: a=rsa-sha1; q=dns; l=1865; t=1162410170; x=1163274170; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sipping]=20Re=3A=20Comments=20on=20draft-roach-sipping-callcomp -bfcp-00.txt |To:Adam=20Roach=20; X=v=3Dcisco.com=3B=20h=3DzwHl5QURPj23GW/7RZxaQ3IPB4E=3D; b=W0kByy/8/aH5QBHaFFasvnor4kuI/f+mhXT7cQsR4I0Rv0rKrpNJaQ7Bp1bapvSo9XB/T3gK hh+NNat18JIk2p2pdgi8uu+gLcwbHonUfRnyUj5JUO6b260X5uXK1SAP; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sipping , Adam Roach , Gonzalo Camarillo X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Adam Roach wrote: > Gonzalo Camarillo wrote: >> a few comments on draft-roach-sipping-callcomp-bfcp-00.txt. >> >> The draft proposes to to establish a SIP session for the BFCP >> connection. Once the floor is grated, the callee establishes another SIP >> session for the actual call. >> >> The draft should explain how the callee correlates both SIP sessions. >> That is, how does the callee know that the user calling is the same one >> as got the floor. The draft should deal with such correlations for >> anonymous callers as well, where the caller's identity will not be >> available for the correlation. > > The intention is that the GRID on the GRUU that the caller uses to > complete the call will uniquely identify the caller with regards to the > CCBS service. (That is, it can't be used to necessarily identify them, > but it does correlate them). However grid is now gone from gruu. Equivalent functionality, using UA loose routing, is intended to come back sometime, but no doubt it will be somewhat later. (Maybe a lot later.) Paul >> A question: the draft talks about the establishment of one or more BFCP >> sessions. What do you have in mind? In which cases would UAs establish >> more than one BFCP session? > > That paragraph could be made clearer. The intention is: if the INVITE > forks to, say, three terminals (all of which support call completion), > then the calling party will set up three BFCP sessions (one with each > terminal) for the call completion service. > > /a > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 16:37:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNlg-00078e-C6; Wed, 01 Nov 2006 16:37:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfNle-0006s3-DV for sipping@ietf.org; Wed, 01 Nov 2006 16:37:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfNld-0008SP-3D for sipping@ietf.org; Wed, 01 Nov 2006 16:37:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2006 13:37:00 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="1861349590:sNHT47851012" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1Lb0pD004326 for ; Wed, 1 Nov 2006 13:37:00 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LavAw026342 for ; Wed, 1 Nov 2006 13:37:00 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:36:46 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:36:46 -0800 Message-ID: <4549136D.20509@cisco.com> Date: Wed, 01 Nov 2006 16:36:45 -0500 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: IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 21:36:46.0418 (UTC) FILETIME=[D4BA7320:01C6FDFD] DKIM-Signature: a=rsa-sha1; q=dns; l=1177; t=1162417020; x=1163281020; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-schubert-sipping-wg-analyzed-00; X=v=3Dcisco.com=3B=20h=3DWigrp5WkH20ttjSutke0XKcPL80=3D; b=g0RW2sWextxTVK4NIOFMlOyGHF0xhrR+xtcc1cHfiOkfU2vHNsNIuvS3px+7qWV9vLwOB0wE KgUs0o9cXx/AoBHujg3orUZLnKlnhsF8tuQMGxlfBhOmN3+/hz0PSH+k; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thanks for putting this together. Its always good to see real numbers to help understand a problem. My main question is how these trends compare to other working groups in the IETF. I think that might tell us a lot. You make an interesting observation here: 9. Room for improvements? Although SIPPING was initially formed to filter work going into SIP WG for SIP WG to better address the drafts that are of interests of SIP WG, looking at the figures above it may be now SIP WG that needs to take back some of the task it delegated to SIPPING WG. Here are some questions we may want to consider and its reasoning. I would argue that the more logical conclusion is that the sipping WG needs to reject more work than it is right now. That is what will really make it a filtering function. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 16:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO4h-0003ht-AG; Wed, 01 Nov 2006 16:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfO4e-0003hl-3H for sipping@ietf.org; Wed, 01 Nov 2006 16:56:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfO4c-0003sY-Ej for sipping@ietf.org; Wed, 01 Nov 2006 16:56:40 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2006 13:56:26 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="1861356113:sNHT6595144438" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1LuP8G002862; Wed, 1 Nov 2006 13:56:25 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1LuPW4001629; Wed, 1 Nov 2006 13:56:25 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:56:25 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 13:56:25 -0800 Message-ID: <45491808.8050003@cisco.com> Date: Wed, 01 Nov 2006 16:56:24 -0500 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: Mayumi Munakata Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 References: <200611010951.kA19pxSh002520@imf.m.ecl.ntt.co.jp> In-Reply-To: <200611010951.kA19pxSh002520@imf.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 21:56:25.0465 (UTC) FILETIME=[937EBE90:01C6FE00] DKIM-Signature: a=rsa-sha1; q=dns; l=5911; t=1162418185; x=1163282185; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Discussions=20on=20draft-munakata-sipping-privacy-cl arified-00; X=v=3Dcisco.com=3B=20h=3DfX8H7ncNnKZDvjpLLdAur6MOTAc=3D; b=rxcFymBtZBgwJEvlXoOjBDCp+xcX9DWolEu+gQv7yX8Fs2/3Wrm3Cz7LGh3oCP2IApv5qeob 30AJQbIbNE0Wr78OaX6ttyuW5y49U+Y+b7HK6ryc0NcNMkLf7/0lCafy; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I'd like to take a step back here for a second. I think the complexity here on how to do this is really illustrating that there is a larger architectural problem. The larger problem is the complexity involved in signaling privacy intentions from the UA, given the diversity of what such intentions might mean. I also think its important to note that, AFAIK, the vast majority of SIP 'privacy' that is deployed today, is just RFC 3325 and 'id' privacy. Thats it. This, to me, calls to a failure of RFC 3323 to achieve its goals. I would suggest that much has changed since the publication of RFC 3323. In particular, we know have the tools that make it possible for a UA to populate a valid SIP message with fields which don't identify itself. This can be accomplished through a combination of TURN and GRUU. Given the UA can populate a message which doesn't identify itself, the real issue that remains is the service provider including information that identifies the user or the provider itself. Clearly, if the user includes anonymous identifiers in fields like From, this is a signal that an SP should not insert any headers or information that identify the user. As for identifying the provider itself - well, there is no helping that, since the provider must be identified for the call to work. Consequently, if a user wants to avoid having the provider be identified, they need to use a different provider entirely, one whose function is to be anonymous. Much of this is discussed in: http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-privacy-00.txt which basically suggests deprecation of RFC 3323 entirely. Before we spend many cycles on "fixing up" RFC 3323, I think we should step back and ask ourselves whether we want to even continue to pursue it as the vehicle for privacy in SIP. -Jonathan R. Mayumi Munakata wrote: > Hi all, > > Thank you for everybody's comments for draft-munakata-sipping-privacy-clarified-00. > > In order to put together the discussions so far, I try rewriting the latter half of the Table 1 as follows. > > ----------------------------------------------------------------------- > Target headers user header session id history > > Warning modify > Record-Route strip(*1) > P-Asserted-Identity delete? delete? delete > History-Info not add not add delete > Path strip(*1) > Referred-By modify(*2) > Replaces > Service-Route strip(*1) > Target-Dialog modify? > Identity-Info modify? > > *1: "strip" means that privacy services operating on requests should > remove all Via/Record-Route/Path/Service-Route headers that have > been added to the request prior to its arrival at the privacy > service and then should add a single Via/Record-Route/Path/ > Service-Route header representing themselves. The server doing the > stripping must restore the stripped value in the responses. > > *2: Referred-By header will be modified when it appears in REFER request > with Privacy:user that means the referrer's privacy is required. > It should not be modified when it appears in INVITE request. > > ----------------------------------------------------------------------- > > It seems that Warning, Path, Referred-By, Replaces, and Service-Route headers' manipulations were agreed, so I deleted the question marks. (Empty column of Replaces header means that the header is not a target for any priv-values.) > > On the other hand, Target-Dialog header likely needs more discussion. > I personally agree Paul's opinion that Target-Dialog should not be modified considering the meaning of the header. > > >>- Replaces: this references specific state held by the target of the >> request. It is obviously already known to the target, and the >> request can't function without it. I don't see what can/should be >> modified. >> >>- Target-Dialog: same as Replaces. > > > > A question about P-Asserted-Identity header is asked by Roland. > > >>My interpretation is that the P-Asserted-Identity is also a header >>'which cannot be completely expunged of identifying information >>without the assistance of intermediaries'. >>So if the user includes 'header' the P-Asserted-Identity' shall >>also be anonymised. > > > > Another question about Identity-Info header is asked by Shida as well. > > >>BTW, would you think identity-info, location header be a target >>as well for some of the priv-value(e.g. header) as it generally >>contains the domain name of the caller in URI form? >> >>Now if identity is provided, one may doubt the motivation of >>requesting privacy but let's not forget that user requesting >>the privacy may have no idea sip-identity is provided as service. >>In which case it is completely reasonable for caller to request >>privacy even when the domain serving that user provides sip-identity. > > > I would like to hear people's opinions about these headers to be targets for any priv-values. > > Thank you, > Mayumi > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 17:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOJZ-0008JH-VL; Wed, 01 Nov 2006 17:12:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOJY-0008JA-3J for sipping@ietf.org; Wed, 01 Nov 2006 17:12:04 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOJV-0006hW-Nw for sipping@ietf.org; Wed, 01 Nov 2006 17:12:04 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2006 14:12:01 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="753592999:sNHT49983092" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1MC1Si025367; Wed, 1 Nov 2006 14:12:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1MC0Ao005234; Wed, 1 Nov 2006 14:12:00 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:12:00 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:12:00 -0800 Message-ID: <45491BAF.5000703@cisco.com> Date: Wed, 01 Nov 2006 17:11:59 -0500 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: "Jani Hautakorpi (JO/LMF)" Subject: Re: [Sipping] Method for URI-List servers to refuse the handling of a URI-List References: <44A9009E.3070906@ericsson.com> In-Reply-To: <44A9009E.3070906@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 22:12:00.0539 (UTC) FILETIME=[C0D7B6B0:01C6FE02] DKIM-Signature: a=rsa-sha1; q=dns; l=1481; t=1162419121; x=1163283121; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Method=20for=20URI-List=20servers=20to=20refuse=20th e=20handling=0A=20of=20a=09URI-List; X=v=3Dcisco.com=3B=20h=3D4mCP91ItWOiUFfVv2vM/+hDntwc=3D; b=k6drrkJqsDT9o0xXOxfOfuklUqliNxPhrYWaZWmcHsRlGie/R4BoiBEHgJ1nHZ5eUGMd+TJm 8hgYpwcLt/v3NaPKLV7vxtObi7G40Vx4srnYbmSPIjd47LKUCY7SFwnT; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sipping@ietf.org, gonzalo.camarillo@ericsson.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I don't really understand the motivation for this draft. There are countless reasons why a server might not want to process a request. Why is it important in this case to communicate the reason back to the UA? Why not just send a 400 and be done with it? Is it commonly expected that a server will refuse to fan out a request? What remediation to you expect the client to take? -Jonathan R. Jani Hautakorpi (JO/LMF) wrote: > Hi all, > > We have written a draft describing a method for URI-list servers to > refuse the handling of a URI-List. You can find the draft from: > > http://www.ietf.org/internet-drafts/draft-hautakorpi-sipping-uri-list-handling-refused-00.txt > > > The motivation for writing this draft is that currently URI-List servers > don't have any explicit method for denying the handling of incoming > request. This draft describes just that in a form of a new response > code, 495 (URI-List Handling Refused). > > I would be very interested in hearing any comments/ideas/thoughts that > you might have about this draft. So, please send your input to me > (jani.hautakorpi@ericsson.com). > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 17:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOj5-0006Kq-VH; Wed, 01 Nov 2006 17:38:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOj4-0006ER-4V for sipping@ietf.org; Wed, 01 Nov 2006 17:38:26 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOj1-0003Ig-P1 for sipping@ietf.org; Wed, 01 Nov 2006 17:38:26 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2006 14:38:24 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="349424661:sNHT53440348" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1McN8X017839; Wed, 1 Nov 2006 14:38:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1McFWG014390; Wed, 1 Nov 2006 14:38:22 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:38:21 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:38:21 -0800 Message-ID: <454921DB.2090207@cisco.com> Date: Wed, 01 Nov 2006 17:38:19 -0500 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: Volker Hilt Subject: Re: AW: [Sipping] Comments on draft-hilt-sipping-overload-00.txt References: <454777ED.1020101@ericsson.com> <454780B0.9080508@bell-labs.com> In-Reply-To: <454780B0.9080508@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 22:38:21.0403 (UTC) FILETIME=[6F1C6AB0:01C6FE06] DKIM-Signature: a=rsa-sha1; q=dns; l=1728; t=1162420703; x=1163284703; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20AW=3A=20[Sipping]=20Comments=20on=20draft-hilt-sipping-overload- 00.txt; X=v=3Dcisco.com=3B=20h=3DhbxpJOel5ScOIc/OYpvPxPXOA/k=3D; b=fsgQbWKeGM69jri12CO5fRBw4nZDrSaUKDQMbPf5B9vdRe9T5IyLER+2qqWP3bVYnjC5pFCT be3jJWTV5/Rq/J2nHqLZMhZHC9cOZxShixPOw1xNYD6ZRXGJz1olTkc1; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: daryl.malas@level3.com, iwidjaja@lucent.com, rich.terpstra@level3.com, sipping , Gonzalo Camarillo X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org inline. Volker Hilt wrote: > Christian, Gonzalo, > >> >> yes, the draft should talk about overload state that needs to be >> propagated upstream in cases like the one you describe. >> > Yes, this case probably needs more attention in the draft. > >>> what about an IMS/FMC like architecture where >>> application servers (Ax) and e.g. MGCF functionality (C) are hidden >>> behind the IMS cloud (B). >>> >>> A1---\ >>> A2----B--- C >>> A3---/ IF C enters overload it will only inform B to reduce the load >>> send to C by x% (although the traffic from Ax is the reason for this). > > > Yes. It is up to B to decide what to do. If B knows that it is in a > controlled environment and C is its *only* downstream neighbor, B can > use hop-by-hop overload control to indicate overload to its upstream > neighbors if C is overloaded. Essentially B can consider C as a message > processing resource in this scenario. If this resource is overloaded B > signals overload to its upstream neighbor. No; I don't think it signals overload upstream. This violates the definition of what overload means. Rather, I think it rejects the request, and we need a way to say that a request was rejected because all downstream servers were congested. We need to specify behavior on receipt of such a response. The usual questions about retrying come up... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 17:44:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOp0-0001Wf-J0; Wed, 01 Nov 2006 17:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOoz-0001VU-SZ for sipping@ietf.org; Wed, 01 Nov 2006 17:44:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOov-0004R7-2D for sipping@ietf.org; Wed, 01 Nov 2006 17:44:33 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2006 14:44:28 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="447626416:sNHT63650964" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1MiSw8001357; Wed, 1 Nov 2006 14:44:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1MiSAo009474; Wed, 1 Nov 2006 14:44:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 14:44:28 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 14:44:27 -0800 Message-ID: <4549234A.9000402@cisco.com> Date: Wed, 01 Nov 2006 17:44:26 -0500 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: Volker Hilt Subject: Re: [Sipping] Combined overload control draft References: <453F719D.8020600@bell-labs.com> In-Reply-To: <453F719D.8020600@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 22:44:27.0968 (UTC) FILETIME=[4999CC00:01C6FE07] DKIM-Signature: a=rsa-sha1; q=dns; l=5866; t=1162421068; x=1163285068; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Combined=20overload=20control=20draft; X=v=3Dcisco.com=3B=20h=3D0wap3TtFTvMZN2hz8kLWrLJ0BlE=3D; b=lymloMAUzOOZzZwB2TjkCg/liBa+kUODzAKJNeM9XZY4IxlybTZfOX2oPGt8thDifYgnLpyD akBn3y8QwGE9WyhOaj0Qep5bt2lDUbdvV4aCTMDuIC62BHVF/tXDV+fn; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: "Malas, Daryl" , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Overall, this is very good. I think it is pretty much on target to what we need, and is more or less what I had in mind. Some comments of course. Firstly, I think we only want to address the hop-by-hop mechanism. I don't think we can do the e2e. Secondly, I don't see a need to report load. I think we are much better off by specifying a throttle value, and defining a normative algorithm that gets executed on the upstream server. You have tried to avoid a normative algorithm. However I think its essential. Knowledge of what the upstream behavior will be is key to deciding how to transform knowledge of load into a set of parameters to include in the response. Much like TCP specifies AIMD on the upstream elements, we need something like that. I like the way you fade out the load estimates. One issue you need to address is that a client will get lots of load values from the same downstream server (one in each response). So does it keep the most recent? How do you define most recent? You need to address that. I'm not sure I agree with using 503 with upstream elements that don't support it. This introduces the possibility of making things worse because of the known problems with 503. I'd prefer a new response code or something. Another piece of this is whether an element needs to implement some kind of fairness algorithm so that it doesn't give disproportionate work to upstream elements which don't throttle. Thats also the main security consideration you need to address - what if an upstream element doesn't obey the throttle instructions. -Jonathan R. Volker Hilt wrote: > We have submitted a new overload control draft that combines the two > existing overload drafts: draft-hilt-sipping-hopbyhop-overload-00 and > draft-malas-sipping-congestion-header-01. > > In addition to combining the existing drafts, the new draft has been > completely revised to accommodate comments and feedback received and it > has a new section that discusses design considerations and introduces a > control model for SIP overload control. > > Volker > > > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-hilt-sipping-overload-00.txt > From: > Internet-Drafts@ietf.org > Date: > Tue, 17 Oct 2006 15:50:01 -0400 > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Initiation Protocol (SIP) Overload Control > Author(s) : V. Hilt, et al. > Filename : draft-hilt-sipping-overload-00.txt > Pages : 23 > Date : 2006-10-17 > > Overload occurs in Session Initiation Protocol (SIP) networks when > SIP servers have insufficient resources to handle all SIP messages > they receive. Even though the SIP protocol provides a limited > overload control mechanism through its 503 response code, SIP servers > are still vulnerable to overload. This specification defines a new > SIP overload control mechanism that protects SIP servers against > overload. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-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-hilt-sipping-overload-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-hilt-sipping-overload-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 18:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfP8l-0007jP-Ok; Wed, 01 Nov 2006 18:04:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfP8k-0007iY-E9 for sipping@ietf.org; Wed, 01 Nov 2006 18:04:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfP8j-00007T-1D for sipping@ietf.org; Wed, 01 Nov 2006 18:04:58 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2006 15:04:56 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="447631809:sNHT69475252" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1N4urD006043 for ; Wed, 1 Nov 2006 15:04:56 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA1N4uW4017102 for ; Wed, 1 Nov 2006 15:04:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 15:04:56 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:04:56 -0800 Message-ID: <45492817.6030808@cisco.com> Date: Wed, 01 Nov 2006 18:04:55 -0500 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: IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 23:04:56.0141 (UTC) FILETIME=[25A61FD0:01C6FE0A] DKIM-Signature: a=rsa-sha1; q=dns; l=1440; t=1162422296; x=1163286296; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-malas-performance-metrics-05; X=v=3Dcisco.com=3B=20h=3DV6AbRqqbmoWyF7aAJPqM9mrr8tk=3D; b=glLGGJZCFt9riWMp9UvLXSX1xAL6oTv0Ky/5s+dDeOWC8PyQ9gAqiQf+I6jkywv8riJYOWYx s38KYBWimrfb4klFT2WmdQf+/hBEgc54HXT9kMCUY9ilGLJD/ezOK6gU; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sipping] comments on draft-malas-performance-metrics-05 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Section 3.1.2 says it measures the delay from the register request to a failure response, yet the figure shows the interval as from REGISTER to the 200 OK, through the 401. This seems in conflict. Section 3.2 claims that SRD is the same as PDD, but its not. Only the definition in 3.2.1 could be consider PDD. Section 3.3 - why do you include timeouts here and not in the other metrics? Section 3.4 - should consider when a BYE comes in the reverse direction Section 3.5 - this is not the same as ASR. I thought that ASR includes failure cases which are still a consequence of successfully reaching the called party, most notably 'busy'. The metric you define is not that useful as a consequence. So you would need to include specific error response codes in here. That will not be an easy task. For example do you include 403? Section 3.6 - why not other 5xx codes? Section 3.8 - so what values of Reason are included in this? Section 3.9 - this definition is vague. How do you know whether the response comes from the the intended proxy or UA? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 18:25:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPSa-0004Wk-CT; Wed, 01 Nov 2006 18:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPSY-0004Vk-9E for sipping@ietf.org; Wed, 01 Nov 2006 18:25:26 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPSW-0003IR-V2 for sipping@ietf.org; Wed, 01 Nov 2006 18:25:26 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2006 15:25:24 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="753626312:sNHT47980942" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1NPOFW013652 for ; Wed, 1 Nov 2006 15:25:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA1NPOAo026100 for ; Wed, 1 Nov 2006 15:25:24 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:25:23 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:25:23 -0800 Message-ID: <45492CE2.6090408@cisco.com> Date: Wed, 01 Nov 2006 18:25:22 -0500 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: IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 23:25:23.0489 (UTC) FILETIME=[01349110:01C6FE0D] DKIM-Signature: a=rsa-sha1; q=dns; l=1028; t=1162423524; x=1163287524; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:draft-stucker-sipping-early-media-coping-03; X=v=3Dcisco.com=3B=20h=3DTqsICJZ9lbjIV8+F2ZotcKj9OnU=3D; b=Dk0tOlRwmbBduW//SVgB/FI7dqIiJv1rrYi2AGTFcxcRROnpPP29gHBELgaCFCa0Avr893H1 ZlNw5jVk7EsFMSK/nTqz9Lzp5njBPkRDO0cjaagc7ahaAOnPtjdwaLaA; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sipping] draft-stucker-sipping-early-media-coping-03 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I read this draft, and am pretty confused about what problem its solving. I was looking for something that pointed out concrete issues with the existing mechanisms but didnt see that. It seems its worried about classifying types of media streams in terms of importance so a UA knows whether to render them or not. What I totally fail to understand is how a gateway, which is really our primary use case for this mess, knows how to classify the media stream. It won't. For things that can classify (maybe a SIP-based prepaid server or something), they'll just mark everything as critical and we're right back to the issue that I think maybe you're trying to solve. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 19:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQCt-0004Fm-ID; Wed, 01 Nov 2006 19:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQCr-0004B2-Bi for sipping@ietf.org; Wed, 01 Nov 2006 19:13:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQ0H-0000Iq-FL for sipping@ietf.org; Wed, 01 Nov 2006 19:00:21 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Nov 2006 16:00:14 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="349452976:sNHT8019287164" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA200Dr7007308 for ; Wed, 1 Nov 2006 16:00:13 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA200Din021418 for ; Wed, 1 Nov 2006 16:00:13 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:00:13 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 16:00:12 -0800 Message-ID: <4549350B.1080905@cisco.com> Date: Wed, 01 Nov 2006 19:00:11 -0500 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: IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 00:00:12.0974 (UTC) FILETIME=[DEA2ACE0:01C6FE11] DKIM-Signature: a=rsa-sha1; q=dns; l=2356; t=1162425613; x=1163289613; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20draft-roach-sipping-callcomp-bfcp-00; X=v=3Dcisco.com=3B=20h=3DybzQviRjgwurG77z09lLjHhAX3A=3D; b=Oy3MDu1FPQ0W/rWH9MOEfUpUA/KX3o46rvxCqKLdd7+PTwPzhbr76+kLQhpr+MAoSqdvG+Q1 nUX/uOgVObxGIe49T85TC2WDwwJgbJQjVrj9JNBn+vWxSTpIvmojBs5u; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This is a very interesting draft. Neat idea to use BFCP to manage the queue. Its not clear to me that this mechanism works well in the face of forking. Seems like you could end up with disparate queues for each of my phones. What you are really after is the state of the user (i.e., AOR) and not their devices. This seems to make it problematic to implement this in the UA at all. I understand your intention is that this be in a server in the network; but if it only works in that case it needs to be called out. Similar issues arise when the originating user has multiple devices. So if I call you from phone 1, and later you are available, does the ringback happen only at phone 1 or all of my phones? Seems like the latter is much more desirable. That too implies that a UA-based solution on the originating side has some problems. There is clearly a relationship between all of this and presence; I think you need to call that out. On whether BFCP is the right thing or not for this problem, I'm not sure. In one sense, you could characterize this as really a problem with RFC3265 in general; that for certain event packages, notification of an event to all watchers can cause them to take actions that result in a further change to that same state. This is a race condition. An alternative way to model the queueing discipline to fix the race is through a generic capability in RFC 3265, which sends out notifications gradually. You need to be careful to not end up embedding queue control commands in SUBSCRIBE as you have pointed out previously. However, nothing stops a notifier from sending out notifications one at a time. That would not permit you to do things like pause your position in queue or similar features, but 3265 sometimes feels to be more on-target for this service. I share John's concerns as to whether this really interoperates with the PSTN. Perhaps if you had some call flows demonstrating it, this would help. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 01 23:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfU9v-00042U-Ti; Wed, 01 Nov 2006 23:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfU9u-00042M-Fc for sipping@ietf.org; Wed, 01 Nov 2006 23:26:30 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfU9t-0004xY-8J for sipping@ietf.org; Wed, 01 Nov 2006 23:26:30 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 01 Nov 2006 20:23:44 -0800 X-IronPort-AV: i="4.09,379,1157353200"; d="scan'208"; a="603060644:sNHT149770596" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Nov 2006 23:26:27 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2806099790@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on draft-service-examples-11.txt Thread-index: Acb+NxBLhb4KP2qhSZGcKqNT5+ppxw== From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sipping] Comment on draft-service-examples-11.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hello, I believe there is a small issue in draft-service-examples-11.txt In the call pickup example, message F3 SUBSCRIBE Bill -> Bob The Subscription-state header is present in the SUBCRIBE request. According to RFC 3265, section 7.2 such header should not be present because it is '-' (non applicable) in case of SUBSCRIBEs. According to RFC3261 "Not applicable" means that the header field MUST NOT be present in a request." I belive a header Expires with value 0 should be used to convey a immediate expiration. Thanks, Reinaldo _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 01:25:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVyW-0000Kb-V2; Thu, 02 Nov 2006 01:22:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVyV-0000KV-8q for sipping@ietf.org; Thu, 02 Nov 2006 01:22:51 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfVyO-0008On-G1 for sipping@ietf.org; Thu, 02 Nov 2006 01:22:51 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 920D54F4; Thu, 2 Nov 2006 07:22:35 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 07:22:35 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 07:22:34 +0100 Received: from [131.160.126.125] (rvi2-126-125.lmf.ericsson.se [131.160.126.125]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F37042370; Thu, 2 Nov 2006 08:22:34 +0200 (EET) Message-ID: <45498EAA.4000308@ericsson.com> Date: Thu, 02 Nov 2006 08:22:34 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sipping] Method for URI-List servers to refuse the handling of a URI-List References: <44A9009E.3070906@ericsson.com> <45491BAF.5000703@cisco.com> In-Reply-To: <45491BAF.5000703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 06:22:35.0043 (UTC) FILETIME=[492C9730:01C6FE47] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jonathan, in addition to the response code you refer to, the draft defines a way to inform the client about which entries in the URI-list the server did not like, because those entries were lists themselves, and provide the individual members of those lists. For example, a server receives the following URI-list in a request: Bob@example.com Bob-friends@server2.example.com The second URI in the list is a URI-list that needs to be "exploded" at a different server. But our server cannot know that just by looking at the URI. It sends a request to each of the URIs and gets an error response (the one defined in the draft) and a list with the individual members of Bob-friends@server2.example.com. The original server then sends requests to those URIs. This is basically an OMA dependency for PoC. The server receiving the original request is the controlling PoC server of an ad-hoc PoC session, which is created by a request that contains URIs that represent PoC sessions at a different PoC server. Any given PoC session can only have a single controlling PoC server. So, the debate here is whether this is general enough to be a regular header field or whether a P-header using an existing error code is more appropriate. I believe that the ability to point out which URIs in a URI-list caused a server to refuse the request is general enough and, thus, a regular header field is the way to go. However, OMA will most likely be equally happy if we add the "P-" prefix to such header. Cheers, Gonzalo Jonathan Rosenberg wrote: > I don't really understand the motivation for this draft. There are > countless reasons why a server might not want to process a request. Why > is it important in this case to communicate the reason back to the UA? > Why not just send a 400 and be done with it? Is it commonly expected > that a server will refuse to fan out a request? What remediation to you > expect the client to take? > > -Jonathan R. > > Jani Hautakorpi (JO/LMF) wrote: > >> Hi all, >> >> We have written a draft describing a method for URI-list servers to >> refuse the handling of a URI-List. You can find the draft from: >> >> http://www.ietf.org/internet-drafts/draft-hautakorpi-sipping-uri-list-handling-refused-00.txt >> >> >> The motivation for writing this draft is that currently URI-List >> servers don't have any explicit method for denying the handling of >> incoming >> request. This draft describes just that in a form of a new response >> code, 495 (URI-List Handling Refused). >> >> I would be very interested in hearing any comments/ideas/thoughts that >> you might have about this draft. So, please send your input to me >> (jani.hautakorpi@ericsson.com). >> >> > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 01:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWM3-0000EJ-4F; Thu, 02 Nov 2006 01:47:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWM1-0000Cm-NQ for sipping@ietf.org; Thu, 02 Nov 2006 01:47:09 -0500 Received: from gate01.nexlink.ch ([80.86.198.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWM0-00064q-3g for sipping@ietf.org; Thu, 02 Nov 2006 01:47:09 -0500 Received: from MAIL03.NEXLINK.CH ([10.51.9.3]) by gate01.nexlink.ch (8.13.1/8.13.1) with ESMTP id kA26krNS014701; Thu, 2 Nov 2006 07:46:54 +0100 Message-Id: <200611020646.kA26krNS014701@gate01.nexlink.ch> MIME-Version: 1.0 From: =?ISO-8859-1?Q?Jo=EBl Repiquet?= To: Gonzalo Camarillo Date: Thu, 02 Nov 2006 07:46:53 +0100 X-Uidl: 1162369465.H368398P10812.MAIL03.NEXLINK.CH X-Mailer: AtMail 4.3 X-Spam-Score: 1.3 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sipping@ietf.org, mary.barnes@nortel.com Subject: [Sipping] Re: [WGLC of draft-ietf-sipping-service-examples-10.txt] (examples 2.4, 2.5, 2.6) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0410256029==" Errors-To: sipping-bounces@ietf.org --===============0410256029== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

In draft-ietf-sipping-service-examples-11,  there is only one error= left with respect to the comments I made about examples 2.4, 2.5 and 2.6:<= br />
In F13, p. 50, the session identifier has been updated but not t= he session version:

      o=3Dcarol 28909445= 27 2890844527 IN IP4 client.chicago.example.com

is to be replace= d by:

      o=3Dcarol 2890944527 2890944527 = IN IP4 client.chicago.example.com

Regards


O= n Mer Nov 1 9:24 , Gonzalo Camarillo sent:

Dear reviewers of = the service examples draft,
=0D
=0D the authors of the draft have submitted a new revision of the draft that =0D is supposed to address all your WGLC comments. Could you please have a
=0D look at it and send a note to the SIPPING mailing list, cc:ing the
= =0D chairs, stating whether or not you are now OK with the draft?
=0D
=0D
=0D


--===============0410256029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0410256029==-- From sipping-bounces@ietf.org Thu Nov 02 03:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYIZ-00039F-9F; Thu, 02 Nov 2006 03:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYIY-000394-4p for sipping@ietf.org; Thu, 02 Nov 2006 03:51:42 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYIV-00006J-Gw for sipping@ietf.org; Thu, 02 Nov 2006 03:51:42 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA28pYp1007717; Thu, 2 Nov 2006 17:51:34 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4D3C420AE29; Thu, 2 Nov 2006 17:51:34 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1F4AA20AE28; Thu, 2 Nov 2006 17:51:34 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA28pXwl010611; Thu, 2 Nov 2006 17:51:33 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA28pX51023716; Thu, 2 Nov 2006 17:51:33 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA28pWaU023711; Thu, 2 Nov 2006 17:51:32 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id kA28pWP4018451; Thu, 2 Nov 2006 17:51:32 +0900 (JST) Message-Id: <200611020851.kA28pWP4018451@imf.m.ecl.ntt.co.jp> To: jdrosen@cisco.com Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 From: Mayumi Munakata Date: Thu, 02 Nov 2006 17:51:32 +0900 X-Mailer: WebMail V3.5.0 PL4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jonathan, Thank you for the valuable comments. To my knowledge, RFC 3323 is widely deployed already, so it is necessary to keep the mechanism and clarify it as much as possible for the already deployed implementations. Your sip-identity-privacy draft may solve all the privacy problems, but still, we need RFC 3323, even if it is a short-term solution. If everybody views RFC 3323 in the same way, I can change the text in Section 4.2. (Guidelines on specifying new priv-values) to something like "it is RECOMMENDED to avoid defining a new priv-value in future RFCs". Thanks, Mayumi _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 04:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnm-0005p4-EK; Thu, 02 Nov 2006 04:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnh-0005kE-3W for sipping@ietf.org; Thu, 02 Nov 2006 04:23:53 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYhE-0005hI-GZ for sipping@ietf.org; Thu, 02 Nov 2006 04:17:14 -0500 Received: from sonata (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA29G9m18074; Thu, 2 Nov 2006 02:16:30 -0700 Message-Id: <200611020916.kA29G9m18074@agnada.com> From: To: "'Jonathan Rosenberg'" , "'IETF Sipping List'" , Subject: Re: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00 Date: Thu, 2 Nov 2006 01:15:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9/fEW0lNllinCSNaW3tQhVk6p9wAR9y1wAAZlhlA= X-Spam-Score: 1.3 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jonathan; Thanks for your review, my comments inline.. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, November 01, 2006 1:37 PM > To: IETF Sipping List > Subject: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00 > > Thanks for putting this together. Its always good to see real numbers > to help understand a problem. > > My main question is how these trends compare to other working groups > in the IETF. I think that might tell us a lot. [[Shida]] Any suggestions? I was thinking of possibly comparing it to SIP WG to see if the suggestion I made below would be feasible and possibly SIMPLE WG, which span off from SIPPING/SIP that may show us the benefit of distributing the focus. > > You make an interesting observation here: > > 9. Room for improvements? > > Although SIPPING was initially formed to filter work going into SIP > WG for SIP WG to better address the drafts that are of interests of > SIP WG, looking at the figures above it may be now SIP WG that needs > to take back some of the task it delegated to SIPPING WG. Here are > some questions we may want to consider and its reasoning. > > > I would argue that the more logical conclusion is that the sipping WG > needs to reject more work than it is right now. That is what will > really make it a filtering function. [[Shida]] Sure.. I don't disagree, but you do need to see that SIPPING focuses on very vast scope and with having people with different focuses and expectations from the WG in the room, it's hard to reject work that some people think is uninterested while others in the room think its important. Possible solution may be to take a step that SIP took when it span-off SIPPING, which is to narrow the focus so WG can work more efficiently (As Dean suggested before or at the IETF 65..). As far as I can see SIPPING currently looks at: 1. Requirements for service, security and new functions that results in new SIP extension.(RFC4484, RFC4245 etc.) 2. Requirements form different SDOs.(OMA, 3GPP, TISPAN etc.) 3. Guidelines trying to clarify issues that are arising in the actual deployments. (dialogusage etc.). 4. Guidelines on how SIP simply works.(RFC3665:basic-call-flows etc.) 5. Frameworks. > There are two categories; > framework which will contribute in helping new services emerge. - consent-fw / uri-list services > framework which tries to help SIP work flawlessly in the actually deployment. - config-fw / session-policies 6. Interwork related items(RFC3398,RFC3372 etc.). 7. Test spec(RFC4475 etc.) 8. New event packages.(rtcp-summary, kpml etc.) 9. BCP.(A bit different from 3 and 4 as BCP tries to lay out the best way to accomplish a task among various way of accomplishing the same tasks. > nat-scenario, v6-transition etc. 10. Analysis of possible issues. (sbc-funcs etc.) 11. Bug fixes.(loop-fix, max-breadth etc.) * There are probably more but what I have above are what comes to my mind right now.. Regards Shida > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 05:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZwT-0006WR-76; Thu, 02 Nov 2006 05:37:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXHd-00054s-Kc for sipping@ietf.org; Thu, 02 Nov 2006 02:46:41 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXHa-0006nC-6j for sipping@ietf.org; Thu, 02 Nov 2006 02:46:41 -0500 Received: from sonata (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA27jWI11195; Thu, 2 Nov 2006 00:45:53 -0700 Message-Id: <200611020745.kA27jWI11195@agnada.com> From: "Shida" To: "'Jonathan Rosenberg'" , "'IETF Sipping List'" , Subject: RE: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00 Date: Wed, 1 Nov 2006 23:45:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9/fEW0lNllinCSNaW3tQhVk6p9wAR9y1w In-Reply-To: <4549136D.20509@cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Thu, 02 Nov 2006 05:36:59 -0500 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jonathan; Thanks for your review, my comments inline.. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, November 01, 2006 1:37 PM > To: IETF Sipping List > Subject: [Sipping] comments on draft-schubert-sipping-wg-analyzed-00 > > Thanks for putting this together. Its always good to see real numbers to > help understand a problem. > > My main question is how these trends compare to other working groups in > the IETF. I think that might tell us a lot. [[Shida]] Any suggestions? I was thinking of possibly comparing it to SIP WG to see if the suggestion I made below would be feasible and possibly SIMPLE WG, which span off from SIPPING/SIP that may show us the benefit of distributing the focus. > > You make an interesting observation here: > > 9. Room for improvements? > > Although SIPPING was initially formed to filter work going into SIP > WG for SIP WG to better address the drafts that are of interests of > SIP WG, looking at the figures above it may be now SIP WG that needs > to take back some of the task it delegated to SIPPING WG. Here are > some questions we may want to consider and its reasoning. > > > I would argue that the more logical conclusion is that the sipping WG > needs to reject more work than it is right now. That is what will really > make it a filtering function. [[Shida]] Sure.. I don't disagree, but you do need to see that SIPPING focuses on very vast scope and with having people with different focuses and expectations from the WG in the room, it's hard to reject work that some people think is uninterested while others in the room think its important. Possible solution may be to take a step that SIP took when it span-off SIPPING, which is to narrow the focus so WG can work more efficiently (As Dean suggested before or at the IETF 65..). As far as I can see SIPPING currently looks at: 1. Requirements for service, security and new functions that results in new SIP extension.(RFC4484, RFC4245 etc.) 2. Requirements form different SDOs.(OMA, 3GPP, TISPAN etc.) 3. Guidelines trying to clarify issues that are arising in the actual deployments. (dialogusage etc.). 4. Guidelines on how SIP simply works.(RFC3665:basic-call-flows etc.) 5. Frameworks. > There are two categories; > framework which will contribute in helping new services emerge. - consent-fw / uri-list services > framework which tries to help SIP work flawlessly in the actually deployment. - config-fw / session-policies 6. Interwork related items(RFC3398,RFC3372 etc.). 7. Test spec(RFC4475 etc.) 8. New event packages.(rtcp-summary, kpml etc.) 9. BCP.(A bit different from 3 and 4 as BCP tries to lay out the best way to accomplish a task among various way of accomplishing the same tasks. > nat-scenario, v6-transition etc. 10. Analysis of possible issues. (sbc-funcs etc.) 11. Bug fixes.(loop-fix, max-breadth etc.) * There are probably more but what I have above are what comes to my mind right now.. Regards Shida > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 08:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfcxr-0006S2-4e; Thu, 02 Nov 2006 08:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfcxp-0006Rw-Oi for sipping@ietf.org; Thu, 02 Nov 2006 08:50:37 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfcxL-0003lk-5s for sipping@ietf.org; Thu, 02 Nov 2006 08:50:37 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8300J8PVQUE4@siemenscomms.co.uk> for sipping@ietf.org; Thu, 02 Nov 2006 13:49:42 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG71MK>; Thu, 02 Nov 2006 13:49:32 +0000 Content-return: allowed Date: Thu, 02 Nov 2006 13:49:31 +0000 From: "Elwell, John" To: Jonathan Rosenberg Message-id: <50B1CBA96870A34799A506B2313F26670A410D28@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sipping Subject: [Sipping] RE: [Sip] New I-D on usage of phone numbers in SIP [DO NOT REPLY! ] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jonathan, Some good stuff in here. > The document proposes a framework and architecture for the usage of > phone numbers with SIP. It tries to answer questions like the > difference > between a tel URI and SIP URI with user=phone, when to use each, what > the meaning of concepts like LNP and freephone are in a > pure-SIP world, > the architectural role of ENUM, and impacts on PSTN interoperability, > and so on. I am not sure about classing a SIP URI as an address. As you say later, the more important meaning of the domain part is as an identifier of the owner of the namespace to which the user part belongs. It says nothing about where this can be found (unless it is in the form of an IP address). It requires a DNS look-up to obtain an address (IP address). Likewise, at least when used as an AoR, the entire SIP URI (including the user part) identifies a resource (a user) and does not say where that resource is to be found. It requires a location server look-up to determine this. So in many respects I think a SIP URI is much more like a name. I could put it on my business card, in the same way I would put a phone number on my business card. However, I do realise that the rest of the document is predicated on this distinction between name and address, so this discrimination is useful even if the terms aren't quite right. Unfortunately I don't have a proposal. John _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 10:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeM2-0004LV-Ii; Thu, 02 Nov 2006 10:19:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeM0-0004LL-LY for sipping@ietf.org; Thu, 02 Nov 2006 10:19:40 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeLy-0003rz-2d for sipping@ietf.org; Thu, 02 Nov 2006 10:19:40 -0500 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Thu, 2 Nov 2006 16:19:30 +0100 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 16:19:29 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Thu, 2 Nov 2006 16:19:29 +0100 Message-Id: in-reply-to: <4549350B.1080905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb+E/n5gHdwKtMPQjKvohBVgoRvEAAdm8UA From: "Huelsemann, Martin" To: , X-OriginalArrivalTime: 02 Nov 2006 15:19:29.0729 (UTC) FILETIME=[4A9F9310:01C6FE92] X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jonathan, all, I don't think that there really is a relationship between presence and = call completion. Presence is about the general availibility of a certain = user, call completion provides the possibility to complete a call to a = certain destination you've got a busy error response from. Because of = this busy indication it is clear that someone in principle can be = reached at that destination, and with call completion this will be = acheived as soon as the destination user hangs up the receiver, of = course depending on your position in the queue. Perhaps there will be = another person at the phone then you wanted to talk to, but at least you = will get an answer. =20 I don't understand the problem with the notification and the race = condition. I thought there would be a seperate BFCP session for each = outstanding call completion request. And so the BFCP server at the = callee could grant the floor for the user at the top of the queue = independently from the other requests. Did I misunderstand this? Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Donnerstag, 2. November 2006 01:00 > An: IETF Sipping List > Betreff: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 >=20 >=20 > This is a very interesting draft. Neat idea to use BFCP to manage the=20 > queue. >=20 > Its not clear to me that this mechanism works well in the face of=20 > forking. Seems like you could end up with disparate queues=20 > for each of=20 > my phones. What you are really after is the state of the user (i.e.,=20 > AOR) and not their devices. This seems to make it problematic to=20 > implement this in the UA at all. I understand your intention is that=20 > this be in a server in the network; but if it only works in=20 > that case it=20 > needs to be called out. >=20 > Similar issues arise when the originating user has multiple=20 > devices. So=20 > if I call you from phone 1, and later you are available, does the=20 > ringback happen only at phone 1 or all of my phones? Seems like the=20 > latter is much more desirable. That too implies that a=20 > UA-based solution=20 > on the originating side has some problems. >=20 > There is clearly a relationship between all of this and presence; I=20 > think you need to call that out. >=20 > On whether BFCP is the right thing or not for this problem, I'm not=20 > sure. In one sense, you could characterize this as really a=20 > problem with=20 > RFC3265 in general; that for certain event packages,=20 > notification of an=20 > event to all watchers can cause them to take actions that result in a=20 > further change to that same state. This is a race condition. >=20 > An alternative way to model the queueing discipline to fix=20 > the race is=20 > through a generic capability in RFC 3265, which sends out=20 > notifications=20 > gradually. You need to be careful to not end up embedding=20 > queue control=20 > commands in SUBSCRIBE as you have pointed out previously. However,=20 > nothing stops a notifier from sending out notifications one=20 > at a time.=20 > That would not permit you to do things like pause your=20 > position in queue=20 > or similar features, but 3265 sometimes feels to be more=20 > on-target for=20 > this service. >=20 > I share John's concerns as to whether this really=20 > interoperates with the=20 > PSTN. Perhaps if you had some call flows demonstrating it,=20 > this would help. >=20 > Thanks, > Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > 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 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 10:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfej9-00085B-6g; Thu, 02 Nov 2006 10:43:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfej7-000851-Ev for sipping@ietf.org; Thu, 02 Nov 2006 10:43:33 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfej2-0007Dw-Rs for sipping@ietf.org; Thu, 02 Nov 2006 10:43:33 -0500 Received: from [172.17.1.79] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kA2FhQ0K059660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Nov 2006 09:43:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <454A1209.50106@nostrum.com> Date: Thu, 02 Nov 2006 09:43:05 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 References: <4549350B.1080905@cisco.com> In-Reply-To: <4549350B.1080905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jonathan Rosenberg wrote: > Its not clear to me that this mechanism works well in the face of > forking. Seems like you could end up with disparate queues for each of > my phones. That's pretty much what I intended, yes. As far as I can tell, the net result -- that is, the behavior of the system -- would end up being identical (or, at least, substantially the same) with queues maintained on each of your devices versus a single, centralized queue -- unless there's more than one of you, in which case neither solution will behave particularly gracefully (although I believe the forking setup has better recovery properties under such circumstances). When I get a spare moment, I'll work through a few scenarios to demonstrate how the externally observed system behavior is the same between distributed management of several queues and centralized management of one queue. > Similar issues arise when the originating user has multiple devices. > So if I call you from phone 1, and later you are available, does the > ringback happen only at phone 1 or all of my phones? Seems like the > latter is much more desirable. That too implies that a UA-based > solution on the originating side has some problems. That depends. Are you asserting this as a new requirement? No one has raised this capability as a requirement so far, and the previously offered solution certainly didn't have this property. To be clear: I agree that this is probably an improvement on the service; however, the more requirements we pile on, the harder a solution becomes -- and we've become experts at putting so many requirements on a problem that the solution space dwindles down to nothing. > There is clearly a relationship between all of this and presence; I > think you need to call that out. Martin beat me to it, but I'll reiterate his comment: the relationship here isn't related as much to presence as it is to dialog state. And that is called out in the discussion about centralized queue management. > On whether BFCP is the right thing or not for this problem, I'm not > sure. In one sense, you could characterize this as really a problem > with RFC3265 in general; that for certain event packages, notification > of an event to all watchers can cause them to take actions that result > in a further change to that same state. This is a race condition. Not in general -- this race condition arises in the draft-poetzl document because it's doing something with SUBSCRIBE that SUBSCRIBE was never meant to do: changing the state of the thing that is watched. Let's go back to first principles: SUBSCRIBE is a request to retrieve the state of a resource, and receive that state whenever it changes. It's a way for an observer to *LOOK* at a state. Now, as I'm always having to tell my kids: you look with your eyes, not with your hands. If the act of subscribing to a state changes that very state, then you're no longer looking -- you're touching. SUBSCRIBE doesn't touch the state it's monitoring. (Now, we have defined some *meta* state regarding the very state of that subscription, but you need to subscribe to that separately, and the act of subscribing to that meta-state doesn't change the meta-state). If you violate the basic principles on which a protocol was developed, then, yes, you end up with protocol characteristics that are highly undesirable. The race condition you describe is one. The objections that I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a service aren't purely academic: if you use a protocol in a way that is well outside its original design, then clearly identifiable bad things happen. > I share John's concerns as to whether this really interoperates with > the PSTN. Perhaps if you had some call flows demonstrating it, this > would help. Martin has put together some pretty nice call flows showing how this interoperates with the PSTN. Perhaps he could be convinced to share them with the wider group? /a _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 13:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhN3-0007bj-8c; Thu, 02 Nov 2006 13:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhN0-0006uf-3e for sipping@ietf.org; Thu, 02 Nov 2006 13:32:54 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfhA7-0007pJ-6i for sipping@ietf.org; Thu, 02 Nov 2006 13:19:39 -0500 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id kA2IJVcx017874; Thu, 2 Nov 2006 18:19:32 GMT Subject: Re: [Sipping] comments on draft-malas-performance-metrics-05 From: Daryl Malas To: Jonathan Rosenberg In-Reply-To: <45492817.6030808@cisco.com> References: <45492817.6030808@cisco.com> Content-Type: text/plain Date: Thu, 02 Nov 2006 11:22:42 -0700 Message-Id: <1162491762.16895.219.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thanks for questions, comments in-line... On Wed, 2006-11-01 at 18:04 -0500, Jonathan Rosenberg wrote: > > Section 3.1.2 says it measures the delay from the register request to a > failure response, yet the figure shows the interval as from REGISTER to > the 200 OK, through the 401. This seems in conflict. This is intended to be an example of a failed REGISTER attempt due to invalid authorization credentials. I could have used a 400, 403, or 423 failure example as described in section 10.3 of 3261, if that makes more sense. The examples of failures is not intended to be exhaustive. I will likely change this to avoid confusion with the first "successful" example. > > Section 3.2 claims that SRD is the same as PDD, but its not. Only the > definition in 3.2.1 could be consider PDD. I use to only include successfully setup calls for SRD, but some suggested the same should be considered for failed calls as well. The thought is related to sending an INVITE and then waiting for any response....even if it is a failure. The result is the same to the user experience of waiting...waiting...waiting...for either "ring-back", an "early-media" automated failure response, or a "re-order" tone. I have debated this one both internal to Level 3 and externally with a number of people. Opinions are appreciated...the debate continues... :-) I'll bring this up in San Diego. > > Section 3.3 - why do you include timeouts here and not in the other > metrics? Hmmm....wish I had a brilliant answer here. I didn't try to make the other failure situations exhaustive to include timeouts, but it seemed to make sense to include this one in this section. I hope that makes sense. I could add them to the others, but I'm just trying to avoid (maybe hopelessly) in describing every failure situation in each metric. > > Section 3.4 - should consider when a BYE comes in the reverse direction I can add this, as it probably makes sense to be described in this section; also, I will be adding sections relative to the UAS, which will also provide examples of this scenario. > > Section 3.5 - this is not the same as ASR. I thought that ASR includes > failure cases which are still a consequence of successfully reaching the > called party, most notably 'busy'. The metric you define is not that > useful as a consequence. So you would need to include specific error > response codes in here. That will not be an easy task. For example do > you include 403? Actually, seizure has to do with "seizing" the media path in a voice call. The difficulty here is deciding exactly when "seizure" takes place. Since, an ACM and 183 w/SDP can indicate media is being sent from the UAS or far-end switch, this could indicate "seizure". However, an ACM and 183 can also be sent without media being cut-through. In either of the previous two examples, media is only uni-directional. In order to avoid a difficult process of parsing ACM's and 183's to determine if media was sent, I think "seizure" should only be considered when media is bi-directionally sent. This only occurs after a 200 OK is sent and/or a ANM in the PSTN world. A busy is consider a REL w/ cause 17...or a 486. This is not considered "seizure". > Section 3.6 - why not other 5xx codes? I used a "commonly" defined set of ISUP codes in determining DPM (Defects per Million) in the PSTN world. I then used RFC 3398 to map those to SIP release values. Due to the 1:n relationship with ISUP:SIP, this resulted in only the 3 SIP releases. I am open to discussing others. > > Section 3.8 - so what values of Reason are included in this? RFC 3326 does not specify any for this condition, so I would suggest this one should be used: Reason: SIP ;cause=BYE ;text="Media Failure" > > Section 3.9 - this definition is vague. How do you know whether the > response comes from the the intended proxy or UA? Good point...this might be more easily described with a 408 or Timer F expiry. > > > Thanks, > Jonathan R. _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 15:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfils-00045n-Qb; Thu, 02 Nov 2006 15:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfilr-00045h-FK for sipping@ietf.org; Thu, 02 Nov 2006 15:02:39 -0500 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfilo-0005t3-1R for sipping@ietf.org; Thu, 02 Nov 2006 15:02:39 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA2K2Q8U010724; Thu, 2 Nov 2006 14:02:30 -0600 (CST) Received: from [135.180.240.247] (volker-hopc2.dnrc.bell-labs.com [135.180.240.247]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA2K2Qk16572; Thu, 2 Nov 2006 15:02:26 -0500 (EST) Message-ID: <454A4ED2.1070405@bell-labs.com> Date: Thu, 02 Nov 2006 15:02:26 -0500 From: Volker Hilt User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sipping] Combined overload control draft References: <453F719D.8020600@bell-labs.com> <4549234A.9000402@cisco.com> In-Reply-To: <4549234A.9000402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: "Malas, Daryl" , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jonathan, thanks for the comments. > Firstly, I think we only want to address the hop-by-hop mechanism. I > don't think we can do the e2e. > I agree!! > Secondly, I don't see a need to report load. I think reporting the load is useful if it is done in *addition* to a throttle value. This is essentially the model three in the draft. Overload control is done via the throttle value, however, the load value provides extra information that helps a proxy to find underutilized servers (e.g. to retarget a request). > I think we are much better > off by specifying a throttle value, and defining a normative algorithm > that gets executed on the upstream server. You have tried to avoid a > normative algorithm. However I think its essential. Knowledge of what > the upstream behavior will be is key to deciding how to transform > knowledge of load into a set of parameters to include in the response. > Much like TCP specifies AIMD on the upstream elements, we need something > like that. > I completely agree that we need to define a normative behavior for the throttle value on the upstream server for exactly the reasons you state. I think the hard part is to find out what works best as throttle value. A percentage value (e.g. reject/redirect 10% of the traffic) is easy to calculate in the downstream server and easy to use in the upstream server. The problem is that the value needs to be constantly adjusted if load varies. For example, if a downstream proxy sets a throttle value of 10% but the load increases by 20%, the downstream proxy will see an increase of 10% instead of a decrease. An alternative is to use an absolute request rate (e.g. 100 requests per second). The problem here is that the algorithm in the downstream entity now has to assign a given request rate to each of its upstream server. Thus, it needs to know its upstream servers and split its processing capacity across them. It needs to re-evaluate this rate as the load varies and upstream servers appear/disappear and needs to avoid the starvation of servers or the assignment of too high capacities. > I like the way you fade out the load estimates. One issue you need to > address is that a client will get lots of load values from the same > downstream server (one in each response). So does it keep the most > recent? How do you define most recent? You need to address that. > True. We may need a timestamp/sequence number. Will add that to the next rev. > I'm not sure I agree with using 503 with upstream elements that don't > support it. This introduces the possibility of making things worse > because of the known problems with 503. I'd prefer a new response code > or something. Another piece of this is whether an element needs to > implement some kind of fairness algorithm so that it doesn't give > disproportionate work to upstream elements which don't throttle. > I'm not sure how a new response code would help elements that don't support the extension since these nodes would probably not understand the new response code as well. Would this be like sending e.g. a 500 for each request? > Thats also the main security consideration you need to address - what if > an upstream element doesn't obey the throttle instructions. > That's true. Need to add that to the next rev. Depending on the throttle value we choose, it might be difficult to find out if the upstream server obeys or not. If a percentage value is used, how does the downstream server know if the upstream server actually follows the throttle instruction? It is easier to do for a fixed rate. Thanks, Volker > Volker Hilt wrote: > >> We have submitted a new overload control draft that combines the two >> existing overload drafts: draft-hilt-sipping-hopbyhop-overload-00 and >> draft-malas-sipping-congestion-header-01. >> >> In addition to combining the existing drafts, the new draft has been >> completely revised to accommodate comments and feedback received and >> it has a new section that discusses design considerations and >> introduces a control model for SIP overload control. >> >> Volker >> >> >> >> ------------------------------------------------------------------------ >> >> Subject: >> I-D ACTION:draft-hilt-sipping-overload-00.txt >> From: >> Internet-Drafts@ietf.org >> Date: >> Tue, 17 Oct 2006 15:50:01 -0400 >> To: >> i-d-announce@ietf.org >> >> To: >> i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Session Initiation Protocol (SIP) Overload Control >> Author(s) : V. Hilt, et al. >> Filename : draft-hilt-sipping-overload-00.txt >> Pages : 23 >> Date : 2006-10-17 >> >> Overload occurs in Session Initiation Protocol (SIP) networks when >> SIP servers have insufficient resources to handle all SIP messages >> they receive. Even though the SIP protocol provides a limited >> overload control mechanism through its 503 response code, SIP servers >> are still vulnerable to overload. This specification defines a new >> SIP overload control mechanism that protects SIP servers against >> overload. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-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-hilt-sipping-overload-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-hilt-sipping-overload-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. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 02 15:25:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfj74-00070d-V8; Thu, 02 Nov 2006 15:24:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfj72-0006zk-Nz for sipping@ietf.org; Thu, 02 Nov 2006 15:24:32 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfj6y-00009P-7f for sipping@ietf.org; Thu, 02 Nov 2006 15:24:32 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA2KOOF14493; Thu, 2 Nov 2006 15:24:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] draft-stucker-sipping-early-media-coping-03 Date: Thu, 2 Nov 2006 14:24:23 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711140F0E8@zrc2hxm2.corp.nortel.com> In-Reply-To: <45492CE2.6090408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-stucker-sipping-early-media-coping-03 Thread-Index: Acb+DTsBilgFlfQvTdu+KoKQ247KLwAqupRg From: "Brian Stucker" To: "Jonathan Rosenberg" , "IETF Sipping List" X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jonathan, Take a look at the sections describing the bad behavior of intermediaries and the (from the perspective of the early media generator) unpredictable behavior of the originating client as to how their media will be treated. I do not agree that gateway is our primary use case. It is a use case, there are others as well. Just because we can interwork SIP with a brick doesn't mean that all the other possible interworking use cases for other UA's must be brick-like as well. Besides, the number of dumb gateways should be decreasing over time in the long run, not increasing. The draft is really discussing three things: 1. The problem with SIP wrt the required behavior of an SDP offerer. The current mechanism is crazy. It's analogous to requiring that because you invited your neighbor over for dinner you have to feed anyone that shows up at your house. Further, they don't have to identify themselves upon entry, and they can eat as much as they like. 2. The problem with SIP wrt what an early media generator as to what they can expect from the SDP offerer. Client/proxy implementations trying to deal with problem #1 (ie. preventing entry of the mob into your home) also have bad effects. They may be let into the house, or ignored, or let in and then kicked back out, etc. From their perspective it can be random as to what happens. They may get treated differently at different times with no indication of what's going on. Further, some of the coping mechanisms in place potentially break other things (like SRTP) or complicate them. 3. The stubs of a few things that might be able to help make items 1 and 2 work better. These are mostly intended as discussion starters and need more feedback and review to see if they can be refined further or if another mechanism should be introduced to solve the problem. The intended (eventual) output of this draft is either one of two things (may be a combination as well, I'm not sure): 1. A set of procedures that fixes early media in SIP where possible. Help the SDP offeror understand who is knocking at the door so they can let in the people they wanted to let in, and keep out or delay the people they don't. 2. A document that explains why early media is fundamentally broken, that we've tried everything, and short of major revisions to SIP it will never work right, what implementations can do to deal with the reprocussions, and to discourage egregiously bad behavior that is likely to break other things in SIP. SIP is complex, and not all of the interactions with various mechanisms and early media are obvious to the reader. Having a document to reference that more explicitly says "you shouldn't do this because you're going to break that" is valuable in and of itself even if there's no change to the protocol. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, November 01, 2006 5:25 PM > To: IETF Sipping List > Subject: [Sipping] draft-stucker-sipping-early-media-coping-03 >=20 > I read this draft, and am pretty confused about what problem=20 > its solving. I was looking for something that pointed out=20 > concrete issues with the existing mechanisms but didnt see that. >=20 > It seems its worried about classifying types of media streams=20 > in terms of importance so a UA knows whether to render them=20 > or not. What I totally fail to understand is how a gateway,=20 > which is really our primary use case for this mess, knows how=20 > to classify the media stream. It won't. For things that can=20 > classify (maybe a SIP-based prepaid server or something),=20 > they'll just mark everything as critical and we're right back=20 > to the issue that I think maybe you're trying to solve. >=20 > -Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 07:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfyXI-0000Rw-Ri; Fri, 03 Nov 2006 07:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfyXH-0000Ol-6j for sipping@ietf.org; Fri, 03 Nov 2006 07:52:39 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfyX8-0005bH-St for sipping@ietf.org; Fri, 03 Nov 2006 07:52:39 -0500 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 3 Nov 2006 13:52:26 +0100 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:52:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Nov 2006 13:52:24 +0100 Message-Id: in-reply-to: <454A1209.50106@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb+ld9KtqwHpSXYSouZ/VlqKtqcfwArUr3g From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 03 Nov 2006 12:52:25.0837 (UTC) FILETIME=[E99641D0:01C6FF46] X-Spam-Score: 1.1 (+) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: adam@nostrum.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, I have drawn two basic flows for a PSTN interworking, available at=20 http://www.softarmor.com/sipping/drafts/Roach%20Call%20Completion%20inter= working.pdf. I think they show an interwoking according to Adams proposal, Adam = please correct me if I'm wrong. The interworking itself seems to be feasible to me, but looking at the = flow where CCBS is invoked in the PSTN, I share Johns concern that the = call completion INVITE (or respectivly the IAM with the call completion = indication) has to be routed exactly via that MGC that has the function = of the BFCP client and that handles that specific GRUU/GRID instance, = and it's not determinstic that this will be the case in the PSTN as far = as I know. It has to be that particular MGC, because only this MGC knows the = GRUU/GRID and could interwork it because of the IAM Calling Party Number = and CCSS indication.=20 So at least from a PSTN point of view there would be an advantage if the = call completion call could be handled independently from a specific = GRUU/GRID, perhaps as a kind of fallback mechanism for an interworking = with networks that don't support GRUU. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Adam Roach [mailto:adam@nostrum.com]=20 > Gesendet: Donnerstag, 2. November 2006 16:43 > An: Jonathan Rosenberg > Cc: IETF Sipping List > Betreff: Re: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 >=20 > Jonathan Rosenberg wrote: > > Its not clear to me that this mechanism works well in the face of=20 > > forking. Seems like you could end up with disparate queues=20 > for each of=20 > > my phones. >=20 > That's pretty much what I intended, yes. As far as I can=20 > tell, the net=20 > result -- that is, the behavior of the system -- would end up being=20 > identical (or, at least, substantially the same) with queues=20 > maintained=20 > on each of your devices versus a single, centralized queue -- unless=20 > there's more than one of you, in which case neither solution=20 > will behave=20 > particularly gracefully (although I believe the forking setup=20 > has better=20 > recovery properties under such circumstances). >=20 > When I get a spare moment, I'll work through a few scenarios to=20 > demonstrate how the externally observed system behavior is the same=20 > between distributed management of several queues and centralized=20 > management of one queue. >=20 > > Similar issues arise when the originating user has multiple=20 > devices.=20 > > So if I call you from phone 1, and later you are available,=20 > does the=20 > > ringback happen only at phone 1 or all of my phones? Seems like the=20 > > latter is much more desirable. That too implies that a UA-based=20 > > solution on the originating side has some problems. >=20 > That depends. Are you asserting this as a new requirement? No one has=20 > raised this capability as a requirement so far, and the previously=20 > offered solution certainly didn't have this property. >=20 > To be clear: I agree that this is probably an improvement on the=20 > service; however, the more requirements we pile on, the harder a=20 > solution becomes -- and we've become experts at putting so many=20 > requirements on a problem that the solution space dwindles=20 > down to nothing. >=20 > > There is clearly a relationship between all of this and presence; I=20 > > think you need to call that out. >=20 > Martin beat me to it, but I'll reiterate his comment: the=20 > relationship=20 > here isn't related as much to presence as it is to dialog state. And=20 > that is called out in the discussion about centralized queue=20 > management. >=20 > > On whether BFCP is the right thing or not for this problem, I'm not=20 > > sure. In one sense, you could characterize this as really a problem=20 > > with RFC3265 in general; that for certain event packages,=20 > notification=20 > > of an event to all watchers can cause them to take actions=20 > that result=20 > > in a further change to that same state. This is a race condition. >=20 > Not in general -- this race condition arises in the draft-poetzl=20 > document because it's doing something with SUBSCRIBE that=20 > SUBSCRIBE was=20 > never meant to do: changing the state of the thing that is watched. >=20 > Let's go back to first principles: SUBSCRIBE is a request to retrieve=20 > the state of a resource, and receive that state whenever it changes.=20 > It's a way for an observer to *LOOK* at a state. >=20 > Now, as I'm always having to tell my kids: you look with your=20 > eyes, not=20 > with your hands. If the act of subscribing to a state changes=20 > that very=20 > state, then you're no longer looking -- you're touching. SUBSCRIBE=20 > doesn't touch the state it's monitoring. (Now, we have defined some=20 > *meta* state regarding the very state of that subscription,=20 > but you need=20 > to subscribe to that separately, and the act of subscribing to that=20 > meta-state doesn't change the meta-state). >=20 > If you violate the basic principles on which a protocol was=20 > developed,=20 > then, yes, you end up with protocol characteristics that are highly=20 > undesirable. The race condition you describe is one. The=20 > objections that=20 > I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a=20 > service aren't purely academic: if you use a protocol in a=20 > way that is=20 > well outside its original design, then clearly identifiable=20 > bad things=20 > happen. >=20 > > I share John's concerns as to whether this really=20 > interoperates with=20 > > the PSTN. Perhaps if you had some call flows demonstrating it, this=20 > > would help. >=20 > Martin has put together some pretty nice call flows showing how this=20 > interoperates with the PSTN. Perhaps he could be convinced to=20 > share them=20 > with the wider group? >=20 > /a >=20 > _______________________________________________ > 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 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 09:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0M6-0003xE-4m; Fri, 03 Nov 2006 09:49:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0M4-0003x9-O1 for sipping@ietf.org; Fri, 03 Nov 2006 09:49:12 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0Lw-0001x1-JQ for sipping@ietf.org; Fri, 03 Nov 2006 09:49:12 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8500G0NT2KRY@siemenscomms.co.uk> for sipping@ietf.org; Fri, 03 Nov 2006 14:47:08 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG7ZM9>; Fri, 03 Nov 2006 14:46:58 +0000 Content-return: allowed Date: Fri, 03 Nov 2006 14:46:56 +0000 From: "Elwell, John" Subject: RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 To: "Huelsemann, Martin" , sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A4623B5@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: adam@nostrum.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Martin, Thanks for preparing these examples. Concerning the point about = managing without GRUU/GRID for call completion calls that come in via a = different MGC, how exactly would this work? By the way, I am not sure if it has already been mentioned in this = context, but GRID is no longer part of GRUU. John=20 > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > Sent: 03 November 2006 12:52 > To: sipping@ietf.org > Cc: adam@nostrum.com > Subject: AW: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 >=20 > Hi, >=20 > I have drawn two basic flows for a PSTN interworking, available at=20 > http://www.softarmor.com/sipping/drafts/Roach%20Call%20Complet > ion%20interworking.pdf. > I think they show an interwoking according to Adams proposal,=20 > Adam please correct me if I'm wrong. >=20 > The interworking itself seems to be feasible to me, but=20 > looking at the flow where CCBS is invoked in the PSTN, I=20 > share Johns concern that the call completion INVITE (or=20 > respectivly the IAM with the call completion indication) has=20 > to be routed exactly via that MGC that has the function of=20 > the BFCP client and that handles that specific GRUU/GRID=20 > instance, and it's not determinstic that this will be the=20 > case in the PSTN as far as I know. > It has to be that particular MGC, because only this MGC knows=20 > the GRUU/GRID and could interwork it because of the IAM=20 > Calling Party Number and CCSS indication.=20 >=20 > So at least from a PSTN point of view there would be an=20 > advantage if the call completion call could be handled=20 > independently from a specific GRUU/GRID, perhaps as a kind of=20 > fallback mechanism for an interworking with networks that=20 > don't support GRUU. >=20 >=20 >=20 > Regards, Martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Adam Roach [mailto:adam@nostrum.com]=20 > > Gesendet: Donnerstag, 2. November 2006 16:43 > > An: Jonathan Rosenberg > > Cc: IETF Sipping List > > Betreff: Re: [Sipping] comments on=20 > > draft-roach-sipping-callcomp-bfcp-00 > >=20 > >=20 > > Jonathan Rosenberg wrote: > > > Its not clear to me that this mechanism works well in the face of = > > > forking. Seems like you could end up with disparate queues=20 > > for each of=20 > > > my phones. > >=20 > > That's pretty much what I intended, yes. As far as I can=20 > > tell, the net=20 > > result -- that is, the behavior of the system -- would end up being = > > identical (or, at least, substantially the same) with queues=20 > > maintained=20 > > on each of your devices versus a single, centralized queue=20 > -- unless=20 > > there's more than one of you, in which case neither solution=20 > > will behave=20 > > particularly gracefully (although I believe the forking setup=20 > > has better=20 > > recovery properties under such circumstances). > >=20 > > When I get a spare moment, I'll work through a few scenarios to=20 > > demonstrate how the externally observed system behavior is the same = > > between distributed management of several queues and centralized=20 > > management of one queue. > >=20 > > > Similar issues arise when the originating user has multiple=20 > > devices.=20 > > > So if I call you from phone 1, and later you are available,=20 > > does the=20 > > > ringback happen only at phone 1 or all of my phones?=20 > Seems like the=20 > > > latter is much more desirable. That too implies that a UA-based=20 > > > solution on the originating side has some problems. > >=20 > > That depends. Are you asserting this as a new requirement?=20 > No one has=20 > > raised this capability as a requirement so far, and the previously=20 > > offered solution certainly didn't have this property. > >=20 > > To be clear: I agree that this is probably an improvement on the=20 > > service; however, the more requirements we pile on, the harder a=20 > > solution becomes -- and we've become experts at putting so many=20 > > requirements on a problem that the solution space dwindles=20 > > down to nothing. > >=20 > > > There is clearly a relationship between all of this and=20 > presence; I=20 > > > think you need to call that out. > >=20 > > Martin beat me to it, but I'll reiterate his comment: the=20 > > relationship=20 > > here isn't related as much to presence as it is to dialog=20 > state. And=20 > > that is called out in the discussion about centralized queue=20 > > management. > >=20 > > > On whether BFCP is the right thing or not for this=20 > problem, I'm not=20 > > > sure. In one sense, you could characterize this as really=20 > a problem=20 > > > with RFC3265 in general; that for certain event packages,=20 > > notification=20 > > > of an event to all watchers can cause them to take actions=20 > > that result=20 > > > in a further change to that same state. This is a race condition. > >=20 > > Not in general -- this race condition arises in the draft-poetzl=20 > > document because it's doing something with SUBSCRIBE that=20 > > SUBSCRIBE was=20 > > never meant to do: changing the state of the thing that is watched. > >=20 > > Let's go back to first principles: SUBSCRIBE is a request=20 > to retrieve=20 > > the state of a resource, and receive that state whenever it=20 > changes.=20 > > It's a way for an observer to *LOOK* at a state. > >=20 > > Now, as I'm always having to tell my kids: you look with your=20 > > eyes, not=20 > > with your hands. If the act of subscribing to a state changes=20 > > that very=20 > > state, then you're no longer looking -- you're touching. SUBSCRIBE=20 > > doesn't touch the state it's monitoring. (Now, we have defined some = > > *meta* state regarding the very state of that subscription,=20 > > but you need=20 > > to subscribe to that separately, and the act of subscribing to that = > > meta-state doesn't change the meta-state). > >=20 > > If you violate the basic principles on which a protocol was=20 > > developed,=20 > > then, yes, you end up with protocol characteristics that are highly = > > undesirable. The race condition you describe is one. The=20 > > objections that=20 > > I have repeatedly raised with the "abuse" of SUBSCRIBE to=20 > activate a=20 > > service aren't purely academic: if you use a protocol in a=20 > > way that is=20 > > well outside its original design, then clearly identifiable=20 > > bad things=20 > > happen. > >=20 > > > I share John's concerns as to whether this really=20 > > interoperates with=20 > > > the PSTN. Perhaps if you had some call flows=20 > demonstrating it, this=20 > > > would help. > >=20 > > Martin has put together some pretty nice call flows showing=20 > how this=20 > > interoperates with the PSTN. Perhaps he could be convinced to=20 > > share them=20 > > with the wider group? > >=20 > > /a > >=20 > > _______________________________________________ > > 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 > >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 10:21:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0pj-0007tl-3s; Fri, 03 Nov 2006 10:19:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0ph-0007tb-EU for sipping@ietf.org; Fri, 03 Nov 2006 10:19:49 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0pd-0006XQ-0m for sipping@ietf.org; Fri, 03 Nov 2006 10:19:49 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA3FJgx10167 for ; Fri, 3 Nov 2006 10:19:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Nov 2006 09:19:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated SIPPING WG document status & WG milestones Thread-Index: Acb/W3wTXTYSbTzTS0CtAZNG5xRLhw== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Sipping] Updated SIPPING WG document status & WG milestones X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi all,=20 I've updated the spreadsheets with the recent reviews: http://www.softarmor.com/sipping/process/review_procedure.html (root directory for reviews) http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html (sorted by Review due date) http://www.softarmor.com/sipping/process/wg-review/sipping-rt-rev-due.ht ml (sorted by revision due date) http://www.softarmor.com/sipping/process/wg-review/sipping-rt-wglc.html (sorted by WGLC dates) http://www.softarmor.com/sipping/process/wg-review/sipping-rt-editor.htm l (sorted by document editor) New documents added: --------------------- We have also started tracking the following individual drafts that have been pending approval as WG documents: - draft-camarillo-sipping-sbc-funcs-05.txt - draft-hasebe-sipping-race-examples-02.txt - draft-rosenberg-sipping-overload-reqs-02 - draft-sawada-sipping-sip-offeranswer-01.txt=20 - draft-gurbani-sipping-ipv6-sip-03.txt Once we have AD approval, those docs will be re-submitted as WG documents and several will be quickly progressed.=20 Docs in WGLC: ------------- We currently do not have any documents undergoing WGLC, however, we only had one person officially review: - draft-ietf-sipping-config-framework-09.txt (WGLC ended on 31 Oct) Additional reviews of this document would be useful. If past reviewers, could at least verify that their original comments and concerns were addressed, that would be very helpful.=20 Docs having completed WGLC: --------------------------- The highlights of the other documents that have recently completed WGLC within the past month are: - draft-ietf-sipping-dialogusage-03.txt (WGLC 11 Sept - 2 Oct)=20 - draft-ietf-sipping-consent-format-00.txt (WGLC 17 Oct - 31 Oct) - draft-ietf-sipping-pending-additions-00.txt (WGLC 17 Oct - 31 Oct) Docs planned for WGLC during the next 6-8 weeks: ------------------------------------------------ - draft-camarillo-sipping-sbc-funcs-05.txt (WGLC 24 Nov - 15 Dec) - draft-ietf-sipping-spam-03 (WGLC 11 Dec - 31 Dec) =20 If you're interested in being an offical reviewer for a particular document, please contact the chairs.For folks that aren't official=20 reviewers, your comments are always welcome and of course, the schedule=20 doesn't preclude discussion or review of other relevant documents at anytime. =20 Feedback on the proposed milestone dates for WGLC and IESG would be appreciated as those will be rolled up into the official WG milestones (pending AD approval), which I've summarized at the end of this email.=20 Regards, Mary SIPPING WG co-chair Updated milestones for SIPPING Working Group: ---------------------------------------------- Done WGLC SIP Service Examples ---New--- Done WGLC IPv6 Transition ---New--- Done WGLC Multiple Dialog Usages ---New--- Done Framework for Realtime Text over IP to IESG as Informational ---New--- Done WGLC Framework for Consent-based Communications in SIP ---New--- Done WGLC XML Format Extension for Capacity Attributes in Resource Lists ---New--- Nov 2006 SIP Service Examples to IESG as Info Done IPv6 Transition in SIP to the IESG as Info Done Service Quality Reporting to IESG as PS Nov 2006 XML Format Extension for Capacity Attributes in Resource Lists to the IESG as PS ---New--- Dec 2006 WGLC Session Border Controller requirements ---New--- Dec 2006 WGLC SPAM problems in SIP ---New--- Jan 2007 WGLC Session Policy package ---New--- Jan 2007 WGLC User Agent Profile for Media Policy ---New--- Jan 2007 Multiple Dialog Usages to IESG as Info ---New--- Feb 2007 WGLC Call Control Framework ---New--- Feb 2007 WGLC SIP Torture Tests for IPv6 ---New--- Feb 2007 Session Border Controller requirements to IESG as Info ---New--- Feb 2007 SPAM problems in SIP to IESG as Info ---New--- Mar 2007 WGLC NAT scenarios ---New--- Mar 2007 Session Policy package to the IESG as PS ---New--- Mar 2007 User Agent Profile for Media Policy to the IESG as PS ---New--- Apr 2007 WGLC Requirements for Management of Overload in SIP ---New--- Apr 2007 WGLC SIP Offer/Answer Examples ---New--- Apr 2007 SIP Call Control - Transfer to IESG as Info ---New--- Apr 2007 Call Control Framework to the IESG as Info ---New--- Apr 2007 SIP Torture Tests for IPv6 to the IESG as Info ---New--- May 2007 WGLC SIP Race Condition Examples ---New--- May 2007 NAT Scenarios to IESG as Info ---New--- June 2007 Requirements for Management of Overload in SIP to IESG as Info ---New--- June 2007 SIP Offer/Answer Examples to IESG as Info ---New--- July 2007 SIP Race Condition Examples to IESG as Info ---New--- Aug 2007 Revise Charter With the following old milestones to be deleted: Nov 2005 Session Policy Requirements to IESG as Info Jan 2006 Session Independent Policy Mechanism to the IESG as PS Jan 2006 Session Specific Policy Mechanism to the IESG as PS Jan 2006 SIP Security Flows to IESG as Info - work is now in SIP WG _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 11:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1mg-000145-Fo; Fri, 03 Nov 2006 11:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1mf-000140-92 for sipping@ietf.org; Fri, 03 Nov 2006 11:20:45 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg1ma-0001lH-Gw for sipping@ietf.org; Fri, 03 Nov 2006 11:20:45 -0500 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 3 Nov 2006 17:20:34 +0100 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 17:20:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Fri, 3 Nov 2006 17:20:32 +0100 Message-Id: in-reply-to: <50B1CBA96870A34799A506B2313F26670A4623B5@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb/WY3d7+xG1oI0TYiT/CwN76ADPwABhjRQ From: "Huelsemann, Martin" To: , X-OriginalArrivalTime: 03 Nov 2006 16:20:33.0723 (UTC) FILETIME=[FCF270B0:01C6FF63] X-Spam-Score: 1.1 (+) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: adam@nostrum.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, it seems that would be a general problem, how to interwork a GRUU to a = network that doesn't support GRUU, and which parameters are available to = reassemble a GRUU at the interworking function. Of course that is a = problem of the 'non-GRUU' network, but I think at least in the PSTN this = problem cannot be solved. So from the PSTN point of view I would suggest a solution that works - = as a alternative or fallback mechanism - with that part of the GRUU that = can be interworked and perhaps with a general call completion indication = for the prioritization. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Freitag, 3. November 2006 15:47 > An: H=FClsemann, Martin; sipping@ietf.org > Cc: adam@nostrum.com > Betreff: RE: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 >=20 > Martin, >=20 > Thanks for preparing these examples. Concerning the point=20 > about managing > without GRUU/GRID for call completion calls that come in via=20 > a different > MGC, how exactly would this work? >=20 > By the way, I am not sure if it has already been mentioned in=20 > this context, > but GRID is no longer part of GRUU. >=20 > John=20 >=20 > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > > Sent: 03 November 2006 12:52 > > To: sipping@ietf.org > > Cc: adam@nostrum.com > > Subject: AW: [Sipping] comments on=20 > > draft-roach-sipping-callcomp-bfcp-00 > >=20 > >=20 > > Hi, > >=20 > > I have drawn two basic flows for a PSTN interworking, available at=20 > > = http://www.softarmor.com/sipping/drafts/Roach%20Call%20Completion%20inter= working.pdf. > > I think they show an interwoking according to Adams proposal,=20 > > Adam please correct me if I'm wrong. > >=20 > > The interworking itself seems to be feasible to me, but=20 > > looking at the flow where CCBS is invoked in the PSTN, I=20 > > share Johns concern that the call completion INVITE (or=20 > > respectivly the IAM with the call completion indication) has=20 > > to be routed exactly via that MGC that has the function of=20 > > the BFCP client and that handles that specific GRUU/GRID=20 > > instance, and it's not determinstic that this will be the=20 > > case in the PSTN as far as I know. > > It has to be that particular MGC, because only this MGC knows=20 > > the GRUU/GRID and could interwork it because of the IAM=20 > > Calling Party Number and CCSS indication.=20 > >=20 > > So at least from a PSTN point of view there would be an=20 > > advantage if the call completion call could be handled=20 > > independently from a specific GRUU/GRID, perhaps as a kind of=20 > > fallback mechanism for an interworking with networks that=20 > > don't support GRUU. > >=20 > >=20 > >=20 > > Regards, Martin > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Adam Roach [mailto:adam@nostrum.com]=20 > > > Gesendet: Donnerstag, 2. November 2006 16:43 > > > An: Jonathan Rosenberg > > > Cc: IETF Sipping List > > > Betreff: Re: [Sipping] comments on=20 > > > draft-roach-sipping-callcomp-bfcp-00 > > >=20 > > >=20 > > > Jonathan Rosenberg wrote: > > > > Its not clear to me that this mechanism works well in=20 > the face of=20 > > > > forking. Seems like you could end up with disparate queues=20 > > > for each of=20 > > > > my phones. > > >=20 > > > That's pretty much what I intended, yes. As far as I can=20 > > > tell, the net=20 > > > result -- that is, the behavior of the system -- would=20 > end up being=20 > > > identical (or, at least, substantially the same) with queues=20 > > > maintained=20 > > > on each of your devices versus a single, centralized queue=20 > > -- unless=20 > > > there's more than one of you, in which case neither solution=20 > > > will behave=20 > > > particularly gracefully (although I believe the forking setup=20 > > > has better=20 > > > recovery properties under such circumstances). > > >=20 > > > When I get a spare moment, I'll work through a few scenarios to=20 > > > demonstrate how the externally observed system behavior=20 > is the same=20 > > > between distributed management of several queues and centralized=20 > > > management of one queue. > > >=20 > > > > Similar issues arise when the originating user has multiple=20 > > > devices.=20 > > > > So if I call you from phone 1, and later you are available,=20 > > > does the=20 > > > > ringback happen only at phone 1 or all of my phones?=20 > > Seems like the=20 > > > > latter is much more desirable. That too implies that a UA-based=20 > > > > solution on the originating side has some problems. > > >=20 > > > That depends. Are you asserting this as a new requirement?=20 > > No one has=20 > > > raised this capability as a requirement so far, and the=20 > previously=20 > > > offered solution certainly didn't have this property. > > >=20 > > > To be clear: I agree that this is probably an improvement on the=20 > > > service; however, the more requirements we pile on, the harder a=20 > > > solution becomes -- and we've become experts at putting so many=20 > > > requirements on a problem that the solution space dwindles=20 > > > down to nothing. > > >=20 > > > > There is clearly a relationship between all of this and=20 > > presence; I=20 > > > > think you need to call that out. > > >=20 > > > Martin beat me to it, but I'll reiterate his comment: the=20 > > > relationship=20 > > > here isn't related as much to presence as it is to dialog=20 > > state. And=20 > > > that is called out in the discussion about centralized queue=20 > > > management. > > >=20 > > > > On whether BFCP is the right thing or not for this=20 > > problem, I'm not=20 > > > > sure. In one sense, you could characterize this as really=20 > > a problem=20 > > > > with RFC3265 in general; that for certain event packages,=20 > > > notification=20 > > > > of an event to all watchers can cause them to take actions=20 > > > that result=20 > > > > in a further change to that same state. This is a race=20 > condition. > > >=20 > > > Not in general -- this race condition arises in the draft-poetzl=20 > > > document because it's doing something with SUBSCRIBE that=20 > > > SUBSCRIBE was=20 > > > never meant to do: changing the state of the thing that=20 > is watched. > > >=20 > > > Let's go back to first principles: SUBSCRIBE is a request=20 > > to retrieve=20 > > > the state of a resource, and receive that state whenever it=20 > > changes.=20 > > > It's a way for an observer to *LOOK* at a state. > > >=20 > > > Now, as I'm always having to tell my kids: you look with your=20 > > > eyes, not=20 > > > with your hands. If the act of subscribing to a state changes=20 > > > that very=20 > > > state, then you're no longer looking -- you're touching.=20 > SUBSCRIBE=20 > > > doesn't touch the state it's monitoring. (Now, we have=20 > defined some=20 > > > *meta* state regarding the very state of that subscription,=20 > > > but you need=20 > > > to subscribe to that separately, and the act of=20 > subscribing to that=20 > > > meta-state doesn't change the meta-state). > > >=20 > > > If you violate the basic principles on which a protocol was=20 > > > developed,=20 > > > then, yes, you end up with protocol characteristics that=20 > are highly=20 > > > undesirable. The race condition you describe is one. The=20 > > > objections that=20 > > > I have repeatedly raised with the "abuse" of SUBSCRIBE to=20 > > activate a=20 > > > service aren't purely academic: if you use a protocol in a=20 > > > way that is=20 > > > well outside its original design, then clearly identifiable=20 > > > bad things=20 > > > happen. > > >=20 > > > > I share John's concerns as to whether this really=20 > > > interoperates with=20 > > > > the PSTN. Perhaps if you had some call flows=20 > > demonstrating it, this=20 > > > > would help. > > >=20 > > > Martin has put together some pretty nice call flows showing=20 > > how this=20 > > > interoperates with the PSTN. Perhaps he could be convinced to=20 > > > share them=20 > > > with the wider group? > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > Sipping mailing list =20 > 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 > > >=20 > >=20 > > _______________________________________________ > > 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 > >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 15:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5rQ-0008Nt-Cd; Fri, 03 Nov 2006 15:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5rP-0008Md-0S for sipping@ietf.org; Fri, 03 Nov 2006 15:41:55 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg5rL-0000KY-LG for sipping@ietf.org; Fri, 03 Nov 2006 15:41:54 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA3KfogI001138; Fri, 3 Nov 2006 14:41:50 -0600 (CST) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.4]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Nov 2006 14:41:50 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sipping] Updated overload requirements draft Date: Fri, 3 Nov 2006 14:41:48 -0600 Message-ID: <9F1D84BDF02A2B41B030921EB090861878BB83@ILEXC1U01.ndc.lucent.com> In-Reply-To: <453B83D8.9060200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Updated overload requirements draft Thread-Index: Acb16UhqnH9BY1kdRgmA4ExOQHYjygJlK/Ug From: "Widjaja, Indra \(Indra\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 03 Nov 2006 20:41:50.0118 (UTC) FILETIME=[7CCE7C60:01C6FF88] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi: I have the following questions in the simulation model section. 1) A sentence on page 14 states: "Similarly, messages sent from the home proxy to the edge proxies are distributed uniformly amongst them."=20 Does this imply that we're not using the destination of a message to explicitly route the message to the edge proxy? Also, are we restricting the simulation model to uniform traffic pattern only? 2) Section 6.2 adopts a model where different transactions are assumed to be independent, which on one hand seems desirable because of its simplicity. On the other hand, it's not clear what the precise effect of this assumption is on the actual performance. 3) Should the metrics for comparison purposes be added? Regards, Indra -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Sunday, October 22, 2006 10:45 AM To: IETF Sipping List Subject: [Sipping] Updated overload requirements draft I've submitted an update to the overload requirements document. Until it appears in the archives, you can pick it up here: http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-02.t xt The main change is that I've added a network simulation model, including a network model, proxy processing model, and traffic and simulation=20 parameters. This model has been requested at the last few meetings. It=20 serves several purposes: 1. to allow experts from the congestion control community to understand=20 the problem and help recommend and model solutions 2. to allow for a baseline model to use in comparing proposed solutions Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 17:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7yG-0007cz-Pq; Fri, 03 Nov 2006 17:57:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7yE-0007al-G2 for sipping@ietf.org; Fri, 03 Nov 2006 17:57:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7y8-0005oN-2p for sipping@ietf.org; Fri, 03 Nov 2006 17:57:06 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2006 14:56:59 -0800 X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="339303679:sNHT53907104" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3Muxg8008016; Fri, 3 Nov 2006 14:56:59 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA3MuabF026155; Fri, 3 Nov 2006 14:56:44 -0800 (PST) From: "Dan Wing" To: "'Brian Stucker'" , "'Jonathan Rosenberg'" , "'IETF Sipping List'" Subject: RE: [Sipping] draft-stucker-sipping-early-media-coping-03 Date: Fri, 3 Nov 2006 14:56:28 -0800 Message-ID: <0a1e01c6ff9b$5add8ac0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb+DTsBilgFlfQvTdu+KoKQ247KLwAqupRgADiZOvA= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711140F0E8@zrc2hxm2.corp.nortel.com> DKIM-Signature: a=rsa-sha1; q=dns; l=3441; t=1162594619; x=1163458619; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Sipping]=20draft-stucker-sipping-early-media-coping-03; X=v=3Dcisco.com=3B=20h=3DCTJzZkT4x7i6+wqvV7QREE9Bqoc=3D; b=p8xI3kW1U9jgfK7vrLIzHiLimcJpijbubTOmINMN4zsHaJGs00aJJEB4juBrq74p8JmC8oxR 1PJPcICvyjPU6ulYrvdrMxnRcAPQQP9+s3dFGBIiXu65OMRWRZfOqp3k; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brian Stucker wrote: ... > The intended (eventual) output of this draft is either one of > two things (may be a combination as well, I'm not sure): > > 1. A set of procedures that fixes early media in SIP where possible. > Help the SDP offeror understand who is knocking at the door > so they can let in the people they wanted to let in, and keep > out or delay the people they don't. ICE seems useful for that -- the offerer can avoid playing out any RTP packets until either (a) an SDP answer is received, and the RTP media is arriving from the transport address in the SDP answer, or (b) the offerer receives a STUN Binding Request, with the STUN username in its offer. This is very similar to the technique in draft-wing-session-auth-00.txt (which is now expired and available from http://tools.ietf.org/internet-drafts/draft-wing-session-auth-00.txt) -d > 2. A document that explains why early media is fundamentally broken, > that we've tried everything, and short of major revisions to SIP > it will never work right, what implementations can do to deal > with the reprocussions, and to discourage egregiously bad > behavior that is likely to break other things in SIP. SIP is > complex, and not all of the interactions with various mechanisms > and early media are obvious to the reader. Having a document to > reference that more explicitly says "you shouldn't do this > because you're going to break that" is valuable in and of itself > even if there's no change to the protocol. > > > Regards, > Brian > > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Wednesday, November 01, 2006 5:25 PM > > To: IETF Sipping List > > Subject: [Sipping] draft-stucker-sipping-early-media-coping-03 > > > > I read this draft, and am pretty confused about what problem > > its solving. I was looking for something that pointed out > > concrete issues with the existing mechanisms but didnt see that. > > > > It seems its worried about classifying types of media streams > > in terms of importance so a UA knows whether to render them > > or not. What I totally fail to understand is how a gateway, > > which is really our primary use case for this mess, knows how > > to classify the media stream. It won't. For things that can > > classify (maybe a SIP-based prepaid server or something), > > they'll just mark everything as critical and we're right back > > to the issue that I think maybe you're trying to solve. > > > > -Jonathan R. > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 19:56:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg9o9-00029I-1C; Fri, 03 Nov 2006 19:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg9o7-00025b-E5 for sipping@ietf.org; Fri, 03 Nov 2006 19:54:47 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg9o5-0006uZ-Ut for sipping@ietf.org; Fri, 03 Nov 2006 19:54:47 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA40sDm20146; Fri, 3 Nov 2006 19:54:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Sipping] RE: RE: WGLC of draft-ietf-sipping-service-examples-10.txt Date: Fri, 3 Nov 2006 18:53:57 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C1FA@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A410637@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] RE: RE: WGLC of draft-ietf-sipping-service-examples-10.txt Thread-Index: Acb90p+sdg0ScK68S/Kx3rIpsxHg3wB2NzbQ From: "Samir Srivastava" To: "Elwell, John" , "sipping" , "Alan Johnston" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Gonzalo Camarillo , Mary Barnes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org A general comment (version 11 also), when SIPS itself is debatable, why = to put SIPS uri in the call flows. Thx Samir > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, November 01, 2006 8:23 AM > To: sipping; Alan Johnston > Cc: Gonzalo Camarillo; Barnes, Mary (RICH2:AR00) > Subject: [Sipping] RE: RE: WGLC of = draft-ietf-sipping-service-examples- > 10.txt >=20 > Comments I submitted during WGLC on version 10 have been fixed in = version > 11 > with the exception of those points highlighted below. >=20 > John >=20 > > -----Original Message----- > > From: Elwell, John > > Sent: 23 June 2006 11:30 > > To: 'Gonzalo Camarillo'; 'sipping' > > Cc: 'Samuli P=F6ykk=F6'; 'mary.barnes@nortel.com'; 'Alan > > Johnston'; 'Robert Sparks'; 'kevin.summers@sonusnet.com' > > Subject: RE: WGLC of draft-ietf-sipping-service-examples-10.txt > > > > My comments resulting from review of assigned sections (2.3, > > 2.18, 2.19): > > > > Section 1: "and will help further the goal of a standard > > implementation of RFC 3261 [2]". Add "... and some of its = extensions". > > > > Section 1: "Other RFCs also comprise the SIP standard and are > > used and references in these call flows.". Change to "Other > > RFCs also form part of the SIP standard and are used and > > referenced in these call flows." > [JRE] Still need to change "used and references" to "used and = referenced". >=20 > > > > Section 1: "Some examples make use the GRUU". Change to "Some > > examples make use of the GRUU". > > > > Section 1: "The use of Secure SIP URIs (sips) is shown > > throughout this document with assumed certificate validation > > for security. However, other security approaches such as > > Digest challenges can be used." I have a problem with this > > statement, since it seems to assume that SIPS and Digest > > challenges are mutually interchangeable. They are not, and > > the use of TLS transport in conjunction with Digest > > authentication is a likely scenario, particularly between a > > UA and its outbound proxy, where only TLS server > > authentication is likely to be available. I would propose > > "The use of Secure SIP URIs (sips) is shown throughout this > > document, implying TLS transport on each hop with assumed > > certificate validation. However, other security approaches > > can be used. Also the used of Digest authentication is shown > > in some examples." > > > > Section 2.3: "off of hold". Change to "off hold". > > > > Section 2.3: "Note that if Alice responds to the INVITE with > > hold SDP in the 200 OK, this call flow will not work > > properly.". I don't understand what this means. Greater > > explanation is required. In particular which INVITE > > (presumably F7), and what is meant by "hold SDP" here - = a=3Dinactive? > > > > Section 2.3 F1: "Call-ID: 12345600@atlanta.example.com". For > > global uniqueness, would "Call-ID: > > 12345600@client.atlanta.example.com" be better. This would > > impact the other flows too. > [JRE] This has not been addressed. Any particular reason? >=20 > > > > Section 2.3 F1: "Contact: " > > and "c=3DIN IP4 music.server.example.com". I would normally > > expect the host part of the contact URI to be the same as the > > host in the SDP c=3D line, although of course it doesn't need to be. > [JRE] My mistake, the comment referred to F6, not F1. So the comment = has > not > been addressed. >=20 > > > > Section 2.3 F8: ";received=3D192.0.2.103". This is the same IP > > address as used by Bob in F2, for example. Likewise F14. > > > > Section 2.18 "A is alerted". Change to "Alice is alerted". > > > > Section 2.18 F2 "To: Bob > > ;tag=3D982039i4". A 486 response > > is not dialog-forming, so I am not sure why it contains a To > > tag. However, I can't find anything in RFC 3261 that > > clarifies this. If the To tag is removed, this will also impact F3. > [JRE] This comment has not been addressed. Note that it now applies to = F2 > and F3 in section 2.17. >=20 > > > > Section 2.18 F5: This is missing an Expires header. > > > > Section 2.18 F6 "NOTIFY sips:alice@atlanta.example.com > > SIP/2.0". Change to "NOTIFY > > sips:alice@atlanta.client.example.com SIP/2.0" > > > > Section 2.18 F6: This is missing a Contact header. > [JRE] Still not quite correct. Change "biloxi.com" to > "biloxi.example.com". > This now applies to F6 in section 2.17. >=20 > > > > Section 2.18 F8: "Subscription-State: active;expires=3D3600". > > The value of 3600 for the expires parameter is not very > > realistic - it has not decreased since the initial NOTIFY request. > [JRE] This has been fixed in a different way, which I don't = understand. > Why > would Bob's UA terminate the subscription to the dialog event package = when > it sends the NOTIFY request F8? Bob's UA does not know for what = purposes > Alice's UA has subscribed to this package. Note that if it is decided = that > this is correct, we at least need to change "terminiated" to = "terminated". >=20 > > > > Section 2.18. It does not show Alice cancelling the > > subscription - not essential but likely. > [JRE] As per my comment above, I don't believe Bob's UA is in a = position > to > know that the subscription has to be terminated when it sends a NOTIFY > request. Therefore I still believe Alice's UA needs to send a = SUBSCRIBE to > cancel the subscription. >=20 > > > > Section 2.18 F10: "o=3Dalice 2890844526 2890844526 IN IP4 > > client.atlanta.example.com". The session ID and version are > > the same as in F1, but this is a new session request. > > > > Section 2.19 "Note that Bob's SIP phone immediately > > terminates the dialog by indicating in the NOTIFY (F3) that > > the subscription is terminated.". Although legitimate, this > > is not typical behaviour. > > > > Section 2.19 F1: "Call-ID: 12345601@atlanta.example.com". > > This is a curious choice of Call-ID, since the call is > > initiated by Bob@biloxy.com. This will impact subsequent > > flows too. Similar comment on F5. > > > > Section 2.19 F1: "Contact: > > ". Similarly this seems > > wrong. Presumably it should be the value in the Request-URI of F3. > [JRE] This has not been addressed. Since the former F3 has now gone, = we > can't copy the URI from there. Even though a dialog will not be formed = for > the suscription, we still need the Contact header field in the = request, > since support for no-refer-sub at Bob is not know at this stage. I = would > propose . >=20 > > > > Section 2.19 F3: "Content-Type: message/sipfrag" - no body is > > shown, and I don't think there should be a body. > > > > Section 2.19 F4: ";received=3D192.0.2.113". This is the same as > > in F2 - should be different. Similar comment on F6/F7. > > > > John > > > > > > > > >=20 > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCU-0007ad-Ka; Fri, 03 Nov 2006 21:24:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCS-0007Zu-QO for sipping@ietf.org; Fri, 03 Nov 2006 21:24:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCP-0003EQ-Fp for sipping@ietf.org; Fri, 03 Nov 2006 21:24:00 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 18:23:57 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJKIS0WrR7PDh2dsb2JhbACMSwEBAQgOKg X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="350001285:sNHT25698404" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42Nu0e031047 for ; Fri, 3 Nov 2006 18:23:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42Nuin015093 for ; Fri, 3 Nov 2006 18:23:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:23:56 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:23:56 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping , Jonathan Rosenberg From: Cullen Jennings Date: Fri, 3 Nov 2006 18:23:59 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:23:56.0402 (UTC) FILETIME=[476CDD20:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=645; t=1162607036; x=1163471036; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-rosenberg-sipping-overload-reqs=20recovery; X=v=3Dcisco.com=3B=20h=3Dw6rbjCKbBN1PtvIFNF35HLuwXoQ=3D; b=Jh8W4KK/sk+3jXkv+56OdIalKrT1T+Rh14Tq5OBvvzTrIeG+6Qk4B2Yg4xNl1PjUL+afoC4r TXYD5AJ1LBN8BfDuJC5py2Db0YD3RS8IxjGrDt/utVqdGrO6eexgrj+K; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org A possible additional requirement.... Imagine a system (perhaps a single proxy) that could do 100cps. It is in steady state doing 80cps with very few retransmission. Then for 5 minutes the incoming requests goes to 500cps then drops back to an incoming call rate of 80cps. The question is, how long before the system gets back to the state where it if is successfully processing all the 80cps? I have seen systems that never recover - that is bad. I think one of the design goals is that it is at least possible to build to systems that recover back to steady state relatively quickly after an overload impulse. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCp-0008Gn-0w; Fri, 03 Nov 2006 21:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCn-0008CA-9X for sipping@ietf.org; Fri, 03 Nov 2006 21:24:21 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCj-0003FG-VC for sipping@ietf.org; Fri, 03 Nov 2006 21:24:21 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 18:24:18 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754548702:sNHT48289704" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42OHf5002090 for ; Fri, 3 Nov 2006 18:24:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA42OEAq008628 for ; Fri, 3 Nov 2006 18:24:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:17 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:17 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping From: Cullen Jennings Date: Fri, 3 Nov 2006 18:24:20 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:24:17.0059 (UTC) FILETIME=[53BCDF30:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1291; t=1162607057; x=1163471057; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-stucker-sipping-early-media-coping=20; X=v=3Dcisco.com=3B=20h=3DQD1EVo+lrnGeHoyL7W0kKhQXLNk=3D; b=d9Jv8Q9bWo1w+22Me1TQWsEiIUfvE0Sh69A7BTy3wECMLPHl8FedM2YeyrLvtWzOfdtHVElX Fj7nEDKiZ5/PRhBwx2Cz+1Gf/NV5oXik+uhP5cJSDtVk5QP8TylkdWiP; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sipping] draft-stucker-sipping-early-media-coping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I have to admit there were many parts of this that left me somewhat lost on what the problem was or how it was solved. There were also some things that left me really surprised if many people use them .... For example - you very correctly point out that the Alert-Info header can only be used where the source of the header is trusted - however, I can't imagine any case where this was true and the Alter-Info header was useful and suspect that mostly it was not used - or that at least where it was used there was huge security holes. You talk about proxy sdp stripping being a "a very common mechanism" - this surprised me so I might just be misunderstanding what you are saying. If this is done, I don't see how early media works and if early media does not work I don't see how phoning things that need it work. I thought that every non trivial deployment did early media. Anyways ... I don't think I would take any of these comments too seriously other than the meta point that I probably don't understand the draft and that it probably needs mmuisc and avt review more than sip. Also, have you looked at the application interaction framework stuff for doing things like inserting media announcements at the beginning of a call. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCc-0007g6-BU; Fri, 03 Nov 2006 21:24:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCa-0007g1-Mv for sipping@ietf.org; Fri, 03 Nov 2006 21:24:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCX-0003Ek-D1 for sipping@ietf.org; Fri, 03 Nov 2006 21:24:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2006 18:24:04 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEmGS0WrR7PEh2dsb2JhbACMSwEBAQgOKg X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="447997936:sNHT24416572" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42O4Pg010017 for ; Fri, 3 Nov 2006 18:24:04 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42O4in015170 for ; Fri, 3 Nov 2006 18:24:04 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:04 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:04 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <665715C9-4CAA-4B16-A4E7-BEC03289F737@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sipping From: Cullen Jennings Date: Fri, 3 Nov 2006 18:24:07 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:24:04.0402 (UTC) FILETIME=[4C319120:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=74; t=1162607044; x=1163471044; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-malas-performance-metrics=20-=20speermint?; X=v=3Dcisco.com=3B=20h=3DWsOdRGcOc/Sx06BomwCcv15c9LI=3D; b=TKIb0Lr+k2IKhL6FWFHZO2Ak4p9c6sdD9RskEr3kwY/q+MbgUyIOXgT+j2mLzC/Knu4wt8ai 2YsFArsdQTANo5p78ElvkVsImiRsuBXlAoUPN+2d8k9jy7gnvlaxjbeZ; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Sipping] draft-malas-performance-metrics - speermint? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I wonder if this draft might be better in spearmint? Just a thought... _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCU-0007ad-Ka; Fri, 03 Nov 2006 21:24:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCS-0007Zu-QO for sipping@ietf.org; Fri, 03 Nov 2006 21:24:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCP-0003EQ-Fp for sipping@ietf.org; Fri, 03 Nov 2006 21:24:00 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2006 18:23:57 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJKIS0WrR7PDh2dsb2JhbACMSwEBAQgOKg X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="350001285:sNHT25698404" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42Nu0e031047 for ; Fri, 3 Nov 2006 18:23:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42Nuin015093 for ; Fri, 3 Nov 2006 18:23:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:23:56 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:23:56 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping , Jonathan Rosenberg From: Cullen Jennings Date: Fri, 3 Nov 2006 18:23:59 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:23:56.0402 (UTC) FILETIME=[476CDD20:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=645; t=1162607036; x=1163471036; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-rosenberg-sipping-overload-reqs=20recovery; X=v=3Dcisco.com=3B=20h=3Dw6rbjCKbBN1PtvIFNF35HLuwXoQ=3D; b=Jh8W4KK/sk+3jXkv+56OdIalKrT1T+Rh14Tq5OBvvzTrIeG+6Qk4B2Yg4xNl1PjUL+afoC4r TXYD5AJ1LBN8BfDuJC5py2Db0YD3RS8IxjGrDt/utVqdGrO6eexgrj+K; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org A possible additional requirement.... Imagine a system (perhaps a single proxy) that could do 100cps. It is in steady state doing 80cps with very few retransmission. Then for 5 minutes the incoming requests goes to 500cps then drops back to an incoming call rate of 80cps. The question is, how long before the system gets back to the state where it if is successfully processing all the 80cps? I have seen systems that never recover - that is bad. I think one of the design goals is that it is at least possible to build to systems that recover back to steady state relatively quickly after an overload impulse. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCp-0008Gn-0w; Fri, 03 Nov 2006 21:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCn-0008CA-9X for sipping@ietf.org; Fri, 03 Nov 2006 21:24:21 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCj-0003FG-VC for sipping@ietf.org; Fri, 03 Nov 2006 21:24:21 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2006 18:24:18 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754548702:sNHT48289704" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42OHf5002090 for ; Fri, 3 Nov 2006 18:24:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA42OEAq008628 for ; Fri, 3 Nov 2006 18:24:17 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:17 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:17 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping From: Cullen Jennings Date: Fri, 3 Nov 2006 18:24:20 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:24:17.0059 (UTC) FILETIME=[53BCDF30:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=1291; t=1162607057; x=1163471057; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-stucker-sipping-early-media-coping=20; X=v=3Dcisco.com=3B=20h=3DQD1EVo+lrnGeHoyL7W0kKhQXLNk=3D; b=d9Jv8Q9bWo1w+22Me1TQWsEiIUfvE0Sh69A7BTy3wECMLPHl8FedM2YeyrLvtWzOfdtHVElX Fj7nEDKiZ5/PRhBwx2Cz+1Gf/NV5oXik+uhP5cJSDtVk5QP8TylkdWiP; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sipping] draft-stucker-sipping-early-media-coping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I have to admit there were many parts of this that left me somewhat lost on what the problem was or how it was solved. There were also some things that left me really surprised if many people use them .... For example - you very correctly point out that the Alert-Info header can only be used where the source of the header is trusted - however, I can't imagine any case where this was true and the Alter-Info header was useful and suspect that mostly it was not used - or that at least where it was used there was huge security holes. You talk about proxy sdp stripping being a "a very common mechanism" - this surprised me so I might just be misunderstanding what you are saying. If this is done, I don't see how early media works and if early media does not work I don't see how phoning things that need it work. I thought that every non trivial deployment did early media. Anyways ... I don't think I would take any of these comments too seriously other than the meta point that I probably don't understand the draft and that it probably needs mmuisc and avt review more than sip. Also, have you looked at the application interaction framework stuff for doing things like inserting media announcements at the beginning of a call. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCc-0007g6-BU; Fri, 03 Nov 2006 21:24:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCa-0007g1-Mv for sipping@ietf.org; Fri, 03 Nov 2006 21:24:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCX-0003Ek-D1 for sipping@ietf.org; Fri, 03 Nov 2006 21:24:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2006 18:24:04 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEmGS0WrR7PEh2dsb2JhbACMSwEBAQgOKg X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="447997936:sNHT24416572" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42O4Pg010017 for ; Fri, 3 Nov 2006 18:24:04 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA42O4in015170 for ; Fri, 3 Nov 2006 18:24:04 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:04 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:04 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <665715C9-4CAA-4B16-A4E7-BEC03289F737@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sipping From: Cullen Jennings Date: Fri, 3 Nov 2006 18:24:07 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:24:04.0402 (UTC) FILETIME=[4C319120:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=74; t=1162607044; x=1163471044; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-malas-performance-metrics=20-=20speermint?; X=v=3Dcisco.com=3B=20h=3DWsOdRGcOc/Sx06BomwCcv15c9LI=3D; b=TKIb0Lr+k2IKhL6FWFHZO2Ak4p9c6sdD9RskEr3kwY/q+MbgUyIOXgT+j2mLzC/Knu4wt8ai 2YsFArsdQTANo5p78ElvkVsImiRsuBXlAoUPN+2d8k9jy7gnvlaxjbeZ; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Sipping] draft-malas-performance-metrics - speermint? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I wonder if this draft might be better in spearmint? Just a thought... _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 21:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCu-0008Ki-QA; Fri, 03 Nov 2006 21:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgBCt-0008Hq-2W for sipping@ietf.org; Fri, 03 Nov 2006 21:24:27 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgBCq-0003J3-PF for sipping@ietf.org; Fri, 03 Nov 2006 21:24:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2006 18:24:24 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="85358588:sNHT52252722" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA42OORI014195; Fri, 3 Nov 2006 18:24:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA42OOW4020833; Fri, 3 Nov 2006 18:24:24 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Nov 2006 18:24:23 -0800 Received: from [171.69.133.212] ([171.69.133.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 18:24:23 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <13BB01FB-508D-40D6-82E1-20471EE6AEA5@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping , Adam Roach From: Cullen Jennings Date: Fri, 3 Nov 2006 18:24:27 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Nov 2006 02:24:23.0621 (UTC) FILETIME=[57A62750:01C6FFB8] DKIM-Signature: a=rsa-sha1; q=dns; l=605; t=1162607064; x=1163471064; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-roach-sipping-callcomp-bfcp; X=v=3Dcisco.com=3B=20h=3DQf9c1j13XRwG+9YR8IwSfrczqfo=3D; b=H8BwtIxYEJW7YUt6zYatmc6N6c6qQpUYmbMp1kxLcrIqZxZgPzs6y53qQVR8JXa/zfNsmNOl jYcW4hUBgjcEBd5MnS0mMGgqqoUAOeCom8bq2c+AKXVjGIha1SeAG4wC; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Sipping] draft-roach-sipping-callcomp-bfcp X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I like this - this queue management technique could be very interesting in call center applications beyond just the stuff here. One use case that seemed a little weak was around imagine I have a desk phone, mobile phone, and voice mail and my calls fork to all of them. You call me while I am talking on my desk phone. I hang up my desk phone to and start to walk out of the office. What I want to have happen is for both my desk and mobile phone to ring so I can answer either. Seems like you should be able to make this work with a bit of presence or dialog package magic. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 03 22:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgC3e-0005lT-26; Fri, 03 Nov 2006 22:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgC3b-0005kA-LU for sipping@ietf.org; Fri, 03 Nov 2006 22:18:55 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgC3Z-0005GB-CZ for sipping@ietf.org; Fri, 03 Nov 2006 22:18:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2006 22:18:53 -0500 X-IronPort-AV: i="4.09,387,1157342400"; d="scan'208"; a="108699659:sNHT48472168" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA43IrJO000821 for ; Fri, 3 Nov 2006 22:18:53 -0500 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 kA43IrDM005585 for ; Fri, 3 Nov 2006 22:18:53 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 22:18:52 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 22:18:52 -0500 Message-ID: <454C069C.6010500@cisco.com> Date: Fri, 03 Nov 2006 22:18:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cullen Jennings Subject: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> In-Reply-To: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2006 03:18:52.0763 (UTC) FILETIME=[F435A2B0:01C6FFBF] DKIM-Signature: a=rsa-sha1; q=dns; l=1128; t=1162610333; x=1163474333; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Utility=20of=20Alert-Info=20(was=3A=20Re=3A=20[Sipping]=20draft-stucker- sipping-early-media-coping) |To:Cullen=20Jennings=20; X=v=3Dcisco.com=3B=20h=3DE/nk98sSVdpdPLjIpzav02KhEmg=3D; b=PC4Pip6U7heLe1ASClroKdIsPlca97APc8/bM9XsgZyv3uTX+5DwE1XFdI2pPg9cRjZ9gdzm 4/GLtY8wIyghx2GxidT9qpjvJt1TAh7/visExpJrYF9pV2kVOuqAem1S; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Cullen Jennings wrote: > For example - you very correctly point out that the Alert-Info header > can only be used where the source of the header is trusted - however, I > can't imagine any case where this was true and the Alter-Info header was > useful and suspect that mostly it was not used - or that at least where > it was used there was huge security holes. I have been party to discussions of a use that seems to be safe and useful: The Alert-Info only goes between the UA and a proxy that acts on its behalf. The proxy strips any Alert-Info headers coming to it in the direction of the UA. Then the proxy may insert an Alert-Info header. The decision of what to insert may be based on black lists, white lists, or any sort of feature logic the proxy may choose to carry out. An advantage of this is that all the data and logic for making the decisions can be centralized for multiple UAs. The UAs themselves only need to know how to handle Alert-Info. This requires that messages only reach the UA via the proxy, but we know of many environments where that is the case. Paul _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 04 00:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDyJ-0002Ua-5t; Sat, 04 Nov 2006 00:21:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDyH-0002UV-PV for sipping@ietf.org; Sat, 04 Nov 2006 00:21:33 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDyG-00049p-H2 for sipping@ietf.org; Sat, 04 Nov 2006 00:21:33 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA45LT704090; Sat, 4 Nov 2006 00:21:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Fri, 3 Nov 2006 23:21:31 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F74C26A@zrc2hxm2.corp.nortel.com> In-Reply-To: <454C069C.6010500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: Acb/wJGV9KVYBSupQwSI8Kd9bU2R9gADiWpg From: "Samir Srivastava" To: "Paul Kyzivat" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org IMHO, Alert-Info is big incentive for SPAMMERS. White listing does suffer from the big problem of introduction.=20 3261 underspecifies the Alert-Info, If it comes to Proxy responsible for UAS in the INVITE, what it will do ? I may be missing something. Thx Samir =20 >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: Friday, November 03, 2006 7:19 PM >To: Cullen Jennings >Cc: sipping >Subject: Utility of Alert-Info (was: Re: [Sipping]=20 >draft-stucker-sipping-early-media-coping) > > > >Cullen Jennings wrote: > >> For example - you very correctly point out that the=20 >Alert-Info header=20 >> can only be used where the source of the header is trusted -=20 >however,=20 >> I can't imagine any case where this was true and the=20 >Alter-Info header=20 >> was useful and suspect that mostly it was not used - or that=20 >at least=20 >> where it was used there was huge security holes. > >I have been party to discussions of a use that seems to be=20 >safe and useful: > >The Alert-Info only goes between the UA and a proxy that acts=20 >on its behalf. The proxy strips any Alert-Info headers coming=20 >to it in the direction of the UA. Then the proxy may insert an=20 >Alert-Info header. The decision of what to insert may be based=20 >on black lists, white lists, or any sort of feature logic the=20 >proxy may choose to carry out. > >An advantage of this is that all the data and logic for making=20 >the decisions can be centralized for multiple UAs. The UAs=20 >themselves only need to know how to handle Alert-Info. > >This requires that messages only reach the UA via the proxy,=20 >but we know of many environments where that is the case. > > Paul > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sip@ietf.org for new developments of core SIP > _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 04 15:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgSAz-0005Lb-AR; Sat, 04 Nov 2006 15:31:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgSAx-0005K0-OK for sipping@ietf.org; Sat, 04 Nov 2006 15:31:35 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgSAw-0000hv-D4 for sipping@ietf.org; Sat, 04 Nov 2006 15:31:35 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Nov 2006 12:31:34 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMaFTEVAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.09,388,1157353200"; d="scan'208"; a="47865595:sNHT27922576" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA4KVXK6007359; Sat, 4 Nov 2006 15:31:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA4KVXYJ019764; Sat, 4 Nov 2006 15:31:33 -0500 (EST) 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.1830); Sat, 4 Nov 2006 15:31:33 -0500 Received: from [10.86.242.55] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Nov 2006 15:31:33 -0500 Message-ID: <454CF8A4.50802@cisco.com> Date: Sat, 04 Nov 2006 15:31:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <62B9B0847CC47543B6B3B5E26BD268E60F74C26A@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F74C26A@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2006 20:31:33.0099 (UTC) FILETIME=[37729BB0:01C70050] DKIM-Signature: a=rsa-sha1; q=dns; l=3354; t=1162672294; x=1163536294; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=20[Sipping]=09draft- stucker-sipping-early-media-coping) |To:Samir=20Srivastava=20; X=v=3Dcisco.com=3B=20h=3DEznzXFZQhtZUeHYSqv1syHt5RL0=3D; b=Av8NS3KZ0amnbETwI2XQnKSCtww8i1xzIHMyrQY5Mz70tb1BpHEXbb2PcRo9DfEi4vXbOLpc VE03GMc2poS1K6LWyvOgX/Ria/tD6fpi/9MCiwBBV2qIHXEE8CVx/ff9; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Samir Srivastava wrote: > IMHO, Alert-Info is big incentive for SPAMMERS. White listing does > suffer from the big problem of introduction. Alert-Info indeed could easily be abused if its use is not carefully controlled. If the UAS renders anything that is included by the UAC then almost anything could happen. OTOH, if the UAS knows that the usage of the Alert-Info will be policed by a proxy on its behalf then it can be more trusting in honoring an Alert-Info that reaches it. (Another way to achieve safety would be for the UAS to only honor a fixed set of URIs in the Alert-Info header. Then the only thing a caller could do would be to choose among alternatives. This would at least be "safe". But of course it would be problematic for the caller to know what set of values are acceptable.) > 3261 underspecifies the Alert-Info, If it comes to Proxy responsible for > UAS in the INVITE, what it will do ? I may be missing something. AFAIK there are no rules for this. It would be a feature/service provided by a proxy in the domain of the UAS to police the use of Alert-Info. It could do this any way that is satisfactory to the user of the UAS. My thought is that a good way is for it to remove any Alert-Info inbound from the UAC - assuming it to be untrustworthy. Then the proxy could generate an Alert-Info going forward to the UAS, in order to provide the UAS with its recommendation of a suitable alerting mode for this caller and call. Paul > Thx > Samir > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, November 03, 2006 7:19 PM >> To: Cullen Jennings >> Cc: sipping >> Subject: Utility of Alert-Info (was: Re: [Sipping] >> draft-stucker-sipping-early-media-coping) >> >> >> >> Cullen Jennings wrote: >> >>> For example - you very correctly point out that the >> Alert-Info header >>> can only be used where the source of the header is trusted - >> however, >>> I can't imagine any case where this was true and the >> Alter-Info header >>> was useful and suspect that mostly it was not used - or that >> at least >>> where it was used there was huge security holes. >> I have been party to discussions of a use that seems to be >> safe and useful: >> >> The Alert-Info only goes between the UA and a proxy that acts >> on its behalf. The proxy strips any Alert-Info headers coming >> to it in the direction of the UA. Then the proxy may insert an >> Alert-Info header. The decision of what to insert may be based >> on black lists, white lists, or any sort of feature logic the >> proxy may choose to carry out. >> >> An advantage of this is that all the data and logic for making >> the decisions can be centralized for multiple UAs. The UAs >> themselves only need to know how to handle Alert-Info. >> >> This requires that messages only reach the UA via the proxy, >> but we know of many environments where that is the case. >> >> Paul >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 05 08:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgiTS-0000vO-0m; Sun, 05 Nov 2006 08:55:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgiTQ-0000v8-9g; Sun, 05 Nov 2006 08:55:44 -0500 Received: from client62.quarrytech.com ([4.17.144.62] helo=ZOE.RPS.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgiTN-0001fQ-Un; Sun, 05 Nov 2006 08:55:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] draft-rosenberg-sipping-overload-reqs recovery X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 5 Nov 2006 08:55:37 -0500 Message-ID: <4BAEA3008BEC574095447FF2A47AAD08183285@ZOE.RPS.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-rosenberg-sipping-overload-reqs recovery Thread-Index: Acb/uMVtWPUhRIKhRfGS5YG428w8dgBJ4qkQ References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> From: "Poretsky, Scott" To: "Cullen Jennings" , "sipping" , "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: bmwg@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0417907461==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0417907461== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C700E2.12288306" This is a multi-part message in MIME format. ------_=_NextPart_001_01C700E2.12288306 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it is worth mentioning that there is work in the Benchmarking = Methodology Working Group (BMWG) to perform this type of SIP device = benchmarking. This can be found at: http://tools.ietf.org/id/draft-poretsky-sip-bench-term-02.txt and http://www.ietf.org/internet-drafts/draft-poretsky-bmwg-sip-bench-meth-00= .txt -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Fri 11/3/2006 9:23 PM To: sipping; Jonathan Rosenberg Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery =20 A possible additional requirement.... Imagine a system (perhaps a single proxy) that could do 100cps. It is =20 in steady state doing 80cps with very few retransmission. Then for 5 =20 minutes the incoming requests goes to 500cps then drops back to an =20 incoming call rate of 80cps. The question is, how long before the =20 system gets back to the state where it if is successfully processing =20 all the 80cps? I have seen systems that never recover - that is bad. I think one of =20 the design goals is that it is at least possible to build to systems =20 that recover back to steady state relatively quickly after an =20 overload impulse. _______________________________________________ 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 ------_=_NextPart_001_01C700E2.12288306 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] draft-rosenberg-sipping-overload-reqs = recovery

I think it is worth mentioning that there is work in = the Benchmarking Methodology Working Group (BMWG) to perform this type = of SIP device benchmarking.  This can be found at:

ht= tp://tools.ietf.org/id/draft-poretsky-sip-bench-term-02.txt

and

http://www.ietf.org/internet-drafts/draft-poretsky-bmwg-sip= -bench-meth-00.txt

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]
Sent: Fri 11/3/2006 9:23 PM
To: sipping; Jonathan Rosenberg
Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery


A possible additional requirement....

Imagine a system (perhaps a single proxy) that could do 100cps. It = is 
in steady state doing 80cps with very few retransmission. Then for = 5 
minutes the incoming requests goes to 500cps then drops back to = an 
incoming call rate of 80cps. The question is, how long before = the 
system gets back to the state where it if is successfully = processing 
all the 80cps?

I have seen systems that never recover - that is bad. I think one = of 
the design goals is that it is at least possible to build to = systems 
that recover back to steady state relatively quickly after an 
overload impulse.



_______________________________________________
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

------_=_NextPart_001_01C700E2.12288306-- --===============0417907461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0417907461==-- From sipping-bounces@ietf.org Sun Nov 05 10:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggk0F-0000zO-0C; Sun, 05 Nov 2006 10:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggk0C-0000zA-Lm for sipping@ietf.org; Sun, 05 Nov 2006 10:33:40 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggk01-0007Ri-RZ for sipping@ietf.org; Sun, 05 Nov 2006 10:33:40 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB36B4F0001; Sun, 5 Nov 2006 16:33:22 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 16:33:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 16:33:21 +0100 Received: from [131.160.126.94] (rvi2-126-94.lmf.ericsson.se [131.160.126.94]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BCF542372; Sun, 5 Nov 2006 17:33:19 +0200 (EET) Message-ID: <454E043D.2090807@ericsson.com> Date: Sun, 05 Nov 2006 17:33:17 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sipping] Draft agenda References: <4541DF7B.8030205@ericsson.com> <278D440F-E7FF-41AC-93F4-6862C1705587@softarmor.com> <45430B1B.1010301@ericsson.com> In-Reply-To: <45430B1B.1010301@ericsson.com> Content-Type: multipart/mixed; boundary="------------050608090008090608010405" X-OriginalArrivalTime: 05 Nov 2006 15:33:22.0094 (UTC) FILETIME=[B9FDA4E0:01C700EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.4 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: sipping , Mary Barnes , Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --------------050608090008090608010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached. Gonzalo Gonzalo Camarillo wrote: > Hi Dean, > > yes, good point. When we have the final agenda, I will send it in an > attachment to the list, in addition to providing the link. > > However, this is not the final agenda. It *will* change over the weekend > to accommodate a few last-minute requests that deserve discussion time. > Keep tuned. > > Cheers, > > Gonzalo --------------050608090008090608010405 Content-Type: text/html; charset=UTF-8; name="agenda.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="agenda.html" SIPPING - IETF 67 Agenda

SIPPING - IETF 67 

Chairs: Gonzalo Camarillo, and Mary Barnes
Secretary: Oscar Novo

MONDAY, November 6, 2006, 0900-1130, Room Grande Ballroom A

Time Length Discussion Leader Topic Relevant Documents
0900 - 0915 15 minutes Chairs Status and Agenda Bash  
0915 - 0945 30 minutes Volker Hilt Session Policies
 draft-ietf-sipping-policy-package-02.txt
draft-ietf-sipping-media-policy-dataset-02.txt
draft-ietf-sip-session-policy-framework-00.txt
0945 - 1000 15 minutes Jonathan Rosenberg Overload Requirements draft-rosenberg-sipping-overload-reqs-02.txt
1000 - 1015 15 minutes Volker Hilt Overload Control draft-hilt-sipping-overload-00.txt
1015 - 1030 15 minutes Daryl Malas SIP End-to-end Performance Metrics draft-malas-performance-metrics-05.txt
1030 - 1045 15 minutes Mayumi Munakata Clarification of Privacy Mechanism draft-munakata-sipping-privacy-clarified-00.txt
1045 - 1100 15 minutes Jani Hautakorpi Method for URI-List Servers to Refuse the Handling of a URI-List draft-hautakorpi-sipping-uri-list-handling-refused-00.txt
1100 - 1130 30 minutes Brian Stucker Early Media draft-stucker-sipping-early-media-coping-03.txt
draft-ejzak-sipping-p-em-auth-02.txt

TUESDAY, November 7, 2006, 1850-1950, Room Grande Ballroom B

Time Length Discussion Leader Topic Relevant Documents
1850 - 1855 5 minutes Chairs Status and Agenda Bash  
1855 -1920 25 minutes Adam Roach
 Call Completion Service
 draft-roach-sipping-callcomp-bfcp-00.txt
1920 - 1935 15 minutes Paul Kyzivat Offer/answer usage draft-sawada-sipping-sip-offeranswer-01.txt
1935 - 1950 15 minutes Jun Koshiko Race Conditions draft-hasebe-sipping-race-examples-02.txt

--------------050608090008090608010405 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --------------050608090008090608010405-- From sipping-bounces@ietf.org Sun Nov 05 17:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggqqm-0000gZ-GV; Sun, 05 Nov 2006 17:52:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfw6z-0001Rs-GZ for sipping@ietf.org; Fri, 03 Nov 2006 05:17:21 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfw6y-0004eG-1T for sipping@ietf.org; Fri, 03 Nov 2006 05:17:21 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 11:17:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Fri, 3 Nov 2006 11:16:58 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC0BF08725@ftrdmel1.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb+lcaO0xskB581R4yEOvZkfxxTvwAmwSWA From: "GARCIN Sebastien RD-CORE-ISS" To: "Adam Roach" , "Jonathan Rosenberg" X-OriginalArrivalTime: 03 Nov 2006 10:17:01.0272 (UTC) FILETIME=[33B68D80:01C6FF31] X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-Mailman-Approved-At: Sun, 05 Nov 2006 17:52:23 -0500 Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org hi=20 >>The objections that I have repeatedly raised with the "abuse" of = SUBSCRIBE to activate a service aren't purely academic I am still missing the "non-academic" arguments that would convince me = not to the procedures in draft-ploetz. Thanks for clarifying that part. s=E9bastien -----Message d'origine----- De : Adam Roach [mailto:adam@nostrum.com]=20 Envoy=E9 : jeudi 2 novembre 2006 16:43 =C0 : Jonathan Rosenberg Cc : IETF Sipping List Objet : Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Jonathan Rosenberg wrote: > Its not clear to me that this mechanism works well in the face of=20 > forking. Seems like you could end up with disparate queues for each of = > my phones. That's pretty much what I intended, yes. As far as I can tell, the net = result -- that is, the behavior of the system -- would end up being = identical (or, at least, substantially the same) with queues maintained = on each of your devices versus a single, centralized queue -- unless = there's more than one of you, in which case neither solution will behave = particularly gracefully (although I believe the forking setup has better = recovery properties under such circumstances). When I get a spare moment, I'll work through a few scenarios to = demonstrate how the externally observed system behavior is the same = between distributed management of several queues and centralized = management of one queue. > Similar issues arise when the originating user has multiple devices.=20 > So if I call you from phone 1, and later you are available, does the=20 > ringback happen only at phone 1 or all of my phones? Seems like the=20 > latter is much more desirable. That too implies that a UA-based=20 > solution on the originating side has some problems. That depends. Are you asserting this as a new requirement? No one has = raised this capability as a requirement so far, and the previously = offered solution certainly didn't have this property. To be clear: I agree that this is probably an improvement on the = service; however, the more requirements we pile on, the harder a = solution becomes -- and we've become experts at putting so many = requirements on a problem that the solution space dwindles down to = nothing. > There is clearly a relationship between all of this and presence; I=20 > think you need to call that out. Martin beat me to it, but I'll reiterate his comment: the relationship = here isn't related as much to presence as it is to dialog state. And = that is called out in the discussion about centralized queue management. > On whether BFCP is the right thing or not for this problem, I'm not=20 > sure. In one sense, you could characterize this as really a problem=20 > with RFC3265 in general; that for certain event packages, notification = > of an event to all watchers can cause them to take actions that result = > in a further change to that same state. This is a race condition. Not in general -- this race condition arises in the draft-poetzl = document because it's doing something with SUBSCRIBE that SUBSCRIBE was = never meant to do: changing the state of the thing that is watched. Let's go back to first principles: SUBSCRIBE is a request to retrieve = the state of a resource, and receive that state whenever it changes.=20 It's a way for an observer to *LOOK* at a state. Now, as I'm always having to tell my kids: you look with your eyes, not = with your hands. If the act of subscribing to a state changes that very = state, then you're no longer looking -- you're touching. SUBSCRIBE = doesn't touch the state it's monitoring. (Now, we have defined some *meta* state regarding the very state of that subscription, but you need = to subscribe to that separately, and the act of subscribing to that = meta-state doesn't change the meta-state). If you violate the basic principles on which a protocol was developed, = then, yes, you end up with protocol characteristics that are highly = undesirable. The race condition you describe is one. The objections that = I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a = service aren't purely academic: if you use a protocol in a way that is = well outside its original design, then clearly identifiable bad things = happen. > I share John's concerns as to whether this really interoperates with=20 > the PSTN. Perhaps if you had some call flows demonstrating it, this=20 > would help. Martin has put together some pretty nice call flows showing how this = interoperates with the PSTN. Perhaps he could be convinced to share them = with the wider group? /a _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 05 20:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgspK-0003WE-Mq; Sun, 05 Nov 2006 19:59:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgspJ-0003W6-AP for sipping@ietf.org; Sun, 05 Nov 2006 19:59:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgspH-0005Vj-TD for sipping@ietf.org; Sun, 05 Nov 2006 19:59:01 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA60wvl4009571 for ; Sun, 5 Nov 2006 17:58:57 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Re: draft-littlefield-sipping-mgmt-event-01.txt Date: Sun, 5 Nov 2006 17:58:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-littlefield-sipping-mgmt-event-01.txt Thread-Index: Acb53ziUzU1SNAvxQvKzO9utGNzSegHOnx8w From: "Sumanth Channabasappa" To: "sipping" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments inline... From: Josh Littlefield [mailto:joshl@cisco.com]=20 Hi Paul, Paul Kyzivat wrote: > Did you consider, as an alternative, simply sending a REFER to the=20 > device, with a Refer-To: snmp:whatever ? I guess that's an interesting idea for what I've defined as the NOTIFY end of this (assuming we can define sufficiently descriptive URIs for the mgmt protocols). It leaves open the question of how the UA indicates it's availability and interest in being managed, and its mgmt capabilities. The SUBSCRIBE from the managed entity provides a way to do that, but they REFER would seem to arrive sort of spontaneously from the management station. [S] Managed SIP UAs usually have knowledge of the management stations authorized to manage them. This can happen via pre-or dynamic configuration, but in most cases will be known to the client. The REFER may work for the initial setup, but the SUBSCRIBE/NOTIFY framework provides a slightly richer behavior, IMHO: a) it allows for the 'client' to SUBSCRIBE and maintain the subscription until interested (or configured otherwise) b) Allows for the SIP infrastructure to send a NOTIFY (within a subscription) when communication is required or anything changes. The latter (b) could be achieved using REFER, but can we also achieve the former? One could use REFER from an authenticated source as a means to configure the client with the Management Station information, which would then proceed to SUBSCRIBE to the information - if that makes sense? Was the REFER considered as an option for the SIPPING-CONFIG framework? Maybe that could be solved through presence (this is getting out of my depth), but I'm not sure how much infrastructure is desirable to be pulled into solving this problem. [S] Unsure if this can be solved using Presence. Can you provide more details? Thanks - S >=20 > Paul >=20 > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> >> Title : A Management Request Event Package for the Session >> Initiation Protocol (SIP) >> Author(s) : J. Littlefield >> Filename : draft-littlefield-sipping-mgmt-event-01.txt >> Pages : 19 >> Date : 2006-10-22 >> =20 >> In many environments, firewall, NAT and IP addressing issues make >> remote management of devices containing SIP user agents difficult. >> This document defines a SIP event package for notifying a user agent >> that it should initiate a session with a management entity for >> management operations. This type of "call-home" management avoids >> the need to maintain persistent TCP connections, or generate >> additional STUN traffic, with the management entity. This event >> package is intended not to tunnel management protocols or otherwise >> provide management itself, but instead to provide a means for >> signaling a SIP UA that a management session is desired. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-littlefield-sipping-mgmt-ev >> ent-01.txt >> >> >> To remove yourself from the I-D Announcement list, send a message to=20 >> i-d-announce-request@ietf.org with the word unsubscribe in the body=20 >> of the message. You can also visit=20 >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20 >> subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the=20 >> username "anonymous" and a password of your e-mail address. After=20 >> logging in, type "cd internet-drafts" and then "get=20 >> draft-littlefield-sipping-mgmt-event-01.txt". >> >> A list of Internet-Drafts directories can be found in=20 >> http://www.ietf.org/shadow.html or=20 >> 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-littlefield-sipping-mgmt-event-01.txt". >> =20 >> 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=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 05 20:21:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgtB1-0006xr-H9; Sun, 05 Nov 2006 20:21:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgtAz-0006x4-KR for sipping@ietf.org; Sun, 05 Nov 2006 20:21:25 -0500 Received: from web31804.mail.mud.yahoo.com ([68.142.207.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GgtAw-0008Gk-V9 for sipping@ietf.org; Sun, 05 Nov 2006 20:21:25 -0500 Received: (qmail 71349 invoked by uid 60001); 6 Nov 2006 01:21:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mRd8JxNdJ3DXhw1oPpfA56Z+h1PrxrqJmAWJuTJzBeDyjdrRsgEAojny+79WDUGsuFBMfnJKBdSiGrPfnOEY5H+Ju95daAktpIo4+kTb/XwkUavwXscNkdfoWXVitYzqwPV5kcXHSD68tRlZWW/fPtlWSp5whrHINxbfpDT1eNU= ; Message-ID: <20061106012122.71347.qmail@web31804.mail.mud.yahoo.com> X-YMail-OSG: CzKrgWYVM1k5hn1iDJoxhmraD9p7sOmsRxViXCNu Received: from [12.105.242.254] by web31804.mail.mud.yahoo.com via HTTP; Sun, 05 Nov 2006 17:21:22 PST Date: Sun, 5 Nov 2006 17:21:22 -0800 (PST) From: Dan Petrie To: Sumanth Channabasappa , Gonzalo Camarillo , sipping In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: Dan Petrie Subject: [Sipping] Re: WGLC: draft-ietf-sipping-config-framework-09.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Sumanth, Josh and Nhut: Thank you very much. You have made some very constructive comments that I have done my best to resolve and incorporate in the draft (post 09). See comments inline. Cheers, Dan > Gonzalo, Dan, > > As indicated before, here are the comments on: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework- > 09.txt > > > Since the comments were the result of collective feedback, I have > included the originators of the comments. [Josh] refers to Josh > Littlefield (joshl@cisco.com) and Nhut refers to Nhut Nguyen > (nnguyen@sta.samsung.com). > > > regards > Sumanth (on behalf of the comment originators) > > > #1 > > Overview: > -------- > > + 1.1 [Page 6; need clarification] > > << > "With SIP the users and devices already are assigned globally routable > addresses. In addition the firewall and NAT problems are already > presumably solved in the environments in which SIP user agents are to be > used." >>> > > [Sumanth] Was the intention to state that in SIP networks, users and > devices are 'globally reachable'? Globally routable address implies > something different Yes, globally routable is the wrong term here. The point was that SIP already provides a mechanism to address the route messaging to the users and end points needing configuration. > > > > + 1.2 [Page 7; Josh] Diagram on page 8 might make more sense as a simple > flow diagram, as depicted below: Thank you this is much clearer. An ASCII artist I am not. > > +------------------+ +----------------------+ > +------+ |Residential Router| |SP Prof. Delivery Srvr| > |Device| | DHCP SIP | | HTTPS SIP | > +------+ +------------------+ +----------------------+ > | | | | | > (1A) |<===DHCP===>| | | | > | | | | | > | | | | | > | SUBSCRIBE/NOTIFY | | | > (1B) |<=local-network profile=>| | | > | | | | | > | | | | | > (2) [User enters SP hostname] > | | | | | > | | | | | > (3) |-----------SUBSCRIBE/TLS device profile----------->| > | | | | | > | | | | | > (4) |<-------NOTIFY (on existing TLS connection)--------| > | | | | | > | | | | | > (5A) |-------HTTPS GET device profile------>| | > | | | | | > | | | | | > (5B)[User enters UserID/password] > | | | | | > | | | | | > (6) |<-----HTTPS resp w/dev. profile-------| | > | | | | | > | | | | | > (7) |-----Re-SUBSCRIBE (configured device profile)----->| > | | | | | > | | | | | > | | | | | > > > > + 1.3 [General, Nhut] > Overview should probably indicate something about authentication of > entities obtaining profiles Added. > > > > #2: > Section 5.1 > ----------- > > + 2.1 [Page 8; clarification requested] > << > 5. The device receives the NOTIFY request with the device profile URI. > The device prompts the user for the user ID and password provided by the > service provider. The device does an HTTPS GET to retrieve the device > profile (see Section 8.4 and Section 7.8). > > The profile delivery server challenges for Digest authentication. The > device re-sends the HTTPS GET with Digest credentials using > the user ID and password entered by the user. >>> > > [Sumanth, Josh] The statement seems to indicate that the Device Profile > is obtained via 'User Credentials'. Does this imply that the possession > of valid User credentials on the Service Provider's network would allow > the User to obtain any Device Profile (or is the Device Profile specific > to that User)? Given this is a Use Case, the assumption that this is > feasible is probably valid, but should probably be clarified (esp. given > the subtleties). > Good point. I have added text. > > + 2.2 [Page 8; clarification requested] > << > The device receives the device profile from the HTTPS response, > re-SUBSCRIBEs using the device profile URI provided in the > profile. The device profile also may contain URIs for the > default user's user and other profile SUBSCRIBE request URIs for > the SIP event package defined in Section 7. The device uses > these URIs to retrieve user and other profiles in a similar way > to the device profile. After retrieving these profiles the > device is fully functional in the service provider's SIP service. >>> > > [Josh, Sumanth] This I-D mentions a 'Default User' for a device. The > current understanding is that a device can use this 'Default User' to > obtain User Profile information in the absence of any other User. Is > this understanding right? If so, should we say something upfront? Yes, I got a number of comments on defining the data content which is mostly out of scope of this document. I hope that I have resolved this by adding a paragraph in the data model section that makes some recommendations on the data contents to be defined in another document. > > > > #3 > > Section 5.2 > ----------- > > + 3.1 [Sumanth] This section needs to indicate that for Certificate > Validation, the Certificate Signer information should be present. This > can be accomplished using a PKI or some out of band mechanism. Added. > > > #4 > > Section 6 > --------- > > + 4.1 [last paragraph; error?] > << > The device instance id is used to form the user id part of the URI for > subscribing to the device and local network profiles. >>> > > [Josh] This seems to contradicts 7.13.3 (as per change 1 in the current > I-D)? Yes. Thank you, I missed that in the last set of edits. > > > > #5 > Section 7.2 > ----------- > > 5.1 [Page 13] > << > The "network-user" parameter MUST be set when subscribing for device > profiles if the user's AOR is known. >>> > > [Josh] Do we really need the 'network-user' for the device profile? Can > this be a SHOULD? > [Sumanth] I concur, is there a justification for the MUST? Actually, this should be a MAY for the device profile. network-user in the device profile subscription is an indication of an a request by the user agent to make the given user the default user for the device. It is a MUST for the local-network profile. > > > 5.2 [Page 14] > [Josh] > + discussion of "network-user" parameter is both contradictory and > repetitive. It needs to be cleaned up. > > First it says "The "network-user" parameter MUST be set when subscribing > for device profiles if the user's AOR is known." Later, at the bottom > of the page, it says "When the profile-type is "device", the user agent > SHOULD set the "network-user" parameter to the "user" profile resource > identifier if it is known.". Thanks. I will make these consistant: MAY for device profile, MUST for local-network profile. > > The justification for the network-user parameter is also repeated in > this section. At the start: > > << > The URIs will not contain the user profile identifier. For this reason > the "network-user" parameter is needed to indicate the user profile > resource identifier associated with the "device" or URI. >>> > > > and near the bottom: > << > Since the From field and SUBSCRIBE request URI indicate the "device" > profile resource identifier, the "network-user" parameter is needed to > indicate the additional resource identifier for the user associated with > this device. Deleted. >>> > > > > General comments (Josh): > ------- -------- > + The I-D seems to provide more information than required in certain > cases, e.g. > << > The data provided in the three types of profiles may overlap. As an > example, the codecs that a user prefers to use, the codecs that the > device supports (and the enterprise or device owner wishes to use), > the codecs that the local network can support (and the network > operator wishes to allow) all may overlap in how they are specified > in the three corresponding profiles. This policy for merging the > constraints across the multiple profile types can only unambiguously > be defined in the context of the profile syntax and semantics. This > is out of scope for this document and will be defined in a subsequent > document(s) that define the data profile format. >>> > > One could simplify this by saying that data overlap across profiles is > out of scope. Just a thought, not a strong recommendation. The discussion of data overlap and merging is in here mainly as the framework intensionally is designed to allow it. This paragraph is here to resolve issues that someone else brought up on the discussion of overlap for this document. However the solution to resolving overlap is out of scope for this document. It is something that we discuss and solve in the profile-data-sets draft. > > > + General formatting issues. Many sections seem to have gained odd > formatting (indentation) resulting from edits. For example, pages 13 > and 14. Is this intentional? If so, vertical spacing should offset > these paragraphs above and below. Yes, the extra indentation is for rational for statements in the prior paragraph, typically normative statements. Thanks for pointing our the vertical spacing issues. > > > + s/localdomain/local domain/ on page 14 done > > > + Example for 7.12 shows TCP Via header in SUBSCRIBE and UDP Via header > in NOTIFY. Does that make sense? (Maybe so with a proxy, but I'm not > sure.) Good catch. They are both TCP now. > > > + Update XCAP reference (now -12, Oct. 06, -11 is expired) Done > > > > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, October 10, 2006 12:26 AM > To: sipping > Cc: Martin Dolly; Even, Roni; Daniel Petrie; > Christian.Stredicke@snom.de; Mary Barnes; Amy Pendleton > Subject: [Sipping] WGLC: draft-ietf-sipping-config-framework-09.txt > > Folks, > > we would like to working group last call (WGLC) the following draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework- > 09.txt > > We would like to recruit a few volunteers to serve as dedicated > reviewers (in addition to Roni, Martin, and Chistian, who already > reviewed the draft). > > If you are interested and willing to review this draft, please send an > email to the SIPPING chairs. > > As always, anyone else that gets a chance to review should also send > their feedback to the authors and copy the SIPPING mailing list. > > This WGLC will end on October 31st, 2006. > > Thanks, > > Gonzalo > SIPPING co-chair SIPez LLC SIP VoIP, IM and Presence Consulting http:/www.sipez.com tel: +1 (617) 273-4000 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 03:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzhg-0008S6-Aq; Mon, 06 Nov 2006 03:19:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzhe-0008Kj-Tb for sipping@ietf.org; Mon, 06 Nov 2006 03:19:34 -0500 Received: from [130.129.67.127] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggzhc-0002sd-JJ for sipping@ietf.org; Mon, 06 Nov 2006 03:19:34 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 95BA11CC5D for ; Mon, 6 Nov 2006 00:19:08 -0800 (PST) To: sipping@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 06 Nov 2006 00:19:08 -0800 From: EKR Message-Id: <20061106081908.95BA11CC5D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-09 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25 18:52:13 ekr Exp $ I'm fairly naive about SIP UAs and configuration, but this document strikes me as an extremely complex approach to what's really a fairly simple problem. As I understand the problem space from reading the draft, there are four main use cases: (1) Plug a naive (out of the box) SIP UA into a network and have it "just work" like a POTS UA does with no additional configuration provided. (2) Have a user be able to provide some identifying information about a SIP UA (E.g., the MAC address) to some management console and then have the UA be able to configure itself. Arguably this is a subcase of (1). (3) Have a user be able to register with some SIP service provider via some undefined out-of-band mechanism and have that service provider give them a URL and some authentication credentials which they can feed to their UA and their UA can use to get configured. (4) Have a user be able to take a preconfigured SIP UA to a new network environment and get the new network access information (e.g., a hotel proxy) while retaining the original configuration information (the AOR, keying material, etc.) Arguably, something based on this document could do this job--though note that this document alone cannot because it doesn't actually specify any of the relevant parameters--but it's not clear that all near the complexity in this protocol is required. In particular: - I don't see why it's necessary to have three tiers of configuration data (local network, device, and user) which must somehow be merged. In the first three cases, ISTM that you really only have one tier and in the fourth there is only some very limited set of well-defined information, namely the local proxy. It's not like you want a hotel proxy to even be able to specify what you should be using as your SIP AOR! - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA can get its profile either via SIP or via an external reference in a NOTIFY. Let's keep life simple. - The mechanisms for discovering the URI seem extremely complicated. Currently, there are different mechanisms for each of the three URI types. If we collapse this down to a single type then is there some reason we can't use the SIP DHCP option? -Ekr _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 09:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5uw-0001uX-4z; Mon, 06 Nov 2006 09:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5uu-0001uS-JJ for sipping@ietf.org; Mon, 06 Nov 2006 09:57:40 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh5uq-0003er-63 for sipping@ietf.org; Mon, 06 Nov 2006 09:57:40 -0500 Received: from [10.1.2.171] (66-146-188-42.skyriver.net [66.146.188.42]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA6EvY5d011549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Nov 2006 09:57:35 -0500 (EST) In-Reply-To: <20061106081908.95BA11CC5D@delta.rtfm.com> References: <20061106081908.95BA11CC5D@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00AB308C-51C4-4B65-8EB4-3C0A44C0B7BA@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Date: Mon, 6 Nov 2006 06:57:33 -0800 To: EKR X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think this is a good example of a draft that gets less useful by having been around for many, many years. As years and IETF meetings accumulate, more and more stuff gets added, without any real indication that there is a constituency for them. Nobody seems to be paying much attention to the draft, so there's little pushback on feature creep. Just as for consent and in SIMPLE, I think it's time to step back and see if we can't get 90% of the benefit with 10% of the effort, and maybe scoping the problem so that other features can be added later, if there is demonstrated demand for them. Unfortunately, this draft has become a posterchild on why people consider SIP to be far too complex. I had said this before, but I'll repeat that I still find the merging stuff far too messy and unpredictable to be useful. (It is difficult for any of the parties to know what exactly happened in the end, making debugging and troubleshooting difficult.) A simple alternative is to designate parameters for each role and only allow certain entities to set them. The old saying went that a draft isn't finished until there's nothing left to take out. I don't think we've even tried to have this discussion. Henning On Nov 6, 2006, at 12:19 AM, EKR wrote: > $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 > 2006/10/25 18:52:13 ekr Exp $ > > I'm fairly naive about SIP UAs and configuration, but this document > strikes me as an extremely complex approach to what's really a fairly > simple problem. As I understand the problem space from reading the > draft, there are four main use cases: > > (1) Plug a naive (out of the box) SIP UA into a network and have > it "just work" like a POTS UA does with no additional > configuration > provided. > (2) Have a user be able to provide some identifying information > about a SIP UA (E.g., the MAC address) to some management > console and then have the UA be able to configure itself. > Arguably this is a subcase of (1). > (3) Have a user be able to register with some SIP service provider > via some undefined out-of-band mechanism and have that service > provider give them a URL and some authentication credentials > which they can feed to their UA and their UA can use to get > configured. > (4) Have a user be able to take a preconfigured SIP UA to a new > network environment and get the new network access information > (e.g., a hotel proxy) while retaining the original configuration > information (the AOR, keying material, etc.) > > Arguably, something based on this document could do this job--though > note that this document alone cannot because it doesn't actually > specify any of the relevant parameters--but it's not clear that > all near the complexity in this protocol is required. In > particular: > > - I don't see why it's necessary to have three tiers of configuration > data (local network, device, and user) which must somehow be merged. > In the first three cases, ISTM that you really only have one tier > and in the fourth there is only some very limited set of well- > defined > information, namely the local proxy. It's not like you want a > hotel proxy to even be able to specify what you should be using > as your SIP AOR! > > - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA > can get its profile either via SIP or via an external reference > in a NOTIFY. Let's keep life simple. > > - The mechanisms for discovering the URI seem extremely complicated. > Currently, there are different mechanisms for each of the three > URI types. If we collapse this down to a single type then is > there some reason we can't use the SIP DHCP option? > > -Ekr > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 11:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TN-0008BD-WD; Mon, 06 Nov 2006 11:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TM-0008B6-CK for sipping@ietf.org; Mon, 06 Nov 2006 11:37:20 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7TI-0000bq-0Y for sipping@ietf.org; Mon, 06 Nov 2006 11:37:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6GbCB01094; Mon, 6 Nov 2006 11:37:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] draft-stucker-sipping-early-media-coping Date: Mon, 6 Nov 2006 10:37:12 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA8F@zrc2hxm2.corp.nortel.com> In-Reply-To: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-stucker-sipping-early-media-coping Thread-Index: Acb/uM3mM5AdkO6LQeKctUV3ql7okgBrr+qQ From: "Brian Stucker" To: "Cullen Jennings" , "sipping" X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Cullen.. Please see comments below, thanks for reviewing the draft. Regards, Brian=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Friday, November 03, 2006 8:24 PM > To: sipping > Subject: [Sipping] draft-stucker-sipping-early-media-coping >=20 >=20 > I have to admit there were many parts of this that left me=20 > somewhat lost on what the problem was or how it was solved.=20 > There were also some things that left me really surprised if=20 > many people use them .... The draft is trying to show the ways early media is broken, the ways that people have gotten creative to try to manage the mess, the problems those approaches cause, and the beginnings of some discussion on how to fix it. The intent of the draft is to try to gather together all of the information I could find about the issues with early media so we can start working on ways of either fixing it or explaining why it can never be fixed (along with recommendations to implementors as to how they should handle the situation). One of the worst problems with early media isn't early media. It's the divergent ways in which various designs have tried to take advantage of it for a particular application, or manage the chaos that is what is most concerning to me. People "in the know" know that there are issues with early media, but there are still people out there working on implementations and developing standards that aren't aware of all the implications of their decisions. Clarification alone seems useful. >=20 > For example - you very correctly point out that the=20 > Alert-Info header can only be used where the source of the=20 > header is trusted - however, I can't imagine any case where=20 > this was true and the Alter-Info header was useful and=20 > suspect that mostly it was not used - or that at least where=20 > it was used there was huge security holes. It's used, and proxies aren't required to strip it, so how do endpoints know where it came from? It just arrives. Bad news. We probably need to put some nerf around this header to allow endpoints to figure out when it's coming to them from a trusted source and when it comes from outer space somewhere. If nobody was using it, then we could just deprecate it (but I know people are using it). >=20 > You talk about proxy sdp stripping being a "a very common mechanism" =20 > - this surprised me so I might just be misunderstanding what=20 > you are saying. If this is done, I don't see how early media=20 > works and if early media does not work I don't see how=20 > phoning things that need it work. I thought that every non=20 > trivial deployment did early media. I've seen it done on a number of different deployed devices. You can also think of it as the proxy "delaying" the SDP to the 200 OK rather than letting it go through on a 18x message. For early media endpoints that the proxy is controlling or trusts, it allows the 18x with SDP to flow back to the originator. Further, it may let SDP answers from terminating endpoints flow back on 18x messages to the originator if the proxy knows that some early media it is controlling (perhaps a ringback generator) is no longer necessary to the call.=20 >=20 > Anyways ... I don't think I would take any of these comments=20 > too seriously other than the meta point that I probably don't=20 > understand the draft and that it probably needs mmuisc and=20 > avt review more than sip. Also, have you looked at the=20 > application interaction framework stuff for doing things like=20 > inserting media announcements at the beginning of a call. >=20 I have not looked at the application interaction framework stuff for a number of moons. I'll have a look at it before the next revision of the draft to see if there's more problems that it may introduce or fix to the problem space. >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 11:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TP-0008BY-J6; Mon, 06 Nov 2006 11:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TO-0008BT-Vt for sipping@ietf.org; Mon, 06 Nov 2006 11:37:22 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7TK-0000cC-Ku for sipping@ietf.org; Mon, 06 Nov 2006 11:37:22 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6GbEB01114; Mon, 6 Nov 2006 11:37:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Mon, 6 Nov 2006 10:37:14 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> In-Reply-To: <454C069C.6010500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: Acb/wKzVwQq1ymayT+ihppaqBXJrwQBpWvNQ From: "Brian Stucker" To: "Paul Kyzivat" , "Cullen Jennings" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sipping X-BeenThere: sippiFrom sipping-bounces@ietf.org Mon Nov 06 11:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TN-0008BD-WD; Mon, 06 Nov 2006 11:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TM-0008B6-CK for sipping@ietf.org; Mon, 06 Nov 2006 11:37:20 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7TI-0000bq-0Y for sipping@ietf.org; Mon, 06 Nov 2006 11:37:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6GbCB01094; Mon, 6 Nov 2006 11:37:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] draft-stucker-sipping-early-media-coping Date: Mon, 6 Nov 2006 10:37:12 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA8F@zrc2hxm2.corp.nortel.com> In-Reply-To: <58C12A0B-98EC-4DE8-8451-6C85E2E1A205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-stucker-sipping-early-media-coping Thread-Index: Acb/uM3mM5AdkO6LQeKctUV3ql7okgBrr+qQ From: "Brian Stucker" To: "Cullen Jennings" , "sipping" X-Spam-Score: 1.1 (+) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Cullen.. Please see comments below, thanks for reviewing the draft. Regards, Brian=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Friday, November 03, 2006 8:24 PM > To: sipping > Subject: [Sipping] draft-stucker-sipping-early-media-coping >=20 >=20 > I have to admit there were many parts of this that left me=20 > somewhat lost on what the problem was or how it was solved.=20 > There were also some things that left me really surprised if=20 > many people use them .... The draft is trying to show the ways early media is broken, the ways that people have gotten creative to try to manage the mess, the problems those approaches cause, and the beginnings of some discussion on how to fix it. The intent of the draft is to try to gather together all of the information I could find about the issues with early media so we can start working on ways of either fixing it or explaining why it can never be fixed (along with recommendations to implementors as to how they should handle the situation). One of the worst problems with early media isn't early media. It's the divergent ways in which various designs have tried to take advantage of it for a particular application, or manage the chaos that is what is most concerning to me. People "in the know" know that there are issues with early media, but there are still people out there working on implementations and developing standards that aren't aware of all the implications of their decisions. Clarification alone seems useful. >=20 > For example - you very correctly point out that the=20 > Alert-Info header can only be used where the source of the=20 > header is trusted - however, I can't imagine any case where=20 > this was true and the Alter-Info header was useful and=20 > suspect that mostly it was not used - or that at least where=20 > it was used there was huge security holes. It's used, and proxies aren't required to strip it, so how do endpoints know where it came from? It just arrives. Bad newsng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org That's one use... Here's another: I've seen Alert-Info used for distinctive ringing where the URL in the Alert-Info specifies a resource local to the terminator that is known to the server and the end client. That probably sounds a bit crazy, so here's an example: Let's say the terminator has previously specified that they wish to hear ring pattern A when someone inside an enterprise calls them, and ring pattern B when someone outside the enterprise is calling. As a result, you might get implementations that do the following in order to prevent managing dial-plan information on the terminator's end-device: If the call is from within the enterprise: Alert-Info: http://127.0.0.1/ringpattern-a.wav If the call is from outside the enterprise: Alert-Info: http://127.0.0.1/ringpattern-b.wav In either case, these are sent to the terminator. Luckily, this doesn't have an early media impact. However, in the case of colorful ringback, where you hear something other than "ring-ring" when making a call, the same logic above could be used in the reverse direction towards the originator. When does the originator do what if it gets this back, plus some early media from a gateway somewhere? The header is in 3261. It clearly has some issues around it's operation and interaction with other forms of early media. We should nerf it, deprecate it, or explain under what conditions it should be used so there's a decent chance of someone using it getting what they expected. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, November 03, 2006 9:19 PM > To: Cullen Jennings > Cc: sipping > Subject: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 >=20 >=20 > Cullen Jennings wrote: >=20 > > For example - you very correctly point out that the=20 > Alert-Info header=20 > > can only be used where the source of the header is trusted=20 > - however,=20 > > I can't imagine any case where this was true and the=20 > Alter-Info header=20 > > was useful and suspect that mostly it was not used - or=20 > that at least=20 > > where it was used there was huge security holes. >=20 > I have been party to discussions of a use that seems to be=20 > safe and useful: >=20 > The Alert-Info only goes between the UA and a proxy that acts=20 > on its behalf. The proxy strips any Alert-Info headers coming=20 > to it in the direction of the UA. Then the proxy may insert=20 > an Alert-Info header. The decision of what to insert may be=20 > based on black lists, white lists, or any sort of feature=20 > logic the proxy may choose to carry out. >=20 > An advantage of this is that all the data and logic for=20 > making the decisions can be centralized for multiple UAs. The=20 > UAs themselves only need to know how to handle Alert-Info. >=20 > This requires that messages only reach the UA via the proxy,=20 > but we know of many environments where that is the case. >=20 > Paul >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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. We probably need to put some nerf around this header to allow endpoints to figure out when it's coming to them from a trusted source and when it comes from outer space somewhere. If nobody was using it, then we could just deprecate it (but I know people are using it). >=20 > You talk about proxy sdp stripping being a "a very common mechanism" =20 > - this surprised me so I might just be misunderstanding what=20 > you are saying. If this is done, I don't see how early media=20 > works and if early media does not work I don't see how=20 > phoning things that need it work. I thought that every non=20 > trivial deployment did early media. I've seen it done on a number of different deployed devices. You can also think of it as the proxy "delaying" the SDP to the 200 OK rather than letting it go through on a 18x message. For early media endpoints that the proxy is controlling or trusts, it allows the 18x with SDP to flow back to the originator. Further, it may let SDP answers from terminating endpoints flow back on 18x messages to the originator if the proxy knows that some early media it is controlling (perhaps a ringback generator) is no longer necessary to the call.=20 >=20 > Anyways ... I don't think I would take any of these comments=20 > too seriously other than the meta point that I probably don't=20 > understand the draft and that it probably needs mmuisc and=20 > avt review more than sip. Also, have you looked at the=20 > application interaction framework stuff for doing things like=20 > inserting media announcements at the beginning of a call. >=20 I have not looked at the application interaction framework stuff for a number of moons. I'll have a look at it before the next revision of the draft to see if there's more problems that it may introduce or fix to the problem space. >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 11:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TP-0008BY-J6; Mon, 06 Nov 2006 11:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7TO-0008BT-Vt for sipping@ietf.org; Mon, 06 Nov 2006 11:37:22 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7TK-0000cC-Ku for sipping@ietf.org; Mon, 06 Nov 2006 11:37:22 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6GbEB01114; Mon, 6 Nov 2006 11:37:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Mon, 6 Nov 2006 10:37:14 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> In-Reply-To: <454C069C.6010500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: Acb/wKzVwQq1ymayT+ihppaqBXJrwQBpWvNQ From: "Brian Stucker" To: "Paul Kyzivat" , "Cullen Jennings" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sipping X-BeenThere: sippi SIP ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org That's one use... Here's another: I've seen Alert-Info used for distinctive ringing where the URL in the Alert-Info specifies a resource local to the terminator that is known to the server and the end client. That probably sounds a bit crazy, so here's an example: Let's say the terminator has previously specified that they wish to hear ring pattern A when someone inside an enterprise calls them, and ring pattern B when someone outside the enterprise is calling. As a result, you might get implementations that do the following in order to prevent managing dial-plan information on the terminator's end-device: If the call is from within the enterprise: Alert-Info: http://127.0.0.1/ringpattern-a.wav If the call is from outside the enterprise: Alert-Info: http://127.0.0.1/ringpattern-b.wav In either case, these are sent to the terminator. Luckily, this doesn't have an early media impact. However, in the case of colorful ringback, where you hear something other than "ring-ring" when making a call, the same logic above could be used in the reverse direction towards the originator. When does the originator do what if it gets this back, plus some early media from a gateway somewhere? The header is in 3261. It clearly has some issues around it's operation and interaction with other forms of early media. We should nerf it, deprecate it, or explain under what conditions it should be used so there's a decent chance of someone using it getting what they expected. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, November 03, 2006 9:19 PM > To: Cullen Jennings > Cc: sipping > Subject: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 >=20 >=20 > Cullen Jennings wrote: >=20 > > For example - you very correctly point out that the=20 > Alert-Info header=20 > > can only be used where the source of the header is trusted=20 > - however,=20 > > I can't imagine any case where this was true and the=20 > Alter-Info header=20 > > was useful and suspect that mostly it was not used - or=20 > that at least=20 > > where it was used there was huge security holes. >=20 > I have been party to discussions of a use that seems to be=20 > safe and useful: >=20 > The Alert-Info only goes between the UA and a proxy that acts=20 > on its behalf. The proxy strips any Alert-Info headers coming=20 > to it in the direction of the UA. Then the proxy may insert=20 > an Alert-Info header. The decision of what to insert may be=20 > based on black lists, white lists, or any sort of feature=20 > logic the proxy may choose to carry out. >=20 > An advantage of this is that all the data and logic for=20 > making the decisions can be centralized for multiple UAs. The=20 > UAs themselves only need to know how to handle Alert-Info. >=20 > This requires that messages only reach the UA via the proxy,=20 > but we know of many environments where that is the case. >=20 > Paul >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 13:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9CJ-0003IM-SB; Mon, 06 Nov 2006 13:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9CI-0003IH-7W for sipping@ietf.org; Mon, 06 Nov 2006 13:27:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9CE-0006UO-EH for sipping@ietf.org; Mon, 06 Nov 2006 13:27:50 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 10:27:46 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="754994416:sNHT55912814" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6IRjQL015586; Mon, 6 Nov 2006 10:27:45 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6IRjin027789; Mon, 6 Nov 2006 10:27:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:27:44 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:27:44 -0800 Message-ID: <454F7E9F.3030403@cisco.com> Date: Mon, 06 Nov 2006 13:27:43 -0500 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: Brian Stucker Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 18:27:44.0253 (UTC) FILETIME=[40562AD0:01C701D1] DKIM-Signature: a=rsa-sha1; q=dns; l=4344; t=1162837665; x=1163701665; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=09[Sipping]=09draft- stucker-sipping-early-media-coping); X=v=3Dcisco.com=3B=20h=3DDE3+4rTo8jmdmzk0dKCRoSTNsVQ=3D; b=ns4+h5kE7FnmSgFyl1j3yO0TadrGK3pZOdGwZOiaRPdwOcgyioPZA07siCYxuw04Jo5AQrZF WYYVijcm0yrA+zN39x3w8p+EbSlgID85RhJy2uAhwfgFNs6LwvcXoIln; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Cullen Jennings , Paul Kyzivat , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think it would be far better to define a URN namespace for ringtones and use local configuration to map those to specific files. What you are proposing will only work in the most closed and homogeneous environments. -Jonahtan R. Brian Stucker wrote: > That's one use... Here's another: > > I've seen Alert-Info used for distinctive ringing where the URL in the > Alert-Info specifies a resource local to the terminator that is known to > the server and the end client. > > That probably sounds a bit crazy, so here's an example: > > Let's say the terminator has previously specified that they wish to hear > ring pattern A when someone inside an enterprise calls them, and ring > pattern B when someone outside the enterprise is calling. As a result, > you might get implementations that do the following in order to prevent > managing dial-plan information on the terminator's end-device: > > If the call is from within the enterprise: > > Alert-Info: http://127.0.0.1/ringpattern-a.wav > > If the call is from outside the enterprise: > > Alert-Info: http://127.0.0.1/ringpattern-b.wav > > In either case, these are sent to the terminator. Luckily, this doesn't > have an early media impact. However, in the case of colorful ringback, > where you hear something other than "ring-ring" when making a call, the > same logic above could be used in the reverse direction towards the > originator. When does the originator do what if it gets this back, plus > some early media from a gateway somewhere? > > The header is in 3261. It clearly has some issues around it's operation > and interaction with other forms of early media. We should nerf it, > deprecate it, or explain under what conditions it should be used so > there's a decent chance of someone using it getting what they expected. > > Regards, > Brian > > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Friday, November 03, 2006 9:19 PM >>To: Cullen Jennings >>Cc: sipping >>Subject: Utility of Alert-Info (was: Re: [Sipping] >>draft-stucker-sipping-early-media-coping) >> >> >> >>Cullen Jennings wrote: >> >> >>>For example - you very correctly point out that the >> >>Alert-Info header >> >>>can only be used where the source of the header is trusted >> >>- however, >> >>>I can't imagine any case where this was true and the >> >>Alter-Info header >> >>>was useful and suspect that mostly it was not used - or >> >>that at least >> >>>where it was used there was huge security holes. >> >>I have been party to discussions of a use that seems to be >>safe and useful: >> >>The Alert-Info only goes between the UA and a proxy that acts >>on its behalf. The proxy strips any Alert-Info headers coming >>to it in the direction of the UA. Then the proxy may insert >>an Alert-Info header. The decision of what to insert may be >>based on black lists, white lists, or any sort of feature >>logic the proxy may choose to carry out. >> >>An advantage of this is that all the data and logic for >>making the decisions can be centralized for multiple UAs. The >>UAs themselves only need to know how to handle Alert-Info. >> >>This requires that messages only reach the UA via the proxy, >>but we know of many environments where that is the case. >> >> Paul >> >>_______________________________________________ >>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 >> > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 13:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9Ff-00075p-5Z; Mon, 06 Nov 2006 13:31:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9Fe-00072U-7m for sipping@ietf.org; Mon, 06 Nov 2006 13:31:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9FZ-0006sT-Es for sipping@ietf.org; Mon, 06 Nov 2006 13:31:18 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 10:31:13 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86227624:sNHT60661008" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6IVCpH021458; Mon, 6 Nov 2006 10:31:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6IVCin001839; Mon, 6 Nov 2006 10:31:12 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:31:12 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:31:12 -0800 Message-ID: <454F7F6F.2030803@cisco.com> Date: Mon, 06 Nov 2006 13:31:11 -0500 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: Henning Schulzrinne Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 References: <20061106081908.95BA11CC5D@delta.rtfm.com> <00AB308C-51C4-4B65-8EB4-3C0A44C0B7BA@cs.columbia.edu> In-Reply-To: <00AB308C-51C4-4B65-8EB4-3C0A44C0B7BA@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 18:31:12.0446 (UTC) FILETIME=[BC6DE5E0:01C701D1] DKIM-Signature: a=rsa-sha1; q=dns; l=5249; t=1162837872; x=1163701872; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Comments=20on=20draft-ietf-sipping-config-framework- 09; X=v=3Dcisco.com=3B=20h=3DtEu3k4QSktg/QOOwhiSao5I7hjA=3D; b=MqRcFPa6JVe0KzVgqtJauTcPRgpVwSFt9Fm/U7fFum2toseEdZ8Eyhi7kk9F7mCJ1e23qvQN JoDruWonM7hGPnik46PFI0g/aYMmop8IOMkxJ0WDJlMvnoifA4U53GZN; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Let me chime in here and agree with Henning and Ekr on this. I too have complained, at several past meetings, that I think the merging stuff is way too complicated and not worth the incremental benefit. For this reason most implementations remain proprietary and have not adopted this specification. -Jonathan R. Henning Schulzrinne wrote: > I think this is a good example of a draft that gets less useful by > having been around for many, many years. As years and IETF meetings > accumulate, more and more stuff gets added, without any real indication > that there is a constituency for them. Nobody seems to be paying much > attention to the draft, so there's little pushback on feature creep. > > Just as for consent and in SIMPLE, I think it's time to step back and > see if we can't get 90% of the benefit with 10% of the effort, and > maybe scoping the problem so that other features can be added later, if > there is demonstrated demand for them. Unfortunately, this draft has > become a posterchild on why people consider SIP to be far too complex. > > I had said this before, but I'll repeat that I still find the merging > stuff far too messy and unpredictable to be useful. (It is difficult > for any of the parties to know what exactly happened in the end, making > debugging and troubleshooting difficult.) A simple alternative is to > designate parameters for each role and only allow certain entities to > set them. > > The old saying went that a draft isn't finished until there's nothing > left to take out. I don't think we've even tried to have this discussion. > > Henning > > On Nov 6, 2006, at 12:19 AM, EKR wrote: > >> $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25 >> 18:52:13 ekr Exp $ >> >> I'm fairly naive about SIP UAs and configuration, but this document >> strikes me as an extremely complex approach to what's really a fairly >> simple problem. As I understand the problem space from reading the >> draft, there are four main use cases: >> >> (1) Plug a naive (out of the box) SIP UA into a network and have >> it "just work" like a POTS UA does with no additional configuration >> provided. >> (2) Have a user be able to provide some identifying information >> about a SIP UA (E.g., the MAC address) to some management >> console and then have the UA be able to configure itself. >> Arguably this is a subcase of (1). >> (3) Have a user be able to register with some SIP service provider >> via some undefined out-of-band mechanism and have that service >> provider give them a URL and some authentication credentials >> which they can feed to their UA and their UA can use to get >> configured. >> (4) Have a user be able to take a preconfigured SIP UA to a new >> network environment and get the new network access information >> (e.g., a hotel proxy) while retaining the original configuration >> information (the AOR, keying material, etc.) >> >> Arguably, something based on this document could do this job--though >> note that this document alone cannot because it doesn't actually >> specify any of the relevant parameters--but it's not clear that >> all near the complexity in this protocol is required. In >> particular: >> >> - I don't see why it's necessary to have three tiers of configuration >> data (local network, device, and user) which must somehow be merged. >> In the first three cases, ISTM that you really only have one tier >> and in the fourth there is only some very limited set of well- defined >> information, namely the local proxy. It's not like you want a >> hotel proxy to even be able to specify what you should be using >> as your SIP AOR! >> >> - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA >> can get its profile either via SIP or via an external reference >> in a NOTIFY. Let's keep life simple. >> >> - The mechanisms for discovering the URI seem extremely complicated. >> Currently, there are different mechanisms for each of the three >> URI types. If we collapse this down to a single type then is >> there some reason we can't use the SIP DHCP option? >> >> -Ekr >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 13:46:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9TZ-0002Ve-Iq; Mon, 06 Nov 2006 13:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9TX-0002L2-Hz for sipping@ietf.org; Mon, 06 Nov 2006 13:45:39 -0500 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9TT-00009v-6Z for sipping@ietf.org; Mon, 06 Nov 2006 13:45:39 -0500 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.0.685.10; Mon, 6 Nov 2006 10:45:34 -0800 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Mon, 6 Nov 2006 10:45:34 -0800 From: Rajesh Ramanathan To: "sipping@ietf.org" Date: Mon, 6 Nov 2006 10:44:39 -0800 Thread-Topic: Comments on new Sipping drafts - 605, 303? Thread-Index: AccB0508HgT+hbg4QlOaNWMlXS6zmA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [Sipping] Comments on new Sipping drafts - 605, 303? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454799750==" Errors-To: sipping-bounces@ietf.org --===============1454799750== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D4C7DFGRTDANEMSGe_" --_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D4C7DFGRTDANEMSGe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I haven't seen any comments on the following two drafts that were submitted= some time ago. http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt Anyone have comments/feedback on this? Thanks Rajesh Ramanathan Microsoft Corporation --_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D4C7DFGRTDANEMSGe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I haven’t seen any comments on the following = two drafts that were submitted some time ago.

 

h= ttp://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt

h= ttp://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt

 

Anyone have comments/feedback on this?

 

Thanks

Rajesh Ramanathan

Microsoft Corporation

 

--_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D4C7DFGRTDANEMSGe_-- --===============1454799750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1454799750==-- From sipping-bounces@ietf.org Mon Nov 06 13:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9WQ-0004BH-NJ; Mon, 06 Nov 2006 13:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9WO-0004BB-Eq for sipping@ietf.org; Mon, 06 Nov 2006 13:48:36 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9WK-0000Qn-JM for sipping@ietf.org; Mon, 06 Nov 2006 13:48:36 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 10:48:32 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="86234714:sNHT54268479" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6ImVm4010003; Mon, 6 Nov 2006 10:48:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA6ImVW4009284; Mon, 6 Nov 2006 10:48:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:48:31 -0800 Received: from [10.21.144.115] ([10.21.144.115]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:48:31 -0800 Message-ID: <454F837E.1010504@cisco.com> Date: Mon, 06 Nov 2006 13:48:30 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Stucker Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 18:48:31.0475 (UTC) FILETIME=[27BD2430:01C701D4] DKIM-Signature: a=rsa-sha1; q=dns; l=4507; t=1162838912; x=1163702912; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=20[Sipping]=09draft- stucker-sipping-early-media-coping); X=v=3Dcisco.com=3B=20h=3DEznzXFZQhtZUeHYSqv1syHt5RL0=3D; b=KxblHW13Dm8KrVLZy7rmuS2Nrj5V3LQOJ1rtJ+fs311rEGI6hj3Oq0ptdO0nwqDYk+mZE9k5 FxDHuScqEeSDkv6/0zqKvYVaXSVdkICsV/RkJ3GKFGY+SkGjW4rx26M/; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brian, The case you specify is almost the same case I am talking about, but make more specific. I didn't say anything about what values the specific URIs should be. I think there are three interesting categories: 1) a URL of a remote resource that the UAS may actually retrieve and render 2) a URL of a resource local to the UAS. 3) a URN, that simply specifies a name of a particular alerting style. The UAS must know what to do for one of these to use it, or have its own way of discovering that given the URN. I have seen (2) used, but usually as an alternative for (3) in that it isn't really expected that the UAS will necessarily have something stored in exactly this way. I find (2) to be unreasonable in most deployments, and (3) to be a much more reasonable approach, that has equivalent functionality. This is all orthogonal to how trustworthiness of Alert-Info headers is managed. I find it difficult to imagine any cases when the UAS would want to honor a value sent by the UAC. Paul Brian Stucker wrote: > That's one use... Here's another: > > I've seen Alert-Info used for distinctive ringing where the URL in the > Alert-Info specifies a resource local to the terminator that is known to > the server and the end client. > > That probably sounds a bit crazy, so here's an example: > > Let's say the terminator has previously specified that they wish to hear > ring pattern A when someone inside an enterprise calls them, and ring > pattern B when someone outside the enterprise is calling. As a result, > you might get implementations that do the following in order to prevent > managing dial-plan information on the terminator's end-device: > > If the call is from within the enterprise: > > Alert-Info: http://127.0.0.1/ringpattern-a.wav > > If the call is from outside the enterprise: > > Alert-Info: http://127.0.0.1/ringpattern-b.wav > > In either case, these are sent to the terminator. Luckily, this doesn't > have an early media impact. However, in the case of colorful ringback, > where you hear something other than "ring-ring" when making a call, the > same logic above could be used in the reverse direction towards the > originator. When does the originator do what if it gets this back, plus > some early media from a gateway somewhere? > > The header is in 3261. It clearly has some issues around it's operation > and interaction with other forms of early media. We should nerf it, > deprecate it, or explain under what conditions it should be used so > there's a decent chance of someone using it getting what they expected. > > Regards, > Brian > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, November 03, 2006 9:19 PM >> To: Cullen Jennings >> Cc: sipping >> Subject: Utility of Alert-Info (was: Re: [Sipping] >> draft-stucker-sipping-early-media-coping) >> >> >> >> Cullen Jennings wrote: >> >>> For example - you very correctly point out that the >> Alert-Info header >>> can only be used where the source of the header is trusted >> - however, >>> I can't imagine any case where this was true and the >> Alter-Info header >>> was useful and suspect that mostly it was not used - or >> that at least >>> where it was used there was huge security holes. >> I have been party to discussions of a use that seems to be >> safe and useful: >> >> The Alert-Info only goes between the UA and a proxy that acts >> on its behalf. The proxy strips any Alert-Info headers coming >> to it in the direction of the UA. Then the proxy may insert >> an Alert-Info header. The decision of what to insert may be >> based on black lists, white lists, or any sort of feature >> logic the proxy may choose to carry out. >> >> An advantage of this is that all the data and logic for >> making the decisions can be centralized for multiple UAs. The >> UAs themselves only need to know how to handle Alert-Info. >> >> This requires that messages only reach the UA via the proxy, >> but we know of many environments where that is the case. >> >> Paul >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 14:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9ni-0000Yi-Up; Mon, 06 Nov 2006 14:06:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9nf-0000Tq-5x for sipping@ietf.org; Mon, 06 Nov 2006 14:06:27 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9ek-00019C-Vz for sipping@ietf.org; Mon, 06 Nov 2006 13:57:18 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8B0043SONKJD@siemenscomms.co.uk> for sipping@ietf.org; Mon, 06 Nov 2006 18:57:20 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG873C>; Mon, 06 Nov 2006 18:57:09 +0000 Content-return: allowed Date: Mon, 06 Nov 2006 18:57:08 +0000 From: "Elwell, John" To: sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A4B25E8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sipping] Way forward on draft-munakata-sipping-privacy-clarified X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org In view of the lack of implementations of all but "id" in the Privacy header field, I would favour deprecating the other methods and carrying out any necessary clarifications relating to "id". In addition we should work on UA-based solutions. John _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 14:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9yN-0005Ov-Pw; Mon, 06 Nov 2006 14:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9yL-0005KY-P4 for sipping@ietf.org; Mon, 06 Nov 2006 14:17:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9yK-0003el-Ef for sipping@ietf.org; Mon, 06 Nov 2006 14:17:29 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 11:17:24 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFIYT0WrR7O6WWdsb2JhbACMQAEUDis X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="448341303:sNHT26431056" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6JHOQu005157 for ; Mon, 6 Nov 2006 11:17:24 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6JHOin009173 for ; Mon, 6 Nov 2006 11:17:24 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:17:24 -0800 Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:17:23 -0800 Message-ID: <454F8A43.8000400@cisco.com> Date: Mon, 06 Nov 2006 14:17:23 -0500 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: Cullen Jennings References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> In-Reply-To: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 19:17:23.0932 (UTC) FILETIME=[305D19C0:01C701D8] DKIM-Signature: a=rsa-sha1; q=dns; l=1258; t=1162840644; x=1163704644; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20draft-rosenberg-sipping-overload-reqs=20recovery; X=v=3Dcisco.com=3B=20h=3D/dXGc1TknZs+mVCq7jbtUsKSykM=3D; b=LWWiVV9ElqnaGBBPaPN3dHk17V5xAKM2RnJdJtVVk7xW15CATHQbJaOX+sv43iPwWUUoj7h8 j3DDEjqqqQB3bxNnt5K0gvzWh43a9iC82G+jZ9u88YHbD/HlFHxKUnCE; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sipping Subject: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Cullen Jennings wrote: > > A possible additional requirement.... > > Imagine a system (perhaps a single proxy) that could do 100cps. It is > in steady state doing 80cps with very few retransmission. Then for 5 > minutes the incoming requests goes to 500cps then drops back to an > incoming call rate of 80cps. The question is, how long before the > system gets back to the state where it if is successfully processing > all the 80cps? As soon as it can. Are you suggesting a requirement here? Seems like this is an implementation thing and wouldn't impact any protocol mechanisms. > > I have seen systems that never recover - that is bad. I think one of > the design goals is that it is at least possible to build to systems > that recover back to steady state relatively quickly after an overload > impulse. Sure; but I'm not sure I see the protocol requirement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 15:22:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAxV-0006f6-LY; Mon, 06 Nov 2006 15:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAxU-0006al-4U; Mon, 06 Nov 2006 15:20:40 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAxP-0002Tj-O7; Mon, 06 Nov 2006 15:20:40 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA6KKYL2012749; Mon, 6 Nov 2006 14:20:35 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 14:20:34 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 21:20:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 6 Nov 2006 21:20:26 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: 489 status code Thread-Index: AccBxIdrtd5YWEX5Rx+kq0PVMLxg1gAG4ihg From: "Drage, Keith \(Keith\)" To: "Adam Roach" X-OriginalArrivalTime: 06 Nov 2006 20:20:27.0873 (UTC) FILETIME=[FFC4AD10:01C701E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, sipping@ietf.org Subject: [Sipping] RE: [Sip] Re: 489 status code X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org (As SIP WG chair) See http://www.iana.org/assignments/sip-parameters for a list of currently assigned response codes (with 489 allocated already as Adam indicates). As definition of a new response code requires a SIP WG document, can I suggest that only such documents make any attempt to assign a response code value - I know this can be useful because the examples have to show it. If your document is not one of these, use 4xx or something else that can be replaced later. I notice also drafts in SIPPING group attempting to assign response codes. Regards Keith =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 November 2006 21:51 > To: Gonzalo Camarillo > Cc: sip@ietf.org; adam.roach@ericsson.com; Jonathan Rosemberg > Subject: [Sip] Re: 489 status code >=20 > On July 31, 2001, Gonzalo Camarillo wrote: > > A minor comment about 489 status code: In Adam's event=20 > draft it means=20 > > "Bad Event", and in Jonathan's early media draft it means "Request=20 > > Updated". Since both are just I-Ds this is not really an=20 > issue right=20 > > now, but when they advance to RFCs we will have to resolve this=20 > > conflict. >=20 > ...and in draft-gurbani-sip-large-udp-response-00, it means=20 > "Use Congestion Controlled Transport." >=20 > I'd offer to move mine somewhere else, but it's been=20 > published as an RFC already. >=20 > /a >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 16:44:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCF6-00079b-UH; Mon, 06 Nov 2006 16:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCF5-000774-7H for sipping@ietf.org; Mon, 06 Nov 2006 16:42:55 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCDn-0006is-Nt for sipping@ietf.org; Mon, 06 Nov 2006 16:41:39 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA6Lf9x5013709; Mon, 6 Nov 2006 15:41:09 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 15:41:09 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Nov 2006 22:41:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Date: Mon, 6 Nov 2006 22:41:05 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072B80C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on new Sipping drafts - 605, 303? Thread-Index: AccB0508HgT+hbg4QlOaNWMlXS6zmAAF0z5g From: "Drage, Keith \(Keith\)" To: "Rajesh Ramanathan" , X-OriginalArrivalTime: 06 Nov 2006 21:41:07.0482 (UTC) FILETIME=[446667A0:01C701EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Well, =20 I know these are only response codes, but they do seem to be a bit thin on motivation. Perhaps if you look at RFC 4485 you will see some instructions for formatting SIP specifying drafts, which tells you the structure of the document and what sections are required. You may also want to look at: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-03.txt As an example of a completed draft that defines a new response code. Note that while these documents should stay in SIPPING until you have convinced people of the need for these response codes, it will eventually have to transfer to SIP to be progressed. See also mail I sent earlier today on when the number should be assigned to response codes. Finally in several places you have statements that say things like: The 605 looks identical to the 603 in all respects, except that the response code has a very special meaning for the proxy. Proxys that do not support 605 are expected to treat this as a 603 and send the response all the back to the client. Rather any entity that does not implement these extensions will default to RFC 3261 behaviour which in proxy case is to pass on, and in UA case is to treat as the X00 response code when XYY is received. Regards Keith ________________________________ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 18:45 To: sipping@ietf.org Subject: [Sipping] Comments on new Sipping drafts - 605, 303?=20 =09 =09 Hi all, =20 I haven't seen any comments on the following two drafts that were submitted some time ago. =20 http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt =20 Anyone have comments/feedback on this? =20 Thanks Rajesh Ramanathan Microsoft Corporation =20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 17:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD4G-0006Gv-TU; Mon, 06 Nov 2006 17:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD4F-0006Gp-0P for sipping@ietf.org; Mon, 06 Nov 2006 17:35:47 -0500 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD4D-0007ID-OO for sipping@ietf.org; Mon, 06 Nov 2006 17:35:46 -0500 Received: from s73602 (dhcp66-117.ietf67.org[130.129.66.117]) by comcast.net (rwcrmhc15) with SMTP id <20061106223545m1500b6eoke>; Mon, 6 Nov 2006 22:35:45 +0000 Message-ID: <0b9701c701f3$84373600$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: "sipping" References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> <454F8A43.8000400@cisco.com> Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Mon, 6 Nov 2006 14:32:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, Jonathan, From: "Jonathan Rosenberg" > > Cullen Jennings wrote: > >> >> A possible additional requirement.... >> >> Imagine a system (perhaps a single proxy) that could do 100cps. It is in >> steady state doing 80cps with very few retransmission. Then for 5 >> minutes the incoming requests goes to 500cps then drops back to an >> incoming call rate of 80cps. The question is, how long before the system >> gets back to the state where it if is successfully processing all the >> 80cps? > > As soon as it can. Are you suggesting a requirement here? Seems like this > is an implementation thing and wouldn't impact any protocol mechanisms. > >> >> I have seen systems that never recover - that is bad. I think one of the >> design goals is that it is at least possible to build to systems that >> recover back to steady state relatively quickly after an overload >> impulse. > > Sure; but I'm not sure I see the protocol requirement. I may have read too much into Cullen's note, but what *I* thought was being discussed was a "net" incoming rate of 500 cps, and what I thought Cullen was saying was that when the "net" incoming rate drops back to 80 cps, the system should not continue to present a "gross" (new requests + retransmitted requests) incoming rate of 500 cps for a very long time. That seemed more of a protocol requirement than just saying "please don't fall over and not get up". Thanks, Spencer _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 18:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQo-0004C0-Vg; Mon, 06 Nov 2006 17:59:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQY-0003oO-Dv for sipping@ietf.org; Mon, 06 Nov 2006 17:58:50 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDEP-0000D1-Hy for sipping@ietf.org; Mon, 06 Nov 2006 17:46:22 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8B00B8TZ8XY1@siemenscomms.co.uk> for sipping@ietf.org; Mon, 06 Nov 2006 22:46:09 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG8869>; Mon, 06 Nov 2006 22:45:58 +0000 Content-return: allowed Date: Mon, 06 Nov 2006 22:45:57 +0000 From: "Elwell, John" Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? To: Rajesh Ramanathan , sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A4B2617@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1521013832==" Errors-To: sipping-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. --===============1521013832== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_vhaHQdgKT16a9xBovPQXcA)" 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_vhaHQdgKT16a9xBovPQXcA) Content-type: text/plain Content-transfer-encoding: 7BIT Rajesh, Concerning 605, RFC 3261 already says that CANCEL SHOULD be sent on each branch, so I see hardly any difference between 605 and 603. John _____ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 18:45 To: sipping@ietf.org Subject: [Sipping] Comments on new Sipping drafts - 605, 303? Hi all, I haven't seen any comments on the following two drafts that were submitted some time ago. http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt Anyone have comments/feedback on this? Thanks Rajesh Ramanathan Microsoft Corporation --Boundary_(ID_vhaHQdgKT16a9xBovPQXcA) Content-type: text/html Content-transfer-encoding: 7BIT
Rajesh,
 
Concerning 605, RFC 3261 already says that CANCEL SHOULD be sent on each branch, so I see hardly any difference between 605 and 603.
 
John

From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com]
Sent: 06 November 2006 18:45
To: sipping@ietf.org
Subject: [Sipping] Comments on new Sipping drafts - 605, 303?

Hi all,

 

I haven’t seen any comments on the following two drafts that were submitted some time ago.

 

http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt

http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt

 

Anyone have comments/feedback on this?

 

Thanks

Rajesh Ramanathan

Microsoft Corporation

 

--Boundary_(ID_vhaHQdgKT16a9xBovPQXcA)-- --===============1521013832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1521013832==-- From sipping-bounces@ietf.org Mon Nov 06 18:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE3p-0003sg-Kz; Mon, 06 Nov 2006 18:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE3n-0003sa-T6 for sipping@ietf.org; Mon, 06 Nov 2006 18:39:23 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhE3m-00073o-HG for sipping@ietf.org; Mon, 06 Nov 2006 18:39:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA6Nd4112976; Mon, 6 Nov 2006 18:39:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Mon, 6 Nov 2006 17:39:03 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA98@zrc2hxm2.corp.nortel.com> In-Reply-To: <454F7E9F.3030403@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: AccB0UWqQ63LnVZrRFSkZ5wkxCsOKwABbbrA From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Cullen Jennings , Paul Kyzivat , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I'm not proposing using it.=20 I'm giving it as an example of how it's already being used. Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, November 06, 2006 10:28 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Paul Kyzivat; Cullen Jennings; sipping > Subject: Re: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 > I think it would be far better to define a URN namespace for=20 > ringtones and use local configuration to map those to=20 > specific files. What you are proposing will only work in the=20 > most closed and homogeneous environments. >=20 > -Jonahtan R. >=20 > Brian Stucker wrote: >=20 > > That's one use... Here's another: > >=20 > > I've seen Alert-Info used for distinctive ringing where the=20 > URL in the=20 > > Alert-Info specifies a resource local to the terminator=20 > that is known=20 > > to the server and the end client. > >=20 > > That probably sounds a bit crazy, so here's an example: > >=20 > > Let's say the terminator has previously specified that they wish to=20 > > hear ring pattern A when someone inside an enterprise calls=20 > them, and=20 > > ring pattern B when someone outside the enterprise is calling. As a=20 > > result, you might get implementations that do the following=20 > in order=20 > > to prevent managing dial-plan information on the=20 > terminator's end-device: > >=20 > > If the call is from within the enterprise: > >=20 > > Alert-Info: http://127.0.0.1/ringpattern-a.wav > >=20 > > If the call is from outside the enterprise: > >=20 > > Alert-Info: http://127.0.0.1/ringpattern-b.wav > >=20 > > In either case, these are sent to the terminator. Luckily, this=20 > > doesn't have an early media impact. However, in the case of=20 > colorful=20 > > ringback, where you hear something other than "ring-ring"=20 > when making=20 > > a call, the same logic above could be used in the reverse direction=20 > > towards the originator. When does the originator do what if it gets=20 > > this back, plus some early media from a gateway somewhere? > >=20 > > The header is in 3261. It clearly has some issues around it's=20 > > operation and interaction with other forms of early media.=20 > We should=20 > > nerf it, deprecate it, or explain under what conditions it=20 > should be=20 > > used so there's a decent chance of someone using it getting=20 > what they expected. > >=20 > > Regards, > > Brian > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Friday, November 03, 2006 9:19 PM > >>To: Cullen Jennings > >>Cc: sipping > >>Subject: Utility of Alert-Info (was: Re: [Sipping] > >>draft-stucker-sipping-early-media-coping) > >> > >> > >> > >>Cullen Jennings wrote: > >> > >> > >>>For example - you very correctly point out that the > >> > >>Alert-Info header > >> > >>>can only be used where the source of the header is trusted > >> > >>- however, > >> > >>>I can't imagine any case where this was true and the > >> > >>Alter-Info header > >> > >>>was useful and suspect that mostly it was not used - or > >> > >>that at least > >> > >>>where it was used there was huge security holes. > >> > >>I have been party to discussions of a use that seems to be safe and=20 > >>useful: > >> > >>The Alert-Info only goes between the UA and a proxy that=20 > acts on its=20 > >>behalf. The proxy strips any Alert-Info headers coming to it in the=20 > >>direction of the UA. Then the proxy may insert an=20 > Alert-Info header.=20 > >>The decision of what to insert may be based on black lists, white=20 > >>lists, or any sort of feature logic the proxy may choose to=20 > carry out. > >> > >>An advantage of this is that all the data and logic for making the=20 > >>decisions can be centralized for multiple UAs. The UAs=20 > themselves only=20 > >>need to know how to handle Alert-Info. > >> > >>This requires that messages only reach the UA via the proxy, but we=20 > >>know of many environments where that is the case. > >> > >> Paul > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP Use=20 > >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>sip@ietf.org for new developments of core SIP > >> > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 18:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEMQ-0006Sc-Vu; Mon, 06 Nov 2006 18:58:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEMP-0006SX-I5 for sipping@ietf.org; Mon, 06 Nov 2006 18:58:37 -0500 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEMJ-0002Nx-UI for sipping@ietf.org; Mon, 06 Nov 2006 18:58:37 -0500 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.0.685.10; Mon, 6 Nov 2006 15:58:31 -0800 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Mon, 6 Nov 2006 15:58:31 -0800 From: Rajesh Ramanathan To: "Elwell, John" , "sipping@ietf.org" Date: Mon, 6 Nov 2006 15:57:32 -0800 Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Thread-Topic: [Sipping] Comments on new Sipping drafts - 605, 303? Thread-Index: AccB9VVkfNQie19nRLGYqEl82HRB9AACUXlg Message-ID: References: <50B1CBA96870A34799A506B2313F26670A4B2617@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A4B2617@ntht201e.siemenscomms.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160151237==" Errors-To: sipping-bounces@ietf.org --===============0160151237== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D641DFGRTDANEMSGe_" --_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D641DFGRTDANEMSGe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the response The difference lies in how we treat staged ringing, or unanswered forwardin= g (such as voicemail). In one case we still allow staged ringing (603), in = other case the call is declined completely. (Scenario #2 spells out what 60= 3 does and Scenario #4 covers the intention of 605) So even if you say that Scenario #4 is covered by 603, we will leave Scenar= io #2 unsolved. Rajesh From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, November 06, 2006 2:46 PM To: Rajesh Ramanathan; sipping@ietf.org Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Rajesh, Concerning 605, RFC 3261 already says that CANCEL SHOULD be sent on each br= anch, so I see hardly any difference between 605 and 603. John ________________________________ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 18:45 To: sipping@ietf.org Subject: [Sipping] Comments on new Sipping drafts - 605, 303? Hi all, I haven't seen any comments on the following two drafts that were submitted= some time ago. http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt Anyone have comments/feedback on this? Thanks Rajesh Ramanathan Microsoft Corporation --_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D641DFGRTDANEMSGe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the response

 

The difference lies in how we treat staged ringing, or unanswer= ed forwarding (such as voicemail). In one case we still allow staged ringing (603), in other case the call is declined completely. (Scenario #2 spells o= ut what 603 does and Scenario #4 covers the intention of 605)


So even if you say that Scenario #4 is covered by 603, we will leave Scenar= io #2 unsolved.

 

Rajesh

 

From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, November 06, 2006 2:46 PM
To: Rajesh Ramanathan; sipping@ietf.org
Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303?

 

Rajesh,

 

Concerning 605, RFC 3261 already says that CANCEL SHOULD be sen= t on each branch, so I see hardly any difference between 605 and 603.

 

John

 

From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com]
Sent: 06 November 2006 18:45
To: sipping@ietf.org
Subject: [Sipping] Comments on new Sipping drafts - 605, 303?=

Hi all,

 

I haven’t seen any comments on the following = two drafts that were submitted some time ago.

 

h= ttp://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt

h= ttp://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt

 

Anyone have comments/feedback on this?

 

Thanks

Rajesh Ramanathan

Microsoft Corporation

 

--_000_DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D641DFGRTDANEMSGe_-- --===============0160151237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0160151237==-- From sipping-bounces@ietf.org Mon Nov 06 19:23:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEk1-000385-Sx; Mon, 06 Nov 2006 19:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEk0-00037H-F4 for sipping@ietf.org; Mon, 06 Nov 2006 19:23:00 -0500 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEjw-0000ot-VX for sipping@ietf.org; Mon, 06 Nov 2006 19:23:00 -0500 Received: from DF-BHD-04.exchange.corp.microsoft.com (157.54.63.169) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.10; Mon, 6 Nov 2006 16:22:56 -0800 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by DF-BHD-04.exchange.corp.microsoft.com ([157.54.63.169]) with mapi; Mon, 6 Nov 2006 16:22:56 -0800 From: Rajesh Ramanathan To: "Drage, Keith (Keith)" , "sipping@ietf.org" Date: Mon, 6 Nov 2006 16:22:00 -0800 Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Thread-Topic: [Sipping] Comments on new Sipping drafts - 605, 303? Thread-Index: AccB0508HgT+hbg4QlOaNWMlXS6zmAAF0z5gAAU8BqA= Message-ID: References: <5D1A7985295922448D5550C94DE2918072B80C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B80C@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thanks for the comments. I will work on making the drafts more clear. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Monday, November 06, 2006 1:41 PM To: Rajesh Ramanathan; sipping@ietf.org Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Well, I know these are only response codes, but they do seem to be a bit thin on motivation. Perhaps if you look at RFC 4485 you will see some instructions for formatting SIP specifying drafts, which tells you the structure of the document and what sections are required. You may also want to look at: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-03.txt As an example of a completed draft that defines a new response code. Note that while these documents should stay in SIPPING until you have convinced people of the need for these response codes, it will eventually have to transfer to SIP to be progressed. See also mail I sent earlier today on when the number should be assigned to response codes. Finally in several places you have statements that say things like: The 605 looks identical to the 603 in all respects, except that the response code has a very special meaning for the proxy. Proxys that do not support 605 are expected to treat this as a 603 and send the response all the back to the client. Rather any entity that does not implement these extensions will default to RFC 3261 behaviour which in proxy case is to pass on, and in UA case is to treat as the X00 response code when XYY is received. Regards Keith ________________________________ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 18:45 To: sipping@ietf.org Subject: [Sipping] Comments on new Sipping drafts - 605, 303? Hi all, I haven't seen any comments on the following two drafts that were submitted some time ago. http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt Anyone have comments/feedback on this? Thanks Rajesh Ramanathan Microsoft Corporation _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 20:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG8h-0003p6-6A; Mon, 06 Nov 2006 20:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG8f-0003p1-FQ for sipping@ietf.org; Mon, 06 Nov 2006 20:52:33 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhG8b-0004Eu-Pd for sipping@ietf.org; Mon, 06 Nov 2006 20:52:33 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8C00E3Y7VHFC@siemenscomms.co.uk> for sipping@ietf.org; Tue, 07 Nov 2006 01:52:29 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG89VC>; Tue, 07 Nov 2006 01:52:18 +0000 Content-return: allowed Date: Tue, 07 Nov 2006 01:52:18 +0000 From: "Elwell, John" Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? To: Rajesh Ramanathan , sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A4B261E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827677270==" Errors-To: sipping-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. --===============0827677270== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_f52DnJzIhS3j4bKuhn4Oww)" 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_f52DnJzIhS3j4bKuhn4Oww) Content-type: text/plain Content-transfer-encoding: 7BIT Rajesh, I am not sure I understand your scenarios correctly, but 603 at present will cancel all current branches and not permit any new branches, and hence it would not allow the call to be answered by voicemail. So 603 already covers your scenario 4, and there is no need for 605. I agree that your scenario 2 is perhaps not covered, but your draft seems to propose 605 for scenario 4, not for scenario 2. John _____ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 23:58 To: Elwell, John; sipping@ietf.org Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Thanks for the response The difference lies in how we treat staged ringing, or unanswered forwarding (such as voicemail). In one case we still allow staged ringing (603), in other case the call is declined completely. (Scenario #2 spells out what 603 does and Scenario #4 covers the intention of 605) So even if you say that Scenario #4 is covered by 603, we will leave Scenario #2 unsolved. Rajesh From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, November 06, 2006 2:46 PM To: Rajesh Ramanathan; sipping@ietf.org Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303? Rajesh, Concerning 605, RFC 3261 already says that CANCEL SHOULD be sent on each branch, so I see hardly any difference between 605 and 603. John _____ From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com] Sent: 06 November 2006 18:45 To: sipping@ietf.org Subject: [Sipping] Comments on new Sipping drafts - 605, 303? Hi all, I haven't seen any comments on the following two drafts that were submitted some time ago. http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt Anyone have comments/feedback on this? Thanks Rajesh Ramanathan Microsoft Corporation --Boundary_(ID_f52DnJzIhS3j4bKuhn4Oww) Content-type: text/html Content-transfer-encoding: 7BIT
Rajesh,
 
I am not sure I understand your scenarios correctly, but 603 at present will cancel all current branches and not permit any new branches, and hence it would not allow the call to be answered by voicemail. So 603 already covers your scenario 4, and there is no need for 605. I agree that your scenario 2 is perhaps not covered, but your draft seems to propose 605 for scenario 4, not for scenario 2.
 
John

From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com]
Sent: 06 November 2006 23:58
To: Elwell, John; sipping@ietf.org
Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303?

Thanks for the response

 

The difference lies in how we treat staged ringing, or unanswered forwarding (such as voicemail). In one case we still allow staged ringing (603), in other case the call is declined completely. (Scenario #2 spells out what 603 does and Scenario #4 covers the intention of 605)


So even if you say that Scenario #4 is covered by 603, we will leave Scenario #2 unsolved.

 

Rajesh

 

From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, November 06, 2006 2:46 PM
To: Rajesh Ramanathan; sipping@ietf.org
Subject: RE: [Sipping] Comments on new Sipping drafts - 605, 303?

 

Rajesh,

 

Concerning 605, RFC 3261 already says that CANCEL SHOULD be sent on each branch, so I see hardly any difference between 605 and 603.

 

John

 

From: Rajesh Ramanathan [mailto:rajeshra@exchange.microsoft.com]
Sent: 06 November 2006 18:45
To: sipping@ietf.org
Subject: [Sipping] Comments on new Sipping drafts - 605, 303?

Hi all,

 

I haven’t seen any comments on the following two drafts that were submitted some time ago.

 

http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt

http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt

 

Anyone have comments/feedback on this?

 

Thanks

Rajesh Ramanathan

Microsoft Corporation

 

--Boundary_(ID_f52DnJzIhS3j4bKuhn4Oww)-- --===============0827677270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0827677270==-- From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGy0-0002UI-NG; Mon, 06 Nov 2006 21:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxz-0002Tv-80 for sipping@ietf.org; Mon, 06 Nov 2006 21:45:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxx-0003Je-SK for sipping@ietf.org; Mon, 06 Nov 2006 21:45:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:45:33 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86440911:sNHT72356877" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jXkx009801; Mon, 6 Nov 2006 18:45:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jXW4024035; Mon, 6 Nov 2006 18:45:33 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:33 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:32 -0800 Message-ID: <454FBD34.50409@cisco.com> Date: Mon, 06 Nov 2006 17:54:44 -0500 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: Mayumi Munakata Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 References: <200611020851.kA28pWP4018451@imf.m.ecl.ntt.co.jp> In-Reply-To: <200611020851.kA28pWP4018451@imf.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:32.0863 (UTC) FILETIME=[CB6A5CF0:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=3077; t=1162867533; x=1163731533; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Discussions=20on=20draft-munakata-sipping-privacy-cl arified-00; X=v=3Dcisco.com=3B=20h=3DfX8H7ncNnKZDvjpLLdAur6MOTAc=3D; b=EDiwelWYh11owC6fhZZnGwZnWQKqoWQovWhgnYzQuxk86DvgfUzQR203zsFPNX5JopTfdpjj ReAk4IZbYIBCh9PtJ83ypsR2LWqug7GB8ljxk0sRzKb2eUuc5Bsbycuu; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Let me follow up some more to my remarks at the microphone today. We clearly have a need for privacy services in SIP, and a revision of RFC 3323 is warranted. What I think such a revision should do is: 1. give guidance on how a UA can construct a completely anonymous request, utilizing anonymous gruu and using TURN to obtain IP addresses and ports for media relay. This would need to have guidance on various header fields, as rfc 3323 does today. However the context there is how to construct (or omit) them, rather for guidance on removal or manipulation. 2. Once you define (1), the additional service you need from the network is not to insert aFrom sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGy0-0002UI-NG; Mon, 06 Nov 2006 21:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxz-0002Tv-80 for sipping@ietf.org; Mon, 06 Nov 2006 21:45:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxx-0003Je-SK for sipping@ietf.org; Mon, 06 Nov 2006 21:45:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:45:33 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86440911:sNHT72356877" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jXkx009801; Mon, 6 Nov 2006 18:45:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jXW4024035; Mon, 6 Nov 2006 18:45:33 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:33 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:32 -0800 Message-ID: <454FBD34.50409@cisco.com> Date: Mon, 06 Nov 2006 17:54:44 -0500 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: Mayumi Munakata Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 References: <200611020851.kA28pWP4018451@imf.m.ecl.ntt.co.jp> In-Reply-To: <200611020851.kA28pWP4018451@imf.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:32.0863 (UTC) FILETIME=[CB6A5CF0:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=3077; t=1162867533; x=1163731533; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Discussions=20on=20draft-munakata-sipping-privacy-cl arified-00; X=v=3Dcisco.com=3B=20h=3DfX8H7ncNnKZDvjpLLdAur6MOTAc=3D; b=EDiwelWYh11owC6fhZZnGwZnWQKqoWQovWhgnYzQuxk86DvgfUzQR203zsFPNX5JopTfdpjj ReAk4IZbYIBCh9PtJ83ypsR2LWqug7GB8ljxk0sRzKb2eUuc5Bsbycuu; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Let me follow up some more to my remarks at the microphone today. We clearly have a need for privacy services in SIP, and a revision of RFC 3323 is warranted. What I think such a revision should do is: 1. give guidance on how a UA can construct a completely anonymous request, utilizing anonymous gruu and using TURN to obtain IP addresses and ports for media relay. This would need to have guidance on various header fields, as rfc 3323 does today. However the context there is how to construct (or omit) them, rather for guidance on removal or manipulation. 2. Once you define (1), the additional service you need from the network is not to insert additional information into the request which identify the user. Thus, you need a flag that indicates the request is anonymous. We could use the Privacy: id value for this, or use the presence of an anonymous URI in the From as this flag. What I assert we do NOT want is anything more than just a single flag. We don't want specific guidance on whether its allowed to insert header foo vs. header bar. That is too complicated and I think is not useful. 3. Additionally, one might want a solution for UA which, for some reason, cannot construct messages using (1). In that case, the UA will want to invoke a privacy service in the network. I would argue that we DONT want complex features that allow the UA to micro-manage the behavior of that privacy service. As a privacy service, it does a "full-processing" on the request - removing or obfuscating anything that could reveal user identity. Thus, the only thing we need to signal is a way for a UA to invoke that service, thats it. We could use a Privacy value for that, or we could use other techniques we have developed for service invocation. For example a route header field that points to an anonymization service. I will point out that RFC 3323 itself has only seen deployment in the context of RFC 3325. That is, to my knowledge, the only value of the Privacy header ever used is "id". -Jonathan R. Mayumi Munakata wrote: > Jonathan, > > Thank you for the valuable comments. > > To my knowledge, RFC 3323 is widely deployed already, so it is > necessary to keep the mechanism and clarify it as much as possible > for the already deployed implementations. > > Your sip-identity-privacy draft may solve all the privacy problems, > but still, we need RFC 3323, even if it is a short-term solution. > > If everybody views RFC 3323 in the same way, I can change the text in > Section 4.2. (Guidelines on specifying new priv-values) to something > like "it is RECOMMENDED to avoid defining a new priv-value in future > RFCs". > > Thanks, Mayumi > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxy-0002Td-1N; Mon, 06 Nov 2006 21:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxv-0002TE-Hu for sipping@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxu-0003Iu-5T for sipping@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 18:45:28 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANaBT0WrR7PDh2dsb2JhbABEjAUBAQEIDio X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="448474001:sNHT27550212" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jS1W009720; Mon, 6 Nov 2006 18:45:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jRWO023970; Mon, 6 Nov 2006 18:45:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:26 -0800 Received: fromdditional information into the request which identify the user. Thus, you need a flag that indicates the request is anonymous. We could use the Privacy: id value for this, or use the presence of an anonymous URI in the From as this flag. What I assert we do NOT want is anything more than just a single flag. We don't want specific guidance on whether its allowed to insert header foo vs. header bar. That is too complicated and I think is not useful. 3. Additionally, one might want a solution for UA which, for some reason, cannot construct messages using (1). In that case, the UA will want to invoke a privacy service in the network. I would argue that we DONT want complex features that allow the UA to micro-manage the behavior of that privacy service. As a privacy service, it does a "full-processing" on the request - removing or obfuscating anything that could reveal user identity. Thus, the only thing we need to signal is a way for a UA to invoke that service, thats it. We could use a Privacy value for that, or we could use other techniques we have developed for service invocation. For example a route header field that points to an anonymization service. I will point out that RFC 3323 itself has only seen deployment in the context of RFC 3325. That is, to my knowledge, the only value of the Privacy header ever used is "id". -Jonathan R. Mayumi Munakata wrote: > Jonathan, > > Thank you for the valuable comments. > > To my knowledge, RFC 3323 is widely deployed already, so it is > necessary to keep the mechanism and clarify it as much as possible > for the already deployed implementations. > > Your sip-identity-privacy draft may solve all the privacy problems, > but still, we need RFC 3323, even if it is a short-term solution. > > If everybody views RFC 3323 in the same way, I can change the text in > Section 4.2. (Guidelines on specifying new priv-values) to something > like "it is RECOMMENDED to avoid defining a new priv-value in future > RFCs". > > Thanks, Mayumi > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxy-0002Td-1N; Mon, 06 Nov 2006 21:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxv-0002TE-Hu for sipping@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxu-0003Iu-5T for sipping@ietf.org; Mon, 06 Nov 2006 21:45:31 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 18:45:28 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANaBT0WrR7PDh2dsb2JhbABEjAUBAQEIDio X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="448474001:sNHT27550212" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jS1W009720; Mon, 6 Nov 2006 18:45:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jRWO023970; Mon, 6 Nov 2006 18:45:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:26 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:26 -0800 Message-ID: <454FB4BE.1080008@cisco.com> Date: Mon, 06 Nov 2006 17:18:38 -0500 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: Rajesh Ramanathan Subject: Re: [Sipping] Comments on new Sipping drafts - 605, 303? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Nov 2006 02:45:26.0801 (UTC) FILETIME=[C7CD6010:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=1767; t=1162867528; x=1163731528; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Comments=20on=20new=20Sipping=20drafts=20-=20605, =20 303?; X=v=3Dcisco.com=3B=20h=3DRa+H5TF+jOn1l0SuvvNqtq2Gns0=3D; b=oLnIopgPGm9Y/DqQ7KQNP0A5e+jHf334JiMBTnubxFqRKvzWy2lSmbVyaJ0HH1KtNiFVdA/8 QMmKuEqFfK9D8n+Fqvgs9UfF/jDnEjRxU/sXXwZx8HKNnm9uD4LRdGfE; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "sipping@ietf.org" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On the 303 draft, I could not understand the problem you were describing. Are you trying to come up with a mechanism by which a proxy receiving a redirect always recurses on it? I thought that was what you wanted, but the mechanism you describe says a proxy either recurses or forwards upstream, which is the same as currently defined for 3xx responses. So, I didnt understand what was different. My comment on the 605 draft was similar. It wasn't clear what intention you were trying to convey and why what you've defined was different than for existing 6xx behaviors. -Jonathan R. Rajesh Ramanathan wrote: > Hi all, > > > > I haven’t seen any comments on the following two drafts that were > submitted some time ago. > > > > http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt > > http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt > > > > Anyone have comments/feedback on this? > > > > Thanks > > Rajesh Ramanathan > > Microsoft Corporation > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-imp [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:26 -0800 Message-ID: <454FB4BE.1080008@cisco.com> Date: Mon, 06 Nov 2006 17:18:38 -0500 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: Rajesh Ramanathan Subject: Re: [Sipping] Comments on new Sipping drafts - 605, 303? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Nov 2006 02:45:26.0801 (UTC) FILETIME=[C7CD6010:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=1767; t=1162867528; x=1163731528; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Comments=20on=20new=20Sipping=20drafts=20-=20605, =20 303?; X=v=3Dcisco.com=3B=20h=3DRa+H5TF+jOn1l0SuvvNqtq2Gns0=3D; b=oLnIopgPGm9Y/DqQ7KQNP0A5e+jHf334JiMBTnubxFqRKvzWy2lSmbVyaJ0HH1KtNiFVdA/8 QMmKuEqFfK9D8n+Fqvgs9UfF/jDnEjRxU/sXXwZx8HKNnm9uD4LRdGfE; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "sipping@ietf.org" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On the 303 draft, I could not understand the problem you were describing. Are you trying to come up with a mechanism by which a proxy receiving a redirect always recurses on it? I thought that was what you wanted, but the mechanism you describe says a proxy either recurses or forwards upstream, which is the same as currently defined for 3xx responses. So, I didnt understand what was different. My comment on the 605 draft was similar. It wasn't clear what intention you were trying to convey and why what you've defined was different than for existing 6xx behaviors. -Jonathan R. Rajesh Ramanathan wrote: > Hi all, > > > > I haven’t seen any comments on the following two drafts that were > submitted some time ago. > > > > http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt > > http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt > > > > Anyone have comments/feedback on this? > > > > Thanks > > Rajesh Ramanathan > > Microsoft Corporation > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 lementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyS-0002bP-Q4; Mon, 06 Nov 2006 21:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyR-0002bA-2m for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGyP-0003ME-OJ for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:46:01 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86441071:sNHT48679326" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72k122020055; Mon, 6 Nov 2006 18:46:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA72j6B0016837; Mon, 6 Nov 2006 18:46:00 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:29 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:29 -0800 Message-ID: <454FB9C8.8000800@cisco.com> Date: Mon, 06 Nov 2006 17:40:08 -0500 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: "Huelsemann, Martin" Subject: Re: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:29.0285 (UTC) FILETIME=[C9486750:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=1466; t=1162867561; x=1163731561; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20AW=3A=20[Sipping]=20comments=20on=20draft-roach-sipping-callcomp -bfcp-00; X=v=3Dcisco.com=3B=20h=3DM3ODl/OfYagA97HxHhrOOkPCtGQ=3D; b=udJgLKrSt3kwV778YG05Pj12qamINN5eaWt7CJ1GySzpo/QumUPa/DbMrUT1INDG2+mF1RoH g01tmr9MN/3KPh4mdeqY6i+GANIbvrNIJ8skvS1HcNVqS1QuORa24MS4; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Huelsemann, Martin wrote: > Hi Jonathan, all, > > I don't think that there really is a relationship between presence > and call completion. Presence is about the general availibility of a > certain user, call completion provides the possibility to complete a > call to a certain destination you've got a busy error response from. I completely disagree. When you invoke the CCBS service, the ringback you get when they are "available" is exactly presence. However, in the PSTN, it is limited to the only concept of presence they have - whether you are on a call or not. In an IP world, I can be unavailable for voice service even though I'm not in a call strictly speaking. For example, if I've got five parallel IM sessions, and as a consequence, I set my voice service to "closed" through presence, what is the desired behavior of the SIP-based CCBS system? I would assert that I *dont* want the callback to come now. If it does, I won't answer it anyway since I'm busy with other things. So, the call goes to voicemail or goes unanswered. That does not seem like the desired behavior. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyT-0002bt-Gf; Mon, 06 Nov 2006 21:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyR-0002bH-T2 for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGyQ-0003ML-Hp for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 18:46:01 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="755076617:sNHT2357838674" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72k1W6012501; Mon, 6 Nov 2006 18:46:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA72j6B2016837; Mon, 6 Nov 2006 18:46:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:30 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:30 -0800 Message-ID: <454FBB5D.4060607@cisco.com> Date: Mon, 06 Nov 2006 17:46:53 -0500 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: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670A410D28@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A410D28@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:30.0176 (UTC) FILETIME=[C9D05C00:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=2273; t=1162867561; x=1163731561; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20New=20I-D=20on=20usage=20of=20phone=20numbers=20in=20SIP =20[DO=20NOT=20REPLY!=0A=20]; X=v=3Dcisco.com=3B=20h=3DEpT4jMelJ1BVR4RadKUmEjfSzVc=3D; b=ezehGU0+Se74T1eA1DDAsLYAJWN0l70xdMWJZZhr8kSWKpGoRjX86yHi4IT6QgLEZWI9X5/a xqtKM5G21RTmC3jsax/hpBMcjhepsAwq35qRa6hvvFu6ZeSMLmGQCw/U; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sipping Subject: [Sipping] Re: [Sip] New I-D on usage of phone numbers in SIP [DO NOT REPLY! ] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Elwell, John wrote: > Jonathan, > > Some good stuff in here. Thanks! > > >>The document proposes a framework and architecture for the usage of >>phone numbers with SIP. It tries to answer questions like the >>difference >>between a tel URI and SIP URI with user=phone, when to use each, what >>the meaning of concepts like LNP and freephone are in a >>pure-SIP world, >>the architectural role of ENUM, and impacts on PSTN interoperability, >>and so on. > > > I am not sure about classing a SIP URI as an address. As you say later, the > more important meaning of the domain part is as an identifier of the owner > of the namespace to which the user part belongs. It says nothing about where > this can be found (unless it is in the form of an IP address). It requires a > DNS look-up to obtain an address (IP address). Its an address in that it is bound to a specific domain and requests to it will get routed to proxies with particular IP addresses, learned through the DNS. Likewise, at least when used > as an AoR, the entire SIP URI (including the user part) identifies a > resource (a user) and does not say where that resource is to be found. Sure it does; it says it is found in the domain indicated in the RHS of the URI. I like drawing analogies to the postal service; this would be equivalent to saying something like "Joe Smith of London, England". It absolutely an address, in that it points to something through its location (London). Its just not very specific, in that you need to do some further work once you get to London. > It > requires a location server look-up to determine this. So in many respects I > think a SIP URI is much more like a name. I could put it on my business > card, in the same way I would put a phone number on my business card. Sure; both are valuable on business cards. That doesn't make them both names. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyS-0002bP-Q4; Mon, 06 Nov 2006 21:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyR-0002bA-2m for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGyP-0003ME-OJ for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:46:01 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86441071:sNHT48679326" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72k122020055; Mon, 6 Nov 2006 18:46:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA72j6B0016837; Mon, 6 Nov 2006 18:46:00 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:29 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:29 -0800 Message-ID: <454FB9C8.8000800@cisco.com> Date: Mon, 06 Nov 2006 17:40:08 -0500 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: "Huelsemann, Martin" Subject: Re: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:29.0285 (UTC) FILETIME=[C9486750:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=1466; t=1162867561; x=1163731561; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20AW=3A=20[Sipping]=20comments=20on=20draft-roach-sipping-callcomp -bfcp-00; X=v=3Dcisco.com=3B=20h=3DM3ODl/OfYagA97HxHhrOOkPCtGQ=3D; b=udJgLKrSt3kwV778YG05Pj12qamINN5eaWt7CJ1GySzpo/QumUPa/DbMrUT1INDG2+mF1RoH g01tmr9MN/3KPh4mdeqY6i+GANIbvrNIJ8skvS1HcNVqS1QuORa24MS4; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Huelsemann, Martin wrote: > Hi Jonathan, all, > > I don't think that there really is a relationship between presence > and call completion. Presence is about the general availibility of a > certain user, call completion provides the possibility to complete a > call to a certain destination you've got a busy error response from. I completely disagree. When you invoke the CCBS service, the ringback you get when they are "available" is exactly presence. However, in the PSTN, it is limited to the only concept of presence they have - whether you are on a call or not. In an IP world, I can be unavailable for voice service even though I'm not in a call strictly speaking. For example, if I've got five parallel IM sessions, and as a consequence, I set my voice service to "closed" through presence, what is the desired behavior of the SIP-based CCBS system? I would assert that I *dont* want the callback to come now. If it does, I won't answer it anyway since I'm busy with other things. So, the call goes to voicemail or goes unanswered. That does not seem like the desired behavior. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyT-0002bt-Gf; Mon, 06 Nov 2006 21:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGyR-0002bH-T2 for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGyQ-0003ML-Hp for sipping@ietf.org; Mon, 06 Nov 2006 21:46:03 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 18:46:01 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="755076617:sNHT2357838674" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72k1W6012501; Mon, 6 Nov 2006 18:46:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA72j6B2016837; Mon, 6 Nov 2006 18:46:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:30 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:30 -0800 Message-ID: <454FBB5D.4060607@cisco.com> Date: Mon, 06 Nov 2006 17:46:53 -0500 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: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670A410D28@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A410D28@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:30.0176 (UTC) FILETIME=[C9D05C00:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=2273; t=1162867561; x=1163731561; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20New=20I-D=20on=20usage=20of=20phone=20numbers=20in=20SIP =20[DO=20NOT=20REPLY!=0A=20]; X=v=3Dcisco.com=3B=20h=3DEpT4jMelJ1BVR4RadKUmEjfSzVc=3D; b=ezehGU0+Se74T1eA1DDAsLYAJWN0l70xdMWJZZhr8kSWKpGoRjX86yHi4IT6QgLEZWI9X5/a xqtKM5G21RTmC3jsax/hpBMcjhepsAwq35qRa6hvvFu6ZeSMLmGQCw/U; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sipping Subject: [Sipping] Re: [Sip] New I-D on usage of phone numbers in SIP [DO NOT REPLY! ] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Elwell, John wrote: > Jonathan, > > Some good stuff in here. Thanks! > > >>The document proposes a framework and architecture for the usage of >>phone numbers with SIP. It tries to answer questions like the >>difference >>between a tel URI and SIP URI with user=phone, when to use each, what >>the meaning of concepts like LNP and freephone are in a >>pure-SIP world, >>the architectural role of ENUM, and impacts on PSTN interoperability, >>and so on. > > > I am not sure about classing a SIP URI as an address. As you say later, the > more important meaning of the domain part is as an identifier of the owner > of the namespace to which the user part belongs. It says nothing about where > this can be found (unless it is in the form of an IP address). It requires a > DNS look-up to obtain an address (IP address). Its an address in that it is bound to a specific domain and requests to it will get routed to proxies with particular IP addresses, learned through the DNS. Likewise, at least when used > as an AoR, the entire SIP URI (including the user part) identifies a > resource (a user) and does not say where that resource is to be found. Sure it does; it says it is found in the domain indicated in the RHS of the URI. I like drawing analogies to the postal service; this would be equivalent to saying something like "Joe Smith of London, England". It absolutely an address, in that it points to something through its location (London). Its just not very specific, in that you need to do some further work once you get to London. > It > requires a location server look-up to determine this. So in many respects I > think a SIP URI is much more like a name. I could put it on my business > card, in the same way I would put a phone number on my business card. Sure; both are valuable on business cards. That doesn't make them both names. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 21:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxz-0002U8-Om; Mon, 06 Nov 2006 21:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGxx-0002TW-Q1 for sipping@ietf.org; Mon, 06 Nov 2006 21:45:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGxv-0003Ij-DK for sipping@ietf.org; Mon, 06 Nov 2006 21:45:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 18:45:29 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANaBT0WrR7MVh2dsb2JhbABEjAUBAQEIDio X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="448474007:sNHT26164124" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72jTgF023525; Mon, 6 Nov 2006 18:45:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA72jRWS023970; Mon, 6 Nov 2006 18:45:29 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:28 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:45:28 -0800 Message-ID: <454FB857.1040107@cisco.com> Date: Mon, 06 Nov 2006 17:33:59 -0500 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: "Widjaja, Indra \(Indra\)" Subject: Re: [Sipping] Updated overload requirements draft References: <9F1D84BDF02A2B41B030921EB090861878BB83@ILEXC1U01.ndc.lucent.com> In-Reply-To: <9F1D84BDF02A2B41B030921EB090861878BB83@ILEXC1U01.ndc.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 02:45:28.0472 (UTC) FILETIME=[C8CC5980:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=1739; t=1162867529; x=1163731529; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sipping]=20Updated=20overload=20requirements=20draft; X=v=3Dcisco.com=3B=20h=3DGT4KJkWqVHbbWp1o5MPk9INcF04=3D; b=ClkBH2AuGFbU1xIvOt6w4wZdl+Yj4YKTIWy/u4w/laXXMMucZO791OO1RgNB786IIEdkNII+ /K5xoo/zFv1UJ+Rn9ilxKxv9KF0PyVVxD5U0KQd72eSUEZA1hAZbi2YI; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Widjaja, Indra (Indra) wrote: > Hi: > > I have the following questions in the simulation model section. > > 1) A sentence on page 14 states: "Similarly, messages sent from the home > proxy to the edge proxies are distributed uniformly amongst them." > Does this imply that we're not using the destination of a message to > explicitly route the message to the edge proxy? Also, are we restricting > the simulation model to uniform traffic pattern only? Yes. I don't think that it adds much in terms of understanding this problem. Typically calls would be uniformly distributed amongst the edge proxies anyway, in a real network where proper registration processing was being used. > > 2) Section 6.2 adopts a model where different transactions are assumed > to be independent, which on one hand seems desirable because of its > simplicity. On the other hand, it's not clear what the precise effect of > this assumption is on the actual performance. I didn't see any reason why it impacts the overall model. > > 3) Should the metrics for comparison purposes be added? Thats a good idea; the main metrics are the goodput (the number of successfully completed transactions - ones not rejected for reasons of overload) vs the offered load, and the throuput (total number of transactions that generated any response, including ones due to overload). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 22:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHJ8-0000VD-2X; Mon, 06 Nov 2006 22:07:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHJ5-0000V1-Ry for sipping@ietf.org; Mon, 06 Nov 2006 22:07:23 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHJ4-0006ow-Gu for sipping@ietf.org; Mon, 06 Nov 2006 22:07:23 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2006 19:07:22 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH2GT0WrR7O6W2dsb2JhbACMPxUOKw X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="350440261:sNHT25470656" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA737Lqu027219; Mon, 6 Nov 2006 19:07:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA737LAo028260; Mon, 6 Nov 2006 19:07:21 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:07:21 -0800 Received: from [10.21.114.247] ([10.21.114.247]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:07:21 -0800 Message-ID: <454FF866.4000109@cisco.com> Date: Mon, 06 Nov 2006 22:07:18 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: AW: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 References: <454FB9C8.8000800@cisco.com> In-Reply-To: <454FB9C8.8000800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:07:21.0349 (UTC) FILETIME=[D7557B50:01C70219] DKIM-Signature: a=rsa-sha1; q=dns; l=2139; t=1162868841; x=1163732841; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20AW=3A=20[Sipping]=20comments=20on=20draft-roach-sipping-callcomp -bfcp-00; X=v=3Dcisco.com=3B=20h=3Dxy3LgWPLQytXDkxFKfA2wgxlNJ8=3D; b=bZnuYYAgv24tG2XlVrrMRYxHFmoM9OtRjugyezSTR8dWJT3REOAHprpDUJSD1Zk02wBhztS1 y7YSFUsvI8bCjKIbefUcbH5x3giYIBolRbOH70RSM1Zuw72gECwcE4Fy; Authentication-Results: sj-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org amen. Going further, being in a call (even a voice call) doesn't mean that I'm *not* available to take another call. This is a place that they never got the feature interactions right - namely with caller id. It may be that you are the person I most want to talk to, but when you tried to call me before I was already involved in two calls and just didn't have a way to manage another. Later I am only involved in one call and would be thrilled to have you call me back. Presence provides ways to say all of this, and so it could be a great way to provide a "better" version of this feature than is available in the PSTN. What it doesn't easily do is provide a faithful emulation of what the PSTN does. Providing a faithful emulation seems to be incompatible with providing a more interesting and potentially more useful implementation in the new world of more capable devices. Paul Jonathan Rosenberg wrote: > > > Huelsemann, Martin wrote: > >> Hi Jonathan, all, >> >> I don't think that there really is a relationship between presence >> and call completion. Presence is about the general availibility of a >> certain user, call completion provides the possibility to complete a >> call to a certain destination you've got a busy error response from. > > I completely disagree. > > When you invoke the CCBS service, the ringback you get when they are > "available" is exactly presence. However, in the PSTN, it is limited to > the only concept of presence they have - whether you are on a call or not. > > In an IP world, I can be unavailable for voice service even though I'm > not in a call strictly speaking. For example, if I've got five parallel > IM sessions, and as a consequence, I set my voice service to "closed" > through presence, what is the desired behavior of the SIP-based CCBS > system? I would assert that I *dont* want the callback to come now. If > it does, I won't answer it anyway since I'm busy with other things. So, > the call goes to voicemail or goes unanswered. That does not seem like > the desired behavior. > > -Jonathan R. _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 22:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHTT-0002rB-9j; Mon, 06 Nov 2006 22:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHTR-0002qr-DF for sipping@ietf.org; Mon, 06 Nov 2006 22:18:05 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHTP-0008EW-15 for sipping@ietf.org; Mon, 06 Nov 2006 22:18:05 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 19:18:02 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86451304:sNHT48163086" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73I2bH010547 for ; Mon, 6 Nov 2006 19:18:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA73I2in027401 for ; Mon, 6 Nov 2006 19:18:02 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:18:02 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:18:02 -0800 Message-ID: <454FFAE9.5030905@cisco.com> Date: Mon, 06 Nov 2006 22:18:01 -0500 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: IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:18:02.0248 (UTC) FILETIME=[5556E880:01C7021B] DKIM-Signature: a=rsa-sha1; q=dns; l=1898; t=1162869482; x=1163733482; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=g48O2KJ+zqU/zcIRfun3//8FW4axCqEZa/tM5sIVVTG9j3c2kG1LhGAwu5+5ek5q22eyXkNg Pf0E/SIT8WjFAnqGTpPjmNWP7ccMT+AojL3ai0XNl43+S0bDDlKipWuu; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sipping] ICE tutorial: Lunch logistics update [DO NOT REPLY] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 06 23:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhIFq-0001Ke-Eq; Mon, 06 Nov 2006 23:08:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhIFo-0001KU-T6 for sipping@ietf.org; Mon, 06 Nov 2006 23:08:04 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhIFk-0003lL-VD for sipping@ietf.org; Mon, 06 Nov 2006 23:08:04 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B75A82063B for ; Tue, 7 Nov 2006 09:32:27 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id A36862062D for ; Tue, 7 Nov 2006 09:32:27 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 09:37:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C70222.4DE339F8" Date: Tue, 7 Nov 2006 09:37:56 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB01AB@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb71TbpvTTWSdoPROmtdAZowBC7oAGTDeZw From: To: X-OriginalArrivalTime: 07 Nov 2006 04:07:57.0473 (UTC) FILETIME=[4EA1F910:01C70222] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [Sipping] Draft for review:draft-sreeram-specify-method-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C70222.4DE339F8 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C70222.4DE339F8" ------_=_NextPart_002_01C70222.4DE339F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 We have submitted a I-D regarding the Extension to the SIP to allow the=20 SIP entities intension of Asynchronous service change request. =20 The url of the draft is : http://www.ietf.org/internet-drafts/draft-sreeram-specify-method-00.txt =20 We received few comments in the sip mailing list and also many offline comments. We are now working on them to make the requirements more clear for the problem stated in the ID. =20 Please look at the draft and provide suggestions, comments and/or concerns. =20 =20 =20 Thanking you, =20 Regards, Sreeram. ------_=_NextPart_002_01C70222.4DE339F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

=

We have submitted a I-D regarding = the Extension to the SIP to allow the

SIP entities intension of = Asynchronous service change request.

 

=

The url of the draft is = :

http://www.ietf.org/internet-drafts/= draft-sreeram-specify-method-00.txt

 

=

We received few comments in the sip mailing list and also many offline = comments.

We are now working on them to make = the requirements more clear for the problem stated in the = ID.

 

Please look at the draft and = provide suggestions, comments and/or = concerns.       

 

 

Thanking = you,

 

Regards,

Sreeram.

------_=_NextPart_002_01C70222.4DE339F8-- ------_=_NextPart_001_01C70222.4DE339F8 Content-Type: text/plain; name="ATT93783.txt" Content-Transfer-Encoding: base64 Content-Description: ATT93783.txt Content-Disposition: inline; filename="ATT93783.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcCBtYWls aW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KVGhp cyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQpV c2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJy ZW50IHNpcA0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhl IGFwcGxpY2F0aW9uIG9mIHNpcA== ------_=_NextPart_001_01C70222.4DE339F8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 ------_=_NextPart_001_01C70222.4DE339F8-- From sipping-bounces@ietf.org Tue Nov 07 00:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJ4p-00086G-61; Tue, 07 Nov 2006 00:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJ4o-00085x-4z; Tue, 07 Nov 2006 00:00:46 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhJ4j-0008OI-Nj; Tue, 07 Nov 2006 00:00:46 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id kA750OBU013222; Mon, 6 Nov 2006 21:00:24 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id kA750I4J013221; Mon, 6 Nov 2006 21:00:24 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Mon, 06 Nov 2006 21:00:17 -0800 (PST) Date: Mon, 6 Nov 2006 21:00:14 -0800 From: Marc Petit-Huguenin To: "Drage, Keith \(Keith\)" Message-ID: <455012DE.2030604@acm.org> In-Reply-To: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE2918072B807@DEEXC1U01.de.lucent.com> x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.7 (X11/20061013) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, sipping@ietf.org, Adam Roach Subject: [Sipping] Re: [Sip] Re: 489 status code X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Drage, Keith (Keith) wrote: > (As SIP WG chair) > > See http://www.iana.org/assignments/sip-parameters for a list of > currently assigned response codes (with 489 allocated already as Adam > indicates). > > As definition of a new response code requires a SIP WG document, can I > suggest that only such documents make any attempt to assign a response > code value - I know this can be useful because the examples have to show > it. If your document is not one of these, use 4xx or something else that > can be replaced later. Using 4xx can be confusing as there will be no way to know if it is an yet unassigned specific response code in the 4xx class or the whole 4xx class. May I suggest 4?? instead? > > I notice also drafts in SIPPING group attempting to assign response > codes. > _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 01:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKdv-0003Sj-Kr; Tue, 07 Nov 2006 01:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhKdt-0003LS-PK for sipping@ietf.org; Tue, 07 Nov 2006 01:41:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhKdp-0003Cl-Mk for sipping@ietf.org; Tue, 07 Nov 2006 01:41:05 -0500 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 22:41:00 -0800 X-IronPort-AV: i="4.09,394,1157353200"; d="scan'208,217"; a="340208771:sNHT82910500" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA76ewRq018904 for ; Tue, 7 Nov 2006 12:10:58 +0530 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 kA76evkq019302 for ; Tue, 7 Nov 2006 06:40:57 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 12:10:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 12:10:55 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Status Code= 450 "Call in minimal state" Thread-Index: AccCN61oxA3GbGKxTk63c5pCPhRdGw== From: "Rajeev Narang \(ranarang\)" To: X-OriginalArrivalTime: 07 Nov 2006 06:40:56.0769 (UTC) FILETIME=[ADEB6310:01C70237] DKIM-Signature: a=rsa-sha1; q=dns; l=3552; t=1162881658; x=1163745658; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ranarang@cisco.com; z=From:=22Rajeev=20Narang=20\(ranarang\)=22=20 |Subject:New=20Status=20Code=3D=20450=20=22Call=20in=20minimal=20state=22; X=v=3Dcisco.com=3B=20h=3Dr3EeSFLMGaAuMqvFB/hJ8ERsCe8=3D; b=1KqjiUhg4NDfXSpakuE8kNL/1ptY6aOyuHYTTapC0SfdxIqGwopOB+OZ2aqyNl5/BZdM7LPB KcJXbw1DJDDa1ylqkBXS4Caf3Ba81KG2otZmiSQsavuPyuIuXgIpzP0d; Authentication-Results: ind-dkim-2; header.From=ranarang@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Sipping] New Status Code= 450 "Call in minimal state" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1491350978==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1491350978== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70237.AE0773F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70237.AE0773F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed draft describes the scenarios about the network failure happening in signaling connection on one side of the B2BUA and proposal to use a new SIP status code for communication of this situation to the other side of B2BUA on SIP dialog.=20 =20 Using this status code the implementation could perform more graceful handling of the network failure conditions and help in adding robustness to the VoIP system. =20 =20 http://www.ietf.org/internet-drafts/draft-ranarang-sipping-middialog-sip -status-00.txt =20 =20 =20 This draft is available for comments from SIPPING. =20 Regards, Rajeev =20 ------_=_NextPart_001_01C70237.AE0773F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The proposed draft describes the = scenarios=20 about the network failure happening in signaling connection on = one
side of=20 the B2BUA and proposal to use a new SIP status code for communication of = this=20 situation to the
other side of B2BUA on SIP dialog. =
 
Using this status = code the=20 implementation could perform more graceful handling of
the network = failure=20 conditions and help in adding robustness to the VoIP = system.
 
 
http://www.ietf.org/internet-drafts/draft-ranarang-sipping-middi= alog-sip-status-00.txt
 
 
This = draft is=20 available for comments from SIPPING.
 
Regards,
Rajeev
 
------_=_NextPart_001_01C70237.AE0773F4-- --===============1491350978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1491350978==-- From sipping-bounces@ietf.org Tue Nov 07 02:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLLw-0004B3-NR; Tue, 07 Nov 2006 02:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLLu-0004Av-QJ for sipping@ietf.org; Tue, 07 Nov 2006 02:26:34 -0500 Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhLLt-0008PE-43 for sipping@ietf.org; Tue, 07 Nov 2006 02:26:34 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA77QRDE025293; Tue, 7 Nov 2006 16:26:27 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AD22D20AE2D; Tue, 7 Nov 2006 16:26:26 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B072E20AE2C; Tue, 7 Nov 2006 16:26:25 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA77QPmh007955; Tue, 7 Nov 2006 16:26:25 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA77QODR011527; Tue, 7 Nov 2006 16:26:24 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kA77QOai011521; Tue, 7 Nov 2006 16:26:24 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id kA77QOqq012593; Tue, 7 Nov 2006 16:26:24 +0900 (JST) Message-Id: <200611070726.kA77QOqq012593@imf.m.ecl.ntt.co.jp> To: jdrosen@cisco.com Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00 From: Mayumi Munakata Date: Tue, 07 Nov 2006 16:26:24 +0900 In-Reply-To: <454FBD34.50409@cisco.com> X-Mailer: WebMail V3.5.0 PL4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jonathan, Thank you for the follow up. We are using "id" and "none", and it seems like there are some implementations that already deploy "header", too. Other priv-values ("user", "session", and "critical") could be deprecated if they are really not used in anywhere. However, your proposal to use Privacy: id as a flag to indicate a server not to add any identity information will ruin the backward compatibility. We would prefer to define a new priv-value like "all" as this flag. What about "history" privacy? As Roland mentioned in the other email "The 'history' privacy can be within the Message or within the History Info header itself", privacy=history can be set in a History-Info header in order to request the privacy for each hi-entry. I guess this mechanism should not be deprecated because there are use cases and can not be realized without this. Thank you, Mayumi > Let me follow up some more to my remarks at the microphone today. > > We clearly have a need for privacy services in SIP, and a revision of > RFC 3323 is warranted. > > What I think such a revision should do is: > > 1. give guidance on how a UA can construct a completely anonymous > request, utilizing anonymous gruu and using TURN to obtain IP addresses > and ports for media relay. This would need to have guidance on various > header fields, as rfc 3323 does today. However the context there is how > to construct (or omit) them, rather for guidance on removal or manipulation. > > 2. Once you define (1), the additional service you need from the network > is not to insert additional information into the request which identify > the user. Thus, you need a flag that indicates the request is anonymous. > We could use the Privacy: id value for this, or use the presence of an > anonymous URI in the From as this flag. What I assert we do NOT want is > anything more than just a single flag. We don't want specific guidance > on whether its allowed to insert header foo vs. header bar. That is too > complicated and I think is not useful. > > 3. Additionally, one might want a solution for UA which, for some > reason, cannot construct messages using (1). In that case, the UA will > want to invoke a privacy service in the network. I would argue that we > DONT want complex features that allow the UA to micro-manage the > behavior of that privacy service. As a privacy service, it does a > "full-processing" on the request - removing or obfuscating anything that > could reveal user identity. Thus, the only thing we need to signal is a > way for a UA to invoke that service, thats it. We could use a Privacy > value for that, or we could use other techniques we have developed for > service invocation. For example a route header field that points to an > anonymization service. > > > I will point out that RFC 3323 itself has only seen deployment in the > context of RFC 3325. That is, to my knowledge, the only value of the > Privacy header ever used is "id". > > -Jonathan R. > > > Mayumi Munakata wrote: > > > Jonathan, > > > > Thank you for the valuable comments. > > > > To my knowledge, RFC 3323 is widely deployed already, so it is > > necessary to keep the mechanism and clarify it as much as possible > > for the already deployed implementations. > > > > Your sip-identity-privacy draft may solve all the privacy problems, > > but still, we need RFC 3323, even if it is a short-term solution. > > > > If everybody views RFC 3323 in the same way, I can change the text in > > Section 4.2. (Guidelines on specifying new priv-values) to something > > like "it is RECOMMENDED to avoid defining a new priv-value in future > > RFCs". > > > > Thanks, Mayumi > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 03:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLsi-0000kw-En; Tue, 07 Nov 2006 03:00:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhLsg-0000kk-RA for sipping@ietf.org; Tue, 07 Nov 2006 03:00:26 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhLsd-0004HY-Dc for sipping@ietf.org; Tue, 07 Nov 2006 03:00:26 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id kA780Ld24937 for ; Tue, 7 Nov 2006 03:00:21 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006110703002827179 for ; Tue, 07 Nov 2006 03:00:28 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 03:00:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 03:00:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-haluska-sipping-directory-assistance-01.txt thread-index: AccCQsoKBOTKxJYfTfG3CPNYdboFWQ== From: "Haluska, John J" To: X-OriginalArrivalTime: 07 Nov 2006 08:00:28.0877 (UTC) FILETIME=[CA5147D0:01C70242] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Haluska, John J" Subject: [Sipping] draft-haluska-sipping-directory-assistance-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641440601==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0641440601== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70242.CA27646B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70242.CA27646B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is a new revision of "Considerations for Information Services and = Operator Services Using SIP". Until it shows up in the internet-drafts repository, it is available at=20 ftp://ftp.research.telcordia.com/pub/world/haluska/draft-haluska-sipping-= directory-assistance-01.txt Thanks for the comments and discussion on the -00 version. This revision = is substantially updated. We welcome feedback and comments on the = SIPPING mailing list. "Considerations for Information Services and Operator Services Using = SIP". Abstract=20 Information Services are services whereby information is provided by=20 the network in response to user requests, and may include involvement = of a human or automated agent. A popular existing Information Service = is Directory Assistance (DA). Moving ahead, Information Services=20 providers envision exciting multimedia services that support=20 simultaneous voice and data interactions with full operator backup at = any time during the call. Information Services providers are planning = to migrate to SIP based platforms, which will enable such advanced=20 services, while continuing to support traditional DA services. This=20 document aims to identify how such services can be implemented using=20 existing or currently proposed SIP mechanisms.=20 ------_=_NextPart_001_01C70242.CA27646B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-haluska-sipping-directory-assistance-01.txt

There is a new revision of "Considerations for = Information Services and Operator Services Using SIP".

Until it shows up in the internet-drafts repository, it is available = at

ftp://ftp.research.telcordia.com/pub= /world/haluska/draft-haluska-sipping-directory-assistance-01.txt


Thanks for the comments and discussion on the -00 version. This revision = is substantially updated. We welcome feedback and comments on the = SIPPING mailing  list.


"Considerations for Information Services and Operator Services = Using SIP".

Abstract

   Information Services are services whereby information is = provided by
   the network in response to user requests, and may include = involvement
   of a human or automated agent. A popular existing = Information Service
   is Directory Assistance (DA). Moving ahead, Information = Services
   providers envision exciting multimedia services that = support
   simultaneous voice and data interactions with full operator = backup at
   any time during the call. Information Services providers = are planning
   to migrate to SIP based platforms, which will enable such = advanced
   services, while continuing to support traditional DA = services. This
   document aims to identify how such services can be = implemented using
   existing or currently proposed SIP mechanisms.

------_=_NextPart_001_01C70242.CA27646B-- --===============0641440601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0641440601==-- From sipping-bounces@ietf.org Tue Nov 07 03:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhMgd-0005eS-QR; Tue, 07 Nov 2006 03:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhMgd-0005eN-0M for sipping@ietf.org; Tue, 07 Nov 2006 03:52:03 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhMgb-00026J-Ft for sipping@ietf.org; Tue, 07 Nov 2006 03:52:02 -0500 Received: from hkaplan [12.105.247.78] by acmepacket.com with ESMTP (SMTPD-9.10) id A924064C; Tue, 07 Nov 2006 03:51:48 -0500 From: "Hadriel Kaplan" To: "'Mayumi Munakata'" , Subject: RE: [Sipping] Discussions ondraft-munakata-sipping-privacy-clarified-00 Date: Mon, 6 Nov 2006 12:50:20 -0500 Message-ID: <007601c701cc$0d579bf0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccCPn4W/PgwCHnlQde1Sbakzs0LuwAc5XxA In-Reply-To: <200611070726.kA77QOqq012593@imf.m.ecl.ntt.co.jp> X-Spam-Score: 1.2 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org "user" is used as well (as is "header" and "none", and obviously "id"). -hadriel > -----Original Message----- > From: Mayumi Munakata [mailto:munakata.mayumi@lab.ntt.co.jp] > Sent: Tuesday, November 07, 2006 2:26 AM > To: jdrosen@cisco.com > Cc: sipping@ietf.org > Subject: Re: [Sipping] Discussions ondraft-munakata-sipping-privacy- > clarified-00 > > Hi Jonathan, > Thank you for the follow up. > > We are using "id" and "none", and it seems like there are > some implementations that already deploy "header", too. > Other priv-values ("user", "session", and "critical") > could be deprecated if they are really not used in anywhere. > > However, your proposal to use Privacy: id as a flag to > indicate a server not to add any identity information will > ruin the backward compatibility. We would prefer to define > a new priv-value like "all" as this flag. > > What about "history" privacy? > As Roland mentioned in the other email "The 'history' privacy can > be within the Message or within the History Info header itself", > privacy=history can be set in a History-Info header in order to > request the privacy for each hi-entry. > I guess this mechanism should not be deprecated because there > are use cases and can not be realized without this. > > Thank you, > Mayumi > > > > Let me follow up some more to my remarks at the microphone today. > > > > We clearly have a need for privacy services in SIP, and a revision of > > RFC 3323 is warranted. > > > > What I think such a revision should do is: > > > > 1. give guidance on how a UA can construct a completely anonymous > > request, utilizing anonymous gruu and using TURN to obtain IP addresses > > and ports for media relay. This would need to have guidance on various > > header fields, as rfc 3323 does today. However the context there is how > > to construct (or omit) them, rather for guidance on removal or > manipulation. > > > > 2. Once you define (1), the additional service you need from the network > > is not to insert additional information into the request which identify > > the user. Thus, you need a flag that indicates the request is anonymous. > > We could use the Privacy: id value for this, or use the presence of an > > anonymous URI in the From as this flag. What I assert we do NOT want is > > anything more than just a single flag. We don't want specific guidance > > on whether its allowed to insert header foo vs. header bar. That is too > > complicated and I think is not useful. > > > > 3. Additionally, one might want a solution for UA which, for some > > reason, cannot construct messages using (1). In that case, the UA will > > want to invoke a privacy service in the network. I would argue that we > > DONT want complex features that allow the UA to micro-manage the > > behavior of that privacy service. As a privacy service, it does a > > "full-processing" on the request - removing or obfuscating anything that > > could reveal user identity. Thus, the only thing we need to signal is a > > way for a UA to invoke that service, thats it. We could use a Privacy > > value for that, or we could use other techniques we have developed for > > service invocation. For example a route header field that points to an > > anonymization service. > > > > > > I will point out that RFC 3323 itself has only seen deployment in the > > context of RFC 3325. That is, to my knowledge, the only value of the > > Privacy header ever used is "id". > > > > -Jonathan R. > > > > > > Mayumi Munakata wrote: > > > > > Jonathan, > > > > > > Thank you for the valuable comments. > > > > > > To my knowledge, RFC 3323 is widely deployed already, so it is > > > necessary to keep the mechanism and clarify it as much as possible > > > for the already deployed implementations. > > > > > > Your sip-identity-privacy draft may solve all the privacy problems, > > > but still, we need RFC 3323, even if it is a short-term solution. > > > > > > If everybody views RFC 3323 in the same way, I can change the text in > > > Section 4.2. (Guidelines on specifying new priv-values) to something > > > like "it is RECOMMENDED to avoid defining a new priv-value in future > > > RFCs". > > > > > > Thanks, Mayumi > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 11:05:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTQ0-0000m5-OI; Tue, 07 Nov 2006 11:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTPy-0000lQ-QZ; Tue, 07 Nov 2006 11:03:18 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTPw-00022d-Db; Tue, 07 Nov 2006 11:03:18 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA7G35EM005167; Tue, 7 Nov 2006 10:03:14 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 10:03:08 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Nov 2006 17:03:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 7 Nov 2006 17:03:05 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918072BD09@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: 489 status code Thread-Index: AccCKbQ9AknnvJpFSQq6dHqX/Fd9xQAXCj6w From: "Drage, Keith \(Keith\)" To: "Marc Petit-Huguenin" X-OriginalArrivalTime: 07 Nov 2006 16:03:07.0009 (UTC) FILETIME=[36B58F10:01C70286] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, sipping@ietf.org, Adam Roach Subject: [Sipping] RE: [Sip] Re: 489 status code X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Whatever keeps it from assigning digits. The key point is that nobody is supervising all these selections made by individual author drafts, and we even find conflicts in working group items, and therefore if someone is trying something in an implementation, they are guaranteed to get a conflict if that usage survives for any length of time. Regards Keith=20 > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 > Sent: 07 November 2006 05:00 > To: Drage, Keith (Keith) > Cc: Adam Roach; sip@ietf.org; sipping@ietf.org > Subject: Re: [Sip] Re: 489 status code >=20 > Drage, Keith (Keith) wrote: > > (As SIP WG chair) > >=20 > > See http://www.iana.org/assignments/sip-parameters for a list of=20 > > currently assigned response codes (with 489 allocated=20 > already as Adam=20 > > indicates). > >=20 > > As definition of a new response code requires a SIP WG=20 > document, can I=20 > > suggest that only such documents make any attempt to assign=20 > a response=20 > > code value - I know this can be useful because the examples have to=20 > > show it. If your document is not one of these, use 4xx or something=20 > > else that can be replaced later. >=20 > Using 4xx can be confusing as there will be no way to know if=20 > it is an yet unassigned specific response code in the 4xx=20 > class or the whole 4xx class. May I suggest 4?? instead? >=20 > >=20 > > I notice also drafts in SIPPING group attempting to assign response=20 > > codes. > >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 13:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVjc-0006Zu-DE; Tue, 07 Nov 2006 13:31:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVja-0006Zk-Da for sipping@ietf.org; Tue, 07 Nov 2006 13:31:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVjY-00038u-Vx for sipping@ietf.org; Tue, 07 Nov 2006 13:31:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2006 10:31:41 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACBeUEVAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="48144051:sNHT31840264" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7IVer7018126; Tue, 7 Nov 2006 13:31:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA7IVeDM025709; Tue, 7 Nov 2006 13:31:40 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:31:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Comments on draft-malas-performance-metrics-05.txt Date: Tue, 7 Nov 2006 13:31:37 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DA945@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-malas-performance-metrics-05.txt Thread-Index: Acb8wtgBbb/Q/0j9QRaUokHgDisV9wAL/VfAAABucgAABxqJoAFiDVLQ From: "Michael Hammer \(mhammer\)" To: "Malas, Daryl" , "Dolly, Martin C, ALABS" , "Gonzalo Camarillo" , "sipping" X-OriginalArrivalTime: 07 Nov 2006 18:31:40.0170 (UTC) FILETIME=[F75DFEA0:01C7029A] DKIM-Signature: a=rsa-sha1; q=dns; l=7196; t=1162924300; x=1163788300; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20Comments=20on=20draft-malas-performance-metrics-05.t xt |To:=22Malas, =20Daryl=22=20, =0A=20=20=20=20=20=20=20 =20=22Dolly, =20Martin=20C, =20ALABS=22=20, =0A=20=20=20=20=20 =20=20=20=22Gonzalo=20Camarillo=22=20, =0A=2 0=20=20=20=20=20=20=20=22sipping=22=20; X=v=3Dcisco.com=3B=20h=3D5UZGDHnPaBKjJo4RhAHfKdofbqY=3D; b=0oiRq0ditnMOmWcHZhA1LxMmYSMuPZ7VJnxxNBIkhvefLccz3dNHt++UMe1RgiWL6dkW6dxv 730MtVyQ6thJ04V/fyqI90njkMcBFetSh4AhJsg98p1hDnrEKHKq5Yrd; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Daryl, The only metric that might be useful (throwing out for consideration) is the differential between when the 200 OK passes some signaling point, and when the forward or backward media passes the border. This may give some sense of whether clipping is occurring. =20 Do we care if there is significant difference between when media flow arrives at the caller and 200 OK arrives, or vice versa? Do we care if there is a delay from 200 OK received and forward path flow? Note this may require some timing relationship if the border element is decomposed. Note, the 3 cases we seem to have is signaling-only interactions, media-only, and signaling-media interactions. I am wondering about the latter case. Mike > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 > Sent: Tuesday, October 31, 2006 12:33 PM > To: Dolly, Martin C, ALABS; Michael Hammer (mhammer); Gonzalo=20 > Camarillo; sipping > Subject: RE: [Sipping] Comments on=20 > draft-malas-performance-metrics-05.txt >=20 > All of the metrics in this draft deal with signaling=20 > indicators to TB and TS. They have nothing to do with media.=20 > The "session" deals with signaling not media. The=20 > correction Gonzalo mentioned is to an example call flow in=20 > section 3.9.1. >=20 > Do we need a metric that measures the actual receipt and=20 > sending of media as related to the UAC and UAS? If that is=20 > the case, then I think there are two types of media that=20 > should be considered here. First, do we care about=20 > "early-media" as related to a 183 w/ SDP? Second,=20 > "session-media" as related to media generated by the UAC and=20 > UAS after a 200 OK and the reception of the ACK by the UAS. >=20 > I personally cannot think of any metrics we should consider=20 > that deal with the media portion, which aren't dealt with in=20 > RFC 3550 and 3611 (or elsewhere such as ITU-T P.862, etc.). =20 > Mike, you seemed to begin to mention some. Thoughts? >=20 > --Daryl >=20 > > -----Original Message----- > > From: Dolly, Martin C, ALABS [mailto:mdolly@att.com] > > Sent: Tuesday, October 31, 2006 6:59 AM > > To: Michael Hammer (mhammer); Gonzalo Camarillo; sipping > > Cc: Malas, Daryl > > Subject: RE: [Sipping] Comments on > draft-malas-performance-metrics-05.txt > >=20 > > The timing of cut-thru is extremely important, as it=20 > relates to tones=20 > > and announcements that occur before answer. > >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, October 31, 2006 8:51 AM > > To: Gonzalo Camarillo; sipping > > Cc: daryl.malas@level3.com > > Subject: RE: [Sipping] Comments on > > draft-malas-performance-metrics-05.txt > >=20 > > Is there an issue associated with when "cut through" really occurs? > >=20 > > In other words, in some cases each media path may be available at=20 > > different times. So, perhaps the setup times should be relative to > each > > unidirectional path. > >=20 > > Also, is the focus of "session" the media or signaling? Just trying > to > > be sure it is clear what we intend to measure. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > Sent: Tuesday, October 31, 2006 3:00 AM > > > To: sipping > > > Cc: daryl.malas@level3.com > > > Subject: [Sipping] Comments on > draft-malas-performance-metrics-05.txt > > > > > > Hi, > > > > > > a few comments on draft-malas-performance-metrics-05.txt. > > > > > > The Section "Conventions used in this document", which currently=20 > > > appears between the Abstract and the TOC, is usually part of the=20 > > > Terminology Section instead. > > > > > > Expand acronyms (e.g., UAC, UAS) on their first use. > > > > > > Section 3.1.2: RRD is defined as: > > > > > > "the interval is defined from the initial REGISTER=20 > request and the=20 > > > final response indicating a failure received from the destination=20 > > > registrar or interim proxies." > > > > > > However, in the example, the UAC receives an error response, it=20 > > > sends a new REGISTER, and then gives up. RRD is=20 > calculated until the=20 > > > UAC gives up. Therefore, the description needs to clarify which=20 > > > final responses are taking into account to calculate RRD=20 > (i.e., when=20 > > > the UAC gives up) and which ones are not (e.g., authentication=20 > > > challenges). > > > > > > Section 3.2 talks about the Session Request Delay (SSD=20 > and says that=20 > > > is telephony applications of SIP is known as Post Dial Delay. > > > > > > The ITU defines the post-selection delay as: > > > > > > "Post-selection delay (en bloc sending) is defined as the time=20 > > > interval from the instant the first bit of the initial=20 > SETUP message=20 > > > containing all the selection digits is passed by the calling=20 > > > terminal to the access signalling system until the last=20 > bit of the=20 > > > first message indicating call disposition is received by=20 > the calling=20 > > > terminal (ALERTING message in case of successful call)." > > > > > > However, the draft defines Time Begin as: > > > > > > "TB occurs when the designated request has been=20 > processed by the > > > application and last bit of the request packet has been sent=20 > > > from the > > > proxy or UA (and is externally observable at some physical > > > interface)." > > > > > > Therefore, while for the ITU, TB relates to the first bit of the=20 > > > message, for the draft TB relates to the last bit of the=20 > message. We=20 > > > should either use the first bit of the message as well of clarify=20 > > > that the Post Dial Delay is not the same thing as > SRD. > > > > > > Section 3.4 defines the Session Duration Time as an interval=20 > > > starting with a 200 OK response. However, session establishments=20 > > > involving an answer in the ACK cannot be considered to be=20 > > > established until the ACK arrives to the UAS. These=20 > sessions can be=20 > > > considered to be "accepted", though. Section 3.4 should=20 > clarify this=20 > > > point. > > > > > > The example in Section 4 does not seem to relate to any=20 > of the ways=20 > > > to provide finer granularity, which are described right=20 > before the=20 > > > example. > > > > > > Cheers, > > > > > > Gonzalo > > > > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > > > > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 13:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW1v-0002bw-8G; Tue, 07 Nov 2006 13:50:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW1t-0002bc-OR for sipping@ietf.org; Tue, 07 Nov 2006 13:50:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW1q-0006Cw-5m for sipping@ietf.org; Tue, 07 Nov 2006 13:50:37 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2006 10:50:34 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHRjUEVAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="48145690:sNHT33208960" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7IoX3S025247; Tue, 7 Nov 2006 13:50:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA7IoXDO000588; Tue, 7 Nov 2006 13:50:33 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:50:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Tue, 7 Nov 2006 13:50:32 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DA959@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb+lcaO0xskB581R4yEOvZkfxxTvwAmwSWAANr8WiA= From: "Michael Hammer \(mhammer\)" To: "GARCIN Sebastien RD-CORE-ISS" , "Adam Roach" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 07 Nov 2006 18:50:33.0522 (UTC) FILETIME=[9AE5C920:01C7029D] DKIM-Signature: a=rsa-sha1; q=dns; l=6633; t=1162925433; x=1163789433; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20comments=20on=20draft-roach-sipping-callcomp-bfcp-00 |To:=22GARCIN=20Sebastien=20RD-CORE-ISS=22=20, =0A=20=20=20=20=20=20=20=20=22Adam=20Roach=22=20, = 0A=20=20=20=20=20=20=20=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20; X=v=3Dcisco.com=3B=20h=3DRMmLZDgsWW42Wv3H5p5z3+726qc=3D; b=i6g0+LhgcowLqhV0DvUnu28WpXxLwukn89NTj5E8A6Lz+fM9FTS8msCI+AbiZWZo2lWfyYj8 QI6bPsaz+9rAdkJ7Iuzq4WL7UFZd6nCayashHW1PQ+bwFat8cCqiLWwU; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I still have not seen a convincing explanation that any abuse exists. = This feature is about meta information; precisely the type of = information that the events framework was intended.=20 When the 486 Busy is received, that call is done. It is then about what = is the state of the queue, and who should initiate the next call = involving the called party. My problem with the way this is headed, is that it is designing a SIP = feature using PSTN thinking. You could get the same user experience, = but is modeling this with a mechanism designed for conference calls the = way to go? Mike > -----Original Message----- > From: GARCIN Sebastien RD-CORE-ISS=20 > [mailto:sebastien.garcin@orange-ftgroup.com]=20 > Sent: Friday, November 03, 2006 5:17 AM > To: Adam Roach; Jonathan Rosenberg (jdrosen) > Cc: IETF Sipping List > Subject: RE: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 > hi=20 >=20 > >>The objections that I have repeatedly raised with the "abuse" of=20 > >>SUBSCRIBE to activate a service aren't purely academic >=20 > I am still missing the "non-academic" arguments that would=20 > convince me not to the procedures in draft-ploetz. >=20 > Thanks for clarifying that part. >=20 > s=E9bastien >=20 > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com] Envoy=E9 : jeudi 2=20 > novembre 2006 16:43 =C0 : Jonathan Rosenberg Cc : IETF Sipping=20 > List Objet : Re: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 > Jonathan Rosenberg wrote: > > Its not clear to me that this mechanism works well in the face of=20 > > forking. Seems like you could end up with disparate queues=20 > for each of=20 > > my phones. >=20 > That's pretty much what I intended, yes. As far as I can=20 > tell, the net result -- that is, the behavior of the system=20 > -- would end up being identical (or, at least, substantially=20 > the same) with queues maintained on each of your devices=20 > versus a single, centralized queue -- unless there's more=20 > than one of you, in which case neither solution will behave=20 > particularly gracefully (although I believe the forking setup=20 > has better recovery properties under such circumstances). >=20 > When I get a spare moment, I'll work through a few scenarios=20 > to demonstrate how the externally observed system behavior is=20 > the same between distributed management of several queues and=20 > centralized management of one queue. >=20 > > Similar issues arise when the originating user has multiple=20 > devices.=20 > > So if I call you from phone 1, and later you are available,=20 > does the=20 > > ringback happen only at phone 1 or all of my phones? Seems like the=20 > > latter is much more desirable. That too implies that a UA-based=20 > > solution on the originating side has some problems. >=20 > That depends. Are you asserting this as a new requirement? No=20 > one has raised this capability as a requirement so far, and=20 > the previously offered solution certainly didn't have this property. >=20 > To be clear: I agree that this is probably an improvement on=20 > the service; however, the more requirements we pile on, the=20 > harder a solution becomes -- and we've become experts at=20 > putting so many requirements on a problem that the solution=20 > space dwindles down to nothing. >=20 > > There is clearly a relationship between all of this and presence; I=20 > > think you need to call that out. >=20 > Martin beat me to it, but I'll reiterate his comment: the=20 > relationship here isn't related as much to presence as it is=20 > to dialog state. And that is called out in the discussion=20 > about centralized queue management. >=20 > > On whether BFCP is the right thing or not for this problem, I'm not=20 > > sure. In one sense, you could characterize this as really a problem=20 > > with RFC3265 in general; that for certain event packages,=20 > notification=20 > > of an event to all watchers can cause them to take actions=20 > that result=20 > > in a further change to that same state. This is a race condition. >=20 > Not in general -- this race condition arises in the=20 > draft-poetzl document because it's doing something with=20 > SUBSCRIBE that SUBSCRIBE was never meant to do: changing the=20 > state of the thing that is watched. >=20 > Let's go back to first principles: SUBSCRIBE is a request to=20 > retrieve the state of a resource, and receive that state=20 > whenever it changes.=20 > It's a way for an observer to *LOOK* at a state. >=20 > Now, as I'm always having to tell my kids: you look with your=20 > eyes, not with your hands. If the act of subscribing to a=20 > state changes that very state, then you're no longer looking=20 > -- you're touching. SUBSCRIBE doesn't touch the state it's=20 > monitoring. (Now, we have defined some > *meta* state regarding the very state of that subscription,=20 > but you need to subscribe to that separately, and the act of=20 > subscribing to that meta-state doesn't change the meta-state). >=20 > If you violate the basic principles on which a protocol was=20 > developed, then, yes, you end up with protocol=20 > characteristics that are highly undesirable. The race=20 > condition you describe is one. The objections that I have=20 > repeatedly raised with the "abuse" of SUBSCRIBE to activate a=20 > service aren't purely academic: if you use a protocol in a=20 > way that is well outside its original design, then clearly=20 > identifiable bad things happen. >=20 > > I share John's concerns as to whether this really=20 > interoperates with=20 > > the PSTN. Perhaps if you had some call flows demonstrating it, this=20 > > would help. >=20 > Martin has put together some pretty nice call flows showing=20 > how this interoperates with the PSTN. Perhaps he could be=20 > convinced to share them with the wider group? >=20 > /a >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 14:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWPf-0003iw-Nc; Tue, 07 Nov 2006 14:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWPf-0003ih-3p for sipping@ietf.org; Tue, 07 Nov 2006 14:15:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWPa-0000bB-W5 for sipping@ietf.org; Tue, 07 Nov 2006 14:15:11 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2006 11:15:07 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="48149289:sNHT56246212" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7JF6Zc019901; Tue, 7 Nov 2006 14:15:06 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7JF6YJ029595; Tue, 7 Nov 2006 14:15:06 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 14:15:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Discussions ondraft-munakata-sipping-privacy-clarified-00 Date: Tue, 7 Nov 2006 14:15:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DA975@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Discussions ondraft-munakata-sipping-privacy-clarified-00 Thread-Index: AccCF1FoRBfUWf1ER4ySEHNusRFPkgAiaaDA From: "Michael Hammer \(mhammer\)" To: "Jonathan Rosenberg \(jdrosen\)" , "Mayumi Munakata" X-OriginalArrivalTime: 07 Nov 2006 19:15:06.0279 (UTC) FILETIME=[08BAAB70:01C702A1] DKIM-Signature: a=rsa-sha1; q=dns; l=4057; t=1162926906; x=1163790906; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20Discussions=20ondraft-munakata-sipping-privacy-clari fied-00 |To:=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20, =0A=20=20 =20=20=20=20=20=20=22Mayumi=20Munakata=22=20; X=v=3Dcisco.com=3B=20h=3D8Hhq1ygSQtHO5EtEcE6wiRXgP44=3D; b=VLsu1+r6j46OjCo51LKmrO4gG6NJsAICntvZ3PPTOpomTTxZ67PI9n4nbqDiA7WKA8NNJOZZ uEPN0kXLaFHSlOHHOXzxhLHTglu+ItXlW8ZClUvfkXXlUkPr7l1GtR/P; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org We should also try to minimize churn on PTSN GW designs as much as possible. Mike =20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen)=20 > Sent: Monday, November 06, 2006 5:55 PM > To: Mayumi Munakata > Cc: sipping@ietf.org > Subject: Re: [Sipping] Discussions=20 > ondraft-munakata-sipping-privacy-clarified-00 >=20 > Let me follow up some more to my remarks at the microphone today. >=20 > We clearly have a need for privacy services in SIP, and a=20 > revision of RFC 3323 is warranted. >=20 > What I think such a revision should do is: >=20 > 1. give guidance on how a UA can construct a completely=20 > anonymous request, utilizing anonymous gruu and using TURN to=20 > obtain IP addresses and ports for media relay. This would=20 > need to have guidance on various header fields, as rfc 3323=20 > does today. However the context there is how to construct (or=20 > omit) them, rather for guidance on removal or manipulation. >=20 > 2. Once you define (1), the additional service you need from=20 > the network is not to insert additional information into the=20 > request which identify the user. Thus, you need a flag that=20 > indicates the request is anonymous.=20 > We could use the Privacy: id value for this, or use the=20 > presence of an anonymous URI in the From as this flag. What I=20 > assert we do NOT want is anything more than just a single=20 > flag. We don't want specific guidance on whether its allowed=20 > to insert header foo vs. header bar. That is too complicated=20 > and I think is not useful. >=20 > 3. Additionally, one might want a solution for UA which, for=20 > some reason, cannot construct messages using (1). In that=20 > case, the UA will want to invoke a privacy service in the=20 > network. I would argue that we DONT want complex features=20 > that allow the UA to micro-manage the behavior of that=20 > privacy service. As a privacy service, it does a=20 > "full-processing" on the request - removing or obfuscating=20 > anything that could reveal user identity. Thus, the only=20 > thing we need to signal is a way for a UA to invoke that=20 > service, thats it. We could use a Privacy value for that, or=20 > we could use other techniques we have developed for service=20 > invocation. For example a route header field that points to=20 > an anonymization service. >=20 >=20 > I will point out that RFC 3323 itself has only seen=20 > deployment in the context of RFC 3325. That is, to my=20 > knowledge, the only value of the Privacy header ever used is "id". >=20 > -Jonathan R. >=20 >=20 > Mayumi Munakata wrote: >=20 > > Jonathan, > >=20 > > Thank you for the valuable comments. > >=20 > > To my knowledge, RFC 3323 is widely deployed already, so it is=20 > > necessary to keep the mechanism and clarify it as much as=20 > possible for=20 > > the already deployed implementations. > >=20 > > Your sip-identity-privacy draft may solve all the privacy problems,=20 > > but still, we need RFC 3323, even if it is a short-term solution. > >=20 > > If everybody views RFC 3323 in the same way, I can change=20 > the text in=20 > > Section 4.2. (Guidelines on specifying new priv-values) to=20 > something=20 > > like "it is RECOMMENDED to avoid defining a new priv-value=20 > in future=20 > > RFCs". > >=20 > > Thanks, Mayumi > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 14:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWUY-0005pV-DG; Tue, 07 Nov 2006 14:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWUX-0005pJ-0a for sipping@ietf.org; Tue, 07 Nov 2006 14:20:13 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWUV-0001DI-Lc for sipping@ietf.org; Tue, 07 Nov 2006 14:20:12 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA7JKATV010905; Tue, 7 Nov 2006 12:20:10 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Comments on draft-malas-performance-metrics-05.txt Date: Tue, 7 Nov 2006 12:20:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-malas-performance-metrics-05.txt Thread-Index: Acb8wtgBbb/Q/0j9QRaUokHgDisV9wAL/VfAAABucgAABxqJoAFiDVLQAADwXiA= From: "Jean-Francois Mule" To: "Malas, Daryl" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Daryl, Thank you for initiating this draft. It is quite a useful document, and at a minimum, it could bring common terminology and methods to the long list of implementations that measure some kinds of metrics like these and report those via various mechanisms. Here are a couple of first comments, some of which we did chat about yesterday. --- Template for metrics to guide extensibility: Given the wg acknowledged that the draft should only focus on the most widely supported and useable metrics, and that many will come up with other specific things, it would be useful to define how other metrics should be defined by vendors, operators. This could be a simple paragraph providing some kind of template: metric name, 3 or 4 letter abbreviation, problem statement or motivation, what is measured, how, in what units and optionally, if it can be averaged, specify how. --- IANA registry? It might be useful to have some discussions on an iana registry for these. This would allow protocol mechanisms used to report or correlate these metrics to refer to a well-known registry and it could help avoiding folks to overload a metric acronym. --- Section 5.2, Data Collection Considerations Replace: < The information may also be transmitted through use of=20 < SNMP traps as described in the work in progress SIP MIB draft ^ ^^^^^ ^^^^^^^^^^^^^^^^ ^ =20 With: > The information may also be transmitted through the use of=20 > network management protocols like SNMP [RFC3410] and via future=20 > extensions to the SIP MIB modules [] The reasons are: - SNMP notifications may not be the optimal way to fetch metrics in general - sure, they could be used if some metrics cross some configured threshold to create an alarm but folks also use those kinds of metrics with a statistical approach: over a period of hours/days, how are my systems doing on call session attempts, etc. so poll operations (or push at some well defined time intervals) may be the mainstream usage of this. Jean-Francois jfm@cablelabs.com _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 14:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX4S-0006W8-8R; Tue, 07 Nov 2006 14:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX4Q-0006VQ-Uv for sipping@ietf.org; Tue, 07 Nov 2006 14:57:18 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhX4O-0004xb-J2 for sipping@ietf.org; Tue, 07 Nov 2006 14:57:18 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA7JvFuL021562 for ; Tue, 7 Nov 2006 12:57:15 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Date: Tue, 7 Nov 2006 12:57:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Thread-Index: AccBfTlqal5OsK9jTBiHcxheAPIRSwBHz8EQ From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Some comments inline... - I don't see why it's necessary to have three tiers of configuration data (local network, device, and user) which must somehow be merged. In the first three cases, ISTM that you really only have one tier and in the fourth there is only some very limited set of well-defined information, namely the local proxy. It's not like you want a hotel proxy to even be able to specify what you should be using as your SIP AOR! [S] The reason why you need this differentiation in profiles is rooted in the Subscriber Modeling possible in SIP based networks. Assume the case where the 'Device (or client)' and the 'Users' are distinct (have their own SIP AORs and their own characteristics). Further, this client can be behind a Local Network (e.g. Public WiFi). In this case, there is a need to have distinct profiles, each provided to a specific AOR by a specific entity. For e.g.: -------- / \ | Service | =20 | Provider | ---> Provides the 'User' and 'Device' =20 \ Y / Profiles -------- =20 | ------ | / Local \ | | Network | | | Provider| -> Can Provide a 'Local Network'=20 | \ / Profile (e.g. STUN Server Address) | ------ | / | / =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Local Network ) =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 | | | --------- =20 | Client X| -> Client obtains the 'Device'=20 --------- Profile from the SP 'Y' / \ (e.g. Users allowed on this client) / \ =20 ------ ------ |User A| |User B| -> 'Users' obtain individual 'Profiles' ------ ------ (e.g. Services, Features=20 for each User) =20 Further, to answer why we can't combine the 'User' and 'Device' Profiles, consider the following case: - A Client X, provided by Service Provider Y who allows for its own Subscribers (e.g. User A) as well as users from other Service Providers (e.g. User B obtains services from Service Provider Z). - An example could be a client that acts as a kiosk ---------- ---------- | Service | | Service | | Provider | | Provider | =20 \ Y / \ Z / ---------- -------- | | | | | | | | | | =20 | | \ / --------- =20 | Client X| =20 --------- =20 / \ =20 ------ ------ |User A| |User B| =20 ------ ------ =20 =20 - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA can get its profile either via SIP or via an external reference in a NOTIFY. Let's keep life simple. [S] Well, would it not help to obtain smaller data (bytes) via the NOTIFY and external references (using say XCAP) to larger profiles (KB, MB?)from an external source? Or did I misunderstand the point? - The mechanisms for discovering the URI seem extremely complicated. Currently, there are different mechanisms for each of the three URI types. If we collapse this down to a single type then is there some reason we can't use the SIP DHCP option?=20 [S] In the case where the client is in a Local Network not controlled by the Service Profider, this may not be possible. For e.g. in cases where the client can reside in a Public WiFi network or home network you will not be able to control the DHCP options. To allow for multiple scenarios, it is required to have multiple methods. My $.02! Thanks! - S =20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 16:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY5q-00020x-Jl; Tue, 07 Nov 2006 16:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY5p-00020p-3g; Tue, 07 Nov 2006 16:02:49 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY5k-0004SX-48; Tue, 07 Nov 2006 16:02:49 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA7L2gCE003124; Tue, 7 Nov 2006 15:02:42 -0600 (CST) Received: from [135.244.5.130] (vkg.lra.lucent.com [135.244.5.130]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA7L2fM12397; Tue, 7 Nov 2006 15:02:41 -0600 (CST) Message-ID: <4550F470.7010507@lucent.com> Date: Tue, 07 Nov 2006 15:02:40 -0600 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Sipping] Comments on draft-malas-performance-metrics-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Malas, Daryl" , sipping , bmwg@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jean-Francois Mule wrote: > --- Template for metrics to guide extensibility: > Given the wg acknowledged that the draft should only focus on the most > widely supported and useable metrics, and that many will come up with > other specific things, it would be useful to define how other metrics > should be defined by vendors, operators. > This could be a simple paragraph providing some kind of template: metric > name, 3 or 4 letter abbreviation, problem statement or motivation, what > is measured, how, in what units and optionally, if it can be averaged, > specify how. There is complementary work in the bmwg WG that touches upon other metrics. Please see the following two companion documents: http://www.ietf.org/internet-drafts/draft-poretsky-sip-bench-term-02.txt http://www.ietf.org/internet-drafts/draft-poretsky-sip-bench-term-02.txt At least for right now, the bmwg drafts and the sipping drafts are tracking each other closely. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 17:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZSz-0006ZP-P1; Tue, 07 Nov 2006 17:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZSy-0006Yb-Rl for sipping@ietf.org; Tue, 07 Nov 2006 17:30:48 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZSx-00084W-AR for sipping@ietf.org; Tue, 07 Nov 2006 17:30:48 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 07 Nov 2006 14:27:57 -0800 X-IronPort-AV: i="4.09,398,1157353200"; d="scan'208"; a="606268676:sNHT57280004" 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: [Sipping] Comments on draft-malas-performance-metrics-05.txt Date: Tue, 7 Nov 2006 17:30:44 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280624EDAE@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-malas-performance-metrics-05.txt Thread-index: Acb8wtgBbb/Q/0j9QRaUokHgDisV9wAL/VfAAABucgAABxqJoAFiDVLQAADwXiAAB1RqUA== From: "Reinaldo Penno" To: "Jean-Francois Mule" , "Malas, Daryl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hello Daryl, This draft is a good idea and should be pursued forward. Here are my comments: "Time Begin (TB) - This is the time instant that starts a continuous time interval running until the related* response is received. TB occurs when the designated request has been processed by the application and last bit of the request packet has been sent from the proxy or UA (and is externally observable at some physical interface)**." * related to what? ** This is a little bit confusing. After the request is processed by the application, it traverses the TCP/IP stack, which imposes a considerable delay. Then it is put in the output interface and (most likely) sent out. So, I would suggest you specify exactly where you start TB. This would be probably after application processing, since you generally have no way to passing interface counters back to the application. "The first SIP message indicates the TB associated with the user or application TB expectation associated with the request." This phrase could use a rewrite to make it clear "This metric is commonly calculated as an average. The following represents the calculation for this metric as an average: SUM (Time of Final Response - Time of REGISTER Request) ARRD =3D ------------------------------------------------------- SUM # of REGISTER Requests" >From an implementaion perspective this seems a bit over the top. Some customers want exponential moving average, other the mean, other something else. We should separate the definition of metric, its collection and its presentation. The draft should focus on the former and mention the latters on some applicability statement. I would suggest you leave the exact method or just say that average is _one_ of the methods that could be used.=20 This applies to all other formulas in the draft. "3.1.2. Failed REGISTER Attempt RRD" It seems there is a failed register attempt inside every successful REGISTER completion when a 401 message is received. TS, in the case above, should a Failed REGISTER attempt be incremented as well? "seconds and/or milliseconds." I would suggest you settle on one time measurement. This is the type of thing that if is left open causes interoperability problems. Most timers in RFC3261 expire in XX seconds, so I would suggest you go with seconds for failed things and milliseconds for successful things, but never both for the same measurement. "In SIP, the message indicating status would be a non-100 Trying provisional message received in response to an INVITE request. In some cases, a non-100 Trying provisional message is not received, but rather a 200 message is received as the first status message instead. " Hummm...I'm not sure about that. It might make sense to consider a 183 a successful setup, but clearly not a 181. A response of type 181 would be similar to 302 below. What happens if I send a CANCEL before the receipt of a 2xx response. Is that counted as a successful session attempt or not? "3.4.1. Successful session completion SDT In a successful session completion, SDT is calculated as an average and is defined as the duration of a dialog from receipt of a 200 OK" In 3.2.1 you mention that a non-100 Provisional response establishes a session and signals a TS event. So, wouldn't a non-100 response also be counted as the TB in this case? What happens to the time between, for example, a 180 and a 200 message? It seems it is not counted anywhere.=20 General: I believe the notion of "Session Establishment" needs to be well defined in this doc. Again, here you consider a 200OK as the establishing the session but not 180. If a session is established with a=3Dsendonly or a=3Dinactive, etc In 3.2.1, 180 is consider as establishing a session. Thanks, REinaldo > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Tuesday, November 07, 2006 11:20 AM > To: Malas, Daryl > Cc: sipping > Subject: RE: [Sipping] Comments on=20 > draft-malas-performance-metrics-05.txt >=20 > Daryl, >=20 > Thank you for initiating this draft. >=20 > It is quite a useful document, and at a minimum, it could=20 > bring common terminology and methods to the long list of=20 > implementations that measure some kinds of metrics like these=20 > and report those via various mechanisms. >=20 > Here are a couple of first comments, some of which we did=20 > chat about yesterday. >=20 > --- Template for metrics to guide extensibility: > Given the wg acknowledged that the draft should only focus on=20 > the most widely supported and useable metrics, and that many=20 > will come up with other specific things, it would be useful=20 > to define how other metrics should be defined by vendors, operators. > This could be a simple paragraph providing some kind of=20 > template: metric name, 3 or 4 letter abbreviation, problem=20 > statement or motivation, what is measured, how, in what units=20 > and optionally, if it can be averaged, specify how. >=20 > --- IANA registry? > It might be useful to have some discussions on an iana=20 > registry for these. This would allow protocol mechanisms used=20 > to report or correlate these metrics to refer to a well-known=20 > registry and it could help avoiding folks to overload a=20 > metric acronym. >=20 > --- Section 5.2, Data Collection Considerations > Replace: > < The information may also be transmitted through use of <=20 > SNMP traps as described in the work in progress SIP MIB draft > ^ ^^^^^ ^^^^^^^^^^^^^^^^ ^ =20 > With: > > The information may also be transmitted through the use of network=20 > > management protocols like SNMP [RFC3410] and via future=20 > extensions to=20 > > the SIP MIB modules [] >=20 > The reasons are: > - SNMP notifications may not be the optimal way to fetch=20 > metrics in general > - sure, they could be used if some metrics cross some=20 > configured threshold to create an alarm but folks also use=20 > those kinds of metrics with a statistical approach: over a=20 > period of hours/days, how are my systems doing on call=20 > session attempts, etc. so poll operations (or push at some=20 > well defined time intervals) may be the mainstream usage of this. >=20 > Jean-Francois > jfm@cablelabs.com >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 07 22:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghdqw-0005cQ-Uf; Tue, 07 Nov 2006 22:11:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghdqu-0005Yg-Qg for sipping@ietf.org; Tue, 07 Nov 2006 22:11:48 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdoO-0001nV-2K for sipping@ietf.org; Tue, 07 Nov 2006 22:09:13 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2006 19:09:11 -0800 X-IronPort-AV: i="4.09,399,1157353200"; d="scan'208"; a="87026179:sNHT48313440" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA839Bw6024398 for ; Tue, 7 Nov 2006 19:09:11 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA839Bin001554 for ; Tue, 7 Nov 2006 19:09:11 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 19:09:11 -0800 Received: from [130.129.71.112] ([10.21.98.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 19:09:11 -0800 In-Reply-To: <454F8A43.8000400@cisco.com> References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> <454F8A43.8000400@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <001BC546-95FD-42E4-85A2-57E0B9C551A7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 7 Nov 2006 19:09:15 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Nov 2006 03:09:11.0211 (UTC) FILETIME=[433AD7B0:01C702E3] DKIM-Signature: a=rsa-sha1; q=dns; l=1893; t=1162955351; x=1163819351; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20draft-rosenberg-sipping-overload-reqs=20recovery; X=v=3Dcisco.com=3B=20h=3DNsmclo610L2TAjaPHfHtozoy3kk=3D; b=SLlg4YWTYmfD4wuSm+Wpay/waS50u6GdQyHDXJOuI6Z86YjLXjRTAgAdcoNZis5pU773PMtJ TVKFu+a7AeyDpggogDBNvxh6DMUlotgGrrcN4t5tHFM65La5RkDqV0+2; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sipping Subject: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Clearly this was a long way from the text for a requirement but, yes, I was proposing that this be added as one of the requirements. I don't feel strongly about this and if we can't figure out how to express this as a requirement that is useful, I can certainly live with not adding it. The reason I think it is a requirement is I can easily imagine that the mechanism for doing overload push-back causes the systems to fail in the way I described below (i.e. never recover back to steady state). On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > > > Cullen Jennings wrote: > >> A possible additional requirement.... >> Imagine a system (perhaps a single proxy) that could do 100cps. It >> is in steady state doing 80cps with very few retransmission. Then >> for 5 minutes the incoming requests goes to 500cps then drops >> back to an incoming call rate of 80cps. The question is, how long >> before the system gets back to the state where it if is >> successfully processing all the 80cps? > > As soon as it can. Are you suggesting a requirement here? Seems > like this is an implementation thing and wouldn't impact any > protocol mechanisms. > >> I have seen systems that never recover - that is bad. I think one >> of the design goals is that it is at least possible to build to >> systems that recover back to steady state relatively quickly >> after an overload impulse. > > Sure; but I'm not sure I see the protocol requirement. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 03:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiQN-00018C-RA; Wed, 08 Nov 2006 03:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhiQL-000183-Q5 for sipping@ietf.org; Wed, 08 Nov 2006 03:04:41 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhiQL-00069i-8U for sipping@ietf.org; Wed, 08 Nov 2006 03:04:41 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 09:04:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 09:04:07 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC0C02F991@ftrdmel1.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: Acb+lcaO0xskB581R4yEOvZkfxxTvwAmwSWAANr8WiAAG1lbIA== From: "GARCIN Sebastien RD-CORE-ISS" To: "Michael Hammer \(mhammer\)" , "Adam Roach" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 08 Nov 2006 08:04:26.0601 (UTC) FILETIME=[826CD590:01C7030C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There may have been a slite misunderstanding, I do not believe that = using this BCFP mechanisn is the right way.=20 The draft-ploetz-ccss based on SUB/NOT is my prefered solution to the = problem? Nobody to my knowledge has provided a "non-academic" = explanation as to why it does not work, so why do I need to look = elsewhere? Moreover, migration from PSTN to SIP does require that the services = provided by the underlying SIP and PSTN networks look similar to the = users a least during the migration phase, there is not much one can do = about it. s=E9bastien =20 =20 -----Message d'origine----- De : Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Envoy=E9 : mardi 7 novembre 2006 19:51 =C0 : GARCIN Sebastien RD-CORE-ISS; Adam Roach; Jonathan Rosenberg = (jdrosen) Cc : IETF Sipping List Objet : RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 I still have not seen a convincing explanation that any abuse exists. = This feature is about meta information; precisely the type of = information that the events framework was intended.=20 When the 486 Busy is received, that call is done. It is then about what = is the state of the queue, and who should initiate the next call = involving the called party. My problem with the way this is headed, is that it is designing a SIP = feature using PSTN thinking. You could get the same user experience, = but is modeling this with a mechanism designed for conference calls the = way to go? Mike > -----Original Message----- > From: GARCIN Sebastien RD-CORE-ISS > [mailto:sebastien.garcin@orange-ftgroup.com] > Sent: Friday, November 03, 2006 5:17 AM > To: Adam Roach; Jonathan Rosenberg (jdrosen) > Cc: IETF Sipping List > Subject: RE: [Sipping] comments on > draft-roach-sipping-callcomp-bfcp-00 >=20 > hi >=20 > >>The objections that I have repeatedly raised with the "abuse" of=20 > >>SUBSCRIBE to activate a service aren't purely academic >=20 > I am still missing the "non-academic" arguments that would convince me = > not to the procedures in draft-ploetz. >=20 > Thanks for clarifying that part. >=20 > s=E9bastien >=20 > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com] Envoy=E9 : jeudi 2 novembre=20 > 2006 16:43 =C0 : Jonathan Rosenberg Cc : IETF Sipping List Objet : Re: = > [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 >=20 > Jonathan Rosenberg wrote: > > Its not clear to me that this mechanism works well in the face of=20 > > forking. Seems like you could end up with disparate queues > for each of > > my phones. >=20 > That's pretty much what I intended, yes. As far as I can tell, the net = > result -- that is, the behavior of the system > -- would end up being identical (or, at least, substantially the same) = > with queues maintained on each of your devices versus a single,=20 > centralized queue -- unless there's more than one of you, in which=20 > case neither solution will behave particularly gracefully (although I=20 > believe the forking setup has better recovery properties under such=20 > circumstances). >=20 > When I get a spare moment, I'll work through a few scenarios to=20 > demonstrate how the externally observed system behavior is the same=20 > between distributed management of several queues and centralized=20 > management of one queue. >=20 > > Similar issues arise when the originating user has multiple > devices.=20 > > So if I call you from phone 1, and later you are available, > does the > > ringback happen only at phone 1 or all of my phones? Seems like the=20 > > latter is much more desirable. That too implies that a UA-based=20 > > solution on the originating side has some problems. >=20 > That depends. Are you asserting this as a new requirement? No one has=20 > raised this capability as a requirement so far, and the previously=20 > offered solution certainly didn't have this property. >=20 > To be clear: I agree that this is probably an improvement on the=20 > service; however, the more requirements we pile on, the harder a=20 > solution becomes -- and we've become experts at putting so many=20 > requirements on a problem that the solution space dwindles down to=20 > nothing. >=20 > > There is clearly a relationship between all of this and presence; I=20 > > think you need to call that out. >=20 > Martin beat me to it, but I'll reiterate his comment: the relationship = > here isn't related as much to presence as it is to dialog state. And=20 > that is called out in the discussion about centralized queue=20 > management. >=20 > > On whether BFCP is the right thing or not for this problem, I'm not=20 > > sure. In one sense, you could characterize this as really a problem=20 > > with RFC3265 in general; that for certain event packages, > notification > > of an event to all watchers can cause them to take actions > that result > > in a further change to that same state. This is a race condition. >=20 > Not in general -- this race condition arises in the draft-poetzl=20 > document because it's doing something with SUBSCRIBE that SUBSCRIBE=20 > was never meant to do: changing the state of the thing that is=20 > watched. >=20 > Let's go back to first principles: SUBSCRIBE is a request to retrieve=20 > the state of a resource, and receive that state whenever it changes. > It's a way for an observer to *LOOK* at a state. >=20 > Now, as I'm always having to tell my kids: you look with your eyes,=20 > not with your hands. If the act of subscribing to a state changes that = > very state, then you're no longer looking > -- you're touching. SUBSCRIBE doesn't touch the state it's monitoring. = > (Now, we have defined some > *meta* state regarding the very state of that subscription, but you=20 > need to subscribe to that separately, and the act of subscribing to=20 > that meta-state doesn't change the meta-state). >=20 > If you violate the basic principles on which a protocol was developed, = > then, yes, you end up with protocol characteristics that are highly=20 > undesirable. The race condition you describe is one. The objections=20 > that I have repeatedly raised with the "abuse" of SUBSCRIBE to=20 > activate a service aren't purely academic: if you use a protocol in a=20 > way that is well outside its original design, then clearly=20 > identifiable bad things happen. >=20 > > I share John's concerns as to whether this really > interoperates with > > the PSTN. Perhaps if you had some call flows demonstrating it, this=20 > > would help. >=20 > Martin has put together some pretty nice call flows showing how this=20 > interoperates with the PSTN. Perhaps he could be convinced to share=20 > them with the wider group? >=20 > /a >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 04:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjZC-0000GA-TE; Wed, 08 Nov 2006 04:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhjZB-000085-EO for sipping@ietf.org; Wed, 08 Nov 2006 04:17:53 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhjNu-0007LN-V3 for sipping@ietf.org; Wed, 08 Nov 2006 04:06:17 -0500 Received: (qmail 20777 invoked by uid 0); 8 Nov 2006 09:05:45 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Nov 2006 09:05:45 -0000 Message-ID: <005e01c70315$1bcf1060$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "GARCIN Sebastien RD-CORE-ISS" , "Michael Hammer \(mhammer\)" , "Adam Roach" , "Jonathan Rosenberg \(jdrosen\)" References: <49E7012A614B024B80A7D175CB9A64EC0C02F991@ftrdmel1.rd.francetelecom.fr> Subject: Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 10:05:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.1 (+) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Sebastien, It appears to me that the discussion is really not about "work versus not-work", but more about "elegant versus not-elegant" or "in the spirit of SIP(tm)" My preference is also for a pure SIP-based solution, because adding BFCP adds an additional deployment burden on already feature-heavy SIP devices. You will end up with all the nightmares of firewall traversal, privacy features, etc, etc, all of which are (at least in the process of) being resolved within SIP. That being said, I believe what is triggering the "academic" objections is the underlying model of draft-poetzl-sipping-call-completion-01: multiple subscriptions to a single resource (the CCBS/CCNR queue) but a single notification to the "first, non-suspended subscriber". That goes against RFC3265 (in more than one ways) If instead it was modeled / described as a subscription to a queue *position* (where the subscriber does not know / need to know which position that is, relative to other subscribers), it makes more sense. IMO it would help if the underlying conceptual model were explicitly described in the draft. Then, instead of "queue management", I would suggest to model suspend/resume as event filtering: the subscriber enables/disables his interest in the "available for a call" event. Identification and prioritization of CCBS/CCNR calls over "regular" calls could be handled as follows: in the NOTIFY for "available for a call", add a URI to which the subscriber must send his INVITE. In this URI, put something (no need for standardization here, can e.g. be in the username ) that the callee can recognise as resulting from a CCBS/CCNR callback (this URI needs to be a GRUU). Alternatively, you could specify that the callback needs to take place in the context of the same dialog as the SUBSCRIBE/NOTIFY for the CCBS/CCNR event, but some people dislike such multi-usages. Regards, Jeroen GARCIN Sebastien RD-CORE-ISS wrote: > There may have been a slite misunderstanding, I do not believe that > using this BCFP mechanisn is the right way. > The draft-ploetz-ccss based on SUB/NOT is my prefered solution to the > problem? Nobody to my knowledge has provided a "non-academic" > explanation as to why it does not work, so why do I need to look > elsewhere? > > Moreover, migration from PSTN to SIP does require that the services > provided by the underlying SIP and PSTN networks look similar to the > users a least during the migration phase, there is not much one can > do about it. > > sébastien > > > -----Message d'origine----- > De : Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Envoyé : mardi 7 novembre 2006 19:51 > À : GARCIN Sebastien RD-CORE-ISS; Adam Roach; Jonathan Rosenberg > (jdrosen) > Cc : IETF Sipping List > Objet : RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 > > I still have not seen a convincing explanation that any abuse exists. > This feature is about meta information; precisely the type of > information that the events framework was intended. > > When the 486 Busy is received, that call is done. It is then about > what is the state of the queue, and who should initiate the next call > involving the called party. > > My problem with the way this is headed, is that it is designing a SIP > feature using PSTN thinking. You could get the same user experience, > but is modeling this with a mechanism designed for conference calls > the way to go? > > Mike > > >> -----Original Message----- >> From: GARCIN Sebastien RD-CORE-ISS >> [mailto:sebastien.garcin@orange-ftgroup.com] >> Sent: Friday, November 03, 2006 5:17 AM >> To: Adam Roach; Jonathan Rosenberg (jdrosen) >> Cc: IETF Sipping List >> Subject: RE: [Sipping] comments on >> draft-roach-sipping-callcomp-bfcp-00 >> >> hi >> >>>> The objections that I have repeatedly raised with the "abuse" of >>>> SUBSCRIBE to activate a service aren't purely academic >> >> I am still missing the "non-academic" arguments that would convince >> me not to the procedures in draft-ploetz. >> >> Thanks for clarifying that part. >> >> sébastien >> >> -----Message d'origine----- >> De : Adam Roach [mailto:adam@nostrum.com] Envoyé : jeudi 2 novembre >> 2006 16:43 À : Jonathan Rosenberg Cc : IETF Sipping List Objet : Re: >> [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 >> >> Jonathan Rosenberg wrote: >>> Its not clear to me that this mechanism works well in the face of >>> forking. Seems like you could end up with disparate queues >> for each of >>> my phones. >> >> That's pretty much what I intended, yes. As far as I can tell, the >> net result -- that is, the behavior of the system >> -- would end up being identical (or, at least, substantially the >> same) with queues maintained on each of your devices versus a single, >> centralized queue -- unless there's more than one of you, in which >> case neither solution will behave particularly gracefully (although I >> believe the forking setup has better recovery properties under such >> circumstances). >> >> When I get a spare moment, I'll work through a few scenarios to >> demonstrate how the externally observed system behavior is the same >> between distributed management of several queues and centralized >> management of one queue. >> >>> Similar issues arise when the originating user has multiple >> devices. >>> So if I call you from phone 1, and later you are available, >> does the >>> ringback happen only at phone 1 or all of my phones? Seems like the >>> latter is much more desirable. That too implies that a UA-based >>> solution on the originating side has some problems. >> >> That depends. Are you asserting this as a new requirement? No one has >> raised this capability as a requirement so far, and the previously >> offered solution certainly didn't have this property. >> >> To be clear: I agree that this is probably an improvement on the >> service; however, the more requirements we pile on, the harder a >> solution becomes -- and we've become experts at putting so many >> requirements on a problem that the solution space dwindles down to >> nothing. >> >>> There is clearly a relationship between all of this and presence; I >>> think you need to call that out. >> >> Martin beat me to it, but I'll reiterate his comment: the >> relationship here isn't related as much to presence as it is to >> dialog state. And that is called out in the discussion about >> centralized queue management. >> >>> On whether BFCP is the right thing or not for this problem, I'm not >>> sure. In one sense, you could characterize this as really a problem >>> with RFC3265 in general; that for certain event packages, >> notification >>> of an event to all watchers can cause them to take actions >> that result >>> in a further change to that same state. This is a race condition. >> >> Not in general -- this race condition arises in the draft-poetzl >> document because it's doing something with SUBSCRIBE that SUBSCRIBE >> was never meant to do: changing the state of the thing that is >> watched. >> >> Let's go back to first principles: SUBSCRIBE is a request to retrieve >> the state of a resource, and receive that state whenever it changes. >> It's a way for an observer to *LOOK* at a state. >> >> Now, as I'm always having to tell my kids: you look with your eyes, >> not with your hands. If the act of subscribing to a state changes >> that very state, then you're no longer looking >> -- you're touching. SUBSCRIBE doesn't touch the state it's >> monitoring. (Now, we have defined some >> *meta* state regarding the very state of that subscription, but you >> need to subscribe to that separately, and the act of subscribing to >> that meta-state doesn't change the meta-state). >> >> If you violate the basic principles on which a protocol was >> developed, then, yes, you end up with protocol characteristics that >> are highly undesirable. The race condition you describe is one. The >> objections that I have repeatedly raised with the "abuse" of >> SUBSCRIBE to activate a service aren't purely academic: if you use a >> protocol in a way that is well outside its original design, then >> clearly identifiable bad things happen. >> >>> I share John's concerns as to whether this really >> interoperates with >>> the PSTN. Perhaps if you had some call flows demonstrating it, this >>> would help. >> >> Martin has put together some pretty nice call flows showing how this >> interoperates with the PSTN. Perhaps he could be convinced to share >> them with the wider group? >> >> /a >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 07:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhmiM-0007cj-9o; Wed, 08 Nov 2006 07:39:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhmiK-0007ce-NC for sipping@ietf.org; Wed, 08 Nov 2006 07:39:32 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhmiF-0005mK-VP for sipping@ietf.org; Wed, 08 Nov 2006 07:39:30 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:39:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 13:40:17 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC0C02FE1B@ftrdmel1.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: AccDFRyMNQ1TMlFTT5Wo+K20Ye2u7gAGiTaw From: "GARCIN Sebastien RD-CORE-ISS" To: "Jeroen van Bemmel" , "Michael Hammer \(mhammer\)" , "Adam Roach" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 08 Nov 2006 12:39:03.0077 (UTC) FILETIME=[DF2B8D50:01C70332] X-Spam-Score: 1.1 (+) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: IETF Sipping List X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Jeroen, See below, Regards, s=E9bastien=20 -----Message d'origine----- De : Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Envoy=E9 : mercredi 8 novembre 2006 10:06 =C0 : GARCIN Sebastien RD-CORE-ISS; Michael Hammer (mhammer); Adam = Roach; Jonathan Rosenberg (jdrosen) Cc : IETF Sipping List Objet : Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Sebastien, It appears to me that the discussion is really not about "work versus = not-work", but more about "elegant versus not-elegant" or "in the spirit = of SIP(tm)" My preference is also for a pure SIP-based solution, because adding BFCP = adds an additional deployment burden on already feature-heavy SIP = devices.=20 You will end up with all the nightmares of firewall traversal, privacy = features, etc, etc, all of which are (at least in the process of) being = resolved within SIP. That being said, I believe what is triggering the "academic" objections = is the underlying model of draft-poetzl-sipping-call-completion-01: = multiple subscriptions to a single resource (the CCBS/CCNR queue) but a = single notification to the "first, non-suspended subscriber". That goes = against RFC3265 (in more than one ways) [SG: That depends on what you consider being the resource monitored. = Basically if you consider that what is being monitored is "access to the = B-user according to the CCSS service rules", then it is perfectly OK to = send a notification to the "first non-suspended subscriber".] If instead it was modeled / described as a subscription to a queue *position* (where the subscriber does not know / need to know which = position that is, relative to other subscribers), it makes more sense. = IMO it would help if the underlying conceptual model were explicitly = described in the draft. [SG: We might be agreeing here, but further discussion would be needed I = guess.] Then, instead of "queue management", I would suggest to model = suspend/resume as event filtering: the subscriber enables/disables his = interest in the "available for a call" event. Identification and prioritization of CCBS/CCNR calls over "regular" = calls could be handled as follows: in the NOTIFY for "available for a = call", add a URI to which the subscriber must send his INVITE. In this = URI, put something (no need for standardization here, can e.g. be in the = username ) that the callee can recognise as resulting from a CCBS/CCNR = callback (this URI needs to be a GRUU).=20 [SG: If a non-GRUU solution works and that the limitations are = understood then I don't want to risk jeopardizing the service = availability date just for the sake of having an elegant solution based = on GRUU. IMHO draft-ploetzl-sipping is not the right place to specify = whether GRUU is mandatory to the service or not, all that is needed is = the protocol extensions and their limitations, it is not up to IETF to = describe CCSS service logic.] Alternatively, you could specify that the callback needs to take place = in the context of the same dialog as the SUBSCRIBE/NOTIFY for the = CCBS/CCNR event, but some people dislike such multi-usages. [SG: You may be assuming that we are in an environment with forking, = nonetheless forking is not mandatory and hence using GRUU shouldn't be = either in the service implementation.] Regards, Jeroen GARCIN Sebastien RD-CORE-ISS wrote: > There may have been a slite misunderstanding, I do not believe that=20 > using this BCFP mechanisn is the right way. > The draft-ploetz-ccss based on SUB/NOT is my prefered solution to the=20 > problem? Nobody to my knowledge has provided a "non-academic" > explanation as to why it does not work, so why do I need to look=20 > elsewhere? > > Moreover, migration from PSTN to SIP does require that the services=20 > provided by the underlying SIP and PSTN networks look similar to the=20 > users a least during the migration phase, there is not much one can do = > about it. > > s=E9bastien > > > -----Message d'origine----- > De : Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Envoy=E9 :=20 > mardi 7 novembre 2006 19:51 =C0 : GARCIN Sebastien RD-CORE-ISS; Adam=20 > Roach; Jonathan Rosenberg > (jdrosen) > Cc : IETF Sipping List > Objet : RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 > > I still have not seen a convincing explanation that any abuse exists. > This feature is about meta information; precisely the type of=20 > information that the events framework was intended. > > When the 486 Busy is received, that call is done. It is then about=20 > what is the state of the queue, and who should initiate the next call=20 > involving the called party. > > My problem with the way this is headed, is that it is designing a SIP=20 > feature using PSTN thinking. You could get the same user experience,=20 > but is modeling this with a mechanism designed for conference calls=20 > the way to go? > > Mike > > >> -----Original Message----- >> From: GARCIN Sebastien RD-CORE-ISS >> [mailto:sebastien.garcin@orange-ftgroup.com] >> Sent: Friday, November 03, 2006 5:17 AM >> To: Adam Roach; Jonathan Rosenberg (jdrosen) >> Cc: IETF Sipping List >> Subject: RE: [Sipping] comments on >> draft-roach-sipping-callcomp-bfcp-00 >> >> hi >> >>>> The objections that I have repeatedly raised with the "abuse" of=20 >>>> SUBSCRIBE to activate a service aren't purely academic >> >> I am still missing the "non-academic" arguments that would convince=20 >> me not to the procedures in draft-ploetz. >> >> Thanks for clarifying that part. >> >> s=E9bastien >> >> -----Message d'origine----- >> De : Adam Roach [mailto:adam@nostrum.com] Envoy=E9 : jeudi 2 novembre >> 2006 16:43 =C0 : Jonathan Rosenberg Cc : IETF Sipping List Objet : = Re: >> [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 >> >> Jonathan Rosenberg wrote: >>> Its not clear to me that this mechanism works well in the face of=20 >>> forking. Seems like you could end up with disparate queues >> for each of >>> my phones. >> >> That's pretty much what I intended, yes. As far as I can tell, the=20 >> net result -- that is, the behavior of the system >> -- would end up being identical (or, at least, substantially the >> same) with queues maintained on each of your devices versus a single, = >> centralized queue -- unless there's more than one of you, in which=20 >> case neither solution will behave particularly gracefully (although I = >> believe the forking setup has better recovery properties under such=20 >> circumstances). >> >> When I get a spare moment, I'll work through a few scenarios to=20 >> demonstrate how the externally observed system behavior is the same=20 >> between distributed management of several queues and centralized=20 >> management of one queue. >> >>> Similar issues arise when the originating user has multiple >> devices. >>> So if I call you from phone 1, and later you are available, >> does the >>> ringback happen only at phone 1 or all of my phones? Seems like the=20 >>> latter is much more desirable. That too implies that a UA-based=20 >>> solution on the originating side has some problems. >> >> That depends. Are you asserting this as a new requirement? No one has = >> raised this capability as a requirement so far, and the previously=20 >> offered solution certainly didn't have this property. >> >> To be clear: I agree that this is probably an improvement on the=20 >> service; however, the more requirements we pile on, the harder a=20 >> solution becomes -- and we've become experts at putting so many=20 >> requirements on a problem that the solution space dwindles down to=20 >> nothing. >> >>> There is clearly a relationship between all of this and presence; I=20 >>> think you need to call that out. >> >> Martin beat me to it, but I'll reiterate his comment: the=20 >> relationship here isn't related as much to presence as it is to=20 >> dialog state. And that is called out in the discussion about=20 >> centralized queue management. >> >>> On whether BFCP is the right thing or not for this problem, I'm not=20 >>> sure. In one sense, you could characterize this as really a problem=20 >>> with RFC3265 in general; that for certain event packages, >> notification >>> of an event to all watchers can cause them to take actions >> that result >>> in a further change to that same state. This is a race condition. >> >> Not in general -- this race condition arises in the draft-poetzl=20 >> document because it's doing something with SUBSCRIBE that SUBSCRIBE=20 >> was never meant to do: changing the state of the thing that is=20 >> watched. >> >> Let's go back to first principles: SUBSCRIBE is a request to retrieve = >> the state of a resource, and receive that state whenever it changes. >> It's a way for an observer to *LOOK* at a state. >> >> Now, as I'm always having to tell my kids: you look with your eyes,=20 >> not with your hands. If the act of subscribing to a state changes=20 >> that very state, then you're no longer looking >> -- you're touching. SUBSCRIBE doesn't touch the state it's=20 >> monitoring. (Now, we have defined some >> *meta* state regarding the very state of that subscription, but you=20 >> need to subscribe to that separately, and the act of subscribing to=20 >> that meta-state doesn't change the meta-state). >> >> If you violate the basic principles on which a protocol was=20 >> developed, then, yes, you end up with protocol characteristics that=20 >> are highly undesirable. The race condition you describe is one. The=20 >> objections that I have repeatedly raised with the "abuse" of=20 >> SUBSCRIBE to activate a service aren't purely academic: if you use a=20 >> protocol in a way that is well outside its original design, then=20 >> clearly identifiable bad things happen. >> >>> I share John's concerns as to whether this really >> interoperates with >>> the PSTN. Perhaps if you had some call flows demonstrating it, this=20 >>> would help. >> >> Martin has put together some pretty nice call flows showing how this=20 >> interoperates with the PSTN. Perhaps he could be convinced to share=20 >> them with the wider group? >> >> /a >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sip@ietf.org for new developments of core SIP >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 09:06:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gho2x-0007OI-HK; Wed, 08 Nov 2006 09:04:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gho0y-0006q6-C3 for sipping@ietf.org; Wed, 08 Nov 2006 09:02:52 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghnne-0006tD-2C for sipping@ietf.org; Wed, 08 Nov 2006 08:49:11 -0500 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kA8Dn6xj020923; Wed, 8 Nov 2006 14:49:06 +0100 Received: from [127.0.0.1] ([155.132.188.76]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006110814490079:3047 ; Wed, 8 Nov 2006 14:49:00 +0100 Message-ID: <4551E041.8080901@alcatel.fr> Date: Wed, 08 Nov 2006 14:48:49 +0100 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 References: <49E7012A614B024B80A7D175CB9A64EC0C02FE1B@ftrdmel1.rd.francetelecom.fr> In-Reply-To: <49E7012A614B024B80A7D175CB9A64EC0C02FE1B@ftrdmel1.rd.francetelecom.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/08/2006 14:49:01, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/08/2006 14:49:02, Serialize complete at 11/08/2006 14:49:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.3 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF Sipping List , Adam Roach , "Michael Hammer \(mhammer\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org About the usage of BFCP, chairs started a poll yesterday during the meeting, but decided to stop it after 5/10 people raised their hand to vote for "this is a good approach"... Then, Rohan(I think) asked "who understand / is interested by the problem"?, and since few people were responding, nobody got the chance to vote for "this is NOT a good approach"... So, maybe we can start a new poll on mailing list with *interested* people? Jeroen van Bemmel wrote: > That being said, I believe what is triggering the "academic" objections is the underlying model of draft-poetzl-sipping-call-completion-01: multiple subscriptions to a single resource (the CCBS/CCNR queue) but a single notification to the "first, non-suspended subscriber". That goes against > RFC3265 (in more than one ways) > Can you clatify this statement? for me, this is not completely clear why... _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 10:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpJh-0004My-39; Wed, 08 Nov 2006 10:26:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpJg-0004Mp-42 for sipping@ietf.org; Wed, 08 Nov 2006 10:26:16 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpJe-0003tJ-Ak for sipping@ietf.org; Wed, 08 Nov 2006 10:26:16 -0500 Received: (qmail 18206 invoked by uid 0); 8 Nov 2006 15:27:21 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Nov 2006 15:27:21 -0000 Message-ID: <00f901c7034a$3908f4e0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <49E7012A614B024B80A7D175CB9A64EC0C02FE1B@ftrdmel1.rd.francetelecom.fr> <4551E041.8080901@alcatel.fr> Subject: Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 16:26:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF Sipping List , Adam Roach , "Michael Hammer \(mhammer\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org >> That being said, I believe what is triggering the "academic" >> objections is the underlying model of >> draft-poetzl-sipping-call-completion-01: multiple subscriptions to a >> single resource (the CCBS/CCNR queue) but a single notification to >> the "first, non-suspended subscriber". That goes against RFC3265 (in >> more than one ways) > Can you clatify this statement? for me, this is not completely clear > why... RFC3265 defines a model in which subscribers subscribe to a resource, and get notified of event changes. The way I interpret the current text in draft-poetzl, the resource is the queue of the target user, i.e. a single unique resource per callee. If two subscribers (say A and B) subscribe to some callee's queue Q, and some event occurs for Q, then both should receive a NOTIFY. In RFC3265 there is no notion of selecting a specific subscriber from the set of all subscribers to receive the NOTIFY. A similar argument holds for the notion of "suspending" a subscription, in the RFC3265 model you are either subscribed to an event or not. Of course, since RFC3265 there have been extensions that can affect this basic pattern. For example, when event filters (RFC4660) are being used, it might be that A receives a NOTIFY while B does not, due to filtering. However, if this is intended the draft should explicitly talk about that, and preferrably reuse what is already standardized, instead of defining an entirely different mechanism using a mix of event package parameters, new SIP headers, and new usages of existing SIP headers. The current draft has two (yes, 2 in total) normative references: RFC3261 and RFC3265. My suggestion would be to investigate whether other existing extensions, such as RFC4660, can be leveraged to realize this service. Reusing existing, standardized & accepted mechanisms would likely make the draft more acceptable to a wider audience Regards, Jeroen _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 11:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq8P-00065E-5B; Wed, 08 Nov 2006 11:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq8N-000651-IH for sipping@ietf.org; Wed, 08 Nov 2006 11:18:39 -0500 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghq8M-0003HT-8Z for sipping@ietf.org; Wed, 08 Nov 2006 11:18:39 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA8GIaL8029918; Wed, 8 Nov 2006 10:18:36 -0600 (CST) Received: from [135.244.5.84] (volkerh.lra.lucent.com [135.244.5.84]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA8GIYo18529; Wed, 8 Nov 2006 11:18:35 -0500 (EST) Message-ID: <4552034D.8000005@bell-labs.com> Date: Wed, 08 Nov 2006 08:18:21 -0800 From: Volker Hilt User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com> <454F8A43.8000400@cisco.com> <001BC546-95FD-42E4-85A2-57E0B9C551A7@cisco.com> In-Reply-To: <001BC546-95FD-42E4-85A2-57E0B9C551A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think that stability of overload control is an important requirement. We certainly want to avoid building something that starts to oscillate once it reaches overload state. It may be somehow implicit to REQ 1 since an unstable system will hardly be able to maintain the overall useful throughput at a high level. Volker Cullen Jennings wrote: > Clearly this was a long way from the text for a requirement but, yes, I > was proposing that this be added as one of the requirements. I don't > feel strongly about this and if we can't figure out how to express this > as a requirement that is useful, I can certainly live with not adding it. > > The reason I think it is a requirement is I can easily imagine that the > mechanism for doing overload push-back causes the systems to fail in the > way I described below (i.e. never recover back to steady state). > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > >> >> >> Cullen Jennings wrote: >> >>> A possible additional requirement.... >>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>> is in steady state doing 80cps with very few retransmission. Then >>> for 5 minutes the incoming requests goes to 500cps then drops back >>> to an incoming call rate of 80cps. The question is, how long before >>> the system gets back to the state where it if is successfully >>> processing all the 80cps? >> >> As soon as it can. Are you suggesting a requirement here? Seems like >> this is an implementation thing and wouldn't impact any protocol >> mechanisms. >> >>> I have seen systems that never recover - that is bad. I think one of >>> the design goals is that it is at least possible to build to systems >>> that recover back to steady state relatively quickly after an >>> overload impulse. >> >> Sure; but I'm not sure I see the protocol requirement. >> >> -Jonathan R. >> >> >> >> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 11:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqWs-0001H1-CD; Wed, 08 Nov 2006 11:43:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqW7-0000Sr-08 for sipping@ietf.org; Wed, 08 Nov 2006 11:43:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhqUW-00065D-5X for sipping@ietf.org; Wed, 08 Nov 2006 11:41:33 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2006 11:41:32 -0500 X-IronPort-AV: i="4.09,401,1157342400"; d="scan'208"; a="109135434:sNHT52268392" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8GfVoo015712; Wed, 8 Nov 2006 11:41:31 -0500 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 kA8GfRYT013497; Wed, 8 Nov 2006 11:41:31 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 11:41:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 11:41:28 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DAC14@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: AccDPKo2+hdVmg1URUC//iEzqVqcHwAGAWTQ From: "Michael Hammer \(mhammer\)" To: , "Jeroen van Bemmel" X-OriginalArrivalTime: 08 Nov 2006 16:41:29.0991 (UTC) FILETIME=[BDCE7970:01C70354] DKIM-Signature: a=rsa-sha1; q=dns; l=1446; t=1163004091; x=1163868091; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20comments=20on=20draft-roach-sipping-callcomp-bfcp-00 |To:, =20=22Jeroen=20van=20Bemmel=22=20; X=v=3Dcisco.com=3B=20h=3DxesuDYUS5hhP5YgFmay3D64vSwM=3D; b=lgBMoByTUB23rk8gfJQv59zNxbE7MIauT1JfJEuNlGXhF17OYXbfJP6r3PmuPJfExa67FO7o SdcLTliEIXFSbUJCFWLnbfC5LgiBX0L+iVNbpnMMyURLuDcc/lGAPeq/; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF Sipping List , Adam Roach X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This does not sound like a valid poll. Mike =20 > -----Original Message----- > From: Thomas.Froment@alcatel.fr [mailto:Thomas.Froment@alcatel.fr]=20 > Sent: Wednesday, November 08, 2006 8:49 AM > To: Jeroen van Bemmel > Cc: GARCIN Sebastien RD-CORE-ISS; Michael Hammer (mhammer);=20 > Adam Roach; Jonathan Rosenberg (jdrosen); IETF Sipping List > Subject: Re: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 > About the usage of BFCP, chairs started a poll yesterday=20 > during the meeting, but decided to stop it after 5/10 people=20 > raised their hand to vote for "this is a good approach"... > Then, Rohan(I think) asked "who understand / is interested=20 > by the problem"?, and since few people were responding,=20 > nobody got the chance to vote for "this is NOT a good approach"... >=20 > So, maybe we can start a new poll on mailing list with=20 > *interested* people? >=20 > Jeroen van Bemmel wrote: >=20 > > That being said, I believe what is triggering the "academic"=20 > > objections is the underlying model of=20 > > draft-poetzl-sipping-call-completion-01: multiple=20 > subscriptions to a=20 > > single resource (the CCBS/CCNR queue) but a single=20 > notification to the=20 > > "first, non-suspended subscriber". That goes against > > RFC3265 (in more than one ways) > > =20 > Can you clatify this statement? for me, this is not=20 > completely clear why... >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 15:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuGL-0005Ha-Nr; Wed, 08 Nov 2006 15:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuGJ-0005Gy-Lo for sipping@ietf.org; Wed, 08 Nov 2006 15:43:07 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuGG-00083M-Mj for sipping@ietf.org; Wed, 08 Nov 2006 15:43:07 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id kA8Kh3d19185 for ; Wed, 8 Nov 2006 15:43:03 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006110815431106832 for ; Wed, 08 Nov 2006 15:43:11 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Nov 2006 15:43:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Nov 2006 15:43:05 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: fwd:I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt thread-index: AccDdnzmUbn87gMLSGKIfXMtBGD6Tg== From: "Haluska, John J" To: X-OriginalArrivalTime: 08 Nov 2006 20:43:11.0723 (UTC) FILETIME=[81832BB0:01C70376] X-Spam-Score: 0.5 (/) X-Scan-Signature: 2cf79100e158081ec662b95abd1ecd80 Subject: [Sipping] fwd:I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1798967390==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1798967390== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C70376.813DBF0A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70376.813DBF0A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C70376.813DBF0A" ------_=_NextPart_002_01C70376.813DBF0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 [Date Prev ][Date Next ][Thread Prev ][Thread Next ][Date Index ][Thread Index ]=20 I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt ________________________________ * To: i-d-announce at ietf.org * Subject: I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt=20 * From: Internet-Drafts at ietf.org =20 * Date: Tue, 07 Nov 2006 15:50:01 -0500 * Cc:=20 * List-archive: > * List-help: * List-id: i-d-announce.ietf.org * List-post: * List-subscribe: < https://www1.ietf.org/mailman/listinfo/i-d-announce>, < mailto:i-d-announce-request@ietf.org?subject=3Dsubscribe> * List-unsubscribe: < https://www1.ietf.org/mailman/listinfo/i-d-announce>, < mailto:i-d-announce-request@ietf.org?subject=3Dunsubscribe> * Reply-to: internet-drafts at ietf.org =20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =20 =20 Title : Considerations for Information Services and Operator Services Using SIP Author(s) : J. Haluska, et al. Filename : draft-haluska-sipping-directory-assistance-01.txt Pages : 49 Date : 2006-11-7 =20 Information Services are services whereby information is provided by=20 the network in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services=20 providers envision exciting multimedia services that support=20 simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced=20 services, while continuing to support traditional DA services. This=20 document aims to identify how such services can be implemented using=20 existing or currently proposed SIP mechanisms. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assi stance-01.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-haluska-sipping-directory-assistance-01.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-haluska-sipping-directory-assistance-01.txt". =20 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. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 * Prev by Date: I-D ACTION:draft-ietf-mpls-over-l2tpv3-02.txt =20 * Next by Date: I-D ACTION:draft-harrington-text-mib-doc-template-01.txt =20 * Previous by thread: I-D ACTION:draft-ietf-mpls-over-l2tpv3-02.txt =20 * Next by thread: I-D ACTION:draft-harrington-text-mib-doc-template-01.txt =20 * Index(es):=20 * Date =20 * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.=20 =20 ------_=_NextPart_002_01C70376.813DBF0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= /font>

<= /font>

<= /font>

<= /font>

<= /font>

<= /font>

<= /font>
size=3D2 width=3D"100%" align=3Dcenter>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt

size=3D2 = width=3D"100%" align=3Dcenter> 
A New Internet-Draft is available from the on-line Internet-Drafts =

directories.
 
 
        =
Title          : =
Considerations for Information Services and Operator Services Using =
SIP
        =
Author(s)      : J. Haluska, et =
al.
        =
Filename       : =
draft-haluska-sipping-directory-assistance-01.txt
        =
Pages          : =
49
        =
Date           : =
2006-11-7
        =

Information Services are services whereby =
information is provided by 
   the network in response to =
user requests, and may include involvement =

   of a human or automated =
agent. A popular existing Information Service =

   is Directory Assistance =
(DA). Moving ahead, Information Services =

   providers envision exciting =
multimedia services that support =

   simultaneous voice and data =
interactions with full operator backup at =

   any time during the call. =
Information Services providers are planning =

   to migrate to SIP based =
platforms, which will enable such advanced =

   services, while continuing =
to support traditional DA services. This =

   document aims to identify =
how such services can be implemented using =

   existing or currently =
proposed SIP mechanisms.
 
A URL for =
this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haluska-s=
ipping-directory-assistance-01.txt
 
To remove =
yourself from the I-D Announcement list, send a message to =

i-d-announce-request at 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-haluska-sipping-directory-assistance-01.txt".
 
A list of =
Internet-Drafts directories can be found =
in
http://www.ietf.org/shadow.html<=
/a> 
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
 
Internet-Drafts can also be obtained by =
e-mail.
 
Send a =
message to:
        =
mailserv at ietf.org.
In the =
body type:
        =
"FILE =
/internet-drafts/draft-haluska-sipping-directory-assistance-01.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.
=

<ftp://ftp.ietf.org/internet-drafts/draft-haluska= -sipping-directory-assistance-01.txt>

= 
______________________________________________=
_
I-D-Announce mailing =
list
I-D-Announce at =
ietf.org
https://www1=
.ietf.org/mailman/listinfo/i-d-announce




 =
size=3D2
width=3D"100%" align=3Dcenter>











Note:
Messages sent to this list are the opinions of the senders and do not =
imply
endorsement by the IETF. 



 
------_=_NextPart_002_01C70376.813DBF0A-- ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhOgAVAOb/AP///xAQECEhITk5OUJCQlpaWmNjY2tra3Nzc3t7e4SEhIyMjHtzc4R7e1JK SoR7c2NaUlpSSmtjWoyEa6WUWoR7Wq2cWqWUUr2lUta1OZSMa4yEY62cUqWUSsatSr2lQsatQt69 OefGOd69MefGMZSMY5yMQs61Qta9QsatOc61Oda9OcatMbWlSr2tSufOQufOOd7GMda9KZyUWqWc UpyUQnt7c3Nza2trY1paUoSEc4yMayEhAHuElHN7jHN7lDlCY2NrjDE5a4yMlISEjHNze2trc3t7 hGNja1paY4SElHt7jHNzhGtre2Njc1paa1JSY3t7lHNzjGtrhGNje1pac3NzlDk5SlJSa2trjGNj hFpaeykpOVJSczk5UkpKa0JCY1JSe0pKcykpQkJCazExUjk5YzExWjk5azExYxgYMTExaykpWhgY OSkpYxAQMVpSY4yEjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAOgAVAEAH/4BpgoOEhYaHiImKhmtrW0qQWm6TaEtKREoLmE1ImJlEUQkqHD9REyMTVhqoUT4Y KWduaVpDSlFijYuIa19LmEtIWGhpVUSYRwZfbmhHkERGUMO604ZuZM2YW2mTXZjGYpNpTEOYU2bh 1INoXVqQUcFraB8eTD4XGQ0/pxM/CRk0UT4dS2KJSBxvSKKlISOlFhMDXcSkm0ix4jRrVLYRctOl i6xBbsxQQfPRIiGJJbeh2WKsJZEjWKYo8QUqAYoQGqJ4i6JBBAgvKRcGHcRGDg8RL5ImhfHBxy8l UiiQ2KDTWA9/JqRcwhSlgowKOnUqsdIBhlKkIeQEAFeNGJaNQP8+rLAR0FeUDTIuaCXiK1MTbDqX DDnypNAZNE7IDKXoRkyRt4W2GFEGkkyTJ9JMplus8RBnzYiWCc4IUswCJR4JTRkypTPoxSELiqXC 0ZsnKBGyzDQ2JEgEoG0XudkyhLQgazT5QjLSiaalBCsunCrxQ8mPEqgspAAuiwpqzmrG2LDBYHwS L2YKGrt048kvTzqi+7gUZccKGismiJXCYTsc8uMhoEYbhnExAAMIIMhADjnMwwQkP1Cgwgwr5GRL Aidc4IRdxzxhRBNE9LAeNAXcYEOCCRwgAAFdtEUFEQdA5gYYILgwQwg6BBRFCSGUcEILVtj2UhLY bPUMZrIsI4U2AslYFBIO6l3yBARGQGKJEkcggYZM6ymBABZDfTYRckQkpBFHWBpAxiBmPHhANGKC JmechwQCADs= ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhKQAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA KQAVAEAFsSAkjmRpnmgKEQaDMGODJI7IOEkCubCIIzWVcEgsGo8iVpKQAAQVgAYAsQPAmgxAYTYL Ir/g8LHREH8JAccjYHBoH45BAAIgPBAAnWEeKDweBQEPKgQEIgaGCwEAAAM1eVUweBAOAowDg2aa m5ydnp6Fn0JojFYQeIwBC3SLAAalBxCKpQqjhisEeJkLVpBZkr2FBAOmKaG4DgEDCwrKdFS/pwAQ AnZxt18MZUU3ot7fIQA7 ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhCwAVAKL/AP///97e59bW5729zlJSe0pKezExYwAAACwAAAAACwAVAEADHmi63AGkyUnZ izXnS/n0Wigug1B0EIpJoJNO5TpWCQA7 ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image004.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.gif Content-Location: image004.gif R0lGODlhXAAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA XAAVAEAF/yAkjmRpnmiqrmxrNg30MA8Eiwui1A7TOAgApNdD2BoMBGOU3NFIwMTMAVuIGoiEQ/ac PWBYqSi5dJnPkCBgrSAtAmtAAQ0hEOj4vH7fOsAXAAEHEAYCIwUBQSIJAAQBW4p2InaMNRCAZQ0A VjIACJKMWxAKAIxLDAAMBIYiBUIPCAFzfLS1tre4ubpDZSI9u8BDmwZygA2MCRAMAQZByUGkVoyE AQ0PspoFDw4DqSMBAw4PrggGAQwOctsD596oqqXKzAgCDwq9KQJzBaxpcQawhPgbJUeRgTuE7iiA I8fbFQFrVpVD+GZNOH+BUtnp1mgGnHPBQoocSbKkyZMoU6/yUTSCpUo8fiAggyCoThwBQAIxmOYo YB2G3g7E6dYLkEVPjoSoCbTgnTKNQB+hIuAwH6JV/OoMGCF0mj8BCCMhpATAEqYxm0Q8KCUpiFlP 7jQihCDUQQABCCylSGcI4hZABpIAOOA1SANwMoVIqkMgnTZuVcGKIyfJ7oAFC8M1ggcvcJACBAww 1jOFdBYGqgKQSJCgaV0TPqD0koRuhJeXULKIgpIAwe4zVHALPxMCADs= ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image005.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.gif Content-Location: image005.gif R0lGODlhOwAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA OwAVAEAF/yAkjmRpnmiqpg7TII6TJM+4IAp551ADFA5YK8iDBGkMB0QBWzmfzkUAQC1Ar9jsEwEQ EQwiQIIgQCQQOLLZnAMgGAAGV8T1LUQPsbEAKGr/gIGCg4QjSQ8MNYUjCQALDwECDz4zAQwQDAFm lpiaDj8LcVw5ZBABAw4PfGNgTSlzEAQEYQgQB1R9IrdUPG5wcl0QjT0CVGqNAJKLy8zNzs/Q0dIQ vnHNXFMBBFQBSttUAzXfAOHfXMBTbhCh4G4IpwGKKLCytGSy9/kE2tQJv8PC4jjC4ybUAD8nANaj hmNgIwYKHFqrBoxOFwEEUvHhQkNdoBbyjCS6MmMBg1tKWglMuyLD1cpoIQAAOw== ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image006.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.gif Content-Location: image006.gif R0lGODlhTQAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA TQAVAEAF/yAkjmRpnmiqrizpME6CONADM7WCLOOj8yIfAhfUESEOROIBGCIgjQZjOJoqbI9HYqlC AFrgMMsLKCvE6LR6LfLSIApAAoALFEYCg70EIMhkDH1/SgBnSHJeEAQEIotzDyILdBAMBABvbJma m5ydnp8pMC+gXgUPDgMBgaZ6OHMJrRAJBAwGAzRztbeyAAsBtw8FTXMQeg0Pdg0Apqh0ckkqc8IA AlKTDwZlTSLTAAc1lgABDeBl40gCZZaExYztcAFlwrVlBqD3+Pn6+/z9/v+emiT65CVemQWBAsxI p67GAG13HDBchg4iHG0PZXwhYHDSAYx0CAgQ4A7Fo0hNJnF5G7FoJQlqi9bBbGkJCBMEiRY18gMA EgRJDD4aOHLCy4AFCgIICITjYwJ6C5zSY1AggINgAbBerfpAQAAFCx7i3OhukYNlp8QCaAA0RSIp KF74FCGXBFy7RCmRW/FACYNKAUREWTEKYJgkCTAZXkwiBAA7 ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image007.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image007.gif Content-Location: image007.gif R0lGODlhOQAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA OQAVAEAF+CAkjmRpnmiqmgzAlIRABEBBNoSztu/q/8CgcEgs8iAAAAJCMIgegcOIhwCIqtWpK8lV QhwAQnFMLpvP6LToSCKIRQLn2lUdJAIGaLSQZCRqCQIBDw1KMQ8pbCMEXQokVFYQfxADAAMCfQs1 BwE2mgucOmqjpKWmp6hpOA0lB24FCyWrK7NkiiJuInw9XwQNCgQHAAKsOMN/L4FhrAdODgSOKEcI CC+5uG8QkIjCyCLIcQwMmgkQVS4qt0xiDZWi2i6T5lvlEAYucSINCYgGNPUoHCB4J0JBAgQKCH4Z yGCJtiUPEBiANVCbAQL1EpR7kCBWqo8gf4QAADs= ------_=_NextPart_001_01C70376.813DBF0A Content-Type: image/gif; name="image008.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image008.gif Content-Location: image008.gif R0lGODlhJAAVAMT/AP////f39+fn797e587O3rW1xr29zqWlvZyctYyMrXt7nHNzlGNjjFpahEpK czk5azExYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA JAAVAEAFpiAkjmRpnmiJAGzQQAQLMJAiA8Kb7rzDOKQfb0gcrlgDIEFAIDgAh9MgUAAWr9isdrtN AEReGGE0EJAeCEZgiuCtHgLBQzxyBAQKRiJAQMgPX1yCg4SFhls+DDQiDYoMcxAOCQgKkFcrDAt3 YooPCwAGQAxTDw6URjMKazB8BA0ACSYMAD4KPF4GADpNIwYBlg0ENApxbl+zBXR1AzIGD3AssYfT hSEAOw== ------_=_NextPart_001_01C70376.813DBF0A-- --===============1798967390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1798967390==-- From sipping-bounces@ietf.org Wed Nov 08 16:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghusb-0004h1-Oo; Wed, 08 Nov 2006 16:22:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghusa-0004gw-Gy for sipping@ietf.org; Wed, 08 Nov 2006 16:22:40 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhusZ-00059l-19 for sipping@ietf.org; Wed, 08 Nov 2006 16:22:40 -0500 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id kA8LMbd28021 for ; Wed, 8 Nov 2006 16:22:37 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006110816224525434 for ; Wed, 08 Nov 2006 16:22:45 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Nov 2006 16:22:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Nov 2006 16:22:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt thread-index: AccDfAgkokWpgO+ATAGbOSWN1UpKDg== From: "Haluska, John J" To: X-OriginalArrivalTime: 08 Nov 2006 21:22:45.0488 (UTC) FILETIME=[0862F700:01C7037C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Subject: [Sipping] FW: I-D ACTION:draft-haluska-sipping-directory-assistance-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0586137597==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0586137597== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7037C.082E641B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7037C.082E641B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I forwarded this previously, but the html was scrubbed, so here is the = text only. A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Considerations for Information Services and Operator Services = Using SIP Author(s) : J. Haluska, et al. Filename : draft-haluska-sipping-directory-assistance-01.txt Pages : 49 Date : 2006-11-7 =09 Information Services are services whereby information is provided by=20 the network in response to user requests, and may include involvement = of a human or automated agent. A popular existing Information Service = is Directory Assistance (DA). Moving ahead, Information Services=20 providers envision exciting multimedia services that support=20 simultaneous voice and data interactions with full operator backup at = any time during the call. Information Services providers are planning = to migrate to SIP based platforms, which will enable such advanced=20 services, while continuing to support traditional DA services. This=20 document aims to identify how such services can be implemented using=20 existing or currently proposed SIP mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assis= tance-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body = of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-haluska-sipping-directory-assistance-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE = /internet-drafts/draft-haluska-sipping-directory-assistance-01.txt". =09 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_001_01C7037C.082E641B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D = ACTION:draft-haluska-sipping-directory-assistance-01.txt

I forwarded this previously, but  the html was = scrubbed, so here is the text only.


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title   =         : Considerations for = Information Services and Operator Services Using SIP
        = Author(s)       : J. Haluska, et al.
        = Filename        : = draft-haluska-sipping-directory-assistance-01.txt
        Pages   =         : 49
        Date    =         : 2006-11-7
       
Information Services are services whereby information is provided by
   the network in response to user requests, and may include = involvement
   of a human or automated agent. A popular existing = Information Service
   is Directory Assistance (DA). Moving ahead, Information = Services
   providers envision exciting multimedia services that = support
   simultaneous voice and data interactions with full operator = backup at
   any time during the call. Information Services providers = are planning
   to migrate to SIP based platforms, which will enable such = advanced
   services, while continuing to support traditional DA = services. This
   document aims to identify how such services can be = implemented using
   existing or currently proposed SIP mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haluska-s= ipping-directory-assistance-01.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at 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-haluska-sipping-directory-assistance-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv at ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-haluska-sipping-directory-assistance-01.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.

<ftp://ftp.ietf.org/internet-drafts/draft-haluska-sip= ping-directory-assistance-01.txt>

------_=_NextPart_001_01C7037C.082E641B-- --===============0586137597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0586137597==-- From sipping-bounces@ietf.org Wed Nov 08 16:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv8x-0001nd-5t; Wed, 08 Nov 2006 16:39:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv8w-0001nV-1G for sipping@ietf.org; Wed, 08 Nov 2006 16:39:34 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghv8q-0000j5-Mo for sipping@ietf.org; Wed, 08 Nov 2006 16:39:32 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J8F00B7NLHKP3@siemenscomms.co.uk> for sipping@ietf.org; Wed, 08 Nov 2006 21:39:20 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG0G8Q>; Wed, 08 Nov 2006 21:39:09 +0000 Content-return: allowed Date: Wed, 08 Nov 2006 21:39:07 +0000 From: "Elwell, John" Subject: RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 To: Thomas.Froment@alcatel.fr, Jeroen van Bemmel Message-id: <50B1CBA96870A34799A506B2313F26670A5023AE@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Adam Roach , IETF Sipping List , "Michael Hammer \(mhammer\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org As I stated at the mic yesterday and also in an earlier email, I do not think the BFCP approach is a sensible way of solving the call completion problem. Setting aside alternative solutions that might be more appropriate in a pure SIP environment, if the main driver is to provide a solution that can interwork with PSTN CCBS/CCNR, we should try to satisfy this requirement in the simplest way possible. IMO, BFCP is not the simplest approach and introduces unwanted complexity, particularly at a gateway. I think the Poetzle draft is a far better starting point, especially if we could try to align it better with the principles of RFC 3265, for example following some of the suggestions of Jeroen. John > -----Original Message----- > From: Thomas.Froment@alcatel.fr [mailto:Thomas.Froment@alcatel.fr] > Sent: 08 November 2006 13:49 > To: Jeroen van Bemmel > Cc: IETF Sipping List; Adam Roach; Michael Hammer (mhammer) > Subject: Re: [Sipping] comments on > draft-roach-sipping-callcomp-bfcp-00 > > About the usage of BFCP, chairs started a poll yesterday during the > meeting, but decided to stop it after 5/10 people raised > their hand to > vote for "this is a good approach"... > Then, Rohan(I think) asked "who understand / is interested by the > problem"?, and since few people were responding, nobody got > the chance > to vote for "this is NOT a good approach"... > > So, maybe we can start a new poll on mailing list with > *interested* people? > > Jeroen van Bemmel wrote: > > > That being said, I believe what is triggering the > "academic" objections is the underlying model of > draft-poetzl-sipping-call-completion-01: multiple > subscriptions to a single resource (the CCBS/CCNR queue) but > a single notification to the "first, non-suspended > subscriber". That goes against > > RFC3265 (in more than one ways) > > > Can you clatify this statement? for me, this is not > completely clear why... > > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 17:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvkU-0002KG-GJ; Wed, 08 Nov 2006 17:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvkS-0002KA-Bs for sipping@ietf.org; Wed, 08 Nov 2006 17:18:20 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvkR-0000Q6-1i for sipping@ietf.org; Wed, 08 Nov 2006 17:18:20 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA8MHAw20152; Wed, 8 Nov 2006 17:17:10 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Date: Wed, 8 Nov 2006 16:16:54 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DEC2517@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A5023AE@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00 Thread-Index: AccDf0fHMWYJU2RRQQ6A0kHfuWP0gAAAvTSQ From: "Francois Audet" To: "Elwell, John" , , "Jeroen van Bemmel" X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF Sipping List , Adam Roach , "Michael Hammer \(mhammer\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Embedded below.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Wednesday, November 08, 2006 13:39 > To: Thomas.Froment@alcatel.fr; Jeroen van Bemmel > Cc: Adam Roach; IETF Sipping List; Michael Hammer (mhammer) > Subject: RE: [Sipping] comments on=20 > draft-roach-sipping-callcomp-bfcp-00 >=20 > As I stated at the mic yesterday and also in an earlier=20 > email, I do not think the BFCP approach is a sensible way of=20 > solving the call completion problem. As I also said at the mike, I agree 100% with John. Using=20 a separate protocol like BFCP for CCBS+CCNR does not seem to be a sensible way of solving this problem. > Setting aside alternative solutions that might be more=20 > appropriate in a pure SIP environment, if the main driver is=20 > to provide a solution that can interwork with PSTN CCBS/CCNR,=20 > we should try to satisfy this requirement in the simplest way=20 > possible. IMO, BFCP is not the simplest approach and=20 > introduces unwanted complexity, particularly at a gateway. I=20 > think the Poetzle draft is a far better starting point,=20 > especially if we could try to align it better with the=20 > principles of RFC 3265, for example following some of the=20 > suggestions of Jeroen. I completely agree again.=20 I would also like to start with a native SIP approach based on something like the Poetzle draft. If we want to start with a really simple approach we can also look at section 2.17 of=20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples- 11.txt as a starting point. But yes, if a plain dialog-package approach is not sufficient, then=20 defining a package like in http://tools.ietf.org/wg/sipping/draft-poetzl-sipping-call-completion-01 .txt seems much more appealing than using BFCP. _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 17:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw7q-000749-Jb; Wed, 08 Nov 2006 17:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw7p-000741-62 for sipping@ietf.org; Wed, 08 Nov 2006 17:42:29 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghw7n-0005Qe-OG for sipping@ietf.org; Wed, 08 Nov 2006 17:42:29 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA8MgKCo015434; Wed, 8 Nov 2006 15:42:22 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Wed, 8 Nov 2006 15:42:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Thread-Index: AccDUlAgQ2uV64mZSYiP1ab6r1f0DAAMCPGw From: "Jean-Francois Mule" To: "Volker Hilt" , "Cullen Jennings" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Volker wrote: > I think that stability of overload control is an important requirement. > We certainly want to avoid building something that starts to oscillate > once it reaches overload state.=20 Oscillations are often unavoidable in overload conditions, it's the characterization of these oscillations (amplitude, duration, frequency, ...) that may lead to instability. Cullen wrote: > >>> A possible additional requirement.... > >>> Imagine a system (perhaps a single proxy) that could do 100cps. It > >>> is in steady state doing 80cps with very few retransmission. Then > >>> for 5 minutes the incoming requests goes to 500cps then drops > back > >>> to an incoming call rate of 80cps. The question is, how long > before > >>> the system gets back to the state where it if is successfully > >>> processing all the 80cps? Volker added: > It may be somehow implicit to REQ 1 > since an unstable system will hardly be able to maintain the overall > useful throughput at a high level. Following in Cullen's example, I interpret requirement #1 to mean: out of the 500 cps, the system under load should pick up the *useful* transactions to keep the using applications happy. May be a way to help formulate Cullen's example is to introduce some wording or requirements around oscillations or the characteristics of the overload, and say something around the recovery time like: the overload control mechanism should help predict the time a system will take to recover based on the characterization of the overload? Jean-Francois. > -----Original Message----- > From: Volker Hilt [mailto:volkerh@bell-labs.com] > Sent: Wednesday, November 08, 2006 9:18 AM > To: Cullen Jennings > Cc: sipping > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs > recovery >=20 > I think that stability of overload control is an important requirement. > We certainly want to avoid building something that starts to oscillate > once it reaches overload state. It may be somehow implicit to REQ 1 > since an unstable system will hardly be able to maintain the overall > useful throughput at a high level. >=20 > Volker >=20 >=20 >=20 > Cullen Jennings wrote: > > Clearly this was a long way from the text for a requirement but, yes, > I > > was proposing that this be added as one of the requirements. I don't > > feel strongly about this and if we can't figure out how to express > this > > as a requirement that is useful, I can certainly live with not > adding it. > > > > The reason I think it is a requirement is I can easily imagine that > the > > mechanism for doing overload push-back causes the systems to fail in > the > > way I described below (i.e. never recover back to steady state). > > > > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > > > >> > >> > >> Cullen Jennings wrote: > >> > >>> A possible additional requirement.... > >>> Imagine a system (perhaps a single proxy) that could do 100cps. It > >>> is in steady state doing 80cps with very few retransmission. Then > >>> for 5 minutes the incoming requests goes to 500cps then drops > back > >>> to an incoming call rate of 80cps. The question is, how long > before > >>> the system gets back to the state where it if is successfully > >>> processing all the 80cps? > >> > >> As soon as it can. Are you suggesting a requirement here? Seems > like > >> this is an implementation thing and wouldn't impact any protocol > >> mechanisms. > >> > >>> I have seen systems that never recover - that is bad. I think one > of > >>> the design goals is that it is at least possible to build to > systems > >>> that recover back to steady state relatively quickly after an > >>> overload impulse. > >> > >> Sure; but I'm not sure I see the protocol requirement. > >> > >> -Jonathan R. > >> > >> > >> > >> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: (973) 952- > 5050 > >> http://www.jdrosen.net PHONE: (973) 952- > 5000 > >> http://www.cisco.com > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 17:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwJ3-0002AM-3e; Wed, 08 Nov 2006 17:54:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwJ0-0001xh-4L for sipping@ietf.org; Wed, 08 Nov 2006 17:54:02 -0500 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhwIx-0007VU-Lu for sipping@ietf.org; Wed, 08 Nov 2006 17:54:02 -0500 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id kA8MrocX028043 for ; Wed, 8 Nov 2006 17:53:55 -0500 (EST) In-Reply-To: Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery To: "Jean-Francois Mule" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 8 Nov 2006 17:53:47 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 11/08/2006 05:52:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Cullen Jennings , Volker Hilt , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think it is ineveitable that the overload control system WILL oscillate. The thing is to make sure it is STABLE oscillation, not UNSTABLE. Janet "Jean-Francois Mule" wrote on 11/08/2006 05:42:20 PM: > > Volker wrote: > > I think that stability of overload control is an important > requirement. > > We certainly want to avoid building something that starts to oscillate > > once it reaches overload state. > > Oscillations are often unavoidable in overload conditions, it's the > characterization of these oscillations (amplitude, duration, frequency, > ...) that may lead to instability. > > > Cullen wrote: > > >>> A possible additional requirement.... > > >>> Imagine a system (perhaps a single proxy) that could do 100cps. It > > >>> is in steady state doing 80cps with very few retransmission. Then > > >>> for 5 minutes the incoming requests goes to 500cps then drops > > back > > >>> to an incoming call rate of 80cps. The question is, how long > > before > > >>> the system gets back to the state where it if is successfully > > >>> processing all the 80cps? > > Volker added: > > It may be somehow implicit to REQ 1 > > since an unstable system will hardly be able to maintain the overall > > useful throughput at a high level. > > Following in Cullen's example, I interpret requirement #1 to mean: out > of the 500 cps, the system under load should pick up the *useful* > transactions to keep the using applications happy. > > May be a way to help formulate Cullen's example is to introduce some > wording or requirements around oscillations or the characteristics of > the overload, and say something around the recovery time like: > the overload control mechanism should help predict the time a system > will take to recover based on the characterization of the overload? > > Jean-Francois. > > > -----Original Message----- > > From: Volker Hilt [mailto:volkerh@bell-labs.com] > > Sent: Wednesday, November 08, 2006 9:18 AM > > To: Cullen Jennings > > Cc: sipping > > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs > > recovery > > > > I think that stability of overload control is an important > requirement. > > We certainly want to avoid building something that starts to oscillate > > once it reaches overload state. It may be somehow implicit to REQ 1 > > since an unstable system will hardly be able to maintain the overall > > useful throughput at a high level. > > > > Volker > > > > > > > > Cullen Jennings wrote: > > > Clearly this was a long way from the text for a requirement but, > yes, > > I > > > was proposing that this be added as one of the requirements. I don't > > > feel strongly about this and if we can't figure out how to express > > this > > > as a requirement that is useful, I can certainly live with not > > adding it. > > > > > > The reason I think it is a requirement is I can easily imagine that > > the > > > mechanism for doing overload push-back causes the systems to fail in > > the > > > way I described below (i.e. never recover back to steady state). > > > > > > > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > > > > > >> > > >> > > >> Cullen Jennings wrote: > > >> > > >>> A possible additional requirement.... > > >>> Imagine a system (perhaps a single proxy) that could do 100cps. It > > >>> is in steady state doing 80cps with very few retransmission. Then > > >>> for 5 minutes the incoming requests goes to 500cps then drops > > back > > >>> to an incoming call rate of 80cps. The question is, how long > > before > > >>> the system gets back to the state where it if is successfully > > >>> processing all the 80cps? > > >> > > >> As soon as it can. Are you suggesting a requirement here? Seems > > like > > >> this is an implementation thing and wouldn't impact any protocol > > >> mechanisms. > > >> > > >>> I have seen systems that never recover - that is bad. I think one > > of > > >>> the design goals is that it is at least possible to build to > > systems > > >>> that recover back to steady state relatively quickly after an > > >>> overload impulse. > > >> > > >> Sure; but I'm not sure I see the protocol requirement. > > >> > > >> -Jonathan R. > > >> > > >> > > >> > > >> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >> Cisco Fellow Parsippany, NJ > > 07054-2711 > > >> Cisco Systems > > >> jdrosen@cisco.com FAX: (973) 952- > > 5050 > > >> http://www.jdrosen.net PHONE: (973) 952- > > 5000 > > >> http://www.cisco.com > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 18:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwdO-0005oC-Ui; Wed, 08 Nov 2006 18:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwdM-0005aD-S6 for sipping@ietf.org; Wed, 08 Nov 2006 18:15:04 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhwdL-0002qz-Dr for sipping@ietf.org; Wed, 08 Nov 2006 18:15:04 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2006 18:15:03 -0500 X-IronPort-AV: i="4.09,401,1157342400"; d="scan'208"; a="109174019:sNHT62377080" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8NF3CH019496; Wed, 8 Nov 2006 18:15:03 -0500 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 kA8NF3DM012182; Wed, 8 Nov 2006 18:15:03 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 18:15:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Wed, 8 Nov 2006 18:15:00 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DADC9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Thread-Index: AccDUlAgQ2uV64mZSYiP1ab6r1f0DAAMCPGwAAJHsKA= From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , "Volker Hilt" , "Cullen Jennings \(fluffy\)" X-OriginalArrivalTime: 08 Nov 2006 23:15:02.0866 (UTC) FILETIME=[B82D4320:01C7038B] DKIM-Signature: a=rsa-sha1; q=dns; l=6055; t=1163027703; x=1163891703; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20Re=3A=20draft-rosenberg-sipping-overload-reqs=20reco very |To:=22Jean-Francois=20Mule=22=20, =0A=20=20=20=20=20= 20=20=20=22Volker=20Hilt=22=20, =0A=20=20=20=20=20=20 =20=20=22Cullen=20Jennings=20\(fluffy\)=22=20; X=v=3Dcisco.com=3B=20h=3Dc/tyx/3xJgsZiNZXdPN2zHnNVok=3D; b=GrjMCuU6owTZUF5PHgTDAl2oFYoJq+EhTJCky7RqdLQ1yh+jtVIpUVWwILz1TlOjNdwntXt5 ImAoFgfy+lbwl0Hv9X8OMOYSALzWn8/Q/mCHgD+rPxulF4mYZC9ULilZ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org So the requirement is to get damped versus undamped oscillations. Mike=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Wednesday, November 08, 2006 5:42 PM > To: Volker Hilt; Cullen Jennings (fluffy) > Cc: sipping > Subject: RE: [Sipping] Re:=20 > draft-rosenberg-sipping-overload-reqs recovery >=20 >=20 > Volker wrote: > > I think that stability of overload control is an important > requirement. > > We certainly want to avoid building something that starts=20 > to oscillate=20 > > once it reaches overload state. >=20 > Oscillations are often unavoidable in overload conditions,=20 > it's the characterization of these oscillations (amplitude,=20 > duration, frequency, > ...) that may lead to instability. >=20 >=20 > Cullen wrote: > > >>> A possible additional requirement.... > > >>> Imagine a system (perhaps a single proxy) that could do=20 > 100cps. It=20 > > >>> is in steady state doing 80cps with very few=20 > retransmission. Then=20 > > >>> for 5 minutes the incoming requests goes to 500cps then drops > > back > > >>> to an incoming call rate of 80cps. The question is, how long > > before > > >>> the system gets back to the state where it if is successfully=20 > > >>> processing all the 80cps? >=20 > Volker added: > > It may be somehow implicit to REQ 1 > > since an unstable system will hardly be able to maintain=20 > the overall=20 > > useful throughput at a high level. >=20 > Following in Cullen's example, I interpret requirement #1 to=20 > mean: out of the 500 cps, the system under load should pick=20 > up the *useful* transactions to keep the using applications happy. >=20 > May be a way to help formulate Cullen's example is to=20 > introduce some wording or requirements around oscillations or=20 > the characteristics of the overload, and say something around=20 > the recovery time like: > the overload control mechanism should help predict the time a=20 > system will take to recover based on the characterization of=20 > the overload? >=20 > Jean-Francois. >=20 > > -----Original Message----- > > From: Volker Hilt [mailto:volkerh@bell-labs.com] > > Sent: Wednesday, November 08, 2006 9:18 AM > > To: Cullen Jennings > > Cc: sipping > > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs > > recovery > >=20 > > I think that stability of overload control is an important > requirement. > > We certainly want to avoid building something that starts=20 > to oscillate=20 > > once it reaches overload state. It may be somehow implicit to REQ 1=20 > > since an unstable system will hardly be able to maintain=20 > the overall=20 > > useful throughput at a high level. > >=20 > > Volker > >=20 > >=20 > >=20 > > Cullen Jennings wrote: > > > Clearly this was a long way from the text for a requirement but, > yes, > > I > > > was proposing that this be added as one of the=20 > requirements. I don't=20 > > > feel strongly about this and if we can't figure out how to express > > this > > > as a requirement that is useful, I can certainly live with not > > adding it. > > > > > > The reason I think it is a requirement is I can easily=20 > imagine that > > the > > > mechanism for doing overload push-back causes the systems=20 > to fail in > > the > > > way I described below (i.e. never recover back to steady state). > > > > > > > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > > > > > >> > > >> > > >> Cullen Jennings wrote: > > >> > > >>> A possible additional requirement.... > > >>> Imagine a system (perhaps a single proxy) that could do=20 > 100cps. It=20 > > >>> is in steady state doing 80cps with very few=20 > retransmission. Then=20 > > >>> for 5 minutes the incoming requests goes to 500cps then drops > > back > > >>> to an incoming call rate of 80cps. The question is, how long > > before > > >>> the system gets back to the state where it if is successfully=20 > > >>> processing all the 80cps? > > >> > > >> As soon as it can. Are you suggesting a requirement here? Seems > > like > > >> this is an implementation thing and wouldn't impact any protocol=20 > > >> mechanisms. > > >> > > >>> I have seen systems that never recover - that is bad. I=20 > think one > > of > > >>> the design goals is that it is at least possible to build to > > systems > > >>> that recover back to steady state relatively quickly after an=20 > > >>> overload impulse. > > >> > > >> Sure; but I'm not sure I see the protocol requirement. > > >> > > >> -Jonathan R. > > >> > > >> > > >> > > >> --Jonathan D. Rosenberg, Ph.D. 600=20 > Lanidex Plaza > > >> Cisco Fellow Parsippany, NJ > > 07054-2711 > > >> Cisco Systems > > >> jdrosen@cisco.com FAX: (973) 952- > > 5050 > > >> http://www.jdrosen.net PHONE: (973) 952- > > 5000 > > >> http://www.cisco.com > > > > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 18:16:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghwee-0007ck-FN; Wed, 08 Nov 2006 18:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghwed-0007ce-5H for sipping@ietf.org; Wed, 08 Nov 2006 18:16:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhweZ-00034E-T7 for sipping@ietf.org; Wed, 08 Nov 2006 18:16:22 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2006 15:16:19 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="340940029:sNHT71945226" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8NGJni030790; Wed, 8 Nov 2006 15:16:19 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA8NGIOV009775; Wed, 8 Nov 2006 15:16:18 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 18:16:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Wed, 8 Nov 2006 18:16:16 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3022DADCA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Thread-Index: AccDiT2o9nE+DSowQ2mIROMKQ0QdrAAApUmg From: "Michael Hammer \(mhammer\)" To: "Janet P Gunn" , "Jean-Francois Mule" X-OriginalArrivalTime: 08 Nov 2006 23:16:18.0489 (UTC) FILETIME=[E5406A90:01C7038B] DKIM-Signature: a=rsa-sha1; q=dns; l=6931; t=1163027779; x=1163891779; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sipping]=20Re=3A=20draft-rosenberg-sipping-overload-reqs=20reco very; X=v=3Dcisco.com=3B=20h=3Dc/tyx/3xJgsZiNZXdPN2zHnNVok=3D; b=IiXzLgThehlrgT2CBjcAEtzhaEZNgvygVqwu+FOLXO/Wnam0kNaD8a5XlbczQc9HoUsJO8l/ sTsb7uqkO0g/OzU2E8cJcD5Wi45LDFDDbQTsZNNy0foZOgRBmz/HMDrg; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: "Cullen Jennings \(fluffy\)" , Volker Hilt , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I would prefer to damp them than to keep the oscillation going, i.e. stable. Mike=20 > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com]=20 > Sent: Wednesday, November 08, 2006 5:54 PM > To: Jean-Francois Mule > Cc: Cullen Jennings (fluffy); Volker Hilt; sipping > Subject: RE: [Sipping] Re:=20 > draft-rosenberg-sipping-overload-reqs recovery >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > I think it is ineveitable that the overload control system=20 > WILL oscillate. > The thing is to make sure it is STABLE oscillation, not UNSTABLE. >=20 > Janet >=20 > "Jean-Francois Mule" wrote on=20 > 11/08/2006 05:42:20 > PM: >=20 > > > > Volker wrote: > > > I think that stability of overload control is an important > > requirement. > > > We certainly want to avoid building something that starts to=20 > > > oscillate once it reaches overload state. > > > > Oscillations are often unavoidable in overload conditions, it's the=20 > > characterization of these oscillations (amplitude, duration,=20 > > frequency, > > ...) that may lead to instability. > > > > > > Cullen wrote: > > > >>> A possible additional requirement.... > > > >>> Imagine a system (perhaps a single proxy) that could=20 > do 100cps.=20 > > > >>> It is in steady state doing 80cps with very few=20 > retransmission.=20 > > > >>> Then for 5 minutes the incoming requests goes to 500cps then=20 > > > >>> drops > > > back > > > >>> to an incoming call rate of 80cps. The question is, how long > > > before > > > >>> the system gets back to the state where it if is=20 > successfully=20 > > > >>> processing all the 80cps? > > > > Volker added: > > > It may be somehow implicit to REQ 1 > > > since an unstable system will hardly be able to maintain=20 > the overall=20 > > > useful throughput at a high level. > > > > Following in Cullen's example, I interpret requirement #1=20 > to mean: out=20 > > of the 500 cps, the system under load should pick up the *useful*=20 > > transactions to keep the using applications happy. > > > > May be a way to help formulate Cullen's example is to=20 > introduce some=20 > > wording or requirements around oscillations or the=20 > characteristics of=20 > > the overload, and say something around the recovery time like: > > the overload control mechanism should help predict the time=20 > a system=20 > > will take to recover based on the characterization of the overload? > > > > Jean-Francois. > > > > > -----Original Message----- > > > From: Volker Hilt [mailto:volkerh@bell-labs.com] > > > Sent: Wednesday, November 08, 2006 9:18 AM > > > To: Cullen Jennings > > > Cc: sipping > > > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs > > > recovery > > > > > > I think that stability of overload control is an important > > requirement. > > > We certainly want to avoid building something that starts to=20 > > > oscillate once it reaches overload state. It may be=20 > somehow implicit=20 > > > to REQ 1 since an unstable system will hardly be able to maintain=20 > > > the overall useful throughput at a high level. > > > > > > Volker > > > > > > > > > > > > Cullen Jennings wrote: > > > > Clearly this was a long way from the text for a requirement but, > > yes, > > > I > > > > was proposing that this be added as one of the requirements. I=20 > > > > don't feel strongly about this and if we can't figure=20 > out how to=20 > > > > express > > > this > > > > as a requirement that is useful, I can certainly live with not > > > adding it. > > > > > > > > The reason I think it is a requirement is I can easily imagine=20 > > > > that > > > the > > > > mechanism for doing overload push-back causes the=20 > systems to fail=20 > > > > in > > > the > > > > way I described below (i.e. never recover back to steady state). > > > > > > > > > > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > > > > > > > >> > > > >> > > > >> Cullen Jennings wrote: > > > >> > > > >>> A possible additional requirement.... > > > >>> Imagine a system (perhaps a single proxy) that could=20 > do 100cps.=20 > > > >>> It is in steady state doing 80cps with very few=20 > retransmission.=20 > > > >>> Then for 5 minutes the incoming requests goes to 500cps then=20 > > > >>> drops > > > back > > > >>> to an incoming call rate of 80cps. The question is, how long > > > before > > > >>> the system gets back to the state where it if is=20 > successfully=20 > > > >>> processing all the 80cps? > > > >> > > > >> As soon as it can. Are you suggesting a requirement here? Seems > > > like > > > >> this is an implementation thing and wouldn't impact=20 > any protocol=20 > > > >> mechanisms. > > > >> > > > >>> I have seen systems that never recover - that is bad. I think=20 > > > >>> one > > > of > > > >>> the design goals is that it is at least possible to build to > > > systems > > > >>> that recover back to steady state relatively quickly after an=20 > > > >>> overload impulse. > > > >> > > > >> Sure; but I'm not sure I see the protocol requirement. > > > >> > > > >> -Jonathan R. > > > >> > > > >> > > > >> > > > >> --Jonathan D. Rosenberg, Ph.D. 600=20 > Lanidex Plaza > > > >> Cisco Fellow Parsippany, NJ > > > 07054-2711 > > > >> Cisco Systems > > > >> jdrosen@cisco.com FAX: =20 > (973) 952- > > > 5050 > > > >> http://www.jdrosen.net PHONE:=20 > (973) 952- > > > 5000 > > > >> http://www.cisco.com > > > > > > > > _______________________________________________ > > > > Sipping mailing list =20 > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 08 18:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhwhA-0001rj-Ix; Wed, 08 Nov 2006 18:19:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghwh7-0001rd-VW for sipping@ietf.org; Wed, 08 Nov 2006 18:18:57 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghwh5-0003dz-MS for sipping@ietf.org; Wed, 08 Nov 2006 18:18:57 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA8NIsKB028666 for ; Wed, 8 Nov 2006 16:18:55 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Re: draft-rosenberg-sipping-overload-reqs Date: Wed, 8 Nov 2006 16:18:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs Thread-Index: AccDUlAgQ2uV64mZSYiP1ab6r1f0DAAMCPGwAAGK3+A= From: "Jean-Francois Mule" To: "sipping" X-Approved: ondar X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org It would good if the overload control mechanism could be designed with reporting in mind. That is, after the system has recovered from overload, there is a common set of things that can be reported to express the overload condition to a sysadmin: "system x got blasted and turned the overload control mode ON at : x requests/responses received in z secs causing cpus to jump to ... and y transactions to be NACKed; recovered to normal mode at " I have not thought much about this and it may be orthogonal to the mechanism that deals with overload but it'd be good if the mechanism could help provide some useful feedback to users or operators to address the root causes with a more precise view of the pb and oscillation. Should there be a requirement that the overload mechanism should help characterize the overload with a well known set of variables?=20 Jean-Francois. _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 00:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2Iq-0003yx-Gh; Thu, 09 Nov 2006 00:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2Il-0003is-8U for sipping@ietf.org; Thu, 09 Nov 2006 00:18:11 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2AW-0006cq-JW for sipping@ietf.org; Thu, 09 Nov 2006 00:09:42 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Nov 2006 21:09:29 -0800 From: "Darshan Bildikar" To: Date: Thu, 9 Nov 2006 10:39:26 +0530 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AccDUlAgQ2uV64mZSYiP1ab6r1f0DAAMCPGwAAGK3+AADFtOoA== Message-ID: X-OriginalArrivalTime: 09 Nov 2006 05:09:30.0077 (UTC) FILETIME=[3C6C20D0:01C703BD] X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sipping] Some questions and comments on draft-rosenberg-sipping-overload-reqs X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hello Jonathan, I have some questions/comments on your overload control draft. 1) Section 4.1 - "How, a single request from the client, before timing out, could generate as many as 18 requests and as many responses!" You're probably going for "However" there? Also, I would appreciate if you could clarify how the number of requests/responses could go up to 18. 2) In figure 3, why the assumption that both proxies would try the same set of servers? If P1 and P2 are being used purely for load balancing purposes then what is the likelihood that they would route requests to the same set of servers? 3) REQ 7 states, "The mechanism shall provide a way for an element to throttle the amount of traffic it receives from an upstream element. This throttling shall be graded, so that it is not all or nothing as with the current 503 mechanism. This recognizes the fact that "overload" is not a binary state, and there are degrees of overload." Reading this line I draw the conclusion that the actual throttling (load balancing) is done by the element or rather the up stream element (proxy). Wouldn't it be better rephrased-- "The mechanism shall provide a way for an element to indicate current load parameters to an upstream element such that traffic to the element can be suitably throttled. This throttling shall be graded, so that it is not all or nothing as with the current 503 mechanism. This recognizes the fact that "overload" is not a binary state, and there are degrees of overload." 4) REQ 18 states, "The overload mechanism should be unambiguous about whether a load indication applies to a specific IP address, host, or URI, so that an upstream element can determine the load of the entity to which a request is to be sent" REQ 19 talks about specific SIP method types that might be desirable to process in time of overload. There is also need for throttling based on service type. For example, a server might host Prepaid and CRBT services and might wish to indicate loads separately to proxies based on service type i.e. I cant handle prepaid calls right now but I can handle CRBT. I would however assume that each service would be invoked through a different URI. But is this a safe assumption to make? Also, throttling based on media would be useful. For example, a server might wish to indicate that it cannot handle VIDEO and can only handle AUDIO for a while. The examples above are not an exhaustive list. What I am trying to say is that we need a more EXHAUSTIVE list of parameters based on which over load control can be more "fine grained". Best regards, Darshan _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 02:21:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4C7-0006ia-RU; Thu, 09 Nov 2006 02:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4C6-0006iV-Db for sipping@ietf.org; Thu, 09 Nov 2006 02:19:26 -0500 Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi4C4-0003bO-W7 for sipping@ietf.org; Thu, 09 Nov 2006 02:19:26 -0500 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 0228426000B; Thu, 9 Nov 2006 08:19:24 +0100 (CET) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14602-10; Thu, 9 Nov 2006 08:19:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 157AF26000A; Thu, 9 Nov 2006 08:19:19 +0100 (CET) From: Nils Ohlmeier To: sipping@ietf.org, hasebe.miki@east.ntt.co.jp, j.koshiko@east.ntt.co.jp, suzuki.yasushi@east.ntt.co.jp, tomoyuki.yoshikawa@east.ntt.co.jp, pkyzivat@cisco.com Date: Thu, 9 Nov 2006 07:35:39 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611090735.39901.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Sipping] Comments on draft-hasebe-sipping-race-examples-02 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hello, please find my comments below from reviewing draft-hasebe-sipping-race-examples-02.txt: page 5, 1st diagram: Their are arrows missing in the lines for 2xx: | | +-------------+--+ should be | | +------------>+<-+ page 6, 1st paragraph: "The dialog which is to be terminated by BYE in Early state." What does this sentense mean? page 6, 1st diagram: The same applies for the diagram above: | | +-------------+--+ should be | | +------------>+<-+ Section 2 The whole sections contains several references to subsections 2.x which do not exist. Probably they should refer to subsections 3.x. Page 10, 1st paragraph: (UAs that do not deal with this bug still need to recognize the retransmission relying on its From-tag and Call-ID, even though it does not match the transaction.) I think the UAS should recognize the request as a retransmission by the CSeq. The From-tag and Call-ID should lead to the same dialog even if the To-tag is missing. Page 11, 1st call flow: I think their is no RTP flowing, at least not from Alice to Bob. As it is described in the text below on page 12 Alice sends the BYE immediately after sending out the ACK for the 200 (INVITE). I would assume that their is no microphone turned on any more on Alice's UA which could record audio for any RTP. Thus I would recommend to reduce the RTP stream to a one way from Bob to Alice. Page 12, 1st paragraph: I would add here once again that this way of terminating an early dialog is not recommended (like it was pointed out earlier already in the draft). Page 48, 3rd paragraph: Their is a small typo in the first line: 'transactiuon' should be 'transaction'. Page 48, 4th paragraph: '... BYE with an appropriate certificate' their is no certificate involved in digest authentication. I think the word 'certificate' should be replaced with 'authentication header' or with 'credentials'. Regards Nils Ohlmeier _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 06:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi8Xr-00066X-3t; Thu, 09 Nov 2006 06:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi8Xq-00066Q-DD for sipping@ietf.org; Thu, 09 Nov 2006 06:58:10 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi8Xp-0000s3-4l for sipping@ietf.org; Thu, 09 Nov 2006 06:58:10 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Nov 2006 03:58:04 -0800 From: "Darshan Bildikar" To: "'sipping'" Date: Thu, 9 Nov 2006 17:27:50 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Acb/uM3mM5AdkO6LQeKctUV3ql7okgBrr+qQAKL5+CA= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA8F@zrc2hxm2.corp.nortel.com> Message-ID: X-OriginalArrivalTime: 09 Nov 2006 11:58:04.0578 (UTC) FILETIME=[50342020:01C703F6] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sipping] A comment on draft-stucker-sipping-early-media-coping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Section 4.1 "Any SDP answers in provisional responses are stripped before being forwarded upstream. The SDP answer may be added into a 200 response upstream from last provisional SDP answer received if SDP is not already present in the message to ensure that the offer/answer exchange is completed. This effectively turns off early media" I am not sure whether such an approach would turn off early media. 3264 clearly says that the terminating UA can start sending RTP immediately after the receipt of the offer. Hence even if you don't send the answer SDP to the upstream entity there is a good chance media will still be rendered even if SDP is stripped away. (In fact, we have actually faced this problem). The solution is to INVITE the callee always with a HOLD / NO SDP and renegotiate always after answer. _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 10:28:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBnV-0007od-SU; Thu, 09 Nov 2006 10:26:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBnU-0007k6-OO for sipping@ietf.org; Thu, 09 Nov 2006 10:26:32 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiBnQ-0006Ei-Bp for sipping@ietf.org; Thu, 09 Nov 2006 10:26:30 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kA9FQDvR009174 for ; Thu, 9 Nov 2006 09:26:13 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 09:26:13 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 16:26:12 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 9 Nov 2006 16:26:11 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180775570@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed revised layout for draft-ietf-sipping-config-framework Thread-Index: AccDph1WdbxPpJLjTAOyr1t+jOrpAg== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 09 Nov 2006 15:26:12.0122 (UTC) FILETIME=[635C1FA0:01C70413] X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Subject: [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org During the breakout session on the config framework we decided that the existing material in this document was essentially covering the right material and scope, but that a new structure was needed and then a rewrite of the text that goes into those sections.=20 There is a hope that during this rewrite, much duplicate material will be removed and the document will become shorter as well as the main goal of making the document more understandable. To follow normal RFC drafting rules To follow guidelines for SIP extensions (RFC 4485) To follow requirements for defining Event packages (RFC 3265) Comments are welcome, this is a strawman. ------------------------------------------------------------------------ ------------- Abstract 1 Introduction 2 Terminology 3 Overview Much of the information in the existing section 4 seems to be appropriate to be=20 here.=20 =09 Suggest also that the definition of different profile types is moved here from=20 the event package definition. That then leaves the way forward for the event=20 package to assign parameters to the different profile types. 3.1 Profile Life Cycle 3.2 Reference model This will say that the document describes this in terms of UA acting as Device,=20 and of a Profile Delivery Server, which consists of two parts: * Profile Notification Server * Profile Content Indirection Server Indicate that the Profile Content Indirection Server is optional to implement 3.3 Profile types and data model Include here section 6 and stuff from the event package that is not event=20 package specific. Leave only the coding in the event package. 4 Use cases Text from section 5 of the document. 5 Processing Rules Place in this section the content indirection requirements. Need to clearly distinguish all requirements for profile content server and=20 profile delivery server. 5.1 Device Behaviour 5.1.1 Profile delivery server discovery 5.1.2 Forming URIs for subscription Needs to include content from 7.13 5.1.1.1 Device URIs 5.1.1.2 User URIs 5.1.1.3 Local Network URIs 5.1.3 Enrollment with Profile Server 5.1.4 Notification of Profile Changes 5.1.5 Retrieval of Profile Data split to cover from both profile notification server and profile content=20 indirection server. 5.1.5 Upload of Profile Changes only from profile content indirection server 5.2 Profile Notification Server Behaviour 5.2.1 Enrollment with Profile Server 5.2.2 Notification of Profile Changes 5.2.3 Retrieval of Profile Data 5.3 Profile Content Indirection Server Behaviour 5.3.1 Retrieval of Profile Data 5.3.2 Upload of Profile Changes 6 Event Package Definition The sub-breakdown here comes from RFC 3265 however the idea of RFC=20 3265 is not to slavishly follow, but to make sure all the information is=20 contained. Therefore it is proposed that the examples are moved out of this=20 level to a later point in the document. Remove all text relating to content indirection from the existing event package=20 definition except for the passing of the URI. The idea is that this defines the package, but material relating to the use of=20 the package goes elsewhere.=09 6.1 Event Package Name 6.2 Event Package Parameters Move out the profile type introduction to the overview. 6.3 SUBSCRIBE Bodies 6.4 Subscription Duration 6.5 NOTIFY Bodies 6.6 Notifier Processing of SUBSCRIBE Requests 6.7 Notifier Generation of SUBSCRIBE Requests 6.8 Subscriber Processing of NOTIFY Requests 6.9 Handling of Forked Requests 6.10 Rate of Notifications 6.11 State Agents 7 Instructions for Data Set Authors Substantially new. Data set authors need to register a mime type for their data set. 8 Examples See section 7.12 of existing document. 9 IANA Considerations 9.1 SIP Event Package 9.2 New HTTP Event Header 10 Security Considerations Much of the procedural text in here actually needs to go back into the main=20 text ? where there are already some requirements. The text here should then=20 refer to that text rather than repeat it. 11 References 11.1 Normative References 11.2 Informative References ------------------------------------------------------------------------ ---------- Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 12:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDcQ-00062d-Ui; Thu, 09 Nov 2006 12:23:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDcP-0005xv-GQ for sipping@ietf.org; Thu, 09 Nov 2006 12:23:13 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDcM-0001r8-7J for sipping@ietf.org; Thu, 09 Nov 2006 12:23:13 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.255,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_BADTAG_00_10: 0.001,HTML_MESSAGE: 0.001, SARE_RECV_ADDR: 0.027,SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Thu, 9 Nov 2006 17:21:33 +0000 From: "Siddhartha Bhakta" To: Date: Thu, 9 Nov 2006 17:21:26 -0000 Message-ID: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccEI3xzBcz0dffgRnijwX7I/2CJ6g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: 'Siddhartha Bhakta' Subject: [Sipping] Query related to draft-ietf-sipping-service-examples-11 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1246519983==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1246519983== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01C70423.7F36C210" This is a multi-part message in MIME format. ------=_NextPart_000_00FD_01C70423.7F36C210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Alan/Robert/Kevin, I could find out following problem in sec 2.9 as far as SIP dialog is concerned. The F5(180) is creating an early dialog between Alice and Proxy(from-tag=1234567, to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10) and 180(F13) with a different to-tag. The F10 (181) contains to-tag=9214d and to-tag=765432 Is it not the violation of RFC3261 dialog concept? I am not sure how the Alice SIP entity shall manage the SIP dialog. Definitely, F10 and F13 shall not be associated to the dialog created by F5. Alice might discard F10 (181) as that is containing different to-tags. The out of dialog 1xx should be discarded. Similar problem is there in sec 2.12. The F5 and F18 contains different to-tags. In sec 2.7, the F3 and F6 have different to-tags. In sec 2.8, F6 and F9 have different to-tags. Early response is anticipated. Thanks, Siddhartha --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_00FD_01C70423.7F36C210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Dear =
Alan/Robert/Kevin,
 
I could find out following =
problem in sec 2.9 as far
as SIP dialog is concerned. The =
F5(180) is creating an
early dialog between Alice and =
Proxy(from-tag=3D1234567, =
to-tag=3D3145678).
Whereas, later on, Proxy is =
sending back 181(F10) and 180(F13) with =
a
different to-tag. The F10 (181) =
contains to-tag=3D9214d and =
to-tag=3D765432
 
Is it not the violation of =
RFC3261 dialog concept?
I am not sure how the Alice SIP =
entity shall manage the SIP dialog. Definitely, F10 and F13 shall not be =
associated to the dialog created by =
F5.
Alice might =
discard F10 (181) as that is containing different to-tags. The out of =
dialog 1xx should be discarded.
 
Similar problem is there in sec =
2.12. The F5 and F18 contains different =
to-tags.
In sec 2.7, the F3 and F6 have =
different to-tags.
In sec 2.8, F6 and F9 have =
different to-tags.
 
Early response is =
anticipated.
 
Thanks,


Siddhartha


---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_00FD_01C70423.7F36C210-- --===============1246519983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1246519983==-- From sipping-bounces@ietf.org Thu Nov 09 13:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEN7-0007b6-PV; Thu, 09 Nov 2006 13:11:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEN6-0007b1-O1 for sipping@ietf.org; Thu, 09 Nov 2006 13:11:28 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEN5-0008N7-F2 for sipping@ietf.org; Thu, 09 Nov 2006 13:11:28 -0500 Received: from [130.129.68.74] (dhcp68-74.ietf67.org [130.129.68.74]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA9HEv7o031378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 11:14:58 -0600 In-Reply-To: <454F7E9F.3030403@cisco.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F7E9F.3030403@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 12:11:12 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Paul Kyzivat , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: > I think it would be far better to define a URN namespace for > ringtones and use local configuration to map those to specific > files. What you are proposing will only work in the most closed and > homogeneous environments. > Absolutely. I think this is a GREAT idea. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 13:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiENO-0007fl-Od; Thu, 09 Nov 2006 13:11:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiENN-0007ff-It for sipping@ietf.org; Thu, 09 Nov 2006 13:11:45 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiENM-0008PP-3T for sipping@ietf.org; Thu, 09 Nov 2006 13:11:45 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 10:02:37 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863471913:sNHT12031141464" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I2ajY019028; Thu, 9 Nov 2006 10:02:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I2ain002195; Thu, 9 Nov 2006 10:02:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:02:36 -0800 Received: from [10.21.90.224] ([10.21.90.224]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:02:36 -0800 Message-ID: <45536D3B.1030806@cisco.com> Date: Thu, 09 Nov 2006 13:02:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> In-Reply-To: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2006 18:02:36.0142 (UTC) FILETIME=[3CABF0E0:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=1855; t=1163095356; x=1163959356; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:; X=v=3Dcisco.com=3B=20h=3DNWT45m5bMQsOSPHD5y5ooIO/q7M=3D; b=kcOkNPPRMHBc0gnvXUqD5gHOUOCHGeKdYTJAXYx1naTVruaswx5/aGQaI23xRpBKeEfBdCuc EvlXq2Z0jaqnft5BkmfTBb1TDF/4xEGMtkD3gktB9voxoM9zmcOfX9LN; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sipping@ietf.org, 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > Dear Alan/Robert/Kevin, > > I could find out following problem in sec 2.9 as far > as SIP dialog is concerned. The F5(180) is creating an > early dialog between Alice and Proxy(from-tag=1234567, to-tag=3145678). > Whereas, later on, Proxy is sending back 181(F10) and 180(F13) with a > different to-tag. The F10 (181) contains to-tag=9214d and to-tag=765432 > > Is it not the violation of RFC3261 dialog concept? No. This is normal behavior in the presence of forking. Each distinct to-tag results in a new early dialog. > I am not sure how the Alice SIP entity shall manage the SIP dialog. > Definitely, F10 and F13 shall not be associated to the dialog created by F5. > Alice might discard F10 (181) as that is containing different to-tags. Alice must recognize that she is receiving responses for two dialogs, and must be prepared for either of them to receive a 200. Discarding the responses for the 2nd dialog is incorrect. Normally you will receive a final response for one of the early dialogs, or possibly for yet another dialog that hasn't previously been seen. If that is >=300, they you should consider all of your dialogs terminated. If you get a 2xx response, then you know one dialog that succeeded. Usually all the others will be canceled by the proxy. But it is possible that there is another 2xx on the way for another dialog. If so then you must deal with that some way. Most commonly people send a BYE to any subsequent 2xxs they receive. Paul > The out of dialog 1xx should be discarded. > > Similar problem is there in sec 2.12. The F5 and F18 contains different to-tags. > In sec 2.7, the F3 and F6 have different to-tags. > In sec 2.8, F6 and F9 have different to-tags. > > Early response is anticipated. > > Thanks, > > Siddhartha _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 13:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEw7-00040O-KS; Thu, 09 Nov 2006 13:47:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEw6-00040B-QK for sipping@ietf.org; Thu, 09 Nov 2006 13:47:38 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEw4-0004y6-IK for sipping@ietf.org; Thu, 09 Nov 2006 13:47:38 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id kA9IlYff007721; Thu, 9 Nov 2006 12:47:34 -0600 (CST) Received: from [135.244.36.146] (volkerh.lra.lucent.com [135.244.36.146]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kA9IlUx25476; Thu, 9 Nov 2006 13:47:33 -0500 (EST) Message-ID: <455377BF.8040305@bell-labs.com> Date: Thu, 09 Nov 2006 10:47:27 -0800 From: Volker Hilt User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jean-Francois Mule wrote: > It would good if the overload control mechanism could be designed with > reporting in mind. That is, after the system has recovered from > overload, there is a common set of things that can be reported to > express the overload condition to a sysadmin: > "system x got blasted and turned the overload control mode ON at > : x requests/responses received in z secs causing cpus to > jump to ... and y transactions to be NACKed; recovered to normal mode at > " > > I have not thought much about this and it may be orthogonal to the > mechanism that deals with overload but it'd be good if the mechanism > could help provide some useful feedback to users or operators to address > the root causes with a more precise view of the pb and oscillation. > Yes, I think that reporting overload information to a sysadmin is orthogonal to the actual overload control mechanism. Both the overloaded entity and the upstream entity that receives an overload indication will have some information about the overload situation (e.g. when it occurred, which server was affected etc.). I'm not sure what else these entities would need (in particular what they would need from each other). > Should there be a requirement that the overload mechanism should help > characterize the overload with a well known set of variables? > I think a question is who should report what and how much information is needed about the entity on the other end of overload control. Volker _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 13:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiF6O-0003d2-QX; Thu, 09 Nov 2006 13:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiF6L-0003cv-Sk for sipping@ietf.org; Thu, 09 Nov 2006 13:58:13 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiF6L-0006Hj-1H for sipping@ietf.org; Thu, 09 Nov 2006 13:58:13 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id CDF10200A9; Thu, 9 Nov 2006 13:58:12 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31547-01; Thu, 9 Nov 2006 13:58:12 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 1D743200AF; Thu, 9 Nov 2006 13:58:12 -0500 (EST) To: "Drage, Keith \(Keith\)" Subject: Re: [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 9 Nov 2006 13:58:10 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/09/2006 01:58:10 PM, Serialize complete at 11/09/2006 01:58:10 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1206993131==" Errors-To: sipping-bounces@ietf.org This is a multipart message in MIME format. --===============1206993131== Content-Type: multipart/alternative; boundary="=_alternative 0068345A85257221_=" This is a multipart message in MIME format. --=_alternative 0068345A85257221_= Content-Type: text/plain; charset="us-ascii" Hi Keith, all, Thanks for doing this. As a first pass, I do like the overall structure proposed. Seems to break down the complexity in a nice rational flow of bite-sized pieces. Not clear to me the restructuring would necessarily reduce overall size of the doc. Even though there would be some redundancy removed (hopefully), since the structuring itself costs words too. Important part is getting it to be easy to understand and implement correctly. As long as necessary, but no longer. I have a few detailed tweaks suggested, and a couple of questions: o Sec 3, suggest *brief* subsection "Scope and Requirements Overview" (or some such) to clearly define what the spec does and does not address, esp that it does not cover actual data formats and related. This might help focus and remove debates that do not belong in this doc. Maybe this would be 1st sub-sec of Overview, or a stand-alone section. o Sec 3.1 Profile Life Cycle Unclear what is intended by this. What would content be here. o Sec 3.1 Reference model. Modulo answers to above, I'd bet this should really be the first technical content subsec. Reference model typically helps frame everything else. Definitely needs a pretty picture to show relation of the various elements. o Message flow diagrams, showing general flow from high level, would be very helpful, preferably fairly early in the doc. Not sure where this would go, but probably close to Reference Model, or maybe even part of it. (Sec 8 Examples should contain examples in grueling detail.) When we met on Tuesday, I think there was general head-nodding that this would be helpful. o Sec 5.1.1.1 - 5.1.1.3 Forming X URI, suggest these should be ordered in same sequence as they are actually used, ie Local Network, then Device, then User. There may be other places where this general principal could be applied as well. -- Peter Blatherwick "Drage, Keith \(Keith\)" 09.11.06 10:26 To: cc: Subject: [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework During the breakout session on the config framework we decided that the existing material in this document was essentially covering the right material and scope, but that a new structure was needed and then a rewrite of the text that goes into those sections. There is a hope that during this rewrite, much duplicate material will be removed and the document will become shorter as well as the main goal of making the document more understandable. To follow normal RFC drafting rules To follow guidelines for SIP extensions (RFC 4485) To follow requirements for defining Event packages (RFC 3265) Comments are welcome, this is a strawman. ------------------------------------------------------------------------ ------------- Abstract 1 Introduction 2 Terminology 3 Overview Much of the information in the existing section 4 seems to be appropriate to be here. Suggest also that the definition of different profile types is moved here from the event package definition. That then leaves the way forward for the event package to assign parameters to the different profile types. 3.1 Profile Life Cycle 3.2 Reference model This will say that the document describes this in terms of UA acting as Device, and of a Profile Delivery Server, which consists of two parts: * Profile Notification Server * Profile Content Indirection Server Indicate that the Profile Content Indirection Server is optional to implement 3.3 Profile types and data model Include here section 6 and stuff from the event package that is not event package specific. Leave only the coding in the event package. 4 Use cases Text from section 5 of the document. 5 Processing Rules Place in this section the content indirection requirements. Need to clearly distinguish all requirements for profile content server and profile delivery server. 5.1 Device Behaviour 5.1.1 Profile delivery server discovery 5.1.2 Forming URIs for subscription Needs to include content from 7.13 5.1.1.1 Device URIs 5.1.1.2 User URIs 5.1.1.3 Local Network URIs 5.1.3 Enrollment with Profile Server 5.1.4 Notification of Profile Changes 5.1.5 Retrieval of Profile Data split to cover from both profile notification server and profile content indirection server. 5.1.5 Upload of Profile Changes only from profile content indirection server 5.2 Profile Notification Server Behaviour 5.2.1 Enrollment with Profile Server 5.2.2 Notification of Profile Changes 5.2.3 Retrieval of Profile Data 5.3 Profile Content Indirection Server Behaviour 5.3.1 Retrieval of Profile Data 5.3.2 Upload of Profile Changes 6 Event Package Definition The sub-breakdown here comes from RFC 3265 however the idea of RFC 3265 is not to slavishly follow, but to make sure all the information is contained. Therefore it is proposed that the examples are moved out of this level to a later point in the document. Remove all text relating to content indirection from the existing event package definition except for the passing of the URI. The idea is that this defines the package, but material relating to the use of the package goes elsewhere. 6.1 Event Package Name 6.2 Event Package Parameters Move out the profile type introduction to the overview. 6.3 SUBSCRIBE Bodies 6.4 Subscription Duration 6.5 NOTIFY Bodies 6.6 Notifier Processing of SUBSCRIBE Requests 6.7 Notifier Generation of SUBSCRIBE Requests 6.8 Subscriber Processing of NOTIFY Requests 6.9 Handling of Forked Requests 6.10 Rate of Notifications 6.11 State Agents 7 Instructions for Data Set Authors Substantially new. Data set authors need to register a mime type for their data set. 8 Examples See section 7.12 of existing document. 9 IANA Considerations 9.1 SIP Event Package 9.2 New HTTP Event Header 10 Security Considerations Much of the procedural text in here actually needs to go back into the main text ? where there are already some requirements. The text here should then refer to that text rather than repeat it. 11 References 11.1 Normative References 11.2 Informative References ------------------------------------------------------------------------ ---------- Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ 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 --=_alternative 0068345A85257221_= Content-Type: text/html; charset="us-ascii"
Hi Keith, all,  

Thanks for doing this.  As a first pass, I do like the overall structure proposed.  Seems to break down the complexity in a nice rational flow of bite-sized pieces.  

Not clear to me the restructuring would necessarily reduce overall size of the doc.  Even though there would be some redundancy removed (hopefully), since the structuring itself costs words too.  Important part is getting it to be easy to understand and implement correctly.  As long as necessary, but no longer.  

I have a few detailed tweaks suggested, and a couple of questions:

o Sec 3, suggest *brief* subsection "Scope and Requirements Overview" (or some such) to clearly define what the spec does and does not address, esp that it does not cover actual data formats and related.  This might help focus and remove debates that do not belong in this doc.  Maybe this would be 1st sub-sec of Overview, or a stand-alone section.  

o Sec 3.1 Profile Life Cycle  Unclear what is intended by this.  What would content be here.  

o Sec 3.1 Reference model.  Modulo answers to above, I'd bet this should really be the first technical content subsec.  Reference model typically helps frame everything else.  Definitely needs a pretty picture to show relation of the various elements.  

o Message flow diagrams, showing general flow from high level, would be very helpful, preferably fairly early in the doc.  Not sure where this would go, but probably close to Reference Model, or maybe even part of it.   (Sec 8 Examples should contain examples in grueling detail.)  When we met on Tuesday, I think there was general head-nodding that this would be helpful.  

o Sec 5.1.1.1 - 5.1.1.3  Forming X URI, suggest these should be ordered in same sequence as they are actually used, ie Local Network, then Device, then User.  There may be other places where this general principal could be applied as well.  

-- Peter Blatherwick



"Drage, Keith \(Keith\)" <drage@lucent.com>

09.11.06 10:26

       
        To:        <sipping@ietf.org>
        cc:        
        Subject:        [Sipping] Proposed revised layout for        draft-ietf-sipping-config-framework



During the breakout session on the config framework we decided that the
existing material in this document was essentially covering the right
material and scope, but that a new structure was needed and then a
rewrite of the text that goes into those sections.

There is a hope that during this rewrite, much duplicate material will
be removed and the document will become shorter as well as the main goal
of making the document more understandable.

To follow normal RFC drafting rules
To follow guidelines for SIP extensions (RFC 4485)
To follow requirements for defining Event packages (RFC 3265)

Comments are welcome, this is a strawman.

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

Abstract

1                 Introduction

2                 Terminology

3                 Overview

                Much of the information in the existing section 4 seems to be
appropriate to be
                here.
               
                Suggest also that the definition of different profile types is
moved here from
                the event package definition. That then leaves the way forward
for the event
                package to assign parameters to the different profile types.

3.1                 Profile Life Cycle

3.2                 Reference model

                This will say that the document describes this in terms of UA
acting as Device,
                and of a Profile Delivery Server, which consists of two parts:
                *                 Profile Notification Server
                *                 Profile Content Indirection Server
                Indicate that the Profile Content Indirection Server is optional
to implement

3.3                 Profile types and data model

                Include here section 6 and stuff from the event package that is
not event
                package specific. Leave only the coding in the event package.

4                 Use cases

Text from section 5 of the document.

5                 Processing Rules

                Place in this section the content indirection requirements.

                Need to clearly distinguish all requirements for profile content
server and
                profile delivery server.

5.1                 Device Behaviour

5.1.1                 Profile delivery server discovery

5.1.2                 Forming URIs for subscription

                Needs to include content from 7.13

5.1.1.1                 Device URIs
5.1.1.2                 User URIs
5.1.1.3                 Local Network URIs

5.1.3                 Enrollment with Profile Server
5.1.4                 Notification of Profile Changes
5.1.5                 Retrieval of Profile Data

                split to cover from both profile notification server and profile
content
                indirection server.

5.1.5                 Upload of Profile Changes

                only from profile content indirection server

5.2                 Profile Notification Server Behaviour

5.2.1                 Enrollment with Profile Server

5.2.2                 Notification of Profile Changes

5.2.3                 Retrieval of Profile Data

5.3                 Profile Content Indirection Server Behaviour

5.3.1                 Retrieval of Profile Data

5.3.2                 Upload of Profile Changes

6                 Event Package Definition

                The sub-breakdown here comes from RFC 3265 however the idea of
RFC
                3265 is not to slavishly follow, but to make sure all the
information is
                contained. Therefore it is proposed that the examples are moved
out of this
                level to a later point in the document.
                Remove all text relating to content indirection from the
existing event package
                definition except for the passing of the URI.

                The idea is that this defines the package, but material relating
to the use of
                the package goes elsewhere.                

6.1                 Event Package Name

6.2                 Event Package Parameters

                Move out the profile type introduction to the overview.

6.3                 SUBSCRIBE Bodies

6.4                 Subscription Duration

6.5                 NOTIFY Bodies

6.6                 Notifier Processing of SUBSCRIBE Requests

6.7                 Notifier Generation of SUBSCRIBE Requests

6.8                 Subscriber Processing of NOTIFY Requests

6.9                 Handling of Forked Requests

6.10                 Rate of Notifications

6.11                 State Agents

7                 Instructions for Data Set Authors

                Substantially new.

                Data set authors need to register a mime type for their data
set.

8                 Examples

                See section 7.12 of existing document.

9                 IANA Considerations

9.1                 SIP Event Package

9.2                 New HTTP Event Header

10                 Security Considerations

                Much of the procedural text in here actually needs to go back
into the main
                text ? where there are already some requirements. The text here
should then
                refer to that text rather than repeat it.

11                 References

11.1                 Normative References

11.2                 Informative References

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

Regards

Keith

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

_______________________________________________
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

--=_alternative 0068345A85257221_=-- --===============1206993131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1206993131==-- From sipping-bounces@ietf.org Thu Nov 09 14:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFEo-0000MZ-7j; Thu, 09 Nov 2006 14:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFEn-0000K4-Ai for sipping@ietf.org; Thu, 09 Nov 2006 14:06:57 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFEl-0007iH-Sj for sipping@ietf.org; Thu, 09 Nov 2006 14:06:57 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kA9J6sQB007802 for ; Thu, 9 Nov 2006 12:06:55 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Proposed revised layout fordraft-ietf-sipping-config-framework Date: Thu, 9 Nov 2006 12:06:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Proposed revised layout fordraft-ietf-sipping-config-framework Thread-Index: AccDph1WdbxPpJLjTAOyr1t+jOrpAgAirGxw From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Keith, Thanks for putting this together. On a quick skim, I think I agree with most of it (and it seems to flow well), but a few observations/comments follow: - Do we need an explicit split indicating 'Profile Notification Server' and 'Profile Content Indirection Server'? A logical differentiation may help, but the functionality would be implemented by the same entity (were you hinting at a logical separation or different entities)? - Unsure if we need a new section for data sets (Section 7) as they are not within the scope of this document. So, can we handle this as part of the data set document? If we feel that we need to have this here, it would be new work (as you have indicated)=20 Thoughts? - S =20 =20 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Thursday, November 09, 2006 7:26 AM To: sipping@ietf.org Subject: [Sipping] Proposed revised layout fordraft-ietf-sipping-config-framework During the breakout session on the config framework we decided that the existing material in this document was essentially covering the right material and scope, but that a new structure was needed and then a rewrite of the text that goes into those sections.=20 There is a hope that during this rewrite, much duplicate material will be removed and the document will become shorter as well as the main goal of making the document more understandable. To follow normal RFC drafting rules To follow guidelines for SIP extensions (RFC 4485) To follow requirements for defining Event packages (RFC 3265) Comments are welcome, this is a strawman. ------------------------------------------------------------------------ ------------- Abstract 1 Introduction 2 Terminology 3 Overview Much of the information in the existing section 4 seems to be appropriate to be=20 here.=20 =09 Suggest also that the definition of different profile types is moved here from=20 the event package definition. That then leaves the way forward for the event=20 package to assign parameters to the different profile types. 3.1 Profile Life Cycle 3.2 Reference model This will say that the document describes this in terms of UA acting as Device,=20 and of a Profile Delivery Server, which consists of two parts: * Profile Notification Server * Profile Content Indirection Server Indicate that the Profile Content Indirection Server is optional to implement 3.3 Profile types and data model Include here section 6 and stuff from the event package that is not event=20 package specific. Leave only the coding in the event package. 4 Use cases Text from section 5 of the document. 5 Processing Rules Place in this section the content indirection requirements. Need to clearly distinguish all requirements for profile content server and=20 profile delivery server. 5.1 Device Behaviour 5.1.1 Profile delivery server discovery 5.1.2 Forming URIs for subscription Needs to include content from 7.13 5.1.1.1 Device URIs 5.1.1.2 User URIs 5.1.1.3 Local Network URIs 5.1.3 Enrollment with Profile Server 5.1.4 Notification of Profile Changes 5.1.5 Retrieval of Profile Data split to cover from both profile notification server and profile content=20 indirection server. 5.1.5 Upload of Profile Changes only from profile content indirection server 5.2 Profile Notification Server Behaviour 5.2.1 Enrollment with Profile Server 5.2.2 Notification of Profile Changes 5.2.3 Retrieval of Profile Data 5.3 Profile Content Indirection Server Behaviour 5.3.1 Retrieval of Profile Data 5.3.2 Upload of Profile Changes 6 Event Package Definition The sub-breakdown here comes from RFC 3265 however the idea of RFC=20 3265 is not to slavishly follow, but to make sure all the information is=20 contained. Therefore it is proposed that the examples are moved out of this=20 level to a later point in the document. Remove all text relating to content indirection from the existing event package=20 definition except for the passing of the URI. The idea is that this defines the package, but material relating to the use of=20 the package goes elsewhere.=09 6.1 Event Package Name 6.2 Event Package Parameters Move out the profile type introduction to the overview. 6.3 SUBSCRIBE Bodies 6.4 Subscription Duration 6.5 NOTIFY Bodies 6.6 Notifier Processing of SUBSCRIBE Requests 6.7 Notifier Generation of SUBSCRIBE Requests 6.8 Subscriber Processing of NOTIFY Requests 6.9 Handling of Forked Requests 6.10 Rate of Notifications 6.11 State Agents 7 Instructions for Data Set Authors Substantially new. Data set authors need to register a mime type for their data set. 8 Examples See section 7.12 of existing document. 9 IANA Considerations 9.1 SIP Event Package 9.2 New HTTP Event Header 10 Security Considerations Much of the procedural text in here actually needs to go back into the main=20 text ? where there are already some requirements. The text here should then=20 refer to that text rather than repeat it. 11 References 11.1 Normative References 11.2 Informative References ------------------------------------------------------------------------ ---------- Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 14:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFbV-0000h1-Uj; Thu, 09 Nov 2006 14:30:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFbV-0000gw-3M for sipping@ietf.org; Thu, 09 Nov 2006 14:30:25 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFbT-0003J4-Ql for sipping@ietf.org; Thu, 09 Nov 2006 14:30:25 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA9JTp600908; Thu, 9 Nov 2006 14:29:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 13:29:46 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: AccEKnyOtdSW0UxWSCmi3N+I7vwIvwACsmzQ From: "Brian Stucker" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Cullen Jennings , Paul Kyzivat , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I would also agree. I wasn't proposing anything earlier, just stating an observed behavior (ala SIPit reports). I can make a recommendation in the early media draft though around this area. Regards, Brian=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, November 09, 2006 10:11 AM > To: Jonathan Rosenberg > Cc: Stucker, Brian (RICH1:AR00); Cullen Jennings; Paul=20 > Kyzivat; sipping > Subject: Re: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 >=20 > On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: >=20 > > I think it would be far better to define a URN namespace=20 > for ringtones=20 > > and use local configuration to map those to specific files.=20 > What you=20 > > are proposing will only work in the most closed and homogeneous=20 > > environments. > > >=20 > Absolutely. I think this is a GREAT idea. >=20 > -- > Dean >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 14:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFdm-00023m-1H; Thu, 09 Nov 2006 14:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFdk-00023f-5z for sipping@ietf.org; Thu, 09 Nov 2006 14:32:44 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFdh-0003k4-Qv for sipping@ietf.org; Thu, 09 Nov 2006 14:32:44 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA9JWN601516; Thu, 9 Nov 2006 14:32:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] A comment on draft-stucker-sipping-early-media-coping Date: Thu, 9 Nov 2006 13:32:08 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371116250D8@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] A comment on draft-stucker-sipping-early-media-coping Thread-Index: Acb/uM3mM5AdkO6LQeKctUV3ql7okgBrr+qQAKL5+CAAEICp0A== From: "Brian Stucker" To: "Darshan Bildikar" , "sipping" X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org True, that's another problem though. Some devices won't render early media without an SDP answer though (they simply ignore everything until they get something on the signaling path). I don't think you want to pull the HOLD on INVITE trick though, because it aggravates the general clipping problem. Regards, Brian =20 > -----Original Message----- > From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 > Sent: Thursday, November 09, 2006 3:58 AM > To: 'sipping' > Subject: [Sipping] A comment on=20 > draft-stucker-sipping-early-media-coping >=20 > Section 4.1=20 >=20 > "Any SDP answers in provisional responses are stripped before=20 > being forwarded upstream. The SDP answer may be added into a=20 > 200 response upstream from last provisional SDP answer=20 > received if SDP is not already present in the message to=20 > ensure that the offer/answer exchange is completed. This=20 > effectively turns off early media" >=20 > I am not sure whether such an approach would turn off early=20 > media. 3264 clearly says that the terminating UA can start=20 > sending RTP immediately after the receipt of the offer. Hence=20 > even if you don't send the answer SDP to the upstream entity=20 > there is a good chance media will still be rendered even if=20 > SDP is stripped away. (In fact, we have actually faced this=20 > problem). The solution is to INVITE the callee always with a=20 > HOLD / NO SDP and renegotiate always after answer.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 16:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHFd-0004Hn-7n; Thu, 09 Nov 2006 16:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHFb-0004HD-7a for sipping@ietf.org; Thu, 09 Nov 2006 16:15:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHFZ-00043e-IP for sipping@ietf.org; Thu, 09 Nov 2006 16:15:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 13:15:53 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9LFqOP028550; Thu, 9 Nov 2006 16:15:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9LFqDM010370; Thu, 9 Nov 2006 16:15:52 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 16:15:52 -0500 Received: from [10.86.240.251] ([10.86.240.251]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 16:15:51 -0500 Message-ID: <45539A86.6030306@cisco.com> Date: Thu, 09 Nov 2006 16:15:50 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework References: <5D1A7985295922448D5550C94DE29180775570@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180775570@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2006 21:15:51.0589 (UTC) FILETIME=[3C18BD50:01C70444] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5782; t=1163106952; x=1163970952; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joshl@cisco.com; z=From:=20Josh=20Littlefield=20 |Subject:=20Re=3A=20[Sipping]=20Proposed=20revised=20layout=20for=09draft -ietf-sipping-config-framework |Sender:=20 |To:=20=22Drage,=20Keith=20\(Keith\)=22=20; bh=+yh6MLviaxwODCQ1paFWpYwKNQuzHqPJ+J52K24zn9k=; b=Hb5aEpf23Bc2V04/dEu5HIuP2eVZF+g68RnkA4gD/aq4/zfZT7Fr5W/9c6OtoYpzMoE1jKLp +ncD9ycM2MTCqXpa0+Fyimsgoha6hBrglj0mi1EhMs+CME0DKSKu0GeS; Authentication-Results: rtp-dkim-2; header.From=joshl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I like the overall structure. I am unclear on "Profile Life Cycle". While the "instructions to data set authors" seems appropriate at first glance, I would think this section should be very short to avoid getting into data set issues that are out of scope, and keeping the mechanism dataset independent. -josh Drage, Keith (Keith) wrote: > During the breakout session on the config framework we decided that the > existing material in this document was essentially covering the right > material and scope, but that a new structure was needed and then a > rewrite of the text that goes into those sections. > > There is a hope that during this rewrite, much duplicate material will > be removed and the document will become shorter as well as the main goal > of making the document more understandable. > > To follow normal RFC drafting rules > To follow guidelines for SIP extensions (RFC 4485) > To follow requirements for defining Event packages (RFC 3265) > > Comments are welcome, this is a strawman. > > ------------------------------------------------------------------------ > ------------- > > Abstract > > 1 Introduction > > 2 Terminology > > 3 Overview > > Much of the information in the existing section 4 seems to be > appropriate to be > here. > > Suggest also that the definition of different profile types is > moved here from > the event package definition. That then leaves the way forward > for the event > package to assign parameters to the different profile types. > > 3.1 Profile Life Cycle > > 3.2 Reference model > > This will say that the document describes this in terms of UA > acting as Device, > and of a Profile Delivery Server, which consists of two parts: > * Profile Notification Server > * Profile Content Indirection Server > Indicate that the Profile Content Indirection Server is optional > to implement > > 3.3 Profile types and data model > > Include here section 6 and stuff from the event package that is > not event > package specific. Leave only the coding in the event package. > > 4 Use cases > > Text from section 5 of the document. > > 5 Processing Rules > > Place in this section the content indirection requirements. > > Need to clearly distinguish all requirements for profile content > server and > profile delivery server. > > 5.1 Device Behaviour > > 5.1.1 Profile delivery server discovery > > 5.1.2 Forming URIs for subscription > > Needs to include content from 7.13 > > 5.1.1.1 Device URIs > 5.1.1.2 User URIs > 5.1.1.3 Local Network URIs > > 5.1.3 Enrollment with Profile Server > 5.1.4 Notification of Profile Changes > 5.1.5 Retrieval of Profile Data > > split to cover from both profile notification server and profile > content > indirection server. > > 5.1.5 Upload of Profile Changes > > only from profile content indirection server > > 5.2 Profile Notification Server Behaviour > > 5.2.1 Enrollment with Profile Server > > 5.2.2 Notification of Profile Changes > > 5.2.3 Retrieval of Profile Data > > 5.3 Profile Content Indirection Server Behaviour > > 5.3.1 Retrieval of Profile Data > > 5.3.2 Upload of Profile Changes > > 6 Event Package Definition > > The sub-breakdown here comes from RFC 3265 however the idea of > RFC > 3265 is not to slavishly follow, but to make sure all the > information is > contained. Therefore it is proposed that the examples are moved > out of this > level to a later point in the document. > Remove all text relating to content indirection from the > existing event package > definition except for the passing of the URI. > > The idea is that this defines the package, but material relating > to the use of > the package goes elsewhere. > > 6.1 Event Package Name > > 6.2 Event Package Parameters > > Move out the profile type introduction to the overview. > > 6.3 SUBSCRIBE Bodies > > 6.4 Subscription Duration > > 6.5 NOTIFY Bodies > > 6.6 Notifier Processing of SUBSCRIBE Requests > > 6.7 Notifier Generation of SUBSCRIBE Requests > > 6.8 Subscriber Processing of NOTIFY Requests > > 6.9 Handling of Forked Requests > > 6.10 Rate of Notifications > > 6.11 State Agents > > 7 Instructions for Data Set Authors > > Substantially new. > > Data set authors need to register a mime type for their data > set. > > 8 Examples > > See section 7.12 of existing document. > > 9 IANA Considerations > > 9.1 SIP Event Package > > 9.2 New HTTP Event Header > > 10 Security Considerations > > Much of the procedural text in here actually needs to go back > into the main > text ? where there are already some requirements. The text here > should then > refer to that text rather than repeat it. > > 11 References > > 11.1 Normative References > > 11.2 Informative References > > ------------------------------------------------------------------------ > ---------- > > Regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > 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 -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 16:18:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHHx-0006Z2-EA; Thu, 09 Nov 2006 16:18:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHHv-0006Un-QK for sipping@ietf.org; Thu, 09 Nov 2006 16:18:19 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHHu-0004ZT-JD for sipping@ietf.org; Thu, 09 Nov 2006 16:18:19 -0500 Received: from [130.129.66.46] (dhcp66-46.ietf67.org [130.129.66.46]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA9LI3WH026118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Nov 2006 16:18:08 -0500 (EST) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 13:18:01 -0800 To: "Brian Stucker" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I'm unclear how this could work, unless we define some global registry of ring tones, which seems utterly impractical. On Nov 9, 2006, at 11:29 AM, Brian Stucker wrote: > I would also agree. > > I wasn't proposing anything earlier, just stating an observed behavior > (ala SIPit reports). I can make a recommendation in the early media > draft though around this area. > > Regards, > Brian > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 16:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHJs-0008DL-BQ; Thu, 09 Nov 2006 16:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHJr-0008Cf-3p for sipping@ietf.org; Thu, 09 Nov 2006 16:20:19 -0500 Received: from web8704.mail.in.yahoo.com ([203.84.221.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiHJp-00052o-CX for sipping@ietf.org; Thu, 09 Nov 2006 16:20:19 -0500 Received: (qmail 83936 invoked by uid 60001); 9 Nov 2006 21:19:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=soBOyRPcjR/tTX0uw1sEno/qv3Hb3fsLVnN/Cy1F0m/K5mJtDd7w4Px20N70zkPBor9ySnpi8DI7eRriP9lqlTR4GxAMHYs2P/uKbg0rWO8DPEhp0ZR8dRjTtJVTMTDFHobob8UcyNf+7naFkBMUWzxhCTZBFze+x+uw5+kaXX4= ; Message-ID: <20061109211953.83934.qmail@web8704.mail.in.yahoo.com> Received: from [172.202.87.146] by web8704.mail.in.yahoo.com via HTTP; Thu, 09 Nov 2006 21:19:53 GMT Date: Thu, 9 Nov 2006 21:19:53 +0000 (GMT) From: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Paul Kyzivat , Siddhartha Bhakta In-Reply-To: <45536D3B.1030806@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: sipping@ietf.org, 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Dear Paul, I could not appreciate the comment "Each distinct to-tag results in a new early dialog". May be due to lack of my understanding about the dialog concept. I am considering Alice in isolation here. In sec 2.9 call flow, the F5 creates a dialog-ID1{Local-tag=1234567, remote-tag=3145678, call-id=12345600@atlanta.example.com}. The F10 shall create another dialog-ID2{Local-tag=1234567, remote-tag=9214d, call-id=12345600@atlanta.example.com}. Subsequently, F13 shall create dialog-ID3{Local-tag=1234567, remote-tag=765432, call-id=12345600@atlanta.example.com}. In this call flow, the dialog-ID3 is being continued. How dialog-ID1 and dialog-ID2 shall be terminated? Will those be timed-out (32*T1)? I suppose, the F18, F21 shall terminate dialog-ID3 only. Moreover, the sec 13.3.1.1 of RFC3261 indicates that "A UAS MAY send as many provisional responses as it likes. Each of these MUST indicate the same dialog ID." Initially I was assuming this logic. You can validate this: The dialog-id is being modified on receiving F10. It is further modified on receiving F13. In this logic, Alice shall not receive message related to dialog-ID1 after receiving F10. Similarly, Alice shall not receive message related to dialog-ID2 after receiving F13. Please clarify. I was assuming the logic that, any early dialog identifier can be modified. Though, I could not find out such a logic in any RFC. The sec 2.9 call flow also violates SDP offer/answer flow mentioned in RFC3261. As per sec 13.2.1 of RFC3261, if provisional response contains SDP answer, then subsequent provisional response or 2xx response should contain same SDP. If they contain different SDP then UAC should ignore it. With this logic, SDP of F13 shall be ignored as Alice has already received SDP on F5. This shall lead to the fact, Alice is not hearing the ringtone fed by User B2. Please comment. In am quoting the relevent part(sec 13.2.1) of RFC3261... " o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." --- Paul Kyzivat wrote: > > > Siddhartha Bhakta wrote: > > Dear Alan/Robert/Kevin, > > > > I could find out following problem in sec 2.9 as > far > > as SIP dialog is concerned. The F5(180) is > creating an > > early dialog between Alice and > Proxy(from-tag=1234567, to-tag=3145678). > > Whereas, later on, Proxy is sending back 181(F10) > and 180(F13) with a > > different to-tag. The F10 (181) contains > to-tag=9214d and to-tag=765432 > > > > Is it not the violation of RFC3261 dialog concept? > > No. This is normal behavior in the presence of > forking. > > Each distinct to-tag results in a new early dialog. > > > I am not sure how the Alice SIP entity shall > manage the SIP dialog. > > Definitely, F10 and F13 shall not be associated to > the dialog created by F5. > > Alice might discard F10 (181) as that is > containing different to-tags. > > Alice must recognize that she is receiving responses > for two dialogs, > and must be prepared for either of them to receive a > 200. Discarding the > responses for the 2nd dialog is incorrect. > > Normally you will receive a final response for one > of the early dialogs, > or possibly for yet another dialog that hasn't > previously been seen. If > that is >=300, they you should consider all of your > dialogs terminated. > > If you get a 2xx response, then you know one dialog > that succeeded. > Usually all the others will be canceled by the > proxy. But it is possible > that there is another 2xx on the way for another > dialog. If so then you > must deal with that some way. Most commonly people > send a BYE to any > subsequent 2xxs they receive. > > Paul > > > The out of dialog 1xx should be discarded. > > > > Similar problem is there in sec 2.12. The F5 and > F18 contains different to-tags. > > In sec 2.7, the F3 and F6 have different to-tags. > > In sec 2.8, F6 and F9 have different to-tags. > > > > Early response is anticipated. > > > > Thanks, > > > > Siddhartha > __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 16:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHkT-00005h-DU; Thu, 09 Nov 2006 16:47:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHkS-00004t-B1 for sipping@ietf.org; Thu, 09 Nov 2006 16:47:48 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHjI-0000Lp-QW for sipping@ietf.org; Thu, 09 Nov 2006 16:46:38 -0500 Received: (qmail 32272 invoked by uid 0); 9 Nov 2006 21:46:19 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Nov 2006 21:46:19 -0000 Message-ID: <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "Siddhartha Bhakta" References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> <45536D3B.1030806@cisco.com> Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Thu, 9 Nov 2006 22:46:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org 181 is one of those types of responses for which I tend to think: wouldn't that work better without a to-tag? I know the current RFC3261 rules don't allow that (non-100 responses MUST have a to-tag), and section 16.7 point 6 explicitly talks about a "virtual UAS" to model the case of a proxy sending a non-100 response. But OTOH: the proxy knows it won't be needing the dialog Regards, Jeroen Paul Kyzivat wrote: > Siddhartha Bhakta wrote: >> Dear Alan/Robert/Kevin, >> >> I could find out following problem in sec 2.9 as far >> as SIP dialog is concerned. The F5(180) is creating an >> early dialog between Alice and Proxy(from-tag=1234567, >> to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10) >> and 180(F13) with a different to-tag. The F10 (181) contains to-tag=9214d >> and >> to-tag=765432 Is it not the violation of RFC3261 dialog concept? > > No. This is normal behavior in the presence of forking. > > Each distinct to-tag results in a new early dialog. > >> I am not sure how the Alice SIP entity shall manage the SIP dialog. >> Definitely, F10 and F13 shall not be associated to the dialog >> created by F5. Alice might discard F10 (181) as that is containing >> different to-tags. > > Alice must recognize that she is receiving responses for two dialogs, > and must be prepared for either of them to receive a 200. Discarding > the responses for the 2nd dialog is incorrect. > > Normally you will receive a final response for one of the early > dialogs, or possibly for yet another dialog that hasn't previously > been seen. If that is >=300, they you should consider all of your > dialogs terminated. > If you get a 2xx response, then you know one dialog that succeeded. > Usually all the others will be canceled by the proxy. But it is > possible that there is another 2xx on the way for another dialog. If > so then you must deal with that some way. Most commonly people send a > BYE to any subsequent 2xxs they receive. > > Paul > >> The out of dialog 1xx should be discarded. >> >> Similar problem is there in sec 2.12. The F5 and F18 contains >> different to-tags. In sec 2.7, the F3 and F6 have different to-tags. >> In sec 2.8, F6 and F9 have different to-tags. >> >> Early response is anticipated. >> >> Thanks, >> >> Siddhartha > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 17:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIkH-0004JM-6p; Thu, 09 Nov 2006 17:51:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiIkF-0004Fw-OI for sipping@ietf.org; Thu, 09 Nov 2006 17:51:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIkD-00011Q-V1 for sipping@ietf.org; Thu, 09 Nov 2006 17:51:39 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 14:51:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA9Mpb26032207; Thu, 9 Nov 2006 14:51:37 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA9MpYW4003921; Thu, 9 Nov 2006 14:51:34 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 14:51:33 -0800 Received: from [10.21.152.186] ([10.21.152.186]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 14:51:33 -0800 Message-ID: <4553B0F1.4040604@cisco.com> Date: Thu, 09 Nov 2006 17:51:29 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Henning Schulzrinne References: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com> <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> In-Reply-To: <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2006 22:51:33.0649 (UTC) FILETIME=[9AA19010:01C70451] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1711; t=1163112697; x=1163976697; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info |Sender:=20; bh=94I1L4GNJLBCgCTwzaAWyQ40oa0xBy+/MWnA8Rws5UM=; b=kwdaf9dkNIl3OiPkjIczWNdrjivLOCrmsZCDUdi2Uyuoxq3iSzkqGrmbF/TjkIxRjdGWLZob pZXaPhR/u3Eam/EzmUccWd0SzTn4Ps5eaZYEMgZ//Oy4g+SR/UGHx4XK; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sipping , Brian Stucker Subject: [Sipping] Re: Utility of Alert-Info X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There could be a registry of ring tones, reflected in a URN. Or several different ones. Of course this is only useful if there is knowledge by the entity inserting the Alert-Info of the URNs supported by the UAS. In general it is probably impractical to expect that callers will know which ones their callee will accept. As as have said a few times now, I find this much more practical if it is used between a server acting for the UAS and the UAS. In such an environment, it becomes practical for the server to be informed of the URNs that the UAS will support. So this allows the server to apply all sorts of interesting algorithms to incoming requests to decide what sort of ring tone would be appropriate, and then insert an Alert-Info for the UAS. In that way you can have a ring tone algorithm that works consistently across all your phones without having to configure each one to do it. Paul Henning Schulzrinne wrote: > I'm unclear how this could work, unless we define some global registry > of ring tones, which seems utterly impractical. > > On Nov 9, 2006, at 11:29 AM, Brian Stucker wrote: > >> I would also agree. >> >> I wasn't proposing anything earlier, just stating an observed behavior >> (ala SIPit reports). I can make a recommendation in the early media >> draft though around this area. >> >> Regards, >> Brian >> > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 18:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJh3-0006la-RK; Thu, 09 Nov 2006 18:52:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJh3-0006lP-03 for sipping@ietf.org; Thu, 09 Nov 2006 18:52:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJgy-0007uw-Pj for sipping@ietf.org; Thu, 09 Nov 2006 18:52:24 -0500 Received: from [130.129.68.74] (dhcp68-74.ietf67.org [130.129.68.74]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kA9Mtpng000592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 16:55:51 -0600 In-Reply-To: <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> References: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com> <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08D5AA48-9AC8-48AF-872B-3471DBFAF255@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 17:52:04 -0600 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 9, 2006, at 3:18 PM, Henning Schulzrinne wrote: > I'm unclear how this could work, unless we define some global > registry of ring tones, which seems utterly impractical. > I would think a global registry of national-standard ring tones would be reasonably practical. I generally wouldn't care all that much is somebody wanted me to hear a French ring-back when I call them. What I don't really want is to go download (esp. at time of use) the latest Britney Spears MP3 just so I can hear it play while I'm waiting on my niece to answer the phone. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 18:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJiz-0000XN-90; Thu, 09 Nov 2006 18:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJix-0000X8-Da for sipping@ietf.org; Thu, 09 Nov 2006 18:54:23 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJiw-0008F3-3e for sipping@ietf.org; Thu, 09 Nov 2006 18:54:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA9Nru614790; Thu, 9 Nov 2006 18:53:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 17:53:50 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111625643@zrc2hxm2.corp.nortel.com> In-Reply-To: <08D5AA48-9AC8-48AF-872B-3471DBFAF255@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: AccEWh3PTlYSZ+vCTuOm/XYCuXkKOQAACmrQ From: "Brian Stucker" To: "Dean Willis" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org AMEN.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, November 09, 2006 3:52 PM > To: Henning Schulzrinne > Cc: Stucker, Brian (RICH1:AR00); sipping > Subject: Re: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 >=20 > On Nov 9, 2006, at 3:18 PM, Henning Schulzrinne wrote: >=20 > > I'm unclear how this could work, unless we define some=20 > global registry=20 > > of ring tones, which seems utterly impractical. > > >=20 > I would think a global registry of national-standard ring=20 > tones would =20 > be reasonably practical. I generally wouldn't care all that much is =20 > somebody wanted me to hear a French ring-back when I call them. What =20 > I don't really want is to go download (esp. at time of use) the =20 > latest Britney Spears MP3 just so I can hear it play while I'm =20 > waiting on my niece to answer the phone. >=20 > -- > Dean >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 19:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKYR-0002VN-H6; Thu, 09 Nov 2006 19:47:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKYQ-0002UH-5W for sipping@ietf.org; Thu, 09 Nov 2006 19:47:34 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKYO-0007uv-TO for sipping@ietf.org; Thu, 09 Nov 2006 19:47:34 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20061110004731m12000dvoae>; Fri, 10 Nov 2006 00:47:31 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAA0lUQg021141 for ; Thu, 9 Nov 2006 19:47:30 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAA0lUEI021137; Thu, 9 Nov 2006 19:47:30 -0500 Date: Thu, 9 Nov 2006 19:47:30 -0500 Message-Id: <200611100047.kAA0lUEI021137@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <453FBDA9.6090201@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt References: <453CC8EC.1090303@sipstation.com> <4ff4e7370610251116w4d764541h5bdc18d5d3989f90@mail.gmail.com> <453FB037.3000606@sipstation.com> <4ff4e7370610251207k64a90d9bi301810b5017f097c@mail.gmail.com> <453FBDA9.6090201@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: Paul Kyzivat > I agree that the draft/call flow you have indicated in the document for > MOH does not show dynamic pay load but based on experiences I have had > with various vendors, there are dynamic payloads involved in a majority > of calls thus making this example flow un-usable in most real world > examples. > I also agree there needs to be a broader discussion w.r.t 3PCC > and dynamic pay load types. However, in the absence of such > guidelines, I am not sure depicting call flows that violates RFC 3264 > behavior makes sense. The example as it stands doesn't violate anything. I gather your issue isn't that this example is wrong, but rather that it isn't realistic, and that if it were made realistic then it would be apparent that it would be likely to be wrong. Is that right? So you would like to see everybody using dynamic payloads in this example? I'd say that if an example *depends* on not using dynamic payloads to work correctly, it should be noted in the example. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 20:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKsm-0001ds-Bc; Thu, 09 Nov 2006 20:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKsl-0001dn-7C for sipping@ietf.org; Thu, 09 Nov 2006 20:08:35 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKsk-0001uh-1F for sipping@ietf.org; Thu, 09 Nov 2006 20:08:35 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006111001083301400qd4vme>; Fri, 10 Nov 2006 01:08:33 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAA18XQg021623 for ; Thu, 9 Nov 2006 20:08:33 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAA18XY6021619; Thu, 9 Nov 2006 20:08:33 -0500 Date: Thu, 9 Nov 2006 20:08:33 -0500 Message-Id: <200611100108.kAA18XY6021619@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: (dean.willis@softarmor.com) Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F7E9F.3030403@cisco.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > I think it would be far better to define a URN namespace for > ringtones and use local configuration to map those to specific > files. What you are proposing will only work in the most closed and > homogeneous environments. I don't think a URN namespace would be particularly useful because the only use case is vanity customizations -- there is no set of conceptual ringtones that has meaning over a broad swathe of users. So Alert-Info URIs are going to be either URLs that are only locally significant (http://127.0.0.1/spears1.wav) or nearly arbitrary URNs that are only locally significant (urn:oid:1.3.6.1.4.1.14490.4.1). Dale _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 22:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNAd-0005pT-IP; Thu, 09 Nov 2006 22:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNAb-0005os-MT for sipping@ietf.org; Thu, 09 Nov 2006 22:35:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiNAZ-0005Qi-Bx for sipping@ietf.org; Thu, 09 Nov 2006 22:35:09 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 19:35:07 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="342054399:sNHT48252886" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAA3Z6rD031774; Thu, 9 Nov 2006 19:35:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAA3Yode020529; Thu, 9 Nov 2006 19:34:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 19:34:55 -0800 Received: from [130.129.71.112] ([10.21.121.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 19:34:55 -0800 In-Reply-To: References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F7E9F.3030403@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34639103-DCC4-4F42-A0B3-DEAB03B1305C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 19:34:55 -0800 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 03:34:55.0620 (UTC) FILETIME=[30987440:01C70479] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=867; t=1163129706; x=1163993706; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=09[Sippin g]=09draft-stucker-sipping-early-media-coping) |Sender:=20; bh=PbbzNvGkXnpUi/YYc1rlc4SfCk8q74Tw+D7BLGp7odg=; b=nbvWL8dLsZ+pd5NMz/aQpsUJNYYhgcBqZvzXDsf6dqmEBXSazb2QkfnWsjh5qVZSOrKNGSDQ NjywCkyc0G8t/7aQkNwHy6VXyhY6sZqr3aj9yiUyiCkaC4jOEaIk0Hev; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Paul Kyzivat , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org If you want a list of the tones - you might check out the draft I did a long time ago ... http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- midi.html If you think that it would be a good idea that when I phone country X, I get a tone that I can recognize as busy or ringing , well I agree with you but all research of what users wants and what companies want to build seems to disagree with you. On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: > > On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: > >> I think it would be far better to define a URN namespace for >> ringtones and use local configuration to map those to specific >> files. What you are proposing will only work in the most closed >> and homogeneous environments. >> > > Absolutely. I think this is a GREAT idea. > > -- > Dean _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 23:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiO5e-0006gy-PP; Thu, 09 Nov 2006 23:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiO5e-0006gE-25 for sipping@ietf.org; Thu, 09 Nov 2006 23:34:06 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiO5c-0007HD-OD for sipping@ietf.org; Thu, 09 Nov 2006 23:34:06 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20061110043359m1100ndalfe>; Fri, 10 Nov 2006 04:33:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAA4XwQg026531; Thu, 9 Nov 2006 23:33:58 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAA4XvJN026527; Thu, 9 Nov 2006 23:33:57 -0500 Date: Thu, 9 Nov 2006 23:33:57 -0500 Message-Id: <200611100433.kAA4XvJN026527@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Mary Barnes , Gonzalo Camarillo Subject: [Sipping] draft-ietf-sipping-service-examples-11.txt and my review of draft-ietf-sipping-service-examples-10.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I've compared my review of draft-ietf-sipping-service-examples-10.txt with draft-ietf-sipping-service-examples-11.txt and have the following comments: > * Header line breaking > > While the grammar of RFC 3261 section 25.1 allows header values to be > broken at most delimiters, it does not allow URIs to be broken. # I have fixed this by using the tag defined in RFC 4475. This fix is good, but it's not quite complete. In regard to whitespace around the point of the break, RFC 4475 says: Several of these examples contain unfolded lines longer than 72 characters. These are captured between tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line. (The final phrase "at the beginning of a line" implicitly refers to the left margin established by the surrounding text.) In -11, the uses of are: page 59, message F15: REFER sips:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds2g Max-Forwards: 70 From: Bob ;tag=23431 To: Alice ;tag=1234567 Call-ID: 12345600@atlanta.example.com CSeq: 1025 REFER Refer-To: Referred-By: Contact: Content-Length: 0 pages 66/67, message F5: Do you want to take this call from Alice? page 130, message F5: REFER sips:park@server.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Park Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 REFER Refer-To: Referred-By: Contact: Content-Length: 0 In all three cases, the successive displayed line are indented one space relative to the initial displayed line, which according to RFC 4425 means that a space is present in the "real" line. But whitespace is not allowed in URIs (which is why they can't be broken across lines). The indentation needs to be removed. > * 2.15. Call Park In the comment on message F14, Bob's name is truncated to "B" in one place: /* Park Server reports success back to B by returning a 200 OK response. Bob obtains the dialog identifiers from the headers included in the response. */ > Section 2.16: > > * Is intended to be a GRUU? If so, > to align it with draft-ietf-sip-gruu-09.txt, it should be replaced > with . But "gruu" has been changed to "gr" in draft-ietf-sip-gruu-11. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 09 23:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiO9f-0001ev-U5; Thu, 09 Nov 2006 23:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiO9e-0001eO-VF for sipping@ietf.org; Thu, 09 Nov 2006 23:38:14 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiO9d-00082J-Od for sipping@ietf.org; Thu, 09 Nov 2006 23:38:14 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20061110043812b1400cu4n3e>; Fri, 10 Nov 2006 04:38:13 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAA4cCQg026646 for ; Thu, 9 Nov 2006 23:38:12 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAA4cCHI026642; Thu, 9 Nov 2006 23:38:12 -0500 Date: Thu, 9 Nov 2006 23:38:12 -0500 Message-Id: <200611100438.kAA4cCHI026642@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> <45536D3B.1030806@cisco.com> <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> X-Spam-Score: 1.4 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: "Jeroen van Bemmel" 181 is one of those types of responses for which I tend to think: wouldn't that work better without a to-tag? I know the current RFC3261 rules don't allow that (non-100 responses MUST have a to-tag), and section 16.7 point 6 explicitly talks about a "virtual UAS" to model the case of a proxy sending a non-100 response. But OTOH: the proxy knows it won't be needing the dialog You don't want to put an exception in the lower-layer processing of Special Case Foo because the higher-layer won't be needing the information. That way lies madness. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 01:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiPzR-0006kr-41; Fri, 10 Nov 2006 01:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiPzO-0006kk-Pl for sipping@ietf.org; Fri, 10 Nov 2006 01:35:46 -0500 Received: from smtp.dgcsystems.net ([83.241.254.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiPzJ-0008AY-E3 for sipping@ietf.org; Fri, 10 Nov 2006 01:35:46 -0500 Received: from Snork ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 07:35:29 +0100 From: "Gunnar Hellstrom" To: "Cullen Jennings" , "Dean Willis" Subject: SV: Utility of Alert-Info (was:Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Fri, 10 Nov 2006 07:35:40 +0100 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <34639103-DCC4-4F42-A0B3-DEAB03B1305C@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-OriginalArrivalTime: 10 Nov 2006 06:35:29.0919 (UTC) FILETIME=[6A5748F0:01C70492] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Paul Kyzivat , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org If this discussion will lead to an enhanced definition of alerting, please then remember to include not only that the tone characteristics should be configurable, but also the mode of alerting. -Audible - Ring tones etc according to current discussion. -Visual - Flashing lights, flashing screen. -Tactile - Pocket vibration, watch vibration, handset vibration. In many cases the selection can be made from preferences in a user profile, while in other cases it is the environment that influences what mode to use. ( e.g. flashing light in very noisy industry area ) Gunnar -----Ursprungligt meddelande----- Fran: Cullen Jennings [mailto:fluffy@cisco.com] Skickat: den 10 november 2006 04:35 Till: Dean Willis Kopia: Paul Kyzivat; sipping; Brian Stucker Amne: Re: Utility of Alert-Info (was:Re: [Sipping] draft-stucker-sipping-early-media-coping) If you want a list of the tones - you might check out the draft I did a long time ago ... http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- midi.html If you think that it would be a good idea that when I phone country X, I get a tone that I can recognize as busy or ringing , well I agree with you but all research of what users wants and what companies want to build seems to disagree with you. On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: > > On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: > >> I think it would be far better to define a URN namespace for >> ringtones and use local configuration to map those to specific >> files. What you are proposing will only work in the most closed >> and homogeneous environments. >> > > Absolutely. I think this is a GREAT idea. > > -- > Dean _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 01:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQ4x-0008M0-PS; Fri, 10 Nov 2006 01:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiQ4w-0008Kc-NR for sipping@ietf.org; Fri, 10 Nov 2006 01:41:30 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiQ4u-0000Xl-9e for sipping@ietf.org; Fri, 10 Nov 2006 01:41:30 -0500 Received: (qmail 14232 invoked by uid 0); 10 Nov 2006 06:41:10 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Nov 2006 06:41:10 -0000 Message-ID: <001401c70493$3d556a20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com><45536D3B.1030806@cisco.com> <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> <200611100438.kAA4cCHI026642@dragon.ariadne.com> Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 07:41:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There is no need to change anything in the lower layers (I presume you mean transaction layer and below). The change would be that a proxy be allowed to originate 1xx responses without a to-tag, on the UAC side the dialog layer would recognise (as it already should) that there is no to-tag, hence no early dialog. In any case, the current 2.9 example flow is wrong and incomplete: the way it currently is (with to-tag) F10 should have a Contact header, and the UAC should send BYE to this Contact Regards, Jeroen Dale.Worley@comcast.net wrote: > From: "Jeroen van Bemmel" > > 181 is one of those types of responses for which I tend to think: > wouldn't that work better without a to-tag? > > I know the current RFC3261 rules don't allow that (non-100 > responses MUST have a to-tag), and section 16.7 point 6 explicitly > talks about a "virtual UAS" to model the case of a proxy sending a > non-100 response. But OTOH: the proxy knows it won't be needing the > dialog > > You don't want to put an exception in the lower-layer processing of > Special Case Foo because the higher-layer won't be needing the > information. That way lies madness. > > Dale > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 06:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiUNU-0002rF-Fb; Fri, 10 Nov 2006 06:16:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiUMT-0002Bp-8o for sipping@ietf.org; Fri, 10 Nov 2006 06:15:53 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiU9P-0003tz-0q for sipping@ietf.org; Fri, 10 Nov 2006 06:02:26 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.236,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027,SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Fri, 10 Nov 2006 11:00:34 +0000 From: "Siddhartha Bhakta" To: "'Jeroen van Bemmel'" , "'Paul Kyzivat'" Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 11:00:27 -0000 Message-ID: <011b01c704b7$7089e500$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccESGtvxnk7b7KZSr2yvdPblIRe4AAbjvvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> X-Spam-Score: 1.2 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jeroen, I tend to agree with you on 181 responses. The 181 response should be considered like 100 responses, which may not have to-tag. In fact, I think 100 and 181 MUST not have to-tag as those are not typically generated by ultimate SIP endpoint. In fact, the draft-ietf-sipping-service-examples-08 does not have to-tag in 181 responses. Regards, Siddhartha -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 09 November 2006 21:47 To: Paul Kyzivat; Siddhartha Bhakta Cc: sipping@ietf.org Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 181 is one of those types of responses for which I tend to think: wouldn't that work better without a to-tag? I know the current RFC3261 rules don't allow that (non-100 responses MUST have a to-tag), and section 16.7 point 6 explicitly talks about a "virtual UAS" to model the case of a proxy sending a non-100 response. But OTOH: the proxy knows it won't be needing the dialog Regards, Jeroen Paul Kyzivat wrote: > Siddhartha Bhakta wrote: >> Dear Alan/Robert/Kevin, >> >> I could find out following problem in sec 2.9 as far >> as SIP dialog is concerned. The F5(180) is creating an >> early dialog between Alice and Proxy(from-tag=1234567, >> to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10) >> and 180(F13) with a different to-tag. The F10 (181) contains to-tag=9214d >> and >> to-tag=765432 Is it not the violation of RFC3261 dialog concept? > > No. This is normal behavior in the presence of forking. > > Each distinct to-tag results in a new early dialog. > >> I am not sure how the Alice SIP entity shall manage the SIP dialog. >> Definitely, F10 and F13 shall not be associated to the dialog >> created by F5. Alice might discard F10 (181) as that is containing >> different to-tags. > > Alice must recognize that she is receiving responses for two dialogs, > and must be prepared for either of them to receive a 200. Discarding > the responses for the 2nd dialog is incorrect. > > Normally you will receive a final response for one of the early > dialogs, or possibly for yet another dialog that hasn't previously > been seen. If that is >=300, they you should consider all of your > dialogs terminated. > If you get a 2xx response, then you know one dialog that succeeded. > Usually all the others will be canceled by the proxy. But it is > possible that there is another 2xx on the way for another dialog. If > so then you must deal with that some way. Most commonly people send a > BYE to any subsequent 2xxs they receive. > > Paul > >> The out of dialog 1xx should be discarded. >> >> Similar problem is there in sec 2.12. The F5 and F18 contains >> different to-tags. In sec 2.7, the F3 and F6 have different to-tags. >> In sec 2.8, F6 and F9 have different to-tags. >> >> Early response is anticipated. >> >> Thanks, >> >> Siddhartha > > _______________________________________________ > 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 --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 09:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiWve-0005BZ-Iq; Fri, 10 Nov 2006 09:00:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiWvc-0005A8-7b for sipping@ietf.org; Fri, 10 Nov 2006 09:00:20 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiWvW-00067I-NS for sipping@ietf.org; Fri, 10 Nov 2006 09:00:20 -0500 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAADxocS032090; Fri, 10 Nov 2006 14:59:50 +0100 Received: from [127.0.0.1] ([155.132.188.76]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006111014594332:6853 ; Fri, 10 Nov 2006 14:59:43 +0100 Message-ID: <455485C3.703@alcatel.fr> Date: Fri, 10 Nov 2006 14:59:31 +0100 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> <45536D3B.1030806@cisco.com> <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> In-Reply-To: <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 14:59:43, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 14:59:45, Serialize complete at 11/10/2006 14:59:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.3 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Paul Kyzivat , sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jeroen van Bemmel wrote: > 181 is one of those types of responses for which I tend to think: > wouldn't that work better without a to-tag? I agree with that point, it is particularly tricky for UAs implementations to receive a first 1xx with a toTag, and then, and 200 OK with another one... I general, they report a bug to proxy implementor ;-) and after realizing it is the "virtual UAS" case in RFC, they start to classify this as "evil" feature... That's true that UAs should support forking, and thus, be capable of receiving multiple toTag, but is just not very often supported from my experience... > > I know the current RFC3261 rules don't allow that (non-100 responses > MUST have a to-tag), and section 16.7 point 6 explicitly talks about a > "virtual UAS" to model the case of a proxy sending a non-100 response. > But OTOH: the proxy knows it won't be needing the dialog > > Regards, > Jeroen > > Paul Kyzivat wrote: >> Siddhartha Bhakta wrote: >>> Dear Alan/Robert/Kevin, >>> >>> I could find out following problem in sec 2.9 as far >>> as SIP dialog is concerned. The F5(180) is creating an >>> early dialog between Alice and Proxy(from-tag=1234567, >>> to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10) >>> and 180(F13) with a different to-tag. The F10 (181) contains >>> to-tag=9214d and >>> to-tag=765432 Is it not the violation of RFC3261 dialog concept? >> >> No. This is normal behavior in the presence of forking. >> >> Each distinct to-tag results in a new early dialog. >> >>> I am not sure how the Alice SIP entity shall manage the SIP dialog. >>> Definitely, F10 and F13 shall not be associated to the dialog >>> created by F5. Alice might discard F10 (181) as that is containing >>> different to-tags. >> >> Alice must recognize that she is receiving responses for two dialogs, >> and must be prepared for either of them to receive a 200. Discarding >> the responses for the 2nd dialog is incorrect. >> >> Normally you will receive a final response for one of the early >> dialogs, or possibly for yet another dialog that hasn't previously >> been seen. If that is >=300, they you should consider all of your >> dialogs terminated. >> If you get a 2xx response, then you know one dialog that succeeded. >> Usually all the others will be canceled by the proxy. But it is >> possible that there is another 2xx on the way for another dialog. If >> so then you must deal with that some way. Most commonly people send a >> BYE to any subsequent 2xxs they receive. >> >> Paul >> >>> The out of dialog 1xx should be discarded. >>> >>> Similar problem is there in sec 2.12. The F5 and F18 contains >>> different to-tags. In sec 2.7, the F3 and F6 have different to-tags. >>> In sec 2.8, F6 and F9 have different to-tags. >>> >>> Early response is anticipated. >>> >>> Thanks, >>> >>> Siddhartha >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 09:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXN2-0005Ew-No; Fri, 10 Nov 2006 09:28:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXN1-0005Er-B5 for sipping@ietf.org; Fri, 10 Nov 2006 09:28:39 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXMz-00024d-40 for sipping@ietf.org; Fri, 10 Nov 2006 09:28:39 -0500 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 09:28:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 09:28:13 -0500 Message-ID: <77BD870EA838FC469FDD2AE248B1357B01788D05@ATL1VEXC008.usdom003.tco.tc> In-Reply-To: <455485C3.703@alcatel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Thread-Index: AccE0MtJ1u7RJHeuQce5C3xR7xhrOQAAH8OQ From: "Brett Tate" To: X-OriginalArrivalTime: 10 Nov 2006 14:28:11.0228 (UTC) FILETIME=[72FF99C0:01C704D4] X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > > 181 is one of those types of responses for which=20 > > I tend to think: wouldn't that work better without=20 > > a to-tag? >=20 > I agree with that point, it is particularly tricky for UAs=20 > implementations to receive a first 1xx with a toTag, and=20 > then, and 200 OK with another one... > I general, they report a bug to proxy implementor ;-) and=20 > after realizing it is the "virtual UAS" case in RFC, they=20 > start to classify this as "evil" feature... > That's true that UAs should support forking, and thus, be=20 > capable of receiving multiple toTag, but is just not very=20 > often supported from my experience... User Agents expecting offer/answer compliance must support forking proxies and thus 18x's and 2xx's with different To tags. I discuss some of the reasons within the following link. https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-November/0 14620.html _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 09:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXi7-0001IF-7o; Fri, 10 Nov 2006 09:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXi5-0001AY-7P for sipping@ietf.org; Fri, 10 Nov 2006 09:50:25 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXYJ-0003yJ-6u for sipping@ietf.org; Fri, 10 Nov 2006 09:40:20 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006111014401801400qdfbpe>; Fri, 10 Nov 2006 14:40:18 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAAEeIQg008476 for ; Fri, 10 Nov 2006 09:40:18 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAAEeHhX008472; Fri, 10 Nov 2006 09:40:17 -0500 Date: Fri, 10 Nov 2006 09:40:17 -0500 Message-Id: <200611101440.kAAEeHhX008472@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <455485C3.703@alcatel.fr> (Thomas.Froment@alcatel.fr) Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> <45536D3B.1030806@cisco.com> <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> <455485C3.703@alcatel.fr> X-Spam-Score: 1.4 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: Thomas.Froment@alcatel.fr I agree with that point, it is particularly tricky for UAs implementations to receive a first 1xx with a toTag, and then, and 200 OK with another one... How could a UA support forking generally and not handle this case smoothly? Forking of a request is not a weird special case. Non-forking of a request is the special case. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 09:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXqC-0005YC-J0; Fri, 10 Nov 2006 09:58:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXqB-0005Xr-0n for sipping@ietf.org; Fri, 10 Nov 2006 09:58:47 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXq8-0007iL-Sb for sipping@ietf.org; Fri, 10 Nov 2006 09:58:47 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.233,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027,SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Fri, 10 Nov 2006 14:56:54 +0000 From: "Siddhartha Bhakta" To: , "'Jeroen van Bemmel'" Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 14:56:48 -0000 Message-ID: <013f01c704d8$74c14a20$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccE0HNz+gWzxIOiQIixiGuVTaZSygABBlZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <455485C3.703@alcatel.fr> X-Spam-Score: 1.2 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 'Paul Kyzivat' , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org If any SIP Proxy wants to generate any response when dialog is not created properly(i.e., t-tag is not exchanged) then proxy should skip to-tag. This logic shall avoid the mess. The "100 Trying" would come in such a category. The "181 Call Is Being Forwarded" message of draft-ietf-sipping-service-examples-11 draft should not have to-tag. If any SIP proxy wants to generate 183 of its own to feed some tone, it should also skip to-tag. With the above mentioned logic, we can not always avoid the fact that SIP UA may receive multiple responses with different to-tags. Consider the CFNA (sec 2.9 of draft-ietf-sipping-service-examples-11) where forking proxy ought to send 180 (from User B1) downstream as proxy has no idea beforehand whether User B1 shall pick up the phone or not. Now the question is: If any SIP UA(Alice here) receives multiple provisional/final responses (of single INVITE) with different to-tags then whether it should create different dialogs or not? I would suggest that SIP UA should not create separate dialog. Rather it should modify the dialog-id of the existing dialog, if already created. As soon as a response with different tag is received then earlier dialog becomes invalid. Then what is point in keeping the earlier dialog ! This logic shall introduce the new concept that if provisional response is received with to-tag when there is already an established dialog then it shall modify the dialog-id. This shall ensure that if any SIP entity sends single INVITE message then it shall create single dialog only. Forking works on different principal: SIP entity sends multiple INVITEs (with different branch parameters) and each of these INVITE shall create one dialog once corresponding response shall be received with to-tag. But we are talking about responses of a single INVITE ! Please suggest. -----Original Message----- From: Thomas.Froment@alcatel.fr [mailto:Thomas.Froment@alcatel.fr] Sent: 10 November 2006 14:00 To: Jeroen van Bemmel Cc: Paul Kyzivat; Siddhartha Bhakta; sipping@ietf.org Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Jeroen van Bemmel wrote: > 181 is one of those types of responses for which I tend to think: > wouldn't that work better without a to-tag? I agree with that point, it is particularly tricky for UAs implementations to receive a first 1xx with a toTag, and then, and 200 OK with another one... I general, they report a bug to proxy implementor ;-) and after realizing it is the "virtual UAS" case in RFC, they start to classify this as "evil" feature... That's true that UAs should support forking, and thus, be capable of receiving multiple toTag, but is just not very often supported from my experience... > > I know the current RFC3261 rules don't allow that (non-100 responses > MUST have a to-tag), and section 16.7 point 6 explicitly talks about a > "virtual UAS" to model the case of a proxy sending a non-100 response. > But OTOH: the proxy knows it won't be needing the dialog > > Regards, > Jeroen > > Paul Kyzivat wrote: >> Siddhartha Bhakta wrote: >>> Dear Alan/Robert/Kevin, >>> >>> I could find out following problem in sec 2.9 as far >>> as SIP dialog is concerned. The F5(180) is creating an >>> early dialog between Alice and Proxy(from-tag=1234567, >>> to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10) >>> and 180(F13) with a different to-tag. The F10 (181) contains >>> to-tag=9214d and >>> to-tag=765432 Is it not the violation of RFC3261 dialog concept? >> >> No. This is normal behavior in the presence of forking. >> >> Each distinct to-tag results in a new early dialog. >> >>> I am not sure how the Alice SIP entity shall manage the SIP dialog. >>> Definitely, F10 and F13 shall not be associated to the dialog >>> created by F5. Alice might discard F10 (181) as that is containing >>> different to-tags. >> >> Alice must recognize that she is receiving responses for two dialogs, >> and must be prepared for either of them to receive a 200. Discarding >> the responses for the 2nd dialog is incorrect. >> >> Normally you will receive a final response for one of the early >> dialogs, or possibly for yet another dialog that hasn't previously >> been seen. If that is >=300, they you should consider all of your >> dialogs terminated. >> If you get a 2xx response, then you know one dialog that succeeded. >> Usually all the others will be canceled by the proxy. But it is >> possible that there is another 2xx on the way for another dialog. If >> so then you must deal with that some way. Most commonly people send a >> BYE to any subsequent 2xxs they receive. >> >> Paul >> >>> The out of dialog 1xx should be discarded. >>> >>> Similar problem is there in sec 2.12. The F5 and F18 contains >>> different to-tags. In sec 2.7, the F3 and F6 have different to-tags. >>> In sec 2.8, F6 and F9 have different to-tags. >>> >>> Early response is anticipated. >>> >>> Thanks, >>> >>> Siddhartha >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 10:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYLg-0000GD-HM; Fri, 10 Nov 2006 10:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYLe-0000DM-Gr for sipping@ietf.org; Fri, 10 Nov 2006 10:31:18 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYLc-000489-Vf for sipping@ietf.org; Fri, 10 Nov 2006 10:31:18 -0500 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAAFVI50025289; Fri, 10 Nov 2006 16:31:18 +0100 Received: from [127.0.0.1] ([155.132.188.76]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006111016311251:8345 ; Fri, 10 Nov 2006 16:31:12 +0100 Message-ID: <45549B2F.9050709@alcatel.fr> Date: Fri, 10 Nov 2006 16:30:55 +0100 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <00fc01c70423$7f36c210$3801a8c0@newportnetworks.com> <45536D3B.1030806@cisco.com> <003a01c70448$85c64b30$0601a8c0@BEMBUSTER> <455485C3.703@alcatel.fr> <200611101440.kAAEeHhX008472@dragon.ariadne.com> In-Reply-To: <200611101440.kAAEeHhX008472@dragon.ariadne.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 16:31:13, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 16:31:13, Serialize complete at 11/10/2006 16:31:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.3 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Thomas.Froment@alcatel.fr > > I agree with that point, it is particularly tricky for UAs > implementations to receive a first 1xx with a toTag, and then, and > 200 OK with another one... > > How could a UA support forking generally and not handle this case > smoothly? > Theoritically, you are right :-), in practice, after 5 SIPIT, forking is not always so well supported by UAs (and proxies, by the way), probably because this is complex to implement... I still think that a proxy "muted temporarily" to a UAS is something unecesssary complex, it could be possible to say that a proxy sending 1xx reponses should NOT put any totag, (as for 100 trying)... So easy to say, so easy to implement... Best regards, Thomas _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 10:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYL3-0008ML-Gl; Fri, 10 Nov 2006 10:30:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYL1-0008MC-Ui for sipping@ietf.org; Fri, 10 Nov 2006 10:30:39 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYKx-000437-Av for sipping@ietf.org; Fri, 10 Nov 2006 10:30:39 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.252,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_BADTAG_00_10: 0.001,HTML_MESSAGE: 0.001, SARE_RECV_ADDR: 0.027,SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Fri, 10 Nov 2006 15:28:22 +0000 From: "Siddhartha Bhakta" To: Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 15:28:15 -0000 Message-ID: <014001c704dc$d9ec80a0$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccE3Nb+HLP7xIXFQMuRB4/tryp6Xg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1879145298==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1879145298== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01C704DC.D9EC80A0" This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C704DC.D9EC80A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Brett, For forking, SIP entity shall send multiple INVITE with different branch parameter. As s result, it shall receive response corresponding to different INVITEs. Those shall create multiple dilaogs. Here each of the dialogs are having separate INVITE messages. I am discussing sec 2.9, where Alice is sending single INVITE(F1) but it is receiving 1xx with different to-tags. Now the question is that, whether single INVITE can result into multiple dialogs? I thought that forking proxy shall manage all the forked dialogs and select one dialog as the best dialog and pass response downstream for that dialog only. That way Alice shall only see single dialog where proxy shall manage two forked dialog in this example. Please clarify. Message: 5 Date: Fri, 10 Nov 2006 09:28:13 -0500 From: "Brett Tate" Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Cc: sipping@ietf.org Message-ID: <77BD870EA838FC469FDD2AE248B1357B01788D05@ATL1VEXC008.usdom003.tco.tc> Content-Type: text/plain; charset="us-ascii" > > 181 is one of those types of responses for which I tend to think: > > wouldn't that work better without a to-tag? > > I agree with that point, it is particularly tricky for UAs > implementations to receive a first 1xx with a toTag, and then, and 200 > OK with another one... > I general, they report a bug to proxy implementor ;-) and after > realizing it is the "virtual UAS" case in RFC, they start to classify > this as "evil" feature... > That's true that UAs should support forking, and thus, be capable of > receiving multiple toTag, but is just not very often supported from my > experience... User Agents expecting offer/answer compliance must support forking proxies and thus 18x's and 2xx's with different To tags. I discuss some of the reasons within the following link. https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-November/0 14620.html --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_0141_01C704DC.D9EC80A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Brett,

 

For = forking, SIP entity shall send multiple INVITE with different branch parameter. As s = result, it shall receive response corresponding to different INVITEs. Those = shall create multiple dilaogs. Here each of the dialogs are having separate = INVITE messages.

 

I am = discussing sec 2.9, where Alice is sending single INVITE(F1) but it is receiving 1xx with different = to-tags. Now the question is that, whether single INVITE can result into multiple dialogs? I thought that forking proxy shall manage all the forked = dialogs and select one dialog as the best dialog and pass response downstream for = that dialog only. That way Alice shall only see single dialog where proxy shall manage two forked dialog = in this example.

 

Please = clarify.

 

 

Message: 5

Date: = Fri, 10 Nov 2006 09:28:13 -0500

From: = "Brett Tate" <brett@broadsoft.com>

Subject: RE: [Sipping] Query related to

      = draft-ietf-sipping-service-examples-11

To: <Thomas.Froment@alcatel.fr>

Cc: = sipping@ietf.org

Message-ID:

      = <77BD870EA838FC469FDD2AE248B1357B01788D05@ATL1VEXC008.usdom003.tco.tc&= gt;

Content-Type: text/plain;     = charset=3D"us-ascii"

 

> = > 181 is one of those types of responses for which I tend to think: =

> = > wouldn't that work better without a to-tag?

> =

> I = agree with that point, it is particularly tricky for UAs =

> implementations to receive a first 1xx with a toTag, and then, and 200 =

> = OK with another one...

> I = general, they report a bug to proxy implementor ;-) and after =

> = realizing it is the "virtual UAS" case in RFC, they start to classify =

> = this as "evil" feature...

> = That's true that UAs should support forking, and thus, be capable of =

> = receiving multiple toTag, but is just not very often supported from my =

> experience...

 

User = Agents expecting offer/answer compliance must support forking proxies and thus = 18x's and 2xx's with different To tags.

 

I = discuss some of the reasons within the following link.

 

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-No= vember/0

14620.html

 



---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_0141_01C704DC.D9EC80A0-- --===============1879145298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1879145298==-- From sipping-bounces@ietf.org Fri Nov 10 10:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYPz-0001xH-HO; Fri, 10 Nov 2006 10:35:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYPx-0001xC-CZ for sipping@ietf.org; Fri, 10 Nov 2006 10:35:45 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYPv-0004WE-LK for sipping@ietf.org; Fri, 10 Nov 2006 10:35:45 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.251,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_MESSAGE: 0.001,SARE_RECV_ADDR: 0.027, SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Fri, 10 Nov 2006 15:33:58 +0000 From: "Siddhartha Bhakta" To: , Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 15:33:51 -0000 Message-ID: <014501c704dd$a2390d80$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccE3Z9MU4zYBNMmRmSPVM9a8n0OPA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380097428==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1380097428== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01C704DD.A2390D80" This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C704DD.A2390D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For forking, SIP UA shall send multiple INVITE with different branch parameters. As s result, it shall receive response corresponding to different INVITEs. Those shall create multiple dialogs. Here each of the dialogs are having separate INVITE messages. In this case (sec 2.9), multiple to-tags are received for a single INVITE message. Therefore, these two cases are different. SIP UA can easily create single dialog per INVITE message(with distinct branch parameter). But managing multiple dialogs resulted due to single INVITE seems weird. Message: 6 Date: Fri, 10 Nov 2006 09:40:17 -0500 From: Dale.Worley@comcast.net Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: sipping@ietf.org Message-ID: <200611101440.kAAEeHhX008472@dragon.ariadne.com> From: Thomas.Froment@alcatel.fr I agree with that point, it is particularly tricky for UAs implementations to receive a first 1xx with a toTag, and then, and 200 OK with another one... How could a UA support forking generally and not handle this case smoothly? Forking of a request is not a weird special case. Non-forking of a request is the special case. Dale --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_0146_01C704DD.A2390D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For = forking, SIP UA shall send multiple INVITE with different branch parameters. As s = result, it shall receive response corresponding to different INVITEs. Those shall = create multiple dialogs. Here each of the dialogs are having separate INVITE = messages.

 

In = this case (sec 2.9), multiple to-tags are received for a single INVITE message. = Therefore, these two cases are different.

 

SIP UA = can easily create single dialog per INVITE message(with distinct branch parameter). = But managing multiple dialogs resulted due to single INVITE seems = weird.

 

Message: 6

Date: = Fri, 10 Nov 2006 09:40:17 -0500

From: Dale.Worley@comcast.net

Subject: Re: [Sipping] Query related to

      = draft-ietf-sipping-service-examples-11

To: sipping@ietf.org

Message-ID: <200611101440.kAAEeHhX008472@dragon.ariadne.com><= /font>

 

   From: Thomas.Froment@alcatel.fr

 

   I agree with that point, it is particularly tricky for = UAs

   implementations to receive a first 1xx with a toTag, and then, = and

   200 OK with another one...

 

How = could a UA support forking generally and not handle this case = smoothly?

 

Forking of a request is not a weird special case.  Non-forking of a request is the = special case.

 

Dale

 



---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_0146_01C704DD.A2390D80-- --===============1380097428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1380097428==-- From sipping-bounces@ietf.org Fri Nov 10 10:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYkM-0005ds-R5; Fri, 10 Nov 2006 10:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYkK-0005dL-Rj for sipping@ietf.org; Fri, 10 Nov 2006 10:56:48 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYkH-0007KB-DO for sipping@ietf.org; Fri, 10 Nov 2006 10:56:48 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.251,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_MESSAGE: 0.001,SARE_RECV_ADDR: 0.027, SUBJ_HAS_UNIQ_ID: 0.809 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Fri, 10 Nov 2006 15:55:02 +0000 From: "Siddhartha Bhakta" To: , Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 15:54:55 -0000 Message-ID: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccE4JBuoi+3n4IBSVyEyWJu+4WrbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484581404==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0484581404== Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01C704E0.935E3A80" This is a multi-part message in MIME format. ------=_NextPart_000_014B_01C704E0.935E3A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thomas's suggestion sounds good. If forking proxy needs to pass 18x downstream, it should NOT put to-tag. However, that shall put the restriction that PRACK can not be sent for that 18x messages since PRACK can only be sent over established dialog. If 18x response does not contain to-tag, it can not create dialog. That may be worth bet compared to all dialog related mess up in this case. Best regards, Siddhartha Date: Fri, 10 Nov 2006 16:30:55 +0100 From: Thomas.Froment@alcatel.fr Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Dale.Worley@comcast.net Cc: sipping@ietf.org Message-ID: <45549B2F.9050709@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dale.Worley@comcast.net wrote: > From: Thomas.Froment@alcatel.fr > > I agree with that point, it is particularly tricky for UAs > implementations to receive a first 1xx with a toTag, and then, and > 200 OK with another one... > > How could a UA support forking generally and not handle this case > smoothly? > Theoritically, you are right :-), in practice, after 5 SIPIT, forking is not always so well supported by UAs (and proxies, by the way), probably because this is complex to implement... I still think that a proxy "muted temporarily" to a UAS is something unecesssary complex, it could be possible to say that a proxy sending 1xx reponses should NOT put any totag, (as for 100 trying)... So easy to say, so easy to implement... Best regards, Thomas --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_014B_01C704E0.935E3A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thomas’s suggestion sounds good. If forking proxy needs to pass 18x downstream, = it should NOT put to-tag.

However, that shall put the restriction that PRACK can not be sent for that 18x = messages since PRACK can only be sent over established dialog. If 18x response = does not contain to-tag, it can not create dialog.

 

That = may be worth bet compared to all dialog related mess up in this = case.

 

Best = regards,

Siddhartha

 

Date: = Fri, 10 Nov 2006 16:30:55 +0100

From: Thomas.Froment@alcatel.fr

Subject: Re: [Sipping] Query related to

      = draft-ietf-sipping-service-examples-11

To: Dale.Worley@comcast.net

Cc: sipping@ietf.org

Message-ID: <45549B2F.9050709@alcatel.fr>

Content-Type: text/plain; charset=3DISO-8859-1; = format=3Dflowed

 

Dale.Worley@comcast.net wrote:

>    From: Thomas.Froment@alcatel.fr

> 

>    I agree with that point, it is particularly tricky for = UAs

>    implementations to receive a first 1xx with a toTag, and then, = and

>    200 OK with another one...

> 

> = How could a UA support forking generally and not handle this case =

> = smoothly?

>  

Theoritically, you are right :-), in practice, after 5 SIPIT, forking is not always so = well supported by UAs (and proxies, by the way), probably because this is = complex to implement... I still think that a proxy "muted temporarily" to = a UAS is something unecesssary complex, it could be possible to say that a = proxy sending 1xx reponses should NOT put any totag, (as for 100 trying)... So = easy to say, so easy to implement...

 

Best = regards,

Thomas

 



---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_014B_01C704E0.935E3A80-- --===============0484581404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0484581404==-- From sipping-bounces@ietf.org Fri Nov 10 10:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYmz-0008BP-MT; Fri, 10 Nov 2006 10:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYmz-0008BK-1v for sipping@ietf.org; Fri, 10 Nov 2006 10:59:33 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYmw-0007aQ-Q5 for sipping@ietf.org; Fri, 10 Nov 2006 10:59:33 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GiYms-0004IL-Na; Fri, 10 Nov 2006 07:59:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was:Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Fri, 10 Nov 2006 07:59:25 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC4B97A8@sea02-mxc01.citel.com> In-Reply-To: <08D5AA48-9AC8-48AF-872B-3471DBFAF255@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was:Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: AccEWsTAbRutoK/IR2q49YpyGVE5bwAhhIDw From: "Steve Langstaff" To: "Dean Willis" , "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 09 November 2006 23:52 > To: Henning Schulzrinne > Cc: sipping; Brian Stucker > Subject: Re: Utility of Alert-Info (was:Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 >=20 > On Nov 9, 2006, at 3:18 PM, Henning Schulzrinne wrote: >=20 > > I'm unclear how this could work, unless we define some=20 > global registry=20 > > of ring tones, which seems utterly impractical. > > >=20 > I would think a global registry of national-standard ring=20 > tones would =20 > be reasonably practical. I generally wouldn't care all that much is =20 > somebody wanted me to hear a French ring-back when I call them. What =20 > I don't really want is to go download (esp. at time of use) the =20 > latest Britney Spears MP3 just so I can hear it play while I'm =20 > waiting on my niece to answer the phone. Sorry if this is a silly question, but is the discussion here about the Alert-Info header in an INVITE or elsewhere (i.e. is it the called party or calling party that gets to hear Britney Spears being rendered)? _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 11:22:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZ87-00049c-FQ; Fri, 10 Nov 2006 11:21:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZ85-00049T-Iy for sipping@ietf.org; Fri, 10 Nov 2006 11:21:21 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIPK-0006zL-6U for sipping@ietf.org; Thu, 09 Nov 2006 17:30:02 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiIBI-00033y-W1 for sipping@ietf.org; Thu, 09 Nov 2006 17:15:34 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA9MFUi01312; Thu, 9 Nov 2006 17:15:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Date: Thu, 9 Nov 2006 16:15:29 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371116254B6@zrc2hxm2.corp.nortel.com> In-Reply-To: <71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) Thread-Index: AccERLl2knD6fFBeSmGpNpFAwlqNdAAAdg7A From: "Brian Stucker" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think we're getting off-track here. Let me reboot this thread... There was a comment made on the list about nobody using Alert-Info. Paul K. brought up a use and I brought up a use that we've both seen as a counter-point to show that people do actually use Alert-Info. In the usage that I have seen the problem that the Alert-Info was being used to solve was to denote a network/client coordinated alerting pattern. The network knew about what the client supported, and had previously coordinated a set of values to tell the terminating client to use alert pattern X versus alert pattern Y. The recommendation proposed is that in these cases the Alert-Info use a separate namespace in cases where the proxy inserting the Alert-Info is colluding with the UAS that will receive it in order to render an alert tone that is stored on the UAS. Regards, Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Thursday, November 09, 2006 1:18 PM > To: Stucker, Brian (RICH1:AR00) > Cc: sipping > Subject: Re: Utility of Alert-Info (was: Re: [Sipping]=20 > draft-stucker-sipping-early-media-coping) >=20 > I'm unclear how this could work, unless we define some global=20 > registry of ring tones, which seems utterly impractical. >=20 > On Nov 9, 2006, at 11:29 AM, Brian Stucker wrote: >=20 > > I would also agree. > > > > I wasn't proposing anything earlier, just stating an=20 > observed behavior=20 > > (ala SIPit reports). I can make a recommendation in the early media=20 > > draft though around this area. > > > > Regards, > > Brian > > >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 12:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiabY-0002Fb-VY; Fri, 10 Nov 2006 12:55:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiabY-0002FV-7h for sipping@ietf.org; Fri, 10 Nov 2006 12:55:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiabS-0007I6-OX for sipping@ietf.org; Fri, 10 Nov 2006 12:55:52 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 09:55:46 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="615205:sNHT69013026" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAAHtkWE012384; Fri, 10 Nov 2006 09:55:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAAHthio006065; Fri, 10 Nov 2006 09:55:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 09:55:43 -0800 Received: from [10.21.92.9] ([10.21.92.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 09:55:42 -0800 Message-ID: <4554BD1D.3070306@cisco.com> Date: Fri, 10 Nov 2006 12:55:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F7E9F.3030403@cisco.com> <34639103-DCC4-4F42-A0B3-DEAB03B1305C@cisco.com> In-Reply-To: <34639103-DCC4-4F42-A0B3-DEAB03B1305C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2006 17:55:42.0562 (UTC) FILETIME=[70926420:01C704F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2443; t=1163181346; x=1164045346; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=09[Sippin g]=09draft-stucker-sipping-early-media-coping) |Sender:=20; bh=iHPkIHrCsvkVKG2EE5ysbMjig/zWe20laAT0X8EiY1s=; b=eOKGy9YuyYPFwtdlD85jE2g972eStKTq30achocCP1BiAr97ZLNvck4ghehpiergbi+uX+bS roCMDpt75uJk4cVSipcVOvp379KXH0knqfJpe/Hco7okRucWA8oIxgZ4; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Brian Stucker , sipping , Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There are two usages of Alert-Info that are being conflated in comments here: - in a request, where it influences the alerting / ring tones - in a response, where it influences the ringback. Most of the discussions apply to both, but lets keep in mind that they are different. Certainly the use cases are different. (When I call France I might expect to hear a French ringback, but the callee probably doesn't expect to get an American ring tone.) A key thing about Alert-Info is that it is advisory. There is no obligation for the recipient to honor it. So one possible usage would be for UASs to include an Alert-Info in responses to suggest a ringback. By default it could be either omitted, or set to a country-specific ringback URN. Potentially the UAS could be customized to include some arbitrary URI, such as a reference to the latest Britney song. When it gets to the UAC, it can play it or not. One possibility is to play it if it is a URN that is known to the UAC and otherwise ignore. That would solve Dean's problem. An alternative policy is for the a proxy in the network to do call screening for the UA. It can remove all incoming Alert-Info values, or it might allow them from some sources, or it might allow certain values and refuse others. It also might insert Alert-Info values itself based on some policy. In this case the UA could be configured to attempt to honor any incoming Alert-Info that arrives via the screening proxy. Paul Cullen Jennings wrote: > > If you want a list of the tones - you might check out the draft I did a > long time ago ... > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping-midi.html > > > If you think that it would be a good idea that when I phone country X, I > get a tone that I can recognize as busy or ringing , well I agree with > you but all research of what users wants and what companies want to > build seems to disagree with you. > > > On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: > >> >> On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: >> >>> I think it would be far better to define a URN namespace for >>> ringtones and use local configuration to map those to specific files. >>> What you are proposing will only work in the most closed and >>> homogeneous environments. >>> >> >> Absolutely. I think this is a GREAT idea. >> >> -- >> Dean > > _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 13:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gib14-0002YK-O6; Fri, 10 Nov 2006 13:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gib13-0002YB-6a for sipping@ietf.org; Fri, 10 Nov 2006 13:22:13 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gib11-0003Ld-Vg for sipping@ietf.org; Fri, 10 Nov 2006 13:22:13 -0500 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 13:22:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Fri, 10 Nov 2006 13:22:10 -0500 Message-ID: <77BD870EA838FC469FDD2AE248B1357B01788E59@ATL1VEXC008.usdom003.tco.tc> In-Reply-To: <014001c704dc$d9ec80a0$3801a8c0@newportnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Thread-Index: AccE3Nb+HLP7xIXFQMuRB4/tryp6XgAAkpDQ From: "Brett Tate" To: "Siddhartha Bhakta" X-OriginalArrivalTime: 10 Nov 2006 18:22:07.0983 (UTC) FILETIME=[218E6FF0:01C704F5] X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > I am discussing sec 2.9, where Alice is sending=20 > single INVITE(F1) but it is receiving 1xx with=20 > different to-tags. Now the question is that,=20 > whether single INVITE can result into multiple=20 > dialogs?=20 I'm not positive what you mean by "single INVITE". However the answer is yes for both forking and "virtual" forking situations. > I thought that forking proxy shall manage all=20 > the forked dialogs and select one dialog as=20 > the best dialog and pass response downstream=20 > for that dialog only. That way Alice shall=20 > only see single dialog where proxy shall manage=20 > two forked dialog in this example. The example results in 3 early dialogs. Prior to the RFCs which imposed various offer/answer restrictions, a B2BUA could do something similar to what you are suggesting (with some limitations). RFC 3261 section 16.7 discusses what a proxy should do if it wants to generate a non-100 provisional response. "1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response. Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the request to a UAS sharing the same element as the proxy. This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS does not have to be a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as the proxy." I do not have a strong opinion concerning the sending of 181 (without SDP) when the proxy has received the 487 response. There are 3 options; however only option 1 is compliant with rfc3261. 1) Follow service example and add new To tag. This is the only rfc3261 compliant solution. 2) Use the To tag of the received failure response. This is non complaint to rfc3261 and requires waiting for the 487. The reason that it might be nice is because allowing this to be valid would easily allow a new 1xx response code to be sent by a forking proxy to indicate when a particular early dialog no longer exists. However there are definitely other ways to solve that problem. 3) Send non-100 1xx responses without To tag. This provides extra ambiguity; and this is especially true when multiple forking proxies are involved. And it is non compliant to rfc3261. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 13:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibIl-0006Qv-LP; Fri, 10 Nov 2006 13:40:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibIf-0006G3-PI for sipping@ietf.org; Fri, 10 Nov 2006 13:40:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibII-0005VZ-MB for sipping@ietf.org; Fri, 10 Nov 2006 13:40:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2006 10:40:02 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="342607960:sNHT101818284" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAAIe19D002608; Fri, 10 Nov 2006 10:40:01 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAAIe1io008976; Fri, 10 Nov 2006 10:40:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 10:40:00 -0800 Received: from [10.21.92.9] ([10.21.92.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 10:40:00 -0800 Message-ID: <4554C77F.7020300@cisco.com> Date: Fri, 10 Nov 2006 13:39:59 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Gunnar Hellstrom Subject: Re: SV: Utility of Alert-Info (was:Re: [Sipping] draft-stucker-sipping-early-media-coping) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2006 18:40:00.0331 (UTC) FILETIME=[A0B9C1B0:01C704F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2712; t=1163184001; x=1164048001; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20SV=3A=20Utility=20of=20Alert-Info=20(was=3ARe=3A=09[S ipping]=09draft-stucker-sipping-early-media-coping) |Sender:=20; bh=CriZb0j3AYOcqcrqPjnvGRDZCzs188MVfN1J3htOp4Q=; b=j62mDkfwmSqhpL52QzTKRGS9U1hVCGId7PhgAPqa2+gdi0e6gMHDIh5tm84naiaRm59DuG9q 9gLrqrVWC+MMrG0mfHTV0LCJYTbaEBvvCO+Bu4e3zsokDp1ubyx0agkq; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Cullen Jennings , Brian Stucker , sipping , Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org The thing referenced by an Alert-Info can have any kind of alerting behavior. For instance, it ultimately could be a multipart mime body with audio, video, and other kinds of material. Then the UA can choose which of these to render. If URNs are used, then each UA can have its own mapping from the URN to the actual alerting mechanism. That provides a mechanism to have a generic set of alerts that are expected to be distinguishable from one another, while still accommodating the environmental, etc. needs of individual users. Paul Gunnar Hellstrom wrote: > If this discussion will lead to an enhanced definition of alerting, please > then remember to include not only that the tone characteristics should be > configurable, but also the mode of alerting. > > -Audible - Ring tones etc according to current discussion. > -Visual - Flashing lights, flashing screen. > -Tactile - Pocket vibration, watch vibration, handset vibration. > > In many cases the selection can be made from preferences in a user profile, > while in other cases it is the environment that influences what mode to use. > ( e.g. flashing light in very noisy industry area ) > > Gunnar > > -----Ursprungligt meddelande----- > Fran: Cullen Jennings [mailto:fluffy@cisco.com] > Skickat: den 10 november 2006 04:35 > Till: Dean Willis > Kopia: Paul Kyzivat; sipping; Brian Stucker > Amne: Re: Utility of Alert-Info (was:Re: [Sipping] > draft-stucker-sipping-early-media-coping) > > > > If you want a list of the tones - you might check out the draft I did > a long time ago ... > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- > midi.html > > If you think that it would be a good idea that when I phone country > X, I get a tone that I can recognize as busy or ringing , well I > agree with you but all research of what users wants and what > companies want to build seems to disagree with you. > > > On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: > >> On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: >> >>> I think it would be far better to define a URN namespace for >>> ringtones and use local configuration to map those to specific >>> files. What you are proposing will only work in the most closed >>> and homogeneous environments. >>> >> Absolutely. I think this is a GREAT idea. >> >> -- >> Dean > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 14:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibgP-0006Jx-Pj; Fri, 10 Nov 2006 14:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibgN-0006Jl-S0 for sipping@ietf.org; Fri, 10 Nov 2006 14:04:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GibgM-00021x-GI for sipping@ietf.org; Fri, 10 Nov 2006 14:04:55 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 11:04:54 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="682714:sNHT57865536" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAAJ4rqG002775; Fri, 10 Nov 2006 11:04:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAAJ4rin016891; Fri, 10 Nov 2006 11:04:53 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:04:53 -0800 Received: from [10.21.92.9] ([10.21.92.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:04:53 -0800 Message-ID: <4554CD54.1080309@cisco.com> Date: Fri, 10 Nov 2006 14:04:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> In-Reply-To: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Nov 2006 19:04:53.0169 (UTC) FILETIME=[1A86C210:01C704FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3444; t=1163185493; x=1164049493; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:=20; bh=I8+4QKzBVBnewJsopNrAcOWhX5UeOm2f6FOT4ohogCQ=; b=o7/2V37njtnok92g7ojieVJjbuYoYOlCww62OZwQKNxhJTAeMDEno6XQgrSdHG8XawiZhsv9 tJMiNTvYc+am1bMrwOb9sF5Lg9b95hH4TcL7arZlFYMrj1B0Bx1xm/gP; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org The kind of change you describe is in fact a normative change. To get such a change made, you will have to explain why there is currently a problem that needs fixing. I don't think you have a case for that. The bookkeeping to manage the multiple dialogs is currently already required for forking, so no added implementation is required. At worst it requires a little extra storage for state retention in some cases where the proposed change might avoid that. Note that in case of forking it is necessary to retain early dialogs until a final response is received. If the final result is failure then the UA can immediately drop all the dialogs. If the result is success, then the other dialogs need to be retained long enough for any other 2xx responses in transit to arrive. Paul Siddhartha Bhakta wrote: > Thomas’s suggestion sounds good. If forking proxy needs to pass 18x > downstream, it should NOT put to-tag. > > However, that shall put the restriction that PRACK can not be sent for > that 18x messages since PRACK can only be sent over established dialog. > If 18x response does not contain to-tag, it can not create dialog. > > > > That may be worth bet compared to all dialog related mess up in this case. > > > > Best regards, > > Siddhartha > > > > Date: Fri, 10 Nov 2006 16:30:55 +0100 > > From: Thomas.Froment@alcatel.fr > > Subject: Re: [Sipping] Query related to > > draft-ietf-sipping-service-examples-11 > > To: Dale.Worley@comcast.net > > Cc: sipping@ietf.org > > Message-ID: <45549B2F.9050709@alcatel.fr> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Dale.Worley@comcast.net wrote: > >> From: Thomas.Froment@alcatel.fr > >> > >> I agree with that point, it is particularly tricky for UAs > >> implementations to receive a first 1xx with a toTag, and then, and > >> 200 OK with another one... > >> > >> How could a UA support forking generally and not handle this case > >> smoothly? > >> > > Theoritically, you are right :-), in practice, after 5 SIPIT, forking is > not always so well supported by UAs (and proxies, by the way), probably > because this is complex to implement... I still think that a proxy > "muted temporarily" to a UAS is something unecesssary complex, it could > be possible to say that a proxy sending 1xx reponses should NOT put any > totag, (as for 100 trying)... So easy to say, so easy to implement... > > > > Best regards, > > Thomas > > > > > > ------------------------------------------------------------------------ > --------------- > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the contents in this > e-mail is strictly forbidden. > --------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 14:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0N-0002vn-AZ; Fri, 10 Nov 2006 14:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic0L-0002tk-Ur for sipping@ietf.org; Fri, 10 Nov 2006 14:25:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gibyz-0004PW-KB for sipping@ietf.org; Fri, 10 Nov 2006 14:24:13 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 11:24:09 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="700313:sNHT170430894" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAAJO9sn029223; Fri, 10 Nov 2006 11:24:09 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAAJO8W4013402; Fri, 10 Nov 2006 11:24:08 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:24:08 -0800 Received: from [10.21.92.9] ([10.21.92.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 11:24:08 -0800 Message-ID: <4554D1D7.7020007@cisco.com> Date: Fri, 10 Nov 2006 14:24:07 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sipping] draft-ietf-sipping-service-examples-11.txt and my review of draft-ietf-sipping-service-examples-10.txt References: <200611100433.kAA4XvJN026527@dragon.ariadne.com> In-Reply-To: <200611100433.kAA4XvJN026527@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2006 19:24:08.0292 (UTC) FILETIME=[CB088A40:01C704FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1693; t=1163186649; x=1164050649; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20draft-ietf-sipping-service-examples-11.tx t=20and=20my=20review=0A=20of=20draft-ietf-sipping-service-examples-10.txt |Sender:=20; bh=WLbj8uZN3e8EEAxNKcFTJZvJm9zo0YMCetn5j7PmvR4=; b=nKNnTWfgdX+rZJxSAwHTrmSo6MCWoybG09XiK/yJz/eN5yG5w1A0Wqai6NlJax9M/fI3G2et DBnVPZyyAe4jB20uSsPa2nuHKG7/EkmhC6iIO53/9Yc4aAv4InvXJTdi; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sipping@ietf.org, Mary Barnes , Gonzalo Camarillo X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Dale.Worley@comcast.net wrote: > I've compared my review of draft-ietf-sipping-service-examples-10.txt > with draft-ietf-sipping-service-examples-11.txt and have the following > comments: > >> * Header line breaking >> >> While the grammar of RFC 3261 section 25.1 allows header values to be >> broken at most delimiters, it does not allow URIs to be broken. > > # I have fixed this by using the tag defined in RFC 4475. > > This fix is good, but it's not quite complete. In regard to > whitespace around the point of the break, RFC 4475 says: > > Several of these examples contain unfolded lines longer than 72 > characters. These are captured between tags. The > single unfolded line is reconstructed by directly concatenating all > lines appearing between the tags (discarding any line feeds or > carriage returns). There will be no whitespace at the end of lines. > Any whitespace appearing at a fold-point will appear at the beginning > of a line. > > (The final phrase "at the beginning of a line" implicitly refers to > the left margin established by the surrounding text.) I've struggled with this myself and decided to add in my own language making this implicit assumption explicit. I've wondered if we need a better convention for this - one that is among the common policies for drafts and RFCs rather than being something specific to a few sip drafts. Frankly, for readability I would rather that all the whitespace adjacent to the fold (both preceding and following) be removed. But that would require some other convention for inserting whitespace in such a case. Paul _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 14:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic5m-00054a-35; Fri, 10 Nov 2006 14:31:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gic13-0003Bh-RN for sipping@ietf.org; Fri, 10 Nov 2006 14:26:17 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giboh-0003DD-2x for sipping@ietf.org; Fri, 10 Nov 2006 14:13:37 -0500 Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAAJDVHu030811; Fri, 10 Nov 2006 20:13:31 +0100 Received: from [127.0.0.1] ([155.132.188.76]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006111020132533:10478 ; Fri, 10 Nov 2006 20:13:25 +0100 Message-ID: <4554CF49.5020804@alcatel.fr> Date: Fri, 10 Nov 2006 20:13:13 +0100 From: Thomas.Froment@alcatel.fr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> <4554CD54.1080309@cisco.com> In-Reply-To: <4554CD54.1080309@cisco.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 20:13:25, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/10/2006 20:13:26, Serialize complete at 11/10/2006 20:13:26 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 1.3 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Paul Kyzivat wrote: > The kind of change you describe is in fact a normative change. To get > such a change made, you will have to explain why there is currently a > problem that needs fixing. I don't think you have a case for that. > > The bookkeeping to manage the multiple dialogs is currently already > required for forking, so no added implementation is required. In that case, why not completely deprecate forking itself? .. just kidding ^_^... _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 23:33:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GikVS-00076g-Pg; Fri, 10 Nov 2006 23:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GikVR-00076Z-GS for sipping@ietf.org; Fri, 10 Nov 2006 23:30:13 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GikVQ-0006E4-9p for sipping@ietf.org; Fri, 10 Nov 2006 23:30:13 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061111043011b1100fkb1de>; Sat, 11 Nov 2006 04:30:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAB4UAQg027503 for ; Fri, 10 Nov 2006 23:30:10 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAB4UAK6027498; Fri, 10 Nov 2006 23:30:10 -0500 Date: Fri, 10 Nov 2006 23:30:10 -0500 Message-Id: <200611110430.kAB4UAK6027498@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4554CF49.5020804@alcatel.fr> (Thomas.Froment@alcatel.fr) Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> <4554CD54.1080309@cisco.com> <4554CF49.5020804@alcatel.fr> X-Spam-Score: 1.4 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: Thomas.Froment@alcatel.fr > The bookkeeping to manage the multiple dialogs is currently already > required for forking, so no added implementation is required. In that case, why not completely deprecate forking itself? Heh -- you know that has been seriously proposed. But like jumping a chasm, it's not something to be done by halves. Until you actually eliminate forking, you can't twiddle the parts of the protocol that are needed to cope with forking. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 10 23:36:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GikbX-0000Ah-JZ; Fri, 10 Nov 2006 23:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GikbW-00009H-88 for sipping@ietf.org; Fri, 10 Nov 2006 23:36:30 -0500 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GikbV-00073c-09 for sipping@ietf.org; Fri, 10 Nov 2006 23:36:30 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20061111043622m14001csfre>; Sat, 11 Nov 2006 04:36:28 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAB4aLQg027632 for ; Fri, 10 Nov 2006 23:36:21 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAB4aLP1027628; Fri, 10 Nov 2006 23:36:21 -0500 Date: Fri, 10 Nov 2006 23:36:21 -0500 Message-Id: <200611110436.kAB4aLP1027628@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <77BD870EA838FC469FDD2AE248B1357B01788E59@ATL1VEXC008.usdom003.tco.tc> (brett@broadsoft.com) Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <77BD870EA838FC469FDD2AE248B1357B01788E59@ATL1VEXC008.usdom003.tco.tc> X-Spam-Score: 1.4 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: "Brett Tate" 2) Use the To tag of the received failure response. This is non complaint to rfc3261 and requires waiting for the 487. The reason that it might be nice is because allowing this to be valid would easily allow a new 1xx response code to be sent by a forking proxy to indicate when a particular early dialog no longer exists. However there are definitely other ways to solve that problem. Well, I think that there is no way for the UAC to discover that the proxy is faking it, as the UAS could have sent a 1xx followed by the 487, but the network reordered the responses. So this scenario is not visibly different from RFC 3261 compliance. But there are still problems: One you mention is that the 1xx can't be sent until the 487 is received by the proxy, so no time is gained -- the proxy might as well send the 487 on to indicate that the early dialog is ended. The other is that the 1xx isn't reliably delivered, and so it can only be used for advisory information, limiting the value of such a device. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 11 06:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiqoN-0001nF-78; Sat, 11 Nov 2006 06:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiqoM-0001nA-72 for sipping@ietf.org; Sat, 11 Nov 2006 06:14:10 -0500 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiqoG-0007uN-TE for sipping@ietf.org; Sat, 11 Nov 2006 06:14:10 -0500 Received: from Inbox ([89.205.152.190]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J8K00AF8F0M4020@jes-fe1.zx.nl> for sipping@ietf.org; Sat, 11 Nov 2006 12:07:45 +0000 (GMT) Date: Sat, 11 Nov 2006 12:13:50 +0100 From: Jeroen Van Bemmel Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Paul Kyzivat , Siddhartha Bhakta Message-id: <0J8K00AF9F0N4020@jes-fe1.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 2.3 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There is another way around this: Since the 181 does not contain a Contact,= the UAC can safely ignore it. This does violate RFC3261 section 12.1.1, which says dialog creating respon= ses MUST contain a Contact Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Paul Kyzivat" Aan: "Siddhartha Bhakta" CC: sipping@ietf.org Verzonden: 10-11-06 20:04 Onderwerp: Re: [Sipping] Query related to draft-ietf-sipping-service-exampl= es-11 The kind of change you describe is in fact a normative change. To get=20 such a change made, you will have to explain why there is currently a=20 problem that needs fixing. I don't think you have a case for that. The bookkeeping to manage the multiple dialogs is currently already=20 required for forking, so no added implementation is required. At worst=20 it requires a little extra storage for state retention in some cases=20 where the proposed change might avoid that. Note that in case of forking it is necessary to retain early dialogs=20 until a final response is received. If the final result is failure then=20 the UA can immediately drop all the dialogs. If the result is success,=20 then the other dialogs need to be retained long enough for any other 2xx=20 responses in transit to arrive. Paul Siddhartha Bhakta wrote: > Thomas=92s suggestion sounds good. If forking proxy needs to pass 18x=20 > downstream, it should NOT put to-tag. >=20 > However, that shall put the restriction that PRACK can not be sent for=20 > that 18x messages since PRACK can only be sent over established dialog.=20 > If 18x response does not contain to-tag, it can not create dialog. >=20 > =20 _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 11 15:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gizfd-00080o-Vh; Sat, 11 Nov 2006 15:41:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gizfb-00080i-Ps for sipping@ietf.org; Sat, 11 Nov 2006 15:41:43 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.ygnition.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GizfZ-0008RB-CW for sipping@ietf.org; Sat, 11 Nov 2006 15:41:43 -0500 Received: from SSPRUNK (ip25.post-vineyard.dfw.ygnition.net [24.219.179.25]) by ns2.ygnition.com (8.13.6/8.13.5) with SMTP id kABKfWRG017380; Sat, 11 Nov 2006 15:41:37 -0500 Message-ID: <01c901c705d1$c7cea1a0$6701a8c0@atlanta.polycom.com> From: "Stephen Sprunk" To: "Paul Kyzivat" , "Gunnar Hellstrom" References: <4554C77F.7020300@cisco.com> Date: Sat, 11 Nov 2006 14:34:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Dean Willis , sipping , Brian Stucker Subject: [Sipping] Re: SV: Utility of Alert-Info X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thus spake "Paul Kyzivat" > The thing referenced by an Alert-Info can have any kind of alerting > behavior. For instance, it ultimately could be a multipart mime body > with audio, video, and other kinds of material. Then the UA can choose > which of these to render. That's clever... > If URNs are used, then each UA can have its own mapping from the > URN to the actual alerting mechanism. That provides a mechanism to > have a generic set of alerts that are expected to be distinguishable > from one another, while still accommodating the environmental, etc. > needs of individual users. This is already done to an extent today, though not with URNs. There are a number of vendors that send us something like: Alert-Info: http://127.0.0.1/Bellcore-dr2 Exactly what we do with that is up to the receiver; in our case, the user is allowed to decide what "Distinctive Ring #2" sounds/looks like. In fact, this has been the standard mechanism we've been seeing for several years. It's only recently that some folks have started sending us real URIs (SP-controlled custom ringtones); the problem with that is being sure the UA is capable of playing the media format referenced. What if you send a URI for an WMA file to a UA that's only capable of playing MP3 or WAV files? Multipart might help solve that as well. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 11 16:18:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0DX-0000pU-8m; Sat, 11 Nov 2006 16:16:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj0DV-0000pF-5i for sipping@ietf.org; Sat, 11 Nov 2006 16:16:45 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.ygnition.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj0DS-0003qn-MQ for sipping@ietf.org; Sat, 11 Nov 2006 16:16:45 -0500 Received: from SSPRUNK (ip25.post-vineyard.dfw.ygnition.net [24.219.179.25]) by ns2.ygnition.com (8.13.6/8.13.5) with SMTP id kABL1FWG017403; Sat, 11 Nov 2006 16:01:16 -0500 Message-ID: <000401c705d4$86bd7f80$6701a8c0@atlanta.polycom.com> From: "Stephen Sprunk" To: "Dean Willis" , "Henning Schulzrinne" References: <6FC4416DDE56C44DA0AEE67BC7CA4371116250CB@zrc2hxm2.corp.nortel.com><71C12E67-507E-4D60-B72D-4018E4C271DC@cs.columbia.edu> <08D5AA48-9AC8-48AF-872B-3471DBFAF255@softarmor.com> Date: Sat, 11 Nov 2006 14:58:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sipping , Brian Stucker Subject: [Sipping] Re: Utility of Alert-Info X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thus spake "Dean Willis" > I would think a global registry of national-standard ring tones would > be reasonably practical. I generally wouldn't care all that much is > somebody wanted me to hear a French ring-back when I call them. URNs for standard national ringback/ringtone would be nice, and it'd get rid of the need for a lot of early media streams, since that what most of them are today. > What I don't really want is to go download (esp. at time of use) the > latest Britney Spears MP3 just so I can hear it play while I'm > waiting on my niece to answer the phone. Unfortunately, there appear to be a large number of consumers willing to pay to force you to listen to Britney when you call them. It's "cool", and a big source of revenue for the SP. More recently, I'm running into businesses that have their ringback set to play Muzak or advertisements. Grrr. Yes, you could try to block that by ignoring Alert-Info headers, but for now those CRBTs are coming in via early media, not Alert-Info. To stop them, you'd have to ignore all early media, which is not viable since there are a large number of 1-800 IVR systems that require acceptance of early media to function correctly -- users won't consider not being able to call their bank or airline to be a viable trade-off for blocking annoying-but-harmless CRBTs. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 11 18:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2ES-0004I5-JB; Sat, 11 Nov 2006 18:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj2EQ-0004FC-Kl for sipping@ietf.org; Sat, 11 Nov 2006 18:25:50 -0500 Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj2EP-0005Od-6F for sipping@ietf.org; Sat, 11 Nov 2006 18:25:50 -0500 Received: from zanxmb00b.cc-ntd1.covad.com (zanxmb00b.corp.covad.com [172.16.2.76]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id PAA15884 for ; Sat, 11 Nov 2006 15:25:48 -0800 (PST) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.84]) by zanxmb00b.cc-ntd1.covad.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 15:25:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 11 Nov 2006 15:25:48 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-malas-performance-metrics-05.txt Thread-Index: AccFCtMfhlh9tMHqQVekBZ43AQCR6wAADCTAADdksWA= From: "Fardid, Reza" To: X-OriginalArrivalTime: 11 Nov 2006 23:25:48.0396 (UTC) FILETIME=[B82E92C0:01C705E8] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.6.1039-14806.000 X-TM-AS-Result: No--11.798800-0.000000-31 X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Subject: [Sipping] Comments on draft-malas-performance-metrics-05.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0402296669==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0402296669== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C705E8.B83F1948" This is a multi-part message in MIME format. ------_=_NextPart_001_01C705E8.B83F1948 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Daryl, =20 Here are a few comments on this draft, based on a first pass through it: =20 1. Introduction =20 I would add User Behavior as another factor that can affect measurements of some of the metrics. =20 3. SIP Performance Metrics =20 If User Behavior MAY affect measurements of a metric, then it MUST be noted for each defined metric. =20 3.5 Session Establishment Ratio (SER) =20 I suggest referencing ITU-T E.411 for the telephony definition of ASR, unless GR-512-CORE includes it. 3.11 (or 3.5.1) Session Establishment Efficiency Ratio (SEER): proposed as a new metric, unless it can be derived from currently defined metrics =20 This metric is used to provide a better representation of network performance by eliminating user behavior from Session Established Ratio (SER). It is known as Network Efficiency Ratio (NER) in telephony applications, and was adopted from the ITU-T E.411 Amendment. =20 The following response codes provide a guideline for this metric: =20 - 480 Temporarily Unavailable - 486 Busy Here - 600 Busy Everywhere =20 SEER % =3D (# of INVITEs w/ associated 200OK + # of 480s + # of 486s + = # of 600s)/(Total # of INVITEs) =20 Regards, Reza Fardid =20 ------_=_NextPart_001_01C705E8.B83F1948 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Daryl,

 

Here are a few comments on this draft, based on a first pass = through it:

 

1. Introduction

 

I would add User Behavior as another factor that can affect measurements of some of the metrics.

 

3. SIP Performance Metrics

 

If User Behavior MAY affect measurements of a metric, then it = MUST be noted for each defined metric.

 

3.5 Session Establishment Ratio (SER)

 

I suggest referencing ITU-T E.411 for the telephony definition = of ASR, unless GR-512-CORE includes it.

3.11 (or 3.5.1) Session Establishment Efficiency Ratio (SEER): = proposed as a new metric, unless it can be derived from currently defined = metrics

 

This metric is used to provide a better representation of = network performance by eliminating user behavior from  Session Established = Ratio (SER). It is known as Network Efficiency Ratio (NER) in telephony = applications, and was adopted from the ITU-T E.411 Amendment.

 

The following response codes provide a guideline for this = metric:

 

-        = ; 480  Temporarily Unavailable

-        = ; 486  Busy Here

-        = ; 600  Busy Everywhere

 

SEER % =3D (# of  INVITEs w/ associated 200OK + # of 480s + = # of 486s + # of 600s)/(Total # of INVITEs)

 

Regards,

Reza Fardid

 

------_=_NextPart_001_01C705E8.B83F1948-- --===============0402296669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0402296669==-- From sipping-bounces@ietf.org Sun Nov 12 07:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjEG3-0005tl-O0; Sun, 12 Nov 2006 07:16:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjEG2-0005td-Dq for sipping@ietf.org; Sun, 12 Nov 2006 07:16:18 -0500 Received: from web8705.mail.in.yahoo.com ([203.84.221.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjEG0-0002Xf-Mx for sipping@ietf.org; Sun, 12 Nov 2006 07:16:18 -0500 Received: (qmail 33159 invoked by uid 60001); 12 Nov 2006 12:13:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tL7DIiGeVMcDaXf1H3cnijHZcOB6BmCweOyug7OHIo74pcB/6KrTEeBXzFZ9HI3jw+aaODcdhhyq5ZdMDbQ5Enjnwmq7XDqdt2O0dAEpNiep14LESBQco3rzShh8j/MLu683bChHnh8dF6VcHXifKX1bA6q3X8Zb4L3N3LzGrhg= ; Message-ID: <20061112121346.33157.qmail@web8705.mail.in.yahoo.com> Received: from [172.203.17.209] by web8705.mail.in.yahoo.com via HTTP; Sun, 12 Nov 2006 12:13:46 GMT Date: Sun, 12 Nov 2006 12:13:46 +0000 (GMT) From: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Paul Kyzivat In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Dear paul, The forking and virtual forking case are quite different. In forking case, each of the dialogs are managed separately. All these forked dialogs are terminated properly. Either calling side cancels it or called side reject it by sending 3xx-6xx responses. For for virtual forking case, SIP entity creates multiple dialogs by receiving multiple to-tags in multiple 1xx responses. The management of those dialogs seem peculiar to me. a)3xx-6xx of any such early dialog shall terminate all these dialogs. Therefore, management of such dialogs are not independent to each other. b)Only one of these dialogs is managed properly. I have a question about the longevity about rest of the dilaogs. Neither called side shall reject it nor calling side shall cancel it. It least that's what is seen in sec 2.9 of draft-ietf-sipping-service-examples-11. In sec 2.9 call flow, the F5 creates a dialog-ID1{Local-tag=1234567, remote-tag=3145678, call-id=12345600@atlanta.example.com}. The F10 creates another dialog-ID2{Local-tag=1234567, remote-tag=9214d, call-id=12345600@atlanta.example.com}. Subsequently, F13 creates dialog-ID3{Local-tag=1234567, remote-tag=765432, call-id=12345600@atlanta.example.com}. The dialog-ID3 is being managed properly here. Neither Alice canceling dialog-ID1 & dialog-ID2 nor Alice is getting 3xx-6xx for dialog-ID1 & dialog-ID2. What is the fate of dialog-ID1 & dialog-ID2? Will they be timed-out? The above two points clearly indicates that for virtual forking case, only one dialog should be created since only one of them are being managed properly. Hence the suggestion is to drop to-tag from 1xx response for those cases. The first 2xx shall create the dialog. For forking case, I don't have any objection since each of the dialogs is managed properly. In sec 2.9, forking proxy creates dialog-ID1{Local-tag=1234567, remote-tag=3145678, call-id=12345600@atlanta.example.com} with User B1 and creates dialog-ID2{Local-tag=1234567, remote-tag=765432, call-id=12345600@atlanta.example.com} with user B2. This dialog-ID1 is cancelled by sending CANCEL(F6) and dialog-ID2 is being continued. The dialog-ID2 is later terminated by BYE(F19) message. In summery, for virtual forking case, single dialog should be created and managed. Therefore, forking proxy should drop to-tag while passing 1xx response downatream. Or the alternative approach could be that, forking proxy needs to send 3xx-6xx response for all early dialogs those are not being continued. This way, for dialogs shall be managed properly in virtual forking case also. Please comment. Paul Kyzivat wrote: >The kind of change you describe is in fact a >normative change. To get >such a change made, you will have to explain why >there is currently a >problem that needs fixing. I don't think you have a >case for that. >The bookkeeping to manage the multiple dialogs is >currently already >required for forking, so no added implementation is >required. At worst >it requires a little extra storage for state >retention in some cases >where the proposed change might avoid that. >Note that in case of forking it is necessary to >retain early dialogs >until a final response is received. If the final >result is failure then >the UA can immediately drop all the dialogs. If the >result is success, >then the other dialogs need to be retained long >enough for any other >2xx >responses in transit to arrive. Paul __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 11:53:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjIXz-0007pq-CZ; Sun, 12 Nov 2006 11:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjIXx-0007pL-JP for sipping@ietf.org; Sun, 12 Nov 2006 11:51:05 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjIXv-0008Nx-9O for sipping@ietf.org; Sun, 12 Nov 2006 11:51:04 -0500 Received: (qmail 7409 invoked by uid 0); 12 Nov 2006 16:50:46 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 12 Nov 2006 16:50:46 -0000 Message-ID: <002401c7067a$b9222d30$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brett Tate" , "Siddhartha Bhakta" References: <77BD870EA838FC469FDD2AE248B1357B01788E59@ATL1VEXC008.usdom003.tco.tc> Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Sun, 12 Nov 2006 17:50:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > I do not have a strong opinion concerning the sending of 181 (without > SDP) when the proxy has received the 487 response. There are 3 > options; however only option 1 is compliant with rfc3261. > > 1) Follow service example and add new To tag. This is the only > rfc3261 compliant solution. > As I wrote in a separate response, if we were to combine this with the proxy not inserting a Contact, and have the UAC interpret that as "does not want to continue with this dialog" (or at least "can safely postpone creating an early dialog until a next response with a valid Contact arrives"), we could have ourselves a workable solution. Jeroen _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 12:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjJTx-0007Ct-34; Sun, 12 Nov 2006 12:51:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjJTt-0007Aw-Rp for sipping@ietf.org; Sun, 12 Nov 2006 12:50:57 -0500 Received: from web8701.mail.in.yahoo.com ([203.84.221.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjJTS-0002yA-Fm for sipping@ietf.org; Sun, 12 Nov 2006 12:50:35 -0500 Received: (qmail 49092 invoked by uid 60001); 12 Nov 2006 17:50:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DsrGvrRxlWOMLbCuE8qPlSQliwfB/ExH8KN3VZ5Owh01EbKOyBu+BLoa/Fjg8dwzH8f97UXixuDuLZ5mRB+LYCFKLePzYreaE9wBHcD3bg9AeUM6ZDN2mSoOMsXLzkL4YYkqPkSOebLEhza7xxbM05PQP2BUdSmAlbpf6jJjr+w= ; Message-ID: <20061112175028.49090.qmail@web8701.mail.in.yahoo.com> Received: from [172.143.204.234] by web8701.mail.in.yahoo.com via HTTP; Sun, 12 Nov 2006 17:50:28 GMT Date: Sun, 12 Nov 2006 17:50:28 +0000 (GMT) From: Siddhartha Bhakta Subject: [SIPPING] SDP Rollback in draft-sawada-sipping-sip-offeranswer-01.txt To: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, I am not sure (as I am a very new user to SIPPING group) whether SDP rollback has ever been discussed regarding this draft or not. I personally feel that 'SDP rollback' is very relevent topics regarding this draft. The sec 1.2 indicates the response(488) to reject any SDP offer. But the missing part is that if any SIP request carrying SDP offer is rejected by 3xx-6xx then SDP offer should be rolled-back. The rollback means, applying last session description. Rather than specifying different SIP messages separately, it would be better to have some thumb rule that shall be quite easy to follow as far as SDP rollback is concerned. I am proposing following thumb rule. Please indicate whether that make sense or not. The SDP rollback shall be associated with transaction rollback/rejection. [1] If the transaction request (carrying SDP offer) is rejected then SDP offer shall be rolled-back. The exception is the ACK request. The ACK (of 2xx) can not be rejected. (The ACK of 3xx-6xx is not the transaction initiating request). [2] If any transaction request carries SDP answer (e.g., ACK or PRACK) then that transaction can not rejected as there shall be the confusion over whether SDP shall be rolled-back or not. I suppose, SDP answer can not be rolled-back. There is no confusion for ACK, as it can not rejected but for PRACK the restriction should be there that it can not be rejected if it carries SDP answer. This draft says that PRACK(irrespective of whether it is carrying SDP offer/answer) can not be rejected. I can not understand the rationale about this statement. Though, I can appreciate why PRACK MUST not be rejected it it carries SDP answer. [3] If any SIP response contains SDP offer then that SDP can not be rolled-back. If any SIP entity wants to rollback the SDP offer carried by SIP response, it should initiate a SIP transaction carrying old SDP to accomplish it. There is a special case for re-INVITE. If multiple SDP offer/answer happens(using PRACK/UPDATE) within re-INVITE transaction and re-INVITE is rejected by 4xx-6xx then whether all the SDP offer/answer happens within re-INVITE transaction shall be rolled-back or not. My suggestion would be that once SDP offer/answer is completed, that can not rolled-back by means of transaction rejection. That means, all the completed SDP offer/answer shall not be rolled-back due to 4xx-6xx of re-INVITE. This decision shall save the work of SIP UA, SIP SBC, B2BUA etc. that follows SDP offer/answer state. Please comment. Thanks and Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 14:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKcW-0006kN-4T; Sun, 12 Nov 2006 14:03:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKcU-0006jv-Fy for sipping@ietf.org; Sun, 12 Nov 2006 14:03:54 -0500 Received: from web8702.mail.in.yahoo.com ([203.84.221.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjKcR-0008UX-QA for sipping@ietf.org; Sun, 12 Nov 2006 14:03:54 -0500 Received: (qmail 87112 invoked by uid 60001); 12 Nov 2006 19:03:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qtCtLwDMBuwPOELQ/5+QJ5Yj8TZp0rPBQabieHWy9H/PsCaO5o48L8ZkU92fjH9okLEQa6DCLCgKVl8qNOTLiinUuRKtdv7MOzXAA327UFcXsIuoQ9AgoFCZ73j1VAJMS50ZxEH/aulBIoPHq5DMBDJQCL/08bN5NsPGP86MzlM= ; Message-ID: <20061112190349.87110.qmail@web8702.mail.in.yahoo.com> Received: from [172.143.204.234] by web8702.mail.in.yahoo.com via HTTP; Sun, 12 Nov 2006 19:03:49 GMT Date: Sun, 12 Nov 2006 19:03:49 +0000 (GMT) From: Siddhartha Bhakta Subject: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt To: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sbhakta007@yahoo.co.in, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, Though, post RFC3261 drafts indicate that one valid answer would be there for one SDP offer, the our old friend early-media flow is still present in practice. B2BUA/SBC Proxy PABX Bob | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 183 F3 |--------------->| INVITE F4 | |<---------------| |--------------->| | | | | | | | 180 without SDP F5 | | |<---------------| | | | | | | 180 with SDP F6 | | 180 F7 |<---------------| | |<---------------| | 200 F8 | | | 200 F9 |<---------------| | 200 F10 |<---------------| | |<---------------| | | | ACK F11 | | | |--------------->| ACK F12 | | | |--------------->| ACK F13 | | | |--------------->| Our B2BUA is facing the problem as specified above. The first answer is carried by F3. This SDP is specified by Proxy. The 2nd SDP answer is carried by F6,F7. In fact, this SDP is specified by PABX. The third SDP answer is carried by F8,F9,F10. This SDP is specified by called party (Bob). As per the RFC3261 & RFC3264, the SDP answer carried by F6,F7 should match with F3 as far as B2BUA is concerned. Therefore, B2BUA shall ignore it. This is leading to the fact that SIP UA behind B2BUA can not listen to ringtone fed by PABX. Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This shall lead to the fact that SIP UA behind B2BUA can not listen to Bob's voice. Too bad. This problem is due to the fact that RFC3261 & RFC3264 are not backward compatible. The sec 2.2. of draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE should be used to update the media in early media. But in practice old early-media flow (i.e., sending different SDPs over different 1xx responses of INVITE) is quite common. Can we somehow make new SDP offer/answer specified in RFC3261 & RFC3264 backward compatible? The old standard (early-media), allows multiple SDP answers of single SDP offer. can we somehow induce this thing in SDP offer/answer model? If many of you think the need of it then I may comeup with some thumb rule for the same. Thanks & regards, Siddhartha Bhakta __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 14:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKjg-0002Mn-Hi; Sun, 12 Nov 2006 14:11:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKjf-0002Mh-GH for sipping@ietf.org; Sun, 12 Nov 2006 14:11:19 -0500 Received: from web8704.mail.in.yahoo.com ([203.84.221.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjKjc-0001Js-RS for sipping@ietf.org; Sun, 12 Nov 2006 14:11:19 -0500 Received: (qmail 98292 invoked by uid 60001); 12 Nov 2006 19:11:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zepSU2vHXiRFQAoZMKHqYp3yz5c3vKU/horEjVWEV/KtL+3UwFT+pT4am8B8E6nOinAORIxq23aiGnrrrpcuf9978NhIh45Zrc2cOwWRecPkL3LaxpQEfhs38/Rj5LjRdZyNdU+O0nO2H0cg5tT4jymx2gBzU8dVlNCJUsGra5g= ; Message-ID: <20061112191114.98290.qmail@web8704.mail.in.yahoo.com> Received: from [172.143.204.234] by web8704.mail.in.yahoo.com via HTTP; Sun, 12 Nov 2006 19:11:14 GMT Date: Sun, 12 Nov 2006 19:11:14 +0000 (GMT) From: Siddhartha Bhakta Subject: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt To: sipping@ietf.org In-Reply-To: <20061112190349.87110.qmail@web8702.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sbhakta007@yahoo.co.in, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I am re-sending it as in last email, the figure was distorted. Though, post RFC3261 drafts indicate that one valid answer would be there for one SDP offer, the our old friend early-media flow is still present in practice. B2BUA/SBC Proxy PABX Bob | | | | | INVITE F1 | | | |----------->| INVITE F2 | | | 183 F3 |----------->| INVITE F4 | |<-----------| |----------->| | | | | | | | 180 without SDP F5 | | |<-----------| | | | | | | 180 with SDP F6 | | 180 F7 |<-----------| | |<-----------| | 200 F8 | | | 200 F9 |<-----------| | 200 F10 |<-----------| | |<-----------| | | | ACK F11 | | | |----------->| ACK F12 | | | |----------->| ACK F13 | | | |----------->| Our B2BUA is facing the problem as specified above. The first answer is carried by F3. This SDP is specified by Proxy. The 2nd SDP answer is carried by F6,F7. In fact, this SDP is specified by PABX. The third SDP answer is carried by F8,F9,F10. This SDP is specified by called party (Bob). As per the RFC3261 & RFC3264, the SDP answer carried by F6,F7 should match with F3 as far as B2BUA is concerned. Therefore, B2BUA shall ignore it. This is leading to the fact that SIP UA behind B2BUA can not listen to ringtone fed by PABX. Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This shall lead to the fact that SIP UA behind B2BUA can not listen to Bob's voice. Too bad. This problem is due to the fact that RFC3261 & RFC3264 are not backward compatible. The sec 2.2. of draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE should be used to update the media in early media. But in practice old early-media flow (i.e., sending different SDPs over different 1xx responses of INVITE) is quite common. Can we somehow make new SDP offer/answer specified in RFC3261 & RFC3264 backward compatible? The old standard (early-media), allows multiple SDP answers of single SDP offer. can we somehow induce this thing in SDP offer/answer model? If many of you think the need of it then I may comeup with some thumb rule for the same. Thanks & Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 15:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjLcy-0000N0-TM; Sun, 12 Nov 2006 15:08:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjLcy-0000Mv-06 for sipping@ietf.org; Sun, 12 Nov 2006 15:08:28 -0500 Received: from web8714.mail.in.yahoo.com ([203.84.221.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjLcw-0003Bb-CL for sipping@ietf.org; Sun, 12 Nov 2006 15:08:27 -0500 Received: (qmail 6691 invoked by uid 60001); 12 Nov 2006 20:08:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=j/rGUu7iUJjpja7cKGZuoCHkollhEOxsC2SIlgtXCDvHMmuZu5E21DSADtG1U4Haw1M87pfv5Pb6ZB2nmS3/ELmElrAWtkKw4vWQ/4zC1tMd65NoQ4VVUSiPDrCUMypL3er2DKJ6cWQPvnu/7pVZJeftgxWZKoGDIDXpfByyXvk= ; Message-ID: <20061112200824.6689.qmail@web8714.mail.in.yahoo.com> Received: from [172.143.204.234] by web8714.mail.in.yahoo.com via HTTP; Sun, 12 Nov 2006 20:08:24 GMT Date: Sun, 12 Nov 2006 20:08:24 +0000 (GMT) From: Siddhartha Bhakta Subject: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org About point 3) I can say that not to-tag but Via Branch parameter of SIP responses helps forking proxy to associate those with any forked dialog. If 4xx-6xx is received then depending on the via branch parameter, forking proxy can know which dialog is being terminated. The very first to-tag does not really help forking proxy to associate with any dialog. Therefore, I can not understand the reason of extra ambiguity if to-tag of 1xx response is being dropped. Your point 2) and 3) ensures that Alice can manage three dilaogs properly. If point 1) is implemented then I can not understand how the dialogs created by F5 and F10 shall be terminated at Alice in sec 2.9. The dialog created by F13 is terminated by BYE(F18) as far as Alice is concerned. I have asked this question earlier also. I am yet to get answer from anyone! Thanks and Regards, Siddhartha Brett Tate Wrote: ----------------- I do not have a strong opinion concerning the sending of 181 (without SDP) when the proxy has received the 487 response. There are 3 options; however only option 1 is compliant with rfc3261. 1) Follow service example and add new To tag. This is the only rfc3261 compliant solution. 2) Use the To tag of the received failure response. This is non complaint to rfc3261 and requires waiting for the 487. The reason that it might be nice is because allowing this to be valid would easily allow a new 1xx response code to be sent by a forking proxy to indicate when a particular early dialog no longer exists. However there are definitely other ways to solve that problem. 3) Send non-100 1xx responses without To tag. This provides extra ambiguity; and this is especially true when multiple forking proxies are involved. And it is non compliant to rfc3261. __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 12 21:49:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjRpu-0003Ft-Qa; Sun, 12 Nov 2006 21:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjRps-0003B6-8B for sipping@ietf.org; Sun, 12 Nov 2006 21:46:12 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjRkV-0006S8-1k for sipping@ietf.org; Sun, 12 Nov 2006 21:40:40 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AB130410; Sun, 12 Nov 2006 21:40:19 -0500 From: "Hadriel Kaplan" To: "'Siddhartha Bhakta'" , Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Sun, 12 Nov 2006 21:39:39 -0500 Message-ID: <021d01c706cc$f7e65170$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20061112191114.98290.qmail@web8704.mail.in.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccGjnrgUxuLDKUgT2ej+MGrazrbswAOrPLg X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org If the Proxy is sending back SDP by itself it's not a proxy, but a b2bua, as is the PBX. As such, it should be answering in a different dialog, so its SDP answer should be in a 183 with a different To-tag from the 180, and the PBX's 180 SDP should have a different To-tag than the 200ok. That would make them look like a forked call and follow the RFCs. Of course the reality is often different, but being a b2bua yourself it's in your power to fix it. How you do that is not up to the IETF to define, as the very idea of it goes against the IETF's view of the world. (and I say that in a positive way, as I think it would be practically impossible for the IETF to do otherwise) -hadriel > -----Original Message----- > From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] > Sent: Sunday, November 12, 2006 2:11 PM > To: sipping@ietf.org > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > Subject: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping- > sip-offeranswer-01.txt > > I am re-sending it as in last email, the figure was > distorted. > > Though, post RFC3261 drafts indicate that one valid > answer would be there for one SDP > offer, the our old friend early-media flow is still > present in practice. > > B2BUA/SBC Proxy PABX Bob > | | | | > | INVITE F1 | | | > |----------->| INVITE F2 | | > | 183 F3 |----------->| INVITE F4 | > |<-----------| |----------->| > | | | | > | | | 180 without SDP F5 > | | |<-----------| > | | | | > | | 180 with SDP F6 | > | 180 F7 |<-----------| | > |<-----------| | 200 F8 | > | | 200 F9 |<-----------| > | 200 F10 |<-----------| | > |<-----------| | | > | ACK F11 | | | > |----------->| ACK F12 | | > | |----------->| ACK F13 | > | | |----------->| > > Our B2BUA is facing the problem as specified above. > The first answer is carried > by F3. This SDP is specified by Proxy. The 2nd SDP > answer is carried by F6,F7. > In fact, this SDP is specified by PABX. The third SDP > answer is carried by F8,F9,F10. > This SDP is specified by called party (Bob). > > As per the RFC3261 & RFC3264, the SDP answer carried > by F6,F7 should match with F3 > as far as B2BUA is concerned. Therefore, B2BUA shall > ignore it. This is leading to > the fact that SIP UA behind B2BUA can not listen to > ringtone fed by PABX. > Similarly, SDP answer carried by F8,F9,F10 shall be > ignored. This shall lead to the fact > that SIP UA behind B2BUA can not listen to Bob's > voice. Too bad. > This problem is due to the fact that RFC3261 & RFC3264 > are not backward compatible. > > > The sec 2.2. of > draft-sawada-sipping-sip-offeranswer-01.txt indicates > that UPDATE should > be used to update the media in early media. But in > practice old early-media flow (i.e., > sending different SDPs over different 1xx responses of > INVITE) is quite common. > Can we somehow make new SDP offer/answer specified in > RFC3261 & RFC3264 backward > compatible? > > The old standard (early-media), allows multiple SDP > answers of single SDP offer. can > we somehow induce this thing in SDP offer/answer > model? If many of you think the need > of it then I may comeup with some thumb rule for the > same. > > Thanks & Regards, > Siddhartha _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 00:38:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjUUh-0001Wr-Qu; Mon, 13 Nov 2006 00:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjUUg-0001Wg-6P for sipping@ietf.org; Mon, 13 Nov 2006 00:36:30 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjUUe-0008DT-P8 for sipping@ietf.org; Mon, 13 Nov 2006 00:36:30 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 12 Nov 2006 21:31:31 -0800 From: "Darshan Bildikar" To: "'Paul Kyzivat'" , "'Gunnar Hellstrom'" Subject: RE: SV: Utility of Alert-Info(was:Re:[Sipping]draft-stucker-sipping-early-media-coping) Date: Mon, 13 Nov 2006 11:01:26 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AccE+Ky/bQUQCdffRz2Sn8xxVYp7xgB6ib2w In-Reply-To: <4554C77F.7020300@cisco.com> Message-ID: X-OriginalArrivalTime: 13 Nov 2006 05:31:32.0483 (UTC) FILETIME=[FA4A4530:01C706E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Cullen Jennings' , 'Dean Willis' , 'sipping' , 'Brian Stucker' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org My understanding was that RBT's are always generated by downstream entities (in case of PSTN interop by the terminating gateways) and busy tones are generated by local proxies. (Like in PSTN where the terminating switch generates the RBT and the local switch generates the busy tone) If we were to generate local RBT based on a URN namespace what would happen if an RBT is also getting generated from the remote end? Are we supposed to ignore it? If yes, then it would go against RFC 3264 that states that the UA must be prepared to start receiving RTP immediately after sending an offer. There is then the likelihood of two RBT's being played to the caller simultaneously. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Saturday, November 11, 2006 12:10 AM To: Gunnar Hellstrom Cc: Cullen Jennings; Brian Stucker; sipping; Dean Willis Subject: Re: SV: Utility of Alert-Info(was:Re: [Sipping] draft-stucker-sipping-early-media-coping) The thing referenced by an Alert-Info can have any kind of alerting behavior. For instance, it ultimately could be a multipart mime body with audio, video, and other kinds of material. Then the UA can choose which of these to render. If URNs are used, then each UA can have its own mapping from the URN to the actual alerting mechanism. That provides a mechanism to have a generic set of alerts that are expected to be distinguishable from one another, while still accommodating the environmental, etc. needs of individual users. Paul Gunnar Hellstrom wrote: > If this discussion will lead to an enhanced definition of alerting, please > then remember to include not only that the tone characteristics should be > configurable, but also the mode of alerting. > > -Audible - Ring tones etc according to current discussion. > -Visual - Flashing lights, flashing screen. > -Tactile - Pocket vibration, watch vibration, handset vibration. > > In many cases the selection can be made from preferences in a user profile, > while in other cases it is the environment that influences what mode to use. > ( e.g. flashing light in very noisy industry area ) > > Gunnar > > -----Ursprungligt meddelande----- > Fran: Cullen Jennings [mailto:fluffy@cisco.com] > Skickat: den 10 november 2006 04:35 > Till: Dean Willis > Kopia: Paul Kyzivat; sipping; Brian Stucker > Amne: Re: Utility of Alert-Info (was:Re: [Sipping] > draft-stucker-sipping-early-media-coping) > > > > If you want a list of the tones - you might check out the draft I did > a long time ago ... > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- > midi.html > > If you think that it would be a good idea that when I phone country > X, I get a tone that I can recognize as busy or ringing , well I > agree with you but all research of what users wants and what > companies want to build seems to disagree with you. > > > On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: > >> On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: >> >>> I think it would be far better to define a URN namespace for >>> ringtones and use local configuration to map those to specific >>> files. What you are proposing will only work in the most closed >>> and homogeneous environments. >>> >> Absolutely. I think this is a GREAT idea. >> >> -- >> Dean > > _______________________________________________ > 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 > _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 06:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaKX-0001lP-1K; Mon, 13 Nov 2006 06:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjaKV-0001l7-D9 for sipping@ietf.org; Mon, 13 Nov 2006 06:50:23 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjaKQ-0002U1-PP for sipping@ietf.org; Mon, 13 Nov 2006 06:50:23 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.237,BAYES_00: -1.665, MAILTO_TO_SPAM_ADDR: 0.106, SARE_RECV_ADDR: 0.027, SARE_SUB_MOBFU_2: 0.712 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Mon, 13 Nov 2006 11:48:05 +0000 From: "Siddhartha Bhakta" To: "'Hadriel Kaplan'" , "'Siddhartha Bhakta'" , Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Mon, 13 Nov 2006 11:47:59 -0000 Message-ID: <019201c70719$938ce610$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccGjnrgUxuLDKUgT2ej+MGrazrbswAOrPLgABO+6sA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <021d01c706cc$f7e65170$0500a8c0@acmepacket.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I know, the RFC3261 indicates so. As per RFC3261, all such 1xx with SDP should contain distinct to-tags(virtual UAS) so that it appears to belong to different dialogs. The offer-answer state is maintained separately in different dialogs. Therefore, there shall not be the case where a single dialog is having multiple answers for a single offer. However, we can not deny the fact that this flow of RFC3261/RFC3264 is not backward compatible (where multiple SDP answers were possible per SDP offer). In my depicted example, the 183 shall definitely have different to-tag. But the '180 Ringing' shall carry same to-tag as that of 200 OK. So my concern is that whether we should put the effort to make RFC3261/RFRC3264 backward compatible. I hope, this is quite justifies expectation. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: 13 November 2006 02:40 To: 'Siddhartha Bhakta'; sipping@ietf.org Cc: 'Siddhartha Bhakta' Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt If the Proxy is sending back SDP by itself it's not a proxy, but a b2bua, as is the PBX. As such, it should be answering in a different dialog, so its SDP answer should be in a 183 with a different To-tag from the 180, and the PBX's 180 SDP should have a different To-tag than the 200ok. That would make them look like a forked call and follow the RFCs. Of course the reality is often different, but being a b2bua yourself it's in your power to fix it. How you do that is not up to the IETF to define, as the very idea of it goes against the IETF's view of the world. (and I say that in a positive way, as I think it would be practically impossible for the IETF to do otherwise) -hadriel > -----Original Message----- > From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] > Sent: Sunday, November 12, 2006 2:11 PM > To: sipping@ietf.org > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > Subject: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping- > sip-offeranswer-01.txt > > I am re-sending it as in last email, the figure was > distorted. > > Though, post RFC3261 drafts indicate that one valid > answer would be there for one SDP > offer, the our old friend early-media flow is still > present in practice. > > B2BUA/SBC Proxy PABX Bob > | | | | > | INVITE F1 | | | > |----------->| INVITE F2 | | > | 183 F3 |----------->| INVITE F4 | > |<-----------| |----------->| > | | | | > | | | 180 without SDP F5 > | | |<-----------| > | | | | > | | 180 with SDP F6 | > | 180 F7 |<-----------| | > |<-----------| | 200 F8 | > | | 200 F9 |<-----------| > | 200 F10 |<-----------| | > |<-----------| | | > | ACK F11 | | | > |----------->| ACK F12 | | > | |----------->| ACK F13 | > | | |----------->| > > Our B2BUA is facing the problem as specified above. > The first answer is carried > by F3. This SDP is specified by Proxy. The 2nd SDP > answer is carried by F6,F7. > In fact, this SDP is specified by PABX. The third SDP > answer is carried by F8,F9,F10. > This SDP is specified by called party (Bob). > > As per the RFC3261 & RFC3264, the SDP answer carried > by F6,F7 should match with F3 > as far as B2BUA is concerned. Therefore, B2BUA shall > ignore it. This is leading to > the fact that SIP UA behind B2BUA can not listen to > ringtone fed by PABX. > Similarly, SDP answer carried by F8,F9,F10 shall be > ignored. This shall lead to the fact > that SIP UA behind B2BUA can not listen to Bob's > voice. Too bad. > This problem is due to the fact that RFC3261 & RFC3264 > are not backward compatible. > > > The sec 2.2. of > draft-sawada-sipping-sip-offeranswer-01.txt indicates > that UPDATE should > be used to update the media in early media. But in > practice old early-media flow (i.e., > sending different SDPs over different 1xx responses of > INVITE) is quite common. > Can we somehow make new SDP offer/answer specified in > RFC3261 & RFC3264 backward > compatible? > > The old standard (early-media), allows multiple SDP > answers of single SDP offer. can > we somehow induce this thing in SDP offer/answer > model? If many of you think the need > of it then I may comeup with some thumb rule for the > same. > > Thanks & Regards, > Siddhartha --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 10:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdgD-0007Ae-P2; Mon, 13 Nov 2006 10:25:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdgC-0007AZ-Kk for sipping@ietf.org; Mon, 13 Nov 2006 10:25:00 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdgA-00012T-EA for sipping@ietf.org; Mon, 13 Nov 2006 10:25:00 -0500 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 10:25:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Mon, 13 Nov 2006 10:24:55 -0500 Message-ID: <77BD870EA838FC469FDD2AE248B1357B0178914D@ATL1VEXC008.usdom003.tco.tc> In-reply-to: <20061112200824.6689.qmail@web8714.mail.in.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Thread-Index: AccGl2vGCI6idO2lRd+jArXXxcSXTAAk1DQg From: "Brett Tate" To: "Siddhartha Bhakta" , X-OriginalArrivalTime: 13 Nov 2006 15:25:00.0574 (UTC) FILETIME=[E25DC3E0:01C70737] X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > About point 3) I can say that not to-tag but Via Branch=20 > parameter of SIP responses helps forking proxy to associate=20 > those with any forked dialog. If 4xx-6xx is received then=20 > depending on the via branch parameter, forking proxy can know=20 > which dialog is being terminated. The very first to-tag does=20 > not really help forking proxy to associate with any dialog.=20 > Therefore, I can not understand the reason of extra ambiguity=20 > if to-tag of 1xx response is being dropped. The ambiguity is not with the 18x's received at the forking proxy. The ambiguity is at the UA receiving the proxied 18x's which in your proposal would not contain To tags. > Your point 2) and 3) ensures that Alice can manage three=20 > dilaogs properly. If point 1) is implemented then I can not=20 > understand how the dialogs created by > F5 and F10 shall be terminated at Alice in sec 2.9. > The dialog created by F13 is terminated by BYE(F18) as far as=20 > Alice is concerned. I have asked this question earlier also.=20 > I am yet to get answer from anyone! The forking proxy terminates them per rfc3261 section 16.7 step 10. Otherwise during race conditions or when the caller wants to release a particular dialog, the caller can send a BYE for the individual dialog. _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 11:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjew4-0005Dq-77; Mon, 13 Nov 2006 11:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjew2-0005Df-PC for sipping@ietf.org; Mon, 13 Nov 2006 11:45:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjevy-0004QR-NG for sipping@ietf.org; Mon, 13 Nov 2006 11:45:26 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 08:45:21 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2094126:sNHT430423722" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADGjLrt006196; Mon, 13 Nov 2006 11:45:21 -0500 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 kADGjKYJ018455; Mon, 13 Nov 2006 11:45:20 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:45:20 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:45:19 -0500 Message-ID: <4558A11F.1040402@cisco.com> Date: Mon, 13 Nov 2006 11:45:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stephen Sprunk References: <4554C77F.7020300@cisco.com> <01c901c705d1$c7cea1a0$6701a8c0@atlanta.polycom.com> In-Reply-To: <01c901c705d1$c7cea1a0$6701a8c0@atlanta.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 16:45:19.0957 (UTC) FILETIME=[1AF14050:01C70743] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1762; t=1163436321; x=1164300321; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20SV=3A=20Utility=20of=20Alert-Info |Sender:=20 |To:=20Stephen=20Sprunk=20; bh=LCxteqQz1L7IF9xtx5Y9aRB9u8XbX6PG1BS/VIT5txs=; b=pfOi1d1RZj/byV75vq0oROHWyBKFeMny3ziBgcd8GJw9bAa5lzA949sX7AeT4BWppb9bA2zZ Br+Ro2X56UZ5TGeWEjIEXol/OfwwD0U0DKaldcjDV/3mhuN5c5OO67pl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Cullen Jennings , sipping , Dean Willis , Gunnar Hellstrom , Brian Stucker Subject: [Sipping] Re: SV: Utility of Alert-Info X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Stephen Sprunk wrote: > Thus spake "Paul Kyzivat" >> The thing referenced by an Alert-Info can have any kind of alerting >> behavior. For instance, it ultimately could be a multipart mime body >> with audio, video, and other kinds of material. Then the UA can choose >> which of these to render. > > That's clever... > >> If URNs are used, then each UA can have its own mapping from the >> URN to the actual alerting mechanism. That provides a mechanism to >> have a generic set of alerts that are expected to be distinguishable >> from one another, while still accommodating the environmental, etc. >> needs of individual users. > > This is already done to an extent today, though not with URNs. There > are a number of vendors that send us something like: > > Alert-Info: http://127.0.0.1/Bellcore-dr2 This is "poor man's URN", without any real standardization of meaning. Paul > Exactly what we do with that is up to the receiver; in our case, the > user is allowed to decide what "Distinctive Ring #2" sounds/looks like. > > In fact, this has been the standard mechanism we've been seeing for > several years. It's only recently that some folks have started sending > us real URIs (SP-controlled custom ringtones); the problem with that is > being sure the UA is capable of playing the media format referenced. > What if you send a URI for an WMA file to a UA that's only capable of > playing MP3 or WAV files? Multipart might help solve that as well. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 11:48:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjezO-0008AX-FG; Mon, 13 Nov 2006 11:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjezM-00089m-7k for sipping@ietf.org; Mon, 13 Nov 2006 11:48:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjezK-000547-I2 for sipping@ietf.org; Mon, 13 Nov 2006 11:48:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 08:48:32 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="344243245:sNHT11259663436" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADGmUVJ007747; Mon, 13 Nov 2006 11:48:30 -0500 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 kADGmUYJ019425; Mon, 13 Nov 2006 11:48:30 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:48:30 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 11:48:30 -0500 Message-ID: <4558A1DD.3060506@cisco.com> Date: Mon, 13 Nov 2006 11:48:29 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Darshan Bildikar Subject: Re: SV: Utility of Alert-Info(was:Re:[Sipping]draft-stucker-sipping-early-media-coping) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 16:48:30.0110 (UTC) FILETIME=[8C484BE0:01C70743] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4564; t=1163436510; x=1164300510; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20SV=3A=20Utility=20of=20Alert-Info(was=3ARe=3A[Sipping ]draft-stucker-sipping-early-media-coping) |Sender:=20 |To:=20Darshan=20Bildikar=20; bh=xFXbB7Ghz3k/DszU+s76CSxu7N6BrZDWD8i5ERtzKFY=; b=ZZZGyG8nZZRvaSKSO2d7LmIPDj2HgmJMg2hMxUTejXQ7cGU5gJqjDOezHyaYByC6ca3PuxY7 1JRhwRDca48ghFCiSW1c0t/zTgCHPUkLWfNtPK56wSNTH/RUHVPkXmlq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: 'Cullen Jennings' , 'sipping' , 'Dean Willis' , 'Gunnar Hellstrom' , 'Brian Stucker' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Darshan Bildikar wrote: > My understanding was that RBT's are always generated by downstream entities > (in case of PSTN interop by the terminating gateways) and busy tones are > generated by local proxies. (Like in PSTN where the terminating switch > generates the RBT and the local switch generates the busy tone) > > If we were to generate local RBT based on a URN namespace what would happen > if an RBT is also getting generated from the remote end? Are we supposed to > ignore it? If yes, then it would go against RFC 3264 that states that the UA > must be prepared to start receiving RTP immediately after sending an offer. > There is then the likelihood of two RBT's being played to the caller > simultaneously. IMO, the Alert-Info merely overrides the default alerting / ringback mechanism used by the device. In the case of ringback, that will typically only be used when there has been a 180 response *and* there is no in-band ringback. Just as in-band ringback preempts the default local ringback, it should probably also preempt the locally generated ringback based on Alert-Info. YMMV. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Saturday, November 11, 2006 12:10 AM > To: Gunnar Hellstrom > Cc: Cullen Jennings; Brian Stucker; sipping; Dean Willis > Subject: Re: SV: Utility of Alert-Info(was:Re: [Sipping] > draft-stucker-sipping-early-media-coping) > > The thing referenced by an Alert-Info can have any kind of alerting > behavior. For instance, it ultimately could be a multipart mime body > with audio, video, and other kinds of material. Then the UA can choose > which of these to render. > > If URNs are used, then each UA can have its own mapping from the URN to > the actual alerting mechanism. That provides a mechanism to have a > generic set of alerts that are expected to be distinguishable from one > another, while still accommodating the environmental, etc. needs of > individual users. > > Paul > > Gunnar Hellstrom wrote: >> If this discussion will lead to an enhanced definition of alerting, please >> then remember to include not only that the tone characteristics should be >> configurable, but also the mode of alerting. >> >> -Audible - Ring tones etc according to current discussion. >> -Visual - Flashing lights, flashing screen. >> -Tactile - Pocket vibration, watch vibration, handset vibration. >> >> In many cases the selection can be made from preferences in a user > profile, >> while in other cases it is the environment that influences what mode to > use. >> ( e.g. flashing light in very noisy industry area ) >> >> Gunnar >> >> -----Ursprungligt meddelande----- >> Fran: Cullen Jennings [mailto:fluffy@cisco.com] >> Skickat: den 10 november 2006 04:35 >> Till: Dean Willis >> Kopia: Paul Kyzivat; sipping; Brian Stucker >> Amne: Re: Utility of Alert-Info (was:Re: [Sipping] >> draft-stucker-sipping-early-media-coping) >> >> >> >> If you want a list of the tones - you might check out the draft I did >> a long time ago ... >> >> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- >> midi.html >> >> If you think that it would be a good idea that when I phone country >> X, I get a tone that I can recognize as busy or ringing , well I >> agree with you but all research of what users wants and what >> companies want to build seems to disagree with you. >> >> >> On Nov 9, 2006, at 10:11 AM, Dean Willis wrote: >> >>> On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote: >>> >>>> I think it would be far better to define a URN namespace for >>>> ringtones and use local configuration to map those to specific >>>> files. What you are proposing will only work in the most closed >>>> and homogeneous environments. >>>> >>> Absolutely. I think this is a GREAT idea. >>> >>> -- >>> Dean >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 12:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjflT-0007GW-N9; Mon, 13 Nov 2006 12:38:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjflS-0007Df-2G for sipping@ietf.org; Mon, 13 Nov 2006 12:38:34 -0500 Received: from web8708.mail.in.yahoo.com ([203.84.221.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjflO-0003FH-88 for sipping@ietf.org; Mon, 13 Nov 2006 12:38:34 -0500 Received: (qmail 59226 invoked by uid 60001); 13 Nov 2006 17:38:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=53A5bG0YVMcqevbOWJWB+1uUXPBgyPrO9DP2VJhgQCC6n3NmimqxsDmTTsMu28HYsRP3Z8U7+F2XlUvx6rfg4fwsxNG/woJ3ndVQxMLRrFYd8YmNods0LrEIBWs6u1d0eIU8Cp5vbpNg+m2HEHpKWIfmKKtMAXa21V9S5T+IeDk= ; Message-ID: <20061113173828.59224.qmail@web8708.mail.in.yahoo.com> Received: from [217.45.197.113] by web8708.mail.in.yahoo.com via HTTP; Mon, 13 Nov 2006 17:38:28 GMT Date: Mon, 13 Nov 2006 17:38:28 +0000 (GMT) From: Siddhartha Bhakta Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Brett Tate , sipping@ietf.org In-Reply-To: <77BD870EA838FC469FDD2AE248B1357B0178914D@ATL1VEXC008.usdom003.tco.tc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org My response is inserted below starting with [SB]. --- Brett Tate wrote: > > About point 3) I can say that not to-tag but Via > Branch > > parameter of SIP responses helps forking proxy to > associate > > those with any forked dialog. If 4xx-6xx is > received then > > depending on the via branch parameter, forking > proxy can know > > which dialog is being terminated. The very first > to-tag does > > not really help forking proxy to associate with > any dialog. > > Therefore, I can not understand the reason of > extra ambiguity > > if to-tag of 1xx response is being dropped. > > The ambiguity is not with the 18x's received at the > forking proxy. The > ambiguity is at the UA receiving the proxied 18x's > which in your > proposal would not contain To tags. [SB] If to-tag is dropped from 18x response, then dialog creation shall be deferred. That's is exactly what I am proposing in this case. Since forking proxy does not know whether to this dialog shall be continued or not, it should deferred the dialog creation at the SIP entity behind. > > > Your point 2) and 3) ensures that Alice can manage > three > > dilaogs properly. If point 1) is implemented then > I can not > > understand how the dialogs created by > > F5 and F10 shall be terminated at Alice in sec > 2.9. > > The dialog created by F13 is terminated by > BYE(F18) as far as > > Alice is concerned. I have asked this question > earlier also. > > I am yet to get answer from anyone! > > The forking proxy terminates them per rfc3261 > section 16.7 step 10. > Otherwise during race conditions or when the caller > wants to release a > particular dialog, the caller can send a BYE for the > individual dialog. > [SB] I don't understand, how dialogs created by F5 and F10 are terminated at Alice. Proxy is sending CANCEL towards User B1 to terminated dialog created by F4 but it is not sending anything back to Alice. In fact, the proxy is not doing anything to terminate the dialog created by F5 and F10 at Alice in sec 2.9. Alice is also not sending CANCEL for those dialogs. Therefore, I can not understand, how those dialog shall be terminated at Alice. __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 12:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfxC-0000eC-Vi; Mon, 13 Nov 2006 12:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjfxB-0000e6-K4 for sipping@ietf.org; Mon, 13 Nov 2006 12:50:41 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjfx9-0004pK-07 for sipping@ietf.org; Mon, 13 Nov 2006 12:50:41 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 09:50:37 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2162034:sNHT168671619" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kADHoaM2009635; Mon, 13 Nov 2006 12:50:36 -0500 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 kADHoaYJ007736; Mon, 13 Nov 2006 12:50:36 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:50:36 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:50:35 -0500 Message-ID: <4558B06B.20903@cisco.com> Date: Mon, 13 Nov 2006 12:50:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt References: <20061112191114.98290.qmail@web8704.mail.in.yahoo.com> In-Reply-To: <20061112191114.98290.qmail@web8704.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 17:50:35.0786 (UTC) FILETIME=[38F556A0:01C7074C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4313; t=1163440236; x=1164304236; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[SIPPING]=20SDP=20offer/answer=20in=20early=20media=3 A=09draft-sawada-sipping-sip-offeranswer-01.txt |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=Vv15a/ITvh/B6yxZA6z5xbsGNLXmTfarZu4nnDrRU/k=; b=xfe4Wa0BQqHCqHPUli38hI0DfDCIFTF/sOpFbcwOluWmOBgdrLupauZSgAjJ2euhgis7p4eD lTa6VElSIPQsVeamthv1nxlO6qTOKDjx5Xt8tj7GZakpxJlcjtdYDums; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > I am re-sending it as in last email, the figure was > distorted. > > Though, post RFC3261 drafts indicate that one valid > answer would be there for one SDP > offer, the our old friend early-media flow is still > present in practice. > > B2BUA/SBC Proxy PABX Bob > | | | | > | INVITE F1 | | | > |----------->| INVITE F2 | | > | 183 F3 |----------->| INVITE F4 | > |<-----------| |----------->| > | | | | > | | | 180 without SDP F5 > | | |<-----------| > | | | | > | | 180 with SDP F6 | > | 180 F7 |<-----------| | > |<-----------| | 200 F8 | > | | 200 F9 |<-----------| > | 200 F10 |<-----------| | > |<-----------| | | > | ACK F11 | | | > |----------->| ACK F12 | | > | |----------->| ACK F13 | > | | |----------->| In the above, F3 is illegal according to 3261, because this action is not permitted for proxies. It can be fixed by modeling another UA (an early media source) that the proxy forks to. F6 may also be illegal. It depends on whether the PABX is a proxy or a B2BUA. If a proxy then it too is illegal. > Our B2BUA is facing the problem as specified above. > The first answer is carried > by F3. This SDP is specified by Proxy. The 2nd SDP > answer is carried by F6,F7. > In fact, this SDP is specified by PABX. The third SDP > answer is carried by F8,F9,F10. > This SDP is specified by called party (Bob). > > As per the RFC3261 & RFC3264, the SDP answer carried > by F6,F7 should match with F3 > as far as B2BUA is concerned. This is not required if F3, F7, and F10 are all separate dialogs. If I understand what you are trying to accomplish, then that is the way to accomplish it. > Therefore, B2BUA shall > ignore it. This is leading to > the fact that SIP UA behind B2BUA can not listen to > ringtone fed by PABX. > Similarly, SDP answer carried by F8,F9,F10 shall be > ignored. This shall lead to the fact > that SIP UA behind B2BUA can not listen to Bob's > voice. Too bad. > This problem is due to the fact that RFC3261 & RFC3264 > are not backward compatible. If the three SDPs are generated independently then they can't be expected to obey the constraints imposed by being within a single dialog. Your problem is trying to force them to do so. > The sec 2.2. of > draft-sawada-sipping-sip-offeranswer-01.txt indicates > that UPDATE should > be used to update the media in early media. That would not solve your problem. It is concerned with a single dialog. You have a situation with multiple dialogs. Each must be considered separately. (However, you are not the first to raise this sort of issue. Perhaps it should be discussed in the draft.) > But in > practice old early-media flow (i.e., > sending different SDPs over different 1xx responses of > INVITE) is quite common. > Can we somehow make new SDP offer/answer specified in > RFC3261 & RFC3264 backward > compatible? > The old standard (early-media), allows multiple SDP > answers of single SDP offer. can > we somehow induce this thing in SDP offer/answer > model? If many of you think the need > of it then I may comeup with some thumb rule for the > same. IMO there is nothing to fix in the standards to solve your problem. What needs fixing are the sip implementations in some of the elements you are using. Paul > Thanks & Regards, > Siddhartha > > > > __________________________________________________________ > Yahoo! India Answers: Share what you know. Learn something new > http://in.answers.yahoo.com/ > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 13:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgBY-0000O9-4n; Mon, 13 Nov 2006 13:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgBW-0000Nv-LR for sipping@ietf.org; Mon, 13 Nov 2006 13:05:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgBV-0006je-6L for sipping@ietf.org; Mon, 13 Nov 2006 13:05:30 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 10:05:28 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2179254:sNHT56888883" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kADI5SKI008317; Mon, 13 Nov 2006 10:05:28 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kADI5ROV016798; Mon, 13 Nov 2006 10:05:28 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:05:27 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:05:27 -0500 Message-ID: <4558B3E6.1030404@cisco.com> Date: Mon, 13 Nov 2006 13:05:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <20061112200824.6689.qmail@web8714.mail.in.yahoo.com> In-Reply-To: <20061112200824.6689.qmail@web8714.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:05:27.0335 (UTC) FILETIME=[4C5CEB70:01C7074E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3925; t=1163441128; x=1164305128; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:=20; bh=yi1Xptyse/0LDgWsJehblE4wZMHxhSdOEckPAvjXLoc=; b=IH8xMawG+D6xOBxjEYGYVCQVbyz2t09TLJuN9A0nQGwRSjtZiOHr1xbUpjmLfFyLrISZ6g0j 2GXmqqxIhCjcUIjgVnZ0zQePnlvVYHdb+qWy7ZB4y3Rsc8cC5mLlYJw8; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > About point 3) I can say that not to-tag but Via > Branch parameter of SIP responses helps forking proxy > to associate those with any forked dialog. I disagree. The branch parameter associates the response with a particular request. It is the Call-ID, To-tag, and From-tag that identify a particular dialog. In the forking case, the To-tags are not initially known to the UAC. So the Call-ID and From-tag define a half-formed dialog, and each response with a unique To-tag defines a new dialog. If you try to associate the half-formed dialog with the invite-transaction you may have trouble with some things. Of particular note, once you receive one 2xx response, you may have difficulty establishing added dialogs for other 2xx responses that might arrive. There is even more difficulty in case of subscribe/notify. In that case, extra dialogs may be established based on received NOTIFY requests which aren't tied to the SUBSCRIBE by branch, only by callid and tags. > If 4xx-6xx > is received then depending on the via branch > parameter, forking proxy can know which dialog is > being terminated. This happens to work because only a single non-successful final response is ever returned. Note that this implies the termination of *all* early dialogs that might have been established. (There may have been more than one.) > The very first to-tag does not > really help forking proxy to associate with any > dialog. Therefore, I can not understand the reason of > extra ambiguity if to-tag of 1xx response is being > dropped. The first to-tag received identifies the creation of the first early dialog. Subsequent responses with the same to-tag then must follow the offer/answer rules for that dialog. Dropping the to-tag is wrong because a to-tag is required in a 1xx response. > Your point 2) and 3) ensures that Alice can manage > three dilaogs properly. This is moot since these are illegal. > If point 1) is implemented > then I can not understand how the dialogs created by > F5 and F10 shall be terminated at Alice in sec 2.9. Brett already gave a reference for how these get terminated. Paul > The dialog created by F13 is terminated by BYE(F18) as > far as Alice is concerned. I have asked this question > earlier also. I am yet to get answer from anyone! > > > Thanks and Regards, > Siddhartha > > > Brett Tate Wrote: > ----------------- > > I do not have a strong opinion concerning the sending > of 181 (without > SDP) when the proxy has received the 487 response. > There are 3 options; > however only option 1 is compliant with rfc3261. > > 1) Follow service example and add new To tag. This is > the only rfc3261 > compliant solution. > > 2) Use the To tag of the received failure response. > This is non > complaint to rfc3261 and requires waiting for the 487. > The reason that > it might be nice is because allowing this to be valid > would easily allow > a new 1xx response code to be sent by a forking proxy > to indicate when a > particular early dialog no longer exists. However > there are definitely > other ways to solve that problem. > > 3) Send non-100 1xx responses without To tag. This > provides extra > ambiguity; and this is especially true when multiple > forking proxies are > involved. And it is non compliant to rfc3261. > > > > > __________________________________________________________ > Yahoo! India Answers: Share what you know. Learn something new > http://in.answers.yahoo.com/ > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 13:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgNm-000096-95; Mon, 13 Nov 2006 13:18:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgNk-000090-Ha for sipping@ietf.org; Mon, 13 Nov 2006 13:18:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgNi-0000B0-Sp for sipping@ietf.org; Mon, 13 Nov 2006 13:18:08 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 10:18:01 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="2195408:sNHT2756693385" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADIHxCi015380; Mon, 13 Nov 2006 13:17:59 -0500 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 kADIHwDM002630; Mon, 13 Nov 2006 13:17:58 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:17:58 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:17:58 -0500 Message-ID: <4558B6D5.1050505@cisco.com> Date: Mon, 13 Nov 2006 13:17:57 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt References: <019201c70719$938ce610$3801a8c0@newportnetworks.com> In-Reply-To: <019201c70719$938ce610$3801a8c0@newportnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:17:58.0240 (UTC) FILETIME=[0BEFEE00:01C70750] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6091; t=1163441879; x=1164305879; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[SIPPING]=20SDP=20offer/answer=20in=20early=09media=3 Adraft-sawada-sipping-sip-offeranswer-01.txt |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=VbeXHZ8ZW0U+Y5rstdZyncgG+qB1VyYKyMzoc//wAEc=; b=sEIaAbLnTAlGTvMVfvwCtA8wEd6jc2++Tfmtv5bzPLQMbeMUJ1/8XXwNLpURslQvq3xVtQdO Ur6HuiKuvQhKeX2ZxmY9AXKWhzLOL9Km+14W4oWmAGfrFlJ22d/51sYt; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sipping@ietf.org, 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > I know, the RFC3261 indicates so. As per RFC3261, all such 1xx with SDP > should contain distinct to-tags(virtual UAS) so that it appears to belong to > different dialogs. The offer-answer state is maintained separately in > different dialogs. Therefore, there shall not be the case where a single > dialog is having multiple answers for a single offer. > > However, we can not deny the fact that this flow of RFC3261/RFC3264 is not > backward compatible (where multiple SDP answers were possible per SDP > offer). I beg to differ. In fact I *do* deny your assertion. > In my depicted example, the 183 shall definitely have different > to-tag. But the '180 Ringing' shall carry same to-tag as that of 200 OK. Well, the 180 F5 presumably has the same to-tag as 200 F8. But 180 F6 is a different message that F5. It has SDP from a different source. So it should have a different to-tag from both F3 and F5. It is clearly a matter for your PABX to decide how to handle F9. > So > my concern is that whether we should put the effort to make RFC3261/RFRC3264 > backward compatible. I hope, this is quite justifies expectation. You just need to make your implementations backwards compatble with 3261 and 3264. Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 13 November 2006 02:40 > To: 'Siddhartha Bhakta'; sipping@ietf.org > Cc: 'Siddhartha Bhakta' > Subject: RE: [SIPPING] SDP offer/answer in early > media:draft-sawada-sipping-sip-offeranswer-01.txt > > If the Proxy is sending back SDP by itself it's not a proxy, but a b2bua, as > is the PBX. > As such, it should be answering in a different dialog, so its SDP answer > should be in a 183 with a different To-tag from the 180, and the PBX's 180 > SDP should have a different To-tag than the 200ok. That would make them > look like a forked call and follow the RFCs. > > Of course the reality is often different, but being a b2bua yourself it's in > your power to fix it. How you do that is not up to the IETF to define, as > the very idea of it goes against the IETF's view of the world. (and I say > that in a positive way, as I think it would be practically impossible for > the IETF to do otherwise) > > -hadriel > > >> -----Original Message----- >> From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] >> Sent: Sunday, November 12, 2006 2:11 PM >> To: sipping@ietf.org >> Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta >> Subject: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping- >> sip-offeranswer-01.txt >> >> I am re-sending it as in last email, the figure was >> distorted. >> >> Though, post RFC3261 drafts indicate that one valid >> answer would be there for one SDP >> offer, the our old friend early-media flow is still >> present in practice. >> >> B2BUA/SBC Proxy PABX Bob >> | | | | >> | INVITE F1 | | | >> |----------->| INVITE F2 | | >> | 183 F3 |----------->| INVITE F4 | >> |<-----------| |----------->| >> | | | | >> | | | 180 without SDP F5 >> | | |<-----------| >> | | | | >> | | 180 with SDP F6 | >> | 180 F7 |<-----------| | >> |<-----------| | 200 F8 | >> | | 200 F9 |<-----------| >> | 200 F10 |<-----------| | >> |<-----------| | | >> | ACK F11 | | | >> |----------->| ACK F12 | | >> | |----------->| ACK F13 | >> | | |----------->| >> >> Our B2BUA is facing the problem as specified above. >> The first answer is carried >> by F3. This SDP is specified by Proxy. The 2nd SDP >> answer is carried by F6,F7. >> In fact, this SDP is specified by PABX. The third SDP >> answer is carried by F8,F9,F10. >> This SDP is specified by called party (Bob). >> >> As per the RFC3261 & RFC3264, the SDP answer carried >> by F6,F7 should match with F3 >> as far as B2BUA is concerned. Therefore, B2BUA shall >> ignore it. This is leading to >> the fact that SIP UA behind B2BUA can not listen to >> ringtone fed by PABX. >> Similarly, SDP answer carried by F8,F9,F10 shall be >> ignored. This shall lead to the fact >> that SIP UA behind B2BUA can not listen to Bob's >> voice. Too bad. >> This problem is due to the fact that RFC3261 & RFC3264 >> are not backward compatible. >> >> >> The sec 2.2. of >> draft-sawada-sipping-sip-offeranswer-01.txt indicates >> that UPDATE should >> be used to update the media in early media. But in >> practice old early-media flow (i.e., >> sending different SDPs over different 1xx responses of >> INVITE) is quite common. >> Can we somehow make new SDP offer/answer specified in >> RFC3261 & RFC3264 backward >> compatible? >> >> The old standard (early-media), allows multiple SDP >> answers of single SDP offer. can >> we somehow induce this thing in SDP offer/answer >> model? If many of you think the need >> of it then I may comeup with some thumb rule for the >> same. >> >> Thanks & Regards, >> Siddhartha > > > > > > --------------- > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. > --------------- > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 13:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgRE-0004mc-PQ; Mon, 13 Nov 2006 13:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjgRD-0004mO-L6 for sipping@ietf.org; Mon, 13 Nov 2006 13:21:43 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjgR7-0000h8-H0 for sipping@ietf.org; Mon, 13 Nov 2006 13:21:43 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.171,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Mon, 13 Nov 2006 18:19:34 +0000 From: "Siddhartha Bhakta" To: "'Paul Kyzivat'" , "'Siddhartha Bhakta'" Subject: RE: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt Date: Mon, 13 Nov 2006 18:19:27 -0000 Message-ID: <01b301c70750$43922da0$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccHTCHX5Z/pi/ACS16+TqyglWgXZAAAoWyA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4558B06B.20903@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Paul, The proxy and PABX in my figure are acting perfectly fine with the RFC2543 standard or any old standard that allows the PSTN like early-media flow. In those standards, multiple SDP answer of a single SDP was allowed. As soon as we upgrade our node to RFC3261, we are facing this problem. Can I say the offer/answer flow of RFC3261/RFC3264 is not backward compatible to older early-media standard? If that is the case, then I believe, we should try to make RFC3261/RFC3264 backward compatible otherwise people shall definitely face this problem. I thought, this draft shall be best place to address this issue. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 13 November 2006 17:51 To: Siddhartha Bhakta Cc: sipping@ietf.org; Siddhartha Bhakta Subject: Re: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt Siddhartha Bhakta wrote: > I am re-sending it as in last email, the figure was > distorted. > > Though, post RFC3261 drafts indicate that one valid > answer would be there for one SDP > offer, the our old friend early-media flow is still > present in practice. > > B2BUA/SBC Proxy PABX Bob > | | | | > | INVITE F1 | | | > |----------->| INVITE F2 | | > | 183 F3 |----------->| INVITE F4 | > |<-----------| |----------->| > | | | | > | | | 180 without SDP F5 > | | |<-----------| > | | | | > | | 180 with SDP F6 | > | 180 F7 |<-----------| | > |<-----------| | 200 F8 | > | | 200 F9 |<-----------| > | 200 F10 |<-----------| | > |<-----------| | | > | ACK F11 | | | > |----------->| ACK F12 | | > | |----------->| ACK F13 | > | | |----------->| In the above, F3 is illegal according to 3261, because this action is not permitted for proxies. It can be fixed by modeling another UA (an early media source) that the proxy forks to. F6 may also be illegal. It depends on whether the PABX is a proxy or a B2BUA. If a proxy then it too is illegal. > Our B2BUA is facing the problem as specified above. > The first answer is carried > by F3. This SDP is specified by Proxy. The 2nd SDP > answer is carried by F6,F7. > In fact, this SDP is specified by PABX. The third SDP > answer is carried by F8,F9,F10. > This SDP is specified by called party (Bob). > > As per the RFC3261 & RFC3264, the SDP answer carried > by F6,F7 should match with F3 > as far as B2BUA is concerned. This is not required if F3, F7, and F10 are all separate dialogs. If I understand what you are trying to accomplish, then that is the way to accomplish it. > Therefore, B2BUA shall > ignore it. This is leading to > the fact that SIP UA behind B2BUA can not listen to > ringtone fed by PABX. > Similarly, SDP answer carried by F8,F9,F10 shall be > ignored. This shall lead to the fact > that SIP UA behind B2BUA can not listen to Bob's > voice. Too bad. > This problem is due to the fact that RFC3261 & RFC3264 > are not backward compatible. If the three SDPs are generated independently then they can't be expected to obey the constraints imposed by being within a single dialog. Your problem is trying to force them to do so. > The sec 2.2. of > draft-sawada-sipping-sip-offeranswer-01.txt indicates > that UPDATE should > be used to update the media in early media. That would not solve your problem. It is concerned with a single dialog. You have a situation with multiple dialogs. Each must be considered separately. (However, you are not the first to raise this sort of issue. Perhaps it should be discussed in the draft.) > But in > practice old early-media flow (i.e., > sending different SDPs over different 1xx responses of > INVITE) is quite common. > Can we somehow make new SDP offer/answer specified in > RFC3261 & RFC3264 backward > compatible? > The old standard (early-media), allows multiple SDP > answers of single SDP offer. can > we somehow induce this thing in SDP offer/answer > model? If many of you think the need > of it then I may comeup with some thumb rule for the > same. IMO there is nothing to fix in the standards to solve your problem. What needs fixing are the sip implementations in some of the elements you are using. Paul > Thanks & Regards, > Siddhartha > > > > __________________________________________________________ > Yahoo! India Answers: Share what you know. Learn something new > http://in.answers.yahoo.com/ > > _______________________________________________ > 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 > --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 13:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjgrh-0005yr-Mc; Mon, 13 Nov 2006 13:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjgrg-0005lp-0u for sipping@ietf.org; Mon, 13 Nov 2006 13:49:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjglD-0003Nd-7E for sipping@ietf.org; Mon, 13 Nov 2006 13:42:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 10:42:22 -0800 X-IronPort-AV: i="4.09,418,1157353200"; d="scan'208"; a="344350726:sNHT170452176" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADIgLJ5028828; Mon, 13 Nov 2006 13:42:21 -0500 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 kADIgADU011100; Mon, 13 Nov 2006 13:42:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:42:20 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 13:42:19 -0500 Message-ID: <4558BC8B.6010700@cisco.com> Date: Mon, 13 Nov 2006 13:42:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt References: <01b301c70750$43922da0$3801a8c0@newportnetworks.com> In-Reply-To: <01b301c70750$43922da0$3801a8c0@newportnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2006 18:42:19.0967 (UTC) FILETIME=[7331C4F0:01C70753] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7032; t=1163443341; x=1164307341; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[SIPPING]=20SDP=20offer/answer=20in=20early=20media=3 A=09draft-sawada-sipping-sip-offeranswer-01.txt |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=X/6x6d21QRQw4h9Jybo82Z/mvfBPSTpL47sSp0oJ1mk=; b=N5u1vYtfjbr0mlaIf68l835O2WeAAAovRZQEFAjUyD2aolrRNyWaNDh4IqGPslvu0QWu4V8c I4iOEje+PNk+JoY4StBe0KoU352zxy8Idn7qIpvzC0gr5z0c2Qh3BMJa; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: sipping@ietf.org, 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > Paul, > > The proxy and PABX in my figure are acting perfectly fine with the RFC2543 > standard or any old standard that allows the PSTN like early-media flow. In > those standards, multiple SDP answer of a single SDP was allowed. > > As soon as we upgrade our node to RFC3261, we are facing this problem. Ah! This is the first time you have mentioned 2543. If it is compatibility with 2543 that you are concerned with, that is an entirely different story. And it is one that is largely not discussed in 3261, though 3261 took some pains to allow coexistence. Its been a very long time since I looked at 2543, so I won't claim to be able to give you an accurate answer with respect to that. In particular, I am not going to go digging to figure out whether what you are showing would be valid in 2543 or not. For the most part people now assume 3261 support, so you may have difficulty getting help with questions on 2543 compatibility. In any case, I disagree that your proxy is compliant with 2543. I'm pretty sure that even back then proxies were not allowed to generate an answer to an offer - that is a UA responsibility. > Can I say the offer/answer flow of RFC3261/RFC3264 is not backward > compatible to older early-media standard? I wasn't around when the backward compatibility issues of this were worked out, so somebody else will have to answer to that. > If that is the case, then I believe, we should try to make RFC3261/RFC3264 > backward compatible otherwise people shall definitely face this problem. I > thought, this draft shall be best place to address this issue. If there was a problem, it should have been caught before 3261 became an RFC. It has been an RFC so long, with so many implementations, that incompatible changes to it would be worse than the incompatibility with 2543. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 13 November 2006 17:51 > To: Siddhartha Bhakta > Cc: sipping@ietf.org; Siddhartha Bhakta > Subject: Re: [SIPPING] SDP offer/answer in early media: > draft-sawada-sipping-sip-offeranswer-01.txt > > > > Siddhartha Bhakta wrote: >> I am re-sending it as in last email, the figure was >> distorted. >> >> Though, post RFC3261 drafts indicate that one valid >> answer would be there for one SDP >> offer, the our old friend early-media flow is still >> present in practice. >> >> B2BUA/SBC Proxy PABX Bob >> | | | | >> | INVITE F1 | | | >> |----------->| INVITE F2 | | >> | 183 F3 |----------->| INVITE F4 | >> |<-----------| |----------->| >> | | | | >> | | | 180 without SDP F5 >> | | |<-----------| >> | | | | >> | | 180 with SDP F6 | >> | 180 F7 |<-----------| | >> |<-----------| | 200 F8 | >> | | 200 F9 |<-----------| >> | 200 F10 |<-----------| | >> |<-----------| | | >> | ACK F11 | | | >> |----------->| ACK F12 | | >> | |----------->| ACK F13 | >> | | |----------->| > > In the above, F3 is illegal according to 3261, because this action is > not permitted for proxies. It can be fixed by modeling another UA (an > early media source) that the proxy forks to. > > F6 may also be illegal. It depends on whether the PABX is a proxy or a > B2BUA. If a proxy then it too is illegal. > >> Our B2BUA is facing the problem as specified above. >> The first answer is carried >> by F3. This SDP is specified by Proxy. The 2nd SDP >> answer is carried by F6,F7. >> In fact, this SDP is specified by PABX. The third SDP >> answer is carried by F8,F9,F10. >> This SDP is specified by called party (Bob). >> >> As per the RFC3261 & RFC3264, the SDP answer carried >> by F6,F7 should match with F3 >> as far as B2BUA is concerned. > > This is not required if F3, F7, and F10 are all separate dialogs. If I > understand what you are trying to accomplish, then that is the way to > accomplish it. > >> Therefore, B2BUA shall >> ignore it. This is leading to >> the fact that SIP UA behind B2BUA can not listen to >> ringtone fed by PABX. >> Similarly, SDP answer carried by F8,F9,F10 shall be >> ignored. This shall lead to the fact >> that SIP UA behind B2BUA can not listen to Bob's >> voice. Too bad. >> This problem is due to the fact that RFC3261 & RFC3264 >> are not backward compatible. > > If the three SDPs are generated independently then they can't be > expected to obey the constraints imposed by being within a single > dialog. Your problem is trying to force them to do so. > >> The sec 2.2. of >> draft-sawada-sipping-sip-offeranswer-01.txt indicates >> that UPDATE should >> be used to update the media in early media. > > That would not solve your problem. It is concerned with a single dialog. > You have a situation with multiple dialogs. Each must be considered > separately. > > (However, you are not the first to raise this sort of issue. Perhaps it > should be discussed in the draft.) > >> But in >> practice old early-media flow (i.e., >> sending different SDPs over different 1xx responses of >> INVITE) is quite common. >> Can we somehow make new SDP offer/answer specified in >> RFC3261 & RFC3264 backward >> compatible? > >> The old standard (early-media), allows multiple SDP >> answers of single SDP offer. can >> we somehow induce this thing in SDP offer/answer >> model? If many of you think the need >> of it then I may comeup with some thumb rule for the >> same. > > IMO there is nothing to fix in the standards to solve your problem. What > needs fixing are the sip implementations in some of the elements you are > using. > > Paul > >> Thanks & Regards, >> Siddhartha >> >> >> >> __________________________________________________________ >> Yahoo! India Answers: Share what you know. Learn something new >> http://in.answers.yahoo.com/ >> >> _______________________________________________ >> 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 >> > > > > --------------- > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. > --------------- > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 13 14:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh2f-0001LI-88; Mon, 13 Nov 2006 14:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh2d-0001L6-Tn for sipping@ietf.org; Mon, 13 Nov 2006 14:00:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh2c-0006gO-8Z for sipping@ietf.org; Mon, 13 Nov 2006 14:00:23 -0500 Received: from [10.10.16.252] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kADI3wZX011026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Nov 2006 12:03:58 -0600 In-Reply-To: <4554CF49.5020804@alcatel.fr> References: <014a01c704e0$935e3a80$3801a8c0@newportnetworks.com> <4554CD54.1080309@cisco.com> <4554CF49.5020804@alcatel.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9903EFCE-A564-4CA6-8496-AC461E41FC7F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Mon, 13 Nov 2006 13:00:07 -0600 To: Thomas.Froment@alcatel.fr X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Paul Kyzivat , sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 10, 2006, at 1:13 PM, Thomas.Froment@alcatel.fr wrote: > In that case, why not completely deprecate forking itself? > .. just kidding ^_^... Pure genius! Best idea I've heard all week. Hey, I may not be allowed to suggest it myself, but I can applaud when someone else does. At least until the WG takes a hum on that one too . . . -- dean _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 00:11:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjqWv-0005ha-7Z; Tue, 14 Nov 2006 00:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjqWt-0005hT-12 for sipping@ietf.org; Tue, 14 Nov 2006 00:08:15 -0500 Received: from eastmail1.ntt-east.co.jp ([202.229.5.44] helo=evx1.enoc.east.ntt.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjqWr-000158-EC for sipping@ietf.org; Tue, 14 Nov 2006 00:08:15 -0500 Received: from emix1.enoc.east.ntt.co.jp by evx1.enoc.east.ntt.co.jp with ESMTP id kAE586Y15060; Tue, 14 Nov 2006 14:08:06 +0900 (JST) Received: from cip8.noc.east.ntt.co.jp by emix1.enoc.east.ntt.co.jp with ESMTP id kAE585x23052; Tue, 14 Nov 2006 14:08:05 +0900 (JST) Received: from mail.east.ntt.co.jp ([10.8.52.7]) by cip8.noc.east.ntt.co.jp (MOS 3.4.6-GR) with SMTP id CLQ26574; Tue, 14 Nov 2006 14:08:05 +0900 (JST) Message-Id: <200611140508.CLQ26574@cip8.noc.east.ntt.co.jp> Date: Tue, 14 Nov 2006 14:06:56 +0900 From: Miki HASEBE X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 To: lists@ohlmeier.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Paul Kyzivat , akihiro.shimizu@ntt-at.co.jp, sipping@ietf.org Subject: [Sipping] Re: Comments on draft-hasebe-sipping-race-examples-02 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Thank you for a lot of comments. I will correct the editorial errors that you pointed out in the next revision. Other comments are replied in-line. Nils Ohlmeier wrote: > Hello, > > please find my comments below from reviewing > draft-hasebe-sipping-race-examples-02.txt: > > page 5, 1st diagram: > Their are arrows missing in the lines for 2xx: > | | +-------------+--+ > should be > | | +------------>+<-+ > > page 6, 1st paragraph: > "The dialog which is to be terminated by BYE in > Early state." > What does this sentense mean? I'm sorry that the meaning of the sentence is unclear. The sentence is intended to explain the way that BYE works. I will modify it. > page 6, 1st diagram: > The same applies for the diagram above: > | | +-------------+--+ > should be > | | +------------>+<-+ > > Section 2 > The whole sections contains several references to > subsections 2.x which do not exist. Probably they > should refer to subsections 3.x. > > Page 10, 1st paragraph: > (UAs that do not deal with this bug still need to recognize the > retransmission relying on its From-tag and Call-ID, even though it > does not match the transaction.) > I think the UAS should recognize the request as a > retransmission by the CSeq. The From-tag and Call-ID should > lead to the same dialog even if the To-tag is missing. Surely, you are right. (but, I think that the detailed description may not be necessary, because the sentence in parentheses is not needed if SIP-UA supports #769 bug fix.) > Page 11, 1st call flow: > I think their is no RTP flowing, at least not from Alice to Bob. > As it is described in the text below on page 12 Alice sends the > BYE immediately after sending out the ACK for the 200 (INVITE). > I would assume that their is no microphone turned on any more on > Alice's UA which could record audio for any RTP. > Thus I would recommend to reduce the RTP stream to a one way from > Bob to Alice. I agree with you. Probably, Alice will not send RTP. I will modify it to "one way". > Page 12, 1st paragraph: > I would add here once again that this way of terminating an early > dialog is not recommended (like it was pointed out earlier already > in the draft). You pointed the first sentence of "Page 13", didn't you? (I understand that a sentence I should add is "sending BYE on Early dialog is not recommended", because BYE is sent on Early dialog on page 13.) If my understanding is correct, I would add the sentence. > Page 48, 3rd paragraph: > Their is a small typo in the first line: 'transactiuon' should be > 'transaction'. > > Page 48, 4th paragraph: > '... BYE with an appropriate certificate' their is no certificate > involved in digest authentication. I think the word 'certificate' > should be replaced with 'authentication header' or with 'credentials'. > > Regards > Nils Ohlmeier OK. I will modify it to "credential". Thank you for the comments on the draft. Any additional comments would be appreciated. Miki, _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 02:25:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjscu-0007Jy-ME; Tue, 14 Nov 2006 02:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjsct-0007Gg-E8 for sipping@ietf.org; Tue, 14 Nov 2006 02:22:35 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjscq-0003Hw-Ti for sipping@ietf.org; Tue, 14 Nov 2006 02:22:35 -0500 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id kAE7MQWD002543; Tue, 14 Nov 2006 08:22:26 +0100 In-Reply-To: <4552034D.8000005@bell-labs.com> Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery To: Volker Hilt X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Tue, 14 Nov 2006 08:22:24 +0100 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/14/2006 08:22:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Stability is an implicit requirement of every load control and overload protection mechanism (for network elements and networks targeting high system and/or service availability). The rational behind is the fact that any overload control may be modeled (& realized) as open or closed control loop. Any control arround signalling protocols is typically realized as closed loop (e.g. due to realtime background). A well designed closed control requires a proof of stability for the intended range of operation; stability is an implicit requirement from control theory, particularly for load control with stochastic components as in our case here. - Albrecht Volker Hilt bs.com> cc: sipping Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery 08.11.2006 17:18 I think that stability of overload control is an important requirement. We certainly want to avoid building something that starts to oscillate once it reaches overload state. It may be somehow implicit to REQ 1 since an unstable system will hardly be able to maintain the overall useful throughput at a high level. Volker Cullen Jennings wrote: > Clearly this was a long way from the text for a requirement but, yes, I > was proposing that this be added as one of the requirements. I don't > feel strongly about this and if we can't figure out how to express this > as a requirement that is useful, I can certainly live with not adding it. > > The reason I think it is a requirement is I can easily imagine that the > mechanism for doing overload push-back causes the systems to fail in the > way I described below (i.e. never recover back to steady state). > > > On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: > >> >> >> Cullen Jennings wrote: >> >>> A possible additional requirement.... >>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>> is in steady state doing 80cps with very few retransmission. Then >>> for 5 minutes the incoming requests goes to 500cps then drops back >>> to an incoming call rate of 80cps. The question is, how long before >>> the system gets back to the state where it if is successfully >>> processing all the 80cps? >> >> As soon as it can. Are you suggesting a requirement here? Seems like >> this is an implementation thing and wouldn't impact any protocol >> mechanisms. >> >>> I have seen systems that never recover - that is bad. I think one of >>> the design goals is that it is at least possible to build to systems >>> that recover back to steady state relatively quickly after an >>> overload impulse. >> >> Sure; but I'm not sure I see the protocol requirement. >> >> -Jonathan R. >> >> >> >> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > > _______________________________________________ > 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 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 03:27:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjtbO-0004wm-FT; Tue, 14 Nov 2006 03:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjtbM-0004wX-So for sipping@ietf.org; Tue, 14 Nov 2006 03:25:04 -0500 Received: from [202.177.174.130] (helo=mail.spanservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjtbL-00045p-GB for sipping@ietf.org; Tue, 14 Nov 2006 03:25:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Nov 2006 13:56:25 +0530 Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05ACD@mail.spanservices.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Malformed messages Thread-Index: AccHvuM5N03xMQS7Q1Obyrfcoj8lVQABoBjx References: From: "SUNIL J. KUMAR" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sipping] SIP Malformed messages X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, =20 Can any one provide info on all possible failure scenarios when a SIP = message is declared as Malformed Message at: =20 1. UAS for all received SIP Requests 2. UAC for all received SIP Responses =20 Similarily, is there anything related to SDP Malformed Body? =20 Thanks, Sunil _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 03:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjtnf-0004VG-4Z; Tue, 14 Nov 2006 03:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjtnc-0004V0-UN for sipping@ietf.org; Tue, 14 Nov 2006 03:37:44 -0500 Received: from hermes2.aegean.gr ([195.251.130.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjtnY-0005e2-Ez for sipping@ietf.org; Tue, 14 Nov 2006 03:37:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sipping] SIP Malformed messages Date: Tue, 14 Nov 2006 10:36:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Malformed messages Thread-Index: AccHvuM5N03xMQS7Q1Obyrfcoj8lVQABoBjxAACkVLY= References: <8DA47B9A5400DE40ADB30B051C215CCE02C05ACD@mail.spanservices.com> From: "Geneiatakis Dimitris" To: "SUNIL J. KUMAR" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963222281==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0963222281== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C707C8.05DC7047" This is a multi-part message in MIME format. ------_=_NextPart_001_01C707C8.05DC7047 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 You can find information about malformed messages in the following: 1) PROTOS test suite, = http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html 2) www.snocer.org Cheers=20 Dimitris -------------------------------------------------------------------------= ------- Dimitris Geneiatakis Research Assistant Laboratory of Information and Communication Systems Security = (Info-Sec-Lab) Department of Information and Communication Systems Engineering University of the Aegean Karlovassi, Samos, GR-83200, GREECE Tel: +30-22730-82247 Fax: +30-22730-82009 e-mail: dgen@aegean.gr -------------------------------------------------------------------------= ------- -----Original Message----- From: SUNIL J. KUMAR [mailto:sunilkumar_j@spanservices.com] Sent: Tue 11/14/2006 10:26 To: sipping@ietf.org Subject: [Sipping] SIP Malformed messages =20 Hi, =20 Can any one provide info on all possible failure scenarios when a SIP = message is declared as Malformed Message at: =20 1. UAS for all received SIP Requests 2. UAC for all received SIP Responses =20 Similarily, is there anything related to SDP Malformed Body? =20 Thanks, Sunil _______________________________________________ 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 ------_=_NextPart_001_01C707C8.05DC7047 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] SIP Malformed messages

Hi,
You can find information about malformed messages in the following:
1) PROTOS test suite, http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.= html
2) www.snocer.org

Cheers
Dimitris


-------------------------------------------------------------------------= -------
Dimitris Geneiatakis
Research Assistant
Laboratory of Information and Communication Systems Security = (Info-Sec-Lab)
Department of Information and Communication Systems Engineering
University of the Aegean
Karlovassi, Samos, GR-83200, GREECE
Tel: +30-22730-82247
Fax: +30-22730-82009
e-mail: dgen@aegean.gr
-------------------------------------------------------------------------= -------




-----Original Message-----
From: SUNIL J. KUMAR [mailto:sunilkumar_j@spanser= vices.com]
Sent: Tue 11/14/2006 10:26
To: sipping@ietf.org
Subject: [Sipping] SIP Malformed messages

Hi,

Can any one provide info on all possible failure scenarios when a SIP = message is declared as Malformed Message at:

1. UAS for all received SIP Requests
2. UAC for all received SIP Responses

Similarily, is there anything related to SDP Malformed Body?

Thanks,
Sunil

_______________________________________________
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

------_=_NextPart_001_01C707C8.05DC7047-- --===============0963222281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0963222281==-- From sipping-bounces@ietf.org Tue Nov 14 03:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gju7C-0005X8-P5; Tue, 14 Nov 2006 03:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gju7B-0005UA-8V for sipping@ietf.org; Tue, 14 Nov 2006 03:57:57 -0500 Received: from smtpauth01.csee.siteprotect.com ([64.41.126.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gju79-0008Sb-7s for sipping@ietf.org; Tue, 14 Nov 2006 03:57:57 -0500 Received: from gkheterpalpc01 (unknown [221.134.154.130]) by smtpauth01.csee.siteprotect.com (Postfix) with ESMTP id 75E6D32C041; Tue, 14 Nov 2006 02:56:54 -0600 (CST) From: "Gaurav Kheterpal" To: "'Geneiatakis Dimitris'" , "'SUNIL J. KUMAR'" , Subject: RE: [Sipping] SIP Malformed messages Date: Tue, 14 Nov 2006 14:30:14 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: thread-index: AccHvuM5N03xMQS7Q1Obyrfcoj8lVQABoBjxAACkVLYAAGWbwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-Id: <20061114085654.75E6D32C041@smtpauth01.csee.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1938637668==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1938637668== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C707F9.685D13D0" This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C707F9.685D13D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For a vendor independent/ standardized approach, you may refer to the 'SIP Torture Tests' on http://www.cs.columbia.edu/sip/sipit/torture.html It contains an exhaustive use cast list to ensure max inter-operability with other vendors & compliance to specifications. You may also refer to the following draft for a protocol independent approach: http://tools.ietf.org/wg/speermint/draft-niccolini-speermint-voipthreats-00. txt Regards, Gaurav _____ From: Geneiatakis Dimitris [mailto:dgen@aegean.gr] Sent: Tuesday, November 14, 2006 2:06 PM To: SUNIL J. KUMAR; sipping@ietf.org Subject: RE: [Sipping] SIP Malformed messages Hi, You can find information about malformed messages in the following: 1) PROTOS test suite, http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html 2) www.snocer.org Cheers Dimitris ---------------------------------------------------------------------------- ---- Dimitris Geneiatakis Research Assistant Laboratory of Information and Communication Systems Security (Info-Sec-Lab) Department of Information and Communication Systems Engineering University of the Aegean Karlovassi, Samos, GR-83200, GREECE Tel: +30-22730-82247 Fax: +30-22730-82009 e-mail: dgen@aegean.gr ---------------------------------------------------------------------------- ---- -----Original Message----- From: SUNIL J. KUMAR [mailto:sunilkumar_j@spanservices.com] Sent: Tue 11/14/2006 10:26 To: sipping@ietf.org Subject: [Sipping] SIP Malformed messages Hi, Can any one provide info on all possible failure scenarios when a SIP message is declared as Malformed Message at: 1. UAS for all received SIP Requests 2. UAC for all received SIP Responses Similarily, is there anything related to SDP Malformed Body? Thanks, Sunil _______________________________________________ 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 ------=_NextPart_000_003A_01C707F9.685D13D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sipping] SIP Malformed messages

For a vendor independent/ = standardized approach, you may refer to the ‘SIP Torture Tests’ on http://www.cs.= columbia.edu/sip/sipit/torture.html

 

It contains an exhaustive use = cast list to ensure max inter-operability with other vendors & compliance to = specifications.

 

You may also refer to the = following draft for a protocol independent approach:

 

http://tools.ietf.org/wg/speermint/draft-niccolini-speerm= int-voipthreats-00.txt

 

Regards,
Gaurav

 

From: = Geneiatakis Dimitris [mailto:dgen@aegean.gr]
Sent: Tuesday, November = 14, 2006 2:06 PM
To: SUNIL J. KUMAR; = sipping@ietf.org
Subject: RE: [Sipping] = SIP Malformed messages

 

Hi,
You can find information about malformed messages in the following:
1) PROTOS test suite, http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.= html
2) www.snocer.org

Cheers
Dimitris


-------------------------------------------------------------------------= -------
Dimitris Geneiatakis
Research Assistant
Laboratory of Information and Communication Systems Security = (Info-Sec-Lab)
Department of Information and Communication Systems Engineering
University of the Aegean
Karlovassi, Samos, GR-83200, GREECE
Tel: +30-22730-82247
Fax: +30-22730-82009
e-mail: dgen@aegean.gr
-------------------------------------------------------------------------= -------




-----Original Message-----
From: SUNIL J. KUMAR [mailto:sunilkumar_j@spanser= vices.com]
Sent: Tue 11/14/2006 10:26
To: sipping@ietf.org
Subject: [Sipping] SIP Malformed messages

Hi,

Can any one provide info on all possible failure scenarios when a SIP = message is declared as Malformed Message at:

1. UAS for all received SIP Requests
2. UAC for all received SIP Responses

Similarily, is there anything related to SDP Malformed Body?

Thanks,
Sunil

_______________________________________________
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

------=_NextPart_000_003A_01C707F9.685D13D0-- --===============1938637668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1938637668==-- From sipping-bounces@ietf.org Tue Nov 14 07:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjxCf-0008PD-1R; Tue, 14 Nov 2006 07:15:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjxCd-0008P8-D6 for sipping@ietf.org; Tue, 14 Nov 2006 07:15:47 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjxCb-0000Ut-1S for sipping@ietf.org; Tue, 14 Nov 2006 07:15:47 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.171,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Tue, 14 Nov 2006 12:13:27 +0000 From: "Siddhartha Bhakta" To: "'Paul Kyzivat'" Subject: RE: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 12:13:20 -0000 Message-ID: <01e301c707e6$48c45f50$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccHU2MepZnq+ZYRSkSbCvSqOIc9PgAhVIWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4558BC8B.6010700@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: sipping@ietf.org, 'Siddhartha Bhakta' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Paul, The PABX in my example is a B2BUA. But 180(F6) and 200(F9) generated by it is having same to-tag but they are carrying different SDPs. The PABX vendors are claiming that below mentioned flow is as per RFC2543. I could not counter it as I could not find out the reference where RFC2543 is preventing it. For a Media server(IVR) implementation, the tone (183) and voice (200) might contain different media description as that were not prevented in RFC2543. The RFC2543 compliant Media server shall not put different to-tag in 183 and 200 for sure as it is not the forking case. Now, if any RFC3261 compliant phone does not apply SDP of 200 OK then it can not hear the voice. Now, it's down to the fact whether RFC3261 supports the co-existence to RFC2543 or not. I hope, I am not the only one who faced this problem. We are going beyond RFC3261 (in our implementation) to support the co-existence of RFC3261 and RFC2543. But it would have been better if RFC3261 itself could have addressed this. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 13 November 2006 18:42 To: Siddhartha Bhakta Cc: 'Siddhartha Bhakta'; sipping@ietf.org Subject: Re: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt Siddhartha Bhakta wrote: > Paul, > > The proxy and PABX in my figure are acting perfectly fine with the RFC2543 > standard or any old standard that allows the PSTN like early-media flow. In > those standards, multiple SDP answer of a single SDP was allowed. > > As soon as we upgrade our node to RFC3261, we are facing this problem. Ah! This is the first time you have mentioned 2543. If it is compatibility with 2543 that you are concerned with, that is an entirely different story. And it is one that is largely not discussed in 3261, though 3261 took some pains to allow coexistence. Its been a very long time since I looked at 2543, so I won't claim to be able to give you an accurate answer with respect to that. In particular, I am not going to go digging to figure out whether what you are showing would be valid in 2543 or not. For the most part people now assume 3261 support, so you may have difficulty getting help with questions on 2543 compatibility. In any case, I disagree that your proxy is compliant with 2543. I'm pretty sure that even back then proxies were not allowed to generate an answer to an offer - that is a UA responsibility. > Can I say the offer/answer flow of RFC3261/RFC3264 is not backward > compatible to older early-media standard? I wasn't around when the backward compatibility issues of this were worked out, so somebody else will have to answer to that. > If that is the case, then I believe, we should try to make RFC3261/RFC3264 > backward compatible otherwise people shall definitely face this problem. I > thought, this draft shall be best place to address this issue. If there was a problem, it should have been caught before 3261 became an RFC. It has been an RFC so long, with so many implementations, that incompatible changes to it would be worse than the incompatibility with 2543. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 13 November 2006 17:51 > To: Siddhartha Bhakta > Cc: sipping@ietf.org; Siddhartha Bhakta > Subject: Re: [SIPPING] SDP offer/answer in early media: > draft-sawada-sipping-sip-offeranswer-01.txt > > > > Siddhartha Bhakta wrote: >> I am re-sending it as in last email, the figure was >> distorted. >> >> Though, post RFC3261 drafts indicate that one valid >> answer would be there for one SDP >> offer, the our old friend early-media flow is still >> present in practice. >> >> B2BUA/SBC Proxy PABX Bob >> | | | | >> | INVITE F1 | | | >> |----------->| INVITE F2 | | >> | 183 F3 |----------->| INVITE F4 | >> |<-----------| |----------->| >> | | | | >> | | | 180 without SDP F5 >> | | |<-----------| >> | | | | >> | | 180 with SDP F6 | >> | 180 F7 |<-----------| | >> |<-----------| | 200 F8 | >> | | 200 F9 |<-----------| >> | 200 F10 |<-----------| | >> |<-----------| | | >> | ACK F11 | | | >> |----------->| ACK F12 | | >> | |----------->| ACK F13 | >> | | |----------->| > > In the above, F3 is illegal according to 3261, because this action is > not permitted for proxies. It can be fixed by modeling another UA (an > early media source) that the proxy forks to. > > F6 may also be illegal. It depends on whether the PABX is a proxy or a > B2BUA. If a proxy then it too is illegal. > >> Our B2BUA is facing the problem as specified above. >> The first answer is carried >> by F3. This SDP is specified by Proxy. The 2nd SDP >> answer is carried by F6,F7. >> In fact, this SDP is specified by PABX. The third SDP >> answer is carried by F8,F9,F10. >> This SDP is specified by called party (Bob). >> >> As per the RFC3261 & RFC3264, the SDP answer carried >> by F6,F7 should match with F3 >> as far as B2BUA is concerned. > > This is not required if F3, F7, and F10 are all separate dialogs. If I > understand what you are trying to accomplish, then that is the way to > accomplish it. > >> Therefore, B2BUA shall >> ignore it. This is leading to >> the fact that SIP UA behind B2BUA can not listen to >> ringtone fed by PABX. >> Similarly, SDP answer carried by F8,F9,F10 shall be >> ignored. This shall lead to the fact >> that SIP UA behind B2BUA can not listen to Bob's >> voice. Too bad. >> This problem is due to the fact that RFC3261 & RFC3264 >> are not backward compatible. > > If the three SDPs are generated independently then they can't be > expected to obey the constraints imposed by being within a single > dialog. Your problem is trying to force them to do so. > >> The sec 2.2. of >> draft-sawada-sipping-sip-offeranswer-01.txt indicates >> that UPDATE should >> be used to update the media in early media. > > That would not solve your problem. It is concerned with a single dialog. > You have a situation with multiple dialogs. Each must be considered > separately. > > (However, you are not the first to raise this sort of issue. Perhaps it > should be discussed in the draft.) > >> But in >> practice old early-media flow (i.e., >> sending different SDPs over different 1xx responses of >> INVITE) is quite common. >> Can we somehow make new SDP offer/answer specified in >> RFC3261 & RFC3264 backward >> compatible? > >> The old standard (early-media), allows multiple SDP >> answers of single SDP offer. can >> we somehow induce this thing in SDP offer/answer >> model? If many of you think the need >> of it then I may comeup with some thumb rule for the >> same. > > IMO there is nothing to fix in the standards to solve your problem. What > needs fixing are the sip implementations in some of the elements you are > using. > > Paul > >> Thanks & Regards, >> Siddhartha >> >> >> >> __________________________________________________________ >> Yahoo! India Answers: Share what you know. Learn something new >> http://in.answers.yahoo.com/ >> >> _______________________________________________ >> 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 >> > > > > --------------- > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. > --------------- > --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 10:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0NO-0007Pp-07; Tue, 14 Nov 2006 10:39:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0NM-0007Oe-6b for sipping@ietf.org; Tue, 14 Nov 2006 10:39:04 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0NL-0004Fy-04 for sipping@ietf.org; Tue, 14 Nov 2006 10:39:04 -0500 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 10:38:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 10:38:38 -0500 Message-ID: <77BD870EA838FC469FDD2AE248B1357B017895E6@ATL1VEXC008.usdom003.tco.tc> In-reply-to: <01e301c707e6$48c45f50$3801a8c0@newportnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AccHU2MepZnq+ZYRSkSbCvSqOIc9PgAhVIWQAAdnFeA= From: "Brett Tate" To: "Siddhartha Bhakta" X-OriginalArrivalTime: 14 Nov 2006 15:38:55.0169 (UTC) FILETIME=[FE3C9B10:01C70802] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > The PABX in my example is a B2BUA. But 180(F6) and 200(F9)=20 > generated by it is having same to-tag but they are carrying=20 > different SDPs. The PABX vendors are claiming that below=20 > mentioned flow is as per RFC2543. I could not counter it as I=20 > could not find out the reference where RFC2543 is preventing it. It was considered that rfc2543 allowed too much flexibility/ambiguity from an SDP offer/answer perspective; and thus it was considered not interoperable. Subsequent drafts reduced much of the flexibility/ambiguity and that was what many vendors implemented. For better or worse, rfc3261 (and other offer/answer RFCs) removed even more of the flexibility. > Now, it's down to the fact whether RFC3261 supports the=20 > co-existence to RFC2543 or not. I hope, I am not the=20 > only one who faced this problem. We are going=20 > beyond RFC3261 (in our implementation)=20 > to support the co-existence of RFC3261 and RFC2543.=20 > But it would have been better if RFC3261=20 > itself could have addressed this. I agree. However many considered rfc2543's ambiguity/flexibility unworkable; thus there was little associated backward compatibility consideration given to rfc2543. As you are experiencing, a large complaint with rfc3261 was not allowing the SDPs to change (and not be ignored) within subsequent 18x's and 2xx. When rfc3311 and rfc3262 not supported/adequate and such SDP modification is desired, it forces forking proxy simulations to remain compliant to rfc3261 and rfc3264. Without the caller relaxing some of the offer/answer rules of rfc3261, rfc3264, etcetera, it will have problems interacting with devices not yet compliant. _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 11:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ov-0002mB-Cl; Tue, 14 Nov 2006 11:07:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ot-0002hA-Bn for sipping@ietf.org; Tue, 14 Nov 2006 11:07:31 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0mU-0008QW-QN for sipping@ietf.org; Tue, 14 Nov 2006 11:05:05 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.186,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027,SARE_SUB_MOBFU_2: 0.712 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Tue, 14 Nov 2006 16:03:11 +0000 From: "Siddhartha Bhakta" To: "'Brett Tate'" Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 16:03:04 -0000 Message-ID: <020d01c70806$6098c880$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccHU2MepZnq+ZYRSkSbCvSqOIc9PgAhVIWQAAdnFeAAA4xCUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <77BD870EA838FC469FDD2AE248B1357B017895E6@ATL1VEXC008.usdom003.tco.tc> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thanks Brett. From your reply I could understand that the problem we are facing is unavoidable. It is resulted not due to our lack of understanding about RFC3261 but due to backward incompatibility of RFC3261 to RFC2543. Thanks to Paul and Hadriel also for their time. -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 14 November 2006 15:39 To: Siddhartha Bhakta Cc: sipping@ietf.org Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt > The PABX in my example is a B2BUA. But 180(F6) and 200(F9) > generated by it is having same to-tag but they are carrying > different SDPs. The PABX vendors are claiming that below > mentioned flow is as per RFC2543. I could not counter it as I > could not find out the reference where RFC2543 is preventing it. It was considered that rfc2543 allowed too much flexibility/ambiguity from an SDP offer/answer perspective; and thus it was considered not interoperable. Subsequent drafts reduced much of the flexibility/ambiguity and that was what many vendors implemented. For better or worse, rfc3261 (and other offer/answer RFCs) removed even more of the flexibility. > Now, it's down to the fact whether RFC3261 supports the > co-existence to RFC2543 or not. I hope, I am not the > only one who faced this problem. We are going > beyond RFC3261 (in our implementation) > to support the co-existence of RFC3261 and RFC2543. > But it would have been better if RFC3261 > itself could have addressed this. I agree. However many considered rfc2543's ambiguity/flexibility unworkable; thus there was little associated backward compatibility consideration given to rfc2543. As you are experiencing, a large complaint with rfc3261 was not allowing the SDPs to change (and not be ignored) within subsequent 18x's and 2xx. When rfc3311 and rfc3262 not supported/adequate and such SDP modification is desired, it forces forking proxy simulations to remain compliant to rfc3261 and rfc3264. Without the caller relaxing some of the offer/answer rules of rfc3261, rfc3264, etcetera, it will have problems interacting with devices not yet compliant. --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 11:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0zL-0007Yi-F6; Tue, 14 Nov 2006 11:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0pG-000301-Qd for sipping@ietf.org; Tue, 14 Nov 2006 11:07:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0dZ-0007Ef-VM for sipping@ietf.org; Tue, 14 Nov 2006 10:55:51 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 07:55:49 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAEFtnlH007685 for ; Tue, 14 Nov 2006 07:55:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEFtnio025039 for ; Tue, 14 Nov 2006 07:55:49 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 07:55:49 -0800 Received: from [192.168.1.3] ([10.21.115.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 07:55:49 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4AC0C620-96D4-40CF-AB04-B0232C8E06C3@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping From: Cullen Jennings Date: Tue, 14 Nov 2006 07:55:55 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Nov 2006 15:55:49.0131 (UTC) FILETIME=[5A9AEDB0:01C70805] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=230; t=1163519749; x=1164383749; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20STUN=20bis=20is=20in=20WGLC=20in=20BEHAVE |Sender:=20; bh=25wUO5LwnPz9AvQLRzEsyvAIokzc95hgT6NXioluC4k=; b=IuXzEFXw67kj8P5e6Ni/wirGDGNyQzF81Xy2raiQQU5BRCH7ZUztAC5JI8r5ARwjPZaCKKuV xacDGxH1qAugbUVdPT8WHn7zhhG4dNCctV5RoY5KXdWH/tOOk+iL8vj/; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sipping] STUN bis is in WGLC in BEHAVE X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org STUN is in WGLC in the BAHAVE WG. This is pretty relevant to ICE so you might want to read it if you are following ICE. Please send comments to the behave list and don't reply to this email. Cullen _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 12:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk290-00018F-VG; Tue, 14 Nov 2006 12:32:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk28z-00016w-Gw for sipping@ietf.org; Tue, 14 Nov 2006 12:32:21 -0500 Received: from web8701.mail.in.yahoo.com ([203.84.221.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk28w-0005tL-FO for sipping@ietf.org; Tue, 14 Nov 2006 12:32:21 -0500 Received: (qmail 58673 invoked by uid 60001); 14 Nov 2006 17:31:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4Wl398RmZeFDyzxgLrSjPDQ5vdOemm/OljcYtsqEJideBAZYljs8qbh67z1D4mmEKoe0X02/bDCQamCBdyfoKy1JhbIHoorj0qPrm/Yt/VqLOcTYBf3y68Hn8qh799hp9M5cRtJ/BhTBciO+6dDBZroPvXHmE3QbzpYcFoOh4Fs= ; Message-ID: <20061114173159.58671.qmail@web8701.mail.in.yahoo.com> Received: from [217.45.197.113] by web8701.mail.in.yahoo.com via HTTP; Tue, 14 Nov 2006 17:31:59 GMT Date: Tue, 14 Nov 2006 17:31:59 +0000 (GMT) From: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Paul Kyzivat In-Reply-To: <4558B3E6.1030404@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > > If 4xx-6xx > > is received then depending on the via branch > > parameter, forking proxy can know which dialog is > > being terminated. > > This happens to work because only a single > non-successful final response > is ever returned. Note that this implies the > termination of *all* early > dialogs that might have been established. (There may > have been more than > one.) So far, I thought that each of the forked INVITE transactions shall be managed independently. The 4xx of one INVITE shall not affect other INVITE transactions. Atleast "2.12. Single Line Extension" of draft-ietf-sipping-service-examples-10.txt indicates so. After F8(480 Not Logged In) receiving also, Proxy was continuing with the INVITE transaction with User B3. It will be really surprising to me if you say that call flow in 2.12 of Single Line Extension" of draft-ietf-sipping-service-examples-10.txt is not as per RFC3261. The reason is twofold. Firstly, this draft is proposed(March, 2006) long after RFC3261. Secondly, the forking proxes I came across do follow the draft-ietf-sipping-service-examples-10.txt instead of what you are saying. If I accept your comment, then I can say parallel forking is not possible. Or atleast, parallel forking will not be safe. If any instance of a given user returns 4xx-6xx then all other forked INVITE transaction shall be terminated. Only sequencial forking shall be possible. On receiving final error response from one INVITE, the forking proxy can send another forked INVITE. Not before that. This shall impose time constraint to any SIP services based on SIP forking. I can see that draft-ietf-sipping-service-examples-11 does not mention any parallel forking. All the forkings in this draft are sequencial. The "Single Line Extension" is also removed from this draft. > > About point 3) I can say that not to-tag but Via > > Branch parameter of SIP responses helps forking > proxy > > to associate those with any forked dialog. > > I disagree. The branch parameter associates the > response with a > particular request. > > It is the Call-ID, To-tag, and From-tag that > identify a particular > dialog. In the forking case, the To-tags are not > initially known to the > UAC. So the Call-ID and From-tag define a > half-formed dialog, and each > response with a unique To-tag defines a new dialog. > > If you try to associate the half-formed dialog with > the > invite-transaction you may have trouble with some > things. Of particular > note, once you receive one 2xx response, you may > have difficulty > establishing added dialogs for other 2xx responses > that might arrive. > > There is even more difficulty in case of > subscribe/notify. In that case, > extra dialogs may be established based on received > NOTIFY requests which > aren't tied to the SUBSCRIBE by branch, only by > callid and tags. We came across following call flow from the deployment, Proxy OUR-NODE User2 User | | | | | INVITE F1 | | | |----------->| INVITE F2 | | | |----------->| | | | 183 F3 | | | 183 F4 |<-----------| | |<-----------| | | Request Timesout | | | | | | | CANCEL F5 | | | |----------->| CANCEL F6 | | | |----------->| | | INVITE F7 | | | |----------->| INVITE F8 | | | |------------------------>| | | 200 F9 | | | 200 F10 |<-----------| | |<-----------| | | | | 487 F11 | | | 487 F12 |<-----------| | |<-----------| | | | ACK F13 | | | |----------->| ACK F14 | | | |----------->| | | | | | | | 200 F15 | | | 200 F16 |<------------------------| |<-----------| | | | ACK F17 | | | |----------->| ACK F18 | | | |------------------------>| | | | | | | | | If OUR-NODE is RFC3261 compliant Proxy then it shall terminate other early dialog (created by 180; not shown) on receiving 487 F11. Therefore, the overlapped forking as specified above shall be prevented by OUR-NODE. Only solution was to create separate half-formed dialog for separate INVITE. This shall be done if we consider the as the half-formed dialog. As soon as to-tag shall be received the dialog shall be created with . I believe, in RFC2543, branch parameter was used to associate response with any forked SIP Request. For the above flow, OUR-NODE could have delayed the 2nd INVITE but this approach can not save us if OUR-NODE is placed between Forking Proxy and Users in "2.12 of Single Line Extension" call flow of draft-ietf-sipping-service-examples-10.txt. However, you have rightly pointed out the SUBSCRIBE-NOTIFY case, where the above approach shall definitely fail as NOTIFY may create dialog initiated by SUBSCRIBE. I always feel the special handling for SUBSCRIBE-NOTIFY was not really necessary. If so, then why it is not written that UPDATE can create the dialog initiated by INVITE message. Due to network problem, UPDATE can also reach to Caller before first 1xx(non 100) response from Called party. Thanks and Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 12:38:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2F0-0004fv-Pf; Tue, 14 Nov 2006 12:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2Ey-0004ea-8F for sipping@ietf.org; Tue, 14 Nov 2006 12:38:32 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2Eu-0006oq-FX for sipping@ietf.org; Tue, 14 Nov 2006 12:38:32 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.151,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_MESSAGE: 0.001,SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Tue, 14 Nov 2006 17:36:38 +0000 From: "Siddhartha Bhakta" To: , "'Paul Kyzivat'" Date: Tue, 14 Nov 2006 17:36:31 -0000 Message-ID: <021901c70813$6eae3560$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccIE2wpVQte41urRri6IDFwF4RCvA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: bf298c52ab1dc9f39fd87b679918f163 Cc: sipping@ietf.org Subject: [Sipping] SDP Rollback in draft-sawada-sipping-sip-offeranswer-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139575379==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0139575379== Content-Type: multipart/alternative; boundary="----=_NextPart_000_021A_01C70813.6EAE3560" This is a multi-part message in MIME format. ------=_NextPart_000_021A_01C70813.6EAE3560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am not sure (as I am a very new user to SIPPING group) whether SDP rollback has ever been discussed regarding this draft or not. I personally feel that 'SDP rollback' is very relevant topics regarding this draft. The sec 1.2 indicates the response(488) to reject any SDP offer. But the missing part is that if any SIP request carrying SDP offer is rejected by 3xx-6xx then SDP offer should be rolled-back. The rollback means, applying last session description. Rather than specifying different SIP messages separately, it would be better to have some thumb rule that shall be quite easy to follow as far as SDP rollback is concerned. I am proposing following thumb rule. Please indicate whether that makes sense or not. The SDP rollback shall be associated with transaction rollback/rejection. [1] If the transaction request (carrying SDP offer) is rejected then SDP offer shall be rolled-back. The exception is the ACK request. The ACK (of 2xx) can not be rejected. (The ACK of 3xx-6xx is not the transaction initiating request). [2] If any transaction request carries SDP answer (e.g., ACK or PRACK) then that transaction can not rejected as there shall be the confusion over whether SDP shall be rolled-back or not. I suppose, SDP answer can not be rolled-back. There is no confusion for ACK, as it can not rejected but for PRACK the restriction should be there that it can not be rejected if it carries SDP answer. This draft says that PRACK(irrespective of whether it is carrying SDP offer/answer) can not be rejected. I can not understand the rationale about this statement. Though, I can appreciate why PRACK MUST not be rejected if it carries SDP answer. [3] If any SIP response contains SDP offer then that SDP can not be rolled-back. If any SIP entity wants to rollback the SDP offer carried by SIP response, it should initiate a SIP transaction carrying old SDP to accomplish it. There is a special case for re-INVITE. If multiple SDP offer/answer happens(using PRACK/UPDATE) within re-INVITE transaction and re-INVITE is rejected by 4xx-6xx then whether all the SDP offer/answer happens within re-INVITE transaction shall be rolled-back or not. My suggestion would be that once SDP offer/answer is completed, that can not rolled-back by means of transaction rejection. That means, all the completed SDP offer/answer shall not be rolled-back due to 4xx-6xx of re-INVITE. This decision shall save the work of SIP UA, SIP SBC, B2BUA etc. that follows SDP offer/answer state. Please comment. Thanks and Regards, Siddhartha --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_021A_01C70813.6EAE3560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am = not sure (as I am a very new user to SIPPING

group) = whether SDP rollback has ever been discussed

regarding this draft or not. I personally feel that

'SDP = rollback' is very relevant topics regarding this

draft.

 

The = sec 1.2 indicates the response(488) to reject any

SDP = offer. But the missing part is that if any SIP

request carrying SDP offer is rejected by 3xx-6xx then

SDP = offer should be rolled-back. The rollback means,

applying last session description.

 

Rather = than specifying different SIP messages

separately, it would be better to have some thumb rule

that = shall be quite easy to follow as far as SDP

rollback is concerned. I am proposing following thumb

rule. = Please indicate whether that makes sense or not.

 

The = SDP rollback shall be associated with transaction

rollback/rejection.

 

[1] If = the transaction request (carrying SDP offer) is

rejected then SDP offer shall be rolled-back. The

exception is the ACK request. The ACK (of 2xx) can not

be = rejected. (The ACK of 3xx-6xx is not the

transaction initiating request).

 

[2] If = any transaction request carries SDP answer

(e.g., = ACK or PRACK) then that transaction can not

rejected as there shall be the confusion over whether

SDP = shall be rolled-back or not. I suppose, SDP answer

can = not be rolled-back. There is no confusion for ACK,

as it = can not rejected but for PRACK the restriction

should = be there that it can not be rejected if it

carries SDP answer.

 

This = draft says that PRACK(irrespective of whether it

is = carrying SDP offer/answer) can not be rejected. I

can = not understand the rationale about this = statement.

Though, I can appreciate why PRACK MUST not be

rejected if it carries SDP answer.

 

[3] If = any SIP response contains SDP offer then that

SDP = can not be rolled-back. If any SIP entity wants to

rollback the SDP offer carried by SIP response, it

should = initiate a SIP transaction carrying old SDP to

accomplish it.

 

There = is a special case for re-INVITE. If multiple SDP

offer/answer happens(using PRACK/UPDATE) within

re-INVITE transaction and re-INVITE is rejected by

4xx-6xx then whether all the SDP offer/answer happens

within = re-INVITE transaction shall be rolled-back or

not. = My suggestion would be that once SDP = offer/answer

is = completed, that can not rolled-back by means of

transaction rejection. That means, all the completed

SDP = offer/answer shall not be rolled-back due to

4xx-6xx of re-INVITE. This decision shall save the

work = of SIP UA, SIP SBC, B2BUA etc. that follows SDP

offer/answer state.

 

Please = comment.

 

 

Thanks = and Regards,

Siddhartha

 



---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_021A_01C70813.6EAE3560-- --===============0139575379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0139575379==-- From sipping-bounces@ietf.org Tue Nov 14 12:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2RC-0002Y7-5O; Tue, 14 Nov 2006 12:51:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2RA-0002Y1-4F for sipping@ietf.org; Tue, 14 Nov 2006 12:51:08 -0500 Received: from web8705.mail.in.yahoo.com ([203.84.221.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk2R6-0000FQ-AJ for sipping@ietf.org; Tue, 14 Nov 2006 12:51:08 -0500 Received: (qmail 42643 invoked by uid 60001); 14 Nov 2006 17:51:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OMpifpC8zBSctvR6AAQsP2fbLJKdNWXZKpbvCiFkoStcsNalKlPy5Ub5b4rZ8EvpJD+M6B/B6PUjv/CImWO9CLvhFB0Px1HjJ7LrougXxN3G/qKq46M1MwDPTYs8mevWxhrTsvN+dFy0uhfXdlJ5/elVEaFteeM1PHNDoiwD4AY= ; Message-ID: <20061114175102.42641.qmail@web8705.mail.in.yahoo.com> Received: from [217.45.197.113] by web8705.mail.in.yahoo.com via HTTP; Tue, 14 Nov 2006 17:51:02 GMT Date: Tue, 14 Nov 2006 17:51:02 +0000 (GMT) From: Siddhartha Bhakta Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Brett Tate , sipping@ietf.org, Paul Kyzivat In-Reply-To: <77BD870EA838FC469FDD2AE248B1357B0178914D@ATL1VEXC008.usdom003.tco.tc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brett/Paul, In sec 2.9, if you consider Alice only then you can see that F5 creates a dialog-ID1{Local-tag=1234567, remote-tag=3145678, call-id=12345600@atlanta.example.com}. The F10 creates another dialog-ID2{Local-tag=1234567, remote-tag=9214d, call-id=12345600@atlanta.example.com}. Subsequently, F13 creates dialog-ID3{Local-tag=1234567, remote-tag=765432, call-id=12345600@atlanta.example.com}. Neither Alice is sending CANCEL for dialog-ID1 & dialog-ID2, nor Proxy is sending 3xx-6xx to Alice for dialog-ID1 & dialog-ID2. How dialog-ID1 & dialog-ID2 shall be terminated at Alice? You are possibly suggesting Alice to send BYE on those dialog! But that is missing in sec 2.9. Please comment. --- Brett Tate wrote: > > > Your point 2) and 3) ensures that Alice can manage > three > > dilaogs properly. If point 1) is implemented then > I can not > > understand how the dialogs created by > > F5 and F10 shall be terminated at Alice in sec > 2.9. > > The dialog created by F13 is terminated by > BYE(F18) as far as > > Alice is concerned. I have asked this question > earlier also. > > I am yet to get answer from anyone! > > The forking proxy terminates them per rfc3261 > section 16.7 step 10. > Otherwise during race conditions or when the caller > wants to release a > particular dialog, the caller can send a BYE for the > individual dialog. > > __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 13:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2uY-0006re-77; Tue, 14 Nov 2006 13:21:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2uX-0006rQ-1n for sipping@ietf.org; Tue, 14 Nov 2006 13:21:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2uU-0004AJ-25 for sipping@ietf.org; Tue, 14 Nov 2006 13:21:29 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 10:21:25 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kAEILP2S011680; Tue, 14 Nov 2006 10:21:25 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAEILCdU000093; Tue, 14 Nov 2006 10:21:24 -0800 (PST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 13:21:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] SDP Rollback indraft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 13:21:17 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E0258EDF7@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SDP Rollback indraft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AccIE2wpVQte41urRri6IDFwF4RCvAABWQGQ From: "Sanjay Sinha \(sanjsinh\)" To: "Siddhartha Bhakta" , , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 14 Nov 2006 18:21:19.0661 (UTC) FILETIME=[AE6815D0:01C70819] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=22789; t=1163528485; x=1164392485; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:=20RE=3A=20[Sipping]=20SDP=20Rollback=20indraft-sawada-sipping-s ip-offeranswer-01.txt |Sender:=20; bh=4UxI2YsQFTc4tDux5LUFPEuPc+G58V6L4bpg02pTeWE=; b=UdzZMVzDY5M+wE9ia1uFpqfEkU7p3dFHi4aTZWUMZKMnJht2jTUdq0/Ja0zqaxAcOWMrvUM3 jEa5uvMW24h/H+/a8hE9Yh0qjXolp3mMrapxUChKr04MLIL0SIo4QEHt; Authentication-Results: sj-dkim-6; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 94375f06b91351a23b2e62bbf6b5a18c Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1139725983==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1139725983== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70819.ADC57430" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70819.ADC57430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SDP rollback applies only if previously there has been an offer-answer exchange and an early dialog or a confirmed dialog has been established. In that case, if SDP in re-Invite/UPDATE is rejected, then session continues with previously negotiated characteristics. This is mentioned in RFC 3261. And this draft does mention that if offer in Prack or in a sip response is rejected, then answerer has to send an updated offer. So I am not sure how is the new proposal different than what has been already stated. =20 Sanjay ________________________________ From: Siddhartha Bhakta [mailto:Siddhartha.Bhakta@newport-networks.com]=20 Sent: Tuesday, November 14, 2006 12:37 PM To: tu-sawada@kddi.com; Paul Kyzivat (pkyzivat) Cc: sipping@ietf.org Subject: [Sipping] SDP Rollback indraft-sawada-sipping-sip-offeranswer-01.txt =09 =09 Hi, =20 I am not sure (as I am a very new user to SIPPING group) whether SDP rollback has ever been discussed regarding this draft or not. I personally feel that 'SDP rollback' is very relevant topics regarding this draft. =20 The sec 1.2 indicates the response(488) to reject any SDP offer. But the missing part is that if any SIP request carrying SDP offer is rejected by 3xx-6xx then SDP offer should be rolled-back. The rollback means, applying last session description. =20 Rather than specifying different SIP messages separately, it would be better to have some thumb rule that shall be quite easy to follow as far as SDP rollback is concerned. I am proposing following thumb rule. Please indicate whether that makes sense or not. =20 The SDP rollback shall be associated with transaction rollback/rejection. =20 [1] If the transaction request (carrying SDP offer) is rejected then SDP offer shall be rolled-back. The exception is the ACK request. The ACK (of 2xx) can not be rejected. (The ACK of 3xx-6xx is not the transaction initiating request). =20 [2] If any transaction request carries SDP answer (e.g., ACK or PRACK) then that transaction can not rejected as there shall be the confusion over whether SDP shall be rolled-back or not. I suppose, SDP answer can not be rolled-back. There is no confusion for ACK, as it can not rejected but for PRACK the restriction should be there that it can not be rejected if it carries SDP answer. =20 This draft says that PRACK(irrespective of whether it is carrying SDP offer/answer) can not be rejected. I can not understand the rationale about this statement. Though, I can appreciate why PRACK MUST not be rejected if it carries SDP answer. =20 [3] If any SIP response contains SDP offer then that SDP can not be rolled-back. If any SIP entity wants to rollback the SDP offer carried by SIP response, it should initiate a SIP transaction carrying old SDP to accomplish it. =20 There is a special case for re-INVITE. If multiple SDP offer/answer happens(using PRACK/UPDATE) within re-INVITE transaction and re-INVITE is rejected by 4xx-6xx then whether all the SDP offer/answer happens within re-INVITE transaction shall be rolled-back or not. My suggestion would be that once SDP offer/answer is completed, that can not rolled-back by means of transaction rejection. That means, all the completed SDP offer/answer shall not be rolled-back due to 4xx-6xx of re-INVITE. This decision shall save the work of SIP UA, SIP SBC, B2BUA etc. that follows SDP offer/answer state. =20 Please comment. =20 =20 Thanks and Regards, Siddhartha =20 ________________________________ --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ---------------=20 =09 ------_=_NextPart_001_01C70819.ADC57430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
SDP rollback applies only if previously there = has been an=20 offer-answer exchange and an early dialog or a confirmed dialog has been = established. In that case, if SDP in re-Invite/UPDATE is rejected, then = session=20 continues with previously negotiated characteristics. This is mentioned = in RFC=20 3261. And this draft does mention that if offer in Prack or in a sip = response is=20 rejected, then answerer has to send an updated offer. So I am not sure = how is=20 the new proposal different than what has been already=20 stated.
 
Sanjay

From: Siddhartha Bhakta=20 [mailto:Siddhartha.Bhakta@newport-networks.com]
Sent: = Tuesday,=20 November 14, 2006 12:37 PM
To: tu-sawada@kddi.com; Paul = Kyzivat=20 (pkyzivat)
Cc: sipping@ietf.org
Subject: [Sipping] = SDP=20 Rollback = indraft-sawada-sipping-sip-offeranswer-01.txt

Hi,

 

I am not sure = (as I am a=20 very new user to SIPPING

group) whether = SDP=20 rollback has ever been discussed

regarding this = draft or=20 not. I personally feel that

'SDP rollback' = is very=20 relevant topics regarding this

draft.

 

The sec 1.2 = indicates the=20 response(488) to reject any

SDP offer. But = the missing=20 part is that if any SIP

request carrying = SDP offer=20 is rejected by 3xx-6xx then

SDP offer should = be=20 rolled-back. The rollback means,

applying last = session=20 description.

 

Rather than = specifying=20 different SIP messages

separately, it = would be=20 better to have some thumb rule

that shall be = quite easy=20 to follow as far as SDP

rollback is = concerned. I=20 am proposing following thumb

rule. Please = indicate=20 whether that makes sense or not.

 

The SDP rollback = shall be=20 associated with transaction

rollback/rejection.

 

[1] If the = transaction=20 request (carrying SDP offer) is

rejected then = SDP offer=20 shall be rolled-back. The

exception is the = ACK=20 request. The ACK (of 2xx) can not

be rejected. = (The ACK of=20 3xx-6xx is not the

transaction = initiating=20 request).

 

[2] If any = transaction=20 request carries SDP answer

(e.g., ACK or = PRACK) then=20 that transaction can not

rejected as = there shall be=20 the confusion over whether

SDP shall be = rolled-back=20 or not. I suppose, SDP answer

can not be = rolled-back.=20 There is no confusion for ACK,

as it can not = rejected but=20 for PRACK the restriction

should be there = that it=20 can not be rejected if it

carries SDP=20 answer.

 

This draft says = that=20 PRACK(irrespective of whether it

is carrying SDP=20 offer/answer) can not be rejected. I

can not = understand the=20 rationale about this statement.

Though, I can = appreciate=20 why PRACK MUST not be

rejected if it = carries SDP=20 answer.

 

[3] If any SIP = response=20 contains SDP offer then that

SDP can not be=20 rolled-back. If any SIP entity wants to

rollback the SDP = offer=20 carried by SIP response, it

should initiate = a SIP=20 transaction carrying old SDP to

accomplish=20 it.

 

There is a = special case=20 for re-INVITE. If multiple SDP

offer/answer = happens(using=20 PRACK/UPDATE) within

re-INVITE = transaction and=20 re-INVITE is rejected by

4xx-6xx then = whether all=20 the SDP offer/answer happens

within re-INVITE = transaction shall be rolled-back or

not. My = suggestion would=20 be that once SDP offer/answer

is completed, = that can not=20 rolled-back by means of

transaction = rejection.=20 That means, all the completed

SDP offer/answer = shall not=20 be rolled-back due to

4xx-6xx of = re-INVITE. This=20 decision shall save the

work of SIP UA, = SIP SBC,=20 B2BUA etc. that follows SDP

offer/answer=20 state.

 

Please=20 comment.

 

 

Thanks and=20 Regards,

Siddhartha

 



---------------
This e-mail may contain confidential and/or = privileged=20 information. If you are not the intended recipient (or have received = this=20 e-mail in error) please notify the sender immediately and delete this = e-mail.=20 Any unauthorized copying, disclosure or distribution of the contents = in this=20 e-mail is strictly forbidden.
--------------- =
------_=_NextPart_001_01C70819.ADC57430-- --===============1139725983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1139725983==-- From sipping-bounces@ietf.org Tue Nov 14 13:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2yK-00017O-HI; Tue, 14 Nov 2006 13:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2yI-00017G-LN for sipping@ietf.org; Tue, 14 Nov 2006 13:25:22 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2yH-0004fY-G0 for sipping@ietf.org; Tue, 14 Nov 2006 13:25:22 -0500 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 13:25:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Date: Tue, 14 Nov 2006 13:25:15 -0500 Message-ID: <77BD870EA838FC469FDD2AE248B1357B017896EF@ATL1VEXC008.usdom003.tco.tc> In-reply-to: <20061114175102.42641.qmail@web8705.mail.in.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Query related to draft-ietf-sipping-service-examples-11 Thread-Index: AccIFXl3LmRkPSM3RSGpMV5x5LFjcAAAe0Nw From: "Brett Tate" To: "Siddhartha Bhakta" , X-OriginalArrivalTime: 14 Nov 2006 18:25:25.0172 (UTC) FILETIME=[40BE1740:01C7081A] X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > Neither Alice is sending CANCEL for dialog-ID1 & dialog-ID2,=20 > nor Proxy is sending 3xx-6xx to Alice for > dialog-ID1 & dialog-ID2. > How dialog-ID1 & dialog-ID2 shall be terminated at Alice? You=20 > are possibly suggesting Alice to send BYE on those dialog!=20 > But that is missing in sec 2.9. If you look closer at rfc3261 (and rfc2543) basically only 1 final response for the INVITE is proxied back to the caller. Thus Alice can assume that the other dialogs have been released upon receiving a final response for the INVITE. During race conditions extra INVITE 2xx responses might be received on the other dialogs. Only within these race conditions does Alice need to send the extra BYEs. And there is no reason for Alice to send a CANCEL if a final response for the INVITE has been received because the forking proxies sent or will send the CANCELs as needed. _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 13:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk38e-0004tb-UF; Tue, 14 Nov 2006 13:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk38e-0004tQ-6p for sipping@ietf.org; Tue, 14 Nov 2006 13:36:04 -0500 Received: from web8712.mail.in.yahoo.com ([203.84.221.133]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk38c-00067U-Gf for sipping@ietf.org; Tue, 14 Nov 2006 13:36:04 -0500 Received: (qmail 87126 invoked by uid 60001); 14 Nov 2006 18:36:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MeGCTSM765mY6Hbb52o9p4zoYMLzhy5N+kMH3x+nR5zfFMGmm8C9e3kssnVmT3l5cVqDOOtvzvOHJZ8rQb+Wzda1iafa3f/9rVlz8GStQ7mUImeaWJGKLZ5t3NxT1MP0qSpUnSrVjHrzIpBU3xvV7tOKpEPxfzL9oB+m9lBsb6E= ; Message-ID: <20061114183600.87124.qmail@web8712.mail.in.yahoo.com> Received: from [217.45.197.113] by web8712.mail.in.yahoo.com via HTTP; Tue, 14 Nov 2006 18:36:00 GMT Date: Tue, 14 Nov 2006 18:36:00 +0000 (GMT) From: Siddhartha Bhakta Subject: RE: [Sipping] Query related to draft-ietf-sipping-service-examples-11 To: Brett Tate , sipping@ietf.org In-Reply-To: <77BD870EA838FC469FDD2AE248B1357B017896EF@ATL1VEXC008.usdom003.tco.tc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brett, But forking proxy needs to send CANCEL for all early dialogs after receiving final reasponse of one INVITE. Why is the discrimination? Is it due to the fact that forking proxy has to send multiple INVITE and multiple dialogs are created due to response of different INVITE dialogs whereas SIP-UA behind Forking proxy creates multiple dialogs for a single INVITE message? --- Brett Tate wrote: > > Neither Alice is sending CANCEL for dialog-ID1 & > dialog-ID2, > > nor Proxy is sending 3xx-6xx to Alice for > > dialog-ID1 & dialog-ID2. > > How dialog-ID1 & dialog-ID2 shall be terminated at > Alice? You > > are possibly suggesting Alice to send BYE on those > dialog! > > But that is missing in sec 2.9. > > If you look closer at rfc3261 (and rfc2543) > basically only 1 final > response for the INVITE is proxied back to the > caller. Thus Alice can > assume that the other dialogs have been released > upon receiving a final > response for the INVITE. During race conditions > extra INVITE 2xx > responses might be received on the other dialogs. > Only within these > race conditions does Alice need to send the extra > BYEs. And there is no > reason for Alice to send a CANCEL if a final > response for the INVITE has > been received because the forking proxies sent or > will send the CANCELs > as needed. > __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 18:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk837-0000rq-5b; Tue, 14 Nov 2006 18:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk830-0000mh-0y; Tue, 14 Nov 2006 18:50:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk82z-0008OJ-V3; Tue, 14 Nov 2006 18:50:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gk82y-00019L-J1; Tue, 14 Nov 2006 18:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 806532AC6D; Tue, 14 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gk82U-0006tx-9P; Tue, 14 Nov 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 14 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-05.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : Multiple Dialog Usages in the Session Initiation Protocol Author(s) : R. Sparks Filename : draft-ietf-sipping-dialogusage-05.txt Pages : 29 Date : 2006-11-14 Several methods in the Session Initiation Protocol can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.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-sipping-dialogusage-05.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-sipping-dialogusage-05.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: <2006-11-14164619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-dialogusage-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-dialogusage-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-14164619.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Tue Nov 14 19:23:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk8Xk-0001OW-D2; Tue, 14 Nov 2006 19:22:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk8Xh-0001N3-9J; Tue, 14 Nov 2006 19:22:17 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk8Xf-0007Wy-TU; Tue, 14 Nov 2006 19:22:17 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id kAF0MFtO017671; Tue, 14 Nov 2006 16:22:15 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id kAF0MFtI017670; Tue, 14 Nov 2006 16:22:15 -0800 Date: Tue, 14 Nov 2006 16:22:15 -0800 Message-Id: <200611150022.kAF0MFtI017670@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sipping@ietf.org, rfc-editor@rfc-editor.org Subject: [Sipping] RFC 4730 on A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4730 Title: A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) Author: E. Burger, M. Dolly Status: Standards Track Date: November 2006 Mailbox: eburger@cantata.com, mdolly@att.com Pages: 56 Characters: 120186 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-kpml-08.txt URL: http://www.rfc-editor.org/rfc/rfc4730.txt This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS TRACK] This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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 ... _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 19:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk94D-0002kg-Eo; Tue, 14 Nov 2006 19:55:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk94B-0002kD-Jh for sipping@ietf.org; Tue, 14 Nov 2006 19:55:51 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk949-0000CE-A3 for sipping@ietf.org; Tue, 14 Nov 2006 19:55:51 -0500 Received: from [10.10.16.252] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAENxZ2p018237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Nov 2006 17:59:36 -0600 In-Reply-To: <020d01c70806$6098c880$3801a8c0@newportnetworks.com> References: <020d01c70806$6098c880$3801a8c0@newportnetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 18:55:43 -0600 To: Siddhartha Bhakta X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sipping@ietf.org, 'Brett Tate' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 14, 2006, at 10:03 AM, Siddhartha Bhakta wrote: > Thanks Brett. From your reply I could understand that the problem > we are > facing is unavoidable. It is resulted not due to our lack of > understanding > about RFC3261 but due to backward incompatibility of RFC3261 to > RFC2543. I would actually say that it's more of a bug in RFC 2543, which wasn't even backward compatible with itself. It's much better specified in RFC 3261. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 14 20:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk9Yf-0002Z7-Ll; Tue, 14 Nov 2006 20:27:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk9Ye-0002YU-VZ for sipping@ietf.org; Tue, 14 Nov 2006 20:27:20 -0500 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk9Ya-0006ea-CV for sipping@ietf.org; Tue, 14 Nov 2006 20:27:20 -0500 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 14 Nov 2006 17:26:12 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kAF1NSvV023111; Tue, 14 Nov 2006 17:23:28 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kAF1PuPF024649; Tue, 14 Nov 2006 17:25:56 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:25:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Tue, 14 Nov 2006 17:25:56 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141315@namail5.corp.adobe.com> In-Reply-To: <01e301c707e6$48c45f50$3801a8c0@newportnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AccHU2MepZnq+ZYRSkSbCvSqOIc9PgAhVIWQAB6TGbA= From: "Henry Sinnreich" To: "Siddhartha Bhakta" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Nov 2006 01:25:56.0829 (UTC) FILETIME=[FFFB68D0:01C70854] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > The PABX in my example is a B2BUA This sounds not quite right. =20 A PBX is a call control server that has well defined SIP and RTP behavior, while a B2BUA can be anything - great source of comfort :-) It may be interesting to see if PBX developers agree with your equivalence. Henry -----Original Message----- From: Siddhartha Bhakta [mailto:Siddhartha.Bhakta@newport-networks.com]=20 Sent: Tuesday, November 14, 2006 6:13 AM To: 'Paul Kyzivat' Cc: sipping@ietf.org; 'Siddhartha Bhakta' Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Paul, The PABX in my example is a B2BUA. But 180(F6) and 200(F9) generated by it is having same to-tag but they are carrying different SDPs. The PABX vendors are claiming that below mentioned flow is as per RFC2543. I could not counter it as I could not find out the reference where RFC2543 is preventing it. For a Media server(IVR) implementation, the tone (183) and voice (200) might contain different media description as that were not prevented in RFC2543. The RFC2543 compliant Media server shall not put different to-tag in 183 and 200 for sure as it is not the forking case. Now, if any RFC3261 compliant phone does not apply SDP of 200 OK then it can not hear the voice. Now, it's down to the fact whether RFC3261 supports the co-existence to RFC2543 or not. I hope, I am not the only one who faced this problem. We are going beyond RFC3261 (in our implementation) to support the co-existence of RFC3261 and RFC2543. But it would have been better if RFC3261 itself could have addressed this. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 13 November 2006 18:42 To: Siddhartha Bhakta Cc: 'Siddhartha Bhakta'; sipping@ietf.org Subject: Re: [SIPPING] SDP offer/answer in early media: draft-sawada-sipping-sip-offeranswer-01.txt Siddhartha Bhakta wrote: > Paul, >=20 > The proxy and PABX in my figure are acting perfectly fine with the RFC2543 > standard or any old standard that allows the PSTN like early-media flow. In > those standards, multiple SDP answer of a single SDP was allowed. >=20 > As soon as we upgrade our node to RFC3261, we are facing this problem. Ah! This is the first time you have mentioned 2543. If it is=20 compatibility with 2543 that you are concerned with, that is an entirely different story. And it is one that is largely not discussed in 3261,=20 though 3261 took some pains to allow coexistence. Its been a very long time since I looked at 2543, so I won't claim to be able to give you an accurate answer with respect to that. In particular, I am not going to go digging to figure out whether what you are showing=20 would be valid in 2543 or not. For the most part people now assume 3261 support, so you may have=20 difficulty getting help with questions on 2543 compatibility. In any case, I disagree that your proxy is compliant with 2543. I'm=20 pretty sure that even back then proxies were not allowed to generate an=20 answer to an offer - that is a UA responsibility. > Can I say the offer/answer flow of RFC3261/RFC3264 is not backward > compatible to older early-media standard? I wasn't around when the backward compatibility issues of this were=20 worked out, so somebody else will have to answer to that. > If that is the case, then I believe, we should try to make RFC3261/RFC3264 > backward compatible otherwise people shall definitely face this problem. I > thought, this draft shall be best place to address this issue. If there was a problem, it should have been caught before 3261 became an RFC. It has been an RFC so long, with so many implementations, that=20 incompatible changes to it would be worse than the incompatibility with=20 2543. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 13 November 2006 17:51 > To: Siddhartha Bhakta > Cc: sipping@ietf.org; Siddhartha Bhakta > Subject: Re: [SIPPING] SDP offer/answer in early media: > draft-sawada-sipping-sip-offeranswer-01.txt >=20 >=20 >=20 > Siddhartha Bhakta wrote: >> I am re-sending it as in last email, the figure was >> distorted. >> >> Though, post RFC3261 drafts indicate that one valid >> answer would be there for one SDP >> offer, the our old friend early-media flow is still >> present in practice. >> >> B2BUA/SBC Proxy PABX Bob >> | | | | >> | INVITE F1 | | | >> |----------->| INVITE F2 | | >> | 183 F3 |----------->| INVITE F4 | >> |<-----------| |----------->| >> | | | | >> | | | 180 without SDP F5 >> | | |<-----------| >> | | | | >> | | 180 with SDP F6 | >> | 180 F7 |<-----------| | >> |<-----------| | 200 F8 | >> | | 200 F9 |<-----------| >> | 200 F10 |<-----------| | >> |<-----------| | | >> | ACK F11 | | | >> |----------->| ACK F12 | | >> | |----------->| ACK F13 | >> | | |----------->| >=20 > In the above, F3 is illegal according to 3261, because this action is=20 > not permitted for proxies. It can be fixed by modeling another UA (an=20 > early media source) that the proxy forks to. >=20 > F6 may also be illegal. It depends on whether the PABX is a proxy or a > B2BUA. If a proxy then it too is illegal. >=20 >> Our B2BUA is facing the problem as specified above. >> The first answer is carried >> by F3. This SDP is specified by Proxy. The 2nd SDP >> answer is carried by F6,F7. >> In fact, this SDP is specified by PABX. The third SDP >> answer is carried by F8,F9,F10. >> This SDP is specified by called party (Bob). >> >> As per the RFC3261 & RFC3264, the SDP answer carried >> by F6,F7 should match with F3 >> as far as B2BUA is concerned. >=20 > This is not required if F3, F7, and F10 are all separate dialogs. If I > understand what you are trying to accomplish, then that is the way to=20 > accomplish it. >=20 >> Therefore, B2BUA shall >> ignore it. This is leading to >> the fact that SIP UA behind B2BUA can not listen to >> ringtone fed by PABX. >> Similarly, SDP answer carried by F8,F9,F10 shall be >> ignored. This shall lead to the fact >> that SIP UA behind B2BUA can not listen to Bob's >> voice. Too bad. >> This problem is due to the fact that RFC3261 & RFC3264 >> are not backward compatible. >=20 > If the three SDPs are generated independently then they can't be=20 > expected to obey the constraints imposed by being within a single=20 > dialog. Your problem is trying to force them to do so. >=20 >> The sec 2.2. of >> draft-sawada-sipping-sip-offeranswer-01.txt indicates >> that UPDATE should >> be used to update the media in early media. >=20 > That would not solve your problem. It is concerned with a single dialog.=20 > You have a situation with multiple dialogs. Each must be considered=20 > separately. >=20 > (However, you are not the first to raise this sort of issue. Perhaps it=20 > should be discussed in the draft.) >=20 >> But in >> practice old early-media flow (i.e., >> sending different SDPs over different 1xx responses of >> INVITE) is quite common. >> Can we somehow make new SDP offer/answer specified in >> RFC3261 & RFC3264 backward >> compatible? >=20 >> The old standard (early-media), allows multiple SDP >> answers of single SDP offer. can >> we somehow induce this thing in SDP offer/answer >> model? If many of you think the need >> of it then I may comeup with some thumb rule for the >> same. >=20 > IMO there is nothing to fix in the standards to solve your problem. What=20 > needs fixing are the sip implementations in some of the elements you are=20 > using. >=20 > Paul >=20 >> Thanks & Regards, >> Siddhartha >> >> >> =09 >> __________________________________________________________ >> Yahoo! India Answers: Share what you know. Learn something new >> http://in.answers.yahoo.com/ >> >> _______________________________________________ >> 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 >> >=20 >=20 >=20 > --------------- > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. > --------------- >=20 --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 01:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5s-0001EX-Mn; Wed, 15 Nov 2006 01:17:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5q-0001EB-UL for sipping@ietf.org; Wed, 15 Nov 2006 01:17:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkE5l-0006JE-Hy for sipping@ietf.org; Wed, 15 Nov 2006 01:17:54 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 22:17:48 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAF6Hmpr021751; Tue, 14 Nov 2006 22:17:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAF6Hmin003259; Tue, 14 Nov 2006 22:17:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:48 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:47 -0800 Message-ID: <455A80A6.5020902@cisco.com> Date: Tue, 14 Nov 2006 21:51:18 -0500 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: Paul Kyzivat Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F837E.1010504@cisco.com> In-Reply-To: <454F837E.1010504@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 06:17:47.0899 (UTC) FILETIME=[C564A4B0:01C7087D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2517; t=1163571468; x=1164435468; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=09[Sippin g]=09draft-stucker-sipping-early-media-coping) |Sender:=20; bh=gghmDfrZg0N42HtUsWD9GHmvhOglWTDKSXy2M6F/orQ=; b=T0cs2ayuFb3B5LeVRVogFN7uM1/MuNiqDVNRsXeImfzdFwUutZsfFRq5fMTaiFnBCLFB5yhg 8aCaaxcMFpoRc0PHnGfFDdHxvpGOBtrywiSDIIhHSKnq2C9GNKqEv73a; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Cullen Jennings , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org inline. Paul Kyzivat wrote: > Brian, > > The case you specify is almost the same case I am talking about, but > make more specific. > > I didn't say anything about what values the specific URIs should be. I > think there are three interesting categories: > 1) a URL of a remote resource that the UAS may actually retrieve > and render > > 2) a URL of a resource local to the UAS. > > 3) a URN, that simply specifies a name of a particular alerting style. > The UAS must know what to do for one of these to use it, or have its > own way of discovering that given the URN. > > I have seen (2) used, but usually as an alternative for (3) in that it > isn't really expected that the UAS will necessarily have something > stored in exactly this way. I find (2) to be unreasonable in most > deployments, and (3) to be a much more reasonable approach, that has > equivalent functionality. > > This is all orthogonal to how trustworthiness of Alert-Info headers is > managed. I find it difficult to imagine any cases when the UAS would > want to honor a value sent by the UAC. Well, here is where URN helps. Since the UA that has to render the URN has to know what it means, you can authorize it or not based on that understanding. As others have pointed out, the URN is not going to help cases where people want Britney Spears songs as ringback, but it can help with country-specific ringbacks, where we could easily create a registry. I've become convinced that custom ringtones are best done the way they are done today. The ringtone is stored on the called party device, and logic on the phone itself selects which one to use based on the identity of the caller. Having the caller select content that gets rendered at the called party, without asking the called party for authorization (which is the case for ringtones), is a recipe for absolute disaster. I'm not worried about tasteless music - I'm worried about some malicious user that decides to record some highly offensive content and then start calling random numbers to cause the content to get played out automatically. Big mistake. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 01:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5q-0001E5-J9; Wed, 15 Nov 2006 01:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE5o-0001Dz-VZ for sipping@ietf.org; Wed, 15 Nov 2006 01:17:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkE5i-0006J2-B1 for sipping@ietf.org; Wed, 15 Nov 2006 01:17:52 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 22:17:45 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAF6Hisi009953; Tue, 14 Nov 2006 22:17:44 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAF6HiW4005774; Tue, 14 Nov 2006 22:17:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:43 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 22:17:43 -0800 Message-ID: <455A7C54.1070201@cisco.com> Date: Tue, 14 Nov 2006 21:32:52 -0500 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: Albrecht.Schwarz@alcatel.de Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 06:17:43.0821 (UTC) FILETIME=[C2F663D0:01C7087D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5709; t=1163571464; x=1164435464; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sipping]=20Re=3A=20draft-rosenberg-sipping-overload- reqs=20recovery |Sender:=20; bh=fneboS8PX8a0WGIFp0tOgUCOOAAjZj3vtQggLvy/adg=; b=GZ0SaJODxbzdw63LaezbboxTvx/fEOPQC6zuLIXxG2q0I/S4V8kkuDZJ5yuFGfIuTo215U+H p+dnQDt2WExE76onte/1Lf+SM5sI+UMUqp06L5JxJ9dx9BRslKJxT1NF; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Cullen Jennings , Volker Hilt , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think its reasonable to make it an explicit requirement. How about: The overload mechanism should ensure that the system remains stable. When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load. -Jonathan R. Albrecht.Schwarz@alcatel.de wrote: > Stability is an implicit requirement of every load control and overload > protection mechanism (for network elements and networks targeting high > system and/or service availability). > > The rational behind is the fact that any overload control may be modeled (& > realized) as open or closed control loop. Any control arround signalling > protocols is typically realized as closed loop (e.g. due to realtime > background). > A well designed closed control requires a proof of stability for the > intended range of operation; stability is an implicit requirement from > control theory, particularly for load control with stochastic components as > in our case here. > > - Albrecht > > > > > Volker Hilt > > bs.com> cc: sipping > Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery > 08.11.2006 17:18 > > > > > > I think that stability of overload control is an important requirement. > We certainly want to avoid building something that starts to oscillate > once it reaches overload state. It may be somehow implicit to REQ 1 > since an unstable system will hardly be able to maintain the overall > useful throughput at a high level. > > Volker > > > > Cullen Jennings wrote: > >>Clearly this was a long way from the text for a requirement but, yes, I >>was proposing that this be added as one of the requirements. I don't >>feel strongly about this and if we can't figure out how to express this >>as a requirement that is useful, I can certainly live with not adding it. >> >>The reason I think it is a requirement is I can easily imagine that the >>mechanism for doing overload push-back causes the systems to fail in the >>way I described below (i.e. never recover back to steady state). >> >> >>On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >> >> >>> >>>Cullen Jennings wrote: >>> >>> >>>>A possible additional requirement.... >>>>Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>is in steady state doing 80cps with very few retransmission. Then >>>>for 5 minutes the incoming requests goes to 500cps then drops back >>>>to an incoming call rate of 80cps. The question is, how long before >>>>the system gets back to the state where it if is successfully >>>>processing all the 80cps? >>> >>>As soon as it can. Are you suggesting a requirement here? Seems like >>>this is an implementation thing and wouldn't impact any protocol >>>mechanisms. >>> >>> >>>>I have seen systems that never recover - that is bad. I think one of >>>>the design goals is that it is at least possible to build to systems >>>>that recover back to steady state relatively quickly after an >>>>overload impulse. >>> >>>Sure; but I'm not sure I see the protocol requirement. >>> >>>-Jonathan R. >>> >>> >>> >>>--Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>Cisco Fellow Parsippany, NJ 07054-2711 >>>Cisco Systems >>>jdrosen@cisco.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>http://www.cisco.com >> >>_______________________________________________ >>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 > > > > _______________________________________________ > 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 > > > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 11:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNwY-0008By-NZ; Wed, 15 Nov 2006 11:48:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNwW-0008Ai-Ap for sipping@ietf.org; Wed, 15 Nov 2006 11:48:56 -0500 Received: from [202.177.174.130] (helo=mail.spanservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNwU-0007e2-LQ for sipping@ietf.org; Wed, 15 Nov 2006 11:48:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Nov 2006 22:20:22 +0530 Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05AF0@mail.spanservices.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proxy in DMZ while B2BUA as an ALG Thread-Index: AccIfzqm8Wk/nONyTCuZLv77bcGYagAVTDwU References: <455A7C54.1070201@cisco.com> From: "SUNIL J. KUMAR" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Sipping] proxy in DMZ while B2BUA as an ALG X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, =20 I am developing a SIP ALG as B2BUA sitting along with NAT/Firewall on = the boundary of the network. =20 I am covering one scenario like: =20 1. SIP Proxy/registrar located in the DMZ: The users UA1 and UA2 sitting = on a private (trusted) network, are to be registered with the SIP = Proxy/registrar in the DMZ.=20 =20 =20 =20 Private Network | = Public Network = | UA1-----------------|--------| |----------------| = = |----------------| | switch |-------------| = ALG(B2BUA)|------------------------------------|proxy/Registrar= |----------UA3 UA2-----------------|--------| | NAT/FW | = = |----------------|=20 = |----------------| = | = | DMZ = | = |----------------| = |proxy/Registrar | = |----------------| = | = | =20 =20 In this case, when UA1 and UA2 send a Register request, will reach SIP = ALG(B2BUA) first as if it is UA1's outbound proxy, where from it will = get forwarded to the Proxy/Registrar in DMZ. =20 Incoming Call: =20 At some later point of time when UA3 in public network makes a call to = UA1, the what should be the path of INVITE from UA3 to UA1? When B2BUA = makes a DNS lookup, it gets resolved as the proxy in DMZ.=20 =20 What should be the response path? =20 Outgoing Call: When UA1 in private network makes a call to UA3 in public, what should = be the path of INVITE in this scanrio? What should be the response path? =20 =20 Regards, Sunil =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 12:16:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOLl-000308-06; Wed, 15 Nov 2006 12:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOLj-000300-8c for sipping@ietf.org; Wed, 15 Nov 2006 12:14:59 -0500 Received: from web8701.mail.in.yahoo.com ([203.84.221.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkOLg-0002bS-H9 for sipping@ietf.org; Wed, 15 Nov 2006 12:14:59 -0500 Received: (qmail 80091 invoked by uid 60001); 15 Nov 2006 17:14:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2cZMp1pxiaLdVRJ3/ODk76FkQoOvTJEBVyPUZPoZqDWjUdbTdQddw+RhgsgP42C0EoYfPDY2suT+EWKkX4goMhzQGJgro8K0yBWZs+MbNCSmCLu1BYkev3CKm9MI76tm0Tlvwcbku63/DYTC4hJvd7dULAUsIf0VHRnjBQMlVTM= ; Message-ID: <20061115171454.80089.qmail@web8701.mail.in.yahoo.com> Received: from [217.45.197.113] by web8701.mail.in.yahoo.com via HTTP; Wed, 15 Nov 2006 17:14:54 GMT Date: Wed, 15 Nov 2006 17:14:54 +0000 (GMT) From: Siddhartha Bhakta To: RjS@estacado.net, alan@sisptation.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sipping@ietf.org Subject: [Sipping] Comment on draft-ietf-sipping-cc-transfer-07 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, The Replace ext/header in sec "7.2. Protecting transfer target" of draft-ietf-sipping-cc-transfer-07 is wrong. The to-tag and from-tag should be swapped. In this example, the Transferee shall interpret the Replace header. The to-tag and from-tag of Replace header should be the local-tag and remote-tag respectively. As far as Transferee is concerned, the local-tag=7553452 and remote-tag=31431 for dialog1. Existing -------- F5 REFER Transferor -> Transfer Target Refer-To: sips:3ld812adkjw@biloxi.example.com;grid=3413kj2ha;gruu?Replaces=090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452> F6 INVITE Transfer Target -> Transferee Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 Corrected -------- F5 REFER Transferor -> Transfer Target Refer-To: sips:3ld812adkjw@biloxi.example.com;grid=3413kj2ha;gruu?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431> F6 INVITE Transfer Target -> Transferee Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 Thanks and Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 12:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOXL-0007GF-HI; Wed, 15 Nov 2006 12:26:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOXJ-0007G0-9T for sipping@ietf.org; Wed, 15 Nov 2006 12:26:57 -0500 Received: from web8701.mail.in.yahoo.com ([203.84.221.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkOXH-0004Le-IN for sipping@ietf.org; Wed, 15 Nov 2006 12:26:57 -0500 Received: (qmail 83802 invoked by uid 60001); 15 Nov 2006 17:26:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hACeUCy6U1ayYMa/bOMobT40AoAxdDV0/MZVvtGy/FEylOFBCEyA8F5NPKYiuGPt1+NUdMLejJ1shawD5P4MCAat0v5IhBMBiv0GfkoBN54T+oUfpH/7QIOm+0DGaaBOdhqcd9C2p/ojwEE+O9csCrlb8+m5QzcX0AI02N4xULQ= ; Message-ID: <20061115172654.83800.qmail@web8701.mail.in.yahoo.com> Received: from [217.45.197.113] by web8701.mail.in.yahoo.com via HTTP; Wed, 15 Nov 2006 17:26:54 GMT Date: Wed, 15 Nov 2006 17:26:54 +0000 (GMT) From: Siddhartha Bhakta To: Alan Johnston , "Robert J. Sparks" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sipping@ietf.org Subject: [Sipping] Comment on draft-ietf-sipping-cc-transfer-07 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I am re-sending it as I got send failure last time. Alan has wrong email address in draft-ietf-sipping-cc-transfer-07 Another comment :-) Hi, The Replace ext/header in sec "7.2. Protecting transfer target" of draft-ietf-sipping-cc-transfer-07 is wrong. The to-tag and from-tag should be swapped. In this example, the Transferee shall interpret the Replace header. The to-tag and from-tag of Replace header should be the local-tag and remote-tag respectively. As far as Transferee is concerned, the local-tag=7553452 and remote-tag=31431 for dialog1. Existing -------- F5 REFER Transferor -> Transfer Target Refer-To: sips:3ld812adkjw@biloxi.example.com;grid=3413kj2ha;gruu?Replaces=090459243588173445%3Bto-tag%3D31431%3Bfrom-tag%3D7553452> F6 INVITE Transfer Target -> Transferee Replaces: 090459243588173445;to-tag=31431;from-tag=7553452 Corrected -------- F5 REFER Transferor -> Transfer Target Refer-To: sips:3ld812adkjw@biloxi.example.com;grid=3413kj2ha;gruu?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431> F6 INVITE Transfer Target -> Transferee Replaces: 090459243588173445;to-tag=7553452;from-tag=31431 Thanks and Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 13:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPis-0000HQ-GT; Wed, 15 Nov 2006 13:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPiq-0000HE-Oq for sipping@ietf.org; Wed, 15 Nov 2006 13:42:56 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPio-0007cm-9u for sipping@ietf.org; Wed, 15 Nov 2006 13:42:56 -0500 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAFIgvBP021139 for ; Wed, 15 Nov 2006 19:42:57 +0100 Received: from [172.31.152.172] ([172.31.152.172]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2006111519425205:10244 ; Wed, 15 Nov 2006 19:42:52 +0100 Message-ID: <455B5FAC.9050908@alcatel.be> Date: Wed, 15 Nov 2006 19:42:52 +0100 From: stefaan.willaert@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/15/2006 19:42:52, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/15/2006 19:42:53, Serialize complete at 11/15/2006 19:42:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sipping] recover from avalance registrations X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Consider the following circumstances: 500000 users connected to a proxy-registrar configured as active/active each proxy registrar is capable of handling 500 registrations/s The phones register once every hour, in normal circumstances, which the server can easily handle. However under double failures, in short time, the rate of registrations builds up massively, due to the cumulation of failed registrations which reattempt once per minute iso once per hour and the retransmissions generated for each of them. Successful registration of a user requires 2 cycles since the first registration is challenged in the 401 response. Coming up after 10min, the first server is hit by around 28000 registers/s After short time the chances for both register cycles to succeed, drops to such small value, that it would take too much time to from the registration storm. Are there any recommendations concerning this. _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 13:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyB-00078v-HV; Wed, 15 Nov 2006 13:58:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyA-00076c-FV for sipping@ietf.org; Wed, 15 Nov 2006 13:58:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPy9-0004p3-3D for sipping@ietf.org; Wed, 15 Nov 2006 13:58:46 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2006 10:58:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAFIwiDd004958; Wed, 15 Nov 2006 10:58:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAFIwiio015915; Wed, 15 Nov 2006 10:58:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 10:58:44 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 10:58:43 -0800 Message-ID: <455B6363.3060103@cisco.com> Date: Wed, 15 Nov 2006 13:58:43 -0500 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: stefaan.willaert@alcatel.be Subject: Re: [Sipping] recover from avalance registrations References: <455B5FAC.9050908@alcatel.be> In-Reply-To: <455B5FAC.9050908@alcatel.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 18:58:44.0107 (UTC) FILETIME=[129D1DB0:01C708E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1925; t=1163617124; x=1164481124; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sipping]=20recover=20from=20avalance=20registrations |Sender:=20; bh=Tt7x01wVAOHM87Qk4rEpeaQ3Z/HrYOJtS3eK0w3Davs=; b=oE15UTvIlRfjUxBWbDyIiqD7ZrvoQ6zsJZBSWJ356r0rCozgC06J0YYQiLMy+P1poEObRPH8 tafcoQlEX4IY5BA69Udspq7QSOVihFcBmYZIgb0c1bdPzyeWxjIMcWfA; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There is currently active working in defining overload mechanisms to address this. See: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-overload-reqs-02.txt http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-00.txt -Jonathan R. stefaan.willaert@alcatel.be wrote: > Consider the following circumstances: > 500000 users connected to a proxy-registrar configured as active/active > each proxy registrar is capable of handling 500 registrations/s > The phones register once every hour, in normal circumstances, which the > server > can easily handle. > However under double failures, in short time, the rate of registrations > builds up massively, due to the cumulation of failed registrations which > reattempt once per minute iso once per hour and the retransmissions > generated for > each of them. > Successful registration of a user requires 2 cycles since the first > registration is challenged > in the 401 response. Coming up after 10min, the first server is hit by > around 28000 registers/s > After short time the chances for both register cycles to succeed, drops > to such small > value, that it would take too much time to from the registration storm. > Are there any recommendations concerning this. > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 17:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTLJ-0007KS-Rh; Wed, 15 Nov 2006 17:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTLI-0007KK-CO for sipping@ietf.org; Wed, 15 Nov 2006 17:34:52 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTLH-0002uM-09 for sipping@ietf.org; Wed, 15 Nov 2006 17:34:52 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id kAFMYbGV007835; Wed, 15 Nov 2006 16:34:39 -0600 (CST) Received: from [135.180.240.247] (volker-hopc2.dnrc.bell-labs.com [135.180.240.247]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kAFMYbo18205; Wed, 15 Nov 2006 17:34:37 -0500 (EST) Message-ID: <455B95FD.6030909@bell-labs.com> Date: Wed, 15 Nov 2006 17:34:37 -0500 From: Volker Hilt User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery References: <455A7C54.1070201@cisco.com> In-Reply-To: <455A7C54.1070201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Cullen Jennings , Albrecht.Schwarz@alcatel.de, sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> > Jennings >> >> bs.com> cc: sipping >> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 19:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUi2-0002tz-Oj; Wed, 15 Nov 2006 19:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUi1-0002tn-5L for sipping@ietf.org; Wed, 15 Nov 2006 19:02:25 -0500 Received: from web8703.mail.in.yahoo.com ([203.84.221.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkUhz-0007Ri-H1 for sipping@ietf.org; Wed, 15 Nov 2006 19:02:25 -0500 Received: (qmail 81577 invoked by uid 60001); 16 Nov 2006 00:02:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2myElSgecnsroqv/JwTav3Em7cTCFrfM/il940BmQBLh63+3OYgSRy+B0+bmcZa/7Twg2woIZl2t1sBDt29mawUy7MzBPTx3E2IXZaw209Swe50KQ2vUsA70Gq8tUyL9GZBBbLLZsIPSqu41qMGP2lP/whHnDVRNeeR5Qj4A0Xk= ; Message-ID: <20061116000221.81575.qmail@web8703.mail.in.yahoo.com> Received: from [172.212.185.183] by web8703.mail.in.yahoo.com via HTTP; Thu, 16 Nov 2006 00:02:21 GMT Date: Thu, 16 Nov 2006 00:02:21 +0000 (GMT) From: Siddhartha Bhakta To: "Robert J. Sparks" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sipping@ietf.org Subject: [Sipping] Dialog usage termination in draft-ietf-sipping-dialogusage-05 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Robert, I have following comments on sec 4 (Dialog usage Destruction), [1] The sec 4.1 indicates that 200 of BYE destroy the dilaog usage. In fact reception of BYE also terminates Dialog usage. [2] For the BYE initiating side, the reception of 2xx, 481, 408, no response at all is received for the BYE (that is, a timeout is returned by the client transaction)to BYE terminates dialog usage. Refer, sec 15.1.1 of RFC3261 [3]Though sec 15.1.1 of RFC3261 indicates that only 481, 408 error response of BYE terminates dialog, I feel atleast 403 Forbidden should also terminate the dilaog usage. Consider the case when BYE is challenged by proxy(407) or end-user(401). The user shall re-send BYE with credential. If that credential is also not accepted then 403 Forbidden shall be received. The user is not suppose to send any message after receiving 403 Forbidden(Refer 21.4.4 of RFC3261). The 403 Forbidden should mark the dialog usage as down. Can we apply the same logic to NOTIFY-terminated also? The table 1 & 2 might need to be modified accordingly. [4] If BYE and NOTIFY-terminated is being rejected then how the dialog shall be terminated? Is there any guideline about the fallback error responses? I know of 401/407->403. I think, on receiving last fallback error response of BYE or NOTIFY-terminated, the corresponding dialog usage should be terminated. Thanks & Regards, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 15 20:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkW9U-0003mG-GY; Wed, 15 Nov 2006 20:34:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkW9T-0003m7-Cx for sipping@ietf.org; Wed, 15 Nov 2006 20:34:51 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkW9S-0003ab-70 for sipping@ietf.org; Wed, 15 Nov 2006 20:34:51 -0500 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2006111601340701100rk21re>; Thu, 16 Nov 2006 01:34:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAG1Xkjh001913 for ; Wed, 15 Nov 2006 20:33:46 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAG1XkCF001909; Wed, 15 Nov 2006 20:33:46 -0500 Date: Wed, 15 Nov 2006 20:33:46 -0500 Message-Id: <200611160133.kAG1XkCF001909@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <455B5FAC.9050908@alcatel.be> (stefaan.willaert@alcatel.be) Subject: Re: [Sipping] recover from avalanche registrations References: <455B5FAC.9050908@alcatel.be> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org There is little that can be done to avoid the fist cruch of registrations after a registrar becomes available again. Well, the phones can back off in the interval between registration attempts. If the normal registration interval is 60 mins, and at maximum back-off the phones attempt to register once every 10 mins, even if all the phones lose their registrations, the attempt rate is only 3,000 registrations/sec, not 28,000. Initially, only a small fraction of attempts succeed, but as those phones get registrations, the intensity of registrations decreases. What you can avoid is the problem 1 hour after restoration of service. Normally, if the phones request 2 hour expiration and re-register after 1 hour, there will be a huge burst of re-registration attempts 1 hour after restoration of service, which can choke the system. sipX avoids this by giving each phone not the registration time it asked for, but a random fraction of that time. This breaks up large blocks of registrations without the registrar having to maintain any additional state to allocate registration times. The cost is that the registrar has to handle about double the previous registration load. Unfortunately, some phones do not check the expiration time returned on the REGISTER response, and assume that they have been allocated the full requested time... Dale _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 03:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkc8V-0004DV-1b; Thu, 16 Nov 2006 02:58:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkc8T-0004Ci-Ex for sipping@ietf.org; Thu, 16 Nov 2006 02:58:13 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkc0G-0004Ul-Ns for sipping@ietf.org; Thu, 16 Nov 2006 02:49:46 -0500 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id kAG7nb5n015420; Thu, 16 Nov 2006 08:49:37 +0100 In-Reply-To: <455B95FD.6030909@bell-labs.com> Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery To: Volker Hilt X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Thu, 16 Nov 2006 08:49:35 +0100 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/16/2006 08:49:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Agree to make an explicit requirement, but the current proposal is now containing two requirements in my understanding. One related to the stability criteria, and one related to performance (-> throughput) under overload. The 2nd one is so far only considering throughput ("maximize throughput, = equal to offered load"), but not the requirement of bounding response times of (SIP) messages. A successfully processed SIP message and the correspondent response time are tightly coupled. A successfully processed message, but with too much delay, is typically meaningless. (The maximum response time is typically given by SIP protocol timers, or timers of the SIP served application, or behaviour of human beings behind a UA, or ...) Like to split them therefore into two: The overload mechanism should ensure that the system remains stable independent of the offered load (i.e., in the entire load range). When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load (under steady-state conditions). Response times (or system times; given by service time and all waiting times within the SIP entity) should be below a maximum value under all load conditions. - Albrecht Volker Hilt bs.com> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings , sipping 15.11.2006 23:34 Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> > Jennings >> >> bs.com> cc: sipping >> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 06:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkfdM-0005p0-J8; Thu, 16 Nov 2006 06:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkfdL-0005oo-A0 for sipping@ietf.org; Thu, 16 Nov 2006 06:42:19 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkfdJ-0005Ta-Ni for sipping@ietf.org; Thu, 16 Nov 2006 06:42:19 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1163677335!17133277!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15730 invoked from network); 16 Nov 2006 11:42:16 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-12.tower-120.messagelabs.com with SMTP; 16 Nov 2006 11:42:16 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAGBZTQp028586; Thu, 16 Nov 2006 06:35:29 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAGBZMmg028566; Thu, 16 Nov 2006 06:35:24 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Nov 2006 05:42:08 -0600 Message-ID: <28F05913385EAC43AF019413F674A017101B71F2@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Thread-Index: AccJWBx6tY+kga0KRQK6Vo+QmFpyEQAG+EGg From: "Dolly, Martin C, ALABS" To: , "Volker Hilt" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Is requirement #22 a step function, or does it support a gradual recovery?=20 -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de]=20 Sent: Thursday, November 16, 2006 2:50 AM To: Volker Hilt Cc: Cullen Jennings; sipping Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Agree to make an explicit requirement, but the current proposal is now containing two requirements in my understanding. One related to the stability criteria, and one related to performance (-> throughput) under overload. The 2nd one is so far only considering throughput ("maximize throughput, =3D equal to offered load"), but not the requirement of bounding response times of (SIP) messages. A successfully processed SIP message and the correspondent response time are tightly coupled. A successfully processed message, but with too much delay, is typically meaningless. (The maximum response time is typically given by SIP protocol timers, or timers of the SIP served application, or behaviour of human beings behind a UA, or ...) Like to split them therefore into two: The overload mechanism should ensure that the system remains stable independent of the offered load (i.e., in the entire load range). When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load (under steady-state conditions). Response times (or system times; given by service time and all waiting times within the SIP entity) should be below a maximum value under all load conditions. - Albrecht =20 Volker Hilt =20 bs.com> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings , =20 sipping 15.11.2006 23:34 Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery =20 =20 I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> > Jennings >> >> bs.com> cc: sipping >> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 11:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkk92-0006gT-VY; Thu, 16 Nov 2006 11:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkk92-0006gO-1k for sipping@ietf.org; Thu, 16 Nov 2006 11:31:20 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkk8x-0002T2-Gy for sipping@ietf.org; Thu, 16 Nov 2006 11:31:20 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAGGV3hd003416; Thu, 16 Nov 2006 10:31:03 -0600 (CST) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.4]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 10:31:03 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Thu, 16 Nov 2006 10:31:00 -0600 Message-ID: <9F1D84BDF02A2B41B030921EB09086188542CE@ILEXC1U01.ndc.lucent.com> In-Reply-To: <28F05913385EAC43AF019413F674A017101B71F2@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Thread-Index: AccJdVKJeo+WAXwAQV+CElmjsBZgsQAJIhWw From: "Widjaja, Indra \(Indra\)" To: "Dolly, Martin C, ALABS" , , "Volker Hilt" X-OriginalArrivalTime: 16 Nov 2006 16:31:03.0795 (UTC) FILETIME=[9BDE8C30:01C7099C] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: Cullen Jennings , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org My understanding is that #22 in "drops from above the overall capacity of the network to below the overall capacity" can take a step function. Requirement #22 also implies that the system is asymptotically stable. One question is whether a stronger or more specific requirement in #22 is needed such as by how much oscillation (if it occurs) should decay after a certain period, or what is the speed of convergence. Maybe, this is too much? Indra -----Original Message----- From: Dolly, Martin C, ALABS [mailto:mdolly@att.com]=20 Sent: Thursday, November 16, 2006 6:42 AM To: Albrecht.Schwarz@alcatel.de; Volker Hilt Cc: Cullen Jennings; sipping Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Is requirement #22 a step function, or does it support a gradual recovery?=20 -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de]=20 Sent: Thursday, November 16, 2006 2:50 AM To: Volker Hilt Cc: Cullen Jennings; sipping Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Agree to make an explicit requirement, but the current proposal is now containing two requirements in my understanding. One related to the stability criteria, and one related to performance (-> throughput) under overload. The 2nd one is so far only considering throughput ("maximize throughput, =3D equal to offered load"), but not the requirement of bounding response times of (SIP) messages. A successfully processed SIP message and the correspondent response time are tightly coupled. A successfully processed message, but with too much delay, is typically meaningless. (The maximum response time is typically given by SIP protocol timers, or timers of the SIP served application, or behaviour of human beings behind a UA, or ...) Like to split them therefore into two: The overload mechanism should ensure that the system remains stable independent of the offered load (i.e., in the entire load range). When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load (under steady-state conditions). Response times (or system times; given by service time and all waiting times within the SIP entity) should be below a maximum value under all load conditions. - Albrecht =20 Volker Hilt =20 bs.com> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings , =20 sipping 15.11.2006 23:34 Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery =20 =20 I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> > Jennings >> >> bs.com> cc: sipping >> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 12:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl4l-0001Rl-G6; Thu, 16 Nov 2006 12:30:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl4k-0001Rd-3z for sipping@ietf.org; Thu, 16 Nov 2006 12:30:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkl4i-0003MD-KI for sipping@ietf.org; Thu, 16 Nov 2006 12:30:58 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 09:30:55 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGHUrKS004810; Thu, 16 Nov 2006 12:30:53 -0500 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 kAGHUrDM029564; Thu, 16 Nov 2006 12:30:53 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:30:53 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:30:53 -0500 Message-ID: <455CA04E.2060302@cisco.com> Date: Thu, 16 Nov 2006 12:30:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <20061114183600.87124.qmail@web8712.mail.in.yahoo.com> In-Reply-To: <20061114183600.87124.qmail@web8712.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 17:30:53.0265 (UTC) FILETIME=[F75C3410:01C709A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2983; t=1163698253; x=1164562253; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=auFpwOjxC9wofc+2RuWyKucDLU17kfEs03n6ORx+aho=; b=E8DUJ0VnKkiRsyMf01e19BMpiZVTB5T88B8Y4edKyE0U+EPMhmFFe1WLVmAu/QGVSXEiSLQx KAxuOwFbMX/i2bX/CpevGZEKvUNv+h3v7+gX+YBr3JjgUDdI1JSQesTp; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sipping@ietf.org, Brett Tate X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > Brett, > > But forking proxy needs to send CANCEL for all early > dialogs after receiving final reasponse of one INVITE. > Why is the discrimination? > Is it due to the fact that forking proxy has to send > multiple INVITE and multiple dialogs are created due > to response of different INVITE dialogs whereas SIP-UA > behind Forking proxy creates multiple dialogs for a > single INVITE message? You keep talking about the dialogs as if they matter to the proxy. They do not. Proxies can function quite properly without any awareness of them. The proxy has one *transaction* with alice, and multiple *transactions* that it creates in order to do forking. The proxy is responsible for seeing that all of the transactions it initiated are completed. That is why *it* sends CANCEL to other transactions after it has a response it wants to send back. CANCEL is a request to terminate a *transaction* early, not a dialog. In the case of a 2xx response, the hope is that the cancel will be successful and as a result there will only be one 2xx response. However there remains a race condition in that case. It was deemed to be better for the UAC to deal with this case, so the proxy is expected to forward all the 2xx responses, and for the UAC to deal with them. This is recognized as an ugly case. May people wish forking had never been included, but it is, so we must deal with it. Paul > --- Brett Tate wrote: > >>> Neither Alice is sending CANCEL for dialog-ID1 & >> dialog-ID2, >>> nor Proxy is sending 3xx-6xx to Alice for >>> dialog-ID1 & dialog-ID2. >>> How dialog-ID1 & dialog-ID2 shall be terminated at >> Alice? You >>> are possibly suggesting Alice to send BYE on those >> dialog! >>> But that is missing in sec 2.9. >> If you look closer at rfc3261 (and rfc2543) >> basically only 1 final >> response for the INVITE is proxied back to the >> caller. Thus Alice can >> assume that the other dialogs have been released >> upon receiving a final >> response for the INVITE. During race conditions >> extra INVITE 2xx >> responses might be received on the other dialogs. >> Only within these >> race conditions does Alice need to send the extra >> BYEs. And there is no >> reason for Alice to send a CANCEL if a final >> response for the INVITE has >> been received because the forking proxies sent or >> will send the CANCELs >> as needed. >> > > > > > __________________________________________________________ > Yahoo! India Answers: Share what you know. Learn something new > http://in.answers.yahoo.com/ > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 12:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl6t-000244-Q5; Thu, 16 Nov 2006 12:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl6s-00023x-PY for sipping@ietf.org; Thu, 16 Nov 2006 12:33:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkl6r-0003Xy-EV for sipping@ietf.org; Thu, 16 Nov 2006 12:33:10 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 09:33:08 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAGHX7S9032399; Thu, 16 Nov 2006 12:33:07 -0500 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 kAGHX7YJ014362; Thu, 16 Nov 2006 12:33:07 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:33:07 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:33:06 -0500 Message-ID: <455CA0D4.1010303@cisco.com> Date: Thu, 16 Nov 2006 12:33:08 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <77BD870EA838FC469FDD2AE248B1357B01788E59@ATL1VEXC008.usdom003.tco.tc> <002401c7067a$b9222d30$0601a8c0@BEMBUSTER> In-Reply-To: <002401c7067a$b9222d30$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 17:33:06.0939 (UTC) FILETIME=[47093CB0:01C709A5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1266; t=1163698388; x=1164562388; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=/1c65hILjxc/69pZAcG2O1EykM+MCb7Zq7VfY7iKIeU=; b=JIfsAM9lhs6UMQjZ0D9/yKTNFQRhgwCiI5H+Tvyy3wWzonE2/7lIMit5IGJzLfOLCdWz10CV E1xCmVYuQ7kO2zH3mjIx0bgN90Aqd15mLKk/idMmIwOGDvAUBwbuyIzI; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Siddhartha Bhakta , sipping@ietf.org, Brett Tate X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I think solutions like this might have been good if they had been incorporated originally. But adding such behavior now is of dubious value. It doesn't save any work because of the need to be backwards compatible. Paul Jeroen van Bemmel wrote: >> I do not have a strong opinion concerning the sending of 181 (without >> SDP) when the proxy has received the 487 response. There are 3 >> options; however only option 1 is compliant with rfc3261. >> >> 1) Follow service example and add new To tag. This is the only >> rfc3261 compliant solution. >> > > As I wrote in a separate response, if we were to combine this with the > proxy not inserting a Contact, and have the UAC interpret that as "does > not want to continue with this dialog" (or at least "can safely postpone > creating an early dialog until a next response with a valid Contact > arrives"), we could have ourselves a workable solution. > > Jeroen > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 12:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3f-0001EA-SE; Thu, 16 Nov 2006 12:29:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3b-0001Al-Pq for sipping@ietf.org; Thu, 16 Nov 2006 12:29:47 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkktp-00013j-JU for sipping@ietf.org; Thu, 16 Nov 2006 12:19:44 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2006 09:19:40 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGHJe97001122; Thu, 16 Nov 2006 12:19:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAGHJeDM027164; Thu, 16 Nov 2006 12:19:40 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:19:40 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:19:39 -0500 Message-ID: <455C9DAB.5000101@cisco.com> Date: Thu, 16 Nov 2006 12:19:39 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11 References: <20061114173159.58671.qmail@web8701.mail.in.yahoo.com> In-Reply-To: <20061114173159.58671.qmail@web8701.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 17:19:39.0689 (UTC) FILETIME=[65E0A990:01C709A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9917; t=1163697580; x=1164561580; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20Query=20related=20to=20draft-ietf-sipping -service-examples-11 |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=i3LoByEcVjGL4+8EcuzqcrMaMfTLZWoAVn/S9ep6UCs=; b=QM6S1uokzMydSxN8Nx+vL0UEqOmleCuSEjNcIMPKsTForlKzXtx79pYI7945nXLlGIfWFEl+ 5sOtlzEK9snhSn54ZO5xgMZxSvq4ftUiWHgakETYuYJDPb68LYtJ/gMQ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments inline. Paul Siddhartha Bhakta wrote: >>> If 4xx-6xx >>> is received then depending on the via branch >>> parameter, forking proxy can know which dialog is >>> being terminated. >> This happens to work because only a single >> non-successful final response >> is ever returned. Note that this implies the >> termination of *all* early >> dialogs that might have been established. (There may >> have been more than >> one.) > > So far, I thought that each of the forked INVITE > transactions shall be managed independently. The 4xx > of one INVITE shall not affect other INVITE > transactions. Yes and no. The transactions transactions that the proxy initiates complete independently. But a forking proxy may only return one non-2xx final response. It can try other alternatives after receiving a non-2xx final response as long is it doesn't return one to the caller. Eventually it must decide which of the final responses to send upstream. When it does this it needs to cancel all the other other forks. OTOH, the proxy must return all 2xx responses it receives. So, if it has receives a non-2xx final response, and wishes to give up, it must cancel all outstanding forked requests and wait for them to complete, and then pick one of the final responses to send. If it receives a 2xx response, it is to send a cancel to all remaining branches, locally handle any non-2xx final responses, and forward all 2xx final responses. So, while each transaction the proxy initiates as a result of forking completes independently, but the proxy is forced to coordinate they way it manages them in order to follow proxy rules, and in order to send the proper responses to the invite transaction that it received. Also, while a forking proxy must be transaction stateful, it need not have any knowledge of the resulting dialog(s). > Atleast "2.12. Single Line Extension" of > draft-ietf-sipping-service-examples-10.txt indicates > so. I wouldn't use that as an authoritative source. There is a new -11 version that doesn't even include the example you reference. > After F8(480 Not Logged In) receiving also, Proxy was > continuing with the INVITE transaction with User B3. The *proxy* can continue. It knows about all the forks. But the UAC is unaware of this. The UAC can infer that forking is going on when it receives responses containing different to-tags. > It will be really surprising to me if you say that > call flow in 2.12 of Single Line Extension" of > draft-ietf-sipping-service-examples-10.txt is not as > per RFC3261. The reason is twofold. Firstly, this > draft is proposed(March, 2006) long after RFC3261. > Secondly, the forking proxes I came across do follow > the draft-ietf-sipping-service-examples-10.txt instead > of what you are saying. I just glanced at it, and without studying carefully, it does seem to be ok. (I don't know why it was removed in version -11.) But it seems to be properly returning to-tags. F7 and F11 both extablish early dialogs. F12 converts one of them into a final dialog. It is then up to the UAC to make the early dialog established by F7 go away. It should keep it around for a time in case a 200 comes in for it, but eventually if that doesn't happen it must discard it. > If I accept your comment, then I can say parallel > forking is not possible. Or atleast, parallel forking > will not be safe. If any instance of a given user > returns 4xx-6xx then all other forked INVITE > transaction shall be terminated. You and I probably aren't talking about the same thing. The situation id different at the UAC than it is at the proxy. > Only sequencial > forking shall be possible. On receiving final error > response from one INVITE, the forking proxy can send > another forked INVITE. Not before that. This shall > impose time constraint to any SIP services based on > SIP forking. I can see that > draft-ietf-sipping-service-examples-11 does not > mention any parallel forking. All the forkings in this > draft are sequencial. The "Single Line Extension" is > also removed from this draft. The UAC can't see any difference between serial and parallel forking, except that it might result in getting more than one 2xx response. Parallel forking is definitely permitted and can work. >>> About point 3) I can say that not to-tag but Via >>> Branch parameter of SIP responses helps forking >> proxy >>> to associate those with any forked dialog. >> I disagree. The branch parameter associates the >> response with a >> particular request. >> >> It is the Call-ID, To-tag, and From-tag that >> identify a particular >> dialog. In the forking case, the To-tags are not >> initially known to the >> UAC. So the Call-ID and From-tag define a >> half-formed dialog, and each >> response with a unique To-tag defines a new dialog. >> >> If you try to associate the half-formed dialog with >> the >> invite-transaction you may have trouble with some >> things. Of particular >> note, once you receive one 2xx response, you may >> have difficulty >> establishing added dialogs for other 2xx responses >> that might arrive. >> >> There is even more difficulty in case of >> subscribe/notify. In that case, >> extra dialogs may be established based on received >> NOTIFY requests which >> aren't tied to the SUBSCRIBE by branch, only by >> callid and tags. > > > We came across following call flow from the > deployment, > > Proxy OUR-NODE User2 User > | | | | > | INVITE F1 | | | > |----------->| INVITE F2 | | > | |----------->| | > | | 183 F3 | | > | 183 F4 |<-----------| | > |<-----------| | | > Request Timesout | | > | | | | > | CANCEL F5 | | | > |----------->| CANCEL F6 | | > | |----------->| | > | INVITE F7 | | | > |----------->| INVITE F8 | | > | |------------------------>| > | | 200 F9 | | > | 200 F10 |<-----------| | > |<-----------| | | > | | 487 F11 | | > | 487 F12 |<-----------| | > |<-----------| | | > | ACK F13 | | | > |----------->| ACK F14 | | > | |----------->| | > | | | | > | | 200 F15 | | > | 200 F16 |<------------------------| > |<-----------| | | > | ACK F17 | | | > |----------->| ACK F18 | | > | |------------------------>| > | | | | > | | | | > > If OUR-NODE is RFC3261 compliant Proxy then it shall > terminate other early dialog (created by 180; not > shown) on receiving 487 F11. I'm guessing you mean a 180 in response to F8, right? F1 and F7 are entirely independent. If OUR-NODE is a *proxy*, then when it receives F11, it should cancel any remaining transactions it established as a result of F1. In this case there aren't any. The transactions resulting from F7 are unaffected by this. Note that this has nothing to do with dialogs. The story is potentially different if OUR-NODE is a B2BUA, and there are few rules about how to get that right, except that it must act as a UA on both sides. If you are trying to have it be a B2BUA and yet appear to alice as a proxy, then it gets tricky indeed. > Therefore, the overlapped > forking as specified above shall be prevented by > OUR-NODE. If 3261 is followed there should be no problem here. > Only solution was to create separate half-formed > dialog for separate INVITE. This shall be done if we > consider the as the > half-formed dialog. As soon as to-tag shall be > received the dialog shall be created with From-tag, to-tag>. I believe, in RFC2543, branch > parameter was used to associate response with any > forked SIP Request. I don't have the time to go research again what 2543 called for here. > For the above flow, OUR-NODE could have delayed the > 2nd INVITE but this approach can not save us if > OUR-NODE is placed between Forking Proxy and Users in > "2.12 of Single Line Extension" call flow of > draft-ietf-sipping-service-examples-10.txt. > > However, you have rightly pointed out the > SUBSCRIBE-NOTIFY case, where the above approach shall > definitely fail as NOTIFY may create dialog initiated > by SUBSCRIBE. I always feel the special handling for > SUBSCRIBE-NOTIFY was not really necessary. If so, then > why it is not written that UPDATE can create the > dialog initiated by INVITE message. Due to network > problem, UPDATE can also reach to Caller before first > 1xx(non 100) response from Called party. Usually UPDATE is used in conjunction with 100rel. In that case, the 1xx will be confirmed by a PRACK before an UPDATE is sent. I see there is a potential issue if the 1xx isn't reliable and then an UPDATE is sent. In most cases I think the offer/answer rules will make this usage illegal. I suppose you could raise this as another issue for the Race Conditions draft to address if you think it important. > Thanks and Regards, > Siddhartha > > > > __________________________________________________________ > Yahoo! India Answers: Share what you know. Learn something new > http://in.answers.yahoo.com/ > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 12:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklBE-0004TC-KV; Thu, 16 Nov 2006 12:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklBD-0004Sx-FS for sipping@ietf.org; Thu, 16 Nov 2006 12:37:39 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklBC-0003zx-3I for sipping@ietf.org; Thu, 16 Nov 2006 12:37:39 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kAGHU7400078; Thu, 16 Nov 2006 12:30:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Thu, 16 Nov 2006 11:37:05 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371117C5202@zrc2hxm2.corp.nortel.com> In-Reply-To: <021d01c706cc$f7e65170$0500a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AccGjnrgUxuLDKUgT2ej+MGrazrbswAOrPLgALckYDA= From: "Brian Stucker" To: "Hadriel Kaplan" , "Siddhartha Bhakta" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Fake forking... Please note, if there's SDP in the other provisional responses, you're going to run into problems potentially getting themedia rendered (assuming that's your goal). Regards, Brian=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Sunday, November 12, 2006 8:40 PM > To: 'Siddhartha Bhakta'; sipping@ietf.org > Cc: 'Siddhartha Bhakta' > Subject: RE: [SIPPING] SDP offer/answer in early=20 > media:draft-sawada-sipping-sip-offeranswer-01.txt >=20 > If the Proxy is sending back SDP by itself it's not a proxy,=20 > but a b2bua, as is the PBX. > As such, it should be answering in a different dialog, so its=20 > SDP answer should be in a 183 with a different To-tag from=20 > the 180, and the PBX's 180 SDP should have a different To-tag=20 > than the 200ok. That would make them look like a forked call=20 > and follow the RFCs. >=20 > Of course the reality is often different, but being a b2bua=20 > yourself it's in your power to fix it. How you do that is=20 > not up to the IETF to define, as the very idea of it goes=20 > against the IETF's view of the world. (and I say that in a=20 > positive way, as I think it would be practically impossible=20 > for the IETF to do otherwise) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] > > Sent: Sunday, November 12, 2006 2:11 PM > > To: sipping@ietf.org > > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > > Subject: [SIPPING] SDP offer/answer in early=20 > > media:draft-sawada-sipping- sip-offeranswer-01.txt > >=20 > > I am re-sending it as in last email, the figure was distorted. > >=20 > > Though, post RFC3261 drafts indicate that one valid answer would be=20 > > there for one SDP offer, the our old friend early-media=20 > flow is still=20 > > present in practice. > >=20 > > B2BUA/SBC Proxy PABX Bob > > | | | | > > | INVITE F1 | | | > > |----------->| INVITE F2 | | > > | 183 F3 |----------->| INVITE F4 | > > |<-----------| |----------->| > > | | | | > > | | | 180 without SDP F5 > > | | |<-----------| > > | | | | > > | | 180 with SDP F6 | > > | 180 F7 |<-----------| | > > |<-----------| | 200 F8 | > > | | 200 F9 |<-----------| > > | 200 F10 |<-----------| | > > |<-----------| | | > > | ACK F11 | | | > > |----------->| ACK F12 | | > > | |----------->| ACK F13 | > > | | |----------->| > >=20 > > Our B2BUA is facing the problem as specified above. > > The first answer is carried > > by F3. This SDP is specified by Proxy. The 2nd SDP answer=20 > is carried=20 > > by F6,F7. > > In fact, this SDP is specified by PABX. The third SDP answer is=20 > > carried by F8,F9,F10. > > This SDP is specified by called party (Bob). > >=20 > > As per the RFC3261 & RFC3264, the SDP answer carried by=20 > F6,F7 should=20 > > match with F3 as far as B2BUA is concerned. Therefore, B2BUA shall=20 > > ignore it. This is leading to the fact that SIP UA behind B2BUA can=20 > > not listen to ringtone fed by PABX. > > Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This=20 > > shall lead to the fact that SIP UA behind B2BUA can not listen to=20 > > Bob's voice. Too bad. > > This problem is due to the fact that RFC3261 & RFC3264 are not=20 > > backward compatible. > >=20 > >=20 > > The sec 2.2. of > > draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE=20 > > should be used to update the media in early media. But in=20 > practice old=20 > > early-media flow (i.e., sending different SDPs over different 1xx=20 > > responses of > > INVITE) is quite common. > > Can we somehow make new SDP offer/answer specified in > > RFC3261 & RFC3264 backward > > compatible? > >=20 > > The old standard (early-media), allows multiple SDP answers=20 > of single=20 > > SDP offer. can we somehow induce this thing in SDP=20 > offer/answer model?=20 > > If many of you think the need of it then I may comeup with=20 > some thumb=20 > > rule for the same. > >=20 > > Thanks & Regards, > > Siddhartha >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 13:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklZo-0002lf-EB; Thu, 16 Nov 2006 13:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklZn-0002lZ-8X for sipping@ietf.org; Thu, 16 Nov 2006 13:03:03 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklZk-0007D4-3Q for sipping@ietf.org; Thu, 16 Nov 2006 13:03:03 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.241,BAYES_00: -1.665, MAILTO_TO_SPAM_ADDR: 0.106, SARE_RECV_ADDR: 0.027, SARE_SUB_MOBFU_2: 0.712 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Thu, 16 Nov 2006 17:58:23 +0000 From: "Siddhartha Bhakta" To: "'Brian Stucker'" , "'Hadriel Kaplan'" , "'Siddhartha Bhakta'" , Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Thu, 16 Nov 2006 17:58:16 -0000 Message-ID: <032401c709a8$cd760cd0$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AccGjnrgUxuLDKUgT2ej+MGrazrbswAOrPLgALckYDAAAFKdsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371117C5202@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I agree with you. No matter whether different provisional responses are creating different dialogs or not, case is same as far as media rendering/committing is concerned. For media committing, there are multiple answers for a given offer. Like you, I also can not understand what we are gaining by creating multiple dialogs here except the chance to manage offer/answer state as per RFC3261/RFC3264. It seems that multiple SDP answers for a given SDP offer is the reality. We can not avoid that by applying any tricky logic in dialog management (like Fake Forking). -----Original Message----- From: Brian Stucker [mailto:bstucker@nortel.com] Sent: 16 November 2006 17:37 To: Hadriel Kaplan; Siddhartha Bhakta; sipping@ietf.org Cc: Siddhartha Bhakta Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Fake forking... Please note, if there's SDP in the other provisional responses, you're going to run into problems potentially getting themedia rendered (assuming that's your goal). Regards, Brian > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sunday, November 12, 2006 8:40 PM > To: 'Siddhartha Bhakta'; sipping@ietf.org > Cc: 'Siddhartha Bhakta' > Subject: RE: [SIPPING] SDP offer/answer in early > media:draft-sawada-sipping-sip-offeranswer-01.txt > > If the Proxy is sending back SDP by itself it's not a proxy, > but a b2bua, as is the PBX. > As such, it should be answering in a different dialog, so its > SDP answer should be in a 183 with a different To-tag from > the 180, and the PBX's 180 SDP should have a different To-tag > than the 200ok. That would make them look like a forked call > and follow the RFCs. > > Of course the reality is often different, but being a b2bua > yourself it's in your power to fix it. How you do that is > not up to the IETF to define, as the very idea of it goes > against the IETF's view of the world. (and I say that in a > positive way, as I think it would be practically impossible > for the IETF to do otherwise) > > -hadriel > > > > -----Original Message----- > > From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] > > Sent: Sunday, November 12, 2006 2:11 PM > > To: sipping@ietf.org > > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > > Subject: [SIPPING] SDP offer/answer in early > > media:draft-sawada-sipping- sip-offeranswer-01.txt > > > > I am re-sending it as in last email, the figure was distorted. > > > > Though, post RFC3261 drafts indicate that one valid answer would be > > there for one SDP offer, the our old friend early-media > flow is still > > present in practice. > > > > B2BUA/SBC Proxy PABX Bob > > | | | | > > | INVITE F1 | | | > > |----------->| INVITE F2 | | > > | 183 F3 |----------->| INVITE F4 | > > |<-----------| |----------->| > > | | | | > > | | | 180 without SDP F5 > > | | |<-----------| > > | | | | > > | | 180 with SDP F6 | > > | 180 F7 |<-----------| | > > |<-----------| | 200 F8 | > > | | 200 F9 |<-----------| > > | 200 F10 |<-----------| | > > |<-----------| | | > > | ACK F11 | | | > > |----------->| ACK F12 | | > > | |----------->| ACK F13 | > > | | |----------->| > > > > Our B2BUA is facing the problem as specified above. > > The first answer is carried > > by F3. This SDP is specified by Proxy. The 2nd SDP answer > is carried > > by F6,F7. > > In fact, this SDP is specified by PABX. The third SDP answer is > > carried by F8,F9,F10. > > This SDP is specified by called party (Bob). > > > > As per the RFC3261 & RFC3264, the SDP answer carried by > F6,F7 should > > match with F3 as far as B2BUA is concerned. Therefore, B2BUA shall > > ignore it. This is leading to the fact that SIP UA behind B2BUA can > > not listen to ringtone fed by PABX. > > Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This > > shall lead to the fact that SIP UA behind B2BUA can not listen to > > Bob's voice. Too bad. > > This problem is due to the fact that RFC3261 & RFC3264 are not > > backward compatible. > > > > > > The sec 2.2. of > > draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE > > should be used to update the media in early media. But in > practice old > > early-media flow (i.e., sending different SDPs over different 1xx > > responses of > > INVITE) is quite common. > > Can we somehow make new SDP offer/answer specified in > > RFC3261 & RFC3264 backward > > compatible? > > > > The old standard (early-media), allows multiple SDP answers > of single > > SDP offer. can we somehow induce this thing in SDP > offer/answer model? > > If many of you think the need of it then I may comeup with > some thumb > > rule for the same. > > > > Thanks & Regards, > > Siddhartha > > > _______________________________________________ > 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 > --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 13:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklaZ-0003BJ-HZ; Thu, 16 Nov 2006 13:03:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GklaX-00039T-RB for sipping@ietf.org; Thu, 16 Nov 2006 13:03:49 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GklaW-0007K9-Ej for sipping@ietf.org; Thu, 16 Nov 2006 13:03:49 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAGI3js00071; Thu, 16 Nov 2006 13:03:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Date: Thu, 16 Nov 2006 12:03:45 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371117C5268@zrc2hxm2.corp.nortel.com> In-Reply-To: <032401c709a8$cd760cd0$3801a8c0@newportnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AccGjnrgUxuLDKUgT2ej+MGrazrbswAOrPLgALckYDAAAFKdsAAAmCuQ From: "Brian Stucker" To: "Siddhartha Bhakta" , "Hadriel Kaplan" , "Siddhartha Bhakta" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Actually, I think you can. Play out your early media as part of a separate dialog. Regards, Brian=20 > -----Original Message----- > From: Siddhartha Bhakta=20 > [mailto:Siddhartha.Bhakta@newport-networks.com]=20 > Sent: Thursday, November 16, 2006 11:58 AM > To: Stucker, Brian (RICH1:AR00); 'Hadriel Kaplan';=20 > 'Siddhartha Bhakta'; sipping@ietf.org > Subject: RE: [SIPPING] SDP offer/answer in early=20 > media:draft-sawada-sipping-sip-offeranswer-01.txt >=20 > I agree with you. No matter whether different provisional=20 > responses are creating different dialogs or not, case is same=20 > as far as media rendering/committing is concerned. For media=20 > committing, there are multiple answers for a given offer. >=20 > Like you, I also can not understand what we are gaining by=20 > creating multiple dialogs here except the chance to manage=20 > offer/answer state as per RFC3261/RFC3264. It seems that=20 > multiple SDP answers for a given SDP offer is the reality. We=20 > can not avoid that by applying any tricky logic in dialog=20 > management (like Fake Forking). >=20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: 16 November 2006 17:37 > To: Hadriel Kaplan; Siddhartha Bhakta; sipping@ietf.org > Cc: Siddhartha Bhakta > Subject: RE: [SIPPING] SDP offer/answer in early=20 > media:draft-sawada-sipping-sip-offeranswer-01.txt >=20 > Fake forking... >=20 > Please note, if there's SDP in the other provisional=20 > responses, you're going to run into problems potentially=20 > getting themedia rendered (assuming that's your goal). >=20 > Regards, > Brian=20 >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Sunday, November 12, 2006 8:40 PM > > To: 'Siddhartha Bhakta'; sipping@ietf.org > > Cc: 'Siddhartha Bhakta' > > Subject: RE: [SIPPING] SDP offer/answer in early=20 > > media:draft-sawada-sipping-sip-offeranswer-01.txt > >=20 > > If the Proxy is sending back SDP by itself it's not a proxy, but a=20 > > b2bua, as is the PBX. > > As such, it should be answering in a different dialog, so its SDP=20 > > answer should be in a 183 with a different To-tag from the 180, and=20 > > the PBX's 180 SDP should have a different To-tag than the=20 > 200ok. That=20 > > would make them look like a forked call and follow the RFCs. > >=20 > > Of course the reality is often different, but being a b2bua=20 > yourself=20 > > it's in your power to fix it. How you do that is not up to=20 > the IETF=20 > > to define, as the very idea of it goes against the IETF's=20 > view of the=20 > > world. (and I say that in a positive way, as I think it would be=20 > > practically impossible for the IETF to do otherwise) > >=20 > > -hadriel > >=20 > >=20 > > > -----Original Message----- > > > From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] > > > Sent: Sunday, November 12, 2006 2:11 PM > > > To: sipping@ietf.org > > > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > > > Subject: [SIPPING] SDP offer/answer in early > > > media:draft-sawada-sipping- sip-offeranswer-01.txt > > >=20 > > > I am re-sending it as in last email, the figure was distorted. > > >=20 > > > Though, post RFC3261 drafts indicate that one valid=20 > answer would be=20 > > > there for one SDP offer, the our old friend early-media > > flow is still > > > present in practice. > > >=20 > > > B2BUA/SBC Proxy PABX Bob > > > | | | | > > > | INVITE F1 | | | > > > |----------->| INVITE F2 | | > > > | 183 F3 |----------->| INVITE F4 | > > > |<-----------| |----------->| > > > | | | | > > > | | | 180 without SDP F5 > > > | | |<-----------| > > > | | | | > > > | | 180 with SDP F6 | > > > | 180 F7 |<-----------| | > > > |<-----------| | 200 F8 | > > > | | 200 F9 |<-----------| > > > | 200 F10 |<-----------| | > > > |<-----------| | | > > > | ACK F11 | | | > > > |----------->| ACK F12 | | > > > | |----------->| ACK F13 | > > > | | |----------->| > > >=20 > > > Our B2BUA is facing the problem as specified above. > > > The first answer is carried > > > by F3. This SDP is specified by Proxy. The 2nd SDP answer > > is carried > > > by F6,F7. > > > In fact, this SDP is specified by PABX. The third SDP answer is=20 > > > carried by F8,F9,F10. > > > This SDP is specified by called party (Bob). > > >=20 > > > As per the RFC3261 & RFC3264, the SDP answer carried by > > F6,F7 should > > > match with F3 as far as B2BUA is concerned. Therefore,=20 > B2BUA shall=20 > > > ignore it. This is leading to the fact that SIP UA behind=20 > B2BUA can=20 > > > not listen to ringtone fed by PABX. > > > Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This=20 > > > shall lead to the fact that SIP UA behind B2BUA can not listen to=20 > > > Bob's voice. Too bad. > > > This problem is due to the fact that RFC3261 & RFC3264 are not=20 > > > backward compatible. > > >=20 > > >=20 > > > The sec 2.2. of > > > draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE=20 > > > should be used to update the media in early media. But in > > practice old > > > early-media flow (i.e., sending different SDPs over different 1xx=20 > > > responses of > > > INVITE) is quite common. > > > Can we somehow make new SDP offer/answer specified in > > > RFC3261 & RFC3264 backward > > > compatible? > > >=20 > > > The old standard (early-media), allows multiple SDP answers > > of single > > > SDP offer. can we somehow induce this thing in SDP > > offer/answer model?=20 > > > If many of you think the need of it then I may comeup with > > some thumb > > > rule for the same. > > >=20 > > > Thanks & Regards, > > > Siddhartha > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 >=20 >=20 >=20 > --------------- > This e-mail may contain confidential and/or privileged=20 > information. If you are not the intended recipient (or have=20 > received this e-mail in error) please notify the sender=20 > immediately and delete this e-mail. Any unauthorized copying,=20 > disclosure or distribution of the contents in this e-mail is=20 > strictly forbidden. > --------------- >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 13:07:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkldU-0004qK-Tx; Thu, 16 Nov 2006 13:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkldT-0004q7-Fr for sipping@ietf.org; Thu, 16 Nov 2006 13:06:51 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkldR-0007o9-4d for sipping@ietf.org; Thu, 16 Nov 2006 13:06:51 -0500 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id kAGI6jm9027574; Thu, 16 Nov 2006 18:06:46 GMT Subject: Re: [Sipping] Comments on draft-malas-performance-metrics-05.txt From: Daryl Malas To: "Fardid, Reza" In-Reply-To: References: Content-Type: text/plain Date: Thu, 16 Nov 2006 11:10:47 -0700 Message-Id: <1163700648.16895.235.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Sat, 2006-11-11 at 15:25 -0800, Fardid, Reza wrote: > > > Daryl, > > > > Here are a few comments on this draft, based on a first pass through > it: > > > > 1. Introduction > > > > I would add User Behavior as another factor that can affect > measurements of some of the metrics. > I'll have to think about this further. Can you please give an example of how user behavior can effect signaling and therefore impact a metric? Thanks... > > > 3. SIP Performance Metrics > > > > If User Behavior MAY affect measurements of a metric, then it MUST be > noted for each defined metric. > See above. > > > 3.5 Session Establishment Ratio (SER) > > > > I suggest referencing ITU-T E.411 for the telephony definition of ASR, > unless GR-512-CORE includes it. I will review and reference as necessary. Thanks... > > 3.11 (or 3.5.1) Session Establishment Efficiency Ratio (SEER): > proposed as a new metric, unless it can be derived from currently > defined metrics > > > > This metric is used to provide a better representation of network > performance by eliminating user behavior from Session Established > Ratio (SER). It is known as Network Efficiency Ratio (NER) in > telephony applications, and was adopted from the ITU-T E.411 > Amendment. > > > > The following response codes provide a guideline for this metric: > > > > - 480 Temporarily Unavailable > > - 486 Busy Here > > - 600 Busy Everywhere > > > > SEER % = (# of INVITEs w/ associated 200OK + # of 480s + # of 486s + > # of 600s)/(Total # of INVITEs) > There are a number of metrics people have suggested. All of them are valid and good metrics. I will ask the working group to review them, and comment. I don't mind adding them if the mailing list finds significant value in them. Thanks... > > > Regards, > > Reza Fardid > > > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 13:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkls5-00023t-UZ; Thu, 16 Nov 2006 13:21:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkls4-0001zn-HI for sipping@ietf.org; Thu, 16 Nov 2006 13:21:56 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkls3-00017q-7B for sipping@ietf.org; Thu, 16 Nov 2006 13:21:56 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAGILgX09017 for ; Thu, 16 Nov 2006 13:21:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Nov 2006 12:21:33 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111820290@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A Test Balloon For AS generated Early Media: EMIND Thread-Index: AccJrAt0bBQhzOxuTayJQ+yk/9Q20Q== From: "Brian Stucker" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sipping] A Test Balloon For AS generated Early Media: EMIND X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org All, I think I have a way to fix application server generated early media, which I believe makes up a great deal of the solvable early media interactions we have today. This is early media triggered by some service in the SIP network that is supplied by a network controlled media server to the originating client. I'm looking for comments/poking of holes/support. To my mind, there are three major problems to be solved with application server generated early media: getting the middle out of the way of the end-to-end SDP negotiations, ensuring the middle has a chance at having the client render the intended media, and getting the ordering correct. Here's the proposal to address these areas: - The UAC generates an INVITE as it always has, except that it includes a supported tag denoting support for the early media model in this proposal (let's use the option tag "emind" - early media indicator for the sake of argument). - If an application server/proxy wants to trigger some sort of network generated early media back to the UAC, and it sees the "emind" supported option tag, it does so by generating a 183 message back to the UAC with an Alert-Info header that contains a SIP URI of the media resource it wishes the UAC to connect to. - Upon receiving the 183 message back with the Alert-Info header containing the SIP URI to connect to, the UAC generates another INVITE to the SIP URI from the 180 Alert-Info header. It may reuse the IP/ports from the original SDP offerin the first INVITE request for this early media offer if it so wishes (might be some issues with ICE processing here), however, it should set a different dynamic RTP payload type on in the SDP for this early media offer (more on this later). - The UAC now may negotiate SDP between the two endpoints entirely separately. It should know the exact state of each dialog and only end-to-end SDP exchanges should be occurring on the original INVITE dialog. The network media server would be contacted by the UAC for the early media the application server wanted presented and able to answer the early media INVITE to begin early media playback on that dialog. - In the meantime, the UAC now knows which packets are transitional or final media, and which ones are eary media because the RTP payload types are different. When the UAC sees final media coming from the first, end-to-end INVITE it can either wait for the 200 OK to comeon that dialog or switch over immediately to that media stream and BYE the early media INVITE. It is expected that the UAC's local outbound proxy will strip any Alert-Info headers from untrusted sources prior to sending them to the UAC today. Also, there would need to be a change to the Alert-Info syntax to allow a SIP URI. The forking issue should abate on the client as it can ignore any forking on the end-to-end INVITE as far as knowing whether or not it should revert to local ringback or not, and a q-value could be used to get the ordering right for early-media dialogs. Thoughts? Regards, Brian _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 13:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmHC-0007jy-RE; Thu, 16 Nov 2006 13:47:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmHC-0007jt-2P for sipping@ietf.org; Thu, 16 Nov 2006 13:47:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkmHA-0003gD-IY for sipping@ietf.org; Thu, 16 Nov 2006 13:47:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 10:47:50 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGIlnFw004860; Thu, 16 Nov 2006 13:47:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAGIlnDO021872; Thu, 16 Nov 2006 13:47:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 13:47:48 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 13:47:48 -0500 Message-ID: <455CB253.9060604@cisco.com> Date: Thu, 16 Nov 2006 13:47:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F837E.1010504@cisco.com> <455A80A6.5020902@cisco.com> In-Reply-To: <455A80A6.5020902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 18:47:48.0394 (UTC) FILETIME=[B63100A0:01C709AF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3574; t=1163702869; x=1164566869; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info=20(was=3A=20Re=3A=09[Sippin g]=09draft-stucker-sipping-early-media-coping) |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=d+CUEd3wVz/N7SmVhB1NJXGxaUwcR0lTMbUvmsQp1YY=; b=MR2hxaxeX9gEL0YvPwzKkRQPAJJkkdTdKpzuj27hAUKGADb2Hpx7k76UvXYG6l0mCcsGi/5Q kX3UruDdKY3j9VAcirZP+FgssfE22G/RyUiDZWZsRxD404hdtmRpXVux; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Cullen Jennings , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I mostly agree with Jonathan. One slight difference inline. Paul Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >> Brian, >> >> The case you specify is almost the same case I am talking about, but >> make more specific. >> >> I didn't say anything about what values the specific URIs should be. I >> think there are three interesting categories: >> 1) a URL of a remote resource that the UAS may actually retrieve >> and render >> >> 2) a URL of a resource local to the UAS. >> >> 3) a URN, that simply specifies a name of a particular alerting style. >> The UAS must know what to do for one of these to use it, or have its >> own way of discovering that given the URN. >> >> I have seen (2) used, but usually as an alternative for (3) in that it >> isn't really expected that the UAS will necessarily have something >> stored in exactly this way. I find (2) to be unreasonable in most >> deployments, and (3) to be a much more reasonable approach, that has >> equivalent functionality. >> >> This is all orthogonal to how trustworthiness of Alert-Info headers is >> managed. I find it difficult to imagine any cases when the UAS would >> want to honor a value sent by the UAC. > > Well, here is where URN helps. Since the UA that has to render the URN > has to know what it means, you can authorize it or not based on that > understanding. > > As others have pointed out, the URN is not going to help cases where > people want Britney Spears songs as ringback, but it can help with > country-specific ringbacks, where we could easily create a registry. > > I've become convinced that custom ringtones are best done the way they > are done today. The ringtone is stored on the called party device, and > logic on the phone itself selects which one to use based on the identity > of the caller. I think the above is a perfectly reasonable mechanism, well suited to reasonably smart devices with UIs and capabilities for the necessary configuration, and when it makes sense to manage each device independently. I also see value in a case where some of this logic is offloaded from the device to a server acting on its behalf. The server makes a decision about which alert as appropriate for each call, while the device does the rendering of that alert. This is potentially useful for devices that are limited in their capabilities in general and their UI in particular. It also could be helpful when there are multiple devices and the same alert selection logic is desired for them all. > Having the caller select content that gets rendered at > the called party, without asking the called party for authorization > (which is the case for ringtones), is a recipe for absolute disaster. > I'm not worried about tasteless music - I'm worried about some malicious > user that decides to record some highly offensive content and then start > calling random numbers to cause the content to get played out > automatically. Big mistake. Yes, I agree. At most, I can see a UA (or a proxy acting on behalf of the UA) accepting a small selection of Alert-Info values that it considers benign. Other values should be ignored. If a UA knows it has a proxy acting on its behalf in screen Alert-Info, and perhaps inserting values based on policy carried out by the proxy, then the UA may be willing to trust any value it receives via that proxy, and render any Alert-Info value it is capable of rendering. Paul > > -Jonathan R. > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 14:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmiR-00067b-0v; Thu, 16 Nov 2006 14:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmiP-00067W-Nw for sipping@ietf.org; Thu, 16 Nov 2006 14:16:01 -0500 Received: from web8706.mail.in.yahoo.com ([203.84.221.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkmiN-0008W4-PC for sipping@ietf.org; Thu, 16 Nov 2006 14:16:01 -0500 Received: (qmail 3500 invoked by uid 60001); 16 Nov 2006 19:15:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u7JG25kLYW0eQgsGNh7irJ/jfshkaKvbsgokGSVVyqRAnWwe6kG8QZtbx5YvfpRUJIsQ6/+zTcBzsQFcm/0UbvGoTR+FkZFG4Weok4hBWLGx3m41kd3CFmG3JxFO+nWeLAYZCe0zU02i9PWVe2T2ep5sx+yUPEpYrjd/EUkws/A= ; Message-ID: <20061116191536.3498.qmail@web8706.mail.in.yahoo.com> Received: from [172.188.68.35] by web8706.mail.in.yahoo.com via HTTP; Thu, 16 Nov 2006 19:15:35 GMT Date: Thu, 16 Nov 2006 19:15:35 +0000 (GMT) From: Siddhartha Bhakta Subject: RE: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt To: Brian Stucker , Siddhartha Bhakta , Hadriel Kaplan , sipping@ietf.org In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371117C5268@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org While UA is sending INVITE with SDP, it is listening on the media port(s) published by it. If multiple early media comes with different SDP description then UA have to accept media from different destinations irrespective of whether all these early media messages are part of different dialogs or not. However, as per RFC3264, offerer shall be able to receive media packet before receiving SDP answer (ofcourse, if offer media stream was recvonly/sendrecv). Then, why is 18x (with SDP) required? In early dialog, Media sending capability is not required. The RTCP can be one of the reason! can anyone confirm? If 18x is not necessary then fake forking shall not be required. Big relief :-) Forget about the case, I was talking about for a moment. If we take the fake forking case, in sec 2.9 of draft-ietf-sipping-service-examples-11. After receiving F13 (180 ringing), which SDP shall be used by Alice for media sending and RTCP purpose? (given that Alice is receiving packet from both the sources). --- Brian Stucker wrote: > Actually, I think you can. > > Play out your early media as part of a separate > dialog. > > Regards, > Brian > > > -----Original Message----- > > From: Siddhartha Bhakta > > [mailto:Siddhartha.Bhakta@newport-networks.com] > > Sent: Thursday, November 16, 2006 11:58 AM > > To: Stucker, Brian (RICH1:AR00); 'Hadriel Kaplan'; > > > 'Siddhartha Bhakta'; sipping@ietf.org > > Subject: RE: [SIPPING] SDP offer/answer in early > > media:draft-sawada-sipping-sip-offeranswer-01.txt > > > > I agree with you. No matter whether different > provisional > > responses are creating different dialogs or not, > case is same > > as far as media rendering/committing is concerned. > For media > > committing, there are multiple answers for a given > offer. > > > > Like you, I also can not understand what we are > gaining by > > creating multiple dialogs here except the chance > to manage > > offer/answer state as per RFC3261/RFC3264. It > seems that > > multiple SDP answers for a given SDP offer is the > reality. We > > can not avoid that by applying any tricky logic in > dialog > > management (like Fake Forking). > > > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: 16 November 2006 17:37 > > To: Hadriel Kaplan; Siddhartha Bhakta; > sipping@ietf.org > > Cc: Siddhartha Bhakta > > Subject: RE: [SIPPING] SDP offer/answer in early > > media:draft-sawada-sipping-sip-offeranswer-01.txt > > > > Fake forking... > > > > Please note, if there's SDP in the other > provisional > > responses, you're going to run into problems > potentially > > getting themedia rendered (assuming that's your > goal). > > > > Regards, > > Brian > > > > > -----Original Message----- > > > From: Hadriel Kaplan > [mailto:HKaplan@acmepacket.com] > > > Sent: Sunday, November 12, 2006 8:40 PM > > > To: 'Siddhartha Bhakta'; sipping@ietf.org > > > Cc: 'Siddhartha Bhakta' > > > Subject: RE: [SIPPING] SDP offer/answer in early > > > > > media:draft-sawada-sipping-sip-offeranswer-01.txt > > > > > > If the Proxy is sending back SDP by itself it's > not a proxy, but a > > > b2bua, as is the PBX. > > > As such, it should be answering in a different > dialog, so its SDP > > > answer should be in a 183 with a different > To-tag from the 180, and > > > the PBX's 180 SDP should have a different To-tag > than the > > 200ok. That > > > would make them look like a forked call and > follow the RFCs. > > > > > > Of course the reality is often different, but > being a b2bua > > yourself > > > it's in your power to fix it. How you do that > is not up to > > the IETF > > > to define, as the very idea of it goes against > the IETF's > > view of the > > > world. (and I say that in a positive way, as I > think it would be > > > practically impossible for the IETF to do > otherwise) > > > > > > -hadriel > > > > > > > > > > -----Original Message----- > > > > From: Siddhartha Bhakta > [mailto:sbhakta007@yahoo.co.in] > > > > Sent: Sunday, November 12, 2006 2:11 PM > > > > To: sipping@ietf.org > > > > Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta > > > > Subject: [SIPPING] SDP offer/answer in early > > > > media:draft-sawada-sipping- > sip-offeranswer-01.txt > > > > > > > > I am re-sending it as in last email, the > figure was distorted. > > > > > > > > Though, post RFC3261 drafts indicate that one > valid > > answer would be > > > > there for one SDP offer, the our old friend > early-media > > > flow is still > > > > present in practice. > > > > > > > > B2BUA/SBC Proxy PABX Bob > > > > | | | | > > > > | INVITE F1 | | | > > > > |----------->| INVITE F2 | | > > > > | 183 F3 |----------->| INVITE F4 | > > > > |<-----------| |----------->| > > > > | | | | > > > > | | | 180 without > SDP F5 > > > > | | |<-----------| > > > > | | | | > > > > | | 180 with SDP F6 | > > > > | 180 F7 |<-----------| | > > > > |<-----------| | 200 F8 | > > > > | | 200 F9 |<-----------| > > > > | 200 F10 |<-----------| | > > > > |<-----------| | | > > > > | ACK F11 | | | > > > > |----------->| ACK F12 | | > > > > | |----------->| ACK F13 | > > > > | | |----------->| > > > > > > > > Our B2BUA is facing the problem as specified > above. > > > > The first answer is carried > > > > by F3. This SDP is specified by Proxy. The 2nd > SDP answer > > > is carried > > > > by F6,F7. > > > > In fact, this SDP is specified by PABX. The > third SDP answer is > > > > carried by F8,F9,F10. > > > > This SDP is specified by called party (Bob). > > > > > > > > As per the RFC3261 & RFC3264, the SDP answer > carried by > > > F6,F7 should > > > > match with F3 as far as B2BUA is concerned. > Therefore, > > B2BUA shall > > > > ignore it. This is leading to the fact that > SIP UA behind > > B2BUA can > > > > not listen to ringtone fed by PABX. > > > > Similarly, SDP answer carried by F8,F9,F10 > shall be ignored. This > > > > shall lead to the fact that SIP UA behind > B2BUA can not listen to > > > > Bob's voice. Too bad. > > > > This problem is due to the fact that RFC3261 & > RFC3264 are not > > > > backward compatible. > > > > > > > > > > > > The sec 2.2. of > > > > draft-sawada-sipping-sip-offeranswer-01.txt > indicates that UPDATE > > > > should be used to update the media in early > media. But in > > > practice old > > > > early-media flow (i.e., sending different SDPs > over different 1xx > > > > responses of > > > > INVITE) is quite common. > > > > Can we somehow make new SDP offer/answer > specified in > > > > RFC3261 & RFC3264 backward > > > > compatible? > > > > > > > > The old standard (early-media), allows > multiple SDP answers > > > of single > > > > SDP offer. can we somehow induce this thing in > SDP > > > offer/answer model? > > > > If many of you think the need of it then I may > comeup with > > > some thumb > > > > rule for the same. > === message truncated === __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 15:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknNH-0003qB-Cw; Thu, 16 Nov 2006 14:58:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknNG-0003q6-EN for sipping@ietf.org; Thu, 16 Nov 2006 14:58:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknNE-00022G-Q8 for sipping@ietf.org; Thu, 16 Nov 2006 14:58:14 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 11:58:11 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAGJwAIO004056; Thu, 16 Nov 2006 14:58:10 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAGJwAYJ029174; Thu, 16 Nov 2006 14:58:10 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:58:10 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 14:58:09 -0500 Message-ID: <455CC2D1.9020406@cisco.com> Date: Thu, 16 Nov 2006 14:58:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Siddhartha Bhakta Subject: Re: [SIPPING] SDP offer/answer in early media:draft-sawada-sipping-sip-offeranswer-01.txt References: <032401c709a8$cd760cd0$3801a8c0@newportnetworks.com> In-Reply-To: <032401c709a8$cd760cd0$3801a8c0@newportnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 19:58:09.0767 (UTC) FILETIME=[8A536770:01C709B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7275; t=1163707090; x=1164571090; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[SIPPING]=20SDP=20offer/answer=20in=20early=09media=3 Adraft-sawada-sipping-sip-offeranswer-01.txt |Sender:=20 |To:=20Siddhartha=20Bhakta=20; bh=8FY4hpIc0xqoJDkF47iut0sJjUqbJxcvpAlW1X0uKpA=; b=momOOKrfdj1l+BkEWoMrsGuD4iQMtUKdWbVw0xJZjqO1JAle2EU0gXX7JdtsnSdNtCJVx71Z VoCQT5cgi8oGLaW0hi3By0fyGK5HrVRZuMvs6Iico9DK279YsTxS2Lso; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sipping@ietf.org, 'Siddhartha Bhakta' , 'Brian Stucker' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Siddhartha Bhakta wrote: > I agree with you. No matter whether different provisional responses are > creating different dialogs or not, case is same as far as media > rendering/committing is concerned. For media committing, there are multiple > answers for a given offer. > > Like you, I also can not understand what we are gaining by creating multiple > dialogs here except the chance to manage offer/answer state as per > RFC3261/RFC3264. It seems that multiple SDP answers for a given SDP offer is > the reality. We can not avoid that by applying any tricky logic in dialog > management (like Fake Forking). If you ignore dialogs, it becomes impossible to impose any offer/answer rules. By paying attention to the separate dialogs, it is possible to have offer/answer rules that make sense. If you just mix together offers or answers from multiple destinations it becomes impossible to make any sense of what you have once it is determined which dialog will be completed. For the period when there are multiple dialogs, you have two different things going on: - an offer/answer state machine is proceeding in each dialog, and defining the current media parameters for that dialog - you are deciding which dialog(s) you want to process and send media to. As Brian notes, it is complex to decide which dialog to honor during the early stage. But once you settle on one dialog at least you will then know what to do. Paul > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: 16 November 2006 17:37 > To: Hadriel Kaplan; Siddhartha Bhakta; sipping@ietf.org > Cc: Siddhartha Bhakta > Subject: RE: [SIPPING] SDP offer/answer in early > media:draft-sawada-sipping-sip-offeranswer-01.txt > > Fake forking... > > Please note, if there's SDP in the other provisional responses, you're > going to run into problems potentially getting themedia rendered > (assuming that's your goal). > > Regards, > Brian > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Sunday, November 12, 2006 8:40 PM >> To: 'Siddhartha Bhakta'; sipping@ietf.org >> Cc: 'Siddhartha Bhakta' >> Subject: RE: [SIPPING] SDP offer/answer in early >> media:draft-sawada-sipping-sip-offeranswer-01.txt >> >> If the Proxy is sending back SDP by itself it's not a proxy, >> but a b2bua, as is the PBX. >> As such, it should be answering in a different dialog, so its >> SDP answer should be in a 183 with a different To-tag from >> the 180, and the PBX's 180 SDP should have a different To-tag >> than the 200ok. That would make them look like a forked call >> and follow the RFCs. >> >> Of course the reality is often different, but being a b2bua >> yourself it's in your power to fix it. How you do that is >> not up to the IETF to define, as the very idea of it goes >> against the IETF's view of the world. (and I say that in a >> positive way, as I think it would be practically impossible >> for the IETF to do otherwise) >> >> -hadriel >> >> >>> -----Original Message----- >>> From: Siddhartha Bhakta [mailto:sbhakta007@yahoo.co.in] >>> Sent: Sunday, November 12, 2006 2:11 PM >>> To: sipping@ietf.org >>> Cc: sbhakta007@yahoo.co.in; Siddhartha Bhakta >>> Subject: [SIPPING] SDP offer/answer in early >>> media:draft-sawada-sipping- sip-offeranswer-01.txt >>> >>> I am re-sending it as in last email, the figure was distorted. >>> >>> Though, post RFC3261 drafts indicate that one valid answer would be >>> there for one SDP offer, the our old friend early-media >> flow is still >>> present in practice. >>> >>> B2BUA/SBC Proxy PABX Bob >>> | | | | >>> | INVITE F1 | | | >>> |----------->| INVITE F2 | | >>> | 183 F3 |----------->| INVITE F4 | >>> |<-----------| |----------->| >>> | | | | >>> | | | 180 without SDP F5 >>> | | |<-----------| >>> | | | | >>> | | 180 with SDP F6 | >>> | 180 F7 |<-----------| | >>> |<-----------| | 200 F8 | >>> | | 200 F9 |<-----------| >>> | 200 F10 |<-----------| | >>> |<-----------| | | >>> | ACK F11 | | | >>> |----------->| ACK F12 | | >>> | |----------->| ACK F13 | >>> | | |----------->| >>> >>> Our B2BUA is facing the problem as specified above. >>> The first answer is carried >>> by F3. This SDP is specified by Proxy. The 2nd SDP answer >> is carried >>> by F6,F7. >>> In fact, this SDP is specified by PABX. The third SDP answer is >>> carried by F8,F9,F10. >>> This SDP is specified by called party (Bob). >>> >>> As per the RFC3261 & RFC3264, the SDP answer carried by >> F6,F7 should >>> match with F3 as far as B2BUA is concerned. Therefore, B2BUA shall >>> ignore it. This is leading to the fact that SIP UA behind B2BUA can >>> not listen to ringtone fed by PABX. >>> Similarly, SDP answer carried by F8,F9,F10 shall be ignored. This >>> shall lead to the fact that SIP UA behind B2BUA can not listen to >>> Bob's voice. Too bad. >>> This problem is due to the fact that RFC3261 & RFC3264 are not >>> backward compatible. >>> >>> >>> The sec 2.2. of >>> draft-sawada-sipping-sip-offeranswer-01.txt indicates that UPDATE >>> should be used to update the media in early media. But in >> practice old >>> early-media flow (i.e., sending different SDPs over different 1xx >>> responses of >>> INVITE) is quite common. >>> Can we somehow make new SDP offer/answer specified in >>> RFC3261 & RFC3264 backward >>> compatible? >>> >>> The old standard (early-media), allows multiple SDP answers >> of single >>> SDP offer. can we somehow induce this thing in SDP >> offer/answer model? >>> If many of you think the need of it then I may comeup with >> some thumb >>> rule for the same. >>> >>> Thanks & Regards, >>> Siddhartha >> >> _______________________________________________ >> 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 >> > > > > --------------- > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. > --------------- > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 16:35:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkosD-0000sQ-U4; Thu, 16 Nov 2006 16:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkosD-0000sL-4s for sipping@ietf.org; Thu, 16 Nov 2006 16:34:17 -0500 Received: from mail18.syd.optusnet.com.au ([211.29.132.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkos8-00034i-EP for sipping@ietf.org; Thu, 16 Nov 2006 16:34:17 -0500 Received: from c210-49-37-63.rochd2.qld.optusnet.com.au (c210-49-37-63.rochd2.qld.optusnet.com.au [210.49.37.63]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kAGLY8SS002226 for ; Fri, 17 Nov 2006 08:34:10 +1100 From: Benjamin Carlyle To: sipping@ietf.org Content-Type: text/plain Date: Fri, 17 Nov 2006 07:34:05 +1000 Message-Id: <1163712845.4597.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sipping] SIP Subscription for SCADA/Stock quotes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org G'day, I work for Westinghouse Rail Systems Australia, and am investigating standard subscription protocols for use in our SCADA product line. SCADA systems (centralised monitoring and control of remote equipment such as power distribution systems) tend to rely a lot on subscription to push data to users and to distributed services. SIP has come up as a possible way to do this, however at present given my reading of rfc3265 I suspect it is not appropriate and would like to confirm with this mailing list. rfc3265 indicates that it is not a general purpose subscription mechanism. Specific weaknesses I see include * There is no obvious way to subscribe to a HTTP resource. Subscriptions are sent to the combination of a SIP url and event package identifier. * Proxies are used for transport through firewall-intensive networks, but do not participate in the subscription. A restful architecture is constrained to support layering, whereby muliple clients who share a proxy might enjoy a multicasting effect through the proxy * Data flow is limited by explicit timers. In a SCADA or stock quote system old data degrades rapidly in value with time, and the objective is to get as close as possible to immediate notifications. The maximum notification rate should be related to available bandwidth, or at worst to network latency * Subscriptions are refreshed individually at a client-specified rate. In a SCADA environment we are likely to have thousands of subscriptions active between a client and server. The client-specified rate may be used as a keep-alive so that the client can detect server death and recreate its subscriptions on another cluster member. I believe it is better for the client to send exactly no renewals. Keep-alive should be sent from the server only, and at a long reliable rate when no data has been transmitted over the subscription during the keep-alive interval. Before I started my quest for an appropriate protocol, I wrote up a strawman which may be viewed here: http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt If I am unable to resolve the issues I have with existing standards I intend to refine and propose the straw-man as a potential standards-track rfc. I hope to find that an appropriate subscription mechanism already exists. I see defining a new one as something of a last resort. Security is still a weakness of my protocol when NOTIFY and PATCHNOTIFY are used. HTTP may only support the EXPIRE notification model without additional trust mechanisms becoming better understood and deployed. I believe I have already ruled out the use of XMPP's XEP-0060 given the way that it makes use of an intermediatary to manage subscriptions but does not summarise subscription data for slow clients: http://mail.jabber.org/pipermail/standards-jig/2006-November/012971.html http://mail.jabber.org/pipermail/standards-jig/2006-November/012974.html http://mail.jabber.org/pipermail/standards-jig/2006-November/013042.html Benjamin. _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 17:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpc9-0005on-KE; Thu, 16 Nov 2006 17:21:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpc8-0005oi-Q9 for sipping@ietf.org; Thu, 16 Nov 2006 17:21:44 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkpc7-0002rS-DV for sipping@ietf.org; Thu, 16 Nov 2006 17:21:44 -0500 Received: from lion.cs.columbia.edu (IDENT:tSIxmSo/w9ME5K0OEvkknzJqaX/2AG44@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kAGMLcOa027396 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 16 Nov 2006 17:21:38 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id kAGMLZaB007413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Nov 2006 17:21:37 -0500 Message-ID: <455CE46A.50808@cs.columbia.edu> Date: Thu, 16 Nov 2006 17:21:30 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Benjamin Carlyle Subject: Re: [Sipping] SIP Subscription for SCADA/Stock quotes References: <1163712845.4597.25.camel@localhost.localdomain> In-Reply-To: <1163712845.4597.25.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I don't think you should quite give up yet. Some of the constraints are general pieces of advice, not protocol constraints. They are meant to protect certain general-purpose call routing proxies, say, which isn't a concern in your case. Benjamin Carlyle wrote: > G'day, > > I work for Westinghouse Rail Systems Australia, and am investigating > standard subscription protocols for use in our SCADA product line. SCADA > systems (centralised monitoring and control of remote equipment such as > power distribution systems) tend to rely a lot on subscription to push > data to users and to distributed services. SIP has come up as a possible > way to do this, however at present given my reading of rfc3265 I suspect > it is not appropriate and would like to confirm with this mailing list. > > rfc3265 indicates that it is not a general purpose subscription > mechanism. Specific weaknesses I see include > * There is no obvious way to subscribe to a HTTP resource. Subscriptions > are sent to the combination of a SIP url and event package identifier. I don't know what you mean by 'subscribe to HTTP resources'. Clearly, if you want to monitor if an HTTP resource changes, that resource has to PUBLISH or NOTIFY when the change occurs. > * Proxies are used for transport through firewall-intensive networks, > but do not participate in the subscription. A restful architecture is > constrained to support layering, whereby muliple clients who share a > proxy might enjoy a multicasting effect through the proxy I don't understand this comment. > * Data flow is limited by explicit timers. In a SCADA or stock quote > system old data degrades rapidly in value with time, and the objective > is to get as close as possible to immediate notifications. The maximum > notification rate should be related to available bandwidth, or at worst > to network latency See my comment at the top. This may not apply in your case. > * Subscriptions are refreshed individually at a client-specified rate. > In a SCADA environment we are likely to have thousands of subscriptions > active between a client and server. The client-specified rate may be > used as a keep-alive so that the client can detect server death and > recreate its subscriptions on another cluster member. I believe it is > better for the client to send exactly no renewals. Keep-alive should be > sent from the server only, and at a long reliable rate when no data has > been transmitted over the subscription during the keep-alive interval. There is nothing that prevents the client from specifying a long (infinite) expiration interval or the server from changing it. Thus, you can easily implement a model where the client detects server liveness. The reason for the client renewal was to prevent "memory leakage" on the server, where clients no longer interested in subscriptions would get NOTIFYs. > > Before I started my quest for an appropriate protocol, I wrote up a > strawman which may be viewed here: > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt > > If I am unable to resolve the issues I have with existing standards I > intend to refine and propose the straw-man as a potential > standards-track rfc. I hope to find that an appropriate subscription > mechanism already exists. I see defining a new one as something of a > last resort. > > Security is still a weakness of my protocol when NOTIFY and PATCHNOTIFY > are used. HTTP may only support the EXPIRE notification model without > additional trust mechanisms becoming better understood and deployed. > > I believe I have already ruled out the use of XMPP's XEP-0060 given the > way that it makes use of an intermediatary to manage subscriptions but > does not summarise subscription data for slow clients: > http://mail.jabber.org/pipermail/standards-jig/2006-November/012971.html > http://mail.jabber.org/pipermail/standards-jig/2006-November/012974.html > http://mail.jabber.org/pipermail/standards-jig/2006-November/013042.html > > Benjamin. > > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 17:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpmV-0002DM-Su; Thu, 16 Nov 2006 17:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpmU-0002D7-L2 for sipping@ietf.org; Thu, 16 Nov 2006 17:32:26 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpmS-0004dn-Vv for sipping@ietf.org; Thu, 16 Nov 2006 17:32:26 -0500 Received: from [192.168.1.6] ([68.160.33.116]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J8U008HRH1EM4F0@vms040.mailsrvcs.net> for sipping@ietf.org; Thu, 16 Nov 2006 16:27:16 -0600 (CST) Date: Thu, 16 Nov 2006 17:27:10 -0500 From: David Robbins Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) In-reply-to: <455CB253.9060604@cisco.com> To: Paul Kyzivat Message-id: MIME-version: 1.0 (Apple Message framework v624) X-Mailer: Apple Mail (2.624) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F837E.1010504@cisco.com> <455A80A6.5020902@cisco.com> <455CB253.9060604@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Cullen Jennings , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Several items in this thread have touched on the idea of defining URNs to represent a "well known" set of alerting patterns (e.g., national standard sets such as the "Bellcore" patterns in the US). While that is useful only in limited contexts and circumstances, as noted by many in this discussion, it is sufficiently useful that it would, in my opinion, be worth doing. In work I'm currently involved in, we are encountering two different sets of URLs that (as Paul noted) are used as a "poor man's URN," and may see more variations in the future. An actual URN namespace with identifiers defined for each of the standard alerting patterns would be preferable, to simplify interoperability. Are we at a point where we can propose such a URN namespace? Pick a namespace ID (perhaps "alert" or "std-alert"). The NSS wouldn't have to be anything more complicated than a name, though it could have two components, the first indicating the jurisdiction within which the standard pattern is defined (e.g., a country, or administration) and the second indicating the specific pattern. Wouldn't want to make it more complex than necessary, but sufficiently flexible to be used not just in North America. On Nov 16, 2006, at 1:47 PM, Paul Kyzivat wrote: > I mostly agree with Jonathan. One slight difference inline. > > Paul > > Jonathan Rosenberg wrote: >> inline. >> Paul Kyzivat wrote: >>> Brian, >>> >>> The case you specify is almost the same case I am talking about, but >>> make more specific. >>> >>> I didn't say anything about what values the specific URIs should be. >>> I think there are three interesting categories: >>> 1) a URL of a remote resource that the UAS may actually retrieve >>> and render >>> >>> 2) a URL of a resource local to the UAS. >>> >>> 3) a URN, that simply specifies a name of a particular alerting >>> style. >>> The UAS must know what to do for one of these to use it, or have >>> its >>> own way of discovering that given the URN. >>> >>> I have seen (2) used, but usually as an alternative for (3) in that >>> it isn't really expected that the UAS will necessarily have >>> something stored in exactly this way. I find (2) to be unreasonable >>> in most deployments, and (3) to be a much more reasonable approach, >>> that has equivalent functionality. >>> >>> This is all orthogonal to how trustworthiness of Alert-Info headers >>> is managed. I find it difficult to imagine any cases when the UAS >>> would want to honor a value sent by the UAC. >> Well, here is where URN helps. Since the UA that has to render the >> URN has to know what it means, you can authorize it or not based on >> that understanding. >> As others have pointed out, the URN is not going to help cases where >> people want Britney Spears songs as ringback, but it can help with >> country-specific ringbacks, where we could easily create a registry. >> I've become convinced that custom ringtones are best done the way >> they are done today. The ringtone is stored on the called party >> device, and logic on the phone itself selects which one to use based >> on the identity of the caller. > > I think the above is a perfectly reasonable mechanism, well suited to > reasonably smart devices with UIs and capabilities for the necessary > configuration, and when it makes sense to manage each device > independently. > > I also see value in a case where some of this logic is offloaded from > the device to a server acting on its behalf. The server makes a > decision about which alert as appropriate for each call, while the > device does the rendering of that alert. This is potentially useful > for devices that are limited in their capabilities in general and > their UI in particular. It also could be helpful when there are > multiple devices and the same alert selection logic is desired for > them all. > >> Having the caller select content that gets rendered at the called >> party, without asking the called party for authorization (which is >> the case for ringtones), is a recipe for absolute disaster. I'm not >> worried about tasteless music - I'm worried about some malicious user >> that decides to record some highly offensive content and then start >> calling random numbers to cause the content to get played out >> automatically. Big mistake. > > Yes, I agree. At most, I can see a UA (or a proxy acting on behalf of > the UA) accepting a small selection of Alert-Info values that it > considers benign. Other values should be ignored. > > If a UA knows it has a proxy acting on its behalf in screen > Alert-Info, and perhaps inserting values based on policy carried out > by the proxy, then the UA may be willing to trust any value it > receives via that proxy, and render any Alert-Info value it is capable > of rendering. > > Paul > >> -Jonathan R. > > _______________________________________________ > 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 > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 17:48:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkq0p-0001kA-GF; Thu, 16 Nov 2006 17:47:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkq0m-0001ju-QA for sipping@ietf.org; Thu, 16 Nov 2006 17:47:12 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkq0j-00072U-Ex for sipping@ietf.org; Thu, 16 Nov 2006 17:47:12 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAGMkfX04213; Thu, 16 Nov 2006 17:46:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Thu, 16 Nov 2006 16:46:38 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FB9009F@zrc2hxm2.corp.nortel.com> In-Reply-To: <1163712845.4597.25.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccJx6TQvC1F5/7fS+SFJ1f5lVCYwgAAtcrA From: "Samir Srivastava" To: "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Do we want to cater the different verticals now ? More in-line. Thx Samir > -----Original Message----- > From: Benjamin Carlyle [mailto:benjamincarlyle@optusnet.com.au] > Sent: Thursday, November 16, 2006 1:34 PM > To: sipping@ietf.org > Subject: [Sipping] SIP Subscription for SCADA/Stock quotes >=20 > G'day, >=20 > I work for Westinghouse Rail Systems Australia, and am investigating > standard subscription protocols for use in our SCADA product line. SCADA > systems (centralised monitoring and control of remote equipment such as > power distribution systems) tend to rely a lot on subscription to push > data to users and to distributed services. SIP has come up as a possible > way to do this, however at present given my reading of rfc3265 I suspect > it is not appropriate and would like to confirm with this mailing list. >=20 > rfc3265 indicates that it is not a general purpose subscription > mechanism. Specific weaknesses I see include > * There is no obvious way to subscribe to a HTTP resource. Subscriptions > are sent to the combination of a SIP url and event package identifier. We can transport different URL schemes over SIP network e.g. Tel, URN etc, It will require enhancements to current PUBLISH etc. > * Proxies are used for transport through firewall-intensive networks, > but do not participate in the subscription. A restful architecture is > constrained to support layering, whereby muliple clients who share a > proxy might enjoy a multicasting effect through the proxy As far as I know, maddr was meant for that originally. 3261 talks about the multicasting at several places. But I don't know, who has implemented that. ICE is nice solution within MMUSIC for firewall/NAT traversal.=20 > * Data flow is limited by explicit timers. In a SCADA or stock quote > system old data degrades rapidly in value with time, and the objective > is to get as close as possible to immediate notifications. The maximum > notification rate should be related to available bandwidth, or at worst > to network latency Overload/congestion etc in this regard is the work in progress. > * Subscriptions are refreshed individually at a client-specified rate. > In a SCADA environment we are likely to have thousands of subscriptions > active between a client and server. The client-specified rate may be > used as a keep-alive so that the client can detect server death and > recreate its subscriptions on another cluster member. I believe it is > better for the client to send exactly no renewals. Keep-alive should be > sent from the server only, and at a long reliable rate when no data has > been transmitted over the subscription during the keep-alive interval. Server has a mechanism with Min-Expire header with 423 response to enforce the refresh interval, it is comfortable with. You can use OPTIONS from server to do that with a long subscription duration. =20 >=20 > Before I started my quest for an appropriate protocol, I wrote up a > strawman which may be viewed here: > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt >=20 > If I am unable to resolve the issues I have with existing standards I > intend to refine and propose the straw-man as a potential > standards-track rfc. I hope to find that an appropriate subscription > mechanism already exists. I see defining a new one as something of a > last resort. >=20 > Security is still a weakness of my protocol when NOTIFY and PATCHNOTIFY > are used. HTTP may only support the EXPIRE notification model without > additional trust mechanisms becoming better understood and deployed. We are heavily involved in ironing out security issues. =20 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 18:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkquW-0005oh-Ed; Thu, 16 Nov 2006 18:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkquU-0005mo-P3 for sipping@ietf.org; Thu, 16 Nov 2006 18:44:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkquT-0007tc-4n for sipping@ietf.org; Thu, 16 Nov 2006 18:44:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 15:44:44 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAGNihd8026957; Thu, 16 Nov 2006 18:44:43 -0500 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 kAGNihYJ007451; Thu, 16 Nov 2006 18:44:43 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:44:43 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:44:43 -0500 Message-ID: <455CF7EA.5070404@cisco.com> Date: Thu, 16 Nov 2006 18:44:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Robbins Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F837E.1010504@cisco.com> <455A80A6.5020902@cisco.com> <455CB253.9060604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2006 23:44:43.0061 (UTC) FILETIME=[308F7650:01C709D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6448; t=1163720683; x=1164584683; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Utility=20of=20Alert-Info=20(was=3A=09Re=3A=09[Sippin g]=20draft-stucker-sipping-early-media-coping) |Sender:=20 |To:=20David=20Robbins=20; bh=8z3eI5VutbxKbhiD8eYV2RdDiMoT/K3O9QNEl6wzRJ0=; b=dVVf5M63l3UouNxk15Uwv36mYO3DDzc8e/yn1KJv38OdpJI7tLLMcgfF3TM/tCuysK66w/cf DGd7bHRFQ3T14lTajyfpl1+6CswP3Iylrtl4TUnPPRNPSQF/QKJQOPhn; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Cullen Jennings , sipping , Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org David Robbins wrote: > Several items in this thread have touched on the idea of defining URNs > to represent a "well known" set of alerting patterns (e.g., national > standard sets such as the "Bellcore" patterns in the US). While that is > useful only in limited contexts and circumstances, as noted by many in > this discussion, it is sufficiently useful that it would, in my opinion, > be worth doing. In work I'm currently involved in, we are encountering > two different sets of URLs that (as Paul noted) are used as a "poor > man's URN," and may see more variations in the future. An actual URN > namespace with identifiers defined for each of the standard alerting > patterns would be preferable, to simplify interoperability. > > Are we at a point where we can propose such a URN namespace? Pick a > namespace ID (perhaps "alert" or "std-alert"). The NSS wouldn't have to > be anything more complicated than a name, though it could have two > components, the first indicating the jurisdiction within which the > standard pattern is defined (e.g., a country, or administration) and the > second indicating the specific pattern. Wouldn't want to make it more > complex than necessary, but sufficiently flexible to be used not just in > North America. It seems that there are still multiple opinions about the value in this, but it may be time to propose something. A part of the job as yet untouched is nailing down precisely what one of these URNs names. If it is always a sound, then it might be better to establish a URN specifically for sounds, songs, music clips, and the like. (urn:sounds:Beethovens-fifth-intro, urn:sounds:who-let-the-dogs-out, urn:sounds:bellcore-dr1) Alternatively these URNs might just denote a logical alerting concept that could be rendered in various ways - sound, visual, tactile, some combination of these, etc. (urn:alerts:called-party-alerting, urn:alerts:normal-call, urn:alerts:alt-line-call, urn:alerts:known-caller, urn:alerts:unknown-caller) There could be different URN types for each kind, or the different kinds could be accommodated in a single URN based on what registration info is provided for a name. Paul > On Nov 16, 2006, at 1:47 PM, Paul Kyzivat wrote: > >> I mostly agree with Jonathan. One slight difference inline. >> >> Paul >> >> Jonathan Rosenberg wrote: >>> inline. >>> Paul Kyzivat wrote: >>>> Brian, >>>> >>>> The case you specify is almost the same case I am talking about, but >>>> make more specific. >>>> >>>> I didn't say anything about what values the specific URIs should be. >>>> I think there are three interesting categories: >>>> 1) a URL of a remote resource that the UAS may actually retrieve >>>> and render >>>> >>>> 2) a URL of a resource local to the UAS. >>>> >>>> 3) a URN, that simply specifies a name of a particular alerting style. >>>> The UAS must know what to do for one of these to use it, or have its >>>> own way of discovering that given the URN. >>>> >>>> I have seen (2) used, but usually as an alternative for (3) in that >>>> it isn't really expected that the UAS will necessarily have >>>> something stored in exactly this way. I find (2) to be unreasonable >>>> in most deployments, and (3) to be a much more reasonable approach, >>>> that has equivalent functionality. >>>> >>>> This is all orthogonal to how trustworthiness of Alert-Info headers >>>> is managed. I find it difficult to imagine any cases when the UAS >>>> would want to honor a value sent by the UAC. >>> Well, here is where URN helps. Since the UA that has to render the >>> URN has to know what it means, you can authorize it or not based on >>> that understanding. >>> As others have pointed out, the URN is not going to help cases where >>> people want Britney Spears songs as ringback, but it can help with >>> country-specific ringbacks, where we could easily create a registry. >>> I've become convinced that custom ringtones are best done the way >>> they are done today. The ringtone is stored on the called party >>> device, and logic on the phone itself selects which one to use based >>> on the identity of the caller. >> >> I think the above is a perfectly reasonable mechanism, well suited to >> reasonably smart devices with UIs and capabilities for the necessary >> configuration, and when it makes sense to manage each device >> independently. >> >> I also see value in a case where some of this logic is offloaded from >> the device to a server acting on its behalf. The server makes a >> decision about which alert as appropriate for each call, while the >> device does the rendering of that alert. This is potentially useful >> for devices that are limited in their capabilities in general and >> their UI in particular. It also could be helpful when there are >> multiple devices and the same alert selection logic is desired for >> them all. >> >>> Having the caller select content that gets rendered at the called >>> party, without asking the called party for authorization (which is >>> the case for ringtones), is a recipe for absolute disaster. I'm not >>> worried about tasteless music - I'm worried about some malicious user >>> that decides to record some highly offensive content and then start >>> calling random numbers to cause the content to get played out >>> automatically. Big mistake. >> >> Yes, I agree. At most, I can see a UA (or a proxy acting on behalf of >> the UA) accepting a small selection of Alert-Info values that it >> considers benign. Other values should be ignored. >> >> If a UA knows it has a proxy acting on its behalf in screen >> Alert-Info, and perhaps inserting values based on policy carried out >> by the proxy, then the UA may be willing to trust any value it >> receives via that proxy, and render any Alert-Info value it is capable >> of rendering. >> >> Paul >> >>> -Jonathan R. >> >> _______________________________________________ >> 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 >> > > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 20:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksAH-0008Gs-C1; Thu, 16 Nov 2006 20:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksAF-0008Gk-Ha for sipping@ietf.org; Thu, 16 Nov 2006 20:05:07 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GksAE-000275-3s for sipping@ietf.org; Thu, 16 Nov 2006 20:05:07 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAH13xn02903; Thu, 16 Nov 2006 20:03:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Thu, 16 Nov 2006 19:03:44 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111820913@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FB9009F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccJx6TQvC1F5/7fS+SFJ1f5lVCYwgAAtcrAAAVQ36A= From: "Brian Stucker" To: "Samir Srivastava" , "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Inline comments below.=20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Thursday, November 16, 2006 4:47 PM > To: Benjamin Carlyle; sipping@ietf.org > Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes >=20 > Do we want to cater the different verticals now ? More in-line. >=20 > Thx > Samir Huh? This is a request to evaluate part of SIP framework to see if it is fit for handling a large scale, highly distributed event driven environment. It had better handle it or SIP is in major trouble trying to handle presence.=20 Ben, you may wish to take a look at some of the scaling work out of the SIMPLE WG around presence. Although the service involved is different, I think you will find some useful information and mechanisms for your problem. >=20 > > -----Original Message----- > > From: Benjamin Carlyle [mailto:benjamincarlyle@optusnet.com.au] > > Sent: Thursday, November 16, 2006 1:34 PM > > To: sipping@ietf.org > > Subject: [Sipping] SIP Subscription for SCADA/Stock quotes > >=20 [snip] > >=20 > > rfc3265 indicates that it is not a general purpose subscription=20 > > mechanism. Specific weaknesses I see include > > * There is no obvious way to subscribe to a HTTP resource. > Subscriptions > > are sent to the combination of a SIP url and event package=20 > identifier. >=20 > We can transport different URL schemes over SIP network e.g.=20 > Tel, URN etc, It will require enhancements to current PUBLISH etc. The point of that statement in 3265 and elsewhere is not to limit the URL schemes that can be used, but to point out that there are many ways of pushing data around a network. The intent of the framework wasn't to solve world-event-subscription-hunger. There was a lot of discussion at the time around using (PUBLISH in particular) for all sorts of things and we wanted to constrain the problem space so we could finish off the RFC sometime in our lifetime. [snip] >=20 > > * Subscriptions are refreshed individually at a=20 > client-specified rate. > > In a SCADA environment we are likely to have thousands of > subscriptions > > active between a client and server. The client-specified=20 > rate may be=20 > > used as a keep-alive so that the client can detect server death and=20 > > recreate its subscriptions on another cluster member. I=20 > believe it is=20 > > better for the client to send exactly no renewals. Keep-alive should > be > > sent from the server only, and at a long reliable rate when no data > has > > been transmitted over the subscription during the=20 > keep-alive interval. >=20 > Server has a mechanism with Min-Expire header with 423=20 > response to enforce the refresh interval, it is comfortable=20 > with. You can use OPTIONS from server to do that with a long=20 > subscription duration. =20 Samir-- Min-Expires is only used to ask the client to extend the expire timer from what it requested. It does not enforce the refresh interval alone. There's quite a bit involved in managing the problem of highly-distributed, soft-state, state machines. Probably the best example of this space is the complexity of TCP congestion algorithms.=20 OPTIONS isn't intended to be used as a generic pinging mechanism and has no semantics for keepalive. It is sent to inquire as to the capabilities of an endpoint, and when the linger timer for the transaction pops after sending a response, there is no semantic for keeping track of who/what/when/why an OPTIONS was sent. All an OPTIONS response will typically tell you is that the endpoint's SIP stack is alive. It could be brain-dead above that, and there's no way to know that an OPTIONS failure (for instance a 408 time-out response) is due to a transient network error. Even if you do get a response, it doesn't mean that the subscription is still active on the device. Ben-- RFC-3265 does not have a server-initiated refresh mechanism because the server handling the subscriptions should be spending it's time handling incoming subscription requests, generating notifications, and processing the events that trigger notification. A typical 3265 server implementation will not, for instance, have a timer running for the duration of a subscription. It may simply timestamp the subscription when it is created and then passively garbage collect it later after it expires. Having the much larger set of clients keep track of their timers rather than centralizing the problem is viewed as a better scaling solution because it fans out the work to the largest source of capacity (ie. the clients). IMHO- The best way to solve the dead server problem is to have neither end generating keep-alive traffic (which, in an ideal environment in which no node fails, is always useless). Solve the problem at the server by utilizing a high-availability scheme there so that a server failure does not interrupt service. >=20 > >=20 > > Before I started my quest for an appropriate protocol, I wrote up a=20 > > strawman which may be viewed here: > > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt > >=20 > > If I am unable to resolve the issues I have with existing=20 > standards I=20 > > intend to refine and propose the straw-man as a potential=20 > > standards-track rfc. I hope to find that an appropriate=20 > subscription=20 > > mechanism already exists. I see defining a new one as=20 > something of a=20 > > last resort. > >=20 > > Security is still a weakness of my protocol when NOTIFY and > PATCHNOTIFY > > are used. HTTP may only support the EXPIRE notification=20 > model without=20 > > additional trust mechanisms becoming better understood and deployed. >=20 > We are heavily involved in ironing out security issues. >=20 Ben-- I've done some work in the past with SCADA, and typically the payload in the event notifications does not require encryption. What you need to typically prevent is someone trying to corrupt your central database with garbage data (indicating faults where there are none, or masking faults where they do exist). This can be handled by request authentication. I believe there are a number of ways to solve this problem depending on the level of assurance that you require for your particular application. You could use HTTP Digest authentication to deal with this, or something heavier such as TLS. Without understanding the security requirements needed, it's going to be hard to evaluate. However, there are a number of models out there already that you can look at to see if there's a fit for your particular purpose. Regards, Brian _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 21:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktQK-000471-IE; Thu, 16 Nov 2006 21:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktQJ-00046w-09 for sipping@ietf.org; Thu, 16 Nov 2006 21:25:47 -0500 Received: from panorama.covad.com ([66.134.72.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktQH-0004ai-JE for sipping@ietf.org; Thu, 16 Nov 2006 21:25:46 -0500 Received: from zanxmb00a.cc-ntd1.covad.com (zanxmb00a.corp.covad.com [172.16.2.75]) by panorama.Covad.COM (8.9.3/8.8.7) with ESMTP id SAA27503; Thu, 16 Nov 2006 18:24:25 -0800 (PST) Received: from ZANEVS03.cc-ntd1.covad.com ([172.16.2.84]) by zanxmb00a.cc-ntd1.covad.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:24:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Comments on draft-malas-performance-metrics-05.txt Date: Thu, 16 Nov 2006 18:24:24 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-malas-performance-metrics-05.txt Thread-Index: AccJqgFUmaVhL2mgQ/OJa7oKbt1fGgAQcGdg From: "Fardid, Reza" To: "Daryl Malas" X-OriginalArrivalTime: 17 Nov 2006 02:24:24.0705 (UTC) FILETIME=[7FAA4F10:01C709EF] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.6.1039-14818.000 X-TM-AS-Result: No--26.080800-0.000000-31 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments are inline. Thanks, -Reza -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Thursday, November 16, 2006 10:11 AM To: Fardid, Reza Cc: sipping@ietf.org Subject: Re: [Sipping] Comments on draft-malas-performance-metrics-05.txt On Sat, 2006-11-11 at 15:25 -0800, Fardid, Reza wrote: > =20 >=20 > Daryl, >=20 > =20 >=20 > Here are a few comments on this draft, based on a first pass through > it: >=20 > =20 >=20 > 1. Introduction >=20 > =20 >=20 > I would add User Behavior as another factor that can affect > measurements of some of the metrics. >=20 I'll have to think about this further. Can you please give an example of how user behavior can effect signaling and therefore impact a metric? Thanks... > =20 >=20 >> ASR (=3D=3DSER) measurement is affected by UA2 busy or unavailable signals, >> User Behavior in this context means not caused by the network, excluding >> overload conditions, which are covered with the ISA metric. > > 3. SIP Performance Metrics >=20 > =20 >=20 > If User Behavior MAY affect measurements of a metric, then it MUST be > noted for each defined metric. >=20 See above. > =20 >=20 > 3.5 Session Establishment Ratio (SER) >=20 > =20 >=20 > I suggest referencing ITU-T E.411 for the telephony definition of ASR, > unless GR-512-CORE includes it. I will review and reference as necessary. Thanks... >=20 > 3.11 (or 3.5.1) Session Establishment Efficiency Ratio (SEER): > proposed as a new metric, unless it can be derived from currently > defined metrics >=20 > =20 >=20 > This metric is used to provide a better representation of network > performance by eliminating user behavior from Session Established > Ratio (SER). It is known as Network Efficiency Ratio (NER) in > telephony applications, and was adopted from the ITU-T E.411 > Amendment. >=20 > =20 >=20 > The following response codes provide a guideline for this metric: >=20 > =20 >=20 > - 480 Temporarily Unavailable >=20 > - 486 Busy Here >=20 > - 600 Busy Everywhere >=20 > =20 >=20 > SEER % =3D (# of INVITEs w/ associated 200OK + # of 480s + # of 486s = + > # of 600s)/(Total # of INVITEs) >=20 There are a number of metrics people have suggested. All of them are valid and good metrics. I will ask the working group to review them, and comment. I don't mind adding them if the mailing list finds significant value in them. Thanks... > =20 >=20 >> Sounds good. I think NER (=3D=3DSEER) is more useful for both the=20 >> customer (SLA) and service provider (performance) tracking purposes=20 >> than ASR, which is contaminated. > > Regards, >=20 > Reza Fardid >=20 > =20 >=20 >=20 > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 21:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktbn-00025W-TP; Thu, 16 Nov 2006 21:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktbm-00025R-KV for sipping@ietf.org; Thu, 16 Nov 2006 21:37:38 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gktbl-000649-D5 for sipping@ietf.org; Thu, 16 Nov 2006 21:37:38 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20061117023736m13004q841e>; Fri, 17 Nov 2006 02:37:36 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAH2bZjh014624 for ; Thu, 16 Nov 2006 21:37:35 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAH2bZv1014620; Thu, 16 Nov 2006 21:37:35 -0500 Date: Thu, 16 Nov 2006 21:37:35 -0500 Message-Id: <200611170237.kAH2bZv1014620@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: (robbins.dave@verizon.net) Subject: Re: Utility of Alert-Info (was: Re: [Sipping] draft-stucker-sipping-early-media-coping) References: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA91@zrc2hxm2.corp.nortel.com> <454F837E.1010504@cisco.com> <455A80A6.5020902@cisco.com> <455CB253.9060604@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: David Robbins Are we at a point where we can propose such a URN namespace? Pick a namespace ID (perhaps "alert" or "std-alert"). "sip" Dale _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 16 22:11:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gku6q-00089p-Aa; Thu, 16 Nov 2006 22:09:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gku6o-00089a-Az for sipping@ietf.org; Thu, 16 Nov 2006 22:09:42 -0500 Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gku6m-0001ky-SS for sipping@ietf.org; Thu, 16 Nov 2006 22:09:42 -0500 Received: from [192.168.1.3] ([151.203.33.203]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J8U00ISSU3LK5Q2@vms042.mailsrvcs.net> for sipping@ietf.org; Thu, 16 Nov 2006 21:09:22 -0600 (CST) Date: Thu, 16 Nov 2006 22:09:04 -0500 From: David Robbins Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 In-reply-to: <00AB308C-51C4-4B65-8EB4-3C0A44C0B7BA@cs.columbia.edu> To: sipping Message-id: MIME-version: 1.0 (Apple Message framework v624) X-Mailer: Apple Mail (2.624) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: <20061106081908.95BA11CC5D@delta.rtfm.com> <00AB308C-51C4-4B65-8EB4-3C0A44C0B7BA@cs.columbia.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This framework has been around for a while, and I'm curious as to how much acceptance it is receiving in the industry. Can anybody on this list comment on the extent to which SIP device vendors have adopted it or are planning on adopting it? Some of you may be aware that in the subset of the industry that pays attention to the DSL Forum, TR-104 in conjunction with TR-69 is getting some traction for SIP device management, including configuration. Is the IETF SIP configuration framework getting comparable traction? My company has adopted the IETF framework, for one project, roughly as it was defined in mid-2005 (but without the merging behavior, whose issues many of you have noted). Will we see wider adoption of this framework? Is there a broad constituency for this framework, whether simplified or complexified? On Nov 6, 2006, at 9:57 AM, Henning Schulzrinne wrote: > I think this is a good example of a draft that gets less useful by > having been around for many, many years. As years and IETF meetings > accumulate, more and more stuff gets added, without any real > indication that there is a constituency for them. Nobody seems to be > paying much attention to the draft, so there's little pushback on > feature creep. > > Just as for consent and in SIMPLE, I think it's time to step back and > see if we can't get 90% of the benefit with 10% of the effort, and > maybe scoping the problem so that other features can be added later, > if there is demonstrated demand for them. Unfortunately, this draft > has become a posterchild on why people consider SIP to be far too > complex. > > I had said this before, but I'll repeat that I still find the merging > stuff far too messy and unpredictable to be useful. (It is difficult > for any of the parties to know what exactly happened in the end, > making debugging and troubleshooting difficult.) A simple alternative > is to designate parameters for each role and only allow certain > entities to set them. > > The old saying went that a draft isn't finished until there's nothing > left to take out. I don't think we've even tried to have this > discussion. > > Henning > > On Nov 6, 2006, at 12:19 AM, EKR wrote: > >> $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25 >> 18:52:13 ekr Exp $ >> >> I'm fairly naive about SIP UAs and configuration, but this document >> strikes me as an extremely complex approach to what's really a fairly >> simple problem. As I understand the problem space from reading the >> draft, there are four main use cases: >> >> (1) Plug a naive (out of the box) SIP UA into a network and have >> it "just work" like a POTS UA does with no additional >> configuration >> provided. >> (2) Have a user be able to provide some identifying information >> about a SIP UA (E.g., the MAC address) to some management >> console and then have the UA be able to configure itself. >> Arguably this is a subcase of (1). >> (3) Have a user be able to register with some SIP service provider >> via some undefined out-of-band mechanism and have that service >> provider give them a URL and some authentication credentials >> which they can feed to their UA and their UA can use to get >> configured. >> (4) Have a user be able to take a preconfigured SIP UA to a new >> network environment and get the new network access information >> (e.g., a hotel proxy) while retaining the original configuration >> information (the AOR, keying material, etc.) >> >> Arguably, something based on this document could do this job--though >> note that this document alone cannot because it doesn't actually >> specify any of the relevant parameters--but it's not clear that >> all near the complexity in this protocol is required. In >> particular: >> >> - I don't see why it's necessary to have three tiers of configuration >> data (local network, device, and user) which must somehow be merged. >> In the first three cases, ISTM that you really only have one tier >> and in the fourth there is only some very limited set of >> well-defined >> information, namely the local proxy. It's not like you want a >> hotel proxy to even be able to specify what you should be using >> as your SIP AOR! >> >> - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA >> can get its profile either via SIP or via an external reference >> in a NOTIFY. Let's keep life simple. >> >> - The mechanisms for discovering the URI seem extremely complicated. >> Currently, there are different mechanisms for each of the three >> URI types. If we collapse this down to a single type then is >> there some reason we can't use the SIP DHCP option? >> >> -Ekr >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 17 02:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkyV8-0001WB-Mi; Fri, 17 Nov 2006 02:51:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkyV7-0001Vm-8g for sipping@ietf.org; Fri, 17 Nov 2006 02:51:05 -0500 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkyV5-0000pk-GD for sipping@ietf.org; Fri, 17 Nov 2006 02:51:05 -0500 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id kAH7orPg002451; Fri, 17 Nov 2006 08:50:53 +0100 In-Reply-To: <9F1D84BDF02A2B41B030921EB09086188542CE@ILEXC1U01.ndc.lucent.com> Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery To: "Widjaja, Indra \(Indra\)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Fri, 17 Nov 2006 08:50:47 +0100 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/17/2006 08:50:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: Cullen Jennings , "Dolly, Martin C, ALABS" , sipping , Volker Hilt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I could be such a function, but it must not be IMHO. I'm not sure whether you can pose a requirement itself on specific functions or algorithms. [The network model in clause 6.1 reminds me a little bit to overload control mechanisms designed for intelligent networks. The "home proxy" relates to the IN SCP, the "edge proxy" to the SSPs, etc. The problem is very similar in many aspects. But I can't remember a requirement itself for the convergence/adapation/stability/... functional behaviour (arround TCAP, INAP, served user instances of INAP; or SSP/SCP internal behaviour).] - Albrecht "Widjaja, Indra \(Indra\)" To: "Dolly, Martin C, ALABS" , Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, l-labs.com> cc: Cullen Jennings , sipping Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery 16.11.2006 17:31 My understanding is that #22 in "drops from above the overall capacity of the network to below the overall capacity" can take a step function. Requirement #22 also implies that the system is asymptotically stable. One question is whether a stronger or more specific requirement in #22 is needed such as by how much oscillation (if it occurs) should decay after a certain period, or what is the speed of convergence. Maybe, this is too much? Indra -----Original Message----- From: Dolly, Martin C, ALABS [mailto:mdolly@att.com] Sent: Thursday, November 16, 2006 6:42 AM To: Albrecht.Schwarz@alcatel.de; Volker Hilt Cc: Cullen Jennings; sipping Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Is requirement #22 a step function, or does it support a gradual recovery? -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Thursday, November 16, 2006 2:50 AM To: Volker Hilt Cc: Cullen Jennings; sipping Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Agree to make an explicit requirement, but the current proposal is now containing two requirements in my understanding. One related to the stability criteria, and one related to performance (-> throughput) under overload. The 2nd one is so far only considering throughput ("maximize throughput, = equal to offered load"), but not the requirement of bounding response times of (SIP) messages. A successfully processed SIP message and the correspondent response time are tightly coupled. A successfully processed message, but with too much delay, is typically meaningless. (The maximum response time is typically given by SIP protocol timers, or timers of the SIP served application, or behaviour of human beings behind a UA, or ...) Like to split them therefore into two: The overload mechanism should ensure that the system remains stable independent of the offered load (i.e., in the entire load range). When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load (under steady-state conditions). Response times (or system times; given by service time and all waiting times within the SIP entity) should be below a maximum value under all load conditions. - Albrecht Volker Hilt bs.com> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings , sipping 15.11.2006 23:34 Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> > Jennings >> >> bs.com> cc: sipping >> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 17 10:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5Sp-00051m-Op; Fri, 17 Nov 2006 10:17:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5So-00051d-GA for sipping@ietf.org; Fri, 17 Nov 2006 10:17:10 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5Si-0000xG-Vw for sipping@ietf.org; Fri, 17 Nov 2006 10:17:10 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAHFH3xL002071; Fri, 17 Nov 2006 08:17:04 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Date: Fri, 17 Nov 2006 08:17:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Thread-Index: AccJ9o4+qtyYP90VS4uyxYqh1KeirAAY85uA From: "Sumanth Channabasappa" To: "David Robbins" , "sipping" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org David, As per the ad-hoc discussions that happened at the last IETF, we have quite a few organizations interested in this approach. Speaking personally, the CableLabs PacketCable PACM framework utilizes this. The public specifications are available at: http://www.packetcable.com=20 , for your reference. This effort was the collective result of various organizations. The efforts in PACM looked at various approaches and found that a SIP based configuration framework in conjunction with XCAP made the most sense (details in the specifications or I can take it offline). As indicated by a few others, it would be nice to complete this effort in the best possible manner (sooner than later). Thanks! - S -----Original Message----- From: David Robbins [mailto:robbins.dave@verizon.net]=20 Sent: Thursday, November 16, 2006 8:09 PM To: sipping Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 This framework has been around for a while, and I'm curious as to how much acceptance it is receiving in the industry. Can anybody on this list comment on the extent to which SIP device vendors have adopted it or are planning on adopting it? Some of you may be aware that in the subset of the industry that pays attention to the DSL Forum, TR-104 in conjunction with TR-69 is getting some traction for SIP device management, including configuration. Is the IETF SIP configuration framework getting comparable traction? My company has adopted the IETF framework, for one project, roughly as it was defined in mid-2005 (but without the merging behavior, whose issues many of you have noted). Will we see wider adoption of this framework? Is there a broad constituency for this framework, whether simplified or complexified? On Nov 6, 2006, at 9:57 AM, Henning Schulzrinne wrote: > I think this is a good example of a draft that gets less useful by=20 > having been around for many, many years. As years and IETF meetings=20 > accumulate, more and more stuff gets added, without any real=20 > indication that there is a constituency for them. Nobody seems to be=20 > paying much attention to the draft, so there's little pushback on=20 > feature creep. > > Just as for consent and in SIMPLE, I think it's time to step back and=20 > see if we can't get 90% of the benefit with 10% of the effort, and=20 > maybe scoping the problem so that other features can be added later,=20 > if there is demonstrated demand for them. Unfortunately, this draft=20 > has become a posterchild on why people consider SIP to be far too=20 > complex. > > I had said this before, but I'll repeat that I still find the merging=20 > stuff far too messy and unpredictable to be useful. (It is difficult=20 > for any of the parties to know what exactly happened in the end,=20 > making debugging and troubleshooting difficult.) A simple alternative=20 > is to designate parameters for each role and only allow certain=20 > entities to set them. > > The old saying went that a draft isn't finished until there's nothing=20 > left to take out. I don't think we've even tried to have this=20 > discussion. > > Henning > > On Nov 6, 2006, at 12:19 AM, EKR wrote: > >> $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25 >> 18:52:13 ekr Exp $ >> >> I'm fairly naive about SIP UAs and configuration, but this document=20 >> strikes me as an extremely complex approach to what's really a fairly >> simple problem. As I understand the problem space from reading the=20 >> draft, there are four main use cases: >> >> (1) Plug a naive (out of the box) SIP UA into a network and have >> it "just work" like a POTS UA does with no additional=20 >> configuration >> provided. >> (2) Have a user be able to provide some identifying information >> about a SIP UA (E.g., the MAC address) to some management >> console and then have the UA be able to configure itself. >> Arguably this is a subcase of (1). >> (3) Have a user be able to register with some SIP service provider >> via some undefined out-of-band mechanism and have that service >> provider give them a URL and some authentication credentials >> which they can feed to their UA and their UA can use to get >> configured. >> (4) Have a user be able to take a preconfigured SIP UA to a new >> network environment and get the new network access information >> (e.g., a hotel proxy) while retaining the original configuration >> information (the AOR, keying material, etc.) >> >> Arguably, something based on this document could do this job--though=20 >> note that this document alone cannot because it doesn't actually=20 >> specify any of the relevant parameters--but it's not clear that all=20 >> near the complexity in this protocol is required. In >> particular: >> >> - I don't see why it's necessary to have three tiers of configuration >> data (local network, device, and user) which must somehow be merged. >> In the first three cases, ISTM that you really only have one tier >> and in the fourth there is only some very limited set of=20 >> well-defined >> information, namely the local proxy. It's not like you want a >> hotel proxy to even be able to specify what you should be using >> as your SIP AOR! >> >> - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA >> can get its profile either via SIP or via an external reference >> in a NOTIFY. Let's keep life simple. >> >> - The mechanisms for discovering the URI seem extremely complicated. >> Currently, there are different mechanisms for each of the three >> URI types. If we collapse this down to a single type then is >> there some reason we can't use the SIP DHCP option? >> >> -Ekr >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 17 10:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl65C-0001gP-UK; Fri, 17 Nov 2006 10:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl65B-0001fX-JQ for sipping@ietf.org; Fri, 17 Nov 2006 10:56:49 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl64c-0005cW-Rm for sipping@ietf.org; Fri, 17 Nov 2006 10:56:49 -0500 Received: from [10.10.16.240] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAHF0045005703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 09:00:01 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Date: Fri, 17 Nov 2006 09:56:07 -0600 To: Sumanth Channabasappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: David Robbins , sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 17, 2006, at 9:17 AM, Sumanth Channabasappa wrote: > David, > > As per the ad-hoc discussions that happened at the last IETF, we have > quite a few organizations interested in this approach. > > Speaking personally, the CableLabs PacketCable PACM framework utilizes > this. The public specifications are available at: > http://www.packetcable.com > , for your reference. This effort was the collective result of various > organizations. > > The efforts in PACM looked at various approaches and found that a SIP > based configuration framework in conjunction with XCAP made the most > sense (details in the specifications or I can take it offline). > > As indicated by a few others, it would be nice to complete this effort > in the best possible manner (sooner than later). > For those not familiar with it the PacketCable specifications provide the basis for the delivery of conventional-looking telephone services over cable television networks. This approach has broad deployment in North America and is picking up (although occasionally with minor specification variance) in other geographies. Current deployments are in the millions, and some industry forecasts predict tens of millions over the next few years. Residential phone adapters for PacketCable are made in quantity by large consumer electronics providers including Motorola, Linksys (and Siemens, I think) as well as a number of possibly less-well-known providers. So yeah, the config framework has an adequate constituency. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 17 15:16:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA65-0005WZ-LS; Fri, 17 Nov 2006 15:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlA63-0005WE-8M for sipping@ietf.org; Fri, 17 Nov 2006 15:13:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlA5x-0004ju-M1 for sipping@ietf.org; Fri, 17 Nov 2006 15:13:59 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2006 12:13:52 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAHKDqXJ009501; Fri, 17 Nov 2006 15:13:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAHKDqDM004657; Fri, 17 Nov 2006 15:13:52 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:13:52 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:13:51 -0500 Message-ID: <455E17FF.9030204@cisco.com> Date: Fri, 17 Nov 2006 15:13:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sipping] A Test Balloon For AS generated Early Media: EMIND References: <6FC4416DDE56C44DA0AEE67BC7CA437111820290@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111820290@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 20:13:51.0667 (UTC) FILETIME=[E627B030:01C70A84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4045; t=1163794432; x=1164658432; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20A=20Test=20Balloon=20For=20AS=20generated =20Early=20Media=3A=20EMIND |Sender:=20 |To:=20Brian=20Stucker=20; bh=HRglL+NPJ2xnIVqb1xTMmGc3+wcwdEsr3Z+539BzmE8=; b=D6+zYD6NJLp7d4dHnY9HM0LQYqa6xWmx9N70f8w4v4wF32l2DyTcQCq7PjL+dXCZTfs2ezCf THCaTcAgx0ZslQUCpfGCXmXxDtCmNgOBLxLt79qCwLEcKeQTmQtdvFkb; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brian, Is there a reason you propose something new like this in preference to the Application Server model of early media specified in RFC 3960? While apparently not implemented, it does have the advantage of having a spec that is already done. Both it and what you propose present some implementation/deployment challenges. Yours is probably somewhat simpler to implement, but is that enough to be worth the trouble? If so, should we also deprecate the application server model? Paul Brian Stucker wrote: > All, > > I think I have a way to fix application server generated early media, > which I believe makes up a great deal of the solvable early media > interactions we have today. This is early media triggered by some > service in the SIP network that is supplied by a network controlled > media server to the originating client. I'm looking for comments/poking > of holes/support. > > To my mind, there are three major problems to be solved with application > server generated early media: getting the middle out of the way of the > end-to-end SDP negotiations, ensuring the middle has a chance at having > the client render the intended media, and getting the ordering correct. > > Here's the proposal to address these areas: > > - The UAC generates an INVITE as it always has, except that it includes > a supported tag denoting support for the early media model in this > proposal (let's use the option tag "emind" - early media indicator for > the sake of argument). > - If an application server/proxy wants to trigger some sort of network > generated early media back to the UAC, and it sees the "emind" supported > option tag, it does so by generating a 183 message back to the UAC with > an Alert-Info header that contains a SIP URI of the media resource it > wishes the UAC to connect to. > - Upon receiving the 183 message back with the Alert-Info header > containing the SIP URI to connect to, the UAC generates another INVITE > to the SIP URI from the 180 Alert-Info header. It may reuse the IP/ports > from the original SDP offerin the first INVITE request for this early > media offer if it so wishes (might be some issues with ICE processing > here), however, it should set a different dynamic RTP payload type on in > the SDP for this early media offer (more on this later). > - The UAC now may negotiate SDP between the two endpoints entirely > separately. It should know the exact state of each dialog and only > end-to-end SDP exchanges should be occurring on the original INVITE > dialog. The network media server would be contacted by the UAC for the > early media the application server wanted presented and able to answer > the early media INVITE to begin early media playback on that dialog. > - In the meantime, the UAC now knows which packets are transitional or > final media, and which ones are eary media because the RTP payload types > are different. When the UAC sees final media coming from the first, > end-to-end INVITE it can either wait for the 200 OK to comeon that > dialog or switch over immediately to that media stream and BYE the early > media INVITE. > > It is expected that the UAC's local outbound proxy will strip any > Alert-Info headers from untrusted sources prior to sending them to the > UAC today. Also, there would need to be a change to the Alert-Info > syntax to allow a SIP URI. The forking issue should abate on the client > as it can ignore any forking on the end-to-end INVITE as far as knowing > whether or not it should revert to local ringback or not, and a q-value > could be used to get the ordering right for early-media dialogs. > > Thoughts? > > Regards, > Brian > > > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 17 16:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlArf-0005NS-Dn; Fri, 17 Nov 2006 16:03:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlArd-0005NM-Qa for sipping@ietf.org; Fri, 17 Nov 2006 16:03:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlArb-0004EI-6T for sipping@ietf.org; Fri, 17 Nov 2006 16:03:09 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 13:03:05 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAHL34qE019144; Fri, 17 Nov 2006 16:03:04 -0500 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 kAHL33YJ025618; Fri, 17 Nov 2006 16:03:03 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 16:03:03 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 16:03:02 -0500 Message-ID: <455E2386.4080900@cisco.com> Date: Fri, 17 Nov 2006 16:03:02 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sipping] SDP Rollback indraft-sawada-sipping-sip-offeranswer-01.txt References: <8983EC086A9D954BA74D9763E853CF3E0258EDF7@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E0258EDF7@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 21:03:03.0011 (UTC) FILETIME=[C54B0B30:01C70A8B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7276; t=1163797384; x=1164661384; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20SDP=20Rollback=20indraft-sawada-sipping-s ip-offeranswer-01.txt |Sender:=20 |To:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20; bh=Z1/h+UbW7bAiUFzYw23M14nda06yICXjFPdE2NxOilA=; b=VpGmWqHMt9zHk4Jxlj3k/6v4cTF7/6ScvYkknoXuTLVTRrwJEXUTphTjnaT19sPkMmj7eevP ZPdCqyxDnmdlwyjV3dGN5q8REAZOFjaa9Nz1cDxo8c2QnHJ/S1FmRu+5; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: tu-sawada@kddi.com, sipping@ietf.org, Siddhartha Bhakta X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org (To those who haven't been paying attention, this is about what to do about SDP when a reINVITE fails. RFC 3261, section 14.1, says that if a non-2xx final response is received the session parameters must remain unchanged, as if no reINVITE had been issued. Herein that is being described as "rollback" of the SDP.) There are several interesting questions relative to this topic: - are the existing RFCs clear about what should be done? (Do all informed and reasonable people agree what this is?) - what do currently deployed implementations do? - what is the *most reasonable* thing to do? There has been quite a bit of discussion in the past on this, though we could probably some more because I think only a few people participated. IMO the existing RFCs are *not* clear, because we are getting multiple interpretations that can be justified to some extent. The rollback rule only appears in 3261, and doesn't really address the additional issues raised by 3262, 3311, and 3312. There are also good arguments for either of two approaches being the most reasonable thing to do. The two competing interpretations are: 1) once an answer has been transmitted reliably it is committed and will not be rolled back, even if a reinvite fails. 2) an entire sequence of offers and answers (there could be many) that is initiated by a reinvite, is rolled back if the reinvite fails. Of these, (1) is somewhat easier to implement. It also eliminates some race conditions that seem unresolvable, though obscure, that can arise with (2). The downside is that when multiple offers and answers are used to resolve preconditions, and then the reinvite fails, you end up in an interim state with unresolved preconditions. The proper behavior in that state is not clear. With (2) the precondition problem goes away. A few ambiguous race conditions have been identified, but they are obscure cases that can probably be resolved by just just writing some best practices to avoid them. Its not entirely clear to me if this approach requires retention of any more state than (1), but if so it is only slightly more. It would be helpful if people that have opinions on this subject identify which approach they advocate and why. I'm not expecting to see a new approach different from either of the above, but if somebody has one, please spell out how it differs from these, and why it is better. Thanks, Paul Sanjay Sinha (sanjsinh) wrote: > SDP rollback applies only if previously there has been an offer-answer > exchange and an early dialog or a confirmed dialog has been established. > In that case, if SDP in re-Invite/UPDATE is rejected, then session > continues with previously negotiated characteristics. This is mentioned > in RFC 3261. And this draft does mention that if offer in Prack or in a > sip response is rejected, then answerer has to send an updated offer. So > I am not sure how is the new proposal different than what has been > already stated. > > Sanjay > > ------------------------------------------------------------------------ > *From:* Siddhartha Bhakta > [mailto:Siddhartha.Bhakta@newport-networks.com] > *Sent:* Tuesday, November 14, 2006 12:37 PM > *To:* tu-sawada@kddi.com; Paul Kyzivat (pkyzivat) > *Cc:* sipping@ietf.org > *Subject:* [Sipping] SDP Rollback > indraft-sawada-sipping-sip-offeranswer-01.txt > > Hi, > > > > I am not sure (as I am a very new user to SIPPING > > group) whether SDP rollback has ever been discussed > > regarding this draft or not. I personally feel that > > 'SDP rollback' is very relevant topics regarding this > > draft. > > > > The sec 1.2 indicates the response(488) to reject any > > SDP offer. But the missing part is that if any SIP > > request carrying SDP offer is rejected by 3xx-6xx then > > SDP offer should be rolled-back. The rollback means, > > applying last session description. > > > > Rather than specifying different SIP messages > > separately, it would be better to have some thumb rule > > that shall be quite easy to follow as far as SDP > > rollback is concerned. I am proposing following thumb > > rule. Please indicate whether that makes sense or not. > > > > The SDP rollback shall be associated with transaction > > rollback/rejection. > > > > [1] If the transaction request (carrying SDP offer) is > > rejected then SDP offer shall be rolled-back. The > > exception is the ACK request. The ACK (of 2xx) can not > > be rejected. (The ACK of 3xx-6xx is not the > > transaction initiating request). > > > > [2] If any transaction request carries SDP answer > > (e.g., ACK or PRACK) then that transaction can not > > rejected as there shall be the confusion over whether > > SDP shall be rolled-back or not. I suppose, SDP answer > > can not be rolled-back. There is no confusion for ACK, > > as it can not rejected but for PRACK the restriction > > should be there that it can not be rejected if it > > carries SDP answer. > > > > This draft says that PRACK(irrespective of whether it > > is carrying SDP offer/answer) can not be rejected. I > > can not understand the rationale about this statement. > > Though, I can appreciate why PRACK MUST not be > > rejected if it carries SDP answer. > > > > [3] If any SIP response contains SDP offer then that > > SDP can not be rolled-back. If any SIP entity wants to > > rollback the SDP offer carried by SIP response, it > > should initiate a SIP transaction carrying old SDP to > > accomplish it. > > > > There is a special case for re-INVITE. If multiple SDP > > offer/answer happens(using PRACK/UPDATE) within > > re-INVITE transaction and re-INVITE is rejected by > > 4xx-6xx then whether all the SDP offer/answer happens > > within re-INVITE transaction shall be rolled-back or > > not. My suggestion would be that once SDP offer/answer > > is completed, that can not rolled-back by means of > > transaction rejection. That means, all the completed > > SDP offer/answer shall not be rolled-back due to > > 4xx-6xx of re-INVITE. This decision shall save the > > work of SIP UA, SIP SBC, B2BUA etc. that follows SDP > > offer/answer state. > > > > Please comment. > > > > > > Thanks and Regards, > > Siddhartha > > > > > > ------------------------------------------------------------------------ > --------------- > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail > in error) please notify the sender immediately and delete this > e-mail. Any unauthorized copying, disclosure or distribution of the > contents in this e-mail is strictly forbidden. > --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 18 12:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlU7q-0008Qk-BD; Sat, 18 Nov 2006 12:37:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlU7o-0008Qe-M8 for sipping@ietf.org; Sat, 18 Nov 2006 12:37:08 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlU7e-0002oy-L4 for sipping@ietf.org; Sat, 18 Nov 2006 12:37:08 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BB642701; Sat, 18 Nov 2006 18:36:49 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 18:36:49 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 18:36:49 +0100 Received: from [131.160.126.15] (rvi2-126-15.lmf.ericsson.se [131.160.126.15]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EBD68236E; Sat, 18 Nov 2006 19:36:48 +0200 (EET) Message-ID: <455F44B0.1050406@ericsson.com> Date: Sat, 18 Nov 2006 19:36:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2006 17:36:49.0225 (UTC) FILETIME=[205AE390:01C70B38] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Mary Barnes Subject: [Sipping] New editor for the config framework: volunteers needed X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Folks, we intend to appoint a new editor to work on the re-structuring of the config framework draft. The re-structuring will require a considerable commitment from the draft's editor and Dan (the current editor) does not have enough cycles to do it at this point. The new editor should be familiar with the problem the draft deals with and have experience writing specifications. If you would like to volunteer, send an email to the SIPPING chairs. We intend to appoint the new editor as soon as there is agreement on the new structure of the document. http://www1.ietf.org/mail-archive/web/sipping/current/msg12336.html Thanks, Gonzalo SIPPING co-chair _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 18 14:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlVee-0003dW-0j; Sat, 18 Nov 2006 14:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlVed-0003dQ-8e for sipping@ietf.org; Sat, 18 Nov 2006 14:15:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlVeT-00083G-CI for sipping@ietf.org; Sat, 18 Nov 2006 14:15:07 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 930AA16D; Sat, 18 Nov 2006 20:14:54 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 20:14:54 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 20:14:54 +0100 Received: from [131.160.126.15] (rvi2-126-15.lmf.ericsson.se [131.160.126.15]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 056BF236E; Sat, 18 Nov 2006 21:14:54 +0200 (EET) Message-ID: <455F5BAD.1090507@ericsson.com> Date: Sat, 18 Nov 2006 21:14:53 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2006 19:14:54.0416 (UTC) FILETIME=[D433C500:01C70B45] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Robert Sparks , Mary Barnes Subject: [Sipping] Requesting the publication of the dialogusage draft X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Folks, FYI: the following draft incorporates all the WGLC comments. We intend to request its publication shortly. http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.txt Cheers, Gonzalo _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 18 17:27:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYbR-0003sZ-Vk; Sat, 18 Nov 2006 17:24:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlYbR-0003sF-6H for sipping@ietf.org; Sat, 18 Nov 2006 17:24:01 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GlYbK-0001gl-F3 for sipping@ietf.org; Sat, 18 Nov 2006 17:24:01 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1163888632!16776787!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30989 invoked from network); 18 Nov 2006 22:23:53 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 18 Nov 2006 22:23:53 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAIMH3a8004449; Sat, 18 Nov 2006 17:17:04 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kAIMH0Hv004439; Sat, 18 Nov 2006 17:17:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] New editor for the config framework: volunteers needed Date: Sat, 18 Nov 2006 16:23:48 -0600 Message-ID: <28F05913385EAC43AF019413F674A017101B722A@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <455F44B0.1050406@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] New editor for the config framework: volunteers needed Thread-Index: AccLOXrsWtlhdEj+TMS3Lv/ag3iSaAAJqW7w From: "Dolly, Martin C, ALABS" To: "Gonzalo Camarillo" , "sipping" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mary Barnes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hello, Please explain what you mean by "profile life cycle" and what level of documentation do you expect?=20 I do not see profile content indirection as being optional. Martin=20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Saturday, November 18, 2006 12:37 PM To: sipping Cc: Mary Barnes Subject: [Sipping] New editor for the config framework: volunteers needed Folks, we intend to appoint a new editor to work on the re-structuring of the config framework draft. The re-structuring will require a considerable commitment from the draft's editor and Dan (the current editor) does not have enough cycles to do it at this point. The new editor should be familiar with the problem the draft deals with and have experience writing specifications. If you would like to volunteer, send an email to the SIPPING chairs. We intend to appoint the new editor as soon as there is agreement on the new structure of the document. http://www1.ietf.org/mail-archive/web/sipping/current/msg12336.html Thanks, Gonzalo SIPPING co-chair _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 04:36:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5YB-0003zO-5z; Mon, 20 Nov 2006 04:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5Y9-0003zJ-S8 for sipping@ietf.org; Mon, 20 Nov 2006 04:34:49 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm5Y8-0002Qp-Ex for sipping@ietf.org; Mon, 20 Nov 2006 04:34:49 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAK9YeR18511; Mon, 20 Nov 2006 04:34:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Mon, 20 Nov 2006 03:34:38 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FBF2FCF@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111820913@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccJx6TQvC1F5/7fS+SFJ1f5lVCYwgAAtcrAAAVQ36AAo8VAIA== From: "Samir Srivastava" To: "Brian Stucker" , "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, in line. Thx Samir > >> -----Original Message----- >> From: Srivastava, Samir (SC100:8826) >> Sent: Thursday, November 16, 2006 4:47 PM >> To: Benjamin Carlyle; sipping@ietf.org >> Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes >>=20 >> Do we want to cater the different verticals now ? More in-line. >>=20 >> Thx >> Samir > >Huh? This is a request to evaluate part of SIP framework to=20 >see if it is fit for handling a large scale, highly=20 >distributed event driven environment. It had better handle it=20 >or SIP is in major trouble trying to handle presence.=20 If you remember Hennings frustration from the meeting that one bit of information is going with how many bytes. SIP presence framework itself is not that good :-) Though I am not focused on optimizing it currently. In 2000, there was an attempt on the communication of Intelligent Appliances... "SIP Extensions for Communicating with Networked Appliances", H.=20 Schulzrinne, Simon Tsang, Stanley Moyer, Dave Marples, Arjun=20 Roychowdhury, 11/16/2000, A variety of technologies are available to network appliances and=20 provide home automation and control. However, these do not support=20 wide-area access control and interworking of these Networked=20 Appliances (NA). This document describes a new SIP method, DO, that allows a SIP UA to communicate with NAs. " If my recollection of arguments on the list is correct, There were arguments that most of the startups die because of indigestion etc. SIP is not an infant any more. In the startup mode, you focus on the problem at the hand. But you keep architecture open such that it can handle varying needs. It should increase the degree of pervassiveness in the future seamlessly. I think fathers/god father of SIP were not be having such a myopic vision on the utility of SIP for just mimicking PSTN and Presence as you are trying to say. Presence came later and it fit in well.=20 To me, your fear comes from the arguments given by others for weakness of SIP as "SIP Does many things for many people" . I counter it "IP does the same", It depends on how you see and design the versatile / pervassive protocol fulfilling different needs seamlessly with little extensions where processing intelligence of those extensions is just at the required end point. Rest nodes are just conduit. To me, Presence in its current form is just one aspect. SIP in the core is excellent protocol but with some rough edges coming from mimicking PSTN, etc... <> > >The point of that statement in 3265 and elsewhere is not to=20 >limit the URL schemes that can be used, but to point out that=20 >there are many ways of pushing data around a network. The=20 >intent of the framework wasn't to solve=20 >world-event-subscription-hunger. There was a lot of discussion=20 >at the time around using (PUBLISH in particular) for all sorts=20 >of things and we wanted to constrain the problem space so we=20 >could finish off the RFC sometime in our lifetime. I am not asking world-event-hunger to be fullfilled with this like X-Motif/JDK event models etc. I am asking only the presence framework to extend.... <> >OPTIONS isn't intended to be used as a generic pinging=20 >mechanism and has no semantics for keepalive. It is sent to=20 >inquire as to the capabilities of an endpoint, and when the=20 >linger timer for the transaction pops after sending a=20 >response, there is no semantic for keeping track of=20 >who/what/when/why an OPTIONS was sent. All an OPTIONS response=20 >will typically tell you is that the endpoint's SIP stack is=20 >alive. It could be brain-dead above that, and there's no way=20 >to know that an OPTIONS failure (for instance a 408 time-out=20 >response) is due to a transient network error. Even if you do=20 >get a response, it doesn't mean that the subscription is still=20 >active on the device. As per Section 11 of 3261=20 "An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog." OPTIONS does allow the Allow-Event header etc. There may be sometime need for a SIP entity to find the state of subscirbe created dialog on another end, there it will be useful. (Like missing NOTIFY with state change delta) State indication can be event package specific. 200 OK with subscription event state tells the querying endpoint what is happening. If event state is currently not supported, then protocol might need to extend. Other response codes can be viewed differently.. I was coining it as he was asking for server driven. I don't understand completely his problem requirements as of now. > >Ben-- > >RFC-3265 does not have a server-initiated refresh mechanism=20 >because the server handling the subscriptions should be=20 >spending it's time handling incoming subscription requests,=20 >generating notifications, and processing the events that=20 >trigger notification. A typical 3265 server implementation=20 >will not, for instance, have a timer running for the duration=20 >of a subscription. It may simply timestamp the subscription=20 >when it is created and then passively garbage collect it later=20 >after it expires. Having the much larger set of clients keep=20 >track of their timers rather than centralizing the problem is=20 >viewed as a better scaling solution because it fans out the=20 >work to the largest source of capacity (ie. the clients). Your point was earlier well understood even before commenting. See the above. > >IMHO- The best way to solve the dead server problem is to have=20 >neither end generating keep-alive traffic (which, in an ideal=20 >environment in which no node fails, is always useless). Solve=20 >the problem at the server by utilizing a high-availability=20 >scheme there so that a server failure does not interrupt service. > Refer my long time back proposal on the list for the Event based heart beat=20 http://www1.ietf.org/mail-archive/web/sip/current/msg08844.html This was to avoid the periodic OPTIONS messages flow when other server was down to avoid congestion etc.. I was just scratching the congestion at that time... Somewhere at the IP layer when packet is sent, it needs to know which IP server should fill. VRRP just talks about the IP layer connectivity. Can you describe your scheme... =20 >Ben-- > >I've done some work in the past with SCADA, and typically the=20 >payload in the event notifications does not require=20 >encryption. What you need to typically prevent is someone=20 >trying to corrupt your central database with garbage data=20 >(indicating faults where there are none, or masking faults=20 >where they do exist). This can be handled by request=20 >authentication. I believe there are a number of ways to solve=20 >this problem depending on the level of assurance that you=20 >require for your particular application. You could use HTTP=20 >Digest authentication to deal with this, or something heavier=20 >such as TLS. Without understanding the security requirements=20 >needed, it's going to be hard to evaluate. However, there are=20 >a number of models out there already that you can look at to=20 >see if there's a fit for your particular purpose. There were some postings on the HTTP Digest being prone to brute force attacks. BTW, I worked earlier in different event based/driven systems too. When I have more free time, I will start looking into this. _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 06:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7EY-00064j-98; Mon, 20 Nov 2006 06:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7EW-00064W-IL for sipping@ietf.org; Mon, 20 Nov 2006 06:22:40 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm7EO-0008EU-5U for sipping@ietf.org; Mon, 20 Nov 2006 06:22:39 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4D389E78 for ; Mon, 20 Nov 2006 12:22:23 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 12:22:22 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Nov 2006 12:21:54 +0100 Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C030BF23C@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft on grouping of AoRs Thread-Index: AccMlhVb6mVXOS/FSBCWGBGnxn/dSw== From: "Jesus Javier Arauz \(MI/EEM\)" To: X-OriginalArrivalTime: 20 Nov 2006 11:22:22.0057 (UTC) FILETIME=[25B49D90:01C70C96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [Sipping] New draft on grouping of AoRs X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0574170598==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0574170598== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70C96.15ACDDE3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70C96.15ACDDE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some weeks ago I submitted the draft draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts archive. As many of you know, within the IMS application of SIP a user can have his/her AoRs grouped in so-called Implicit Registration Sets (IRS). The goal of this grouping is to allow bootstrapping a SIP UA that knows only one of the AoRs in an IRS, so the UA gets all the AoRs within that IRS simultaneously registered (and deregistered) in an implicit way. Within the context of the latest IMS release (Rel-7) a finer-grained mechanism for grouping AoRs has been introduced. The need to have "aliases", or sets of fully equivalent AoRs, was identified. The IRS mechanism was evaluated as a means to fulfill this need and the conclusion was that the goals of the IRS (i.e. bootstrapping) and the AoR aliasing are orthogonal and thus problems could arise if the same mechanism is used for both purposes. Therefore a new mechanism has been introduced that allows defining groups of alias AoRs that are fully equivalent from a network perspective, i.e. any AoR within one group receives the very same treatment from the network as any other AoR within that group. In order to simplify network handling of these groups the limitation was introduced that any group of alias AoRs must not span more than one IRS, i.e. a group of alias AoRs is always a subset of a containing IRS. There are situations where it is convenient that other network entities different from the registrar are aware of the existence and composition of groups of alias AoRs. The three situations that have been identified so far are: 1) The UA needs to know about the groups of alias AoRs within an IRS in order for it to know that it can use any of those alias in a SIP procedure when there is no indication from the user otherwise. For instance if the UA has a local call barring feature, if the barring is active for a given AoR it must be implicitly active also for any other AoR belonging to the same group of alias AoRs as the former. 2) The first-hop proxy (P-CSCF) needs to know about the groups of alias AoRs within an IRS in order to provide them to the access network's policy decision point (PCRF), which may then apply common policies to all the alias AoRs within a group. This simplifies policy management in the access network, allowing to define group-wide policies instead of policies per AoR. 3) A proxy of B2BUA providing services to the user (AS in IMS terminology) needs to be able to know about the groups of alias AoRs in order to provide the same services with the same service parameters to all the alias AoRs within a group. There is a mechanism in the IMS network to notify any interested party about the composition of a user's IRS, based on the registration event notification mechanism defined in RFC3680. The draft I've submitted extends this mechanism to include the group or groups of alias AoRs that exist within those IRS. The mechanism is mandatorily supported by the IMS UA and first-hop proxy and can also be leveraged by proxy/B2BUA entities so it fulfills the three requirements outlined above. I'd like to know what are the sipping community's views on the draft?. Thanks and regards, /Javier ------_=_NextPart_001_01C70C96.15ACDDE3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New draft on grouping of AoRs

Hi,

Some weeks ago I = submitted the draft draft-jarauz-sipping-grouping-reg-event-00 to the = IETF drafts archive.

As many of you know, = within the IMS application of SIP a user can have his/her AoRs grouped = in so-called Implicit Registration Sets (IRS). The goal of this grouping = is to allow bootstrapping a SIP UA that knows only one of the AoRs in an = IRS, so the UA gets all the AoRs within that IRS simultaneously = registered (and deregistered) in an implicit way.

Within the context of = the latest IMS release (Rel-7) a finer-grained mechanism for grouping = AoRs has been introduced. The need to have "aliases", or sets = of fully equivalent AoRs, was identified. The IRS mechanism was = evaluated as a means to fulfill this need and the conclusion was that = the goals of the IRS (i.e. bootstrapping) and the AoR aliasing are = orthogonal and thus problems could arise if the same mechanism is used = for both purposes. Therefore a new mechanism has been introduced that = allows defining groups of alias AoRs that are fully equivalent from a = network perspective, i.e. any AoR within one group receives the very = same treatment from the network as any other AoR within that group. In = order to simplify network handling of these groups the limitation was = introduced that any group of alias AoRs must not span more than one IRS, = i.e. a group of alias AoRs is always a subset of a containing = IRS.

There are situations = where it is convenient that other network entities different from the = registrar are aware of the existence and composition of groups of alias = AoRs. The three situations that have been identified so far = are:

1) The UA needs to = know about the groups of alias AoRs within an IRS in order for it to = know that it can use any of those alias in a SIP procedure when there is = no indication from the user otherwise. For instance if the UA has a = local call barring feature, if the barring is active for a given AoR it = must be implicitly active also for any other AoR belonging to the same = group of alias AoRs as the former.

2) The first-hop = proxy (P-CSCF) needs to know about the groups of alias AoRs within an = IRS in order to provide them to the access network's policy decision = point (PCRF), which may then apply common policies to all the alias AoRs = within a group. This simplifies policy management in the access network, = allowing to define group-wide policies instead of policies per = AoR.

3) A proxy of B2BUA = providing services to the user (AS in IMS terminology) needs to be able = to know about the groups of alias AoRs in order to provide the same = services with the same service parameters to all the alias AoRs within a = group.

There is a mechanism = in the IMS network to notify any interested party about the composition = of a user's IRS, based on the registration event notification mechanism = defined in RFC3680. The draft I've submitted extends this mechanism to = include the group or groups of alias AoRs that exist within those IRS. = The mechanism is mandatorily supported by the IMS UA and first-hop proxy = and can also be leveraged by proxy/B2BUA entities so it fulfills the = three requirements outlined above.

I'd like to know what = are the sipping community's views on the draft?.

Thanks and = regards,
/Javier


------_=_NextPart_001_01C70C96.15ACDDE3-- --===============0574170598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0574170598==-- From sipping-bounces@ietf.org Mon Nov 20 06:55:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7jP-0004cC-UC; Mon, 20 Nov 2006 06:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7jO-0004c5-En for sipping@ietf.org; Mon, 20 Nov 2006 06:54:34 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm7jJ-0001oI-19 for sipping@ietf.org; Mon, 20 Nov 2006 06:54:34 -0500 Received: from [192.168.0.102] (ppp-70-245-134-245.dsl.rcsntx.swbell.net [70.245.134.245]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kAKBsQOD061682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Nov 2006 05:54:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <456197AD.4030908@nostrum.com> Date: Mon, 20 Nov 2006 05:55:25 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sipping] SIP Subscription for SCADA/Stock quotes References: <62B9B0847CC47543B6B3B5E26BD268E60FBF2FCF@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FBF2FCF@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.134.245 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sipping@ietf.org, Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Samir Srivastava wrote: > If my recollection of arguments on the list is correct, There were > arguments that most of the startups die because of indigestion etc. SIP > is not an infant any more. In the startup mode, you focus on the problem > at the hand. But you keep architecture open such that it can handle > varying needs. It should increase the degree of pervassiveness in the > future seamlessly. I think fathers/god father of SIP were not be having > such a myopic vision on the utility of SIP for just mimicking PSTN and > Presence as you are trying to say. Presence came later and it fit in > well. > Having been deeply involved in the whole genesis of events and presence, I can confidently say that this is highly inaccurate revisionist bunk. Forgive me as I indulge in a bit of personal anecdote. When Jonathan et. al. dropped the first version of the documents that would become the presence and instant messaging extensions using SIP, I was in Stockholm helping Ericsson's 3GPP delegates cope with the then very recent decision by 3GPP to use SIP as their protocol for the IMS core. (At that point in time, the only people doing standards work within Ericsson who had any familiarity of SIP were me and Sean Olson). I recognized the impending train wreck between the use of SUBSCRIBE/NOTIFY for PINT and SUBSCRIBE/NOTIFY for what was then IMPP, and decided that what we really needed was an extensible framework that would allow different usages of these primitives peacefully co-exist. Thus was born the draft that eventually became RFC3265. (Ironically, my own interest in the problem stemmed partially from the need for a call-completion service [1] -- a topic still generating considerable consternation). So, important and relevant point #1: the use of SIP for presence preceded a general framework for event notification by several weeks. (If you would like to verify the timing of a SIP architecture in the IMS core, I'd advise starting with S2-00751 [3], dated May of 2000, which I wrote during my stint in Stockholm: you will be unable to find anything resembling a coherent SIP architecture in any form within 3GPP prior to this contribution). > To me, your fear comes from the arguments given by others for weakness > of SIP as "SIP Does many things for many people" . I counter it "IP does > the same", It depends on how you see and design the versatile / > pervassive protocol fulfilling different needs seamlessly with little > extensions where processing intelligence of those extensions is just at > the required end point. Rest nodes are just conduit. To me, Presence in > its current form is just one aspect. SIP in the core is excellent > protocol but with some rough edges coming from mimicking PSTN, etc... The importance of the 3GPP aspect of this story is as follows: until 3GPP got into the business of extending SIP and defining network architectures for it, it was as decidedly un-PSTN-like as possible. In fact, there was a rather constant thunder of complaining from the ITU-T wonks ("Bell Heads", if you will) that the way SIP did things was so very, very different than the way ISUP and H.323 did things, and that interworking the networks would be problematic. You can see echoes of the SIP community's response to this in draft-sparks-sip-service-examples-00 [2] (which the Bell Heads completely missed the point of, considering it to be the equivalent of H.323's annexes as opposed to a thesis on why service standardization was unnecessary) and the PSTN interoperation work which was eventually published as RFC 3372 and RFC 3398. So, important and relevant point #2: no one was trying to make SIP mimic the PSTN at the time RFC 3265 was developed; reality was quite the opposite: "the SIP way" was so thoroughly anti-PSTN that it received a steady stream of criticism for not fitting neatly into the Bell Heads' view of the world. Beyond these points of fact, there are a number of points of philosophy that I could raise in objection to a lot of what you say (e.g., yes, a lot of things run on IP -- this is a very deliberate design that is intended NOT to be mimicked in higher layers; google "Internet Hourglass" [4] for myriad explanations), but I'll leave the rest of those points to others. /a [1] http://www.potaroo.net/ietf/idref/draft-roach-sip-acb/ [2] http://tools.ietf.org/html/draft-sparks-sip-service-examples-00 [3] http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/drafting_meetings/00_05_Stockholm/S2_key_issues/tdocs/S2-000751.zip [4] http://www.google.com/search?q=%22internet+hourglass%22 _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 08:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm99b-0001v0-TO; Mon, 20 Nov 2006 08:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm99a-0001ui-Ny for sipping@ietf.org; Mon, 20 Nov 2006 08:25:42 -0500 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm99X-0002mo-FG for sipping@ietf.org; Mon, 20 Nov 2006 08:25:40 -0500 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Nov 2006 05:20:15 -0800 From: "Darshan Bildikar" To: "'sipping'" Date: Mon, 20 Nov 2006 18:54:43 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AccMpz2NLW5sPovhRAas2o91ObbHYQ== Message-ID: X-OriginalArrivalTime: 20 Nov 2006 13:20:15.0558 (UTC) FILETIME=[9DD73660:01C70CA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sipping] Question on SIP RFC implementation status X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org List, I am not sure if this is the right forum to ask this question. Apologies in advance if it is not! I was wondering if there is a repository that indicates what vendors have implemented a particular SIP RFC (SIPPING/SIMPLE/XCON/MMUSIC too!) This would:- 1) Provide a good mechanism to gauge the acceptance of a particular RFC in the industry. 2) Help in pushing the case for implementation of a particular RFC if it were to be shown that there was already considerable industry support. This is of course in addition to the actual benefit of implementing the RFC itself! 3) Help IOT initiatives! I am aware that some of this info could be confidential but even some basic info would help! Appreciate any pointers in the right direction Darshan Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 11:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC3x-0006hI-0c; Mon, 20 Nov 2006 11:32:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC3v-0006hB-Lh for sipping@ietf.org; Mon, 20 Nov 2006 11:32:03 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmC3s-0004rG-CM for sipping@ietf.org; Mon, 20 Nov 2006 11:32:03 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GmC3m-0004aP-Q9; Mon, 20 Nov 2006 08:31:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] New draft on grouping of AoRs Date: Mon, 20 Nov 2006 08:31:52 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC538278@sea02-mxc01.citel.com> In-Reply-To: <33D71F0FC0684C4C8A3BB76989EDED9C030BF23C@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] New draft on grouping of AoRs Thread-Index: AccMlhVb6mVXOS/FSBCWGBGnxn/dSwAKrLpA From: "Steve Langstaff" To: "Jesus Javier Arauz \(MI/EEM\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > From: Jesus Javier Arauz (MI/EEM) [mailto:jesus.javier.arauz@ericsson.com]=20 > Sent: 20 November 2006 11:22 > To: sipping@ietf.org > Subject: [Sipping] New draft on grouping of AoRs > > Hi,=20 > > Some weeks ago I submitted the draft draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts archive.=20 > > As many of you know, within the IMS application of SIP a user can have his/her AoRs grouped in so-called Implicit Registration Sets (IRS). The goal of this grouping is to allow bootstrapping a SIP UA that knows only one of the AoRs in an IRS, so the UA gets all the AoRs within that IRS simultaneously registered (and deregistered) in an implicit way. > > Within the context of the latest IMS release (Rel-7) a finer-grained mechanism for grouping AoRs has been introduced. The need to have "aliases", or sets of fully equivalent AoRs, was identified. The IRS mechanism was evaluated as a means to fulfill this need and the conclusion was that the goals of the IRS (i.e. bootstrapping) and the AoR aliasing are orthogonal and thus problems could arise if the same mechanism is used for both purposes. Therefore a new mechanism has been introduced that allows defining groups of alias AoRs that are fully equivalent from a network perspective, i.e. any AoR within one group receives the very same treatment from the network as any other AoR within that group. In order to simplify network handling of these groups the limitation was introduced that any group of alias AoRs must not span more than one IRS, i.e. a group of alias AoRs is always a subset of a containing IRS. (Please forgive me if this appears to be a question that has been answered many times before.) If the AoRs are 'fully equivalent' why can't they be replaced by a single AoR? _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 11:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC8v-0002zC-9Y; Mon, 20 Nov 2006 11:37:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmC8t-0002z1-Io for sipping@ietf.org; Mon, 20 Nov 2006 11:37:11 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmC8s-0005EG-4L for sipping@ietf.org; Mon, 20 Nov 2006 11:37:11 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAKGb2R24773; Mon, 20 Nov 2006 11:37:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Mon, 20 Nov 2006 10:37:02 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711188578A@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FBF2FCF@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccJx6TQvC1F5/7fS+SFJ1f5lVCYwgAAtcrAAAVQ36AAo8VAIAATn4cg From: "Brian Stucker" To: "Samir Srivastava" , "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Samir, See below. > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Monday, November 20, 2006 3:35 AM > To: Stucker, Brian (RICH1:AR00); 'Benjamin Carlyle';=20 > 'sipping@ietf.org' > Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes >=20 > Hi, >=20 > in line. >=20 > Thx > Samir >=20 > > > >> -----Original Message----- > >> From: Srivastava, Samir (SC100:8826) > >> Sent: Thursday, November 16, 2006 4:47 PM > >> To: Benjamin Carlyle; sipping@ietf.org > >> Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes > >>=20 > >> Do we want to cater the different verticals now ? More in-line. > >>=20 > >> Thx > >> Samir > > > >Huh? This is a request to evaluate part of SIP framework to=20 > see if it=20 > >is fit for handling a large scale, highly distributed event driven=20 > >environment. It had better handle it or SIP is in major=20 > trouble trying=20 > >to handle presence. >=20 >=20 > If you remember Hennings frustration from the meeting that=20 > one bit of information is going with how many bytes. SIP=20 > presence framework itself is not that good :-) Though I am=20 > not focused on optimizing it currently. >=20 > In 2000, there was an attempt on the communication of=20 > Intelligent Appliances... > "SIP Extensions for Communicating with Networked Appliances", H.=20 > Schulzrinne, Simon Tsang, Stanley Moyer, Dave Marples, Arjun=20 > Roychowdhury, 11/16/2000,=20 > =20 >=20 > A variety of technologies are available to network appliances and=20 > provide home automation and control. However, these do=20 > not support=20 > wide-area access control and interworking of these Networked=20 > Appliances (NA). This document describes a new SIP=20 > method, DO, that=20 > allows a SIP UA to communicate with NAs. " >=20 > If my recollection of arguments on the list is correct, There=20 > were arguments that most of the startups die because of=20 > indigestion etc. SIP is not an infant any more. In the=20 > startup mode, you focus on the problem at the hand. But you=20 > keep architecture open such that it can handle varying needs.=20 > It should increase the degree of pervassiveness in the future=20 > seamlessly. I think fathers/god father of SIP were not be=20 > having such a myopic vision on the utility of SIP for just=20 > mimicking PSTN and Presence as you are trying to say.=20 > Presence came later and it fit in well.=20 >=20 > To me, your fear comes from the arguments given by others for=20 > weakness of SIP as "SIP Does many things for many people" . I=20 > counter it "IP does the same", It depends on how you see and=20 > design the versatile / pervassive protocol fulfilling=20 > different needs seamlessly with little extensions where=20 > processing intelligence of those extensions is just at the=20 > required end point. Rest nodes are just conduit. To me,=20 > Presence in its current form is just one aspect. SIP in the=20 > core is excellent protocol but with some rough edges coming=20 > from mimicking PSTN, etc... >=20 I think Adam already responded to this, and I happen to agree with his response. >=20 > > > >The point of that statement in 3265 and elsewhere is not to=20 > >limit the URL schemes that can be used, but to point out that=20 > >there are many ways of pushing data around a network. The=20 > >intent of the framework wasn't to solve=20 > >world-event-subscription-hunger. There was a lot of discussion=20 > >at the time around using (PUBLISH in particular) for all sorts=20 > >of things and we wanted to constrain the problem space so we=20 > >could finish off the RFC sometime in our lifetime. >=20 > I am not asking world-event-hunger to be fullfilled with this=20 > like X-Motif/JDK event models etc. I am asking only the=20 > presence framework to extend.... >=20 Presence framework to extend what? [SNIP] >=20 >=20 > As per Section 11 of 3261=20 > "An OPTIONS request MAY be sent as part of an established dialog to > query the peer on capabilities that may be utilized later in the > dialog." >=20 > OPTIONS does allow the Allow-Event header etc. There may be=20 > sometime need for a SIP entity to find the state of subscirbe=20 > created dialog on another end, there it will be useful. (Like=20 > missing NOTIFY with state change delta) State indication can=20 > be event package specific. 200 OK with subscription event=20 > state tells the querying endpoint what is happening. If event=20 > state is currently not supported, then protocol might need to=20 > extend. Other response codes can be viewed differently.. I=20 > was coining it as he was asking for server driven. I don't=20 > understand completely his problem requirements as of now. OPTIONS is not intended to carry information that can change over time. SUBSCRIBE/NOTIFY does this. The protocol has already been extended, and it does not use OPTIONS. See RFC-3857. >=20 > > > >IMHO- The best way to solve the dead server problem is to have=20 > >neither end generating keep-alive traffic (which, in an ideal=20 > >environment in which no node fails, is always useless). Solve=20 > >the problem at the server by utilizing a high-availability=20 > >scheme there so that a server failure does not interrupt service. > > >=20 > Refer my long time back proposal on the list for the Event=20 > based heart beat=20 >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg08844.htm l This was to avoid the periodic OPTIONS messages flow when > other server was down to avoid congestion etc.. I was just=20 > scratching the congestion at that time... >=20 > Somewhere at the IP layer when packet is sent, it needs to=20 > know which IP server should fill. VRRP just talks about the=20 > IP layer connectivity. Can you describe your scheme... > =20 >=20 My point here is that within this application, heartbeating between clients and servers to solve an issue of server availability is a bad model. Use a high-availability scheme between the servers so that they can take over for one another. Nothing special happens at the clients.=20 [SNIP] >=20 > There were some postings on the HTTP Digest being prone to=20 > brute force attacks. > BTW, I worked earlier in different event based/driven systems=20 > too. When I have more free time, I will start looking into this. >=20 Please do. _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 12:23:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCr8-0007V2-GX; Mon, 20 Nov 2006 12:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCr7-0007Uv-0q for sipping@ietf.org; Mon, 20 Nov 2006 12:22:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCr5-0000WP-3Q for sipping@ietf.org; Mon, 20 Nov 2006 12:22:53 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 20 Nov 2006 09:22:49 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAKHMnIT011765; Mon, 20 Nov 2006 12:22:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAKHMmDM020418; Mon, 20 Nov 2006 12:22:48 -0500 (EST) 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.1830); Mon, 20 Nov 2006 12:22:48 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 12:22:48 -0500 Message-ID: <4561E467.4080700@cisco.com> Date: Mon, 20 Nov 2006 12:22:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sipping] New draft on grouping of AoRs References: <76431CABEC5EED489807DB8AEBCCA0BC538278@sea02-mxc01.citel.com> In-Reply-To: <76431CABEC5EED489807DB8AEBCCA0BC538278@sea02-mxc01.citel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 17:22:48.0321 (UTC) FILETIME=[7FF69F10:01C70CC8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2445; t=1164043369; x=1164907369; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20New=20draft=20on=20grouping=20of=20AoRs |Sender:=20 |To:=20Steve=20Langstaff=20; bh=wvCNHIk6IR1auVVvHILGVBwJeG6VekM+iuw4Ttk2zZ4=; b=llcuIoHSJ39mR6a7rku3a/POycrZ337BNV5W7wgVS+GlYM/OiuEQdJ48w95QZ7KjWNeBcso8 kk6hSps+oSQKMQBy+8R3lQvuTU3nPTQtnDDl8Zo7Xgla3Ft7VlvOkRrT; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sipping@ietf.org, "Jesus Javier Arauz \(MI/EEM\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Steve, At least one reason for the aliases is that they may be of different forms that are better suited to use with different devices or modes of access. For instance: sip:john.smith@atlanta.com sip:+12125551234@atlanta.com Paul Steve Langstaff wrote: > >> From: Jesus Javier Arauz (MI/EEM) > [mailto:jesus.javier.arauz@ericsson.com] >> Sent: 20 November 2006 11:22 >> To: sipping@ietf.org >> Subject: [Sipping] New draft on grouping of AoRs >> >> Hi, >> >> Some weeks ago I submitted the draft > draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts archive. >> As many of you know, within the IMS application of SIP a user can have > his/her AoRs grouped in so-called Implicit Registration Sets (IRS). The > goal of this grouping is to allow bootstrapping a SIP UA that knows only > one of the AoRs in an IRS, so the UA gets all the AoRs within that IRS > simultaneously registered (and deregistered) in an implicit way. >> Within the context of the latest IMS release (Rel-7) a finer-grained > mechanism for grouping AoRs has been introduced. The need to have > "aliases", or sets of fully equivalent AoRs, was identified. The IRS > mechanism was evaluated as a means to fulfill this need and the > conclusion was that the goals of the IRS (i.e. bootstrapping) and the > AoR aliasing are orthogonal and thus problems could arise if the same > mechanism is used for both purposes. Therefore a new mechanism has been > introduced that allows defining groups of alias AoRs that are fully > equivalent from a network perspective, i.e. any AoR within one group > receives the very same treatment from the network as any other AoR > within that group. In order to simplify network handling of these groups > the limitation was introduced that any group of alias AoRs must not span > more than one IRS, i.e. a group of alias AoRs is always a subset of a > containing IRS. > > (Please forgive me if this appears to be a question that has been > answered many times before.) > > If the AoRs are 'fully equivalent' why can't they be replaced by a > single AoR? > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 14:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmEue-0005Kk-Gv; Mon, 20 Nov 2006 14:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmEud-0005JX-1A for sipping@ietf.org; Mon, 20 Nov 2006 14:34:39 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmEua-0007JF-PQ for sipping@ietf.org; Mon, 20 Nov 2006 14:34:39 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAKJXnR27812; Mon, 20 Nov 2006 14:33:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) Date: Mon, 20 Nov 2006 13:33:48 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111885ABE@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) Thread-Index: AccM2szOKjMS9BIAQVGQ1XRGMc9T2Q== From: "Brian Stucker" To: "Siddhartha Bhakta" , , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org <<>> Thanks for going through the proposal Siddhartha. I have had to keep going back to make sure that I'm not restating RFC-3959 as I've gone through this process. I also had at one point (if you go looking for earlier incarnations of my early media draft you'll see this) thought about marking up the SDP. There's some problems with this around a proxy's ability to manipulate message bodies. =20 You did prompt me to try to simplify my thinking some more... =20 What I've done is essentially depricated early media. There's just media now. Some of it may get played while another call is being setup. The UAC gets back places that it may wish to contact (and some extra help in knowing what the intended ordering was) to play or contact another endpoint while an associated call is being established. The RTP payload magic is just an extra little helper to know when to switch back to the original call without suffering from clipping. =20 Early media is broken. It will always be broken. So let's get rid of it and have 'associated media'. Essentially media that is related to another call, but is a different priority. I think we could also use this general model for other purposes, such as music on hold, or periodic announcements during a call (ie. a tone that plays every so often to denote some account balance remaining, etc). I'm sure there are others (or will be). =20 This keeps the model much simpler. Every media stream should be signaled separately. I'm not suggesting that we depricate forking, but instead to not expect any media to necessarily be rendered prior to answer which is what RFC-3261 says, but not what RFC-3960 intimates at times. Just that we should get the guy in the middle out of the end-to-end SDP negotiations. =20 I think this is a much more powerful architecture, and one that lets everyone involved on both ends of the media stream know what the status of that stream is at either end without having to introduce complications into the basic call setup flow. =20 Regards, Brian _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 15:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFkO-0001Lf-9H; Mon, 20 Nov 2006 15:28:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFkM-0001La-W6 for sipping@ietf.org; Mon, 20 Nov 2006 15:28:06 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFkE-0005rw-AX for sipping@ietf.org; Mon, 20 Nov 2006 15:28:06 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C9CEAF2; Mon, 20 Nov 2006 21:27:55 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 21:27:55 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 21:27:54 +0100 Received: from [131.160.126.61] (rvi2-126-61.lmf.ericsson.se [131.160.126.61]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8F2CC265D; Mon, 20 Nov 2006 22:27:54 +0200 (EET) Message-ID: <45620FCA.40409@ericsson.com> Date: Mon, 20 Nov 2006 22:27:54 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2006 20:27:54.0855 (UTC) FILETIME=[5BF93770:01C70CE2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Mary Barnes Subject: [Sipping] Draft SIPPING minutes X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Folks, here you have the draft SIPPING minutes from our last face-to-face sessions in San Diego. http://www3.ietf.org/proceedings/06nov/minutes/sipping.txt Cheers, Gonzalo _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 20 15:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmG1j-0002CF-78; Mon, 20 Nov 2006 15:46:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmG1i-0002C9-Gt for sipping@ietf.org; Mon, 20 Nov 2006 15:46:02 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmG1h-0007Xs-8B for sipping@ietf.org; Mon, 20 Nov 2006 15:46:02 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAKKjVk03267; Mon, 20 Nov 2006 15:45:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Heart Beat ||Was RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Mon, 20 Nov 2006 14:45:14 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60FC8B78C@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711188578A@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Heart Beat ||Was RE: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccJx6TQvC1F5/7fS+SFJ1f5lVCYwgAAtcrAAAVQ36AAo8VAIAATn4cgAAmunYA= From: "Samir Srivastava" To: "Brian Stucker" , "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Brian, I will address the other issues separately.=20 >=20 > My point here is that within this application, heartbeating between > clients and servers to solve an issue of server availability is a bad > model. Use a high-availability scheme between the servers so that they can > take over for one another. Nothing special happens at the clients. >=20 >=20 What IP address client will fill in when it needs to send the packet to the SIP Server ? VRRP in the front or something else. If it is VRRP -IP, there is still a chance that SIP message is delivered to the server whose IP layer is good but SIP application server is down/stuck etc... Thx Samir =20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 04:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmS2V-0008Vr-2c; Tue, 21 Nov 2006 04:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmS2T-0008Vk-RW for sipping@ietf.org; Tue, 21 Nov 2006 04:35:37 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmS2M-0007Zx-BD for sipping@ietf.org; Tue, 21 Nov 2006 04:35:37 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F97111E0; Tue, 21 Nov 2006 10:35:27 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 10:35:27 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] New draft on grouping of AoRs Date: Tue, 21 Nov 2006 10:35:02 +0100 Message-ID: <33D71F0FC0684C4C8A3BB76989EDED9C030DB2A1@eesmdmw020.eemea.ericsson.se> In-Reply-To: <4561E467.4080700@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] New draft on grouping of AoRs Thread-Index: AccMyISsztJa5EysTA22vQsvmBXNPwAh2+Zg From: "Jesus Javier Arauz \(MI/EEM\)" To: "Paul Kyzivat" , "Steve Langstaff" X-OriginalArrivalTime: 21 Nov 2006 09:35:27.0070 (UTC) FILETIME=[607D07E0:01C70D50] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Steve, Paul has given you the key reason. Another, less relevant reason is to be able to use 'nicknames', i.e. 'sip:jesus.javier.arauz@ericsson.com' and 'sip:javi@ericsson.com'. The latter will be easier to type in if it's not in the caller's phonebook. Regards, /Javier Paul Kyzivat wrote: > Steve, >=20 > At least one reason for the aliases is that they may be of different > forms that are better suited to use with different devices or modes > of access. For instance: =20 >=20 > sip:john.smith@atlanta.com > sip:+12125551234@atlanta.com >=20 > Paul >=20 > Steve Langstaff wrote: >>=20 >>> From: Jesus Javier Arauz (MI/EEM) >> [mailto:jesus.javier.arauz@ericsson.com] >>> Sent: 20 November 2006 11:22 >>> To: sipping@ietf.org >>> Subject: [Sipping] New draft on grouping of AoRs >>>=20 >>> Hi, >>>=20 >>> Some weeks ago I submitted the draft >> draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts >> archive.=20 >>> As many of you know, within the IMS application of SIP a user can >>> have >> his/her AoRs grouped in so-called Implicit Registration Sets (IRS). >> The goal of this grouping is to allow bootstrapping a SIP UA that >> knows only one of the AoRs in an IRS, so the UA gets all the AoRs >> within that IRS simultaneously registered (and deregistered) in an >> implicit way.=20 >>> Within the context of the latest IMS release (Rel-7) a finer-grained >> mechanism for grouping AoRs has been introduced. The need to have >> "aliases", or sets of fully equivalent AoRs, was identified. The IRS >> mechanism was evaluated as a means to fulfill this need and the >> conclusion was that the goals of the IRS (i.e. bootstrapping) and the >> AoR aliasing are orthogonal and thus problems could arise if the same >> mechanism is used for both purposes. Therefore a new mechanism has >> been introduced that allows defining groups of alias AoRs that are >> fully equivalent from a network perspective, i.e. any AoR within one >> group receives the very same treatment from the network as any other >> AoR within that group. In order to simplify network handling of these >> groups the limitation was introduced that any group of alias AoRs >> must=20 >> not span more than one IRS, i.e. a group of alias AoRs is always a >> subset of a containing IRS. >>=20 >> (Please forgive me if this appears to be a question that has been >> answered many times before.) >>=20 >> If the AoRs are 'fully equivalent' why can't they be replaced by a >> single AoR? >>=20 >> _______________________________________________ >> 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 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 04:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSGp-0007sv-5I; Tue, 21 Nov 2006 04:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSGo-0007sq-Be for sipping@ietf.org; Tue, 21 Nov 2006 04:50:26 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSGm-0002lq-U8 for sipping@ietf.org; Tue, 21 Nov 2006 04:50:26 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GmSGm-0008UZ-74; Tue, 21 Nov 2006 01:50:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] New draft on grouping of AoRs Date: Tue, 21 Nov 2006 01:50:22 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC5384F6@sea02-mxc01.citel.com> In-Reply-To: <33D71F0FC0684C4C8A3BB76989EDED9C030DB2A1@eesmdmw020.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] New draft on grouping of AoRs Thread-Index: AccMyISsztJa5EysTA22vQsvmBXNPwAh2+ZgAACQoMA= From: "Steve Langstaff" To: "Jesus Javier Arauz \(MI/EEM\)" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Fair enough - I was thinking that the users device(s) could register with a single AoR and let the network perform any alias translation required for incoming requests, but I guess that's putting a bit too much control in the network. > -----Original Message----- > From: Jesus Javier Arauz (MI/EEM)=20 > [mailto:jesus.javier.arauz@ericsson.com]=20 > Sent: 21 November 2006 09:35 > To: Paul Kyzivat; Steve Langstaff > Cc: sipping@ietf.org > Subject: RE: [Sipping] New draft on grouping of AoRs >=20 > Steve, Paul has given you the key reason. >=20 > Another, less relevant reason is to be able to use 'nicknames', i.e. > 'sip:jesus.javier.arauz@ericsson.com' and=20 > 'sip:javi@ericsson.com'. The latter will be easier to type in=20 > if it's not in the caller's phonebook. >=20 > Regards, > /Javier >=20 > Paul Kyzivat wrote: > > Steve, > >=20 > > At least one reason for the aliases is that they may be of=20 > different=20 > > forms that are better suited to use with different devices=20 > or modes of=20 > > access. For instance: > >=20 > > sip:john.smith@atlanta.com > > sip:+12125551234@atlanta.com > >=20 > > Paul > >=20 > > Steve Langstaff wrote: > >>=20 > >>> From: Jesus Javier Arauz (MI/EEM) > >> [mailto:jesus.javier.arauz@ericsson.com] > >>> Sent: 20 November 2006 11:22 > >>> To: sipping@ietf.org > >>> Subject: [Sipping] New draft on grouping of AoRs > >>>=20 > >>> Hi, > >>>=20 > >>> Some weeks ago I submitted the draft > >> draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts=20 > >> archive. > >>> As many of you know, within the IMS application of SIP a user can=20 > >>> have > >> his/her AoRs grouped in so-called Implicit Registration Sets (IRS). > >> The goal of this grouping is to allow bootstrapping a SIP UA that=20 > >> knows only one of the AoRs in an IRS, so the UA gets all the AoRs=20 > >> within that IRS simultaneously registered (and deregistered) in an=20 > >> implicit way. > >>> Within the context of the latest IMS release (Rel-7) a=20 > finer-grained > >> mechanism for grouping AoRs has been introduced. The need to have=20 > >> "aliases", or sets of fully equivalent AoRs, was=20 > identified. The IRS=20 > >> mechanism was evaluated as a means to fulfill this need and the=20 > >> conclusion was that the goals of the IRS (i.e.=20 > bootstrapping) and the=20 > >> AoR aliasing are orthogonal and thus problems could arise=20 > if the same=20 > >> mechanism is used for both purposes. Therefore a new mechanism has=20 > >> been introduced that allows defining groups of alias AoRs that are=20 > >> fully equivalent from a network perspective, i.e. any AoR=20 > within one=20 > >> group receives the very same treatment from the network as=20 > any other=20 > >> AoR within that group. In order to simplify network=20 > handling of these=20 > >> groups the limitation was introduced that any group of alias AoRs=20 > >> must not span more than one IRS, i.e. a group of alias=20 > AoRs is always=20 > >> a subset of a containing IRS. > >>=20 > >> (Please forgive me if this appears to be a question that has been=20 > >> answered many times before.) > >>=20 > >> If the AoRs are 'fully equivalent' why can't they be replaced by a=20 > >> single AoR? > >>=20 > >> _______________________________________________ > >> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sip@ietf.org for new developments of core SIP >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 04:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSM5-00027J-Um; Tue, 21 Nov 2006 04:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmSM4-00025m-WA for sipping@ietf.org; Tue, 21 Nov 2006 04:55:53 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmSLz-0003iU-PO for sipping@ietf.org; Tue, 21 Nov 2006 04:55:52 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.148,BAYES_00: -1.665, HTML_80_90: 0.036,HTML_BADTAG_00_10: 0.001,HTML_MESSAGE: 0.001, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Tue, 21 Nov 2006 09:53:35 +0000 From: "Siddhartha Bhakta" To: , Subject: Re: [Sipping] A Test Balloon For AS generated Early Media: EMIND Date: Tue, 21 Nov 2006 09:53:43 -0000 Message-ID: <006d01c70d52$f0783e80$3801a8c0@newportnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccNUu3j0ABONW6uT/mX0kPNIqEI3g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 06d482d1c72628b52d66564c4b21944e Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0931516581==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0931516581== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C70D52.F0783E80" This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C70D52.F0783E80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit <> Hi, If the objective of Application server model is to somehow de-multiplex early media from regular media (in order to avoid media clipping) then I think Brian's proposal is not going beyond it. The RFC3959 has proposed one way to achieve Application Server model whereas Brian is possibly proposing another way to achieve it. The RFC3959 proposed Application server has the issue for NAT traversal as specified below. But the Brian's idea of discriminating early media from regular media based on RTP payload type is showing a way to solve that problem quite easily(specified below). NAT Traversal issue with Application Server model ------------------------------------------------- There are NAT traversal devices that losses few initial media packet before being able to exchange media. Not sure whether Interactive Connectivity Establishment(ICE) also works on same principle or not. However, RFC3959 proposed separate Media path (Source IP-Port, Dest IP-port) for Early media and regular media. Atleast the UAC side should have separate RTP IP/port for early media and regular media to be able to discriminate regular media packet from early media packet. Due to this, Media Pinhole for early media shall be different than regular media. When regular media shall be established then few initial regular media packet shall be lost for Media pinhole discovery. This shall introduce media clipping for NATed case. Solution -------- If avoiding media clipping is the only objective then very simple call flow can be proposed. Many SIP UA and B2BUA vendor may find RFC3959 difficult to implement because it is creating multiple media session for a dialog. Brian's proposal shall be simpler one but it is also creating multiple media sessions even in non-forking case. The UAC shall send INVITE with SDP offer containing two sets of payload types one for regular media and one for early media. The UAS's are allowed to send 18x with early media payload type only in SDP. When they shall send 2xx they are allowed to send regular media payload type in SDP. At UAC side, as soon as RTP packet with regular media payload type is received it can mute all early media sessions. The Media pinhole shall be created at the cost of few initial early media packets but that same media pinhole shall be re-used for regular media also. Therefore, no regular media packet shall be lost. There are few ways to carry separate payload for early media and regular media: 1)Modifying the RTPMAP attributes to indicate whether a payload type is for early media or regular media whereas m= line shall carry regular media payload type and early media payload type. The existing RTPMAP syntax is, a=rtpmap: /[/] It can be modified to, a=rtpmap: /[/] [early] if optional 'early' flag is specified then that payload type shall be for early media. v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 96 97 a=rtpmap:96 PCMU/8000 a=rtpmap:97 PCMU/8000 early In the above example, the 97 payload type is for early media. or 2)Introduce early-media=line to carry early media payload types under a media stream. The above example shall be modified to, v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 96 early-media=97 a=rtpmap:96 PCMU/8000 a=rtpmap:97 PCMU/8000 Call Flow ----------- A B | | |--------(F1) INVITE------->| | offer | | | |<--(F2) Session Progress---| | early-answer | | | | ************************* | | Early Media | | <--------RTP for early media | <--------RTP for early media | ************************* | | | |<--------RTP for regular media | | |<--------(F3) 200 OK-------| | | |---------(F4) ACK--------->| | | Where(Only format 1 is shown here), F1: v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 96 97 a=rtpmap:96 PCMU/8000 a=rtpmap:97 PCMU/8000 early F2: v=0 o=Bob 2890844725 2890844725 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30000 RTP/AVP 97 a=rtpmap:97 PCMU/8000 early F3: v=0 o=Bob 2890844725 2890844725 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30000 RTP/AVP 96 a=rtpmap:96 PCMU/8000 Please check whether it makes sense or not. Thanks, Siddhartha Paul wrote: ------------ Brian, Is there a reason you propose something new like this in preference to the Application Server model of early media specified in RFC 3960? While apparently not implemented, it does have the advantage of having a spec that is already done. Both it and what you propose present some implementation/deployment challenges. Yours is probably somewhat simpler to implement, but is that enough to be worth the trouble? If so, should we also deprecate the application server model? --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- ------=_NextPart_000_006E_01C70D52.F0783E80 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 
<<re-sending as it was exceeding =
mailing-list buffer>>
 
Hi,
 
If the =
objective of Application server model is to somehow =
de-multiplex
early =
media from regular media (in order to avoid media clipping) =
then
I think =
Brian's proposal is not going
beyond =
it. The RFC3959 has proposed one way to achieve Application =
Server
model =
whereas Brian is possibly proposing another way to achieve =
it.
 
The =
RFC3959 proposed Application server has the issue for NAT =
traversal
as =
specified below.
But the =
Brian’s idea of discriminating early media from regular media =
based
on RTP =
payload type is showing a way to solve that problem quite =
easily(specified
below).
 
NAT =
Traversal issue with Application Server =
model
----------------------------------------------=
---
There are =
NAT traversal devices that losses few initial media =
packet
before =
being able to exchange media. Not sure whether =
Interactive
Connectivity Establishment(ICE) also works on =
same principle or not.
However, =
RFC3959 proposed separate Media path (Source IP-Port, =
Dest
IP-port) =
for Early media and regular media. Atleast the UAC side =
should
have =
separate RTP IP/port for early media and regular media to be =
able
to =
discriminate regular media packet from early media =
packet.
Due to =
this, Media Pinhole for early media shall be different =
than
regular =
media. When regular media shall be established then few =
initial
regular =
media packet shall be lost for Media pinhole =
discovery.
This =
shall introduce media clipping for NATed =
case.
 
 
Solution
--------
If =
avoiding media clipping is the only objective then very simple =
call
flow can =
be proposed. Many SIP UA and B2BUA vendor =
may
find =
RFC3959 difficult to implement because it is creating multiple =
media
session =
for a dialog. Brian’s proposal shall be simpler one but it is =
also
creating =
multiple media sessions even in non-forking =
case.
 
The UAC =
shall send INVITE with SDP offer containing two sets of payload =
types
one for =
regular media and one for early media. The UAS's are allowed =
to
send 18x =
with early media payload type only in SDP. When they shall =
send
2xx they =
are allowed to send regular media payload type in =
SDP.
 
At UAC =
side, as soon as RTP packet with regular media payload type =
is
received =
it can mute all early media sessions. The Media pinhole =
shall
be =
created at the cost of few initial early media packets but that =
same
media =
pinhole shall be re-used for regular media also. Therefore, =
no
regular =
media packet shall be lost.
 
 
There are =
few ways to carry separate payload for early =
media
and =
regular media:
 
        =
1)Modifying the RTPMAP attributes to indicate whether a payload =
type
        is =
for early media or regular media whereas m=3D line shall =
carry
        =
regular media payload type and early media payload =
type.
        =
The existing RTPMAP syntax is,
    a=3Drtpmap:<payload =
type> <encoding name>/<clock =
rate>[/<encoding
     =
parameters>]
        It =
can be modified to,
    a=3Drtpmap:<payload =
type> <encoding name>/<clock =
rate>[/<encoding
     parameters>] =
[early]
        =

       &nbs=
p; if optional 'early' flag is specified then that payload type shall =
be
       &nbs=
p; for early media.
 
    =
    v=3D0
        =
o=3Dalice =
2890844730 2890844731 IN IP4 =
host.example.com
        =
s=3D
        =
c=3DIN IP4 192.0.2.1
        =
t=3D0 0
        =
m=3Daudio 20000 RTP/AVP 96 97
        =
a=3Drtpmap:96 PCMU/8000
        =
a=3Drtpmap:97 PCMU/8000 early
 
        In =
the above example, the 97 payload type is for early =
media.
 
 
        =
or
        =
2)Introduce early-media=3Dline to carry early media payload types =
under
        a =
media stream. The above example shall be modified =
to,
 
 
    =
    v=3D0
        =
o=3Dalice =
2890844730 2890844731 IN IP4 =
host.example.com
        =
s=3D
        =
c=3DIN IP4 192.0.2.1
        =
t=3D0 0
        =
m=3Daudio 20000 RTP/AVP 96
        =
early-media=3D97
        =
a=3Drtpmap:96 PCMU/8000
        =
a=3Drtpmap:97 PCMU/8000
 
 
 
 
Call =
Flow
-----------
      = A            =             &= nbsp;  B
      =
|            =
            &=
nbsp;  |
      |--------(F1) =
INVITE------->|
      =
|            =
offer          =
|
      =
|            =
            &=
nbsp;  |
      |<--(F2) =
Session Progress---|
      =
|       =
early-answer        =
|
      =
|            =
            &=
nbsp;  |
      | =
************************* |
      =
|        Early =
Media        =
|
      | =
<--------RTP for early media
      | =
<--------RTP for early media
      | =
************************* |
      =
|            =
            &=
nbsp;  |
      =
|<--------RTP for regular =
media
    =
  |          =
            &=
nbsp;    |
      =
|<--------(F3) 200 =
OK-------|
      =
|            =
            &=
nbsp;  |
      |---------(F4) =
ACK--------->|
      =
|            =
            &=
nbsp;  |
 
 
Where(Only format 1 is shown =
here),
F1:
   =
v=3D0
   o=3Dalice =
2890844730 2890844731 IN IP4 =
host.example.com
   =
s=3D
   c=3DIN IP4 =
192.0.2.1
   t=3D0 =
0
   m=3Daudio 20000 RTP/AVP 96 =
97
   a=3Drtpmap:96 =
PCMU/8000
   a=3Drtpmap:97 PCMU/8000 =
early
 
F2:
   =
v=3D0
   o=3DBob 2890844725 2890844725 IN =
IP4 host.example.org
   =
s=3D
   c=3DIN IP4 =
192.0.2.2
   t=3D0 =
0
   m=3Daudio 30000 RTP/AVP =
97
   a=3Drtpmap:97 PCMU/8000 =
early
 
F3:
   =
v=3D0
   o=3DBob 2890844725 2890844725 IN =
IP4 host.example.org
   =
s=3D
   c=3DIN IP4 =
192.0.2.2
   t=3D0 =
0
   m=3Daudio 30000 RTP/AVP =
96
   a=3Drtpmap:96 =
PCMU/8000
 
 
Please =
check whether it makes sense or =
not.
 
Thanks,
Siddhartha
=
 
 
 
Paul =
wrote:
------------
 
Brian,


Is there a reason you propose something new like this in preference to the Application Server model of early media specified in RFC = 3960?

While apparently not implemented, it does have the advantage of having a spec = that is already done. Both it and what you propose present some implementation/deployment challenges. Yours is probably somewhat simpler = to implement, but is that enough to be worth the trouble? If so, should we = also deprecate the application server = model?



---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------
------=_NextPart_000_006E_01C70D52.F0783E80-- --===============0931516581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0931516581==-- From sipping-bounces@ietf.org Tue Nov 21 05:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmT3g-00014N-Cc; Tue, 21 Nov 2006 05:40:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmT3e-00014C-5v for sipping@ietf.org; Tue, 21 Nov 2006 05:40:54 -0500 Received: from bay0-omc2-s26.bay0.hotmail.com ([65.54.246.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmT3c-0001TY-Se for sipping@ietf.org; Tue, 21 Nov 2006 05:40:54 -0500 Received: from BAY112-W3 ([64.4.26.103]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 02:39:46 -0800 X-Originating-IP: [64.104.175.143] X-Originating-Email: [iamjennycn@hotmail.com] Message-ID: From: CheungJenny To: Date: Tue, 21 Nov 2006 10:39:46 +0000 MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2006 10:39:46.0564 (UTC) FILETIME=[5CED1440:01C70D59] X-Spam-Score: 2.2 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2110462707==" Errors-To: sipping-bounces@ietf.org --===============2110462707== Content-Type: multipart/alternative; boundary="_e6138f9f-a215-4113-906b-a04e0849b9e2_" --_e6138f9f-a215-4113-906b-a04e0849b9e2_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, I have a question about "hookflash event transfer". Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, can hookflash be transfered using the same 3 methods? What I want to know is, if I hookflash, how does the peer gets to know this? Thanks. _________________________________________________________________ ÂÊÏȳ¢ÊÔ Windows Live Mail¡£ http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d --_e6138f9f-a215-4113-906b-a04e0849b9e2_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi,
 
I have a question about "hookflash event transfer".
Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, can hookflash be transfered using the same 3 methods?
What I want to know is, if I hookflash, how does the peer gets to know this?
 
Thanks.
 

Windows Live Safety Center ΪÄúµÄ¼ÆËã»úÌṩÃâ·ÑµÄ°²È«É¨Ãè·þÎñ¡£ ËüÊÇÃâ·ÑµÄ£¡ --_e6138f9f-a215-4113-906b-a04e0849b9e2_-- --===============2110462707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2110462707==-- From sipping-bounces@ietf.org Tue Nov 21 09:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWI9-0000xH-6J; Tue, 21 Nov 2006 09:08:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWI7-0000w0-Rp for sipping@ietf.org; Tue, 21 Nov 2006 09:08:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWI5-0006gb-Ek for sipping@ietf.org; Tue, 21 Nov 2006 09:08:03 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 06:08:00 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kALE80ZY025511; Tue, 21 Nov 2006 09:08:00 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kALE80DM016605; Tue, 21 Nov 2006 09:08:00 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:08:00 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:07:59 -0500 Message-ID: <4563083F.6020108@cisco.com> Date: Tue, 21 Nov 2006 09:07:59 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: CheungJenny Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Nov 2006 14:07:59.0744 (UTC) FILETIME=[73711000:01C70D76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1183; t=1164118080; x=1164982080; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20how=20to=20transfer=20hookflash=20event, = 09e.g.=20in=20a=203-way=20conference=0A=20call? |Sender:=20 |To:=20CheungJenny=20; bh=PqT5NAz2/5x8AR+6iTVlTC6aJvMXOYKW46XZs6tV96E=; b=aYKKu0QUUCsrczKwsXCuAA39qXqPk67h1xcrnDTsVXtB28vgYx3b7znfc4F0hAKFYfaE7n7Z 33XJnOTE3Ohxk7px9Q3dyWa3/yUEGTN5gJDVbqTnYQ6NTJJfr9iv8mV6; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Generally in sip you would expect the device to handle the hookflash locally (because it is a user interface issue), decide it is a request to transfer, and then initiate the transfer itself. So the hookflash need not be signaled remotely. Paul CheungJenny wrote: > Hi, > > I have a question about "hookflash event transfer". > Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, > can hookflash be transfered using the same 3 methods? > What I want to know is, if I hookflash, how does the peer gets to know this? > > Thanks. > > > ------------------------------------------------------------------------ > Windows Live Safety Center ΪÄúµÄ¼ÆËã»úÌṩÃâ·ÑµÄ°²È«É¨Ãè·þÎñ¡£ ËüÊÇÃâ·Ñ > µÄ£¡ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 10:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXE2-0006D0-IO; Tue, 21 Nov 2006 10:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXE1-0006BS-4U for sipping@ietf.org; Tue, 21 Nov 2006 10:07:53 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXDy-0003ob-Mz for sipping@ietf.org; Tue, 21 Nov 2006 10:07:53 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kALF7Lf04964; Tue, 21 Nov 2006 10:07:22 -0500 (EST) Received: from [47.130.19.1] ([47.130.19.1] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 10:07:20 -0500 Message-ID: <45631625.7010205@nortel.com> Date: Tue, 21 Nov 2006 10:07:17 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <4563083F.6020108@cisco.com> In-Reply-To: <4563083F.6020108@cisco.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 21 Nov 2006 15:07:20.0764 (UTC) FILETIME=[BDF997C0:01C70D7E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortel.com id kALF7Lf04964 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sipping@ietf.org, CheungJenny X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I shuddered to see the concept of stimulus signalling in SIP in some of the test cases for our recent MultiService Forum interoperability event. The counter-argument I received is that there is a requirement for such signalling when black telephones sit behind a SIP-speaking IAD and the meaning of "flash" in a given context is held in service logic in an application server. I'll also mention that we are talking about logic that varies from country to country. At my instigation the MSF is investigating the requirements as they relate both to architecture and protocol selection. Paul Kyzivat wrote: > Generally in sip you would expect the device to handle the hookflash > locally (because it is a user interface issue), decide it is a request > to transfer, and then initiate the transfer itself. So the hookflash > need not be signaled remotely. >=20 > Paul >=20 > CheungJenny wrote: >> Hi, >> =20 >> I have a question about "hookflash event transfer". >> Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT,= =20 >> can hookflash be transfered using the same 3 methods? >> What I want to know is, if I hookflash, how does the peer gets to know= this? >> =20 >> Thanks. >> =20 >> >> ----------------------------------------------------------------------= -- >> Windows Live Safety Center =CE=AA=C4=FA=B5=C4=BC=C6=CB=E3=BB=FA=CC=E1=B9= =A9=C3=E2=B7=D1=B5=C4=B0=B2=C8=AB=C9=A8=C3=E8=B7=FE=CE=F1=A1=A3 =CB=FC=CA= =C7=C3=E2=B7=D1=20 >> =B5=C4=A3=A1 >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> 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 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 10:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXnQ-0001aA-U6; Tue, 21 Nov 2006 10:44:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXnQ-0001a2-6U for sipping@ietf.org; Tue, 21 Nov 2006 10:44:28 -0500 Received: from brixmail.brixnet.com ([63.122.27.37] helo=brixmail.ma.brixnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXnL-0008Ee-Va for sipping@ietf.org; Tue, 21 Nov 2006 10:44:28 -0500 Received: from mail pickup service by brixmail.ma.brixnet.com with Microsoft SMTPSVC; Tue, 21 Nov 2006 10:44:23 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Comments on draft-malas-performance-metrics-05.txt Date: Tue, 21 Nov 2006 10:44:23 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Sipping] Comments on draft-malas-performance-metrics-05.txt thread-index: AccNg+rh3vQgyQsrS9KnGpuF6jGGSQ== From: "Venna, Nagarjuna" To: X-OriginalArrivalTime: 21 Nov 2006 15:44:23.0625 (UTC) FILETIME=[EAE74390:01C70D83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Daryl, =20 I agree with Reza on NER (=3DSEER). We have found that it is a useful metric to set thresholds on for SLA monitoring and conformance. =20 Regards, Nagarjuna =20 On Thu, 16 Nov 2006 18:24:24 -0800, Fardid, Reza wrote: >> Sounds good. I think NER (=3D=3DSEER) is more useful for both the=20 >> customer (SLA) and service provider (performance) tracking purposes=20 >> than ASR, which is contaminated. > > Regards, >=20 > Reza Fardid -------------------------------------------------------------------------= ---------------------------------------------------------------------- Service Quality Matters. Test the performance and quality of your VoIP = or IP video service at:=20 http://www.TestYourVoIP.com http://www.TestYourIPVideo.com _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 11:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYUM-0005eU-9E; Tue, 21 Nov 2006 11:28:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYUK-0005eM-CU for sipping@ietf.org; Tue, 21 Nov 2006 11:28:48 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYUH-0007eG-TI for sipping@ietf.org; Tue, 21 Nov 2006 11:28:48 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:28:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Tue, 21 Nov 2006 17:28:01 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64EC0C34BEA9@ftrdmel1.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Thread-Index: AccNfwg2VhdYOMJBT9+sjBX1lcozcQACTOGA From: "GARCIN Sebastien RD-CORE-ISS" To: "Tom-PT Taylor" , "Paul Kyzivat" X-OriginalArrivalTime: 21 Nov 2006 16:28:01.0378 (UTC) FILETIME=[0334AC20:01C70D8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sipping@ietf.org, CheungJenny X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1359683413==" Errors-To: sipping-bounces@ietf.org --===============1359683413== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Rm9yIHlvdXIgaW5mb3JtYXRpb24sIFRJU1BBTiBoYXMgZGVzY3JpYmVkIHR3byBzY2VuYXJpbyBm b3IgaG9va2ZsYXNoIGludGVycHJldGF0aW9uIGFzIHBhcnQgdGhlIFBTVE4gZW11bGF0aW9uIHN1 YnN5c3RlbSAoc29ycnkgZm9yIHRoZSB2b2NhYnVsYXJ5KToNCi0gbG9jYWwgaW50ZXJwcmV0YXRp b24NCi0gcmVtb3RlIGludGVycHJldGF0aW9uIGZyb20gYW4gQVMgKGluIHRoaXMgY2FzZSB0aGUg aG9va2ZsYXNoIGV2ZW50IGlzIHNlbnQgaW4gdGhlIHJlcXVlc3QtdXJpIG9mIHRoZSBJTlZJVEUp DQoNCnPDqWJhc3RpZW4gDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBUb20t UFQgVGF5bG9yIFttYWlsdG86dGF5bG9yQG5vcnRlbC5jb21dIA0KRW52b3nDqSA6IG1hcmRpIDIx IG5vdmVtYnJlIDIwMDYgMTY6MDcNCsOAIDogUGF1bCBLeXppdmF0DQpDYyA6IHNpcHBpbmdAaWV0 Zi5vcmc7IENoZXVuZ0plbm55DQpPYmpldCA6IFJlOiBbU2lwcGluZ10gaG93IHRvIHRyYW5zZmVy IGhvb2tmbGFzaCBldmVudCxlLmcuIGluIGEgMy13YXkgY29uZmVyZW5jZSBjYWxsPw0KDQpJIHNo dWRkZXJlZCB0byBzZWUgdGhlIGNvbmNlcHQgb2Ygc3RpbXVsdXMgc2lnbmFsbGluZyBpbiBTSVAg aW4gc29tZSBvZiB0aGUgdGVzdCBjYXNlcyBmb3Igb3VyIHJlY2VudCBNdWx0aVNlcnZpY2UgRm9y dW0gaW50ZXJvcGVyYWJpbGl0eSBldmVudC4NClRoZSBjb3VudGVyLWFyZ3VtZW50IEkgcmVjZWl2 ZWQgaXMgdGhhdCB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBzdWNoIHNpZ25hbGxpbmcgd2hl biBibGFjayB0ZWxlcGhvbmVzIHNpdCBiZWhpbmQgYSBTSVAtc3BlYWtpbmcgSUFEIGFuZCB0aGUg bWVhbmluZyBvZiAiZmxhc2giIGluIGEgZ2l2ZW4gY29udGV4dCBpcyBoZWxkIGluIHNlcnZpY2Ug bG9naWMgaW4gYW4gYXBwbGljYXRpb24gc2VydmVyLiBJJ2xsIGFsc28gbWVudGlvbiB0aGF0IHdl IGFyZSB0YWxraW5nIGFib3V0IGxvZ2ljIHRoYXQgdmFyaWVzIGZyb20gY291bnRyeSB0byBjb3Vu dHJ5LiBBdCBteSBpbnN0aWdhdGlvbiB0aGUgTVNGIGlzIGludmVzdGlnYXRpbmcgdGhlIHJlcXVp cmVtZW50cyBhcyB0aGV5IHJlbGF0ZSBib3RoIHRvIGFyY2hpdGVjdHVyZSBhbmQgcHJvdG9jb2wg c2VsZWN0aW9uLg0KDQpQYXVsIEt5eml2YXQgd3JvdGU6DQo+IEdlbmVyYWxseSBpbiBzaXAgeW91 IHdvdWxkIGV4cGVjdCB0aGUgZGV2aWNlIHRvIGhhbmRsZSB0aGUgaG9va2ZsYXNoIA0KPiBsb2Nh bGx5IChiZWNhdXNlIGl0IGlzIGEgdXNlciBpbnRlcmZhY2UgaXNzdWUpLCBkZWNpZGUgaXQgaXMg YSByZXF1ZXN0IA0KPiB0byB0cmFuc2ZlciwgYW5kIHRoZW4gaW5pdGlhdGUgdGhlIHRyYW5zZmVy IGl0c2VsZi4gU28gdGhlIGhvb2tmbGFzaCANCj4gbmVlZCBub3QgYmUgc2lnbmFsZWQgcmVtb3Rl bHkuDQo+IA0KPiAJUGF1bA0KPiANCj4gQ2hldW5nSmVubnkgd3JvdGU6DQo+PiBIaSwNCj4+ICAN Cj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0ICJob29rZmxhc2ggZXZlbnQgdHJhbnNmZXIiLg0K Pj4gQmVjYXVzZSBEVE1GIHNpZ25hbCBjYW4gYmUgdHJhbnNmZXJlZCBpbiAzIHdheXM6IElORk8s IGluYmFuZCBhbmQgDQo+PiBBVlQsIGNhbiBob29rZmxhc2ggYmUgdHJhbnNmZXJlZCB1c2luZyB0 aGUgc2FtZSAzIG1ldGhvZHM/DQo+PiBXaGF0IEkgd2FudCB0byBrbm93IGlzLCBpZiBJIGhvb2tm bGFzaCwgaG93IGRvZXMgdGhlIHBlZXIgZ2V0cyB0byBrbm93IHRoaXM/DQo+PiAgDQo+PiBUaGFu a3MuDQo+PiAgDQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtLS0gV2luZG93cyBMaXZlIFNhZmV0 eSBDZW50ZXIg5Li65oKo55qE6K6h566X5py65o+Q5L6b5YWN6LS555qE5a6J5YWo5omr5o+P5pyN 5Yqh44CCIOWug+aYr+WFjei0uQ0KPj4g55qE77yBIDxodHRwOi8vc2FmZXR5LmxpdmUuY29tL3Np dGUvWkgtQ04vZGVmYXVsdC5odG0+DQo+Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLS0tDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IFNpcHBpbmcgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBwaW5nDQo+PiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUg YXBwbGljYXRpb24gb2YgU0lQIFVzZSANCj4+IHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEu ZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXAgVXNlIA0KPj4gc2lwQGlldGYub3JnIGZv ciBuZXcgZGV2ZWxvcG1lbnRzIG9mIGNvcmUgU0lQDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXBwaW5nIG1haWxpbmcgbGlzdCAgaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcGluZw0KPiBUaGlzIGxpc3Qg aXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQIFVzZSANCj4g c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50 IHNpcCBVc2UgDQo+IHNpcEBpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvZiBjb3JlIFNJ UA0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClNpcHBpbmcgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBwaW5nDQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgYXBw bGljYXRpb24gb2YgU0lQIFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3Ig cXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwIFVzZSBzaXBAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9w bWVudHMgb2YgY29yZSBTSVANCg== --===============1359683413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1359683413==-- From sipping-bounces@ietf.org Tue Nov 21 11:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYv3-0005F8-0K; Tue, 21 Nov 2006 11:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYv1-0005F0-1a for sipping@ietf.org; Tue, 21 Nov 2006 11:56:23 -0500 Received: from mail.newport-networks.co.uk ([217.45.197.114] helo=mail.newport-networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYux-0003Xe-P8 for sipping@ietf.org; Tue, 21 Nov 2006 11:56:23 -0500 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.166,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by mail.newport-networks.com; Tue, 21 Nov 2006 16:53:48 +0000 From: "Siddhartha Bhakta" To: "'Brian Stucker'" , , "'Francois Audet'" Subject: RE: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) Date: Tue, 21 Nov 2006 16:52:51 -0000 Message-ID: <00db01c70d8d$7dc300b0$3801a8c0@newportnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccM2szOKjMS9BIAQVGQ1XRGMc9T2QAkwEVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111885ABE@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brain, Your proposal may simplify the Media server driven (early) media cases as UAC shall send another INVITE to create early-media or associated-media session. But we need to check whether basic purpose of early media shall be achieved by your proposal or not. Apology in advance, if I am asking some question which has been answered and concluded in past. The early media in PSTN domain has following salient points, a) A tone/indication to the Calling party to indicate that your call attempt is being honored by network. Call progress, Ringback tones are serving that purpose. Without those, caller shall disconnect the call. b) Early media indicates whether voice path will be through once Called side shall answer. If user can not hear the ringback tone properly then typically Caller shall terminate the call. Therefore, Caller shall not have to pay for a call that does not have good quality. This indicates that early media and regular media should use the same media path(Soure RTP IP/port, Dest RTP IP/port). That was the main reason why ringback tone were generated by Called side exchange. c)The early media is not billed since it is there just to indicate whether media path shall be through while Called party shall answer. Typically early media is shall be one-way (Called side to calling side). Since early media is not billed, there is chance that people may mis-use it. To avoid the misuse, early media was one-way. In SIP world the early media shall needs to be bothway just to avoid media clipping in NATed environment. The early-media shall be clipped for discovering media NAT pinhole(who cares about early media clipping). But this shall ensure that regular media shall not be clipped. If we forget about forking case then all the above points were complied by very simple SIP call flow. The 18x contains same SDP as that of 200 OK. This ensures that early media and regular media follow the same media path(point b) above. The point b) is very important from the NAT traversal point of view. Otherwise, we shall experience the regular media clipping. The point c) was implemented quite easily as typically Application server starts billing on getting 200 OK of dialog initiating INVITE. In your architecture you have to make sure that you are ensuring point b) and point c). To satisfy the point b), your proposal shall have two dialogs with same Media path. Will that create any problem? If any SBC is between then two separate dialog shall have separate media paths. It shall quite difficult to satisfy the point c) in your proposal. You need to add some header, ext to indicate that a particular dialog is for early-media/associated-media only so that Application server does not bill it. But I thought, the original intention was to take care early media in case of forking. I don't think we have proposed any proper solution to take care of that. The early media is broken in case forking if SIP user does not have the conferencing ability(in that case, it can put all the early dialogs in conference). So, let it be broken. Can we introduce some SIP header or extension to indicate that a particular dialog is a forked dialog so that Called party does not initiate early media? Let the calling side to play local ringtone for forking case as per the local policy as specified in RFC3960. If SIP user have the conferencing ability and wants to do the conferencing of all early media then it may indicate so in the new SIP header or extension. In summery, I am suggesting two things, 1. Deprecation of Application Server Model and 2. Avoid (inband) early media in case of forking if Calling user does not have the ability to do conferencing of early media. Any comment on this? Thanks & Regards, Siddhartha -----Original Message----- From: Brian Stucker [mailto:bstucker@nortel.com] Sent: 20 November 2006 19:34 To: Siddhartha Bhakta; pkyzivat@cisco.com; Francois Audet Cc: sipping@ietf.org Subject: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) <<>> Thanks for going through the proposal Siddhartha. I have had to keep going back to make sure that I'm not restating RFC-3959 as I've gone through this process. I also had at one point (if you go looking for earlier incarnations of my early media draft you'll see this) thought about marking up the SDP. There's some problems with this around a proxy's ability to manipulate message bodies. You did prompt me to try to simplify my thinking some more... What I've done is essentially depricated early media. There's just media now. Some of it may get played while another call is being setup. The UAC gets back places that it may wish to contact (and some extra help in knowing what the intended ordering was) to play or contact another endpoint while an associated call is being established. The RTP payload magic is just an extra little helper to know when to switch back to the original call without suffering from clipping. Early media is broken. It will always be broken. So let's get rid of it and have 'associated media'. Essentially media that is related to another call, but is a different priority. I think we could also use this general model for other purposes, such as music on hold, or periodic announcements during a call (ie. a tone that plays every so often to denote some account balance remaining, etc). I'm sure there are others (or will be). This keeps the model much simpler. Every media stream should be signaled separately. I'm not suggesting that we depricate forking, but instead to not expect any media to necessarily be rendered prior to answer which is what RFC-3261 says, but not what RFC-3960 intimates at times. Just that we should get the guy in the middle out of the end-to-end SDP negotiations. I think this is a much more powerful architecture, and one that lets everyone involved on both ends of the media stream know what the status of that stream is at either end without having to introduce complications into the basic call setup flow. Regards, Brian --------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. --------------- _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 12:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZPh-0008GI-7h; Tue, 21 Nov 2006 12:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZPg-0008FO-6O for sipping@ietf.org; Tue, 21 Nov 2006 12:28:04 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZPe-00005p-J0 for sipping@ietf.org; Tue, 21 Nov 2006 12:28:04 -0500 Received: from [132.197.118.231] by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J9300608CINERU3@vms040.mailsrvcs.net> for sipping@ietf.org; Tue, 21 Nov 2006 11:28:00 -0600 (CST) Date: Tue, 21 Nov 2006 12:28:02 -0500 From: David Robbins Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? In-reply-to: <45631625.7010205@nortel.com> To: "Tom-PT Taylor" Message-id: MIME-version: 1.0 (Apple Message framework v624) X-Mailer: Apple Mail (2.624) References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1309498392==" Errors-To: sipping-bounces@ietf.org --===============1309498392== Content-type: multipart/alternative; boundary=Apple-Mail-8--1008194823 --Apple-Mail-8--1008194823 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=HZ-GB-2312; delsp=yes; format=flowed What bothers me about including "flash" signaling in SIP is that it creates a device dependency that doesn't belong in SIP. It renders the flash-dependent services inaccessible to devices other than black phones (or devices with equivalent user interface capabilities), or else requires devices to emulate the flash (or more generally, translate the user's selection of a service into a sequence of low-level signaling actions) in order to access such services. Services that involve management of multiple calls (which are typically what flash is used for, e.g., call waiting, three-way call, call transfer) are much better managed in a SIP world by the device itself. SIP application servers built by carrying over the PSTN legacy don't like to let the SIP device do such things, but really, that's an artifact of PSTN legacy thinking. If you want to emulate the PSTN in all of its details with a VoIP protocol, choose MGCP or MEGACO, not SIP, for communication with the end-user device. I prefer to revisit the flash-dependent services themselves, identify the SIP equivalent, and define the required behavior for a black-phone-like device to translate the familiar UI actions into the appropriate device-independent SIP signaling. Several SIPPING documents have shown the SIP equivalent for most such services (e.g., draft-ietf-sipping-cc-framework). Given flash-dependent service logic that varies from one place to another, my approach requires tailoring the SIP device behavior to the environment within which it is used. This can be a complication, which I will admit is avoided if we simply transmit a flash in SIP signaling. How much variation is there, really? There's a practical limit to what you can do with a flash, because it's an unavoidably ambiguous service request, and the user must remember, for a given service, a sequence of actions that may include multiple flashes and dialed codes. In North America, there are really very few services that are directly flash-dependent, and they're all easily translated by the device into standard SIP signaling. Rather than just assume that we'll always need to be able to send a flash to the server, it would be preferable to understand just how many and what flash-dependent services exist throughout the world, and how they should be done in SIP. I look forward to the results of the MSF investigation Tom has initiated. I already know the answer for North American services, but not for the rest of the world. On Nov 21, 2006, at 10:07 AM, Tom-PT Taylor wrote: > I shuddered to see the concept of stimulus signalling in SIP in some of > the test cases for our recent MultiService Forum interoperability > event. > The counter-argument I received is that there is a requirement for such > signalling when black telephones sit behind a SIP-speaking IAD and the > meaning of "flash" in a given context is held in service logic in an > application server. I'll also mention that we are talking about logic > that varies from country to country. At my instigation the MSF is > investigating the requirements as they relate both to architecture and > protocol selection. > > Paul Kyzivat wrote: >> Generally in sip you would expect the device to handle the hookflash >> locally (because it is a user interface issue), decide it is a request >> to transfer, and then initiate the transfer itself. So the hookflash >> need not be signaled remotely. >> >> Paul >> >> CheungJenny wrote: >>> Hi, >>> >>> I have a question about "hookflash event transfer". >>> Because DTMF signal can be transfered in 3 ways: INFO, inband and >>> AVT, >>> can hookflash be transfered using the same 3 methods? >>> What I want to know is, if I hookflash, how does the peer gets to >>> know this? >>> >>> Thanks. >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> Windows Live Safety Center ~{N*Dz5D>> ~{5D#!~} >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 --Apple-Mail-8--1008194823 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=HZ-GB-2312 What bothers me about including "flash" signaling in SIP is that it creates a device dependency that doesn't belong in SIP. It renders the flash-dependent services inaccessible to devices other than black phones (or devices with equivalent user interface capabilities), or else requires devices to emulate the flash (or more generally, translate the user's selection of a service into a sequence of low-level signaling actions) in order to access such services. Services that involve management of multiple calls (which are typically what flash is used for, e.g., call waiting, three-way call, call transfer) are much better managed in a SIP world by the device itself. SIP application servers built by carrying over the PSTN legacy don't like to let the SIP device do such things, but really, that's an artifact of PSTN legacy thinking. If you want to emulate the PSTN in all of its details with a VoIP protocol, choose MGCP or MEGACO, not SIP, for communication with the end-user device. I prefer to revisit the flash-dependent services themselves, identify the SIP equivalent, and define the required behavior for a black-phone-like device to translate the familiar UI actions into the appropriate device-independent SIP signaling. Several SIPPING documents have shown the SIP equivalent for most such services (e.g., draft-ietf-sipping-cc-framework). Given flash-dependent service logic that varies from one place to another, my approach requires tailoring the SIP device behavior to the environment within which it is used. This can be a complication, which I will admit is avoided if we simply transmit a flash in SIP signaling. How much variation is there, really? There's a practical limit to what you can do with a flash, because it's an unavoidably ambiguous service request, and the user must remember, for a given service, a sequence of actions that may include multiple flashes and dialed codes. In North America, there are really very few services that are directly flash-dependent, and they're all easily translated by the device into standard SIP signaling. Rather than just assume that we'll always need to be able to send a flash to the server, it would be preferable to understand just how many and what flash-dependent services exist throughout the world, and how they should be done in SIP. I look forward to the results of the MSF investigation Tom has initiated. I already know the answer for North American services, but not for the rest of the world. On Nov 21, 2006, at 10:07 AM, Tom-PT Taylor wrote: I shuddered to see the concept of stimulus signalling in SIP in some of the test cases for our recent MultiService Forum interoperability event. The counter-argument I received is that there is a requirement for such signalling when black telephones sit behind a SIP-speaking IAD and the meaning of "flash" in a given context is held in service logic in an application server. I'll also mention that we are talking about logic that varies from country to country. At my instigation the MSF is investigating the requirements as they relate both to architecture and protocol selection. Paul Kyzivat wrote: Generally in sip you would expect the device to handle the hookflash locally (because it is a user interface issue), decide it is a request to transfer, and then initiate the transfer itself. So the hookflash need not be signaled remotely. Paul CheungJenny wrote: Hi, I have a question about "hookflash event transfer". Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, can hookflash be transfered using the same 3 methods? What I want to know is, if I hookflash, how does the peer gets to know this? Thanks. ------------------------------------------------------------------------ Windows Live Safety Center STHeiti~{N*Dz5D STHeiti~{K|JGCb7Q~} STHeiti~{5D#!~} < ------------------------------------------------------------------------ _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 --Apple-Mail-8--1008194823-- --===============1309498392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1309498392==-- From sipping-bounces@ietf.org Tue Nov 21 14:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbUy-0003CA-TA; Tue, 21 Nov 2006 14:41:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbUt-00031U-Iy for sipping@ietf.org; Tue, 21 Nov 2006 14:41:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbQ8-0007BY-HM for sipping@ietf.org; Tue, 21 Nov 2006 14:36:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 11:36:39 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kALJachY020830; Tue, 21 Nov 2006 14:36:38 -0500 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 kALJacDM014228; Tue, 21 Nov 2006 14:36:38 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:36:38 -0500 Received: from [161.44.79.184] ([161.44.79.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:36:38 -0500 Message-ID: <45635545.6080901@cisco.com> Date: Tue, 21 Nov 2006 14:36:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Robbins Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> In-Reply-To: Content-Type: text/plain; charset=HZ-GB-2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Nov 2006 19:36:38.0062 (UTC) FILETIME=[5C799CE0:01C70DA4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6707; t=1164137799; x=1165001799; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20how=20to=20transfer=20hookflash=20event, = 09e.g.=20in=20a=203-way=20conference=0A=20call? |Sender:=20 |To:=20David=20Robbins=20; bh=9Xg39DNUVyQk7YGiCBW1PThj6P1EXr6u9Cru08Tub6E=; b=oGv5WtnZ+JRB7FuM/2nJdVLiioMrZsyApa5AVfqCuMwH1aMDID+PXfUm+4VsUiEFks1tdjv9 Q3BRj3w+3Td7XtNaGubNnN+vif4aG182wHi1xcmNj4h2lzfql0bUPJpQ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sipping , Tom-PT Taylor X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I agree with David here. For the server to perform the multiple call rearrangement that is implied when processing the flash, the server must be aware of the multiple calls. If the calls are anchored in the device, then the server probably needs to be monitoring the digest event package, and then needs to loop instructions back to the device about what to do, which is very convoluted. More likely the server will then want to anchor the calls itself, acting as a B2BUA for all calls to the device. In effect you are then doing MGCP over SIP. Paul David Robbins wrote: > What bothers me about including "flash" signaling in SIP is that it > creates a device dependency that doesn't belong in SIP. It renders the > flash-dependent services inaccessible to devices other than black phones > (or devices with equivalent user interface capabilities), or else > requires devices to emulate the flash (or more generally, translate the > user's selection of a service into a sequence of low-level signaling > actions) in order to access such services. Services that involve > management of multiple calls (which are typically what flash is used > for, e.g., call waiting, three-way call, call transfer) are much better > managed in a SIP world by the device itself. SIP application servers > built by carrying over the PSTN legacy don't like to let the SIP device > do such things, but really, that's an artifact of PSTN legacy thinking. > If you want to emulate the PSTN in all of its details with a VoIP > protocol, choose MGCP or MEGACO, not SIP, for communication with the > end-user device. > > I prefer to revisit the flash-dependent services themselves, identify > the SIP equivalent, and define the required behavior for a > black-phone-like device to translate the familiar UI actions into the > appropriate device-independent SIP signaling. Several SIPPING documents > have shown the SIP equivalent for most such services (e.g., > draft-ietf-sipping-cc-framework). > > Given flash-dependent service logic that varies from one place to > another, my approach requires tailoring the SIP device behavior to the > environment within which it is used. This can be a complication, which I > will admit is avoided if we simply transmit a flash in SIP signaling. > How much variation is there, really? There's a practical limit to what > you can do with a flash, because it's an unavoidably ambiguous service > request, and the user must remember, for a given service, a sequence of > actions that may include multiple flashes and dialed codes. In North > America, there are really very few services that are directly > flash-dependent, and they're all easily translated by the device into > standard SIP signaling. > > Rather than just assume that we'll always need to be able to send a > flash to the server, it would be preferable to understand just how many > and what flash-dependent services exist throughout the world, and how > they should be done in SIP. I look forward to the results of the MSF > investigation Tom has initiated. I already know the answer for North > American services, but not for the rest of the world. > > On Nov 21, 2006, at 10:07 AM, Tom-PT Taylor wrote: > > I shuddered to see the concept of stimulus signalling in SIP in some of > the test cases for our recent MultiService Forum interoperability > event. > The counter-argument I received is that there is a requirement for such > signalling when black telephones sit behind a SIP-speaking IAD and the > meaning of "flash" in a given context is held in service logic in an > application server. I'll also mention that we are talking about logic > that varies from country to country. At my instigation the MSF is > investigating the requirements as they relate both to architecture and > protocol selection. > > Paul Kyzivat wrote: > > Generally in sip you would expect the device to handle the > hookflash > locally (because it is a user interface issue), decide it is a > request > to transfer, and then initiate the transfer itself. So the > hookflash > need not be signaled remotely. > > Paul > > CheungJenny wrote: > > Hi, > > I have a question about "hookflash event transfer". > Because DTMF signal can be transfered in 3 ways: INFO, > inband and AVT, > can hookflash be transfered using the same 3 methods? > What I want to know is, if I hookflash, how does the peer > gets to know this? > > Thanks. > > > ------------------------------------------------------------------------ > > Windows Live Safety Center ~{N*Dz5D ~{Nq!#~} ~{K|JGCb7Q~} > ~{5D#!~} > > > ------------------------------------------------------------------------ > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 15:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbru-0006u3-HD; Tue, 21 Nov 2006 15:05:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmbrs-0006tp-EK for sipping@ietf.org; Tue, 21 Nov 2006 15:05:20 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmbrr-0003NK-Ve for sipping@ietf.org; Tue, 21 Nov 2006 15:05:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kALK5Bg13638; Tue, 21 Nov 2006 15:05:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) Date: Tue, 21 Nov 2006 14:05:08 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711191A0C9@zrc2hxm2.corp.nortel.com> In-Reply-To: <00db01c70d8d$7dc300b0$3801a8c0@newportnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) Thread-Index: AccM2szOKjMS9BIAQVGQ1XRGMc9T2QAkwEVQAA2SlfA= From: "Brian Stucker" To: "Siddhartha Bhakta" , , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments below.=20 > -----Original Message----- > From: Siddhartha Bhakta=20 >=20 > Brain, Thanks. :) >=20 > Your proposal may simplify the Media server driven (early)=20 > media cases as UAC shall send another INVITE to create=20 > early-media or associated-media session. But we need to check=20 > whether basic purpose of early media shall be achieved by=20 > your proposal or not. Apology in advance, if I am asking some=20 > question which has been answered and concluded in past. >=20 > The early media in PSTN domain has following salient points, >=20 > a) A tone/indication to the Calling party to indicate=20 > that your call attempt is being honored by network. Call=20 > progress, Ringback tones are serving that purpose. Without=20 > those, caller shall disconnect the call. Send the calling party a 180 Ringing and have it generate local ringback (if necessary) ala RFC-3960. >=20 > b) Early media indicates whether voice path will be=20 > through once Called side shall answer. If user can not hear=20 > the ringback tone properly then typically Caller shall=20 > terminate the call. Therefore, Caller shall not have to pay=20 > for a call that does not have good > quality. This indicates that early media and regular media=20 > should use the > same media path(Soure RTP IP/port, Dest RTP IP/port). That=20 > was the main > reason why ringback tone were generated by Called side exchange. I'm not sure I followed all of that. I don't see how I'm degrading the quality of the call. The proposal allows multiplexing of media streams to the same SDP offered IP/port of the originator (RTP payload types are used to figure out which is which). If the PSTN gateway has something other than ringback to generate, it can use the proposal to setup a separate dialog for that early media if it desires. Keep in mind, that PSTN gateway generated early media is frequently broken when forking occurs as noted in RFC-3960 and elsewhere. It can't be fixed unless the protocol that you're interworking with can handle forking as well, which ISUP can't.=20 >=20 > c)The early media is not billed since it is there just=20 > to indicate whether media path shall be through while Called=20 > party shall answer. > Typically early media is shall be one-way (Called side to calling > side). Since early media is not billed, there is chance that=20 > people may > mis-use it. To avoid the misuse, early media was one-way. In=20 > SIP world the early media shall needs to be bothway just to=20 > avoid media clipping in NATed environment. The early-media=20 > shall be clipped for > discovering media NAT pinhole(who cares about early media=20 > clipping). But > this shall ensure that regular media shall not be clipped. I think there's a bit of confusion here. I don't view all media that arrives at the originator prior to the originator getting the 200 OK as "early media". To my mind, there are three basic types of media: - Early media: media that is generated by a device prior to a terminating device sending a 200 OK to the INVITE. - Transitional media: media that is generated after a terminating device has sent the 200 OK to the INVITE, but arrives at the originator before the 200 OK is received. - Final media: media that is generated after a terminating device has sent the 200 OK to the INVITE, and arrives at the originator after the 200 OK is received. I'm talking about deprecating early media, not transitional or final media. You have to send a 200 OK to send media and expect the originator to do anything with it. They might render it if they're feeling nice about it, but there's no guarantee that they're going to do anything with it but drop it on the floor. This is what we have, in effect, today. The difference is that I've given a way to create associated transitional/final media streams that may get rendered during the time period when "early media" would have been sent before. >=20 > If we forget about forking case then all the above points=20 > were complied by very simple SIP call flow. The 18x contains=20 > same SDP as that of 200 OK. This ensures that early media and=20 > regular media follow the same media path(point > b) above. > The point b) is very important from the NAT traversal point of view. > Otherwise, we shall experience the regular media clipping.=20 > The point c) was implemented quite easily as typically=20 > Application server starts billing on getting 200 OK of dialog=20 > initiating INVITE. I'm not following. I'm setting up separate calls for each media stream. I don't see how this complicates NAT traversal at all. You simply apply the same technique (perhaps utilizing knowledge gained during the setup of the original call, like gathering candidate addresses for ICE) to the associated call. I have yet to see an application server, or any server, that bills on SIP signaling. Proxies do, however, start accounting based off of SIP signaling. I think it's a trivial matter to craft the associated call URI sent back in the Alert-Info header from the main call to identify the media resource you wanted to contact, and have the accounting mechanism mark the record accordingly so that downstream billing processes treat this call as non-billable.=20 >=20 > In your architecture you have to make sure that you are=20 > ensuring point b) and point c). To satisfy the point b), your=20 > proposal shall have two dialogs with same Media path. Will=20 > that create any problem? If any SBC is between then two=20 > separate dialog shall have separate media paths. You will have separate media paths today, that's part of the problem. I'm not trying to solve end-to-end early media because it's my contention that there are very few (or none) applications that allow end-to-end early media to be heard anyhow. It's transitional and final media that you wind up with. Any early media getting generated by a some box in the middle of the signaling path is going to have a separate media path to the originator. >=20 > It shall quite difficult to satisfy the point c) in your=20 > proposal. You need to add some header, ext to indicate that a=20 > particular dialog is for early-media/associated-media only so=20 > that Application server does not bill it. Nope. They look at where the URI routes to. You can fake out headers. If the call is routing to a media server in the network to play "Mary Had a Little Lamb" for the originator, then the network can mark the accounting record accordingly. Besides, accounting is out of scope of our specifications (but not outside of the design). >=20 > But I thought, the original intention was to take care early=20 > media in case of forking. I don't think we have proposed any=20 > proper solution to take care of that. The early media is=20 > broken in case forking if SIP user does not have the=20 > conferencing ability(in that case, it can put all the early=20 > dialogs in conference). So, let it be broken. It is fixed. The originator can contact each forked leg for their early media in turn.=20 >=20 > Can we introduce some SIP header or extension to indicate=20 > that a particular dialog is a forked dialog so that Called=20 > party does not initiate early media? > Let the calling side to play local ringtone for forking case=20 > as per the local policy as specified in RFC3960. If SIP user=20 > have the conferencing ability and wants to do the=20 > conferencing of all early media then it may indicate so in=20 > the new SIP header or extension. ??? No conferencing ability is necessary. I think you've missed my point. >=20 > In summery, I am suggesting two things, > 1. Deprecation of Application Server Model and > 2. Avoid (inband) early media in case of forking if Calling user > does not have the ability to do conferencing of early media. >=20 > Any comment on this? I am proposing deprecation of early media, period. Everything else falls out from there. >=20 >=20 > Thanks & Regards, > Siddhartha >=20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: 20 November 2006 19:34 > To: Siddhartha Bhakta; pkyzivat@cisco.com; Francois Audet > Cc: sipping@ietf.org > Subject: Deprication of Early Media (was RE: [Sipping] A Test=20 > Balloon For AS generated Early Media: EMIND) >=20 >=20 > << out the mailing list buffer>>> >=20 >=20 > Thanks for going through the proposal Siddhartha. I have had to keep > going back to make sure that I'm not restating RFC-3959 as I've gone > through this process. I also had at one point (if you go looking for > earlier incarnations of my early media draft you'll see this) thought > about marking up the SDP. There's some problems with this around a > proxy's ability to manipulate message bodies. > =20 > You did prompt me to try to simplify my thinking some more... > =20 > What I've done is essentially depricated early media. There's=20 > just media > now. Some of it may get played while another call is being setup. The > UAC gets back places that it may wish to contact (and some=20 > extra help in > knowing what the intended ordering was) to play or contact another > endpoint while an associated call is being established. The=20 > RTP payload > magic is just an extra little helper to know when to switch=20 > back to the > original call without suffering from clipping. > =20 > Early media is broken. It will always be broken. So let's get=20 > rid of it > and have 'associated media'. Essentially media that is related to > another call, but is a different priority. I think we could also use > this general model for other purposes, such as music on hold, or > periodic announcements during a call (ie. a tone that plays every so > often to denote some account balance remaining, etc). I'm=20 > sure there are > others (or will be). > =20 > This keeps the model much simpler. Every media stream should=20 > be signaled > separately. I'm not suggesting that we depricate forking, but=20 > instead to > not expect any media to necessarily be rendered prior to=20 > answer which is > what RFC-3261 says, but not what RFC-3960 intimates at times.=20 > Just that > we should get the guy in the middle out of the end-to-end SDP > negotiations. > =20 > I think this is a much more powerful architecture, and one that lets > everyone involved on both ends of the media stream know what=20 > the status > of that stream is at either end without having to introduce > complications into the basic call setup flow. > =20 > Regards, > Brian >=20 >=20 >=20 >=20 > --------------- > This e-mail may contain confidential and/or privileged=20 > information. If you are not the intended recipient (or have=20 > received this e-mail in error) please notify the sender=20 > immediately and delete this e-mail. Any unauthorized copying,=20 > disclosure or distribution of the contents in this e-mail is=20 > strictly forbidden. > --------------- >=20 >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 16:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmd7R-0005JX-6g; Tue, 21 Nov 2006 16:25:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmd7P-0005JA-Kh for sipping@ietf.org; Tue, 21 Nov 2006 16:25:27 -0500 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmd7N-0007vs-BN for sipping@ietf.org; Tue, 21 Nov 2006 16:25:27 -0500 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id kALLPP6S007899 for ; Tue, 21 Nov 2006 16:25:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Nov 2006 16:25:24 -0500 Message-ID: <6B3E29721F78364AA2C43697AFB15D91278603@sonusmail07.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3264 (SDP Offer/Answer) Interpretation Question Thread-Index: AccNs4685VHzIqGqQTmQrfIqWAZyvQ== From: "Gardell, Steven" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org =20 3264 allows the answer to include codecs that were not in the offer. Is the offering side allowed to select an un-offered codec from the answer list without a subsequent offer? The specification does not=20 seem to expressly prohibit this, but it seems to violate the whole=20 notion of "offer/answer" which is modeled on information being present=20 in both the offer and the answer. It also seems at odds with a couple of parenthetical remarks in this same document Steven Gardell GSX SIP Development=20 sgardell@sonusnet.com=20 t +1 978 614 8831=20 f +1 978 614 8101=20 250 Apollo Drive=20 Chelmsford, MA=20 01824 USA=20 www.sonusnet.com =09 Deliver the Future First with Sonus Networks. Disclaimer: Content provided is for information purposes only and is subject to change without notice. Sonus has no obligation or commitment to develop or deliver any future release, upgrade, feature, enhancement or function described in this email or any attachment or presentation except as specifically set forth in a written agreement.=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 17:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gme3R-0007y5-Fk; Tue, 21 Nov 2006 17:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gme3P-0007y0-ON for sipping@ietf.org; Tue, 21 Nov 2006 17:25:23 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gme3M-0002PG-U5 for sipping@ietf.org; Tue, 21 Nov 2006 17:25:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kALMI6b14594; Tue, 21 Nov 2006 17:18:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question Date: Tue, 21 Nov 2006 16:25:06 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711191A31B@zrc2hxm2.corp.nortel.com> In-Reply-To: <6B3E29721F78364AA2C43697AFB15D91278603@sonusmail07.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question Thread-Index: AccNs4685VHzIqGqQTmQrfIqWAZyvQABmqLg From: "Brian Stucker" To: "Gardell, Steven" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Short answer seems to be yes, but only with the understanding that the codecs for the media stream must therefore by assymetric. Only the set intersection between the SDP offer and answer can be used by the answerer for generating media. The additional codecs in the answer cannot be used by the answerer because the offerer didn't offer them (and therefore there's no agreement or expectation that they'll be rendered; ever). This is mentioned in section 6.1 of RFC-3264. Section 7 does allow the offerer to send using any codec included in the SDP answer for any accepted stream. So, from a strict reading of RFC-3264, the following example can be constructed: - The offerer can send SDP with G.711 listed for an audio stream. - The answerer can reply with SDP that includes G.711 and G.729 for the same audio stream, accepting that media stream. - The answerer can only send G.711 on that stream, but the offerer can send G.711 or G.729 at its discretion. I don't think this breaks the offer answer model. The answerer is in essence offering another codec back to the answerer and the offerer is answering it by using it. It's just not doing it through another formal SDP exchange. In practice, I doubt this is used much. I'd postulate that it may be a bug in the spec except that it's explicitly mentioned in the text in section 6. Doesn't seem to break anything. Regards, Brian > -----Original Message----- > From: Gardell, Steven [mailto:sgardell@sonusnet.com]=20 > Sent: Tuesday, November 21, 2006 3:25 PM > To: sipping@ietf.org > Subject: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question >=20 > =20 > 3264 allows the answer to include codecs that were not in the offer. > Is the offering side allowed to select an un-offered codec=20 > from the answer list without a subsequent offer? The=20 > specification does not seem to expressly prohibit this, but=20 > it seems to violate the whole notion of "offer/answer" which=20 > is modeled on information being present in both the offer and=20 > the answer. It also seems at odds with a couple of=20 > parenthetical remarks in this same document >=20 >=20 > Steven Gardell > GSX SIP Development > sgardell@sonusnet.com=20 >=20 > t +1 978 614 8831 > f +1 978 614 8101 > 250 Apollo Drive > Chelmsford, MA > 01824 USA > www.sonusnet.com > =09 > Deliver the Future First with Sonus Networks. > Disclaimer: Content provided is for information purposes only=20 > and is subject to change without notice. Sonus has no=20 > obligation or commitment to develop or deliver any future=20 > release, upgrade, feature, enhancement or function described=20 > in this email or any attachment or presentation except as=20 > specifically set forth in a written agreement.=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 23:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjPi-00067u-B0; Tue, 21 Nov 2006 23:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjPh-00067o-89 for sipping@ietf.org; Tue, 21 Nov 2006 23:08:45 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmjPg-0003Va-0J for sipping@ietf.org; Tue, 21 Nov 2006 23:08:45 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20061122040842m14001eqihe>; Wed, 22 Nov 2006 04:08:43 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAM48f5K010356 for ; Tue, 21 Nov 2006 23:08:41 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAM48fHH010352; Tue, 21 Nov 2006 23:08:41 -0500 Date: Tue, 21 Nov 2006 23:08:41 -0500 Message-Id: <200611220408.kAM48fHH010352@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45631625.7010205@nortel.com> (taylor@nortel.com) Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: "Tom-PT Taylor" The counter-argument I received is that there is a requirement for such signalling when black telephones sit behind a SIP-speaking IAD and the meaning of "flash" in a given context is held in service logic in an application server. It may not be pretty, but it's already standardized: RFC 2833 3.10 DTMF Events Table 1 summarizes the DTMF-related named events within the telephone-event payload format. Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16 Table 1: DTMF named events Dale _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 21 23:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjzF-0002Is-OZ; Tue, 21 Nov 2006 23:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjzE-0002Gd-1S for sipping@ietf.org; Tue, 21 Nov 2006 23:45:28 -0500 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmjvD-000586-4K for sipping@ietf.org; Tue, 21 Nov 2006 23:41:20 -0500 Received: from [192.168.1.3] ([141.157.187.97]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J94006067OMIKW6@vms040.mailsrvcs.net> for sipping@ietf.org; Tue, 21 Nov 2006 22:41:10 -0600 (CST) Date: Tue, 21 Nov 2006 23:40:53 -0500 From: David Robbins Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? In-reply-to: <200611220408.kAM48fHH010352@dragon.ariadne.com> To: Dale.Worley@comcast.net Message-id: MIME-version: 1.0 (Apple Message framework v624) X-Mailer: Apple Mail (2.624) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> <200611220408.kAM48fHH010352@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org (I agree, it's not pretty.) This, of course, transmits the flash in the media stream, not in the SIP signaling. Works if and only if the app server gets the media stream, which is not generally what SIP app servers want to do. This does remind me that in this way SIP can be a device-level protocol: just use an INVITE to set up a media stream between device and app server, and do everything else as RFC 2833 events and ordinary audio in the media stream. Gets SIP pretty much completely out of the way, but you can still claim you're using SIP. :-) (I have seen a situation where this actually makes sense, but it's not an ordinary use of SIP.) On Nov 21, 2006, at 11:08 PM, Dale.Worley@comcast.net wrote: > From: "Tom-PT Taylor" > > The counter-argument I received is that there is a requirement for > such > signalling when black telephones sit behind a SIP-speaking IAD and > the > meaning of "flash" in a given context is held in service logic in an > application server. > > It may not be pretty, but it's already standardized: > > RFC 2833 > > 3.10 DTMF Events > > Table 1 summarizes the DTMF-related named events within the > telephone-event payload format. > > Event encoding (decimal) > _________________________ > 0--9 0--9 > * 10 > # 11 > A--D 12--15 > Flash 16 > > Table 1: DTMF named events > > Dale > > _______________________________________________ > 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 > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 00:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmka2-0002BE-H3; Wed, 22 Nov 2006 00:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmka1-00027i-Am for sipping@ietf.org; Wed, 22 Nov 2006 00:23:29 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmka0-0004c3-45 for sipping@ietf.org; Wed, 22 Nov 2006 00:23:29 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20061122052327b1200muev4e>; Wed, 22 Nov 2006 05:23:27 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kAM5NQ5K015816 for ; Wed, 22 Nov 2006 00:23:26 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kAM5NQMg015812; Wed, 22 Nov 2006 00:23:26 -0500 Date: Wed, 22 Nov 2006 00:23:26 -0500 Message-Id: <200611220523.kAM5NQMg015812@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: (robbins.dave@verizon.net) Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> <200611220408.kAM48fHH010352@dragon.ariadne.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: David Robbins (I agree, it's not pretty.) This, of course, transmits the flash in the media stream, not in the SIP signaling. Works if and only if the app server gets the media stream, which is not generally what SIP app servers want to do. OTOH, if the application server is not functioning as a B2BUA (and thus getting the media), can it really do the call-control actions that people have been talking about as the goal? I suppose you could put some sort of indication in an INFO request. But these things get ugly fast. How do you implement 3-way calling without the UA being fully aware that that is what is going on? Other than with an application server that is a full B2BUA? Dale _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 05:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpAk-0007Lc-BS; Wed, 22 Nov 2006 05:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmpAi-0007LW-9L for sipping@ietf.org; Wed, 22 Nov 2006 05:17:40 -0500 Received: from sea02-fw01.citel.com ([205.234.66.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmpAe-0004CQ-SA for sipping@ietf.org; Wed, 22 Nov 2006 05:17:40 -0500 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-fw01.citel.com with smtp (Exim 4.43) id 1GmpAa-0000mV-C0; Wed, 22 Nov 2006 02:17:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes Date: Wed, 22 Nov 2006 02:17:31 -0800 Message-ID: <76431CABEC5EED489807DB8AEBCCA0BC5D3A9F@sea02-mxc01.citel.com> In-Reply-To: <1163712845.4597.25.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] SIP Subscription for SCADA/Stock quotes Thread-Index: AccNq4RAK2uH7yZ8TF2ATVz+mBFTOwAb/8+g From: "Michael Procter" To: "Benjamin Carlyle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Comments inline: Benjamin Carlyle wrote: > * There is no obvious way to subscribe to a HTTP resource. Subscriptions > are sent to the combination of a SIP url and event package identifier. This is true. A SIP SUBSCRIBE subscribes to a SIP resource. > * Proxies are used for transport through firewall-intensive networks, > but do not participate in the subscription. A restful architecture is > constrained to support layering, whereby muliple clients who share a > proxy might enjoy a multicasting effect through the proxy This is also true. But proxies in SIP have a different role to those in HTTP. State Agents may be a closer fit to this requirement, which I discuss later in this email. > * Data flow is limited by explicit timers. In a SCADA or stock quote > system old data degrades rapidly in value with time, and the objective > is to get as close as possible to immediate notifications. The maximum > notification rate should be related to available bandwidth, or at worst > to network latency I don't agree. Notification rate is to be defined by the event package in question. Since you haven't defined an event package yet, this is open to some flexibility. > * Subscriptions are refreshed individually at a client-specified rate. > In a SCADA environment we are likely to have thousands of subscriptions > active between a client and server. The client-specified rate may be > used as a keep-alive so that the client can detect server death and > recreate its subscriptions on another cluster member. I believe it is > better for the client to send exactly no renewals. Keep-alive should be > sent from the server only, and at a long reliable rate when no data has > been transmitted over the subscription during the keep-alive interval. Actually, the client specifies the maximum duration that it can support, but the server determines the interval used. Ranges for durations can be defined in the event package (see RFC3265 Sec 4.4.4), so you can pick suitable ones for your application. > Before I started my quest for an appropriate protocol, I wrote up a > strawman which may be viewed here: > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt I glanced through this document, and picked up on your list of desirable characteristics: Summarisation. This is the organised discarding of older information to ensure that slow clients recieve as much fresh data as their connection characteristics permit. Differential flow control. A slow client should not prevent fast ones from getting updates. Localised resynchronisation. A client need not reach back to the origin server for the current resource status if its immediate server is already handling the subscription. Patch updates. For large resources (especially lists), the ability to deliver a message that indicates the change from last time, only. Not the whole state. Dial-back. Pub/Sub can be an amplifier of denial of service attacks. The subscription mechanism must be able to detect when its notifications are being treated as spam and end the subscription. The third item in particular suggests to me that you might benefit from inserting a layer of State Agents (RFC3265 Sec 4.4.11) between your clients and servers. The servers can PUBLISH their data to the State Agents, which accept subscriptions from your clients. This ensures that your servers are not troubled by subscription refreshes, and that clients can obtain the latest information from the State Agents rather than the servers directly. =20 The other items can be dealt with in the event package itself, and have no direct bearing on RFC3265. There are, of course, other benefits and complications associated with this approach, but you need to weigh up whether it is appropriate for your application. Regards, Michael Procter _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 09:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmt4l-0005pO-Gh; Wed, 22 Nov 2006 09:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmt4k-0005pD-8h for sipping@ietf.org; Wed, 22 Nov 2006 09:27:46 -0500 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmt4f-0007R7-Qc for sipping@ietf.org; Wed, 22 Nov 2006 09:27:46 -0500 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id kAMERaaA032442; Wed, 22 Nov 2006 09:27:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Date: Wed, 22 Nov 2006 09:27:36 -0500 Message-ID: <6B3E29721F78364AA2C43697AFB15D9127860C@sonusmail07.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Comments on draft-ietf-sipping-config-framework-09 Thread-Index: AccJ9o4+qtyYP90VS4uyxYqh1KeirAAY85uAAPnd19A= From: "Gardell, Steven" To: "Sumanth Channabasappa" , "David Robbins" , "sipping" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Has there been any discussion of using this framework for configuring Gateway behavior? (In other words for configuring the moral equivalent of Cisco Dial peer's) In a large network managing these on a per-device basis can become quite burdensome, so some centralized mechanism is desirable. On one hand, the specification seems flexible enough to allow this, on the other hand it seems to be beyond the intent. -----Original Message----- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Friday, November 17, 2006 10:17 AM To: David Robbins; sipping Subject: RE: [Sipping] Comments on draft-ietf-sipping-config-framework-09 David, As per the ad-hoc discussions that happened at the last IETF, we have quite a few organizations interested in this approach. Speaking personally, the CableLabs PacketCable PACM framework utilizes this. The public specifications are available at: http://www.packetcable.com , for your reference. This effort was the collective result of various organizations. The efforts in PACM looked at various approaches and found that a SIP based configuration framework in conjunction with XCAP made the most sense (details in the specifications or I can take it offline). As indicated by a few others, it would be nice to complete this effort in the best possible manner (sooner than later). Thanks! - S -----Original Message----- From: David Robbins [mailto:robbins.dave@verizon.net] Sent: Thursday, November 16, 2006 8:09 PM To: sipping Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-09 This framework has been around for a while, and I'm curious as to how much acceptance it is receiving in the industry. Can anybody on this list comment on the extent to which SIP device vendors have adopted it or are planning on adopting it? Some of you may be aware that in the subset of the industry that pays attention to the DSL Forum, TR-104 in conjunction with TR-69 is getting some traction for SIP device management, including configuration. Is the IETF SIP configuration framework getting comparable traction? My company has adopted the IETF framework, for one project, roughly as it was defined in mid-2005 (but without the merging behavior, whose issues many of you have noted). Will we see wider adoption of this framework? Is there a broad constituency for this framework, whether simplified or complexified? On Nov 6, 2006, at 9:57 AM, Henning Schulzrinne wrote: > I think this is a good example of a draft that gets less useful by=20 > having been around for many, many years. As years and IETF meetings=20 > accumulate, more and more stuff gets added, without any real=20 > indication that there is a constituency for them. Nobody seems to be=20 > paying much attention to the draft, so there's little pushback on=20 > feature creep. > > Just as for consent and in SIMPLE, I think it's time to step back and=20 > see if we can't get 90% of the benefit with 10% of the effort, and=20 > maybe scoping the problem so that other features can be added later,=20 > if there is demonstrated demand for them. Unfortunately, this draft=20 > has become a posterchild on why people consider SIP to be far too=20 > complex. > > I had said this before, but I'll repeat that I still find the merging=20 > stuff far too messy and unpredictable to be useful. (It is difficult=20 > for any of the parties to know what exactly happened in the end,=20 > making debugging and troubleshooting difficult.) A simple alternative=20 > is to designate parameters for each role and only allow certain=20 > entities to set them. > > The old saying went that a draft isn't finished until there's nothing=20 > left to take out. I don't think we've even tried to have this=20 > discussion. > > Henning > > On Nov 6, 2006, at 12:19 AM, EKR wrote: > >> $Id: draft-ietf-sipping-config-framework-09-rev.txt,v 1.2 2006/10/25 >> 18:52:13 ekr Exp $ >> >> I'm fairly naive about SIP UAs and configuration, but this document=20 >> strikes me as an extremely complex approach to what's really a fairly >> simple problem. As I understand the problem space from reading the=20 >> draft, there are four main use cases: >> >> (1) Plug a naive (out of the box) SIP UA into a network and have >> it "just work" like a POTS UA does with no additional=20 >> configuration >> provided. >> (2) Have a user be able to provide some identifying information >> about a SIP UA (E.g., the MAC address) to some management >> console and then have the UA be able to configure itself. >> Arguably this is a subcase of (1). >> (3) Have a user be able to register with some SIP service provider >> via some undefined out-of-band mechanism and have that service >> provider give them a URL and some authentication credentials >> which they can feed to their UA and their UA can use to get >> configured. >> (4) Have a user be able to take a preconfigured SIP UA to a new >> network environment and get the new network access information >> (e.g., a hotel proxy) while retaining the original configuration >> information (the AOR, keying material, etc.) >> >> Arguably, something based on this document could do this job--though=20 >> note that this document alone cannot because it doesn't actually=20 >> specify any of the relevant parameters--but it's not clear that all=20 >> near the complexity in this protocol is required. In >> particular: >> >> - I don't see why it's necessary to have three tiers of configuration >> data (local network, device, and user) which must somehow be merged. >> In the first three cases, ISTM that you really only have one tier >> and in the fourth there is only some very limited set of=20 >> well-defined >> information, namely the local proxy. It's not like you want a >> hotel proxy to even be able to specify what you should be using >> as your SIP AOR! >> >> - Multiple mechanisms for profile retrieval. As I understand 8.4, a UA >> can get its profile either via SIP or via an external reference >> in a NOTIFY. Let's keep life simple. >> >> - The mechanisms for discovering the URI seem extremely complicated. >> Currently, there are different mechanisms for each of the three >> URI types. If we collapse this down to a single type then is >> there some reason we can't use the SIP DHCP option? >> >> -Ekr >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 11:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmuyy-0003SS-Sf; Wed, 22 Nov 2006 11:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmuyw-0003SF-IO for sipping@ietf.org; Wed, 22 Nov 2006 11:29:54 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmuyu-0007ZT-6p for sipping@ietf.org; Wed, 22 Nov 2006 11:29:54 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAMGTnX17436; Wed, 22 Nov 2006 11:29:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Wed, 22 Nov 2006 10:29:43 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> In-Reply-To: <200611220523.kAM5NQMg015812@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Thread-Index: AccN9rwe37AfJnnDTZqXeC0F8Op8sQAV5M0w From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Ugh. 2833... IMHO-- Sending media/2833 to an application server makes it no longer an application server, but an application gateway. For instance, a PSTN gateway is an application gateway (access to the PSTN being the application in question). We really shouldn't be fixated on the fact that it's a flash event. It's an event at the UA that occurs during mid-call. It may not even need to be signaled to another node in the network. For instance, the client may be able to locally manage the two calls and hitting the hookflash button on the device tells the client to swap the set of media streams being rendered. So looking at this that way... There's two events in a 3-way conference. The first event is to tell the UA that you want to make a second call without ending the first one (first hook-flash). That should be a local UA event (meaning nothing goes to a SIP server in the network). This event occurs mid-call in the first call. And typically causes the first call to be placed on hold while the second call is being established. The second event is to join the two calls together. This event occurs mid-call in the second call (the second hook-flash). If the UA is able to do local conferencing, then this should also be a local event to the UA: hey UA, start conferencing the two media streams. In this case the UA simply takes the first call off hold and starts conferencing packets. If the UA is relying on a network conference server to handle the conferencing, then the second hook-flash can be used to contact the conference server, get a conference token, and then REFER the two call legs to the conference server with the token in the Refer-To URI. The two calls to be conferenced are now both on hold until the conference is established. Now everyone is talking to the conference server to get the media mixed. The original two calls are dropped, and each UA involved in the conference only have SIP sessions setup with the conference server. If you need to know at the conferencing server that this was a '3-way' call feature invocation, that can be included in the original conference URI. Here's the server flow: Party A Party B Party C Conference | | | | | | | | |---INVITE (b)--------------->| | | |<--200 OK--------------------| | | |---ACK---------------------->| | | | | | | (flash) | | | | | | | |---INVITE (b), [HOLD SDP]--->| | | |<--200 OK--------------------| | | |---ACK---------------------->| | | | | | | |---------INVITE (c)--------------------------->| | |<--------200 OK -------------------------------| | |---------ACK---------------------------------->| | | | | | (flash) | | | |---------INVITE (c), [HOLD SDP]--------------->| | |<--------200 OK -------------------------------| | |---------ACK---------------------------------->| | | | | | |------------INVITE (conf@...)----------------------------------------------->| |<-----200 OK, Contact:sip:conf@...;token...----------------------------------| |------------ACK-------------------------------------------------------- ----->| | | | | |---REFER (conf@...;token)--->| | | |<--202-----------------------| | | |---REFER (conf@...;token)--------------------->| | |<--202-----------------------------------------| | | | | | | |----------INVITE (conf@...;token...)---------->| | |<-------200 OK---------------------------------| | |--------ACK----------------------------------->| | | |-INVITE (conf@...;token...)->| | | |<--------200 OK--------------| | | |---------ACK---------------->| | | | | |<----NOTIFY (a), [200 OK]----| | | |-----200 OK----------------->| | | |-----BYE (b)---------------->| | | |<----200 OK------------------| | | | | | | |<----------------------NOTIFY (a), [200 OK]----| | |-----------------------200 OK----------------->| | |-----------------------BYE (c)---------------->| | |<----------------------200 OK------------------| | | | | | | | | | Regards, Brian > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Tuesday, November 21, 2006 11:23 PM > To: sipping@ietf.org > Subject: Re: [Sipping] how to transfer hookflash event, e.g.=20 > in a 3-way conference call? >=20 > From: David Robbins >=20 > (I agree, it's not pretty.) This, of course, transmits the=20 > flash in the=20 > media stream, not in the SIP signaling. Works if and only=20 > if the app=20 > server gets the media stream, which is not generally what SIP app=20 > servers want to do. >=20 > OTOH, if the application server is not functioning as a B2BUA=20 > (and thus getting the media), can it really do the=20 > call-control actions that people have been talking about as the goal? >=20 > I suppose you could put some sort of indication in an INFO request. >=20 > But these things get ugly fast. How do you implement 3-way=20 > calling without the UA being fully aware that that is what is=20 > going on? Other than with an application server that is a full B2BUA? >=20 > Dale >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 13:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx6f-0000X6-Dc; Wed, 22 Nov 2006 13:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx6d-0000Wj-MJ for sipping@ietf.org; Wed, 22 Nov 2006 13:45:59 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmx6c-000378-BD for sipping@ietf.org; Wed, 22 Nov 2006 13:45:59 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kAMIjeiq006085; Wed, 22 Nov 2006 12:45:53 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 12:45:49 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 19:45:47 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Question on SIP RFC implementation status X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Nov 2006 19:45:46 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180846AE8@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Question on SIP RFC implementation status Thread-Index: AccMpz2NLW5sPovhRAas2o91ObbHYQBvsYuw From: "Drage, Keith \(Keith\)" To: "Darshan Bildikar" , "sipping" X-OriginalArrivalTime: 22 Nov 2006 18:45:47.0541 (UTC) FILETIME=[6CA2CC50:01C70E66] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org After each SIPIT, Robert Sparks gives a report on the SIP list of the number of implementations of various features presented for test. You should be able to find the previous versions in the archives of the SIP list. The last report was sent on 25th October 2006. Alternatively contact Robert Sparks directly. Regards Keith > -----Original Message----- > From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 > Sent: 20 November 2006 13:25 > To: 'sipping' > Subject: [Sipping] Question on SIP RFC implementation status >=20 > List, >=20 > I am not sure if this is the right forum to ask this=20 > question. Apologies in advance if it is not! >=20 > I was wondering if there is a repository that indicates what=20 > vendors have implemented a particular SIP RFC=20 > (SIPPING/SIMPLE/XCON/MMUSIC too!)=20 >=20 >=20 > This would:- >=20 > 1) Provide a good mechanism to gauge the acceptance of a=20 > particular RFC in the industry.=20 > 2) Help in pushing the case for implementation of a=20 > particular RFC if it were to be shown that there was already=20 > considerable industry support. This is of course in addition=20 > to the actual benefit of implementing the RFC itself! > 3) Help IOT initiatives! >=20 > I am aware that some of this info could be confidential but=20 > even some basic info would help! >=20 > Appreciate any pointers in the right direction >=20 > Darshan >=20 > Human beings, who are almost unique in having the ability to=20 > learn from the experience of others, are also remarkable for=20 > their apparent disinclination to do so >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 14:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxNe-0004J3-Ao; Wed, 22 Nov 2006 14:03:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxNc-0004Bm-KZ for sipping@ietf.org; Wed, 22 Nov 2006 14:03:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxNa-0005G7-Rm for sipping@ietf.org; Wed, 22 Nov 2006 14:03:32 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2006 11:03:29 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAMJ3TLi024044; Wed, 22 Nov 2006 14:03:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAMJ3SYP020599; Wed, 22 Nov 2006 14:03:29 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:03:23 -0500 Received: from [10.82.241.108] ([10.82.241.108]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:03:22 -0500 Message-ID: <45649EF9.8070808@cisco.com> Date: Wed, 22 Nov 2006 14:03:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2006 19:03:22.0487 (UTC) FILETIME=[E16EC870:01C70E68] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8324; t=1164222209; x=1165086209; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20how=20to=20transfer=20hookflash=20event, = 09e.g.=20in=20a=203-way=20conference=0A=20call? |Sender:=20 |To:=20Brian=20Stucker=20; bh=i55+HX58k3+ZL/lsTFMr+u8EU0shJ+3qzcZhvq813Lc=; b=tylJ1eB0YuASwe8BwIoa9ahzBBurfH26kClys651nPG/DjnJzEN9bTElK3TlPt1YkixmpGcA kUGbom7Zd0GuTLPW/A/FjvaVo7lVH/SL4N3AtxUxK8yzqbYr9tuaCoOz; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org After having worked on this a bit, I began to see what the issue is: SIP assumes that the devices are a lot smarter than "traditional" devices were, and expects them to carry out features that previously had been carried out in the network. And that is fine if the feature implementation can be self contained in the device. That depends on the device being smart enough, which is easy, and that it have enough UI to manage and control the features. But consider a black phone adapter. Regardless of how smart it is, its UI is limited to that black phone. So it has DTMF and audio to work with as its UI. And its unlikely to be able to do a whole lot of good audio synthesis. Also, there is some expectation about how features should work on such a device. Generally they are expected to be invoked with star codes, and some of them may have audio feedback of various sorts. Still, some features, such as transfer, can be done in the device. Others still require an in-network implementation, and some might need cooperation with some support in the device and some in the network. This is all possible, but it complicates the implementation, and it especially complicates the configuration of the device: - which interactions are handled locally - which are handled remotely? and how are they invoked? - which have local and remote components? How are the remote components identified and accessed? In the end this becomes a complicated distributed application implementation. It is certainly doable, but the bar for doing it is high, and those of us working on sip specs aren't helping much with it. So its not too surprising that some may just want to throw in the towel and go for an implementation that puts all the smarts in the network and makes the devices dumb. In that way the implementation can be similar to what has been done before, and it depends only on the lowest common denominator capability from the devices. The configuration framework is a step towards solving this problem, but only a step. Paul Brian Stucker wrote: > Ugh. 2833... > > IMHO-- Sending media/2833 to an application server makes it no longer an > application server, but an application gateway. For instance, a PSTN > gateway is an application gateway (access to the PSTN being the > application in question). > > We really shouldn't be fixated on the fact that it's a flash event. It's > an event at the UA that occurs during mid-call. It may not even need to > be signaled to another node in the network. For instance, the client may > be able to locally manage the two calls and hitting the hookflash button > on the device tells the client to swap the set of media streams being > rendered. > > So looking at this that way... > > There's two events in a 3-way conference. The first event is to tell the > UA that you want to make a second call without ending the first one > (first hook-flash). That should be a local UA event (meaning nothing > goes to a SIP server in the network). This event occurs mid-call in the > first call. And typically causes the first call to be placed on hold > while the second call is being established. > > The second event is to join the two calls together. This event occurs > mid-call in the second call (the second hook-flash). If the UA is able > to do local conferencing, then this should also be a local event to the > UA: hey UA, start conferencing the two media streams. In this case the > UA simply takes the first call off hold and starts conferencing packets. > > If the UA is relying on a network conference server to handle the > conferencing, then the second hook-flash can be used to contact the > conference server, get a conference token, and then REFER the two call > legs to the conference server with the token in the Refer-To URI. The > two calls to be conferenced are now both on hold until the conference is > established. > > Now everyone is talking to the conference server to get the media mixed. > The original two calls are dropped, and each UA involved in the > conference only have SIP sessions setup with the conference server. If > you need to know at the conferencing server that this was a '3-way' call > feature invocation, that can be included in the original conference URI. > > Here's the server flow: > > Party A Party B Party C > Conference > | | | > | > | | | > | > |---INVITE (b)--------------->| | > | > |<--200 OK--------------------| | > | > |---ACK---------------------->| | > | > | | | > | > (flash) | | > | > | | | > | > |---INVITE (b), [HOLD SDP]--->| | > | > |<--200 OK--------------------| | > | > |---ACK---------------------->| | > | > | | | > | > |---------INVITE (c)--------------------------->| > | > |<--------200 OK -------------------------------| > | > |---------ACK---------------------------------->| > | > | | | > | > (flash) | | > | > |---------INVITE (c), [HOLD SDP]--------------->| > | > |<--------200 OK -------------------------------| > | > |---------ACK---------------------------------->| > | > | | | > | > |------------INVITE > (conf@...)----------------------------------------------->| > |<-----200 OK, > Contact:sip:conf@...;token...----------------------------------| > |------------ACK-------------------------------------------------------- > ----->| > | | | > | > |---REFER (conf@...;token)--->| | > | > |<--202-----------------------| | > | > |---REFER (conf@...;token)--------------------->| > | > |<--202-----------------------------------------| > | > | | | > | > | |----------INVITE > (conf@...;token...)---------->| > | |<-------200 > OK---------------------------------| > | > |--------ACK----------------------------------->| > | | |-INVITE > (conf@...;token...)->| > | | > |<--------200 OK--------------| > | | > |---------ACK---------------->| > | | | > | > |<----NOTIFY (a), [200 OK]----| | > | > |-----200 OK----------------->| | > | > |-----BYE (b)---------------->| | > | > |<----200 OK------------------| | > | > | | | > | > |<----------------------NOTIFY (a), [200 OK]----| > | > |-----------------------200 OK----------------->| > | > |-----------------------BYE (c)---------------->| > | > |<----------------------200 OK------------------| > | > | | | > | > | | | > | > > > Regards, > Brian > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Tuesday, November 21, 2006 11:23 PM >> To: sipping@ietf.org >> Subject: Re: [Sipping] how to transfer hookflash event, e.g. >> in a 3-way conference call? >> >> From: David Robbins >> >> (I agree, it's not pretty.) This, of course, transmits the >> flash in the >> media stream, not in the SIP signaling. Works if and only >> if the app >> server gets the media stream, which is not generally what SIP app >> servers want to do. >> >> OTOH, if the application server is not functioning as a B2BUA >> (and thus getting the media), can it really do the >> call-control actions that people have been talking about as the goal? >> >> I suppose you could put some sort of indication in an INFO request. >> >> But these things get ugly fast. How do you implement 3-way >> calling without the UA being fully aware that that is what is >> going on? Other than with an application server that is a full B2BUA? >> >> Dale >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 > _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 22 21:24:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4Ej-0000Zg-IC; Wed, 22 Nov 2006 21:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn4Eh-0000YF-DH for sipping@ietf.org; Wed, 22 Nov 2006 21:22:47 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.ygnition.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn4Ef-0000a1-VB for sipping@ietf.org; Wed, 22 Nov 2006 21:22:47 -0500 Received: from SSPRUNK (ip25.post-vineyard.dfw.ygnition.net [24.219.179.25]) by ns2.ygnition.com (8.13.6/8.13.5) with SMTP id kAN2MeoD025995; Wed, 22 Nov 2006 21:22:42 -0500 Message-ID: <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> From: "Stephen Sprunk" To: "Paul Kyzivat" , "Brian Stucker" References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> <45649EF9.8070808@cisco.com> Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Wed, 22 Nov 2006 20:02:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Thus spake "Paul Kyzivat" > After having worked on this a bit, I began to see what the issue is: > > SIP assumes that the devices are a lot smarter than "traditional" > devices were, and expects them to carry out features that previously > had been carried out in the network. And that is fine if the feature > implementation can be self contained in the device. That depends on > the device being smart enough, which is easy, and that it have enough > UI to manage and control the features. SIP takes a lot of horsepower to do correctly. The extra cycles needed to translate a hookflash into some sort of REFER, NOTIFY, or INVITE message disappear in the noise. > But consider a black phone adapter. Unfortunately, I've run into this request from customers even on high-end GUI phones. I've had a few nearly fail us on acceptance testing because we don't use flash for hold/transfer/conference -- and we have both softkeys _and_ hardkeys for those functions! > Regardless of how smart it is, its UI is limited to that black phone. > So it has DTMF and audio to work with as its UI. And its unlikely to > be able to do a whole lot of good audio synthesis. Also, there is some > expectation about how features should work on such a device. Generally > they are expected to be invoked with star codes, and some of them may > have audio feedback of various sorts. Star codes do not require device support in any but a few cases* I've encountered. At most, an ATA needs to support complex digit maps to determine when to play dial tone(s) or complete the call. Other than that, you usually just need the ability to send an INVITE to the star-coded number and let the proxy/b2bua figure out what to do with it. [*] e.g. I've dealt with one system where if you use a star code to park a call, the system needs to return back the orbit number it got parked on, since it may be different than the one the user requested (if any). > Still, some features, such as transfer, can be done in the device. > Others still require an in-network implementation, and some might need > cooperation with some support in the device and some in the network. What examples of hookflash uses require network support to emulate? The only one I can think of is a really dumb device that can't do local conferencing, but the device should still be able to figure out a conference is desired and request it via a real SIP message (e.g. NOTIFY or reINVITE). If you're stuck with really, really dumb devices, particularly ones that are trying to emulate POTS service, it's probably better to go with MGCP or Megaco than SIP. Let's not mess up SIP by overlaying antiquated hookflash signalling, no matter how tempting it may be. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 00:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn6hZ-0008VO-Re; Thu, 23 Nov 2006 00:00:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn6hY-0008VJ-8d for sipping@ietf.org; Thu, 23 Nov 2006 00:00:44 -0500 Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn6hW-0005h3-Fd for sipping@ietf.org; Thu, 23 Nov 2006 00:00:44 -0500 Received: from [192.168.1.2] ([151.199.53.165]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J96000MJ38KBKYA@vms048.mailsrvcs.net> for sipping@ietf.org; Wed, 22 Nov 2006 23:00:21 -0600 (CST) Date: Thu, 23 Nov 2006 00:00:04 -0500 From: David Robbins Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? In-reply-to: <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> To: "Stephen Sprunk" Message-id: <33edf0b0b45f28de644d8265b4107259@verizon.net> MIME-version: 1.0 (Apple Message framework v624) X-Mailer: Apple Mail (2.624) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> <45649EF9.8070808@cisco.com> <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This has been an interesting discussion, and though we may be beating it to death now, it will surely come up again. Remarks inline ... On Nov 22, 2006, at 9:02 PM, Stephen Sprunk wrote: > Thus spake "Paul Kyzivat" >> After having worked on this a bit, I began to see what the issue is: >> >> SIP assumes that the devices are a lot smarter than "traditional" >> devices were, and expects them to carry out features that previously >> had been carried out in the network. And that is fine if the feature >> implementation can be self contained in the device. That depends on >> the device being smart enough, which is easy, and that it have enough >> UI to manage and control the features. > > SIP takes a lot of horsepower to do correctly. The extra cycles > needed to translate a hookflash into some sort of REFER, NOTIFY, or > INVITE message disappear in the noise. Amen! If a SIP device has sufficient resources (processor, memory, signal processing) to do SIP correctly, it has enough to do many interesting features locally. But nobody will be surprised that I still hear people claim that it's too big a burden for a SIP device to do these features (as recently as last week). >> But consider a black phone adapter. > > Unfortunately, I've run into this request from customers even on > high-end GUI phones. I've had a few nearly fail us on acceptance > testing because we don't use flash for hold/transfer/conference -- and > we have both softkeys _and_ hardkeys for those functions! > >> Regardless of how smart it is, its UI is limited to that black phone. >> So it has DTMF and audio to work with as its UI. And its unlikely to >> be able to do a whole lot of good audio synthesis. Also, there is >> some expectation about how features should work on such a device. >> Generally they are expected to be invoked with star codes, and some >> of them may have audio feedback of various sorts. > > Star codes do not require device support in any but a few cases* I've > encountered. At most, an ATA needs to support complex digit maps to > determine when to play dial tone(s) or complete the call. Other than > that, you usually just need the ability to send an INVITE to the > star-coded number and let the proxy/b2bua figure out what to do with > it. > > [*] e.g. I've dealt with one system where if you use a star code to > park a call, the system needs to return back the orbit number it got > parked on, since it may be different than the one the user requested > (if any). Whether a black phone or a SIP phone with the same UI, it is the highly constrained UI that dictates the implementation of features in terms of flashes, star codes, audio prompts, and additional dialing. Such implementations are effective only to the extent that users can remember the magic incantation -- I daresay that few, if any, black phone users could perform more than a very few of all the available features without looking at the cheat sheet. My experience supports your claim that device support is required in only a few cases. Most features can look like simple calls to the device, with a server handling the subsequent user interaction. The few features that are directly based on the flash can and should be handled entirely by the device. Of all the PSTN features (of which, depending upon how you count them, there are nearly 100, several hundred, or several thousand), there are about a dozen that really, really should be done on the device. Many more could be done on the device, but can also reasonably be done in a server. This is particularly so when the device in question is a single-line black phone or equivalent. More sophisticated devices, supporting multiple lines and having a richer UI (e.g., buttons, lamps, and a display) can impose more requirements for communication and coordination between device and server. >> Still, some features, such as transfer, can be done in the device. >> Others still require an in-network implementation, and some might >> need cooperation with some support in the device and some in the >> network. > > What examples of hookflash uses require network support to emulate? > The only one I can think of is a really dumb device that can't do > local conferencing, but the device should still be able to figure out > a conference is desired and request it via a real SIP message (e.g. > NOTIFY or reINVITE). I know of no flash-based feature that requires network support to emulate. But I make a distinction between a feature that is directly based on flash (e.g., call waiting, three-way call, transfer, hold) and a feature that is indirectly based on flash (e.g., most features invoked mid-call are invoked by what looks to the device like the beginning of a three-way call sequence, but do not otherwise require coordination between device and server). As you (and Brian earlier in this thread) point out, if you have a device with insufficient signal processing resources or network bandwidth to do local conferencing, there are well-defined SIP procedures for the device to manage a conference using network conferencing resources. > If you're stuck with really, really dumb devices, particularly ones > that are trying to emulate POTS service, it's probably better to go > with MGCP or Megaco than SIP. Let's not mess up SIP by overlaying > antiquated hookflash signalling, no matter how tempting it may be. Agreed. With a little imagination, we can map the interesting features into SIP by utilizing the resources available at the device and the server and distributing functions between the two in a manner that maintains SIP's device independence. I believe that I've done exactly that for a project I'm currently working on. (And I have encountered some resistance to the idea that SIP devices aren't dumb.) > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > 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 > > Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 03:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9Wd-0007hf-4d; Thu, 23 Nov 2006 03:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn9Wb-0007hV-DZ for sipping@ietf.org; Thu, 23 Nov 2006 03:01:37 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn9WZ-0007RA-Nc for sipping@ietf.org; Thu, 23 Nov 2006 03:01:37 -0500 Received: (qmail 8235 invoked by uid 0); 23 Nov 2006 08:01:17 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 Nov 2006 08:01:17 -0000 Message-ID: <002201c70ed5$9701d0d0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "Brian Stucker" References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> <45649EF9.8070808@cisco.com> Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Thu, 23 Nov 2006 09:01:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org So in summary, the answer to the original question would be: don't "transfer" the event, but interpret/convert it to the SIP mechanism that is defined for the feature you are implementing (assuming there is an analog POTS device with naught but hook flashes and DTMF to do signalling / feature activation, and some kind of edge device that converts this into SIP). Does this "put the intelligence in the network"? Regards, Jeroen Paul Kyzivat wrote: > After having worked on this a bit, I began to see what the issue is: > > SIP assumes that the devices are a lot smarter than "traditional" > devices were, and expects them to carry out features that previously > had been carried out in the network. And that is fine if the feature > implementation can be self contained in the device. That depends on > the device being smart enough, which is easy, and that it have enough > UI to manage and control the features. > > But consider a black phone adapter. Regardless of how smart it is, its > UI is limited to that black phone. So it has DTMF and audio to work > with as its UI. And its unlikely to be able to do a whole lot of good > audio synthesis. Also, there is some expectation about how features > should work on such a device. Generally they are expected to be > invoked with star codes, and some of them may have audio feedback of > various sorts. > Still, some features, such as transfer, can be done in the device. > Others still require an in-network implementation, and some might need > cooperation with some support in the device and some in the network. > > This is all possible, but it complicates the implementation, and it > especially complicates the configuration of the device: > - which interactions are handled locally > - which are handled remotely? and how are they invoked? > - which have local and remote components? How are the > remote components identified and accessed? > > In the end this becomes a complicated distributed application > implementation. It is certainly doable, but the bar for doing it is > high, and those of us working on sip specs aren't helping much with > it. > So its not too surprising that some may just want to throw in the > towel and go for an implementation that puts all the smarts in the > network and makes the devices dumb. In that way the implementation > can be similar to what has been done before, and it depends only on > the lowest common denominator capability from the devices. > > The configuration framework is a step towards solving this problem, > but only a step. > > Paul > > Brian Stucker wrote: >> Ugh. 2833... >> >> IMHO-- Sending media/2833 to an application server makes it no >> longer an application server, but an application gateway. For >> instance, a PSTN gateway is an application gateway (access to the >> PSTN being the application in question). >> >> We really shouldn't be fixated on the fact that it's a flash event. >> It's an event at the UA that occurs during mid-call. It may not even >> need to be signaled to another node in the network. For instance, >> the client may be able to locally manage the two calls and hitting >> the hookflash button on the device tells the client to swap the set >> of media streams being rendered. >> >> So looking at this that way... >> >> There's two events in a 3-way conference. The first event is to tell >> the UA that you want to make a second call without ending the first >> one (first hook-flash). That should be a local UA event (meaning >> nothing goes to a SIP server in the network). This event occurs >> mid-call in the first call. And typically causes the first call to >> be placed on hold while the second call is being established. >> >> The second event is to join the two calls together. This event occurs >> mid-call in the second call (the second hook-flash). If the UA is >> able to do local conferencing, then this should also be a local >> event to the UA: hey UA, start conferencing the two media streams. >> In this case the UA simply takes the first call off hold and starts >> conferencing packets. If the UA is relying on a network conference server >> to handle the >> conferencing, then the second hook-flash can be used to contact the >> conference server, get a conference token, and then REFER the two >> call legs to the conference server with the token in the Refer-To >> URI. The two calls to be conferenced are now both on hold until the >> conference is established. >> >> Now everyone is talking to the conference server to get the media >> mixed. The original two calls are dropped, and each UA involved in >> the conference only have SIP sessions setup with the conference >> server. If you need to know at the conferencing server that this was >> a '3-way' call feature invocation, that can be included in the >> original conference URI. Here's the server flow: >> >> Party A Party B Party C >> Conference >>>>> >>> >>>>> >>> >>> ---INVITE (b)--------------->| | >>> >>> <--200 OK--------------------| | >>> >>> ---ACK---------------------->| | >>> >>>>> >>> >> (flash) | | >>> >>>>> >>> >>> ---INVITE (b), [HOLD SDP]--->| | >>> >>> <--200 OK--------------------| | >>> >>> ---ACK---------------------->| | >>> >>>>> >>> >>> ---------INVITE (c)--------------------------->| >>> >>> <--------200 OK -------------------------------| >>> >>> ---------ACK---------------------------------->| >>> >>>>> >>> >> (flash) | | >>> >>> ---------INVITE (c), [HOLD SDP]--------------->| >>> >>> <--------200 OK -------------------------------| >>> >>> ---------ACK---------------------------------->| >>> >>>>> >>> >>> ------------INVITE >> (conf@...)----------------------------------------------->| >>> <-----200 OK, >> Contact:sip:conf@...;token...----------------------------------| >>> ------------ACK-------------------------------------------------------- >>> ----->| >>>>> >>> >>> ---REFER (conf@...;token)--->| | >>> >>> <--202-----------------------| | >>> >>> ---REFER (conf@...;token)--------------------->| >>> >>> <--202-----------------------------------------| >>> >>>>> >>> >>>> ----------INVITE >> (conf@...;token...)---------->| >>>> <-------200 >> OK---------------------------------| >>> >>> --------ACK----------------------------------->| >>>>> -INVITE >> (conf@...;token...)->| >>>> >>> <--------200 OK--------------| >>>> >>> ---------ACK---------------->| >>>>> >>> >>> <----NOTIFY (a), [200 OK]----| | >>> >>> -----200 OK----------------->| | >>> >>> -----BYE (b)---------------->| | >>> >>> <----200 OK------------------| | >>> >>>>> >>> >>> <----------------------NOTIFY (a), [200 OK]----| >>> >>> -----------------------200 OK----------------->| >>> >>> -----------------------BYE (c)---------------->| >>> >>> <----------------------200 OK------------------| >>> >>>>> >>> >>>>> >>> >> >> >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Sent: Tuesday, November 21, 2006 11:23 PM >>> To: sipping@ietf.org >>> Subject: Re: [Sipping] how to transfer hookflash event, e.g. >>> in a 3-way conference call? >>> >>> From: David Robbins >>> >>> (I agree, it's not pretty.) This, of course, transmits the >>> flash in the >>> media stream, not in the SIP signaling. Works if and only >>> if the app >>> server gets the media stream, which is not generally what SIP app >>> servers want to do. >>> >>> OTOH, if the application server is not functioning as a B2BUA >>> (and thus getting the media), can it really do the >>> call-control actions that people have been talking about as the >>> goal? I suppose you could put some sort of indication in an INFO >>> request. >>> >>> But these things get ugly fast. How do you implement 3-way >>> calling without the UA being fully aware that that is what is >>> going on? Other than with an application server that is a full >>> B2BUA? Dale >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 03:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA48-0000WT-Rb; Thu, 23 Nov 2006 03:36:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnA47-0000VK-Az for sipping@ietf.org; Thu, 23 Nov 2006 03:36:15 -0500 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn9zG-00038q-1D for sipping@ietf.org; Thu, 23 Nov 2006 03:31:20 -0500 Received: from Inbox ([89.205.141.237]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0J9600JR6CZDAY70@jes-fe2.zx.nl> for sipping@ietf.org; Thu, 23 Nov 2006 09:30:58 +0100 (CET) Date: Thu, 23 Nov 2006 09:30:51 +0100 From: Jeroen Van Bemmel Subject: RE: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? To: Paul Kyzivat , Brian Stucker Message-id: <0J9600JR7CZFAY70@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Alternatively, the answer could also be: have an application server subscri= be to the KPML event package, and have the edge device convert hook flashes= to NOTIFYs. Then the AS can interpret them. This model may be appropriate = when interpretation of the flashes is complex and requires coordination. Not 100% IETF, but... Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Jeroen van Bemmel" Aan: "Paul Kyzivat" ; "Brian Stucker" CC: sipping@ietf.org Verzonden: 23-11-06 09:01 Onderwerp: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way c= onference call? So in summary, the answer to the original question would be: don't=20 "transfer" the event, but interpret/convert it to the SIP mechanism that is= =20 defined for the feature you are implementing (assuming there is an analog=20 POTS device with naught but hook flashes and DTMF to do signalling / featur= e=20 activation, and some kind of edge device that converts this into SIP). Does= =20 this "put the intelligence in the network"? Regards, Jeroen Paul Kyzivat wrote: > After having worked on this a bit, I began to see what the issue is: > > SIP assumes that the devices are a lot smarter than "traditional" > devices were, and expects them to carry out features that previously > had been carried out in the network. And that is fine if the feature > implementation can be self contained in the device. That depends on > the device being smart enough, which is easy, and that it have enough > UI to manage and control the features. > > But consider a black phone adapter. Regardless of how smart it is, its > UI is limited to that black phone. So it has DTMF and audio to work > with as its UI. And its unlikely to be able to do a whole lot of good > audio synthesis. Also, there is some expectation about how features > should work on such a device. Generally they are expected to be > invoked with star codes, and some of them may have audio feedback of _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 06:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCcf-0002dl-Cg; Thu, 23 Nov 2006 06:20:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCcd-0002ci-9F for sipping@ietf.org; Thu, 23 Nov 2006 06:20:03 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCbQ-0005o8-Tv for sipping@ietf.org; Thu, 23 Nov 2006 06:18:50 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kANBIjeR016273; Thu, 23 Nov 2006 12:18:45 +0100 In-Reply-To: <0J9600JR7CZFAY70@jes-fe2.zx.nl> Subject: RE: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? To: Jeroen Van Bemmel X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Rudi.Van_Tilburg@alcatel.be Date: Thu, 23 Nov 2006 12:18:39 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/23/2006 12:18:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Paul Kyzivat , dirk.de_gelder@alcatel.be, sipping@ietf.org, Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Jeroen, Your correct indeed - What puzzles me however is that you state - Not 100% IETF. If I remember well it was pushed to introduce in the kpml event package the "reporting of the Recall Event" exactly for the purpose you mention below. Refer to ftp://ftp.rfc-editor.org/in-notes/rfc4730.txt (Eric Burger) (Became an official RFC this month ;-) ) The CPE suppliers should of course follow ;-) Kind Regards, Rudi van Jeroen Van Bemmel To: Paul Kyzivat , Brian Stucker Subject: RE: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? 23/11/2006 09:30 Alternatively, the answer could also be: have an application server subscribe to the KPML event package, and have the edge device convert hook flashes to NOTIFYs. Then the AS can interpret them. This model may be appropriate when interpretation of the flashes is complex and requires coordination. Not 100% IETF, but... Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Jeroen van Bemmel" Aan: "Paul Kyzivat" ; "Brian Stucker" CC: sipping@ietf.org Verzonden: 23-11-06 09:01 Onderwerp: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? So in summary, the answer to the original question would be: don't "transfer" the event, but interpret/convert it to the SIP mechanism that is defined for the feature you are implementing (assuming there is an analog POTS device with naught but hook flashes and DTMF to do signalling / feature activation, and some kind of edge device that converts this into SIP). Does this "put the intelligence in the network"? Regards, Jeroen Paul Kyzivat wrote: > After having worked on this a bit, I began to see what the issue is: > > SIP assumes that the devices are a lot smarter than "traditional" > devices were, and expects them to carry out features that previously > had been carried out in the network. And that is fine if the feature > implementation can be self contained in the device. That depends on > the device being smart enough, which is easy, and that it have enough > UI to manage and control the features. > > But consider a black phone adapter. Regardless of how smart it is, its > UI is limited to that black phone. So it has DTMF and audio to work > with as its UI. And its unlikely to be able to do a whole lot of good > audio synthesis. Also, there is some expectation about how features > should work on such a device. Generally they are expected to be > invoked with star codes, and some of them may have audio feedback of _______________________________________________ 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 _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 12:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIn2-0001BW-9b; Thu, 23 Nov 2006 12:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIn0-0001BH-27 for sipping@ietf.org; Thu, 23 Nov 2006 12:55:10 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnImy-0008B1-FR for sipping@ietf.org; Thu, 23 Nov 2006 12:55:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2006 09:55:08 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kANHt7wF021660; Thu, 23 Nov 2006 09:55:07 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kANHt7W4029439; Thu, 23 Nov 2006 09:55:07 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 09:55:06 -0800 Received: from [10.0.34.15] ([10.21.97.93]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 09:55:06 -0800 In-Reply-To: <455A7C54.1070201@cisco.com> References: <455A7C54.1070201@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28C739C9-4751-4E88-BC75-14B498B6C851@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Date: Thu, 23 Nov 2006 12:55:07 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Nov 2006 17:55:06.0572 (UTC) FILETIME=[827D80C0:01C70F28] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6291; t=1164304507; x=1165168507; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sipping]=20Re=3A=20draft-rosenberg-sipping-overload- reqs=20recovery |Sender:=20; bh=f3kvHOczuhzgqvCB9WfmjBXHOjtI1dBJ6VNLvMLOnsQ=; b=BEmcqMUtkz+Rb6jcYJhz2mE7LyVWCYCpWs7vxNFnH1BRtqeVo3EccrrINvBmxNTTfHWQ5L1O kVMXuqDZCzHATnSq0tgiMy4WtHghcQiK2v53QVpg3AiGIRvLWc6zhgEk; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Volker Hilt , Albrecht.Schwarz@alcatel.de, sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org That captures what I was trying to say - thanks. I can see how people would say this is an obvious implicit requirement and does not need mentioning but I have been involved with some, uh, systems that failed this requirement. On Nov 14, 2006, at 9:32 PM, Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > The overload mechanism should ensure that the > system remains stable. When the offered load drops from above the > overall capacity of the network to below the overall capacity, the > throughput should stabilize and become equal to the offered load. > > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and >> overload >> protection mechanism (for network elements and networks targeting >> high >> system and/or service availability). >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround >> signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement >> from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> - Albrecht >> >> >> Volker >> Hilt >> >> > >> bs.com> cc: sipping >> >> Subject: Re: >> [Sipping] Re: draft-rosenberg-sipping-overload-reqs >> recovery 08.11.2006 >> 17:18 >> >> >> I think that stability of overload >> control is an important requirement. >> We certainly want to avoid building something that starts to >> oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> Volker >> Cullen Jennings wrote: >>> Clearly this was a long way from the text for a requirement but, >>> yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to >>> express this >>> as a requirement that is useful, I can certainly live with not >>> adding it. >>> >>> The reason I think it is a requirement is I can easily imagine >>> that the >>> mechanism for doing overload push-back causes the systems to fail >>> in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops >>>>> back >>>>> to an incoming call rate of 80cps. The question is, how long >>>>> before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems >>>> like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think >>>>> one of >>>>> the design goals is that it is at least possible to build to >>>>> systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) >>>> 952-5050 >>>> http://www.jdrosen.net PHONE: (973) >>>> 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ 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 From sipping-bounces@ietf.org Thu Nov 23 15:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKsY-000742-1t; Thu, 23 Nov 2006 15:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnKsW-0006v3-0G; Thu, 23 Nov 2006 15:09:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnKp5-0002kA-Eg; Thu, 23 Nov 2006 15:05:28 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2006 12:05:26 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kANK5Qqm016415; Thu, 23 Nov 2006 12:05:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kANK5Qio016476; Thu, 23 Nov 2006 12:05:26 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:05:26 -0800 Received: from [10.0.34.15] ([10.21.98.32]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 12:05:25 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sipping , SIP From: Cullen Jennings Date: Thu, 23 Nov 2006 15:05:36 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Nov 2006 20:05:25.0924 (UTC) FILETIME=[B72FEE40:01C70F3A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=117; t=1164312326; x=1165176326; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Scheduling=20of=20Friday=20morning=20at=20next=20IETF |Sender:=20; bh=jmy2GsHNUjs+yVMHh5xAdxejiDMtzeTpH7n16S0GxAQ=; b=qsZgBa6hvhrp7i5XNhYYjkNnehntOwHgQ+j0zafire2J3RFCELI2UmCr5R9geYnEuIxyOp0F tnEHtdxPWeLBnFxSNc7qogCCScmbpWQnLBmSeTRAbZJuVpfNjnw/OFpH; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [Sipping] Scheduling of Friday morning at next IETF X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org If you are planning travel, there odds are good that there will be a sipping meeting Friday morning in Prague. _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 24 01:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnUy6-0005sp-1i; Fri, 24 Nov 2006 01:55:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnUy5-0005sk-0O for sipping@ietf.org; Fri, 24 Nov 2006 01:55:25 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnUxw-0002Xj-Dk for sipping@ietf.org; Fri, 24 Nov 2006 01:55:24 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71070D15; Fri, 24 Nov 2006 07:55:05 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 07:55:05 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 07:55:04 +0100 Received: from [131.160.36.17] (EH3I2003TGFCPET-131160036017.lmf.ericsson.se [131.160.36.17]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E060D236E; Fri, 24 Nov 2006 08:55:04 +0200 (EET) Message-ID: <45669748.902@ericsson.com> Date: Fri, 24 Nov 2006 08:55:04 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2006 06:55:04.0876 (UTC) FILETIME=[7873FEC0:01C70F95] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Mary Barnes , ejzak@lucent.com Subject: [Sipping] Requesting the publication of draft-ejzak-sipping-p-em-auth-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi, as discussed in our last face-to-face meeting in San Diego, we will be requesting the publication of the following draft shortly: http://www.ietf.org/internet-drafts/draft-ejzak-sipping-p-em-auth-02.txt If somebody has any last-minute comments, please let us know. Cheers, Gonzalo SIPPING co-chair _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 24 18:13:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnkCI-0001t7-Dq; Fri, 24 Nov 2006 18:11:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnkCG-0001t1-SW for sipping@ietf.org; Fri, 24 Nov 2006 18:11:04 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnkCF-0002Jz-It for sipping@ietf.org; Fri, 24 Nov 2006 18:11:04 -0500 Received: from [10.10.16.45] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAOMEsLD006195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Nov 2006 16:14:54 -0600 In-Reply-To: References: <4563083F.6020108@cisco.com> <45631625.7010205@nortel.com> <200611220408.kAM48fHH010352@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4973E00C-8D19-4A1E-87E3-C937B04BA02F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Fri, 24 Nov 2006 17:10:54 -0600 To: David Robbins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Nov 21, 2006, at 10:40 PM, David Robbins wrote: > (I agree, it's not pretty.) This, of course, transmits the flash in > the media stream, not in the SIP signaling. Works if and only if > the app server gets the media stream, which is not generally what > SIP app servers want to do. > This is the line of reasoning that led us to develop "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)" as documented in RFC 4730. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Fri Nov 24 18:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnkGD-0002yq-LP; Fri, 24 Nov 2006 18:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnkGC-0002yc-8X for sipping@ietf.org; Fri, 24 Nov 2006 18:15:08 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnkG9-0003wN-V4 for sipping@ietf.org; Fri, 24 Nov 2006 18:15:08 -0500 Received: from [10.10.16.45] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kAOMIvxB006217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Nov 2006 16:18:57 -0600 In-Reply-To: <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> <45649EF9.8070808@cisco.com> <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? Date: Fri, 24 Nov 2006 17:14:58 -0600 To: Stephen Sprunk X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Paul Kyzivat , sipping@ietf.org, Brian Stucker X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org > Unfortunately, I've run into this request from customers even on > high-end GUI phones. I've had a few nearly fail us on acceptance > testing because we don't use flash for hold/transfer/conference -- > and we have both softkeys _and_ hardkeys for those functions! I understand that customers initially demanded auxiliary handcranks for cars that were designed with electric starters. Eventually, they got over it. -- Dean _______________________________________________ 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 From sipping-bounces@ietf.org Sat Nov 25 17:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go5hR-0000Xp-D2; Sat, 25 Nov 2006 17:08:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go5hQ-0000Vf-0B for sipping@ietf.org; Sat, 25 Nov 2006 17:08:40 -0500 Received: from web8703.mail.in.yahoo.com ([203.84.221.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Go5hM-0002fy-9a for sipping@ietf.org; Sat, 25 Nov 2006 17:08:39 -0500 Received: (qmail 70206 invoked by uid 60001); 25 Nov 2006 22:08:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eX8Iw6y9A665/bjeOS3RJWY+VseDozdO0sw0zbg9naCbpz2xyZU1mO+reQEB32NxHUg+1EiVOqg+eyg0ToL8EP094YSSTx6Ei85sfMk5V8CDLs4yrT7QA9dPXb9/Uuqoy336d6Q3kjQKQTmxk6Rdvjmfj+YH1Vu5v6rOf8OeitE= ; Message-ID: <20061125220819.70204.qmail@web8703.mail.in.yahoo.com> Received: from [172.200.109.47] by web8703.mail.in.yahoo.com via HTTP; Sat, 25 Nov 2006 22:08:19 GMT Date: Sat, 25 Nov 2006 22:08:19 +0000 (GMT) From: Siddhartha Bhakta Subject: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND) To: Brian Stucker , pkyzivat@cisco.com, audet@nortel.com In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371117C5268@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brian, The forking works fine with Local Ringback tone. New proposal is only needed to make early media work for forking. Most of the SIP deployments are quite happy with Local Ringback or Call progress tone. Therefore UA may go ahead with Local Ringback tone under forked condition if in-band early media is not absolutely necessary. For forking condition if UAS wants to play early media (i.e., in-band call progress tone) then only they have to go ahead with your proposal or RFC3959. The problem today is that UAS can not know whether some incoming call is forked or not therefore it don't know for sure whether it has a (safe) choice of going with traditional in-band early-media or not. I am talking about the choice because Application server model (RFC3959) or your proposal may seems difficult for UAC to implement. Your proposal is definitely simpler than Application server due to that fact Application server introduces multiple media sessions for a single SIP dialog. The B2BUA in between or UAs may find it difficult to implement. Your proposal introduces multiple sessions and dialogs for a single call. UAC may look for choice of not implementing it as they need media mixing capability to implement your proposal. Here is my proposal that gives the fare choice depending on the situation: a)The UAC those have the ability to implement your proposal (i.e., associated-media) shall indicate Content-Disposition: associated-media b)The forking proxy or B2BUA shall add a SIP header namely 'forked' when it is forking When INVITE reaches to UAS, depending on these two parameters it can make the choice. Case1: Content-Disposition: associated-media and forked header UAS may specify URL/URN (in 18x) of the media server if it wants to feed in-band tone, music etc. UAS may also send 18x without SDP and it must not send early media packet as this is forked call. Case2:Content-Disposition: associated-media and non-forked UAS may specify URL/URN for the media server in 18x UAS may send 18x with SDP and may start sending in-band early media UAS may send 18x without SDP Case3: No associated-media support and forked UAS MUST send 18x without SDP. Even if UAS wants to play early media, it MUST not do so as it is forking call. Case4: No associated-media support and non-forked UAS may send 18x with SDP and may start sending in-band early media UAS may send 18x without SDP Any comments? PS: In my last email, I was describing the objective of early of PSTN domain to check how much SIP domain is fulfilling it. I was doing that since early-media concept is inherited from PSTN domain. The objectives are the a)call progess indication, b)Early indication of the voice channel and c)no billing for early media. I do agree with you that in SIP domain, end to end early media is not quite common therefore b) objective is hardly met. if we definitely solve the billing problem then I think your proposal is giving a powerful architecture. It will simplyfy early-media flow for non-forking case also. __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ 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 From sipping-bounces@ietf.org Sun Nov 26 02:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoE8i-0002mK-4D; Sun, 26 Nov 2006 02:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoE8g-0002jQ-RV for sipping@ietf.org; Sun, 26 Nov 2006 02:09:22 -0500 Received: from mail29.syd.optusnet.com.au ([211.29.132.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoE8c-0005i4-Jx for sipping@ietf.org; Sun, 26 Nov 2006 02:09:22 -0500 Received: from c210-49-37-63.rochd2.qld.optusnet.com.au (c210-49-37-63.rochd2.qld.optusnet.com.au [210.49.37.63]) by mail29.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kAQ78wsv008298; Sun, 26 Nov 2006 18:08:59 +1100 Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes From: Benjamin Carlyle To: Brian Stucker In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111820913@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437111820913@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Date: Sun, 26 Nov 2006 17:08:56 +1000 Message-Id: <1164524937.4820.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: MichaelProcter , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Sorry to all of you whose replies I originally missed. They were filed in a different mail folder than I had expected. So at the moment I'm still looking at SIP as a possible way to transfer notifications that a resource has changed. I am also still considering trying to push a cut-down version of my own draft somewhere. What do you guys think? To achieve a SIP-based version I think I would need: * An event package that allows a http resource to be specified somehow * A way to locate the appropriate SIP url to send the SUBSCRIBE request to * Either to follow along the current NOTIFY+partial NOTIFY path that SIP seems to be taking, or look at how to mirror the EXPIRE approach from my draft * Better understand state agents, and how/whether they could be used to layer subscriptions for transparent proxying and scalability * Better understand how a state agent with bounded buffers can participate in the subscription. Can they summarise, do they need unbounded buffers, do they refuse new messages until slow clients catch up, do they unsubscribe slow clients, or is the event package completely responsible for defining their behaviour? * Better understand the Rate of notifications section of rfc3265. Can I design an event package that sets the rate at "all available bandwidth" without harming the SIP network? My cut-down draft (EXPIRE only, no NOTIFY/PATCHNOTIFY support) is accessable here: http://soundadvice.id.au/blog/draft-carlyle-sena-01.txt More in-line. On Thu, 2006-11-16 at 19:03 -0600, Brian Stucker wrote: > Ben, you may wish to take a look at some of the scaling work out of the > SIMPLE WG around presence. Although the service involved is different, I > think you will find some useful information and mechanisms for your > problem. Thanks, I'll take a look. Is this technical report the main place to look? My quick first impressions of the TR for my use cases: RLS is similar to something I've thought about in the past, and might minimise keep-alive traffic when a large number of subscriptions are made to a real or apparent small set of servers. The resource lists do have to be built up on the server-side, though, limiting the application of this techinque for ad hoc subscriptions. Partial PUBLISH and NOTIFY are approaches I have listed in my draft as particularly useful when synchronising list content. There is some tension between partial notification support and summarisation by state agents (proxies in my draft). The systems I work with are built fundamentally not to melt down under extreme change rates relative to the rate at which changes can be processed. This means that state agents have a bounded (often no more than 1-space) buffer size allocated for each subscription, and that something needs to happen when that buffer limit is hit. My approach is to follow Rohit Khare's model from his paper on Decentralizing REST: To summarise. This means that the state agent may be discarding content or even rewriting it to preserve as much information as possible while reducing the number of bytes in a lossy stream compression. Building a security model around this may be impossible, so my draft probably has to drop it for use in insecure environments. I hadn't fully come to terms with the place of state agents in SIP subscription. Can they be layered transparently to users in a similar way to HTTP proxies? For example, could an ISP run a state agent that aggregates subscriptions to all of its users... or could a corporation set up a state agent at each of its offices? > > > rfc3265 indicates that it is not a general purpose subscription > > > mechanism. Specific weaknesses I see include > > > * There is no obvious way to subscribe to a HTTP resource. > > Subscriptions > > > are sent to the combination of a SIP url and event package > > identifier. > > We can transport different URL schemes over SIP network e.g. > > Tel, URN etc, It will require enhancements to current PUBLISH etc. > The point of that statement in 3265 and elsewhere is not to limit the > URL schemes that can be used, but to point out that there are many ways > of pushing data around a network. The intent of the framework wasn't to > solve world-event-subscription-hunger. There was a lot of discussion at > the time around using (PUBLISH in particular) for all sorts of things > and we wanted to constrain the problem space so we could finish off the > RFC sometime in our lifetime. I'm not sure I understand this. Can I specify a http url somehow as the target for my subscription under SIP's rfc3265? I thought that the url had to be a sip one, and that the event package did the rest. Are we talking about a parameter being applied to the event package? > > > * Subscriptions are refreshed individually at a > > client-specified rate. > > > In a SCADA environment we are likely to have thousands of > > subscriptions > > > active between a client and server. The client-specified > > rate may be > > > used as a keep-alive so that the client can detect server death and > > > recreate its subscriptions on another cluster member. I > > believe it is > > > better for the client to send exactly no renewals. Keep-alive should > > be > > > sent from the server only, and at a long reliable rate when no data > > has > > > been transmitted over the subscription during the > > keep-alive interval. > ... > RFC-3265 does not have a server-initiated refresh mechanism because the > server handling the subscriptions should be spending it's time handling > incoming subscription requests, generating notifications, and processing > the events that trigger notification. A typical 3265 server > implementation will not, for instance, have a timer running for the > duration of a subscription. It may simply timestamp the subscription > when it is created and then passively garbage collect it later after it > expires. Having the much larger set of clients keep track of their > timers rather than centralizing the problem is viewed as a better > scaling solution because it fans out the work to the largest source of > capacity (ie. the clients). My suggestion is that at the time of garbage collection the server attempts to send keep-alives (ie duplicate notifications) back to any client that hasn't recieved a notification since the last collection interval. If the request is treated as spam or is unable to get through based on normal timeouts, the subscription terminates. If the request does get through and recieves an OK response, the subscription continues. This allows the server to reap old subscriptions without a client-initiated keepalive. Whether the gc is driven from a timer or from a high watermark wouldn't be too relevant so long as the watermark isn't hit and the gc performed too often. I haven't implemented this exact scenario myself as yet. In fact, the implementation I'm working with presently ties subscription lifetime to that of a TCP/IP connection. I am hoping to move to a more standard approach. > IMHO- The best way to solve the dead server problem is to have neither > end generating keep-alive traffic (which, in an ideal environment in > which no node fails, is always useless). Solve the problem at the server > by utilizing a high-availability scheme there so that a server failure > does not interrupt service. I agree. This is the gist of my draft's musings on the topic. The client never sends keepalives because the server should ensure that the subscription is persistent and keeps operating despite outages. Clients are more numerous and less reliable, so keepalive is still required in the reverse direction. I feel that the client should not normally be involved in choosing the interval. It really doesn't concern the client, and the interval should be long enough that any client can cope with the traffic. I suggested the same keepalive interval as TCP/IP suggests: 2 hours minimum, and only when notifications haven't been sent recently. > I've done some work in the past with SCADA, and typically the payload in > the event notifications does not require encryption. What you need to > typically prevent is someone trying to corrupt your central database > with garbage data (indicating faults where there are none, or masking > faults where they do exist). This can be handled by request > authentication. I believe there are a number of ways to solve this > problem depending on the level of assurance that you require for your > particular application. You could use HTTP Digest authentication to deal > with this, or something heavier such as TLS. Without understanding the > security requirements needed, it's going to be hard to evaluate. > However, there are a number of models out there already that you can > look at to see if there's a fit for your particular purpose. When I started thinking about the security problem it became clear to me that it isn't worth putting too much effort into encryption as part of an internet-scale mechanism as the concept of secrecy itself doesn't scale. You might as well just use SSL or some other direct mechanism. Secret data doesn't benefit from increases in scale, because only a small set of users are ever going to access the secret data. Authentication for NOTIFY requests is an interesting area, though. Normally HTTP authenication is based around a client who has an account on the server. With NOTIFY what you want to determine is that the client is acting on behalf of the server you subscribed to. You could ensure this by authenticating the server during your SUBSCRIBE, and passing it some kind of token to pass back. However that is subject to replay attacks and the like. Probably the most sustainable solution is to obtain a public key from the server that is signed by a trusted certificate authority. If the notify resource recieves a notification signed by the server's public key, and the sequence number (part of the signed portion of the document) is greater than the last one, then it knows it has a valid notification. If we are talking about pure nofication and not parital publication this is enough to continue to update to the latest state despite summarisation by state agents. Parital publication with summarising state agents requires that the signature be for the state produced by applying the patch, and can similarly be summarised by state agents. Unfortunately, I don't think there is any hope of getting something with such a new and complex security mechanism standardised in HTTP as part of a subscription protocol :) This pretty much leaves me with EXPIRE functionality only, i.e. someone claims something has changed but might not be trustworthy: You had better to a GET and see if they are right. The veracity of EXPIREs requests are only tested by going back and making that GET request. Easy, and probably standardisable. As such, I wonder if SIP might still be the way to go. The first hurdle would pretty-much be figuring out which sip URL to send your SUBSCRIBE request to when you have http://example.com/circuit-breakers/001 in-hand and want to subscribe to it. I think I'm reading that dialogs have to be initiated by the subscriber, as opposed to the resource being subscribed to.. and that a dialog needs to be established for a conversation. I think that would rule out using only the SUBSCRIBE part of my draft, and specifying a sip address as a callback. Or would that work? Benjamin. _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 27 14:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom0Y-00065F-U0; Mon, 27 Nov 2006 14:19:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom0X-00064p-Je for sipping@ietf.org; Mon, 27 Nov 2006 14:19:13 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom0W-00057Y-D7 for sipping@ietf.org; Mon, 27 Nov 2006 14:19:13 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061127191821b1100sqgf9e>; Mon, 27 Nov 2006 19:19:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kARJIK69005601 for ; Mon, 27 Nov 2006 14:18:21 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kARJIKfO005592; Mon, 27 Nov 2006 14:18:20 -0500 Date: Mon, 27 Nov 2006 14:18:20 -0500 Message-Id: <200611271918.kARJIKfO005592@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0J9600JR7CZFAY70@jes-fe2.zx.nl> (jbemmel@zonnet.nl) Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <0J9600JR7CZFAY70@jes-fe2.zx.nl> X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: Jeroen Van Bemmel Alternatively, the answer could also be: have an application server subscribe to the KPML event package, and have the edge device convert hook flashes to NOTIFYs. Then the AS can interpret them. ... and use third-party call-control to implement the features in question. That does sound like it fulfils all of the original poster's requirements. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 27 14:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom3l-00011w-V8; Mon, 27 Nov 2006 14:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom3k-0000tF-6B for sipping@ietf.org; Mon, 27 Nov 2006 14:22:32 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom3h-0005cY-VQ for sipping@ietf.org; Mon, 27 Nov 2006 14:22:32 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20061127192149b1200mt6l5e>; Mon, 27 Nov 2006 19:22:29 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id kARJKl69005773 for ; Mon, 27 Nov 2006 14:20:47 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kARJKlZO005769; Mon, 27 Nov 2006 14:20:47 -0500 Date: Mon, 27 Nov 2006 14:20:47 -0500 Message-Id: <200611271920.kARJKlZO005769@dragon.ariadne.com> To: sipping@ietf.org From: Dale.Worley@comcast.net In-reply-to: <33edf0b0b45f28de644d8265b4107259@verizon.net> (robbins.dave@verizon.net) Subject: Re: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call? References: <6FC4416DDE56C44DA0AEE67BC7CA43711191A78F@zrc2hxm2.corp.nortel.com> <45649EF9.8070808@cisco.com> <02c201c70ea6$40401510$6401a8c0@atlanta.polycom.com> <33edf0b0b45f28de644d8265b4107259@verizon.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org From: David Robbins Amen! If a SIP device has sufficient resources (processor, memory, signal processing) to do SIP correctly, it has enough to do many interesting features locally. But nobody will be surprised that I still hear people claim that it's too big a burden for a SIP device to do these features (as recently as last week). In my experience, audio processing consumes much more resources than even SIP processing. But... If your real limitation is time-to-market, and hence, development effort, and you've already got an application server that does the things you want, it saves a lot of code writing if you can anything beyond the baseline SIP implementation. Dale _______________________________________________ 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 From sipping-bounces@ietf.org Mon Nov 27 15:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQT-0003PG-Nf; Mon, 27 Nov 2006 15:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQP-0003Mn-Re; Mon, 27 Nov 2006 15:50:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQP-00020C-K6; Mon, 27 Nov 2006 15:50:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 903B132992; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FA-F6; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-sbc-funcs-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments Author(s) : J. Hautakorpi, et al. Filename : draft-ietf-sipping-sbc-funcs-00.txt Pages : 24 Date : 2006-11-27 This documents describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). Although the goal of this document is to describe all the functions of SBCs, a special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. It also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-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-sipping-sbc-funcs-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-sipping-sbc-funcs-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: <2006-11-27100417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-sbc-funcs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-sbc-funcs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27100417.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Mon Nov 27 15:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQc-0003Rt-N5; Mon, 27 Nov 2006 15:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQQ-0003NM-9F; Mon, 27 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQP-00020P-S4; Mon, 27 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BB02932997; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FX-Ka; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-consent-format-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : A Document Format for Requesting Consent Author(s) : G. Camarillo Filename : draft-ietf-sipping-consent-format-01.txt Pages : 14 Date : 2006-11-27 This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request the permission, of a specific recipient, to perform a particular routing translation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-format-01.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-sipping-consent-format-01.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-sipping-consent-format-01.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: <2006-11-27103744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-consent-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-consent-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27103744.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Mon Nov 27 15:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQa-0003RF-Kl; Mon, 27 Nov 2006 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQQ-0003N1-5c; Mon, 27 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQP-00020N-RX; Mon, 27 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B56F232996; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FU-Jm; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-pending-additions-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : The Session Initiation Protocol (SIP) Pending Additions Event Package Author(s) : G. Camarillo Filename : draft-ietf-sipping-pending-additions-01.txt Pages : 13 Date : 2006-11-27 This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-pending-additions-01.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-sipping-pending-additions-01.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@ietFrom sipping-bounces@ietf.org Mon Nov 27 15:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQc-0003Rt-N5; Mon, 27 Nov 2006 15:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQQ-0003NM-9F; Mon, 27 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQP-00020P-S4; Mon, 27 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BB02932997; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FX-Ka; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-consent-format-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : A Document Format for Requesting Consent Author(s) : G. Camarillo Filename : draft-ietf-sipping-consent-format-01.txt Pages : 14 Date : 2006-11-27 This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request the permission, of a specific recipient, to perform a particular routing translation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-format-01.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-sipping-consent-format-01.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-sipping-consent-format-01.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: Messagef.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-pending-additions-01.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: <2006-11-27103549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-pending-additions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-pending-additions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27103549.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- /External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-27103744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-consent-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-consent-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27103744.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Mon Nov 27 15:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQa-0003RF-Kl; Mon, 27 Nov 2006 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonQQ-0003N1-5c; Mon, 27 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonQP-00020N-RX; Mon, 27 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B56F232996; Mon, 27 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GonQP-0001FU-Jm; Mon, 27 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-pending-additions-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : The Session Initiation Protocol (SIP) Pending Additions Event Package Author(s) : G. Camarillo Filename : draft-ietf-sipping-pending-additions-01.txt Pages : 13 Date : 2006-11-27 This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-pending-additions-01.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-sipping-pending-additions-01.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-sipping-pending-additions-01.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: <2006-11-27103549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-pending-additions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-pending-additions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-27103549.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Tue Nov 28 10:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4zG-0007JB-Kb; Tue, 28 Nov 2006 10:35:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4zE-0007J5-Go for sipping@ietf.org; Tue, 28 Nov 2006 10:35:08 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp4z8-00041t-6e for sipping@ietf.org; Tue, 28 Nov 2006 10:35:08 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kASFYxWs028238; Tue, 28 Nov 2006 09:34:59 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kASFYsV19122; Tue, 28 Nov 2006 09:34:55 -0600 (CST) Message-ID: <456C571F.7030701@lucent.com> Date: Tue, 28 Nov 2006 09:34:55 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIPPING LIST Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Chris Boulton Subject: [Sipping] draft-ietf-sipping-ipv6-torture-tests-00 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Folks: As per the discussions in San Diego, I have submitted the SIP IPv6 Torture test draft as a WG item. Until it is available in the archives, you can get a copy from: https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sipping-ipv6-torture-tests/draft-ietf-sipping-ipv6-torture-tests-00.txt We have not added any new text in it since the -03 version of the individual submission. However, the intent is to wrap it up by Prague IETF. If you can eyeball it and suggest new test cases, they will be included in the next revision. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 28 15:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Q2-00089Q-D5; Tue, 28 Nov 2006 15:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9Q0-00089H-Md for sipping@ietf.org; Tue, 28 Nov 2006 15:19:04 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9Pw-0007qc-7W for sipping@ietf.org; Tue, 28 Nov 2006 15:19:04 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASKIv109006; Tue, 28 Nov 2006 15:18:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-capacity-attribute-02.txt Date: Tue, 28 Nov 2006 14:18:39 -0600 Message-ID: In-Reply-To: <452A0219.4000005@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] I-D ACTION:draft-ietf-sipping-capacity-attribute-02.txt Thread-Index: AcbreVOuTrAuZEf3S9y2h6BVtM5LvwnrY5xQ From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Miguel Garcia , gonzalo.camarillo@ericsson.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I've done a delayed re-review of the updated document and it looks ready to go, except for a few editorial nits that were introduced with the new text, summarized below. For folks in the WG, any additional feedback on this document should be provided by December 5th, at which time the plan is to forward the doc for AD/IESG review.=20 There is also a diff available at: http://tools.ietf.org/wg/sipping/draft-ietf-sipping-capacity-attribute/d raft-ietf-sipping-capacity-attribute-02-from-01.diff.html Regards, Mary. SIPPING WG co-chair Editorial nits: --------------- - Section 1, 3rd paragraph, 1st sentence: insert "a" before "list of resources" or changes "list" to "lists": OLD: Although the XML resource list [7] provides a powerful mechanism for describing list of resources,=20 NEW:=20 Although the XML resource list [7] provides a powerful mechanism for describing a list of resources,=20 - Section 1, 4th paragraph, 1st sentence, last word: "recipeint" -> "recipient" - Section 2, "Copy Control" definition, 2nd sentence: insert "to" before "recipient" OLD: Its purpose is to indicate the recipient whether he is getting a primary, carbon, or blind carbon copy of the SIP request. NEW:=20 Its purpose is to indicate to the recipient whether he is getting a primary, carbon, or blind carbon copy of the SIP request. - Section 3, 1st paragraph, 2nd sentence: "of intended recipients" is redundant given the definition of "Recipient List" in section 2. OLD: A SIP User Agent Client (UAC) issuer sends a SIP request (F1) to a URI-list server containing a recipient list of intended recipients.=20 NEW:=20 A SIP User Agent Client (UAC) issuer sends a SIP request (F1) to a URI-list server containing a recipient list. -----Original Message----- From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20 Sent: Monday, October 09, 2006 3:03 AM To: sipping@ietf.org Cc: Gonzalo Camarillo; Barnes, Mary (RICH2:AR00) Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-capacity-attribute-02.txt This version of the document captures the comments received during WGLC. The main changes are: - 'capacity' attribute renamed as 'copyControl' - addition of two concepts that help to understand the draft: "recipient list" and "recipient-history list". - discussion of the commonalities of a bcc and an anonymize attribute I have also created a diff version with respect -01: http://people.nokia.net/~miguel/drafts/draft-ietf-sipping-capacity-attri bute-01-to-02.html BR, Miguel sipping-bounces@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. >=20 > Title : Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists > Author(s) : M. Garcia-Martin, G. Camarillo > Filename : draft-ietf-sipping-capacity-attribute-02.txt > Pages : 16 > Date : 2006-10-6 > =09 > In certain types of multimedia communications, a Session Initiation > Protocol (SIP) request is distributed to a group of SIP User Agents > (UAs). The sender sends a single SIP request to a server which > further distributes the request to the group. This SIP request > contains a list of Uniform Resource Identifiers (URIs), which > identify the recipients of the SIP request. This URI-list is > expressed as a resource list XML document. This specification > defines an XML extension to the XML resource list format that allows > the sender of the request to qualify a recipient with a copy control > level similar to the copy control level of existing e-mail systems. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-capacity-attribut e-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sipping-capacity-attribute-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-capacity-attribute-02.txt". > =09 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ 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 From sipping-bounces@ietf.org Tue Nov 28 15:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9u2-000797-K4; Tue, 28 Nov 2006 15:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9tx-00074s-VO; Tue, 28 Nov 2006 15:50:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9tx-00049R-NX; Tue, 28 Nov 2006 15:50:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id AAB8C3289A; Tue, 28 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gp9tx-0001AB-Ia; Tue, 28 Nov 2006 15:50:01 -0500 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, 28 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-overload-reqs-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : Requirements for Management of Overload in the Session Initiation Protocol Author(s) : J. Rosenberg Filename : draft-ietf-sipping-overload-reqs-00.txt Pages : 21 Date : 2006-11-28 Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-overload-reqs-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-sipping-overload-reqs-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-sipping-overload-reqs-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: <2006-11-28113212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-overload-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-overload-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-28113212.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Wed Nov 29 10:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpR5J-000688-Dh; Wed, 29 Nov 2006 10:10:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpR5I-00067U-LU for sipping@ietf.org; Wed, 29 Nov 2006 10:10:52 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpR5G-0004sc-CC for sipping@ietf.org; Wed, 29 Nov 2006 10:10:52 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kATFAm218851 for ; Wed, 29 Nov 2006 10:10:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Nov 2006 09:10:47 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-sipping-sbc-funcs-00.txt Thread-Index: AccTyIwzzFbzrdjkQXqjVKtgp5wx5g== From: "Mary Barnes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Sipping] WGLC: draft-ietf-sipping-sbc-funcs-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0059179180==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0059179180== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C713C8.8C4E2A10" This is a multi-part message in MIME format. ------_=_NextPart_001_01C713C8.8C4E2A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This is to announce Working Group Last Call on the following document: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-00.txt We would like 3 volunteers to commit to reviewing the document. If interested, please contact me directly. I'll include that information in the spreadsheet that will be updated shortly to reflect the state of this document in WGLC.=20 As always, anyone else that gets a chance to review should also send their feedback to the authors and copy the SIPPING mailing list.=20 This WGLC will end on December 20th, 2006 (three weeks time).=20 Thanks,=20 Mary=20 SIPPING WG co-chair ------_=_NextPart_001_01C713C8.8C4E2A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC: draft-ietf-sipping-sbc-funcs-00.txt

Hi all,

This is to announce Working Group = Last Call on the following document:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-00.= txt

We would like 3 volunteers to = commit to reviewing the document.  If interested, please contact me = directly.  I'll include that information in the spreadsheet that = will be updated shortly to reflect the state of this document in WGLC. =

As always, anyone else that gets = a chance to review should also send
their feedback to the authors = and copy the SIPPING mailing list.

This WGLC will end on December = 20th, 2006 (three weeks time).

Thanks,
Mary
SIPPING WG co-chair

------_=_NextPart_001_01C713C8.8C4E2A10-- --===============0059179180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0059179180==-- From sipping-bounces@ietf.org Wed Nov 29 10:43:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRbI-00068e-TJ; Wed, 29 Nov 2006 10:43:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRbG-00068M-Nr for sipping@ietf.org; Wed, 29 Nov 2006 10:43:54 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRbE-0003iS-V9 for sipping@ietf.org; Wed, 29 Nov 2006 10:43:54 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kATFhOFn027786; Wed, 29 Nov 2006 17:43:49 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 17:43:33 +0200 Received: from [10.162.76.48] ([10.162.76.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 29 Nov 2006 17:43:32 +0200 Message-ID: <456DAAA4.2040107@nokia.com> Date: Wed, 29 Nov 2006 17:43:32 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-capacity-attribute-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2006 15:43:32.0568 (UTC) FILETIME=[1FC69580:01C713CD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061129174349-6C899BB0-670A900C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: sipping@ietf.org, gonzalo.camarillo@ericsson.com X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Mary: Thanks for your comments. We will introduce then into a new version of the draft. We are targeting for producing this new version by mid next week, so if someone else want to add reasonable comments, we can accept them until December 5th. BR, Miguel Mary Barnes wrote: > I've done a delayed re-review of the updated document and it looks ready > to go, except for a few editorial nits that were introduced with the new > text, summarized below. > > For folks in the WG, any additional feedback on this document should be > provided by December 5th, at which time the plan is to forward the doc > for AD/IESG review. > > There is also a diff available at: > http://tools.ietf.org/wg/sipping/draft-ietf-sipping-capacity-attribute/d > raft-ietf-sipping-capacity-attribute-02-from-01.diff.html > > Regards, > Mary. > SIPPING WG co-chair > > > Editorial nits: > --------------- > - Section 1, 3rd paragraph, 1st sentence: insert "a" before "list of > resources" or changes "list" to "lists": > OLD: > Although the XML resource list [7] provides a powerful mechanism for > describing list of resources, > NEW: > Although the XML resource list [7] provides a powerful mechanism for > describing a list of resources, > > - Section 1, 4th paragraph, 1st sentence, last word: "recipeint" -> > "recipient" > > - Section 2, "Copy Control" definition, 2nd sentence: insert "to" before > "recipient" > OLD: > Its purpose is to indicate the recipient whether > he is getting a primary, carbon, or blind carbon copy of the SIP > request. > NEW: > Its purpose is to indicate to the recipient whether > he is getting a primary, carbon, or blind carbon copy of the SIP > request. > > - Section 3, 1st paragraph, 2nd sentence: "of intended recipients" is > redundant given the definition of "Recipient List" in section 2. > OLD: > A SIP User Agent Client (UAC) issuer sends a SIP request > (F1) to a URI-list server containing a recipient list of intended > recipients. > NEW: > A SIP User Agent Client (UAC) issuer sends a SIP request > (F1) to a URI-list server containing a recipient list. > > > -----Original Message----- > From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Sent: Monday, October 09, 2006 3:03 AM > To: sipping@ietf.org > Cc: Gonzalo Camarillo; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sipping] I-D > ACTION:draft-ietf-sipping-capacity-attribute-02.txt > > > This version of the document captures the comments received during WGLC. > > The main changes are: > > - 'capacity' attribute renamed as 'copyControl' > - addition of two concepts that help to understand the draft: "recipient > > list" and "recipient-history list". > - discussion of the commonalities of a bcc and an anonymize attribute > > I have also created a diff version with respect -01: > > http://people.nokia.net/~miguel/drafts/draft-ietf-sipping-capacity-attri > bute-01-to-02.html > > BR, > > Miguel > > sipping-bounces@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. >> Title : Extensible Markup Language (XML) Format > Extension for Representing Copy Control Attributes in Resource Lists >> Author(s) : M. Garcia-Martin, G. Camarillo >> Filename : draft-ietf-sipping-capacity-attribute-02.txt >> Pages : 16 >> Date : 2006-10-6 >> >> In certain types of multimedia communications, a Session Initiation >> Protocol (SIP) request is distributed to a group of SIP User Agents >> (UAs). The sender sends a single SIP request to a server which >> further distributes the request to the group. This SIP request >> contains a list of Uniform Resource Identifiers (URIs), which >> identify the recipients of the SIP request. This URI-list is >> expressed as a resource list XML document. This specification >> defines an XML extension to the XML resource list format that > allows >> the sender of the request to qualify a recipient with a copy > control >> level similar to the copy control level of existing e-mail systems. >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-sipping-capacity-attribut > e-02.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-sipping-capacity-attribute-02.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-sipping-capacity-attribute-02.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. >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ 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 From sipping-bounces@ietf.org Wed Nov 29 10:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhP-0000mb-H9; Wed, 29 Nov 2006 10:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRhL-0000lZ-22; Wed, 29 Nov 2006 10:50:11 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRhB-0004aI-Ti; Wed, 29 Nov 2006 10:50:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D99D0328E0; Wed, 29 Nov 2006 15:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GpRhB-00017j-Oz; Wed, 29 Nov 2006 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Nov 2006 10:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-ipv6-torture-tests-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-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 Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) Author(s) : V. Gurbani, et al. Filename : draft-ietf-sipping-ipv6-torture-tests-00.txt Pages : 13 Date : 2006-11-29 This informational document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the IPv6 portions of a SIP implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-ipv6-torture-tests-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-sipping-ipv6-torture-tests-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-sipping-ipv6-torture-tests-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: <2006-11-29061618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-ipv6-torture-tests-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-ipv6-torture-tests-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-29061618.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sipping-bounces@ietf.org Thu Nov 30 20:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx3k-0007RG-P3; Thu, 30 Nov 2006 20:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpx3i-0007R6-SK for sipping@ietf.org; Thu, 30 Nov 2006 20:19:22 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpx3g-00034s-Fz for sipping@ietf.org; Thu, 30 Nov 2006 20:19:22 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB11JHL29671 for ; Thu, 30 Nov 2006 20:19:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] WGLC: draft-ietf-sipping-sbc-funcs-00.txt Date: Thu, 30 Nov 2006 19:19:16 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E37A37B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] WGLC: draft-ietf-sipping-sbc-funcs-00.txt thread-index: AccTyIwzzFbzrdjkQXqjVKtgp5wx5gBFmrHw From: "Francois Audet" To: "Mary Barnes" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org I really do not believe that this document is ready for Working Group Last Call. I have started to review it, but I'm having difficulties because it just isn't ready yet. There are a number of comments (unresolved issues) from the authors still embedded in the document, illustrating that it is not ready for WGLC. It is pretty entertaining to read the dialog between the co-authors, but it does emphasise that the text is not ready. I also find that the wording needs lots of improvement.=20 The purpose of the document is not very clear either. And the introduction is more confusing than helpful. Some specific comments: - In the Scenario section, I'd like to see an Enterprise border scenario. (I.e., where an enteprise uses an SBC at the edge of it's network, in the DMZ). On the other side, it could be the open internet with "normal" SIP DNS based connectivity, or it could be a SIP service provider. - The problem in section 3.1.2 is not "theoretical". It will happen in all but the smallest of Enterprise scenarios (as per the scenario described in previous bullet). - The term "SIP Profiles" in section 3.3.1 is probably something we want to avoid (i.e., say "implement=20 SIP differently" instead of "implement different SIP Profiles"). - The section about NAT should explain more media anchoring, and the difference between anchoring in one direction or in two direction (i.e., some SBCs only anchor media for IP addresses on the private side, like "ALGs"). - Section 3.5.2: SBCs do introduce a scalabiliy problem because it forces the funneling of signalling and media into a single point of failure. - I don't see the point of the list of "bugs" fixed in 3.6.3 by an SBC.=20 - Architectural issues in 3.7.2 for Media encryption should describe the extra delay affecting voice quality, as well as the processing requirement. It should also describe that it introduces another layer of routing on top of IP and generate sub-optiomal routing. - Security consideration section needs to be written. There are lots of security considerations to talk about. SBCs are Man-in-the-Middle by definition. It has impact on RFC 4474 that needs to be described. Also on signalling security (explain that SBC is a TLS hop). The implications of Topology hiding for security needs to be explored.=20 In summary, I think it needs quite a few more cycles of editing. ________________________________ From: Barnes, Mary (RICH2:AR00)=20 Sent: Wednesday, November 29, 2006 07:11 To: sipping@ietf.org Subject: [Sipping] WGLC: draft-ietf-sipping-sbc-funcs-00.txt =09 =09 Hi all,=20 This is to announce Working Group Last Call on the following document:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-00.txt We would like 3 volunteers to commit to reviewing the document. If interested, please contact me directly. I'll include that information in the spreadsheet that will be updated shortly to reflect the state of this document in WGLC.=20 As always, anyone else that gets a chance to review should also send=20 their feedback to the authors and copy the SIPPING mailing list. This WGLC will end on December 20th, 2006 (three weeks time).=20 Thanks,=20 Mary=20 SIPPING WG co-chair=20 _______________________________________________ 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