Question on do not disturb indication

"Basic=20 Forwarding" Rule in 4.3.3.1.3 ie:

Also:

"In the case of a Request that is = being
forwarded, the=20 index is determined by adding another level of
indexing since the=20 depth/length of the branch is increasing."

Reworking the index is important because the = tree=20 structure

has to be = maintained.

I can think of two ways of dealing = with=20 this:

1. The Application is an acknowledged entity = in the=20 rfc.

Treat UAC/UAS not as an endpoint but as a=20 component

that may be passed a list of History-Info = headers by the=20 Application.

The reworking of the index can either be = Application=20 reposibility

or UAC responsibility. =

We have two = options:

1.1) UAC is probably where it should=20 reworked

as this fits with = the proxy=20 reqts of forwarding..and we are doing

forwarding in a = larger=20 sense.

1.2) Let Application rework the index and = pass it down to=20 the UAC.

Also, the headers can be passed into the UAS = from the=20 Application to

address the voice-mail use-case identified=20 above.

In either case, I suggest we add some = language to clarify=20 this. Because

currently the UAC is instructed to add a = History-Info=20 header with an

index value of "1". And the UAS is asked to = simply copy=20 back the H-I

headers from the request to response. I find = this=20 insufficient.

2. Specify a model in which B2BUA plays a = role and define=20 responsibilities.

What do you folks = think?

Thanks,

Ganesh

------_=_NextPart_001_01C6BD37.4FBFB3A2-- --===============2052488190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============2052488190==-- From sipping-bounces@ietf.org Fri Aug 11 11:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZ5O-0005pC-Hg; Fri, 11 Aug 2006 11:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZ5N-0005p7-Iz for sipping@ietf.org; Fri, 11 Aug 2006 11:38:09 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBZ5M-0006nd-7j for sipping@ietf.org; Fri, 11 Aug 2006 11:38:09 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7BFc0R22348; Fri, 11 Aug 2006 11:38:00 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Clarification on RFC 3959 - early media Date: Fri, 11 Aug 2006 10:37:59 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710FDDECC4@zrc2hxm2.corp.nortel.com> In-Reply-To: <44DBB324.3080307@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Clarification on RFC 3959 - early media Thread-Index: Aca8zGXHzO90gODhTDuYZdU+w3bazwAj1r4A From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Pre-routing, pre-presentation, etc. are monikers that I came up with to try to explain at which points early media can arise during processing. The idea here is that all early media is not equal, some early media is more evil than others. I've seen all of the techniques mentioned in the draft in the wild. Many of them are undetectable to the originating UA. Regards, Brian=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, August 10, 2006 5:29 PM > To: Stucker, Brian (RICH1:B620) > Cc: Kapil Nayar; sipping@ietf.org > Subject: Re: [Sipping] Clarification on RFC 3959 - early media >=20 > Brian, >=20 > I just got around to looking at this. I need to think about=20 > the techniques you propose at the end. But I am having=20 > trouble getting past the first half of the document. I have=20 > never heard mention of the things you describe as Pre-routing=20 > early media or Pre-presentation early media.=20 > Nor have I heard of the Proxy-side coping mechanisms you describe. >=20 > These are all positively *obscene*. You suggest that these=20 > are common.=20 > Is that really true??? (Maybe you live in a particularly dangerous > neighborhood.) >=20 > Tell me it isn't true! Please! >=20 > Paul >=20 > Brian Stucker wrote: > > You may wish to take a look at the following: > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media- > > co > > ping-01.txt >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 11 14:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbhH-0000sy-SH; Fri, 11 Aug 2006 14:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbhF-0000s6-Qx for sipping@ietf.org; Fri, 11 Aug 2006 14:25:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbhE-0003L3-GM for sipping@ietf.org; Fri, 11 Aug 2006 14:25:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 14:25:24 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96279103:sNHT30775270" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BIPOdI027634; Fri, 11 Aug 2006 14:25:24 -0400 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 k7BIPOe2006872; Fri, 11 Aug 2006 14:25:24 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:25:24 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:25:23 -0400 Message-ID: <44DCCB93.6090802@cisco.com> Date: Fri, 11 Aug 2006 14:25:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sipping] Clarification on RFC 3959 - early media References: <6FC4416DDE56C44DA0AEE67BC7CA43710FDDECC4@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710FDDECC4@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2006 18:25:23.0548 (UTC) FILETIME=[828809C0:01C6BD73] DKIM-Signature: a=rsa-sha1; q=dns; l=1857; t=1155320724; x=1156184724; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sipping]=20Clarification=20on=20RFC=203959=20-=20early=20media |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3D/ddYJqkrd9IxqsyFuDtUIsYBJE0=3D; b=aUb+gJ50w8BMnhYIGsgbja3dkxEm4ZsAf3eJonMfi9t2+y6tAdg8sRn1pgU101+3DVoV06ds xXmARjUS5czS795MdfDRx25SqUvcpaY5HCjyuvkUw0L3KRgsoYlbwbYq; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Brian Stucker wrote: > Pre-routing, pre-presentation, etc. are monikers that I came up with to > try to explain at which points early media can arise during processing. It isn't the names that bother me. (It's obvious you coined those.) It's the behaviors described that are disturbing. > The idea here is that all early media is not equal, some early media is > more evil than others. > > I've seen all of the techniques mentioned in the draft in the wild. Time to declare open season! (Kill those nasty beasts before they hurt the children.) (I wouldn't be killing any of my kin would I?) > Many of them are undetectable to the originating UA. Except that things work funny, or sometimes don't work. Paul > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, August 10, 2006 5:29 PM >> To: Stucker, Brian (RICH1:B620) >> Cc: Kapil Nayar; sipping@ietf.org >> Subject: Re: [Sipping] Clarification on RFC 3959 - early media >> >> Brian, >> >> I just got around to looking at this. I need to think about >> the techniques you propose at the end. But I am having >> trouble getting past the first half of the document. I have >> never heard mention of the things you describe as Pre-routing >> early media or Pre-presentation early media. >> Nor have I heard of the Proxy-side coping mechanisms you describe. >> >> These are all positively *obscene*. You suggest that these >> are common. >> Is that really true??? (Maybe you live in a particularly dangerous >> neighborhood.) >> >> Tell me it isn't true! Please! >> >> Paul >> >> Brian Stucker wrote: >>> You may wish to take a look at the following: >>> >>> >> http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media- >>> co >>> ping-01.txt > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 11 14:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc0t-00087P-Lk; Fri, 11 Aug 2006 14:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc0s-000865-G5 for sipping@ietf.org; Fri, 11 Aug 2006 14:45:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbpj-0004Op-D3 for sipping@ietf.org; Fri, 11 Aug 2006 14:34:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 14:34:11 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96280867:sNHT41991036" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BIYBAQ032329; Fri, 11 Aug 2006 14:34:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7BIY6eA009475; Fri, 11 Aug 2006 14:34:10 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:34:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header) Date: Fri, 11 Aug 2006 14:31:26 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6020441C8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header) Thread-Index: Aca9cqWc4cyu9FhXQQiUzGtu4vxtIgAALHZg From: "Ganesh Jayadevan $gjayadev$" To: "Dean Willis" X-OriginalArrivalTime: 11 Aug 2006 18:34:10.0108 (UTC) FILETIME=[BC62B7C0:01C6BD74] DKIM-Signature: a=rsa-sha1; q=dns; l=3095; t=1155321251; x=1156185251; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gjayadev@cisco.com; z=From:=22Ganesh=20Jayadevan=20$gjayadev$=22=20 |Subject:RE=3A=20[Sipping]=20b2bua/call=20control=20aspect=20for=20rfc4244=20(His tory-Info=20header) |To:=22Dean=20Willis=22=20; X=v=3Dcisco.com=3B=20h=3D1cLGn2DD5TC9ybLvkwjBKeHi0Jo=3D; b=VZW06tC/5aD98cPnbxo4G/CuKb6lLV/EPZvKb9T91cJK9VWIsn1o61UImZBAffac9i8sxRel tq5rjWfMHvW+F9f+4r2YtaUPXezM/Rjpfn5dxZCAms06UGg67uTBAwy1; Authentication-Results: rtp-dkim-2.cisco.com; header.From=gjayadev@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "Cullen Jennings $fluffy$" , "Sudipto Mukherjee $sudiptom$" , Jon.Peterson@NeuStar.biz, mark@digitalfountain.com, mary.barnes@nortel.com, "Mohammad Al-Taraireh $maltarai$" , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi Dean, I see what you are saying about B2BUAs in general. I also proposed another alternative of an Application being able to pass a HI tuple to a UAC (or UAS) that can forward (or backward) propogate. This interface and function can be defined in the limited context of this rfc. Without this call control b2buas will implement rfc4244 in=20 an undefined way leading to inconsistent infomration models and the purpose of the rfc will be defeated. thanks, Ganesh -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, August 11, 2006 2:19 PM To: Ganesh Jayadevan (gjayadev) Cc: sipping@ietf.org; Cullen Jennings (fluffy); Sudipto Mukherjee (sudiptom); Jon.Peterson@NeuStar.biz; mark@digitalfountain.com; mary.barnes@nortel.com; Mohammad Al-Taraireh (maltarai) Subject: Re: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header) On Aug 11, 2006, at 6:11 AM, Ganesh Jayadevan ((gjayadev)) wrote: > Folks, > > rfc4244 (History-Info) addresses what the UAC, UAS, and the proxy must > do with the History-Info header. > True to the tradition of SIP, a b2bua is not given any special status=20 > but is seen as a concat of a UAS-UAC. > > I am wondering if this leaves a gap and hinders achieving the=20 > objectives of the rfc. > The problem is that defining what a B2BUA does, in general, seems to be an intractable problem. You have one specific sub-model of B2BUA that is fairly proxy-like in its behavior in mind. However, another model of B2BUA serves as an anonymizer. It's entire role in life is to keep one side from knowing anything about the "real UA" on the other side of the B2BUA. This probably includes disclosing that there's even a B2BUA in the loop -- the "other side" =20 should see the anonymizing B2BUA as the terminal node. So by this logic, we should specify that B2BUAs do not propagate History-Info at all. Now, clearly that's also wrong for the general case. There may not even be a "general case" for B2BUA behavior. So we end up with a situation where each application of a B2BUA requires an analysis of the appropriate transparency behavior for that specific application. Given that there are arguably a large number (if not infinite set) of B2BUA applications, this means that a thorough description of the behavior of B2BUAs with respect to any specific extension is sufficiently difficult as to be infeasible. Contrast this with the bounded problem space of describing the extensions behavior wrt to UAC, UAS, proxy (possibly stateless, transaction stateful, and dialog stateful) and registrar. Now it may be that there are a finite set of design patterns for B2BUAs that can be cleanly defined, each of which has an obvious set of transparency requirements. I'm certainly not convinced that this set is small or the problem tractable, but if you'd like to try and establish an appropriate taxonomy along with discussion of the transparency behavior of each pattern, I'll be happy to read your results. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 11 14:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcBb-0000o6-St; Fri, 11 Aug 2006 14:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcBa-0000nF-K5 for sipping@ietf.org; Fri, 11 Aug 2006 14:56:46 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBcBY-0006XZ-8m for sipping@ietf.org; Fri, 11 Aug 2006 14:56:46 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7BIucV00985; Fri, 11 Aug 2006 14:56:38 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Clarification on RFC 3959 - early media Date: Fri, 11 Aug 2006 13:56:37 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710FDDF059@zrc2hxm2.corp.nortel.com> In-Reply-To: <44DCCB93.6090802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Clarification on RFC 3959 - early media Thread-Index: Aca9c4iqU4Jn7U/2RlONfvuWa+HJ/QAA8PXA From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, August 11, 2006 1:25 PM > To: Stucker, Brian (RICH1:B620) > Cc: Kapil Nayar; sipping@ietf.org > Subject: Re: [Sipping] Clarification on RFC 3959 - early media >=20 >=20 >=20 > Brian Stucker wrote: > > Pre-routing, pre-presentation, etc. are monikers that I=20 > came up with=20 > > to try to explain at which points early media can arise=20 > during processing. >=20 > It isn't the names that bother me. (It's obvious you coined=20 > those.) It's the behaviors described that are disturbing. >=20 > > The idea here is that all early media is not equal, some=20 > early media=20 > > is more evil than others. > >=20 > > I've seen all of the techniques mentioned in the draft in the wild. >=20 > Time to declare open season! > (Kill those nasty beasts before they hurt the children.) >=20 > (I wouldn't be killing any of my kin would I?) :) I'm not interested in pointing fingers, I just want to get the problem under control. To others who may have experience with early media, and know of a mechanism that they've seen used that is not currently documented in the draft, please email me so I can include it in the discussion. >=20 > > Many of them are undetectable to the originating UA. >=20 > Except that things work funny, or sometimes don't work. True, but you have to keep in mind that many of the things that work funny or don't work with early media are things that happen on behalf of the terminator. How is the originator going to tell that the early media the network is trying to provide from a PSTN gateway or some service for the terminator is missing? >=20 > Paul >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, August 10, 2006 5:29 PM > >> To: Stucker, Brian (RICH1:B620) > >> Cc: Kapil Nayar; sipping@ietf.org > >> Subject: Re: [Sipping] Clarification on RFC 3959 - early media > >> > >> Brian, > >> > >> I just got around to looking at this. I need to think about the=20 > >> techniques you propose at the end. But I am having trouble getting=20 > >> past the first half of the document. I have never heard mention of=20 > >> the things you describe as Pre-routing early media or=20 > >> Pre-presentation early media. > >> Nor have I heard of the Proxy-side coping mechanisms you describe. > >> > >> These are all positively *obscene*. You suggest that these are=20 > >> common. > >> Is that really true??? (Maybe you live in a particularly dangerous > >> neighborhood.) > >> > >> Tell me it isn't true! Please! > >> > >> Paul > >> > >> Brian Stucker wrote: > >>> You may wish to take a look at the following: > >>> > >>> > >>=20 > http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media > >> - > >>> co > >>> ping-01.txt > >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 11 14:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcCP-0002Je-QQ; Fri, 11 Aug 2006 14:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcCN-0002JU-R1 for sipping@ietf.org; Fri, 11 Aug 2006 14:57:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBcCM-0006a6-G7 for sipping@ietf.org; Fri, 11 Aug 2006 14:57:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 14:57:34 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96284342:sNHT1933423756" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BIvWML009801; Fri, 11 Aug 2006 14:57:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7BIvWe2015504; Fri, 11 Aug 2006 14:57:32 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:57:31 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 14:57:31 -0400 Message-ID: <44DCD31A.1070906@cisco.com> Date: Fri, 11 Aug 2006 14:57:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Ganesh Jayadevan (gjayadev)" Subject: Re: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header) References: <15B86BC7352F864BB53A47B540C089B6020441C8@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <15B86BC7352F864BB53A47B540C089B6020441C8@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2006 18:57:31.0435 (UTC) FILETIME=[FFA43FB0:01C6BD77] DKIM-Signature: a=rsa-sha1; q=dns; l=3786; t=1155322652; x=1156186652; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sipping]=20b2bua/call=20control=20aspect=20for=20rfc4244=20(His tory-Info=0A=20header) |To:=22Ganesh=20Jayadevan=20(gjayadev)=22=20; X=v=3Dcisco.com=3B=20h=3DDkXAXVd5uBATvEKBBNaAn9uAFoo=3D; b=vEhf/lQVz+MNSHl98J7QF90K28Tbtz53GnTE6uBV715h9A2damvdwgOSx/XIfq00VmhYTlc8 Jgp1JVDYUVCYpvzJAVJpCc83uNj065KqbOW2iaeI/fg7eBsai/euDn3V; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Cullen Jennings $fluffy$" , "Sudipto Mukherjee $sudiptom$" , Jon.Peterson@NeuStar.biz, mark@digitalfountain.com, "Mohammad Al-Taraireh $maltarai$" , mary.barnes@nortel.com, Dean Willis , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Ganesh Jayadevan (gjayadev) wrote: > Hi Dean, > > I see what you are saying about B2BUAs in general. > > I also proposed another alternative of an Application > being able to pass a HI tuple to a UAC (or UAS) that can forward > (or backward) propogate. This interface and function can be > defined in the limited context of this rfc. Yes, I can see how it would make sense to permit the application to do this. I agree with dean on the general intractability of specifying anything useful in general for a B2BUA. Paul > Without this call control b2buas will implement rfc4244 in > an undefined way leading to inconsistent infomration models > and the purpose of the rfc will be defeated. > > thanks, > Ganesh > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, August 11, 2006 2:19 PM > To: Ganesh Jayadevan (gjayadev) > Cc: sipping@ietf.org; Cullen Jennings (fluffy); Sudipto Mukherjee > (sudiptom); Jon.Peterson@NeuStar.biz; mark@digitalfountain.com; > mary.barnes@nortel.com; Mohammad Al-Taraireh (maltarai) > Subject: Re: [Sipping] b2bua/call control aspect for rfc4244 > (History-Info header) > > > On Aug 11, 2006, at 6:11 AM, Ganesh Jayadevan ((gjayadev)) wrote: > >> Folks, >> >> rfc4244 (History-Info) addresses what the UAC, UAS, and the proxy must > >> do with the History-Info header. >> True to the tradition of SIP, a b2bua is not given any special status >> but is seen as a concat of a UAS-UAC. >> >> I am wondering if this leaves a gap and hinders achieving the >> objectives of the rfc. >> > > The problem is that defining what a B2BUA does, in general, seems to be > an intractable problem. > > You have one specific sub-model of B2BUA that is fairly proxy-like in > its behavior in mind. > > However, another model of B2BUA serves as an anonymizer. It's entire > role in life is to keep one side from knowing anything about the "real > UA" on the other side of the B2BUA. This probably includes disclosing > that there's even a B2BUA in the loop -- the "other side" > should see the anonymizing B2BUA as the terminal node. > > So by this logic, we should specify that B2BUAs do not propagate > History-Info at all. > > Now, clearly that's also wrong for the general case. There may not even > be a "general case" for B2BUA behavior. > > So we end up with a situation where each application of a B2BUA requires > an analysis of the appropriate transparency behavior for that specific > application. > > Given that there are arguably a large number (if not infinite set) of > B2BUA applications, this means that a thorough description of the > behavior of B2BUAs with respect to any specific extension is > sufficiently difficult as to be infeasible. > > Contrast this with the bounded problem space of describing the > extensions behavior wrt to UAC, UAS, proxy (possibly stateless, > transaction stateful, and dialog stateful) and registrar. > > Now it may be that there are a finite set of design patterns for B2BUAs > that can be cleanly defined, each of which has an obvious set of > transparency requirements. I'm certainly not convinced that this set is > small or the problem tractable, but if you'd like to try and establish > an appropriate taxonomy along with discussion of the transparency > behavior of each pattern, I'll be happy to read your results. > > -- > Dean > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 11 18:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfyU-0004fF-0m; Fri, 11 Aug 2006 18:59:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfyT-0004ea-2g for sipping@ietf.org; Fri, 11 Aug 2006 18:59:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBblX-0003hG-3Y for sipping@ietf.org; Fri, 11 Aug 2006 14:29:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBbb8-0002e1-8I for sipping@ietf.org; Fri, 11 Aug 2006 14:19:06 -0400 Received: from [64.101.149.196] (dwillis-mb.cisco.com [64.101.149.196]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7BIL6OG010734 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 11 Aug 2006 13:21:07 -0500 In-Reply-To: <15B86BC7352F864BB53A47B540C089B602044010@xmb-rtp-20b.amer.cisco.com> References: <15B86BC7352F864BB53A47B540C089B602044010@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1840314F-CC26-4CA7-ADD8-B9B14DE4CF28@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] b2bua/call control aspect for rfc4244 (History-Info header) Date: Fri, 11 Aug 2006 13:18:49 -0500 To: Ganesh Jayadevan ((gjayadev)) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Cullen Jennings $fluffy$" , "Sudipto Mukherjee $sudiptom$" , Jon.Peterson@NeuStar.biz, mark@digitalfountain.com, mary.barnes@nortel.com, "Mohammad Al-Taraireh $maltarai$" , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org On Aug 11, 2006, at 6:11 AM, Ganesh Jayadevan ((gjayadev)) wrote: > Folks, > > rfc4244 (History-Info) addresses what the UAC, UAS, and > the proxy must do with the History-Info header. > True to the tradition of SIP, a b2bua is not given any special > status but is seen as a concat of a UAS-UAC. > > I am wondering if this leaves a gap and hinders achieving the > objectives of the rfc. > The problem is that defining what a B2BUA does, in general, seems to be an intractable problem. You have one specific sub-model of B2BUA that is fairly proxy-like in its behavior in mind. However, another model of B2BUA serves as an anonymizer. It's entire role in life is to keep one side from knowing anything about the "real UA" on the other side of the B2BUA. This probably includes disclosing that there's even a B2BUA in the loop -- the "other side" should see the anonymizing B2BUA as the terminal node. So by this logic, we should specify that B2BUAs do not propagate History-Info at all. Now, clearly that's also wrong for the general case. There may not even be a "general case" for B2BUA behavior. So we end up with a situation where each application of a B2BUA requires an analysis of the appropriate transparency behavior for that specific application. Given that there are arguably a large number (if not infinite set) of B2BUA applications, this means that a thorough description of the behavior of B2BUAs with respect to any specific extension is sufficiently difficult as to be infeasible. Contrast this with the bounded problem space of describing the extensions behavior wrt to UAC, UAS, proxy (possibly stateless, transaction stateful, and dialog stateful) and registrar. Now it may be that there are a finite set of design patterns for B2BUAs that can be cleanly defined, each of which has an obvious set of transparency requirements. I'm certainly not convinced that this set is small or the problem tractable, but if you'd like to try and establish an appropriate taxonomy along with discussion of the transparency behavior of each pattern, I'll be happy to read your results. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Aug 14 05:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYdf-0004QV-Ic; Mon, 14 Aug 2006 05:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCYdd-0004QQ-R8 for sipping@ietf.org; Mon, 14 Aug 2006 05:21:37 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCYdc-0003m3-Hk for sipping@ietf.org; Mon, 14 Aug 2006 05:21:37 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7E9LaHT029743 for ; Mon, 14 Aug 2006 05:21:36 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 05:21:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Aug 2006 14:51:32 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5C26@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bug in rfc-3261 Thread-Index: Aca/gwfiixc33VgoReSnMHo4UQN/Ig== From: "B, Nataraju" To: X-OriginalArrivalTime: 14 Aug 2006 09:21:36.0259 (UTC) FILETIME=[0A641530:01C6BF83] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Sipping] bug in rfc-3261 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040513359==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1040513359== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BF83.08172448" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BF83.08172448 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Header field where proxy ACK BYE CAN INV OPT REG WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Contact 3xx d - o - o o o Why proxy column is mentioned as "ar" for WWW-Authenticate in 401/407. It should have been mentioned as "r" only. In no case proxy would add the WWW-Authenticate header for responses 401/407 ?. Does the proxy aggregation considered for this case ? Why proxy is allowed to "delete only" for contact in 3xx response? Even it should be allowed to read the contacts in 3xx replies. BTW, in which scenario it can delete a contact in 3xx response. This option should have been either "dr" or "r" only depending on answer to my previous question.=20 Thanks, Nataraju A B Sonus Networks Ind Pvt Ltd ------_=_NextPart_001_01C6BF83.08172448 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable bug in rfc-3261

