From davecruse1@hotmail.com Tue May 1 00:13:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2949C21F8675 for ; Tue, 1 May 2012 00:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhueBd8hHiJ2 for ; Tue, 1 May 2012 00:12:58 -0700 (PDT) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8488921F8657 for ; Tue, 1 May 2012 00:12:58 -0700 (PDT) Received: from BLU161-W31 ([65.55.111.137]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 May 2012 00:12:57 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cc121dc2-ac33-499b-aa37-8e1f0f44e846_" X-Originating-IP: [72.163.217.103] From: dave Cruse To: , Date: Tue, 1 May 2012 07:12:57 +0000 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2012 07:12:57.0429 (UTC) FILETIME=[D5B85850:01CD2769] Cc: paulej@packetizer.com, gsalguei@cisco.com Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 07:13:00 -0000 --_cc121dc2-ac33-499b-aa37-8e1f0f44e846_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Glen=2C I have some few basic questions here: Q1. Does this feature support TLS UDP OR just TCP only? Q2. What if Endpoint support only FAX but not Video? Regards - Dave > Date: Mon=2C 5 Mar 2012 13:36:52 -0800 > From: glavers@cisco.com > To: sipcore@ietf.org > CC: paulej@packetizer.com=3B gsalguei@cisco.com > Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt >=20 > Folks=2C > I have submitted a new draft to define an 'immersive' media feature tag. = The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-imm= ersive-capability=20 >=20 > The authors would appreciate feedback and or detailed comments.=20 >=20 > Many thanks=2C > Glen=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --_cc121dc2-ac33-499b-aa37-8e1f0f44e846_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Glen=2C

I have some few basic questions here:

Q1. D= oes this feature support TLS UDP OR just TCP only?

Q2. What if E= ndpoint support only FAX but not Video?

Regards
- Dave

>=3B Date: Mon=2C 5 Mar 2012 13:3= 6:52 -0800
>=3B From: glavers@cisco.com
>=3B To: sipcore@ietf.org=
>=3B CC: paulej@packetizer.com=3B gsalguei@cisco.com
>=3B Subjec= t: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt
>=3B >=3B Folks=2C
>=3B I have submitted a new draft to define an 'immer= sive' media feature tag. The draft is posted at: http://tools.ietf.org/html= /draft-lavers-sipcore-immersive-capability
>=3B
>=3B The author= s would appreciate feedback and or detailed comments.
>=3B
>= =3B Many thanks=2C
>=3B Glen
>=3B ______________________________= _________________
>=3B sipcore mailing list
>=3B sipcore@ietf.org=
>=3B https://www.ietf.org/mailman/listinfo/sipcore

= = --_cc121dc2-ac33-499b-aa37-8e1f0f44e846_-- From paulej@packetizer.com Tue May 1 04:26:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44221F8767 for ; Tue, 1 May 2012 04:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz2WEodamJnS for ; Tue, 1 May 2012 04:26:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DCEEA21F8762 for ; Tue, 1 May 2012 04:26:14 -0700 (PDT) Received: from [156.106.244.108] ([156.106.244.108]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q41BQA2m001790 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 May 2012 07:26:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335871571; bh=HDw8NXMqdrMEiZrtsp4HEH8GirP/5nMR7Vqlg8qnye8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=tzBrD4+DPQdpVNysUsRSBDQvOnSaDcDG6dsnvYVD3vviCORTYGx7jT4q0GN4uHEg2 3s+rzblDCFrrrQWpUlVXEG4oDB80LhyJyaobuJFfPFnyMInQLzR0df2y93bXoHS4K7 yTqvoQOTJqPRLxYMSBwfdomVit4ZXjpZRomEAfGQ= Message-ID: <4F9FC854.8090804@packetizer.com> Date: Tue, 01 May 2012 07:26:12 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: dave Cruse References:

In-Reply-To: Content-Type: multipart/alternative; boundary="------------020105020207020402080206" Cc: glavers@cisco.com, sipcore@ietf.org, gsalguei@cisco.com Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 11:26:19 -0000 This is a multi-part message in MIME format. --------------020105020207020402080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, I think the IETF largely rejected this proposal, so what I will say is probably of little value. Q1) The proposal is transport independent. Q2) The "immersive" concept could be applied to voice, video, or other media type. I don't think anyone would think of fax as immersive, but there are no limits on interpretation. The reason I say this is that the "immersive" tag is a SIP header value, not an SDP value. Therefore, it is largely divorced from the media types used in a call. At a high level, the proposal merely defined a way for a device to indicate that it would like to make a call to a device that is "immersive" or to advertise the fact that a device is "immersive". It fits into the "caller preferences" framework defined by the IETF. Unfortunately, the IETF did not like it, citing that "immersive" is not well-defined and also admitting that the whole "caller preferences" work is not specified very well. As we understood the intent of caller preferences, we believed that "immersive" would be a valuable addition, for example, to allow me to make a call to you and indicate that I want an "immersive" device. What "immersive" might mean to me and you might be different, but the thinking was that if you have a desk phone and an HD video terminal, then you would mark the HD video terminal as "immersive". This would allow me to call you from my HD video terminal to your. Without this addition to SIP, then if I call you, both your desk phone and HD video terminal might ring. You might answer my HD video call on your phone. That's a bit of a waste, right? So, SIP will remain "dumb" in this regard, I guess. Paul On 5/1/2012 3:12 AM, dave Cruse wrote: > > Hello Glen, > > I have some few basic questions here: > > Q1. Does this feature support TLS UDP OR just TCP only? > > > Q2. What if Endpoint support only FAX but not Video? > > Regards > - Dave > > > Date: Mon, 5 Mar 2012 13:36:52 -0800 > > From: glavers@cisco.com > > To: sipcore@ietf.org > > CC: paulej@packetizer.com; gsalguei@cisco.com > > Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt > > > > Folks, > > I have submitted a new draft to define an 'immersive' media feature > tag. The draft is posted at: > http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability > > > > The authors would appreciate feedback and or detailed comments. > > > > Many thanks, > > Glen > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------020105020207020402080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave,

I think the IETF largely rejected this proposal, so what I will say is probably of little value.

Q1) The proposal is transport independent.
Q2) The "immersive" concept could be applied to voice, video, or other media type. I don't think anyone would think of fax as immersive, but there are no limits on interpretation. The reason I say this is that the "immersive" tag is a SIP header value, not an SDP value. Therefore, it is largely divorced from the media types used in a call.

At a high level, the proposal merely defined a way for a device to indicate that it would like to make a call to a device that is "immersive" or to advertise the fact that a device is "immersive". It fits into the "caller preferences" framework defined by the IETF.

Unfortunately, the IETF did not like it, citing that "immersive" is not well-defined and also admitting that the whole "caller preferences" work is not specified very well. As we understood the intent of caller preferences, we believed that "immersive" would be a valuable addition, for example, to allow me to make a call to you and indicate that I want an "immersive" device. What "immersive" might mean to me and you might be different, but the thinking was that if you have a desk phone and an HD video terminal, then you would mark the HD video terminal as "immersive". This would allow me to call you from my HD video terminal to your. Without this addition to SIP, then if I call you, both your desk phone and HD video terminal might ring. You might answer my HD video call on your phone. That's a bit of a waste, right? So, SIP will remain "dumb" in this regard, I guess.

Paul

On 5/1/2012 3:12 AM, dave Cruse wrote:

Hello Glen,

I have some few basic questions here:

Q1. Does this feature support TLS UDP OR just TCP only?

Q2. What if Endpoint support only FAX but not Video?

Regards
- Dave

> Date: Mon, 5 Mar 2012 13:36:52 -0800
> From: glavers@cisco.com
> To: sipcore@ietf.org
> CC: paulej@packetizer.com; gsalguei@cisco.com
> Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt
>
> Folks,
> I have submitted a new draft to define an 'immersive' media feature tag. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability
>
> The authors would appreciate feedback and or detailed comments.
>
> Many thanks,
> Glen
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--------------020105020207020402080206-- From keith.drage@alcatel-lucent.com Tue May 1 05:49:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0282721E8458 for ; Tue, 1 May 2012 05:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.094 X-Spam-Level: X-Spam-Status: No, score=-110.094 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLy5HwhFiQd for ; Tue, 1 May 2012 05:49:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id AD87821E84E0 for ; Tue, 1 May 2012 05:49:05 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q41Cn1hI010103 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 May 2012 14:49:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 1 May 2012 14:49:01 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , dave Cruse Date: Tue, 1 May 2012 14:49:00 +0200 Thread-Topic: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Ac0njT/xbavD3ziuShC0euzMOhXBIAACg4fQ Message-ID: References:

<4F9FC854.8090804@packetizer.com> In-Reply-To: <4F9FC854.8090804@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE22693D898FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "glavers@cisco.com" , "sipcore@ietf.org" , "gsalguei@cisco.com" Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 12:49:07 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE22693D898FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The key objection was that based on the submitted text, the sender and rece= iver would not necessarily have the same understanding of what the feature = tags mean. Come back with something much more specific on the capabilities = supported and it would stand a better chance of success. Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: 01 May 2012 12:26 To: dave Cruse Cc: glavers@cisco.com; sipcore@ietf.org; gsalguei@cisco.com Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt Dave, I think the IETF largely rejected this proposal, so what I will say is prob= ably of little value. Q1) The proposal is transport independent. Q2) The "immersive" concept could be applied to voice, video, or other medi= a type. I don't think anyone would think of fax as immersive, but there ar= e no limits on interpretation. The reason I say this is that the "immersiv= e" tag is a SIP header value, not an SDP value. Therefore, it is largely d= ivorced from the media types used in a call. At a high level, the proposal merely defined a way for a device to indicate= that it would like to make a call to a device that is "immersive" or to ad= vertise the fact that a device is "immersive". It fits into the "caller pr= eferences" framework defined by the IETF. Unfortunately, the IETF did not like it, citing that "immersive" is not wel= l-defined and also admitting that the whole "caller preferences" work is no= t specified very well. As we understood the intent of caller preferences, = we believed that "immersive" would be a valuable addition, for example, to= allow me to make a call to you and indicate that I want an "immersive" dev= ice. What "immersive" might mean to me and you might be different, but the= thinking was that if you have a desk phone and an HD video terminal, then = you would mark the HD video terminal as "immersive". This would allow me t= o call you from my HD video terminal to your. Without this addition to SIP= , then if I call you, both your desk phone and HD video terminal might ring= . You might answer my HD video call on your phone. That's a bit of a wast= e, right? So, SIP will remain "dumb" in this regard, I guess. Paul On 5/1/2012 3:12 AM, dave Cruse wrote: Hello Glen, I have some few basic questions here: Q1. Does this feature support TLS UDP OR just TCP only? Q2. What if Endpoint support only FAX but not Video? Regards - Dave > Date: Mon, 5 Mar 2012 13:36:52 -0800 > From: glavers@cisco.com > To: sipcore@ietf.org > CC: paulej@packetizer.com; gsalguei@cisco.c= om > Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt > > Folks, > I have submitted a new draft to define an 'immersive' media feature tag. = The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-imm= ersive-capability > > The authors would appreciate feedback and or detailed comments. > > Many thanks, > Glen > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_EDC0A1AE77C57744B664A310A0B23AE22693D898FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The key objection was that based on th= e submitted text, the sender and receiver would not necessarily have the same understanding of what the feature tags mean. Come back with something much = more specific on the capabilities supported and it would stand a better chance o= f success.

Keith

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Be= half Of Paul E. Jones
Sent: 01 May 2012 12:26
To: dave Cruse
Cc: glavers@cisco.com; sipcore@ietf.org; gsalguei@cisco.com
Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt

= Dave,

I think the IETF largely rejected this proposal, so what I will say is prob= ably of little value.

Q1) The proposal is transport independent.
Q2) The "immersive" concept could be applied to voice, video, or other media type. I don't think anyone would think of fax as immersiv= e, but there are no limits on interpretation. The reason I say this is t= hat the "immersive" tag is a SIP header value, not an SDP value. = ; Therefore, it is largely divorced from the media types used in a call.

At a high level, the proposal merely defined a way for a device to indicate that it would like to make a call to a device that is "immersive"= or to advertise the fact that a device is "immersive". It fits into the "caller preferences" framework defined by the IETF.

Unfortunately, the IETF did not like it, citing that "immersive" = is not well-defined and also admitting that the whole "caller preferences" work is not specified very well. As we understood t= he intent of caller preferences, we believed that "immersive" would be a valuable addition, for example, to allow me to make a call to yo= u and indicate that I want an "immersive" device. What "= immersive" might mean to me and you might be different, but the thinking was that if y= ou have a desk phone and an HD video terminal, then you would mark the HD vide= o terminal as "immersive". This would allow me to call you fr= om my HD video terminal to your. Without this addition to SIP, then if I call you, both your desk phone and HD video terminal might ring. You might answer my HD video call on your phone. That's a bit of a waste, right? So, SIP will remain "dumb" in this regard, I guess.<= br>
Paul

On 5= /1/2012 3:12 AM, dave Cru= se wrote:

Hello Glen,

I have some few basic questions here:

Q1. Does this feature support TLS UDP OR just TCP only?

Q2. What if Endpoint support only FAX but not Video?

Regards
- Dave

= > Date: Mon, 5 Mar 2012 13:36:52 -0800
> From: glavers@cisco.com
> To: sipcore@ietf.org
> CC: paulej@packetizer.com= ; gsalguei@cisco.com
> Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt >
> Folks,
> I have submitted a new draft to define an 'immersive' media feature ta= g. The draft is posted at: http://tools.ietf.org/html/draft-lavers-sipcore-immersive-capability
>
> The authors would appreciate feedback and or detailed comments.
>
> Many thanks,
> Glen
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore

_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org=
/mailman/listinfo/sipcore

--_000_EDC0A1AE77C57744B664A310A0B23AE22693D898FRMRSSXCHMBSC3d_-- From ivo.sedlacek@ericsson.com Thu May 3 04:00:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289AE21F855A for ; Thu, 3 May 2012 04:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH41gSnFHCwr for ; Thu, 3 May 2012 03:59:59 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1051D21F84F0 for ; Thu, 3 May 2012 03:59:58 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-6f-4fa2652d32d1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9D.80.26681.D2562AF4; Thu, 3 May 2012 12:59:57 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 3 May 2012 12:59:56 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Date: Thu, 3 May 2012 12:59:56 +0200 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddw== Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E12197E3BB890ESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 11:00:00 -0000 --_000_3A324A65CCACC64289667DFAC0B88E12197E3BB890ESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can I please get experts' view on the issue below? Use case: - the UA contains several applications - each application is associated with a unique contact - all contacts of all the applications have the same IP address and port - the UA registers all contacts of all the applications using a single REGI= STER request, as due to the potentially large number of applications it is = not feasible to register each contact individually As long as outbound is NOT used, this works correctly. Issue: Once the UA would like to create several registration flows using outbound = for reliability, the REGISTER request with multiple contacts sent by the UA= can be rejected by the registrar since RFC5626 states: --------------------------------- Therefore, if the Contact header field contains more than one header field value with a non-zero expiration and any of these header field values contain a "reg-id" Contact header field parameter, the entire registration SHOULD be rejected with a 400 (Bad Request) response. The justification for recommending rejection versus making it mandatory is that the receiver is allowed by [RFC3261] to squelch (not respond to) excessively malformed or malicious messages. --------------------------------- I can understand the reason for rejection where the contacts represent diff= erent UA instances, or have different IP addresses or ports. However, the same sip.instance *and* the same IP address and port are used = in each of the contact registered by the REGISTER request in the case above= . I also assume that the reg-id would be the same for each contact associat= ed with a given flow. Is there a reason why REGISTER with multiple contacts, each having the same= sip.instance, the same IP address and port and the same reg-id, should be = rejected? Thank you for clarification. Kind regards Ivo Sedlacek Ericsson GF Technology, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_3A324A65CCACC64289667DFAC0B88E12197E3BB890ESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

can I please get experts' view on the = ;issue=20 below?

Use case:
- the UA contains several=20 applications
- each application is associated with a unique contact
-= all=20 contacts of all the applications have the same IP address and port
- the= UA=20 registers all contacts of all the applications using a single REGISTER requ= est,=20 as due to the potentially large number of applications it is not feasible t= o=20 register each contact individually

As long as outbound is NOT used, this work= s=20 correctly.

Issue:

Once the UA would like to create several=20 registration flows using outbound for reliability, the REGISTER request wit= h=20 multiple contacts sent by the UA can be rejected by the registrar since RFC= 5626=20 states:
---------------------------------
Therefore, if the Contact h= eader=20 field contains
   more than one header field value with a non-= zero=20 expiration and any
   of these header field values contain a=20 "reg-id" Contact header field
   parameter, the entire registr= ation=20 SHOULD be rejected with a 400 (Bad
   Request) response. = The=20 justification for recommending rejection
   versus making it=20 mandatory is that the receiver is allowed by
   [RFC3261] to=20 squelch (not respond to) excessively malformed or
   malicious= =20 messages.
---------------------------------

I can understand the reason for rejection = where the=20 contacts represent different UA instances, or have different IP addresses o= r=20 ports.

However, the same sip.instance *and* the s= ame IP=20 address and port are used in each of the contact registered by the REGISTER= =20 request in the case above. I also assume that the reg-id would be the same = for=20 each contact associated with a given flow.

Is there a reason why REGISTER with multip= le=20 contacts, each having the same sip.instance, the same IP address and port a= nd=20 the same reg-id, should be rejected?

Thank you for clarification.

Kind regards

Ivo Sedlacek

Ericsson
GF Technol= ogy,=20 Terminal Standardization
Sweden
Office: +46 10 711=20 9382
ivo.sedlacek@ericsson.com
www.ericsson.com

This communica= tion=20 is confidential. We only send and receive email on the basis of the term se= t out=20 at www.ericsson.com/email_disclaimer

