From sip-bounces@ietf.org Mon Aug 01 03:48:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzV2Z-00031h-Gb; Mon, 01 Aug 2005 03:48:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxnhy-0000nq-Hr for sip@megatron.ietf.org; Wed, 27 Jul 2005 11:20:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06981 for ; Wed, 27 Jul 2005 11:20:31 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoDF-0000SN-4V for sip@ietf.org; Wed, 27 Jul 2005 11:52:54 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6RFKRsw001359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2005 11:20:28 -0400 (EDT) Received: from flame.cs.columbia.edu (localhost [127.0.0.1]) by flame.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6RFKRoq016730; Wed, 27 Jul 2005 11:20:27 -0400 (EDT) Received: from localhost (salman@localhost) by flame.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id j6RFKJw8016725; Wed, 27 Jul 2005 11:20:19 -0400 (EDT) X-Authentication-Warning: flame.cs.columbia.edu: salman owned process doing -bs Date: Wed, 27 Jul 2005 11:20:19 -0400 (EDT) From: Salman Abdul Baset To: "Summers, Kevin" Subject: RE: [Sip] MGCP to SIP Interworking? In-Reply-To: <8C0CF305DEE53240BC3739EB4DC557D76B29D7@sonustxmail01.sonusnet.com> Message-ID: References: <8C0CF305DEE53240BC3739EB4DC557D76B29D7@sonustxmail01.sonusnet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 01 Aug 2005 03:48:48 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is a Megaco-to-SIP basic message interconversion document that my colleague and I wrote 3 years back. You can take it as a starting point. It is available at: http://www1.cs.columbia.edu/~salman/publications/sipmegaco.pdf -salman On Wed, 27 Jul 2005, Summers, Kevin wrote: > Not within the IETF. The PacketCable folks may have done some work in this area, but I don't recall ever seeing the mapping you ask about in their specs. > > Keep in mind there are various ways to manage a "connection" in MGCP -- this will complicate your interworking task. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Rahul Joshi > Sent: Wednesday, July 27, 2005 9:38 AM > To: sip@ietf.org > Subject: [Sip] MGCP to SIP Interworking? > > > Is there any standard/draft for interworking between MGCP and SIP? I am > specifically looking for how to map MGCP error messages e.g. NACK's to > CRCX to SIP error codes. Any pointers in this regards would be help. > > Regards. > -Rahul. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 03:48:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzV2b-000328-Rc; Mon, 01 Aug 2005 03:48:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyJoa-0004MV-3A for sip@megatron.ietf.org; Thu, 28 Jul 2005 21:37:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12375 for ; Thu, 28 Jul 2005 21:37:30 -0400 (EDT) Message-Id: <200507290137.VAA12375@ietf.org> Received: from m12-14.163.com ([220.181.12.14] helo=163.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DyKK7-00085D-V5 for sip@ietf.org; Thu, 28 Jul 2005 22:10:10 -0400 Received: from Zanemap (unknown [59.64.179.2]) by smtp11 (Coremail) with SMTP id NEBe8kuI6ULB3V4C.1 for ; Fri, 29 Jul 2005 09:37:25 +0800 (CST) X-Originating-IP: [59.64.179.2] Date: Fri, 29 Jul 2005 09:37:05 +0800 From: "zane" To: "sip" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-Spam-Score: 2.5 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 01 Aug 2005 03:48:48 -0400 Subject: [Sip] Two question about RFC3261 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1179641909==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1179641909== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVsbG8gZXZlcnlvbmU6DQoJSSBuZWVkIHlvdXIgaGVscC5JIGFtIGxlYXJuaW5nIFJGQzMyNjEu SSBoYXZlIHR3byBxdWVzdGlvbiB0aGF0IHB1enpsZSBtZSBhIGxvdC4NCg0KMS4gSW4gUkZDMzI2 MSAxNi45ICxpdCBzYXlzICJJZiB0aGUgcHJveHkgaXMgbm90aWZpZWQgb2YgYW4gZXJyb3Igd2hl biBmb3J3YXJkaW5nIGEgcmVzcG9uc2UsIGl0DQogICBkcm9wcyB0aGUgcmVzcG9uc2UuICBUaGUg cHJveHkgU0hPVUxEIE5PVCBjYW5jZWwgYW55IG91dHN0YW5kaW5nDQogICBjbGllbnQgdHJhbnNh Y3Rpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGlzIHJlc3BvbnNlIGNvbnRleHQgZHVlIHRvIHRoaXMN CiAgIG5vdGlmaWNhdGlvbi4NCiAgICAgIElmIGEgcHJveHkgY2FuY2VscyBpdHMgb3V0c3RhbmRp bmcgY2xpZW50IHRyYW5zYWN0aW9ucywgYSBzaW5nbGUNCiAgICAgIG1hbGljaW91cyBvciBtaXNi ZWhhdmluZyBjbGllbnQgY2FuIGNhdXNlIGFsbCB0cmFuc2FjdGlvbnMgdG8gZmFpbA0KICAgICAg dGhyb3VnaCBpdHMgVmlhIGhlYWRlciBmaWVsZC4iIA0KDQoJSSBjYW4ndCB1bmRlcnN0YW5kLiBJ ZiBwcm94eSBkbyBub3QgY2FuY2VsIHRoZSBjbGllbnQgdHJhbnNhY3Rpb24gYXNzb2NpYXRlZCB3 aXRoIHRoZSBlcnJvciBzZXJ2ZXIgCQ0KCXRyYW5zYWN0aW9uICwgd2hhdCBzaG91bGQgdGhlIHBy b3h5IGRvID8gQmVjYXVzZSB0aGUgZXJyb3Igc2VydmVyIHRyYW5zYWN0aW9uIGhhZCBiZWVuIHRl cm1pbmF0ZWQsIAkNCgl3aGVuIHRoZSBzdWJzZXF1ZW50IHJlc3BvbnNlIGluIGEgc2FtZSBjbGll bnQgdHJhbnNhY3Rpb24gY2FtZSAsIGhvdyBkaWQgdGhlIHByb3h5IHRyZWF0IGl0ID8gDQoJDQoJ QW5kIEkgY2FuJ3QgdW5kZXJzdGFuZCB0aGUgbm90aWZpY2F0aW9uIC4gSG93IGNhbiBhIHNpbmds ZSBtYWxpY2lvdXMgY2xpZW50IGNhdXNlICJhbGwiIHRyYW5zYWN0aW9uIA0KCXRvIGZhaWwgdGhy b3VnaCBpdHMgVmlhID8gSSB0aGluayBpdCBjYW4gb25seSBjYXVzZSB0cmFuc2FjdGlvbiBhc3Nv Y2lhdGUgd2l0aCBpdHNlbGYgdG8gZmFpbCAsYW5kIHRoZW4NCgl3aGF0IGlzIHRoZSBpbnRlbnRp b24gb2YgdGhlIG1hbGljaW91cyBjbGllbnQgZG9pbmcgdGhpcz8NCg0KDQoyLiBJbiBSRkMzMjYx IDE3LjIuMSAsIGl0IHNheXMgIklmIHRpbWVyIEggZmlyZXMgd2hpbGUgaW4gdGhlICJDb21wbGV0 ZWQiIHN0YXRlLCBpdCBpbXBsaWVzIHRoYXQgdGhlDQogICBBQ0sgd2FzIG5ldmVyIHJlY2VpdmVk LiAgSW4gdGhpcyBjYXNlLCB0aGUgc2VydmVyIHRyYW5zYWN0aW9uIE1VU1QNCiAgIHRyYW5zaXRp b24gdG8gdGhlICJUZXJtaW5hdGVkIiBzdGF0ZSwgYW5kIE1VU1QgaW5kaWNhdGUgdG8gdGhlIFRV DQogICB0aGF0IGEgdHJhbnNhY3Rpb24gZmFpbHVyZSBoYXMgb2NjdXJyZWQuIg0KDQoJVGhlIHRy YW5zYWN0aW9uIGxheWVyIGluZm9ybSBUVSB0aGF0IEFDSyBtaXNzZWQgLCBidXQgaG93IGRpZCBU VSBtYW5hZ2UgdGhpcyBlcnJvciA/IEkgY2FuJ3QgZmluZCBpdCANCglpbiBSRkMzMjYxIC4gQW55 Ym9keSBjYW4gdGVsbCBtZSBpdCBwbGVhc2UgPw0KDQoNClRoYXQgaXMgYWxsLiAgVGhhbmtzIGEg bG90IQ0KDQoJDQoJDQoNCqGhoaGhoaGhoaGhoaGhoaFWaWN0b3IgWmFuZQ0KoaGhoaGhoaGhoaGh oaGhoXphbmVidXB0QDE2My5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wNy0yOA0K --===============1179641909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1179641909==-- From sip-bounces@ietf.org Mon Aug 01 03:48:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzV2d-00032a-Ge; Mon, 01 Aug 2005 03:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybTL-0008Qm-Sh for sip@megatron.ietf.org; Fri, 29 Jul 2005 16:28:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07324 for ; Fri, 29 Jul 2005 16:28:45 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dybz5-0004y1-2b for sip@ietf.org; Fri, 29 Jul 2005 17:01:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2005 13:28:38 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6TKSbJL021801; Fri, 29 Jul 2005 13:28:37 -0700 (PDT) Received: from [171.71.193.3] (dhcp-171-71-193-3.cisco.com [171.71.193.3]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j6TKQHxY003737; Fri, 29 Jul 2005 13:26:18 -0700 Message-ID: <42EA9174.10709@cisco.com> Date: Fri, 29 Jul 2005 13:28:36 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] privacy in draft-ietf-sip-identity - Privacy header field ineffective References: <42E50AE5.6020806@cisco.com> In-Reply-To: <42E50AE5.6020806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4157; t=1122668778; x=1123100978; c=nowsp; s=nebraska; h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=thomasm@cisco.com; z=Subject:Re=3A=20[Sip]=20privacy=20in=20draft-ietf-sip-identity=20-=20Privacy=20h eader=20field=0A=20ineffective| From:Michael=20Thomas=20| Date:Fri,=2029=20Jul=202005=2013=3A28=3A36=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Mwbf1Y7bQvJSM7SsABR6E4K1BAXJohn3BgUbNHKg5zUvAguTvjVCofvIwM9VXFfsE4AN1vJX YCITlGViAfh108614PqC6oscTQlwrOP+rxdZVaroSVexvD16XqbttzjuJHiigGkD5T+Ne4vQQDk jUSeVoEfD1G91uw/ia4MAJNQ= Authentication-Results: imail.cisco.com; header.From=thomasm@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Aug 2005 03:48:48 -0400 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I guess my first question would be why you'd expect -identity to work through a b2bua in the first place. It seems to me to be *feature* that anything that changes the semantics of the original message would break the signature. That and my head goes in loops when say that you want source authentication that's, well, anonymous. Don't all of these problems go away if you say that the B2BUA needs to be trusted by the originator, and that the anonymizing service becomes the new From: address, etc? I can't think of a case where the orignator wouldn't have to have some trust in the anonymization service because if nothing else it could trace your IP address back. Mike, it's been a long time so treat me gingerly Jonathan Rosenberg wrote: > Folks, > > Jon, Cullen and I wrote up an I-D that talks about the issues of privacy > in draft-ietf-sip-identity. The draft can be found here: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt > > > As it turns out, rfc3323 (the privacy header field), has numerous > problems when applied to draft-ietf-sip-identity: > > Intra-Domain Privacy: Because the SIP identity mechanism relies on > the domain of the From header field as a key for obtaining > certificates used to validate the identity in the From header > field, anonymity is restricted to being within a domain. It is no > longer possible, as described in RFC 3323, to populate the From > header field with "anonymous.invalid" as the domain. As a > consequence, a recipient of the request will be able to determine > the domain of the originator of the request, though they will not > be able to determine which user within that domain sent the > request. This limitation is not very troubling for domains with > extremely large numbers of users. However, for small domains, > such as enterprises or home networks, it can be equally revealing > as the identity of the requestor themselves. > > Contact Privacy lost: Because the SIP identity mechanism relies on a > signature over the Contact header field for referential integrity, > a privacy service that provides header privacy cannot actually > modify the Contact value. This will reveal the IP address of the > requestor to the recipient of the request, which can often provide > substantial information about the requestor. > > Session Privacy lost: Session privacy is accomplished through a back- > to-back user agent (b2bua) that rewrites the SDP to relay session > media through an intermediary. This no longer works at all with > the SIP identity mechanism, as it relies on a signature over the > body of the request (which contains the SDP) to provide > referential integrity. > > Subscriber Identity Lost within Originating Domain: One of the > benefits of the P-Asserted-ID header field when used in > conjunction with the "id" level of privacy is that elements within > the domain of the originator of the request will still be able to > determine the identity of the originator. This is necessary for > providing features for the requestor, accounting for their usage, > and so on. With the SIP identity mechanism, if privacy is needed, > the From header field contains an anonymous URI. As a result, the > request has no information that can identity the user within their > own domain, unless the SIP identity mechanism is used in > conjunction with RFC3325, which is redundant. > > These problems are in addition to the problems inherent in RFC 3323 > to begin with: > > Sensitivity to Boundary Configuration: Although RFC3323 argues > strongly in favor of placing the privacy service very near the > originator of the request, this goal is at odds with RFC 3325, > which requires the privacy service to be on the egress edge of the > trust domain. As a result, privacy is actually provided only if > every egress proxy is properly configured to take positive action > and remove the P-Asserted-ID header field. Because positive > action from the network is required to provide privacy, this > mechanism is sensitive to misconfiguration of network elements, > particularly in large interconnected trust domains. > > Complicated Call Trace: In many networks, there is a requirement to > provide a call trace feature that allows for malicious callers to > be traced back to their source so that legal action can be taken. > The utility of such features in a global SIP network aside, RFC > 3323 makes such a feature difficult to provide since the identity > of the requestor is literally removed from the request. This > complicates the tracking procedures needed to identify the > originator later on. > > Limited Flexibility The degrees of privacy that RFC 3323 could > provide were coded into the tokens valid in the Privacy header > field. More complicated combinations - anonymity for certain > media streams but not others, for example - were not possible. > > > The draft proposes a mechanism to fix these problems. This mechanism > would allow rfc3323 to be deprecated. > > Comments or questions? > > -Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 06:18:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXGb-0008Sx-JQ; Mon, 01 Aug 2005 06:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXGX-0008RO-TS for sip@megatron.ietf.org; Mon, 01 Aug 2005 06:11:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18373 for ; Mon, 1 Aug 2005 06:11:23 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzXmn-0008TN-KP for sip@ietf.org; Mon, 01 Aug 2005 06:44:46 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j71ABDk9010753; Mon, 1 Aug 2005 12:11:14 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j71ABD8I029655; Mon, 1 Aug 2005 12:11:13 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 12:11:12 +0200 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: AW: [Sip] tschofenig-sip-saml-04 Date: Mon, 1 Aug 2005 12:10:26 +0200 Message-ID: Thread-Topic: [Sip] tschofenig-sip-saml-04 Thread-Index: AcWVQM+uiFSRme4NQQS+0N6HliRdqABPjJNQ From: "Tschofenig, Hannes" To: "Cullen Jennings" , X-OriginalArrivalTime: 01 Aug 2005 10:11:12.0263 (UTC) FILETIME=[5814C170:01C59681] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hi cullen,=20 thanks for your review. please find a few comments inline: > Passing assertion and artifacts optimize different things. I=20 > completely > agree with the draft and we need to be able to do both. The=20 > biggest problem > seem to be how to bind this to the rest of the SIP message.=20 exactly. this is the point.=20 > Let me split > this into three cases >=20 > 1) End to end > 2) End to middle > 3) middle to middle or end >=20 > In case 1, end to end, one way the binding can be done using=20 > the Identity > mechanism and putting the assertion or artifact in the body.=20 > The Identity > provides integrity binding to these rest of the message. certainly true.=20 >=20 > Case 2 is like case 1 but you might want a header like the=20 > end to middle > work has defined so that all the middles do not need to read=20 > all the bodies. it is really similar to case 1 since you might want to express the same concerns in the identity work if you want proxies to verify the asserted identity.=20 >=20 >=20 > Case 3 seems like an age old discussion on having proxies add=20 > bodies. We > have never really figured out how to solve it. At first=20 > glance it seems like > just adding artifacts in headers might solve this case but it=20 > still runs > into the problems with binding and understanding tampering and cut and > paste. All seems hard yet many of the use cases could be=20 > solved with just > case 1 or perhaps 2. i agree that there is some relationship to prior discussions.=20 i personally would also like to see some guidelines with regard to the approach we should take here.=20 the same issue can also be observed with the location conveyance draft.=20 >=20 > Perhaps we should proceed with figuring out case 1 without=20 > yet having a > solution for 3. i am not sure. i could understand if you suggest to have just something like 'solution for 3 with artifacts only'. >=20 additionally, i would like to point you to another problem where the binding is even harder to accomplish:=20 the end host fetches the assertion / artifact using http and then starts the sip exchange. you might want to use the assertion for multiple different sip sessions (or even for different protocols).=20 i tried to highlight these problems in a past presentation:=20 http://www.tschofenig.priv.at/sip/IETF61/SAML-SIP.ppt ciao hannes >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 06:42:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXl4-0006uO-5D; Mon, 01 Aug 2005 06:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXl2-0006tE-3e for sip@megatron.ietf.org; Mon, 01 Aug 2005 06:42:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27787 for ; Mon, 1 Aug 2005 06:42:53 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzYHH-0001mr-F8 for sip@ietf.org; Mon, 01 Aug 2005 07:16:16 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 12:42:45 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j71AgeDi000329 for ; Mon, 1 Aug 2005 12:42:43 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 12:42:40 +0200 Received: from cisco.com ([10.61.80.181]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 12:42:39 +0200 Message-ID: <42EDFC9F.4090508@cisco.com> Date: Mon, 01 Aug 2005 06:42:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-refer-feature-param References: <42ECBB25.4070607@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 10:42:39.0826 (UTC) FILETIME=[BD280320:01C59685] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > * The security considerations section talks about including only useful > feature parameters in the Refer-To; I think you need to spend some more > time in the body of the document describing what this means, and how you > figure out what is relevant I would go further here. The absence of feature parameter doesn't mean the absence of the feature - it means only that no information is being stated about the feature. And its difficult to know what is relevant. So I think the best recommendation is that all known features SHOULD be specified. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 07:41:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYg4-0000l4-Vi; Mon, 01 Aug 2005 07:41:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYg2-0000gp-U7 for sip@megatron.ietf.org; Mon, 01 Aug 2005 07:41:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02539 for ; Mon, 1 Aug 2005 07:41:48 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzZCI-0004Xh-3s for sip@ietf.org; Mon, 01 Aug 2005 08:15:12 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 13:41:39 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j71BfUDm013549 for ; Mon, 1 Aug 2005 13:41:37 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 13:41:35 +0200 Received: from cisco.com ([10.61.80.57]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 13:41:35 +0200 Message-ID: <42EE0A6E.5030506@cisco.com> Date: Mon, 01 Aug 2005 07:41:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-outbound References: <42EC56DC.4090503@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 11:41:35.0101 (UTC) FILETIME=[F8582AD0:01C5968D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen, Couple of points: One thing I am struggling with relative to this draft is how to reconcile it with use of the config framework to bootstrap a device. This outbound stuff requires registering. But the config framework required doing some subscribes first, in order to discover where and how to register. But if this endpoint may be trapped behind a firewall, and needs the mechanisms of *outbound to get anywhere, how do we resolve that? The endpoint can perhaps discover that it must use a particular proxy, and TCP or TLS to connect to it. Based on that it can establish a connection and do an initial SUBSCRIBE. But how do the NOTIFY messages get out to it? The other issue has to do with avalance restart after a power failure that affects many UAs. Currently you specify that each UA should make an initial attempt to register as soon as it powers up. I think there needs to be some jitter applied to this initial startup. If a user is manipulating the UA and actively trying to do something that requires a connection then an immediate attempt is justified. If not, then some amount of time should be tolerable before trying to connect. That time is probably the same as the polling interval for determining if a connection has been lost. (Whatever is agreed to for that.) Paul Paul Jonathan Rosenberg wrote: > This draft is much improved from the previous version. Its an essential > part of the SIP nat traversal story so I am glad to see that. Comments > below, with big issues first. > > > Bigger issues > > * I still like STUN even over TCP. It has the advantage of generating a > response, and allowing the client to correlate the response to the > request. See more below. > > * the idea of a firewall between EP and registrar is something I'd > rather treat in Rohan's connect-reuse draft. Let this draft focus on the > client to network connections. > > * I find the overview of opreations confusing; it describes many > different scenarios, and gives the impression that the draft is a > hodgepodge of techniques. I would prefer to cast the overview and spec > overall in terms of the most genreal case - multiple edge proxies and a > separate registrar - and then treat other scenarios as a simplified case. > > * There are definitely some terminology problems and inconsistencies > around the terms connection, flow and binding. > >> With connection >> oriented transports such as TCP or TLS, the keep alive will detect >> failure after a NAT reboot. Connection oriented transport failures >> are detected by having the UA periodically sends a CRLF over the >> connection; if the connection has failed, a connection level error >> will be reported to the UA. > > > This is not always the case. I've run into deployments where the NATs > simply dropped bindings on the floor, and then dropped any subsequent > data packets without sending a reset or anything else. As such, these > took a very long time to get detected as connection failures. Using a > stun keepalive transaction over tcp allows these to be detected rapidly. > >> A CRLF can be considered the beginning >> of the next message that will be sent, and therefore this approach is >> backwards compatible with the core SIP specification. > > > This is a non-issue. The client needs to know that the server is > supporting this mechanism in the first place before doing anything. Its > just like sigcomp; you need to know the server does it before you start. > The draft proposes the stun flag for that. What you really want is > something like "connection-management=stun", where you can specify > different connection management techniques. You'd use that even if this > was going to be over tcp. > > Another really important point - the presence of > "connection-management=stun" or whatever in the route header field of > the register also tells the proxy that the client is using the > mechanisms in this spec. As such, the proxy knows that it can skip "bad > things" that servers sometimes do (like be an SBC) to deal with clients > behind nat. Thats another reason why you want this connection management > flag there even in the tcp case. > > * its not clear to me that the wait time in section 4.3 provides > sufficient avalanche restart protection, especially in a major case like > a metropolitan power outage. You're still goint to see a huge flood of > initial registrations, since the spec tells clients not to delay their > initial registrations when they power up. > >> Any time the registrar checks if a new contact matches an >> existing contact in the location database, it MUST also check and see >> if both the instance-id and flow-id match. If they do not match, >> then the they are not the same contact. > > > also, need to discuss the case where the contact URI do match, but the > instance-id and flow-id don't. In this case, they are NOT the same contact. > >>> The two algorithm for edge proxies are nearly identical with the >>> exception that one integrity protects the identifier so it can not be >>> tampered with. It is not clear if this integrity protection is >>> needed. The WG should determine if this integrity is need or not >>> then refine this specification. >> > > gruu has the same issue, and I am becoming convinced the encryption > doesnt help much. > > > > > Minor > >> capable of allowing new connections from the private address side to >> the public side. It is worth noting that most UAs in the world are >> deployed behind firewalls or NATs. > > > The last sentence is true today, but who knows what the future brings. > Generally, since RFC text is burned in stone, its better to avoid > statements about current network deployment scenarios. > >> However, these systems can still form TLS >> connections to a proxy or registrar such that the UA authenticates >> the server certificate, and the server authenticates the UA using a >> shared secret in a digest challenge. > > > .. digest challenge over that TLS connection. > >> The key idea of this specification is that when a UA sends a REGISTER >> request, the proxy can later use this same connection to forward any >> requests that need to go to this UA. > > > Since this spec applies to UDP also, I think you need to say here that > "connection" doesnt just mean a tcp connection. > > > Generally, the introduction seems to dance around the main point, which > should be stated bluntly I think: This specification allows SIP > registrations to be used to register clients behind a NAT or firewall. > >> flow: A Flow is a network protocol layer connection between two hosts >> that is represented by the network address of both ends and the >> protocol. For TCP and UDP this would include the IP addresses and >> ports of both ends and the protocol (TCP or UDP). With TCP, a >> flow would often have to one to one correspondence with a single >> file descriptor in the operating system. >> flow-id: This refers to the value of a new header parameter value for >> the contact header. When UA register multiple times, each >> registration gets a unique flow-id value. > > > One would think that a flow-id identifies a flow, but based on the above > definitions it doesn't. The first definition implies that a flow is > identified by its 5-tuple. > > I think that there are really three things here. One is a "flow", which > represents a logical association between a UA and a specific EP host it > wishes to correspond with. A flow is identified by a flow ID. A flow > manifests itself by a "connection", which is a TCP connection for TCP, > and a 5-tuple for UDP. The main point is that, as clienc connections > come and go, the connection IDs (the 5-tuples) change, but they are all > the same flow and thus have the same flow ID. > >> The overall approach is fairly simple. Each UA has a unique >> instance-id that stays the same for this UA even if the UA reboots or >> is power cycled. > > > reference GRUU > >> The overall approach is fairly simple. Each UA has a unique >> instance-id that stays the same for this UA even if the UA reboots or >> is power cycled. Each UA can register multiple times. > > > Sure. But here, I think you mean it can do so multiple times against the > same AOR, for the purposes of HA. > >> Each >> registration includes the instance-id for the UA and a flow-id label >> that is different for each connection. > > > So, if I re-register on a new tcp connection (because my old one > failed), this would seem to imply a new flow-id, but thats not what you > want. > >> UAs use a keep alive mechanism to keep their flow to the proxy or >> registrar alive. For TCP, TLS, and other connection oriented >> protocols this is a burst containing a single CRLF. For UDP it is a >> STUN request sent over the flow. > > > I think you mean connection instead of flow as the last word here. > >> When a proxy goes to route a message to a UA for which it has a >> binding, > > > you have not yet defined or used the term "binding". Also in this > sentence I think you are talking specifically about the registrar proxy. > >> The flow-id parameter is used to allow the >> registrar to detect and avoid using invalid contacts when a UA >> reboots, as described later in this section. > > > reboots or reconnects since its old connection failed for some reason > (like a nat reboot). > >> Implementors often ask why the value of the sip.instance is inside >> angle brackets. This is a requirement of RFC 3840 [8] which >> defines that media feature tags in SIP. Feature tags which are >> strings are compared by case sensitive string comparison. To >> differentiate these tags from tokens (which are not case >> sensitive), case sensitive parameters such as the sip.instance >> media feature tag are placed inside angle brackets. > > > this is discussed more thoroughly in gruu now, not sure it is needed to > replicate that text here > >> If the proxy had >> multiple flows that all went to this UA, it could choose any one of >> registration binding that it had for this AOR and had the same >> instance-id as the selected UA. > > > this isnt just something a proxy "could" do - its almost fundamental to > the operation of this spec. The set of registrations with differing > flows to the same isntance ID represent a logical bundle, of which the > proxy only picks one when actually forwarding a request. > > >> Note: The STUN mechanism is very robust and allows the detection >> of a changed IP address. It may also be possible to do this with >> OPTIONS messages and rport; although this approach has the >> advantage of being backwards compatible, it also increases the >> load on the proxy or registrar server. > > > backwards compatibility is a red-herring; see above. > > OPTIONS "significantly* increases the load. > >> The UA MUST also add a distinct flow-id >> parameter to the contact header. > > > header field > >> described in RFC 3261 and RFC 3263. In particular implementers >> should note that a 503 with a Retry-After is not considered a failure >> to form the connection. The UA should wait the indicated amount of >> time and retry the connection. > > > these two sentences seem contradictory - its not a failure to form the > connection, but you're supposed to retry the connection.. > >> 4.1.1 Instance-ID Selection > > > this all belongs in gruu if needed. > >> User Agents that form flows with stream oriented protocols such as >> TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection >> to detect liveness of the flow. If when sending the CRLF, the >> transport reports an error, then the connection is considered to have >> failed. It is RECOMMENDED that a CRLF be sent if the flow has not >> had any data sent or received in the previous 500 to 600 seconds. > > > this time is way too long. Thing about existing IM clients like AIM. I > find that AIM detects failed connections within about 30s, indicating a > keepalive of around that amount of time. Remember, for the duration that > a bad connection is not detected, there is a gap in availability for > incoming calls. Rapid detection is essential. > > >> User Agents that form flows with datagram oriented protocols such as >> UDP SHOULD check if the URI has the "stun" tag (defined in >> Section 10) and, if the tag is present, > > > you need to specify what URI you are talking about here. > >> Any time a SIP message is sent and the proxy does not respond, this >> is also considered a failure, the flow is closed > > > how does one close a UDP flow? > >> Any time a SIP message is sent and the proxy does not respond, this >> is also considered a failure, the flow is closed and the procedures >> in Section 4.1 are followed to form a new flow. > > > no - it doesnt follow the procedures in 4.1 yet. It has to figure out if > it needs to wait. Generally, whenever section 4.2 concludes that a > connection failed, it should refer to 4.3 for determining when to > re-establish it. > >> however, if there >> is a failure in forming this flow, the UA needs to wait a certain >> amount of time before retrying to form a flow to this particular URI >> in the proxy set. > > > important to mention that this is to avoid avalanche restart > >> wait-time = min( 1800, (30 * (2 ^ consecutive-failures))) > > > this formula doesn't have the base-time in it; 30s is hard-coded. > >> These three times SHOULD be configurable in the UA. > > > not clear which three you mean. You should explicitly define three > variables and use them in the equation above. Also, you should talk > about why they would ever be changed (its based on server capacity). > >> o The proxy MUST NOT populate the target set with more than one >> contact with the same AOR and instance-id at a time. If a request >> for a particular AOR and instance-id fails with a 410 response, >> the proxy SHOULD replace the failed branch with another target >> with the same AOR and instance-id, but a different flow-id. > > > > you should discuss cases like sequential forking, which normally pick > contacts in q-value order; it won't do that now, and would rather > initially treat the ones with the same instance ID as a group and pick > one of those. > > > > Proxies MUST Record-Route so that mid dialog requests are routed over > > the correct flow. > > just edge proxies > > > If a proxy or registrar receives a network error when sending a SIP > > message over a particular flow, it MUST remove all the bindings that > > use that flow (regardless of AOR). > > I thought a flow was specific to a single AOR? > >> Edge Proxies MUST Record-Route with the same URI that was used in the >> path so that mid dialog requests still are routed over the correct >> flow. > > > The thing thats MUST strength is record-routing so that mid-dialog > requests go over the same flow. You can do that without using the same > URI as in the Path. > >> When a URI is created that refers to a SIP device that supports STUN >> as described in this section, the URI parameter "stun", as defined in >> Section 10 SHOULD be added to the URI. > > > MUST I think > >> 9. Grammar >> >> This specification defines a new Contact header field parameter, >> flow-id. The grammar for DIGIT and EQUAL is obtained from RFC 3261 >> [3]. > > > what about the stun parameter (prefer connection-management or something > similar, per above) > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 08:16:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZDx-0005gA-Fd; Mon, 01 Aug 2005 08:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZDv-0005ea-LD for sip@megatron.ietf.org; Mon, 01 Aug 2005 08:16:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04808 for ; Mon, 1 Aug 2005 08:16:48 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzZkB-00067D-Ql for sip@ietf.org; Mon, 01 Aug 2005 08:50:13 -0400 Received: from [86.255.27.16] (open-27-16.ietf63.ietf.org [86.255.27.16]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j71CKft4018346 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 1 Aug 2005 07:20:43 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82472ff66fda07c4d10bb6af7c1bba3b@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 1 Aug 2005 14:16:41 +0200 To: sip@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Allison Mankin Subject: [Sip] Rough notes from SIP meeting session 1 at in IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My rough notes from today's SIP meeting are posted at: http://www.softarmor.com/sipwg/meets/ietf63/notes/notes-dwillis-sip1- ietf63.html Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 09:58:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzaoj-0003lY-9t; Mon, 01 Aug 2005 09:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzaog-0003lQ-Fw for sip@megatron.ietf.org; Mon, 01 Aug 2005 09:58:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09875 for ; Mon, 1 Aug 2005 09:58:52 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbKx-0001pJ-CK for sip@ietf.org; Mon, 01 Aug 2005 10:32:16 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j71DwPir020099; Mon, 1 Aug 2005 07:58:26 -0600 (MDT) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The security-flows document -- use it Date: Mon, 1 Aug 2005 07:59:07 -0600 Message-ID: Thread-Topic: [Sip] The security-flows document -- use it Thread-Index: AcWSKY71F5i6LxmvTJuC/MQqYmDHOQEa9H+w From: "Jean-Francois Mule" To: "Cullen Jennings" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen, Kumiko, I believe this document is helpful: it looks at TLS implementation = with the eyes of a sip developer (kind of similar to the early RFC2818 = for http folks). In the light of today's working group discussion, and per our brief = chat with Cullen, here are a couple of comments for your consideration = on draft-jennings-sip-sec-flows-03.txt: --- 1. Requirement section? The document currently reads just like the sip call flow examples right = now and may not lead folks to get the main implementation gotchas you = are seeing at sipit. Jonathan made a similar point at the mike. If - as you pointed out at the mike - the intent of the document is to = help implementers put the right attention to some potentially obscure = areas of tls/s-mime implementations, it would help abstracting those key = requirements in a separate, high-level sections with pointers to the = relevant ietf rfcs & section.=20 Another question I have is whether there might be some other "obvious" = requirements that could be added, similar to RFC2818 section 2.2 on = error cases (if TLS error, at the SIP app level, how could/should it be = handled?) In short, consider moving section 6 on "testing notes" as the first = section, and consider changing some of the notes to actual requirements: For e.g., replace < A common problem in interoperability is that some SIP clients do not < support TLS and only do SSLv3. Check that the client does use TLS. With something like > SIP clients SHOULD/MUST support TLS [RFC2246] as defined in SIP [] > section x.y. Note that TLS 1.0 and SSL 3.0 do not interoperate=20 > (see RFC2246 for more details and section E on TLS' Backward > Compatibility With SSL).=20 ----> you could potentially borrow more or less text but my preference = would be to state a simple requirement, then give the pointers. Would it = be useful to also point to "HTTP Over TLS" RFC2818 and AES ciphers for = TLS RFC3268 (you mention 3268 in the refs but not in the body of the = draft text)? Similar comment with: < Many SIP clients were found to accept expired certificates with no < warning or error. If you can find a hard requirement in TLS or somewhere that, TLS parties = must validate certificates when present (cert expiration for e.g, etc.), = that would make this text clearer. Note that a number of folks may argue that this is duplication, a repeat = of requirements that exist elsewhere and we don't need it. As Robert = Sparks mentioned, this may however be needed based on the sipit = findings. --- 2. msg flow and other test message snippets If you could articulate some of the main gotchas as requirements and = then provide the msg flow, it would be even more helpful. Mapping some = of the requirements to msg flow sequences or actual test cases would be = even better (in the context of sipit, but that may not belong in your = document). Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 12:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcyF-00041N-NS; Mon, 01 Aug 2005 12:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcyD-00040B-Vw for sip@megatron.ietf.org; Mon, 01 Aug 2005 12:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21415 for ; Mon, 1 Aug 2005 12:16:51 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdUW-0000UE-Jr for sip@ietf.org; Mon, 01 Aug 2005 12:50:17 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 18:16:44 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j71GGKE8025357 for ; Mon, 1 Aug 2005 18:16:41 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 18:14:35 +0200 Received: from cisco.com ([10.61.81.51]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 18:14:34 +0200 Message-ID: <42EE4A6A.20205@cisco.com> Date: Mon, 01 Aug 2005 12:14:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Cullen Jennings" Subject: Re: [Sip] comments on draft-ietf-sip-outbound References: <42EC56DC.4090503@cisco.com> <42EE0A6E.5030506@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 16:14:34.0883 (UTC) FILETIME=[1B748D30:01C596B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Another thing, In sections 5.2 and 6.2 you make requirements for forwarding the request over the flow. If there is an edge proxy, then the registrar proxy will be routing using the Path or Route header, not according to the rules in this section. I'm sure that is what is intended, but I can't find any words to support it. Paul Paul Kyzivat wrote: > Cullen, > > Couple of points: > > One thing I am struggling with relative to this draft is how to > reconcile it with use of the config framework to bootstrap a device. > This outbound stuff requires registering. But the config framework > required doing some subscribes first, in order to discover where and how > to register. But if this endpoint may be trapped behind a firewall, and > needs the mechanisms of *outbound to get anywhere, how do we resolve that? > > The endpoint can perhaps discover that it must use a particular proxy, > and TCP or TLS to connect to it. Based on that it can establish a > connection and do an initial SUBSCRIBE. But how do the NOTIFY messages > get out to it? > > The other issue has to do with avalance restart after a power failure > that affects many UAs. Currently you specify that each UA should make an > initial attempt to register as soon as it powers up. I think there needs > to be some jitter applied to this initial startup. If a user is > manipulating the UA and actively trying to do something that requires a > connection then an immediate attempt is justified. If not, then some > amount of time should be tolerable before trying to connect. That time > is probably the same as the polling interval for determining if a > connection has been lost. (Whatever is agreed to for that.) > > Paul > > Paul > > Jonathan Rosenberg wrote: > >> This draft is much improved from the previous version. Its an >> essential part of the SIP nat traversal story so I am glad to see >> that. Comments below, with big issues first. >> >> >> Bigger issues >> >> * I still like STUN even over TCP. It has the advantage of generating >> a response, and allowing the client to correlate the response to the >> request. See more below. >> >> * the idea of a firewall between EP and registrar is something I'd >> rather treat in Rohan's connect-reuse draft. Let this draft focus on >> the client to network connections. >> >> * I find the overview of opreations confusing; it describes many >> different scenarios, and gives the impression that the draft is a >> hodgepodge of techniques. I would prefer to cast the overview and spec >> overall in terms of the most genreal case - multiple edge proxies and >> a separate registrar - and then treat other scenarios as a simplified >> case. >> >> * There are definitely some terminology problems and inconsistencies >> around the terms connection, flow and binding. >> >>> With connection >>> oriented transports such as TCP or TLS, the keep alive will detect >>> failure after a NAT reboot. Connection oriented transport failures >>> are detected by having the UA periodically sends a CRLF over the >>> connection; if the connection has failed, a connection level error >>> will be reported to the UA. >> >> >> >> This is not always the case. I've run into deployments where the NATs >> simply dropped bindings on the floor, and then dropped any subsequent >> data packets without sending a reset or anything else. As such, these >> took a very long time to get detected as connection failures. Using a >> stun keepalive transaction over tcp allows these to be detected rapidly. >> >>> A CRLF can be considered the beginning >>> of the next message that will be sent, and therefore this approach is >>> backwards compatible with the core SIP specification. >> >> >> >> This is a non-issue. The client needs to know that the server is >> supporting this mechanism in the first place before doing anything. >> Its just like sigcomp; you need to know the server does it before you >> start. The draft proposes the stun flag for that. What you really >> want is something like "connection-management=stun", where you can >> specify different connection management techniques. You'd use that >> even if this was going to be over tcp. >> >> Another really important point - the presence of >> "connection-management=stun" or whatever in the route header field of >> the register also tells the proxy that the client is using the >> mechanisms in this spec. As such, the proxy knows that it can skip >> "bad things" that servers sometimes do (like be an SBC) to deal with >> clients behind nat. Thats another reason why you want this connection >> management flag there even in the tcp case. >> >> * its not clear to me that the wait time in section 4.3 provides >> sufficient avalanche restart protection, especially in a major case >> like a metropolitan power outage. You're still goint to see a huge >> flood of initial registrations, since the spec tells clients not to >> delay their initial registrations when they power up. >> >>> Any time the registrar checks if a new contact matches an >>> existing contact in the location database, it MUST also check and see >>> if both the instance-id and flow-id match. If they do not match, >>> then the they are not the same contact. >> >> >> >> also, need to discuss the case where the contact URI do match, but the >> instance-id and flow-id don't. In this case, they are NOT the same >> contact. >> >>>> The two algorithm for edge proxies are nearly identical with the >>>> exception that one integrity protects the identifier so it can >>>> not be >>>> tampered with. It is not clear if this integrity protection is >>>> needed. The WG should determine if this integrity is need or not >>>> then refine this specification. >>> >>> >> >> gruu has the same issue, and I am becoming convinced the encryption >> doesnt help much. >> >> >> >> >> Minor >> >>> capable of allowing new connections from the private address side to >>> the public side. It is worth noting that most UAs in the world are >>> deployed behind firewalls or NATs. >> >> >> >> The last sentence is true today, but who knows what the future brings. >> Generally, since RFC text is burned in stone, its better to avoid >> statements about current network deployment scenarios. >> >>> However, these systems can still form TLS >>> connections to a proxy or registrar such that the UA authenticates >>> the server certificate, and the server authenticates the UA using a >>> shared secret in a digest challenge. >> >> >> >> .. digest challenge over that TLS connection. >> >>> The key idea of this specification is that when a UA sends a REGISTER >>> request, the proxy can later use this same connection to forward any >>> requests that need to go to this UA. >> >> >> >> Since this spec applies to UDP also, I think you need to say here that >> "connection" doesnt just mean a tcp connection. >> >> >> Generally, the introduction seems to dance around the main point, >> which should be stated bluntly I think: This specification allows SIP >> registrations to be used to register clients behind a NAT or firewall. >> >>> flow: A Flow is a network protocol layer connection between two hosts >>> that is represented by the network address of both ends and the >>> protocol. For TCP and UDP this would include the IP addresses and >>> ports of both ends and the protocol (TCP or UDP). With TCP, a >>> flow would often have to one to one correspondence with a single >>> file descriptor in the operating system. >>> flow-id: This refers to the value of a new header parameter value for >>> the contact header. When UA register multiple times, each >>> registration gets a unique flow-id value. >> >> >> >> One would think that a flow-id identifies a flow, but based on the >> above definitions it doesn't. The first definition implies that a flow >> is identified by its 5-tuple. >> >> I think that there are really three things here. One is a "flow", >> which represents a logical association between a UA and a specific EP >> host it wishes to correspond with. A flow is identified by a flow ID. >> A flow manifests itself by a "connection", which is a TCP connection >> for TCP, and a 5-tuple for UDP. The main point is that, as clienc >> connections come and go, the connection IDs (the 5-tuples) change, but >> they are all the same flow and thus have the same flow ID. >> >>> The overall approach is fairly simple. Each UA has a unique >>> instance-id that stays the same for this UA even if the UA reboots or >>> is power cycled. >> >> >> >> reference GRUU >> >>> The overall approach is fairly simple. Each UA has a unique >>> instance-id that stays the same for this UA even if the UA reboots or >>> is power cycled. Each UA can register multiple times. >> >> >> >> Sure. But here, I think you mean it can do so multiple times against >> the same AOR, for the purposes of HA. >> >>> Each >>> registration includes the instance-id for the UA and a flow-id label >>> that is different for each connection. >> >> >> >> So, if I re-register on a new tcp connection (because my old one >> failed), this would seem to imply a new flow-id, but thats not what >> you want. >> >>> UAs use a keep alive mechanism to keep their flow to the proxy or >>> registrar alive. For TCP, TLS, and other connection oriented >>> protocols this is a burst containing a single CRLF. For UDP it is a >>> STUN request sent over the flow. >> >> >> >> I think you mean connection instead of flow as the last word here. >> >>> When a proxy goes to route a message to a UA for which it has a >>> binding, >> >> >> >> you have not yet defined or used the term "binding". Also in this >> sentence I think you are talking specifically about the registrar proxy. >> >>> The flow-id parameter is used to allow the >>> registrar to detect and avoid using invalid contacts when a UA >>> reboots, as described later in this section. >> >> >> >> reboots or reconnects since its old connection failed for some reason >> (like a nat reboot). >> >>> Implementors often ask why the value of the sip.instance is inside >>> angle brackets. This is a requirement of RFC 3840 [8] which >>> defines that media feature tags in SIP. Feature tags which are >>> strings are compared by case sensitive string comparison. To >>> differentiate these tags from tokens (which are not case >>> sensitive), case sensitive parameters such as the sip.instance >>> media feature tag are placed inside angle brackets. >> >> >> >> this is discussed more thoroughly in gruu now, not sure it is needed >> to replicate that text here >> >>> If the proxy had >>> multiple flows that all went to this UA, it could choose any one of >>> registration binding that it had for this AOR and had the same >>> instance-id as the selected UA. >> >> >> >> this isnt just something a proxy "could" do - its almost fundamental >> to the operation of this spec. The set of registrations with differing >> flows to the same isntance ID represent a logical bundle, of which the >> proxy only picks one when actually forwarding a request. >> >> >>> Note: The STUN mechanism is very robust and allows the detection >>> of a changed IP address. It may also be possible to do this with >>> OPTIONS messages and rport; although this approach has the >>> advantage of being backwards compatible, it also increases the >>> load on the proxy or registrar server. >> >> >> >> backwards compatibility is a red-herring; see above. >> >> OPTIONS "significantly* increases the load. >> >>> The UA MUST also add a distinct flow-id >>> parameter to the contact header. >> >> >> >> header field >> >>> described in RFC 3261 and RFC 3263. In particular implementers >>> should note that a 503 with a Retry-After is not considered a failure >>> to form the connection. The UA should wait the indicated amount of >>> time and retry the connection. >> >> >> >> these two sentences seem contradictory - its not a failure to form the >> connection, but you're supposed to retry the connection.. >> >>> 4.1.1 Instance-ID Selection >> >> >> >> this all belongs in gruu if needed. >> >>> User Agents that form flows with stream oriented protocols such as >>> TCP, TLS, or SCTP SHOULD periodically send a CRLF over the connection >>> to detect liveness of the flow. If when sending the CRLF, the >>> transport reports an error, then the connection is considered to have >>> failed. It is RECOMMENDED that a CRLF be sent if the flow has not >>> had any data sent or received in the previous 500 to 600 seconds. >> >> >> >> this time is way too long. Thing about existing IM clients like AIM. I >> find that AIM detects failed connections within about 30s, indicating >> a keepalive of around that amount of time. Remember, for the duration >> that a bad connection is not detected, there is a gap in availability >> for incoming calls. Rapid detection is essential. >> >> >>> User Agents that form flows with datagram oriented protocols such as >>> UDP SHOULD check if the URI has the "stun" tag (defined in >>> Section 10) and, if the tag is present, >> >> >> >> you need to specify what URI you are talking about here. >> >>> Any time a SIP message is sent and the proxy does not respond, this >>> is also considered a failure, the flow is closed >> >> >> >> how does one close a UDP flow? >> >>> Any time a SIP message is sent and the proxy does not respond, this >>> is also considered a failure, the flow is closed and the procedures >>> in Section 4.1 are followed to form a new flow. >> >> >> >> no - it doesnt follow the procedures in 4.1 yet. It has to figure out >> if it needs to wait. Generally, whenever section 4.2 concludes that a >> connection failed, it should refer to 4.3 for determining when to >> re-establish it. >> >>> however, if there >>> is a failure in forming this flow, the UA needs to wait a certain >>> amount of time before retrying to form a flow to this particular URI >>> in the proxy set. >> >> >> >> important to mention that this is to avoid avalanche restart >> >>> wait-time = min( 1800, (30 * (2 ^ consecutive-failures))) >> >> >> >> this formula doesn't have the base-time in it; 30s is hard-coded. >> >>> These three times SHOULD be configurable in the UA. >> >> >> >> not clear which three you mean. You should explicitly define three >> variables and use them in the equation above. Also, you should talk >> about why they would ever be changed (its based on server capacity). >> >>> o The proxy MUST NOT populate the target set with more than one >>> contact with the same AOR and instance-id at a time. If a request >>> for a particular AOR and instance-id fails with a 410 response, >>> the proxy SHOULD replace the failed branch with another target >>> with the same AOR and instance-id, but a different flow-id. >> >> >> >> >> you should discuss cases like sequential forking, which normally pick >> contacts in q-value order; it won't do that now, and would rather >> initially treat the ones with the same instance ID as a group and pick >> one of those. >> >> >> > Proxies MUST Record-Route so that mid dialog requests are routed over >> > the correct flow. >> >> just edge proxies >> >> > If a proxy or registrar receives a network error when sending a SIP >> > message over a particular flow, it MUST remove all the bindings >> that >> > use that flow (regardless of AOR). >> >> I thought a flow was specific to a single AOR? >> >>> Edge Proxies MUST Record-Route with the same URI that was used in the >>> path so that mid dialog requests still are routed over the correct >>> flow. >> >> >> >> The thing thats MUST strength is record-routing so that mid-dialog >> requests go over the same flow. You can do that without using the same >> URI as in the Path. >> >>> When a URI is created that refers to a SIP device that supports STUN >>> as described in this section, the URI parameter "stun", as defined in >>> Section 10 SHOULD be added to the URI. >> >> >> >> MUST I think >> >>> 9. Grammar >>> >>> This specification defines a new Contact header field parameter, >>> flow-id. The grammar for DIGIT and EQUAL is obtained from RFC 3261 >>> [3]. >> >> >> >> what about the stun parameter (prefer connection-management or >> something similar, per above) >> >> >> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 01 12:22:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd3J-0005jv-N9; Mon, 01 Aug 2005 12:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd3H-0005ji-2F for sip@megatron.ietf.org; Mon, 01 Aug 2005 12:22:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21757 for ; Mon, 1 Aug 2005 12:22:04 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdZZ-0000j0-15 for sip@ietf.org; Mon, 01 Aug 2005 12:55:30 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j71GVedX005661 for ; Mon, 1 Aug 2005 09:31:40 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j71GRHmm001091 for ; Mon, 1 Aug 2005 11:27:18 -0500 (CDT) Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Aug 2005 11:21:59 -0500 Message-ID: <8E4E38BF6D087F4488E80ABAACA2F3F414AE4738@il27exm02.cig.mot.com> From: Kelley Sean-Q12059 To: sip@ietf.org Date: Mon, 1 Aug 2005 11:21:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.8 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sip] Comment on willis-sip-answeralert-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492935774==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0492935774== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C596B5.21BFD356" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C596B5.21BFD356 Content-Type: text/plain Regarding the UAS procedures for handling the Answer-Mode value of "ManualReq", the draft indicates that the UAS SHOULD answer in manual mode, and the UAS SHOULD reject the request if it is unwilling or incapable of answering in manual mode. However, there is a use case for Push to Talk (as it is being specified in OMA) that might justify changing these SHOULDs to SHALLs (similar to how the UAS procedures for handling AutoReq are currently defined). The requesting user may not want their initial talk burst to be automatically played out from the called UA's speaker phone, due to privacy concerns of the calling user. The common example is a mistress who does not want the call to be auto answered, for fear that the wife is present. Another example is when the requesting user is concerned that he/she might be interupting the called user (i.e. calling user suspects that the called user is having lunch with a customer, or is in a meeting) and therefore wants to "politely" alert the user prior to the initial talk burst being played out, in order to giving the called user an opportunity to reject the call. In each of these cases, the calling user's behavior is based upon a "guarantee" from the PoC service that thei! r initial talk burst will only be played out if the called user manually accepts the call. It also would seem more logical to have the semantics of "ManualReq" be truly "manual mode required", rather than the current "manual mode strongly recommended". ------_=_NextPart_001_01C596B5.21BFD356 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUwNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTUxNzU5NTYxNC0wMTA4MjAwNT5S ZWdhcmRpbmcgdGhlIFVBUyANCnByb2NlZHVyZXMgZm9yIGhhbmRsaW5nIHRoZSBBbnN3ZXItTW9k ZSB2YWx1ZSBvZiAiTWFudWFsUmVxIiwgdGhlIGRyYWZ0IA0KaW5kaWNhdGVzIHRoYXQgdGhlIFVB UyBTSE9VTEQgYW5zd2VyIGluIG1hbnVhbCBtb2RlLCBhbmQgdGhlIFVBUyBTSE9VTEQgcmVqZWN0 IA0KdGhlIHJlcXVlc3QgaWYgaXQgaXMgdW53aWxsaW5nIG9yIGluY2FwYWJsZSBvZiBhbnN3ZXJp bmcgaW4gbWFudWFsIA0KbW9kZS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTUxNzU5NTYxNC0wMTA4MjAwNT48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz01MTc1OTU2MTQtMDEwODIwMDU+SG93ZXZlciwgdGhlcmUgaXMgYSANCnVzZSBjYXNlIGZvciBQ dXNoIHRvIFRhbGsgKGFzIGl0IGlzIGJlaW5nIHNwZWNpZmllZCBpbiBPTUEpJm5ic3A7dGhhdCBt aWdodCANCmp1c3RpZnkgY2hhbmdpbmcgdGhlc2UgU0hPVUxEcyB0byBTSEFMTHMgKHNpbWlsYXIg dG8gaG93IHRoZSBVQVMgcHJvY2VkdXJlcyBmb3IgDQpoYW5kbGluZyBBdXRvUmVxIGFyZSBjdXJy ZW50bHkgZGVmaW5lZCkuJm5ic3A7IFRoZSByZXF1ZXN0aW5nIHVzZXIgbWF5IG5vdCB3YW50IA0K dGhlaXIgaW5pdGlhbCB0YWxrIGJ1cnN0IHRvIGJlIGF1dG9tYXRpY2FsbHkgcGxheWVkIG91dCBm cm9tIHRoZSBjYWxsZWQgVUEncyANCnNwZWFrZXIgcGhvbmUsIGR1ZSB0byBwcml2YWN5IGNvbmNl cm5zIG9mIHRoZSBjYWxsaW5nIHVzZXIuJm5ic3A7IFRoZSBjb21tb24gDQpleGFtcGxlIGlzJm5i c3A7YSBtaXN0cmVzcyB3aG8gZG9lcyBub3Qgd2FudCB0aGUgY2FsbCB0byBiZSBhdXRvIGFuc3dl cmVkLCBmb3IgDQpmZWFyIHRoYXQgdGhlIHdpZmUgaXMgcHJlc2VudC4mbmJzcDsgPC9TUEFOPjwv Rk9OVD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTUxNzU5NTYxNC0wMTA4 MjAwNT5Bbm90aGVyIGV4YW1wbGUgaXMgd2hlbiB0aGUgcmVxdWVzdGluZyB1c2VyIGlzIA0KY29u Y2VybmVkIHRoYXQgaGUvc2hlIG1pZ2h0IGJlIGludGVydXB0aW5nIHRoZSBjYWxsZWQgdXNlciAo aS5lLiBjYWxsaW5nIHVzZXIgDQpzdXNwZWN0cyB0aGF0IHRoZSBjYWxsZWQgdXNlciBpcyBoYXZp bmcgbHVuY2ggd2l0aCBhIGN1c3RvbWVyLCBvciBpcyBpbiBhIA0KbWVldGluZykgYW5kIHRoZXJl Zm9yZSB3YW50cyB0byAicG9saXRlbHkiIGFsZXJ0IHRoZSB1c2VyIHByaW9yIHRvIHRoZSBpbml0 aWFsIA0KdGFsayBidXJzdCBiZWluZyBwbGF5ZWQgb3V0LCBpbiBvcmRlciB0byBnaXZpbmcgdGhl IGNhbGxlZCB1c2VyIGFuIG9wcG9ydHVuaXR5IA0KdG8gcmVqZWN0IHRoZSBjYWxsLiZuYnNwOyBJ biBlYWNoIG9mIHRoZXNlIGNhc2VzLCB0aGUgY2FsbGluZyB1c2VyJ3MgYmVoYXZpb3IgaXMgDQpi YXNlZCB1cG9uIGEgImd1YXJhbnRlZSIgZnJvbSB0aGUgUG9DIHNlcnZpY2UgdGhhdCB0aGVpciBp bml0aWFsIHRhbGsgYnVyc3Qgd2lsbCANCm9ubHkgYmUgcGxheWVkIG91dCBpZiB0aGUgY2FsbGVk IHVzZXIgbWFudWFsbHkgYWNjZXB0cyB0aGUgDQpjYWxsLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTE3NTk1NjE0LTAxMDgy MDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFOIGNsYXNzPTUxNzU5NTYxNC0wMTA4MjAwNT5JdCBhbHNvIHdvdWxkIHNlZW0gDQpt b3JlIGxvZ2ljYWwgdG8gaGF2ZSB0aGUgc2VtYW50aWNzIG9mICJNYW51YWxSZXEiIGJlIHRydWx5 ICJtYW51YWwgbW9kZSANCnJlcXVpcmVkIiwgcmF0aGVyIHRoYW4gdGhlIGN1cnJlbnQgIm1hbnVh bCBtb2RlIHN0cm9uZ2x5IA0KcmVjb21tZW5kZWQiLjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9CT0RZ PjwvSFRNTD4NCg== ------_=_NextPart_001_01C596B5.21BFD356-- --===============0492935774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0492935774==-- From sip-bounces@ietf.org Tue Aug 02 06:26:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztyp-0005QB-78; Tue, 02 Aug 2005 06:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztym-0005O0-Vt for sip@megatron.ietf.org; Tue, 02 Aug 2005 06:26:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05979 for ; Tue, 2 Aug 2005 06:26:33 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuVE-0007VC-JF for sip@ietf.org; Tue, 02 Aug 2005 07:00:09 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j72AQT6o023340 for ; Tue, 2 Aug 2005 03:26:29 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j72AWHN6005310 for ; Tue, 2 Aug 2005 05:32:18 -0500 (CDT) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 Aug 2005 15:56:26 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F304B5C29E@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: sip@ietf.org, sip-implementors@cs.columbia.edu Date: Tue, 2 Aug 2005 15:56:24 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [Sip] question rgding call hold X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1706120765==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1706120765== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5974C.A1F275DC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5974C.A1F275DC Content-Type: text/plain I have a query regarding call hold. I am not really sure if this is already discussed, but wanted an advice from the experts here. Is the following call flow acceptable?? Make Call Invite --> 200 ok <-- ACK --> Hold ---> INVITE(sendonly) --> 200 ok(recvonly) <--- ACK --> INVITE(sendrecv) <--- ?????? What should be the response to this INVITE request - 200ok with sendonly or 400 bad request? Wont this INVITE mean, that the remote is trying to release local hold, which is unacceptable? Also, i have not seen any rules regarding this in RFC 3261 or the sipping examples draft. Please redirect me to any other references, which talk about attribute modes in subsequent requests after call hold. Thanks in advance Retesh ------_=_NextPart_001_01C5974C.A1F275DC Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SSBoYXZlIGEgcXVlcnkgDQpyZWdhcmRpbmcgY2FsbCBob2xk LiBJIGFtIG5vdCByZWFsbHkgc3VyZSBpZiB0aGlzIGlzIGFscmVhZHkgZGlzY3Vzc2VkLCBidXQg DQp3YW50ZWQgYW4gYWR2aWNlIGZyb20gdGhlIGV4cGVydHMgaGVyZS48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1Bcmlh bCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0y NTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SXMgdGhlIGZvbGxvd2lu ZyANCmNhbGwgZmxvdyBhY2NlcHRhYmxlPz88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIw MDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+TWFrZSANCkNhbGw8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KSW52aXRlIC0tJmd0OzwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgDQoyMDAgb2sgJmx0Oy0tPC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCkFDSyAtLSZndDs8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+SG9sZCANCi0tLSZndDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KSU5WSVRFKHNlbmRvbmx5KSAtLSZndDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMjAwIG9rKHJlY3Zvbmx5KSAmbHQ7LS0tPC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCkFDSyAtLSZndDs8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+SU5WSVRFKHNlbmRyZWN2KSANCiZsdDstLS0gPz8/Pz8/PC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZh Y2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPldoYXQgc2hv dWxkIGJlIHRoZSANCnJlc3BvbnNlIHRvIHRoaXMgSU5WSVRFIHJlcXVlc3QgLSAyMDBvayB3aXRo IHNlbmRvbmx5IG9yIDQwMCBiYWQgDQpyZXF1ZXN0PzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5X b250IHRoaXMgSU5WSVRFIA0KbWVhbiwgdGhhdCB0aGUgcmVtb3RlIGlzIHRyeWluZyB0byByZWxl YXNlIGxvY2FsIGhvbGQsIHdoaWNoIGlzIA0KdW5hY2NlcHRhYmxlPzwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFs IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1 OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BbHNvLCBpIGhhdmUgbm90 IA0Kc2VlbiBhbnkgcnVsZXMgcmVnYXJkaW5nIHRoaXMgaW4gUkZDIDMyNjEgb3IgdGhlIHNpcHBp bmcgZXhhbXBsZXMgZHJhZnQuIFBsZWFzZSANCnJlZGlyZWN0IG1lIHRvIGFueSBvdGhlciByZWZl cmVuY2VzLCB3aGljaCB0YWxrIGFib3V0IGF0dHJpYnV0ZSBtb2RlcyBpbiANCnN1YnNlcXVlbnQg cmVxdWVzdHMgYWZ0ZXIgY2FsbCBob2xkLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAw NT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFua3MgaW4gDQphZHZhbmNlPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQpzaXplPTI+UmV0ZXNoPC9GT05UPjwvU1BBTj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5974C.A1F275DC-- --===============1706120765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1706120765==-- From sip-bounces@ietf.org Tue Aug 02 06:26:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztz7-0005fv-Bq; Tue, 02 Aug 2005 06:26:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztz5-0005ff-5l for sip@megatron.ietf.org; Tue, 02 Aug 2005 06:26:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05987 for ; Tue, 2 Aug 2005 06:26:52 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuVX-0007Vb-O8 for sip@ietf.org; Tue, 02 Aug 2005 07:00:28 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j72AQYb09407; Tue, 2 Aug 2005 06:26:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Comment on willis-sip-answeralert-00 Date: Tue, 2 Aug 2005 05:26:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF03905E5B@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Comment on willis-sip-answeralert-00 Thread-Index: AcWWtaA8ZWA3ZYfeQi++HeWDEaqgiQAloYgg From: "Francois Audet" To: "Kelley Sean-Q12059" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621927570==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1621927570== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5974C.A7CD4690" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5974C.A7CD4690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we have to distinguish what the IETF produces, i.e., a protocol, versus the service requirement from OMA or whoever wants to use that protocol. =20 I think what we need is an explicit indication similar to Required and Supported that gives no ambiguity to the behavior. (I think the current wording with "SHOULD" is too wishy-washy.) =20 Then, OMA can decides that they support one or the other behavior or both for their own application. =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Kelley Sean-Q12059 Sent: Monday, August 01, 2005 09:22 To: sip@ietf.org Subject: [Sip] Comment on willis-sip-answeralert-00 Regarding the UAS procedures for handling the Answer-Mode value of "ManualReq", the draft indicates that the UAS SHOULD answer in manual mode, and the UAS SHOULD reject the request if it is unwilling or incapable of answering in manual mode. =20 However, there is a use case for Push to Talk (as it is being specified in OMA) that might justify changing these SHOULDs to SHALLs (similar to how the UAS procedures for handling AutoReq are currently defined). The requesting user may not want their initial talk burst to be automatically played out from the called UA's speaker phone, due to privacy concerns of the calling user. The common example is a mistress who does not want the call to be auto answered, for fear that the wife is present. Another example is when the requesting user is concerned that he/she might be interupting the called user (i.e. calling user suspects that the called user is having lunch with a customer, or is in a meeting) and therefore wants to "politely" alert the user prior to the initial talk burst being played out, in order to giving the called user an opportunity to reject the call. In each of these cases, the calling user's behavior is based upon a "guarantee" from the PoC service that their initial talk burst will only be played out if the called user manually accepts the call. =20 It also would seem more logical to have the semantics of "ManualReq" be truly "manual mode required", rather than the current "manual mode strongly recommended". ------_=_NextPart_001_01C5974C.A7CD4690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 think we have to distinguish what the IETF produces, i.e., a protocol, = versus=20 the service requirement from OMA or whoever wants to use that=20 protocol.
 
I=20 think what we need is an explicit indication similar to Required and = Supported=20 that gives no ambiguity to the behavior. (I think the current wording = with=20 "SHOULD" is too wishy-washy.)
 
Then,=20 OMA can decides that they support one or the other behavior or both for = their=20 own application.
 
 
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Kelley=20 Sean-Q12059
Sent: Monday, August 01, 2005 = 09:22
To:=20 sip@ietf.org
Subject: [Sip] Comment on=20 willis-sip-answeralert-00

Regarding the UAS=20 procedures for handling the Answer-Mode value of "ManualReq", the = draft=20 indicates that the UAS SHOULD answer in manual mode, and the UAS = SHOULD reject=20 the request if it is unwilling or incapable of answering in manual=20 mode.
 
However, there is=20 a use case for Push to Talk (as it is being specified in = OMA) that might=20 justify changing these SHOULDs to SHALLs (similar to how the UAS = procedures=20 for handling AutoReq are currently defined).  The requesting user = may not=20 want their initial talk burst to be automatically played out from the = called=20 UA's speaker phone, due to privacy concerns of the calling user.  = The=20 common example is a mistress who does not want the call to be = auto=20 answered, for fear that the wife is present.  Another example = is when the=20 requesting user is concerned that he/she might be interupting the = called user=20 (i.e. calling user suspects that the called user is having lunch with = a=20 customer, or is in a meeting) and therefore wants to "politely" alert = the user=20 prior to the initial talk burst being played out, in order to giving = the=20 called user an opportunity to reject the call.  In each of these = cases,=20 the calling user's behavior is based upon a "guarantee" from the PoC = service=20 that their initial talk burst will only be played out if the called = user=20 manually accepts the call.
 
It = also would seem=20 more logical to have the semantics of "ManualReq" be truly "manual = mode=20 required", rather than the current "manual mode strongly=20 recommended".
------_=_NextPart_001_01C5974C.A7CD4690-- --===============1621927570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1621927570==-- From sip-bounces@ietf.org Tue Aug 02 06:34:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu6a-0000GJ-Aa; Tue, 02 Aug 2005 06:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu6Y-0000Fk-0V for sip@megatron.ietf.org; Tue, 02 Aug 2005 06:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07092 for ; Tue, 2 Aug 2005 06:34:35 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzud0-00086B-AI for sip@ietf.org; Tue, 02 Aug 2005 07:08:11 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2005 12:34:28 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j72AY2E2010881 for ; Tue, 2 Aug 2005 12:34:25 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 12:34:23 +0200 Received: from [86.255.27.246] ([10.58.48.82]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 12:34:23 +0200 Message-ID: <42EF4C2F.8040904@cisco.com> Date: Tue, 02 Aug 2005 06:34:23 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2005 10:34:23.0616 (UTC) FILETIME=[BFCE2000:01C5974D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: 7bit Subject: [Sip] comments on willis-sip-answeralert X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've only followed some of the threads on this, so my apologies if some of this is redundant. I did a detailed read of the doc, here are my comments: > The syntax for the header fields defined in this document is: > Answer-Mode = "Answer-Mode" HCOLON answer-mode > answer-mode = "Manual" / "ManualReq" / "Auto" / "AutoReq" > Alert-Mode = "Alert-Mode" HCOLON alert-mode > alert-mode = "Normal" / "Null" these are not extensible. I think you should make the list extensible. > A UAC supporting this specification indicates its support for this > extension by including an option tag of "answermode" in the Supported > header field of all requests it sends. having a tag called "answermode" which indicates support for an extension that defines BOTH an answer mode and an alert mode seems confusing. Unless you plan on also defining an "alertmode" option tag, you should come up with a different name. > UA includes a SIP extension feature tag of "answermode" in the > Contact: header field of its REGISTER requests. This usage of > feature tags is described in [5]. I don't understand why a new media feature tag is needed. It seems that you could do this with the existing "extensions" feature tag. > To require that the UAS either support this extension or reject the > request, the UAC includes a Required: header field having the value > "answermode". Note that this does not actually force the UAS to s/Required/Require > To request that retargeting proxies in the path preferentially select > targets that have indicated support for this extension in their > registration, a UAC includes an Accept-Contact header field having a > parameter of "answermode". This usage of Accept-Contact is described > in [6]. I'd suggest better guidance on usage of caller prefs here. You list all of the combinations of require and explicit. I think its easier; if the request has a Require header field for answermode, you would use the "require" parameter. If not, then nothing. > existing header field in accord with local policy. Note that this > may result in behavior that is inconsistent with user expectations, > such as having a call that was intended to be a diagnostic loopback > answered by a human, and consequently must be done very carefully. why are we allowing this? as you say it seems like a recipe for trouble. > For a request having an Answer-Mode value of "Manual", the UAS SHOULD > defer accepting the request until the user of the UAS has confirmed > willingness to accept the request. This behavior MAY be altered as > needed for unattended UAS or other local characteristics or policy. > For example, an auto-attendant system that always answers > automatically would go ahead and answer, despite the presence of the > "Manual" Answer-Mode header field value. what about a pstn gateway? > unwilling to do so, it SHOULD reject the request with a "403 > Forbidden" response and MAY include a Reason [7] header field value > of: > > Reason: SIP ;cause=403 ;text="manual answer forbidden" well, folks know my opinion on this. See RFC3326: 2. The Reason Header Field The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. > For a request having an Answer-Mode value of "Auto", the UAS SHOULD, > if the calling party is authenticated and authorized for automatic > answering, accept the request without further user input. The UAS > MAY, according to local policy or user preferences, treat this > request as it would treat a request having a Answer-Mode with a value > of "Manual" or having no Answer-Mode header field. If the calling I am very uncomfortable with this wording. I think authorization is a MUST, and the text here doesnt make that clear. > this aspect into consideration. In general, auto-answer is probably > NOT RECOMMENDED in environments that include forking. What?? I disagree. I think it makes a ton of sense. The typical walkkie-talkie experience would result in a conference - thats the desired behavior we should specify. > Another alternative would be to use dynamic conferencing instead of > forking. In this approach, instead of forking the request, a > conference would be initiated and all UAs invited into that > conference. The mixer attached to the conference would then mediate > traffic flows appropriately. These are not mutually exclusive; if a request forks, and you get multiple 200 OK - thats fine. The UAC would create a conference immediately, either through endpoint mixing or pushing everyone into a conference server. > Normal: The UAS is asked to treat the request as it normally would in > the absence of this specification and exercise whatever alerting > mechanism it might have and be configured to use. > Null: The UAS is asked to not alert its user to the request. I think its worthwhile documenting somewhere the interactions of alert and answer modes - in particular, what combinations make sense? > If the conclusion is to alert the user, the UAS invokes its preferred > alerting mechanism. If the conclusion is to not alert the user, the > UAS proceeds to process the request. Note that the decision of > whether to accept the request is independent of the alerting > decision, but one can generally not expect the user to make this > decision unless the user has been alerted to the request. I think you need more discussion of what a UAS does if it doesnt alert the user; how can it proceed with the call? Answermode is one thing, diagnostics are another, etc. > A UAS supporting this specification inserts a Answer-Mode header > field into the 200 OK response to an INVITE request when it wishes to > inform the UAC as to whether the request was answered manually or > automatically. The full rationale for including or not including > this header field in a response is outside of the scope of this > specification. I think you need to discuss it. > Consequently, the UAS generally or its supporting proxy MUST > authenticate the sender of such requests, using mechanisms such as If you are allowing proxies to do the authorization, you need a way to securely inform the UAS that it has been done. Otherwise, misconfiguration (proxy thinks UAS is authorizing, UAS thinks proxy is authorizing) can introduce attacks. I think we should strive for safety here; misconfiguration cannot easily cause an attack. As you know, these attacks have been a MAJOR issue in bluetooth - let us be extremely cautious here. Furthermore, the behavior of the UAS and proxy for authentication and authorization cannot only be documented in the security considerations section. From the IANA considerations: > The following rows shall be added to the "Option Tags" section of the > SIP Parameters registry: > > +----------------------+----------------------+---------------------+ > | Name | Description | Reference | > +----------------------+----------------------+---------------------+ > | answermode | This option tag is | [RFCXXXX] | > | | used in a Requires | | > | | header field to | | > | | indicate that the | | > | | UAS must support | | > | | negotiation of | | > | | answer mode. | | > | alertmode | This option tag is | [RFCXXXX] | > | | used in a Requires | | ok - so you have two option tags here. The doc only talks about one. Maybe a typo? Also, no IANA registration for media feature tags, though I dont think you need them anyway. minor things > SDP usage for this sort of flow is described in [11]. In this sort > of application, it may not be needful that the human using the node may not be necessary > Req-5: It MUST be possible for UAC to indicate at least two different > priority levels for the desired answer mode. We refer to these as > "normal" and "override" priorities. In normal usage, we expect > that "normal" priority would be used in a user-to-user fashion, > whereas "override" priorities would be used for diagnostic > procedures or some sorts of emergency session establishment. this requirement says how priorities get used, but doesnt define what their semantics are. > Req-8: It MUST be possible for the UAC to construct the request in > such a way that the routing proxy infrastructure, if present, will > select only contacts supporting the selection of answer modes. This is clearly alluding to caller prefs. Its important to note that caller prefs genreally prefers to try a contact, even if you are unusure it supports a capability, rather than reject one you're not sure about. In this particular case, avoiding ringing these devices is an optimization. Thus, I think the requirement here is better worded as: "...will prefer contacts supporting the selection of answer modes." > Req-19: UAS SHOULD accurately represent the answering mode that was > applied, but MAY either not include this information or MAY > misinform UAC in order to maintain the privacy expectations of > UAS-user. Consequently, applications MUST NOT rely on the > veracity of this information. this seems like a requirement in the protocol itself, rather than a requirement for building a protocol. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 02 06:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuEf-0003f8-DH; Tue, 02 Aug 2005 06:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuEc-0003as-2s for sip@megatron.ietf.org; Tue, 02 Aug 2005 06:42:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07980 for ; Tue, 2 Aug 2005 06:42:54 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzul3-0000BC-SE for sip@ietf.org; Tue, 02 Aug 2005 07:16:31 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j72Aqbm3021582 for ; Tue, 2 Aug 2005 03:52:37 -0700 (MST) Received: from zin24exm02.corp.mot.com (zin24exm02.ap.mot.com [10.232.26.1]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j72AnXek000853 for ; Tue, 2 Aug 2005 05:49:34 -0500 (CDT) Received: by zin24exm02.ap.mot.com with Internet Mail Service (5.5.2657.72) id <3MB3CY5W>; Tue, 2 Aug 2005 16:12:52 +0530 Message-ID: <19B94C8C331A7546A88C88502083353B01D0634F@zin24exm02.ap.mot.com> From: Avasarala Ranjit-A20990 To: Chadha Retesh-A19894 , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: RE: [Sip] question rgding call hold Date: Tue, 2 Aug 2005 16:12:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1379750882==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1379750882== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5974E.EE272234" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5974E.EE272234 Content-Type: text/plain Retesh inline Regards Ranjit _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chadha Retesh-A19894 Sent: Tuesday, August 02, 2005 3:56 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] question rgding call hold I have a query regarding call hold. I am not really sure if this is already discussed, but wanted an advice from the experts here. Is the following call flow acceptable?? Make Call Invite --> 200 ok <-- ACK --> Hold ---> INVITE(sendonly) --> 200 ok(recvonly) <--- ACK --> INVITE(sendrecv) <--- ?????? [Ranjit] INVITE (sendrecv) ---> The UA that is on hold cannot send INVITE for resume What should be the response to this INVITE request - 200ok with sendonly or 400 bad request? Wont this INVITE mean, that the remote is trying to release local hold, which is unacceptable? Also, i have not seen any rules regarding this in RFC 3261 or the sipping examples draft. Please redirect me to any other references, which talk about attribute modes in subsequent requests after call hold. Thanks in advance Retesh ------_=_NextPart_001_01C5974E.EE272234 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzQ4 MTk0MTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5S ZXRlc2g8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NzQ4MTk0MTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZm IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NzQ4MTk0MTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xv cj0jMDAwMGZmIHNpemU9Mj5pbmxpbmUmbmJzcDsgPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc0ODE5NDExMC0wMjA4MjAwNT48Rk9OVCBm YWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc0ODE5NDExMC0wMjA4MjAw NT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3J0ZiBmb3JtYXQgLS0+ DQo8UD48U1BBTiBsYW5nPWVuLXVzPjxCPjxJPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwODA4 MCANCnNpemU9Mj5SZWdhcmRzPC9GT05UPjwvST48L0I+PC9TUEFOPiA8QlI+PFNQQU4gbGFuZz1l bi11cz48Qj48ST48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwODA4MCBzaXplPTI+UmFuaml0 PC9GT05UPjwvST48L0I+PC9TUEFOPiA8L1A+PEJSPjxCUj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PEZPTlQgZmFjZT1Bcmlh bCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48QlI+DQo8RElWIGNsYXNzPU91dGxvb2tN ZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KPEhSIHRhYkluZGV4 PS0xPg0KPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBzaXAtYm91bmNlc0Bp ZXRmLm9yZyANClttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiA8 L0I+Q2hhZGhhIA0KUmV0ZXNoLUExOTg5NDxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwgQXVndXN0 IDAyLCAyMDA1IDM6NTYgUE08QlI+PEI+VG86PC9CPiANCnNpcEBpZXRmLm9yZzsgc2lwLWltcGxl bWVudG9yc0Bjcy5jb2x1bWJpYS5lZHU8QlI+PEI+U3ViamVjdDo8L0I+IFtTaXBdIHF1ZXN0aW9u IA0KcmdkaW5nIGNhbGwgaG9sZDxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PkkgaGF2ZSBhIHF1ZXJ5IA0KcmVnYXJkaW5nIGNhbGwgaG9sZC4gSSBhbSBub3QgcmVhbGx5IHN1 cmUgaWYgdGhpcyBpcyBhbHJlYWR5IGRpc2N1c3NlZCwgYnV0IA0Kd2FudGVkIGFuIGFkdmljZSBm cm9tIHRoZSBleHBlcnRzIGhlcmUuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPklzIHRoZSBmb2xsb3dpbmcgDQpjYWxsIGZsb3cgYWNjZXB0 YWJsZT8/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAy MDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPk1ha2UgDQpDYWxsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9 MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyANCkludml0ZSAtLSZndDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFz cz0yNTkzOTE1MTAtMDIwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KMjAwIG9rICZsdDstLTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNs YXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsmbmJz cDsmbmJzcDsgDQpBQ0sgLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhvbGQgDQotLS0m Z3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgy MDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyANCklOVklURShz ZW5kb25seSkgLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5 MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNw OyANCjIwMCBvayhyZWN2b25seSkgJmx0Oy0tLTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJz cDsmbmJzcDsmbmJzcDsgDQpBQ0sgLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQpzaXpl PTI+SU5WSVRFKHNlbmRyZWN2KSAmbHQ7LS0tID8/Pz8/PzxTUEFOIGNsYXNzPTc0ODE5NDExMC0w MjA4MjAwNT48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1 PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NzQ4MTk0MTEwLTAy MDgyMDA1PjxGT05UIGNvbG9yPSMwMDAwZmY+W1JhbmppdF0gSU5WSVRFIChzZW5kcmVjdikgDQot LS0mZ3Q7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9NzQ4MTk0MTEwLTAyMDgyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NzQ4MTk0MTEwLTAyMDgy MDA1PjxGT05UIGNvbG9yPSMwMDAwZmY+VGhlIFVBIHRoYXQgaXMgb24gaG9sZCBjYW5ub3Qgc2Vu ZCANCklOVklURSBmb3IgcmVzdW1lPC9GT05UPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZh Y2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4g Y2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPldoYXQgc2hv dWxkIGJlIHRoZSANCnJlc3BvbnNlIHRvIHRoaXMgSU5WSVRFIHJlcXVlc3QgLSAyMDBvayB3aXRo IHNlbmRvbmx5IG9yIDQwMCBiYWQgDQpyZXF1ZXN0PzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5X b250IHRoaXMgSU5WSVRFIA0KbWVhbiwgdGhhdCB0aGUgcmVtb3RlIGlzIHRyeWluZyB0byByZWxl YXNlIGxvY2FsIGhvbGQsIHdoaWNoIGlzIA0KdW5hY2NlcHRhYmxlPzwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFs IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1 OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BbHNvLCBpIGhhdmUgbm90 IA0Kc2VlbiBhbnkgcnVsZXMgcmVnYXJkaW5nIHRoaXMgaW4gUkZDIDMyNjEgb3IgdGhlIHNpcHBp bmcgZXhhbXBsZXMgZHJhZnQuIFBsZWFzZSANCnJlZGlyZWN0IG1lIHRvIGFueSBvdGhlciByZWZl cmVuY2VzLCB3aGljaCB0YWxrIGFib3V0IGF0dHJpYnV0ZSBtb2RlcyBpbiANCnN1YnNlcXVlbnQg cmVxdWVzdHMgYWZ0ZXIgY2FsbCBob2xkLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI1OTM5MTUxMC0wMjA4MjAw NT48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFua3MgaW4gDQphZHZhbmNlPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjU5MzkxNTEwLTAyMDgyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQpzaXplPTI+UmV0ZXNoPC9GT05UPjwvU1BBTj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5974E.EE272234-- --===============1379750882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1379750882==-- From sip-bounces@ietf.org Tue Aug 02 07:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzv9q-0000Xw-CP; Tue, 02 Aug 2005 07:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzv9o-0000WM-Ib for sip@megatron.ietf.org; Tue, 02 Aug 2005 07:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12846 for ; Tue, 2 Aug 2005 07:42:03 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzvgI-0003SU-1r for sip@ietf.org; Tue, 02 Aug 2005 08:15:38 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2005 13:41:55 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j72BfqDg026473; Tue, 2 Aug 2005 13:41:52 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Aug 2005 13:41:50 +0200 Received: from cisco.com ([10.61.80.181]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Aug 2005 13:41:50 +0200 Message-ID: <42EF5BFD.1090402@cisco.com> Date: Tue, 02 Aug 2005 07:41:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chadha Retesh-A19894 Subject: Re: [Sip] question rgding call hold References: <772BCEF88A1DD91191F80011856715F304B5C29E@zin24exm01.ap.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2005 11:41:50.0681 (UTC) FILETIME=[2C0B3C90:01C59757] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Chadha Retesh-A19894 wrote: > I have a query regarding call hold. I am not really sure if this is > already discussed, but wanted an advice from the experts here. > > Is the following call flow acceptable?? > > Make Call > Invite --> > 200 ok <-- > ACK --> > Hold ---> > INVITE(sendonly) --> > 200 ok(recvonly) <--- > ACK --> > INVITE(sendrecv) <--- ?????? > > What should be the response to this INVITE request - 200ok with sendonly > or 400 bad request? IMO this is clearly a valid request. Barring other issues, the response should be 200. The direction in the response could be sendrecv/sendonly/recvonly/inactive since all are compatible with the offer. If the end answering that offer wants to preserve the status quo, then it should simply respond with a=sendonly. > Wont this INVITE mean, that the remote is trying to release local hold, > which is unacceptable? All this has done then is that the party on the right has indicated a *willingness* or *desire* to go off hold, while the party on the left has indicated it still wants to maintain the call on hold. There is no way that the party on the right can *force* the call out of hold state. > Also, i have not seen any rules regarding this in RFC 3261 or the > sipping examples draft. Please redirect me to any other references, > which talk about attribute modes in subsequent requests after call hold. I'm not aware of much that has been published on this, though it has been discussed on this list several times. I think this behavior is implicit in the specs, but it clearly isn't especially obvious. The spec that has anything to say about this is RFC3264. Paul > Thanks in advance > Retesh > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 02 09:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwOC-0001CH-Ga; Tue, 02 Aug 2005 09:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwO5-00019D-Sm for sip@megatron.ietf.org; Tue, 02 Aug 2005 09:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16770 for ; Tue, 2 Aug 2005 09:00:52 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwuY-0006eK-Sg for sip@ietf.org; Tue, 02 Aug 2005 09:34:28 -0400 Received: from [86.255.30.224] (open-30-224.ietf63.ietf.org [86.255.30.224]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j72D0gkr009558 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 2 Aug 2005 08:00:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <92bf630ebed81417877cc8180ace845a@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 2 Aug 2005 15:00:40 +0200 To: "sip@ietf.org WG" X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 86.255.30.224 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Sip] REFER norefersub Max-Forwards question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org During today's meeting, we discussed whether the text noting that Max-Forwards:0 can be used to avoid forking should be included in the norefersub draft. The text in question is: The best way that the REFER-Issuer can ensure that REFER doesn't get forked is by only sending a REFER with "Refer-Sub" with a Request-URI which has GRUU properties according to definitions of [5]. If this is not known, the other way to ensure that forking will not occur is to ensure that there are no proxies between the REFER-Issuer and the REFER-Recipient. This could be done by sending the REFER with a Max-Forwards: 0 header field. Any proxy receiving this request will return a "483 Too Many Hops" response, indicating that it is not safe to use this extension. Cullen expressed a concern that this looks like a recommendation from the IETF that this is the way forking should be avoided in general. That was never the intent to my knowledge, and on re-read, I agree that the text as is can be interpreted that way. I offer the following repair: If a REFER request to a given Request-URI might fork, the REFER-Issuer SHOULD NOT include the "Refer-Sub" header field. It is RECOMMENDED that a Request-URI that has GRUU properties according to the definitions of [5] be used to ensure the REFER request will not fork. In some specialized environments, the REFER-Issuer MAY use other techniques to be sure the REFER request will not fork, For example, in a constrained network where it is known with absolute certainty that all UAs can reach each other without the use of any proxy, the REFER- Issuer could include a Max-Forwards header field with a value of 0 to prevent forking (if, for some reason, a proxy found itself on the path of that request, it would return a 483 Too Many Hops response). RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 02 10:42:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxyH-0006gb-Dj; Tue, 02 Aug 2005 10:42:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxyE-0006ek-Lq for sip@megatron.ietf.org; Tue, 02 Aug 2005 10:42:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25012 for ; Tue, 2 Aug 2005 10:42:16 -0400 (EDT) Received: from rat01037.dc-ratingen.de ([195.233.129.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyUd-00035h-2z for sip@ietf.org; Tue, 02 Aug 2005 11:15:54 -0400 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id j72Eg7tX029926 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 2 Aug 2005 16:42:07 +0200 (MEST) Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id j72EffDm026656; Tue, 2 Aug 2005 16:42:06 +0200 (MEST) Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by gpsmxr04.gps.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 16:41:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comment on willis-sip-answeralert-00 Date: Tue, 2 Aug 2005 15:41:57 +0100 Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B021BF72C@gpsmx11.gps.internal.vodafone.com> Thread-Topic: [Sip] Comment on willis-sip-answeralert-00 Thread-Index: AcWWtaA8ZWA3ZYfeQi++HeWDEaqgiQAloYggAAigjFA= From: "Zisimopoulos, Haris, VF-Group" To: "Francois Audet" , "Kelley Sean-Q12059" , X-OriginalArrivalTime: 02 Aug 2005 14:41:56.0275 (UTC) FILETIME=[54AE0830:01C59770] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The point is that the description of ManualReq states : =20 "The UAS is also asked NOT to answer automatically, and to reject the request if it is unwilling to answer manually." This is exactly similar to this of AutoReq but when it comes to the description of the procedures of UAS for the AutoReq it is stated that:=20 "The UAS MUST NOT allow "manual" answer of this request, but MAY reject it." But for the ManualReq it is stated:=20 "If the UAS is not capable of answering the request in this "Manual" mode or is unwilling to do so, it SHOULD reject the request with a "403 Forbidden" response..." So the normative behaviour of the UAS when it comes to processing ManualReq and AutoReq is not similar, which from protocol point of view does not make sense given that these header fields convey exactly the same "meaning":=20 If the terminating point cannot answer the request either manually or auto (depending if ManualReq or AutoReq is used) then reject it.=20 AutoReq and ManualReq needs to be mandatory in order to make sense for the UAC to use it for any usage (PoC or not) and be different from Manual and Auto. I cannot understand where it helps if it is wishy-washy. Best regards, Haris=20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: 02 August 2005 11:27 To: Kelley Sean-Q12059; sip@ietf.org Subject: RE: [Sip] Comment on willis-sip-answeralert-00 =09 =09 I think we have to distinguish what the IETF produces, i.e., a protocol, versus the service requirement from OMA or whoever wants to use that protocol. =20 I think what we need is an explicit indication similar to Required and Supported that gives no ambiguity to the behavior. (I think the current wording with "SHOULD" is too wishy-washy.) =20 Then, OMA can decides that they support one or the other behavior or both for their own application. =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Kelley Sean-Q12059 Sent: Monday, August 01, 2005 09:22 To: sip@ietf.org Subject: [Sip] Comment on willis-sip-answeralert-00 =09 =09 Regarding the UAS procedures for handling the Answer-Mode value of "ManualReq", the draft indicates that the UAS SHOULD answer in manual mode, and the UAS SHOULD reject the request if it is unwilling or incapable of answering in manual mode. =20 However, there is a use case for Push to Talk (as it is being specified in OMA) that might justify changing these SHOULDs to SHALLs (similar to how the UAS procedures for handling AutoReq are currently defined). The requesting user may not want their initial talk burst to be automatically played out from the called UA's speaker phone, due to privacy concerns of the calling user. The common example is a mistress who does not want the call to be auto answered, for fear that the wife is present. Another example is when the requesting user is concerned that he/she might be interupting the called user (i.e. calling user suspects that the called user is having lunch with a customer, or is in a meeting) and therefore wants to "politely" alert the user prior to the initial talk burst being played out, in order to giving the called user an opportunity to reject the call. In each of these cases, the calling user's behavior is based upon a "guarantee" from the PoC service that their initial talk burst will only be played out if the called user manually accepts the call. =20 It also would seem more logical to have the semantics of "ManualReq" be truly "manual mode required", rather than the current "manual mode strongly recommended". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 02 11:47:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyzS-0004Dm-Nh; Tue, 02 Aug 2005 11:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyzR-0004B5-0d for sip@megatron.ietf.org; Tue, 02 Aug 2005 11:47:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00381 for ; Tue, 2 Aug 2005 11:47:33 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzVt-0006Tr-4Z for sip@ietf.org; Tue, 02 Aug 2005 12:21:12 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 5801C6C01C for ; Tue, 2 Aug 2005 11:47:25 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sip] Re: sip-target-dialog-01 Date: Tue, 2 Aug 2005 11:44:42 -0400 Message-ID: <06e901c59779$1a761370$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42ECD070.7080102@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Cullen Jennings wrote: > > > Right now, most implementations I have > > seen are using pseudo random (not crypto random) numbers for things like to > > and from tags. If they support this mechanism, then they need to start using > > crypto random. This may be a little hard for large GWs as they don't have > > many sources of randomness (such as disk drives etc) and they have to > > produce lots of these numbers. I think it should be possible given that they > > do have lots of somewhat random network events. Deriving a large number of high-quality random numbers from a limited source of randomness isn't as hard as it seems. There are a number of known ways to do this. The concept is that a crypto function is used to disguise a series of pseudo-random numbers that is initialized from a truly random source. RFC 1750 gives some pointers. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 01:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0BMQ-0007i7-QF; Wed, 03 Aug 2005 01:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0BMN-0007fp-H1 for sip@megatron.ietf.org; Wed, 03 Aug 2005 01:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07853 for ; Wed, 3 Aug 2005 01:00:07 -0400 (EDT) Received: from bay14-f30.bay14.hotmail.com ([64.4.49.30] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Bsu-0002sk-1k for sip@ietf.org; Wed, 03 Aug 2005 01:33:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Aug 2005 21:59:51 -0700 Message-ID: Received: from 80.15.249.149 by by14fd.bay14.hotmail.msn.com with HTTP; Wed, 03 Aug 2005 04:59:50 GMT X-Originating-IP: [210.51.195.2] X-Originating-Email: [cyyyuanyou@hotmail.com] X-Sender: cyyyuanyou@hotmail.com From: "cai youyuan" To: sip@ietf.org Date: Wed, 03 Aug 2005 12:59:50 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 03 Aug 2005 04:59:51.0598 (UTC) FILETIME=[2E5CFCE0:01C597E8] X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA07853 Subject: [Sip] how to understand this sentence? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, In TS 23.228, "the private identity identifies the subscription, not th= e=20 user", can I understand user can have several private identities if he ha= ve=20 several subscriptin services? if user want to register, he use which=20 private identity? expect your anser, thx _________________________________________________________________ =CF=ED=D3=C3=CA=C0=BD=E7=C9=CF=D7=EE=B4=F3=B5=C4=B5=E7=D7=D3=D3=CA=BC=FE=CF= =B5=CD=B3=A1=AA MSN Hotmail=A1=A3 http://www.hotmail.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 01:31:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Bqu-0008Tb-4U; Wed, 03 Aug 2005 01:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Bqp-0008Qr-PH for sip@megatron.ietf.org; Wed, 03 Aug 2005 01:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09167 for ; Wed, 3 Aug 2005 01:31:33 -0400 (EDT) Received: from ebb04.tietoenator.com ([194.142.141.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0CNR-0003yl-61 for sip@ietf.org; Wed, 03 Aug 2005 02:05:17 -0400 Message-ID: <42F056AA.8010909@tietoenator.com> Date: Wed, 03 Aug 2005 08:31:22 +0300 From: Petteri Hallikainen Organization: TietoEnator User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2005 05:31:23.0006 (UTC) FILETIME=[95BAF1E0:01C597EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] Using SIP to start RTSP session for recording videomail? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: petteri.hallikainen@tietoenator.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello all, Have there ever been any discussion of using SIP for starting a RTSP session for recording a videomail ? By videomail I mean same kind of service than voicemail but with video capability, i.e., user could record a video instead plain voice. I do not know if this is a right forum for this kind issue, but anyway. I am looking that I could indicate perhaps in SDP when caller sends INVITE to callee and callee is not reachable, the proxy could send in the SDP the parameters to RTSP server and the streaming server can then establish a session for recording after user sends starts the set up, What I am looking for could look like: a=record a=path:rtsp://videomail.example.com/bob> Or is there some other much usable existing ways of doing this kind of service for SIP users? +--------------------------------------------+ Petteri Hallikainen +358 40 706 4037 P.O Box 171, FI-00381, HELSINKI +--------------------------------------------+ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 02:38:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0CtF-0005yt-Og; Wed, 03 Aug 2005 02:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0CtD-0005yo-Jt for sip@megatron.ietf.org; Wed, 03 Aug 2005 02:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17810 for ; Wed, 3 Aug 2005 02:38:06 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0DPq-0006WZ-S9 for sip@ietf.org; Wed, 03 Aug 2005 03:11:51 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2005 08:37:58 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j736b6E4017015 for ; Wed, 3 Aug 2005 08:37:55 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Aug 2005 08:37:36 +0200 Received: from cisco.com ([10.61.64.100]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Aug 2005 08:37:36 +0200 Message-ID: <42F0662F.3030005@cisco.com> Date: Wed, 03 Aug 2005 02:37:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on willis-sip-answeralert References: <42EF4C2F.8040904@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2005 06:37:36.0291 (UTC) FILETIME=[D5FE1F30:01C597F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Further comments inline. Paul Jonathan Rosenberg wrote: >> To request that retargeting proxies in the path preferentially select >> targets that have indicated support for this extension in their >> registration, a UAC includes an Accept-Contact header field having a >> parameter of "answermode". This usage of Accept-Contact is described >> in [6]. > > I'd suggest better guidance on usage of caller prefs here. You list all > of the combinations of require and explicit. I think its easier; if the > request has a Require header field for answermode, you would use the > "require" parameter. If not, then nothing. Of course the callerprefs could be used in more complex ways to achieve a variety of objectives, and there is no reason to restrict that. But I agree it would be good to call out the cases of primary interest and give explicit guidance on how to achieve those. Since this is intended for an IMS/OMA environment, there may be additional questions about how callerprefs apply to selection of application servers in that environment. (Where those servers typically aren't registered.) But that is perhaps out of scope here. >> this aspect into consideration. In general, auto-answer is probably >> NOT RECOMMENDED in environments that include forking. > > What?? I disagree. I think it makes a ton of sense. The typical > walkkie-talkie experience would result in a conference - thats the > desired behavior we should specify. > >> Another alternative would be to use dynamic conferencing instead of >> forking. In this approach, instead of forking the request, a >> conference would be initiated and all UAs invited into that >> conference. The mixer attached to the conference would then mediate >> traffic flows appropriately. > > These are not mutually exclusive; if a request forks, and you get > multiple 200 OK - thats fine. The UAC would create a conference > immediately, either through endpoint mixing or pushing everyone into a > conference server. It isn't even necessary to create a full conference here. It would be possible to just accept both calls, send to both, and receive from both. >> Normal: The UAS is asked to treat the request as it normally would in >> the absence of this specification and exercise whatever alerting >> mechanism it might have and be configured to use. >> Null: The UAS is asked to not alert its user to the request. > > > I think its worthwhile documenting somewhere the interactions of alert > and answer modes - in particular, what combinations make sense? > > > If the conclusion is to alert the user, the UAS invokes its preferred > > alerting mechanism. If the conclusion is to not alert the user, the > > UAS proceeds to process the request. Note that the decision of > > whether to accept the request is independent of the alerting > > decision, but one can generally not expect the user to make this > > decision unless the user has been alerted to the request. > > I think you need more discussion of what a UAS does if it doesnt alert > the user; how can it proceed with the call? Answermode is one thing, > diagnostics are another, etc. Yes. I think there are some major security concerns here. I think there are major questions whether it is ever safe to answer automatically if that would result in becoming a monitoring device. Diagnostic loopback mode is safer because the caller isn't getting anything remarkable from the environment of the callee. And PTT is safe because the callee is receive-only when it answers. (The callee has to do something overt to transmit.) In the case of autoanswer on a traditional audio call it would be safer if the device answered in receiveonly (muted) mode, and again had to take some overt action to transmit. There are of course exceptions to this: automatons may answer automatically even without being asked. And in some cases (such as an agent phone in a call center) it is appropriate to do a brief alert and then answer automatically in sendrecv mode. Because of the exceptions I think it is hard to do much except provide guidelines, but even that would be helpful. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 04:18:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EOR-0004X8-4A; Wed, 03 Aug 2005 04:14:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EOO-0004Tn-1y for sip@megatron.ietf.org; Wed, 03 Aug 2005 04:14:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23805 for ; Wed, 3 Aug 2005 04:14:22 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Ev2-0002a2-CN for sip@ietf.org; Wed, 03 Aug 2005 04:48:08 -0400 Received: from [86.255.28.232] (open-28-232.ietf63.ietf.org [86.255.28.232]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j738HKH8028004 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Aug 2005 03:17:22 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <565e9d2fe094aa7549e91955a09e2c67@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] how to understand this sentence? Date: Wed, 3 Aug 2005 10:13:23 +0200 To: "cai youyuan" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Aug 3, 2005, at 6:59 AM, cai youyuan wrote: > Hi, > In TS 23.228, "the private identity identifies the subscription, not > the user", can I understand user can have several private identities > if he have several subscriptin services? if user want to register, he > use which private identity? > > expect your anser, thx > While individuals here may have opinions, it's probably not in the domain of the IETF to respond authoritatively to questions about 3GPP specifications. My understanding is that the "private" identity is generally the SIM card, and so there's only one private identity per subscriber in the 3GPP data model. Of course, some people have multiple SIM cards and switch them out. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 04:18:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EKp-000102-Fh; Wed, 03 Aug 2005 04:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EKn-0000z1-7u for sip@megatron.ietf.org; Wed, 03 Aug 2005 04:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23551 for ; Wed, 3 Aug 2005 04:10:39 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ErQ-0002OR-Uc for sip@ietf.org; Wed, 03 Aug 2005 04:44:25 -0400 Received: from [86.255.28.232] (open-28-232.ietf63.ietf.org [86.255.28.232]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j738EVs9027948 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Aug 2005 03:14:33 -0500 In-Reply-To: <42EF4C2F.8040904@cisco.com> References: <42EF4C2F.8040904@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] comments on willis-sip-answeralert Date: Wed, 3 Aug 2005 10:10:34 +0200 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the detailed response. I'll respond point-by-point. On Aug 2, 2005, at 12:34 PM, Jonathan Rosenberg wrote: > I've only followed some of the threads on this, so my apologies if > some of this is redundant. I did a detailed read of the doc, here are > my comments: > > >> The syntax for the header fields defined in this document is: >> Answer-Mode = "Answer-Mode" HCOLON answer-mode >> answer-mode = "Manual" / "ManualReq" / "Auto" / "AutoReq" >> Alert-Mode = "Alert-Mode" HCOLON alert-mode >> alert-mode = "Normal" / "Null" > > these are not extensible. I think you should make the list extensible. > ok. Do we need to IANA register extensions, and if so, what should the IANA admissions requirement be? >> A UAC supporting this specification indicates its support for this >> extension by including an option tag of "answermode" in the >> Supported >> header field of all requests it sends. > > having a tag called "answermode" which indicates support for an > extension that defines BOTH an answer mode and an alert mode seems > confusing. Unless you plan on also defining an "alertmode" option tag, > you should come up with a different name. > It's in there. > >> UA includes a SIP extension feature tag of "answermode" in the >> Contact: header field of its REGISTER requests. This usage of >> feature tags is described in [5]. > > I don't understand why a new media feature tag is needed. It seems > that you could do this with the existing "extensions" feature tag. > Might work. I'm afraid I don't understand the caller preferences stuff at all, despite numerous re-readings. Paul K provided the initial "callerprefs" review on the draft. Please send text. > >> To require that the UAS either support this extension or reject the >> request, the UAC includes a Required: header field having the value >> "answermode". Note that this does not actually force the UAS to > > s/Required/Require good catch, thanks. > >> To request that retargeting proxies in the path preferentially select >> targets that have indicated support for this extension in their >> registration, a UAC includes an Accept-Contact header field having >> a >> parameter of "answermode". This usage of Accept-Contact is >> described >> in [6]. > > I'd suggest better guidance on usage of caller prefs here. You list > all of the combinations of require and explicit. I think its easier; > if the request has a Require header field for answermode, you would > use the "require" parameter. If not, then nothing. That's the proposal we made during the discussion in the SIP meeting. > >> existing header field in accord with local policy. Note that this >> may result in behavior that is inconsistent with user expectations, >> such as having a call that was intended to be a diagnostic loopback >> answered by a human, and consequently must be done very carefully. > > why are we allowing this? as you say it seems like a recipe for > trouble. There seems to be a use case for "polite" feature filtering at intermediate proxies, where (based on receiving user profile at the proxy), said proxy compensates for limitations in the authorization model of the called device by filtering out or changing alerting and answering mode settings. > >> For a request having an Answer-Mode value of "Manual", the UAS SHOULD >> defer accepting the request until the user of the UAS has confirmed >> willingness to accept the request. This behavior MAY be altered as >> needed for unattended UAS or other local characteristics or policy. >> For example, an auto-attendant system that always answers >> automatically would go ahead and answer, despite the presence of >> the >> "Manual" Answer-Mode header field value. > > what about a pstn gateway? Not sure I understand this question. PSTN gateways don't normally send a 200 OK until they've received an "answer" message from the PSTN side indicating that some user-entity has accepted the request. I suppose a plain analog gateway might auto-answer, then out-tone the dialed digits. > >> unwilling to do so, it SHOULD reject the request with a "403 >> Forbidden" response and MAY include a Reason [7] header field value >> of: >> Reason: SIP ;cause=403 ;text="manual answer forbidden" > > > well, folks know my opinion on this. See RFC3326: > > 2. The Reason Header Field > > The Reason header field MAY appear in any request within a dialog, > in > any CANCEL request and in any response whose status code explicitly > allows the presence of this header field. > So what does that mean? > >> For a request having an Answer-Mode value of "Auto", the UAS SHOULD, >> if the calling party is authenticated and authorized for automatic >> answering, accept the request without further user input. The UAS >> MAY, according to local policy or user preferences, treat this >> request as it would treat a request having a Answer-Mode with a >> value >> of "Manual" or having no Answer-Mode header field. If the calling > > I am very uncomfortable with this wording. I think authorization is a > MUST, and the text here doesnt make that clear. OMA wishes to control authorization in the intervening network elements, not in the terminal node. > >> this aspect into consideration. In general, auto-answer is probably >> NOT RECOMMENDED in environments that include forking. > > What?? I disagree. I think it makes a ton of sense. The typical > walkkie-talkie experience would result in a conference - thats the > desired behavior we should specify. > This would provide a "conference" only if the call was placed through a conference bridge. In the typical case, devices cannot do N-way mixing, both because of device capabilities and network characteristics. If you want to require all calls to go through a conference-SBC, then I suppose your approach would work. I suppose another alternative would be to reINVITE to a conference server if one received multiple 200OKs, but the functionality should be useful even if a user does not have a conference bridge available -- and here, forking would kill them. >> Another alternative would be to use dynamic conferencing instead of >> forking. In this approach, instead of forking the request, a >> conference would be initiated and all UAs invited into that >> conference. The mixer attached to the conference would then >> mediate >> traffic flows appropriately. > > These are not mutually exclusive; if a request forks, and you get > multiple 200 OK - thats fine. The UAC would create a conference > immediately, either through endpoint mixing or pushing everyone into a > conference server. > Again, that means that any UAC whose request might fork has to have a conference server available for every call for which they request auto-answer. That's just not realistic. >> Normal: The UAS is asked to treat the request as it normally would in >> the absence of this specification and exercise whatever alerting >> mechanism it might have and be configured to use. >> Null: The UAS is asked to not alert its user to the request. > > I think its worthwhile documenting somewhere the interactions of alert > and answer modes - in particular, what combinations make sense? > That makes sense. > > If the conclusion is to alert the user, the UAS invokes its > preferred > > alerting mechanism. If the conclusion is to not alert the user, > the > > UAS proceeds to process the request. Note that the decision of > > whether to accept the request is independent of the alerting > > decision, but one can generally not expect the user to make this > > decision unless the user has been alerted to the request. > > I think you need more discussion of what a UAS does if it doesnt alert > the user; how can it proceed with the call? Answermode is one thing, > diagnostics are another, etc. > If the UAS doesn't alert the user, then it proceeds just as it would if it had alerted the user. If it auto-answers, it proceeds with an answer, typically a 200 OK. If it does not auto-answer, it behaves just as it would in the case where a user is alerted -- typically, by timing out, responding with a 302, or whatever. This seems quite obvious to me. Negotiation of diagnostic modes is entirely an SDP problem and is out of scope here. > >> A UAS supporting this specification inserts a Answer-Mode header >> field into the 200 OK response to an INVITE request when it wishes >> to >> inform the UAC as to whether the request was answered manually or >> automatically. The full rationale for including or not including >> this header field in a response is outside of the scope of this >> specification. > > I think you need to discuss it. That's probably an NP-complete problem. Are you SURE you want it discussed? > >> Consequently, the UAS generally or its supporting proxy MUST >> authenticate the sender of such requests, using mechanisms such as > > If you are allowing proxies to do the authorization, you need a way to > securely inform the UAS that it has been done. Otherwise, > misconfiguration (proxy thinks UAS is authorizing, UAS thinks proxy is > authorizing) can introduce attacks. I think we should strive for > safety here; misconfiguration cannot easily cause an attack. The OMA use case assumes IMS authorization -- that is, if a request shows up at the client, it did so because it was authorized "by the network". Clients that work this way effectively have a "contract" with their proxies to provide this service. I'm not about to do a detailed analysis of the IMS authorization model here. About all we can do here is describe the risk and state the requirement for reducing it. > As you know, these attacks have been a MAJOR issue in bluetooth - let > us be extremely cautious here. > > Furthermore, the behavior of the UAS and proxy for authentication and > authorization cannot only be documented in the security considerations > section. > As I said, I'm not about to do a detailed analysis of the IMS authorization model here -- it's simply not appropriate in a document of this sort. > From the IANA considerations: > >> The following rows shall be added to the "Option Tags" section of the >> SIP Parameters registry: >> >> +----------------------+----------------------+---------------------+ >> | Name | Description | Reference >> | >> >> +----------------------+----------------------+---------------------+ >> | answermode | This option tag is | [RFCXXXX] >> | >> | | used in a Requires | >> | >> | | header field to | >> | >> | | indicate that the | >> | >> | | UAS must support | >> | >> | | negotiation of | >> | >> | | answer mode. | >> | >> | alertmode | This option tag is | [RFCXXXX] >> | >> | | used in a Requires | >> | > > > ok - so you have two option tags here. The doc only talks about one. > Maybe a typo? > Yes, there appears to be a typo. To quote, 4.1.1 All Requests A UAC supporting this specification indicates its support for this extension by including an option tag of "answermode" in the Supported header field of all requests it sends. and 5.1.1 All Requests A UAC supporting this specification indicates its support for this extension by including an option tag of "answermode" in the Supported header field of all requests it sends. 5.1.1 should say "alertmode". > Also, no IANA registration for media feature tags, though I dont think > you need them anyway. > err, it's in the xml2rfc source. Dunno what happened. Perhaps xml2rfc read your mind and deleted the registration. > minor things > >> SDP usage for this sort of flow is described in [11]. In this sort >> of application, it may not be needful that the human using the node > > may not be necessary > ok >> Req-5: It MUST be possible for UAC to indicate at least two >> different >> priority levels for the desired answer mode. We refer to these >> as >> "normal" and "override" priorities. In normal usage, we expect >> that "normal" priority would be used in a user-to-user fashion, >> whereas "override" priorities would be used for diagnostic >> procedures or some sorts of emergency session establishment. > > this requirement says how priorities get used, but doesnt define what > their semantics are. > That's true. It doesn't. Sectyion 4, however, says: The Answer-Mode header field is used by a UAC to request specific handling of an INVITE request by the responding UAS related to "automatic answering" functionality. If no Answer-Mode header field is included in the request, answering behavior is at the discretion of the UAS, as it would be in the absence of this specification. The desired handling is indicated by the the value of the Answer-Mode header field, as follows: Manual: The UAS is asked to not accept the request (send a 200 OK) until the user of the UAS has interacted with the user interface (UI) of the UAS in such a way as to indicate that the user desires the UAS to accept the request. ManualReq: The UAS is strongly asked to accept the request manually, as in "Manual". Further, the UAS is asked to override local user preferences relating to automatic answer, and answer manually even if the user preferences are to automatically answer requests having a Answer-Mode header field value of "Manual". The UAS is also asked NOT to answer automatically, and to reject the request if it is unwilling to answer manually. Auto: The UAS is asked to accept the request automatically, without waiting for the user of the UAS to interact with the UI of the UAS in such a way as to indicate that the user desires the UAS to accept the request. AutoReq: The UAS is strongly asked to accept the request automatically, as in "Auto". Further, the UAS is asked to override local user preferences relating to automatic answer, and answer automatically even if the user preferences are to not automatically answer requests having a Answer-Mode header field value of "Auto". The UAS is also asked NOT to answer manually, and to reject the request if it is unwilling to answer automatically. >> Req-8: It MUST be possible for the UAC to construct the request in >> such a way that the routing proxy infrastructure, if present, >> will >> select only contacts supporting the selection of answer modes. > > This is clearly alluding to caller prefs. Its important to note that > caller prefs genreally prefers to try a contact, even if you are > unusure it supports a capability, rather than reject one you're not > sure about. In this particular case, avoiding ringing these devices is > an optimization. Thus, I think the requirement here is better worded > as: > > "...will prefer contacts supporting the selection of answer modes." > That's a different requirement, and it's my error that they aren't both included. This was present for alertmode: Req-15: It MUST be possible for UAS to indicate its support for the selection of alerting modes in a REGISTER request so that that the routing proxy can selectively route requests requiring the selection of alerting mode to UAS. This supports the functionality described in the following requirement. Req-16: It MUST be possible for UAC to construct the request in such a way that the routing proxy infrastructure, if present, will select only contacts supporting the selection of alerting modes. This allows the proxy network to efficiently avoid sending the request to nodes that do not support this extension. >> Req-19: UAS SHOULD accurately represent the answering mode that was >> applied, but MAY either not include this information or MAY >> misinform UAC in order to maintain the privacy expectations of >> UAS-user. Consequently, applications MUST NOT rely on the >> veracity of this information. > > this seems like a requirement in the protocol itself, rather than a > requirement for building a protocol. Huh? Seems more like a requirement on implementations to me. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 04:59:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F5h-0006Kp-GC; Wed, 03 Aug 2005 04:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F5e-0006IL-67 for sip@megatron.ietf.org; Wed, 03 Aug 2005 04:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26109 for ; Wed, 3 Aug 2005 04:59:04 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FcH-0004bi-P7 for sip@ietf.org; Wed, 03 Aug 2005 05:32:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j738v7E28124; Wed, 3 Aug 2005 04:57:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] willis-sip-answeralert-00 Date: Wed, 3 Aug 2005 03:58:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF03968D82@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] willis-sip-answeralert-00 Thread-Index: AcWT1hXIkesHTnZaRJ6U9Q5RTfxcYQAoGZcwAL1Y8oA= From: "Francois Audet" To: , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, this is the post on the list I was talking about. What I am suggesting is some wording in section 1 to the effect that this a generic mechanism with many use cases (as opposed to just the 2 listed).=20 I would also like to add something like the following in section 1: A third use case is for "Intercom calls" applications that allow a user to page a device and start talking right away. This is very common in Enterprises in Boss-Secretary type features, or for announcements. Typically it implies a phone device with a speakerphone. There are many other applications where this mechanism may be useful, anytime an application requires automatic=20 answering. The other part of my comments probably needs more discussion, but in summary: - We should make the parameters more explicit about what they do at a technical level.=20 - The parameters should not be limited to an INVITE initiating a session. For example, I can see many uses for re-INVITEs or UPDATE for features "overriding" alerting. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Audet, Francois [SC100:9T51:EXCH] > Sent: Friday, July 29, 2005 12:59 > To: Cullen Jennings; sip@ietf.org > Cc: Dean Willis > Subject: RE: [Sip] willis-sip-answeralert-00 >=20 >=20 > This answeralert stuff is quite useful. >=20 > The document talks about it's applicability to Push-to-talk. >=20 > I would also like to see a mention of it's usefulness for > other features. >=20 > In particular, you can use it for Intercom call features > (like on any traditional PBX). >=20 > Also, it would be extremely useful to allow the answer-mode to be > allowed in an UPDATE (and re-INVITE). That would enable many=20 > features that are available today on traditional PBXs=20 > (secretary override, and other fun stuff difficult to do today).=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 03 10:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JxW-0008Ue-SF; Wed, 03 Aug 2005 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JxU-0008UN-Of for sip@megatron.ietf.org; Wed, 03 Aug 2005 10:11:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19000 for ; Wed, 3 Aug 2005 10:10:59 -0400 (EDT) Received: from [80.74.109.3] (helo=rad-w2ksrv11.radcom.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0KUB-0002vP-Gn for sip@ietf.org; Wed, 03 Aug 2005 10:44:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Aug 2005 17:08:44 +0200 Message-ID: <93E3C7B04652BC47934B2DE74DC607AC0310790E@rad-w2ksrv11.radcom.co.il> Thread-Topic: Establishing 2 subscriptions in the same dialog Thread-Index: AcWYPT09l2gX/HN0Tiaqs6eh8R8vbw== From: "Gilad Shaham" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Sip] Establishing 2 subscriptions in the same dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1851370485==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1851370485== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5983D.3D7B858E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5983D.3D7B858E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have encountered the following scenario for which we believe the spec is not clear. =20 Suppose a dialog is established by an INVITE. Suppose that after the dialog is established, both parties send a subscription on that dialog. =20 RFC 3265 states that in order to differentiate between multiple subscriptions in the same dialog, a SUBSCRIBE request may include an "id" parameter. What if both subscriptions have the same event and id? In the scenario above this can easily occur since it is not required for an id to be generated by the combination of a random string and one side cannot verify uniqueness with the other side since both subscriptions could occur at the same time. =20 Basically, I believe this can be resolved by matching the NOTIFY requests to an outgoing subscription and the rest of the requests (SUBSCRIBE, REFER...) to incoming subscription (where the receiving side is the notifier). However, I haven't found any reference in RFC 3265 that explicitly states that the direction of the subscription should be considered when matching between the requests and the subscriptions. =20 Did I miss anything? Any thoughts? =20 =20 =20 ------_=_NextPart_001_01C5983D.3D7B858E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have encountered the following scenario for which = we believe the spec is not clear.

 

Suppose a dialog is established by an INVITE. Suppose = that after the dialog is established, both parties send a subscription on = that dialog.

 

RFC 3265 states that in order to differentiate = between multiple subscriptions in the same dialog, a SUBSCRIBE request may = include an "id" parameter. What if both subscriptions have the same event and id? In the scenario above this can easily occur since it is not required for an id = to be generated by the combination of a random string and one side cannot = verify uniqueness with the other side since both subscriptions could occur at = the same time.

 

Basically, I believe this can be resolved by matching = the NOTIFY requests to an outgoing subscription and the rest of the requests = (SUBSCRIBE, REFER…) to incoming subscription (where the receiving side is the notifier). However, I haven't found any reference in RFC 3265 that = explicitly states that the direction of the subscription should be considered when matching between the requests and the = subscriptions.

 

Did I miss anything?

Any thoughts?

 

 

 

------_=_NextPart_001_01C5983D.3D7B858E-- --===============1851370485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1851370485==-- From sip-bounces@ietf.org Wed Aug 03 10:36:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KM9-0008GP-3r; Wed, 03 Aug 2005 10:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KM6-0008GH-G9 for sip@megatron.ietf.org; Wed, 03 Aug 2005 10:36:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22353 for ; Wed, 3 Aug 2005 10:36:24 -0400 (EDT) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Ksm-0004Q7-L0 for sip@ietf.org; Wed, 03 Aug 2005 11:10:14 -0400 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.12.10/8.12.10) with SMTP id j73Ea2a4020600 for ; Wed, 3 Aug 2005 10:36:02 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sip] Establishing 2 subscriptions in the same dialog Date: Wed, 3 Aug 2005 10:20:18 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <93E3C7B04652BC47934B2DE74DC607AC0310790E@rad-w2ksrv11.radcom.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.6 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0224647458==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0224647458== Content-Type: multipart/alternative; boundary="----=_NextPart_000_04D2_01C59814.F2875350" This is a multi-part message in MIME format. ------=_NextPart_000_04D2_01C59814.F2875350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 3.1.2. Identification of Subscribed Events and Event Classes Identification of events is provided by three pieces of information: Request URI, Event Type, and (optionally) message body. Would considering Request URI solve your problem? Thanks, Tolga -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Gilad Shaham Sent: Wednesday, August 03, 2005 11:09 AM To: sip@ietf.org Subject: [Sip] Establishing 2 subscriptions in the same dialog We have encountered the following scenario for which we believe the spec is not clear. Suppose a dialog is established by an INVITE. Suppose that after the dialog is established, both parties send a subscription on that dialog. RFC 3265 states that in order to differentiate between multiple subscriptions in the same dialog, a SUBSCRIBE request may include an "id" parameter. What if both subscriptions have the same event and id? In the scenario above this can easily occur since it is not required for an id to be generated by the combination of a random string and one side cannot verify uniqueness with the other side since both subscriptions could occur at the same time. Basically, I believe this can be resolved by matching the NOTIFY requests to an outgoing subscription and the rest of the requests (SUBSCRIBE, REFER.) to incoming subscription (where the receiving side is the notifier). However, I haven't found any reference in RFC 3265 that explicitly states that the direction of the subscription should be considered when matching between the requests and the subscriptions. Did I miss anything? Any thoughts? ------=_NextPart_000_04D2_01C59814.F2875350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3.1.2. = Identification of=20 Subscribed Events and Event Classes

   Identification = of events=20 is provided by three pieces of information:
   Request URI, = Event=20 Type, and (optionally) message body.
Would = considering=20 Request URI solve your problem?
 
  =20 Thanks,
  =20 Tolga

-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Gilad = Shaham
Sent:=20 Wednesday, August 03, 2005 11:09 AM
To:=20 sip@ietf.org
Subject: [Sip] Establishing 2 subscriptions in = the same=20 dialog

We have encountered the = following=20 scenario for which we believe the spec is not=20 clear.

 

Suppose a dialog is = established by=20 an INVITE. Suppose that after the dialog is established, both parties = send a=20 subscription on that dialog.

 

RFC 3265 states that in = order to=20 differentiate between multiple subscriptions in the same dialog, a = SUBSCRIBE=20 request may include an "id" parameter. What if both subscriptions have = the=20 same event and id? In the scenario above this can easily occur since = it is not=20 required for an id to be generated by the combination of a random = string and=20 one side cannot verify uniqueness with the other side since both = subscriptions=20 could occur at the same time.

 

Basically, I believe = this can be=20 resolved by matching the NOTIFY requests to an outgoing subscription = and the=20 rest of the requests (SUBSCRIBE, REFER…) to incoming = subscription (where the=20 receiving side is the notifier). However, I haven't found any = reference in RFC=20 3265 that explicitly states that the direction of the subscription = should be=20 considered when matching between the requests and the=20 subscriptions.

 

Did I miss=20 anything?

Any=20 thoughts?

 

 

 

------=_NextPart_000_04D2_01C59814.F2875350-- --===============0224647458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0224647458==-- From sip-bounces@ietf.org Wed Aug 03 11:11:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KuN-0000Ax-4V; Wed, 03 Aug 2005 11:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KuJ-00007h-U3 for sip@megatron.ietf.org; Wed, 03 Aug 2005 11:11:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24530 for ; Wed, 3 Aug 2005 11:11:45 -0400 (EDT) Received: from [80.74.109.3] (helo=rad-w2ksrv11.radcom.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LR0-0005vg-Um for sip@ietf.org; Wed, 03 Aug 2005 11:45:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Establishing 2 subscriptions in the same dialog Date: Wed, 3 Aug 2005 18:09:36 +0200 Message-ID: <93E3C7B04652BC47934B2DE74DC607AC03107914@rad-w2ksrv11.radcom.co.il> Thread-Topic: [Sip] Establishing 2 subscriptions in the same dialog Thread-Index: AcWYQRY2GqMrwtasRV+9DeG/I/ihBwAAe60g From: "Gilad Shaham" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225039863==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1225039863== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59845.BE801C2D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59845.BE801C2D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That will probably do. Thanks. =20 _____ =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Tolga Asveren Sent: Wednesday, August 03, 2005 4:20 PM To: sip@ietf.org Subject: RE: [Sip] Establishing 2 subscriptions in the same dialog =20 3.1.2. Identification of Subscribed Events and Event Classes Identification of events is provided by three pieces of information: Request URI, Event Type, and (optionally) message body. Would considering Request URI solve your problem? =20 Thanks, Tolga =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Gilad Shaham Sent: Wednesday, August 03, 2005 11:09 AM To: sip@ietf.org Subject: [Sip] Establishing 2 subscriptions in the same dialog We have encountered the following scenario for which we believe the spec is not clear. =20 Suppose a dialog is established by an INVITE. Suppose that after the dialog is established, both parties send a subscription on that dialog. =20 RFC 3265 states that in order to differentiate between multiple subscriptions in the same dialog, a SUBSCRIBE request may include an "id" parameter. What if both subscriptions have the same event and id? In the scenario above this can easily occur since it is not required for an id to be generated by the combination of a random string and one side cannot verify uniqueness with the other side since both subscriptions could occur at the same time. =20 Basically, I believe this can be resolved by matching the NOTIFY requests to an outgoing subscription and the rest of the requests (SUBSCRIBE, REFER...) to incoming subscription (where the receiving side is the notifier). However, I haven't found any reference in RFC 3265 that explicitly states that the direction of the subscription should be considered when matching between the requests and the subscriptions. =20 Did I miss anything? Any thoughts? =20 =20 =20 ------_=_NextPart_001_01C59845.BE801C2D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That will probably = do.

Thanks.

=

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Tolga Asveren
Sent: Wednesday, August = 03, 2005 4:20 PM
To: sip@ietf.org
Subject: RE: [Sip] = Establishing 2 subscriptions in the same dialog

 


3.1.2. Identification of Subscribed Events and Event Classes

   Identification of events is provided by three pieces of information:
   Request URI, Event Type, and (optionally) message = body.

Would considering Request URI solve your = problem?

 

   Thanks,

   Tolga

 

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On = Behalf Of Gilad Shaham
Sent: Wednesday, August = 03, 2005 11:09 AM
To: sip@ietf.org
Subject: [Sip] = Establishing 2 subscriptions in the same dialog

We have encountered the following scenario for which = we believe the spec is not clear.

 

Suppose a dialog is established by an INVITE. Suppose = that after the dialog is established, both parties send a subscription on = that dialog.

 

RFC 3265 states that in order to differentiate = between multiple subscriptions in the same dialog, a SUBSCRIBE request may = include an "id" parameter. What if both subscriptions have the same event = and id? In the scenario above this can easily occur since it is not required = for an id to be generated by the combination of a random string and one side = cannot verify uniqueness with the other side since both subscriptions could = occur at the same time.

 

Basically, I believe this can be resolved by matching = the NOTIFY requests to an outgoing subscription and the rest of the requests (SUBSCRIBE, REFER…) to incoming subscription (where the receiving = side is the notifier). However, I haven't found any reference in RFC 3265 that explicitly states that the direction of the subscription should be = considered when matching between the requests and the = subscriptions.

 

Did I miss anything?

Any thoughts?

 

 

 

------_=_NextPart_001_01C59845.BE801C2D-- --===============1225039863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1225039863==-- From sip-bounces@ietf.org Wed Aug 03 15:53:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PIh-000104-4h; Wed, 03 Aug 2005 15:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0PIc-0000zd-L8 for sip@megatron.ietf.org; Wed, 03 Aug 2005 15:53:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10141 for ; Wed, 3 Aug 2005 15:53:08 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0PpL-0000Qk-RI for sip@ietf.org; Wed, 03 Aug 2005 16:27:01 -0400 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 03 Aug 2005 12:52:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,164,1120460400"; d="scan'208,217"; a="467118616:sNHT36865836" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 12:52:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Aug 2005 12:52:58 -0700 Message-ID: Thread-Topic: Free B2BUA server. Thread-Index: AcWYZPKAnF7azk1LRh2L8ZISl7YFNQ== From: "Anil Bollineni" To: , X-OriginalArrivalTime: 03 Aug 2005 19:52:59.0024 (UTC) FILETIME=[F2F54900:01C59864] X-Spam-Score: 0.5 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [Sip] Free B2BUA server. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0404113752==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0404113752== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59864.F27AA81C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59864.F27AA81C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Do you know any free B2BUA server that can I use for testing? =20 Thanks in Advance, Anil ------_=_NextPart_001_01C59864.F27AA81C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

         =    Do you know any free B2BUA server that can I use for testing?

 

Thanks in Advance,

Anil

=00 ------_=_NextPart_001_01C59864.F27AA81C-- --===============0404113752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0404113752==-- From sip-bounces@ietf.org Thu Aug 04 02:53:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Zbp-0007Gn-NE; Thu, 04 Aug 2005 02:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Zbn-0007Gf-QC for sip@megatron.ietf.org; Thu, 04 Aug 2005 02:53:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05136 for ; Thu, 4 Aug 2005 02:53:38 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a8d-00008I-4i for sip@ietf.org; Thu, 04 Aug 2005 03:27:36 -0400 Received: by wproxy.gmail.com with SMTP id i30so334718wra for ; Wed, 03 Aug 2005 23:53:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fT9lBMum34sKi57j0AqO26pCgijeI8q4FyJjkoZ7LuA+eBjSVjOUkh9Zcx2jghIUyCkMvNIVn4DyPFV4+nE45w/SzLvDwH8DcqW0ibPtSyJki6RBcrmoPtrJsGjMgo/qDSAjfraCdRW4+yAnX4QpwKThfDZVwtsLeDJhQun1WDo= Received: by 10.54.16.66 with SMTP id 66mr1248553wrp; Wed, 03 Aug 2005 23:53:29 -0700 (PDT) Received: by 10.54.127.13 with HTTP; Wed, 3 Aug 2005 23:53:29 -0700 (PDT) Message-ID: Date: Thu, 4 Aug 2005 08:53:29 +0200 From: Nadav Golombick To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Subject: [Sip] draft-jennings-sip-sec-flows Comment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nadav Golombick List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The flow of SIP through TLS indicates the use of the header "transport=3DTLS", although the SIP RFC suggests that the header not be used. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 03:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZvP-0007DV-Kb; Thu, 04 Aug 2005 03:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZvM-0007Cw-Qz for sip@megatron.ietf.org; Thu, 04 Aug 2005 03:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06564 for ; Thu, 4 Aug 2005 03:13:50 -0400 (EDT) From: prince.philip@flextronicssoftware.com Received: from [61.16.168.135] (helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0aSA-00013y-QM for sip@ietf.org; Thu, 04 Aug 2005 03:47:48 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.12.5/8.12.5) with ESMTP id j747DDTk003270; Thu, 4 Aug 2005 12:43:13 +0530 In-Reply-To: <20050804050422.90971.qmail@web8502.mail.in.yahoo.com> To: sip-implementors@cs.columbia.edu, sip@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Thu, 4 Aug 2005 12:43:00 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 08/04/2005 12:53:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Sip] Question on ReliableProvisional Resp and Early Media X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi all, I have some questions:- 1) Why as per RFC 3262, the Offer-Answer is a MUST in the Provisional Resp+PRACK phase? 2) If the 3262 is only for Reliability of Provisional responses, Why should it mandate Offer-Answer completion? 3) As per current recommendations (that are evolved as per discussions in the sip groups), Why we can not send new Offer in the 200 OK to the INVITE, after establishing the early media? 4) If we can not change the media using 200 OK to INVITE, how this early Media is useful? 5) Are we seriously missing some thing in 3262, that forced us to come up with 3311 (UPDATE)? Thanks in advance, rgds, Prince *********************** FSS- Confidential *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 05:33:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c6g-0003IU-Cu; Thu, 04 Aug 2005 05:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c6d-0003II-IM for sip@megatron.ietf.org; Thu, 04 Aug 2005 05:33:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16261 for ; Thu, 4 Aug 2005 05:33:37 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cdT-0008Kw-3s for sip@ietf.org; Thu, 04 Aug 2005 06:07:37 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2005 11:33:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j749XCVb025162; Thu, 4 Aug 2005 11:33:25 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 11:33:23 +0200 Received: from cisco.com ([10.61.80.61]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 11:33:23 +0200 Message-ID: <42F1E0D7.6070207@cisco.com> Date: Thu, 04 Aug 2005 05:33:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prince.philip@flextronicssoftware.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2005 09:33:23.0456 (UTC) FILETIME=[8F018800:01C598D7] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Question on ReliableProvisional Resp and Early Media X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org prince.philip@flextronicssoftware.com wrote: > > > > Hi all, > > I have some questions:- > > > 1) Why as per RFC 3262, the Offer-Answer is a MUST in the Provisional > Resp+PRACK phase? I have yet to find anyone who could explain the WHY to me. However that is the way it is. People have asked in the past if this could be changed. The answer is that it perhaps could be changed, but the effort and impact of doing it would be considerable, and you would still be stuck supporting the old cases for backward compatibility. There are ways to adhere to the current requirement, so its hard to justify making a change. > 2) If the 3262 is only for Reliability of Provisional responses, Why should > it mandate Offer-Answer completion? Again, I am not sure it is possible to answer why. What some people have proposed for a rationale is that there should be at most one offer/answer per transaction. > 3) As per current recommendations (that are evolved as per discussions in > the sip groups), Why we can not send new Offer in the 200 OK to the INVITE, > after establishing the early media? There was extensive discussion of this about a year and a half ago. There were differences in interpretation of this, and finally it was decided that there can be at most one offer/answer per transaction. At this point, that is just the way it is. > 4) If we can not change the media using 200 OK to INVITE, how this early > Media is useful? You may establish early media with a 1xx to the invite, and then change to some other media via an UPDATE sent prior to the 2xx. > 5) Are we seriously missing some thing in 3262, that forced us to come up > with 3311 (UPDATE)? Perhaps. The UPDATE permits changes in media, initiated in *either* direction, prior to completion of the invite. Paul > Thanks in advance, > > rgds, > Prince > > > > > > *********************** FSS- Confidential *********************** > "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 11:26:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hcY-0003hL-Lb; Thu, 04 Aug 2005 11:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d71-0004Fo-9d for sip@megatron.ietf.org; Thu, 04 Aug 2005 06:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24817 for ; Thu, 4 Aug 2005 06:38:04 -0400 (EDT) Received: from [209.97.211.178] (helo=srv01.mizbaan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ddq-0003RB-Q0 for sip@ietf.org; Thu, 04 Aug 2005 07:12:05 -0400 Received: from 81-188-4-54.sdsl.easynet.be ([81.188.4.54] helo=etsmanager1) by srv01.mizbaan.com with esmtp (Exim 4.52) id 1E0d6I-0001vx-7g; Thu, 04 Aug 2005 12:37:22 +0200 From: "BAKIR YILDIRIM" To: "'Paul Kyzivat'" , Date: Thu, 4 Aug 2005 12:33:29 +0200 Message-ID: <002101c598df$f60ad080$1b0a0a0a@server.webetscom.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <42F1E0D7.6070207@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - srv01.mizbaan.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - etscom.be X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 04 Aug 2005 11:26:56 -0400 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] RE : [Sip-implementors] Question on ReliableProvisional Resp and EarlyMedia X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Can u take out my email from your discussions thanks BAKIR Yildirim=20 CEO Behalf of European Technology Solutions 8, Place Madou =20 B-1210 Brussels Belgium Office : +32 (2) 245 22 42 Fax : +32 (2) 245 24 15 Mobile : +32 (476) 911 722 http://www.etscom.be & www.yytel.com ets@etscom.be ************************************************************************ ************************* The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, or other use of this information, or taking of any action in reliance upon it by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ------------------------------- L'information transmise est pr=E9vue seulement pour la personne ou l'entit=E9 auxquelles elle est adress=E9e et peut contenir le mat=E9riel confidentiel et/ou privil=E9gi=E9. N'importe quelle revue, = retransmission, diffusion, ou toute autre utilisation de cette information, ou de prise de n'importe quelle action dans la confiance sur elle par des personnes ou des entit=E9s autres que le destinataire pr=E9vu est interdite. Si = vous receviez ceci par erreur, entrez en contact avec SVP l'exp=E9diteur ou supprimez le mail =E0 partir de n'importe quel ordinateur. ************************************************** =20 =20 -----Message d'origine----- De=A0: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Envoy=E9=A0: jeudi 4 ao=FBt 2005 11:33 =C0=A0: prince.philip@flextronicssoftware.com Cc=A0: sip@ietf.org; sip-implementors@cs.columbia.edu Objet=A0: Re: [Sip-implementors] Question on ReliableProvisional Resp = and EarlyMedia prince.philip@flextronicssoftware.com wrote: >=20 >=20 >=20 > Hi all, >=20 > I have some questions:- >=20 >=20 > 1) Why as per RFC 3262, the Offer-Answer is a MUST in the Provisional > Resp+PRACK phase? I have yet to find anyone who could explain the WHY to me. However that=20 is the way it is. People have asked in the past if this could be=20 changed. The answer is that it perhaps could be changed, but the effort=20 and impact of doing it would be considerable, and you would still be=20 stuck supporting the old cases for backward compatibility. There are=20 ways to adhere to the current requirement, so its hard to justify making a change. > 2) If the 3262 is only for Reliability of Provisional responses, Why should > it mandate Offer-Answer completion? Again, I am not sure it is possible to answer why. What some people have proposed for a rationale is that there should be at most one=20 offer/answer per transaction. > 3) As per current recommendations (that are evolved as per discussions in > the sip groups), Why we can not send new Offer in the 200 OK to the INVITE, > after establishing the early media? There was extensive discussion of this about a year and a half ago.=20 There were differences in interpretation of this, and finally it was=20 decided that there can be at most one offer/answer per transaction. At this point, that is just the way it is. > 4) If we can not change the media using 200 OK to INVITE, how this early > Media is useful? You may establish early media with a 1xx to the invite, and then change=20 to some other media via an UPDATE sent prior to the 2xx. > 5) Are we seriously missing some thing in 3262, that forced us to come up > with 3311 (UPDATE)? Perhaps. The UPDATE permits changes in media, initiated in *either*=20 direction, prior to completion of the invite. Paul > Thanks in advance, >=20 > rgds, > Prince >=20 >=20 >=20 >=20 >=20 > *********************** FSS- Confidential *********************** > "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." >=20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >=20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 11:48:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hxJ-0002XS-SK; Thu, 04 Aug 2005 11:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hxH-0002Vo-RT for sip@megatron.ietf.org; Thu, 04 Aug 2005 11:48:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20564 for ; Thu, 4 Aug 2005 11:48:21 -0400 (EDT) Received: from liszt-11.ednet.co.uk ([212.20.226.53] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0iUA-0007oT-J6 for sip@ietf.org; Thu, 04 Aug 2005 12:22:25 -0400 Received: from liszt-11.ednet.co.uk (mail.ednet.co.uk [212.20.226.52]) by liszt-11.ednet.co.uk (Postfix) with ESMTP id 1E267255BF1 for ; Thu, 4 Aug 2005 16:47:55 +0100 (BST) Received: from sullivan.ednet.co.uk (sullivan.lumison.net [212.20.231.233]) by liszt-11.ednet.co.uk (postfixfilterd/14247) id JAGYCYWBOX for ; Thu, 04 Aug 2005 16:47:54 +0100 (BST) Received: from Azopardi (azopardi.ednet.co.uk [212.20.231.227]) by sullivan.ednet.co.uk (Postfix) with ESMTP id EFF9F16406D for ; Thu, 4 Aug 2005 16:47:04 +0100 (BST) From: "Suha Cubukcuoglu" To: Date: Thu, 4 Aug 2005 16:40:44 +0100 Organization: edNET Message-ID: <002b01c5990a$e0790f40$e3e714d4@Azopardi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Comment: Virus scanned by edNET X-Spam-Score: 0.4 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [Sip] Nonce value in SIP Challenge X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suhac@nplusone.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, In a scenario where a UA sends simultaneous requests, can the SIP Proxy assign the same 'nonce' value in each challenge response to these requests? This is not explained in the RFC3261, so I decided to post to this list in case someone can help us with this. For example, consider the following scenario: 1. UA ------------- REGISTER ----------> SIP Proxy 2. UA -------------- INVITE -----------> SIP Proxy 3. UA <-- 401 (for REGISTER) nonce = 1234 --- SIP Proxy 4. UA <-- 407 (for INVITE) nonce = 5678 --- SIP Proxy 5. UA ------------- REGISTER (nonce = 1234) --- SIP Proxy (REGISTER attempt fails since the new nonce value stored against the user is 5678) Had the Proxy not changed the 'nonce' value for the second request, the REGISTER request in (5) would succeed. My question is actually general: Is the result of this scenario dependent on implementation of the proxy or is it defined anywhere as a standard? Is the Proxy obliged to 'remember' the nonce for each request or can there be only one 'nonce' value per subscriber at any point in time? Thanks. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison, nplusone or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison, nplusone and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by Lumison. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 12:07:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0iGB-0007Os-4I; Thu, 04 Aug 2005 12:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0iG8-0007Oj-SG for sip@megatron.ietf.org; Thu, 04 Aug 2005 12:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21924 for ; Thu, 4 Aug 2005 12:07:50 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0in2-0008S4-Up for sip@ietf.org; Thu, 04 Aug 2005 12:41:54 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j74G6Kcn018651 for ; Thu, 4 Aug 2005 09:06:20 -0700 (MST) Received: from zes06exm01.madrid.ecid.cig.mot.com ([10.161.1.12]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j74GCESB016021 for ; Thu, 4 Aug 2005 11:12:15 -0500 (CDT) Received: by zes06exm01.madrid.ecid.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Aug 2005 18:06:17 +0200 Message-ID: From: Andonegui Jesus-JANDONE1 To: sip@ietf.org Date: Thu, 4 Aug 2005 18:06:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.6 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Question on via branch computation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0718908083==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0718908083== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5990E.6C4AA3F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5990E.6C4AA3F0 Content-Type: text/plain Hi, I have a question related to the via branch computation: why is it possible (according to RFC3216 section 16.6 step 8) to use the topmost via header entry in the computation of the cryptographic hash ? If there is a loop, a server may get the same request from different servers and in that case the topmost via header entry will differ. If you use the topmost via header entry to compute the branch you will not detect the loop in that case. Thanks, Jesus ------_=_NextPart_001_01C5990E.6C4AA3F0 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUwNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MTc2NTQwMDE2LTA0MDgyMDA1 PkhpLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxT UEFOIA0KY2xhc3M9MTc2NTQwMDE2LTA0MDgyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTE3NjU0MDAxNi0wNDA4 MjAwNT5JIGhhdmUgYSBxdWVzdGlvbiANCnJlbGF0ZWQgdG8gdGhlIHZpYSBicmFuY2ggY29tcHV0 YXRpb246IHdoeSBpcyBpdCBwb3NzaWJsZSAoYWNjb3JkaW5nIHRvIFJGQzMyMTYgDQpzZWN0aW9u IDE2LjYgc3RlcCA4KSB0byB1c2UgdGhlIHRvcG1vc3QgdmlhIGhlYWRlciBlbnRyeSBpbiB0aGUg Y29tcHV0YXRpb24gb2YgDQp0aGUgY3J5cHRvZ3JhcGhpYyBoYXNoID8gSWYgdGhlcmUgaXMgYSBs b29wLCBhIHNlcnZlciBtYXkgZ2V0IHRoZSBzYW1lIHJlcXVlc3QgDQpmcm9tIGRpZmZlcmVudCBz ZXJ2ZXJzIGFuZCBpbiB0aGF0IGNhc2UgdGhlIHRvcG1vc3QgdmlhIGhlYWRlciBlbnRyeSB3aWxs IA0KZGlmZmVyLiBJZiB5b3UgdXNlIHRoZSB0b3Btb3N0IHZpYSBoZWFkZXIgZW50cnkgdG8gY29t cHV0ZSB0aGUgYnJhbmNoIHlvdSB3aWxsIA0Kbm90IGRldGVjdCB0aGUgbG9vcCBpbiB0aGF0IGNh c2UuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQpjbGFzcz0xNzY1NDAwMTYtMDQwODIwMDU+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0xNzY1NDAwMTYtMDQw ODIwMDU+VGhhbmtzLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjxTUEFOIA0KY2xhc3M9MTc2NTQwMDE2LTA0MDgyMDA1Pkplc3VzPC9TUEFOPjwvRk9O VD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C5990E.6C4AA3F0-- --===============0718908083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0718908083==-- From sip-bounces@ietf.org Thu Aug 04 14:42:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kfq-0004zp-2J; Thu, 04 Aug 2005 14:42:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kfp-0004zk-1s for sip@megatron.ietf.org; Thu, 04 Aug 2005 14:42:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28775 for ; Thu, 4 Aug 2005 14:42:31 -0400 (EDT) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0lCk-0003k8-H6 for sip@ietf.org; Thu, 04 Aug 2005 15:16:35 -0400 Received: from brett1 (corp.broadsoft.com [66.239.146.130]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id j74Ifxad098780; Thu, 4 Aug 2005 14:42:03 -0400 (EDT) From: "Brett Tate" To: , Subject: RE: [Sip] Nonce value in SIP Challenge Date: Thu, 4 Aug 2005 14:45:08 -0400 Message-ID: <001b01c59924$a3fa7620$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <002b01c5990a$e0790f40$e3e714d4@Azopardi> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > In a scenario where a UA sends simultaneous > requests, can the SIP Proxy assign the same > 'nonce' value in each challenge response to > these requests? It can; but that does not mean that it should. If qop is used, some UAs would cache and increment the nonce count for the cached nonce across unrelated dialogs/transactions. However if they don't cache, the nonce count will not increment correctly across unrelated dialogs/transactions. > This is not explained in the RFC3261, so I > decided to post to this list in case someone > can help us with this. > > For example, consider the following scenario: > > 1. UA ------------- REGISTER ----------> SIP Proxy > 2. UA -------------- INVITE -----------> SIP Proxy > 3. UA <-- 401 (for REGISTER) nonce = 1234 --- SIP Proxy > 4. UA <-- 407 (for INVITE) nonce = 5678 --- SIP Proxy > > 5. UA ------------- REGISTER (nonce = 1234) --- SIP Proxy > > (REGISTER attempt fails since the new nonce > value stored against the user is 5678) > > Had the Proxy not changed the 'nonce' value for > the second request, the REGISTER request > in (5) would succeed. > > My question is actually general: Is the result of this > scenario dependent on implementation of the proxy or > is it defined anywhere as a standard? The result is dependent on the proxy. Because of the SHOULDs and MAYs associated with nonce caching, the UA does not know how the proxy will cache; and the proxy does not know how the UA will cache. Thus if the proxy wants to avoid some of the "stale" nonce situations, it can implement a nonce caching mechanism to handle UAs that cache and those that don't cache. > Is the Proxy obliged to 'remember' the nonce for > each request or can there be only one 'nonce' value > per subscriber at any point in time? The RFC allows the proxy to make the decision. And depending on the implementation, this might occasionally cause another challenge when the proxy thinks the UA sent a "stale" nonce. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 18:07:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nsA-0006xP-Si; Thu, 04 Aug 2005 18:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ns8-0006xA-LU for sip@megatron.ietf.org; Thu, 04 Aug 2005 18:07:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12103 for ; Thu, 4 Aug 2005 18:07:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0oP6-0000ow-Nx for sip@ietf.org; Thu, 04 Aug 2005 18:41:33 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Aug 2005 15:07:17 -0700 X-IronPort-AV: i="3.95,169,1120460400"; d="scan'208"; a="202828341:sNHT41637540" 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 j74M65Zd009744; Thu, 4 Aug 2005 15:07:10 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 18:06:50 -0400 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: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Date: Thu, 4 Aug 2005 18:06:49 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C896057@xmb-rtp-211.amer.cisco.com> Thread-Topic: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Thread-Index: AcWJblDPCWbCq4aKTJmw6zhgQDHHkQP0XbIQ From: "Kevin Lingle \(klingle\)" To: "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 04 Aug 2005 22:06:50.0946 (UTC) FILETIME=[D0C51220:01C59940] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "Wijnen, Bert \(Bert\)" , jf.mule@cablelabs.com, j.schoenwaelder@iu-bremen.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org dan, jean-francois and i have discussed the issue of using method name as an index and, at this point, neither of us are against making that change. it has the benefit of removing the method to identifier table and the IANA overhead of administering the method identifiers. i'm going to take a look at the actual changes required to the mib, but don't believe they will be significant. if you, as our mib doctor, think this is a useful change we will persue it. please let us know your opinion. thanks, kevin -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Friday, July 15, 2005 2:52 PM To: Kevin Lingle (klingle) Cc: Romascanu, Dan (Dan); sip@ietf.org; Wijnen, Bert (Bert); jf.mule@cablelabs.com Subject: Re: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review On Fri, Jul 15, 2005 at 02:13:45PM -0400, Kevin Lingle (klingle) wrote: > A few issues were found related to the definition of the=20 > SipMethodIdentifier TC and its usage: > =20 > 1. The way it is defined the TC encourages extensibility, and this=20 > can be regarded as a good thing. In order to do this a vendor must=20 > invent some numerical assignment, which is not yet used by the=20 > standard, and the DESCRIPTION requires that this assignment "MUST=20 > ensure no collision with officially assigned method identifier values" > but says nothing about how collision can be avoided. > [klingle] one would avoid collision by checking the IANA maintained=20 > list of latest officially assigned method id > values... at least that was the intent/expectation. if that is > sufficient, can we simply add that text? I fail to see how that avoids collisions. =20 > 2. Another MIB Doctor asked 'why the method name has not been used as=20 > an index as this would be the natural naming scheme. Having to go=20 > through a lookup table (in case the SipMethodIdentifier has only local > significance) is painful and the alternative to establish another IANA > registry to number the SIP methods seems also kind of costly.'. I am=20 > not sure that a change is necessary at this stage, as nothing is=20 > broken, but as I would suggest that you provide a rationale for this=20 > design choice. > [klingle] i think this was discussed at some point in the past. > the rationale i recall had to do with the ease of=20 > integral indexing in snmp tables vs. variable-length string > indexes. keep in mind that the mib's generally a=20 > machine interface in that a NM application should be doing the GETs=20 > and then has the opportunity to present > the data in a more user-friendly fashion to a human being. so we=20 > thought the use of string methods indexing > the tables everywhere was less efficient for the agent=20 > implementations. We all know that MIBs are a machine interface. We also know that lots of people use generic MIB browsers short of a suitable machine interface. The more important point I think is that the native identification of a method is the method name. Introducing a new numeric numbering scheme plus a mapping mechanism adds complexity and increases the potential to get things wrong - I would be very careful in trading simplicity, clarity and ease of use against agent implementation efficiency gains, which clearly depend on the SNMP toolkit you use (and with many good toolkits, there hardly would be a difference). /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 04 18:16:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nxT-0007nA-3m; Thu, 04 Aug 2005 18:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nxQ-0007mx-Fw for sip@megatron.ietf.org; Thu, 04 Aug 2005 18:12:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12654 for ; Thu, 4 Aug 2005 18:12:53 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0oUL-0000xq-IW for sip@ietf.org; Thu, 04 Aug 2005 18:47:00 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j74MABHX009540 for ; Thu, 4 Aug 2005 18:10:12 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j74MA9HX009489 for ; Thu, 4 Aug 2005 18:10:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Date: Fri, 5 Aug 2005 01:12:43 +0300 Message-ID: Thread-Topic: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review Thread-Index: AcWJblDPCWbCq4aKTJmw6zhgQDHHkQP0XbIQAABxg0A= From: "Romascanu, Dan \(Dan\)" To: "Kevin Lingle \(klingle\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "Wijnen, Bert \(Bert\)" , jf.mule@cablelabs.com, j.schoenwaelder@iu-bremen.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, I would recommend that you go ahead with this change. Regards, Dan =20 > -----Original Message----- > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com]=20 > Sent: Friday, August 05, 2005 1:07 AM > To: Romascanu, Dan (Dan) > Cc: j.schoenwaelder@iu-bremen.de; sip@ietf.org; Wijnen, Bert=20 > (Bert); jf.mule@cablelabs.com > Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review >=20 > dan, >=20 > jean-francois and i have discussed the issue of using method=20 > name as an index and, at this point, neither of us > are against making that change. it has the benefit of > removing the method to identifier table and the IANA overhead > of administering the method identifiers. i'm going to take > a look at the actual changes required to the mib, but don't=20 > believe they will be significant. >=20 > if you, as our mib doctor, think this is a useful change we=20 > will persue it. please let us know your opinion. >=20 > thanks, > kevin >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Friday, July 15, 2005 2:52 PM > To: Kevin Lingle (klingle) > Cc: Romascanu, Dan (Dan); sip@ietf.org; Wijnen, Bert (Bert);=20 > jf.mule@cablelabs.com > Subject: Re: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review >=20 > On Fri, Jul 15, 2005 at 02:13:45PM -0400, Kevin Lingle=20 > (klingle) wrote: >=20 > > A few issues were found related to the definition of the=20 > > SipMethodIdentifier TC and its usage: > > =20 > > 1. The way it is defined the TC encourages extensibility, and > this=20 > > can be regarded as a good thing. In order to do this a vendor must=20 > > invent some numerical assignment, which is not yet used by the=20 > > standard, and the DESCRIPTION requires that this assignment "MUST=20 > > ensure no collision with officially assigned method=20 > identifier values" >=20 > > but says nothing about how collision can be avoided. > > [klingle] one would avoid collision by checking the IANA > maintained=20 > > list of latest officially assigned method id > > values... at least that was the intent/expectation. if that is > > sufficient, can we simply add that text? >=20 > I fail to see how that avoids collisions. > =20 > > 2. Another MIB Doctor asked 'why the method name has not been > used as=20 > > an index as this would be the natural naming scheme. Having to go=20 > > through a lookup table (in case the SipMethodIdentifier has=20 > only local >=20 > > significance) is painful and the alternative to establish=20 > another IANA >=20 > > registry to number the SIP methods seems also kind of=20 > costly.'. I am=20 > > not sure that a change is necessary at this stage, as nothing is=20 > > broken, but as I would suggest that you provide a rationale=20 > for this=20 > > design choice. > > [klingle] i think this was discussed at some point in the past. > > the rationale i recall had to do with the ease of=20 > > integral indexing in snmp tables vs. variable-length string > > indexes. keep in mind that the mib's generally a=20 > > machine interface in that a NM application should be doing the > GETs=20 > > and then has the opportunity to present > > the data in a more user-friendly fashion to a human being. so > we=20 > > thought the use of string methods indexing > > the tables everywhere was less efficient for the agent=20 > > implementations. >=20 > We all know that MIBs are a machine interface. We also know=20 > that lots of people use generic MIB browsers short of a=20 > suitable machine interface. >=20 > The more important point I think is that the native=20 > identification of a method is the method name. Introducing a=20 > new numeric numbering scheme plus a mapping mechanism adds=20 > complexity and increases the potential to get things wrong -=20 > I would be very careful in trading simplicity, clarity and=20 > ease of use against agent implementation efficiency gains,=20 > which clearly depend on the SNMP toolkit you use (and with=20 > many good toolkits, there hardly would be a difference). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, > Germany >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 05 02:16:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vVh-0001BL-Rq; Fri, 05 Aug 2005 02:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vVf-00017d-AX for sip@megatron.ietf.org; Fri, 05 Aug 2005 02:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16393 for ; Fri, 5 Aug 2005 02:16:45 -0400 (EDT) Received: from mail.uct.ac.za ([137.158.128.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0w2f-0003D8-Ts for sip@ietf.org; Fri, 05 Aug 2005 02:50:56 -0400 Received: from crg.ee.uct.ac.za ([137.158.30.12] helo=[10.64.2.10]) by mail.uct.ac.za with esmtp (Exim 4.44 (FreeBSD)) id 1E0vVZ-000NwJ-0R for sip@ietf.org; Fri, 05 Aug 2005 08:16:41 +0200 Message-ID: <42F30442.7000007@crg.ee.uct.ac.za> Date: Fri, 05 Aug 2005 08:16:34 +0200 From: Richard Good User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Sip] Mobility support using SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I am very new to SIP and have some basic questions regarding mobility support. I have read that the two main mobility protocols at the moment are SIP and MIP. I am doing an undergraduate thesis (3 months) on the topic of vertical handovers between UMTS and WLAN networks. Questions: 1) Is it feasible/possible to use SIP to support mobility and perform handovers between these networks (Also given that I only have 3 months)? 2) SIP is an application layer protocol, does this mean that I only have to implement it at the end node. i.e: Do i need more than a laptop equipped with WiFi card and UMTS datacard? 3) I have found several implementations of MIP on the net (mainly for linux platforms), do such implementations exist for SIP? thanks very much for your help, Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 05 03:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wI6-0003vI-N6; Fri, 05 Aug 2005 03:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wI1-0003uK-2z; Fri, 05 Aug 2005 03:06:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20049; Fri, 5 Aug 2005 03:06:43 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0wp4-0004hz-4P; Fri, 05 Aug 2005 03:40:54 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E0wI0-0001Wy-3X; Fri, 05 Aug 2005 03:06:44 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 05 Aug 2005 03:06:44 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-05.txt Technical Summary The content indirection mechanism in SIP provides an alternative transport mechanism for SIP MIME body parts. It is very general, in that indirected body parts are equivalent to in-line body parts, but specific uses include ensuring that large content (such a png images) is transported along a different path than the signaling when MESSAGE is used for messaging, and to ensure the most efficient handling of large presence documents, just to give two examples. Previous attempts at solving the content indirection problem made use of the text/uri-list MIME type. While attractive for its simplicity (a list of URIs delimited by end-of-line markers), it did not satisfy all the requirements for SIP's content indirection (which are presented in the document). Most notably lacking were an ability to specify attributes for it on a per- URI basis, such as the MIME type of the reference's content, and an expiration time for interest in it. The SIP content indirection solution uses the MIME type message/external-body (RFC 2017), along with MIME parameters and entity headers from there, RFC 2045 and RFC 2046. MIME Content-Type parameters are the preferred manner of describing the URI, while entity headers are the preferred manner of describing the (indirect) content. Working Group Summary The working group reviewed the design directions for a long while and this one appeared the cleanest to them. There was strong support for the document in the working group and in the SIMPLE Working Group. Protocol Quality The document has been reviewed for the IESG by Allison Mankin. It received careful security review and revision. The design got some desired mid-course Apps review while still in the WG. It appeared efficient and sound, but it needed the IESG's Apps review as well. RFC Editor Note - [13] has been published as RFC 3986, and should become the normative reference [7] instead of RFC 2396, which it obsoletes. Delete the informative reference. Also: OLD: 4. Requirements o It MUST be possible to specify the location of content via a URI. Such URIs MUST conform with RFC2396 [7] or its successors, such as [13]. NEW: 4. Requirements o It MUST be possible to specify the location of content via a URI. Such URIs MUST conform with RFC3986 [7]. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 05 07:21:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10Gr-00032v-Ea; Fri, 05 Aug 2005 07:21:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10GY-000306-09 for sip@megatron.ietf.org; Fri, 05 Aug 2005 07:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03815 for ; Fri, 5 Aug 2005 07:21:26 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E10nc-00045n-79 for sip@ietf.org; Fri, 05 Aug 2005 07:55:41 -0400 Received: by wproxy.gmail.com with SMTP id 37so561326wra for ; Fri, 05 Aug 2005 04:21:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=c/jmoGxyOYMc7A6XtJl9LnW49TEnKXgdZnXJpmo8H0jF1HcIpOz4Lo4rAqpMlAMJnwJewjzZCA0+bDRb62Ad3gwrThMYz5THjalXf8g25f7op5BimWemZ0F+Gq354LBe4+zHbUZdrtXsAdvq/EKlM+dO6JqW0lXr/zdwqtl7D3A= Received: by 10.54.14.29 with SMTP id 29mr2455997wrn; Fri, 05 Aug 2005 04:21:19 -0700 (PDT) Received: by 10.54.95.16 with HTTP; Fri, 5 Aug 2005 04:21:19 -0700 (PDT) Message-ID: <52db68bc05080504214b841e38@mail.gmail.com> Date: Fri, 5 Aug 2005 16:51:19 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] query abt SIP in IMS X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sudhir Kumar Reddy List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1768098010==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1768098010== Content-Type: multipart/alternative; boundary="----=_Part_7562_30681568.1123240879656" ------=_Part_7562_30681568.1123240879656 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone I'm newbie in IMS. so, i would like to know whether the IMS modules suppor= t=20 the full functionality (methods, response codes and so on...) of SIP. if not, how? tx in advance regards --=20 Sudhir Kumar Reddy=20 Software Engineer, QualPhone communications pvt. ltd. 09845052651 ------=_Part_7562_30681568.1123240879656 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi everyone
 
I'm newbie in IMS. so, i would like to know whether the IMS modules su= pport the full functionality (methods, response codes and so on...) of SIP.=
 
if not, how?
 
tx in advance
 
regards

--
Sudhir Kumar Reddy
Software En= gineer,
QualPhone communications pvt. ltd.
09845052651
------=_Part_7562_30681568.1123240879656-- --===============1768098010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1768098010==-- From sip-bounces@ietf.org Fri Aug 05 07:32:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10Qj-0005Vn-54; Fri, 05 Aug 2005 07:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10QR-0005TV-79 for sip@megatron.ietf.org; Fri, 05 Aug 2005 07:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04367 for ; Fri, 5 Aug 2005 07:31:42 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E10xT-0004WA-FQ for sip@ietf.org; Fri, 05 Aug 2005 08:05:54 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j75BfDag021636 for ; Fri, 5 Aug 2005 04:41:13 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j75BbNQD013370 for ; Fri, 5 Aug 2005 06:37:23 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 5 Aug 2005 06:31:27 -0500 Message-ID: From: Baniel Uri-CUB001 To: Sudhir Kumar Reddy , sip@ietf.org Subject: RE: [Sip] query abt SIP in IMS Date: Fri, 5 Aug 2005 06:31:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1386299395==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1386299395== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C599B1.374457B4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C599B1.374457B4 Content-Type: text/plain Yes, fully supports and enhances. Emphasis on cellular environment, which entail special attention/requirements for compression, security, timers etc. -uri _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Sudhir Kumar Reddy Sent: Friday, August 05, 2005 6:21 AM To: sip@ietf.org Subject: [Sip] query abt SIP in IMS Hi everyone I'm newbie in IMS. so, i would like to know whether the IMS modules support the full functionality (methods, response codes and so on...) of SIP. if not, how? tx in advance regards -- Sudhir Kumar Reddy Software Engineer, QualPhone communications pvt. ltd. 09845052651 ------_=_NextPart_001_01C599B1.374457B4 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTUwNSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03MDcwNjI4MTEtMDUwODIwMDU+PEZPTlQg ZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPlllcywgZnVsbHkgc3VwcG9ydHMgYW5k IGVuaGFuY2VzLiBFbXBoYXNpcyBvbiBjZWxsdWxhciANCmVudmlyb25tZW50LCB3aGljaCBlbnRh aWwgc3BlY2lhbCBhdHRlbnRpb24vcmVxdWlyZW1lbnRzIGZvciBjb21wcmVzc2lvbiwgDQpzZWN1 cml0eSwgdGltZXJzIGV0Yy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9NzA3MDYyODExLTA1MDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpj b2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzA3MDYyODExLTA1MDgyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj4tdXJpPC9GT05UPjwvU1BBTj48L0RJVj48QlI+ DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGln bj1sZWZ0Pg0KPEhSIHRhYkluZGV4PS0xPg0KPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZy b206PC9CPiBzaXAtYm91bmNlc0BpZXRmLm9yZyANClttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5v cmddIDxCPk9uIEJlaGFsZiBPZiA8L0I+U3VkaGlyIEt1bWFyIA0KUmVkZHk8QlI+PEI+U2VudDo8 L0I+IEZyaWRheSwgQXVndXN0IDA1LCAyMDA1IDY6MjEgQU08QlI+PEI+VG86PC9CPiANCnNpcEBp ZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gW1NpcF0gcXVlcnkgYWJ0IFNJUCBpbiBJTVM8QlI+ PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkhpIGV2ZXJ5b25lPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj5JJ20gbmV3YmllIGluIElNUy4gc28sIGkgd291bGQgbGlr ZSB0byBrbm93IHdoZXRoZXIgdGhlIElNUyBtb2R1bGVzIHN1cHBvcnQgDQp0aGUgZnVsbCBmdW5j dGlvbmFsaXR5IChtZXRob2RzLCByZXNwb25zZSBjb2RlcyBhbmQgc28gb24uLi4pIG9mIFNJUC48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmlmIG5vdCwgaG93PzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+dHggaW4gYWR2YW5jZTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+cmVnYXJkczxCUiBjbGVhcj1hbGw+PEJSPi0tIDxCUj5TdWRoaXIgS3VtYXIgUmVkZHkg PEJSPlNvZnR3YXJlIA0KRW5naW5lZXIsPEJSPlF1YWxQaG9uZSBjb21tdW5pY2F0aW9ucyBwdnQu IGx0ZC48QlI+MDk4NDUwNTI2NTEgDQo8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C599B1.374457B4-- --===============1386299395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1386299395==-- From sip-bounces@ietf.org Fri Aug 05 08:46:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11aP-0006EA-6M; Fri, 05 Aug 2005 08:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11aB-00063Y-HW for sip@megatron.ietf.org; Fri, 05 Aug 2005 08:45:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07944 for ; Fri, 5 Aug 2005 08:45:47 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E127C-0006RY-T7 for sip@ietf.org; Fri, 05 Aug 2005 09:20:01 -0400 Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel12.hp.com (Postfix) with ESMTP id E02C5403CAB for ; Fri, 5 Aug 2005 05:45:44 -0700 (PDT) Received: from nt13195 (nt13195.india.hp.com [15.76.113.195]) by hpuxsrv.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA23820 for ; Fri, 5 Aug 2005 18:22:22 +0530 (IST) Message-Id: <200508051252.SAA23820@hpuxsrv.india.hp.com> From: "Gururaj M K" To: Date: Fri, 5 Aug 2005 18:15:40 +0530 Organization: Hewlett Packard MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWZu5YY7nA1BI3gQ7Wj3e0pPOMaqQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Sip] A Question on maddr X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maknur@india.hp.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0949561413==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0949561413== Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01C599E9.AFF1DB60" This is a multi-part message in MIME format. ------=_NextPart_000_018C_01C599E9.AFF1DB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, RFC 3261 and Section: 16.4 --> Route Information Preprocessing Question: Section 16.4 mentions the action to be taken in the first two cases mentioned below. What should be the action for 3rd and 4th Case? 1. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. 2. A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. 3. A request may arrive with a maddr not matching the proxy, but on a port or transport same as indicated in the URI. 4. A request may arrive with a maddr not matching the proxy, but on a port or transport different from that indicated in the URI. Regards, Guru ------=_NextPart_000_018C_01C599E9.AFF1DB60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A Question on maddr

Hi,

  

RFC = 3261 and Section: 16.4 à Route Information = Preprocessing

Question: Section 16.4 mentions the action to be taken in the first = two cases mentioned below. What should be the action for 3rd and 4th Case?

1.      If the Request-URI has a maddr parameter with a = value the proxy is responsible for, and the request was received using = the port and transport indicated (explicitly or by default) in the = Request-URI, the proxy MUST strip the maddr and any non-default port or = transport parameter and continue processing as if those values had not = been present in the request.

2.      A request may arrive with a maddr matching the = proxy, but on a port or transport different from that indicated in the = URI.

3.      A request may arrive with a = maddr = not matching the proxy, but on a port or transport same as indicated in = the URI.

4.      A request may arrive with a = maddr = not matching the proxy, but on a port or transport different from that indicated in the URI.

Regards,

Guru

------=_NextPart_000_018C_01C599E9.AFF1DB60-- --===============0949561413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0949561413==-- From sip-bounces@ietf.org Fri Aug 05 08:58:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11mm-0000c4-37; Fri, 05 Aug 2005 08:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11mY-0000be-K7 for sip@megatron.ietf.org; Fri, 05 Aug 2005 08:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08508 for ; Fri, 5 Aug 2005 08:58:36 -0400 (EDT) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E12Jd-0006nN-Gi for sip@ietf.org; Fri, 05 Aug 2005 09:32:50 -0400 Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel9.hp.com (Postfix) with ESMTP id 155CBE71F; Fri, 5 Aug 2005 08:57:40 -0400 (EDT) Received: from nt13195 (nt13195.india.hp.com [15.76.113.195]) by hpuxsrv.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA26658; Fri, 5 Aug 2005 18:34:18 +0530 (IST) Message-Id: <200508051304.SAA26658@hpuxsrv.india.hp.com> From: "Gururaj M K" To: "'Andonegui Jesus-JANDONE1'" , Subject: RE: [Sip] Question on via branch computation Date: Fri, 5 Aug 2005 18:27:36 +0530 Organization: Hewlett Packard MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcWZEBYlkB4xRZwNQ/aZhPbmHTItpAArSQiw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.2 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maknur@india.hp.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1064360874==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1064360874== Content-Type: multipart/alternative; boundary="----=_NextPart_000_019D_01C599EB.5AA193B0" This is a multi-part message in MIME format. ------=_NextPart_000_019D_01C599EB.5AA193B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think this condition happens only when maddr header is present as part of the Via header of the request being processed. We can chose to include topmost via header field in the computation of cryptographic hash only if the request doesn't contain maddr header as part of Via. If maddr is present as part of the request then we can dropout topmost via header field in the computation of cryptographic hash. Regards, Guru _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Andonegui Jesus-JANDONE1 Sent: Thursday, August 04, 2005 9:36 PM To: sip@ietf.org Subject: [Sip] Question on via branch computation Hi, I have a question related to the via branch computation: why is it possible (according to RFC3216 section 16.6 step 8) to use the topmost via header entry in the computation of the cryptographic hash ? If there is a loop, a server may get the same request from different servers and in that case the topmost via header entry will differ. If you use the topmost via header entry to compute the branch you will not detect the loop in that case. Thanks, Jesus ------=_NextPart_000_019D_01C599EB.5AA193B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

      =       I think this condition happens only when maddr header is present as part = of the Via header of the request being processed.

 

We can chose to include topmost via = header field in the computation of cryptographic hash only if the request doesn’t contain maddr header as part of = Via.

If maddr is present as part of the = request then we can dropout topmost via header field in the computation of cryptographic hash.

 

Regards,

Guru

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Andonegui Jesus-JANDONE1
Sent: Thursday, August = 04, 2005 9:36 PM
To: sip@ietf.org
Subject: [Sip] Question = on via branch computation

 

Hi,

 

I have a question related to the via branch = computation: why is it possible (according to RFC3216 section 16.6 step 8) to use the = topmost via header entry in the computation of the cryptographic hash ? If there = is a loop, a server may get the same request from different servers and in = that case the topmost via header entry will differ. If you use the topmost via = header entry to compute the branch you will not detect the loop in that = case.

 

Thanks,

Jesus

------=_NextPart_000_019D_01C599EB.5AA193B0-- --===============1064360874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1064360874==-- From sip-bounces@ietf.org Sun Aug 07 21:14:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1wDe-0001CO-PP; Sun, 07 Aug 2005 21:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1wDc-0001Bh-3p for sip@megatron.ietf.org; Sun, 07 Aug 2005 21:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08533 for ; Sun, 7 Aug 2005 21:14:18 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1wlC-00077E-L3 for sip@ietf.org; Sun, 07 Aug 2005 21:49:03 -0400 Received: from [192.168.1.105] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j781I8Na010804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 7 Aug 2005 20:18:09 -0500 In-Reply-To: <52db68bc05080504214b841e38@mail.gmail.com> References: <52db68bc05080504214b841e38@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] query abt SIP in IMS Date: Mon, 8 Aug 2005 03:14:16 +0200 To: Sudhir Kumar Reddy X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Aug 5, 2005, at 1:21 PM, Sudhir Kumar Reddy wrote: > Hi everyone > =A0 > I'm newbie in IMS. so, i would like to know whether the IMS modules=20 > support the full functionality (methods, response codes and so on...)=20= > of SIP. > =A0 > if not, how? > Your question is rather close to NP complete and probably outside the=20 scope of an IETF mailing list (IMS is a 3GPP specification). You may wish to look at: http://www.3gpp.org/specs/numbering.htm with particular emphasis on specifications 24.228 and 24.229 -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 08 03:55:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E22Tc-0005lY-C4; Mon, 08 Aug 2005 03:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E22Ta-0005lI-LS for sip@megatron.ietf.org; Mon, 08 Aug 2005 03:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06260 for ; Mon, 8 Aug 2005 03:55:12 -0400 (EDT) Received: from web15506.mail.cnb.yahoo.com ([202.165.102.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E231C-0007Za-BV for sip@ietf.org; Mon, 08 Aug 2005 04:30:02 -0400 Received: (qmail 4324 invoked by uid 60001); 8 Aug 2005 07:54:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AOUikYPf/I+B642q8lUUQRpg+lrUpxg3uwwIp2ii4AHaeWXnRwiOhQBorMNOcwxSIvjiN26iHC6RBwOptwEv7vQM79CahJ5LGB3wFKo2WrKyiBfRoI3YKNtYM14+JchuZZIFmn5udDf+AaNjkj2LCD0j0HKvf643NFacTPTWiCc= ; Message-ID: <20050808075458.4322.qmail@web15506.mail.cnb.yahoo.com> Received: from [61.149.152.61] by web15506.mail.cnb.yahoo.com via HTTP; Mon, 08 Aug 2005 15:54:58 CST Date: Mon, 8 Aug 2005 15:54:58 +0800 (CST) From: =?gb2312?q?=D7=DE=BE=FC?= To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] How to exchange mid-call information between two UAs? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1952367818==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1952367818== Content-Type: multipart/alternative; boundary="0-2010101334-1123487698=:3702" --0-2010101334-1123487698=:3702 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA06260 Hi! There is a problem, I need a help. =20 In a session, if a UA found there is a little congestion in the IP networ= k, and it want to modify the initial parameters of session to low the rat= e of RTP by changing codec as to keep call on, then there may be a negoti= ation between two UAs.=20 =20 The problem is how exchange such mid-call infomation between two UAs in a= session?=20 INFO is designed to carry mid-call information along the SIP signaling pa= th during the session, but not used to change the state of SIP calls, or = the parameters of the sessions SIP initiates. =20 "In addition, the SIP re-INVITE can be used during a session to change the characteristics of the session. This is generally to change the properties of media flows related to the session or to update the SIP session timer." =20 What's good method? =20 Thanks for any advice and suggestion! =09 --------------------------------- DO YOU YAHOO!? =D1=C5=BB=A2=D3=CA=CF=E4=B3=AC=C7=BF=D4=F6=D6=B5=B7=FE=CE=F1=A3=AD2G=B3= =AC=B4=F3=BF=D5=BC=E4=A1=A2pop3=CA=D5=D0=C5=A1=A2=CE=DE=CF=DE=C1=BF=D3=CA= =BC=FE=CC=E1=D0=D1=20 --0-2010101334-1123487698=:3702 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA06260
Hi!
There is a problem, I need a help.
 
In a session, if a UA found there is a little congestion in&nbs= p;the IP network, and it want to modify the initial parameters of session= to low the rate of RTP by changing codec as to keep call on, then&n= bsp;there may be a negotiation between two UAs.
 
The problem is how exchange such mid-call infomation between two UAs= in a session?
INFO is designed to carry mid-call information along the SIP signali= ng path during the session, but not used to change the state of SIP calls= , or the parameters of the sessions SIP initiates.
 
"In addition, the SIP re-INVITE can be used during a session to chan= ge
the characteristics of the session. This is generally to change the=
properties of media flows related to the session or to update the SIP=
session timer."
 
What's good method?
 
Thanks for any advice and suggestion!

DO YOU YAHOO!?
=20 =20 =D1=C5=BB=A2=D3=CA=CF=E4=B3=AC=C7=BF=D4=F6=D6=B5=B7=FE=CE=F1=A3=AD2G=B3=AC= =B4=F3=BF=D5=BC=E4=A1=A2pop3=CA=D5=D0=C5=A1=A2=CE=DE=CF=DE=C1=BF=D3=CA=BC= =FE=CC=E1=D0=D1=20 --0-2010101334-1123487698=:3702-- --===============1952367818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1952367818==-- From sip-bounces@ietf.org Mon Aug 08 11:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29ua-0003Nm-Hn; Mon, 08 Aug 2005 11:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29uY-0003Ne-Ew for sip@megatron.ietf.org; Mon, 08 Aug 2005 11:51:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28999 for ; Mon, 8 Aug 2005 11:51:31 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ASH-0003ZC-Qn for sip@ietf.org; Mon, 08 Aug 2005 12:26:26 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2005 08:51:25 -0700 X-IronPort-AV: i="3.95,174,1120460400"; d="scan'208"; a="330120047:sNHT30900280" 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 j78FpDow012837; Mon, 8 Aug 2005 08:51:22 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 08:51:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.112.101]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 08:51:16 -0700 Message-Id: <4.3.2.7.2.20050808104848.0327cf08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Aug 2005 10:51:20 -0500 To: =?gb2312?q?=D7=DE=BE=FC?= , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] How to exchange mid-call information between two UAs? In-Reply-To: <20050808075458.4322.qmail@web15506.mail.cnb.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 08 Aug 2005 15:51:16.0357 (UTC) FILETIME=[02C2AB50:01C59C31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Use reINVITE for any changes to the parameters of a dialog - which you are= =20 describing. INFO is for additional information about the session. Look at the example=20 usages in RFC2976 as guidance here (signal strength, etc). At 03:54 PM 8/8/2005 +0800, =3D?gb2312?q?=3DD7=3DDE=3DBE=3DFC?=3D wrote: >Hi! >There is a problem, I need a help. > >In a session, if a UA found there is a little congestion in the IP=20 >network, and it want to modify the initial parameters of session to low=20 >the rate of RTP by changing codec as to keep call on, then there may be a= =20 >negotiation between two UAs. > >The problem is how exchange such mid-call infomation between two UAs in a= =20 >session? >INFO is designed to carry mid-call information along the SIP signaling=20 >path during the session, but not used to change the state of SIP calls, or= =20 >the parameters of the sessions SIP initiates. > >"In addition, the SIP re-INVITE can be used during a session to change >the characteristics of the session. This is generally to change the >properties of media flows related to the session or to update the SIP >session timer." > >What's good method? > >Thanks for any advice and suggestion! > > >DO YOU YAHOO!? >=D1=C5=BB=A2=D3=CA=CF=E4= =B3=AC=C7=BF=D4=F6=D6=B5=B7=FE=CE=F1=A3=AD2G=B3=AC=B4=F3=BF=D5=BC=E4=A1=A2po= p3=CA=D5=D0=C5=A1=A2=CE=DE=CF=DE=C1=BF=D3=CA=BC=FE=CC=E1=D0=D1=20 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 08 19:05:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GgB-00087D-Fw; Mon, 08 Aug 2005 19:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Gg8-000878-UV for sip@megatron.ietf.org; Mon, 08 Aug 2005 19:05:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00818 for ; Mon, 8 Aug 2005 19:05:05 -0400 (EDT) From: frieda.vanparijs@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2HDu-0001AO-Lc for sip@ietf.org; Mon, 08 Aug 2005 19:40:04 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j78N0ege031257 for ; Tue, 9 Aug 2005 01:04:43 +0200 To: sip@ietf.org Message-ID: Date: Tue, 9 Aug 2005 01:01:06 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 08/09/2005 01:04:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] Frieda VANPARIJS/BE/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office starting 08/08/2005 and will not return until 04/01/2006. I will respond to your message when I return. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 09 10:55:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VW0-0001bc-PO; Tue, 09 Aug 2005 10:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VVy-0001bU-TX; Tue, 09 Aug 2005 10:55:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13315; Tue, 9 Aug 2005 10:55:36 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2W3t-00027t-6g; Tue, 09 Aug 2005 11:30:42 -0400 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j79EtGa6043840 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 Aug 2005 09:55:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 9 Aug 2005 09:57:31 -0500 To: Simple WG , sip-implementors@cs.columbia.edu, "sip@ietf.org WG" X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] SIPIT 17 registration closes this week X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIPIT 17 will take place Sep 12-16 in Stockholm, Sweden, hosted by Hotsip. Information about the event is available at sipit17.hotsip.com and www.sipit.net. Registration closes August 14 (this Sunday). If you plan to attend but have not yet registered, please do so now. Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 10 01:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jAX-000466-KS; Wed, 10 Aug 2005 01:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jAS-00045I-V6 for sip@megatron.ietf.org; Wed, 10 Aug 2005 01:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07124 for ; Wed, 10 Aug 2005 01:30:20 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2jiV-0001yb-1I for sip@ietf.org; Wed, 10 Aug 2005 02:05:32 -0400 Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7A5TwP10034; Wed, 10 Aug 2005 00:29:58 -0500 (CDT) Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Aug 2005 15:28:53 +1000 Message-ID: From: "Martin Thomson" To: sip@ietf.org Date: Wed, 10 Aug 2005 15:28:51 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.7 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: jmpolk@cisco.com Subject: [Sip] Comments for draft-ietf-sip-location-conveyance-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019135429==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0019135429== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59D6C.641F95AC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59D6C.641F95AC Content-Type: text/plain Hi All, Comments are included at the following URL, to save everyone who doesn't want a >180K file in their mailboxes: http://uploadx.net/file/?id=pN7ykg== Thanks, Martin ------_=_NextPart_001_01C59D6C.641F95AC Content-Type: text/html Comments for draft-ietf-sip-location-conveyance-01

Hi All,

Comments are included at the following URL, to save everyone who doesn't want a >180K file in their mailboxes:

  http://uploadx.net/file/?id=pN7ykg==

Thanks,
Martin

------_=_NextPart_001_01C59D6C.641F95AC-- --===============0019135429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0019135429==-- From sip-bounces@ietf.org Wed Aug 10 07:54:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pA4-0005tR-Mv; Wed, 10 Aug 2005 07:54:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pA2-0005tH-IN for sip@megatron.ietf.org; Wed, 10 Aug 2005 07:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21837 for ; Wed, 10 Aug 2005 07:54:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2pi7-0003cJ-2n for sip@ietf.org; Wed, 10 Aug 2005 08:29:33 -0400 Received: from hkg-core-1.cisco.com (64.104.123.94) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2005 04:54:06 -0700 X-IronPort-AV: i="3.96,95,1122879600"; d="scan'208"; a="653943643:sNHT29275464" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7ABsFt4015736; Wed, 10 Aug 2005 19:54:16 +0800 (CST) Received: from xmb-hkg-418.apac.cisco.com ([64.104.123.90]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Aug 2005 19:54:00 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 10 Aug 2005 19:54:03 +0800 Message-ID: <01CB1043766A5F4D94A6F8665F28DF52602A56@xmb-hkg-418.apac.cisco.com> Thread-Topic: A question on non provision message scenario Thread-Index: AcWdojRnGaC4LG1cRxyA/CKvCJcBEg== From: "Xiga Kuang \(xikuang\)" To: X-OriginalArrivalTime: 10 Aug 2005 11:54:00.0785 (UTC) FILETIME=[32864410:01C59DA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Sip] A question on non provision message scenario X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi all, I may ask the old question, just a quick one, is that ok for sip Eps behavior to set up one way voice path even it didn't get the 200 0k message from calling side ? I mean , suppose the provision message 1xx had not been received by calling side due to some detectable issue. =20 A ---invite with SDP-->B <---1xx but not receivid--B =20 one way voice path ? A.<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D B picked up and say = "hello" So what happened on A side would be after he dialed the number and then after a silent without ring, he just hears from the "hello" from the other side ?=20 Thanks in advance. .. B.R Xenor _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 10 11:08:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sCG-0004OU-2U; Wed, 10 Aug 2005 11:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sCE-0004OM-NP for sip@megatron.ietf.org; Wed, 10 Aug 2005 11:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04890 for ; Wed, 10 Aug 2005 11:08:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2skL-0001Kx-QW for sip@ietf.org; Wed, 10 Aug 2005 11:44:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2005 08:08:36 -0700 X-IronPort-AV: i="3.96,96,1122879600"; d="scan'208"; a="653979984:sNHT30254048" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7AF8Kp0003132 for ; Wed, 10 Aug 2005 08:08:33 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 11:06:47 -0400 Received: from [192.168.1.100] ([10.86.240.54]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 11:06:47 -0400 Message-ID: <42FA1806.4080404@cisco.com> Date: Wed, 10 Aug 2005 11:06:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Xiga Kuang (xikuang)" Subject: Re: [Sip] A question on non provision message scenario References: <01CB1043766A5F4D94A6F8665F28DF52602A56@xmb-hkg-418.apac.cisco.com> In-Reply-To: <01CB1043766A5F4D94A6F8665F28DF52602A56@xmb-hkg-418.apac.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2005 15:06:47.0178 (UTC) FILETIME=[20A1C6A0:01C59DBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, in fact it is required in RFC 3264: Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information). In the case of RTP, even though it may receive media before the answer arrives, it will not be able to send RTCP receiver reports until the answer arrives. -Jonathan R. Xiga Kuang (xikuang) wrote: > Hi all, > I may ask the old question, just a quick one, is that ok for sip Eps > behavior to set up one way voice path even it didn't get the 200 0k > message from calling side ? I mean , suppose the provision message 1xx > had not been received by calling side due to some detectable issue. > > > A ---invite with SDP-->B > <---1xx but not receivid--B > > one way voice path ? > A.<==========-====== B picked up and say "hello" > > So what happened on A side would be after he dialed the number and then > after a silent without ring, he just hears from the "hello" from the > other side ? > > Thanks in advance. > > .. > B.R > Xenor > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 11 04:32:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38UJ-0002Ce-6G; Thu, 11 Aug 2005 04:32:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38UE-0002AI-Vd for sip@megatron.ietf.org; Thu, 11 Aug 2005 04:32:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16190 for ; Thu, 11 Aug 2005 04:32:24 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E392V-0005Eb-2Q for sip@ietf.org; Thu, 11 Aug 2005 05:07:52 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1E38EK-00080G-00; Thu, 11 Aug 2005 10:16:00 +0200 Message-ID: <42FB0941.8060603@pernau.at> Date: Thu, 11 Aug 2005 10:16:01 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Banibrata Dutta References: <200508040619.LAA13917@harvest.india.hp.com> In-Reply-To: <200508040619.LAA13917@harvest.india.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, 'Rajesh Kadikar' Subject: [Sip] Re: [Sip-implementors] Nokia Series 60 device X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi! Because it is usally much more easier to ask other developers for help. Do you now a contact at Nokia which we may ask about their SIP stack? Klaus Banibrata Dutta wrote: > Why not ask Nokia ? > > -bd > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Rajesh > Kadikar > Sent: Thursday, August 04, 2005 2:16 AM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Nokia Series 60 device > > Guys, > > I am not sure if this is the right forum for this question... > > But has anybody used the SIP stack that came out with Nokia Series 60? > > Do you know if it is RFC 3261 compliant? > > Thanks in advance > > Rajesh > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 12 03:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3UPF-0002x0-0O; Fri, 12 Aug 2005 03:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3UP9-0002wk-C4 for sip@megatron.ietf.org; Fri, 12 Aug 2005 03:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09058 for ; Fri, 12 Aug 2005 03:56:36 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Uxb-0000an-Bi for sip@ietf.org; Fri, 12 Aug 2005 04:32:16 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1E3UCD-00065x-00; Fri, 12 Aug 2005 09:43:17 +0200 Message-ID: <42FC5319.8090800@pernau.at> Date: Fri, 12 Aug 2005 09:43:21 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gaurav Kheterpal References: <4D6E93075B31154298572E6B73CA849D01C4485C@noida-mail.bbnet.ad> In-Reply-To: <4D6E93075B31154298572E6B73CA849D01C4485C@noida-mail.bbnet.ad> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Banibrata Dutta , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Nokia Series 60 device X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Gaurav Kheterpal wrote: > Hi, > > You can refer to > http://sw.nokia.com/id/ad2fe51c-afa0-42f1-b319-982bd0bd9f9a/Series_60_De > veloper_Platform_2_0_Specification_v1_0_en.pdf for Series 60 compliance > information. The Series 60 docs are available on > http://www.forum.nokia.com/main/0,6566,010_40,00.html#documents > > Is there any particular aspect which you would like to know about the > Series 60 compliance with RFC 3261 ? I have limited experience on using > it but I found it *reasonably* compliant with SIP specs. Long time ago I did some testing. The only problem with the stack I can remember: I found out that in the Contact of a 200 OK response from a REGISTER, there must not be a q=...; parameter. If there is a q parameter, Nokia's SIP stack does not accept the 200 OK. Another interesting thing is, if support for IM+presence (MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH) is planned. regards Klaus > > I hope this helps. > > my 2 cents, > > Gaurav > > -----Original Message----- > > > > > ********************** Legal Disclaimer **************************** > "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." > ********************************************************************** > > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Klaus > Darilion > Sent: Thursday, August 11, 2005 1:46 PM > To: Banibrata Dutta > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Nokia Series 60 device > > Hi! > > Because it is usally much more easier to ask other developers for help. > > Do you now a contact at Nokia which we may ask about their SIP stack? > > Klaus > > Banibrata Dutta wrote: > >>Why not ask Nokia ? >> >>-bd >> >>-----Original Message----- >>From: sip-implementors-bounces@cs.columbia.edu >>[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Rajesh >>Kadikar >>Sent: Thursday, August 04, 2005 2:16 AM >>To: sip@ietf.org; sip-implementors@cs.columbia.edu >>Subject: [Sip-implementors] Nokia Series 60 device >> >>Guys, >> >>I am not sure if this is the right forum for this question... >> >>But has anybody used the SIP stack that came out with Nokia Series 60? >> >>Do you know if it is RFC 3261 compliant? >> >>Thanks in advance >> >>Rajesh > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 12 07:52:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Y5H-0002k5-Lx; Fri, 12 Aug 2005 07:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Y5F-0002jv-Ck for sip@megatron.ietf.org; Fri, 12 Aug 2005 07:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17412 for ; Fri, 12 Aug 2005 07:52:19 -0400 (EDT) From: seema.jagatap@flextronicssoftware.com Received: from [61.16.168.135] (helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Ydi-0006am-1n for sip@ietf.org; Fri, 12 Aug 2005 08:28:01 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.12.5/8.12.5) with ESMTP id j7CBpo8t011979 for ; Fri, 12 Aug 2005 17:21:51 +0530 To: sip@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Fri, 12 Aug 2005 17:21:44 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 08/12/2005 05:33:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Sip] Query on SIPS/SIP URI with 'Transport=TLS' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi I have a basic doubt on formation of record route header If there is a request received by proxy which has the topmost route header with SIP URI and 'transport=tls' and the request URI also has the SIP URI (without the 'transport=tls' parameter), then should the proxy insert a sips record-route header while forwarding the message to the callee, or should ti insert a sip URI with a 'transport=tls' parameter? A justification for inserting a sips record-route could be that since the transport=tls is deprecated, hence proxy always inserts a sips record-route. Is there any reason why the proxy should not insert a sips record-route but instead use a sip uri with a transport parameter just becuase the Route header is of this latter form? The RFC does not seem to mention anything about this specific case. Following are the two references mentioned in RFC 3261 But which of them apply for this special case? As per the RFC section 16.6 bullet 4 of RFC 3261, Reference 1 : If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Reference 2: In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI. According to above mentioned section,if Request-URI or topmost Route header field value have non SIPS URI, then record route should have non SIPS URI.However RFC does not talk about the case where topmost route header has non SIPS URI and 'transport=TLS". I request others to provide their valuable opinion on this issue. thanks and regards Seema *********************** FSS-Private *********************** *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 12 09:23:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZVd-0006xK-4z; Fri, 12 Aug 2005 09:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZVa-0006xF-Di for sip@megatron.ietf.org; Fri, 12 Aug 2005 09:23:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21438 for ; Fri, 12 Aug 2005 09:23:35 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3a46-0000dt-Bs for sip@ietf.org; Fri, 12 Aug 2005 09:59:18 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7CDNA504299; Fri, 12 Aug 2005 09:23:10 -0400 (EDT) Received: from [127.0.0.1] (acart07e.ca.nortel.com [47.130.16.236]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QDGY2AQ7; Fri, 12 Aug 2005 09:23:10 -0400 Message-ID: <42FCA2AE.4060903@nortel.com> Date: Fri, 12 Aug 2005 09:22:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peili Xu Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) References: <001801c58eb8$e29d1840$5fb04c0a@huawei.com> In-Reply-To: <001801c58eb8$e29d1840$5fb04c0a@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id j7CDNA504299 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "'Ejzak, Richard P \(Richard\)'" , Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm way behind on some of my E-mail, but as the person who chaired the=20 development of Q.1912.5 I thought I'd better comment. This point about when INFO can be used was one raised by Ericsson, and=20 actually resulted in delay of approval of the specification. The view=20 was that INFO could not be sent until an early dialogue had been=20 established. That has nothing to do with whether the 183 response is=20 reliable or not. Peili Xu wrote: > Hi, Mike, >=20 > =20 >=20 > I totally agree with your comments about=20 >=20 > (1)INFO can be sent within dialog of cause at lease after early dialog = is > established. >=20 > (2)transparent backward ISUP message may be encapsulated in reliable 1x= x or > INFO. >=20 > =20 >=20 > But from the exact Q.1912.5 specification:=20 >=20 > --Q.1912.5, on the other hand, describes how "transparent" messages are > encapsulated, and it says they are carried in the following: > --a) 183 Session Progress provisional response if this is sent by the I= -IWU > in the backward direction before a confirmed dialog is established. > --b) INFO message in all other cases.=20 >=20 > =20 >=20 > It seems that backward ISUP message before call is connected must be ca= rried > in 183 before a =93confirmed dialog=94,=20 >=20 > I think this is the point which confuse some people who consider that I= NFO > in early dialog is another option. >=20 > =20 >=20 > Reguards! >=20 > =20 >=20 > Peili Xu >=20 > =20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of E= jzak, > Richard P (Richard) > Sent: Thursday, July 21, 2005 10:41 PM > To: 'Mpierce1@aol.com'; sip@ietf.org > Subject: RE: [Sip] INFO method used for ISUP to SIP IW (2nd round) >=20 > =20 >=20 > Mike, >=20 > I do not agree with your interpretation of Q.1912.5. Within RFC 3261 a= nd > RFC 3262, a dialog may be established by sending a reliable provisional= or > final response. Q.1912.5 simply says that if you haven't sent a reliab= le > response yet (provisional or final, to establish a dialog), encapsulate= a > transparent backward ISUP message in a provisional. Your interpretatio= n is > correct without 100rel, but breaks down when using 100rel. So accordin= g to > Q.1912.5, any transparent encapsulated ISUP in the backward direction a= fter > transmission of a reliable provisional response will use INFO, includin= g > during the period before transmission of the 200 OK response. Note tha= t > other (not transparent) ISUP messages follow different rules in Q.1912.= 5. >=20 > =20 >=20 > Regarding the supposed constraints on the use of INFO, RFC 2976 says th= e > following things: >=20 > =20 >=20 > It is necessary that the mid-session signaling information traverse > the post session setup SIP signaling path. This is the path taken b= y > SIP re-INVITEs, BYEs and other SIP requests that are tied to an > individual session. This allows SIP proxy servers to receive, and > potentially act on, the mid-session signaling information. >=20 > In RFC 3261 and RFC 3262, this requirement is also satisfied when a dia= log > is established using a reliable provisional response in support of, for > example, the UPDATE request. RFC 2976 goes on to say: >=20 > =20 >=20 > Unless stated otherwise, the protocol rules for the INFO request > governing the usage of tags, Route and Record-Route, > retransmission and reliability, CSeq incrementing and message > formatting follow those in [1] as defined for the BYE request. >=20 > Reference [1] is RFC 2543. This text only discusses the rules for > formatting various header. It does not constrain INFO to all aspects o= f the > use of BYE. And that's all that's said about the relationship of INFO = to > BYE at user agents. >=20 > =20 >=20 > The real problem is that RFC 2976 has not been updated to match RFC 326= 1 and > RFC 3262. But the intent of the original RFC seems clear enough to all= ow > INFO in either direction once a dialog is established, such as by sendi= ng a > reliable provisional response. I see no problem with either RFC 3398 o= r > Q.1912.5 in their use of INFO. >=20 > =20 >=20 > Richard Ejzak >=20 > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Wednesday, July 20, 2005 9:35 PM > To: sip@ietf.org > Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) >=20 > To all, >=20 > Recently, there was a discussion of the question of whether or not the = INFO > can be sent before the dialog has been established. There seemed to be > various opinions on this, but no clear answer. This is a very important > issue for SIP-T. >=20 > As I noted before, INFO is defined in RFC 2976 where it states that it > follows the rules for BYE as contained in RFC 2543. RFC 2543 is now > obsolete. In fact, the main question about the use of INFO relates to i= ts > use during early dialog, a concept which was defined after INFO was def= ined. >=20 > RFC 3261 states that the BYE is used: > in the caller to callee direction, either in confirmed or early dialog = state > in the callee to called direction, on confirmed dialog only >=20 > RFC 3398 indicates that the INFO is used to carry encapsulated ISUP: > in the caller to called direction, even if INVITE transaction is not > finished (i.e., in both early and confirmed dialog state) > in the callee to caller direction, even before answer (i.e., in both e= arly > and confirmed dialog states) >=20 > So, the use of INFO in RFC 3398 does not always follow the rules for BY= E as > stated in RFC 2976. >=20 > Q.1912.5, on the other hand, describes how "transparent" messages are > encapsulated, and it says they are carried in the following: > a) 183 Session Progress provisional response if this is sent by the I-I= WU in > the backward direction before a confirmed dialog is established. > b) INFO message in all other cases.=20 >=20 > So the ITU-T Recommendation does have the INFO following the rules for = BYE. >=20 > Is this a correct interpretation? >=20 > Mike Pierce >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 12 10:24:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aSk-0006RA-3R; Fri, 12 Aug 2005 10:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aSh-0006R5-HD for sip@megatron.ietf.org; Fri, 12 Aug 2005 10:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27048 for ; Fri, 12 Aug 2005 10:24:40 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3b1E-0002h3-D7 for sip@ietf.org; Fri, 12 Aug 2005 11:00:24 -0400 Received: from Mpierce1@aol.com by imo-d22.mx.aol.com (mail_out_v38_r4.1.) id a.208.6fddb7a (17377); Fri, 12 Aug 2005 10:22:57 -0400 (EDT) Message-ID: <208.6fddb7a.302e0ac0@aol.com> Date: Fri, 12 Aug 2005 10:22:56 EDT Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) To: taylor@nortel.com, xupeili@huawei.com MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, ejzak@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266030522==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0266030522== Content-Type: multipart/alternative; boundary="part1_208.6fddb7a.302e0ac0_boundary" --part1_208.6fddb7a.302e0ac0_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/12/2005 9:23:43 AM Eastern Daylight Time, taylor@nortel.com writes: > This point about when INFO can be used was one raised by Ericsson, and > actually resulted in delay of approval of the specification. The view > was that INFO could not be sent until an early dialogue had been > established. That has nothing to do with whether the 183 response is > reliable or not. > I don't think there was ever a question that INFO could not be used before an early dialog. The issue is whether or not it can be used after an early dialog is established and before the confirmed dialog. After all the discussion, I don't believe that there was a solid answer, since IETF RFCs and Q.1912.5 seem to be contradictory (for the callee to caller direction). There really isn't a clear statement in any RFC, except that INFO follows the rules for BYE. RFC 3261 (which was written later) says that the BYE can only be sent in the callee to caller direction on a confirmed dialog. Q.1912.5 indicates that the INFO can be sent (callee to caller direction) before confirmed dialog is established. So which is correct? Can the INFO be used during the early dialog state in the callee to caller direction? This is critically important for the operation of SIP-T. Mike Pierce --part1_208.6fddb7a.302e0ac0_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 8/12/2005 9:23:43 AM Eastern Daylight Time, taylor@nortel.com wr= ites:


This point about when INFO can=20= be used was one raised by Ericsson, and
actually resulted in delay of approval of the specification.  The view=20=
was that INFO could not be sent until an early dialogue had been
established.  That has nothing to do with whether the 183 response is <= BR> reliable or not.


I don't think there was ever a question that INFO could not be used before a= n early dialog. The issue is whether or not it can be used after an early di= alog is established and before the confirmed dialog. After all the discussio= n, I don't believe that there was a solid answer, since IETF RFCs and Q.1912= .5 seem to be contradictory (for the callee to caller direction).

There really isn't a clear statement in any RFC, except that INFO follows th= e rules for BYE. RFC 3261 (which was written later) says that the BYE can on= ly be sent in the callee to caller direction on a confirmed dialog.

Q.1912.5 indicates that the INFO can be sent (callee to caller direction) be= fore confirmed dialog is established.

So which is correct? Can the INFO be used during the early dialog state in t= he callee to caller direction? This is critically important for the operatio= n of SIP-T.

Mike Pierce
 --part1_208.6fddb7a.302e0ac0_boundary-- --===============0266030522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0266030522==-- From sip-bounces@ietf.org Fri Aug 12 14:03:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dss-0002rW-4l; Fri, 12 Aug 2005 14:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dsq-0002rL-Iw for sip@megatron.ietf.org; Fri, 12 Aug 2005 14:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08338 for ; Fri, 12 Aug 2005 14:03:52 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eRM-0000d7-MW for sip@ietf.org; Fri, 12 Aug 2005 14:39:38 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7CI1iK21599; Fri, 12 Aug 2005 14:01:44 -0400 (EDT) Received: from [127.0.0.1] (acart570.ca.nortel.com [47.130.17.227]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QDGY2C0D; Fri, 12 Aug 2005 14:03:29 -0400 Message-ID: <42FCE456.9060701@nortel.com> Date: Fri, 12 Aug 2005 14:03:02 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) References: <208.6fddb7a.302e0ac0@aol.com> In-Reply-To: <208.6fddb7a.302e0ac0@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Once upon a time I figured I'd clarify the situation by updating the INFO specification. I suppose I could still do that, but I was a bit nervous about what else might happen to that spec. if it were reopened. Anyway, you've stated the ITU-T interpretation. Mpierce1@aol.com wrote: > In a message dated 8/12/2005 9:23:43 AM Eastern Daylight Time, > taylor@nortel.com writes: > > > >>This point about when INFO can be used was one raised by Ericsson, and >>actually resulted in delay of approval of the specification. The view >>was that INFO could not be sent until an early dialogue had been >>established. That has nothing to do with whether the 183 response is >>reliable or not. >> > > > I don't think there was ever a question that INFO could not be used before an > early dialog. The issue is whether or not it can be used after an early > dialog is established and before the confirmed dialog. After all the discussion, I > don't believe that there was a solid answer, since IETF RFCs and Q.1912.5 seem > to be contradictory (for the callee to caller direction). > > There really isn't a clear statement in any RFC, except that INFO follows the > rules for BYE. RFC 3261 (which was written later) says that the BYE can only > be sent in the callee to caller direction on a confirmed dialog. > > Q.1912.5 indicates that the INFO can be sent (callee to caller direction) > before confirmed dialog is established. > > So which is correct? Can the INFO be used during the early dialog state in > the callee to caller direction? This is critically important for the operation > of SIP-T. > > Mike Pierce > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Aug 13 12:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3yjg-0002nS-Io; Sat, 13 Aug 2005 12:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3yje-0002nF-DM for sip@megatron.ietf.org; Sat, 13 Aug 2005 12:19:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28401 for ; Sat, 13 Aug 2005 12:19:48 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3zIP-0001wS-A2 for sip@ietf.org; Sat, 13 Aug 2005 12:55:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IL600IBF570S1@usaga01-in.huawei.com> for sip@ietf.org; Sat, 13 Aug 2005 09:16:13 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IL60033156ZNQ@usaga01-in.huawei.com> for sip@ietf.org; Sat, 13 Aug 2005 09:16:12 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [219.133.175.199]) by szxmc02-in.huawei.com (mshttpd); Sun, 14 Aug 2005 00:20:35 +0800 Date: Sun, 14 Aug 2005 00:20:35 +0800 From: xupeili 18916 Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) To: Tom-PT Taylor Message-id: <8173ea81994f.81994f8173ea@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org, Mpierce1@aol.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Update RFC2976 will help those who don`t want to take the risk of disobey RFC even have some doubt about it. Before that I think we can treat INFO like UPDATE except that UPDATE will do session modification. Peili Xu ----- Original Message ----- From: Tom-PT Taylor Date: Saturday, August 13, 2005 2:03 am Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round) > Once upon a time I figured I'd clarify the situation by updating > the > INFO specification. I suppose I could still do that, but I was a > bit > nervous about what else might happen to that spec. if it were > reopened. > Anyway, you've stated the ITU-T interpretation. > > Mpierce1@aol.com wrote: > > In a message dated 8/12/2005 9:23:43 AM Eastern Daylight Time, > > taylor@nortel.com writes: > > > > > > > >>This point about when INFO can be used was one raised by > Ericsson, and > >>actually resulted in delay of approval of the specification. > The view > >>was that INFO could not be sent until an early dialogue had been > >>established. That has nothing to do with whether the 183 > response is > >>reliable or not. > >> > > > > > > I don't think there was ever a question that INFO could not be > used before an > > early dialog. The issue is whether or not it can be used after > an early > > dialog is established and before the confirmed dialog. After all > the discussion, I > > don't believe that there was a solid answer, since IETF RFCs and > Q.1912.5 seem > > to be contradictory (for the callee to caller direction). > > > > There really isn't a clear statement in any RFC, except that > INFO follows the > > rules for BYE. RFC 3261 (which was written later) says that the > BYE can only > > be sent in the callee to caller direction on a confirmed dialog. > > > > Q.1912.5 indicates that the INFO can be sent (callee to caller > direction) > > before confirmed dialog is established. > > > > So which is correct? Can the INFO be used during the early > dialog state in > > the callee to caller direction? This is critically important for > the operation > > of SIP-T. > > > > Mike Pierce > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 14 20:02:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4SR7-0001Qb-HV; Sun, 14 Aug 2005 20:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4SR6-0001QW-Bt for sip@megatron.ietf.org; Sun, 14 Aug 2005 20:02:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19708 for ; Sun, 14 Aug 2005 20:02:38 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4T05-0008EY-2R for sip@ietf.org; Sun, 14 Aug 2005 20:38:52 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7F01HG3011130; Sun, 14 Aug 2005 18:01:17 -0600 (MDT) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt Date: Sun, 14 Aug 2005 18:01:22 -0600 Message-ID: Thread-Topic: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt Thread-Index: AcWPk/cXVZjMLA/XSFe51HRxkewSGgRlW/5Q From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, I have not followed this work closely so sorry if my comments are = off-track, but here are 2 comments.=20 --- 1.=20 The first comment is to consider aligning the aBNF grammar more = strictly with the UAC/UAS behaviors on the remote-param and local-param. Sections 3 & 4 state that target-dialog should be authorized if both = the remote-param and local-param are present (pending various conditions = met). On the UAS, you even indicate the request for authorization MUST = be ignored if both param are not provided (strong MUST). Yet the grammar is much looser: Target-Dialog =3D "Target-Dialog" HCOLON call-id *(SEMI td-param) td-param =3D remote-param / local-param / generic-param remote-param =3D "remote-tag" EQUAL token local-param =3D "local-tag" EQUAL token Is there a reason for not making the grammar stricter to mandate both = remote and local params? Or turning the question around, what would be = examples when an authorization would be granted without both? I understand the potential issues of msgs being rejected due to bad = grammar vs. msgs being accepted while only the header could be ignored = but it seems that an implementation using this new header should be = strict when sending the header. --- 2. IANA section and Header Field Parameters Sub-Registry Per RFC3968, would it make sense to register the Target-Dialog header = field parameters?=20 Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 15 19:07:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4o2m-0003gt-RY; Mon, 15 Aug 2005 19:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4o2l-0003gn-4g for sip@megatron.ietf.org; Mon, 15 Aug 2005 19:06:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11237 for ; Mon, 15 Aug 2005 19:06:56 -0400 (EDT) From: Pierre.Lacour@alcatel.fr Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4obx-000715-Qf for sip@ietf.org; Mon, 15 Aug 2005 19:43:23 -0400 Received: from frmail15.netfr.alcatel.fr (frmail15.netfr.alcatel.fr [155.132.251.15]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j7FN0jgr007069 for ; Tue, 16 Aug 2005 01:06:43 +0200 To: sip@ietf.org Message-ID: Date: Tue, 16 Aug 2005 01:02:20 +0200 X-MIMETrack: Serialize by Router on FRMAIL15/FR/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 08/16/2005 01:06:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] Pierre LACOUR/FR/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office starting 15/08/2005 and will not return until 29/08/2005. I will respond to your message when I return _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 17 07:10:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Lo9-00073U-8w; Wed, 17 Aug 2005 07:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Lo6-00072f-Vv for sip@megatron.ietf.org; Wed, 17 Aug 2005 07:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21537 for ; Wed, 17 Aug 2005 07:10:04 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MNc-0003XO-PM for sip@ietf.org; Wed, 17 Aug 2005 07:46:50 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILD0065V5RBBR@szxga03-in.huawei.com> for sip@ietf.org; Wed, 17 Aug 2005 19:11:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILD0065W5RBAN@szxga03-in.huawei.com> for sip@ietf.org; Wed, 17 Aug 2005 19:11:35 +0800 (CST) Received: from w26552 ([10.76.176.84]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILD00D59629VL@szxml01-in.huawei.com>; Wed, 17 Aug 2005 19:18:09 +0800 (CST) Date: Wed, 17 Aug 2005 19:08:44 +0800 From: Rocky Wang Subject: RE: [Sip] how to understand this sentence? In-reply-to: To: "'cai youyuan'" , sip@ietf.org Message-id: <000001c5a31c$0876eab0$54b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The subscription means the contract you made with your service provider. For the same subscription, you can have several public identifiers which can be used to find where you are, just like the telephone numbers you hold. But in the current network, one subscription is always related to one subscription, that is one contact have only one telephone number. Best Regards, Rocky Wang -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of cai youyuan Sent: 2005=C4=EA8=D4=C23=C8=D5 13:00 To: sip@ietf.org Subject: [Sip] how to understand this sentence? Hi, In TS 23.228, "the private identity identifies the subscription, not the=20 user", can I understand user can have several private identities if he have=20 several subscriptin services? if user want to register, he use which=20 private identity? expect your anser, thx _________________________________________________________________ =CF=ED=D3=C3=CA=C0=BD=E7=C9=CF=D7=EE=B4=F3=B5=C4=B5=E7=D7=D3=D3=CA=BC=FE=CF= =B5=CD=B3=A1=AA MSN Hotmail=A1=A3 http://www.hotmail.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 17 07:10:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LoC-00074t-QD; Wed, 17 Aug 2005 07:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Lo9-000741-O0 for sip@megatron.ietf.org; Wed, 17 Aug 2005 07:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21543 for ; Wed, 17 Aug 2005 07:10:06 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MNe-0003XO-RN for sip@ietf.org; Wed, 17 Aug 2005 07:46:53 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILD006QD5RJ7J@szxga03-in.huawei.com> for sip@ietf.org; Wed, 17 Aug 2005 19:11:44 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILD0066N5RJAN@szxga03-in.huawei.com> for sip@ietf.org; Wed, 17 Aug 2005 19:11:43 +0800 (CST) Received: from w26552 ([10.76.176.84]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILD00D6562HVL@szxml01-in.huawei.com>; Wed, 17 Aug 2005 19:18:17 +0800 (CST) Date: Wed, 17 Aug 2005 19:08:52 +0800 From: Rocky Wang Subject: RE: [Sip] Question on via branch computation In-reply-to: To: "'Andonegui Jesus-JANDONE1'" Message-id: <000101c5a31c$0d3a3f20$54b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132242692==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1132242692== Content-type: multipart/alternative; boundary="Boundary_(ID_59meEYNd0sQrXD1EiUGH4Q)" This is a multi-part message in MIME format. --Boundary_(ID_59meEYNd0sQrXD1EiUGH4Q) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT It is up to the implementation on how to guarantee that the loop can be detected immediately. And it is also very important to select the input set. For instance, the input can input the request-URI, all the route headers, Call-ID, From-tag and To-tag. Based on the last 3 parameters, it has enough information to ensure the branch ID is in the dialog, and all the other parameters to ensure that the next processes will cause the same behavior to all the related SIP nodes. You can also add some other information which will impact on the route selection and further processes. Regards, Rocky Wang -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Andonegui Jesus-JANDONE1 Sent: 2005?8?5? 0:06 To: sip@ietf.org Subject: [Sip] Question on via branch computation Hi, I have a question related to the via branch computation: why is it possible (according to RFC3216 section 16.6 step 8) to use the topmost via header entry in the computation of the cryptographic hash ? If there is a loop, a server may get the same request from different servers and in that case the topmost via header entry will differ. If you use the topmost via header entry to compute the branch you will not detect the loop in that case. Thanks, Jesus --Boundary_(ID_59meEYNd0sQrXD1EiUGH4Q) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

It is up to the implementation on how to guarantee that the loop can be detected immediately.  And it is also very important to select the input set.

For instance, the input can input the request-URI, all the route headers, Call-ID, From-tag and To-tag. Based on the last 3 parameters, it has enough information to ensure the branch ID is in the dialog, and all the other parameters to ensure that the next processes will cause the same behavior to all the related SIP nodes.

You can also add some other information which will impact on the route selection and further processes.

 

Regards,

Rocky Wang

 

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Andonegui Jesus-JANDONE1
Sent: 2005年8月5日 0:06
To: sip@ietf.org
Subject: [Sip] Question on via branch computation

 

Hi,

 

I have a question related to the via branch computation: why is it possible (according to RFC3216 section 16.6 step 8) to use the topmost via header entry in the computation of the cryptographic hash ? If there is a loop, a server may get the same request from different servers and in that case the topmost via header entry will differ. If you use the topmost via header entry to compute the branch you will not detect the loop in that case.

 

Thanks,

Jesus

--Boundary_(ID_59meEYNd0sQrXD1EiUGH4Q)-- --===============1132242692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1132242692==-- From sip-bounces@ietf.org Thu Aug 18 10:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lJ5-0006lC-HR; Thu, 18 Aug 2005 10:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lJ2-0006hu-CT for sip@megatron.ietf.org; Thu, 18 Aug 2005 10:23:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08263 for ; Thu, 18 Aug 2005 10:23:42 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lsm-0002Gb-HN for sip@ietf.org; Thu, 18 Aug 2005 11:00:41 -0400 Received: by wproxy.gmail.com with SMTP id i11so361284wra for ; Thu, 18 Aug 2005 07:23:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=AV8k+VLiKK115g4PY1WB4jvL8s0cZuZYbAYFYlyzXSJIe1b4lerpOXAhGug0hCXLYe0WJvDWpz+VtDLxD7XsDe+pOkxDo5gMUnE9oWvW3XmM8h+B/d6qU3FGluLE263HrduTfAgqg/mTNmC0I+3IBXsQ64mzlZMP3wuJ/62kx94= Received: by 10.54.109.10 with SMTP id h10mr1231424wrc; Thu, 18 Aug 2005 07:23:33 -0700 (PDT) Received: by 10.54.95.16 with HTTP; Thu, 18 Aug 2005 07:23:33 -0700 (PDT) Message-ID: <52db68bc0508180723638273f7@mail.gmail.com> Date: Thu, 18 Aug 2005 19:53:33 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org Mime-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] query abt 4xx response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2092676940==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2092676940== Content-Type: multipart/alternative; boundary="----=_Part_6867_27421172.1124375013893" ------=_Part_6867_27421172.1124375013893 Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 IEhpIEFsbAogSSBoYWQgZmV3IGRvdWJ0cyBpbiBwcm9jZXNzaW5nIDR4eCByZXNwb25zZXMgYnkg VUFDCiAKNDA1IE1ldGhvZCBOb3QgQWxsb3dlZJd3aGF0IG1ldGhvZCBpcyBub3QgYWxsb3dlZD8K CjQwNiBOb3QgQWNjZXB0YWJsZQoKNDE0IFJlcXVlc3QgVVJJIHRvbyBsb25nIAoKYW55IHRob3Vn aHRzIGFyZSBhcHBlcmljYXRlZAogdGhhbmtzIGluIGFkdmFuY2UKIHJlZ2FyZHMKLS0gClN1ZGhp ciBLdW1hciBSZWRkeSAKU29mdHdhcmUgRW5naW5lZXIsClF1YWxQaG9uZSBjb21tdW5pY2F0aW9u cyBwdnQuIGx0ZC4KMDk4NDUwNTI2NTEK ------=_Part_6867_27421172.1124375013893 Content-Type: text/html; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PHNwYW4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PHNwYW4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5IaSBBbGw8L3NwYW4+PC9kaXY+CjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxzcGFuIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9zcGFuPiZuYnNwOzwvZGl2 Pgo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48c3Bh biBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkkgaGFkIGZldyBk b3VidHMmbmJzcDtpbiBwcm9jZXNzaW5nIDR4eCByZXNwb25zZXMgYnkgVUFDPC9zcGFuPjwvZGl2 Pgo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48c3Bh biBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvc3Bhbj4mbmJz cDs8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7 IExJTkUtSEVJR0hUOiAxNHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0Ij40MDUg TWV0aG9kIE5vdCBBbGxvd2Vkl3doYXQgbWV0aG9kIGlzIG5vdCBhbGxvd2VkPzwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBMSU5FLUhF SUdIVDogMTRwdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdCI+NDA2IE5vdCBBY2Nl cHRhYmxlPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQ7IExJTkUtSEVJR0hUOiAxNHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEu MHB0Ij40MTQgUmVxdWVzdCBVUkkgdG9vIGxvbmcgPC9zcGFuPjwvcD4KPGRpdj48YnIgY2xlYXI9 ImFsbCI+YW55IHRob3VnaHRzIGFyZSBhcHBlcmljYXRlZDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2 Pgo8ZGl2PnRoYW5rcyBpbiBhZHZhbmNlPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+cmVn YXJkczxicj4tLSA8YnI+U3VkaGlyIEt1bWFyIFJlZGR5IDxicj5Tb2Z0d2FyZSBFbmdpbmVlciw8 YnI+UXVhbFBob25lIGNvbW11bmljYXRpb25zIHB2dC4gbHRkLjxicj4wOTg0NTA1MjY1MSA8L2Rp dj48L3NwYW4+PC9kaXY+Cg== ------=_Part_6867_27421172.1124375013893-- --===============2092676940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2092676940==-- From sip-bounces@ietf.org Thu Aug 18 11:27:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mIO-0000pO-OA; Thu, 18 Aug 2005 11:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mIN-0000pJ-1J for sip@megatron.ietf.org; Thu, 18 Aug 2005 11:27:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12526 for ; Thu, 18 Aug 2005 11:27:04 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ms7-0004Qi-TU for sip@ietf.org; Thu, 18 Aug 2005 12:04:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2005 08:26:56 -0700 X-IronPort-AV: i="3.96,121,1122879600"; d="scan'208"; a="655428632:sNHT30252328" 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 j7IFQLpO028357; Thu, 18 Aug 2005 08:26:54 -0700 (PDT) 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); Thu, 18 Aug 2005 08:26:47 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 08:26:46 -0700 Message-Id: <4.3.2.7.2.20050818102016.03b77590@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Aug 2005 10:26:45 -0500 To: Sudhir Kumar Reddy , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] query abt 4xx response In-Reply-To: <52db68bc0508180723638273f7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 Aug 2005 15:26:46.0948 (UTC) FILETIME=[3F0E2640:01C5A409] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 07:53 PM 8/18/2005 +0530, Sudhir Kumar Reddy wrote: >Hi All > >I had few doubts in processing 4xx responses by UAC by the way - all responses are by the UAS for that transaction. The UAC=20 sends the Requests for a transaction. > > >405 Method Not Allowed=97what method is not allowed? One that the UAC doesn't support, likely meaning one of the extension=20 Methods like UPDATE, REFER, INFO, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE or= PRACK >406 Not Acceptable This means that something that was Requested was not acceptable, for=20 example, if a call were set up with one codec, and one UA sends a reINVITE= =20 with a new codec (to change the RTP stream to this new codec in place of=20 the first), the UAS could deny that request by sending a 406 >414 Request URI too long I think this one is as it states, though I haven't run into this problem, I= =20 can imagine that since the text fields are unbounded to a great degree, a=20 UAC could include one that the UAS simply could not process due to its=20 length. Others may have specific experience with this one. This could also= =20 be rooted in the similarity of SIP to HTTP, and those URIs can get quite= long. >any thoughts are appericated > >thanks in advance > >regards >-- >Sudhir Kumar Reddy >Software Engineer, >QualPhone communications pvt. ltd. >09845052651 >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 18 12:30:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nHI-0003TE-DX; Thu, 18 Aug 2005 12:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nHF-0003SN-Ty for sip@megatron.ietf.org; Thu, 18 Aug 2005 12:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16151 for ; Thu, 18 Aug 2005 12:29:58 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nqx-0006O1-Rm for sip@ietf.org; Thu, 18 Aug 2005 13:07:00 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILF00LRKFGNWC@szxga02-in.huawei.com> for sip@ietf.org; Fri, 19 Aug 2005 00:36:23 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILF00H1NFGNRT@szxga02-in.huawei.com> for sip@ietf.org; Fri, 19 Aug 2005 00:36:23 +0800 (CST) Received: from mspt9ukf7x4jg7 ([218.17.72.3]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILF004WKFLR35@szxml01-in.huawei.com>; Fri, 19 Aug 2005 00:39:28 +0800 (CST) Date: Fri, 19 Aug 2005 00:29:09 +0800 From: Peili Xu Subject: Re: [Sip] query abt 4xx response To: Sudhir Kumar Reddy , sip@ietf.org Message-id: <006401c5a411$f6403710$9878fea9@mspt9ukf7x4jg7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <52db68bc0508180723638273f7@mail.gmail.com> X-Spam-Score: 3.4 (+++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0843547938==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0843547938== Content-type: multipart/alternative; boundary="Boundary_(ID_zgboL+uRuVe1VCd3nH+Rzw)" This is a multi-part message in MIME format. --Boundary_(ID_zgboL+uRuVe1VCd3nH+Rzw) Content-type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: base64 SSBndWVzcyB5b3UgYXJlIGFza2luZyBmb3IgbW9yZSBpbmZvcm1hdGlvbiB3aHkgdGhlIHJlcXVl c3QgZmFpbGVkIGJ5IHRoYXQgNHh4IHJlc3BvbnNlLg0KDQpmb3IgNDA1LCBVQVMgY2FuIGZpbGwg QWxsb3cgaGVhZGVyIHRvIGluZGljYXRlIHdoYXQgaXQgYWxsb3dzLg0KZm9yIDQwNiwgVUFTIGNh biBmaWxsIEFjY2VwdCB0byBpbmRpY2F0ZSB3aGF0IGl0IGFjY2VwdHMuDQphbHNvIGZvciA0MTQs IG1heWJlIFVBUyBjYW4gcHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGluIFdhcm5pbmcgaGVhZGVy Lg0KDQpyZWdhcmRzDQoNClBlaWxpDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQog IEZyb206IFN1ZGhpciBLdW1hciBSZWRkeSANCiAgVG86IHNpcEBpZXRmLm9yZyANCiAgU2VudDog VGh1cnNkYXksIEF1Z3VzdCAxOCwgMjAwNSAxMDoyMyBQTQ0KICBTdWJqZWN0OiBbU2lwXSBxdWVy eSBhYnQgNHh4IHJlc3BvbnNlDQoNCg0KICBIaSBBbGwNCg0KICBJIGhhZCBmZXcgZG91YnRzIGlu IHByb2Nlc3NpbmcgNHh4IHJlc3BvbnNlcyBieSBVQUMNCg0KICA0MDUgTWV0aG9kIE5vdCBBbGxv d2Vkl3doYXQgbWV0aG9kIGlzIG5vdCBhbGxvd2VkPw0KDQogIDQwNiBOb3QgQWNjZXB0YWJsZQ0K DQogIDQxNCBSZXF1ZXN0IFVSSSB0b28gbG9uZyANCg0KDQogIGFueSB0aG91Z2h0cyBhcmUgYXBw ZXJpY2F0ZWQNCg0KICB0aGFua3MgaW4gYWR2YW5jZQ0KDQogIHJlZ2FyZHMNCiAgLS0gDQogIFN1 ZGhpciBLdW1hciBSZWRkeSANCiAgU29mdHdhcmUgRW5naW5lZXIsDQogIFF1YWxQaG9uZSBjb21t dW5pY2F0aW9ucyBwdnQuIGx0ZC4NCiAgMDk4NDUwNTI2NTEgDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXANCiAgVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNv cmUgU0lQIFByb3RvY29sDQogIFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBm b3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQogIFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBu ZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXA= --Boundary_(ID_zgboL+uRuVe1VCd3nH+Rzw) Content-type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNjMGRjYzA+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3OyBzaXplPTI+SSBndWVzcyB5b3UgYXJlIGFza2luZyBmb3IgbW9yZSBpbmZvcm1hdGlvbiB3 aHkgdGhlIA0KcmVxdWVzdCBmYWlsZWQgYnkgdGhhdCA0eHggcmVzcG9uc2UuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5mb3IgNDA1LCBV QVMgY2FuIGZpbGwgQWxsb3cgaGVhZGVyIHRvIGluZGljYXRlIHdoYXQgaXQgDQphbGxvd3MuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPmZvciA0 MDYsIFVBUyBjYW4gZmlsbCBBY2NlcHQgdG8gaW5kaWNhdGUgd2hhdCBpdCANCmFjY2VwdHMuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPmFsc28g Zm9yIDQxNCwgbWF5YmUgVUFTIGNhbiBwcm92aWRlIHNvbWUgaW5mb3JtYXRpb24gDQppbiBXYXJu aW5nIGhlYWRlci48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPnJlZ2FyZHM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlBlaWxpPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpz dHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6 IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0 OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206 PC9CPiANCiAgPEEgdGl0bGU9dC5zdWRoaXJrdW1hckBnbWFpbC5jb20gaHJlZj0ibWFpbHRvOnQu c3VkaGlya3VtYXJAZ21haWwuY29tIj5TdWRoaXIgDQogIEt1bWFyIFJlZGR5PC9BPiA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEg dGl0bGU9c2lwQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86c2lwQGlldGYub3JnIj5zaXBAaWV0 Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMDUgMTA6MjMgDQpQTTwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8 L0I+IFtTaXBdIHF1ZXJ5IGFidCA0eHggcmVzcG9uc2U8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ DQogIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4NCiAgPERJ ViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkhpIEFsbDwvU1BBTj48 L0RJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQi PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogQXJpYWwiPkkgaGFkIGZldyBkb3VidHMmbmJzcDtpbiANCiAgcHJvY2Vzc2luZyA0eHggcmVz cG9uc2VzIGJ5IFVBQzwvU1BBTj48L0RJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgTElORS1IRUlHSFQ6IDE0cHQ7IG1z by1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog QXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0Ij40MDUgTWV0aG9kIE5vdCANCiAgQWxs b3dlZJd3aGF0IG1ldGhvZCBpcyBub3QgYWxsb3dlZD88L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBMSU5FLUhFSUdIVDogMTRw dDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQiPjQwNiBOb3QgDQogIEFjY2Vw dGFibGU8L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gMHB0OyBMSU5FLUhFSUdIVDogMTRwdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBu b25lIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1z aXplOiAxMS4wcHQiPjQxNCBSZXF1ZXN0IFVSSSB0b28gDQogIGxvbmcgPC9TUEFOPjwvUD4NCiAg PERJVj48QlIgY2xlYXI9YWxsPmFueSB0aG91Z2h0cyBhcmUgYXBwZXJpY2F0ZWQ8L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8 RElWPnRoYW5rcyBpbiBhZHZhbmNlPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+ cmVnYXJkczxCUj4tLSA8QlI+U3VkaGlyIEt1bWFyIFJlZGR5IDxCUj5Tb2Z0d2FyZSBFbmdpbmVl ciw8QlI+UXVhbFBob25lIA0KICBjb21tdW5pY2F0aW9ucyBwdnQuIGx0ZC48QlI+MDk4NDUwNTI2 NTEgPC9ESVY+PC9TUEFOPjwvRElWPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5TaXAgbWFpbGluZyAN CiAgbGlzdCZuYnNwOyBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXA8 QlI+VGhpcyBsaXN0IGlzIGZvciBORVcgDQogIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQ cm90b2NvbDxCUj5Vc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgDQogIGZvciBx dWVzdGlvbnMgb24gY3VycmVudCBzaXA8QlI+VXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBk ZXZlbG9wbWVudHMgb24gDQogIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXA8L0JMT0NLUVVPVEU+PC9C T0RZPjwvSFRNTD4NCg== --Boundary_(ID_zgboL+uRuVe1VCd3nH+Rzw)-- --===============0843547938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0843547938==-- From sip-bounces@ietf.org Fri Aug 19 12:37:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69sL-0002ql-26; Fri, 19 Aug 2005 12:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Bdb-0005wu-RR for sip@megatron.ietf.org; Thu, 11 Aug 2005 07:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25250 for ; Thu, 11 Aug 2005 07:54:18 -0400 (EDT) Received: from cnxtsmtp8.conexant.com ([216.89.70.36] helo=mime-nj.bbnet.ad) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3CBt-0002KE-R9 for sip@ietf.org; Thu, 11 Aug 2005 08:29:47 -0400 Received: Conexant Mail Received: Conexant Mail Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2005 17:24:54 +0530 Message-ID: <4D6E93075B31154298572E6B73CA849D01C4485C@noida-mail.bbnet.ad> Thread-Topic: [Sip-implementors] Nokia Series 60 device Thread-Index: AcWeUnZVxAbPJ1buS7CkZ6I4RODRDwAFfaRQ From: "Gaurav Kheterpal" To: "Klaus Darilion" , "Banibrata Dutta" X-OriginalArrivalTime: 11 Aug 2005 11:55:00.0955 (UTC) FILETIME=[80CD3AB0:01C59E6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 19 Aug 2005 12:37:45 -0400 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Nokia Series 60 device X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, You can refer to http://sw.nokia.com/id/ad2fe51c-afa0-42f1-b319-982bd0bd9f9a/Series_60_De veloper_Platform_2_0_Specification_v1_0_en.pdf for Series 60 compliance information. The Series 60 docs are available on http://www.forum.nokia.com/main/0,6566,010_40,00.html#documents Is there any particular aspect which you would like to know about the Series 60 compliance with RFC 3261 ? I have limited experience on using it but I found it *reasonably* compliant with SIP specs. I hope this helps. my 2 cents, Gaurav -----Original Message----- ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole u= se of the intended recipient. Any unauthorized review, use or distribution= by others is strictly prohibited. If you have received the message in err= or, please advise the sender by reply email and delete the message. Thank y= ou." ********************************************************************** From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Klaus Darilion Sent: Thursday, August 11, 2005 1:46 PM To: Banibrata Dutta Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Nokia Series 60 device Hi! Because it is usally much more easier to ask other developers for help. Do you now a contact at Nokia which we may ask about their SIP stack? Klaus Banibrata Dutta wrote: > Why not ask Nokia ? >=20 > -bd >=20 > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Rajesh=20 > Kadikar > Sent: Thursday, August 04, 2005 2:16 AM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Nokia Series 60 device >=20 > Guys, >=20 > I am not sure if this is the right forum for this question... >=20 > But has anybody used the SIP stack that came out with Nokia Series 60? >=20 > Do you know if it is RFC 3261 compliant? >=20 > Thanks in advance >=20 > Rajesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 19 12:37:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69sM-0002rG-HT; Fri, 19 Aug 2005 12:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3H9c-0002pk-Tj for sip@megatron.ietf.org; Thu, 11 Aug 2005 13:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16264 for ; Thu, 11 Aug 2005 13:47:43 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Hhw-0003OG-QU for sip@ietf.org; Thu, 11 Aug 2005 14:23:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Aug 2005 20:42:55 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CDD5F7F@mail.followap.com> Thread-Topic: draft-ietf-sip-refer-feature-param-00 Thread-Index: AcWem17YSUwBaNsSR0SBuusF3g7LKw== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-Mailman-Approved-At: Fri, 19 Aug 2005 12:37:44 -0400 Cc: sip@ietf.org Subject: [Sip] draft-ietf-sip-refer-feature-param-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999497094==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1999497094== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59E9C.1AE9A9CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59E9C.1AE9A9CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Orit, Referring to below: =20 Note that if any URI parameters are present, the entire URI must be enclosed in "<" and ">". If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. =20 It may be needed to clarify that the feature tags as indicated in 3840 and those added with prescaps-ext-04 (e.g. message) are header parameters and thus are outside the <> enclosing the URI. The URI headers are enclosed (e.g. tcp transport). =20 In addition, it may be needed to show a case of the conferencing (sipping-cc-conferencing) example of REFER to REFER (where Refer-To URI has method=3DREFER parameters with another Refer-To). =20 Cheers, --Fridy / Followap ------_=_NextPart_001_01C59E9C.1AE9A9CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Orit,




Referring to =
below:   
        =
Note that if any URI parameters are present, the entire URI must =
be
        =
enclosed in "<" and ">".  If no =
"<" and ">" are present, =
all
        =
parameters after the URI are header parameters, not URI =
parameters.

 

It may be needed to clarify that the feature tags as indicated in 3840 and those added with prescaps-ext-04 (e.g. message) = are header parameters and thus are outside the <> enclosing the URI. = The URI headers are enclosed (e.g. tcp transport).

 

In addition, it may be needed to show a case of the conferencing (sipping-cc-conferencing) example of REFER to REFER (where Refer-To URI has method=3DREFER parameters with another = Refer-To).

 

Cheers,

--Fridy / Followap

------_=_NextPart_001_01C59E9C.1AE9A9CE-- --===============1999497094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1999497094==-- From sip-bounces@ietf.org Fri Aug 19 12:37:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69sN-0002rh-Oh; Fri, 19 Aug 2005 12:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Hcw-0001eF-Mx for sip@megatron.ietf.org; Thu, 11 Aug 2005 14:18:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17671 for ; Thu, 11 Aug 2005 14:18:01 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3IBH-0004Cd-FU for sip@ietf.org; Thu, 11 Aug 2005 14:53:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Aug 2005 21:09:44 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CDD5F8D@mail.followap.com> Thread-Topic: draft-ietf-sip-target-dialog Thread-Index: AcWen9ookpfzauB8QM6MuNH/zDthJA== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 X-Mailman-Approved-At: Fri, 19 Aug 2005 12:37:45 -0400 Cc: sip@ietf.org Subject: [Sip] draft-ietf-sip-target-dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1212083914==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1212083914== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59EA0.867AD682" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59EA0.867AD682 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Few questions on this: 1) Why NOTIFY is mentioned in paragraph 1 as a dialog creation transaction? (perhaps alongside SUBSCRIBE but it may be confusing). Indeed NOTIFY is not marked in section 7. 2) Relating to below: Instead, a better approach is for user agent A to send the REFER request to user agent C outside of the dialog using its Globally Routable User Agent URI (GRUU) [9]. In that case, a means is needed for user agent B to authorize the REFER As A transfers B to C, A send OOB REFER to C as said above in the first sentence. The 2nd one may be confusing as B is not part of that REFER. B needs to authorize C. 3) Chapter 2 seems to be overview ONLY of the app interaction use case outline in 1 (and not others, e.g. not a general overview...). 4) 3.2 indicates a use case of SUBSCRIBE to conference EP. This can be highlighted in 1, or just generalized in 1 use case talking about SUBSCRIBE, referring to both dialog and conference EP or being general without mentioning either. =20 Thanks, --Fridy / Followap ------_=_NextPart_001_01C59EA0.867AD682 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Few questions on this:

1)       = Why NOTIFY is mentioned in paragraph 1 as a dialog creation transaction? = (perhaps alongside SUBSCRIBE but it may be confusing). Indeed NOTIFY is not = marked in section 7.

2)       = Relating to below:

Instead, a better approach is for user agent =
A to send the
REFER =
request to user agent C outside of the dialog using =
its
Globally =
Routable User Agent URI (GRUU) [9].  In that case, a =
means
is needed =
for user agent B to authorize the REFER

As A = transfers B to C, A send OOB REFER to C as said above in the first sentence. The = 2nd one may be confusing as B is not part of that REFER. B needs to = authorize C.

3)       = Chapter 2 seems to be overview ONLY of the app interaction use case outline in 1 = (and not others, e.g. not a general = overview…).

4)       = 3.2 indicates a use case of SUBSCRIBE to conference EP. This can be = highlighted in 1, or just generalized in 1 use case talking about SUBSCRIBE, referring = to both dialog and conference EP or being general without mentioning = either.

 
Thanks,

--Fridy / Followap

------_=_NextPart_001_01C59EA0.867AD682-- --===============1212083914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1212083914==-- From sip-bounces@ietf.org Sat Aug 20 15:19:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Yso-0005Ve-VK; Sat, 20 Aug 2005 15:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ysm-0005VZ-VK for sip@megatron.ietf.org; Sat, 20 Aug 2005 15:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05028 for ; Sat, 20 Aug 2005 15:19:55 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6ZSx-0003oF-FQ for sip@ietf.org; Sat, 20 Aug 2005 15:57:22 -0400 Received: by zproxy.gmail.com with SMTP id i1so561739nzh for ; Sat, 20 Aug 2005 12:19:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EjxTeeHMgd4JnJENeZZMfGs67lW19HSqdsSphRe7qIMJ83WLIg710TwmsAOjHktWFkJgDuyYGt/GTtXTjGyHbMZOPIo4aUxKaVRh59bD6gsrVqpl+Lm4MgLDResa5KNtXYPXO8RgtLPtxyeX6yU03brp6eKxYZoJcMEzmIYgCWw= Received: by 10.36.221.52 with SMTP id t52mr3024410nzg; Sat, 20 Aug 2005 12:19:42 -0700 (PDT) Received: by 10.37.22.70 with HTTP; Sat, 20 Aug 2005 12:19:42 -0700 (PDT) Message-ID: <8320074d05082012197447d6b8@mail.gmail.com> Date: Sun, 21 Aug 2005 00:49:42 +0530 From: Rohan Sen To: SIP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Sip] Open source implementations for testing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Does anyone know of any open source (or freely available) SIP User Agents which allow to configure (or better bypass) proxies and also proxies for download. I need a couple of them for interoperability testing against a SIP implementation that I am developing. Any help in this regard will be greatly appreciated. --=20 thanks, Rohan Sen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 21 13:41:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tov-0004oq-BR; Sun, 21 Aug 2005 13:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tos-0004nU-DP for sip@megatron.ietf.org; Sun, 21 Aug 2005 13:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09542 for ; Sun, 21 Aug 2005 13:41:17 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6uPG-0004FA-M8 for sip@ietf.org; Sun, 21 Aug 2005 14:18:55 -0400 Received: by wproxy.gmail.com with SMTP id 49so187296wri for ; Sun, 21 Aug 2005 10:41:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V9RMfbNn/ouqYJtl6CrX6lmKpZkxIaWpwORPwVOaoHlBSZFcizJhgnQIRKk0EPhjAKoM7Is533mrtPbZuGDmwv3/9WtCK+QU9uMCPYFHEoU2WeFO1K5dg1oRICaDcQP2E3DSG7SL+wpyXb6goo3O0yV0qNyKrnrDqK9C6Up4Mdg= Received: by 10.54.17.32 with SMTP id 32mr67367wrq; Sun, 21 Aug 2005 10:41:05 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Sun, 21 Aug 2005 10:41:05 -0700 (PDT) Message-ID: Date: Sun, 21 Aug 2005 13:41:05 -0400 From: Arjun Roychowdhury To: Rohan Sen Subject: Re: [Sip] Open source implementations for testing In-Reply-To: <8320074d05082012197447d6b8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8320074d05082012197447d6b8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org A good list of free / trial / commercial software: http://www.sipcenter.com/sip.nsf/html/User+Agents,+Source+Code http://www.cs.columbia.edu/sip/implementations.html Also see http://www.sipfoundry.org/sipX/ - pretty good stuff regds arjun On 8/20/05, Rohan Sen wrote: > Hi, >=20 > Does anyone know of any open source (or freely available) SIP User > Agents which allow to configure (or better bypass) proxies and also > proxies for download. >=20 > I need a couple of them for interoperability testing against a SIP > implementation that I am developing. >=20 > Any help in this regard will be greatly appreciated. > -- > thanks, > Rohan Sen >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 --=20 Arjun Roychowdhury _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 21 14:41:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ulJ-0006pW-1A; Sun, 21 Aug 2005 14:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ulH-0006pN-Jx for sip@megatron.ietf.org; Sun, 21 Aug 2005 14:41:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11749 for ; Sun, 21 Aug 2005 14:41:38 -0400 (EDT) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6vLg-0005Ww-Cd for sip@ietf.org; Sun, 21 Aug 2005 15:19:17 -0400 Received: from [192.168.1.4] (pool-70-16-6-169.balt.east.verizon.net [70.16.6.169]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id j7LIfJO02529 for ; Sun, 21 Aug 2005 13:41:19 -0500 From: "Frank W. Miller" To: sip@ietf.org Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sun, 21 Aug 2005 14:41:17 -0400 Message-Id: <1124649677.2955.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Sip] STUN state machine question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Greetings, I've been working with STUN a bit lately and have run into an interesting situation. This may have been discussed elsewhere and I just haven't seen it. If so, I apologize and would appreciate a pointer to that discussion. In the state diagram, Figure 2 of RFC 3489, there is a path to repeat Test I. That is, if the first execution of Test I yields a different IP address than the current host interface IP address and no response is received from the STUN server for Test II, the client repeats Test I sending the Binding Request to the IP address specified in the CHANGED-ADDRESS attribute from the first execution of Test I. My question is, what should the client assume if no response is received for the repeated execution of Test I? It seems to me that in theory, this situation should never occur. The reason is because the first execution of Test I returned a response and the second execution is doing the same thing, just with a different IP address and port number. However, I have encountered situations in practice where this does occur. My guess would be that you can certainly assume a NAT and use the MAPPED-ADDRESS that you get from the response to the first Test I. Would that be a good assumption? Also, what type of NAT would I then call that? Thoughts? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 22 04:46:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77wa-0004CM-J8; Mon, 22 Aug 2005 04:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77wY-0004C8-PS for sip@megatron.ietf.org; Mon, 22 Aug 2005 04:46:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01168 for ; Mon, 22 Aug 2005 04:46:05 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E78X1-0000mB-GS for sip@ietf.org; Mon, 22 Aug 2005 05:23:52 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1E77vx-0004GY-00; Mon, 22 Aug 2005 10:45:33 +0200 Message-ID: <430990B5.3070601@pernau.at> Date: Mon, 22 Aug 2005 10:45:41 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Sen Subject: Re: [Sip] Open source implementations for testing References: <8320074d05082012197447d6b8@mail.gmail.com> In-Reply-To: <8320074d05082012197447d6b8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Try http://www.pernau.at/kd/voip/bookmarks-sip-rtp-ua.html regards klaus Rohan Sen wrote: > Hi, > > Does anyone know of any open source (or freely available) SIP User > Agents which allow to configure (or better bypass) proxies and also > proxies for download. > > I need a couple of them for interoperability testing against a SIP > implementation that I am developing. > > Any help in this regard will be greatly appreciated. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 23 23:26:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7luN-0001pv-MO; Tue, 23 Aug 2005 23:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7luI-0001pk-PT for sip@megatron.ietf.org; Tue, 23 Aug 2005 23:26:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27180 for ; Tue, 23 Aug 2005 23:26:28 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler1.mail.eds.com ([192.85.154.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7luT-0007N0-K9 for sip@ietf.org; Tue, 23 Aug 2005 23:26:46 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7O3Q29d006380; Tue, 23 Aug 2005 23:26:02 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7O3PjSk009485; Tue, 23 Aug 2005 23:25:45 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7O3PjDW009480; Tue, 23 Aug 2005 23:25:45 -0400 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 23 Aug 2005 23:32:19 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 08/23/2005 08:25:53 PM, Serialize complete at 08/23/2005 08:25:53 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: SIP IETF Subject: [Sip] Reinvite query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1975644791==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1975644791== Content-Type: multipart/alternative; boundary="=_alternative 0012B83385257067_=" This is a multipart message in MIME format. --=_alternative 0012B83385257067_= Content-Type: text/plain; charset="US-ASCII" Hi, Suppose party A and B are talking, and B put A on hold. If there is no Music on hold, party A will not hear an media. If B sends Reinvite to party A (in hold state) with no sdp, what should be the behaviour of A? Will it make a new offer ? As it is asking A to make offer when he is in hold state. Thanks, Udit --=_alternative 0012B83385257067_= Content-Type: text/html; charset="US-ASCII"
Hi,

Suppose party A and B are talking, and B put A on hold. If there is no Music on hold, party A will not hear an media.
If B sends Reinvite to party A (in hold state) with no sdp, what should be the behaviour of A?

Will it make a new offer ? As it is asking A to make offer when he is in hold state.

Thanks,
Udit

--=_alternative 0012B83385257067_=-- --===============1975644791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1975644791==-- From sip-bounces@ietf.org Wed Aug 24 00:51:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nEk-0000ii-3K; Wed, 24 Aug 2005 00:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nEc-0000aD-1Z for sip@megatron.ietf.org; Wed, 24 Aug 2005 00:51:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29759 for ; Wed, 24 Aug 2005 00:51:31 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7nEq-0000xr-OG for sip@ietf.org; Wed, 24 Aug 2005 00:51:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2005 21:51:22 -0700 X-IronPort-AV: i="3.96,137,1122879600"; d="scan'208"; a="656387950:sNHT30202572" 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 j7O4osQe020309; Tue, 23 Aug 2005 21:51:16 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 21:51:15 -0700 Received: from cisco.com ([10.89.16.28]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 21:51:15 -0700 Message-ID: <430BFCC2.1060202@cisco.com> Date: Wed, 24 Aug 2005 00:51:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Udit_Goyal@3com.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2005 04:51:15.0196 (UTC) FILETIME=[753D0BC0:01C5A867] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: SIP IETF , SIP Implementors Subject: [Sip] Re: [Sip-implementors] Reinvite query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Udit_Goyal@3com.com wrote: > Hi, > > Suppose party A and B are talking, and B put A on hold. If there is no > Music on hold, party A will not hear an media. > If B sends Reinvite to party A (in hold state) with no sdp, what should be > the behaviour of A? > > Will it make a new offer ? As it is asking A to make offer when he is in > hold state. IMO A should make an offer consistent with what it (A) would like to do, without regard for any assumption it might have about what B wants to do. It was B that originally wanted to put the call on hold, and so it should also be B, not A, that decides if the reinvite should be on hold. So in particular in this case, A should make an offer containing a:sendrecv. If B still wants the call to be on hold it can answer a:sendonly. But if B no longer wants to be on hold it can get that effect by answering with a:sendrecv. Doing things this way is quite important in order to get 3pcc call flows to work properly. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 00:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nHc-0002Cs-SE; Wed, 24 Aug 2005 00:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nHZ-00029t-3w; Wed, 24 Aug 2005 00:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29946; Wed, 24 Aug 2005 00:54:34 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7nHn-00014E-23; Wed, 24 Aug 2005 00:54:53 -0400 Received: from dlfmail1.hss.hns.com (dlfmail1 [10.203.142.23]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j7O4mk3q008882; Wed, 24 Aug 2005 10:18:47 +0530 (IST) In-Reply-To: Subject: Re: [Sip] Reinvite query To: Udit_Goyal@3com.com X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Retesh Chadha Date: Wed, 24 Aug 2005 10:24:42 +0530 X-MIMETrack: Serialize by Router on Dlfmail1/HSS(Release 6.5|September 26, 2003) at 08/24/2005 10:24:45 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP IETF , SIP Implementors , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think here A will make a new offer, and the attribute mode in A's offer should be sendrecv, but sending recvonly is also not wrong. Rgds Retesh Udit_Goyal@3com.c om Sent by: To sip-bounces@ietf. "SIP Implementors" org cc SIP IETF 08/24/2005 09:02 Subject AM [Sip] Reinvite query Hi, Suppose party A and B are talking, and B put A on hold. If there is no Music on hold, party A will not hear an media. If B sends Reinvite to party A (in hold state) with no sdp, what should be the behaviour of A? Will it make a new offer ? As it is asking A to make offer when he is in hold state. Thanks, Udit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 01:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nzL-0007wC-Oo; Wed, 24 Aug 2005 01:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nzE-0007ph-V1; Wed, 24 Aug 2005 01:39:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02133; Wed, 24 Aug 2005 01:39:44 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7nzN-0002Or-6C; Wed, 24 Aug 2005 01:40:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILP004ARP7NMO@szxga03-in.huawei.com>; Wed, 24 Aug 2005 13:43:00 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILP001PPP7NZA@szxga03-in.huawei.com>; Wed, 24 Aug 2005 13:42:59 +0800 (CST) Received: from GUEST ([10.76.176.9]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILP00LKJPDGMI@szxml02-in.huawei.com>; Wed, 24 Aug 2005 13:46:29 +0800 (CST) Date: Wed, 24 Aug 2005 13:39:26 +0800 From: Peili Xu Subject: RE: [Sip] Reinvite query In-reply-to: To: "'Retesh Chadha'" , Udit_Goyal@3com.com Message-id: <013301c5a86e$305b83e0$09b04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7BIT Cc: 'SIP IETF' , sip-bounces@ietf.org, 'SIP Implementors' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Considering B may want to connect A to some other resources in this way (like 3PCC), and the new media connection may be bi-directional or uni-directional. It better for A to provide the full capability in 200 OK SDP(ie, a=sendrecv), and leave the flexibility of making final decision to B or some other service logic behind him. Peili -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Retesh Chadha Sent: Wednesday, August 24, 2005 12:55 PM To: Udit_Goyal@3com.com Cc: SIP IETF; SIP Implementors; sip-bounces@ietf.org Subject: Re: [Sip] Reinvite query I think here A will make a new offer, and the attribute mode in A's offer should be sendrecv, but sending recvonly is also not wrong. Rgds Retesh Udit_Goyal@3com.c om Sent by: To sip-bounces@ietf. "SIP Implementors" org cc SIP IETF 08/24/2005 09:02 Subject AM [Sip] Reinvite query Hi, Suppose party A and B are talking, and B put A on hold. If there is no Music on hold, party A will not hear an media. If B sends Reinvite to party A (in hold state) with no sdp, what should be the behaviour of A? Will it make a new offer ? As it is asking A to make offer when he is in hold state. Thanks, Udit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 02:40:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ow8-00075H-2u; Wed, 24 Aug 2005 02:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ow5-000751-Mu; Wed, 24 Aug 2005 02:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02167; Wed, 24 Aug 2005 02:40:32 -0400 (EDT) Received: from nwd2mail2.analog.com ([137.71.25.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7owJ-00044X-7Q; Wed, 24 Aug 2005 02:40:50 -0400 Received: from nwd2mhb1.analog.com (nwd2mhb1.analog.com [137.71.5.12]) by nwd2mail2.analog.com (8.12.10/8.12.10) with ESMTP id j7O6eQ0j000566; Wed, 24 Aug 2005 02:40:26 -0400 Received: from lilac.hdcindia.analog.com ([10.121.13.31]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id CAA01554; Wed, 24 Aug 2005 02:40:15 -0400 (EDT) Received: from RTELLAPAD01 ([10.121.13.209]) by lilac.hdcindia.analog.com (8.12.10+Sun/8.12.10) with SMTP id j7O6ZGUM012991; Wed, 24 Aug 2005 12:05:16 +0530 (IST) Message-ID: <003a01c5a876$ae367920$d10d790a@ad.analog.com> From: "T R Naidu" To: "SIP IETF" , References: Date: Wed, 24 Aug 2005 12:10:13 +0530 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.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Status: No, hits=-102.8 required=10.0 tests=ALL_TRUSTED,USER_IN_WHITELIST version=3.0.2 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 3.000002 (2004-11-16) X-Scanned-By: MIMEDefang 2.49 on 137.71.25.51 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] 3-way call conference --- call flow X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Could someone suggest me the 3-way call conference call flows of differenet IP Phones, from different Vendor, which are widely deployed in the market today.I tried a lot in the internet, but could not find any references.Any help would be highly appreciated. thanks in advance. regards, TR Naidu. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 04:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7quq-0002eF-TY; Wed, 24 Aug 2005 04:47:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7qup-0002eA-8p for sip@megatron.ietf.org; Wed, 24 Aug 2005 04:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07446 for ; Wed, 24 Aug 2005 04:47:21 -0400 (EDT) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7qv5-00086L-Qn for sip@ietf.org; Wed, 24 Aug 2005 04:47:41 -0400 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Wed, 24 Aug 2005 10:46:48 +0200 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: [Sip] Reinvite query Date: Wed, 24 Aug 2005 10:46:53 +0200 Message-ID: Thread-Topic: [Sip] Reinvite query Thread-Index: AcWobuv52vP3JIWbTAiq4jyLdXOQ9gAFexJg From: "Christian Jansson" To: "Peili Xu" , "Retesh Chadha" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >Hi, > Considering B may want to connect A to some other resources in this way >(like 3PCC), and the new media connection may be bi-directional or >uni-directional. > >It better for A to provide the full capability in 200 OK SDP(ie, >a=3Dsendrecv), and leave the flexibility of making final decision to B = or >some other service logic behind him. With "full capability" I suppose you mean that the SDP should contain all supported media types like audio, video, text, message, and application. All media types should be in sendrecv mode which would mean that a lot of listening resources had to be started.=20 Is this the correct interpretation of your statement? / Christian Jansson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 13:33:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z82-0002Rr-Dh; Wed, 24 Aug 2005 13:33:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z80-0002RL-6c for sip@megatron.ietf.org; Wed, 24 Aug 2005 13:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07065 for ; Wed, 24 Aug 2005 13:33:29 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7z8L-0000gx-6E for sip@ietf.org; Wed, 24 Aug 2005 13:33:54 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j7OHXHre011734; Wed, 24 Aug 2005 12:33:18 -0500 (CDT) Received: from beavis.ho.lucent.com (beavis.ho.lucent.com [135.112.125.152]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j7OHXGV1013479; Wed, 24 Aug 2005 12:33:16 -0500 (CDT) Received: from [135.112.125.177] (pinky.ho.lucent.com [135.112.125.177]) by beavis.ho.lucent.com (8.11.6+Sun/8.11.6) with ESMTP id j7OHXG506954; Wed, 24 Aug 2005 13:33:16 -0400 (EDT) Message-ID: <430CAF5B.90301@bell-labs.com> Date: Wed, 24 Aug 2005 13:33:15 -0400 From: Troy Cauble User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, "Christian Jansson" Subject: Re: [Sip] Reinvite query References: <200508241606.j7OG6Etm020023@hoemail1.lucent.com> In-Reply-To: <200508241606.j7OG6Etm020023@hoemail1.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: > "Christian Jansson" >>Hi, >> Considering B may want to connect A to some other resources in this > > way > >>(like 3PCC), and the new media connection may be bi-directional or >>uni-directional. >> >>It better for A to provide the full capability in 200 OK SDP(ie, >>a=sendrecv), and leave the flexibility of making final decision to B or >>some other service logic behind him. > > > With "full capability" I suppose you mean that the SDP should contain > all supported media types like audio, video, text, message, and > application. All media types should be in sendrecv mode which would mean > that a lot of listening resources had to be started. > > Is this the correct interpretation of your statement? > > / Christian Jansson > From RFC 3261, section 14: A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. But RFC 3264 puts some restrictions on how the the SDP can differ from the previous SDP provided, including: If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=" lines, the new SDP MUST have at least N "m=" lines. -troy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 24 16:05:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81VK-0004Z0-05; Wed, 24 Aug 2005 16:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81VH-0004Uh-AQ for sip@megatron.ietf.org; Wed, 24 Aug 2005 16:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17308 for ; Wed, 24 Aug 2005 16:05:41 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler4.mail.eds.com ([199.228.142.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81VZ-00066S-Gq for sip@ietf.org; Wed, 24 Aug 2005 16:06:07 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7OK5Bqn023175; Wed, 24 Aug 2005 15:05:13 -0500 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7OK4dAS002875; Wed, 24 Aug 2005 15:04:39 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7OK4dwN002865; Wed, 24 Aug 2005 15:04:39 -0500 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 24 Aug 2005 16:11:12 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 08/24/2005 01:04:41 PM, Serialize complete at 08/24/2005 01:04:41 PM X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIP IETF Subject: [Sip] SDP Query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1178607813==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1178607813== Content-Type: multipart/alternative; boundary="=_alternative 006E2B7E85257067_=" This is a multipart message in MIME format. --=_alternative 006E2B7E85257067_= Content-Type: text/plain; charset="US-ASCII" Hi, Just want to check if following SDP is valid: c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 c=IN IP4 224.2.17.13/127 m=video 51372 RTP/AVP 31 It indicates different IP address used for audio and video types. I thought the reason we have connection parameter in both session and media description is for handling hold cases, where you want to hold a particular set of media instead of whole session. Regards, Udit --=_alternative 006E2B7E85257067_= Content-Type: text/html; charset="US-ASCII"
Hi,

Just want to check if following SDP is valid:

        c=IN IP4 224.2.17.12/127
        t=2873397496 2873404696
        a=recvonly
        m=audio 49170 RTP/AVP 0
        c=IN IP4 224.2.17.13/127
        m=video 51372 RTP/AVP 31

It indicates different IP address used for audio and video types.

I thought the reason we have connection parameter in both session and media description is for handling hold cases, where you want to hold a particular set of media instead of whole session.

Regards,
Udit
--=_alternative 006E2B7E85257067_=-- --===============1178607813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1178607813==-- From sip-bounces@ietf.org Wed Aug 24 18:09:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83Qq-0006Tb-Sv; Wed, 24 Aug 2005 18:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83Qp-0006TA-AX for sip@megatron.ietf.org; Wed, 24 Aug 2005 18:09:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24671 for ; Wed, 24 Aug 2005 18:09:12 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83RB-0001pK-VJ for sip@ietf.org; Wed, 24 Aug 2005 18:09:40 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id D5B76206F0 for ; Thu, 25 Aug 2005 03:28:02 +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 BAE202064E for ; Thu, 25 Aug 2005 03:28:02 +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.211); Thu, 25 Aug 2005 03:38:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] SDP Query Date: Thu, 25 Aug 2005 03:38:42 +0530 Message-ID: Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53rWEgKnpNQZRm2rZsL9vhn1bwAEOjHG To: , X-OriginalArrivalTime: 24 Aug 2005 22:08:57.0304 (UTC) FILETIME=[6C58C580:01C5A8F8] X-Spam-Score: 0.9 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520823618==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1520823618== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A8F8.6C16D209" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A8F8.6C16D209 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Udit, =20 There Must be one "C" field at the session level (or) one "C" field in = each media description level.=20 "C" value at the session level is like global value.and Media level is = like local. so if you do not have it in Media level it will take the value at = Session level. =20 so to your question: Yes it is valid. It is indicating different Ip addresses for different Media types. =20 If you want a particular media stream to be in holding give that IP = address for that particular Media stream "c" (to 0.0.0.0 or = a=3Dinactive) =20 HTH, =20 Regards, Sreeram. ________________________________ From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com Sent: Wed 8/24/2005 4:11 PM To: SIP Implementors Cc: SIP IETF Subject: [Sip] SDP Query Hi,=20 Just want to check if following SDP is valid:=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 It indicates different IP address used for audio and video types.=20 I thought the reason we have connection parameter in both session and = media description is for handling hold cases, where you want to hold a = particular set of media instead of whole session.=20 Regards,=20 Udit=20 ------_=_NextPart_001_01C5A8F8.6C16D209 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
Hi = Udit,
=0A=
 
=0A=
There Must be = one "C" field =0A= at the session level (or) one "C" field in each media description level. =0A=
=0A=
"C" value at = the session =0A= level is like global value.and  Media level is like local.
so if = you do =0A= not have it in Media level it will take the value at Session =0A= level.
=0A=
 
=0A=
so  to = your =0A= question:
=0A=
Yes it is = valid.
It is =0A= indicating different Ip addresses for different Media types.
=0A=
 
=0A=
If you want a = particular =0A= media stream to be in holding give that IP address for that particular = Media =0A= stream  "c"  (to 0.0.0.0 or a=3Dinactive)
=0A=
 
=0A=
HTH,
=0A=
 
=0A=
Regards,
=0A=
Sreeram.
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on behalf = of =0A= Udit_Goyal@3com.com
Sent: Wed 8/24/2005 4:11 PM
To: = SIP =0A= Implementors
Cc: SIP IETF
Subject: [Sip] SDP =0A= Query

=0A=

Hi,

Just want to check if following SDP is = valid: =0A=

        = c=3DIN IP4 =0A= 224.2.17.12/127
  =     =0A=   t=3D2873397496 2873404696
  =0A=       a=3Drecvonly
        m=3Daudio 49170 RTP/AVP 0 =
        c=3DIN IP4 =0A= 224.2.17.13/127
  =     =0A=   m=3Dvideo 51372 RTP/AVP 31

It =0A= indicates different IP address used for audio and video types. =0A=

I thought the reason we = have =0A= connection parameter in both session and media description is for = handling hold =0A= cases, where you want to hold a particular set of media instead of whole =0A= session.

Regards, =
Udit
=0A= ------_=_NextPart_001_01C5A8F8.6C16D209-- --===============1520823618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1520823618==-- From sip-bounces@ietf.org Thu Aug 25 02:17:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8B3l-0006ap-GR; Thu, 25 Aug 2005 02:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8B3k-0006Xh-4b; Thu, 25 Aug 2005 02:17:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00923; Thu, 25 Aug 2005 02:17:51 -0400 (EDT) Received: from [209.163.159.13] (helo=lsmail.austin.kmvtechnologies.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8B48-0007ft-M9; Thu, 25 Aug 2005 02:18:21 -0400 Date: Thu, 25 Aug 2005 01:20:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <717562D70E24CF489737F81B0EA234DF8BA203@lsmail.austin.kmvtechnologies.com> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Sip Video conference Thread-Index: AcWod4lmbAsk6SZxSFKSEjouFhHFCwAxR5Qw From: "Ashish Goyal" To: "SIP IETF" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Sip] Sip Video conference X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is there a defacto standard that vendors in Sip Videoconferencing are adhering to for=20 - Flow control - Far End Camera Control - Dual Video Ashish _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 05:02:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Dcn-000632-Bc; Thu, 25 Aug 2005 05:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Dcg-00062u-2N for sip@megatron.ietf.org; Thu, 25 Aug 2005 05:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07992 for ; Thu, 25 Aug 2005 05:02:05 -0400 (EDT) Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Dd5-00046g-HC for sip@ietf.org; Thu, 25 Aug 2005 05:02:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] SDP Query Date: Thu, 25 Aug 2005 10:01:38 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23688@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53h22ZOWaQ6aRCabES3a4Ab4IAAa12Ww From: "Attila Sipos" To: , "SIP Implementors" X-Spam-Score: 0.3 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500706085==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1500706085== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A953.9A256990" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A953.9A256990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Udit,=20 =20 Yes it is valid. The question is what did you intend it to mean? =20 In your example, you will end up with audio with IP 224.2.17.13 and video with IP 224.2.17.12. =20 The first "c=3D" (is a session description "c=3D" since it comes before = any "m=3D" section) means use this IP address for all media unless the media description says otherwise. =20 The second "c=3D" (is a media description "c=3D" because it comes after = the "m=3D") means for this particular media use the address I've specified here. =20 You could have, as an alternative, written your SDP like this: =20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 c=3DIN IP4 224.2.17.12/127=20 In my example above, there is no session description "c=3D" so every media description has to have a "c=3D". =20 Regards, =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: 24 August 2005 21:11 To: SIP Implementors Cc: SIP IETF Subject: [Sip] SDP Query Hi,=20 Just want to check if following SDP is valid:=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 It indicates different IP address used for audio and video types.=20 I thought the reason we have connection parameter in both session and = media description is for handling hold cases, where you want to hold a = particular set of media instead of whole session.=20 Regards,=20 Udit=20 ------_=_NextPart_001_01C5A953.9A256990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Udit,
 
Yes it=20 is valid.  The question is what did you intend it to=20 mean?
 
In=20 your example, you will end up with audio with IP = 224.2.17.13
and=20 video with IP 224.2.17.12.
 
The first = "c=3D" (is a=20 session description "c=3D" since it = comes before=20 any
"m=3D" = section)=20 means use this IP address for=20 all media unless=20 the
media=20 description says otherwise.
 
The=20 second "c=3D" (is a media description "c=3D" because it comes after the=20 "m=3D")
means=20 for this particular media use the address I've specified=20 here.
 
You=20 could have, as an alternative, written your SDP like = this:
 
        t=3D2873397496 = 2873404696=20
       =20 a=3Drecvonly
  =    =20   m=3Daudio 49170 RTP/AVP 0
 =20       c=3DIN IP4 224.2.17.13/127
        m=3Dvideo = 51372 RTP/AVP=20 31 
        c=3DIN IP4=20 224.2.17.12/127
In my=20 example above, there is no session description "c=3D" so = every
media=20 description has to have a "c=3D".
 
Regards,
 
Attila=20 Sipos
http://www.vegastream.com
 
 
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of=20 Udit_Goyal@3com.com
Sent: 24 August 2005 = 21:11
To: SIP=20 Implementors
Cc: SIP IETF
Subject: [Sip] SDP=20 Query


Hi,=20

Just want to check if = following SDP is=20 valid:

  =    =20   c=3DIN IP4 224.2.17.12/127
        t=3D2873397496 2873404696 =
        = a=3Drecvonly=20
        = m=3Daudio 49170=20 RTP/AVP 0
    =  =20   c=3DIN IP4 224.2.17.13/127
        m=3Dvideo 51372 RTP/AVP 31 =

It indicates different IP = address used=20 for audio and video types.

I=20 thought the reason we have connection parameter in both session and = media=20 description is for handling hold cases, where you want to hold a = particular=20 set of media instead of whole session.

Regards,
Udit=20
------_=_NextPart_001_01C5A953.9A256990-- --===============1500706085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1500706085==-- From sip-bounces@ietf.org Thu Aug 25 05:11:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8DlY-0008Nz-PM; Thu, 25 Aug 2005 05:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8DlW-0008L2-3X for sip@megatron.ietf.org; Thu, 25 Aug 2005 05:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08444 for ; Thu, 25 Aug 2005 05:11:15 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Dlz-0004Pl-GV for sip@ietf.org; Thu, 25 Aug 2005 05:11:48 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [Sip] SDP Query Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 05:24:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Dxx-0004Dq-E8; Thu, 25 Aug 2005 05:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Dxu-0004Di-Vb for sip@megatron.ietf.org; Thu, 25 Aug 2005 05:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08977 for ; Thu, 25 Aug 2005 05:24:04 -0400 (EDT) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8DyN-0004mj-Db for sip@ietf.org; Thu, 25 Aug 2005 05:24:38 -0400 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Thu, 25 Aug 2005 11:23:32 +0200 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: [Sip] SDP Query Date: Thu, 25 Aug 2005 11:23:35 +0200 Message-ID: Thread-Topic: [Sip] SDP Query Thread-Index: AcWpVSsOicaa6eTzS1W/sbYAocbXdwAALBCQ From: "Fevzi Konduk" To: "Colin Perkins" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello,=20 As Collin Pointed out the SDP is not valid.=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31 Look in rfc3264 for some examples and look also bellow.=20 Quote from RFC 2327:=20 Some lines in each description are required and some are optional but ALL MUST APPEAR IN EXACTLY THE ORDER GIVEN HERE (the fixed order greatly enhances error detection and allows for a simple parser). Optional items are marked with a `*'. Session description v=3D (protocol version) o=3D (owner/creator and session identifier). s=3D (session name) i=3D* (session information) Handley & Jacobson Standards Track [Page 7] RFC 2327 SDP April 1998 u=3D* (URI of description) e=3D* (email address) p=3D* (phone number) c=3D* (connection information - not required if included in all media) b=3D* (bandwidth information) One or more time descriptions (see below) z=3D* (time zone adjustments) k=3D* (encryption key) a=3D* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t=3D (time the session is active) r=3D* (zero or more repeat times) Media description m=3D (media name and transport address) i=3D* (media title) c=3D* (connection information - optional if included at session-level) b=3D* (bandwidth information) k=3D* (encryption key) a=3D* (zero or more media attribute lines) > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 25 augusti 2005 11:11 > To: sreeram.kanumuri@wipro.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip] SDP Query >=20 > This is not valid, since it's missing "v=3D", "o=3D", and "s=3D" = lines, all > of which are mandatory in SDP. >=20 > Colin >=20 >=20 > On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > > Hi Udit, > > > > There Must be one "C" field at the session level (or) one "C" field > > in each media description level. > > "C" value at the session level is like global value.and Media > > level is like local. > > so if you do not have it in Media level it will take the value at > > Session level. > > > > so to your question: > > Yes it is valid. > > It is indicating different Ip addresses for different Media types. > > > > If you want a particular media stream to be in holding give that IP > > address for that particular Media stream "c" (to 0.0.0.0 or > > a=3Dinactive) > > > > HTH, > > > > Regards, > > Sreeram. > > > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > > Sent: Wed 8/24/2005 4:11 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip] SDP Query > > > > > > Hi, > > > > Just want to check if following SDP is valid: > > > > c=3DIN IP4 224.2.17.12/127 > > t=3D2873397496 2873404696 > > a=3Drecvonly > > m=3Daudio 49170 RTP/AVP 0 > > c=3DIN IP4 224.2.17.13/127 > > m=3Dvideo 51372 RTP/AVP 31 > > > > It indicates different IP address used for audio and video types. > > > > I thought the reason we have connection parameter in both session > > and media description is for handling hold cases, where you want to > > hold a particular set of media instead of whole session. > > > > Regards, > > Udit > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 16:08:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8O17-0007PG-Va; Thu, 25 Aug 2005 16:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8O15-0007Mj-7X for sip@megatron.ietf.org; Thu, 25 Aug 2005 16:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15603 for ; Thu, 25 Aug 2005 16:08:01 -0400 (EDT) Received: from web52804.mail.yahoo.com ([206.190.48.247]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8O1Z-0000Ss-DS for sip@ietf.org; Thu, 25 Aug 2005 16:08:39 -0400 Received: (qmail 93686 invoked by uid 60001); 25 Aug 2005 20:07:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C72FQ4cwurcvyUkSZ8u8L0XWOZNdXNUeiykf5SXszjptTri/gz9hMN2ZqrGQvyseazlCTE2jI4SNHVAU4o7IuMJy1ULnPM2xdfrExPRNCB4uQhRUn9TrgKn68iAJC/ziHkpiNXYh4bouH7uuPvM8pHVDaSR/rqzznwdAcxBNS2M= ; Message-ID: <20050825200747.93684.qmail@web52804.mail.yahoo.com> Received: from [81.214.132.234] by web52804.mail.yahoo.com via HTTP; Thu, 25 Aug 2005 13:07:47 PDT Date: Thu, 25 Aug 2005 13:07:47 -0700 (PDT) From: Fatih "Eyüp" NAR Subject: RE: [Sip] SDP Query To: Fevzi Konduk , Colin Perkins , sreeram.kanumuri@wipro.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 8bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org i am not on a side to break rules but... in my opinion (as a developer) saying this sdp is not valid in sip messaging and failing the transaction do not make sense since the sip application who is receving this sdp simply has ; IP# , port# , codec info for audio receive. besides saying this {...} is like a ITU approach :-) , if you have enough info to proceed go ahead if not fail the transaction with proper response code. --- Fevzi Konduk wrote: > Hello, > As Collin Pointed out the SDP is not valid. > > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > > Look in rfc3264 for some examples and look also > bellow. > > Quote from RFC 2327: > > Some lines in each description are required and some > are optional but ALL MUST APPEAR IN EXACTLY THE > ORDER GIVEN HERE (the > fixed order greatly enhances error detection and > allows for a simple > parser). Optional items are marked with a `*'. > > Session description > v= (protocol version) > o= (owner/creator and session identifier). > s= (session name) > i=* (session information) > > > > Handley & Jacobson Standards Track > [Page 7] > > > RFC 2327 SDP > April 1998 > > > u=* (URI of description) > e=* (email address) > p=* (phone number) > c=* (connection information - not required > if included in all > media) > b=* (bandwidth information) > One or more time descriptions (see below) > z=* (time zone adjustments) > k=* (encryption key) > a=* (zero or more session attribute lines) > Zero or more media descriptions (see below) > > Time description > t= (time the session is active) > r=* (zero or more repeat times) > > Media description > m= (media name and transport address) > i=* (media title) > c=* (connection information - optional if > included at > session-level) > b=* (bandwidth information) > k=* (encryption key) > a=* (zero or more media attribute lines) > > > > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: den 25 augusti 2005 11:11 > > To: sreeram.kanumuri@wipro.com > > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > > Subject: Re: [Sip] SDP Query > > > > This is not valid, since it's missing "v=", "o=", > and "s=" lines, all > > of which are mandatory in SDP. > > > > Colin > > > > > > On 24 Aug 2005, at 23:08, > sreeram.kanumuri@wipro.com wrote: > > > Hi Udit, > > > > > > There Must be one "C" field at the session level > (or) one "C" field > > > in each media description level. > > > "C" value at the session level is like global > value.and Media > > > level is like local. > > > so if you do not have it in Media level it will > take the value at > > > Session level. > > > > > > so to your question: > > > Yes it is valid. > > > It is indicating different Ip addresses for > different Media types. > > > > > > If you want a particular media stream to be in > holding give that IP > > > address for that particular Media stream "c" > (to 0.0.0.0 or > > > a=inactive) > > > > > > HTH, > > > > > > Regards, > > > Sreeram. > > > > > > From: sip-bounces@ietf.org on behalf of > Udit_Goyal@3com.com > > > Sent: Wed 8/24/2005 4:11 PM > > > To: SIP Implementors > > > Cc: SIP IETF > > > Subject: [Sip] SDP Query > > > > > > > > > Hi, > > > > > > Just want to check if following SDP is valid: > > > > > > c=IN IP4 224.2.17.12/127 > > > t=2873397496 2873404696 > > > a=recvonly > > > m=audio 49170 RTP/AVP 0 > > > c=IN IP4 224.2.17.13/127 > > > m=video 51372 RTP/AVP 31 > > > > > > It indicates different IP address used for audio > and video types. > > > > > > I thought the reason we have connection > parameter in both session > > > and media description is for handling hold > cases, where you want to > > > hold a particular set of media instead of whole > session. > > > > > > Regards, > > > Udit > > > _______________________________________________ > > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > Protocol > > > Use sip-implementors@cs.columbia.edu for > questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 16:20:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OCe-0004jx-Kx; Thu, 25 Aug 2005 16:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OCc-0004jA-Nl for sip@megatron.ietf.org; Thu, 25 Aug 2005 16:19:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16452 for ; Thu, 25 Aug 2005 16:19:56 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ODC-0000wa-BA for sip@ietf.org; Thu, 25 Aug 2005 16:20:35 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63388 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8OCQ-0007iE-H0; Thu, 25 Aug 2005 21:19:46 +0100 In-Reply-To: <20050825200747.93684.qmail@web52804.mail.yahoo.com> References: <20050825200747.93684.qmail@web52804.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [Sip] SDP Query Date: Thu, 25 Aug 2005 21:19:41 +0100 To: =?ISO-8859-1?Q?Fatih_Ey=FCp_NAR?= X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Fevzi Konduk , sip-implementors@cs.columbia.edu, sreeram.kanumuri@wipro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 25 Aug 2005, at 21:07, Fatih Ey=FCp NAR wrote: > i am not on a side to break rules but... > > in my opinion (as a developer) saying this sdp is not > valid in sip messaging and failing the transaction do > not make sense since the sip application who is > receving this sdp simply has ; IP# , port# , codec > info for audio receive. > > besides saying this {...} is like a ITU approach :-) , > if you have enough info to proceed go ahead if not > fail the transaction with proper response code. You're free to ignore the SDP specification if you like, there are no =20= protocol police to stop you... However, interoperability is usually =20 improved by trying to conform to the specifications, and the example =20 in question did not conform to the SDP grammar. Colin= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 19:23:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8R46-0000HV-Iz; Thu, 25 Aug 2005 19:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8R42-0000GG-1L for sip@megatron.ietf.org; Thu, 25 Aug 2005 19:23:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27104 for ; Thu, 25 Aug 2005 19:23:14 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8R4d-00060g-6c for sip@ietf.org; Thu, 25 Aug 2005 19:23:56 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 829E220627 for ; Fri, 26 Aug 2005 04:42:10 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 4E5B82061B for ; Fri, 26 Aug 2005 04:42:10 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 04:53:06 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 04:53:02 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:54:44 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 468E02D4002 for ; Thu, 25 Aug 2005 19:53:45 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id E25A740C005 for ; Thu, 25 Aug 2005 19:53:44 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hwv-0007IQ-01; Thu, 25 Aug 2005 09:39:21 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 14:24:45.0000 (UTC) FILETIME=[BD7E3480:01C5A980] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 19:43:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RNZ-0006vS-D6; Thu, 25 Aug 2005 19:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RNX-0006uz-UX for sip@megatron.ietf.org; Thu, 25 Aug 2005 19:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28192 for ; Thu, 25 Aug 2005 19:43:24 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8RO9-0006du-7r for sip@ietf.org; Thu, 25 Aug 2005 19:44:06 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 51CD220626 for ; Fri, 26 Aug 2005 05:02:20 +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 1E8B320622 for ; Fri, 26 Aug 2005 05:02:20 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:13:16 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:12:50 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:20:36 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A59242A8012; Thu, 25 Aug 2005 19:20:34 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id D87B93F401C; Thu, 25 Aug 2005 19:20:33 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hwu-0007IQ-00; Thu, 25 Aug 2005 09:39:20 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 13:50:36.0292 (UTC) FILETIME=[F85E2C40:01C5A97B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 19:43:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RNq-0006wc-W9; Thu, 25 Aug 2005 19:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RNp-0006wX-9w for sip@megatron.ietf.org; Thu, 25 Aug 2005 19:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28208 for ; Thu, 25 Aug 2005 19:43:42 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ROQ-0006fI-US for sip@ietf.org; Thu, 25 Aug 2005 19:44:23 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 303E020624 for ; Fri, 26 Aug 2005 05:02:38 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 0D21320622 for ; Fri, 26 Aug 2005 05:02:38 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:13:33 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:13:26 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:53:56 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2697C2D4002; Thu, 25 Aug 2005 19:52:57 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id C1C7540C004; Thu, 25 Aug 2005 19:52:56 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hww-0007IQ-00; Thu, 25 Aug 2005 09:39:22 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 14:23:56.0890 (UTC) FILETIME=[A0D133A0:01C5A980] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:01:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfI-0001YT-3m; Thu, 25 Aug 2005 20:01:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfG-0001YO-9Z for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:01:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29921 for ; Thu, 25 Aug 2005 20:01:45 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Rfs-0007Ww-2Y for sip@ietf.org; Thu, 25 Aug 2005 20:02:25 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id EF5DD20634 for ; Fri, 26 Aug 2005 05:20:37 +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 65B882062F for ; Fri, 26 Aug 2005 05:20:37 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:31:33 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:31:04 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 15:29:44 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E38082D4005 for ; Thu, 25 Aug 2005 15:29:43 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id 8D40B40C004 for ; Thu, 25 Aug 2005 15:29:43 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Dch-00070l-02; Thu, 25 Aug 2005 05:02:11 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91pTi026950 for ; Thu, 25 Aug 2005 05:01:54 -0400 (EDT) Received: from vegastream.com (firewall.vegastream.com [217.205.209.100] (may be forged)) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91hsv021641 for ; Thu, 25 Aug 2005 05:01:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Aug 2005 10:01:38 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23688@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53h22ZOWaQ6aRCabES3a4Ab4IAAa12Ww From: "Attila Sipos" To: , "SIP Implementors" X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-crf-test: 0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [Sip-implementors] RE: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 09:59:44.0709 (UTC) FILETIME=[B82E5750:01C5A95B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Udit,=20 =20 Yes it is valid. The question is what did you intend it to mean? =20 In your example, you will end up with audio with IP 224.2.17.13 and video with IP 224.2.17.12. =20 The first "c=3D" (is a session description "c=3D" since it comes before = any "m=3D" section) means use this IP address for all media unless the media description says otherwise. =20 The second "c=3D" (is a media description "c=3D" because it comes after = the "m=3D") means for this particular media use the address I've specified here. =20 You could have, as an alternative, written your SDP like this: =20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 c=3DIN IP4 224.2.17.12/127=20 In my example above, there is no session description "c=3D" so every media description has to have a "c=3D". =20 Regards, =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: 24 August 2005 21:11 To: SIP Implementors Cc: SIP IETF Subject: [Sip] SDP Query Hi,=20 Just want to check if following SDP is valid:=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 It indicates different IP address used for audio and video types.=20 I thought the reason we have connection parameter in both session and = media description is for handling hold cases, where you want to hold a = particular set of media instead of whole session.=20 Regards,=20 Udit=20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:01:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfK-0001Z1-9p; Thu, 25 Aug 2005 20:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfI-0001Yr-DA for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:01:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29924 for ; Thu, 25 Aug 2005 20:01:47 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Rfu-0007Wy-86 for sip@ietf.org; Thu, 25 Aug 2005 20:02:27 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 0166020638 for ; Fri, 26 Aug 2005 05:20:41 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id B9CD920631 for ; Fri, 26 Aug 2005 05:20:40 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:31:35 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:31:22 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 15:22:40 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1DF5E2A800C for ; Thu, 25 Aug 2005 15:22:39 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 2A0A03F4540 for ; Thu, 25 Aug 2005 15:11:58 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Dci-00070l-03; Thu, 25 Aug 2005 05:02:12 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91pTi026950 for ; Thu, 25 Aug 2005 05:01:54 -0400 (EDT) Received: from vegastream.com (firewall.vegastream.com [217.205.209.100] (may be forged)) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91hsv021641 for ; Thu, 25 Aug 2005 05:01:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Aug 2005 10:01:38 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23688@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53h22ZOWaQ6aRCabES3a4Ab4IAAa12Ww From: "Attila Sipos" To: , "SIP Implementors" X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-crf-test: 0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [Sip-implementors] RE: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 09:52:40.0519 (UTC) FILETIME=[BB581570:01C5A95A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Udit,=20 =20 Yes it is valid. The question is what did you intend it to mean? =20 In your example, you will end up with audio with IP 224.2.17.13 and video with IP 224.2.17.12. =20 The first "c=3D" (is a session description "c=3D" since it comes before = any "m=3D" section) means use this IP address for all media unless the media description says otherwise. =20 The second "c=3D" (is a media description "c=3D" because it comes after = the "m=3D") means for this particular media use the address I've specified here. =20 You could have, as an alternative, written your SDP like this: =20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 c=3DIN IP4 224.2.17.12/127=20 In my example above, there is no session description "c=3D" so every media description has to have a "c=3D". =20 Regards, =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: 24 August 2005 21:11 To: SIP Implementors Cc: SIP IETF Subject: [Sip] SDP Query Hi,=20 Just want to check if following SDP is valid:=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 It indicates different IP address used for audio and video types.=20 I thought the reason we have connection parameter in both session and = media description is for handling hold cases, where you want to hold a = particular set of media instead of whole session.=20 Regards,=20 Udit=20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfS-0001cT-Ej; Thu, 25 Aug 2005 20:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RfR-0001c1-D6 for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:01:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29939 for ; Thu, 25 Aug 2005 20:01:56 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Rg3-0007XD-6S for sip@ietf.org; Thu, 25 Aug 2005 20:02:36 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 3203020626 for ; Fri, 26 Aug 2005 05:20:50 +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 155F120623 for ; Fri, 26 Aug 2005 05:20:50 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:31:46 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:31:40 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:11:49 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ADCF72A8015 for ; Thu, 25 Aug 2005 19:11:46 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 930B63F4042 for ; Thu, 25 Aug 2005 19:11:30 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hwv-0007IQ-00; Thu, 25 Aug 2005 09:39:21 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 13:41:49.0345 (UTC) FILETIME=[BE487110:01C5A97A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RiF-0002gf-3q; Thu, 25 Aug 2005 20:04:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RiD-0002gP-3I for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00507 for ; Thu, 25 Aug 2005 20:04:47 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Rim-0007lw-Pg for sip@ietf.org; Thu, 25 Aug 2005 20:05:27 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B847220627 for ; Fri, 26 Aug 2005 05:23:39 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9DD6F20623 for ; Fri, 26 Aug 2005 05:23:39 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:34:35 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:34:22 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:11:23 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BB4A62A800B; Thu, 25 Aug 2005 19:11:20 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 6B2DD3F403D; Thu, 25 Aug 2005 19:10:56 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hwu-0007IQ-01; Thu, 25 Aug 2005 09:39:20 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 13:41:23.0252 (UTC) FILETIME=[AEBAF740:01C5A97A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:36:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SD5-0002mh-4G; Thu, 25 Aug 2005 20:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SCz-0002mc-Nw for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:36:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03559 for ; Thu, 25 Aug 2005 20:36:36 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8SDb-0000nj-L6 for sip@ietf.org; Thu, 25 Aug 2005 20:37:16 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F3972062B for ; Fri, 26 Aug 2005 05:55:29 +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 2362820616 for ; Fri, 26 Aug 2005 05:55:29 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 06:06:25 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 06:06:12 +0530 Received: from wip-cdctls-mx13.wipro.com ([203.91.201.17]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 14:59:51 +0530 Received: from wip-cdctls-mx2.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C53F2D4008 for ; Thu, 25 Aug 2005 14:59:49 +0530 (IST) Received: from mail2.hotsip.com (mail1.hotsip.com [62.119.82.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by wip-cdctls-mx2.wipro.com (Postfix) with ESMTP id D743940C018 for ; Thu, 25 Aug 2005 14:59:46 +0530 (IST) Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Thu, 25 Aug 2005 11:23:31 +0200 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: [Sip] SDP Query Date: Thu, 25 Aug 2005 11:23:35 +0200 Message-ID: Thread-Topic: [Sip] SDP Query Thread-Index: AcWpVSsOicaa6eTzS1W/sbYAocbXdwAALBCQ From: "Fevzi Konduk" To: "Colin Perkins" , X-OriginalArrivalTime: 25 Aug 2005 09:29:51.0438 (UTC) FILETIME=[8B4EE6E0:01C5A957] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello,=20 As Collin Pointed out the SDP is not valid.=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31 Look in rfc3264 for some examples and look also bellow.=20 Quote from RFC 2327:=20 Some lines in each description are required and some are optional but ALL MUST APPEAR IN EXACTLY THE ORDER GIVEN HERE (the fixed order greatly enhances error detection and allows for a simple parser). Optional items are marked with a `*'. Session description v=3D (protocol version) o=3D (owner/creator and session identifier). s=3D (session name) i=3D* (session information) Handley & Jacobson Standards Track [Page 7] RFC 2327 SDP April 1998 u=3D* (URI of description) e=3D* (email address) p=3D* (phone number) c=3D* (connection information - not required if included in all media) b=3D* (bandwidth information) One or more time descriptions (see below) z=3D* (time zone adjustments) k=3D* (encryption key) a=3D* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t=3D (time the session is active) r=3D* (zero or more repeat times) Media description m=3D (media name and transport address) i=3D* (media title) c=3D* (connection information - optional if included at session-level) b=3D* (bandwidth information) k=3D* (encryption key) a=3D* (zero or more media attribute lines) > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 25 augusti 2005 11:11 > To: sreeram.kanumuri@wipro.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip] SDP Query >=20 > This is not valid, since it's missing "v=3D", "o=3D", and "s=3D" = lines, all > of which are mandatory in SDP. >=20 > Colin >=20 >=20 > On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > > Hi Udit, > > > > There Must be one "C" field at the session level (or) one "C" field > > in each media description level. > > "C" value at the session level is like global value.and Media > > level is like local. > > so if you do not have it in Media level it will take the value at > > Session level. > > > > so to your question: > > Yes it is valid. > > It is indicating different Ip addresses for different Media types. > > > > If you want a particular media stream to be in holding give that IP > > address for that particular Media stream "c" (to 0.0.0.0 or > > a=3Dinactive) > > > > HTH, > > > > Regards, > > Sreeram. > > > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > > Sent: Wed 8/24/2005 4:11 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip] SDP Query > > > > > > Hi, > > > > Just want to check if following SDP is valid: > > > > c=3DIN IP4 224.2.17.12/127 > > t=3D2873397496 2873404696 > > a=3Drecvonly > > m=3Daudio 49170 RTP/AVP 0 > > c=3DIN IP4 224.2.17.13/127 > > m=3Dvideo 51372 RTP/AVP 31 > > > > It indicates different IP address used for audio and video types. > > > > I thought the reason we have connection parameter in both session > > and media description is for handling hold cases, where you want to > > hold a particular set of media instead of whole session. > > > > Regards, > > Udit > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:37:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SDR-0002pP-V8; Thu, 25 Aug 2005 20:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SDP-0002pK-6y for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:37:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03568 for ; Thu, 25 Aug 2005 20:37:01 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8SDz-0000oL-1c for sip@ietf.org; Thu, 25 Aug 2005 20:37:42 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B5C9620620 for ; Fri, 26 Aug 2005 05:55:53 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9CFBE20616 for ; Fri, 26 Aug 2005 05:55:53 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 06:06:49 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 06:06:46 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 14:45:41 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B83442A8004 for ; Thu, 25 Aug 2005 14:45:39 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 068F33F404C for ; Thu, 25 Aug 2005 14:35:30 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Dcg-00070l-02; Thu, 25 Aug 2005 05:02:10 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91pTi026950 for ; Thu, 25 Aug 2005 05:01:54 -0400 (EDT) Received: from vegastream.com (firewall.vegastream.com [217.205.209.100] (may be forged)) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P91hsv021641 for ; Thu, 25 Aug 2005 05:01:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Aug 2005 10:01:38 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23688@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53h22ZOWaQ6aRCabES3a4Ab4IAAa12Ww From: "Attila Sipos" To: , "SIP Implementors" X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-crf-test: 0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [Sip-implementors] RE: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 09:15:41.0321 (UTC) FILETIME=[90995790:01C5A955] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Udit,=20 =20 Yes it is valid. The question is what did you intend it to mean? =20 In your example, you will end up with audio with IP 224.2.17.13 and video with IP 224.2.17.12. =20 The first "c=3D" (is a session description "c=3D" since it comes before = any "m=3D" section) means use this IP address for all media unless the media description says otherwise. =20 The second "c=3D" (is a media description "c=3D" because it comes after = the "m=3D") means for this particular media use the address I've specified here. =20 You could have, as an alternative, written your SDP like this: =20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 c=3DIN IP4 224.2.17.12/127=20 In my example above, there is no session description "c=3D" so every media description has to have a "c=3D". =20 Regards, =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: 24 August 2005 21:11 To: SIP Implementors Cc: SIP IETF Subject: [Sip] SDP Query Hi,=20 Just want to check if following SDP is valid:=20 c=3DIN IP4 224.2.17.12/127=20 t=3D2873397496 2873404696=20 a=3Drecvonly=20 m=3Daudio 49170 RTP/AVP 0=20 c=3DIN IP4 224.2.17.13/127=20 m=3Dvideo 51372 RTP/AVP 31=20 It indicates different IP address used for audio and video types.=20 I thought the reason we have connection parameter in both session and = media description is for handling hold cases, where you want to hold a = particular set of media instead of whole session.=20 Regards,=20 Udit=20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 20:40:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SGx-0003qF-ET; Thu, 25 Aug 2005 20:40:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8SGv-0003q9-9i for sip@megatron.ietf.org; Thu, 25 Aug 2005 20:40:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03999 for ; Thu, 25 Aug 2005 20:40:39 -0400 (EDT) Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8SHW-00011q-8W for sip@ietf.org; Thu, 25 Aug 2005 20:41:20 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 865112063A for ; Fri, 26 Aug 2005 05:59:31 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 84E5E2062D for ; Fri, 26 Aug 2005 05:59:29 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 06:10:25 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 06:10:09 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:17:19 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A5FF2A8012 for ; Thu, 25 Aug 2005 19:17:17 +0530 (IST) Received: from beast.cs.columbia.edu (beast.cs.columbia.edu [128.59.16.75]) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 23CD83F4005 for ; Thu, 25 Aug 2005 19:17:15 +0530 (IST) Received: from beast.cs.columbia.edu ([128.59.16.75]) by beast.cs.columbia.edu with esmtp (Exim 4.12) id 1E8Hwt-0007IQ-03; Thu, 25 Aug 2005 09:39:19 -0400 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by beast.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BHTi027873 for ; Thu, 25 Aug 2005 05:11:17 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j7P9BAsw024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Aug 2005 05:11:11 -0400 (EDT) Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62621 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1E8DlI-00042C-2w; Thu, 25 Aug 2005 10:11:04 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FDEDF84-0E76-4BB2-94AB-020F13B45598@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 25 Aug 2005 10:10:58 +0100 To: sreeram.kanumuri@wipro.com X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.25.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT_APPLEMAIL 0, __X_MAILER_APPLEMAIL 0' X-crf-test: 0 X-Mailman-Approved-At: Thu, 25 Aug 2005 09:39:13 -0400 Subject: [Sip-implementors] Re: [Sip] SDP Query X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: X-OriginalArrivalTime: 25 Aug 2005 13:47:19.0498 (UTC) FILETIME=[8311CAA0:01C5A97B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is not valid, since it's missing "v=", "o=", and "s=" lines, all of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field > in each media description level. > "C" value at the session level is like global value.and Media > level is like local. > so if you do not have it in Media level it will take the value at > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP > address for that particular Media stream "c" (to 0.0.0.0 or > a=inactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=IN IP4 224.2.17.12/127 > t=2873397496 2873404696 > a=recvonly > m=audio 49170 RTP/AVP 0 > c=IN IP4 224.2.17.13/127 > m=video 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session > and media description is for handling hold cases, where you want to > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 25 21:40:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8TCN-0008No-9e; Thu, 25 Aug 2005 21:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8TCI-0008IZ-K5 for sip@megatron.ietf.org; Thu, 25 Aug 2005 21:40:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06670 for ; Thu, 25 Aug 2005 21:39:56 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8TCu-0002lA-Mj for sip@ietf.org; Thu, 25 Aug 2005 21:40:38 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B107820623 for ; Fri, 26 Aug 2005 06:58:50 +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 91D192061E for ; Fri, 26 Aug 2005 06:58:50 +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.211); Fri, 26 Aug 2005 07:09:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip-implementors] Re: [Sip] SDP Query Date: Fri, 26 Aug 2005 07:09:46 +0530 Message-ID: Thread-Topic: [Sip-implementors] Re: [Sip] SDP Query Thread-Index: AcWpy/s1wF+dSrz0Sp+2R85RA4qI/QAEjKcG To: X-OriginalArrivalTime: 26 Aug 2005 01:39:46.0866 (UTC) FILETIME=[0A7C8120:01C5A9DF] X-Spam-Score: 0.9 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1707100490==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1707100490== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A9DF.0A52DAD5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A9DF.0A52DAD5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin, =20 SDP is invalid with out mandatory parameters. What I mean is not the syntax and other parameters. =20 I mean to explan Udit's question of multiple "C" parameters at Media = description level and Session level. =20 -Sreeram. ________________________________ From: sip-implementors-bounces@cs.columbia.edu on behalf of Colin = Perkins Sent: Thu 8/25/2005 5:10 AM To: Sreeram Kanumuri (WT01 - Voice & Next Generation Networks) Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; Udit_Goyal@3com.com Subject: [Sip-implementors] Re: [Sip] SDP Query This is not valid, since it's missing "v=3D", "o=3D", and "s=3D" lines, = all=20 of which are mandatory in SDP. Colin On 24 Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote: > Hi Udit, > > There Must be one "C" field at the session level (or) one "C" field=20 > in each media description level. > "C" value at the session level is like global value.and Media=20 > level is like local. > so if you do not have it in Media level it will take the value at=20 > Session level. > > so to your question: > Yes it is valid. > It is indicating different Ip addresses for different Media types. > > If you want a particular media stream to be in holding give that IP=20 > address for that particular Media stream "c" (to 0.0.0.0 or=20 > a=3Dinactive) > > HTH, > > Regards, > Sreeram. > > From: sip-bounces@ietf.org on behalf of Udit_Goyal@3com.com > Sent: Wed 8/24/2005 4:11 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip] SDP Query > > > Hi, > > Just want to check if following SDP is valid: > > c=3DIN IP4 224.2.17.12/127 > t=3D2873397496 2873404696 > a=3Drecvonly > m=3Daudio 49170 RTP/AVP 0 > c=3DIN IP4 224.2.17.13/127 > m=3Dvideo 51372 RTP/AVP 31 > > It indicates different IP address used for audio and video types. > > I thought the reason we have connection parameter in both session=20 > and media description is for handling hold cases, where you want to=20 > hold a particular set of media instead of whole session. > > Regards, > Udit > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ------_=_NextPart_001_01C5A9DF.0A52DAD5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Sip-implementors] Re: [Sip] SDP Query=0A= =0A= =0A=
=0A=
Colin,
=0A=
 
=0A=
SDP is = invalid with out =0A= mandatory parameters.
=0A=
What I = mean is not the =0A= syntax and other parameters.
=0A=
 
=0A=
I mean to = explan Udit's  =0A= question of multiple "C" parameters at  Media description = level and =0A= Session level.
=0A=
 
=0A=
-Sreeram.
=0A=

=0A=
=0A= From: = sip-implementors-bounces@cs.columbia.edu =0A= on behalf of Colin Perkins
Sent: Thu 8/25/2005 5:10 = AM
To: =0A= Sreeram Kanumuri (WT01 - Voice & Next Generation = Networks)
Cc: =0A= sip@ietf.org; sip-implementors@cs.columbia.edu; =0A= Udit_Goyal@3com.com
Subject: [Sip-implementors] Re: [Sip] SDP =0A= Query

=0A=
=0A=

This is not valid, since it's missing "v=3D", "o=3D", = and "s=3D" =0A= lines, all 
of which are mandatory in = SDP.

Colin


On 24 =0A= Aug 2005, at 23:08, sreeram.kanumuri@wipro.com wrote:
> Hi =0A= Udit,
>
> There Must be one "C" field at the session level = (or) one =0A= "C" field 
> in each media description level.
> "C" = value at =0A= the session level is like global value.and  Media 
> = level is =0A= like local.
> so if you do not have it in Media level it will take = the =0A= value at 
> Session level.
>
> so  to your =0A= question:
> Yes it is valid.
> It is indicating different Ip =0A= addresses for different Media types.
>
> If you want a = particular =0A= media stream to be in holding give that IP 
> address for = that =0A= particular Media stream  "c"  (to 0.0.0.0 or 
> =0A= a=3Dinactive)
>
> HTH,
>
> Regards,
> =0A= Sreeram.
>
> From: sip-bounces@ietf.org on behalf of =0A= Udit_Goyal@3com.com
> Sent: Wed 8/24/2005 4:11 PM
> To: SIP =0A= Implementors
> Cc: SIP IETF
> Subject: [Sip] SDP =0A= Query
>
>
> Hi,
>
> Just want to check if =0A= following SDP is =0A= valid:
>
>         = c=3DIN IP4 =0A= 224.2.17.12/127
>         =0A= t=3D2873397496 = 2873404696
>         =0A= a=3Drecvonly
>         = m=3Daudio 49170 =0A= RTP/AVP 0
>         c=3DIN = IP4 =0A= 224.2.17.13/127
>         = m=3Dvideo =0A= 51372 RTP/AVP 31
>
> It indicates different IP address used = for =0A= audio and video types.
>
> I thought the reason we have = connection =0A= parameter in both session 
> and media description is for = handling =0A= hold cases, where you want to 
> hold a particular set of = media =0A= instead of whole session.
>
> Regards,
> Udit
> =0A= _______________________________________________
> Sip mailing = list  =0A= https://www1.ietf.org= /mailman/listinfo/sip
> =0A= This list is for NEW development of the core SIP Protocol
> Use =0A= sip-implementors@cs.columbia.edu for questions on current sip
> = Use =0A= sipping@ietf.org for new developments on the application of =0A= sip

_______________________________________________
Sip-impleme= ntors =0A= mailing list
Sip-implementors@cs.columbia.edu
h= ttp://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

=0A= =0A= =0A= ------_=_NextPart_001_01C5A9DF.0A52DAD5-- --===============1707100490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1707100490==-- From sip-bounces@ietf.org Fri Aug 26 03:08:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8YK9-000215-QX; Fri, 26 Aug 2005 03:08:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8YK4-0001yM-QD for sip@megatron.ietf.org; Fri, 26 Aug 2005 03:08:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01738 for ; Fri, 26 Aug 2005 03:08:19 -0400 (EDT) Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8YKj-0002jE-Kz for sip@ietf.org; Fri, 26 Aug 2005 03:09:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip-implementors] RE: [Sip] SDP Query Date: Fri, 26 Aug 2005 08:07:53 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23690@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] SDP Query Thread-Index: AcWo53h22ZOWaQ6aRCabES3a4Ab4IAAa12WwAC6exjA= From: "Attila Sipos" To: , "SIP Implementors" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry. Colin Perkins is correct - it isn't a correct SDP. I was just considering the m=3D and c=3D lines when I made my evaluation. Regards, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Attila >> Sipos >> Sent: 25 August 2005 10:02 >> To: Udit_Goyal@3com.com; SIP Implementors >> Cc: SIP IETF >> Subject: [Sip-implementors] RE: [Sip] SDP Query >>=20 >>=20 >> Hi Udit,=20 >> =20 >> Yes it is valid. The question is what did you intend it to mean? >> =20 >> In your example, you will end up with audio with IP 224.2.17.13 >> and video with IP 224.2.17.12. >> =20 >> The first "c=3D" (is a session description "c=3D" since it comes=20 >> before any >> "m=3D" section) means use this IP address for all media unless the >> media description says otherwise. >> =20 >> The second "c=3D" (is a media description "c=3D" because it=20 >> comes after the "m=3D") >> means for this particular media use the address I've specified here. >> =20 >> You could have, as an alternative, written your SDP like this: >> =20 >> t=3D2873397496 2873404696=20 >> a=3Drecvonly=20 >> m=3Daudio 49170 RTP/AVP 0=20 >> c=3DIN IP4 224.2.17.13/127=20 >> m=3Dvideo 51372 RTP/AVP 31=20 >> c=3DIN IP4 224.2.17.12/127=20 >>=20 >> In my example above, there is no session description "c=3D" so every >> media description has to have a "c=3D". >> =20 >> Regards, >> =20 >> Attila Sipos >> http://www.vegastream.com >> =20 >> =20 >>=20 >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 >> Behalf Of Udit_Goyal@3com.com >> Sent: 24 August 2005 21:11 >> To: SIP Implementors >> Cc: SIP IETF >> Subject: [Sip] SDP Query >>=20 >>=20 >>=20 >> Hi,=20 >>=20 >> Just want to check if following SDP is valid:=20 >>=20 >> c=3DIN IP4 224.2.17.12/127=20 >> t=3D2873397496 2873404696=20 >> a=3Drecvonly=20 >> m=3Daudio 49170 RTP/AVP 0=20 >> c=3DIN IP4 224.2.17.13/127=20 >> m=3Dvideo 51372 RTP/AVP 31=20 >>=20 >> It indicates different IP address used for audio and video types.=20 >>=20 >> I thought the reason we have connection parameter in both=20 >> session and media description is for handling hold cases,=20 >> where you want to hold a particular set of media instead of=20 >> whole session.=20 >>=20 >> Regards,=20 >> Udit=20 >>=20 >>=20 >>=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 09:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dpD-000768-Sm; Fri, 26 Aug 2005 09:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8W6O-0004SF-SJ for sip@megatron.ietf.org; Fri, 26 Aug 2005 00:46:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13043 for ; Fri, 26 Aug 2005 00:46:02 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8W72-0007Ua-Rs for sip@ietf.org; Fri, 26 Aug 2005 00:46:46 -0400 Received: by wproxy.gmail.com with SMTP id i20so63032wra for ; Thu, 25 Aug 2005 21:45:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=STOXtOZUsqcGfLFG373tVjNDostexVuZvixN1UwtnI7129mNrQlpQkibtjgLZgOI5zbwe0RJ+r7xuTRemebRqfoKQu2dBff2XeFzIhDzV0S44aV6b2RWmjNLvlIo3VCIr3NMoDZyA3gkGSyDf/D4Syf6OGE0bH1TCg0zkYFk+X8= Received: by 10.54.41.55 with SMTP id o55mr2840684wro; Thu, 25 Aug 2005 21:45:39 -0700 (PDT) Received: by 10.54.141.1 with HTTP; Thu, 25 Aug 2005 21:45:39 -0700 (PDT) Message-ID: <5ff8235a05082521454518f845@mail.gmail.com> Date: Fri, 26 Aug 2005 00:45:39 -0400 From: Feng QIN To: sip@ietf.org, sip-implementors@cs.columbia.edu, jdrosen@dynamicsoft.com Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 26 Aug 2005 09:00:49 -0400 Cc: Subject: [Sip] RFC3261: INVITE and non-INVITE server transactions proceeding state has no timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0077709811==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0077709811== Content-Type: multipart/alternative; boundary="----=_Part_4371_6821309.1125031539448" ------=_Part_4371_6821309.1125031539448 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, If we look at RFC3261 on INVITE and non-INVITE server transaction, in=20 proceeding state, transaction only wait for TU to give response to send, bu= t=20 there are no timers to check when TU can give the response. Assuming in a B2BUA, if the outgoing client transaction has no response, th= e=20 INVITE server transaction will NOT get the response from the TU ever, thus= =20 the transaction resource will be dead here. Do we really miss timers there or it implies application should add timer= =20 for this case by itself? Thanks in advance! --=20 Best Regards. QIN Feng ------=_Part_4371_6821309.1125031539448 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all,
If we look at RFC3261 on INVITE and non-INVITE server transaction, in proceeding state, transaction only wait for TU to give response to send, but there are no timers to check when TU can give the response.
Assuming in a B2BUA, if the outgoing client transaction has no response, the INVITE server transaction will NOT get the response from the TU ever, thus the transaction resource will be dead here.

Do we really miss timers there or it implies application should add timer f= or this case by itself?

Thanks in advance!

--
Best Regards.

QIN Fen= g ------=_Part_4371_6821309.1125031539448-- --===============0077709811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0077709811==-- From sip-bounces@ietf.org Fri Aug 26 09:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eUW-0003C6-48; Fri, 26 Aug 2005 09:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8eUS-0003Bp-3e for sip@megatron.ietf.org; Fri, 26 Aug 2005 09:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20018 for ; Fri, 26 Aug 2005 09:43:26 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler3.mail.eds.com ([192.85.154.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8eV5-0006zw-Fi for sip@ietf.org; Fri, 26 Aug 2005 09:44:13 -0400 Received: from ahmlir4.mail.eds.com (ahmlir4-2.mail.eds.com [192.85.154.134]) by ahmler3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7QDh2Ym001689; Fri, 26 Aug 2005 09:43:04 -0400 Received: from ahmlir4.mail.eds.com (localhost [127.0.0.1]) by ahmlir4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7QDgKBe001031; Fri, 26 Aug 2005 09:42:20 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j7QDgJLv001021; Fri, 26 Aug 2005 09:42:19 -0400 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Fri, 26 Aug 2005 09:48:54 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 08/26/2005 06:42:19 AM, Serialize complete at 08/26/2005 06:42:19 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF Subject: [Sip] Reinvite transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122398240==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============2122398240== Content-Type: multipart/alternative; boundary="=_alternative 004B2AA685257069_=" This is a multipart message in MIME format. --=_alternative 004B2AA685257069_= Content-Type: text/plain; charset="US-ASCII" Hi, If during a call, UAC sends RE-invite to change the media, hence a INVITE client transaction will be created, and before he gets any final response, he wants to end the call. If it sends BYE message, it will be a separate transaction, is it the responsibilty of UAC core to end all pending client transactions before sending BYE. because BYE is a separate client transaction. -Udit --=_alternative 004B2AA685257069_= Content-Type: text/html; charset="US-ASCII"
Hi,

If during a call, UAC sends RE-invite to change the media, hence a INVITE client transaction will be created,
and before he gets any final response, he wants to end the call.
 
If it sends BYE message, it will be a separate transaction, is it the responsibilty of UAC core to end all pending client transactions before sending BYE.
because BYE is a separate client transaction.

-Udit
--=_alternative 004B2AA685257069_=-- --===============2122398240== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2122398240==-- From sip-bounces@ietf.org Fri Aug 26 10:16:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ezS-0003sj-0j; Fri, 26 Aug 2005 10:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ezP-0003sZ-4B for sip@megatron.ietf.org; Fri, 26 Aug 2005 10:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22459 for ; Fri, 26 Aug 2005 10:15:25 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8f08-00085f-0L for sip@ietf.org; Fri, 26 Aug 2005 10:16:13 -0400 Received: from persephone.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Aug 2005 15:13:12 +0100 Message-ID: <430F2377.50606@cs.ucl.ac.uk> Date: Fri, 26 Aug 2005 15:13:11 +0100 From: "Piers O'Hanlon" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hgs@cs.columbia.edu, "James M. Polk" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: p.ohanlon@cs.ucl.ac.uk List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Henning and James, I realise the draft has gone to the IESG but I had a few comments that I would be obliged if you could address (plus some minor grammatical notes): In Section 4.5.1"Preemption"; (last paragraph): Just a small point of consistency: It seems unnecessary to refer the reader to section 4.7.2 when the same isn't done for the following section? (Unless you do the same for both sections). In Section 4.5.2 "Priority Queuing"; (At the end of the first paragraph): " If the per-priority-value queue for a newly arriving request is full, the request is rejected immediately. In addition, a priority queueing policy MAY impose a waiting time limit for each priority class, where requests that exceed a specified waiting time are ejected from the queue and a failure response is returned to the requestor." Presumably "ejected" is intended to be equivalent to (or replaced by) "rejected"? It might be useful to elucidate the the meaning (error status) of 'reject' in its various forms in the draft - or refer the reader to the relevant error section. (for example the first [in the above paragraph] 'rejection' code would be something like a 488, and the second may be 408?) Minor grammatical issues: The word "queuing" has been misspelt as "queueing" in a number of places in the draft. Section 4.1: " option tag in a 'Require' header field is describe in Section 4.3 ." describe->described Section 11.1: Para1: "In SIP end system such as IP phones" system->systems Para3: "This authentication and authorization requirements extends to users" This->These, extends->extend Thanks, Piers O'Hanlon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 12:19:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gv0-00060O-De; Fri, 26 Aug 2005 12:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gux-000606-Hu for sip@megatron.ietf.org; Fri, 26 Aug 2005 12:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29779 for ; Fri, 26 Aug 2005 12:18:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gvi-0003zj-JP for sip@ietf.org; Fri, 26 Aug 2005 12:19:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 26 Aug 2005 09:18:50 -0700 X-IronPort-AV: i="3.96,144,1122879600"; d="scan'208"; a="656973335:sNHT31029404" 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 j7QGI4R0027151; Fri, 26 Aug 2005 09:18:42 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 09:18:46 -0700 Received: from jmpolk-wxp.cisco.com ([171.71.200.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 09:18:45 -0700 Message-Id: <4.3.2.7.2.20050826104350.0325e6f8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Aug 2005 11:18:45 -0500 To: p.ohanlon@cs.ucl.ac.uk, hgs@cs.columbia.edu From: "James M. Polk" In-Reply-To: <430F2377.50606@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Aug 2005 16:18:45.0903 (UTC) FILETIME=[D566E9F0:01C5AA59] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Piers Thanks for the review. I agree with everything you suggest except 2 items below. Of those 2, one I believe is covered already, and the other has two choices for a simple solution. more comments in-line below At 03:13 PM 8/26/2005 +0100, Piers O'Hanlon wrote: >Henning and James, > >I realise the draft has gone to the IESG but I had a few comments that I >would be obliged if you could address (plus some minor grammatical notes): > >In Section 4.5.1"Preemption"; (last paragraph): >Just a small point of consistency: It seems unnecessary to refer the >reader to section 4.7.2 when the same isn't done for the following >section? (Unless you do the same for both sections). Would you prefer referring both sections (4.5.1 and 4.5.2) to 4.7.2 *or* referring 4.5.1 to 4.7.2.1 *and* 4.5.2 to 4.7.2.2? Either way, I agree there needs to be consistency here in the doc. >In Section 4.5.2 "Priority Queuing"; (At the end of the first paragraph): > >" If the per-priority-value queue for a newly arriving request is full, >the request is rejected immediately. > In addition, a priority queueing policy MAY impose a waiting time > limit for each priority class, where requests that exceed a specified > waiting time are ejected from the queue and a failure response is > returned to the requestor." > >Presumably "ejected" is intended to be equivalent to (or replaced by) >"rejected"? of course > It might be useful to elucidate the the meaning (error status) of > 'reject' in its various forms in the draft see section 4.6.6 for this > - or refer the reader to the relevant error section. (for example the > first [in the above paragraph] 'rejection' code would be something like a > 488, and the second may be 408?) Doesn't 4.6.6 doesn't address this already, too? >Minor grammatical issues: > >The word "queuing" has been misspelt as "queueing" in a number of places >in the draft. I would prefer this spelling too - I'll talk to my co-author about this. >Section 4.1: >" option tag in a 'Require' header field is describe in Section 4.3 >." >describe->described of course >Section 11.1: >Para1: "In SIP end system such as IP phones" >system->systems of course >Para3: "This authentication and authorization requirements extends to users" >This->These, extends->extend these too >Thanks, > >Piers O'Hanlon cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 13:28:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hzl-0000PM-2u; Fri, 26 Aug 2005 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hzi-0000No-Tm for sip@megatron.ietf.org; Fri, 26 Aug 2005 13:27:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02856 for ; Fri, 26 Aug 2005 13:27:55 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8i0R-00067q-31 for sip@ietf.org; Fri, 26 Aug 2005 13:28:46 -0400 Received: from persephone.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Aug 2005 18:26:24 +0100 Message-ID: <430F50C0.9000509@cs.ucl.ac.uk> Date: Fri, 26 Aug 2005 18:26:24 +0100 From: "Piers O'Hanlon" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20050826104350.0325e6f8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20050826104350.0325e6f8@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, hgs@cs.columbia.edu Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: p.ohanlon@cs.ucl.ac.uk List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org James, Thanks for getting back to me - some responses below. >> In Section 4.5.1"Preemption"; (last paragraph): >> Just a small point of consistency: It seems unnecessary to refer the >> reader to section 4.7.2 when the same isn't done for the following >> section? (Unless you do the same for both sections). > > Would you prefer referring both sections (4.5.1 and 4.5.2) to 4.7.2 > *or* > referring 4.5.1 to 4.7.2.1 *and* 4.5.2 to 4.7.2.2? > The latter option sounds good - best to give too much info than too little. >> In Section 4.5.2 "Priority Queuing"; (At the end of the first >> paragraph): >> >> " If the per-priority-value queue for a newly arriving request is >> full, the request is rejected immediately. >> In addition, a priority queueing policy MAY impose a waiting time >> limit for each priority class, where requests that exceed a specified >> waiting time are ejected from the queue and a failure response is >> returned to the requestor." >> >> Presumably "ejected" is intended to be equivalent to (or replaced by) >> "rejected"? > > of course > It may however save some confusion by using the same word everywhere for the same thing. >> - or refer the reader to the relevant error section. (for example >> the first [in the above paragraph] 'rejection' code would be >> something like a 488, and the second may be 408?) > > > Doesn't 4.6.6 doesn't address this already, too? I guess it addresses it in a general way - I thought it might be useful to just mention specific error codes when explaining each rejection as, for example, is done in 4.6.2, point 2. It's not always that clear as to which error code to use, though I guess in certain cases there may be different error codes used (depending on what caused the rejection)? Cheers, Piers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 22:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qMF-0005bq-8c; Fri, 26 Aug 2005 22:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qMD-0005bl-Pl for sip@megatron.ietf.org; Fri, 26 Aug 2005 22:23:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06159 for ; Fri, 26 Aug 2005 22:23:41 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8qN1-00080m-3C for sip@ietf.org; Fri, 26 Aug 2005 22:24:36 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7R2MK06024079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Aug 2005 22:22:25 -0400 (EDT) Message-ID: <430FCE4E.2060706@cs.columbia.edu> Date: Fri, 26 Aug 2005 22:22:06 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: p.ohanlon@cs.ucl.ac.uk References: <430F2377.50606@cs.ucl.ac.uk> In-Reply-To: <430F2377.50606@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > The word "queuing" has been misspelt as "queueing" in a number of places > in the draft. This is a matter of taste. I tend to go by the seminal books in this field: Leonard Kleinrock Theory, Volume 1, Queueing Systems or Donald Gross Fundamentals of Queueing Theory Queuing is the more popular spelling according to Google, but there are 806,000 references to queueing :-) Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 22:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qPz-0006nm-6V; Fri, 26 Aug 2005 22:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qPw-0006nh-TI for sip@megatron.ietf.org; Fri, 26 Aug 2005 22:27:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06323 for ; Fri, 26 Aug 2005 22:27:34 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8qQm-00087q-Dk for sip@ietf.org; Fri, 26 Aug 2005 22:28:29 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7R2RQON003554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Aug 2005 22:27:28 -0400 (EDT) Message-ID: <430FCF7E.4020107@cs.columbia.edu> Date: Fri, 26 Aug 2005 22:27:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: p.ohanlon@cs.ucl.ac.uk References: <430F2377.50606@cs.ucl.ac.uk> In-Reply-To: <430F2377.50606@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Piers O'Hanlon wrote: > Section 4.1: > " option tag in a 'Require' header field is describe in Section 4.3 > ." > > describe->described > > Section 11.1: > Para1: "In SIP end system such as IP phones" > system->systems > Para3: "This authentication and authorization requirements extends to > users" > This->These, extends->extend I fixed these; depending on what happens, they'll get addressed either before it reaches the RFC editor or in AUTH48. Thanks for catching them. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 22:52:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qo4-0005II-D7; Fri, 26 Aug 2005 22:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8qo2-0005ID-QX for sip@megatron.ietf.org; Fri, 26 Aug 2005 22:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07159 for ; Fri, 26 Aug 2005 22:52:28 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8qos-0000O5-Ji for sip@ietf.org; Fri, 26 Aug 2005 22:53:23 -0400 Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net [141.153.174.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7R2qJEr005815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Aug 2005 22:52:20 -0400 (EDT) Message-ID: <430FD550.5080604@cs.columbia.edu> Date: Fri, 26 Aug 2005 22:52:00 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: p.ohanlon@cs.ucl.ac.uk References: <4.3.2.7.2.20050826104350.0325e6f8@email.cisco.com> <430F50C0.9000509@cs.ucl.ac.uk> In-Reply-To: <430F50C0.9000509@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Piers O'Hanlon wrote: >> *or* >> referring 4.5.1 to 4.7.2.1 *and* 4.5.2 to 4.7.2.2? >> > The latter option sounds good - best to give too much info than too little. Added to both sections. > I guess it addresses it in a general way - I thought it might be useful > to just mention specific error codes when explaining each rejection as, > for example, is done in 4.6.2, point 2. It's not always that clear as to > which error code to use, though I guess in certain cases there may be > different error codes used (depending on what caused the rejection)? This is a bit more difficult. Requests that timeout after residing in the queue always get a 408, which I've now noted. Depending on the particular circumstance (UAS vs. proxy, signaling vs. media path overload, etc.), the rejection when first arriving at the queue can generate several different error codes. It don't think it would help to enumerate them all here, but I've added a reference to 4.6.5 and 4.6.6. > > Cheers, > > Piers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 26 23:07:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8r2r-0002Re-UB; Fri, 26 Aug 2005 23:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8r2p-0002RR-1J; Fri, 26 Aug 2005 23:07:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07965; Fri, 26 Aug 2005 23:07:44 -0400 (EDT) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8r3d-0000tk-H2; Fri, 26 Aug 2005 23:08:39 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7R37d6n003730; Fri, 26 Aug 2005 23:07:39 -0400 (EDT) In-Reply-To: <430FCE4E.2060706@cs.columbia.edu> Subject: Re: [Sip] Re: draft-ietf-sip-resource-priority-10 comments To: Henning Schulzrinne X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 26 Aug 2005 23:05:44 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 08/26/2005 11:07:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, "James M. Polk" , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org To say nothing of "Queues" by D.R. Cox and Wally Smith (which consistently uses the spelling "queueing"). Janet sip-bounces@ietf.org wrote on 08/26/2005 10:22:06 PM: > > > > > The word "queuing" has been misspelt as "queueing" in a number of places > > in the draft. > > This is a matter of taste. I tend to go by the seminal books in this field: > > Leonard Kleinrock > Theory, Volume 1, Queueing Systems > > or > > Donald Gross > Fundamentals of Queueing Theory > > Queuing is the more popular spelling according to Google, but there are > 806,000 references to queueing :-) > > Henning > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 28 23:40:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9aVv-00083H-B5; Sun, 28 Aug 2005 23:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9aVt-000838-Jy for sip@megatron.ietf.org; Sun, 28 Aug 2005 23:40:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28705 for ; Sun, 28 Aug 2005 23:40:46 -0400 (EDT) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9aX7-0008CB-Jr for sip@ietf.org; Sun, 28 Aug 2005 23:42:08 -0400 Received: from [192.168.1.4] (pool-70-16-6-169.balt.east.verizon.net [70.16.6.169]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id j7T3eRX29149 for ; Sun, 28 Aug 2005 22:40:27 -0500 Subject: [Fwd: [Sip] STUN state machine question] From: "Frank W. Miller" To: sip@ietf.org Content-Type: multipart/mixed; boundary="=-h4Rads8dKYUIyM+FxkJg" Organization: Cornfed Systems, LLC Date: Sun, 28 Aug 2005 23:40:22 -0400 Message-Id: <1125286822.2496.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --=-h4Rads8dKYUIyM+FxkJg Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I didn't get any response to this message a week ago so I thought I would try again... Thanks for any comments... FM --=-h4Rads8dKYUIyM+FxkJg Content-Disposition: inline Content-Description: Forwarded message - [Sip] STUN state machine question Content-Type: message/rfc822 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id j7LIggO02593 for ; Sun, 21 Aug 2005 13:42:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ulJ-0006pW-Oq; Sun, 21 Aug 2005 14:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ulH-0006pN-Jx for sip@megatron.ietf.org; Sun, 21 Aug 2005 14:41:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11749 for ; Sun, 21 Aug 2005 14:41:38 -0400 (EDT) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6vLg-0005Ww-Cd for sip@ietf.org; Sun, 21 Aug 2005 15:19:17 -0400 Received: from [192.168.1.4] (pool-70-16-6-169.balt.east.verizon.net [70.16.6.169]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id j7LIfJO02529 for ; Sun, 21 Aug 2005 13:41:19 -0500 From: "Frank W. Miller" To: sip@ietf.org Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sun, 21 Aug 2005 14:41:17 -0400 Message-Id: <1124649677.2955.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] STUN state machine question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Status: Content-Transfer-Encoding: 7bit Greetings, I've been working with STUN a bit lately and have run into an interesting situation. This may have been discussed elsewhere and I just haven't seen it. If so, I apologize and would appreciate a pointer to that discussion. In the state diagram, Figure 2 of RFC 3489, there is a path to repeat Test I. That is, if the first execution of Test I yields a different IP address than the current host interface IP address and no response is received from the STUN server for Test II, the client repeats Test I sending the Binding Request to the IP address specified in the CHANGED-ADDRESS attribute from the first execution of Test I. My question is, what should the client assume if no response is received for the repeated execution of Test I? It seems to me that in theory, this situation should never occur. The reason is because the first execution of Test I returned a response and the second execution is doing the same thing, just with a different IP address and port number. However, I have encountered situations in practice where this does occur. My guess would be that you can certainly assume a NAT and use the MAPPED-ADDRESS that you get from the response to the first Test I. Would that be a good assumption? Also, what type of NAT would I then call that? Thoughts? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=-h4Rads8dKYUIyM+FxkJg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=-h4Rads8dKYUIyM+FxkJg-- From sip-bounces@ietf.org Mon Aug 29 09:13:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jSZ-00070F-51; Mon, 29 Aug 2005 09:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fIW-00017z-58 for sip@megatron.ietf.org; Fri, 26 Aug 2005 10:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23881 for ; Fri, 26 Aug 2005 10:35:09 -0400 (EDT) Received: from bay101-f10.bay101.hotmail.com ([64.4.56.20] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fJE-0000Hw-6k for sip@ietf.org; Fri, 26 Aug 2005 10:35:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 07:34:59 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Fri, 26 Aug 2005 14:34:59 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [vimalsrivastava@hotmail.com] X-Sender: vimalsrivastava@hotmail.com In-Reply-To: <5ff8235a05082521454518f845@mail.gmail.com> From: "vimal srivastava" To: feng.w.qin@gmail.com, sip@ietf.org, sip-implementors@cs.columbia.edu, jdrosen@dynamicsoft.com Date: Fri, 26 Aug 2005 10:34:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Aug 2005 14:34:59.0771 (UTC) FILETIME=[565690B0:01C5AA4B] X-Spam-Score: 3.0 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Mon, 29 Aug 2005 09:13:56 -0400 Cc: Subject: [Sip] RE: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Server Transaction need not run any timer because the Client Transaction which has initiated the Invite/Non-Invite would take care of it. they do run timer. v. From: Feng QIN To: sip@ietf.org, sip-implementors@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer Date: Fri, 26 Aug 2005 00:45:39 -0400 Hello all, If we look at RFC3261 on INVITE and non-INVITE server transaction, in proceeding state, transaction only wait for TU to give response to send, but there are no timers to check when TU can give the response. Assuming in a B2BUA, if the outgoing client transaction has no response, the INVITE server transaction will NOT get the response from the TU ever, thus the transaction resource will be dead here. Do we really miss timers there or it implies application should add timer for this case by itself? Thanks in advance! -- Best Regards. QIN Feng _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 29 09:14:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jSa-00070g-Uz; Mon, 29 Aug 2005 09:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fO6-0002DL-0x for sip@megatron.ietf.org; Fri, 26 Aug 2005 10:41:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24169 for ; Fri, 26 Aug 2005 10:40:55 -0400 (EDT) Received: from bay101-f28.bay101.hotmail.com ([64.4.56.38] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fOp-0000Tx-3a for sip@ietf.org; Fri, 26 Aug 2005 10:41:44 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 07:40:47 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Fri, 26 Aug 2005 14:40:47 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [vimalsrivastava@hotmail.com] X-Sender: vimalsrivastava@hotmail.com In-Reply-To: <5ff8235a05082521454518f845@mail.gmail.com> From: "vimal srivastava" To: feng.w.qin@gmail.com, sip@ietf.org, jdrosen@dynamicsoft.com, sip-implementors@cs.columbia.edu Date: Fri, 26 Aug 2005 10:40:47 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Aug 2005 14:40:47.0335 (UTC) FILETIME=[25809F70:01C5AA4C] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 29 Aug 2005 09:13:56 -0400 Cc: Subject: [Sip] RE: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is how b2bua is working You receive INIVTE at UAS, => a server transaction is created you send out INVITE from UAC => a client transaction is created. now if UAC does not receive any response from the network, then client side transaction will expire Timer B, and tell the application about the TimeOut Condition. now B2bua should respond to UAS side (response of Invite received) based on policy may be 5xx etc. so all the transactions are taken care of. v. From: Feng QIN To: sip@ietf.org, sip-implementors@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer Date: Fri, 26 Aug 2005 00:45:39 -0400 Hello all, If we look at RFC3261 on INVITE and non-INVITE server transaction, in proceeding state, transaction only wait for TU to give response to send, but there are no timers to check when TU can give the response. Assuming in a B2BUA, if the outgoing client transaction has no response, the INVITE server transaction will NOT get the response from the TU ever, thus the transaction resource will be dead here. Do we really miss timers there or it implies application should add timer for this case by itself? Thanks in advance! -- Best Regards. QIN Feng _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 29 09:14:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jSe-000717-Or; Mon, 29 Aug 2005 09:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fY1-0005kw-5X for sip@megatron.ietf.org; Fri, 26 Aug 2005 10:51:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24774 for ; Fri, 26 Aug 2005 10:51:11 -0400 (EDT) Received: from bay101-f6.bay101.hotmail.com ([64.4.56.16] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fYk-0000o2-FY for sip@ietf.org; Fri, 26 Aug 2005 10:51:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 07:51:00 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Fri, 26 Aug 2005 14:51:00 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [vimalsrivastava@hotmail.com] X-Sender: vimalsrivastava@hotmail.com In-Reply-To: From: "vimal srivastava" To: Udit_Goyal@3com.com, sip-implementors@cs.columbia.edu Date: Fri, 26 Aug 2005 10:51:00 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Aug 2005 14:51:00.0585 (UTC) FILETIME=[93072590:01C5AA4D] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Mon, 29 Aug 2005 09:13:56 -0400 Cc: sip@ietf.org Subject: [Sip] RE: [Sip-implementors] Reinvite transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it is taken care of. after re-invite is sent and response is awaited, if other party sends BYE, then a response of 481 will be returned for re-invite (481 Call/Transaction Does Not Exist). if after re-invite is sent and same party sends BYE, then the callee, would have already replied to re-invite so situation of hanging re-invite transactin would never come. v. From: Udit_Goyal@3com.com To: "SIP Implementors" CC: SIP IETF Subject: [Sip-implementors] Reinvite transaction Date: Fri, 26 Aug 2005 09:48:54 -0400 Hi, If during a call, UAC sends RE-invite to change the media, hence a INVITE client transaction will be created, and before he gets any final response, he wants to end the call. If it sends BYE message, it will be a separate transaction, is it the responsibilty of UAC core to end all pending client transactions before sending BYE. because BYE is a separate client transaction. -Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 29 09:14:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jSh-00071Y-D9; Mon, 29 Aug 2005 09:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fic-0008EE-9I for sip@megatron.ietf.org; Fri, 26 Aug 2005 11:02:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25225 for ; Fri, 26 Aug 2005 11:02:08 -0400 (EDT) Received: from bay101-f4.bay101.hotmail.com ([64.4.56.14] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fjM-00017W-ID for sip@ietf.org; Fri, 26 Aug 2005 11:02:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 08:02:00 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Fri, 26 Aug 2005 15:01:59 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [vimalsrivastava@hotmail.com] X-Sender: vimalsrivastava@hotmail.com In-Reply-To: <5ff8235a05082607493d5a817c@mail.gmail.com> From: "vimal srivastava" To: feng.w.qin@gmail.com Date: Fri, 26 Aug 2005 11:01:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Aug 2005 15:02:00.0419 (UTC) FILETIME=[1C51D330:01C5AA4F] X-Spam-Score: 3.1 (+++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Mon, 29 Aug 2005 09:13:56 -0400 Cc: sip@ietf.org, jdrosen@dynamicsoft.com, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually there is no customization. You are assuming TU at UAC and UAS both are not responding. lets take the new case: UAC sends an Invite and creates a client transaction, runs timer B UAS receives the invite and creates a server transaction. UAS user is not replying. so UAC side transaction is taken care because of time out condition. now at UAS side, you are asking about its User is not replying and UAS should run timer to clean it up? right? this will happen if TU is dead, or its not working the way it should. why should 3261 provide anything for that? if TU has died, then application should clean up the hanging transaction. if TU is not working the way it should then again, application should write some cleanup on periodic timers.I think this has nothing to do with 3261. 3261 is between UAC-UAS, for establishing session. but again, its more related to the way you look at it. cheers v. From: Feng QIN To: vimal srivastava CC: sip@ietf.org, jdrosen@dynamicsoft.com, sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer Date: Fri, 26 Aug 2005 10:49:37 -0400 Yes, I agree with you this can work under the help of TU level customized mechanism, but it can't apply to pure transaction stuff, if there is only a UAC => UAS (no B2BUA) with INVITE, and TU at UAS side has no response, the UAS at proceeding state will be dead? Besides I think it will be prefered by application developer if this problem can be solved under stack level... On 8/26/05, vimal srivastava wrote: > > This is how b2bua is working > You receive INIVTE at UAS, => a server transaction is created > you send out INVITE from UAC => a client transaction is created. > now if UAC does not receive any response from the network, then client > side > transaction will expire Timer B, and tell the application about the > TimeOut > Condition. now B2bua should respond to UAS side (response of Invite > received) based on policy may be 5xx etc. > so all the transactions are taken care of. > v. > > > From: Feng QIN > To: sip@ietf.org, sip-implementors@cs.columbia.edu, > jdrosen@dynamicsoft.com > Subject: [Sip-implementors] RFC3261: INVITE and non-INVITE > servertransactions proceeding state has no timer > Date: Fri, 26 Aug 2005 00:45:39 -0400 > > Hello all, > If we look at RFC3261 on INVITE and non-INVITE server transaction, in > proceeding state, transaction only wait for TU to give response to send, > but > there are no timers to check when TU can give the response. > Assuming in a B2BUA, if the outgoing client transaction has no response, > the > INVITE server transaction will NOT get the response from the TU ever, thus > the transaction resource will be dead here. > > Do we really miss timers there or it implies application should add timer > for this case by itself? > > Thanks in advance! > > -- > Best Regards. > > QIN Feng > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > -- Best Regards. QIN Feng _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 29 20:24:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9tvH-0004RF-7Z; Mon, 29 Aug 2005 20:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9tvE-0004RA-H5 for sip@megatron.ietf.org; Mon, 29 Aug 2005 20:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25795 for ; Mon, 29 Aug 2005 20:24:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9twe-0005a6-T3 for sip@ietf.org; Mon, 29 Aug 2005 20:25:46 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 29 Aug 2005 17:24:07 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7U0NwQM016356; Mon, 29 Aug 2005 17:23:59 -0700 (PDT) Received: from dwingwxp ([10.32.240.197] (may be forged)) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA26710; Mon, 29 Aug 2005 17:24:03 -0700 (PDT) Message-Id: <200508300024.RAA26710@edison.cisco.com> From: "Dan Wing" To: Subject: RE: [Fwd: [Sip] STUN state machine question] Date: Mon, 29 Aug 2005 17:24:02 -0700 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: <1125286822.2496.0.camel@localhost.localdomain> Thread-Index: AcWsTE48VlgVlHoWSw68GhnPNBI/VQAq9zXQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org CC'ing the BEHAVE mailing list, where much of this activity is discussed now-a-days. The revision to RFC3489 (STUN) is also owned by BEHAVE (draft-ietf-behave-rfc3489bis). Determining the 'type of NAT' has been found to less useful than originally envisioned. Some NATs change their behavior after they've exchanged packets for a little while with a stream, and some NATs change behavior when they're really busy and become symmetric. So testing a NAT and declaring it's a certain kind of NAT may result in different answers based on the NAT's load, the duration of the stream being used for the test, and other factors. -d ----- > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Frank W. Miller > Sent: Sunday, August 28, 2005 8:40 PM > To: sip@ietf.org > Subject: [Fwd: [Sip] STUN state machine question] > > > Hi, > > I didn't get any response to this message a week ago so I thought I > would try again... > > Thanks for any comments... > > FM -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank W. Miller Sent: Sunday, August 21, 2005 11:41 AM To: sip@ietf.org Subject: [Sip] STUN state machine question Greetings, I've been working with STUN a bit lately and have run into an interesting situation. This may have been discussed elsewhere and I just haven't seen it. If so, I apologize and would appreciate a pointer to that discussion. In the state diagram, Figure 2 of RFC 3489, there is a path to repeat Test I. That is, if the first execution of Test I yields a different IP address than the current host interface IP address and no response is received from the STUN server for Test II, the client repeats Test I sending the Binding Request to the IP address specified in the CHANGED-ADDRESS attribute from the first execution of Test I. My question is, what should the client assume if no response is received for the repeated execution of Test I? It seems to me that in theory, this situation should never occur. The reason is because the first execution of Test I returned a response and the second execution is doing the same thing, just with a different IP address and port number. However, I have encountered situations in practice where this does occur. My guess would be that you can certainly assume a NAT and use the MAPPED-ADDRESS that you get from the response to the first Test I. Would that be a good assumption? Also, what type of NAT would I then call that? Thoughts? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 30 09:05:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5no-0008NW-DB; Tue, 30 Aug 2005 09:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ltk-0004Zf-Hb for sip@megatron.ietf.org; Mon, 29 Aug 2005 11:50:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17738 for ; Mon, 29 Aug 2005 11:50:09 -0400 (EDT) Received: from elgafwout2.elsag.it ([213.156.53.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9lv5-00042E-NB for sip@ietf.org; Mon, 29 Aug 2005 11:51:37 -0400 Received: from elgasmtp01.elsag.it ([172.19.5.43]) by elgafwout2.elsag.it (8.12.9-Elsag-P1/8.12.9) with ESMTP id j7TFnZvp014437; Mon, 29 Aug 2005 17:49:35 +0200 Received: from els00wmx04.elsag.it (localhost [127.0.0.1]) by elgasmtp01.elsag.it (8.12.10-Elsag/8.12.10) with ESMTP id j7TFnY9P001204; Mon, 29 Aug 2005 17:49:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 29 Aug 2005 17:48:20 +0200 Message-ID: <685F1926C37B1846BE64D0033B46AF970804A2@els00wmx04.elsag.it> Thread-Topic: Technical support needing Thread-Index: AcWssRTkPk0s7aCeSEeGX4dbBuaBDQ== From: "Frosali Daniele" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 30 Aug 2005 09:05:20 -0400 Cc: jf.mule@cablelabs.com, jmaeng@austin.rr.com Subject: [Sip] Technical support needing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi to everyone. I am working on MIB SIP, and I have to write a private MIB for the SIP = module working on a particular device. . I have choosen this way because a RFC does not yet exist.=20 In order to write the MIB, I use=20 =20 draft-ietf-sip-mib-09.txt =20 which I have fund at the IEFT link. =20 http://www.ietf.org/html.charters/sip-charter.html =20 I would like to ask you if this my selection of this MIB is right, or if = I should to find something else about SIP. Specially because the draft = above has...expireed! Thanks a lot for any suggestion. =20 BEST REGARDS Ing. Daniele Frosali _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 30 10:28:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA76c-0004au-8Q; Tue, 30 Aug 2005 10:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA76Z-0004ap-PV for sip@megatron.ietf.org; Tue, 30 Aug 2005 10:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16204 for ; Tue, 30 Aug 2005 10:28:49 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EA787-0002mR-Gn for sip@ietf.org; Tue, 30 Aug 2005 10:30:28 -0400 Received: from persephone.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Aug 2005 15:26:29 +0100 Message-ID: <43146C91.8000101@cs.ucl.ac.uk> Date: Tue, 30 Aug 2005 15:26:25 +0100 From: "Piers O'Hanlon" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne References: <430F2377.50606@cs.ucl.ac.uk> <430FCE4E.2060706@cs.columbia.edu> In-Reply-To: <430FCE4E.2060706@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" Subject: [Sip] Re: draft-ietf-sip-resource-priority-10 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: p.ohanlon@cs.ucl.ac.uk List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > >> >> The word "queuing" has been misspelt as "queueing" in a number of >> places in the draft. > > > This is a matter of taste. I tend to go by the seminal books in this > field: > True it is a bit uncertain...(The Oxford English Dictionary has both listed, with "queueing" first, and Merriam-webster has both spellings, whilst Cambridge Advanced Learner's Dictionary lists only "queueing", though dictionary.com seems to only have "queuing" - So personally I would now say that "queueing" is probably more 'correct'). However keeping to a single spelling might be good in one document? Piers. > Leonard Kleinrock > Theory, Volume 1, Queueing Systems > > or > > Donald Gross > Fundamentals of Queueing Theory > > Queuing is the more popular spelling according to Google, but there > are 806,000 references to queueing :-) > > Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 30 12:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8cS-000297-I0; Tue, 30 Aug 2005 12:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8cM-000292-NS for sip@megatron.ietf.org; Tue, 30 Aug 2005 12:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20532 for ; Tue, 30 Aug 2005 12:05:43 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8du-00054b-G9 for sip@ietf.org; Tue, 30 Aug 2005 12:07:24 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j7UG2x8V010736 for ; Tue, 30 Aug 2005 12:03:00 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j7UG1q8V008913 for ; Tue, 30 Aug 2005 12:02:53 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Technical support needing Date: Tue, 30 Aug 2005 19:02:04 +0300 Message-ID: Thread-Topic: [Sip] Technical support needing Thread-Index: AcWssRTkPk0s7aCeSEeGX4dbBuaBDQAyuv3w From: "Romascanu, Dan \(Dan\)" To: "Frosali Daniele" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: jf.mule@cablelabs.com, jmaeng@austin.rr.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The SIP MIB (draft-ietf-sip-mib-09.txt) went through a MIB Doctor review and an updated version is expected to be submitted soon.=20 Regards, Dan =20 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Frosali Daniele > Sent: Monday, August 29, 2005 6:48 PM > To: sip@ietf.org > Cc: jf.mule@cablelabs.com; jmaeng@austin.rr.com > Subject: [Sip] Technical support needing >=20 > Hi to everyone. > I am working on MIB SIP, and I have to write a private MIB=20 > for the SIP module working on a particular device. . > I have choosen this way because a RFC does not yet exist.=20 > In order to write the MIB, I use=20 > =20 > draft-ietf-sip-mib-09.txt > =20 > which I have fund at the IEFT link. > =20 > http://www.ietf.org/html.charters/sip-charter.html > =20 > I would like to ask you if this my selection of this MIB is=20 > right, or if I should to find something else about SIP.=20 > Specially because the draft above has...expireed! > Thanks a lot for any suggestion. > =20 > BEST REGARDS > Ing. Daniele Frosali >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 31 01:04:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKmO-0006qz-LB; Wed, 31 Aug 2005 01:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKmJ-0006oC-JR for sip@megatron.ietf.org; Wed, 31 Aug 2005 01:04:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02085 for ; Wed, 31 Aug 2005 01:04:50 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAKnz-0000xk-04 for sip@ietf.org; Wed, 31 Aug 2005 01:06:36 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j7V590Gu025037 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 Aug 2005 00:09:01 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0385938D@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0385938D@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] willis-sip-answeralert-00 Date: Wed, 31 Aug 2005 00:04:38 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Jul 29, 2005, at 2:58 PM, Francois Audet wrote: > This answeralert stuff is quite useful. > > The document talks about it's applicability to Push-to-talk. > > I would also like to see a mention of it's usefulness for other > features. > > In particular, you can use it for Intercom call features (like on > any traditional PBX). > That makes sense to me, and I've added this into the revised draft. > Also, it would be extremely useful to allow the answer-mode to be > allowed in an UPDATE (and re-INVITE). That would enable many features > that are available today on traditional PBXs (secretary override, and > other fun stuff difficult to do today). > I started adding this in, and realized I didn't understand the usage in UPDATE (or, probably, re-INVITE). Since there is no new dialog being requested, and consequently no "answering", what good does it do to discuss answering modes? So clearly your hinting at a usage that I haven't quite grokked yet. Please elaborate. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 31 08:32:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARl4-0003SW-2a; Wed, 31 Aug 2005 08:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARl1-0003SR-Cn for sip@megatron.ietf.org; Wed, 31 Aug 2005 08:31:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17578 for ; Wed, 31 Aug 2005 08:31:57 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EARmj-0004LC-QV for sip@ietf.org; Wed, 31 Aug 2005 08:33:48 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2005 08:31:49 -0400 X-IronPort-AV: i="3.96,157,1122868800"; d="scan'208"; a="68476841:sNHT29212886" 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 j7VCViQn027212; Wed, 31 Aug 2005 08:31:46 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 08:31:45 -0400 Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 08:31:45 -0400 Message-ID: <4315A330.5070108@cisco.com> Date: Wed, 31 Aug 2005 08:31:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] willis-sip-answeralert-00 References: <1ECE0EB50388174790F9694F77522CCF0385938D@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2005 12:31:45.0277 (UTC) FILETIME=[F2F112D0:01C5AE27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jul 29, 2005, at 2:58 PM, Francois Audet wrote: > >> This answeralert stuff is quite useful. >> >> The document talks about it's applicability to Push-to-talk. >> >> I would also like to see a mention of it's usefulness for other >> features. >> >> In particular, you can use it for Intercom call features (like on >> any traditional PBX). There are other applications as well. In a call center, agents typically wear headsets, and there is need for an auto-answer mode with alerting in the audio channel. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 31 22:57:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfGg-00031E-Iq; Wed, 31 Aug 2005 22:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfGd-000316-4J for sip@megatron.ietf.org; Wed, 31 Aug 2005 22:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04162 for ; Wed, 31 Aug 2005 22:57:28 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAfIU-00048G-3r for sip@ietf.org; Wed, 31 Aug 2005 22:59:27 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j8131mQX028778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 22:01:48 -0500 Message-ID: <43166E7E.4030700@softarmor.com> Date: Wed, 31 Aug 2005 21:59:10 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 Cc: Rohan Mahy , Allison Mankin Subject: [Sip] Draft minutes, SIP WG at IETF 63 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0140748007==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0140748007== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Draft minutes are posted at:
    http://kevlar.softarmor.com/sipwg/meets/ietf63/notes/minutes.html
and text follows. Please review for accuracy and reported back by midday Friday, Sept. 2,  US CDT (GMT-5).

Minutes, SIP WG, IETF 63

Reported by Dean Willis and Adam Roach
Edited by Dean Willis

Session 1

Status, presented by Rohan Mahy

Slides presented.

Note that content-indirection has finally cleared security review and requires a small RFC editor note that will be drafted by Allison.

Discussion of milestones:

Suggested that it would be a good idea to have a regular report on status for WGLC, etc.

The WG will consider getting a WG secretary as an assigned role.

Noted that if we can't track the work we have, we shouldn't accept new work.

Proposed that we delete the response identity work from our work plan. We plan to reopen this during the discussion of the related draft in the Tuesday session.

Discussion on priority of resource conveyance. Proposed schedule is for Spring 06. James Polk thinks we can get it done sooner, and should due to dependencies. We agreed to reopen the schedule discussion after the WG discussion of this draft in the Tuesday session.

Discussion of SIP Security Flows

There seems to be some support for this work, and a consensus that this stuff if important.  Possibility raised that we might also need to update 3261 and related documents, either to add clarity or to fix bugs, and that this is more important than getting example flows. We also have references to outdated security documents, and common implementations may also not be acceptable for current security review. It was noted that S/MIME implementation issues have been common at SIPIts. Poll: Who has an implementation of S/MIME? At least 5 in the room, and two others at last SIPit who are not represented in this room. consensus: We do not have all required expertise in this room. A significant problem is that there is a knowledge gap between the implementation community and the IETF security area. We'll work on a plan for reducing that gap. An important goal is to move the knowledge from this document (once it's there) into the broader community.


Topic: GRUU

Discussion led by Jonathan Rosenberg
Slides presented

Changes since last version reviewed.

Comment: Opaque parameter: Cullen offered a lengthy comment supporting the idea that nodes other than proxies be able to extract the AOR from the GRUU. The current text seems to allow this if the opaque parameter is used. Rohan will send to Jonathan commentary on an apparent error in the current text.

Comment: We may need to discuss the situation where a client has two connections to different proxies.

Comment: Would like to see more discussion on the opaque parameter. Jonathan will plan to clarify the general usage and synchronize the work with the SIP outbound dual-registration use case.

Comment: When is the GRUU assigned? Is it a function of registering a contact, or is it a function of someone needing the GRUU? Jonathan considers this to be a function of domain policy. It would appear that it cannot be constructed after the registration, but could be constructed before. Further discussion of this can be added to the GRUU document.

Comment: There needs to be something about the ability of a user agent to determine whether an AOR is or is not a GRUU when it receives a GRUU. This relates somehow to use of the GRUU in transfer cases. One possibility might be a ";user=gruu" parameter. Discussion seem to indicate that the receiver just has to try the URI and see if it works -- it can't really care whether or not the contact is a GRUU. Proposed to keep as-is, except for clarification.

Comment: We have a September milestone. Will we make it? This seems to depend on the acceptance of today's proposals.


Issue: The Double Role of GRUU

Proposed three solutions 1) GRUU for new requests only, 2) Amend use of Contact in mid-dialog request, 3) , keep as is

Comment: The SBCs are going to ruin GRUU in all the usages proposed. This may more strongly affect #2, and favors #1.

Comment: The contact information is usually wrong anyhow. This favors #2.

Comment: Currently, route sets in a dialog are immutable. The ability  to use applications at the end point is dependent on  this,

Comment: #2 is favorable, because it also encourages endpoints to deal properly with.  Draft should note that when used with Replaces, INVITES to a GRUU should only get automatic and not interactive service treatments.  This will require some changes in the document relating to edge proxy behavior and moving treatment.

Comment: After the preceding discussion, Cullen no longer favors #2.

Comment: Multiple implementations have proposed to use multiple contacts in dialog as a failover mechanism, This does not favor idea 2.


Poll: Does anyone strongly object to "keeping the text as is"? for this issue with clarification as discussed above)? Consensus on this position is reported.

Topic: Dialog retargeting
Discussion led by Jonathan Rosenberg
Slides included in GRUU deck

No open issues, currently in WGLC


Topic: End to Middle Security

Discussion led by Kumiko Ono
Slides presented

Issue #1 UA reaction to (undecipherable) error? If there is only 1 error code and the UAC doesn't support e2m, they don't really know what to do.

Comment: What we want here is the client to encrypt the body and add the proxy to the keying. This differs from the current usage, in which we want the UAC to change the target of the body rather than adding a key.

Comment: The confusion on this relates to confusions on the 493 response, and that leads to the question of response identity. It might be possible to use SIPS to target the alleged proxy.

Comment: We must be careful to not accidentally introduce errors that lead to "base 400" style behavior. This favors a separate error code.

Proposed that we move forward with a separate response code.

Issue #2: How does a proxy indicate disclosure of a specific content type or whole body?

Proposed that an error code without body type have semantics of "disclose whole body". No objections were noted to this proposal.

Issue #3: Do we need a labeling mechanism to instruct a server to validate a signature

Proposed: No. No objection noted.

Issue #4: How does a UA know if the target proxy server complied to  the UA's request?

Proposed that if  we don 't have a use case for this and one is not forthcoming, that we discard this requirement. Further discussion deferred to list.

Noted that we expect to go to WGLC with the next rev of the dratf.

Topic: Outbound Connections

Discussion led by Cullen Jennings
Slides presented.

Changes in terminology since last draft reviewed. Critical terms are "flow" and "flow ID".

Comment: The terminology is still confusing. Some definition changes were discussed, including use of the term "epoch" to refer to a set of TCP and UDP connections.

Issue: default max retry time is 30 minutes. Does this need to change? No changes were suggested.


Issue: Keepalive. Proposed that we use STUN keepalives for both TCP and UDP. This would require changes to the STUN document.

Comment: ICE also uses STUN over TCP.

Comment: The client needs to know that this is supported. Currently, this is done as a URI parameter.

Discussion of this followed, without conclusion.

Issue; Keepalive Times? Proposed that this be 30s for UDP and 10 minutes for TCP. Noted that 1% of one operator's boxes have UDP timeouts of 15s on their NAT bindings.

Comment: We are not doing this because TCP's keepalive does not work, but because the feedback is not delivered fast enough to the SIP system

Comment: Need to make sure that the document shows that the timer resets on each instance of normal traffic.

Comment: Do we know enough about the performance and congestion impact of this?

Proposed:  30s for UDP and 2min for TCP.

Comment: If UAs do this at startup, we have a potential for a restart avalanche. Discussion on this is deferred.

Issue: Flow questions:

Noted that we cannot assume that all UAs using this will have multiple flows.

Issue:  Transport integrity for flow matching.

Do we want the security section say that this only works with integrity protection? general consensus on "no".

Further issues taken to list, including route construction logic.

Session 2


Topic: Refer: Feature Tags

Discussion led by Orit Levin
Slides presented

  - Topic of discussion: Which feature tags do we want to include
    in the REFER? Does the referer include all features it knows
    about? Only the ones that it thinks are relevant for the call?

    - Paul Kyzivat: Allowing the referer to pick which features
      to include is a slippery slope. Doesn't think disclosing
      feature tags is a security risk. Proposes that the referer
      should (or must) include all feature tags it knows about

    - JDR: Disagree with Paul on the security issue. Also, has
      a concern that people will start using these to bypass normal
      SIP negotiation (e.g. not offering video if the referer does
      not indicate support for video). Further, thinks it is realistic
      to pick which feature tags make sense to include: presumably,
      the purpose of the mechanism is to allow changes in the user
      interface, and it should be possible to identify which features
      might have an impact on the interface.

    - Paul Kyzivat: Don't feel strongly about the topics -- seems to
      hinge on security. If there are no security reasons to not
      include *all* feature tags, then including all feature tags
      can only be a good thing.

    - Cullen Jennings: We need to make sure this isn't going to rely
      on implementors deciding what things to include. Also, the list
      of features can grow to be quite long, if you include everything.
      Propose that we set up a concrete registry of feature parameters
      that should be included in REFER requests.

    - Rohan Mahy: Would it be reasonable to include only those features
      that cannot be discovered via SIP negotiation?

    - Proposal: Use MAY and SHOULD recommendations around which official
      tags are to be included in REFER requests. The text will be vetted
      on the list.

    - Cullen: This is tricky; as an implementor, I can't tell which tags
      I should include in a REFER -- and I can't count on what other people
      will send.

    - Rohan: There are really only two options. You can either have an
      explicit list of what must be included. This will always be out
      of date (and consequently always wrong). Alternately, you can leave
      it up to the discretion of the implementors, in which case it will
      only sometimes be wrong, which is better than always being wrong.

    - Cullen: That doesn't make sense. An IANA registry makes a lot more
      sense.

    - Paul Kyzivat: I don't know why we need this at all. How does knowing
      ahead of time that the thing to be invited is a focus make a
      difference?

    - Orit: Consider isfocus. Most of the time, you're not going to be
      talking to a focus. But somtimes you are, and you can either
      find out ahead of time, or have to query for it.

    - Paul: No, you don't. You get that fact in the 180 or 200 response
      to the INVITE.

    - Dean Willis: I'm confused and my head hurts. Are we reaching a
      consensus?

    - Consensus: no.

    - Chair proposal: We will have a group of interested parties get
      together after the meeting to come up with a plan to conclude the
      document.



Topic Refer: Norefersub

Discussion led by Orit Levin
Slides presented

  - Should we use a "Refer-Sub: false" mechanism, or a Supported/Require
    alternative?

    - Adam Roach: We already decided this. Let's not re-open this.

    - RjS: This is not the timme to do this.

    - JDR: The new proposal doesn't seem to be general in any way.

    - Consensus: Leave it as we defined previously.

  - Should remove the use-case discussing single-hop? There was an
    explicit request to do this.

    - RjS: This seems to work.
    - JDR: It's impractical.
    - RjS: I've seen deployments that do this.
    - JDR: Okay. It's not worth debating.

    - Cullen: Is this a recommendation, or simply an observation?

    - Consensus: Just an observation. The draft should reflect this fact.

Topic: Location Conveyance

Discussion led by James Polk

  - Topic: Location Header Option-tags

    - HGS: This seems to be a table of contents for the body. If
      we're going to do that, it should be more generic. We would
      basically want this for any non-SDP body type. (Some discussion
      around this point, but basically results in agreement with
      Henning's comments)

    - Dave Oran: I'm not sure how these specific option tags allow
      a user agent that doesn't know its location but having the
      wherewithal to select, e.g., between civic or geoloc
      information. (Longer discussion, taken offline).

    - Cullen: SHould look at whether this can be based on the
      SIP identity work. (James expresses some concerns that the
      ECRIT work shouldn't block on SIP identity).

    - Unknown Speaker 1: Is it possible to include information both
      from the terminal and by the proxy?

    - James: What do you do in the case of conflicts?

    - Unknown 1: Use what the UA provides.

    - James: Service providers don't want to trust that.

  - Topic: Dean doesn't like using OPTIONS to fetch UAC's location.

    - Several: Dean isn't the only one.

    - Consensus: This should be a SUB/NOT mechanism. (e.g. UA
      subscribes to own presence).

    - Open Issue: Which event package should be used? (Presence,
      new one defined in SIPPING, or new one defined somewhere else)

    - Several Speakers: Presence is done, filtering has had a lot
      of work done on it. It makes no sense to do this work all over
      again with the same end result.

    - Others: It may be too heavy to expect people to deploy presence
      just for emergency services. It's a bit complicated.

    - Rohan: I will put together an email discussing why presence
      isn't the right way to do this.

    - Proposal: Take this text out of the draft, put it elsewhere,
      and progress it separately.

    - Will be taken to the list. If we can't close quickly, we will
      split the draft.

Topic: Response Identity

Discussion led by Feng Cao
Slides presented

  - HGS: This appears to be reinventing TLS using HTTP-digest-like
    authentication.

  - JDR: We need a way to figure out a way to verify that the
    connected party is who they say they are.

  - Jon Peterson: Don't conflate the party or parties who respond
    with the party to whom you are connected.

  - General discussion: It's not clear what this document solves
    that TLS does not. The response authentication stuff simply
    doesn't make sense, given that SIP mandates TLS.

Topic: SIP SAML

Discussion led by Jon Peterson
Slides presented

  - Several people spoke up in support of role-based authorization.
    This was followed by a dogpile of varying use cases.

  - HGS: The barrier to entry seems to be high -- doing the work
    to put in the first installation is wasted, since there's no
    one to talk to.

  - High level issue: should we split framework from mechanism?

    - Cullen: We don't want to freeze the framework before we start
      on the mechanism.


  - Poll for consensus: Should we take this on as a working group
    item?

    - Cullen: Where does this go in our schedule?

    - Result: Rough consensus to add as a working group item.

Topic: Answer and Alert Mode Extensions

Discussion led by Dean Willis
Slides presented

  - Paul Kyzivat: The emphasis thing doesn't seem to make much sense.
    Semantics are unclear.

  - Dave Oran: I'm not confused. I'm sure it's bogus. You can use
    an "Alert-Info" header that specifies a different mode of
    ringing operation. You can use "Priority" if you want to emphasize
    a call.

  - Andrew Allen: We're not sure how priority is getting used.

  - JDR: This presumes a discrete set of policies, which need to be
    well-defined at the UAS -- otherwise, this is pretty useless.

  - Francois Audet: We definitely need to have better defined
    semantics for this, including examples.

  - JDR: Yes, this does need to have applicablity outside the OMA.
    Also, note that this benefits from role-based authorization.

  - Paul Kyzivat: In the general case, this has significant ability
    to be abused. Loopback and push-to-talk don't allow covert listening.
    Once it is applied to two-way calls, you need to have much stronger
    security considerations.

  - Several others spoke in favor of having stronger requirements
    around security and policy.

  - JDR: There are two seperable issues here. First, the policy needs
    to be clearer, so that we understand how the override and emphasis
    stuff works precisely. As a separate issue, we need to be able to
    determine how users are authorized to request these kinds of
    overrides.

  - Comment: OMA has an authorization model around this mechanism that it may be possible to
    leverage.

[Meeting Ends]

---------------------------------------------------------------------------
Key:
  RjS = Robert Sparks
  JDR = Jonathan Rosenberg
  HGS = Henning Schulzrinne
--===============0140748007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0140748007==--