Header = field &n= bsp; where proxy ACK BYE CAN = INV OPT REG

WWW-Authenticate &nbs= p; 401 = ar - m - = m m m

WWW-Authenticate &nbs= p; 407 = ar - o - = o o o

Contact &= nbsp; 3xx d - = o - o o = o

Why proxy column is mentioned as “ar” = for WWW-Authenticate in = 401/407. It should have been mentioned as “r” only. In no = case proxy would add the WWW-Authenticate header for responses 401/407 = ?. Does the proxy aggregation considered for this = case ?

Why proxy is allowed to “delete only” = for contact in 3xx response? Even it should be allowed to read the = contacts in 3xx replies. BTW, in which scenario it can delete a contact in 3xx response. = This option should have = been = either “dr” or “r” only depending on answer to = my previous question.

Thanks,

Nataraju A B

Sonus Networks Ind Pvt Ltd

------_=_NextPart_001_01C6BF83.08172448-- --===============1040513359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1040513359==-- From sipping-bounces@ietf.org Mon Aug 14 05:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZ34-0006FW-4A; Mon, 14 Aug 2006 05:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZ32-0006Ad-Da for sipping@ietf.org; Mon, 14 Aug 2006 05:47:52 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZ2z-00061M-IF for sipping@ietf.org; Mon, 14 Aug 2006 05:47:52 -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 <0J3Z006R6FZOE9@szxga02-in.huawei.com> for sipping@ietf.org; Mon, 14 Aug 2006 18:04:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3Z00KUOFZOS6@szxga02-in.huawei.com> for sipping@ietf.org; Mon, 14 Aug 2006 18:04:36 +0800 (CST) Received: from k19120I ([10.70.145.109]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3Z00DTJFQDSY@szxml04-in.huawei.com> for sipping@ietf.org; Mon, 14 Aug 2006 17:59:01 +0800 (CST) Date: Mon, 14 Aug 2006 17:47:02 +0800 From: Manjunath Warad Subject: RE: [Sipping] bug in rfc-3261 In-reply-to: <70798CF421F00F4DA018059E5B7EEB8C7A5C26@sonusinmail01.sonusnet.com> To: "'B, Nataraju'" , sipping@ietf.org Message-id: <000b01c6bf86$9825e120$6d91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317105639==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1317105639== Content-type: multipart/alternative; boundary="Boundary_(ID_Kh+9gaVQDmUDIkVYmKUoOA)" This is a multi-part message in MIME format. --Boundary_(ID_Kh+9gaVQDmUDIkVYmKUoOA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Please see inline... Rgds, Manju -----Original Message----- From: B, Nataraju [mailto:bnataraju@sonusnet.com] Sent: Monday, August 14, 2006 5:22 PM To: sipping@ietf.org Subject: [Sipping] bug in rfc-3261 Header field where proxy ACK BYE CAN INV OPT REG WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Contact 3xx d - o - o o o Why proxy column is mentioned as "ar" for WWW-Authenticate in 401/407. It should have been mentioned as "r" only. In no case proxy would add the WWW-Authenticate header for responses 401/407 ?. Does the proxy aggregation considered for this case ? Yes you are right! Proxy aggregation is considered here. Why proxy is allowed to "delete only" for contact in 3xx response? Even it should be allowed to read the contacts in 3xx replies. BTW, in which scenario it can delete a contact in 3xx response. This option should have been either "dr" or "r" only depending on answer to my previous question. Here again, proxy can remove the contact, for which it has already tried, so that upstream proxies need not try on those contacts again. This technique is used when proxy chose 3xx as best response to be forwarded for upstream proxies. So, I think "adr" need to be used here as this header can be aggregated to form the final 3xx response if more than 1 is present. Please let me know, if my interpretation is wrong. Thanks, Nataraju A B Sonus Networks Ind Pvt Ltd --Boundary_(ID_Kh+9gaVQDmUDIkVYmKUoOA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message

Hi,

Please see inline...

Rgds,

Manju

-----Original Message-----
From: B, Nataraju [mailto:bnataraju@sonusnet.com]
Sent: Monday, August 14, 2006 5:22 PM
To: sipping@ietf.org
Subject: [Sipping] bug in rfc-3261

Header field              where       proxy ACK BYE CAN INV OPT REG

WWW-Authenticate           401         ar    -   m   -   m   m   m

WWW-Authenticate           407         ar    -   o   -   o   o   o

Contact                     3xx         d    -   o   -   o   o   o

Why proxy column is mentioned as “ar” for WWW-Authenticate in 401/407. It should have been mentioned as “r” only. In no case proxy would add the WWW-Authenticate header for responses 401/407 ?. Does the proxy aggregation considered for this case ?

Yes you are right! Proxy aggregation is considered here.

Why proxy is allowed to “delete only” for contact in 3xx response? Even it should be allowed to read the contacts in 3xx replies. BTW, in which scenario it can delete a contact in 3xx response. This option should have been either “dr” or “r” only depending on answer to my previous question.

Here again, proxy can remove the contact, for which it has already tried, so that upstream proxies need not try on those contacts again. This technique is used when proxy chose 3xx as best response to be forwarded for upstream proxies. So, I think "adr" need to be used here as this header can be aggregated to form the final 3xx response if more than 1 is present.

Please let me know, if my interpretation is wrong.

Thanks,

Nataraju A B

Sonus Networks Ind Pvt Ltd

--Boundary_(ID_Kh+9gaVQDmUDIkVYmKUoOA)-- --===============1317105639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1317105639==-- From sipping-bounces@ietf.org Tue Aug 15 08:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyGB-0007me-E7; Tue, 15 Aug 2006 08:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyG9-0007m1-Im for Sipping@ietf.org; Tue, 15 Aug 2006 08:43:05 -0400 Received: from web8704.mail.in.yahoo.com ([203.84.221.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCyG7-0007XS-Pn for Sipping@ietf.org; Tue, 15 Aug 2006 08:43:05 -0400 Received: (qmail 63704 invoked by uid 60001); 15 Aug 2006 12:43:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2CxlJs8/5Eb8AdVWhKSPGOjfK1B+pEhavVlGoPt9EhwMdlfzC8uuGqFKJAzXbNKvDy7ab9qpHmuWUTX1/6qNSrk5VKG72+lMXZ4qQ10jJ2yVMVDAslvh7g5qEMEC0+oHtTt3q8kR/jZg7Ow3pPfOpyHo6OutD66ju4fRCAxHvzE= ; Message-ID: <20060815124301.63702.qmail@web8704.mail.in.yahoo.com> Received: from [220.224.36.49] by web8704.mail.in.yahoo.com via HTTP; Tue, 15 Aug 2006 13:43:01 BST Date: Tue, 15 Aug 2006 13:43:01 +0100 (BST) From: AMIT KUNDRA To: Sipping@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Sipping] Example of interworking between a Wireline Softswitch & a CDMA Softswitch X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0003355693==" Errors-To: sipping-bounces@ietf.org --===============0003355693== Content-Type: multipart/alternative; boundary="0-341132688-1155645781=:62485" Content-Transfer-Encoding: 8bit --0-341132688-1155645781=:62485 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi , I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries: 1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS& while SIP is part of VoIP ? 2. If different then what is this talk about integarting BICC into SIP ? 3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ? 4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ? Pls respond urgently --------------------------------- Here's a new way to find what you're looking for - Yahoo! Answers Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-341132688-1155645781=:62485 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi ,

I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries:

1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS& while SIP is part of VoIP ?

2. If different then what is this talk about integarting BICC into SIP ?

3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ?

4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ?

Pls respond urgently

Here's a new way to find what you're looking for - Yahoo! Answers
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-341132688-1155645781=:62485-- --===============0003355693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0003355693==-- From sipping-bounces@ietf.org Tue Aug 15 09:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyXR-0004QM-Ev; Tue, 15 Aug 2006 09:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyXP-0004Oo-DE for sipping@ietf.org; Tue, 15 Aug 2006 09:00:55 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyRq-0000Mj-MC for sipping@ietf.org; Tue, 15 Aug 2006 08:55:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2006 15:55:07 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03CB5A9C@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sipping-session-policy-framework-01 Thread-Index: AcbAagjl7qVpGySTTsWf2FbXn+ouzw== From: "Even, Roni" To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: volkerh@bell-labs.com, Mary Barnes , Gonzalo.Camarillo@ericsson.com Subject: [Sipping] Review of draft-ietf-sipping-session-policy-framework-01 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Draft: draft-ietf-sipping-session-policy-framework-01 Reviewer: Roni Even Review Date: 15/8/06 Review Deadline: 25/8/06 Status: Initial review=20 Summary: This draft is basically ready for publication, but has nits = that should be fixed before publication. The document looks good and being asked a lot about bandwidth management = in SIP I find it very important. I have a question: In the session specific policy call flows the UA that send the invite = insert a header field (Policy-Id) indicating to the proxy that it = contacted the Policy server. How does the proxy on the other side know = that the UA contacted the policy server when it gets the 200 with the = answer. A nit Introduction section - says "In contrast to other methods for inserting = a media intermediary, the use of session policies does not require the = inspection or modification of SIP message bodies". Looking at section = 4.3.1 for example shows that at least the two proxies PA and PB will = change the SIP message. I also assume that policy enforcement will = require inspection of the messages. Roni Even ******************************************************************* Roni Even Polycom NSD =A0 Tel: +972-3-9251200 Mobile: +972-54-5481099 Fax: +972-3-9211571 email: roni.even@polycom.co.il _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Aug 15 09:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyg3-0007bD-2c; Tue, 15 Aug 2006 09:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyg1-0007b6-GJ for sipping@ietf.org; Tue, 15 Aug 2006 09:09:49 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyg0-0001UG-3I for sipping@ietf.org; Tue, 15 Aug 2006 09:09:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2006 16:09:45 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03CB5AA2@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sipping-policy-package-01 Thread-Index: AcbAagjl7qVpGySTTsWf2FbXn+ouzw== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: volkerh@bell-labs.com, Mary Barnes , Gonzalo.Camarillo@ericsson.com Subject: [Sipping] Review of draft-ietf-sipping-policy-package-01 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Draft: draft-ietf-sipping-policy-package-01 Reviewer: Roni Even Review Date: 15/8/06 Review Deadline: 25/8/06 Status: Initial review=20 Summary: This draft is on the right track but has open issues, described = in the review. In section 3.3 on the open issue, I think that XML is good direction, = using it will enable to define media policy not in terms of SDP = architecture. Still there is a need to be able to map from SDP to XML. = The mapping should allow specifying per session and per media policy. In section 3.6 on the open issue, I think that there should be a basic = set at least the media and bandwidth. The subscriber may update this = information, for example, if the peer sends a re-invite. This can be = very useful for bandwidth management and even provide a tool for = resource scheduling application that will work also with the non session = specific policy.=20 In section 3.9 why SHOULD is used and not SHALL, if a session policy is = in place and a UA subscribed to the policy server then it must work = according to the policy. Roni Even ******************************************************************* Roni Even Polycom NSD =A0 Tel: +972-3-9251200 Mobile: +972-54-5481099 Fax: +972-3-9211571 email: roni.even@polycom.co.il _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Aug 15 09:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyij-000053-Jw; Tue, 15 Aug 2006 09:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyih-00004y-VM for sipping@ietf.org; Tue, 15 Aug 2006 09:12:35 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyig-0001iM-Kt for sipping@ietf.org; Tue, 15 Aug 2006 09:12:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2006 16:12:32 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03CB5AA3@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sipping-media-policy-dataset-01 Thread-Index: AcbAagjl7qVpGySTTsWf2FbXn+ouzw== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: volkerh@bell-labs.com, Mary Barnes , Gonzalo.Camarillo@ericsson.com Subject: [Sipping] Review of draft-ietf-sipping-media-policy-dataset-01 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Draft: draft-ietf-sipping-media-policy-dataset-01 Reviewer: Roni Even Review Date: 15/8/06 Review Deadline: 25/8/06 Status: Initial review=20 Summary: This draft is basically ready for publication, but has nits = that should be fixed before publication. One nit The draft has media-type both as attribute and element maybe rename one = of them for clarity. Roni Even ******************************************************************* Roni Even Polycom NSD =A0 Tel: +972-3-9251200 Mobile: +972-54-5481099 Fax: +972-3-9211571 email: roni.even@polycom.co.il _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Aug 15 11:49:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD18z-0002Ki-7H; Tue, 15 Aug 2006 11:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD18x-0002KX-W2 for Sipping@ietf.org; Tue, 15 Aug 2006 11:47:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD18w-0003wa-D9 for Sipping@ietf.org; Tue, 15 Aug 2006 11:47:51 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2006 11:47:49 -0400 X-IronPort-AV: i="4.08,128,1154923200"; d="scan'208,217"; a="96919498:sNHT3717105090" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FFlmZM021960; Tue, 15 Aug 2006 11:47:48 -0400 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 k7FFlmKH023767; Tue, 15 Aug 2006 11:47:48 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 11:47:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Example of interworking between a Wireline Softswitch & aCDMA Softswitch Date: Tue, 15 Aug 2006 11:47:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301CE9D55@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Example of interworking between a Wireline Softswitch & aCDMA Softswitch Thread-Index: AcbAaHsTb5aV4NkTRRut9pTTGgWsuwAGXz9g From: "Michael Hammer $mhammer$" To: "AMIT KUNDRA" , X-OriginalArrivalTime: 15 Aug 2006 15:47:48.0914 (UTC) FILETIME=[28C86120:01C6C082] DKIM-Signature: a=rsa-sha1; q=dns; l=4921; t=1155656868; x=1156520868; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20$mhammer$=22=20 |Subject:RE=3A=20[Sipping]=20Example=20of=20interworking=20between=20a=20Wireline =20Softswitch=20&=20aCDMA=20Softswitch |To:=22AMIT=20KUNDRA=22=20,=20; X=v=3Dcisco.com=3B=20h=3D4gHgzvaFm7DVB/y3RgURGjGZqoI=3D; b=joOBXbBENU2oxP+huKBs8drDNAT3gYve3vRrGfpSUh1LkY4d5aOTrcD7PpZwZ14CnYaZkBfF fHPq69rfvmY1/v3wko1nueHHduCA/bIOIYurB0S/fTwK1vt46RUTJ8JF; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0501206506==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0501206506== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C082.282A356A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C082.282A356A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Read Q.1912.5 =20 If you want to be more forward thinking, focus on SIP. =20 Mike =20 ________________________________ From: AMIT KUNDRA [mailto:akundra_1609@yahoo.co.in]=20 Sent: Tuesday, August 15, 2006 8:43 AM To: Sipping@ietf.org Subject: [Sipping] Example of interworking between a Wireline Softswitch & aCDMA Softswitch =09 =09 Hi , =20 I have one doubt. For one of our clients , having CDMA Mobile services & Wireline services If we are to have interworking between a Wireline Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as many people think that BICC is more clearly defines than SIP . From this I have 3 more queries: =20 1. Is SIP & BICC the same kind of protocol with just the difference that BICC is part of SS& while SIP is part of VoIP ? =20 2. If different then what is this talk about integarting BICC into SIP ? =20 3. Is there any SIP variant, called SIP-I as I only know the SIP & SIP-T ? =20 4. Pls clearly distinguish between SIP,SIP-T & SIP-I with practical examples as to where which to be used ? =20 Pls respond urgently=20 =20 =20 =20 =09 ________________________________ Here's a new way to find what you're looking for - Yahoo! Answers Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW ------_=_NextPart_001_01C6C082.282A356A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Read Q.1912.5

If you want to be more forward thinking, focus on=20 SIP.

Mike

From: AMIT KUNDRA=20 [mailto:akundra_1609@yahoo.co.in]
Sent: Tuesday, August 15, = 2006=20 8:43 AM
To: Sipping@ietf.org
Subject: [Sipping] = Example of=20 interworking between a Wireline Softswitch & aCDMA=20 Softswitch

Hi ,

I have one doubt. For one of our clients , having CDMA Mobile = services=20 & Wireline services If we are to have interworking between a = Wireline=20 Softswitch & a CDMA Softswitch then do we use SIP or BICC ? as = many people=20 think that BICC is more clearly defines than SIP . From this I = have 3=20 more queries:

1. Is SIP & BICC the same kind of protocol with just the = difference=20 that BICC is part of SS& while SIP is part of VoIP ?

2. If different then what is this talk about integarting BICC = into SIP=20 ?

3. Is there any SIP variant, called SIP-I as I only know the SIP = &=20 SIP-T ?

4. Pls clearly distinguish between SIP,SIP-T & SIP-I with = practical=20 examples as to where which to be used ?

Pls respond urgently

Here's a new way to find what you're looking for - Yahoo!=20 Answers
Send FREE SMS to your friend's mobile from Yahoo! = Messenger=20 Version 8. Get=20 it NOW ------_=_NextPart_001_01C6C082.282A356A-- --===============0501206506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0501206506==-- From sipping-bounces@ietf.org Tue Aug 15 13:37:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2rE-0002P1-3r; Tue, 15 Aug 2006 13:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2rC-0002Ov-M4 for Sipping@ietf.org; Tue, 15 Aug 2006 13:37:38 -0400 Received: from mail2.spherecom.com ([66.237.126.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2rB-00023x-6J for Sipping@ietf.org; Tue, 15 Aug 2006 13:37:38 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 15 Aug 2006 12:34:54 -0500 Message-ID: <5E6F57726155C84481FA244AE5C6DBA45C5EBE@stratosphere.spherecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on draft-anil-sipping-bla-03.txt Thread-Index: AcaprrYe/LcUQwAGS/WiryiJlYj7RQW4RGmw From: "Agrawal, Vishal" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: Subject: [Sipping] Questions on draft-anil-sipping-bla-03.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0487679238==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0487679238== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C091.7F341E0D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C091.7F341E0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 6.3 "Call offered to a BLA Group", it's possible that more than one user agents answer the incoming call simultaneously. What should be the responses from the Proxy? Should the proxy send an ACK followed by a BYE request? How would the agent receiving BYE know that a race condition just occurred at the Proxy? I think that the section 8 should cover this race condition.=20 =20 -Vishal ------_=_NextPart_001_01C6C091.7F341E0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 6.3 “Call offered to a BLA = Group”, it’s possible that more than one user agents answer the incoming = call simultaneously. What should be the responses from the Proxy? Should the proxy send an = ACK followed by a BYE request? How would the agent receiving BYE know that a = race condition just occurred at the Proxy? I think that the section 8 should = cover this race condition.

-Vishal

------_=_NextPart_001_01C6C091.7F341E0D-- --===============0487679238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0487679238==-- From sipping-bounces@ietf.org Tue Aug 15 13:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD30a-0006ep-2E; Tue, 15 Aug 2006 13:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD30Y-0006ek-El for Sipping@ietf.org; Tue, 15 Aug 2006 13:47:18 -0400 Received: from mail2.spherecom.com ([66.237.126.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD30X-0002Yv-09 for Sipping@ietf.org; Tue, 15 Aug 2006 13:47:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 15 Aug 2006 12:44:35 -0500 Message-ID: <5E6F57726155C84481FA244AE5C6DBA45C5EC0@stratosphere.spherecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sawada-sipping-sip-offeranswer-01.txt Thread-Index: AcbAknjdtYV8KD40T9mccih+pIn9vg== From: "Agrawal, Vishal" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Subject: [Sipping] draft-sawada-sipping-sip-offeranswer-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128258383==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============2128258383== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C092.D900E8AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C092.D900E8AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 3.2 must both UA - A and B reject the offer 1 and offer 2 with 491 responses? The draft says that offer 2 must be rejected, how does the UA B know not to reject offer 1? =20 Vishal ------_=_NextPart_001_01C6C092.D900E8AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 3.2 must both UA - A and B reject the = offer 1 and offer 2 with 491 responses? The draft says that offer 2 must be = rejected, how does the UA B know not to reject offer 1?

Vishal

------_=_NextPart_001_01C6C092.D900E8AE-- --===============2128258383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============2128258383==-- From sipping-bounces@ietf.org Tue Aug 15 16:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5Dz-0004uV-2P; Tue, 15 Aug 2006 16:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5Dx-0004uQ-9j for Sipping@ietf.org; Tue, 15 Aug 2006 16:09:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5Dv-0002XK-07 for Sipping@ietf.org; Tue, 15 Aug 2006 16:09:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2006 16:09:12 -0400 X-IronPort-AV: i="4.08,128,1154923200"; d="scan'208"; a="96965296:sNHT6816722988" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FK9C5c019302; Tue, 15 Aug 2006 16:09:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7FK9Ch5006416; Tue, 15 Aug 2006 16:09:12 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 16:09:11 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 16:09:11 -0400 Message-ID: <44E229E7.6030203@cisco.com> Date: Tue, 15 Aug 2006 16:09:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Agrawal, Vishal" Subject: Re: [Sipping] draft-sawada-sipping-sip-offeranswer-01.txt References: <5E6F57726155C84481FA244AE5C6DBA45C5EC0@stratosphere.spherecom.com> In-Reply-To: <5E6F57726155C84481FA244AE5C6DBA45C5EC0@stratosphere.spherecom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2006 20:09:11.0932 (UTC) FILETIME=[AC9703C0:01C6C0A6] DKIM-Signature: a=rsa-sha1; q=dns; l=983; t=1155672552; x=1156536552; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sipping]=20draft-sawada-sipping-sip-offeranswer-01.txt |To:=22Agrawal,=20Vishal=22=20; X=v=3Dcisco.com=3B=20h=3DsD/eRLp8ibkzyqTiiyJgN4spFkw=3D; b=G9/TFSwVkNukSjUfJOyeEDJB69Sw7joCseBIvRXOMhDCuAg4D/99pj7BRGYbMQ0v9z5845ZJ zg1+lNw+XVz+Sybax0x8Elt92CCfqcmC1Z8CImczIL0WZWTQFgg1KzSD; Authentication-Results: rtp-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Agrawal, Vishal wrote: > In section 3.2 must both UA - A and B reject the offer 1 and offer 2 > with 491 responses? The draft says that offer 2 must be rejected, how > does the UA B know not to reject offer 1? If both offers are carried by UPDATEs then I believe they both fail with 491. Because of the symmetry there is no good way for a winner to be picked. When one is in an UPDATE and the other is in a PRACK the asymmetry allows designating one (the PRACK) as a winner. (Of course there can't be offers in PRACKs going in both directions.) Paul > Vishal > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Aug 16 18:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTb7-0000GK-IS; Wed, 16 Aug 2006 18:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTb6-0000G9-J5 for Sipping@ietf.org; Wed, 16 Aug 2006 18:10:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDTb4-0001Lk-6s for Sipping@ietf.org; Wed, 16 Aug 2006 18:10:48 -0400 Received: by ug-out-1314.google.com with SMTP id m2so336908uge for ; Wed, 16 Aug 2006 15:10:45 -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:references; b=f3MSGL/RwuyJaUdbUJuOtHVJlpSZnNhwyYWeb3SmvSfhtDgb1hl1tdSAFoDbQywJTecibLsVR4TUEcHCH2otgJwB8uljtb8Ir2RyvvGjp/IxQ+kR/kw59GzT+u6CdJcJ6ZuFfsPEFwwmw5tORUR+TFctTuI7TIyj2bVmR/Z/TzI= Received: by 10.49.43.2 with SMTP id v2mr1308536nfj; Wed, 16 Aug 2006 15:10:45 -0700 (PDT) Received: by 10.78.139.6 with HTTP; Wed, 16 Aug 2006 15:10:45 -0700 (PDT) Message-ID: <4ff4e7370608161510i772f5303r1a10f151b1e9d06e@mail.gmail.com> Date: Wed, 16 Aug 2006 15:10:45 -0700 From: Venkatesh To: "Agrawal, Vishal" Subject: Re: [Sipping] Questions on draft-anil-sipping-bla-03.txt In-Reply-To: <5E6F57726155C84481FA244AE5C6DBA45C5EBE@stratosphere.spherecom.com> MIME-Version: 1.0 References: <5E6F57726155C84481FA244AE5C6DBA45C5EBE@stratosphere.spherecom.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0255418268==" Errors-To: sipping-bounces@ietf.org --===============0255418268== Content-Type: multipart/alternative; boundary="----=_Part_48473_16900008.1155766245384" ------=_Part_48473_16900008.1155766245384 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Vishal: Offering calls to a BLA group relies the ability of the proxy to fork the request. The proxy simply forwards all 2xx responses to the calling side in cases where multiple UA's answer the call simultaneously. UA's are expected to handle this condition per section 13.2.2 of RFC 3261. I am not sure there is anything the UA would have to do in addition to what is already mentioned in RFC 3261 for accomodating this condition. Venkatesh On 8/15/06, Agrawal, Vishal wrote: > > In section 6.3 "Call offered to a BLA Group", it's possible that more > than one user agents answer the incoming call simultaneously. What should be > the responses from the Proxy? Should the proxy send an ACK followed by a BYE > request? How would the agent receiving BYE know that a race condition just > occurred at the Proxy? I think that the section 8 should cover this race > condition. > > > > -Vishal > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > ------=_Part_48473_16900008.1155766245384 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Vishal:

Offering calls to a BLA group relies the ability of the proxy to fork the request. The proxy simply forwards all 2xx responses to the calling side in cases where multiple UA's answer the call simultaneously. UA's are expected to handle this condition per section 13.2.2 of RFC 3261. I am not sure there is anything the UA would have to do in addition to what is already mentioned in RFC 3261 for accomodating this condition.

Venkatesh

On 8/15/06, Agrawal, Vishal <VAgrawal@spherecom.com> wrote:

In section 6.3 "Call offered to a BLA Group", it's possible that more than one user agents answer the incoming call simultaneously. What should be the responses from the Proxy? Should the proxy send an ACK followed by a BYE request? How would the agent receiving BYE know that a race condition just occurred at the Proxy? I think that the section 8 should cover this race condition.

-Vishal

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

------=_Part_48473_16900008.1155766245384-- --===============0255418268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0255418268==-- From sipping-bounces@ietf.org Wed Aug 16 18:33:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTw5-0001fC-TZ; Wed, 16 Aug 2006 18:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTw4-0001f6-Go for Sipping@ietf.org; Wed, 16 Aug 2006 18:32:28 -0400 Received: from mail2.spherecom.com ([66.237.126.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDTw1-0002N2-J0 for Sipping@ietf.org; Wed, 16 Aug 2006 18:32:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Questions on draft-anil-sipping-bla-03.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 16 Aug 2006 17:29:33 -0500 Message-ID: <5E6F57726155C84481FA244AE5C6DBA45C5F0B@stratosphere.spherecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Questions on draft-anil-sipping-bla-03.txt Thread-Index: AcbBgNQS4MwN8BHHTIG2JqFaSPeL/wAADcfg From: "Agrawal, Vishal" To: "Venkatesh" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500324034==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1500324034== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C183.D7714683" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C183.D7714683 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Venkatesh, =20 I agree that the UAC should follow both section 13.2.2 and 15 in RFC 3261 to determine the next course of action. However, e.g. when all but one UA receive the BYE, do they terminate the SUBSCRIBE dialog usage as well? Or they need to keep the SUBSCRIBE dialog usage till they receive the NOTIFY with terminated subscription state? =20 I've few other questions basically to clear my understanding:=20 1.) Can two simultaneous outbound calls be allowed from two BLA user-agents if they choose different line appearances? 2.) How does the BLA user-agent tell the registrar/proxy, how many line appearances it has configured for the BLA DA? As per section 5.1 in the BLA ID it's recommended to send one REGISTER request per DA on the device, right? Should the proxy not send the INVITE to a user-agent in the BLA group if it has no line appearance available? 3.) The feature doesn't work for a SIP ATA, right? 4.) Are 2 & 3 configuration issues?=20 =20 Vishal =20 ________________________________ From: Venkatesh [mailto:vvenkatar@gmail.com]=20 Sent: Wednesday, August 16, 2006 5:11 PM To: Agrawal, Vishal Cc: Sipping@ietf.org Subject: Re: [Sipping] Questions on draft-anil-sipping-bla-03.txt =20 Vishal: =20 Offering calls to a BLA group relies the ability of the proxy to fork the request. The proxy simply forwards all 2xx responses to the calling side in cases where multiple UA's answer the call simultaneously. UA's are expected to handle this condition per section 13.2.2 of RFC 3261. I am not sure there is anything the UA would have to do in addition to what is already mentioned in RFC 3261 for accomodating this condition. =20 Venkatesh =20 On 8/15/06, Agrawal, Vishal wrote:=20 In section 6.3 "Call offered to a BLA Group", it's possible that more than one user agents answer the incoming call simultaneously. What should be the responses from the Proxy? Should the proxy send an ACK followed by a BYE request? How would the agent receiving BYE know that a race condition just occurred at the Proxy? I think that the section 8 should cover this race condition.=20 =20 -Vishal _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping =20 This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP =20 ------_=_NextPart_001_01C6C183.D7714683 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Venkatesh,

I = agree that the UAC should follow both section 13.2.2 and 15 in RFC 3261 to = determine the next course of action. However, e.g. when all but one UA receive the = BYE, do they terminate the SUBSCRIBE dialog usage as well? Or they need to keep = the SUBSCRIBE dialog usage till they receive the NOTIFY with terminated subscription state?

I’ve few other questions basically to clear my understanding: =

1.) Can two simultaneous outbound calls be allowed from two BLA user-agents if they choose different line = appearances?

2.) How does the BLA user-agent tell the registrar/proxy, how = many line appearances it has configured for the BLA DA? As per section 5.1 in the = BLA ID it’s recommended to send one REGISTER request per DA on the = device, right? Should the proxy not send the INVITE to a user-agent in the BLA = group if it has no line appearance available?

3.) The feature doesn’t work for a SIP ATA, = right?

4.) Are 2 & 3 configuration issues? =

Vishal

From: = Venkatesh [mailto:vvenkatar@gmail.com]
Sent: Wednesday, = August 16, = 2006 5:11 PM
To: Agrawal, Vishal
Cc: Sipping@ietf.org
Subject: Re: [Sipping] = Questions on draft-anil-sipping-bla-03.txt

Vishal:

Offering calls to a BLA group relies the ability of the proxy to = fork the request. The proxy simply forwards all 2xx responses to the calling = side in cases where multiple UA's answer the call simultaneously. UA's are expected to handle this condition per section 13.2.2 of RFC 3261. I = am not sure there is anything the UA would have to do in addition to what is = already mentioned in RFC 3261 for accomodating this condition.

Venkatesh

On 8/15/06, Agrawal, Vishal = <VAgrawal@spherecom.com> = wrote:

In section 6.3 "Call offered to a BLA Group", it's possible that = more than one user agents answer the incoming call simultaneously. What = should be the responses from the Proxy? Should the proxy send an ACK followed by a = BYE request? How would the agent receiving BYE know that a race condition = just occurred at the Proxy? I think that the section 8 should cover this race condition.

-Vishal

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

------_=_NextPart_001_01C6C183.D7714683-- --===============1500324034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1500324034==-- From sipping-bounces@ietf.org Wed Aug 16 19:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVF6-0000rh-Dt; Wed, 16 Aug 2006 19:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDVF3-0000rc-AA for Sipping@ietf.org; Wed, 16 Aug 2006 19:56:09 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDVF2-00005x-M1 for Sipping@ietf.org; Wed, 16 Aug 2006 19:56:09 -0400 Received: by nf-out-0910.google.com with SMTP id n15so886579nfc for ; Wed, 16 Aug 2006 16:56:07 -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:references; b=bGiKkubRkvfS4JctXf8dz45dM/hFMA/OenqpVcU84n7owM9fqV/5dqu3BovgjNUEFOKKt0M/QnmYJdNHqw9uj7GzireceaDOg0CCYyA6STj/EFyfWbqTKF4TKyDQCv1cG519SvVlYszcGn5CA0DwhX2UZymuYtMeMRwS0t4FHMc= Received: by 10.49.29.3 with SMTP id g3mr1410941nfj; Wed, 16 Aug 2006 16:56:07 -0700 (PDT) Received: by 10.78.139.6 with HTTP; Wed, 16 Aug 2006 16:56:07 -0700 (PDT) Message-ID: <4ff4e7370608161656i3d815b26mc2b62db3374f54f2@mail.gmail.com> Date: Wed, 16 Aug 2006 16:56:07 -0700 From: Venkatesh To: "Agrawal, Vishal" Subject: Re: [Sipping] Questions on draft-anil-sipping-bla-03.txt In-Reply-To: <5E6F57726155C84481FA244AE5C6DBA45C5F0B@stratosphere.spherecom.com> MIME-Version: 1.0 References: <5E6F57726155C84481FA244AE5C6DBA45C5F0B@stratosphere.spherecom.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0727150878==" Errors-To: sipping-bounces@ietf.org --===============0727150878== Content-Type: multipart/alternative; boundary="----=_Part_50638_28150962.1155772567688" ------=_Part_50638_28150962.1155772567688 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Replies inline.... On 8/16/06, Agrawal, Vishal wrote: > > Hi Venkatesh, > > > > I agree that the UAC should follow both section 13.2.2 and 15 in RFC 3261 > to determine the next course of action. However, e.g. when all but one UA > receive the BYE, do they terminate the SUBSCRIBE dialog usage as well? Or > they need to keep the SUBSCRIBE dialog usage till they receive the NOTIFY > with terminated subscription state? > [Venkatesh]: The SUBSCRIBE for dialog-state is an independent dialog by itself. Thus receipt of a BYE does not terminate the subscription. > > I've few other questions basically to clear my understanding: > > 1.) Can two simultaneous outbound calls be allowed from two BLA > user-agents if they choose different line appearances? > [Venkatesh]: Yes. 2.) How does the BLA user-agent tell the registrar/proxy, how many line > appearances it has configured for the BLA DA? As per section 5.1 in the > BLA ID it's recommended to send one REGISTER request per DA on the device, > right? Should the proxy not send the INVITE to a user-agent in the BLA group > if it has no line appearance available? > [Venkatesh]: The BLA user-agent does not need to provide this information to the Registrar/Proxy. This is managed locally by the UA. It is for this reason, the draft recommends that UA's send only one register for the AOR regardless of how many line appearances it is configured with. Since line management is local to the phone, the proxy will always fork an incoming request to a UA regardless of availability of lines at a specific UA. UA's can reject the incoming INVITE with an appropriate response if it does not have any free lines. 3.) The feature doesn't work for a SIP ATA, right? > [Venkatesh]: I am not sure I understand this question. 4.) Are 2 & 3 configuration issues? > > > Vishal > > > ------------------------------ > > *From:* Venkatesh [mailto:vvenkatar@gmail.com] > *Sent:* Wednesday, August 16, 2006 5:11 PM > *To:* Agrawal, Vishal > *Cc:* Sipping@ietf.org > *Subject:* Re: [Sipping] Questions on draft-anil-sipping-bla-03.txt > > > > Vishal: > > > > Offering calls to a BLA group relies the ability of the proxy to fork the > request. The proxy simply forwards all 2xx responses to the calling side in > cases where multiple UA's answer the call simultaneously. UA's are expected > to handle this condition per section 13.2.2 of RFC 3261. I am not sure > there is anything the UA would have to do in addition to what is already > mentioned in RFC 3261 for accomodating this condition. > > > Venkatesh > > > On 8/15/06, *Agrawal, Vishal* wrote: > > In section 6.3 "Call offered to a BLA Group", it's possible that more than > one user agents answer the incoming call simultaneously. What should be the > responses from the Proxy? Should the proxy send an ACK followed by a BYE > request? How would the agent receiving BYE know that a race condition just > occurred at the Proxy? I think that the section 8 should cover this race > condition. > > > > -Vishal > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > ------=_Part_50638_28150962.1155772567688 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Replies inline....

On 8/16/06, Agrawal, Vishal <VAgrawal@spherecom.com> wrote:

Hi Venkatesh,

I agree that the UAC should follow both section 13.2.2 and 15 in RFC 3261 to determine the next course of action. However, e.g . when all but one UA receive the BYE, do they terminate the SUBSCRIBE dialog usage as well? Or they need to keep the SUBSCRIBE dialog usage till they receive the NOTIFY with terminated subscription state?

[Venkatesh]: The SUBSCRIBE for dialog-state is an independent dialog by itself. Thus receipt of a BYE does not terminate the subscription.

I've few other questions basically to clear my understanding:

1.) Can two simultaneous outbound calls be allowed from two BLA user-agents if they choose different line appearances?

[Venkatesh]: Yes.

2.) How does the BLA user-agent tell the registrar/proxy, how many line appearances it has configured for the BLA DA? As per section 5.1 in the BLA ID it's recommended to send one REGISTER request per DA on the device, right? Should the proxy not send the INVITE to a user-agent in the BLA group if it has no line appearance available?

[Venkatesh]: The BLA user-agent does not need to provide this information to the Registrar/Proxy. This is managed locally by the UA. It is for this reason, the draft recommends that UA's send only one register for the AOR regardless of how many line appearances it is configured with. Since line management is local to the phone, the proxy will always fork an incoming request to a UA regardless of availability of lines at a specific UA. UA's can reject the incoming INVITE with an appropriate response if it does not have any free lines.

3.) The feature doesn't work for a SIP ATA, right?

[Venkatesh]: I am not sure I understand this question.

4.) Are 2 & 3 configuration issues?

