Re: [Sip] Encryption in SIP

From exim@www1.ietf.org Mon Dec 1 00:12:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25630 for ; Mon, 1 Dec 2003 00:12:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQgM6-0002Op-2y for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 00:12:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB15CIbm009219 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 00:12:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQgLp-0002Nx-Ao; Mon, 01 Dec 2003 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQgLm-0002Nh-Rh for sip@optimus.ietf.org; Mon, 01 Dec 2003 00:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25615 for ; Mon, 1 Dec 2003 00:11:43 -0500 (EST) From: kowsalya@npd.hcltech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQgLk-0002wl-00 for sip@ietf.org; Mon, 01 Dec 2003 00:11:56 -0500 Received: from [203.199.199.232] (helo=hclnpd.hclt-guindy.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AQgLj-0002wf-00 for sip@ietf.org; Mon, 01 Dec 2003 00:11:55 -0500 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt-guindy.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VL2HDPQC; Mon, 1 Dec 2003 10:41:47 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 10:41:25 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9A99EB4@PILEX> To: gktvm2@yahoo.com, sip@ietf.org Subject: RE: [Sip] Query on PRACK Date: Mon, 1 Dec 2003 10:41:25 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B7C9.91902B80" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3B7C9.91902B80 Content-Type: text/plain; charset="iso-8859-1" Gokul, PRACK is just like any other non-INVITE transaction and hence does not require an ACK by UAC. 1. UAC sends an INVITE 2. UAS responds with a reliable provisional response 3. UAC sends a PRACK 4. UAS responds to PRACK with a 200 OK 5. UAS sends 200 OK for INVITE 6. UAC sends ACK for the original INVITE transaction Thanks Kowsalya -----Original Message----- From: Gokul Krishnan [mailto:gktvm2@yahoo.com] Sent: Saturday, November 29, 2003 5:44 PM To: sip@ietf.org Subject: [Sip] Query on PRACK Hi All, Does PRACK trigger another 2XX response ? If yes, does that mean UAC should send an ACK? Can any one please provide a message sequence flow? If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. (RFC 3262, Page 5) Thanks and Regards Gokul _____ Do you Yahoo!? Free Pop-Up Blocker - Get it now ------_=_NextPart_001_01C3B7C9.91902B80 Content-Type: text/html; charset="iso-8859-1"

Gokul,

PRACK is just like any other non-INVITE transaction and hence does not require an ACK by UAC.

1. UAC sends an INVITE

2. UAS responds with a reliable provisional response

3. UAC sends a PRACK

4. UAS responds to PRACK with a 200 OK

5. UAS sends 200 OK for INVITE

6. UAC sends ACK for the original INVITE transaction

Thanks

Kowsalya

-----Original Message-----
From: Gokul Krishnan [mailto:gktvm2@yahoo.com]
Sent: Saturday, November 29, 2003 5:44 PM
To: sip@ietf.org
Subject: [Sip] Query on PRACK

Hi All,

Does PRACK trigger another 2XX response ? If yes, does that mean UAC should send an ACK? Can any one please provide a message sequence flow?

If a PRACK request is received by the UA core that does not

match any unacknowledged reliable provisional response, the

UAS MUST respond to the PRACK with a 481 response. If the

PRACK does match an unacknowledged reliable provisional

response, it MUST be responded to with a 2xx response.

(RFC 3262, Page 5)

Thanks and Regards

Gokul

Do you Yahoo!?
Free Pop-Up Blocker - Get it now

------_=_NextPart_001_01C3B7C9.91902B80-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 09:20:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11323 for ; Mon, 1 Dec 2003 09:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQouS-0001Lj-Cz for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EKK2V005127 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQouA-0001JW-Pv; Mon, 01 Dec 2003 09:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQotj-0001IY-QP for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:19:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11297 for ; Mon, 1 Dec 2003 09:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoti-0002Hv-00 for sip@ietf.org; Mon, 01 Dec 2003 09:19:34 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1AQoth-0002Hs-00 for sip@ietf.org; Mon, 01 Dec 2003 09:19:33 -0500 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA19403 for ; Mon, 1 Dec 2003 09:19:32 -0500 (EST) From: "Tolga Asveren" To: Date: Mon, 1 Dec 2003 09:18:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EA_01C3B7EC.25B7C030" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <50D40047DC73D611BDA60050BAC4EDD9A99EB4@PILEX> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] remote terget update Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_01EA_01C3B7EC.25B7C030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit (due to no response in sip-implementors list switching to sip list) If a reINVITE with target refresh rejected, should remote target reverted back to its original value before that reINVITE is received? Tolga ------=_NextPart_000_01EA_01C3B7EC.25B7C030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(due to no=20 response in sip-implementors list switching to sip = list)

If a=20 reINVITE with target refresh rejected, should remote target reverted = back to its=20 original value before that reINVITE is received?

=20 Tolga

------=_NextPart_000_01EA_01C3B7EC.25B7C030-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 09:33:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12118 for ; Mon, 1 Dec 2003 09:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp6p-0002Dy-Lp for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EX77S008532 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:33:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp6j-0002CP-70; Mon, 01 Dec 2003 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp5w-000262-JW for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:32:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12025 for ; Mon, 1 Dec 2003 09:31:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQp5u-0002eX-00 for sip@ietf.org; Mon, 01 Dec 2003 09:32:10 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AQp5u-0002ap-00 for sip@ietf.org; Mon, 01 Dec 2003 09:32:10 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hB1EVVZA008159; Mon, 1 Dec 2003 08:31:31 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 08:31:30 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8666C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , fluffy@cisco.com, vkg@lucent.com Cc: sip@ietf.org Subject: RE: [Sip] SCTP and TLS Date: Wed, 26 Nov 2003 12:26:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I thought of throwing that in as another example of a kind of change that isn't backwards compatible. The problem is, keeping the necessary state also disqualified it from being elegant, so I didn't see any advantage that made it worth mentioning. /a > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, November 26, 2003 1:02 > To: adam@dynamicsoft.com; fluffy@cisco.com; vkg@lucent.com > Cc: sip@ietf.org > Subject: RE: [Sip] SCTP and TLS > > > Why isn't it enough to state that if a request was received > using TLS, the response must sent using TLS? It requires > proxies and UASs to keep a state though. > > Regards, > Hisham > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > > Adam Roach > > Sent: 26.November.2003 07:10 > > To: 'Cullen Jennings'; Vijay Gurbani > > Cc: Adam Roach; sip@ietf.org > > Subject: RE: [Sip] SCTP and TLS > > > > > > Cullen Jennings [mailto:fluffy@cisco.com] wrote: > > > > > There is not really any SCTP or TLS over SCTP or UDP or DCCP > > > deployed so I think we could be backwards compatible with > > > existing TLS stuff. I'm not seeing a way to be backwards > > > compatible with everything but the current stuff looks broken > > > so I think the odds of something other than what is currently > > > specified deploying are fairly high. This is not a "I don't > > > like the current thing issues" this is the current thing can't > > > construct a usable via for a stateless proxy using SCTP with TLS. > > > > Actually, I think we have a choice between backwards-compatibility > > and elegance. > > > > For example, we could choose designations like the following > > for a sort of elegance: > > > > UDP: SIP/2.0/UDP > > UDP+TLS: SIP/2.0/TLS/UDP > > TCP: SIP/2.0/TCP > > TCP+TLS: SIP/2.0/TLS/TCP > > SCTP: SIP/2.0/SCTP > > SCTP+TLS: SIP/2.0/TLS/SCTP > > DCCP: SIP/2.0/DCCP > > DCCP+TLS: SIP/2.0/TLS/DCCP > > > > Alternately, we could retain backwards compatibility (but have > > people forever wonder about the TCP aberration) by using > > designations like: > > > > UDP: SIP/2.0/UDP > > UDP+TLS: SIP/2.0/TLS/UDP > > TCP: SIP/2.0/TCP > > TCP+TLS: SIP/2.0/TLS > > SCTP: SIP/2.0/SCTP > > SCTP+TLS: SIP/2.0/TLS/SCTP > > DCCP: SIP/2.0/DCCP > > DCCP+TLS: SIP/2.0/TLS/DCCP > > > > Because of practical considerations, I would propose that the > > second approach is probably the best path forward. > > > > /a > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 09:36:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12204 for ; Mon, 1 Dec 2003 09:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp9o-0002eV-7O for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:36:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EaCKI010136 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:36:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp9f-0002YG-Le; Mon, 01 Dec 2003 09:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp90-0002X3-Uv for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12173 for ; Mon, 1 Dec 2003 09:35:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQp8x-0002i9-00 for sip@ietf.org; Mon, 01 Dec 2003 09:35:19 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQp8x-0002hk-00 for sip@ietf.org; Mon, 01 Dec 2003 09:35:19 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24561; Mon, 1 Dec 2003 09:34:46 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08861; Mon, 1 Dec 2003 09:34:47 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 09:34:46 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'vhegde@san.rr.com'" , sip@ietf.org Subject: RE: [Sip] Session timer question Date: Mon, 1 Dec 2003 09:34:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , You send 420 - Bad Extension, because you don't understand the timer option in the Require. See section 8.2.2.3 in RFC3261. Brian -----Original Message----- From: vhegde@san.rr.com [mailto:vhegde@san.rr.com] Sent: Friday, November 28, 2003 9:13 PM To: sip@ietf.org Subject: [Sip] Session timer question Hi: I have a question on session timer message flow. If a UA does not support session timer and if it receives Require: timer Session Expires: 3600 in the 200 OK to re-INVITE what is the correct way to process this response? Should UAC Ack the 200 OK and then send a bye or ignore the Require and session Expires: headers and continue with rest of the processing? Veda _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 10:38:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15164 for ; Mon, 1 Dec 2003 10:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq82-000618-6v for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 10:38:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1FcPxw023071 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 10:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq7e-0005vd-Oh; Mon, 01 Dec 2003 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq6n-0005kq-Si for sip@optimus.ietf.org; Mon, 01 Dec 2003 10:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15113 for ; Mon, 1 Dec 2003 10:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQq6l-0003Q6-00 for sip@ietf.org; Mon, 01 Dec 2003 10:37:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQq6l-0003Pw-00 for sip@ietf.org; Mon, 01 Dec 2003 10:37:07 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 07:39:19 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1FaXAt029310; Mon, 1 Dec 2003 07:36:33 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI10960; Mon, 1 Dec 2003 10:36:32 -0500 (EST) Message-ID: <3FCB5FFE.7010208@cisco.com> Date: Mon, 01 Dec 2003 10:36:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'vhegde@san.rr.com'" , sip@ietf.org Subject: Re: [Sip] Session timer question References: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian, The question was about a Require in a 200 response to an invite. The UAC clearly can't return a 420 in that case. I don't think any valid usage of session timer will ever result in this case. The only cases where Require: timer is validly put into the response are when the request contained Supported: timer. So this can only result from a broken proxy or UAS. In this case I think the UAC is justified in either sending an ACK and then BYE as you suggest, or else just ignoring the Required: timer. Paul Rosen, Brian wrote: > You send 420 - Bad Extension, because you don't understand the > timer option in the Require. See section 8.2.2.3 in RFC3261. > > Brian > -----Original Message----- > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com] > Sent: Friday, November 28, 2003 9:13 PM > To: sip@ietf.org > Subject: [Sip] Session timer question > > > Hi: > I have a question on session timer message flow. > > If a UA does not support session timer and if it receives > > Require: timer > Session Expires: 3600 > > in the 200 OK to re-INVITE what is the correct way to process this response? > > > Should UAC Ack the 200 OK and then send a bye or ignore the Require and > session Expires: headers and continue with rest of the processing? > > Veda > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 11:44:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17222 for ; Mon, 1 Dec 2003 11:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr9u-0000yc-1O for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 11:44:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1GiPtA003748 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 11:44:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr9V-0000xA-KJ; Mon, 01 Dec 2003 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr99-0000wc-PH for sip@optimus.ietf.org; Mon, 01 Dec 2003 11:43:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17162 for ; Mon, 1 Dec 2003 11:43:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr98-0004yU-00 for sip@ietf.org; Mon, 01 Dec 2003 11:43:38 -0500 Received: from web12704.mail.yahoo.com ([216.136.173.241]) by ietf-mx with smtp (Exim 4.12) id 1AQr97-0004yR-00 for sip@ietf.org; Mon, 01 Dec 2003 11:43:38 -0500 Message-ID: <20031201164335.19058.qmail@web12704.mail.yahoo.com> Received: from [128.107.253.38] by web12704.mail.yahoo.com via HTTP; Mon, 01 Dec 2003 08:43:35 PST Date: Mon, 1 Dec 2003 08:43:35 -0800 (PST) From: Gokul Krishnan To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1804434909-1070297015=:18442" Subject: [Sip] Query on Extensions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1804434909-1070297015=:18442 Content-Type: text/plain; charset=us-ascii Hi All, What is the difference between "Allow" and "Supported" header from a usage perspective? As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). What is the advantage/disadvantage of each approach? Thanks and Regards Gokul --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1804434909-1070297015=:18442 Content-Type: text/html; charset=us-ascii