--_000_3A324A65CCACC64289667DFAC0B88E12197E3BB890ESESSCMS0360e_-- From ibc@aliax.net Thu May 3 07:02:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47F21F856F for ; Thu, 3 May 2012 07:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeZ2kO+Dqwh9 for ; Thu, 3 May 2012 07:02:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3621F84C5 for ; Thu, 3 May 2012 07:02:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1535131vbb.31 for ; Thu, 03 May 2012 07:02:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=iPO/LDgFJnxqDCtA45WU6oGr9WDzgf99ZiTSVVoyA/8=; b=J05KDo/YoJXZ3ZjNxukJKYT7PQCTm95JkKaslNJo6VsaA8mdfnRX3gk/RLi8/jqtpu DtGAArA0l8e0Ty7VouNSibimzLdwcTZEnzPd3iY1LtB6Vew+CdQDwciSnhtCvLYE6ltE l3l96i0gGZ6PBmxXQMqstC8rWKGKyN63Fm0/uYf2lC5TSHWv2LxuTWbEwTJsqo3M9lU9 Cw0R2MGaqXgF5u4ZMW2Pmj2Qm5zX+0CiDDpWuDUNpIUZvN7sj5RoOuVSmsgzgA1WHSYQ yGxVkngsIYW8f5zQla3frwLnk10323YazyhbRbMOZrYqIbFXIeymt8cYFGItM/aEPgfY g+gg== Received: by 10.52.38.167 with SMTP id h7mr1046368vdk.109.1336053721304; Thu, 03 May 2012 07:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Thu, 3 May 2012 07:01:40 -0700 (PDT) In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 3 May 2012 16:01:40 +0200 Message-ID: To: Ivo Sedlacek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn1vlXJ683tekllDl5f2tdSYk50kjUK82sWVeX3xDu/vubpSIZILPy3tijyIXMu+Svk9/Qw Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:02:02 -0000 2012/5/3 Ivo Sedlacek : > Is there a reason why REGISTER with multiple contacts, each having the sa= me > sip.instance, the same IP address and port and the same reg-id, should be > rejected? Let me first a question please: what is the purpose of registering various Contact URI's in the same REGISTER (so an unique To header AoR) pointing all of them to the same "device"? This is, if your device registers various bindings for the AoR in the REGISTER's To header, when that AoR is called your device would receive the request with parallel forking for each binding. What is the purpose of that? --=20 I=C3=B1aki Baz Castillo From ivo.sedlacek@ericsson.com Thu May 3 07:27:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A0521F85E3 for ; Thu, 3 May 2012 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB-OmwEIdBJ2 for ; Thu, 3 May 2012 07:27:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2FE21F85A2 for ; Thu, 3 May 2012 07:27:23 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-c1-4fa295ca1768 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 65.BC.03534.AC592AF4; Thu, 3 May 2012 16:27:22 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 3 May 2012 16:27:22 +0200 From: Ivo Sedlacek To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Thu, 3 May 2012 16:27:20 +0200 Thread-Topic: [sipcore] RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pNVKDTJfr9YrYSCq+IszFdEw+IQAAKMxw Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BBA2F@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:27:24 -0000 SGVsbG8sDQoNCj4gVGhpcyBpcywgaWYgeW91ciBkZXZpY2UgcmVnaXN0ZXJzIHZhcmlvdXMgYmlu ZGluZ3MgZm9yIHRoZSBBb1IgaW4gdGhlIFJFR0lTVEVSJ3MgDQo+IFRvIGhlYWRlciwgd2hlbiB0 aGF0IEFvUiBpcyBjYWxsZWQgeW91ciBkZXZpY2Ugd291bGQgcmVjZWl2ZSB0aGUgcmVxdWVzdCB3 aXRoIHBhcmFsbGVsIA0KPiBmb3JraW5nIGZvciBlYWNoIGJpbmRpbmcuIFdoYXQgaXMgdGhlIHB1 cnBvc2Ugb2YgdGhhdD8gDQoNCkFwcGxpY2F0aW9ucyBoYXZlIGRpZmZlcmVudCBjYXBhYmlsaXRp ZXMsIGluZGljYXRlZCBpbiB0aGUgYXNzb2NpYXRlZCBjb250YWN0cyB1c2luZyB0aGUgbWVjaGFu aXNtIGluIFJGQyAzODQwLg0KVGhlIHJlZ2lzdHJhciB0aGVuIHVzZXMgdGhlIG1lY2hhbmlzbSBp biBSRkMgMzg0MSB0byBjaG9vc2UgdGhlIGNvcnJlY3QgY29udGFjdC4NCg0KS2luZCByZWdhcmRz DQoNCkl2byBTZWRsYWNlayANCg0KRXJpY3Nzb24NCkdGIFRlY2hub2xvZ3ksIFRlcm1pbmFsIFN0 YW5kYXJkaXphdGlvbg0KU3dlZGVuDQpPZmZpY2U6ICs0NiAxMCA3MTEgOTM4Mg0KaXZvLnNlZGxh Y2VrQGVyaWNzc29uLmNvbQ0Kd3d3LmVyaWNzc29uLmNvbQ0KDQpUaGlzIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJh c2lzIG9mIHRoZSB0ZXJtIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFp bWVyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgScOxYWtpIA0KPiBCYXogQ2FzdGlsbG8gDQo+IFNlbnQ6IDMuIGt2xJt0bmEgMjAxMiAxNjow MiANCj4gVG86IEl2byBTZWRsYWNlayANCj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcgDQo+IFN1Ympl Y3Q6IFJlOiBbc2lwY29yZV0gUkZDNTYyNiBhbmQgUkVHSVNURVIgd2l0aCBtdWx0aXBsZSBjb250 YWN0cyANCj4gDQo+IDIwMTIvNS8zIEl2byBTZWRsYWNlayA8aXZvLnNlZGxhY2VrQGVyaWNzc29u LmNvbT46IA0KPiA+IElzIHRoZXJlIGEgcmVhc29uIHdoeSBSRUdJU1RFUiB3aXRoIG11bHRpcGxl IGNvbnRhY3RzLCBlYWNoIGhhdmluZyB0aGUgIA0KPiA+IHNhbWUgc2lwLmluc3RhbmNlLCB0aGUg c2FtZSBJUCBhZGRyZXNzIGFuZCBwb3J0IGFuZCB0aGUgc2FtZSByZWctaWQsICANCj4gPiBzaG91 bGQgYmUgcmVqZWN0ZWQ/IA0KPiANCj4gTGV0IG1lIGZpcnN0IGEgcXVlc3Rpb24gcGxlYXNlOiB3 aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHJlZ2lzdGVyaW5nIHZhcmlvdXMgQ29udGFjdCANCj4gVVJJ J3MgaW4gdGhlIHNhbWUgUkVHSVNURVIgKHNvIGFuIHVuaXF1ZSBUbyBoZWFkZXIgDQo+IEFvUikg cG9pbnRpbmcgYWxsIG9mIHRoZW0gdG8gdGhlIHNhbWUgImRldmljZSI/IA0KPiANCj4gVGhpcyBp cywgaWYgeW91ciBkZXZpY2UgcmVnaXN0ZXJzIHZhcmlvdXMgYmluZGluZ3MgZm9yIHRoZSBBb1Ig aW4gdGhlIFJFR0lTVEVSJ3MgDQo+IFRvIGhlYWRlciwgd2hlbiB0aGF0IEFvUiBpcyBjYWxsZWQg eW91ciBkZXZpY2Ugd291bGQgcmVjZWl2ZSB0aGUgcmVxdWVzdCB3aXRoIHBhcmFsbGVsIA0KPiBm b3JraW5nIGZvciBlYWNoIGJpbmRpbmcuIFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhhdD8gDQo+ IA0KPiAtLSANCj4gScOxYWtpIEJheiBDYXN0aWxsbyANCj4gPGliY0BhbGlheC5uZXQ+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QgDQo+IHNpcGNvcmVAaWV0Zi5vcmcgDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSANCj4g From ibc@aliax.net Thu May 3 07:52:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984B321F848A for ; Thu, 3 May 2012 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc1RCgWjo2bP for ; Thu, 3 May 2012 07:52:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B46E521F85CF for ; Thu, 3 May 2012 07:52:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1595745vbb.31 for ; Thu, 03 May 2012 07:52:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Sa+rIiKWxx7oQrzL0uxOY+ziyTSxxq9ncb8WR4ry8JE=; b=eJR/yPCzqI0Skx9PFZJ2pxbjXUt7tJFD3hzeuIA0rS3+mRBtjcNdtriCXd62G1J4oi Fnw5V8OFq3+ymxi534TURy3t2/iCEGuwO7+VGTUxF+SkA+pfYTA+AMI9mAAb2i9mNSPE Lhwf04AXK6HjUq2Dtp4bk3WAZP+L+ixHPS8oqeIR3qk9VETPmbSsyE6cg074sLU0ExZz U95kujsI6TBgoucp5hmYPeknfvbVXoYIR4yd0GeNFFXql6zfj54Du6H/y+tizZKac2Xg tn/jfYZYt/s9NcCtDh9sxxjqpC9+fjcOuKB8WSKijC6KwRtBOSRJw+RboYSJM+rFZtja OCdg== Received: by 10.220.115.130 with SMTP id i2mr1442528vcq.72.1336056741236; Thu, 03 May 2012 07:52:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Thu, 3 May 2012 07:52:01 -0700 (PDT) In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BBA2F@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBA2F@ESESSCMS0360.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 3 May 2012 16:52:01 +0200 Message-ID: To: Ivo Sedlacek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlRsTol20GkP+5yAv+7qaE54xgDQZZv5BvkkfEj6MnTahg/Wd8ph9v912IpiHTppmiWe5WQ Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:52:22 -0000 2012/5/3 Ivo Sedlacek : >> This is, if your device registers various bindings for the AoR in the RE= GISTER's >> To header, when that AoR is called your device would receive the request= with parallel >> forking for each binding. What is the purpose of that? > > Applications have different capabilities, indicated in the associated con= tacts using the mechanism in RFC 3840. > The registrar then uses the mechanism in RFC 3841 to choose the correct c= ontact. Thanks. Then I agree that limiting the number of Contact instances in the REGISTER is an artificial limitation (in case all of them include the same instance and reg-id parameters). --=20 I=C3=B1aki Baz Castillo From dworley@avaya.com Thu May 3 08:37:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484F521F850C for ; Thu, 3 May 2012 08:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkBmXnTuvNb4 for ; Thu, 3 May 2012 08:37:23 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id AC19D21F84F0 for ; Thu, 3 May 2012 08:37:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKlok/GmAcF/2dsb2JhbABEsnaBB4IJAQEBAQIBEihECwIBCA0FAyEQMhcOAQEEARIIGodmBZ0qnS2QJWMEnBaKKoME X-IronPort-AV: E=Sophos;i="4.75,524,1330923600"; d="scan'208";a="7410780" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 May 2012 11:37:21 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 May 2012 11:34:22 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 3 May 2012 11:37:21 -0400 From: "Worley, Dale R (Dale)" To: Ivo Sedlacek , "sipcore@ietf.org" Date: Thu, 3 May 2012 11:37:20 -0400 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddwAIFbhD Message-ID: References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:37:24 -0000 > From: Ivo Sedlacek [ivo.sedlacek@ericsson.com] >=20 > I can understand the reason for rejection where the contacts represent > different UA instances, or have different IP addresses or ports. >=20 > However, the same sip.instance *and* the same IP address and port are > used in each of the contact registered by the REGISTER request in the > case above. I also assume that the reg-id would be the same for each > contact associated with a given flow. >=20 > Is there a reason why REGISTER with multiple contacts, each having the > same sip.instance, the same IP address and port and the same reg-id, > should be rejected? The underlying concept of "SIP Outbound" processing is that the "contact" that is registered is not the contact URI that is provided, but the *flow* which the UA created to the edge proxy -- a request to the AoR is to be routed to the UA by being sent down the specified flow. Of course, the contact URI will be used as the request-URI, but the request will not be routed based on RFC 3263 processing of the contact URI. An advantage of that concept is that the contact URI provided by the UA does not need to be a URI by which the edge proxy could contact the UA. And in many practical situations, the UA may not be able to determine a usable contact URI. Within that concept, it is difficult for a UA to use one REGISTER for multiple contacts, because all contacts would necessarily be associated with the same flow, and if they are all reached via the same flow, how are they distinguished? In your architecture, I think the concept is that the physical UA device would demultiplex requests to the various effective UAs based on the request-URI of incoming requests. Within that context, it seems reasonable that multiple contact URIs could be presented in one Outbound REGISTER. But I don't think that RFC 5626 envisioned that possibility -- RFC 5626 assumes that each flow originates from only one UA. However, looking at the algorithms presented in RFC 5626, it appears to me that if your device sends two different REGISTERs for two different UAs down the *same* flow, the two UAs become registered to the same flow, but with their different contact URIs. Important point: This requires that the different UAs use *different* sip.instance values, otherwise the second registration replaces the first registration. And now that you've raised the question, it appears to be reasonable that multiple such contacts could be registered with one REGISTER request; the algorithms in the RFC would handle the situation in the obvious way. One critical thing is that if you want the proxy to treat these various application UAs as distinct UAs, you will have to provide each one with a different sip.instance. The philosophy of SIP is that the sip.instance is unique to the UA, and no aspect of SIP will ever be designed to "correctly" handle multiple UAs that present the same sip.instance. Once you give each UA a different sip.instance, each UA has an independent space of reg-ids, as reg-id is only used when it is combined with the sip.instance. However, it would probably be easier to have the device register one contact without any capabilities declaration. Then, all calls are routed to the device, and its demultiplexer can determine which of the application UAs should receive forks of the INVITE, and reject the INVITE if there are none. Dale From kpfleming@digium.com Thu May 3 08:47:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E930E21F84D6 for ; Thu, 3 May 2012 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY4mE9wlKIf1 for ; Thu, 3 May 2012 08:47:40 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70121F84C3 for ; Thu, 3 May 2012 08:47:40 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SPyFm-0002PY-Vu for sipcore@ietf.org; Thu, 03 May 2012 10:47:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E8682D8004 for ; Thu, 3 May 2012 10:47:38 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmN4i25xzkUj for ; Thu, 3 May 2012 10:47:38 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 771E7D8002 for ; Thu, 3 May 2012 10:47:38 -0500 (CDT) Message-ID: <4FA2A88B.3020703@digium.com> Date: Thu, 03 May 2012 10:47:23 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:47:41 -0000 On 05/03/2012 10:37 AM, Worley, Dale R (Dale) wrote: > However, it would probably be easier to have the device register one > contact without any capabilities declaration. Then, all calls are > routed to the device, and its demultiplexer can determine which of the > application UAs should receive forks of the INVITE, and reject the > INVITE if there are none. Some useful information would be lost here though: in the OP's proposed configuration, when the UA receives an INVITE, the will have already done the RFC3841 matching process, and evidence of that process will appear in the request sent to the UA. With a single Contact URI registered, the UA would have to do the caller preferences matching itself to determine which of its internal applications to deliver the request to. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From salinisngh1@gmail.com Thu May 3 08:50:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D522521F85FB for ; Thu, 3 May 2012 08:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl1kgCbH9bg3 for ; Thu, 3 May 2012 08:50:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE3B21F85C4 for ; Thu, 3 May 2012 08:50:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1661516vbb.31 for ; Thu, 03 May 2012 08:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JKmVogMr6HuxHoEItYeArfvpyTI2kLE5K3E42VzYjH8=; b=OT/BnNYzFlAwL3B62qya52Ws7/xKo30l0iUIDtrNeCDj04mBnXKHftKnLaY+rZHLba VLOxvqJpFuV6ogE0IH3PoBPynNZFdCMgmjDXpyhaAqLqNPyJ8Tfu22N59RXbIM8nDK/+ Jp2VplExifNPErtw4IeWNfKaDOOFk5NeeiqZf9UMEC1SlBpKFgu7eGNbGXz7lbj7gsNl eFSpYdr63WaWlDLjtPbX9tElF1jv00reAySERqx4KR3ICbDPZBLwErZSqXfVevcmWGtb ZLbZ3HO7UHkVGwF2E7LJ6KFcvDsSv9uMoxWbiYcCf9vHB20J+oDRzCFkMLc2FK7RYdKO oLGA== MIME-Version: 1.0 Received: by 10.52.24.129 with SMTP id u1mr1236938vdf.77.1336059844271; Thu, 03 May 2012 08:44:04 -0700 (PDT) Received: by 10.220.22.11 with HTTP; Thu, 3 May 2012 08:44:04 -0700 (PDT) Date: Thu, 3 May 2012 21:14:04 +0530 Message-ID: From: salini singh To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Types of Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:50:13 -0000 Hi, How do we distinguish URGENT,NON_URGENT,NORMAL,EMERGENCY calls in our day to day practical/real-life? Regards -salini From pkyzivat@alum.mit.edu Thu May 3 09:17:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C889721F8639 for ; Thu, 3 May 2012 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Cp9s7kpMdS for ; Thu, 3 May 2012 09:17:52 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 337CC21F8625 for ; Thu, 3 May 2012 09:17:52 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 5NMd1j0021YDfWL58UHn3X; Thu, 03 May 2012 16:17:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 5UHr1j00i07duvL3gUHrab; Thu, 03 May 2012 16:17:52 +0000 Message-ID: <4FA2AFAE.2050600@alum.mit.edu> Date: Thu, 03 May 2012 12:17:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Types of Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 16:17:52 -0000 salini, I'm not certain of the context in which you are asking this question. In general I think such things are better discussed on sip-implementors@lists.cs.columbia.edu. So if you want to have an extended discussion I ask you to go there. But I'll give you the short version of my opinion: In practical/real-life we don't have a clear way to indicate this prior to answering the call. After answering, it gets handled informally in-band. In some cases I suppose it is inferred based on indicated identity of the caller. SIP provides some mechanisms for this, but whether they are useful in practice is debatable. The Priority header allows the caller to indicate his opinion of the priority of the call. But the callee may choose not to believe this because of possibility for abuse. Even if it is believed, there is no guarantee that it will be acted on at the callee end of the call, or how. There is also http://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns/ which specifies how to use Alert-Info to cause differing sorts of alerting, that can be used to alert differently due to call priority. Again, if you want to discuss this further, please do it on sip-implementors, unless you have a specific issue to make about a specific core sip capability. Thanks, Paul On 5/3/12 11:44 AM, salini singh wrote: > Hi, > > How do we distinguish URGENT,NON_URGENT,NORMAL,EMERGENCY calls in our > day to day practical/real-life? > > Regards > -salini > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Thu May 3 11:04:20 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8321F862B for ; Thu, 3 May 2012 11:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.302 X-Spam-Level: X-Spam-Status: No, score=-103.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwkIKhYzYxkv for ; Thu, 3 May 2012 11:04:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E49E921F854E for ; Thu, 3 May 2012 11:04:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE/Hok/GmAcF/2dsb2JhbABEsnyBB4IJAQEBAQIBEihECwIBCA0pEDIlAQEEARoah2YFnVidI5AlYwScFooqgwQ X-IronPort-AV: E=Sophos;i="4.75,526,1330923600"; d="scan'208";a="345610611" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 May 2012 14:02:51 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 May 2012 14:00:59 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 3 May 2012 14:03:57 -0400 From: "Worley, Dale R (Dale)" To: Ivo Sedlacek , "sipcore@ietf.org" Date: Thu, 3 May 2012 14:02:52 -0400 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddwAOxWnQ Message-ID: References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 18:04:20 -0000 > the UA registers all contacts of all the applications using a single REGI= STER request, as due to the potentially large number of applications it is = not feasible to register each contact individually If there really is enough applications that registering each one individual= ly is not feasible, beware that there may be so many that the redirection process can= 't handle them properly. Dale From Ranjit.Avasarala@Polycom.com Thu May 3 22:37:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B51D21F855F for ; Thu, 3 May 2012 22:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U8Ur4KW64wK for ; Thu, 3 May 2012 22:37:21 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 37AEE21F8566 for ; Thu, 3 May 2012 22:37:21 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Fri, 4 May 2012 13:37:19 +0800 From: "Avasarala, Ranjit" To: salini singh , "sipcore@ietf.org" Date: Fri, 4 May 2012 13:37:16 +0800 Thread-Topic: [sipcore] Types of Call Thread-Index: Ac0pRHMdcJUzk4p7T1CtBYbHjjEc6wAcwVyg Message-ID: <1F2A2C70609D9E41844A2126145FC09804BCD24E3F@HKGMBOXPRD22.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Types of Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 05:37:22 -0000 Hi Salini Currently there is no means to distinguish the calls as urgent, normal, eme= rgency, etc. but if you are dialing an emergency call, you would be dialin= g to a 911 kind of number identified by a special URL e.g. sip:911@..... Regards Ranjit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of salini singh Sent: Thursday, May 03, 2012 9:14 PM To: sipcore@ietf.org Subject: [sipcore] Types of Call Hi, How do we distinguish URGENT,NON_URGENT,NORMAL,EMERGENCY calls in our day t= o day practical/real-life? Regards -salini _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From ivo.sedlacek@ericsson.com Thu May 3 23:21:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4214A21F8726 for ; Thu, 3 May 2012 23:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C56EqhKm5nmO for ; Thu, 3 May 2012 23:21:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC7E821F8724 for ; Thu, 3 May 2012 23:21:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-7a-4fa37573562e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5B.AB.25560.37573AF4; Fri, 4 May 2012 08:21:40 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 4 May 2012 08:21:39 +0200 From: Ivo Sedlacek To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Fri, 4 May 2012 08:21:38 +0200 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddwAIFbhDACAeKSA= Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BBB8C@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 06:21:42 -0000 Hello, Please see below. Kind regards Ivo Sedlacek=20 Ericsson GF Technology, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Worley,=20 > Dale R (Dale)=20 > Sent: 3. kv=ECtna 2012 17:37=20 > To: Ivo Sedlacek; sipcore@ietf.org=20 > Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts=20 >=20 > > From: Ivo Sedlacek [ivo.sedlacek@ericsson.com]=20 > > =20 > > I can understand the reason for rejection where the contacts represent = =20 > > different UA instances, or have different IP addresses or ports.=20 > > =20 > > However, the same sip.instance *and* the same IP address and port are = =20 > > used in each of the contact registered by the REGISTER request in the = =20 > > case above. I also assume that the reg-id would be the same for each =20 > > contact associated with a given flow.=20 > > =20 > > Is there a reason why REGISTER with multiple contacts, each having the = =20 > > same sip.instance, the same IP address and port and the same reg-id, =20 > > should be rejected?=20 >=20 > The underlying concept of "SIP Outbound" processing is that the "contact"= that is=20 > registered is not the contact URI that is provided, but the *flow* which = the UA created=20 > to the edge proxy -- a request to the AoR is to be routed to the UA by be= ing sent=20 > down the specified flow. Of course, the contact URI will be used as the = request-URI,=20 > but the request will not be routed based on RFC 3263 processing of the co= ntact URI.=20 >=20 >=20 > An advantage of that concept is that the contact URI provided by the UA d= oes not=20 > need to be a URI by which the edge proxy could contact the UA. And in ma= ny practical=20 > situations, the UA may not be able to determine a usable contact URI.=20 This seems to be OK for the desired use case. >=20 > Within that concept, it is difficult for a UA to use one REGISTER for mul= tiple contacts,=20 > because all contacts would necessarily be associated with the same flow, = and if they=20 > are all reached via the same flow, how are they distinguished? Each contact is unique, and distinguished by indicated support of capabilit= ies. =20 >=20 > In your architecture, I think the concept is that the physical UA device = would demultiplex=20 > requests to the various effective UAs based on the request-URI of incomin= g requests.=20 > Within that context, it seems reasonable that multiple contact URIs coul= d be presented=20 > in one Outbound REGISTER. But I don't think that RFC 5626 envisioned tha= t possibility=20 > -- RFC 5626 assumes that each flow originates from only one UA.=20 The device acts as SIP UA towards the registrar so the device should have o= nly one sip.instance as according to RFC5626, the sip.instance identifies a= specific UA instance. I.e., the flow originates from only one SIP UA. >=20 > However, looking at the algorithms presented in RFC 5626, it appears to m= e that if=20 > your device sends two different REGISTERs for two different UAs down the = *same* flow,=20 > the two UAs become registered to the same flow, but with their different = contact=20 > URIs. Important=20 > point: This requires that the different UAs use *different* sip.instance= values,=20 > otherwise the second registration replaces the first registration.=20 >=20 > And now that you've raised the question, it appears to be reasonable that= multiple=20 > such contacts could be registered with one REGISTER request; the algorith= ms in the=20 > RFC would handle the situation in the obvious way.=20 >=20 > One critical thing is that if you want the proxy to treat these various a= pplication=20 > UAs as distinct UAs, you will have to provide each one with a different s= ip.instance.=20 > The philosophy of SIP is that the sip.instance is unique to the UA, and = no aspect=20 > of SIP will ever be designed to "correctly" handle multiple UAs that pres= ent the=20 > same sip.instance.=20 The device acts as SIP UA towards the registrar so the device should have o= nly one sip.instance as according to RFC5626, the sip.instance identifies a= specific UA instance. >=20 > Once you give each UA a different sip.instance, each UA has an independen= t space=20 > of reg-ids, as reg-id is only used when it is combined with the sip.insta= nce.=20 >=20 > However, it would probably be easier to have the device register one cont= act without=20 > any capabilities declaration. Then, all calls are routed to the device, = and its=20 > demultiplexer can determine which of the application UAs should receive f= orks of=20 > the INVITE, and reject the INVITE if there are none.=20 User can have multiple devices (each having the UA with several application= s), registering for the same AoR.=20 Without capability declaration the home proxy could not use RFC3841 to dete= rmine to which device(s) to forks the request. >=20 > Dale=20 > _______________________________________________=20 > sipcore mailing list=20 > sipcore@ietf.org=20 > https://www.ietf.org/mailman/listinfo/sipcore=20 > = From ivo.sedlacek@ericsson.com Fri May 4 00:04:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A3121F86DC for ; Fri, 4 May 2012 00:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6wkT5SKWmci for ; Fri, 4 May 2012 00:04:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E721F86D8 for ; Fri, 4 May 2012 00:04:15 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-a8-4fa37f6ec204 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.A1.25560.E6F73AF4; Fri, 4 May 2012 09:04:14 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 4 May 2012 09:04:13 +0200 From: Ivo Sedlacek To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Fri, 4 May 2012 09:04:13 +0200 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddwAOxWnQABsWh/A= Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 07:04:17 -0000 Hello, I agree that if several contacts are registered, the redirection process ca= n become more complicated. However, that is independent of whether a UA reg= isters several times with a single contact, or registers once with multiple= contacts. Based on the feedback received so far, there doesn't seem to be a technical= reason why multiple contacts (sharing the same IP address and port, the sa= me sip.instance and the same reg-id) in a single REGISTER would not work wi= th outbound. Kind regards Ivo Sedlacek=20 Ericsson GF Technology, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer -----Original Message----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 Sent: 3. kv=ECtna 2012 20:03 To: Ivo Sedlacek; sipcore@ietf.org Subject: RE: RFC5626 and REGISTER with multiple contacts > the UA registers all contacts of all the applications using a single=20 > REGISTER request, as due to the potentially large number of=20 > applications it is not feasible to register each contact individually If there really is enough applications that registering each one individual= ly is not feasible, beware that there may be so many that the redirection p= rocess can't handle them properly. Dale From keith.drage@alcatel-lucent.com Fri May 4 01:55:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732ED21F86E4 for ; Fri, 4 May 2012 01:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.114 X-Spam-Level: X-Spam-Status: No, score=-108.114 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImPWZp6GxfSU for ; Fri, 4 May 2012 01:55:09 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F321F86E3 for ; Fri, 4 May 2012 01:55:08 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q448t0cW027250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 10:55:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 4 May 2012 10:54:38 +0200 From: "DRAGE, Keith (Keith)" To: "Avasarala, Ranjit" , salini singh , "sipcore@ietf.org" Date: Fri, 4 May 2012 10:54:34 +0200 Thread-Topic: [sipcore] Types of Call Thread-Index: Ac0pRHMdcJUzk4p7T1CtBYbHjjEc6wAcwVygAAbb4JA= Message-ID: References: <1F2A2C70609D9E41844A2126145FC09804BCD24E3F@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804BCD24E3F@HKGMBOXPRD22.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sipcore] Types of Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 08:55:09 -0000 There is the possibility of all sorts of indicators, but you need to identi= fy the purpose you expect that indication to be used for. Is it for the des= tination entity, for proxies routeing the call, to be used for identifying = the request endpoint of the call by special routeing, etc. I'd also point out that in the two emergency call architectures I am aware = of, either the Request-URI or the Route header field would be an appropriat= e service URN. Regards Keith -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Avasarala, Ranjit Sent: 04 May 2012 06:37 To: salini singh; sipcore@ietf.org Subject: Re: [sipcore] Types of Call Hi Salini Currently there is no means to distinguish the calls as urgent, normal, eme= rgency, etc. but if you are dialing an emergency call, you would be dialin= g to a 911 kind of number identified by a special URL e.g. sip:911@..... Regards Ranjit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of salini singh Sent: Thursday, May 03, 2012 9:14 PM To: sipcore@ietf.org Subject: [sipcore] Types of Call Hi, How do we distinguish URGENT,NON_URGENT,NORMAL,EMERGENCY calls in our day t= o day practical/real-life? Regards -salini _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri May 4 03:52:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254B721F85FF for ; Fri, 4 May 2012 03:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2STeQZrTgnz for ; Fri, 4 May 2012 03:52:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB2921F85D3 for ; Fri, 4 May 2012 03:52:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2306099vbb.31 for ; Fri, 04 May 2012 03:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=snSTz2iaEJ4YKKxEVzKBkeRtBOMJQWBV0e+FF1cd130=; b=lf9BMxMyrJEnj5rk3f7+AZNKxRbCTDY0Pe4kIqthRON2BF/t1YDQFS6LPBs/u14m6i ccsV46dV7+bXs6cGZRgvsXTOa4yWPBThXjua0TwEi5FUfA4hdYMFacacfR5XnWVLrJmG 1OS/y/+UJM/23R8aetNG0rouxz96D1Q2TpeNz0kdV5kLziL4CVkSLVyvVvrrHTvQm9OP RyufwGWnoY7TbsxPJOju3iO3X7HBKjqLqH2UanWejE6KZWeA8TiZdWY9CMh0FqqnDqin CaK5HG9ez4C7ODr+hGchHtNvYXGVuXrcZnQXEIwoHHtVCHvVBsLp1C/mrArzJSHHAQ8c KSLg== Received: by 10.52.174.199 with SMTP id bu7mr1751786vdc.39.1336121679668; Fri, 04 May 2012 01:54:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Fri, 4 May 2012 01:54:19 -0700 (PDT) In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 May 2012 10:54:19 +0200 Message-ID: To: Ivo Sedlacek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlerzhQwvWU52b4u7ZTOHwiAinL7SEbFoFgMmUpYILv2ayvEJuCdqXYxnvYGu3e6GE+vHnu Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 10:52:42 -0000 2012/5/4 Ivo Sedlacek : > Based on the feedback received so far, there doesn't seem to be a technic= al reason why multiple contacts (sharing the same IP address and port, the = same sip.instance and the same reg-id) in a single REGISTER would not work = with outbound. I agree, however take into account that if two contacts don't share the same sip.instance and reg-id (or one of the contacts does not include those parameters) then the registrar should reject the request, right? If so, maybe RFC 5626 tries to simplify it by avoiding such tedious parameters comparison in server side. Also take into account that the contact IP:port is just "ignored" when using Outbound (the registrar just matches the contact using the sip.instance and reg-id params). --=20 I=C3=B1aki Baz Castillo From ivo.sedlacek@ericsson.com Fri May 4 04:10:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0221F8717 for ; Fri, 4 May 2012 04:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKRQQ3xCVPnr for ; Fri, 4 May 2012 04:10:04 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B121F86C3 for ; Fri, 4 May 2012 04:09:52 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-2a-4fa3b8ffeacb Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E0.7F.03534.FF8B3AF4; Fri, 4 May 2012 13:09:51 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 4 May 2012 13:09:51 +0200 From: Ivo Sedlacek To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Fri, 4 May 2012 13:09:50 +0200 Thread-Topic: [sipcore] RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0p04s9XALT8QJeTa2+nFtEQzvS/AAEQtNA Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BBDF5@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:10:05 -0000 SGVsbG8sDQoNCnBsZWFzZSBzZWUgYmVsb3cNCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNl ayANCg0KRXJpY3Nzb24NCkdGIFRlY2hub2xvZ3ksIFRlcm1pbmFsIFN0YW5kYXJkaXphdGlvbg0K U3dlZGVuDQpPZmZpY2U6ICs0NiAxMCA3MTEgOTM4Mg0KaXZvLnNlZGxhY2VrQGVyaWNzc29uLmNv bQ0Kd3d3LmVyaWNzc29uLmNvbQ0KDQpUaGlzIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt IHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRv OmliY0BhbGlheC5uZXRdIA0KPiBTZW50OiA0LiBrdsSbdG5hIDIwMTIgMTA6NTQgDQo+IFRvOiBJ dm8gU2VkbGFjZWsgDQo+IENjOiBXb3JsZXksIERhbGUgUiAoRGFsZSk7IHNpcGNvcmVAaWV0Zi5v cmcgDQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUkZDNTYyNiBhbmQgUkVHSVNURVIgd2l0aCBt dWx0aXBsZSBjb250YWN0cyANCj4gDQo+IDIwMTIvNS80IEl2byBTZWRsYWNlayA8aXZvLnNlZGxh Y2VrQGVyaWNzc29uLmNvbT46IA0KPiA+IEJhc2VkIG9uIHRoZSBmZWVkYmFjayByZWNlaXZlZCBz byBmYXIsIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBhIHRlY2huaWNhbCByZWFzb24gDQo+IHdo eSBtdWx0aXBsZSBjb250YWN0cyAoc2hhcmluZyB0aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCBwb3J0 LCB0aGUgc2FtZSBzaXAuaW5zdGFuY2UgDQo+IGFuZCB0aGUgc2FtZSByZWctaWQpIGluIGEgc2lu Z2xlIFJFR0lTVEVSIHdvdWxkIG5vdCB3b3JrIHdpdGggb3V0Ym91bmQuIA0KPiANCj4gSSBhZ3Jl ZSwgaG93ZXZlciB0YWtlIGludG8gYWNjb3VudCB0aGF0IGlmIHR3byBjb250YWN0cyBkb24ndCBz aGFyZSB0aGUgc2FtZSBzaXAuaW5zdGFuY2UgDQo+IGFuZCByZWctaWQgKG9yIG9uZSBvZiB0aGUg Y29udGFjdHMgZG9lcyBub3QgaW5jbHVkZSB0aG9zZSBwYXJhbWV0ZXJzKSB0aGVuIHRoZSByZWdp c3RyYXIgDQo+IHNob3VsZCByZWplY3QgdGhlIHJlcXVlc3QsIHJpZ2h0PyANCg0KVGhhdCBzZWVt cyBPSyAtIGF0IGxlYXN0IHdlIHNlZSBubyBuZWVkIHRvIHN1cHBvcnQgY2FzZXMgd2hlcmUgYWxs IGNvbnRhY3RzIGluIGEgUkVHSVNURVIgcmVxdWVzdCBkb24ndCBzaGFyZSB0aGUgc2FtZSBzaXAu aW5zdGFuY2UgYW5kIHRoZSBzYW1lIHJlZy1pZCAoYW5kIHRoZSBzYW1lIElQIGFkZHJlc3MgYW5k IHBvcnQpLiANCg0KPiBJZiBzbywgbWF5YmUgUkZDIDU2MjYgdHJpZXMgdG8gc2ltcGxpZnkgaXQg YnkgYXZvaWRpbmcgDQo+IHN1Y2ggdGVkaW91cyBwYXJhbWV0ZXJzIGNvbXBhcmlzb24gaW4gc2Vy dmVyIHNpZGUuIA0KPiANCj4gQWxzbyB0YWtlIGludG8gYWNjb3VudCB0aGF0IHRoZSBjb250YWN0 IElQOnBvcnQgaXMganVzdCAiaWdub3JlZCIgd2hlbiB1c2luZyBPdXRib3VuZCANCj4gKHRoZSBy ZWdpc3RyYXIganVzdCBtYXRjaGVzIHRoZSBjb250YWN0IHVzaW5nIHRoZSBzaXAuaW5zdGFuY2Ug YW5kIHJlZy1pZCBwYXJhbXMpLiANCg0KRXhhY3RseSwgYW5kIHRoYXQgaXMgdGhlIHJlYXNvbiB3 ZSBhc3N1bWUgaWRlbnRpY2FsIElQIGFkZHJlc3MgYW5kIHBvcnQsIGJlY2F1c2UgaW5jb21pbmcg cmVxdWVzdHMgYXJlIGdvaW5nIHRvIGJlIHNlbnQgdG8gdGhlIHNhbWUgSVAgbG9jYXRpb24gbm8g bWF0dGVyIHdoaWNoIGNvbnRhY3QgaXMgdXNlZC4NCg0KDQo+IA0KPiANCj4gDQo+IA0KPiAtLSAN Cj4gScOxYWtpIEJheiBDYXN0aWxsbyANCj4gPGliY0BhbGlheC5uZXQ+IA0KPiA= From ibc@aliax.net Fri May 4 04:26:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130DB21F85ED for ; Fri, 4 May 2012 04:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAq+3OSMwz8l for ; Fri, 4 May 2012 04:26:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1564E21F85DF for ; Fri, 4 May 2012 04:26:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2326540vbb.31 for ; Fri, 04 May 2012 04:26:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Q/s7jmD+zNAwJ5sEB/VGL2QDNdLPrMRAVSLcSx6bjzk=; b=PcXAAGJoc4PGRJXUqSk7OvdOlbCuByMrfqu+zarnkhiNc6iYjEjj8TLgX8EYRYygsH s3kB/J789+vn5oncSZjqNOb3nFE88SuwNYdX+OVoURu8opA4XemAOAoNs7SX57gBc3hO vTkEzxIYGCCpIY1xYzbSlcjPTi2frH3SWA36haB6knawPJkRlu6qXgDvjLybgGge8nH/ KgI+djpW9vnSeg8UeSDkX5BFskLVtvXEl9lIxAm76kuureVVY6jcFf7nYmoBDz/TeU+P 9TSJVL4LOYeutJo1/Z65WZxg7Btxgwo/CMABqwSHH0k9j2k9dsRoVD1JM4cyH89LEXro deIQ== Received: by 10.52.38.167 with SMTP id h7mr2874383vdk.109.1336130795534; Fri, 04 May 2012 04:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Fri, 4 May 2012 04:26:15 -0700 (PDT) In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BBDF5@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBDF5@ESESSCMS0360.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 May 2012 13:26:15 +0200 Message-ID: To: Ivo Sedlacek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkiYrYIu2aoFCwg3bvfNSl6pJlvD3iyV80Z8oCOVT8ZT2SlI6Ff1euemf81TOppZMyRDJCk Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:26:37 -0000 2012/5/4 Ivo Sedlacek : >> Also take into account that the contact IP:port is just "ignored" when u= sing Outbound >> (the registrar just matches the contact using the sip.instance and reg-i= d params). > > Exactly, and that is the reason we assume identical IP address and port, = because incoming requests are going to be sent to the same IP location no m= atter which contact is used. So correct me if I'm wrong but in a previous mail you said that sending multiple REGISTER with unique Contact works even using Outbound. Could I know how those REGISTER's Contact headers look? (it would be useful to see two of them). I would like to understand why the registrar stores different bindings when the sip.instance and reg-id are the same. It's not clear for me. --=20 I=C3=B1aki Baz Castillo From ivo.sedlacek@ericsson.com Fri May 4 05:54:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6921F8629 for ; Fri, 4 May 2012 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n54uG5SKd2dW for ; Fri, 4 May 2012 05:54:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74021F8620 for ; Fri, 4 May 2012 05:54:16 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-99-4fa3d177d5fd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 59.7E.26681.771D3AF4; Fri, 4 May 2012 14:54:15 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 4 May 2012 14:54:15 +0200 From: Ivo Sedlacek To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Fri, 4 May 2012 14:54:14 +0200 Thread-Topic: [sipcore] RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0p6Ma2cUyW8QE+SAC26DLlJQDCAgACQ9pw Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E3BBEA3@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBDF5@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 12:54:17 -0000 DQpIZWxsbywNCg0KcGxlYXNlIHNlZSBiZWxvdy4NCg0KS2luZCByZWdhcmRzDQoNCg0KSXZvIFNl ZGxhY2VrIA0KDQpFcmljc3Nvbg0KR0YgVGVjaG5vbG9neSwgVGVybWluYWwgU3RhbmRhcmRpemF0 aW9uDQpTd2VkZW4NCk9mZmljZTogKzQ2IDEwIDcxMSA5MzgyDQppdm8uc2VkbGFjZWtAZXJpY3Nz b24uY29tDQp3d3cuZXJpY3Nzb24uY29tDQoNClRoaXMgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhl IHRlcm0gc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXINCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJw7Fha2kg DQo+IEJheiBDYXN0aWxsbyANCj4gU2VudDogNC4ga3bEm3RuYSAyMDEyIDEzOjI2IA0KPiBUbzog SXZvIFNlZGxhY2VrIA0KPiBDYzogV29ybGV5LCBEYWxlIFIgKERhbGUpOyBzaXBjb3JlQGlldGYu b3JnIA0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFJGQzU2MjYgYW5kIFJFR0lTVEVSIHdpdGgg bXVsdGlwbGUgY29udGFjdHMgDQo+IA0KPiAyMDEyLzUvNCBJdm8gU2VkbGFjZWsgPGl2by5zZWRs YWNla0Blcmljc3Nvbi5jb20+OiANCj4gPj4gQWxzbyB0YWtlIGludG8gYWNjb3VudCB0aGF0IHRo ZSBjb250YWN0IElQOnBvcnQgaXMganVzdCAiaWdub3JlZCIgIA0KPiA+PiB3aGVuIHVzaW5nIE91 dGJvdW5kICh0aGUgcmVnaXN0cmFyIGp1c3QgbWF0Y2hlcyB0aGUgY29udGFjdCB1c2luZyB0aGUg c2lwLmluc3RhbmNlIA0KPiBhbmQgcmVnLWlkIHBhcmFtcykuIA0KPiA+IA0KPiA+IEV4YWN0bHks IGFuZCB0aGF0IGlzIHRoZSByZWFzb24gd2UgYXNzdW1lIGlkZW50aWNhbCBJUCBhZGRyZXNzIGFu ZCBwb3J0LCBiZWNhdXNlIA0KPiBpbmNvbWluZyByZXF1ZXN0cyBhcmUgZ29pbmcgdG8gYmUgc2Vu dCB0byB0aGUgc2FtZSBJUCBsb2NhdGlvbiBubyBtYXR0ZXIgd2hpY2ggY29udGFjdCANCj4gaXMg dXNlZC4gDQo+IA0KPiBTbyBjb3JyZWN0IG1lIGlmIEknbSB3cm9uZyBidXQgaW4gYSBwcmV2aW91 cyBtYWlsIHlvdSBzYWlkIHRoYXQgc2VuZGluZyBtdWx0aXBsZSANCj4gUkVHSVNURVIgd2l0aCB1 bmlxdWUgQ29udGFjdCB3b3JrcyBldmVuIHVzaW5nIE91dGJvdW5kLiBDb3VsZCBJIGtub3cgaG93 IHRob3NlIFJFR0lTVEVSJ3MgDQo+IENvbnRhY3QgaGVhZGVycyBsb29rPyAoaXQgd291bGQgYmUg dXNlZnVsIHRvIHNlZSB0d28gb2YgdGhlbSkuIA0KDQpJbiBvdXIgdXNlIGNhc2UsIHdlIHByb3Bv c2VkIHRvIGhhdmUgUkVHSVNURVIgd2l0aCBtdWx0aXBsZSB1bmlxdWUgY29udGFjdHMgd2hpY2gg YWxsIHNoYXJlIHRoZSBzYW1lIHNpcC5pbnN0YW5jZSwgdGhlIHNhbWUgcmVnLWlkIGFuZCB0aGUg c2FtZSBJUCBhZGRyZXNzIGFuZCBwb3J0Lg0KDQpFeGFtcGxlcyBvZiB0aGUgcHJvcG9zZWQgUkVH SVNURVJzIG9mIFVBMToNCg0KUjE6DQoNClJFR0lTVEVSIA0KU3VwcG9ydGVkOiBwYXRoLCBvdXRi b3VuZCANCkNvbnRhY3Q6IDxzaXA6dXNlcnBhcnQxQDEuMi4zLjQ6NTY3OD47K3NpcC5pbnN0YW5j ZT0ieCI7cmVnLWlkPSIxIjsrRmVhdHVyZVRhZzE9InZhbHVlMSI7K0ZlYXR1cmVUYWczDQpDb250 YWN0OiA8c2lwOnVzZXJwYXJ0MkAxLjIuMy40OjU2Nzg+OytzaXAuaW5zdGFuY2U9IngiO3JlZy1p ZD0iMSI7K0ZlYXR1cmVUYWcxPSJ2YWx1ZTIiOytGZWF0dXJlVGFnMzsrRmVhdHVyZVRhZzQNCg0K UjI6DQoNClJFR0lTVEVSIA0KU3VwcG9ydGVkOiBwYXRoLCBvdXRib3VuZCANCkNvbnRhY3Q6IDxz aXA6dXNlcnBhcnQxQDEuMi4zLjQ6NTY3OD47K3NpcC5pbnN0YW5jZT0ieCI7cmVnLWlkPSIyIjsr RmVhdHVyZVRhZzE9InZhbHVlMSI7K0ZlYXR1cmVUYWczDQpDb250YWN0OiA8c2lwOnVzZXJwYXJ0 MkAxLjIuMy40OjU2Nzg+OytzaXAuaW5zdGFuY2U9IngiO3JlZy1pZD0iMiI7K0ZlYXR1cmVUYWcx PSJ2YWx1ZTIiOytGZWF0dXJlVGFnMzsrRmVhdHVyZVRhZzQNCg0KPiANCj4gSSB3b3VsZCBsaWtl IHRvIHVuZGVyc3RhbmQgd2h5IHRoZSByZWdpc3RyYXIgc3RvcmVzIGRpZmZlcmVudCBiaW5kaW5n cyB3aGVuIHRoZSBzaXAuaW5zdGFuY2UgDQo+IGFuZCByZWctaWQgYXJlIHRoZSBzYW1lLiBJdCdz IG5vdCBjbGVhciBmb3IgbWUuIA0KDQphcHBsaWNhdGlvbnMgaGF2ZSBkaWZmZXJlbnQgY2FwYWJp bGl0aWVzLCBpbmRpY2F0ZWQgaW4gdGhlIGFzc29jaWF0ZWQgY29udGFjdHMgdXNpbmcgdGhlIG1l Y2hhbmlzbSBpbiBSRkMgMzg0MC4gVGhlIGhvbWUgcHJveHkgdGhlbiB1c2VzIHRoZSBtZWNoYW5p c20gaW4gUkZDIDM4NDEgdG8gY2hvb3NlIHRoZSBjb3JyZWN0IGNvbnRhY3QgKGFuZCBjb3JyZWN0 IFVBLCBpZiBtdWx0aXBsZSBVQXMgaGF2ZSByZWdpc3RlcmVkIGZvciB0aGUgc2FtZSBBb1IpLg0K DQoNCj4gDQo+IC0tIA0KPiBJw7Fha2kgQmF6IENhc3RpbGxvIA0KPiA8aWJjQGFsaWF4Lm5ldD4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KPiBz aXBjb3JlIG1haWxpbmcgbGlzdCANCj4gc2lwY29yZUBpZXRmLm9yZyANCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIA0KPiA= From kpfleming@digium.com Fri May 4 08:04:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67121F860B for ; Fri, 4 May 2012 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.15 X-Spam-Level: X-Spam-Status: No, score=-106.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xfyaYYUOXYu for ; Fri, 4 May 2012 08:04:09 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id B630F21F85CE for ; Fri, 4 May 2012 08:04:09 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SQK3E-0007G5-DE for sipcore@ietf.org; Fri, 04 May 2012 10:04:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 6A7EAD8004 for ; Fri, 4 May 2012 10:04:08 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l451OJEyPvmG for ; Fri, 4 May 2012 10:04:08 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 0BC34D8002 for ; Fri, 4 May 2012 10:04:08 -0500 (CDT) Message-ID: <4FA3EFD8.2080903@digium.com> Date: Fri, 04 May 2012 10:03:52 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBBC8@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBDF5@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E3BBEA3@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BBEA3@ESESSCMS0360.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:04:10 -0000 On 05/04/2012 07:54 AM, Ivo Sedlacek wrote: > applications have different capabilities, indicated in the associated contacts using the mechanism in RFC 3840. The home proxy then uses the mechanism in RFC 3841 to choose the correct contact (and correct UA, if multiple UAs have registered for the same AoR). You are using a non-SIP term here, 'applications'. Contact URIs aren't bound to an AoR for applications, they are bound for SIP UAs. Each Contact header you provide in a REGISTER request represents a distinct SIP UA. If you want your individual applications (with differing capabilities) to be selected by a proxy/registrar, even if they all physically reside in the same endpoint, they will need different sip.instance values because they are separate UAs. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From dworley@avaya.com Fri May 4 08:29:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B2821F876A for ; Fri, 4 May 2012 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z5I66nneBDD for ; Fri, 4 May 2012 08:29:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1346021F8763 for ; Fri, 4 May 2012 08:29:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGL1o0/GmAcF/2dsb2JhbABFsmWBB4IJAQEBAQIBEihECwIBCA0IIRAyJQEBBAESCBqHZgWdcZ0gkCpjBJwWiiqDBA X-IronPort-AV: E=Sophos;i="4.75,531,1330923600"; d="scan'208";a="7608616" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 May 2012 11:28:56 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 May 2012 11:25:54 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 4 May 2012 11:28:54 -0400 From: "Worley, Dale R (Dale)" To: Ivo Sedlacek , "sipcore@ietf.org" Date: Fri, 4 May 2012 11:28:54 -0400 Thread-Topic: RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0pG+Agd7EhJGWVQWCqariXDqhddwAIFbhDACAeKSAAEz4sTg== Message-ID: References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> , <3A324A65CCACC64289667DFAC0B88E12197E3BBB8C@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E3BBB8C@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: ,