Vishal

From: Venkatesh [mailto: vvenkatar@gmail.com]
Sent: Wednesday, August 16, 2006 5:11 PM
To: Agrawal, Vishal
Cc: Sipping@ietf.org
Subject: Re: [Sipping] Questions on draft-anil-sipping-bla-03.txt

Vishal:

Offering calls to a BLA group relies the ability of the proxy to fork the request. The proxy simply forwards all 2xx responses to the calling side in cases where multiple UA's answer the call simultaneously. UA's are expected to handle this condition per section 13.2.2 of RFC 3261. I am not sure there is anything the UA would have to do in addition to what is already mentioned in RFC 3261 for accomodating this condition.

Venkatesh

On 8/15/06, Agrawal, Vishal < VAgrawal@spherecom.com> wrote:

In section 6.3 "Call offered to a BLA Group", it's possible that more than one user agents answer the incoming call simultaneously. What should be the responses from the Proxy? Should the proxy send an ACK followed by a BYE request? How would the agent receiving BYE know that a race condition just occurred at the Proxy? I think that the section 8 should cover this race condition.

-Vishal

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

------=_Part_50638_28150962.1155772567688-- --===============0727150878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0727150878==-- From sipping-bounces@ietf.org Wed Aug 16 23:48:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDYq2-0000rd-IG; Wed, 16 Aug 2006 23:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDYq1-0000rU-Bx for sipping@ietf.org; Wed, 16 Aug 2006 23:46:33 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDYpz-0005KX-Ph for sipping@ietf.org; Wed, 16 Aug 2006 23:46:33 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7H3kQ3A027468; Wed, 16 Aug 2006 23:46:26 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 23:46:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6C1AF.B479695C" Date: Thu, 17 Aug 2006 09:16:21 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5D17@sonusinmail01.sonusnet.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt Thread-Index: Aca/qnu7TPQm75soSWGV6bpsTk8mSQCBFM3w From: "B, Nataraju" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Aug 2006 03:46:26.0253 (UTC) FILETIME=[B721EFD0:01C6C1AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sipping@ietf.org Subject: [Sipping] RE: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C1AF.B479695C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF1bCwgDQoNCldoYXQgSSBtZWFudCB0byBtZW50aW9uIGhlcmUgd2FzIHRoYXQsIGluIHRoZSBz Y2VuYXJpb3Mgd2hpY2ggbWlnaHQgbGVhZCB0byB0aGVzZSByZXNwb25zZXMgbXVzdCBiZSBhdXRo ZW50aWNhdGVkIGJlZm9yZSB3ZSBjYWxsIGZvciB0aGlzIFJlcG9uc2VzLi4uIA0KCUkgbWVhbiBp ZiB3ZSByZWNlaXZlIGEgTk9USUZZKHVuLWF1dGhlbnRpY2F0ZWQpIDQwNCBzaG91bGQgbm90IGJl IHNlbnQgb3V0IHdoaWNoIHdpbGwgdGVybWluYXRlIHRoZSBkaWFsb2cvdXNhZ2UuICANCg0KCQlB dXRoZW50aWNhdGUgdGhlIE5URlkgcmVxdWVzdCBmaXJzdCB0aGVuIG9ubHkgaXQgY291bGQgYmUg cmVqZWN0ZWQgd2l0aCA0MDQgb3IgYW55IG90aGVyIGFwcHJvcHJpYXRlIHJlcGxpZXMgd2hpY2gg d291bGQgcmVzdWx0IGluIGRpYWxvZyB0ZXJtaW5hdGlvbi4gDQoNClRoYW5rcywNCk5hdGFyYWp1 IEEgQg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgS3l6aXZh dCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTQs IDIwMDYgNzozNCBQTQ0KPiBUbzogQiwgTmF0YXJhanUNCj4gQ2M6IHNpcEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW1NpcF0gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBwaW5nLWRpYWxvZ3Vz YWdlLTAyLnR4dA0KPiANCj4gDQo+IA0KPiBCLCBOYXRhcmFqdSB3cm90ZToNCj4gDQo+ID4gMS4g U2VjIDQgZGVzY3JpYmVzIHdoYXQgdGhlIGVmZmVjdHMgb24gZGlhbG9nIGFyZSBhbmQgaXRzIHVz YWdlcyB3aGVuDQo+ID4gcGFydGljdWxhciByZXNwb25zZXMgYXJlIHJlY2VpdmVkIGZvciBOT1RJ RlkgbWVzc2FnZSwgdGhlIHJlc3BvbnNlcyA0MDQsDQo+ID4gNDEwLCA0MTYsIGxlYWQgdG8gZGlh bG9nIGFuZCBpdHMgdXNhZ2UgdGVybWluYXRpb24uDQo+ID4NCj4gPiAgICAgICBhLiBJIGZlZWwg d2Ugc2hvdWxkIGhhdmUgbWVudGlvbmVkIE9OTFkgdGhlIGF1dGhlbnRpY2F0ZWQgTk9USUZZDQo+ ID4gcmVxdWVzdHMgd2lsbCBoYXZlIHRoaXMgZWZmZWN0IG9uIHRoZSBkaWFsb2dzL3VzYWdlcy4g T3RoZXJ3aXNlIGFueQ0KPiA+IG1pZGRsZSBtZW4gY2FuIHRyYWNlIHRoZSBtZXNzYWdlIGFuZCBz ZW5kIHRoZSBOT1RJRlkgbWVzc2FnZXMgd2hpY2gNCj4gPiB0ZXJtaW5hdGUgdGhlIGRpYWxvZ3Ms IHdoaWNoIGlzIHVuZGVzaXJhYmxlIOKYuS4gSWYgdGhlIGVudGl0eSBzZW5kaW5nDQo+ID4gTk9U SUZZIHJlYWxseSBpbnRlbmQgdG8gZG8gdGhhdCBpdCBjYW4gcmVzZW5kIE5PVElGWSB3aXRoIGF1 dGhvcml6YXRpb24NCj4gPiBjcmVkZW50aWFscyB3aGljaCB3aWxsIGhlbHAgdG8gdGVybWluYXRl IHRoZSBhc3NvY2lhdGVkIGRpYWxvZ3MuDQo+IA0KPiBJIGFncmVlIHdlIHdvdWxkbid0IHdhbnQg dG8gZW5hYmxlIGEgTUlUTSBhdHRhY2sgaGVyZS4NCj4gDQo+IEJ1dCBJIHRoaW5rIHRoYXQgaXMg YWxyZWFkeSBjb3ZlcmVkLiBJZiB0aGUgcmVxdWVzdCBpc24ndCBwcm9wZXJseQ0KPiBhdXRoZW50 aWNhdGVkLCB0aGVuIHRoZSByZXNwb25zZSB3aWxsIGJlIDQwMSwgbm90IDQwNCwgNDEwLCBvciA0 MTYuDQo+IA0KPiAJUGF1bA0KDQoNCg== ------_=_NextPart_001_01C6C1AF.B479695C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from sonusmail01.sonusnet.com ([10.128.32.75]) by SONUSINMAIL01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Aug 2006 12:04:48 +0530 Received: from sonussf1.sonusnet.com ([192.168.1.51]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Aug 2006 02:34:41 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C6BF6B.BD00F400" Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7E6YeNL003687; Mon, 14 Aug 2006 02:34:40 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCW1s-0001fC-7m; Mon, 14 Aug 2006 02:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCW1p-0001Zn-JR for sip@ietf.org; Mon, 14 Aug 2006 02:34:25 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCW1o-0001bo-6p for sip@ietf.org; Mon, 14 Aug 2006 02:34:25 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7E6YOvH003659 for ; Mon, 14 Aug 2006 02:34:24 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 02:34:23 -0400 content-class: urn:content-classes:message Subject: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt Date: Mon, 14 Aug 2006 12:04:19 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5BDA@sonusinmail01.sonusnet.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-sipping-dialogusage-02.txt Thread-Index: Aca/a6vhg1oTxT0IQdO3kIXzBLjzNA== List-Help: List-Subscribe: , List-Unsubscribe: , From: "B, Nataraju" To: This is a multi-part message in MIME format. ------_=_NextPart_002_01C6BF6B.BD00F400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BhcmtzLCANCg0KIA0KDQpJIGhhZCBnb25lIHRocm91Z2ggdGhlIGRvY3VtZW50LCBoZXJl IGFyZSBmZXcgY29tbWVudHMuIA0KDQogDQoNCk5vdGU6IEkgYXNzdW1lIHRoZSBiZWhhdmlvciBt ZW50aW9uZWQgaW4gc2VjIDQgYXBwbGllcyBib3RoIGF0IGNsaWVudCByZWNlaXZpbmcgdGhlc2Ug cmVzcG9uc2VzIChOb3RpZmllcikgYW5kIHNlcnZlciBnZW5lcmF0aW5nIHRoZXNlIHJlcGxpZXMg KFN1YnNjcmliZXIpLiBJZiB0aGlzIHdhcyBtZWFudCB0byBiZSBvbmx5IEAgc2VuZGVyIG9mIE5P VElGWSBzaGFsbCB3ZSBuZWVkIHRvIG1lbnRpb24gdGhlIHNpbWlsYXIgc2V0IG9mIGFjdGlvbnMg QCBTdWJzY3JpYmVyIHNpZGUgdG9vPyANCg0KIA0KDQoxLiBTZWMgNCBkZXNjcmliZXMgd2hhdCB0 aGUgZWZmZWN0cyBvbiBkaWFsb2cgYXJlIGFuZCBpdHMgdXNhZ2VzIHdoZW4gcGFydGljdWxhciBy ZXNwb25zZXMgYXJlIHJlY2VpdmVkIGZvciBOT1RJRlkgbWVzc2FnZSwgdGhlIHJlc3BvbnNlcyA0 MDQsIDQxMCwgNDE2LCBsZWFkIHRvIGRpYWxvZyBhbmQgaXRzIHVzYWdlIHRlcm1pbmF0aW9uLiAN Cg0KICAgICAgYS4gSSBmZWVsIHdlIHNob3VsZCBoYXZlIG1lbnRpb25lZCBPTkxZIHRoZSBhdXRo ZW50aWNhdGVkIE5PVElGWSByZXF1ZXN0cyB3aWxsIGhhdmUgdGhpcyBlZmZlY3Qgb24gdGhlIGRp YWxvZ3MvdXNhZ2VzLiBPdGhlcndpc2UgYW55IG1pZGRsZSBtZW4gY2FuIHRyYWNlIHRoZSBtZXNz YWdlIGFuZCBzZW5kIHRoZSBOT1RJRlkgbWVzc2FnZXMgd2hpY2ggdGVybWluYXRlIHRoZSBkaWFs b2dzLCB3aGljaCBpcyB1bmRlc2lyYWJsZSDimLkuIElmIHRoZSBlbnRpdHkgc2VuZGluZyBOT1RJ RlkgcmVhbGx5IGludGVuZCB0byBkbyB0aGF0IGl0IGNhbiByZXNlbmQgTk9USUZZIHdpdGggYXV0 aG9yaXphdGlvbiBjcmVkZW50aWFscyB3aGljaCB3aWxsIGhlbHAgdG8gdGVybWluYXRlIHRoZSBh c3NvY2lhdGVkIGRpYWxvZ3MuDQoNCiANCg0KICAgICAgYi4gT3RoZXIgYWx0ZXJuYXRpdmUgd291 bGQgYmUgdGhhdCBsZXQgdGhvc2UgcmVzcG9uc2VzIGhhdmUgbm8gZWZmZWN0IG9uIHRoZSBkaWFs b2cvdXNhZ2VzLCBldmVudHVhbGx5IHRoZSBzdWJzY3JpcHRpb24gZHVyYXRpb24gd291bGQgdGFr ZSBjYXJlIG9mIGRpYWxvZyB0ZXJtaW5hdGlvbiBvciB0aGUgYWN0dWFsIGVudGl0eSB3b3VsZCB0 ZXJtaW5hdGUgb3IgZXh0ZW5kIHRoZSBzdWJzY3JpcHRpb24uIEFueSB3YXkgdGhlIHJlcXVlc3Qg ZnJvbSBhY3R1YWwgbm90aWZpZXIgd291bGQgaGF2ZSB0aGUgcHJvcGVyIFVSSXMgb3IgY3JlZGVu dGlhbHMgd2hpY2ggd2lsbCBuZXZlciBsZWFkIHRvIHRoZXNlIHJlc3BvbnNlcy4gDQoNCiANCg0K VGhlIHNhbWUgbG9naWMgd291bGQgbmVlZCB0byBleHRlbmQgZm9yIHJlcGxpZXMgNDgxLCA0ODMs IDQ4NCwgNDg5IGFuZCA2MDQgYWxzby4NCg0KIA0KDQoyLiBTZWMgNCBvZiB0aGUgZHJhZnQNCg0K ICAgDQoNCiAgICA8PDwgICA0MjMgSW50ZXJ2YWwgVG9vIEJyaWVmOiBUaGlzIHJlc3BvbnNlIHdv bid0IGhhcHBlbiBpbiBvdXIgZXhhbXBsZQ0KDQogICAgICBzY2VuYXJpbywgYnV0IGlmIGl0IGNh bWUgaW4gcmVzcG9uc2UgdG8gYSByZVNVQlNDUklCRSwgdGhlDQoNCiAgICAgIHN1YnNjcmliZSB1 c2FnZSBpcyBub3QgZGVzdHJveWVkIChvciBvdGhlcndpc2UgYWZmZWN0ZWQpLiAgTm8NCg0KICAg ICAgb3RoZXIgdXNhZ2VzIG9mIHRoZSBkaWFsb2cgYXJlIGFmZmVjdGVkLiA+Pj4NCg0KIA0KDQog ICAgICBJbiB0aGUgYWJvdmUgUGFyYSB0aGUgbWVhbmluZyBvZiBsYXN0IHBhcnQgb2YgMXN0IHNl bnRlbmNlIChJIG1lYW4sIHRoZSBzdWJzY3JpYmUgdXNhZ2UgaXMgbm90IGRlc3Ryb3llZCAob3Ig b3RoZXJ3aXNlIGFmZmVjdGVkKSkgYW5kIDJuZCBzZW50ZW5jZSBpcyBub3QgY2xlYXIsIGJvdGgg bWVudGlvbiB0aGUgc2FtZSBtZWFuaW5nPyBDYW4gd2UgbWFrZSBpdCBleHBsaWNpdCBhYm91dCB3 aGF0IHdlIHJlYWxseSBtZWFuIGhlcmUgPyANCg0KIA0KDQpUaGFua3MsIA0KDQpOYXRhcmFqdSBB IEINCg0KU29udXMgTmV0d29ya3MgSW5kaWEgUHZ0IEx0ZA0KDQo= ------_=_NextPart_002_01C6BF6B.BD00F400 Content-Type: text/plain; name="ATT192005.txt" Content-Transfer-Encoding: base64 Content-Description: ATT192005.txt Content-Disposition: inline; filename="ATT192005.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcCBtYWls aW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KVGhp cyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQpV c2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJy ZW50IHNpcA0KVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhl IGFwcGxpY2F0aW9uIG9mIHNpcA== ------_=_NextPart_002_01C6BF6B.BD00F400-- ------_=_NextPart_001_01C6C1AF.B479695C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C6C1AF.B479695C-- From sipping-bounces@ietf.org Thu Aug 17 04:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdZY-0004Q3-Ec; Thu, 17 Aug 2006 04:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdZX-0004Py-Js for sipping@ietf.org; Thu, 17 Aug 2006 04:49:51 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDdZW-0006XX-5B for sipping@ietf.org; Thu, 17 Aug 2006 04:49:51 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7H8nhwv019537; Thu, 17 Aug 2006 04:49:43 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 04:49:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] bug in rfc-3261 Date: Thu, 17 Aug 2006 14:19:38 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5DE9@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] bug in rfc-3261 Thread-Index: Aca/ieeygas/2OQ4S2q8R/zZrklZkwCT+TNQ From: "B, Nataraju" To: "Manjunath Warad" , X-OriginalArrivalTime: 17 Aug 2006 08:49:43.0021 (UTC) FILETIME=[154061D0:01C6C1DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0463970250==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0463970250== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C1DA.129F252F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C1DA.129F252F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 I did not get many replies.=20 Should this be logged as bug against 3261 or not ?=20 Thanks,=20 Nataraju A B=20 _____ =20 From: Manjunath Warad [mailto:manjunathwarad@huawei.com]=20 Sent: Monday, August 14, 2006 3:17 PM To: B, Nataraju; sipping@ietf.org Subject: RE: [Sipping] bug in rfc-3261 =20 Hi, Please see inline... =20 Rgds, Manju -----Original Message----- From: B, Nataraju [mailto:bnataraju@sonusnet.com]=20 Sent: Monday, August 14, 2006 5:22 PM To: sipping@ietf.org Subject: [Sipping] bug in rfc-3261 Header field where proxy ACK BYE CAN INV OPT REG WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Contact 3xx d - o - o o o Why proxy column is mentioned as "ar" for WWW-Authenticate in 401/407. It should have been mentioned as "r" only. In no case proxy would add the WWW-Authenticate header for responses 401/407 ?. Does the proxy aggregation considered for this case ?=20 Yes you are right! Proxy aggregation is considered here.=20 Why proxy is allowed to "delete only" for contact in 3xx response? Even it should be allowed to read the contacts in 3xx replies. BTW, in which scenario it can delete a contact in 3xx response. This option should have been either "dr" or "r" only depending on answer to my previous question. =20 Here again, proxy can remove the contact, for which it has already tried, so that upstream proxies need not try on those contacts again. This technique is used when proxy chose 3xx as best response to be forwarded for upstream proxies. So, I think "adr" need to be used here as this header can be aggregated to form the final 3xx response if more than 1 is present. [ABN] this one should be considered bug against rfc-3261.=20 Please let me know, if my interpretation is wrong. Thanks, Nataraju A B Sonus Networks Ind Pvt Ltd ------_=_NextPart_001_01C6C1DA.129F252F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi All, =