Hi All,

What is the difference between "Allow" and "Supported" header from a usage perspective?

As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

What is the advantage/disadvantage of each approach?

Thanks and Regards

Gokul

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1804434909-1070297015=:18442-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 12:51:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19856 for ; Mon, 1 Dec 2003 12:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsCd-0005Aj-MV for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 12:51:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1HpIqw019819 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 12:51:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsCM-00058f-5W; Mon, 01 Dec 2003 12:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsBj-000578-6I for sip@optimus.ietf.org; Mon, 01 Dec 2003 12:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19828 for ; Mon, 1 Dec 2003 12:50:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsBh-0005v8-00 for sip@ietf.org; Mon, 01 Dec 2003 12:50:21 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AQsBg-0005v2-00 for sip@ietf.org; Mon, 01 Dec 2003 12:50:21 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1Hnlxg014972; Mon, 1 Dec 2003 12:49:47 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI23706; Mon, 1 Dec 2003 12:49:45 -0500 (EST) Message-ID: <3FCB7F39.6090205@cisco.com> Date: Mon, 01 Dec 2003 12:49:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gokul Krishnan CC: sip@ietf.org Subject: Re: [Sip] Query on Extensions References: <20031201164335.19058.qmail@web12704.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Gokul Krishnan wrote: > Hi All, > > What is the difference between "Allow" and "Supported" header *from a > usage perspective*? > > As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and > for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). "Allow" identifies sip *methods* that the UA supports. "Supported" identifies named "packages" that the UA supports. The values are drawn from different namespaces. > What is the advantage/disadvantage of each approach? They aren't substitutes for one another. A package listed as Supported may require the use of certain methods. Those methods should also be listed in an Allow header. An example of this is 100rel. You need to specify both Allow: UPDATE and Supported: 100rel to use reliable provisional responses. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 13:29:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21569 for ; Mon, 1 Dec 2003 13:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsnM-0008ST-Gh for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 13:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1ITGJS032512 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 13:29:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsn7-0008RD-Nx; Mon, 01 Dec 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsmA-0008Pu-6L for sip@optimus.ietf.org; Mon, 01 Dec 2003 13:28:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21506 for ; Mon, 1 Dec 2003 13:27:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsm8-0006OA-00 for sip@ietf.org; Mon, 01 Dec 2003 13:28:00 -0500 Received: from [66.192.6.226] (helo=pope.teraglobal.com) by ietf-mx with esmtp (Exim 4.12) id 1AQsm7-0006NY-00 for sip@ietf.org; Mon, 01 Dec 2003 13:27:59 -0500 Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com (Netscape Messaging Server 4.15) with SMTP id HP8BLE00.3IM; Mon, 1 Dec 2003 10:34:26 -0800 Message-ID: <001b01c3b838$c4219380$2506c042@WXPvhegde> From: "Veda Hegde" To: "Paul Kyzivat" , "Rosen Brian" Cc: References: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.com> <3FCB5FFE.7010208@cisco.com> Subject: Re: [Sip] Session timer question Date: Mon, 1 Dec 2003 10:27:24 -0800 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.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi: I don't think it says in the draft that a proxy/UAS can not put Require: timer in 2xx, if UAC did not include Supported: timer in the request. May be this should be specified in the draft. Veda ----- Original Message ----- From: "Paul Kyzivat" To: "Rosen, Brian" Cc: ; Sent: Monday, December 01, 2003 7:36 AM Subject: Re: [Sip] Session timer question > Brian, > > The question was about a Require in a 200 response to an invite. The UAC > clearly can't return a 420 in that case. > > I don't think any valid usage of session timer will ever result in this > case. The only cases where Require: timer is validly put into the > response are when the request contained Supported: timer. > > So this can only result from a broken proxy or UAS. In this case I think > the UAC is justified in either sending an ACK and then BYE as you > suggest, or else just ignoring the Required: timer. > > Paul > > Rosen, Brian wrote: > > You send 420 - Bad Extension, because you don't understand the > > timer option in the Require. See section 8.2.2.3 in RFC3261. > > > > Brian > > -----Original Message----- > > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com] > > Sent: Friday, November 28, 2003 9:13 PM > > To: sip@ietf.org > > Subject: [Sip] Session timer question > > > > > > Hi: > > I have a question on session timer message flow. > > > > If a UA does not support session timer and if it receives > > > > Require: timer > > Session Expires: 3600 > > > > in the 200 OK to re-INVITE what is the correct way to process this response? > > > > > > Should UAC Ack the 200 OK and then send a bye or ignore the Require and > > session Expires: headers and continue with rest of the processing? > > > > Veda > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 13:42:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22004 for ; Mon, 1 Dec 2003 13:42:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQszq-00011E-Da for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 13:42:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IgAw5003917 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 13:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQszh-00010P-Si; Mon, 01 Dec 2003 13:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQszb-000108-MU for sip@optimus.ietf.org; Mon, 01 Dec 2003 13:41:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21960 for ; Mon, 1 Dec 2003 13:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQszZ-0006Yg-00 for sip@ietf.org; Mon, 01 Dec 2003 13:41:53 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AQszY-0006Xy-00 for sip@ietf.org; Mon, 01 Dec 2003 13:41:52 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1IfI005571 for ; Mon, 1 Dec 2003 12:41:18 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XPQJ4>; Mon, 1 Dec 2003 18:41:16 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Veda Hegde'" , Paul Kyzivat , Rosen Brian Cc: sip@ietf.org Subject: RE: [Sip] Session timer question Date: Mon, 1 Dec 2003 18:41:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think this is answered by subclause 8.2.4 of RFC 3261, viz: 8.2.4 Applying Extensions A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. regards Keith > -----Original Message----- > From: Veda Hegde [mailto:vhegde@san.rr.com] > Sent: 01 December 2003 18:27 > To: Paul Kyzivat; Rosen Brian > Cc: sip@ietf.org > Subject: Re: [Sip] Session timer question > > > Hi: > I don't think it says in the draft that a proxy/UAS can not > put Require: > timer in 2xx, if UAC did not include Supported: timer in the request. > May be this should be specified in the draft. > Veda > > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Rosen, Brian" > Cc: ; > Sent: Monday, December 01, 2003 7:36 AM > Subject: Re: [Sip] Session timer question > > > > Brian, > > > > The question was about a Require in a 200 response to an > invite. The UAC > > clearly can't return a 420 in that case. > > > > I don't think any valid usage of session timer will ever > result in this > > case. The only cases where Require: timer is validly put into the > > response are when the request contained Supported: timer. > > > > So this can only result from a broken proxy or UAS. In this > case I think > > the UAC is justified in either sending an ACK and then BYE as you > > suggest, or else just ignoring the Required: timer. > > > > Paul > > > > Rosen, Brian wrote: > > > You send 420 - Bad Extension, because you don't understand the > > > timer option in the Require. See section 8.2.2.3 in RFC3261. > > > > > > Brian > > > -----Original Message----- > > > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com] > > > Sent: Friday, November 28, 2003 9:13 PM > > > To: sip@ietf.org > > > Subject: [Sip] Session timer question > > > > > > > > > Hi: > > > I have a question on session timer message flow. > > > > > > If a UA does not support session timer and if it receives > > > > > > Require: timer > > > Session Expires: 3600 > > > > > > in the 200 OK to re-INVITE what is the correct way to process this > response? > > > > > > > > > Should UAC Ack the 200 OK and then send a bye or ignore > the Require and > > > session Expires: headers and continue with rest of the processing? > > > > > > Veda > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 14:21:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23423 for ; Mon, 1 Dec 2003 14:21:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtbh-00038v-RX for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 14:21:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JLHpP012021 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 14:21:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtbT-00036b-B4; Mon, 01 Dec 2003 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaw-0002yS-6m for sip@optimus.ietf.org; Mon, 01 Dec 2003 14:20:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23317 for ; Mon, 1 Dec 2003 14:20:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074l-00 for sip@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074P-00 for sip@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hB1JJBb9022753; Mon, 1 Dec 2003 19:19:11 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 14:19:11 -0500 Message-ID: From: "Peterson, Jon" To: "'Rene Bartsch'" , "'sip@ietf.org'" Subject: RE: [Sip] ENUM-support in SIP-protocol? Date: Mon, 1 Dec 2003 14:19:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , See: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-04.txt Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rene Bartsch [mailto:ml@bartschnet.de] > Sent: Saturday, November 29, 2003 11:26 AM > To: sip@ietf.org > Subject: [Sip] ENUM-support in SIP-protocol? > > > Hi, > > first I'm new to the list, so hello to all! :-) > > My question is if there is any draft of plan to implement ENUM-lookups > into the SIP-protocol? > > Rene Bartsch > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Dec 1 14:33:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23971 for ; Mon, 1 Dec 2003 14:33:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtn8-0003kh-DH for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 14:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JX6pp014405 for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 14:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtn3-0003j5-Ci; Mon, 01 Dec 2003 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtm3-0003g3-Uk for sip@optimus.ietf.org; Mon, 01 Dec 2003 14:32:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23882 for ; Mon, 1 Dec 2003 14:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtm1-0007B9-00 for sip@ietf.org; Mon, 01 Dec 2003 14:31:57 -0500 Received: from [66.192.6.226] (helo=pope.teraglobal.com) by ietf-mx with esmtp (Exim 4.12) id 1AQtm0-0007Al-00 for sip@ietf.org; Mon, 01 Dec 2003 14:31:56 -0500 Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com (Netscape Messaging Server 4.15) with SMTP id HP8EK300.JGT; Mon, 1 Dec 2003 11:38:27 -0800 Message-ID: <001001c3b841$b5c99d60$2506c042@WXPvhegde> From: "Veda Hegde" To: "Drage Keith $Keith$" , "Paul Kyzivat" , "Rosen Brian" Cc: References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] Session timer question Date: Mon, 1 Dec 2003 11:31:25 -0800 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Keith: Thanks for pointing this out and I will go with this in my implementation. I think, the 2nd paragraph in "Overview of operation" in the draft should be reworded. It says, ---------------------------------------------------------------------------- --------- This extension has the property that it works even when only one UA in a dialog supports it. The processing steps differ for handling each of the four cases (UAC supports it, or doesn't, and UAS supports it, or doesn't). ---------------------------------------------------------------------------- -------- Doesn't this mean even if UAC does not support timer, UAS could support it? Veda ----- Original Message ----- From: "Drage, Keith (Keith)" To: "'Veda Hegde'" ; "Paul Kyzivat" ; "Rosen Brian" Cc: Sent: Monday, December 01, 2003 10:41 AM Subject: RE: [Sip] Session timer question > I think this is answered by subclause 8.2.4 of RFC 3261, viz: > > 8.2.4 Applying Extensions > > A UAS that wishes to apply some extension when generating the > response MUST NOT do so unless support for that extension is > indicated in the Supported header field in the request. If the > desired extension is not supported, the server SHOULD rely only on > baseline SIP and any other extensions supported by the client. In > rare circumstances, where the server cannot process the request > without the extension, the server MAY send a 421 (Extension Required) > response. This response indicates that the proper response cannot be > generated without support of a specific extension. The needed > extension(s) MUST be included in a Require header field in the > response. This behavior is NOT RECOMMENDED, as it will generally > break interoperability. > > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, the server > MUST NOT apply extensions not listed in the Supported header field in > the request. As a result of this, the Require header field in a > response will only ever contain option tags defined in standards- > track RFCs. > > regards > > Keith > > > -----Original Message----- > > From: Veda Hegde [mailto:vhegde@san.rr.com] > > Sent: 01 December 2003 18:27 > > To: Paul Kyzivat; Rosen Brian > > Cc: sip@ietf.org > > Subject: Re: [Sip] Session timer question > > > > > > Hi: > > I don't think it says in the draft that a proxy/UAS can not > > put Require: > > timer in 2xx, if UAC did not include Supported: timer in the request. > > May be this should be specified in the draft. > > Veda > > > > > > ----- Original Message ----- > > From: "Paul Kyzivat" > > To: "Rosen, Brian" > > Cc: ; > > Sent: Monday, December 01, 2003 7:36 AM > > Subject: Re: [Sip] Session timer question > > > > > > > Brian, > > > > > > The question was about a Require in a 200 response to an > > invite. The UAC > > > clearly can't return a 420 in that case. > > > > > > I don't think any valid usage of session timer will ever > > result in this > > > case. The only cases where Require: timer is validly put into the > > > response are when the request contained Supported: timer. > > > > > > So this can only result from a broken proxy or UAS. In this > > case I think > > > the UAC is justified in either sending an ACK and then BYE as you > > > suggest, or else just ignoring the Required: timer. > > > > > > Paul > > > > > > Rosen, Brian wrote: > > > > You send 420 - Bad Extension, because you don't understand the > > > > timer option in the Require. See section 8.2.2.3 in RFC3261. > > > > > > > > Brian > > > > -----Original Message----- > > > > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com] > > > > Sent: Friday, November 28, 2003 9:13 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] Session timer question > > > > > > > > > > > > Hi: > > > > I have a question on session timer message flow. > > > > > > > > If a UA does not support session timer and if it receives > > > > > > > > Require: timer > > > > Session Expires: 3600 > > > > > > > > in the 200 OK to re-INVITE what is the correct way to process this > > response? > > > > > > > > > > > > Should UAC Ack the 200 OK and then send a bye or ignore > > the Require and > > > > session Expires: headers and continue with rest of the processing? > > > > > > > > Veda > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 03:28:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08052 for ; Tue, 2 Dec 2003 03:28:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5tN-0002Bp-8X for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 03:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28SLxI008416 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 03:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5t4-0002Ar-Qd; Tue, 02 Dec 2003 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5sp-0002A1-Fe for sip@optimus.ietf.org; Tue, 02 Dec 2003 03:27:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08035 for ; Tue, 2 Dec 2003 03:27:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5sn-0003Ok-00 for sip@ietf.org; Tue, 02 Dec 2003 03:27:45 -0500 Received: from web12705.mail.yahoo.com ([216.136.173.242]) by ietf-mx with smtp (Exim 4.12) id 1AR5sm-0003Oh-00 for sip@ietf.org; Tue, 02 Dec 2003 03:27:44 -0500 Message-ID: <20031202082745.37337.qmail@web12705.mail.yahoo.com> Received: from [128.107.253.44] by web12705.mail.yahoo.com via HTTP; Tue, 02 Dec 2003 00:27:45 PST Date: Tue, 2 Dec 2003 00:27:45 -0800 (PST) From: Gokul Krishnan Subject: Re: [Sip] Query on Extensions To: pkyzivat@cisco.com Cc: sip@ietf.org In-Reply-To: <3FCB7F39.6090205@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1386608887-1070353665=:36198" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1386608887-1070353665=:36198 Content-Type: text/plain; charset=us-ascii Thanks for the reply Paul. Suppose I add a new method to SIP, say REMOVEPARTY. Now, (1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ?? (2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ? Can I only use "Allow: REMOVEPARTY" in Case2 ? Paul Kyzivat wrote: Gokul Krishnan wrote: > Hi All, > > What is the difference between "Allow" and "Supported" header *from a > usage perspective*? > > As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and > for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). "Allow" identifies sip *methods* that the UA supports. "Supported" identifies named "packages" that the UA supports. The values are drawn from different namespaces. > What is the advantage/disadvantage of each approach? They aren't substitutes for one another. A package listed as Supported may require the use of certain methods. Those methods should also be listed in an Allow header. An example of this is 100rel. You need to specify both Allow: UPDATE and Supported: 100rel to use reliable provisional responses. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1386608887-1070353665=:36198 Content-Type: text/html; charset=us-ascii