Please see below.

Kind regards
<= BR>Ivo=20 Sedlacek

Ericsson
GF Technology, Terminal=20 Standardization
Sweden
Office: +46 10 711=20 9382
ivo.sedlacek@ericsson.com
www.ericsson.com

This communica= tion=20 is confidential. We only send and receive email on the basis of the term se= t out=20 at www.ericsson.com/email_disclaimer

-----Original=20 Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 Behalf Of Kevin
> P. Fleming
> Sent: 9. kv=ECtna 2012 16:27
= >=20 To: sipcore@ietf.org
> Subject: Re: [sipcore] RFC5626 and REGISTER wi= th=20 multiple contacts
>
> On 05/09/2012 06:49 AM, Ivo Sedlacek=20 wrote:
> > RFC5626 states that only one delivery (unless flow fail= s) is=20 attempted to contacts
> with the same AOR and instance-id - see excep= rt=20 above.
>
> That's correct, because as Inaki posted previously, = the=20 RFC is covering the case
> where a UA registers multiple contacts usi= ng=20 different transports/addresses/etc.
> that reach the *same* UA.
No=20 problem there.

The original question of this thread was regarding si= ngle=20 UA, using Outbound, where each REGISTER can contain multiple contacts, each= =20 having the same sip.instance, the same IP address and port and the same=20 reg-id.