I did = not get many replies.

Should = this be logged as bug against 3261 or not ?

Thanks,
Nataraju A B

From: = Manjunath Warad [mailto:manjunathwarad@huawei.com]
Sent: Monday, August 14, = 2006 3:17 PM
To: B, Nataraju; sipping@ietf.org
Subject: RE: [Sipping] = bug in rfc-3261

Hi,

Please see = inline...

Rgds,

Manju

-----Original = Message-----
From: B, Nataraju [mailto:bnataraju@sonusnet.com]
Sent: Monday, August 14, = 2006 5:22 PM
To: sipping@ietf.org
Subject: [Sipping] bug in = rfc-3261

Header field           &n= bsp; where       proxy ACK BYE CAN INV OPT = REG

WWW-Authenticate      &nbs= p;    401         ar    -   m   -   m   m   = m

WWW-Authenticate      &nbs= p;    407         ar    -   o   -   o   o   = o

Contact        &= nbsp;            = 3xx         d    -   o   = -   o   o   o

Why proxy column is mentioned as “ar” for WWW-Authenticate in 401/407. It should have been = mentioned as “r” only. In no case proxy would add the WWW-Authenticate = header for responses 401/407 ?. Does the = proxy aggregation considered for this case ?

Yes you are right! Proxy aggregation is considered here.