Thanks for the reply Paul.

Suppose I add a new method to SIP, say REMOVEPARTY. Now,

(1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ??

(2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ?

Can I only use "Allow: REMOVEPARTY" in Case2 ?

Paul Kyzivat <pkyzivat@cisco.com> wrote:

Gokul Krishnan wrote:
> Hi All,
>
> What is the difference between "Allow" and "Supported" header *from a
> usage perspective*?
>
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported"
identifies named "packages" that the UA supports. The values are drawn
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported
may require the use of certain methods. Those methods should also be
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and
Supported: 100rel to use reliable provisional responses.

Paul

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

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1386608887-1070353665=:36198-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 05:42:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11351 for ; Tue, 2 Dec 2003 05:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7yx-0000B0-2S for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 05:42:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AgFjl000674 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 05:42:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7yj-00006r-MX; Tue, 02 Dec 2003 05:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7xs-00005f-0c for sip@optimus.ietf.org; Tue, 02 Dec 2003 05:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11264 for ; Tue, 2 Dec 2003 05:40:53 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7xo-0004k3-00 for sip@ietf.org; Tue, 02 Dec 2003 05:41:04 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR7xn-0004k0-00 for sip@ietf.org; Tue, 02 Dec 2003 05:41:03 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2Af3s29898 for ; Tue, 2 Dec 2003 12:41:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 12:41:03 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:41:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 12:41:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B8C0.C7AB676C" Subject: RE: [Sip] Query on Extensions Date: Tue, 2 Dec 2003 12:41:01 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B115@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Query on Extensions Thread-Index: AcO4shJ4kiw6YumtThOtm0kZKao90gADgdRQ To: , Cc: X-OriginalArrivalTime: 02 Dec 2003 10:41:02.0663 (UTC) FILETIME=[C8161D70:01C3B8C0] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B8C0.C7AB676C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you put Allow: REMOVEPARTY, you are telling the other side that you = can handle a request with method REMOVEPARTY if you receive it. You tell = the other side what methods you support. Require-header tells the other = side that if it doesn't support a certain extension, then you don't want = to talk to it. =20 So if you require the other side to support REMOVEPARTY, then you would = have the require: pRem extension. =20 /Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Gokul Krishnan Sent: 02.December.2003 10:28 To: pkyzivat@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] Query on Extensions Thanks for the reply Paul. =20 Suppose I add a new method to SIP, say REMOVEPARTY. Now, (1) if my UAC want to force this on UAS, is the only way to define a = package, say pRem, and use "Require: pRem" ?? (2) if my UAC want just to let know the UAS, should I use "Supported: = pRem" ?=20 Can I only use "Allow: REMOVEPARTY" in Case2 ? Paul Kyzivat wrote: Gokul Krishnan wrote: > Hi All, >=20 > What is the difference between "Allow" and "Supported" header *from a=20 > usage perspective*? >=20 > As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and=20 > for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). "Allow" identifies sip *methods* that the UA supports. "Supported"=20 identifies named "packages" that the UA supports. The values are drawn=20 from different namespaces. > What is the advantage/disadvantage of each approach? They aren't substitutes for one another. A package listed as Supported=20 may require the use of certain methods. Those methods should also be=20 listed in an Allow header. An example of this is 100rel. You need to specify both Allow: UPDATE and = Supported: 100rel to use reliable provisional responses. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _____ =20 Do you Yahoo!? Free = Pop-Up Blocker - Get it now ------_=_NextPart_001_01C3B8C0.C7AB676C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you=20 put Allow: REMOVEPARTY, you are telling the other side that you can = handle a=20 request with method REMOVEPARTY if you receive it. You tell the other = side what=20 methods you support. Require-header tells the other side that if it = doesn't=20 support a certain extension, then you don't want to talk to=20 it.

So if=20 you require the other side to support REMOVEPARTY, then you would have = the=20 require: pRem extension.

/Hisham

-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of ext Gokul=20 Krishnan
Sent: 02.December.2003 10:28
To:=20 pkyzivat@cisco.com
Cc: sip@ietf.org
Subject: Re: = [Sip]=20 Query on Extensions

Thanks for the reply = Paul.

Suppose I add a new method = to SIP, say=20 REMOVEPARTY. Now,

(1) if my UAC want to = force this on=20 UAS, is the only way to define a package, say pRem, and use = "Require:=20 pRem" ??

(2) if my UAC want just = to let=20 know the UAS, should I use "Supported: pRem" ?

Can I only = use "Allow:=20 REMOVEPARTY" in Case2 ?

Paul Kyzivat <pkyzivat@cisco.com>=20 wrote:

Gokul=20 Krishnan wrote:
> Hi All,
>
> What is the = difference=20 between "Allow" and "Supported" header *from a
> usage=20 perspective*?
>
> As an example, for PRACK an UAC sends = Supported:100rel (RFC 3262) and
> for UPDATE, the UAC is = supposed to=20 send Allow: UPDATE (RFC 3311).

"Allow" identifies sip = *methods* that=20 the UA supports. "Supported"
identifies named "packages" that = the UA=20 supports. The values are drawn
from different = namespaces.

>=20 What is the advantage/disadvantage of each approach?

They = aren't=20 substitutes for one another. A package listed as Supported
may = require=20 the use of certain methods. Those methods should also be
listed = in an=20 Allow header.

An example of this is 100rel. You need to = specify both=20 Allow: UPDATE and
Supported: 100rel to use reliable provisional=20 = responses.

Paul

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

Do you Yahoo!?
= Free=20 Pop-Up Blocker - Get it now ------_=_NextPart_001_01C3B8C0.C7AB676C-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 07:46:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14756 for ; Tue, 2 Dec 2003 07:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9uz-0005hl-5w for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 07:46:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2CkHX5021926 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 07:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9ul-0005go-4Z; Tue, 02 Dec 2003 07:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9uf-0005gJ-Bb for sip@optimus.ietf.org; Tue, 02 Dec 2003 07:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14724 for ; Tue, 2 Dec 2003 07:45:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR9ue-0006c8-00 for sip@ietf.org; Tue, 02 Dec 2003 07:45:56 -0500 Received: from web12701.mail.yahoo.com ([216.136.173.238]) by ietf-mx with smtp (Exim 4.12) id 1AR9ud-0006c3-00 for sip@ietf.org; Tue, 02 Dec 2003 07:45:55 -0500 Message-ID: <20031202124554.56726.qmail@web12701.mail.yahoo.com> Received: from [128.107.253.44] by web12701.mail.yahoo.com via HTTP; Tue, 02 Dec 2003 04:45:54 PST Date: Tue, 2 Dec 2003 04:45:54 -0800 (PST) From: Gokul Krishnan Subject: RE: [Sip] Query on Extensions To: hisham.khartabil@nokia.com Cc: sip@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B115@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1595446770-1070369154=:52677" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-1595446770-1070369154=:52677 Content-Type: text/plain; charset=us-ascii Thanks Hisham. But this is what confuses me: By using "Require" we force the other side to support the extension. By using "Supported" or "Allow" we are letting the other side know that we support some (new) extension - by using a token (in case of "Supported") or by using method name itself (in case of "Allow"). When implementing a new methd (not forcing the other side) why should I go for "Supported"? Cant I just settle with "Allow" ? Or is it that even with "Require", we must send "Allow" also ?! Which will mean that, if "Require" or "Supported" is there, then it must be accompanied with "Allow"? Sorry for keeping on bombarding with the same query, but I am confused :( hisham.khartabil@nokia.com wrote: If you put Allow: REMOVEPARTY, you are telling the other side that you can handle a request with method REMOVEPARTY if you receive it. You tell the other side what methods you support. Require-header tells the other side that if it doesn't support a certain extension, then you don't want to talk to it. So if you require the other side to support REMOVEPARTY, then you would have the require: pRem extension. /Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext Gokul Krishnan Sent: 02.December.2003 10:28 To: pkyzivat@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] Query on Extensions Thanks for the reply Paul. Suppose I add a new method to SIP, say REMOVEPARTY. Now, (1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ?? (2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ? Can I only use "Allow: REMOVEPARTY" in Case2 ? Paul Kyzivat wrote: Gokul Krishnan wrote: > Hi All, > > What is the difference between "Allow" and "Supported" header *from a > usage perspective*? > > As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and > for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). "Allow" identifies sip *methods* that the UA supports. "Supported" identifies named "packages" that the UA supports. The values are drawn from different namespaces. > What is the advantage/disadvantage of each approach? They aren't substitutes for one another. A package listed as Supported may require the use of certain methods. Those methods should also be listed in an Allow header. An example of this is 100rel. You need to specify both Allow: UPDATE and Supported: 100rel to use reliable provisional responses. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1595446770-1070369154=:52677 Content-Type: text/html; charset=us-ascii

Thanks Hisham.

But this is what confuses me:

By using "Require" we force the other side to support the extension.

By using "Supported" or "Allow" we are letting the other side know that we support some (new) extension - by using a token (in case of "Supported") or by using method name itself (in case of "Allow"). When implementing a new methd (not forcing the other side) why should I go for "Supported"? Cant I just settle with "Allow" ?

Or is it that even with "Require", we must send "Allow" also ?! Which will mean that, if "Require" or "Supported" is there, then it must be accompanied with "Allow"?

Sorry for keeping on bombarding with the same query, but I am confused :(

hisham.khartabil@nokia.com wrote:

If you put Allow: REMOVEPARTY, you are telling the other side that you can handle a request with method REMOVEPARTY if you receive it. You tell the other side what methods you support. Require-header tells the other side that if it doesn't support a certain extension, then you don't want to talk to it.

So if you require the other side to support REMOVEPARTY, then you would have the require: pRem extension.

/Hisham

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext Gokul Krishnan
Sent: 02.December.2003 10:28
To: pkyzivat@cisco.com
Cc: sip@ietf.org
Subject: Re: [Sip] Query on Extensions

Thanks for the reply Paul.

Suppose I add a new method to SIP, say REMOVEPARTY. Now,

(1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ??

(2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ?

Can I only use "Allow: REMOVEPARTY" in Case2 ?

Paul Kyzivat <pkyzivat@cisco.com> wrote:

Gokul Krishnan wrote:
> Hi All,
>
> What is the difference between "Allow" and "Supported" header *from a
> usage perspective*?
>
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported"
identifies named "packages" that the UA supports. The values are drawn
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported
may require the use of certain methods. Those methods should also be
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and
Supported: 100rel to use reliable provisional responses.

Paul

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

Do you Yahoo!?
Free Pop-Up Blocker - Get it now

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1595446770-1070369154=:52677-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 11:39:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25779 for ; Tue, 2 Dec 2003 11:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDYN-0008Tc-1k for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 11:39:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GdAYw032578 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 11:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDXJ-0008Ha-39; Tue, 02 Dec 2003 11:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDWb-00087o-67 for sip@optimus.ietf.org; Tue, 02 Dec 2003 11:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25580 for ; Tue, 2 Dec 2003 11:37:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDWa-0003jo-00 for sip@ietf.org; Tue, 02 Dec 2003 11:37:20 -0500 Received: from central.switch.ch ([130.59.11.11]) by ietf-mx with esmtp (Exim 4.12) id 1ARDWZ-0003jR-00 for sip@ietf.org; Tue, 02 Dec 2003 11:37:19 -0500 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1ARDW4-0003Ac-00; Tue, 02 Dec 2003 17:36:48 +0100 Date: Tue, 2 Dec 2003 17:36:48 +0100 (CET) From: Bernie Hoeneisen To: "'Rene Bartsch'" cc: "'sip@ietf.org'" Subject: RE: [Sip] ENUM-support in SIP-protocol? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Rene! The below might also be of interest for you. cheers, Bernie --- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : enumservice registration for SIP Addresses-of-Record Author(s) : J. Peterson Filename : draft-ietf-enum-sip-01.txt Pages : 9 Date : 2003-12-1 This document registers an ENUM service for SIP (the Session Initiation Protocol), pursuant to the guidelines in RFC2916bis. Specifically, this document focuses on provisioning SIP addresses-of- record in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-01.txt [...] ---- On Mon, 1 Dec 2003, Peterson, Jon wrote: > > See: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-04.txt > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rene Bartsch [mailto:ml@bartschnet.de] > > Sent: Saturday, November 29, 2003 11:26 AM > > To: sip@ietf.org > > Subject: [Sip] ENUM-support in SIP-protocol? > > > > > > Hi, > > > > first I'm new to the list, so hello to all! :-) > > > > My question is if there is any draft of plan to implement ENUM-lookups > > into the SIP-protocol? > > > > Rene Bartsch > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 12:04:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27487 for ; Tue, 2 Dec 2003 12:04:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDwD-00035B-Ul for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 12:03:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H3ncf011848 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 12:03:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDvf-0002tb-Gs; Tue, 02 Dec 2003 12:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDtU-0002Lh-4h for sip@optimus.ietf.org; Tue, 02 Dec 2003 12:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27205 for ; Tue, 2 Dec 2003 12:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDtI-0004Lt-00 for sip@ietf.org; Tue, 02 Dec 2003 12:00:48 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ARDtI-0004Kr-00 for sip@ietf.org; Tue, 02 Dec 2003 12:00:48 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB2Gtbg14277; Tue, 2 Dec 2003 10:55:49 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hB2GsLD12485; Tue, 2 Dec 2003 10:54:21 -0600 (CST) Message-ID: <3FCCC3AD.7020607@lucent.com> Date: Tue, 02 Dec 2003 10:54:05 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy , Dean Willis , SIP LIST CC: "Jain, Rajnish" , "Chris Boulton" , slawrence@pingtel.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] TCP connection design team? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rohan/Dean: At the Minneapolis IETF last month, we arrived at a consensus on the SIP WG mailing list [1] that a BCP-type document should be produced for TCP connections; more specifically, devise and/or document means to keep TCP connections open for a longer time. The current crop of servers do not keep connections between transactions in any deterministic manner. Furthermore, TCP connection management is unclear and/or under-specified in rfc3261. At the San Francisco IETF (56th IETF, March 2003), I had presented a draft [2] which extended Rohan's Connection-Reuse draft [3] to provide for long lived connections and other related aspects. At that time, there wasn't sufficient interest to drive the work beyond what was decribed in [3]; and while I agreed to produce a BCP, it has not happened yet. There is now, I believe, more of an interest to move this work forward. I've been in touch with the folks CC'd on this email, all of whom have expressed an interest and willingness to contribute to this work. However, I would like to request the chairs to officially designate a design team for this effort. We could always simply "go ahed and do it", but it would help tremendously to have some official working group recognition of the effort. This will attract folks with actual TCP implementations who have battled the connection reuse and longevity issues. I would propose using [2,3] as starting points for a BCP. I look forward to your response. References: [1] Thread starting with http://www1.ietf.org/mail-archive/working-groups/sip/current/msg09007.html [2] Requirements for persistent connection management in SIP http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-01.txt [3] Connection reuse in SIP http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-00.txt Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 12:04:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27519 for ; Tue, 2 Dec 2003 12:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDwW-0003BW-Oq for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 12:04:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H48Hn012187 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 12:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDwS-00039d-OO; Tue, 02 Dec 2003 12:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDwA-00033c-Ea for sip@optimus.ietf.org; Tue, 02 Dec 2003 12:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27448 for ; Tue, 2 Dec 2003 12:03:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDw7-0004Qo-00 for sip@ietf.org; Tue, 02 Dec 2003 12:03:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARDw7-0004QL-00 for sip@ietf.org; Tue, 02 Dec 2003 12:03:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 09:06:08 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2H39w5009388; Tue, 2 Dec 2003 09:03:09 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI97664; Tue, 2 Dec 2003 12:03:05 -0500 (EST) Message-ID: <3FCCC5C9.5060109@cisco.com> Date: Tue, 02 Dec 2003 12:03:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gokul Krishnan CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Query on Extensions References: <20031202124554.56726.qmail@web12701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Gokul Krishnan wrote: > Thanks Hisham. > > But this is what confuses me: > > By using "Require" we *force* the other side to support the extension. > > By using "Supported" or "Allow" we are letting the other side know that > we support some (new) extension - by using a token (in case of > "Supported") or by using method name itself (in case of "Allow"). > When implementing a new methd (not forcing the other side) why should I > go for "Supported"? Cant I just settle with "Allow" ? When implementing a new method, you would probably expose your capability with Allow. "Supported" isn't about a specific method, it is about some package of functionality. Of course any package of functionality is going to need to use some methods, but often it will use common methods in special ways. For example, the "timer" package only requires the use of INVITE and ACK, but it also requires the processing of specific extension headers and some specific protocol actions. > Or is it that even with "Require", we must send "Allow" also ?! Which > will mean that, if "Require" or "Supported" is there, then it must be > accompanied with "Allow"? Typically yes. If you want to be complete, you will list every supported method in Allow, and every supported package in Supported. > Sorry for keeping on bombarding with the same query, but I am confused :( Yes, it is a bit obscure. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 13:36:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01327 for ; Tue, 2 Dec 2003 13:36:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFNj-0000Iu-3L for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 13:36:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2IaIld001108 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 13:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFNT-0000Gt-6C; Tue, 02 Dec 2003 13:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFN4-0000GI-Go for sip@optimus.ietf.org; Tue, 02 Dec 2003 13:35:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01204 for ; Tue, 2 Dec 2003 13:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFN2-0005q3-00 for sip@ietf.org; Tue, 02 Dec 2003 13:35:36 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ARFN1-0005pz-00 for sip@ietf.org; Tue, 02 Dec 2003 13:35:35 -0500 Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB2IbDud020682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2003 12:37:13 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB2IbDLW020680; Tue, 2 Dec 2003 12:37:13 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: RE: [Sip] SCTP and TLS From: Dean Willis To: Adam Roach Cc: "'Vijay K. Gurbani'" , Cullen Jennings , sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1070390232.20281.46.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Dec 2003 12:37:12 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > However, this leaves the issue of Via headers. > > I can say: > > Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds > > Or: > > Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds > > But there is no standardized syntax that allows me to say > both at the same time. > Record-in, record out. Use two Via header fields, one for each interface. Just like a dual-homed proxy. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Dec 2 15:37:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09063 for ; Tue, 2 Dec 2003 15:37:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHFp-0006rr-RH for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 15:36:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KaHJX026334 for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 15:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHFd-0006pk-39; Tue, 02 Dec 2003 15:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHFN-0006p1-Q9 for sip@optimus.ietf.org; Tue, 02 Dec 2003 15:35:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08760 for ; Tue, 2 Dec 2003 15:35:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHFM-0000Aw-00 for sip@ietf.org; Tue, 02 Dec 2003 15:35:48 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1ARHFL-0000AX-00 for sip@ietf.org; Tue, 02 Dec 2003 15:35:47 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hB2KY7ZA022427; Tue, 2 Dec 2003 14:34:07 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 14:34:07 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Dean Willis'" , Adam Roach Cc: "'Vijay K. Gurbani'" , Cullen Jennings , sip@ietf.org Subject: RE: [Sip] SCTP and TLS Date: Tue, 2 Dec 2003 14:34:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean Willis [mailto:dean.willis@softarmor.com] writes: > > However, this leaves the issue of Via headers. > > > > I can say: > > > > Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds > > > > Or: > > > > Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds > > > > But there is no standardized syntax that allows me to say > > both at the same time. > > > > Record-in, record out. Use two Via header fields, one for each > interface. Just like a dual-homed proxy. I think you're confused. I'm talking about the case in which I'm sending over a TLS connection that rides on top of SCTP, not bridging between the two kinds of connections (which would require only one via header, anyway). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Dec 4 15:29:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12782 for ; Thu, 4 Dec 2003 15:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS06P-0006xG-DX for sip-archive@odin.ietf.org; Thu, 04 Dec 2003 15:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4KTXEQ026674 for sip-archive@odin.ietf.org; Thu, 4 Dec 2003 15:29:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS05t-0006vF-Sq; Thu, 04 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS05Z-0006uv-Rw for sip@optimus.ietf.org; Thu, 04 Dec 2003 15:28:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12764 for ; Thu, 4 Dec 2003 15:28:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS05Y-0007es-00 for sip@ietf.org; Thu, 04 Dec 2003 15:28:40 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AS05X-0007eo-00 for sip@ietf.org; Thu, 04 Dec 2003 15:28:39 -0500 Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB4KVSud030535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2003 14:31:28 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB4KVScb030533 for sip@ietf.org; Thu, 4 Dec 2003 14:31:28 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: VIRUS WARNING: Re: [Sip] Asserted-Identity: How to 'hint'? From: Dean Willis To: sip@ietf.org In-Reply-To: <200312032059.hB3KxNRt012161@smtp.hispeed.ch> References: <200312032059.hB3KxNRt012161@smtp.hispeed.ch> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1070569888.29479.18.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 04 Dec 2003 14:31:28 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The original of this message, received by me at 2:59 PM US CST on Dece 3 2003 seems to be carrying a virus payload. More and more clever every day, the little monsters. Note that the From address is given as: Jonathan Rosenberg which, as we should all know, is not actually Jonathan's address. On Wed, 2003-12-03 at 14:59, Jonathan Rosenberg wrote: > inline. > > jh@lohi.eng.song.fi wrote: > > > > Peterson, Jon writes: > > > > > So, I take it from the silence on this list today about this matter > > that > > > there is consensus to create a P-Suggested-Identity header in the > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Dec 4 15:32:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12870 for ; Thu, 4 Dec 2003 15:32:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS08q-0007Ez-Sa for sip-archive@odin.ietf.org; Thu, 04 Dec 2003 15:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4KW43Y027750 for sip-archive@odin.ietf.org; Thu, 4 Dec 2003 15:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS08m-0007Cn-Tn; Thu, 04 Dec 2003 15:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS07s-00076w-Vt for sip@optimus.ietf.org; Thu, 04 Dec 2003 15:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12822 for ; Thu, 4 Dec 2003 15:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS07r-0007fs-00 for sip@ietf.org; Thu, 04 Dec 2003 15:31:03 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AS07q-0007fp-00 for sip@ietf.org; Thu, 04 Dec 2003 15:31:03 -0500 Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB4KXcud030546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2003 14:33:38 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB4KXbr8030544; Thu, 4 Dec 2003 14:33:37 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: RE: [Sip] SCTP and TLS From: Dean Willis To: Adam Roach Cc: "'Vijay K. Gurbani'" , Cullen Jennings , sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1070570017.29479.21.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 04 Dec 2003 14:33:37 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tue, 2003-12-02 at 14:34, Adam Roach wrote: Adam said: > Dea nSaid: > > Record-in, record out. Use two Via header fields, one for each > > interface. Just like a dual-homed proxy. > > I think you're confused. I'm talking about the case in which I'm > sending over a TLS connection that rides on top of SCTP, not > bridging between the two kinds of connections (which would require > only one via header, anyway). ah yes, you're right. However, the bridging case does still have the reversible-route problem for Path and Service-Route, so double-recording is still nice to do. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 14:55:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20868 for ; Fri, 5 Dec 2003 14:55:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASM2v-0002UD-Sx for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 14:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5JtPPD009498 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 14:55:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASM2Y-0002S9-Sb; Fri, 05 Dec 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASM2O-0002Rj-Sw for sip@optimus.ietf.org; Fri, 05 Dec 2003 14:54:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20858 for ; Fri, 5 Dec 2003 14:54:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASM2M-0000m1-00 for sip@ietf.org; Fri, 05 Dec 2003 14:54:50 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASM2L-0000lY-00 for sip@ietf.org; Fri, 05 Dec 2003 14:54:49 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5Js1ca027525; Fri, 5 Dec 2003 14:54:01 -0500 (EST) Message-ID: <3FD0E253.1000401@dynamicsoft.com> Date: Fri, 05 Dec 2003 14:53:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Tolga Asveren , sip@ietf.org Subject: Re: [Sip] remote terget update References: <3FCB6090.2060004@cisco.com> In-Reply-To: <3FCB6090.2060004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In particular, see: > 8.2 UAS Behavior > > When a request outside of a dialog is processed by a UAS, there is a > set of processing rules that are followed, independent of the method. > Section 12 gives guidance on how a UAS can tell whether a request is > inside or outside of a dialog. > > Note that request processing is atomic. If a request is accepted, > all state changes associated with it MUST be performed. If it is > rejected, all state changes MUST NOT be performed. Thanks, Jonathan R. Paul Kyzivat wrote: > > > Tolga Asveren wrote: > >> (due to no response in sip-implementors list switching to sip list) >> >> If a reINVITE with target refresh rejected, should remote target >> reverted back to its original value before that reINVITE is received? > > > Yes, 3261 seems pretty clear on this. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 15:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21365 for ; Fri, 5 Dec 2003 15:03:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMAR-0002pG-Dc for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 15:03:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5K3BEd010856 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 15:03:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMAH-0002oD-Nq; Fri, 05 Dec 2003 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASM9J-0002nd-Cb for sip@optimus.ietf.org; Fri, 05 Dec 2003 15:02:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21300 for ; Fri, 5 Dec 2003 15:01:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASM9G-0000we-00 for sip@ietf.org; Fri, 05 Dec 2003 15:01:58 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASM9F-0000ue-00 for sip@ietf.org; Fri, 05 Dec 2003 15:01:57 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5K1Kca027538; Fri, 5 Dec 2003 15:01:21 -0500 (EST) Message-ID: <3FD0E40A.7020008@dynamicsoft.com> Date: Fri, 05 Dec 2003 15:01:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Veda Hegde CC: "Drage Keith (Keith)" , Paul Kyzivat , Rosen Brian , sip@ietf.org Subject: Re: [Sip] Session timer question References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde> In-Reply-To: <001001c3b841$b5c99d60$2506c042@WXPvhegde> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Veda Hegde wrote: > Keith: Thanks for pointing this out and I will go with this in my > implementation. > > I think, the 2nd paragraph in "Overview of operation" in the draft > should be reworded. It says, > ---------------------------------------------------------------------------- > --------- This extension has the property that it works even when > only one UA in a dialog supports it. The processing steps differ > for handling each of the four cases (UAC supports it, or doesn't, > and UAS supports it, or doesn't). > ---------------------------------------------------------------------------- > -------- > > Doesn't this mean even if UAC does not support timer, UAS could > support it? Yes, and this mode is supported. In such a case, the INVITE from the UAC would lack a Supported header field. Proxies insert Session-Expires headers. The UAS receives it. Based on table 2 in the session timer spec, since the UAS supports the extension, it sets the refresher parameter to "uas", and generates a 2xx with the final session timer in the session expires header. This header is ignored by the UAC. The called party will generate refresh requests for the remainder of the call. Note that there is no Require in the 2xx in this case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 15:55:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26347 for ; Fri, 5 Dec 2003 15:55:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMyz-00056b-8U for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 15:55:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KtPsO019565 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 15:55:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMyd-00054H-Rx; Fri, 05 Dec 2003 15:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMxr-0004yn-N8 for sip@optimus.ietf.org; Fri, 05 Dec 2003 15:54:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26192 for ; Fri, 5 Dec 2003 15:54:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASMxq-0002KL-00 for sip@ietf.org; Fri, 05 Dec 2003 15:54:14 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASMxp-0002Je-00 for sip@ietf.org; Fri, 05 Dec 2003 15:54:13 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5Kreca027580; Fri, 5 Dec 2003 15:53:43 -0500 (EST) Message-ID: <3FD0F04E.9000207@dynamicsoft.com> Date: Fri, 05 Dec 2003 15:53:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hu Yijun,BISC R&D SA(BJ)" CC: "'sip@ietf.org'" Subject: Re: [Sip] a question about offer/answer model References: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02> In-Reply-To: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Setting port numbers to zero rejects a STREAM, not the call per se. As such, there would be no bye, the call just proceeds without that stream. If none of the streams are acceptable, the answerer would reject the invite. -Jonathan R. Hu Yijun,BISC R&D SA(BJ) wrote: > hi all, > > I have a question about the SDP offer/answer model. > > In the section 6 of rfc3264, it claimed that the answerer can reject an > offer stream by setting the port number to zero. > > My question is: if an SDP offer, included in INVITE, is reject by the > answerer, and the corresponding SDP answer is included in 200 OK, then > how to deal with this answer in the offerer(UAC)? Should the UAC treat > it as a successful SDP negotiation, or send a BYE immediately after > sending the ACK? > > ----------------------------------------------------------------------------- > Best regards, > Hu Yijun > BISC, R&D SA > Tel.:+86-10-64346-660 > E-mail: yijun.hu@bisc.siemens.com.cn > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 16:01:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26571 for ; Fri, 5 Dec 2003 16:01:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN4V-0005eg-M4 for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5L17dr021709 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN4R-0005dE-DH; Fri, 05 Dec 2003 16:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN3w-0005bG-5x for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26510 for ; Fri, 5 Dec 2003 16:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASN3u-0002Rx-00 for sip@ietf.org; Fri, 05 Dec 2003 16:00:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASN3t-0002R7-00 for sip@ietf.org; Fri, 05 Dec 2003 16:00:29 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5L03ca027584; Fri, 5 Dec 2003 16:00:04 -0500 (EST) Message-ID: <3FD0F1CD.4020208@dynamicsoft.com> Date: Fri, 05 Dec 2003 15:59:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Entity-tags in PUBLISH References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D917F@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D917F@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Once the syntax and semantics are not the same, you should not use the same header name. Even if we added back in the features we don't need pper se, there is still the issue of SHOULD vs. MUST for etag inclusion in the response. I think we definitely want a must. Thus, this is a change in behavior from HTTP. I would propose we use "SIP-Etag" and "SIP-If-Match" to convey that these are similar in scope to their http bretheren, but not the same. -Jonathan R. aki.niemi@nokia.com wrote: > Hi, > > As we discussed in Minneapolis, the PUBLISH draft needs additional text covering the use of etags, and the relationship to HTTP in this respect. One related thing that came up was that although the etags in PUBLISH have been copied from RFC 2616, there are some minor differences, mainly due to the fact that with PUBLISH, we don't have use for features used with for example the GET and HEAD methods: > > - We have dropped the weak etag concept, because PUBLISH etags are basically > always strong. As a side effect, the syntax is also different, i.e., an etag > is a token, instead of quoted-string with an optional "weakness" tag prefix. > This seemed reasonable, since this is the common way to representing > similar things in SIP, and after removing the weak tag, the quotes were > superfluous. > > - We have dropped multiple etags in If-Match header, because in PUBLISH, the > EPA will always only modify/remove/refresh its own publications. This > corresponds to a conditional PUT in HTTP/1.1, where only a single entity-tag > is present in If-Match. > > - We have dropped the "*" valued If-Match. An "If-Match: *" corresponds to a > PUBLISH without the If-Match header, so there is no need for this special > value. > > - In HTTP/1.1, the origin server SHOULD create an etag, whereas in PUBLISH, > the ESC MUST always create an etag. > > The main functionality of etags is the same in my opinion, even with the above "focused" use of them. But I would still like some input on whether the working group feels these differences are considerable enough that we should *not* inherit the syntax for these headers from HTTP/1.1, but create similar but distinct header field names, and response code. > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 16:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26730 for ; Fri, 5 Dec 2003 16:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN9L-0005vK-AF for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5L67R8022744 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:06:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN9H-0005u0-Oy; Fri, 05 Dec 2003 16:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASN8v-0005tT-Kg for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:05:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26701 for ; Fri, 5 Dec 2003 16:05:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASN8t-0002Wh-00 for sip@ietf.org; Fri, 05 Dec 2003 16:05:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ASN8t-0002WS-00 for sip@ietf.org; Fri, 05 Dec 2003 16:05:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 05 Dec 2003 21:05:13 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB5L55DM025839; Fri, 5 Dec 2003 16:05:06 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEL68926; Fri, 5 Dec 2003 16:05:04 -0500 (EST) Message-ID: <3FD0F300.70502@cisco.com> Date: Fri, 05 Dec 2003 16:05:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Hu Yijun,BISC R&D SA(BJ)" , "'sip@ietf.org'" Subject: Re: [Sip] a question about offer/answer model References: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02> <3FD0F04E.9000207@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Setting port numbers to zero rejects a STREAM, not the call per se. As > such, there would be no bye, the call just proceeds without that stream. > If none of the streams are acceptable, the answerer would reject the > invite. Of course an answerer *could* reject all the streams without rejecting the call. This would leave a medialess call. Certainly not a common situation, but possible. The answerer might do that with the thought of initiating a new offer/answer that it thinks might be more acceptable. In such a situation, the initial offerer has multiple possibilities: - send a BYE to terminate the dialog - send a new offer (via reINVITE or UPDATE) and hope things go better - just wait with no media and see what happens. A UA like a phone, that sees this entire possibility as remote and to be avoided, should probably just be prepared to send a BYE in this case. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 16:59:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28625 for ; Fri, 5 Dec 2003 16:59:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNyp-0007u9-2Q for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:59:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LxIx6030325 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:59:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNyX-0007sG-OS; Fri, 05 Dec 2003 16:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNyR-0007rs-LJ for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28594 for ; Fri, 5 Dec 2003 16:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNyO-0007YK-00 for sip@ietf.org; Fri, 05 Dec 2003 16:58:52 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASNyN-0007XK-00 for sip@ietf.org; Fri, 05 Dec 2003 16:58:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hB5Lvvd08451; Fri, 5 Dec 2003 15:58:03 -0600 From: Robert Sparks To: sip-implementors@cs.columbia.edu, sip@ietf.org Content-Type: text/plain Message-Id: <1070661467.911.30.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 05 Dec 2003 15:57:47 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 14 Registration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit SIPIT 14 Registration is open. The event will be held 9-February through 13-February 2004. The last day to register is 16-January-2004 (The last day to secure a room at the event is 9-January-2004) If you plan to attend, but have not already registered, please do so soon. Registration information is available at: http://www.etsi.org/plugtests/SIPIT14.htm RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Dec 5 17:22:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29709 for ; Fri, 5 Dec 2003 17:22:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASOKz-0000eK-0k for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 17:22:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5MMC1C002495 for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 17:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASOKn-0000bs-KD; Fri, 05 Dec 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASOJt-0000aw-O7 for sip@optimus.ietf.org; Fri, 05 Dec 2003 17:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29677 for ; Fri, 5 Dec 2003 17:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASOJr-0002vl-00 for sip@ietf.org; Fri, 05 Dec 2003 17:21:03 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ASOJq-0002rR-00 for sip@ietf.org; Fri, 05 Dec 2003 17:21:02 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5MKcca027601 for ; Fri, 5 Dec 2003 17:20:38 -0500 (EST) Message-ID: <3FD104AF.2030505@dynamicsoft.com> Date: Fri, 05 Dec 2003 17:20:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Updated gruu mechanism spec Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Based on discussions during the IETF 58 meeting, I've submitted a revision to the gruu mechanism document. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt The changes are as follows: * clarified that the registrar needs to return the same gruu in registration refreshes, and this requires reliable storage. No requirement for returning the same gruu across registrations. * clarified that the registrar should ignore any gruu parameter provided in the contact header fields of a registration * mention that, it is still possible that a gruu changes in a registration, in the case where there is a race condition where the client thinks its refreshing, but the registration has just expired at the registrar. As such, recommend that a UA be prepared to deal with such a change. * removed text about using this mechanism to replace dialog reuse * added some more details on the encryption mechanism, such as recommended algorithm and key lengths. Also clearly state that this is just one way to do it, you can do it statefully if you want. * proxies are prohibited from redirecting a request to a gruu, they have to proxy it. If they redirect, you'll ruin any nat traversal benefits associated with gruus. * clarified that gruus don't provide sufficient privacy services, and added a reference to the privacy spec * removed the notion of locally generated gruus. The text now says you need to use the registration mechanism in the draft to obtain a gruu. The result is the end of e2e signaling. It also mentions that a new specification is forthcoming which will address this limitation. At this point, there are no known open issues. I would like to see if there is consensus to adopt this item as a work item of the sip working group. I do not believe we took such a poll during the meeting. Chairs - can you assist? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Dec 6 06:08:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05598 for ; Sat, 6 Dec 2003 06:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASaIP-0005e2-Rb for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 06:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB6B8L3M021638 for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 06:08:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASaI5-0005c3-1t; Sat, 06 Dec 2003 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASaI0-0005bo-GI for sip@optimus.ietf.org; Sat, 06 Dec 2003 06:07:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05582 for ; Sat, 6 Dec 2003 06:07:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASaHw-0006Oo-00 for sip@ietf.org; Sat, 06 Dec 2003 06:07:52 -0500 Received: from web12704.mail.yahoo.com ([216.136.173.241]) by ietf-mx with smtp (Exim 4.12) id 1ASaHw-0006Ol-00 for sip@ietf.org; Sat, 06 Dec 2003 06:07:52 -0500 Message-ID: <20031206110753.51440.qmail@web12704.mail.yahoo.com> Received: from [128.107.253.44] by web12704.mail.yahoo.com via HTTP; Sat, 06 Dec 2003 03:07:53 PST Date: Sat, 6 Dec 2003 03:07:53 -0800 (PST) From: Gokul Krishnan To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2047766205-1070708873=:50009" Subject: [Sip] Encryption in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-2047766205-1070708873=:50009 Content-Type: text/plain; charset=us-ascii Hi All, A query on Encryption in SIP. How is end-to-end encryption achieved in SIP? RFC2543 had headers - Encryption and Response-Key. But in RFC3261 I could only see the mentioning about hop-by-hop encryption using TL/IPSec. Please point to me to the correct portion of RFC in case I am missing something. Thanks Gokul --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-2047766205-1070708873=:50009 Content-Type: text/html; charset=us-ascii

Hi All,

A query on Encryption in SIP.

How is end-to-end encryption achieved in SIP? RFC2543 had headers - Encryption and Response-Key. But in RFC3261 I could only see the mentioning about hop-by-hop encryption using TL/IPSec. Please point to me to the correct portion of RFC in case I am missing something.

Thanks

Gokul

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-2047766205-1070708873=:50009-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Dec 6 12:16:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14008 for ; Sat, 6 Dec 2003 12:16:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASg2Q-0008Jz-Sr for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 12:16:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB6HGEUJ031928 for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 12:16:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASg2F-0008IN-Au; Sat, 06 Dec 2003 12:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASg1t-0008Hl-IQ for sip@optimus.ietf.org; Sat, 06 Dec 2003 12:15:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14002 for ; Sat, 6 Dec 2003 12:15:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASg1s-0003zf-00 for sip@ietf.org; Sat, 06 Dec 2003 12:15:40 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ASg1r-0003zF-00 for sip@ietf.org; Sat, 06 Dec 2003 12:15:39 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2003 09:16:31 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB6HF7At008769; Sat, 6 Dec 2003 09:15:08 -0800 (PST) Received: from [142.131.37.127] (sjc-vpn4-75.cisco.com [10.21.80.75]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKN41686; Sat, 6 Dec 2003 09:15:06 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 06 Dec 2003 09:15:05 -0800 From: Cullen Jennings To: CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Contact header in PUBLISH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Right now the draft says "The PUBLISH request MUST NOT contain a Contact header." Why? Does it do any harm? The paragraph before this makes if fairly clear that PUBLISH does create a new Dialog. The AIB strongly encourages including the Contact header in the sipfrag as correlating material. Clearly we want to use the AIB with PUBLISH. Don't know if this really helps the AIB stuff or not. Anyways, I understand why the Contact header doesn't mean much in a PUBLISH. I don't understand why such strong MUST NOT language. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat Dec 6 22:17:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29661 for ; Sat, 6 Dec 2003 22:17:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpQJ-0007mk-O3 for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 22:17:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB73HVPM029867 for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 22:17:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpPp-0007kq-TR; Sat, 06 Dec 2003 22:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASpPk-0007kV-MY for sip@optimus.ietf.org; Sat, 06 Dec 2003 22:16:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29647 for ; Sat, 6 Dec 2003 22:16:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASpPh-0003D9-00 for sip@ietf.org; Sat, 06 Dec 2003 22:16:53 -0500 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx with esmtp (Exim 4.12) id 1ASpPh-0003Bv-00 for sip@ietf.org; Sat, 06 Dec 2003 22:16:53 -0500 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id hB73GLg01675 for ; Sat, 6 Dec 2003 22:16:21 -0500 (EST) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg01.cc.telcordia.com (SAVSMTP 3.1.2.35) with SMTP id M2003120622162223018 for ; Sat, 06 Dec 2003 22:16:22 -0500 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sat, 6 Dec 2003 22:16:22 -0500 Message-ID: <7B762A7337179544B02B707FAC7F6F1903C9900B@rrc-its-exs03.mail.saic.com> From: "Song, Youngsun"