> In that case, the proxy only needs to send the=20 request
> using one of those Contact URIs, because they are all the s= ame=20 UA.

That is the expected behavior.

> It's clear at this po= int=20 that what you are trying to do was not contemplated by the
> combined= =20 authors of RFCs 3261, 3841 and 5626. That doesn't mean it can't be done,>=20 but there isn't a mechanism that exists today which is fully compliant with= all=20 of
> these RFCs

I can't say that the authors were thinking, an= d I=20 wasn't involved in the IETF work on those RFCs, but at least RFC3261 explic= itly=20 says that UA can register several Contacts and update its own contact=20 *addresses*.

> and doesn't also result in requests being forked t= o=20 your applications.

As long as UA uses the same sip.instance on all=20 contacts, RFC5626 guarantees that.

> With that said, though, you'= ve=20 stated previously that your applications have mutually
> exclusive=20 capability sets; if that's the case, and you registered Contact URIs for>=20 each of them, then a proxy following RFC3841 rules would only select the *o= ne*=20 that
> is compatible with the caller's preferences. The others would = be=20 dropped from the
> candidate set before the request was forwarded, an= d no=20 forking would occur, even
> if the registered URIs all had distinct=20 sip.instance values.

Maybe it could be done that way (I haven't stud= ied=20 it). But, again, we don't consider the contacts being part of different UAs= , and=20 we have yet found no reason why using the same instance-id for each contact= =20 would not work.

Also, due to the characteristics of the instance-id= =20 (being able to survive reboots etc), it could very likely be based on some= =20 hardware identifier/parameter, in which case it would be very difficult to = use=20 different ones.

> If that's not true, then it appears that the=20 underlying problem is that RFC3840 capability
> specifications aren't= =20 expressive enough to describe your UA's capabilities. You need
> both= =20 conjunctive and disjunctive logic, and grouping.

Using RFC3840, this= can=20 be expressed by a UA using multiple contacts.

>
> --
>= ;=20 Kevin P. Fleming
> Digium, Inc. | Director of Software=20 Technologies
> Jabber: kfleming@digium.com | SIP: kpfleming@digium.co= m |=20 Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US= A=20 Check us out at www.digium.com
> & www.asterisk.org=20 _______________________________________________
> sipcore mailing=20 list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--_000_3A324A65CCACC64289667DFAC0B88E12197E4A1D65ESESSCMS0360e_-- From ivo.sedlacek@ericsson.com Thu May 10 09:32:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA821F863D for ; Thu, 10 May 2012 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IGodd9EnNYm for ; Thu, 10 May 2012 09:32:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C123821F84FD for ; Thu, 10 May 2012 09:32:19 -0700 (PDT) X-AuditID: c1b4fb25-b7b09ae000007d0f-39-4fabed9235a5 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AD.00.32015.29DEBAF4; Thu, 10 May 2012 18:32:19 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 10 May 2012 18:32:18 +0200 From: Ivo Sedlacek To: Ivo Sedlacek , "Kevin P. Fleming" , "sipcore@ietf.org" Date: Thu, 10 May 2012 18:32:17 +0200 Thread-Topic: [sipcore] RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0t7+XdPBUlUs/LSBec9hJ94bo2VQAj0YqAABK3NyA= Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E4A1F6E@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <4FA3EFD8.2080903@digium.com> <3A324A65CCACC64289667DFAC0B88E12197E438967@ESESSCMS0360.eemea.ericsson.se> <4FA7D98E.8090100@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E438E96@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438EF2@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438F2D@ESESSCMS0360.eemea.ericsson.se> <4FA92331.5010001@alum.mit.edu> <4FA928C6.4040302@alum.mit.edu> <4FA92E05.4060709@digium.com> <4FA93158.2020104@alum.mit.edu> <4FA936B8.6080801@digium.com> <4FA93FBE.7000508@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E4394DF@ESESSCMS0360.eemea.ericsson.se> <4FAA7EC0.2000402@digium.com> <3A324A65CCACC64289667DFAC0B88E12197E4A1D65@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E4A1D65@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E12197E4A1F6EESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:32:30 -0000 --_000_3A324A65CCACC64289667DFAC0B88E12197E4A1F6EESESSCMS0360e_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I am sorry, there was a typo in the mail below. Corrected now. Kind regards= Ivo Sedlacek ---------------------------------------------------------------------------= ---------------------------------- Please see below. Kind regards Ivo Sedlacek Ericsson GF Technology, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org ] On Behalf Of Kevin > P. Fleming > Sent: 9. kv=ECtna 2012 16:27 > To: sipcore@ietf.org > Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts > > On 05/09/2012 06:49 AM, Ivo Sedlacek wrote: > > RFC5626 states that only one delivery (unless flow fails) is attempted = to contacts > with the same AOR and instance-id - see exceprt above. > > That's correct, because as Inaki posted previously, the RFC is covering t= he case > where a UA registers multiple contacts using different transports/address= es/etc. > that reach the *same* UA. No problem there. The original question of this thread was regarding single UA, using Outboun= d, where each REGISTER can contain multiple contacts, each having the same = sip.instance, the same IP address and port and the same reg-id. > In that case, the proxy only needs to send the request > using one of those Contact URIs, because they are all the same UA. That is the expected behavior. > It's clear at this point that what you are trying to do was not contempla= ted by the > combined authors of RFCs 3261, 3841 and 5626. That doesn't mean it can't = be done, > but there isn't a mechanism that exists today which is fully compliant wi= th all of > these RFCs I can't say what the authors were thinking, and I wasn't involved in the IE= TF work on those RFCs, but at least RFC3261 explicitly says that UA can reg= ister several Contacts and update its own contact *addresses*. > and doesn't also result in requests being forked to your applications. As long as UA uses the same sip.instance on all contacts, RFC5626 guarantee= s that. > With that said, though, you've stated previously that your applications h= ave mutually > exclusive capability sets; if that's the case, and you registered Contact= URIs for > each of them, then a proxy following RFC3841 rules would only select the = *one* that > is compatible with the caller's preferences. The others would be dropped = from the > candidate set before the request was forwarded, and no forking would occu= r, even > if the registered URIs all had distinct sip.instance values. Maybe it could be done that way (I haven't studied it). But, again, we don'= t consider the contacts being part of different UAs, and we have yet found = no reason why using the same instance-id for each contact would not work. Also, due to the characteristics of the instance-id (being able to survive = reboots etc), it could very likely be based on some hardware identifier/par= ameter, in which case it would be very difficult to use different ones. > If that's not true, then it appears that the underlying problem is that R= FC3840 capability > specifications aren't expressive enough to describe your UA's capabilitie= s. You need > both conjunctive and disjunctive logic, and grouping. Using RFC3840, this can be expressed by a UA using multiple contacts. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.d= igium.com > & www.asterisk.org _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --_000_3A324A65CCACC64289667DFAC0B88E12197E4A1F6EESESSCMS0360e_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I am sorry, there was a typo in the mail b= elow.=20 Corrected now. Kind regards Ivo=20 Sedlacek

-----------------------------------------------------------= --------------------------------------------------

Please=20 see below.

Kind regards

Ivo Sedlacek

Ericsson
GF=20 Technology, Terminal Standardization
Sweden
Office: +46 10 711=20 9382
ivo.sedlacek@ericsson.com
www.ericsson.com

This communica= tion=20 is confidential. We only send and receive email on the basis of the term se= t out=20 at www.ericsson.com/email_disclaimer

-----Original=20 Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org=20 <mailto:sipcore-bounces@ietf.org> ] On Behalf Of Kevin
> P. Fleming
> Sent: 9. kv= =ECtna 2012=20 16:27
> To: sipcore@ietf.org
> Subject: Re: [sipcore] RFC5626 a= nd=20 REGISTER with multiple contacts
>
> On 05/09/2012 06:49 AM, Ivo= =20 Sedlacek wrote:
> > RFC5626 states that only one delivery (unless = flow=20 fails) is attempted to contacts
> with the same AOR and instance-id -= see=20 exceprt above.
>
> That's correct, because as Inaki posted=20 previously, the RFC is covering the case
> where a UA registers multi= ple=20 contacts using different transports/addresses/etc.
> that reach the *= same*=20 UA.

No problem there.

The original question of this thread wa= s=20 regarding single UA, using Outbound, where each REGISTER can contain multip= le=20 contacts, each having the same sip.instance, the same IP address and port a= nd=20 the same reg-id.

> In that case, the proxy only needs to send the= =20 request
> using one of those Contact URIs, because they are all the s= ame=20 UA.

That is the expected behavior.

> It's clear at this po= int=20 that what you are trying to do was not contemplated by the
> combined= =20 authors of RFCs 3261, 3841 and 5626. That doesn't mean it can't be done,>=20 but there isn't a mechanism that exists today which is fully compliant with= all=20 of
> these RFCs

I can't say what the authors were thinking, an= d I=20 wasn't involved in the IETF work on those RFCs, but at least RFC3261 explic= itly=20 says that UA can register several Contacts and update its own contact=20 *addresses*.

> and doesn't also result in requests being forked t= o=20 your applications.

As long as UA uses the same sip.instance on all=20 contacts, RFC5626 guarantees that.

> With that said, though, you'= ve=20 stated previously that your applications have mutually
> exclusive=20 capability sets; if that's the case, and you registered Contact URIs for>=20 each of them, then a proxy following RFC3841 rules would only select the *o= ne*=20 that
> is compatible with the caller's preferences. The others would = be=20 dropped from the
> candidate set before the request was forwarded, an= d no=20 forking would occur, even
> if the registered URIs all had distinct=20 sip.instance values.