Why proxy is allowed to = “delete only” for contact in 3xx response? Even it should be allowed to = read the contacts in 3xx replies. BTW, in which scenario it can = delete a contact in 3xx response. This option should have been = either “dr” or “r” only depending on answer to my = previous question.

Here again, proxy can remove the contact, for which it has already tried, so that upstream proxies = need not try on those contacts again. This technique is used when proxy = chose 3xx as best response to be forwarded for upstream = proxies. So, I think "adr" need to be used here as this = header can be aggregated to form the final 3xx response if more than 1 is present.

[ABN] this one should be = considered bug against rfc-3261.

Please let me know, if my interpretation is = wrong.

Thanks,

Nataraju A = B

Sonus Networks Ind Pvt = Ltd

------_=_NextPart_001_01C6C1DA.129F252F-- --===============0463970250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0463970250==-- From sipping-bounces@ietf.org Thu Aug 17 10:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDicy-00061f-Ol; Thu, 17 Aug 2006 10:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDicw-00060H-W1 for sipping@ietf.org; Thu, 17 Aug 2006 10:13:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDhSj-0003vC-3z for sipping@ietf.org; Thu, 17 Aug 2006 08:59:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2006 08:59:05 -0400 X-IronPort-AV: i="4.08,136,1154923200"; d="scan'208"; a="97274823:sNHT34395596" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7HCx4RH030068; Thu, 17 Aug 2006 08:59:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7HCx4dM019454; Thu, 17 Aug 2006 08:59:04 -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.1830); Thu, 17 Aug 2006 08:59:04 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 08:59:04 -0400 Message-ID: <44E46817.9000409@cisco.com> Date: Thu, 17 Aug 2006 08:59:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "B, Nataraju" References: <70798CF421F00F4DA018059E5B7EEB8C7A5D17@sonusinmail01.sonusnet.com> In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C7A5D17@sonusinmail01.sonusnet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Aug 2006 12:59:04.0099 (UTC) FILETIME=[EABFB730:01C6C1FC] DKIM-Signature: a=rsa-sha1; q=dns; l=4793; t=1155819544; x=1156683544; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sipping-dialogusage-02.txt |To:=22B,=20Nataraju=22=20; X=v=3Dcisco.com=3B=20h=3DTH6BmAmf0rRE0cKOJxwAXgTnrbA=3D; b=bhCaCDtowkC9VDLk1bmrCfz0P1kHQJKDGsTfJMQNEEUWw3sqUep7/8FnLbr9pNxaUgmQIy8S xe+sER08NwPkj32gS+iraWvWjFFz6qpOrUkm53UWhFkEuCtCCtzRgOQX; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: sipping@ietf.org Subject: [Sipping] Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org B, Nataraju wrote: > Paul, > > What I meant to mention here was that, in the scenarios which might lead to these responses must be authenticated before we call for this Reponses... > I mean if we receive a NOTIFY(un-authenticated) 404 should not be sent out which will terminate the dialog/usage. > > Authenticate the NTFY request first then only it could be rejected with 404 or any other appropriate replies which would result in dialog termination. If I understand you, this is just standard procedure, applicable regardless of dialog usages. Authentication is supposed to be done first, so no extra information is given to unauthenticated callers. Paul > Thanks, > Nataraju A B > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, August 14, 2006 7:34 PM >> To: B, Nataraju >> Cc: sip@ietf.org >> Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt >> >> >> >> B, Nataraju wrote: >> >>> 1. Sec 4 describes what the effects on dialog are and its usages when >>> particular responses are received for NOTIFY message, the responses 404, >>> 410, 416, lead to dialog and its usage termination. >>> >>> a. I feel we should have mentioned ONLY the authenticated NOTIFY >>> requests will have this effect on the dialogs/usages. Otherwise any >>> middle men can trace the message and send the NOTIFY messages which >>> terminate the dialogs, which is undesirable â˜¹. If the entity sending >>> NOTIFY really intend to do that it can resend NOTIFY with authorization >>> credentials which will help to terminate the associated dialogs. >> I agree we wouldn't want to enable a MITM attack here. >> >> But I think that is already covered. If the request isn't properly >> authenticated, then the response will be 401, not 404, 410, or 416. >> >> Paul > > > > ------------------------------------------------------------------------ > > Subject: > [Sip] comments on draft-ietf-sipping-dialogusage-02.txt > From: > "B, Nataraju" > Date: > Mon, 14 Aug 2006 12:04:19 +0530 > To: > > > To: > > > > Hi Sparks, > > > > I had gone through the document, here are few comments. > > > > Note: I assume the behavior mentioned in sec 4 applies both at client receiving these responses (Notifier) and server generating these replies (Subscriber). If this was meant to be only @ sender of NOTIFY shall we need to mention the similar set of actions @ Subscriber side too? > > > > 1. Sec 4 describes what the effects on dialog are and its usages when particular responses are received for NOTIFY message, the responses 404, 410, 416, lead to dialog and its usage termination. > > a. I feel we should have mentioned ONLY the authenticated NOTIFY requests will have this effect on the dialogs/usages. Otherwise any middle men can trace the message and send the NOTIFY messages which terminate the dialogs, which is undesirable â˜¹. If the entity sending NOTIFY really intend to do that it can resend NOTIFY with authorization credentials which will help to terminate the associated dialogs. > > > > b. Other alternative would be that let those responses have no effect on the dialog/usages, eventually the subscription duration would take care of dialog termination or the actual entity would terminate or extend the subscription. Any way the request from actual notifier would have the proper URIs or credentials which will never lead to these responses. > > > > The same logic would need to extend for replies 481, 483, 484, 489 and 604 also. > > > > 2. Sec 4 of the draft > > > > <<< 423 Interval Too Brief: This response won't happen in our example > > scenario, but if it came in response to a reSUBSCRIBE, the > > subscribe usage is not destroyed (or otherwise affected). No > > other usages of the dialog are affected. >>> > > > > In the above Para the meaning of last part of 1st sentence (I mean, the subscribe usage is not destroyed (or otherwise affected)) and 2nd sentence is not clear, both mention the same meaning? Can we make it explicit about what we really mean here ? > > > > Thanks, > > Nataraju A B > > Sonus Networks India Pvt Ltd > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Aug 17 13:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlfO-000547-1W; Thu, 17 Aug 2006 13:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlfM-000540-Mh for sipping@ietf.org; Thu, 17 Aug 2006 13:28:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlfL-0005vI-BZ for sipping@ietf.org; Thu, 17 Aug 2006 13:28:24 -0400 Received: from [64.101.149.196] (dwillis-mb.cisco.com [64.101.149.196]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k7HHUZXd028327 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Aug 2006 12:30:36 -0500 In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C7A5DE9@sonusinmail01.sonusnet.com> References: <70798CF421F00F4DA018059E5B7EEB8C7A5DE9@sonusinmail01.sonusnet.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sipping] bug in rfc-3261 Date: Thu, 17 Aug 2006 12:28:03 -0500 To: "B, Nataraju" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Personally, I think that whole misbegotten table should be logged as =20 a bug in 3261. It confuses more people than Hilbert's Paradox. But I've not yet seem a better way to render that information. If =20 anybody has an idea, please bring it to the table. -- dean On Aug 17, 2006, at 3:49 AM, B, Nataraju wrote: > Hi All, > > > > I did not get many replies. > > Should this be logged as bug against 3261 or not ? > > Thanks, > Nataraju A B > > From: Manjunath Warad [mailto:manjunathwarad@huawei.com] > Sent: Monday, August 14, 2006 3:17 PM > To: B, Nataraju; sipping@ietf.org > Subject: RE: [Sipping] bug in rfc-3261 > > > > Hi, > > Please see inline... > > > > Rgds, > > Manju > > -----Original Message----- > From: B, Nataraju [mailto:bnataraju@sonusnet.com] > Sent: Monday, August 14, 2006 5:22 PM > To: sipping@ietf.org > Subject: [Sipping] bug in rfc-3261 > > Header field where proxy ACK BYE CAN INV OPT REG > > WWW-Authenticate 401 ar - m - m m m > > WWW-Authenticate 407 ar - o - o o o > > Contact 3xx d - o - o o o > > Why proxy column is mentioned as =93ar=94 for WWW-Authenticate in =20 > 401/407. It should have been mentioned as =93r=94 only. In no case =20 > proxy would add the WWW-Authenticate header for responses =20 > 401/407 ?. Does the proxy aggregation considered for this case ? > > Yes you are right! Proxy aggregation is considered here. > > Why proxy is allowed to =93delete only=94 for contact in 3xx response? = =20 > Even it should be allowed to read the contacts in 3xx replies. BTW, =20= > in which scenario it can delete a contact in 3xx response. This =20 > option should have been either =93dr=94 or =93r=94 only depending on = answer =20 > to my previous question. > > Here again, proxy can remove the contact, for which it has already =20 > tried, so that upstream proxies need not try on those contacts =20 > again. This technique is used when proxy chose 3xx as best response =20= > to be forwarded for upstream proxies. So, I think "adr" need to be =20 > used here as this header can be aggregated to form the final 3xx =20 > response if more than 1 is present. > > [ABN] this one should be considered bug against rfc-3261. > > Please let me know, if my interpretation is wrong. > > Thanks, > > Nataraju A B > > Sonus Networks Ind Pvt Ltd > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Aug 17 16:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDolQ-0004rF-Jc; Thu, 17 Aug 2006 16:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDolO-0004qS-3r; Thu, 17 Aug 2006 16:46:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDo5u-0006og-IA; Thu, 17 Aug 2006 16:03:58 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDnsu-0006Bk-Di; Thu, 17 Aug 2006 15:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1571817591; Thu, 17 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GDnsP-0007fZ-Ln; Thu, 17 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 17 Aug 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-toip-06.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Framework for real-time text over IP using the Session Initiation Protocol (SIP) Author(s) : A. Van Wijk, G. Gybels Filename : draft-ietf-sipping-toip-06.txt Pages : 27 Date : 2006-8-17 This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-toip-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-toip-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-17134336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-toip-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-toip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-17134336.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --NextPart-- From sipping-bounces@ietf.org Thu Aug 17 19:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDr7d-0003pc-06; Thu, 17 Aug 2006 19:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDr7c-0003pN-0Z for sipping@ietf.org; Thu, 17 Aug 2006 19:17:56 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDr7a-0007ut-NL for sipping@ietf.org; Thu, 17 Aug 2006 19:17:55 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k7HNHqUX020944 for ; Thu, 17 Aug 2006 23:17:53 GMT Subject: [Sipping] Updated Draft: SIP Performance Metrics From: Daryl Malas To: sipping@ietf.org Content-Type: text/plain Date: Thu, 17 Aug 2006 17:16:17 -0600 Message-Id: <1155856577.2258.22.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org To all, I have submitted an updated version of the SIP Performance Metrics draft. I renamed the title to SIP End-to-End Performance Metrics for clarity of scope purposes. The following lists some of the changes to this draft: 1. Clarified scope of the document (see introduction and throughout). 2. Defined new terms such as end-to-end. 3. Removed Average Hops per Session. 4. Completely re-did Average Hops per INVITE to clarify. 5. Updated all flows to be compliant with RFC 3665. 6. Updated terms to be compliant with RFC 3261. 7. I described the metrics for both successful and failed situations. 8. I added flows for redirect scenarios. 9. I added verbiage regarding testing. 10. I added the Registration Request Delay (RRD) metric 11. Finally, I clarified a lot of details throughout the document, trying to alleviate confusion. The draft can be found here: http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-04.txt I would really appreciate feedback and comments on the draft. Thanks...--Daryl _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Aug 17 20:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDs4S-0000SM-73; Thu, 17 Aug 2006 20:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDs4R-0000Ph-E3 for sipping@ietf.org; Thu, 17 Aug 2006 20:18:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDqZD-0003Ng-Fu for sipping@ietf.org; Thu, 17 Aug 2006 18:42:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDqOs-0001BQ-5W for sipping@ietf.org; Thu, 17 Aug 2006 18:31:44 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7HMVbC05347 for ; Thu, 17 Aug 2006 18:31:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 17:31:35 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ready for IESG review?: draft-ietf-sipping-toip-06.txt Thread-Index: AcbCPqMZsf7qrNxhRtO74z1eKlxsIgADJgrg From: "Mary Barnes" To: X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Sipping] Ready for IESG review?: draft-ietf-sipping-toip-06.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Hi all, After posting this question about 7 weeks ago, there was a lively discussion that resulted in agreement on additional editorial changes to this document. The proposed changes were summarized on 7 July 2006:=20 http://www1.ietf.org/mail-archive/web/sipping/current/msg11420.html There was one additional change in section 6.2.5.1, related to the discussion of the "txp" media content attribute in the MMUSIC WG, it was decided to remove the explicit reference in this document.=20 The -06 version contains all those updates, with the diff available at: http://tools.ietf.org/wg/sipping/draft-ietf-sipping-toip/draft-ietf-sipp ing-toip-06-from-05.diff.html We'd like to give folks until 25 Aug 2006 to identify any additional concerns on the readiness of this document.=20 Regards, Mary SIPPING WG co-chair -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, August 17, 2006 2:50 PM To: i-d-announce@ietf.org Cc: sipping@ietf.org Subject: I-D ACTION:draft-ietf-sipping-toip-06.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Framework for real-time text over IP using the Session Initiation Protocol (SIP) Author(s) : A. Van Wijk, G. Gybels Filename : draft-ietf-sipping-toip-06.txt Pages : 27 Date : 2006-8-17 =09 This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-06.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-sipping-toip-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-toip-06.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 18 02:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDxpG-0000Xt-A9; Fri, 18 Aug 2006 02:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDxpE-0000Rd-EO for sipping@ietf.org; Fri, 18 Aug 2006 02:27:24 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDxpE-0008Qo-3O for sipping@ietf.org; Fri, 18 Aug 2006 02:27:24 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k7I6RMjC007701; Fri, 18 Aug 2006 02:27:23 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Aug 2006 02:27:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Aug 2006 11:57:18 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C7A5FD8@sonusinmail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt Thread-Index: AcbB/O3w2bO5pUKoREK2Hq0XQ6js2QAke1iA From: "B, Nataraju" To: "Paul Kyzivat" X-OriginalArrivalTime: 18 Aug 2006 06:27:22.0826 (UTC) FILETIME=[5D4FCAA0:01C6C28F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sipping@ietf.org Subject: [Sipping] RE: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0578228680==" Errors-To: sipping-bounces@ietf.org --===============0578228680== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgdGhpbmtpbmcgbWFraW5nIGl0IGV4cGxpY2l0IHdvdWxkIGJlIGJldHRlci4gDQoNCkF0 IGxlYXN0IHNoYWxsIHdlIG1lbnRpb24gdGhpcyBvbmUgYXMgbm9ybWF0aXZlIGluZm9ybWF0aW9u PyANCk90aGVyd2lzZSBtYW55IG1vcmUgb3RoZXJzIG1pZ2h0IHRoaW5rIHRoZSBzYW1lIHdheSAo d2hpY2ggSSB0aG91Z2h0IGVhcmxpZXIpIGFuZCBkZXZlbG9wIHRoZSBidWdneSBzb2Z0d2FyZS4u LiANCg0KVGhhbmtzLA0KTmF0YXJhanUgQSBCDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28uY29tXQ0KPiBT ZW50OiBUaHVyc2RheSwgQXVndXN0IDE3LCAyMDA2IDY6MjkgUE0NCj4gVG86IEIsIE5hdGFyYWp1 DQo+IENjOiBzaXBwaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU2lwXSBjb21tZW50cyBv biBkcmFmdC1pZXRmLXNpcHBpbmctZGlhbG9ndXNhZ2UtMDIudHh0DQo+IA0KPiANCj4gDQo+IEIs IE5hdGFyYWp1IHdyb3RlOg0KPiA+IFBhdWwsDQo+ID4NCj4gPiBXaGF0IEkgbWVhbnQgdG8gbWVu dGlvbiBoZXJlIHdhcyB0aGF0LCBpbiB0aGUgc2NlbmFyaW9zIHdoaWNoIG1pZ2h0IGxlYWQNCj4g dG8gdGhlc2UgcmVzcG9uc2VzIG11c3QgYmUgYXV0aGVudGljYXRlZCBiZWZvcmUgd2UgY2FsbCBm b3IgdGhpcw0KPiBSZXBvbnNlcy4uLg0KPiA+IAlJIG1lYW4gaWYgd2UgcmVjZWl2ZSBhIE5PVElG WSh1bi1hdXRoZW50aWNhdGVkKSA0MDQgc2hvdWxkIG5vdCBiZQ0KPiBzZW50IG91dCB3aGljaCB3 aWxsIHRlcm1pbmF0ZSB0aGUgZGlhbG9nL3VzYWdlLg0KPiA+DQo+ID4gCQlBdXRoZW50aWNhdGUg dGhlIE5URlkgcmVxdWVzdCBmaXJzdCB0aGVuIG9ubHkgaXQgY291bGQgYmUNCj4gcmVqZWN0ZWQg d2l0aCA0MDQgb3IgYW55IG90aGVyIGFwcHJvcHJpYXRlIHJlcGxpZXMgd2hpY2ggd291bGQgcmVz dWx0IGluDQo+IGRpYWxvZyB0ZXJtaW5hdGlvbi4NCj4gDQo+IElmIEkgdW5kZXJzdGFuZCB5b3Us IHRoaXMgaXMganVzdCBzdGFuZGFyZCBwcm9jZWR1cmUsIGFwcGxpY2FibGUNCj4gcmVnYXJkbGVz cyBvZiBkaWFsb2cgdXNhZ2VzLiBBdXRoZW50aWNhdGlvbiBpcyBzdXBwb3NlZCB0byBiZSBkb25l DQo+IGZpcnN0LCBzbyBubyBleHRyYSBpbmZvcm1hdGlvbiBpcyBnaXZlbiB0byB1bmF1dGhlbnRp Y2F0ZWQgY2FsbGVycy4NCj4gDQo+IAlQYXVsDQo+IA0KPiA+IFRoYW5rcywNCj4gPiBOYXRhcmFq dSBBIEINCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBQ YXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IE1vbmRh eSwgQXVndXN0IDE0LCAyMDA2IDc6MzQgUE0NCj4gPj4gVG86IEIsIE5hdGFyYWp1DQo+ID4+IENj OiBzaXBAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtTaXBdIGNvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtc2lwcGluZy1kaWFsb2d1c2FnZS0wMi50eHQNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4g QiwgTmF0YXJhanUgd3JvdGU6DQo+ID4+DQo+ID4+PiAxLiBTZWMgNCBkZXNjcmliZXMgd2hhdCB0 aGUgZWZmZWN0cyBvbiBkaWFsb2cgYXJlIGFuZCBpdHMgdXNhZ2VzIHdoZW4NCj4gPj4+IHBhcnRp Y3VsYXIgcmVzcG9uc2VzIGFyZSByZWNlaXZlZCBmb3IgTk9USUZZIG1lc3NhZ2UsIHRoZSByZXNw b25zZXMNCj4gNDA0LA0KPiA+Pj4gNDEwLCA0MTYsIGxlYWQgdG8gZGlhbG9nIGFuZCBpdHMgdXNh Z2UgdGVybWluYXRpb24uDQo+ID4+Pg0KPiA+Pj4gICAgICAgYS4gSSBmZWVsIHdlIHNob3VsZCBo YXZlIG1lbnRpb25lZCBPTkxZIHRoZSBhdXRoZW50aWNhdGVkIE5PVElGWQ0KPiA+Pj4gcmVxdWVz dHMgd2lsbCBoYXZlIHRoaXMgZWZmZWN0IG9uIHRoZSBkaWFsb2dzL3VzYWdlcy4gT3RoZXJ3aXNl IGFueQ0KPiA+Pj4gbWlkZGxlIG1lbiBjYW4gdHJhY2UgdGhlIG1lc3NhZ2UgYW5kIHNlbmQgdGhl IE5PVElGWSBtZXNzYWdlcyB3aGljaA0KPiA+Pj4gdGVybWluYXRlIHRoZSBkaWFsb2dzLCB3aGlj aCBpcyB1bmRlc2lyYWJsZSDimLkuIElmIHRoZSBlbnRpdHkgc2VuZGluZw0KPiA+Pj4gTk9USUZZ IHJlYWxseSBpbnRlbmQgdG8gZG8gdGhhdCBpdCBjYW4gcmVzZW5kIE5PVElGWSB3aXRoDQo+IGF1 dGhvcml6YXRpb24NCj4gPj4+IGNyZWRlbnRpYWxzIHdoaWNoIHdpbGwgaGVscCB0byB0ZXJtaW5h dGUgdGhlIGFzc29jaWF0ZWQgZGlhbG9ncy4NCj4gPj4gSSBhZ3JlZSB3ZSB3b3VsZG4ndCB3YW50 IHRvIGVuYWJsZSBhIE1JVE0gYXR0YWNrIGhlcmUuDQo+ID4+DQo+ID4+IEJ1dCBJIHRoaW5rIHRo YXQgaXMgYWxyZWFkeSBjb3ZlcmVkLiBJZiB0aGUgcmVxdWVzdCBpc24ndCBwcm9wZXJseQ0KPiA+ PiBhdXRoZW50aWNhdGVkLCB0aGVuIHRoZSByZXNwb25zZSB3aWxsIGJlIDQwMSwgbm90IDQwNCwg NDEwLCBvciA0MTYuDQo+ID4+DQo+ID4+IAlQYXVsDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4NCj4gPiBTdWJqZWN0Og0KPiA+IFtTaXBdIGNvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtc2lwcGluZy1kaWFsb2d1c2FnZS0wMi50eHQNCj4gPiBGcm9tOg0KPiA+ICJCLCBOYXRh cmFqdSIgPGJuYXRhcmFqdUBzb251c25ldC5jb20+DQo+ID4gRGF0ZToNCj4gPiBNb24sIDE0IEF1 ZyAyMDA2IDEyOjA0OjE5ICswNTMwDQo+ID4gVG86DQo+ID4gPHNpcEBpZXRmLm9yZz4NCj4gPg0K PiA+IFRvOg0KPiA+IDxzaXBAaWV0Zi5vcmc+DQo+ID4NCj4gPg0KPiA+IEhpIFNwYXJrcywNCj4g Pg0KPiA+DQo+ID4NCj4gPiBJIGhhZCBnb25lIHRocm91Z2ggdGhlIGRvY3VtZW50LCBoZXJlIGFy ZSBmZXcgY29tbWVudHMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gTm90ZTogSSBhc3N1bWUgdGhlIGJl aGF2aW9yIG1lbnRpb25lZCBpbiBzZWMgNCBhcHBsaWVzIGJvdGggYXQgY2xpZW50DQo+IHJlY2Vp dmluZyB0aGVzZSByZXNwb25zZXMgKE5vdGlmaWVyKSBhbmQgc2VydmVyIGdlbmVyYXRpbmcgdGhl c2UgcmVwbGllcw0KPiAoU3Vic2NyaWJlcikuIElmIHRoaXMgd2FzIG1lYW50IHRvIGJlIG9ubHkg QCBzZW5kZXIgb2YgTk9USUZZIHNoYWxsIHdlDQo+IG5lZWQgdG8gbWVudGlvbiB0aGUgc2ltaWxh ciBzZXQgb2YgYWN0aW9ucyBAIFN1YnNjcmliZXIgc2lkZSB0b28/DQo+ID4NCj4gPg0KPiA+DQo+ ID4gMS4gU2VjIDQgZGVzY3JpYmVzIHdoYXQgdGhlIGVmZmVjdHMgb24gZGlhbG9nIGFyZSBhbmQg aXRzIHVzYWdlcyB3aGVuDQo+IHBhcnRpY3VsYXIgcmVzcG9uc2VzIGFyZSByZWNlaXZlZCBmb3Ig Tk9USUZZIG1lc3NhZ2UsIHRoZSByZXNwb25zZXMgNDA0LA0KPiA0MTAsIDQxNiwgbGVhZCB0byBk aWFsb2cgYW5kIGl0cyB1c2FnZSB0ZXJtaW5hdGlvbi4NCj4gPg0KPiA+ICAgICAgIGEuIEkgZmVl bCB3ZSBzaG91bGQgaGF2ZSBtZW50aW9uZWQgT05MWSB0aGUgYXV0aGVudGljYXRlZCBOT1RJRlkN Cj4gcmVxdWVzdHMgd2lsbCBoYXZlIHRoaXMgZWZmZWN0IG9uIHRoZSBkaWFsb2dzL3VzYWdlcy4g T3RoZXJ3aXNlIGFueSBtaWRkbGUNCj4gbWVuIGNhbiB0cmFjZSB0aGUgbWVzc2FnZSBhbmQgc2Vu ZCB0aGUgTk9USUZZIG1lc3NhZ2VzIHdoaWNoIHRlcm1pbmF0ZSB0aGUNCj4gZGlhbG9ncywgd2hp Y2ggaXMgdW5kZXNpcmFibGUg4pi5LiBJZiB0aGUgZW50aXR5IHNlbmRpbmcgTk9USUZZIHJlYWxs eQ0KPiBpbnRlbmQgdG8gZG8gdGhhdCBpdCBjYW4gcmVzZW5kIE5PVElGWSB3aXRoIGF1dGhvcml6 YXRpb24gY3JlZGVudGlhbHMNCj4gd2hpY2ggd2lsbCBoZWxwIHRvIHRlcm1pbmF0ZSB0aGUgYXNz b2NpYXRlZCBkaWFsb2dzLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgIGIuIE90aGVyIGFsdGVy bmF0aXZlIHdvdWxkIGJlIHRoYXQgbGV0IHRob3NlIHJlc3BvbnNlcyBoYXZlIG5vDQo+IGVmZmVj dCBvbiB0aGUgZGlhbG9nL3VzYWdlcywgZXZlbnR1YWxseSB0aGUgc3Vic2NyaXB0aW9uIGR1cmF0 aW9uIHdvdWxkDQo+IHRha2UgY2FyZSBvZiBkaWFsb2cgdGVybWluYXRpb24gb3IgdGhlIGFjdHVh bCBlbnRpdHkgd291bGQgdGVybWluYXRlIG9yDQo+IGV4dGVuZCB0aGUgc3Vic2NyaXB0aW9uLiBB bnkgd2F5IHRoZSByZXF1ZXN0IGZyb20gYWN0dWFsIG5vdGlmaWVyIHdvdWxkDQo+IGhhdmUgdGhl IHByb3BlciBVUklzIG9yIGNyZWRlbnRpYWxzIHdoaWNoIHdpbGwgbmV2ZXIgbGVhZCB0byB0aGVz ZQ0KPiByZXNwb25zZXMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIHNhbWUgbG9naWMgd291bGQg bmVlZCB0byBleHRlbmQgZm9yIHJlcGxpZXMgNDgxLCA0ODMsIDQ4NCwgNDg5IGFuZA0KPiA2MDQg YWxzby4NCj4gPg0KPiA+DQo+ID4NCj4gPiAyLiBTZWMgNCBvZiB0aGUgZHJhZnQNCj4gPg0KPiA+ DQo+ID4NCj4gPiAgICAgPDw8ICAgNDIzIEludGVydmFsIFRvbyBCcmllZjogVGhpcyByZXNwb25z ZSB3b24ndCBoYXBwZW4gaW4gb3VyDQo+IGV4YW1wbGUNCj4gPg0KPiA+ICAgICAgIHNjZW5hcmlv LCBidXQgaWYgaXQgY2FtZSBpbiByZXNwb25zZSB0byBhIHJlU1VCU0NSSUJFLCB0aGUNCj4gPg0K PiA+ICAgICAgIHN1YnNjcmliZSB1c2FnZSBpcyBub3QgZGVzdHJveWVkIChvciBvdGhlcndpc2Ug YWZmZWN0ZWQpLiAgTm8NCj4gPg0KPiA+ICAgICAgIG90aGVyIHVzYWdlcyBvZiB0aGUgZGlhbG9n IGFyZSBhZmZlY3RlZC4gPj4+DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgICAgSW4gdGhlIGFib3Zl IFBhcmEgdGhlIG1lYW5pbmcgb2YgbGFzdCBwYXJ0IG9mIDFzdCBzZW50ZW5jZSAoSQ0KPiBtZWFu LCB0aGUgc3Vic2NyaWJlIHVzYWdlIGlzIG5vdCBkZXN0cm95ZWQgKG9yIG90aGVyd2lzZSBhZmZl Y3RlZCkpIGFuZA0KPiAybmQgc2VudGVuY2UgaXMgbm90IGNsZWFyLCBib3RoIG1lbnRpb24gdGhl IHNhbWUgbWVhbmluZz8gQ2FuIHdlIG1ha2UgaXQNCj4gZXhwbGljaXQgYWJvdXQgd2hhdCB3ZSBy ZWFsbHkgbWVhbiBoZXJlID8NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBO YXRhcmFqdSBBIEINCj4gPg0KPiA+IFNvbnVzIE5ldHdvcmtzIEluZGlhIFB2dCBMdGQNCj4gPg0K PiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gVGhpcyBsaXN0IGlz IGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQo+ID4gVXNlIHNp cC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBz aXANCj4gPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUg YXBwbGljYXRpb24gb2Ygc2lwDQoNCg0K --===============0578228680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0578228680==-- From sipping-bounces@ietf.org Fri Aug 18 03:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDygG-0007aX-T9; Fri, 18 Aug 2006 03:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDygG-0007aS-AS for sipping@ietf.org; Fri, 18 Aug 2006 03:22:12 -0400 Received: from mx1.shearar.net ([72.21.63.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDygF-0005F5-3u for sipping@ietf.org; Fri, 18 Aug 2006 03:22:12 -0400 Received: from [196.209.116.126] (helo=wsfrank) by mx1.shearar.net with smtp (Exim 4.52) id 1GDyhN-0002eL-TO for sipping@ietf.org; Fri, 18 Aug 2006 09:23:25 +0200 Message-ID: <006701c6c297$02b8e600$0600000a@wsfrank> From: "Frank Shearar" To: Date: Fri, 18 Aug 2006 09:21:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: -102.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sipping] Minor grammatical nits in draft-ietf-sipping-toip-06 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org Section 5.2.3.2: They are a) "No-gain" codec solution, b) the Cellular Text Telephony Modem (CTM) solution [8] both collectively called "Baudot mode" solution in the USA. should read "They are the a) ...., and b) ..." Section 6.2.5.1: This means that the other user may be used to formal turn taking during the call. should maybe read This means that the textphone user may be used to formal turn taking during the call. Looks good! frank _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Aug 18 09:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE49n-0004Lm-CZ; Fri, 18 Aug 2006 09:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE49l-0004Lh-QV for sipping@ietf.org; Fri, 18 Aug 2006 09:13:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE49j-0000va-BV for sipping@ietf.org; Fri, 18 Aug 2006 09:13:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2006 06:12:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,143,1154934000"; d="scan'208"; a="36879720:sNHT27120270" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7IDCwjL003530; Fri, 18 Aug 2006 09:12:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7IDCwuI020871; Fri, 18 Aug 2006 09:12:58 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 09:12:57 -0400 Received: from [161.44.79.104] ([161.44.79.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 09:12:57 -0400 Message-ID: <44E5BCD9.9050600@cisco.com> Date: Fri, 18 Aug 2006 09:12:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "B, Nataraju" References: <70798CF421F00F4DA018059E5B7EEB8C7A5FD8@sonusinmail01.sonusnet.com> In-Reply-To: <70798CF421F00F4DA018059E5B7EEB8C7A5FD8@sonusinmail01.sonusnet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Aug 2006 13:12:57.0906 (UTC) FILETIME=[06265120:01C6C2C8] DKIM-Signature: a=rsa-sha1; q=dns; l=6646; t=1155906778; x=1156770778; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20comments=20on=20draft-ietf-sipping-dialogusage-02.txt |To:=22B,=20Nataraju=22=20; X=v=3Dcisco.com=3B=20h=3DTH6BmAmf0rRE0cKOJxwAXgTnrbA=3D; b=H06DAAf4Hf0IRQoFMpfz11Joqx6o/+s77Me0ssZdkjpPHad1v/OuOZxfyaZjj+Ys2q5YpuXU 6xCIyeBv1enlVAFcSBp28RYR+NB6y8RgQOmMboeIY9dymfBxI9PPr8Cc; Authentication-Results: rtp-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sipping@ietf.org Subject: [Sipping] Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sipping-bounces@ietf.org B, Nataraju wrote: > I was thinking making it explicit would be better. > > At least shall we mention this one as normative information? > Otherwise many more others might think the same way (which I thought earlier) and develop the buggy software... Well, I *thought* it was clear in 3261. But I went back to check, and it is far from clear. Section 8.2 says: UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). which certainly implies that authentication should be done first. Unfortunately, the subsections that follow this intro don't mention authentication at all. :-( And, this section pertains to requests outside a dialog, so it doesn't really apply anyway. Section 12, which defines behavior for dialog establishment and requests within dialogs doesn't mention authentication or authorization at all. So I guess it isn't at all clear that that if 401 is applicable to a request then it should be issued in preference to 404, 410, or 416, and that this should be true inside a dialog as well as outside. It would be good to get some input from others on this. Paul > Thanks, > Nataraju A B > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, August 17, 2006 6:29 PM >> To: B, Nataraju >> Cc: sipping@ietf.org >> Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt >> >> >> >> B, Nataraju wrote: >>> Paul, >>> >>> What I meant to mention here was that, in the scenarios which might lead >> to these responses must be authenticated before we call for this >> Reponses... >>> I mean if we receive a NOTIFY(un-authenticated) 404 should not be >> sent out which will terminate the dialog/usage. >>> Authenticate the NTFY request first then only it could be >> rejected with 404 or any other appropriate replies which would result in >> dialog termination. >> >> If I understand you, this is just standard procedure, applicable >> regardless of dialog usages. Authentication is supposed to be done >> first, so no extra information is given to unauthenticated callers. >> >> Paul >> >>> Thanks, >>> Nataraju A B >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Monday, August 14, 2006 7:34 PM >>>> To: B, Nataraju >>>> Cc: sip@ietf.org >>>> Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt >>>> >>>> >>>> >>>> B, Nataraju wrote: >>>> >>>>> 1. Sec 4 describes what the effects on dialog are and its usages when >>>>> particular responses are received for NOTIFY message, the responses >> 404, >>>>> 410, 416, lead to dialog and its usage termination. >>>>> >>>>> a. I feel we should have mentioned ONLY the authenticated NOTIFY >>>>> requests will have this effect on the dialogs/usages. Otherwise any >>>>> middle men can trace the message and send the NOTIFY messages which >>>>> terminate the dialogs, which is undesirable â˜¹. If the entity sending >>>>> NOTIFY really intend to do that it can resend NOTIFY with >> authorization >>>>> credentials which will help to terminate the associated dialogs. >>>> I agree we wouldn't want to enable a MITM attack here. >>>> >>>> But I think that is already covered. If the request isn't properly >>>> authenticated, then the response will be 401, not 404, 410, or 416. >>>> >>>> Paul >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Subject: >>> [Sip] comments on draft-ietf-sipping-dialogusage-02.txt >>> From: >>> "B, Nataraju" >>> Date: >>> Mon, 14 Aug 2006 12:04:19 +0530 >>> To: >>> >>> >>> To: >>> >>> >>> >>> Hi Sparks, >>> >>> >>> >>> I had gone through the document, here are few comments. >>> >>> >>> >>> Note: I assume the behavior mentioned in sec 4 applies both at client >> receiving these responses (Notifier) and server generating these replies >> (Subscriber). If this was meant to be only @ sender of NOTIFY shall we >> need to mention the similar set of actions @ Subscriber side too? >>> >>> >>> 1. Sec 4 describes what the effects on dialog are and its usages when >> particular responses are received for NOTIFY message, the responses 404, >> 410, 416, lead to dialog and its usage termination. >>> a. I feel we should have mentioned ONLY the authenticated NOTIFY >> requests will have this effect on the dialogs/usages. Otherwise any middle >> men can trace the message and send the NOTIFY messages which terminate the >> dialogs, which is undesirable â˜¹. If the entity sending NOTIFY really >> intend to do that it can resend NOTIFY with authorization credentials >> which will help to terminate the associated dialogs. >>> >>> >>> b. Other alternative would be that let those responses have no >> effect on the dialog/usages, eventually the subscription duration would >> take care of dialog termination or the actual entity would terminate or >> extend the subscription. Any way the request from actual notifier would >> have the proper URIs or credentials which will never lead to these >> responses. >>> >>> >>> The same logic would need to extend for replies 481, 483, 484, 489 and >> 604 also. >>> >>> >>> 2. Sec 4 of the draft >>> >>> >>> >>> <<< 423 Interval Too Brief: This response won't happen in our >> example >>> scenario, but if it came in response to a reSUBSCRIBE, the >>> >>> subscribe usage is not destroyed (or otherwise affected). No >>> >>> other usages of the dialog are affected. >>> >>> >>> >>> >>> In the above Para the meaning of last part of 1st sentence (I >> mean, the subscribe usage is not destroyed (or otherwise affected)) and >> 2nd sentence is not clear, both mention the same meaning? Can we make it >> explicit about what we really mean here ? >>> >>> >>> Thanks, >>> >>> Nataraju A B >>> >>> Sonus Networks India Pvt Ltd >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Aug 19 23:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEe3C-0005k7-NP; Sat, 19 Aug 2006 23:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEe3B-0005jz-TA for sipping@ietf.org; Sat, 19 Aug 2006 23:32:37 -0400 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEe39-00029K-PJ for sipping@ietf.org; Sat, 19 Aug 2006 23:32:37 -0400 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id k7K3bu0j012634 for sipping@ietf.org; Sun, 20 Aug 2006 06:37:56 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id k7K3btA2012628 for ; Sun, 20 Aug 2006 06:37:55 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 20 Aug 2006 06:32:22 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP fmtp video negotiation Thread-Index: Aca7hWc1VCvzL/ZeSWy9gyp0vEKoYgDC5BBAAV4LM2A= From: "Erez Morabia" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Subject: [Sipping] SDP fmtp video negotiation X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1237231808==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1237231808== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C409.4DA4A945" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C409.4DA4A945 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm trying to find here a common base for the negotiation regarding the different codecs on the video media side. It seems that when you advertise fmtp, you declare what you are willing to receive (decoder capabilities) and implicitly what you prefer to send (except for some H264 exceptions). The thumb rule is that when receiving an offer, and there is intersection between the offerer and offeree capabilities, then video channels can be opened in both directions.=20 Is my observation correct? =20 Example: Alice supports QCIF(MPI=3D2) Maximum-Bit=3DRate=3D256Kbps Bob supports CIF(MPI=3D1) QCIF(MPI=3D1) Maximum-Bit=3DRate=3D128Kbps =20 Scenario 1: Alice offers: QCIF(MPI=3D2) Maximum-Bit=3DRate=3D256Kbps Bob answers: QCIF(MPI=3D2) Maximum-Bit=3DRate=3D128Kbps (or CIF(MPI=3D1) QCIF(MPI=3D1) Maximum-Bit=3DRate=3D128Kbps). Is that a correct negotiation? =20 Scenario 2: Bob offers CIF(MPI=3D1) QCIF(MPI=3D1) Maximum-Bit=3DRate=3D128Kbps. Alice answers: QCIF(MPI=3D2) Maximum-Bit=3DRate=3D128Kbps (or = QCIF(MPI=3D2) Maximum-Bit=3DRate=3D256Kbps). Is that a correct negotiation? =20 In both scenarios, both incoming and outgoing channels should be opened correctly with QCIF(MPI=3D2) Maximum-Bit=3DRate=3D128Kbps. =20 BTW The drafts/RFCs I'm using are: H.261: draft-ietf-avt-rfc2032-bis-13.txt H.263: draft-koskelainen-sdp263-01.txt (I'm not sure about that one, does the H.263+ draft overrides it?) H.263+: draft-ietf-avt-rfc2429-bis-09.txt H.264: RFC 3984 =20 Thanks, Erez =20 ------_=_NextPart_001_01C6C409.4DA4A945 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I’m trying to find here a common base for the negotiation regarding the different codecs on the video media = side.

It seems that when you advertise fmtp, you declare = what you are willing to receive (decoder capabilities) and implicitly what you = prefer to send (except for some H264 exceptions).

The thumb rule is that when receiving an offer, and = there is intersection between the offerer and offeree capabilities, then video = channels can be opened in both directions.

Is my observation = correct?

Example:

Alice supports QCIF(MPI=3D2) Maximum-Bit=3DRate=3D256Kbps

Bob supports CIF(MPI=3D1) QCIF(MPI=3D1) = Maximum-Bit=3DRate=3D128Kbps

Scenario 1:

Alice offers: QCIF(MPI=3D2) Maximum-Bit=3DRate=3D256Kbps

Bob answers: QCIF(MPI=3D2) = Maximum-Bit=3DRate=3D128Kbps (or CIF(MPI=3D1) QCIF(MPI=3D1) = Maximum-Bit=3DRate=3D128Kbps).

Is that a correct = negotiation?

Scenario 2:

Bob offers CIF(MPI=3D1) QCIF(MPI=3D1) = Maximum-Bit=3DRate=3D128Kbps.

Alice answers: QCIF(MPI=3D2) Maximum-Bit=3DRate=3D128Kbps (or QCIF(MPI=3D2) = Maximum-Bit=3DRate=3D256Kbps).

Is that a correct = negotiation?

In both scenarios, both incoming and outgoing = channels should be opened correctly with QCIF(MPI=3D2) = Maximum-Bit=3DRate=3D128Kbps.

BTW

The drafts/RFCs I’m using = are:

H.261: = draft-ietf-avt-rfc2032-bis-13.txt

H.263: draft-koskelainen-sdp263-01.txt (I’m not = sure about that one, does the H.263+ draft overrides = it?)

H.263+: = draft-ietf-avt-rfc2429-bis-09.txt

H.264: RFC 3984

Thanks,

Erez

------_=_NextPart_001_01C6C409.4DA4A945-- --===============1237231808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1237231808==-- From sipping-bounces@ietf.org Mon Aug 21 17:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFH5f-0007gd-1b; Mon, 21 Aug 2006 17:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFH5d-0007gR-Eh for sipping@ietf.org; Mon, 21 Aug 2006 17:13:45 -0400 Received: from nat.stoke.com ([209.78.40.100] helo=trio.stoke.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFH5b-0004Dv-Ra for sipping@ietf.org; Mon, 21 Aug 2006 17:13:45 -0400 Received: from us.stoke.com (minsk.us.stoke.com [172.16.4.20]) by trio.stoke.com (8.13.3/8.13.3) with ESMTP id k7LLDhAr033389 for ; Mon, 21 Aug 2006 14:13:43 -0700 (PDT) (envelope-from yafan@stoke.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Aug 2006 14:15:32 -0700 Message-ID: <23EECEC9B06584478B1C9E38C253D35F74ACF4@minsk.us.stoke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fixed Mobile Convergence (draft-yafan-fmc-arch-00.txt) Thread-Index: AcbFZq+8XXo8hqTMRregC7/hP3Ig9gAAAPvw From: "Yafan An" To: X-Virus-Scanned: ClamAV 0.88/1702/Mon Aug 21 08:23:21 2006 on trio.stoke.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-arch-00.txt) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697764581==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0697764581== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C566.EFB5ADF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C566.EFB5ADF5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Sipping Enthusiasts: If you have not noticed the ietf drafts, I'd like to invite you to read and comment on the submitted draft. You can send your comments to me or the sipping list. Thank you. Yafan Title : An Architecture Framework for Fixed Mobile Convergence Using SIP as Access Call Control Protocol Author(s) : Y. An Filename : draft-yafan-fmc-arch-00.txt Pages : 32 Date : 2006-7-28 =09 This document describes an architecture framework for achieving converged mobile services across alternative radio access networks (GAN, or Generic Access Network), such as WLAN, WiMax, and the cellular network, while utilizing SIP for media session control between the dual mode handset (DMH) and a network SIP proxy. The key benefits of this architecture include (1) fast and flexible service deployment in the IP domain, and (2) allow seamless voice call continuity services across IP and circuit-switched cellular domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yafan-fmc-arch-00.txt YAFAN AN - CHIEF ARCHITCET=20 T: 408.855.2957 M: 510.386.2647 F: 408.855.2978 =20 SERVICES WITHOUT BOUNDARIES =09 ------_=_NextPart_001_01C6C566.EFB5ADF5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fixed Mobile Convergence (draft-yafan-fmc-arch-00.txt)

Dear = Sipping Enthusiasts:

If = you have not noticed the ietf drafts, I’d like to = invite you to read and comment on the submitted draft. You can send your = comments to me or the sipping list.

Thank = you.

Yafan

Title = : An Architecture = Framework for Fixed Mobile Convergence Using SIP as = Access Call Control Protocol

Author(s) : Y. = An

Filename = : draft-yafan-fmc-arch-00.txt

Pages = : 32

Date = : 2006-7-28

This document describes an architecture framework for = achieving

converged mobile services across alternative radio access = networks

(GAN, or Generic Access Network), such as WLAN, WiMax, and = the

cellular network, while utilizing SIP for media session = control

between the dual mode handset (DMH) and a network SIP proxy. The key

benefits of this architecture include (1) fast and flexible = service

deployment in the IP domain, and (2) allow seamless voice = call

continuity services across IP and circuit-switched cellular = domains.

A URL for this Internet-Draft is:

= http://www.ietf.org/internet-drafts/draft-yafan-fmc-arch-00.txt

        YAFAN AN – CHIEF ARCHITCET
T: 408.855.2957  M: 510.386.2647  F: = 408.855.2978
SERVICES = WITHOUT BOUNDARIES

------_=_NextPart_001_01C6C566.EFB5ADF5-- --===============0697764581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0697764581==-- From sipping-bounces@ietf.org Mon Aug 21 20:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKGA-0006me-5q; Mon, 21 Aug 2006 20:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKG8-0006mZ-PN for sipping@ietf.org; Mon, 21 Aug 2006 20:36:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHFn-0007dv-1n for sipping@ietf.org; Mon, 21 Aug 2006 17:24:15 -0400 Received: from nat.stoke.com ([209.78.40.100] helo=trio.stoke.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFH49-0002o7-Ed for sipping@ietf.org; Mon, 21 Aug 2006 17:12:15 -0400 Received: from us.stoke.com (minsk.us.stoke.com [172.16.4.20]) by trio.stoke.com (8.13.3/8.13.3) with ESMTP id k7LLBuTS033371 for ; Mon, 21 Aug 2006 14:12:02 -0700 (PDT) (envelope-from yafan@stoke.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Aug 2006 14:13:45 -0700 Message-ID: <23EECEC9B06584478B1C9E38C253D35F74ACF2@minsk.us.stoke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) Thread-Index: AcbFZq+8XXo8hqTMRregC7/hP3Ig9g== From: "Yafan An" To: X-Virus-Scanned: ClamAV 0.88/1702/Mon Aug 21 08:23:21 2006 on trio.stoke.com X-Virus-Status: Clean X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Subject: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0146759010==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0146759010== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C566.B00DC507" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C566.B00DC507 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Sipping Enthusiasts: If you have not noticed the ietf drafts, I'd like to invite you to read and comment on the submitted draft. You can send your comments to me or the sipping list. Thank you. Yafan Title : Mobile Assisted Handover across VoIP and Cellular Domains Using SIP as Access Call Control Author(s) : Y. An Filename : draft-yafan-fmc-mancho-00.txt Pages : 61 Date : 2006-7-31 =09 This document describes the use of SIP between the dual mode handset (DMH) and the mobility SIP proxy to enable network controlled handovers across voice over IP (VoIP) and cellular networks. The mobility SIP proxy has a peering relationship with the cellular network. Mobile assisted and network controlled handovers require the exchange of cellular radio parameters between the DMH and the mobility SIP proxy. The set of cellular related parameters is collectively called Session Handover Protocol (SHP). The SHP is a residual protocol of SIP, where all of its messages are transported as MIME attachment to SIP messages. This document describes the requirements, various SIP message flows for cross-domain roaming and bidirectional handovers between VoIP and cellular domains, and detailed specification of the residual SHP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yafan-fmc-mancho-00.txt YAFAN AN - CHIEF ARCHITCET=20 T: 408.855.2957 M: 510.386.2647 F: 408.855.2978 =20 SERVICES WITHOUT BOUNDARIES =09 ------_=_NextPart_001_01C6C566.B00DC507 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt)

Dear = Sipping = Enthusiasts:

If = you have not noticed the ietf drafts, I’d like to invite you to = read and comment on the submitted draft. You can send your comments = to me or the sipping list.

Thank = you.

Yafan

Title = : Mobile Assisted Handover across VoIP and Cellular = Domains Using SIP as Access Call Control

Author(s) : Y. = An

Filename = : draft-yafan-fmc-mancho-00.txt

Pages = : 61

Date = : 2006-7-31

This document describes the use of SIP between the dual mode = handset

(DMH) and the mobility SIP proxy to enable network = controlled

handovers across voice over IP (VoIP) and cellular networks. = The

mobility SIP proxy has a peering relationship with the = cellular

network. Mobile assisted and network controlled handovers = require

the exchange of cellular radio parameters between the DMH and = the

mobility SIP proxy. The set of cellular related parameters = is

collectively called Session Handover Protocol (SHP). The SHP = is a

residual protocol of SIP, where all of its messages are = transported

as MIME attachment to SIP messages.

This document describes the requirements, various SIP message = flows

for cross-domain roaming and bidirectional handovers between VoIP = and

cellular domains, and detailed specification of the residual = SHP

protocol.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-yafan-fmc-mancho-00.txt

        YAFAN AN – CHIEF ARCHITCET
T: 408.855.2957  M: 510.386.2647  F: = 408.855.2978
SERVICES = WITHOUT BOUNDARIES

------_=_NextPart_001_01C6C566.B00DC507-- --===============0146759010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0146759010==-- From sipping-bounces@ietf.org Mon Aug 21 21:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKpu-0002kw-AV; Mon, 21 Aug 2006 21:13:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKps-0002kq-H0 for sipping@ietf.org; Mon, 21 Aug 2006 21:13:44 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFKpq-0005FY-Ld for sipping@ietf.org; Mon, 21 Aug 2006 21:13:44 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Mon, 21 Aug 2006 18:13:41 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k7M1BbBl007575; Mon, 21 Aug 2006 18:11:39 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k7M1BtRE013556; Mon, 21 Aug 2006 18:13:33 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 18:13:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) Date: Mon, 21 Aug 2006 18:13:31 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22113AC5@namail5.corp.adobe.com> In-Reply-To: <23EECEC9B06584478B1C9E38C253D35F74ACF2@minsk.us.stoke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) Thread-Index: AcbFZq+8XXo8hqTMRregC7/hP3Ig9gAHPdRg From: "Henry Sinnreich" To: "Yafan An" , X-OriginalArrivalTime: 22 Aug 2006 01:13:32.0498 (UTC) FILETIME=[2F36C320:01C6C588] X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0120305040==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0120305040== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C588.2EA8B596" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C588.2EA8B596 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yafan, =20 I am not sure if it is right to have only the limiting assumptions in the I-D: =20 - The 'network' is in control of the handover decision and not the user, - The end user has no control over choosing the network or service provider, - Other networks such as Wi-Fi and WiMAX are not considered where the end user may want to switch to. =20 Last but not least, the Internet point of view is of interest in the IETF. IMHO, 3G is only one of the access options to the Internet ("the Internet is THE service") and the user must have choices and control to exercise them. =20 Thanks, Henry =20 ________________________________ From: Yafan An [mailto:yafan@stoke.com]=20 Sent: Monday, August 21, 2006 4:14 PM To: sipping@ietf.org Subject: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) =20 Dear Sipping Enthusiasts: If you have not noticed the ietf drafts, I'd like to invite you to read and comment on the submitted draft. You can send your comments to me or the sipping list. Thank you. Yafan =20 Title : Mobile Assisted Handover across VoIP and Cellular Domains Using SIP as Access Call Control Author(s) : Y. An Filename : draft-yafan-fmc-mancho-00.txt Pages : 61 Date : 2006-7-31 =20 This document describes the use of SIP between the dual mode handset (DMH) and the mobility SIP proxy to enable network controlled handovers across voice over IP (VoIP) and cellular networks. The mobility SIP proxy has a peering relationship with the cellular network. Mobile assisted and network controlled handovers require the exchange of cellular radio parameters between the DMH and the mobility SIP proxy. The set of cellular related parameters is collectively called Session Handover Protocol (SHP). The SHP is a residual protocol of SIP, where all of its messages are transported as MIME attachment to SIP messages. This document describes the requirements, various SIP message flows for cross-domain roaming and bidirectional handovers between VoIP and cellular domains, and detailed specification of the residual SHP protocol. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yafan-fmc-mancho-00.txt =20 =20 YAFAN AN - CHIEF ARCHITCET T: 408.855.2957 M: 510.386.2647 F: 408.855.2978 =20 SERVICES WITHOUT BOUNDARIES =20 ------_=_NextPart_001_01C6C588.2EA8B596 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt)

Yafan,

I am not sure if it is right to = have only the limiting assumptions in the I-D:

- The ‘network’ is in = control of the handover decision and not the user,

- The end user has no control over choosing the network or service provider,

- Other networks such as Wi-Fi and = WiMAX are not considered where the end user may want to switch = to.

Last but not least, the Internet = point of view is of interest in the IETF. IMHO, 3G is only one of the access = options to the Internet (“the Internet is THE service”) and the user = must have choices and control to exercise them.

Thanks, = Henry

From: Yafan = An [mailto:yafan@stoke.com]
Sent: Monday, August 21, = 2006 4:14 PM
To: sipping@ietf.org
Subject: [Sipping] Fixed = Mobile Convergence (draft-yafan-fmc-mancho-00.txt)

Dear Sipping Enthusiasts:

If you have not noticed the ietf drafts, I’d like to invite you to read = and comment on the submitted draft. You can send your comments = to me or the sipping list.

Thank you.

Yafan

Title : Mobile = Assisted Handover across VoIP and Cellular Domains Using SIP as Access Call = Control

Author(s) = : Y. An

Filename : draft-yafan-fmc-mancho-00.txt

Pages : = 61

Date : = 2006-7-31

This document describes the use of SIP between the dual = mode handset

(DMH) and the mobility SIP proxy to enable network = controlled

handovers across voice over IP (VoIP) and cellular networks. The

mobility SIP proxy has a peering relationship with the = cellular

network. Mobile assisted and network controlled handovers = require

the exchange of cellular radio parameters between the DMH = and the

mobility SIP proxy. The set of cellular related = parameters is

collectively called Session Handover Protocol = (SHP). The SHP is a

residual protocol of SIP, where all of its messages = are transported

as MIME attachment to SIP = messages.

This document describes the requirements, various SIP = message flows

for cross-domain roaming and bidirectional handovers = between VoIP and

cellular domains, and detailed specification of the = residual SHP

protocol.

A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-yafan-fmc-mancho-00.txt

      &n= bsp; YAFAN AN – CHIEF ARCHITCET
T: 408.855.2957  M: 510.386.2647  F: 408.855.2978
SERVICES WITHOUT = BOUNDARIES

------_=_NextPart_001_01C6C588.2EA8B596-- --===============0120305040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0120305040==-- From sipping-bounces@ietf.org Tue Aug 22 01:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOkd-0003fs-9n; Tue, 22 Aug 2006 01:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFOka-0003eG-N8 for sipping@ietf.org; Tue, 22 Aug 2006 01:24:32 -0400 Received: from nat.stoke.com ([209.78.40.100] helo=trio.stoke.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFOWR-0000k6-E0 for sipping@ietf.org; Tue, 22 Aug 2006 01:09:57 -0400 Received: from us.stoke.com (minsk.us.stoke.com [172.16.4.20]) by trio.stoke.com (8.13.3/8.13.3) with ESMTP id k7M59ktl040612 for ; Mon, 21 Aug 2006 22:09:46 -0700 (PDT) (envelope-from yafan@stoke.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) Date: Mon, 21 Aug 2006 22:11:34 -0700 Message-ID: <23EECEC9B06584478B1C9E38C253D35F74AD2B@minsk.us.stoke.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) Thread-Index: AcbFZq+8XXo8hqTMRregC7/hP3Ig9gAHPdRgAAjOopA= From: "Yafan An" To: "Henry Sinnreich" , X-Virus-Scanned: ClamAV 0.88/1705/Mon Aug 21 18:18:23 2006 on trio.stoke.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group $applications of SIP$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1286489110==" Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1286489110== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C5A9.70C2F01D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C5A9.70C2F01D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Henry, =20 The term "network-controlled" handovers refers to the fact that a network element is in control of the execution of the handover procedures. This is in contrast to other schemes where, e.g. the handset is in control of the handover procedures. =20 User selection of which access network to use for access can well be exercised by a policy-based (or other means) on the handset or on a network element. Such control may provision that an on-going session can be handed over from WLAN to/from cellular by a network element according to certain threshold settings. =20 These two types of "controls" do not necessarily conflict with each other. =20 How the control is exercised may be determined by many factors. In GSM, handover is network-controlled (and mobile assisted). =20 Thanks, Yafan =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, August 21, 2006 6:14 PM To: Yafan An; sipping@ietf.org Subject: RE: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) =20 Yafan, =20 I am not sure if it is right to have only the limiting assumptions in the I-D: =20 - The 'network' is in control of the handover decision and not the user, - The end user has no control over choosing the network or service provider, - Other networks such as Wi-Fi and WiMAX are not considered where the end user may want to switch to. =20 Last but not least, the Internet point of view is of interest in the IETF. IMHO, 3G is only one of the access options to the Internet ("the Internet is THE service") and the user must have choices and control to exercise them. =20 Thanks, Henry =20 ________________________________ From: Yafan An [mailto:yafan@stoke.com]=20 Sent: Monday, August 21, 2006 4:14 PM To: sipping@ietf.org Subject: [Sipping] Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt) =20 Dear Sipping Enthusiasts: If you have not noticed the ietf drafts, I'd like to invite you to read and comment on the submitted draft. You can send your comments to me or the sipping list. Thank you. Yafan =20 Title : Mobile Assisted Handover across VoIP and Cellular Domains Using SIP as Access Call Control Author(s) : Y. An Filename : draft-yafan-fmc-mancho-00.txt Pages : 61 Date : 2006-7-31 =20 This document describes the use of SIP between the dual mode handset (DMH) and the mobility SIP proxy to enable network controlled handovers across voice over IP (VoIP) and cellular networks. The mobility SIP proxy has a peering relationship with the cellular network. Mobile assisted and network controlled handovers require the exchange of cellular radio parameters between the DMH and the mobility SIP proxy. The set of cellular related parameters is collectively called Session Handover Protocol (SHP). The SHP is a residual protocol of SIP, where all of its messages are transported as MIME attachment to SIP messages. This document describes the requirements, various SIP message flows for cross-domain roaming and bidirectional handovers between VoIP and cellular domains, and detailed specification of the residual SHP protocol. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yafan-fmc-mancho-00.txt =20 =20 YAFAN AN - CHIEF ARCHITCET T: 408.855.2957 M: 510.386.2647 F: 408.855.2978 =20 SERVICES WITHOUT BOUNDARIES =20 ------_=_NextPart_001_01C6C5A9.70C2F01D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fixed Mobile Convergence (draft-yafan-fmc-mancho-00.txt)

Henry,

The term = “network-controlled” handovers refers to the fact that a network element is in control of the execution of the handover procedures. This is in contrast to other = schemes where, e.g. the handset is in control of the handover = procedures.

User selection of which access = network to use for access can well be exercised by a policy-based (or other means) = on the handset or on a network element. Such control may provision that an = on-going session can be handed over from WLAN to/from cellular by a network = element according to certain threshold settings.

These two types of = “controls” do not necessarily conflict with each = other.

How the control is exercised may be determined by many factors. In GSM, handover is network-controlled (and = mobile assisted).

Thanks,

Yafan

From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Monday, August 21, = 2006 6:14 PM
To: Yafan An; sipping@ietf.org
Subject: RE: [Sipping] = Fixed Mobile Convergence = (draft-yafan-fmc-mancho-00.txt)

Yafan,

I am not sure if it is right to = have only the limiting assumptions in the I-D:

- The ‘network’ is in = control of the handover decision and not the user,

- The end user has no control over choosing the network or service provider,

- Other networks such as Wi-Fi and = WiMAX are not considered where the end user may want to switch = to.

Thanks, = Henry

From: = Yafan An [mailto:yafan@stoke.com]
Sent: Monday, August 21, = 2006 4:14 PM
To: sipping@ietf.org
Subject: [Sipping] Fixed = Mobile Convergence (draft-yafan-fmc-mancho-00.txt)

Dear Sipping Enthusiasts:

If you have not noticed the ietf drafts, I’d like to invite you to = read and comment on the submitted draft. You can send your comments = to me or the sipping list.

Thank you.

Yafan

Title : Mobile Assisted = Handover across VoIP and Cellular Domains Using SIP as Access Call = Control