Maybe it could be done that way (I haven't stud= ied=20 it). But, again, we don't consider the contacts being part of different UAs= , and=20 we have yet found no reason why using the same instance-id for each contact= =20 would not work.

Also, due to the characteristics of the instance-id= =20 (being able to survive reboots etc), it could very likely be based on some= =20 hardware identifier/parameter, in which case it would be very difficult to = use=20 different ones.

> If that's not true, then it appears that the=20 underlying problem is that RFC3840 capability
> specifications aren't= =20 expressive enough to describe your UA's capabilities. You need
> both= =20 conjunctive and disjunctive logic, and grouping.

Using RFC3840, this= can=20 be expressed by a UA using multiple contacts.

>
> --
>= ;=20 Kevin P. Fleming
> Digium, Inc. | Director of Software=20 Technologies
> Jabber: kfleming@digium.com | SIP: kpfleming@digium.co= m |=20 Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US= A=20 Check us out at www.digium.com
> & www.asterisk.org=20 _______________________________________________
> sipcore mailing=20 list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>

--_000_3A324A65CCACC64289667DFAC0B88E12197E4A1F6EESESSCMS0360e_-- From pkyzivat@alum.mit.edu Thu May 10 12:34:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F0721F8652 for ; Thu, 10 May 2012 12:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX3jtLPc5kpe for ; Thu, 10 May 2012 12:34:58 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2E41111E810F for ; Thu, 10 May 2012 12:34:58 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id 8KWG1j0010EZKEL5CKay7w; Thu, 10 May 2012 19:34:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id 8Kay1j00J07duvL3MKaykW; Thu, 10 May 2012 19:34:58 +0000 Message-ID: <4FAC1861.2010706@alum.mit.edu> Date: Thu, 10 May 2012 15:34:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <4FA7D98E.8090100@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E438E96@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438EF2@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438F2D@ESESSCMS0360.eemea.ericsson.se> <4FA92331.5010001@alum.mit.edu> <4FA928C6.4040302@alum.mit.edu> <4FA92E05.4060709@digium.com> <4FA93158.2020104@alum.mit.edu> <4FA936B8.6080801@digium.com> <4FA93FBE.7000508@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E4394DF@ESESSCMS0360.eemea.ericsson.se> <4FAA7EC0.2000402@digium.com> <3A324A65CCACC64289667DFAC0B88E12197E4A1D65@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12197E4A1D65@ESESSCMS0360.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 19:34:59 -0000 On 5/10/12 8:52 AM, Ivo Sedlacek wrote: > > It's clear at this point that what you are trying to do was not > contemplated by the > > combined authors of RFCs 3261, 3841 and 5626. That doesn't mean it > can't be done, > > but there isn't a mechanism that exists today which is fully > compliant with all of > > these RFCs > > I can't say that the authors were thinking, and I wasn't involved in the > IETF work on those RFCs, but at least RFC3261 explicitly says that UA > can register several Contacts and update its own contact *addresses*. I can give some insight. 3261 clearly allows one UA to register multiple contacts with differing addresses, including ones at addresses different from where the REGISTER is originating. I wasn't there when that was worked out - I think it was unchanged from 2543 in that regard - before my time. But there are examples, and lots of later discussion that support that. Subsequently there were various discussions of issues that can result from that feature. For instance "dueling UAs" that remove each other's contacts and substitute their own. But AFAIK there was never any real work to "fix" that. (But the reg event package can be used to at least detect that it is happening.) Outbound complicated things because a flow terminates on a particular UA, and so it makes no sense to attempt to establish one from a different UA. In my recollection there was no discussion at all of callerprefs/callee-caps in the discussion of outbound. I think it was simply viewed as something orthogonal that need not be considered. And of course 3840/3841 predated 5626 and so didn't consider it. So I agree with Kevin that the feature you are interested in was simply never considered. In retrospect perhaps the interactions with 3840/3841 should have been considered in more depth. In any case, we are where we are. You can either try to work within the specs as they are, or you can propose some change. Thanks, Paul From ivo.sedlacek@ericsson.com Fri May 11 08:10:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60621F85C7 for ; Fri, 11 May 2012 08:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94h1rKjOOIIs for ; Fri, 11 May 2012 08:10:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 360BB21F85C9 for ; Fri, 11 May 2012 08:10:38 -0700 (PDT) X-AuditID: c1b4fb25-b7b48ae0000025b3-62-4fad2bed66ab Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.8C.09651.DEB2DAF4; Fri, 11 May 2012 17:10:37 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.5]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 11 May 2012 17:10:36 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "sipcore@ietf.org" Date: Fri, 11 May 2012 17:10:35 +0200 Thread-Topic: [sipcore] RFC5626 and REGISTER with multiple contacts Thread-Index: Ac0u5ACeTGv0yEp3Q+Wu1GL0EbpxVAAoyIrA Message-ID: <3A324A65CCACC64289667DFAC0B88E12197E4A250E@ESESSCMS0360.eemea.ericsson.se> References: <3A324A65CCACC64289667DFAC0B88E12197E3BB890@ESESSCMS0360.eemea.ericsson.se> <4FA7D98E.8090100@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E438E96@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438EF2@ESESSCMS0360.eemea.ericsson.se> <3A324A65CCACC64289667DFAC0B88E12197E438F2D@ESESSCMS0360.eemea.ericsson.se> <4FA92331.5010001@alum.mit.edu> <4FA928C6.4040302@alum.mit.edu> <4FA92E05.4060709@digium.com> <4FA93158.2020104@alum.mit.edu> <4FA936B8.6080801@digium.com> <4FA93FBE.7000508@alum.mit.edu> <3A324A65CCACC64289667DFAC0B88E12197E4394DF@ESESSCMS0360.eemea.ericsson.se> <4FAA7EC0.2000402@digium.com> <3A324A65CCACC64289667DFAC0B88E12197E4A1D65@ESESSCMS0360.eemea.ericsson.se> <4FAC1861.2010706@alum.mit.edu> In-Reply-To: <4FAC1861.2010706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:10:39 -0000 Hello, Of course, there are things that would be good to clarify, and maybe provid= e more guidance and consideration upon (e.g. the "SHOULD reject REGISTER wi= th multiple contacts" statement in RFC 5626). However, my understanding of this discussion is that the current specs do a= llow me to do what I want, so I see no need to change anything :) =20 Kind regards Ivo Sedlacek=20 Ericsson GF Technology, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Paul=20 > Kyzivat=20 > Sent: 10. kv=ECtna 2012 21:35=20 > To: sipcore@ietf.org=20 > Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts=20 >=20 > On 5/10/12 8:52 AM, Ivo Sedlacek wrote:=20 >=20 > > > It's clear at this point that what you are trying to do was not =20 > > contemplated by the > combined authors of RFCs 3261, 3841 and 5626.=20 > > That doesn't mean it can't be done, > but there isn't a mechanism =20 > > that exists today which is fully compliant with all of > these RFCs=20 > >=20 > > I can't say that the authors were thinking, and I wasn't involved in =20 > > the IETF work on those RFCs, but at least RFC3261 explicitly says that = =20 > > UA can register several Contacts and update its own contact *addresses*= .=20 >=20 > I can give some insight.=20 >=20 > 3261 clearly allows one UA to register multiple contacts with differing a= ddresses,=20 > including ones at addresses different from where the REGISTER is originat= ing. I wasn't=20 > there when that was worked out - I think it was unchanged from 2543 in th= at regard=20 > - before my time. But there are examples, and lots of later discussion th= at support=20 > that.=20 >=20 > Subsequently there were various discussions of issues that can result fro= m that feature.=20 > For instance "dueling UAs" that remove each other's contacts and substitu= te their=20 > own. But AFAIK there was never any real work to "fix" that. (But the reg = event package=20 > can be used to at least detect that it is happening.)=20 >=20 > Outbound complicated things because a flow terminates on a particular UA,= and so=20 > it makes no sense to attempt to establish one from a different UA. In my = recollection=20 > there was no discussion at all of callerprefs/callee-caps in the discussi= on of outbound.=20 > I think it was simply viewed as something orthogonal that need not be con= sidered.=20 > And of course 3840/3841 predated 5626 and so didn't consider it.=20 >=20 > So I agree with Kevin that the feature you are interested in was simply n= ever considered.=20 > In retrospect perhaps the interactions with 3840/3841 should have been co= nsidered=20 > in more depth.=20 >=20 > In any case, we are where we are. You can either try to work within the s= pecs as=20 > they are, or you can propose some change.=20 >=20 > Thanks,=20 > Paul=20 > _______________________________________________=20 > sipcore mailing list=20 > sipcore@ietf.org=20 > https://www.ietf.org/mailman/listinfo/sipcore=20 > = From pkyzivat@alum.mit.edu Fri May 18 08:10:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C28921F8757 for ; Fri, 18 May 2012 08:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtvWJwZuQJQx for ; Fri, 18 May 2012 08:10:40 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE221F8755 for ; Fri, 18 May 2012 08:10:40 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id BSwT1j0031vXlb85BTAfj8; Fri, 18 May 2012 15:10:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id BTAf1j00Z07duvL3dTAfuy; Fri, 18 May 2012 15:10:39 +0000 Message-ID: <4FB6666E.5080707@alum.mit.edu> Date: Fri, 18 May 2012 11:10:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:10:41 -0000 I am issuing a WGLC for: draft-ietf-sipcore-proxy-feature-02 (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02) The WGLC will conclude at 23:59 UTC on June 8, 2012. (I'm giving it three weeks because there are a lot of things going on at this time - a 3gpp meeting, some holidays, etc.) Note that this is intended to satisfy our milestone: Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) I'm looking for volunteers to perform a careful review of this document. It would be especially good to have participation of people who haven't previously been closely involved. Please inform me and Adam if you are able to do a careful WGLC review. Thanks, Paul (as co-chair) From md3135@att.com Mon May 21 02:26:20 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD50B21F857A for ; Mon, 21 May 2012 02:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9nXgFjNpkVA for ; Mon, 21 May 2012 02:26:20 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id D7DBE21F853E for ; Mon, 21 May 2012 02:26:19 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id b3a0abf4.4e4f5940.133315.00-592.346870.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 21 May 2012 09:26:19 +0000 (UTC) X-MXL-Hash: 4fba0a3b20b8a8b4-7e805c083ee7d5c624f3b4fead64382a08279c78 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 73a0abf4.0.133308.00-480.346853.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 21 May 2012 09:26:16 +0000 (UTC) X-MXL-Hash: 4fba0a3803632a54-eebecba4ec7be6d7e26a7609d61561c30b949d0a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4L9QFjq021595; Mon, 21 May 2012 05:26:15 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4L9Q70U021487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 05:26:10 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 21 May 2012 05:25:48 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Mon, 21 May 2012 05:25:47 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 Thread-Index: AQHNNQhpiPWNIjylTAuV4ObGBZzUz5bT/PfA Date: Mon, 21 May 2012 09:25:47 +0000 Message-ID: References: <4FB6666E.5080707@alum.mit.edu> In-Reply-To: <4FB6666E.5080707@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.82.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=aMDB4gEj0NsA:10 a=r0Q0CMgy5xIA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=48vgC7mUAAAA:8 a=K6OYNHoXa2E6zDUlzyQA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:26:20 -0000 Paul, I volunteer to review the draft. Regards, Martin -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: Friday, May 18, 2012 11:11 AM To: SIPCORE Subject: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 I am issuing a WGLC for: draft-ietf-sipcore-proxy-feature-02 (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02) The WGLC will conclude at 23:59 UTC on June 8, 2012. (I'm giving it three weeks because there are a lot of things going on at=20 this time - a 3gpp meeting, some holidays, etc.) Note that this is intended to satisfy our milestone: Mechanism to=20 indicate proxy capabilities to both endpoints and other intermediaries=20 in the path of a REGISTER transaction or dialog-forming transaction to=20 IESG (PS) I'm looking for volunteers to perform a careful review of this document.=20 It would be especially good to have participation of people who haven't=20 previously been closely involved. Please inform me and Adam if you are=20 able to do a careful WGLC review. Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From lili.yang@huawei.com Mon May 28 02:01:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7158521F854D for ; Mon, 28 May 2012 02:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeiqPNOnd-2b for ; Mon, 28 May 2012 02:01:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0834D21F84CE for ; Mon, 28 May 2012 02:01:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGI15024; Mon, 28 May 2012 05:01:50 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 01:59:15 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 01:59:14 -0700 Received: from SZXEML521-MBX.china.huawei.com ([169.254.1.206]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 28 May 2012 16:59:06 +0800 From: Lili Yang_lili To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 Thread-Index: AQHNNQh1osoVyrm46ki/v0GluhJkhZbe9YUw Date: Mon, 28 May 2012 08:59:05 +0000 Message-ID: References: <4FB6666E.5080707@alum.mit.edu> In-Reply-To: <4FB6666E.5080707@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.53.84] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 09:01:52 -0000 SGVsbG8gUGF1bCwNCg0KSSBhbSBMaWxpIFlhbmcgZnJvbSBIdWF3ZWkuIA0KSSB2b2x1bnRlZXIg dG8gcmV2aWV3IHRoZSBkcmFmdC4gDQoNCkJlc3QgcmVnYXJkcywNCkxpbGkNCruqzqq8vMr109DP 3rmry74gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCg0KDQpQaG9uZTogKzg2LTc1NS0y ODQyMjU1Ng0KTW9iaWxlOis4Ni0xMzYzMjYzMjA2NQ0KRW1haWw6IExpbGkueWFuZ0BodWF3ZWku Y29tDQq12Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3ZWkg VGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpo ZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbSANCg0Ksb7Tyrz+vLDG 5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXE uPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rI q7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTt ytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpU aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJz b24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRo ZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBi dXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSANCnBob25lIG9yIGVtYWls IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6IEZyaWRheSwgTWF5IDE4 LCAyMDEyIDExOjExIFBNDQpUbzogU0lQQ09SRQ0KU3ViamVjdDogW3NpcGNvcmVdIFdHTEMgZm9y IGRyYWZ0LWlldGYtc2lwY29yZS1wcm94eS1mZWF0dXJlLTAyDQoNCkkgYW0gaXNzdWluZyBhIFdH TEMgZm9yOg0KDQpkcmFmdC1pZXRmLXNpcGNvcmUtcHJveHktZmVhdHVyZS0wMg0KICAgKGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1wcm94eS1mZWF0dXJlLTAy KQ0KDQpUaGUgV0dMQyB3aWxsIGNvbmNsdWRlIGF0IDIzOjU5IFVUQyBvbiBKdW5lIDgsIDIwMTIu DQoNCihJJ20gZ2l2aW5nIGl0IHRocmVlIHdlZWtzIGJlY2F1c2UgdGhlcmUgYXJlIGEgbG90IG9m IHRoaW5ncyBnb2luZyBvbiBhdCANCnRoaXMgdGltZSAtIGEgM2dwcCBtZWV0aW5nLCBzb21lIGhv bGlkYXlzLCBldGMuKQ0KDQpOb3RlIHRoYXQgdGhpcyBpcyBpbnRlbmRlZCB0byBzYXRpc2Z5IG91 ciBtaWxlc3RvbmU6IE1lY2hhbmlzbSB0byANCmluZGljYXRlIHByb3h5IGNhcGFiaWxpdGllcyB0 byBib3RoIGVuZHBvaW50cyBhbmQgb3RoZXIgaW50ZXJtZWRpYXJpZXMgDQppbiB0aGUgcGF0aCBv ZiBhIFJFR0lTVEVSIHRyYW5zYWN0aW9uIG9yIGRpYWxvZy1mb3JtaW5nIHRyYW5zYWN0aW9uIHRv IA0KSUVTRyAoUFMpDQoNCkknbSBsb29raW5nIGZvciB2b2x1bnRlZXJzIHRvIHBlcmZvcm0gYSBj YXJlZnVsIHJldmlldyBvZiB0aGlzIGRvY3VtZW50LiANCkl0IHdvdWxkIGJlIGVzcGVjaWFsbHkg Z29vZCB0byBoYXZlIHBhcnRpY2lwYXRpb24gb2YgcGVvcGxlIHdobyBoYXZlbid0IA0KcHJldmlv dXNseSBiZWVuIGNsb3NlbHkgaW52b2x2ZWQuIFBsZWFzZSBpbmZvcm0gbWUgYW5kIEFkYW0gaWYg eW91IGFyZSANCmFibGUgdG8gZG8gYSBjYXJlZnVsIFdHTEMgcmV2aWV3Lg0KDQoJVGhhbmtzLA0K CVBhdWwgKGFzIGNvLWNoYWlyKQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From shida@ntt-at.com Wed May 30 00:39:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A428421F85D0 for ; Wed, 30 May 2012 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rte-O447+Cv for ; Wed, 30 May 2012 00:39:35 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3C21F85C3 for ; Wed, 30 May 2012 00:39:34 -0700 (PDT) Received: from flh1alt210.tky.mesh.ad.jp ([211.13.69.210]:51218 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SZdVF-0007Ub-7L for sipcore@ietf.org; Wed, 30 May 2012 02:39:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Shida Schubert In-Reply-To: <4FB6666E.5080707@alum.mit.edu> Date: Wed, 30 May 2012 16:39:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4E345C9D-FD9A-418B-B393-95D1523E0641@ntt-at.com> References: <4FB6666E.5080707@alum.mit.edu> To: "sipcore@ietf.org WG" X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1alt210.tky.mesh.ad.jp ([192.168.1.17]) [211.13.69.210]:51218 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 07:39:35 -0000 Here is my review for draft-ietf-sipcore-proxy-feature. 0. Spec name I think as it is no longer about proxy-feature, may be the=20 draft name or spec name should change to reflect what the=20 draft is doing.. "Registration of feature-cap tree and guideline" 1. General Please be consistent with the terms used. It is=20 confusing when so many of similar terms are used for=20 what this draft tries to define.=20 e.g.=20 SIP feature cap SIP feature caps SIP Feature Cap Feature-caps Feature-Caps Feature-Cap header field Also=20 "features" alone and "features and capabilities" are=20 used, I would stick with one when you are trying to=20 say the same things.=20 2. Abstract Abstract is slightly confusing.. Why aren't we using the term SIP intermediary, there=20 was probably a discussion taken place in the ML but=20 SIP entity is rather confusing(I am assuming it is because=20 it includes B2BUA??).. If you insist on using=20 SIP entity then I would rephrase the abstract to say=20 something along the line of... "This specification creates a new IANA registry, "SIP Feature Cap Registry" for registering "SIP feature caps" which is used by SIP=20 entities not represented in the contact header to indicate support=20 of features and capabilities. This specification also defines a new SIP header field, Feature-Caps=20 header field, to convey SIP feature caps." 3. Introduction (Section 1) I would fix the introduction in a similar fashion to that of abstract.=20= 4. Section 4.2.1=20 The sentence about "other registration tree being out of scope, I think=20= is unnecessary here.. unless you want to explicitly state this.." 5. Section 4.2.3=20 Last paragraph, last sentence, should the must be published be MUST be = published? 6. Section 4.4.1 second paragraph What procedure defined in this spec is this talking about? Can you = elaborate?=20 7. Section 4.4.5 second paragraph Add "message" in front of the flows to make it "example message flow" to = make=20 it consistent with the first paragraph.=20 8. Section 5.1 first paragraph Old " to convey support of features and capabilities, using SIP feature = caps." New "to convey support of features and capabilities, by setting SIP = feature caps." 9. Section 5.1 NOTE: Old "It is not possible to convey the address of the SIP entity as a Feature-Caps header field parameter." New "It is not possible to convey the address of the SIP entity as part = of=20 a Feature-Caps header field parameter."=20 What does the following sentence to above mean? Are you saying that=20 you could in fact define a way to convey the address of the entity which=20= indicated support of feature/capabilities by defining a method to do so = in=20 the sip feature-cap spec? 10. Section 5.1 last paragraph foo;bar and bar;foo having the same semantics seems to=20 conflict with the following paragraph where it is indicated that=20 the order of the feature-cap header field indicates the closeness=20 of the entity supporting the features.=20 11. Section 5.2.1 last paragraph I am assuming that the text is trying to mandate entity adding SIP=20 Feature-Caps header to add a "new" header on top of the existing=20 one if there is and prohibit SIP entity wanting to indicate features=20 and capabilities from adding only the value.. Am I correct? If so=20 this I think should be explicitly stated. 12. Section 5.2.1 last paragraph, last sentence. OLD : "the SIP feature caps in the top-most Feature-Caps header field will represent the supported features "closest" to the entity." NEW: "the SIP feature caps in the top-most Feature-Caps header field will represent the features supported by the "closest" entity. 13. Section 5.2.2 B2BUA behavior Isn't it clearer to just say B2BUA where UA is being used? 14. Section 5.2.4 Proxy behavior 5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general=20 behavior of a SIP entity, may be the title should change to=20 general behavior or something. 15. Section 5.3.2 SIP Dialog Paragraph 3 Change "or a target" to "in a target" Change "long supported" to "longer supported" 16. IANA section - It is a little confusing how in the registration policy,=20 "+" is not used but it is mandatory when it is set. I have=20 no problem with it but may be it should be noted in the=20 registration policy that although it is not registered with=20 "+", it is prepended to the fcap-name when used. Regards Shida On May 19, 2012, at 12:10 AM, Paul Kyzivat wrote: > I am issuing a WGLC for: >=20 > draft-ietf-sipcore-proxy-feature-02 > (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02) >=20 > The WGLC will conclude at 23:59 UTC on June 8, 2012. >=20 > (I'm giving it three weeks because there are a lot of things going on = at this time - a 3gpp meeting, some holidays, etc.) >=20 > Note that this is intended to satisfy our milestone: Mechanism to = indicate proxy capabilities to both endpoints and other intermediaries = in the path of a REGISTER transaction or dialog-forming transaction to = IESG (PS) >=20 > I'm looking for volunteers to perform a careful review of this = document. It would be especially good to have participation of people = who haven't previously been closely involved. Please inform me and Adam = if you are able to do a careful WGLC review. >=20 > Thanks, > Paul (as co-chair) > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed May 30 03:41:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BC021F86C8 for ; Wed, 30 May 2012 03:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbAMIkMv2NcH for ; Wed, 30 May 2012 03:41:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE16621F86C4 for ; Wed, 30 May 2012 03:41:14 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-b0-4fc5f949a9d7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id ED.3D.00702.949F5CF4; Wed, 30 May 2012 12:41:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 30 May 2012 12:41:13 +0200 From: Christer Holmberg To: Shida Schubert , "sipcore@ietf.org WG" Date: Wed, 30 May 2012 12:41:13 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments Thread-Index: Ac0+UCLLhWjAUSeLR5Sa84f9g1mNIw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvra7nz6P+BpMOGVr8PjSP1eLrj01s DkweS5b8ZPLouTSbMYApissmJTUnsyy1SN8ugSvj112/gt0uFbc+nGdtYFxp2sXIySEhYCJx 6uVCdghbTOLCvfVsXYxcHEICpxgl5i66wQaSEBJYyCgxfVttFyMHB5uAhUT3P22QsIhAoMTs K03MIGEWAVWJvk+CIGFhgQiJS0cuMkGUREqsWbePFcLWk+jdvQZsFa9AuMTau8eYQWxGoLXf T60Bq2cWEJe49WQ+E8Q5AhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvY7Egt2f2CBsbYllC18z Q8wXlDg58wnLBEbhWUjGzkLSMgtJyywkLQsYWVYxCucmZuakl5vrpRZlJhcX5+fpFaduYgQG +8Etvw12MG66L3aIUZqDRUmcV091v7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxsnLyj8K pL++eLfi58vAjtbWu/Izay4+Sco+Ps3qhn6E+eM5c9fY+olteWKowHB0leicyeZ3ThzYO21X xOZVdd+FpHmc5lYEiF/Vu3btVyfD/fZ/O8vPyzy7pv3i84WSCXu1nFjm/v/3I1VQX2TXO+cf lc8OBs2rd4rx5neMn3ejy1EpZjdXRqQSS3FGoqEWc1FxIgCCi8pBRAIAAA== Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 10:41:16 -0000 Hi Shida, Thanks for your review! Comments inline. ------------ > 0. Spec name > > I think as it is no longer about proxy-feature, may be the draft name or = spec name should change to reflect what the draft is doing.. "Registration = of feature-cap tree and guideline" This has been mentioned before, and if there aren't any administrative issu= es regarding that I am happy to change the name. I suggest the following new title (it's quite long, but should be aligned w= ith terminology we've used for other specs): "Mechanism to indicate support of features and capabilities using feature = caps for the Session Initiation Protocol (SIP)" Unless people want to do it, I guess we don't need to change the spec name,= as it will go away anyway. ------------ > 1. General > > Please be consistent with the terms used. It is confusing when so many of= similar terms are used for what this draft tries to define.=20 > > e.g.=20 > > SIP feature cap > SIP feature caps > SIP Feature Cap > Feature-caps > Feature-Caps > Feature-Cap header field My suggestion is to use "feature cap(s)" when we talk about the feature cap= s, and "Feature-Caps header field" when we talk about the header field. > Also=20 > > "features" alone and "features and capabilities" are used, I would stick = with one when you are trying to say the same things.=20 I suggest to use "features and capabilities". ------------ > 2. Abstract > > Abstract is slightly confusing.. > > Why aren't we using the term SIP intermediary, there was probably a discu= ssion taken place in the ML but SIP entity is rather=20 > confusing(I am assuming it is because it includes B2BUA??).. If you insis= t on using SIP entity then I would rephrase the abstract to say something a= long the line of... > > "This specification creates a new IANA registry, "SIP Feature Cap Registr= y" for registering "SIP feature caps" which is used by SIP entities not rep= resented in the contact header to indicate support of features and capabili= ties. > > This specification also defines a new SIP header field, Feature-Caps head= er field, to convey SIP feature caps." I suggest the following: "This specification creates a new IANA registry, "SIP Feature Cap Registry", for registering "feature caps", which are used by SIP entities= =20 not represented by the URI of the Contact header field to indicate=20 support of features and capabilities. This specification also defines a new SIP header field, Feature-Caps, to convey feature caps in SIP messages." ------------ > 3. Introduction (Section 1) > > I would fix the introduction in a similar fashion to that of abstract.=20 I suggest the following: "This specification creates a new IANA registry, "SIP Feature Cap Registry", for registering "feature caps", which are used by SIP entities= =20 not represented by the URI of the Contact header field to indicate=20 support of features and capabilities, and media feature tags cannot be used to indicate the support. Such cases are: o - The SIP entity acts as a SIP proxy. o - The SIP entity acts as a SIP registrar. o - The SIP entity acts as a B2BUA, where the Contact header field URI represents another SIP entity. This specification also defines a new SIP header field, Feature-Caps, to convey feature caps in SIP messages." ------------ > 4. Section 4.2.1=20 > > The sentence about "other registration tree being out of scope, I think i= s unnecessary here.. unless you want to explicitly state this.." I am ok to remove the sentence. However, I think it was suggested by Paul, so I want to verify that he is o= k with removing it. ------------ > 5. Section 4.2.3=20 > > Last paragraph, last sentence, should the must be published be MUST be pu= blished? Yes. ------------ > 6. Section 4.4.1 second paragraph > > What procedure defined in this spec is this talking about? Can you elabor= ate?=20 The general procedures on how the header field is used etc. I based the text on similar text in RFC 6086 (Info-Package), which says: "It is bad practice for Info Package specifications to repeat procedures=20 defined in this document, unless needed for purposes of clarification=20 or emphasis." But, if it's unclear, maybe I could say something like: =09 "...to repeat procedures (e.g. general procedures on the usage of the Feature-Caps header field and feature caps) defined..." ------------ > 7. Section 4.4.5 second paragraph > > Add "message" in front of the flows to make it "example message flow" to = make it consistent with the first paragraph.=20 Ok. ------------ > 8. Section 5.1 first paragraph > > Old " to convey support of features and capabilities, using SIP feature c= aps." > > New "to convey support of features and capabilities, by setting SIP featu= re caps." Ok. ------------ > 9. Section 5.1 NOTE: > > Old "It is not possible to convey the address of the SIP entity as a Feat= ure-Caps header field parameter." > > New "It is not possible to convey the address of the SIP entity as part o= f a Feature-Caps header field parameter."=20 Ok. > What does the following sentence to above mean? Are you saying that you c= ould in fact define a way to convey the address of the=20 > entity which indicated support of feature/capabilities by defining a meth= od to do so in the sip feature-cap spec? It means that the Feature-Caps header field itself does not contain a heade= r field parameter for conveying the address, but that an individual feature= cap can have an address value if needed. Example: myFeatureCaps=3D"address=3Dx.y.z.w" ------------ > 10. Section 5.1 last paragraph > > foo;bar and bar;foo having the same semantics seems to conflict with the = following paragraph where it is indicated that the order of the feature-cap= header field indicates the closeness of the entity supporting the features= .=20 foo and bar are feature caps within a SINGLE header field, where the order = does not matter. ------------ > 11. Section 5.2.1 last paragraph > > I am assuming that the text is trying to mandate entity adding SIP Featur= e-Caps header to add a "new" header on top of the existing one if there is = and=20 > prohibit SIP entity wanting to indicate features and capabilities from ad= ding only the value.. Am I correct? If so this I think should be explicitly= stated. The ABNF allows for having multiple header fields, or a single header field= with comma separated values, and the semantics are identical in both cases= .=20 However, we normally don't explicitly talk about both options, but instead = talk about adding new header fields. ------------ > 12. Section 5.2.1 last paragraph, last sentence. > > OLD : "the SIP feature caps in the top-most Feature-Caps header field wil= l represent the supported features "closest" to the entity." > > NEW: "the SIP feature caps in the top-most Feature-Caps header field will= represent the features supported by the "closest" entity. Ok. I will use "features and capabilities", though (as per comment 1). ------------ > 13. Section 5.2.2 B2BUA behavior > > Isn't it clearer to just say B2BUA where UA is being used? I am not sure what part of the text I would modify. ------------ > 14. Section 5.2.4 Proxy behavior > > 5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general behavior of a= SIP entity, may be the title should change to general behavior or somethin= g. So, your suggestion is that 5.2.1 would be "General SIP entity behavior"? I am ok with that. ------------ > 15. Section 5.3.2 SIP Dialog Paragraph 3 > > Change "or a target" to "in a target" "or" was supposed to be "of", but I'm ok with "in". > Change "long supported" to "longer supported" Ok. ------------ > 16. IANA section > > - It is a little confusing how in the registration policy, "+" is not use= d but it is mandatory when it is set. I have no problem with it but may be = it >should be noted in the registration policy that although it is not registe= red with "+", it is prepended to the fcap-name when used. I suggest the following mdofication: OLD: "No leading "+" is used in the registrations in any of the media feat= ure tag trees." NEW: "No leading "+" is used in the registrations in any of the media feat= ure tag trees. However, "+" is prepended to the fcap-name when added to a F= eature-Caps header field." ------------ Thank You! Regards, Christer From pkyzivat@alum.mit.edu Wed May 30 07:46:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A245821F8694 for ; Wed, 30 May 2012 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lricc5tFwWcG for ; Wed, 30 May 2012 07:46:26 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9087C21F864D for ; Wed, 30 May 2012 07:46:26 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta01.westchester.pa.mail.comcast.net with comcast id GEXl1j00S0mv7h051EmRnL; Wed, 30 May 2012 14:46:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id GEmQ1j00v07duvL3XEmRka; Wed, 30 May 2012 14:46:25 +0000 Message-ID: <4FC632C0.5020008@alum.mit.edu> Date: Wed, 30 May 2012 10:46:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 CC: SIPCORE References: <4FB6666E.5080707@alum.mit.edu> <4E345C9D-FD9A-418B-B393-95D1523E0641@ntt-at.com> In-Reply-To: <4E345C9D-FD9A-418B-B393-95D1523E0641@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:46:27 -0000 Shida, Thanks for the very thorough review. Its good to get a fresh perspective. I'll wait for Christer to comment on the details. Thanks, Paul On 5/30/12 3:39 AM, Shida Schubert wrote: > > Here is my review for draft-ietf-sipcore-proxy-feature. > > 0. Spec name > > I think as it is no longer about proxy-feature, may be the > draft name or spec name should change to reflect what the > draft is doing.. "Registration of feature-cap tree and guideline" > > > 1. General > > Please be consistent with the terms used. It is > confusing when so many of similar terms are used for > what this draft tries to define. > > e.g. > > SIP feature cap > SIP feature caps > SIP Feature Cap > Feature-caps > Feature-Caps > Feature-Cap header field > > Also > > "features" alone and "features and capabilities" are > used, I would stick with one when you are trying to > say the same things. > > 2. Abstract > > Abstract is slightly confusing.. > > Why aren't we using the term SIP intermediary, there > was probably a discussion taken place in the ML but > SIP entity is rather confusing(I am assuming it is because > it includes B2BUA??).. If you insist on using > SIP entity then I would rephrase the abstract to say > something along the line of... > > "This specification creates a new IANA registry, "SIP Feature Cap > Registry" for registering "SIP feature caps" which is used by SIP > entities not represented in the contact header to indicate support > of features and capabilities. > > This specification also defines a new SIP header field, Feature-Caps > header field, to convey SIP feature caps." > > 3. Introduction (Section 1) > > I would fix the introduction in a similar fashion to that of abstract. > > 4. Section 4.2.1 > > The sentence about "other registration tree being out of scope, I think > is unnecessary here.. unless you want to explicitly state this.." > > 5. Section 4.2.3 > > Last paragraph, last sentence, should the must be published be MUST be published? > > 6. Section 4.4.1 second paragraph > > What procedure defined in this spec is this talking about? Can you elaborate? > > 7. Section 4.4.5 second paragraph > > Add "message" in front of the flows to make it "example message flow" to make > it consistent with the first paragraph. > > 8. Section 5.1 first paragraph > > Old " to convey support of features and capabilities, using SIP feature caps." > > New "to convey support of features and capabilities, by setting SIP feature caps." > > 9. Section 5.1 NOTE: > > Old "It is not possible to convey the address of the SIP entity as a > Feature-Caps header field parameter." > > New "It is not possible to convey the address of the SIP entity as part of > a Feature-Caps header field parameter." > > What does the following sentence to above mean? Are you saying that > you could in fact define a way to convey the address of the entity which > indicated support of feature/capabilities by defining a method to do so in > the sip feature-cap spec? > > 10. Section 5.1 last paragraph > > foo;bar and bar;foo having the same semantics seems to > conflict with the following paragraph where it is indicated that > the order of the feature-cap header field indicates the closeness > of the entity supporting the features. > > 11. Section 5.2.1 last paragraph > > I am assuming that the text is trying to mandate entity adding SIP > Feature-Caps header to add a "new" header on top of the existing > one if there is and prohibit SIP entity wanting to indicate features > and capabilities from adding only the value.. Am I correct? If so > this I think should be explicitly stated. > > 12. Section 5.2.1 last paragraph, last sentence. > > OLD : "the SIP feature caps in the > top-most Feature-Caps header field will represent the supported > features "closest" to the entity." > > NEW: "the SIP feature caps in the > top-most Feature-Caps header field will represent the > features supported by the "closest" entity. > > 13. Section 5.2.2 B2BUA behavior > > Isn't it clearer to just say B2BUA where UA is being used? > > 14. Section 5.2.4 Proxy behavior > > 5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general > behavior of a SIP entity, may be the title should change to > general behavior or something. > > 15. Section 5.3.2 SIP Dialog Paragraph 3 > > Change "or a target" to "in a target" > > Change "long supported" to "longer supported" > > 16. IANA section > > - It is a little confusing how in the registration policy, > "+" is not used but it is mandatory when it is set. I have > no problem with it but may be it should be noted in the > registration policy that although it is not registered with > "+", it is prepended to the fcap-name when used. > > Regards > Shida > > On May 19, 2012, at 12:10 AM, Paul Kyzivat wrote: > >> I am issuing a WGLC for: >> >> draft-ietf-sipcore-proxy-feature-02 >> (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02) >> >> The WGLC will conclude at 23:59 UTC on June 8, 2012. >> >> (I'm giving it three weeks because there are a lot of things going on at this time - a 3gpp meeting, some holidays, etc.) >> >> Note that this is intended to satisfy our milestone: Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) >> >> I'm looking for volunteers to perform a careful review of this document. It would be especially good to have participation of people who haven't previously been closely involved. Please inform me and Adam if you are able to do a careful WGLC review. >> >> Thanks, >> Paul (as co-chair) >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Wed May 30 08:52:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EA521F8610 for ; Wed, 30 May 2012 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkD1hsrDlLU9 for ; Wed, 30 May 2012 08:52:26 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id AD49321F8608 for ; Wed, 30 May 2012 08:52:23 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id GFNh1j0041GhbT857FsPWG; Wed, 30 May 2012 15:52:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id GFsN1j02E07duvL3TFsNtN; Wed, 30 May 2012 15:52:23 +0000 Message-ID: <4FC64235.9060501@alum.mit.edu> Date: Wed, 30 May 2012 11:52:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 15:52:29 -0000 Some followon comments. I've stripped it down to the points I'm commenting on. Thanks, Paul On 5/30/12 6:41 AM, Christer Holmberg wrote: > Hi Shida, > > Thanks for your review! Comments inline. > > > ------------ > > >> 0. Spec name >> >> I think as it is no longer about proxy-feature, may be the draft name or spec name should change to reflect what the draft is doing.. "Registration of feature-cap tree and guideline" > > This has been mentioned before, and if there aren't any administrative issues regarding that I am happy to change the name. There is no problem changing the name. > I suggest the following new title (it's quite long, but should be aligned with terminology we've used for other specs): > > "Mechanism to indicate support of features and capabilities using feature caps for the Session Initiation Protocol (SIP)" The inclusion of both "features and capabilities" and "feature caps" in the title seems quite redundant. How about: "Mechanism to indicate support of features and capabilities of Session Initiation Protocol (SIP) intermediaries" ? Or maybe that doesn't work because it applies to registrars, which aren't intermediaries? Or maybe just: "Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)" The latter could be construed to encompass what 3840 does, but that one has a name that mentions User Agent, so I think its ok. > Unless people want to do it, I guess we don't need to change the spec name, as it will go away anyway. Agreed. >> 3. Introduction (Section 1) >> >> I would fix the introduction in a similar fashion to that of abstract. > > I suggest the following: > > "This specification creates a new IANA registry, "SIP Feature Cap > Registry", for registering "feature caps", which are used by SIP entities > not represented by the URI of the Contact header field to indicate > support of features and capabilities, and media feature tags cannot be > used to indicate the support. Such cases are: I think s/and media feature tags/where media feature tags/ > o - The SIP entity acts as a SIP proxy. > o - The SIP entity acts as a SIP registrar. > o - The SIP entity acts as a B2BUA, where the Contact header field > URI represents another SIP entity. > > This specification also defines a new SIP header field, Feature-Caps, > to convey feature caps in SIP messages." > > > ------------ > > >> 4. Section 4.2.1 >> >> The sentence about "other registration tree being out of scope, I think is unnecessary here.. unless you want to explicitly state this.." > > I am ok to remove the sentence. > > However, I think it was suggested by Paul, so I want to verify that he is ok with removing it. Yes, I said the following back on 24-may: "There is no mention of an IETF tree, analogous to that defined in 2506 for feature tags. Given the history, and a desire to provide a similar structure, I agree it makes sense that we aren't planning on defining anything of that sort. But I think it is confusing to anyone who has looked at 2506 that there is no mention of names that have only one facet. So, I think it would be helpful to explicitly state that names consisting of only a single facet, as well as names with initial facets other than "g" and "sip" are out of scope for this draft. I'm undecided if it would be good to define an IETF tree without any content, or if it would be better not to define it." But I think this sentence and the following note say essentially the same thing. So I'm ok with dropping this sentence and retaining the note. But I think the note needs a bit of touch up. It currently says: NOTE: Compared to RFC 2506, this specification only defines a global tree and a sip tree, as they are the only tree defined in RFC 2506 that have been used for defining media feature tags for SIP. That's mostly true, but 3840 does call out some existing feature tags from the ietf tree for use with sip. So how about: NOTE: In contrast to RFC 2506, this specification only defines a global tree and a sip tree, as they are the only trees defined in RFC 2506 that have been used for defining SIP-specific media feature tags. >> What does the following sentence to above mean? Are you saying that you could in fact define a way to convey the address of the >> entity which indicated support of feature/capabilities by defining a method to do so in the sip feature-cap spec? > > It means that the Feature-Caps header field itself does not contain a header field parameter for conveying the address, but that an individual feature cap can have an address value if needed. > > Example: > > myFeatureCaps="address=x.y.z.w" The paragraph is still a bit confusing. How about: NOTE: It is not possible to convey the address of the SIP entity as a Feature-Caps header field parameter. Each feature that requires address information to be conveyed need to define a way to convey that information as part of the associated SIP feature cap value. NOTE: If data is needed about a feature, such as the address of the sip entity, then the feature definition must define a way to convey that information as part of the associated SIP feature cap value. >> 11. Section 5.2.1 last paragraph >> >> I am assuming that the text is trying to mandate entity adding SIP Feature-Caps header to add a "new" header on top of the existing one if there is and >> prohibit SIP entity wanting to indicate features and capabilities from adding only the value.. Am I correct? If so this I think should be explicitly stated. > > The ABNF allows for having multiple header fields, or a single header field with comma separated values, and the semantics are identical in both cases. > However, we normally don't explicitly talk about both options, but instead talk about adding new header fields. Christer and I discussed this. I had proposed some wording that covered both ways. But it was cumbersome, and I'm not aware of any other draft that deals with it. So I decided I was ok with this. But if Shida has an idea of how to make this clear without being cumbersome then I'm all for it. From shida@ntt-at.com Wed May 30 17:48:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20E11E8138 for ; Wed, 30 May 2012 17:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.465 X-Spam-Level: X-Spam-Status: No, score=-101.465 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb6banU-c+F9 for ; Wed, 30 May 2012 17:48:11 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAF311E8137 for ; Wed, 30 May 2012 17:48:11 -0700 (PDT) Received: from [211.13.69.210] (port=55105 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SZtYf-0003L7-D7; Wed, 30 May 2012 19:48:09 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 31 May 2012 09:48:09 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4AD3AE-0C8A-41AD-83D4-95B05598B001@ntt-at.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1alt210.tky.mesh.ad.jp ([192.168.1.17]) [211.13.69.210]:55105 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 11 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 00:48:12 -0000 Hi Christer; My comments inline.. On May 30, 2012, at 7:41 PM, Christer Holmberg wrote: > Hi Shida, >=20 > Thanks for your review! Comments inline. >=20 >=20 > ------------ >=20 >=20 >> 0. Spec name >>=20 >> I think as it is no longer about proxy-feature, may be the draft name = or spec name should change to reflect what the draft is doing.. = "Registration of feature-cap tree and guideline" >=20 > This has been mentioned before, and if there aren't any administrative = issues regarding that I am happy to change the name. >=20 > I suggest the following new title (it's quite long, but should be = aligned with terminology we've used for other specs): >=20 > "Mechanism to indicate support of features and capabilities = using feature caps for the Session Initiation Protocol (SIP)" >=20 > Unless people want to do it, I guess we don't need to change the spec = name, as it will go away anyway. >=20 >=20 > ------------ >=20 >=20 >> 1. General >>=20 >> Please be consistent with the terms used. It is confusing when so = many of similar terms are used for what this draft tries to define.=20 >>=20 >> e.g.=20 >>=20 >> SIP feature cap >> SIP feature caps >> SIP Feature Cap >> Feature-caps >> Feature-Caps >> Feature-Cap header field >=20 > My suggestion is to use "feature cap(s)" when we talk about the = feature caps, and "Feature-Caps header field" when we talk about the = header field. >=20 >> Also=20 >>=20 >> "features" alone and "features and capabilities" are used, I would = stick with one when you are trying to say the same things.=20 >=20 > I suggest to use "features and capabilities". Sounds good. >=20 >=20 > ------------ >=20 >=20 >> 2. Abstract >>=20 >> Abstract is slightly confusing.. >>=20 >> Why aren't we using the term SIP intermediary, there was probably a = discussion taken place in the ML but SIP entity is rather=20 >> confusing(I am assuming it is because it includes B2BUA??).. If you = insist on using SIP entity then I would rephrase the abstract to say = something along the line of... >>=20 >> "This specification creates a new IANA registry, "SIP Feature Cap = Registry" for registering "SIP feature caps" which is used by SIP = entities not represented in the contact header to indicate support of = features and capabilities. >>=20 >> This specification also defines a new SIP header field, Feature-Caps = header field, to convey SIP feature caps." >=20 > I suggest the following: >=20 > "This specification creates a new IANA registry, "SIP Feature = Cap > Registry", for registering "feature caps", which are used by SIP = entities=20 > not represented by the URI of the Contact header field to = indicate=20 > support of features and capabilities. >=20 > This specification also defines a new SIP header field, = Feature-Caps, > to convey feature caps in SIP messages." >=20 >=20 > ------------ Looks good to me. >=20 >=20 >> 3. Introduction (Section 1) >>=20 >> I would fix the introduction in a similar fashion to that of = abstract.=20 >=20 > I suggest the following: >=20 > "This specification creates a new IANA registry, "SIP Feature = Cap > Registry", for registering "feature caps", which are used by SIP = entities=20 > not represented by the URI of the Contact header field to = indicate=20 > support of features and capabilities, and media feature tags = cannot be > used to indicate the support. Such cases are: >=20 > o - The SIP entity acts as a SIP proxy. > o - The SIP entity acts as a SIP registrar. > o - The SIP entity acts as a B2BUA, where the Contact header = field > URI represents another SIP entity. >=20 > This specification also defines a new SIP header field, = Feature-Caps, > to convey feature caps in SIP messages." >=20 >=20 > ------------ Looks good to me. >=20 >=20 >> 4. Section 4.2.1=20 >>=20 >> The sentence about "other registration tree being out of scope, I = think is unnecessary here.. unless you want to explicitly state this.." >=20 > I am ok to remove the sentence. >=20 > However, I think it was suggested by Paul, so I want to verify that he = is ok with removing it. >=20 >=20 > ------------ OK. >=20 >=20 >> 5. Section 4.2.3=20 >>=20 >> Last paragraph, last sentence, should the must be published be MUST = be published? >=20 > Yes. >=20 >=20 > ------------ >=20 >=20 >> 6. Section 4.4.1 second paragraph >>=20 >> What procedure defined in this spec is this talking about? Can you = elaborate?=20 >=20 > The general procedures on how the header field is used etc. >=20 > I based the text on similar text in RFC 6086 (Info-Package), which = says: >=20 > "It is bad practice for Info Package specifications to repeat = procedures=20 > defined in this document, unless needed for purposes of = clarification=20 > or emphasis." >=20 > But, if it's unclear, maybe I could say something like: > =09 > "...to repeat procedures (e.g. general procedures on the usage = of > the Feature-Caps header field and feature caps) defined..." >=20 >=20 > ------------ That I think is better.. >=20 >=20 >> 7. Section 4.4.5 second paragraph >>=20 >> Add "message" in front of the flows to make it "example message flow" = to make it consistent with the first paragraph.=20 >=20 > Ok. >=20 >=20 > ------------ >=20 >=20 >> 8. Section 5.1 first paragraph >>=20 >> Old " to convey support of features and capabilities, using SIP = feature caps." >>=20 >> New "to convey support of features and capabilities, by setting SIP = feature caps." >=20 > Ok. >=20 >=20 > ------------ >=20 >=20 >> 9. Section 5.1 NOTE: >>=20 >> Old "It is not possible to convey the address of the SIP entity as a = Feature-Caps header field parameter." >>=20 >> New "It is not possible to convey the address of the SIP entity as = part of a Feature-Caps header field parameter."=20 >=20 > Ok. >=20 >> What does the following sentence to above mean? Are you saying that = you could in fact define a way to convey the address of the=20 >> entity which indicated support of feature/capabilities by defining a = method to do so in the sip feature-cap spec? >=20 > It means that the Feature-Caps header field itself does not contain a = header field parameter for conveying the address, but that an individual = feature cap can have an address value if needed. >=20 > Example: >=20 > myFeatureCaps=3D"address=3Dx.y.z.w" >=20 >=20 > ------------ Ok. >=20 >=20 >> 10. Section 5.1 last paragraph >>=20 >> foo;bar and bar;foo having the same semantics seems to conflict with = the following paragraph where it is indicated that the order of the = feature-cap header field indicates the closeness of the entity = supporting the features.=20 >=20 > foo and bar are feature caps within a SINGLE header field, where the = order does not matter. >=20 >=20 > ------------ >=20 >=20 >> 11. Section 5.2.1 last paragraph >>=20 >> I am assuming that the text is trying to mandate entity adding SIP = Feature-Caps header to add a "new" header on top of the existing one if = there is and=20 >> prohibit SIP entity wanting to indicate features and capabilities = from adding only the value.. Am I correct? If so this I think should be = explicitly stated. >=20 > The ABNF allows for having multiple header fields, or a single header = field with comma separated values, and the semantics are identical in = both cases.=20 > However, we normally don't explicitly talk about both options, but = instead talk about adding new header fields. Right.. Fair enough..=20 Regards Shida >=20 >=20 > ------------ >=20 >=20 >> 12. Section 5.2.1 last paragraph, last sentence. >>=20 >> OLD : "the SIP feature caps in the top-most Feature-Caps header field = will represent the supported features "closest" to the entity." >>=20 >> NEW: "the SIP feature caps in the top-most Feature-Caps header field = will represent the features supported by the "closest" entity. >=20 > Ok. I will use "features and capabilities", though (as per comment 1). >=20 >=20 > ------------ >=20 >=20 >> 13. Section 5.2.2 B2BUA behavior >>=20 >> Isn't it clearer to just say B2BUA where UA is being used? >=20 > I am not sure what part of the text I would modify. >=20 >=20 >=20 > ------------ >=20 >=20 >> 14. Section 5.2.4 Proxy behavior >>=20 >> 5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general behavior = of a SIP entity, may be the title should change to general behavior or = something. >=20 > So, your suggestion is that 5.2.1 would be "General SIP entity = behavior"? >=20 > I am ok with that. >=20 >=20 > ------------ >=20 >=20 >> 15. Section 5.3.2 SIP Dialog Paragraph 3 >>=20 >> Change "or a target" to "in a target" >=20 > "or" was supposed to be "of", but I'm ok with "in". >=20 >> Change "long supported" to "longer supported" >=20 > Ok. >=20 >=20 > ------------ >=20 >=20 >> 16. IANA section >>=20 >> - It is a little confusing how in the registration policy, "+" is not = used but it is mandatory when it is set. I have no problem with it but = may be it >> should be noted in the registration policy that although it is not = registered with "+", it is prepended to the fcap-name when used. >=20 > I suggest the following mdofication: >=20 > OLD: "No leading "+" is used in the registrations in any of the = media feature tag trees." >=20 > NEW: "No leading "+" is used in the registrations in any of the = media feature tag trees. However, "+" is prepended to the fcap-name when = added to a Feature-Caps header field." >=20 >=20 > ------------ >=20 > Thank You! >=20 > Regards, >=20 > Christer >=20 >=20 From shida@ntt-at.com Wed May 30 17:52:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68EA11E8136 for ; Wed, 30 May 2012 17:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ZEgghS7-tA for ; Wed, 30 May 2012 17:52:09 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C811E80D2 for ; Wed, 30 May 2012 17:52:09 -0700 (PDT) Received: from [211.13.69.210] (port=55111 helo=[192.168.1.17]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SZtcW-0005Q5-3M; Wed, 30 May 2012 19:52:08 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4FC64235.9060501@alum.mit.edu> Date: Thu, 31 May 2012 09:52:08 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1alt210.tky.mesh.ad.jp ([192.168.1.17]) [211.13.69.210]:55111 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 13 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 00:52:09 -0000 Hi Paul; my comments inline on relevant point.. On May 31, 2012, at 12:52 AM, Paul Kyzivat wrote: >=20 >=20 >>> 11. Section 5.2.1 last paragraph >>>=20 >>> I am assuming that the text is trying to mandate entity adding SIP = Feature-Caps header to add a "new" header on top of the existing one if = there is and >>> prohibit SIP entity wanting to indicate features and capabilities = from adding only the value.. Am I correct? If so this I think should be = explicitly stated. >>=20 >> The ABNF allows for having multiple header fields, or a single header = field with comma separated values, and the semantics are identical in = both cases. >> However, we normally don't explicitly talk about both options, but = instead talk about adding new header fields. >=20 > Christer and I discussed this. I had proposed some wording that = covered both ways. But it was cumbersome, and I'm not aware of any other = draft that deals with it. So I decided I was ok with this. But if Shida = has an idea of how to make this clear without being cumbersome then I'm = all for it. >=20 I am okay with it too. I was just wanting to clarify it...=20 It may help for those implementors that have read the draft once and=20 end up implementing based on ABNF, to add a note in ABNF repeating=20 what is stated at the end of 5.2.1.. To encourage implementors to=20 follow what is suggested.. To take it even further you can add a text=20 with "MUST NOT add value to an existing SIP Feature-Caps header" but=20 that may be too much.. Regards Shida > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed May 30 21:40:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7A21F8555 for ; Wed, 30 May 2012 21:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaAhW0BGBsNy for ; Wed, 30 May 2012 21:40:04 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 264CB21F8550 for ; Wed, 30 May 2012 21:40:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id GUaR1j0011ap0As5DUg2mr; Thu, 31 May 2012 04:40:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id GUg11j00R07duvL3iUg28m; Thu, 31 May 2012 04:40:02 +0000 Message-ID: <4FC6F639.8090605@alum.mit.edu> Date: Thu, 31 May 2012 00:40:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Shida Schubert References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 04:40:07 -0000 On 5/30/12 8:52 PM, Shida Schubert wrote: > > Hi Paul; > > my comments inline on relevant point.. > > On May 31, 2012, at 12:52 AM, Paul Kyzivat wrote: > >> >> >>>> 11. Section 5.2.1 last paragraph >>>> >>>> I am assuming that the text is trying to mandate entity adding SIP Feature-Caps header to add a "new" header on top of the existing one if there is and >>>> prohibit SIP entity wanting to indicate features and capabilities from adding only the value.. Am I correct? If so this I think should be explicitly stated. >>> >>> The ABNF allows for having multiple header fields, or a single header field with comma separated values, and the semantics are identical in both cases. >>> However, we normally don't explicitly talk about both options, but instead talk about adding new header fields. >> >> Christer and I discussed this. I had proposed some wording that covered both ways. But it was cumbersome, and I'm not aware of any other draft that deals with it. So I decided I was ok with this. But if Shida has an idea of how to make this clear without being cumbersome then I'm all for it. >> > > I am okay with it too. I was just wanting to clarify it... > > It may help for those implementors that have read the draft once and > end up implementing based on ABNF, to add a note in ABNF repeating > what is stated at the end of 5.2.1.. To encourage implementors to > follow what is suggested.. To take it even further you can add a text > with "MUST NOT add value to an existing SIP Feature-Caps header" but > that may be too much.. I don't want to take a stand that way. I think either way is equally acceptable. And adding to an existing header saves bytes, which can sometimes matter. So I don't want to discourage doing so. Thanks, Paul From christer.holmberg@ericsson.com Thu May 31 00:03:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB7211E80E5 for ; Thu, 31 May 2012 00:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5yTgWAJwIdA for ; Thu, 31 May 2012 00:03:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7942711E8093 for ; Thu, 31 May 2012 00:03:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-07-4fc717c2c30e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.B2.00702.2C717CF4; Thu, 31 May 2012 09:03:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 31 May 2012 09:03:30 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Thu, 31 May 2012 09:03:29 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments Thread-Index: Ac0+fDtmm39HgfUEQU+HGGYw/Aez8QAfVwww Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459A31A5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> In-Reply-To: <4FC64235.9060501@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre5h8eP+Bn/WsVis2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG9K1bWAvmaFZs/ryKpYGxX6GLkZNDQsBE 4nH7P3YIW0ziwr31bCC2kMApRonX7327GLmA7LmMEk0zDgAlODjYBCwkuv9pg9SICARKXF0y gRnEZhFQlfh1cifYHGGBCIlLRy4yQdRESqxZt48VwjaSWD/jHVicVyBc4veXw2AjhQQqJaYd LgAJcwroSDza28UCYjMCnfP91BqwcmYBcYlbT+YzQZwpILFkz3lmCFtU4uXjf6wQ9aISd9rX M0LU60gs2P2JDcLWlli28DUzxFpBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjcG5iZk56 ublealFmcnFxfp5eceomRmB8HNzy22AH46b7YocYpTlYlMR59VT3+wsJpCeWpGanphakFsUX leakFh9iZOLglGpgzCn/eO2Y4OKvDq9upvx7/1/O6s2TmSsmdndv2bnea7b0GVXZWSeFfvy9 /sck9liP4JN50R7aFc/Wm4hVOuiGH+zKOfDou86b3csL9jGUcn8/K2Zu2NCWXpnxNFuG8e00 j1Sl2h3O00wLy/+evbo6W61B66msjpXTqp2Xtm9o/5BYd33Odr9ESSWW4oxEQy3mouJEAJaa P0RdAgAA Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:03:33 -0000 Hi Paul, >> I suggest the following new title (it's quite long, but should be aligne= d with terminology we've used for other specs): >> >> "Mechanism to indicate support of features and capabilities using featu= re caps for the Session Initiation Protocol (SIP)" > > The inclusion of both "features and capabilities" and "feature caps" in t= he title seems quite redundant. > > How about: > > "Mechanism to indicate support of features and capabilities of Session In= itiation Protocol (SIP) intermediaries" ? > > Or maybe that doesn't work because it applies to registrars, which aren't= intermediaries? > > Or maybe just: > > "Mechanism to indicate support of features and capabilities in the Sessio= n Initiation Protocol (SIP)" > > The latter could be construed to encompass what 3840 does, but that one h= as a name that mentions User Agent, so I think its ok. I'm fine with that. ------------------- >>> 3. Introduction (Section 1) >>> >>> I would fix the introduction in a similar fashion to that of abstract. >> >> I suggest the following: >> >> "This specification creates a new IANA registry, "SIP Feature Cap >> Registry", for registering "feature caps", which are used by SIP entiti= es >> not represented by the URI of the Contact header field to indicate >> support of features and capabilities, and media feature tags cannot be >> used to indicate the support. Such cases are: > > I think s/and media feature tags/where media feature tags/ Yes. ------------ > o - The SIP entity acts as a SIP proxy. > o - The SIP entity acts as a SIP registrar. > o - The SIP entity acts as a B2BUA, where the Contact header field > URI represents another SIP entity. > > This specification also defines a new SIP header field, Feature-Caps, > to convey feature caps in SIP messages." Yes. ------------ >>> 4. Section 4.2.1 >>> >>> The sentence about "other registration tree being out of scope, I think= is unnecessary here.. unless you want to explicitly state this.." >> >> I am ok to remove the sentence. >> >> However, I think it was suggested by Paul, so I want to verify that he i= s ok with removing it. > > Yes, I said the following back on 24-may: > > "There is no mention of an IETF tree, analogous to that defined in 2506 f= or feature tags. Given the history, and a desire to provide=20 >a similar structure, I agree it makes sense that we aren't planning on def= ining anything of that sort. But I think it is confusing to=20 >anyone who has looked at 2506 that there is no mention of names that have = only one facet. > >So, I think it would be helpful to explicitly state that names consisting = of only a single facet, as well as names with initial facets other=20 >than "g" and "sip" are out of scope for this draft. I'm undecided if it wo= uld be good to define an IETF tree without any content, or if it=20 >would be better not to define it." > >But I think this sentence and the following note say essentially the same = thing. So I'm ok with dropping this sentence and retaining the note. But I = think the note needs a bit of touch up. It currently says: > > NOTE: Compared to RFC 2506, this specification only defines a global > tree and a sip tree, as they are the only tree defined in RFC 2506 > that have been used for defining media feature tags for SIP. > > That's mostly true, but 3840 does call out some existing feature tags fro= m the ietf tree for use with sip. So how about: > > NOTE: In contrast to RFC 2506, this specification only defines a > global tree and a sip tree, as they are the only trees defined in > RFC 2506 that have been used for defining SIP-specific media feature > tags. The sip tree isn't defined in RFC 2506, so I think both the old and new not= e text is missleading. What about: "NOTE: In contrast to RFC 2506, this specification only defines a global tree, as it is the only tree defined in RFC 2506 that has been=20 used for defining SIP-specific media feature tags." ------------ >>> What does the following sentence to above mean? Are you saying that=20 >>> you could in fact define a way to convey the address of the entity whic= h indicated support of feature/capabilities by defining a method to do so i= n the sip feature-cap spec? >> >> It means that the Feature-Caps header field itself does not contain a he= ader field parameter for conveying the address, but that an individual feat= ure cap can have an address value if needed. >> >> Example: >> >> myFeatureCaps=3D"address=3Dx.y.z.w" > >The paragraph is still a bit confusing. How about: > > NOTE: It is not possible to convey the address of the SIP entity as a > Feature-Caps header field parameter. Each feature that requires > address information to be conveyed need to define a way to convey > that information as part of the associated SIP feature cap value. > > NOTE: If data is needed about a feature, such as the address of the > sip entity, then the feature definition must define a way to convey > that information as part of the associated SIP feature cap value. Looks good. ------------ Regards, Christer From christer.holmberg@ericsson.com Thu May 31 03:16:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E14121F8638 for ; Thu, 31 May 2012 03:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxIGSA5qfd-u for ; Thu, 31 May 2012 03:16:05 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F21B21F8633 for ; Thu, 31 May 2012 03:16:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-8e-4fc744dd8878 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 65.F1.00702.DD447CF4; Thu, 31 May 2012 12:15:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 31 May 2012 12:15:57 +0200 From: Christer Holmberg To: Paul Kyzivat , Shida Schubert Date: Thu, 31 May 2012 12:15:56 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments Thread-Index: Ac0+53mmq7qGfJY/QPKeWWqEv7NxWwALbx6w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C459A33CD@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> <4FC6F639.8090605@alum.mit.edu> In-Reply-To: <4FC6F639.8090605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre5dl+P+BpeXG1is2HCA1eL3oXms Fl9/bGJzYPb4+/4Dk8eSJT+ZPHouzWYMYI7isklJzcksSy3St0vgypjaMoG14Bt/xdan7A2M R3i6GDk5JARMJL5fa2SFsMUkLtxbz9bFyMUhJHCKUWLhuovsEM5CIOfVZuYuRg4ONgELie5/ 2iANIgLeEtN2TGUBsZkFNCUe7dzLBGKzCKhK3J14FMwWFoiQuHTkIhNEfaTEmnX7WCFsI4m7 3yDivALhEv/O9TFC7DrPKDHzeC8jSIJTQEei6cZhsCJGoOu+n1rDBLFMXOLWk/lMEFcLSCzZ c54ZwhaVePn4HytEvajEnfb1jBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcUonJuYmZNebq6XWpSZXFycn6dXnLqJERhPB7f8NtjBuOm+2CFGaQ4WJXFe PdX9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYz13pdV6x/ZGxuLSoVaJT8Jmy6I0CL//4 KO/7sf5lcUKpUBQfz4G5LcxHjrjM1A/r1LRN6V0iNUvJ+PZiO47W6RdeB7OrpZ7JOpCz+NL7 UptvjyZO1w47s3q27juZ6DcSOWeMY04VPFL3cVo6ty6exzzlyxafgl3TtxosNVdQ/Ght2PT5 RbCsEktxRqKhFnNRcSIAvsxKtHUCAAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:16:05 -0000 Hi, >>>>> 11. Section 5.2.1 last paragraph >>>>> >>>>> I am assuming that the text is trying to mandate entity adding SIP=20 >>>>> Feature-Caps header to add a "new" header on top of the existing one = if there is and prohibit SIP entity wanting to indicate features and capabi= lities from adding only the value.. Am I correct? If so this I think should= be explicitly stated. >>>> >>>> The ABNF allows for having multiple header fields, or a single header = field with comma separated values, and the semantics are identical in both = cases. >>>> However, we normally don't explicitly talk about both options, but ins= tead talk about adding new header fields. >>> >>> Christer and I discussed this. I had proposed some wording that covered= both ways. But it was cumbersome, and I'm not aware=20 >>> of any other draft that deals with it. So I decided I was ok with this.= But if Shida has an idea of how to make this clear without being cumbersom= e then I'm all for it. >>> >> >> I am okay with it too. I was just wanting to clarify it... >> >> It may help for those implementors that have read the draft once and=20 >> end up implementing based on ABNF, to add a note in ABNF repeating=20 >> what is stated at the end of 5.2.1.. To encourage implementors to=20 >> follow what is suggested.. To take it even further you can add a text=20 >> with "MUST NOT add value to an existing SIP Feature-Caps header" but=20 >> that may be too much.. > > I don't want to take a stand that way. I think either way is equally acce= ptable. And adding to an existing header saves bytes, which can sometimes m= atter. So I don't want to discourage doing so. I don't think anyone should implement anything simply based on the ABNF, be= cause there are things which cannot be indicated in ABNF :) However, in this case, the ABNF does show that it is allowed to have a sing= le header field, with multiple values, and there is a normative reference t= o the ABNF spec. Regards, Christer From pkyzivat@alum.mit.edu Thu May 31 07:37:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1D21F8644 for ; Thu, 31 May 2012 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4lsLq3hcFCV for ; Thu, 31 May 2012 07:37:18 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id A371121F85AD for ; Thu, 31 May 2012 07:37:18 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id GeWb1j0050Fqzac55edJpk; Thu, 31 May 2012 14:37:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id GedH1j00H07duvL3UedHjx; Thu, 31 May 2012 14:37:18 +0000 Message-ID: <4FC7821C.2060209@alum.mit.edu> Date: Thu, 31 May 2012 10:37:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C459A31A5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C459A31A5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:37:19 -0000 Christer, One thing: On 5/31/12 3:03 AM, Christer Holmberg wrote: >> That's mostly true, but 3840 does call out some existing feature tags from the ietf tree for use with sip. So how about: >> >> NOTE: In contrast to RFC 2506, this specification only defines a >> global tree and a sip tree, as they are the only trees defined in >> RFC 2506 that have been used for defining SIP-specific media feature >> tags. > > The sip tree isn't defined in RFC 2506, so I think both the old and new note text is missleading. Good point. > What about: > > "NOTE: In contrast to RFC 2506, this specification only defines a > global tree, as it is the only tree defined in RFC 2506 that has been > used for defining SIP-specific media feature tags." This is correct. But maybe it isn't quite the point that needs to be made. How about: NOTE: In contrast to RFCs 2506 and 3840, this specification only defines a global tree and a sip tree, as they are the only trees defined in those RFCs that have been used for defining SIP-specific media feature tags. Thanks, Paul From rjsparks@nostrum.com Thu May 31 07:46:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9E21F866A for ; Thu, 31 May 2012 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVGXCXC3GG+6 for ; Thu, 31 May 2012 07:46:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D221F86D7 for ; Thu, 31 May 2012 07:46:05 -0700 (PDT) Received: from unexplicable.local (pool-173-71-53-156.dllstx.fios.verizon.net [173.71.53.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VEiXu8079966 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 31 May 2012 09:44:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4FC783D0.4070505@nostrum.com> Date: Thu, 31 May 2012 09:44:32 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: RFC Errata System References: <20120531125741.4B83D621A3@rfc-editor.org> In-Reply-To: <20120531125741.4B83D621A3@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.53.156 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 31 May 2012 07:53:32 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, schulzrinne@cs.columbia.edu, sipcore@ietf.org, drage@alcatel-lucent.com, alan.johnston@wcom.com, mjh@icir.org, jon.peterson@neustar.com, dean.willis@softarmor.com, kpfleming@digium.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:46:06 -0000 (adding the sipcore list) Kevin - The important part of "new transaction" is the branch identifier. Are the issues you're having really with transaction identification? (I could only see that being the case if you had 2543 elements involved.) Or is the real pain with policy on what a response to a digest challenge has to look like? What current IETF discussions are you pointing to below? RjS On 5/31/12 7:57 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC3261, > "SIP: Session Initiation Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=3237 > > -------------------------------------- > Type: Editorial > Reported by: Kevin P. Fleming > > Section: 8.1.3.5 > > Original Text > ------------- > In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. > > Corrected Text > -------------- > In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq SHOULD contain a new sequence number that is one higher than the previous. > > Notes > ----- > We have had one implementor claim that they are not required to increment CSeq when retrying the request because the RFC says 'should' and not 'SHOULD'. Based on current IETF discussions, though, these should probably be changed to MUST anyway, but that's a much more substantive change throughout the whole RFC. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3261 (draft-ietf-sip-rfc2543bis-09) > -------------------------------------- > Title : SIP: Session Initiation Protocol > Publication Date : June 2002 > Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From christer.holmberg@ericsson.com Thu May 31 08:31:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870F21F879F for ; Thu, 31 May 2012 08:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoPutJd4Oh2I for ; Thu, 31 May 2012 08:31:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6158221F87A3 for ; Thu, 31 May 2012 08:31:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-32-4fc78edd59ac Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 04.3D.28636.DDE87CF4; Thu, 31 May 2012 17:31:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 31 May 2012 17:31:40 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 31 May 2012 17:30:46 +0200 Thread-Topic: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments Thread-Index: Ac0/OuGH5YVzA0cDQtCfMtAM7RK4AQAB3gJa Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B13B9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C459A2D12@ESESSCMS0356.eemea.ericsson.se> <4FC64235.9060501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C459A31A5@ESESSCMS0356.eemea.ericsson.se>, <4FC7821C.2060209@alum.mit.edu> In-Reply-To: <4FC7821C.2060209@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7dvuP+Bn19ghYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx49xmpoIvHBXrjxxjbmA8y9bFyMEhIWAi 8WsDYxcjJ5ApJnHh3nqgMBeHkMApRokDFy4xQjgLGSWez/vFAtLAJmAh0f1PG8QUEdCQmLRV DaSXWUBT4tHOvUwgNouAqsTqMwdZQWxhgQiJS0cugsVFBCIl1qzbxwphG0nsnrYdzOYVCJf4 /OkGM4gtJPCcUeJJgzyIzSmgI9Hcv5odxGYEuu37qTVMELvEJW49mc8EcbOAxJI955khbFGJ l4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nL AkaWVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgXFzcMtv3R2Mp86JHGKU5mBREuflStrvLySQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoExzfbRljLtqzns02JDasSDzXfI7lp556G12Bzl7um9 jYKhv1/I7ls7ZXYDT/3WpR4ZGdVyVj4lBcxZXZa1jPurTZnV+/9/tQv3vFWm2VtgeGnPG9Ff i6+FHf++dWfstrenJcW+3I5P3sOzcO6ncxtz9RhY1LbXffo85+A75cR4c+7aTdcbr2xVYinO SDTUYi4qTgQAydd2zmkCAAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:31:43 -0000 Hi, >>> That's mostly true, but 3840 does call out some existing feature tags f= rom the ietf tree for use with sip. So how about: >>> >>> NOTE: In contrast to RFC 2506, this specification only defines a >>> global tree and a sip tree, as they are the only trees defined in >>> RFC 2506 that have been used for defining SIP-specific media featur= e >>> tags. >> >> The sip tree isn't defined in RFC 2506, so I think both the old and new = note text is missleading. > > Good point. > >> What about: >> >> "NOTE: In contrast to RFC 2506, this specification only defines a >> global tree, as it is the only tree defined in RFC 2506 that has b= een >> used for defining SIP-specific media feature tags." > > This is correct. But maybe it isn't quite the point that needs to be > made. How about: > > NOTE: In contrast to RFCs 2506 and 3840, this specification only > defines a global tree and a sip tree, as they are the only trees > defined in those RFCs that have been used for defining SIP-specific > media feature tags. Looks good. Regards, Christer= From pkyzivat@alum.mit.edu Thu May 31 08:36:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFE011E8108 for ; Thu, 31 May 2012 08:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7QsT5n+8QVF for ; Thu, 31 May 2012 08:36:43 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0A11E8102 for ; Thu, 31 May 2012 08:36:42 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta13.westchester.pa.mail.comcast.net with comcast id GeCx1j0051GhbT85DfciF4; Thu, 31 May 2012 15:36:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id Gfci1j00907duvL3Tfci5F; Thu, 31 May 2012 15:36:42 +0000 Message-ID: <4FC79009.5020203@alum.mit.edu> Date: Thu, 31 May 2012 11:36:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <20120531125741.4B83D621A3@rfc-editor.org> <4FC783D0.4070505@nostrum.com> In-Reply-To: <4FC783D0.4070505@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:36:43 -0000 Commenting on the errata itself... > On 5/31/12 7:57 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC3261, >> "SIP: Session Initiation Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=3237 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Kevin P. Fleming >> >> Section: 8.1.3.5 >> >> Original Text >> ------------- >> In all of the above cases, the request is retried by creating a new >> request with the appropriate modifications. This new request >> constitutes a new transaction and SHOULD have the same value of the >> Call-ID, To, and From of the previous request, but the CSeq should >> contain a new sequence number that is one higher than the previous. >> >> Corrected Text >> -------------- >> In all of the above cases, the request is retried by creating a new >> request with the appropriate modifications. This new request >> constitutes a new transaction and SHOULD have the same value of the >> Call-ID, To, and From of the previous request, but the CSeq SHOULD >> contain a new sequence number that is one higher than the previous. >> >> Notes >> ----- >> We have had one implementor claim that they are not required to >> increment CSeq when retrying the request because the RFC says 'should' >> and not 'SHOULD'. Based on current IETF discussions, though, these >> should probably be changed to MUST anyway, but that's a much more >> substantive change throughout the whole RFC. Because the retry is a new request, it is governed by all the normative requirements that apply to a new request. So the normative statements elsewhere about the CSeq value apply in this case. For the retry of some arbitrary operation (e.g. OPTIONS) outside of a dialog there aren't any requirements other than that it be less than 2^31. So indeed you could use the same CSeq value if you wished. But if it was a REGISTER, then section 10.2 says the CSeq must be incremented by one. And if the request is within a dialog, then section 12.2.1.1 also says the CSeq value must be incremented by one. The lack of a normative statement *here* doesn't grant license to violate those rules. So I don't see any error to be corrected. Thanks, Paul From brett@broadsoft.com Thu May 31 09:12:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16C11E8155 for ; Thu, 31 May 2012 09:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO1Vbonuq3Vx for ; Thu, 31 May 2012 09:12:42 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 8455911E8154 for ; Thu, 31 May 2012 09:12:42 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 May 2012 09:15:14 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 31 May 2012 09:15:12 -0700 From: Brett Tate To: Robert Sparks , RFC Errata System Date: Thu, 31 May 2012 09:12:39 -0700 Thread-Topic: [sipcore] [Editorial Errata Reported] RFC3261 (3237) Thread-Index: Ac0/PYKGnDB2mUnGQwW+BzmnUZF/nQABI20w Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CC55856@EXMBXCLUS01.citservers.local> References: <20120531125741.4B83D621A3@rfc-editor.org> <4FC783D0.4070505@nostrum.com> In-Reply-To: <4FC783D0.4070505@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 31 May 2012 09:21:39 -0700 Cc: "jdrosen@dynamicsoft.com" , "schooler@research.att.com" , "rsparks@dynamicsoft.com" , "schulzrinne@cs.columbia.edu" , "sipcore@ietf.org" , "drage@alcatel-lucent.com" , "jon.peterson@neustar.com" , "kpfleming@digium.com" , "mjh@icir.org" , "alan.johnston@wcom.com" , "dean.willis@softarmor.com" Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:12:43 -0000 There are normative MUST increment statements else within RFC 3261 concerni= ng the topic. Thus if a UAC or proxy is ignoring the indication to increme= nt cseq, they should not be surprised if it results in a 482 response. Section 22.2: "When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request." Section 22.3: "The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication. If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different." 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Robert Sparks > Sent: Thursday, May 31, 2012 10:45 AM > To: RFC Errata System > Cc: jdrosen@dynamicsoft.com; schooler@research.att.com; > rsparks@dynamicsoft.com; schulzrinne@cs.columbia.edu; sipcore@ietf.org; > drage@alcatel-lucent.com; alan.johnston@wcom.com; mjh@icir.org; > jon.peterson@neustar.com; dean.willis@softarmor.com; > kpfleming@digium.com > Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237) >=20 > (adding the sipcore list) >=20 > Kevin - >=20 > The important part of "new transaction" is the branch identifier. Are > the issues you're having > really with transaction identification? (I could only see that being > the > case if you had 2543 elements > involved.) Or is the real pain with policy on what a response to a > digest challenge has to look like? >=20 > What current IETF discussions are you pointing to below? >=20 > RjS >=20 > On 5/31/12 7:57 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC3261, > > "SIP: Session Initiation Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D3261&eid=3D3237 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Kevin P. Fleming > > > > Section: 8.1.3.5 > > > > Original Text > > ------------- > > In all of the above cases, the request is retried by creating a new > request with the appropriate modifications. This new request > constitutes a new transaction and SHOULD have the same value of the > Call-ID, To, and From of the previous request, but the CSeq should > contain a new sequence number that is one higher than the previous. > > > > Corrected Text > > -------------- > > In all of the above cases, the request is retried by creating a new > request with the appropriate modifications. This new request > constitutes a new transaction and SHOULD have the same value of the > Call-ID, To, and From of the previous request, but the CSeq SHOULD > contain a new sequence number that is one higher than the previous. > > > > Notes > > ----- > > We have had one implementor claim that they are not required to > increment CSeq when retrying the request because the RFC says 'should' > and not 'SHOULD'. Based on current IETF discussions, though, these > should probably be changed to MUST anyway, but that's a much more > substantive change throughout the whole RFC. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC3261 (draft-ietf-sip-rfc2543bis-09) > > -------------------------------------- > > Title : SIP: Session Initiation Protocol > > Publication Date : June 2002 > > Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. > Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler > > Category : PROPOSED STANDARD > > Source : Session Initiation Protocol > > Area : Real-time Applications and Infrastructure > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Thu May 31 09:38:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D5721F86FA for ; Thu, 31 May 2012 09:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsjcRdSVKjC8 for ; Thu, 31 May 2012 09:38:45 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD9121F86F8 for ; Thu, 31 May 2012 09:38:44 -0700 (PDT) Received: from Hydra.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4VGch2H086390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 31 May 2012 11:38:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4FC79E93.3000803@nostrum.com> Date: Thu, 31 May 2012 11:38:43 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <20120531125741.4B83D621A3@rfc-editor.org> <4FC783D0.4070505@nostrum.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CC55856@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2CC55856@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [sipcore] TRIM YOUR CC LINES (was Re: [Editorial Errata Reported] RFC3261 (3237)) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:38:45 -0000 [as chair] This list of recipients CCed on the email that started this thread is too long, and keeps getting caught up in the mailing list's moderation filter. This delays the messages being sent to the list, and requires me or Paul to go manually release them from the spam filter. When replying to mailing list messages, please trim off any unnecessary recipients (or, at the very least, move them to your BCC list so they don't show up at the mailing list server). Thanks! /a From kpfleming@digium.com Thu May 31 12:44:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950721F8766 for ; Thu, 31 May 2012 12:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdSPobn7WEOC for ; Thu, 31 May 2012 12:44:00 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id C92DD21F8764 for ; Thu, 31 May 2012 12:44:00 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SaBHg-0000EL-Ep; Thu, 31 May 2012 14:43:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 67C19D887A; Thu, 31 May 2012 14:43:48 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkkCR63xaU8u; Thu, 31 May 2012 14:43:47 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id BEA94D8002; Thu, 31 May 2012 14:43:47 -0500 (CDT) Message-ID: <4FC7C9E8.7070908@digium.com> Date: Thu, 31 May 2012 14:43:36 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Robert Sparks References: <20120531125741.4B83D621A3@rfc-editor.org> <4FC783D0.4070505@nostrum.com> In-Reply-To: <4FC783D0.4070505@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 31 May 2012 12:47:01 -0700 Cc: jdrosen@dynamicsoft.com, schooler@research.att.com, rsparks@dynamicsoft.com, schulzrinne@cs.columbia.edu, sipcore@ietf.org, drage@alcatel-lucent.com, alan.johnston@wcom.com, mjh@icir.org, jon.peterson@neustar.com, dean.willis@softarmor.com, RFC Errata System Subject: Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,