Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ?

[Rohan Mahy <[e-mail]>]

Hi Rohan,

The main reason to not carry DTMF in SIP INFOs is that there is a very  
good chance that you will get double-digits or otherwise corrupted  
digits because the signaling is not time-synchronized with the audio  
media.  This issue is discussed in an expired draft which I wrote a  
long time ago, which I abandoned in favor of the work generated by the  
app-interaction design team. At this point my draft is useful only in  
that it explains how double digits tend to occur.

my expired draft:

http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping- 
signaled-digits-01.html

the app-interaction design team drafts:

http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt
http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- 
interact-reqs-03.txt
http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info- 
00.txt
http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app- 
interaction-framework-00.txt


thanks,
-rohan (Mahy)


On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:

> Hi All,
>
> I hate to say that but SIP community doesn't agree
> or think that there are lots of use and requirement for carrying
> DTMF Out-of-Band.
>
> Every month, I can see that someone asks the same question again and  
> again
> that how do we send DTMF via INFO and Out-Of-Band .
>
> 3pcc needs it, lots of service creation environment needs it and
> doesn't it looks promising to have a way in SIP to do OOB
> DTMF just like h245-alphanumeric in H.323.
>
> If we think of applications,  then there are lots of them that I can
> count which doesn't care about the timing info carried by RFC2833.
> And if we really care about timing, then carrying RFC2833 via
> notify (Again OOB) is promising.
>
> I really do not understand if this is a political issue to not promote
> SIP INFO for carrying DTMF or if someone can justify it to me
> that there is no use to carry DTMF OOB.
>
> SIP authors, can you answer why SIP INFO for carrying simple
> DTMF is not a standard solution ?
>
> Thanks,
> Rohan Kumar
>
>
> ----- Original Message -----
> From: "Attila Sipos" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Friday, May 09, 2003 9:50 AM
> Subject: RE: [Sip-implementors] dtmf digits using INFO
>
>
>>
>> Hello Zsolt,
>>
>> I still don't think there is a fully-agreed
>> standard.  However, as much as I hate to say it,
>> CISCO have their own proposed standard which some
>> people (like us) interoperate with:
>>
>>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ 
> 122newft/122
>> t/122t11/ftinfo.htm
>>
>> Regards,
>>
>> Attila
>>
>> Attila Sipos
>> Software Engineer
>> <http://www.vegastream.com>
>> VegaStream : A World of difference for your Integrated Communications
>>
>> (jo napot kivánok)
>>
>>
>>
>>> -----Original Message-----
>>> From: Rizsanyi Zsolt [mailto:[e-mail]]
>>> Sent: 09 May 2003 13:41
>>> To: [e-mail]
>>> Subject: [Sip-implementors] dtmf digits using INFO
>>>
>>>
>>> Hi!
>>>
>>> Could somebody refer me to a current standard or draft, on
>>> how to send dtmf
>>> digits using the INFO method?
>>>
>>> Thanks
>>> Zsolt Rizsanyi
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [e-mail]
>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [e-mail]
>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

13-May-2003 19:30:19 -0500,3058;000000000001-00000b00
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 13 May 2003 19:30:19 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E0U96n006594
                for <[e-mail]>; Tue, 13 May 2003 19:30:10 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DNjHB10586;
                Tue, 13 May 2003 19:45:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DNheB10506
                for <[e-mail]>; Tue, 13 May 2003 19:43:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04843
                for <[e-mail]>; Tue, 13 May 2003 20:16:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Fjys-00010j-00
                for [e-mail]; Tue, 13 May 2003 20:18:50 -0400
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19Fjyr-00010g-00
                for [e-mail]; Tue, 13 May 2003 20:18:49 -0400
Received: from txdwillis ([63.206.46.200])
                (authenticated bits=0)
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E0JL6n006521
                (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
                for <[e-mail]>; Tue, 13 May 2003 19:19:25 -0500
From: "Dean Willis" <[e-mail]>
To: <[e-mail]>
Date: Tue, 13 May 2003 19:18:55 -0500
Message-ID: <000a01c319ae$6d67a9e0$06f30a0a@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
                charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sipping] Test -- please ignore
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=subscribe>
X-Spam-Status: No, hits=0.0 required=5.0
                tests=none
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Just probing the list server in a periodic maintenance function.

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

13-May-2003 23:14:38 -0500,3406;000000000001-00000b01
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 13 May 2003 23:14:38 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E4EV6n007969
                for <[e-mail]>; Tue, 13 May 2003 23:14:31 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E3RHB25551;
                Tue, 13 May 2003 23:27:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E3QGB25531
                for <[e-mail]>; Tue, 13 May 2003 23:26:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08744
                for <[e-mail]>; Tue, 13 May 2003 23:59:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FnSE-000277-00
                for [e-mail]; Wed, 14 May 2003 00:01:22 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FnSD-000274-00
                for [e-mail]; Wed, 14 May 2003 00:01:21 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14])
                by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4E41mDU022723;
                Tue, 13 May 2003 21:01:48 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
                by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
                with ESMTP id AHB69236;
                Tue, 13 May 2003 20:55:25 -0700 (PDT)
Date: Tue, 13 May 2003 21:02:01 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: [e-mail], [e-mail], [e-mail],
      "'Dean Willis'" <[e-mail]>, [e-mail]
To: "'[e-mail]'" <[e-mail]>
From: Rohan Mahy <[e-mail]>
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=subscribe>
X-Spam-Status: No, hits=-2.1 required=5.0
                tests=USER_AGENT_APPLEMAIL
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Hello Everyone,

I'd like to begin Working Group Last Call on:

http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt

this WGLC will end on June 13, 2003.

thanks,
-rohan

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 00:11:03 -0500,1904;000000000001-00000b02
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 00:11:03 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from harjus.eng.song.fi ([e-mail] [195.10.149.20])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E5Am6n008311
                for <[e-mail]>; Wed, 14 May 2003 00:10:51 -0500
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 (Debian))
                id 19FoWw-0000Dm-00; Wed, 14 May 2003 08:10:18 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 14 May 2003 08:10:18 +0300
To: Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      [e-mail], "'Dean Willis'" <[e-mail]>,
      [e-mail]
Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
X-Spam-Status: No, hits=-28.6 required=5.0
                tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                autolearn=ham version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Rohan Mahy writes:

  > I'd like to begin Working Group Last Call on:
  > 
  > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt
  > 
  > this WGLC will end on June 13, 2003.

i must be seeing a VERY bad dream. the draft uses the wrong service
field for sip: "sip+E2U" instead of "E2U+sip" as per
draft-ietf-enum-rfc2916bis-06.txt.

please discard the sipping draft from the archives AS SOON AS POSSIBLE
so that not a single new implementer will find and read it.

-- juha

14-May-2003 00:22:12 -0500,3615;000000000001-00000b03
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 00:22:12 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E5M56n008379
                for <[e-mail]>; Wed, 14 May 2003 00:22:06 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E4ZEB29843;
                Wed, 14 May 2003 00:35:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E4YMB29785
                for <[e-mail]>; Wed, 14 May 2003 00:34:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10188
                for <[e-mail]>; Wed, 14 May 2003 01:07:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FoW6-0002Sv-00
                for [e-mail]; Wed, 14 May 2003 01:09:26 -0400
Received: from harjus.eng.song.fi ([195.10.149.20] ident=mail)
                by ietf-mx with esmtp (Exim 4.12)
                id 19FoW5-0002Ss-00
                for [e-mail]; Wed, 14 May 2003 01:09:25 -0400
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 (Debian))
                id 19FoWw-0000Dm-00; Wed, 14 May 2003 08:10:18 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 14 May 2003 08:10:18 +0300
To: Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      [e-mail], "'Dean Willis'" <[e-mail]>,
      [e-mail]
Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=subscribe>
X-Spam-Status: No, hits=-28.6 required=5.0
                tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Rohan Mahy writes:

  > I'd like to begin Working Group Last Call on:
  > 
  > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt
  > 
  > this WGLC will end on June 13, 2003.

i must be seeing a VERY bad dream. the draft uses the wrong service
field for sip: "sip+E2U" instead of "E2U+sip" as per
draft-ietf-enum-rfc2916bis-06.txt.

please discard the sipping draft from the archives AS SOON AS POSSIBLE
so that not a single new implementer will find and read it.

-- juha
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 02:26:55 -0500,3446;000000000001-00000b04
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 02:26:55 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E7Ql6n009163
                for <[e-mail]>; Wed, 14 May 2003 02:26:47 -0500
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4E7POC11664;
                Wed, 14 May 2003 07:25:24 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
                id <ZH2KBVPM>; Wed, 14 May 2003 03:27:15 -0400
Message-ID: <[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Juha Heinanen'" <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, [e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Date: Wed, 14 May 2003 03:27:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset="iso-8859-1"
X-Spam-Status: No, hits=-2.9 required=5.0
                tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT
                autolearn=ham version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

No, you're not suffering any bad dream - just an attack of rhetorical
exaggeration and lax reading. The authors of sipping-e164 are aware of the
rfc2916bis Internet-Draft, and have suitably referenced it in Section 7,
which is entitled "Updates for rfc2916bis". It mentions the new enumservice
format that concerns you so greatly below, and recommends that SIP
applications accept either format for purposes of backwards compatibility -
quite generous considering that rfc2916bis is just a I-D, not a standard. In
the light of all this, it is hard for me to see a justification for
banishing sipping-e164 from the I-D archives.

But granted - the last time that sipping-e164 was updated (October 2002),
rfc2916bis was a lot less mature than it is now. Given that a last call for
rfc2916bis is also now in progress, it might make sense to update
sipping-e164 to reference (normatively) the new rfc2916bis notation
throughout, assuming that they will both go before the IESG at about the
same time. A fair last call comment; we'll remedy this before sipping-e164
goes to the IESG.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[e-mail]]
> Sent: Tuesday, May 13, 2003 10:10 PM
> To: Rohan Mahy
> Cc: '[e-mail]'; [e-mail];
> [e-mail]; 'Dean Willis'; 
> [e-mail]
> Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
> 
> 
> Rohan Mahy writes:
> 
> > I'd like to begin Working Group Last Call on:
> > 
> > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt
> > 
> > this WGLC will end on June 13, 2003.
> 
> i must be seeing a VERY bad dream. the draft uses the wrong service
> field for sip: "sip+E2U" instead of "E2U+sip" as per
> draft-ietf-enum-rfc2916bis-06.txt.
> 
> please discard the sipping draft from the archives AS SOON AS POSSIBLE
> so that not a single new implementer will find and read it.
> 
> -- juha
> 

14-May-2003 02:36:36 -0500,5113;000000000001-00000b05
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 02:36:36 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E7aT6n009254
                for <[e-mail]>; Wed, 14 May 2003 02:36:30 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E6pGB17999;
                Wed, 14 May 2003 02:51:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E6oSB17963
                for <[e-mail]>; Wed, 14 May 2003 02:50:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07865
                for <[e-mail]>; Wed, 14 May 2003 03:23:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Fqdl-0003Hg-00
                for [e-mail]; Wed, 14 May 2003 03:25:29 -0400
Received: from willow.neustar.com ([209.173.53.84])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Fqdk-0003HD-00
                for [e-mail]; Wed, 14 May 2003 03:25:28 -0400
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4E7POC11664;
                Wed, 14 May 2003 07:25:24 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
                id <ZH2KBVPM>; Wed, 14 May 2003 03:27:15 -0400
Message-ID: <[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Juha Heinanen'" <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, [e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Date: Wed, 14 May 2003 03:27:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset="iso-8859-1"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=subscribe>
X-Spam-Status: No, hits=-2.9 required=5.0
                tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

No, you're not suffering any bad dream - just an attack of rhetorical
exaggeration and lax reading. The authors of sipping-e164 are aware of the
rfc2916bis Internet-Draft, and have suitably referenced it in Section 7,
which is entitled "Updates for rfc2916bis". It mentions the new enumservice
format that concerns you so greatly below, and recommends that SIP
applications accept either format for purposes of backwards compatibility -
quite generous considering that rfc2916bis is just a I-D, not a standard. In
the light of all this, it is hard for me to see a justification for
banishing sipping-e164 from the I-D archives.

But granted - the last time that sipping-e164 was updated (October 2002),
rfc2916bis was a lot less mature than it is now. Given that a last call for
rfc2916bis is also now in progress, it might make sense to update
sipping-e164 to reference (normatively) the new rfc2916bis notation
throughout, assuming that they will both go before the IESG at about the
same time. A fair last call comment; we'll remedy this before sipping-e164
goes to the IESG.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[e-mail]]
> Sent: Tuesday, May 13, 2003 10:10 PM
> To: Rohan Mahy
> Cc: '[e-mail]'; [e-mail];
> [e-mail]; 'Dean Willis'; 
> [e-mail]
> Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
> 
> 
> Rohan Mahy writes:
> 
> > I'd like to begin Working Group Last Call on:
> > 
> > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt
> > 
> > this WGLC will end on June 13, 2003.
> 
> i must be seeing a VERY bad dream. the draft uses the wrong service
> field for sip: "sip+E2U" instead of "E2U+sip" as per
> draft-ietf-enum-rfc2916bis-06.txt.
> 
> please discard the sipping draft from the archives AS SOON AS POSSIBLE
> so that not a single new implementer will find and read it.
> 
> -- juha
> 
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 03:56:44 -0500,3487;000000000001-00000b06
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 03:56:44 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E8uc6n009776
                for <[e-mail]>; Wed, 14 May 2003 03:56:38 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E89GB24764;
                Wed, 14 May 2003 04:09:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E88mB24739
                for <[e-mail]>; Wed, 14 May 2003 04:08:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09523
                for <[e-mail]>; Wed, 14 May 2003 04:41:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FrrY-0003kv-00
                for [e-mail]; Wed, 14 May 2003 04:43:48 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se)
                by ietf-mx with esmtp (Exim 4.12)
                id 19FrrX-0003ks-00
                for [e-mail]; Wed, 14 May 2003 04:43:47 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
                by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4E8iX0Q004433;
                Wed, 14 May 2003 10:44:40 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
                id <K765BATY>; Wed, 14 May 2003 10:43:20 +0200
Message-ID: <[e-mail]>
From: "Gonzalo Camarillo Gonzalez (LMF)"
                  <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Date: Wed, 14 May 2003 09:12:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
                charset="iso-8859-1"
Subject: [Sipping] Last Call for early media use cases
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=subscribe>
X-Spam-Status: No, hits=0.0 required=5.0
                tests=none
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Folks,

in the last IETF meeting, we requested early media use cases that show the need of a "media coming" flag. So far, we have not received anything.

We intend to release a new version of the early media draft in a week or so. So, that is the time you have to send me your use cases.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 13:35:23 -0500,6494;000000000001-00000b07
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 13:35:23 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from znsgs01r.nortelnetworks.com (h21s128a211n47.user.nortelnetworks.com [47.211.128.21])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EIZD6n014591
                for <[e-mail]>; Wed, 14 May 2003 13:35:14 -0500
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])
                by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EIW7w29988;
                Wed, 14 May 2003 19:32:08 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
                id <KRL863FY>; Wed, 14 May 2003 19:32:09 +0100
Message-ID: <[e-mail]>
From: "Mark Watson" <[e-mail]>
To: "'Gonzalo Camarillo Gonzalez (LMF)'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Wed, 14 May 2003 19:32:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
                boundary="----_=_NextPart_001_01C31A47.1F6320FA"
X-Spam-Status: No, hits=-1.0 required=5.0
                tests=ASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT
                version=2.52
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C31A47.1F6320FA
Gonzalo,

I think you have received plenty of emails on this topic. What is clear =
is
that there is no consensus either way that such an indication is or is =
not
required.

Anyway, for my part I do not have any further information I can provide =
you
that I think has any prospect of convincing you. I still believe the =
absence
of some kind of additional indication will in practice lead to a
less-than-ideal user experience, but I quite accept there is no =
consensus
right now.

Regards,

Mark

> -----Original Message-----
> From: Gonzalo Camarillo Gonzalez (LMF)
> [mailto:[e-mail]]
> Sent: 14 May 2003 00:13
> To: '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: [Sipping] Last Call for early media use cases
>=20
>=20
> Folks,
>=20
> in the last IETF meeting, we requested early media use cases=20
> that show the need of a "media coming" flag. So far, we have=20
> not received anything.
>=20
> We intend to release a new version of the early media draft=20
> in a week or so. So, that is the time you have to send me=20
> your use cases.
>=20
> Thanks,
>=20
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>=20

------_=3D_NextPart_001_01C31A47.1F6320FA
[Enclosed text/html ]
------_=3D_NextPart_001_01C31A47.1F6320FA--

14-May-2003 13:44:38 -0500,8197;000000000001-00000b08
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 =
13:44:38 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EIiW6n014669
                for <[e-mail]>; Wed, 14 May 2003 13:44:32 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EHvRB04949;
                Wed, 14 May 2003 13:57:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EHumB04860
                for <[e-mail]>; Wed, 14 May 2003 13:56:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29802
                for <[e-mail]>; Wed, 14 May 2003 14:29:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19G12N-0000Ka-00
                for [e-mail]; Wed, 14 May 2003 14:31:35 -0400
Received: from h21s128a211n47.user.nortelnetworks.com ([47.211.128.21] =
helo=3Dznsgs01r.nortelnetworks.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19G12M-0000KU-00
                for [e-mail]; Wed, 14 May 2003 14:31:34 -0400
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com =
[47.160.46.124])
                by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4EIW7w29988;
                Wed, 14 May 2003 19:32:08 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <KRL863FY>; Wed, 14 May 2003 19:32:09 +0100
Message-ID: =
<[e-mail]>
From: "Mark Watson" <[e-mail]>
To: "'Gonzalo Camarillo Gonzalez (LMF)'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Wed, 14 May 2003 19:32:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
                boundary=3D"----_=3D_NextPart_001_01C31A47.1F6320FA"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-1.0 required=3D5.0
                tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C31A47.1F6320FA
Gonzalo,

I think you have received plenty of emails on this topic. What is clear =
is
that there is no consensus either way that such an indication is or is =
not
required.

Anyway, for my part I do not have any further information I can provide =
you
that I think has any prospect of convincing you. I still believe the =
absence
of some kind of additional indication will in practice lead to a
less-than-ideal user experience, but I quite accept there is no =
consensus
right now.

Regards,

Mark

> -----Original Message-----
> From: Gonzalo Camarillo Gonzalez (LMF)
> [mailto:[e-mail]]
> Sent: 14 May 2003 00:13
> To: '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: [Sipping] Last Call for early media use cases
>=20
>=20
> Folks,
>=20
> in the last IETF meeting, we requested early media use cases=20
> that show the need of a "media coming" flag. So far, we have=20
> not received anything.
>=20
> We intend to release a new version of the early media draft=20
> in a week or so. So, that is the time you have to send me=20
> your use cases.
>=20
> Thanks,
>=20
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>=20

------_=3D_NextPart_001_01C31A47.1F6320FA
[Enclosed text/html ]
------_=3D_NextPart_001_01C31A47.1F6320FA--
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 16:51:39 -0500,5088;000000000001-00000b09
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 =
16:51:39 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk =
[193.118.201.102])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h4ELpT6n015948
                for <[e-mail]>; Wed, 14 May 2003 16:51:30 -0500
Received: by rsys001a.roke.co.uk with Internet Mail Service =
(5.5.2653.19)
                id <JZWGWH6B>; Wed, 14 May 2003 22:51:03 +0100
Received: from orion.roke.co.uk ([193.118.192.66]) by =
rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service =
Version 5.5.2653.13)
                id HSB1ZJT4; Wed, 14 May 2003 22:50:51 +0100
From: "Conroy, Lawrence (SMTP)" <[e-mail]>
To: "Peterson, Jon" <[e-mail]>,
      "'Juha Heinanen'"
                  <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Mime-Version: 1.0
X-Sender: lwc@127.0.0.1
Message-Id: <[e-mail]>
In-Reply-To:=20
  <[e-mail]>
References:=20
  <[e-mail]>
Date: Wed, 14 May 2003 22:51:03 +0100
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Content-Type: multipart/mixed;
                boundary=3D"------------InterScan_NT_MIME_Boundary"
X-Spam-Status: No, hits=3D-26.1 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
At 3:27 am -0400 14/5/03, Peterson, Jon wrote:
>No, you're not suffering any bad dream - just an attack of rhetorical
>exaggeration and lax reading. The authors of sipping-e164 are aware of =
the
>rfc2916bis Internet-Draft, and have suitably referenced it in Section =
7,
>which is entitled "Updates for rfc2916bis". It mentions the new =
enumservice
>format that concerns you so greatly below, and recommends that SIP
>applications accept either format for purposes of backwards =
compatibility -
>quite generous considering that rfc2916bis is just a I-D, not a =
standard. In
>the light of all this, it is hard for me to see a justification for
>banishing sipping-e164 from the I-D archives.
>
>But granted - the last time that sipping-e164 was updated (October =
2002),
>rfc2916bis was a lot less mature than it is now. Given that a last =
call for
>rfc2916bis is also now in progress, it might make sense to update
>sipping-e164 to reference (normatively) the new rfc2916bis notation
>throughout, assuming that they will both go before the IESG at about =
the
>same time. A fair last call comment; we'll remedy this before =
sipping-e164
>goes to the IESG.
>
>Jon Peterson
>NeuStar, Inc.
>
>Juha Wrote:
> > i must be seeing a VERY bad dream. the draft uses the wrong =
service
>> field for sip: "sip+E2U" instead of "E2U+sip" as per
>> draft-ietf-enum-rfc2916bis-06.txt.
>>
>> please discard the sipping draft from the archives AS SOON AS =
POSSIBLE
> > so that not a single new implementer will find and read it.
> >
To which I reply:

Hi folks,
    RFC2916 is going to be obsoleted by rfc2916bis-06 (if approved)? =
Thus,
this backward compatibility in sipping-e164 would be with be with an =
obsoleted
document (not even a current I-D).

I have a lot of sympathy with Juha on this one - we have already had=20
fun with one
bunch (strictly) implementing 2916 whilst the other bunch (strictly) =
implement
2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20
- I fear not.

=3D> Do you -REALLY- -REALLY- need backward compatibility?

My vote's to just go with the 2916bis syntax throughout, and remove =
reference
to the soon to be obsoleted syntax in sipping-164?

BTW, will we see an up-issued version as -02 IS out of date and has =
some things
that will/may/might change?

all the best,
      Lawrence
--=20
-----------------------------------------------------------------------
Roke Manor Research : This information is provided "as is" and is =
not
<mailto:[e-mail]>: intended to create any contractual or legal
<tel:[phone]> : relationship.

--------------InterScan_NT_MIME_Boundary
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, =
Bracknell,=20
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is =
confidential to Roke Manor Research Ltd and must not be passed to any =
third party without permission. This communication is for information =
only and shall not create or change any contractual relationship.

--------------InterScan_NT_MIME_Boundary--

14-May-2003 17:05:05 -0500,5976;000000000001-00000b0a
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 =
17:05:05 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EM4t6n016069
                for <[e-mail]>; Wed, 14 May 2003 17:04:56 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELGFB20772;
                Wed, 14 May 2003 17:16:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELFEB20747
                for <[e-mail]>; Wed, 14 May 2003 17:15:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07136
                for <[e-mail]>; Wed, 14 May 2003 17:48:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19G48L-0001oU-00
                for [e-mail]; Wed, 14 May 2003 17:49:57 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
                by ietf-mx with esmtp (Exim 4.12)
                id 19G48K-0001oQ-00
                for [e-mail]; Wed, 14 May 2003 17:49:56 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service =
(5.5.2653.19)
                id <JZWGWH6B>; Wed, 14 May 2003 22:51:03 +0100
Received: from orion.roke.co.uk ([193.118.192.66]) by =
rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service =
Version 5.5.2653.13)
                id HSB1ZJT4; Wed, 14 May 2003 22:50:51 +0100
From: "Conroy, Lawrence (SMTP)" <[e-mail]>
To: "Peterson, Jon" <[e-mail]>,
      "'Juha Heinanen'"
                  <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Mime-Version: 1.0
X-Sender: lwc@127.0.0.1
Message-Id: <[e-mail]>
In-Reply-To:=20
  <[e-mail]>
References:=20
  <[e-mail]>
Date: Wed, 14 May 2003 22:51:03 +0100
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-32.4 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

At 3:27 am -0400 14/5/03, Peterson, Jon wrote:
>No, you're not suffering any bad dream - just an attack of rhetorical
>exaggeration and lax reading. The authors of sipping-e164 are aware of =
the
>rfc2916bis Internet-Draft, and have suitably referenced it in Section =
7,
>which is entitled "Updates for rfc2916bis". It mentions the new =
enumservice
>format that concerns you so greatly below, and recommends that SIP
>applications accept either format for purposes of backwards =
compatibility -
>quite generous considering that rfc2916bis is just a I-D, not a =
standard. In
>the light of all this, it is hard for me to see a justification for
>banishing sipping-e164 from the I-D archives.
>
>But granted - the last time that sipping-e164 was updated (October =
2002),
>rfc2916bis was a lot less mature than it is now. Given that a last =
call for
>rfc2916bis is also now in progress, it might make sense to update
>sipping-e164 to reference (normatively) the new rfc2916bis notation
>throughout, assuming that they will both go before the IESG at about =
the
>same time. A fair last call comment; we'll remedy this before =
sipping-e164
>goes to the IESG.
>
>Jon Peterson
>NeuStar, Inc.
>
>Juha Wrote:
> > i must be seeing a VERY bad dream. the draft uses the wrong =
service
>> field for sip: "sip+E2U" instead of "E2U+sip" as per
>> draft-ietf-enum-rfc2916bis-06.txt.
>>
>> please discard the sipping draft from the archives AS SOON AS =
POSSIBLE
> > so that not a single new implementer will find and read it.
> >
To which I reply:

Hi folks,
    RFC2916 is going to be obsoleted by rfc2916bis-06 (if approved)? =
Thus,
this backward compatibility in sipping-e164 would be with be with an =
obsoleted
document (not even a current I-D).

I have a lot of sympathy with Juha on this one - we have already had=20
fun with one
bunch (strictly) implementing 2916 whilst the other bunch (strictly) =
implement
2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20
- I fear not.

=3D> Do you -REALLY- -REALLY- need backward compatibility?

My vote's to just go with the 2916bis syntax throughout, and remove =
reference
to the soon to be obsoleted syntax in sipping-164?

BTW, will we see an up-issued version as -02 IS out of date and has =
some things
that will/may/might change?

all the best,
      Lawrence
--=20
-----------------------------------------------------------------------
Roke Manor Research : This information is provided "as is" and is =
not
<mailto:[e-mail]>: intended to create any contractual or legal
<tel:[phone]> : relationship.
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 20:57:18 -0500,8136;000000000001-00000b0b
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 =
20:57:18 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4F1vA6n017390
                for <[e-mail]>; Wed, 14 May 2003 20:57:11 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1COB03385;
                Wed, 14 May 2003 21:12:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1BmB03366
                for <[e-mail]>; Wed, 14 May 2003 21:11:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12270
                for <[e-mail]>; Wed, 14 May 2003 21:44:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19G7pC-0002wY-00
                for [e-mail]; Wed, 14 May 2003 21:46:26 -0400
Received: from mail3.hosting.bora.net ([211.40.221.16])
                by ietf-mx with smtp (Exim 4.12)
                id 19G7pA-0002wS-00
                for [e-mail]; Wed, 14 May 2003 21:46:24 -0400
Received: (qmail 6846 invoked from network); 15 May 2003 01:46:57 -0000
Received: from unknown (HELO thomas2000svr) (211.239.8.224)
    by mail3.hosting.bora.net with SMTP; 15 May 2003 01:46:57 -0000
From: "???? ???" <[e-mail]>
To: <[e-mail]>
Date: Thu, 15 May 2003 10:46:58 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
                boundary=3D"----=3D_NextPart_000_0043_01C31ACF.4F688C30"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Subject: [Sipping] Push-To-Talk with SIP
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.4 required=3D5.0
                tests=3DBASE64_ENC_TEXT,MSGID_GOOD_EXCHANGE,RCVD_IN_OSIRUSOFT_COM
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This is a multi-part message in MIME format.

------=3D_NextPart_000_0043_01C31ACF.4F688C30
Hello, 

Nokia, Siemens and Ericsson have announced tu¡…Ёѡ•ä…É”‘•Ù•±½Á¥¹œ„ÁÕÍ µÑ¼µÑ…±¬…ÁÁ±¥…Ñ¥½¸™½ÈMÔÒæWGv÷&·2v—F‚u%2æBf÷"gWGW&R4ræWGv÷&·2âF†W’vç]È\ÙHÒT›ÜˆÚYۘ[[™È]HÛÝ[‰Ýš[™[žH[ܙHetailed information. 

Does someone of you know some detu…¥°…‰½ÕЁѡ”AQPÍ¥¹…±¥¹œÝ¥Ñ M%@ü4)¼Ñ¡•ä…É”…‰½ÕÑÒ&&—G&F–öâ–bGvòV÷ÆRvçBFòFƲFòF†R6ÖRw&÷WH]HØ[YH[YOÈ\™H\™HÛÛYH˜YÈ܈\ØÝ\ÜÚ[ۜÈ]bout this topics? 

regards, 
thomas lee. 

          
        t€€€€€€€€€Q¡½µ…́1••Q•¡¹¥…° ½¹Íձх¹ÑA½±åÁ¥à%¹ÍÑ¥ÑÕѕÒöbFV6†æöÆöw“b7VævFòfVçGW&RF÷vW"ÂcRÓ"6×7VærÖFöæwKØ[™Û˜[KZÝKÙ[Ý[ LÍKN KÛܙXU[ˆ
Î ‹L‹MML‹LÍLLH
^t. 511) Fax : [phone]Mobile : [phone]E-mau¥°€èÑ¡½µ…̹±••
Á½±åÁ¥à¹½µUÉ°€èÝÝܹÁ½±åÁ¥à¹½´€€4(€€€€ÐТÐ Ð Ð wpÝÜ
------=3D_NextPart_000_0043_01C31ACF.4F688C30
[Enclosed text/html ]
------=3D_NextPart_000_0043_01C31ACF.4F688C30--

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 21:32:56 -0500,11696;000000000001-00000b0c
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 =
21:32:56 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4F2Wn6n017582
                for <[e-mail]>; Wed, 14 May 2003 21:32:49 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1m7B05732;
                Wed, 14 May 2003 21:48:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1l6B05690
                for <[e-mail]>; Wed, 14 May 2003 21:47:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12828
                for <[e-mail]>; Wed, 14 May 2003 22:19:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19G8NL-00036W-00
                for [e-mail]; Wed, 14 May 2003 22:21:43 -0400
Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] =
helo=3Dzsc3s004.nortelnetworks.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19G8NK-00036H-00
                for [e-mail]; Wed, 14 May 2003 22:21:42 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com =
[47.81.138.28])
                by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4F2MA629373;
                Wed, 14 May 2003 19:22:10 -0700 (PDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <KRLR2M72>; Wed, 14 May 2003 19:21:40 -0700
Message-ID: =
<[e-mail]>
From: "Francois Audet" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Date: Wed, 14 May 2003 19:21:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
                boundary=3D"----_=3D_NextPart_001_01C31A88.B82957DC"
Subject: [Sipping] Questions and comments on =
draft-rosenberg-sipping-ice-00
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D1.9 required=3D5.0
                tests=3DHTML_10_20,HTML_MESSAGE,SUBJ_HAS_UNIQ_ID
                version=3D2.52
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C31A88.B82957DC
Hi Jonathan,

Better late than never I guess. I have a few questions/comments on=20
draft-rosenberg-sipping-ice-00.html.

- Section 2 (the overview) says that the UAC should attempt to derive
    IP addresses with STUN, TURN, RSIP and VPN servers and place all of=20
    these addresses in the offer SDP. Sections 3, 5.1 and 5.4 confirm =
this=20
    procedure. In the case of STUN, it means a dedicated STUN server as
    opposed to the peer-to-peer UA STUN server used at call setup. =
However,
    section 12.3 may lead the reader to believe that a dedicated STUN=20
    server) is "simply not used" and that instead the peer-to-peer UA =
STUN
    servers are sufficient. The wording should be re-done to clarify that
    what is not used is the NAT classification process (the derivation of =

    the IP address using a dedicated STUN server is indeed used). At =
least,
    I think this is what 12.3 is saying. If there was an example 9.3,=20
    similar to 9.2 but where B calls A, I assume that B would include =
both=20
    LTA2 and PDTA2 in the offer, and that PDTA2 would be marked as
    derived. Is this correct? Since the 2 examples of section 9 do NOT =
have
    a STUN-derived address for the calling party, it is even more =
confusing.

- Section 7.2 says that the derived-attribute refer to transport =
addresses
    "learned from the entity to whom the SDP is being sent (referred to
    as the peer)". This is the same issues as the previous one. I don't =
think
    this is correct. It is the transport address learned from the STUN
    query: in the initial offer, that address is NOT learned from the
    "peer" but from the dedicated STUN server. Correct? In the answer or =
in
    a second round of offer (in an UPDATE), then is is indeed learned =
from=20
    the peer. Is this correct?

- In examples 9.1 and 9.2, A only has one address, a local IPv4 =
address.=20
    The qvalue is set to 1.0 in the offer in both examples. According to=20
    the rules 5.3, shouldn't the qvalue in the offer been set to 0.8=20
    instead?

- In example 9.1, can't we skip the whole peer-to-peer STUN query since
    both A and B know that no NATs are involved from their previous STUN=20
    query to the dedicated STUN servers? I mean, when B receives A's
    offer, it sees only one address (non-derived), and it knows that
    itself has only a non-derived IP address.

- In a few places (including the abstract), it is claimed that ICE is =
less
    brittle than STUN. This may be a little misleading since ICE itselfs
    uses the STUN protocol. It should be clarified (as per my earlier =
point),=20
    that what is meant by "STUN" in this context is that traditional STUN =
only

    is more brittle than ICE.


Typos:
- Section 2, third paragraph, first sentence. Replace "realsm" with=20
    "realms".

- In section 9.2, in the paragraph right before the description of the =

    UPDATE content, replace "has no offered" with "has not offered".


----
Fran=3DE7ois AUDET, Nortel Networks
Tel: [phone]

------_=3D_NextPart_001_01C31A88.B82957DC
[Enclosed text/html ]
------_=3D_NextPart_001_01C31A88.B82957DC--
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 07:06:33 -0500,5234;000000000001-00000b0d
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
07:06:33 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FC6K6n021353
                for <[e-mail]>; Thu, 15 May 2003 07:06:21 -0500
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com =
[10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4FC4pC31658;
                Thu, 15 May 2003 12:04:54 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service =
(5.5.2653.19)
                id <ZH2KB8WC>; Thu, 15 May 2003 08:06:44 -0400
Message-ID: =
<[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Conroy, Lawrence (SMTP)'" <[e-mail]>,
      "'Juha Heinanen'"
                  <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Date: Thu, 15 May 2003 08:06:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
X-Spam-Status: No, hits=3D-2.9 required=3D5.0
                tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

As I indicated in my last note, there will be an updated version, yes, =
but
it will not entirely neglect the soon-to-be-superannuated RFC2916. I =
don't
think it is too much to ask that SIP applications utilizing ENUM be =
generous
in what they receive with regard to enumservices - it just doesn't =
seem
costly to be backwards compatible with the original iteration of the =
ENUM
standard.

If there are things other than the enumservice update that people would =
like
to see mended, this last call period would be a good time to let the =
authors
know.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[e-mail]]
> Sent: Wednesday, May 14, 2003 2:51 PM
> To: Peterson, Jon; 'Juha Heinanen'; Rohan Mahy
> Cc: '[e-mail]'; [e-mail]; 'Dean Willis';
> [e-mail]
> Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
>=20
>=20
> At 3:27 am -0400 14/5/03, Peterson, Jon wrote:
> >No, you're not suffering any bad dream - just an attack of =
rhetorical
> >exaggeration and lax reading. The authors of sipping-e164=20
> are aware of the
> >rfc2916bis Internet-Draft, and have suitably referenced it=20
> in Section 7,
> >which is entitled "Updates for rfc2916bis". It mentions the=20
> new enumservice
> >format that concerns you so greatly below, and recommends that SIP
> >applications accept either format for purposes of backwards=20
> compatibility -
> >quite generous considering that rfc2916bis is just a I-D,=20
> not a standard. In
> >the light of all this, it is hard for me to see a justification for
> >banishing sipping-e164 from the I-D archives.
> >
> >But granted - the last time that sipping-e164 was updated=20
> (October 2002),
> >rfc2916bis was a lot less mature than it is now. Given that=20
> a last call for
> >rfc2916bis is also now in progress, it might make sense to update
> >sipping-e164 to reference (normatively) the new rfc2916bis notation
> >throughout, assuming that they will both go before the IESG=20
> at about the
> >same time. A fair last call comment; we'll remedy this=20
> before sipping-e164
> >goes to the IESG.
> >
> >Jon Peterson
> >NeuStar, Inc.
> >
> >Juha Wrote:
> > > i must be seeing a VERY bad dream. the draft uses the=20
> wrong service
> >> field for sip: "sip+E2U" instead of "E2U+sip" as per
> >> draft-ietf-enum-rfc2916bis-06.txt.
> >>
> >> please discard the sipping draft from the archives AS=20
> SOON AS POSSIBLE
> > > so that not a single new implementer will find and read it.
> > >
> To which I reply:
>=20
> Hi folks,
> RFC2916 is going to be obsoleted by rfc2916bis-06 (if=20
> approved)? Thus,
> this backward compatibility in sipping-e164 would be with be=20
> with an obsoleted
> document (not even a current I-D).
>=20
> I have a lot of sympathy with Juha on this one - we have already had=20
> fun with one
> bunch (strictly) implementing 2916 whilst the other bunch=20
> (strictly) implement
> 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20
> - I fear not.
>=20
> =3D> Do you -REALLY- -REALLY- need backward compatibility?
>=20
> My vote's to just go with the 2916bis syntax throughout, and=20
> remove reference
> to the soon to be obsoleted syntax in sipping-164?
>=20
> BTW, will we see an up-issued version as -02 IS out of date=20
> and has some things
> that will/may/might change?
>=20
> all the best,
> Lawrence
> --=20
> --------------------------------------------------------------
> ---------
> Roke Manor Research : This information is provided "as is"=20
> and is not
> <mailto:[e-mail]>: intended to create any contractual or legal
> <tel:[phone]> : relationship.
>=20

15-May-2003 07:17:36 -0500,6901;000000000001-00000b0e
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
07:17:36 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FCHO6n021506
                for <[e-mail]>; Thu, 15 May 2003 07:17:25 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FBV6B23688;
                Thu, 15 May 2003 07:31:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FBUYB23640
                for <[e-mail]>; Thu, 15 May 2003 07:30:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05469
                for <[e-mail]>; Thu, 15 May 2003 08:03:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GHTn-0006Nq-00
                for [e-mail]; Thu, 15 May 2003 08:04:59 -0400
Received: from willow.neustar.com ([209.173.53.84])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GHTm-0006Nh-00
                for [e-mail]; Thu, 15 May 2003 08:04:58 -0400
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com =
[10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4FC4pC31658;
                Thu, 15 May 2003 12:04:54 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service =
(5.5.2653.19)
                id <ZH2KB8WC>; Thu, 15 May 2003 08:06:44 -0400
Message-ID: =
<[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Conroy, Lawrence (SMTP)'" <[e-mail]>,
      "'Juha Heinanen'"
                  <[e-mail]>, Rohan Mahy <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
Date: Thu, 15 May 2003 08:06:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-2.9 required=3D5.0
                tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

As I indicated in my last note, there will be an updated version, yes, =
but
it will not entirely neglect the soon-to-be-superannuated RFC2916. I =
don't
think it is too much to ask that SIP applications utilizing ENUM be =
generous
in what they receive with regard to enumservices - it just doesn't =
seem
costly to be backwards compatible with the original iteration of the =
ENUM
standard.

If there are things other than the enumservice update that people would =
like
to see mended, this last call period would be a good time to let the =
authors
know.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[e-mail]]
> Sent: Wednesday, May 14, 2003 2:51 PM
> To: Peterson, Jon; 'Juha Heinanen'; Rohan Mahy
> Cc: '[e-mail]'; [e-mail]; 'Dean Willis';
> [e-mail]
> Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
>=20
>=20
> At 3:27 am -0400 14/5/03, Peterson, Jon wrote:
> >No, you're not suffering any bad dream - just an attack of =
rhetorical
> >exaggeration and lax reading. The authors of sipping-e164=20
> are aware of the
> >rfc2916bis Internet-Draft, and have suitably referenced it=20
> in Section 7,
> >which is entitled "Updates for rfc2916bis". It mentions the=20
> new enumservice
> >format that concerns you so greatly below, and recommends that SIP
> >applications accept either format for purposes of backwards=20
> compatibility -
> >quite generous considering that rfc2916bis is just a I-D,=20
> not a standard. In
> >the light of all this, it is hard for me to see a justification for
> >banishing sipping-e164 from the I-D archives.
> >
> >But granted - the last time that sipping-e164 was updated=20
> (October 2002),
> >rfc2916bis was a lot less mature than it is now. Given that=20
> a last call for
> >rfc2916bis is also now in progress, it might make sense to update
> >sipping-e164 to reference (normatively) the new rfc2916bis notation
> >throughout, assuming that they will both go before the IESG=20
> at about the
> >same time. A fair last call comment; we'll remedy this=20
> before sipping-e164
> >goes to the IESG.
> >
> >Jon Peterson
> >NeuStar, Inc.
> >
> >Juha Wrote:
> > > i must be seeing a VERY bad dream. the draft uses the=20
> wrong service
> >> field for sip: "sip+E2U" instead of "E2U+sip" as per
> >> draft-ietf-enum-rfc2916bis-06.txt.
> >>
> >> please discard the sipping draft from the archives AS=20
> SOON AS POSSIBLE
> > > so that not a single new implementer will find and read it.
> > >
> To which I reply:
>=20
> Hi folks,
> RFC2916 is going to be obsoleted by rfc2916bis-06 (if=20
> approved)? Thus,
> this backward compatibility in sipping-e164 would be with be=20
> with an obsoleted
> document (not even a current I-D).
>=20
> I have a lot of sympathy with Juha on this one - we have already had=20
> fun with one
> bunch (strictly) implementing 2916 whilst the other bunch=20
> (strictly) implement
> 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20
> - I fear not.
>=20
> =3D> Do you -REALLY- -REALLY- need backward compatibility?
>=20
> My vote's to just go with the 2916bis syntax throughout, and=20
> remove reference
> to the soon to be obsoleted syntax in sipping-164?
>=20
> BTW, will we see an up-issued version as -02 IS out of date=20
> and has some things
> that will/may/might change?
>=20
> all the best,
> Lawrence
> --=20
> --------------------------------------------------------------
> ---------
> Roke Manor Research : This information is provided "as is"=20
> and is not
> <mailto:[e-mail]>: intended to create any contractual or legal
> <tel:[phone]> : relationship.
>=20
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 08:06:56 -0500,1952;000000000001-00000b0f
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
08:06:56 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from harjus.eng.song.fi ([e-mail] =
[195.10.149.20])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FD6m6n021852
                for <[e-mail]>; Thu, 15 May 2003 08:06:48 -0500
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 =
(Debian))
                id 19GIRE-0000I8-00; Thu, 15 May 2003 16:06:24 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 16:06:24 +0300
To: "Peterson, Jon" <[e-mail]>
Cc: "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: =
<[e-mail]>
References: =
<[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
X-Spam-Status: No, hits=3D-28.6 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Peterson, Jon writes:

  > I don't
  > think it is too much to ask that SIP applications utilizing ENUM be =
generous
  > in what they receive with regard to enumservices - it just doesn't =
seem
  > costly to be backwards compatible with the original iteration of the =
ENUM
  > standard.

check, for example, with cisco and let me know when they accept enum
replies with both formats. today they don't which is a very big
problem.=20

-- juha

15-May-2003 08:18:18 -0500,3663;000000000001-00000b10
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
08:18:18 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FDIB6n021934
                for <[e-mail]>; Thu, 15 May 2003 08:18:11 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCWBB28675;
                Thu, 15 May 2003 08:32:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCVDB28603
                for <[e-mail]>; Thu, 15 May 2003 08:31:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07776
                for <[e-mail]>; Thu, 15 May 2003 09:03:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GIQS-00077W-00
                for [e-mail]; Thu, 15 May 2003 09:05:36 -0400
Received: from harjus.eng.song.fi ([195.10.149.20] ident=3Dmail)
                by ietf-mx with esmtp (Exim 4.12)
                id 19GIQR-00077T-00
                for [e-mail]; Thu, 15 May 2003 09:05:36 -0400
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 =
(Debian))
                id 19GIRE-0000I8-00; Thu, 15 May 2003 16:06:24 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 16:06:24 +0300
To: "Peterson, Jon" <[e-mail]>
Cc: "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: =
<[e-mail]>
References: =
<[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-28.6 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Peterson, Jon writes:

  > I don't
  > think it is too much to ask that SIP applications utilizing ENUM be =
generous
  > in what they receive with regard to enumservices - it just doesn't =
seem
  > costly to be backwards compatible with the original iteration of the =
ENUM
  > standard.

check, for example, with cisco and let me know when they accept enum
replies with both formats. today they don't which is a very big
problem.=20

-- juha
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 10:30:31 -0500,4982;000000000001-00000b11
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
10:30:31 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFUK6n022776
                for <[e-mail]>; Thu, 15 May 2003 10:30:21 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEi3B06874;
                Thu, 15 May 2003 10:44:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEheB06834
                for <[e-mail]>; Thu, 15 May 2003 10:43:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11951
                for <[e-mail]>; Thu, 15 May 2003 11:16:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GKUa-00003y-00
                for [e-mail]; Thu, 15 May 2003 11:18:00 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GKUa-00003v-00
                for [e-mail]; Thu, 15 May 2003 11:18:00 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service =
(5.5.2653.19)
                id <JZWGWL3J>; Thu, 15 May 2003 16:19:09 +0100
Received: from orion.roke.co.uk ([193.118.192.66]) by =
rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service =
Version 5.5.2653.13)
                id K0FN6Y56; Thu, 15 May 2003 16:19:06 +0100
From: "Conroy, Lawrence (SMTP)" <[e-mail]>
To: [e-mail]
Cc: "Peterson, Jon" <[e-mail]>,
      Juha Heinanen
                  <[e-mail]>
Mime-Version: 1.0
X-Sender: lwc@127.0.0.1
Message-Id: <[e-mail]>
Date: Thu, 15 May 2003 16:19:21 +0100
Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed"
Subject: [Sipping] e164 enumservice syntax support
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-6.3 required=3D5.0
                tests=3DSIGNATURE_LONG_DENSE
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Hi Folks,
      [renamed the thread to be more specific]
* "Backward compatibility". There seem to be several choices
            here: (i) allow only RFC2916 syntax
                          (ii) allow only rfc2916bis syntax
                          (iii) allow both
            The e164-02 seems (apart from the add on in section 1 and
            section 7) to tend towards the first option (notably in the
            last sentence of section 5.1). However, with the inclusions
            of these caveats, it now seems to be sort of going for the
            last option.
            I object to this as it means we are producing an RFC that
            allows (or RECOMMENDs) syntax that we KNOW will be obsoleted
            in the very near future (unless someone needs to let me in
            on a secret :).
            I assume that -e164 is going to reference the 2916bis RFC,
            so it will be dependent on this - this isn't going to appear
            before 2916bis gets through the process. As part of the release
            of 2916bis, it obsoletes 2916 in the same way that 3403 obsoleted
            2915. Thus -e164 WILL be referring to obsoleted documents and
            syntax. The current text does not deprecate this syntax, so the
            -02 version of the draft (i.e the one we're reviewing) is at
            least adrift from "normal" IETF practice (see RFC2026 =
ss4.2.4,...).

            Now...given that 2916bis and the other enum drafts don't allow
            such backwards compatibility, why have it here?
            If this is a reference to RFC760 ss 3.2, then liberal means
            general flexibility with syntax; IMHO, -e164 does not need a
            specific reference to a (soon to be) Historic document.
            As Juha points out, this DOES cause confusion. As before, my
            vote's for option (ii).

all the best,
      Lawrence
--=20
-----------------------------------------------------------------------
Roke Manor Research : This information is provided "as is" and is =
not
<mailto:[e-mail]>: intended to create any contractual or legal
<tel:[phone]> : relationship.
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 10:32:23 -0500,6463;000000000001-00000b12
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
10:32:23 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFWE6n022793
                for <[e-mail]>; Thu, 15 May 2003 10:32:14 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEbRB06086;
                Thu, 15 May 2003 10:37:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEadB05589
                for <[e-mail]>; Thu, 15 May 2003 10:36:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11866
                for <[e-mail]>; Thu, 15 May 2003 11:09:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GKNo-000029-00
                for [e-mail]; Thu, 15 May 2003 11:11:00 -0400
Received: from goalie.snowshore.com ([216.57.133.4] =
helo=3Dwebshield.office.snowshore.com)
                by ietf-mx with smtp (Exim 4.12)
                id 19GKNn-00001r-00
                for [e-mail]; Thu, 15 May 2003 11:10:59 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by =
webshield.office.snowshore.com via csmap=20
                  id 9970; Thu, 15 May 2003 11:14:46 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Subject: RE: [Sipping] conf: comments on =
draft-rosenberg-sipping-conferencing-framework-01
Date: Thu, 15 May 2003 11:11:34 -0400
Message-ID: =
<[e-mail]>
Thread-Topic: [Sipping] conf: comments on =
draft-rosenberg-sipping-conferencing-framework-01
Thread-Index: AcMKco2Qi9SqIWgYSg+Yf0l0fUHIuAQgNALQ
From: "Eric Burger" <[e-mail]>
To: "Jonathan Rosenberg" <[e-mail]>
Cc: "Sipping (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id =
h4FEadB05590
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.0 required=3D5.0
                tests=3DQUOTED_EMAIL_TEXT,QUOTE_TWICE_1,SUBJ_HAS_UNIQ_ID
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

My turn to apologize for being late. It's less than a month :-)

Most everything looks good. Some minor points in-line.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Thu, April 24, 2003 11:00 AM
> To: Eric Burger
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] conf: comments on
> draft-rosenberg-sipping-conferencing-framework-01
>=20
>=20
> My apologies for the delay in responding. Thanks for your comments.
> Responses inline.
>=20
> Eric Burger wrote:

[snip]

> > Section 3.1, 4th & 5th paragraphs The example URI
> > ("[e-mail]") would seem to contradict the
> > admonition that "a conference URI is never constructed or guessed =
by
> > a user." The key point is the conference URI is opaque. It could
> > mean something, or it could be a license plate. Requiring=20
> meaning is
> > BAD. Requiring obscuration is also BAD. Just leave it as opaque =
to
> > the framework.
>=20
> Having a URI with a mnemonic user part does not mean its no longer=20
> opaque to the system, no longer unique, or that the intent is=20
> for it to=20
> be guessed. For long lived conferences in particular, where=20
> there is a=20
> likelihood that someone will need to convey one over a phone, I see=20
> value in them being mnemonic.

I think we agree here. That is:
    1. There is value to having a mnemonic URI
    2. The URI is opaque to the protocol.

I was just pointing out that the text of the draft explicitly states =
the conference URI must not be a mnemonic (see quote above).

[snip]

> > Section 5.2.1 Is it worth mentioning a stateful application=20
> server as
> > a mechanism for running a conference?
>=20
> I don't understand. 5.2.1 is talking about adding users to a=20
> conference.=20
> What does that have to do with using an application server?

All INVITEs come from the application server. This means the =
application server is fully aware of the state of all call legs; can =
directly manipulate state, permissions, and media policy; and has the =
added bonus of making CPCP entirely unnecessary.

Given that the largest conference service bureaux in the world are on =
the order of a few tens of thousands of ports, I don't think the =
"application server doesn't scale like a proxy server" argument really =
holds.

[snip]

> > Section 5.4.2 and 5.4.3 I don't really get the difference between
> > these two examples.
>=20
> One of them uses CPCP to remove a user. This can be done by=20
> an automata.=20
> The other uses a web application to remove a user. THis can=20
> only be done=20
> by a user.
[snip]
> So, just because both SIP and CPCP can change the state of a=20
> conference,=20
> does not mean that they are the same protocol.
[snip]
> CPCP, being a data transaction protocol, would also allow you to=20
> directly query for the list. Just because there is this sliver of=20
> overlap does not mean that they are the same protocol.

A "sliver of overlap" is OK. A full set of overlap is not. Look at =
the draft, for just about every operation, the draft says, "Here is the =
way to do it with SIP, and here is the way to do it with CPCP." It may =
be my misreading, but it sounds like there is a lot of overlap.

[snip]

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 10:45:40 -0500,4735;000000000001-00000b13
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
10:45:40 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFjX6n022926
                for <[e-mail]>; Thu, 15 May 2003 10:45:33 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FF17B08175;
                Thu, 15 May 2003 11:01:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FF0KB08127
                for <[e-mail]>; Thu, 15 May 2003 11:00:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12426
                for <[e-mail]>; Thu, 15 May 2003 11:32:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GKki-0000Ax-00
                for [e-mail]; Thu, 15 May 2003 11:34:40 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GKkh-0000Au-00
                for [e-mail]; Thu, 15 May 2003 11:34:40 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service =
(5.5.2653.19)
                id <JZWGWLRJ>; Thu, 15 May 2003 16:35:49 +0100
Received: from orion.roke.co.uk ([193.118.192.66]) by =
rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service =
Version 5.5.2653.13)
                id K0FN6Y72; Thu, 15 May 2003 16:35:45 +0100
From: "Conroy, Lawrence (SMTP)" <[e-mail]>
To: [e-mail]
Cc: [e-mail], "Peterson, Jon" <[e-mail]>
Mime-Version: 1.0
X-Sender: lwc@127.0.0.1
Message-Id: <[e-mail]>
Date: Thu, 15 May 2003 16:35:59 +0100
Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed"
Subject: [Sipping] status of sipping-e164-02.txt//enum-sip-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-6.3 required=3D5.0
                tests=3DSIGNATURE_LONG_DENSE
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Hi folks,
      [Renamed thread to be more specific]
I'm not sure what the relationship is between this I-D and the
enum-sip I-D. I had wondered if the sipping- draft was going to
be superceded by the enum- draft, but there is a lot of useful
exemplary information in the sipping- draft that gives good
guidance to implementors. However, there are chunks of text in
this one that seem appropriate for a 'sip' enumservice definition
(e.g. section 5). Thus, what is the role for this draft; is it
informational, or standards-track, and if so, what is it defining,
given that there's also an enum-sip draft on the standards track?

=3D> IMHO, the sipping- draft does need to be re-addressed in light
of the 'sip' enumservices draft. At present there are overlaps in
several of the sections.


There are some more detailed issues, of course; notably in the
treatment of order and preference fields in section 6.3 - time has
moved on since this draft was issued, and it will need to be changed.

Also, as an aside, some of the statements that seem to mandate a
particular treatment do not include the usual SHALL, MUST, ..keywords.
For example, the penultimate sentence in the 2nd paragraph of section
5.3, which is an instruction, but does not have MUST (only 'is =
always').
This is followed immediately by a sentence that has a SHOULD. Choose.

This draft needs an up-issue, IMHO, and a decision on whether it is
standards-track or informational (it is silent on the matter).

all the best,
      Lawrence
--=20
-----------------------------------------------------------------------
Roke Manor Research : This information is provided "as is" and is =
not
<mailto:[e-mail]>: intended to create any contractual or legal
<tel:[phone]> : relationship.
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

14-May-2003 03:45:10 -0500,1777;000000000000-00000b14
Received: via dmail-2000(11) for +imap/INCOMING; Wed, 14 May 2003 =
03:45:10 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from albatross.tn.sw.ericsson.se =
(albatross-ext.wise.edt.ericsson.se [193.180.251.49])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E8j26n009678
                for <[e-mail]>; Wed, 14 May 2003 03:45:03 -0500
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se =
[153.88.254.120])
                by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with =
ESMTP id h4E8iX0Q004433;
                Wed, 14 May 2003 10:44:40 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service =
(5.5.2655.55)
                id <K765BATY>; Wed, 14 May 2003 10:43:20 +0200
Message-ID: =
<[e-mail]>
From: "Gonzalo Camarillo Gonzalez (LMF)"
                  <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Subject: Last Call for early media use cases
Date: Wed, 14 May 2003 09:12:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
X-Spam-Status: No, hits=3D0.0 required=3D5.0
                tests=3Dnone
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Folks,

in the last IETF meeting, we requested early media use cases that show =
the need of a "media coming" flag. So far, we have not received =
anything.

We intend to release a new version of the early media draft in a week =
or so. So, that is the time you have to send me your use cases.

Thanks,

Gonzalo

13-May-2003 23:02:49 -0500,1682;000000000001-00000b15
Received: via dmail-2000(11) for +imap/INCOMING; Tue, 13 May 2003 =
23:02:49 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com =
[171.71.177.237])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E42e6n007909
                for <[e-mail]>; Tue, 13 May 2003 23:02:40 -0500
Received: from mira-sjc5-b.cisco.com =
(IDENT:[e-mail] [171.71.163.14])
                by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4E41mDU022723;
                Tue, 13 May 2003 21:01:48 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
                by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
                with ESMTP id AHB69236;
                Tue, 13 May 2003 20:55:25 -0700 (PDT)
Date: Tue, 13 May 2003 21:02:01 -0700
Subject: WGLC for draft-ietf-sipping-e164-02.txt
Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: [e-mail], [e-mail], =
[e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
To: "'[e-mail]'" <[e-mail]>
From: Rohan Mahy <[e-mail]>
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=3D-2.1 required=3D5.0
                tests=3DUSER_AGENT_APPLEMAIL
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Hello Everyone,

I'd like to begin Working Group Last Call on:

http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt

this WGLC will end on June 13, 2003.

thanks,
-rohan

15-May-2003 13:40:44 -0500,6996;000000000001-00000b16
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
13:40:44 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FIeY6n024326
                for <[e-mail]>; Thu, 15 May 2003 13:40:35 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FHu3B22250;
                Thu, 15 May 2003 13:56:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FHtWB22224
                for <[e-mail]>; Thu, 15 May 2003 13:55:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17711
                for <[e-mail]>; Thu, 15 May 2003 14:27:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GNUD-0001MX-00
                for [e-mail]; Thu, 15 May 2003 14:29:49 -0400
Received: from willow.neustar.com ([209.173.53.84])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GNUC-0001MJ-00
                for [e-mail]; Thu, 15 May 2003 14:29:48 -0400
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com =
[10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4FIUQC06622;
                Thu, 15 May 2003 18:30:26 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service =
(5.5.2653.19)
                id <ZH2KCA6R>; Thu, 15 May 2003 14:32:20 -0400
Message-ID: =
<[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Conroy, Lawrence (SMTP)'" <[e-mail]>, [e-mail]
Cc: Juha Heinanen <[e-mail]>
Date: Thu, 15 May 2003 14:32:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Subject: [Sipping] RE: e164 enumservice syntax support
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-2.9 required=3D5.0
                tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)


I think we both agree that e164-02 specifies (iii), and I think e164-03
should as well. RF2026 does not mandate, as you seem to suggest, that
behavior for backwards compatibility is illegal in IETF standards. ENUM =
made
a decision (the reasons for which are outside the scope of our work in
SIPPING) to reverse its enumservice string format in order to break
automatic backwards compatibility, yes. This does not change the fact =
that
several ENUM implementations have been constructed in the three years =
since
the publication of RFC2916 that use the service field format of =
RFC2916.
Some implementations, no doubt, use those formats today.

There are numerous RFCs that contain guidance for dealing with
implementations that are compliant with older versions of a =
specification
(for example, the SIP RFC, RFC3261, contains numerous references to =
RFC2543
and quite a bit of behavior that is intended to foster backwards
compatibility) - this is in no way suspect or broken from a process
perspective. I don't think that ENUM clients acting on behalf of SIP
applications which retrieve usable resource records should be forced to
discard these records because the enumservice uses a standard format =
that
has been superannuated. Considering that there are probably =
implementations
out there in the field today that will return such records, I think =
that
would be a poor decision. I don't think any "confusion" that might =
result
from this has yet been substantiated. Nor do I think it is an unseemly
burden for implementers to support two variations on a seven-character
string instead of one.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[e-mail]]
> Sent: Thursday, May 15, 2003 8:19 AM
> To: [e-mail]
> Cc: Peterson, Jon; Juha Heinanen
> Subject: e164 enumservice syntax support
>=20
>=20
> Hi Folks,
> [renamed the thread to be more specific]
> * "Backward compatibility". There seem to be several choices
> here: (i) allow only RFC2916 syntax
> (ii) allow only rfc2916bis syntax
> (iii) allow both
> The e164-02 seems (apart from the add on in section 1 and
> section 7) to tend towards the first option (notably in the
> last sentence of section 5.1). However, with the inclusions
> of these caveats, it now seems to be sort of going for the
> last option.
> I object to this as it means we are producing an RFC that
> allows (or RECOMMENDs) syntax that we KNOW will be obsoleted
> in the very near future (unless someone needs to let me in
> on a secret :).
> I assume that -e164 is going to reference the 2916bis RFC,
> so it will be dependent on this - this isn't going to appear
> before 2916bis gets through the process. As part of the release
> of 2916bis, it obsoletes 2916 in the same way that 3403 =
obsoleted
> 2915. Thus -e164 WILL be referring to obsoleted documents and
> syntax. The current text does not deprecate this syntax, so the
> -02 version of the draft (i.e the one we're reviewing) is at
> least adrift from "normal" IETF practice (see RFC2026 =
ss4.2.4,...).
>=20
> Now...given that 2916bis and the other enum drafts don't allow
> such backwards compatibility, why have it here?
> If this is a reference to RFC760 ss 3.2, then liberal means
> general flexibility with syntax; IMHO, -e164 does not need a
> specific reference to a (soon to be) Historic document.
> As Juha points out, this DOES cause confusion. As before, my
> vote's for option (ii).
>=20
> all the best,
> Lawrence
> --=20
> --------------------------------------------------------------
> ---------
> Roke Manor Research : This information is provided "as is"=20
> and is not
> <mailto:[e-mail]>: intended to create any contractual or legal
> <tel:[phone]> : relationship.
>=20
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 14:19:44 -0500,6048;000000000001-00000b17
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
14:19:44 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FJJZ6n024599
                for <[e-mail]>; Thu, 15 May 2003 14:19:36 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FITJB24806;
                Thu, 15 May 2003 14:29:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FISoB24780
                for <[e-mail]>; Thu, 15 May 2003 14:28:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18731
                for <[e-mail]>; Thu, 15 May 2003 15:01:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GO0P-0001Zq-00
                for [e-mail]; Thu, 15 May 2003 15:03:05 -0400
Received: from willow.neustar.com ([209.173.53.84])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GO0P-0001Ze-00
                for [e-mail]; Thu, 15 May 2003 15:03:05 -0400
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com =
[10.31.13.11])
                by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4FJ3dC07292;
                Thu, 15 May 2003 19:03:39 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service =
(5.5.2653.19)
                id <ZH2KCB1F>; Thu, 15 May 2003 15:05:32 -0400
Message-ID: =
<[e-mail]>
From: "Peterson, Jon" <[e-mail]>
To: "'Conroy, Lawrence (SMTP)'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Date: Thu, 15 May 2003 15:05:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Subject: [Sipping] RE: status of sipping-e164-02.txt//enum-sip-00.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.5 required=3D5.0
                tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)


Unlike draft-ietf-enum-sip, draft-ietf-sipping-e164 exists to describe =
how
SIP implementations should handle E.164 numbers, which may appear in
contexts in which ENUM is impracticable or uninformative (such as =
gateway
location scenarios, cases in which there is no ENUM record =
corresponding to
a particular E.164 number, etc). As you may have noted, it is not an
enumservice definition, but it references and uses an enumservice =
definition
(see sipping-e164 reference [15]). While there are some overlaps =
between the
two drafts (draft-ietf-enum-sip, especially in Section 3, summarizes =
some of
the conclusions of sipping-e164), I don't feel these damage or devalue
either of the documents. That much said, as I revise this document in
response to last call comments, I'll try to seek out and remove any
unhelpful redundancy. Redundancy with rfc2916bis, which has become =
better
specified over time, is probably more likely, and I'll also keep an eye =
out
for that.

>=20
> There are some more detailed issues, of course; notably in the
> treatment of order and preference fields in section 6.3 - time has
> moved on since this draft was issued, and it will need to be changed.

Um, while I don't think the behaviorial recommendations would really =
change
(i.e. use one order when you author ENUM records and differentiate by
preference), I'd agree that 6.3 isn't so crucial, given that rfc2916bis =
now
has section 1.3. I could make 6.3 much shorter and less specific today;
prior versions of rfc2916bis had much less guidance about dealing with
order.

> Also, as an aside, some of the statements that seem to mandate a
> particular treatment do not include the usual SHALL, MUST, =
..keywords.
> For example, the penultimate sentence in the 2nd paragraph of section
> 5.3, which is an instruction, but does not have MUST (only 'is =
always').
> This is followed immediately by a sentence that has a SHOULD. Choose.
>=20

I think the "is always" in 5.3 is not an instruction - it's an =
observation.
The sentence following it is a normative instruction. Really, the "is
always" sentence asserted only that in RFC2916 (and in bis), this "is
always" how examples were constructed. That could be clearer, though, =
sure,
and it will be.

> This draft needs an up-issue, IMHO, and a decision on whether it is
> standards-track or informational (it is silent on the matter).

As I said, I'll be issuing a new revision, and I'll incorporate the =
comments
above. However, IETF documents do not declare their intended status, at
least as far as I know. sipping-e164 is not meant to be Informational - =
it
contains numerous normative guidelines, and was intended for PS.=20

Jon Peterson
NeuStar, Inc.

> all the best,
> Lawrence
> --=20
> --------------------------------------------------------------
> ---------
> Roke Manor Research : This information is provided "as is"=20
> and is not
> <mailto:[e-mail]>: intended to create any contractual or legal
> <tel:[phone]> : relationship.
>=20
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

15-May-2003 19:57:05 -0500,6437;000000000001-00000b18
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 =
19:57:05 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G0us6n026564
                for <[e-mail]>; Thu, 15 May 2003 19:56:55 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G0CHB15192;
                Thu, 15 May 2003 20:12:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G0BZB15165
                for <[e-mail]>; Thu, 15 May 2003 20:11:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28502
                for <[e-mail]>; Thu, 15 May 2003 20:43:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GTLk-0003DF-00
                for [e-mail]; Thu, 15 May 2003 20:45:28 -0400
Received: from auemail2.lucent.com ([192.11.223.163] =
helo=3Dauemail2.firewall.lucent.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19GTLe-0003DB-00
                for [e-mail]; Thu, 15 May 2003 20:45:22 -0400
Received: from uk0006exch001h.wins.lucent.com =
(h135-86-145-57.lucent.com [135.86.145.57])
                by auemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4G0jWV16172
                for <[e-mail]>; Thu, 15 May 2003 20:45:32 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service =
(5.5.2653.19)
                id <XNT1FAPC>; Fri, 16 May 2003 01:45:31 +0100
Message-ID: =
<[e-mail]>
From: "Drage, Keith (Keith)" <[e-mail]>
To: "'Conroy, Lawrence (SMTP)'" <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Cc: "'Peterson, Jon'" <[e-mail]>,
      "'Juha Heinanen'"
                  <[e-mail]>
Subject: RE: [Sipping] e164 enumservice syntax support
Date: Fri, 16 May 2003 01:45:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.2 required=3D5.0
                tests=3DQUOTED_EMAIL_TEXT
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Perhaps an appropriate AD can make a definitive statement on the future =
of RFC 2916.

It would appear to me that it is entirely inappropriate to have a =
reference in a new RFC to an RFC that is already obsolete. So is this =
the situation that will exist?

This is not the same case as when a revised RFC refers to the previous =
version of the same RFC. The appropriate place to cover that case is in =
rfc2916bis with respect to RFC 2916, rather than in the sipping e164 =
document. I understand that it does not do that.

regards

Keith

Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail]=20

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[e-mail]]
> Sent: 15 May 2003 16:19
> To: [e-mail]
> Cc: Peterson, Jon; Juha Heinanen
> Subject: [Sipping] e164 enumservice syntax support
>=20
>=20
> Hi Folks,
> [renamed the thread to be more specific]
> * "Backward compatibility". There seem to be several choices
> here: (i) allow only RFC2916 syntax
> (ii) allow only rfc2916bis syntax
> (iii) allow both
> The e164-02 seems (apart from the add on in section 1 and
> section 7) to tend towards the first option (notably in the
> last sentence of section 5.1). However, with the inclusions
> of these caveats, it now seems to be sort of going for the
> last option.
> I object to this as it means we are producing an RFC that
> allows (or RECOMMENDs) syntax that we KNOW will be obsoleted
> in the very near future (unless someone needs to let me in
> on a secret :).
> I assume that -e164 is going to reference the 2916bis RFC,
> so it will be dependent on this - this isn't going to appear
> before 2916bis gets through the process. As part of the release
> of 2916bis, it obsoletes 2916 in the same way that 3403=20
> obsoleted
> 2915. Thus -e164 WILL be referring to obsoleted documents and
> syntax. The current text does not deprecate this syntax, so the
> -02 version of the draft (i.e the one we're reviewing) is at
> least adrift from "normal" IETF practice (see RFC2026=20
> ss4.2.4,...).
>=20
> Now...given that 2916bis and the other enum drafts don't allow
> such backwards compatibility, why have it here?
> If this is a reference to RFC760 ss 3.2, then liberal means
> general flexibility with syntax; IMHO, -e164 does not need a
> specific reference to a (soon to be) Historic document.
> As Juha points out, this DOES cause confusion. As before, my
> vote's for option (ii).
>=20
> all the best,
> Lawrence
> --=20
> --------------------------------------------------------------
> ---------
> Roke Manor Research : This information is provided "as is"=20
> and is not
> <mailto:[e-mail]>: intended to create any contractual or legal
> <tel:[phone]> : relationship.
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>=20
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 04:18:50 -0500,3560;000000000001-00000b19
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
04:18:50 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Ia6n029955
                for <[e-mail]>; Fri, 16 May 2003 04:18:40 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8UEB23848;
                Fri, 16 May 2003 04:30:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8TLB23815
                for <[e-mail]>; Fri, 16 May 2003 04:29:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17053
                for <[e-mail]>; Fri, 16 May 2003 05:01:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Gb7X-0005QL-00
                for [e-mail]; Fri, 16 May 2003 05:03:19 -0400
Received: from smtp2.dataconnection.com ([192.91.191.8] =
helo=3Dmiles.dataconnection.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19Gb7S-0005QH-00
                for [e-mail]; Fri, 16 May 2003 05:03:14 -0400
Received: by miles.datcon.co.uk with Internet Mail Service =
(5.5.2656.59)
                id <K6J027T8>; Fri, 16 May 2003 10:03:42 +0100
Message-ID: <[e-mail]>
From: Nicole Johnson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 16 May 2003 10:03:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Subject: [Sipping] [Sipping]Questions on =
draft-ietf-sipping-connect-reuse-reqs-00
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D0.8 required=3D5.0
                tests=3DSUBJ_HAS_UNIQ_ID
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

I have a couple of questions about =
draft-ietf-sipping-connect-reuse-reqs-00.

1. Intended scope of alias parameter. =20

Is the aim of this draft to enable connections to be reused within a =
single
dialog, or across multiple dialogs, i.e. can an alias learned within =
the
scope of one dialog be used in another? Is the alias parameter valid =
on
out-of-dialog requests?

2. Target address fails to authenticate.

If a server receives a request containing the alias parameter and the =
target
address of the request fails authentication, how should the server =
react?
It could drop the message, respond to the target address with a "not
authorized" response, or continue processing the request as if the =
"alias"
parameter was not present. Is there a recommended behaviour?=20

Thanks,
Nicole
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 04:23:29 -0500,55379;000000000001-00000b1a
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
04:23:29 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9N86n030018
                for <[e-mail]>; Fri, 16 May 2003 04:23:08 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a6B24227;
                Fri, 16 May 2003 04:36:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E7ToB20927
                for <[e-mail]>; Wed, 14 May 2003 03:29:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08900
                for <[e-mail]>; Wed, 14 May 2003 04:02:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FrFq-0003aJ-00
                for [e-mail]; Wed, 14 May 2003 04:04:50 -0400
Received: from n171-18.deltathree.com ([208.170.171.18] =
helo=3Dexch-jlm2.deltathree.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19FrFo-0003aG-00
                for [e-mail]; Wed, 14 May 2003 04:04:49 -0400
Received: by n171-18.deltathree.com with Internet Mail Service =
(5.5.2653.19)
                id <KZH4XK3J>; Wed, 14 May 2003 11:05:19 +0300
Message-ID: =
<[e-mail]>
From: David Schwartz <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Date: Wed, 14 May 2003 11:05:18 +0300
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sipping] Re: [Sip-implementers] dtmf digits using INFO ... =
SIPauthors ...
  Can you answer please ?
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-11.2 required=3D5.0
                tests=3DASCII_FORM_ENTRY,EMAIL_ATTRIBUTION,HTML_20_30,HTML_MESSAGE,
                            ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)


Hi Rohan.

I would like to add to Nachum's comment.

Here at deltathree we have been using an IVR type system for about two =
years
now with originating sip devices contacting our network from many =
different
locations. For termination we are using Cisco Gateways that address the
double digit issue (as Nachum stated). What we have found is that in
locations that have very poor infrastructure (usually satellite) =
RFC2833 is
highly unreliable. In these locations where latency and packet loss are
high, and the traffic may be bursty in nature, the retransmission =
mechanism
associated with INFO requests assures the arrival of all the digits =
whereas
2833 is not providing us with the same completion rates.=20

When entering a PIN code for instance where the loss of even one digit =
is
destructive we have had higher success rates with INFO type solutions
(vegastream, audiocodes, etc,) than we have had with pure RFC2833 =
devices.
True there is a longer delay associated with this approach as each =
digit is
sent only after receiving a 200 response but the alternative is in many
cases not being able to enter the PIN at all.

David Schwartz

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tue, May 13, 2003 8:46 PM
To: [e-mail]
Subject: Sipping digest, Vol 1 #1017 - 4 msgs


Send Sipping mailing list submissions to
                [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
                https://www1.ietf.org/mailman/listinfo/sipping
or, via email, send a message with subject or body 'help' to
                [e-mail]

You can reach the person managing the list at
                [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sipping digest..."


Today's Topics:

      1. RE: Re: [Sip-implementors] dtmf digits using INFO ... SIPauthors =
...
Can you answer please ? (Nachum Frid)
      2. Re: Re: [Sip-implementors] dtmf digits using INFO ... SIPauthors =
...
Can you answer please ? (Rohan Mahy)
      3. RE: Re: [Sip-implementors] dtmf digits using INFO ... S
              IPauthors ... Can you answer please ? (Francois Audet)

--__--__--

Message: 1
Subject: RE: [Sipping] Re: [Sip-implementors] dtmf digits using INFO =
...
SIPauthors ... Can you answer please ?
Date: Tue, 13 May 2003 19:42:06 +0200
From: "Nachum Frid" <[e-mail]>
To: "Rohan Mahy" <[e-mail]>,
      "SIP Developer" <[e-mail]>
Cc: <[e-mail]>, "Attila Sipos" <[e-mail]>,
      <[e-mail]>, <[e-mail]>

              Rohan,
            =20
              In your draft you are describing the double DTMF problem:
              "
              Under this proposal, a User Agent MUST NOT send signaled digits =
or
                    telephone-events using the INFO method if the event was ever
                    represented as a tone (as media). Only signals originated as =
pure
                    signaling MAY generate an INFO method. Failure to heed this
                    requirement will result in double-detection of digits/events
            =20
              If INFO is used incorrectly by a pair of PSTN gateways (for =
example),
              the source gateway may detect a digit, send an INFO request =
which is
lost, and retransmit that request. The target gateway would send the
              original in-band tone to the PSTN when the audio media arrives, =
later
              when the INFO arrives, the target gateway would render the same =
tone
              again. It is quite likely that the INFO will arrive after the =
media
              tone has been played (especially if multiple intermediaries are
              involved); the same digit would be played out again and this =
will
              frequently cause systems in the PSTN to detect the same digit
              signaled twice."
            =20
            =20
            =20
              Most of the PSTN gateways we are familiar with (Cisco, =
AudioCodes)
will mute the DTMF signal, when they are configured to use out of band
DTMF(H.245 alphanumeric, or SIP INFO). Usually source gateway will =
detect
DTMF digit coming from the PSTN side and erase it from the voice stream =
not
relaying it to IP. Than, the INFO (or H.245) message is send to the =
target
gateway, which will regenerate the DTMF to the PSTN side, without =
playing
double digits. In H.323 it works already for few years.
            =20
              Nachum
            =20
            =20
              -----Original Message-----
From: Rohan Mahy [mailto:[e-mail]]=20
Sent: Tuesday, May 13, 2003 1:34 AM
To: SIP Developer
Cc: [e-mail]; Attila Sipos; [e-mail];
[e-mail]
Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO =
...
SIPauthors ... Can you answer please ?
            =20
              Hi Rohan,
            =20
              The main reason to not carry DTMF in SIP INFOs is that there is =
a
very =20
              good chance that you will get double-digits or otherwise =
corrupted =20
              digits because the signaling is not time-synchronized with the =
audio

              media. This issue is discussed in an expired draft which I =
wrote a =20
              long time ago, which I abandoned in favor of the work generated =
by
the =20
              app-interaction design team. At this point my draft is useful =
only in

              that it explains how double digits tend to occur.
            =20
              my expired draft:
            =20
              =
http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping-=20
              signaled-digits-01.html
            =20
              the app-interaction design team drafts:
            =20
=20
http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt=

              =
http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app-=20
              interact-reqs-03.txt
              =
http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info-=20
              00.txt
              =
http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app-=20
              interaction-framework-00.txt
            =20
            =20
              thanks,
              -rohan (Mahy)
            =20
            =20
              On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:
            =20
              > Hi All,
              >
              > I hate to say that but SIP community doesn't agree
              > or think that there are lots of use and requirement for =
carrying
              > DTMF Out-of-Band.
              >
              > Every month, I can see that someone asks the same question =
again
and =20
              > again
              > that how do we send DTMF via INFO and Out-Of-Band .
              >
              > 3pcc needs it, lots of service creation environment needs it =
and
              > doesn't it looks promising to have a way in SIP to do OOB
              > DTMF just like h245-alphanumeric in H.323.
              >
              > If we think of applications, then there are lots of them that =
I
can
              > count which doesn't care about the timing info carried by =
RFC2833.
              > And if we really care about timing, then carrying RFC2833 via
              > notify (Again OOB) is promising.
              >
              > I really do not understand if this is a political issue to not
promote
              > SIP INFO for carrying DTMF or if someone can justify it to me
              > that there is no use to carry DTMF OOB.
              >
              > SIP authors, can you answer why SIP INFO for carrying simple
              > DTMF is not a standard solution ?
              >
              > Thanks,
              > Rohan Kumar
              >
              >
              > ----- Original Message -----
              > From: "Attila Sipos" <[e-mail]>
              > To: <[e-mail]>; <[e-mail]>
              > Sent: Friday, May 09, 2003 9:50 AM
              > Subject: RE: [Sip-implementors] dtmf digits using INFO
              >
              >
              >>
              >> Hello Zsolt,
              >>
              >> I still don't think there is a fully-agreed
              >> standard. However, as much as I hate to say it,
              >> CISCO have their own proposed standard which some
              >> people (like us) interoperate with:
              >>
              >>
              > =
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/=20
              > 122newft/122
              >> t/122t11/ftinfo.htm
              >>
              >> Regards,
              >>
              >> Attila
              >>
              >> Attila Sipos
              >> Software Engineer
              >> <http://www.vegastream.com>
              >> VegaStream : A World of difference for your Integrated
Communications
              >>
              >> (jo napot kiv=E1nok)
              >>
              >>
              >>
              >>> -----Original Message-----
              >>> From: Rizsanyi Zsolt [mailto:[e-mail]]
              >>> Sent: 09 May 2003 13:41
              >>> To: [e-mail]
              >>> Subject: [Sip-implementors] dtmf digits using INFO
              >>>
              >>>
              >>> Hi!
              >>>
              >>> Could somebody refer me to a current standard or draft, on
              >>> how to send dtmf
              >>> digits using the INFO method?
              >>>
              >>> Thanks
              >>> Zsolt Rizsanyi
              >>>
              >>> _______________________________________________
              >>> Sip-implementors mailing list
              >>> [e-mail]
              >>> =
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
              >>>
              >>
              >> _______________________________________________
              >> Sip-implementors mailing list
              >> [e-mail]
              >> =
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
              >>
              > _______________________________________________
              > Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
              > This list is for NEW development of the application of SIP
              > Use [e-mail] for questions on current =
sip
              > Use [e-mail] for new developments of core SIP
            =20
            =20
              _______________________________________________
              Sip-implementors mailing list
              [e-mail]
              http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--__--__--

Message: 2
Date: Tue, 13 May 2003 09:56:06 -0700
Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO =
...
SIPauthors ... Can you answer please ?
Cc: "SIP Developer" <[e-mail]>, <[e-mail]>,
      "Attila Sipos" <[e-mail]>,
<[e-mail]>,
      <[e-mail]>
To: "Nachum Frid" <[e-mail]>
From: Rohan Mahy <[e-mail]>


On Tuesday, May 13, 2003, at 10:42 AM, Nachum Frid wrote:

> Rohan,
>
> In your draft you are describing the double DTMF problem:
> "
> Under this proposal, a User Agent MUST NOT send signaled =
digits =20
> or
> telephone-events using the INFO method if the event was =
ever
> represented as a tone (as media). Only signals originated =

> as pure
> signaling MAY generate an INFO method. Failure to heed =
this
> requirement will result in double-detection of =
digits/events
>
> If INFO is used incorrectly by a pair of PSTN gateways (for =20
> example),
> the source gateway may detect a digit, send an INFO request =20
> which is lost, and retransmit that request. The target gateway =
would

> send the
> original in-band tone to the PSTN when the audio media =
arrives, =20
> later
> when the INFO arrives, the target gateway would render the =
same =20
> tone
> again. It is quite likely that the INFO will arrive after the =
=20
> media
> tone has been played (especially if multiple intermediaries =
are
> involved); the same digit would be played out again and this =20
> will
> frequently cause systems in the PSTN to detect the same digit
> signaled twice."
>
>
>
> Most of the PSTN gateways we are familiar with (Cisco, =20
> AudioCodes) will mute the DTMF signal, when they are configured to =
use =20
> out of band DTMF(H.245 alphanumeric, or SIP INFO). Usually source =20
> gateway will detect DTMF digit coming from the PSTN side and erase it =
=20
> from the voice stream not relaying it to IP.

In my experience the muting/erasure is imprecise and imperfect at best. =
=20
    Frequently, by the time accurate detection occurs, a bit of tone has =

already leaked out. If you tune your DSP to be more aggressive at =20
removing tones, then you can get false positives and mute harmonics of =

speech. I could go on, but I think you get the idea. i have seen these =
=20
problems with Cisco H.323 gateways and AudioCodes gateways that a Cisco =
=20
aquisition OEMed, so you can't convince me the problem doesn't exist.

> Than, the INFO (or H.245) message is send to the target gateway, =20
> which will regenerate the DTMF to the PSTN side, without playing =20
> double digits. In H.323 it works already for few years.

It works poorly enough that the ITU added support for RFC 2833 in H.323 =
=20
v4 to combat this problem.

thanks,
-rohan


> Nachum
>
>
> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Tuesday, May 13, 2003 1:34 AM
> To: SIP Developer
> Cc: [e-mail]; Attila Sipos; [e-mail]; =
=20
> [e-mail]
> Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO =

> ... SIPauthors ... Can you answer please ?
>
> Hi Rohan,
>
> The main reason to not carry DTMF in SIP INFOs is that there =
is =20
> a very
> good chance that you will get double-digits or otherwise =20
> corrupted
> digits because the signaling is not time-synchronized with the =
=20
> audio
> media. This issue is discussed in an expired draft which I =20
> wrote a
> long time ago, which I abandoned in favor of the work =
generated =20
> by the
> app-interaction design team. At this point my draft is useful =

> only in
> that it explains how double digits tend to occur.
>
> my expired draft:
>
> =20
> http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping-
> signaled-digits-01.html
>
> the app-interaction design team drafts:
>
> =20
> http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-=20
> 01.txt
> =20
> http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app-
> interact-reqs-03.txt
> =20
> http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info-
> 00.txt
> =20
> http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app-
> interaction-framework-00.txt
>
>
> thanks,
> -rohan (Mahy)
>
>
> On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:
>
>> Hi All,
>>
>> I hate to say that but SIP community doesn't agree
>> or think that there are lots of use and requirement for carrying
>> DTMF Out-of-Band.
>>
>> Every month, I can see that someone asks the same question again and
>> again
>> that how do we send DTMF via INFO and Out-Of-Band .
>>
>> 3pcc needs it, lots of service creation environment needs it and
>> doesn't it looks promising to have a way in SIP to do OOB
>> DTMF just like h245-alphanumeric in H.323.
>>
>> If we think of applications, then there are lots of them that I can
>> count which doesn't care about the timing info carried by RFC2833.
>> And if we really care about timing, then carrying RFC2833 via
>> notify (Again OOB) is promising.
>>
>> I really do not understand if this is a political issue to not =
promote
>> SIP INFO for carrying DTMF or if someone can justify it to me
>> that there is no use to carry DTMF OOB.
>>
>> SIP authors, can you answer why SIP INFO for carrying simple
>> DTMF is not a standard solution ?
>>
>> Thanks,
>> Rohan Kumar
>>
>>
>> ----- Original Message -----
>> From: "Attila Sipos" <[e-mail]>
>> To: <[e-mail]>; <[e-mail]>
>> Sent: Friday, May 09, 2003 9:50 AM
>> Subject: RE: [Sip-implementors] dtmf digits using INFO
>>
>>
>>>
>>> Hello Zsolt,
>>>
>>> I still don't think there is a fully-agreed
>>> standard. However, as much as I hate to say it,
>>> CISCO have their own proposed standard which some
>>> people (like us) interoperate with:
>>>
>>>
>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/
>> 122newft/122
>>> t/122t11/ftinfo.htm
>>>
>>> Regards,
>>>
>>> Attila
>>>
>>> Attila Sipos
>>> Software Engineer
>>> <http://www.vegastream.com>
>>> VegaStream : A World of difference for your Integrated =
Communications
>>>
>>> (jo napot kiv=E1nok)
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rizsanyi Zsolt [mailto:[e-mail]]
>>>> Sent: 09 May 2003 13:41
>>>> To: [e-mail]
>>>> Subject: [Sip-implementors] dtmf digits using INFO
>>>>
>>>>
>>>> Hi!
>>>>
>>>> Could somebody refer me to a current standard or draft, on
>>>> how to send dtmf
>>>> digits using the INFO method?
>>>>
>>>> Thanks
>>>> Zsolt Rizsanyi
>>>>
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> [e-mail]
>>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [e-mail]
>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>> _______________________________________________
>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
>
>
> _______________________________________________
> Sip-implementors mailing list
> [e-mail]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


--__--__--

Message: 3
From: "Francois Audet" <[e-mail]>
To: "'Rohan Mahy'" <[e-mail]>, "'Nachum Frid'"
<[e-mail]>
Cc: "'SIP Developer'" <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>,
      "'Attila Sipos'" <[e-mail]>,
      "'[e-mail]'" =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Subject: RE: [Sipping] Re: [Sip-implementors] dtmf digits using INFO =
... S
                IPauthors ... Can you answer please ?
Date: Tue, 13 May 2003 11:20:30 -0700

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C3197C.55FF4E20
The main reason for adding RFC2833 support in H.323v4 (despite the fact t=
he
earlier version supported long tones out-of-band) were:

- Interoperability with systems that use RFC2833. (That means for example
SIP-to-H.323)

- IVR/Call center applications where time synchronization is necessary.
(This applies to SIP as well of course). For example, you could have a
"menu" item in a voice application where pressing a digit will cause a
recording to stop. You could end on somebody's mailbox, where pressing "9=
"
would terminate your recording. If you press 9 and the recording is stopp=
ed
a couple of second later because the signalling message took longer to
arrive, you could unwillingly record something you didn't want to record
(like an insult).=20

Of course this doesn't mean that you'd always need RFC2833 in-band (the
proof is that H.323 systems have been running for years), but there are
indeed difficulties with the current VoIP systems and IVR/Call
Center/Voicemail.

The main problem is the transistion from out-of-band to RFC2833.

> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]=20
> Sent: Tuesday, May 13, 2003 09:56
> To: Nachum Frid
> Cc: SIP Developer; [e-mail]; Attila Sipos;=20
> [e-mail]; [e-mail]
> Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits=20
> using INFO ... SIPauthors ... Can you answer please ?
>=20
>=20
>=20
> On Tuesday, May 13, 2003, at 10:42 AM, Nachum Frid wrote:
>=20
> > Rohan,
> >
> > In your draft you are describing the double DTMF problem:
> > "
> > Under this proposal, a User Agent MUST NOT send=20
> signaled digits
> > or
> > telephone-events using the INFO method if the=20
> event was ever
> > represented as a tone (as media). Only signals=20
> originated =20
> > as pure
> > signaling MAY generate an INFO method. Failure=20
> to heed this
> > requirement will result in double-detection of=20
> digits/events
> >
> > If INFO is used incorrectly by a pair of PSTN gateways (for
> > example),
> > the source gateway may detect a digit, send an INFO request =20
> > which is lost, and retransmit that request. The target=20
> gateway would =20
> > send the
> > original in-band tone to the PSTN when the audio=20
> media arrives, =20
> > later
> > when the INFO arrives, the target gateway would=20
> render the same =20
> > tone
> > again. It is quite likely that the INFO will arrive=20
> after the =20
> > media
> > tone has been played (especially if multiple=20
> intermediaries are
> > involved); the same digit would be played out again=20
> and this =20
> > will
> > frequently cause systems in the PSTN to detect the same digit
> > signaled twice."
> >
> >
> >
> > Most of the PSTN gateways we are familiar with (Cisco, =20
> > AudioCodes) will mute the DTMF signal, when they are=20
> configured to use =20
> > out of band DTMF(H.245 alphanumeric, or SIP INFO). Usually=20
> source =20
> > gateway will detect DTMF digit coming from the PSTN side=20
> and erase it =20
> > from the voice stream not relaying it to IP.
>=20
> In my experience the muting/erasure is imprecise and=20
> imperfect at best. =20
> Frequently, by the time accurate detection occurs, a bit of=20
> tone has =20
> already leaked out. If you tune your DSP to be more aggressive at =20
> removing tones, then you can get false positives and mute=20
> harmonics of =20
> speech. I could go on, but I think you get the idea. i have=20
> seen these =20
> problems with Cisco H.323 gateways and AudioCodes gateways=20
> that a Cisco =20
> aquisition OEMed, so you can't convince me the problem doesn't exist.
>=20
> > Than, the INFO (or H.245) message is send to the target gateway, =20
> > which will regenerate the DTMF to the PSTN side, without playing =20
> > double digits. In H.323 it works already for few years.
>=20
> It works poorly enough that the ITU added support for RFC=20
> 2833 in H.323 =20
> v4 to combat this problem.
>=20
> thanks,
> -rohan
>=20
>=20
> > Nachum
> >
> >
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[e-mail]]
> > Sent: Tuesday, May 13, 2003 1:34 AM
> > To: SIP Developer
> > Cc: [e-mail]; Attila Sipos;=20
> [e-mail]; =20
> > [e-mail]
> > Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits=20
> using INFO =20
> > ... SIPauthors ... Can you answer please ?
> >
> > Hi Rohan,
> >
> > The main reason to not carry DTMF in SIP INFOs is=20
> that there is =20
> > a very
> > good chance that you will get double-digits or otherwise =20
> > corrupted
> > digits because the signaling is not=20
> time-synchronized with the =20
> > audio
> > media. This issue is discussed in an expired draft which I =20
> > wrote a
> > long time ago, which I abandoned in favor of the=20
> work generated =20
> > by the
> > app-interaction design team. At this point my draft=20
> is useful =20
> > only in
> > that it explains how double digits tend to occur.
> >
> > my expired draft:
> >
> > =20
> > http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping-
> > signaled-digits-01.html
> >
> > the app-interaction design team drafts:
> >
> > =20
> > http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-=20
> > 01.txt
> > =20
> > http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app-
> > interact-reqs-03.txt
> > =20
> > http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info-
> > 00.txt
> > =20
> > http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app-
> > interaction-framework-00.txt
> >
> >
> > thanks,
> > -rohan (Mahy)
> >
> >
> > On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:
> >
> >> Hi All,
> >>
> >> I hate to say that but SIP community doesn't agree
> >> or think that there are lots of use and requirement for carrying
> >> DTMF Out-of-Band.
> >>
> >> Every month, I can see that someone asks the same question=20
> again and
> >> again
> >> that how do we send DTMF via INFO and Out-Of-Band .
> >>
> >> 3pcc needs it, lots of service creation environment needs it and
> >> doesn't it looks promising to have a way in SIP to do OOB
> >> DTMF just like h245-alphanumeric in H.323.
> >>
> >> If we think of applications, then there are lots of them=20
> that I can
> >> count which doesn't care about the timing info carried by RFC2833.
> >> And if we really care about timing, then carrying RFC2833 via
> >> notify (Again OOB) is promising.
> >>
> >> I really do not understand if this is a political issue to=20
> not promote
> >> SIP INFO for carrying DTMF or if someone can justify it to me
> >> that there is no use to carry DTMF OOB.
> >>
> >> SIP authors, can you answer why SIP INFO for carrying simple
> >> DTMF is not a standard solution ?
> >>
> >> Thanks,
> >> Rohan Kumar
> >>
> >>
> >> ----- Original Message -----
> >> From: "Attila Sipos" <[e-mail]>
> >> To: <[e-mail]>; <[e-mail]>
> >> Sent: Friday, May 09, 2003 9:50 AM
> >> Subject: RE: [Sip-implementors] dtmf digits using INFO
> >>
> >>
> >>>
> >>> Hello Zsolt,
> >>>
> >>> I still don't think there is a fully-agreed
> >>> standard. However, as much as I hate to say it,
> >>> CISCO have their own proposed standard which some
> >>> people (like us) interoperate with:
> >>>
> >>>
> >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/
> >> 122newft/122
> >>> t/122t11/ftinfo.htm
> >>>
> >>> Regards,
> >>>
> >>> Attila
> >>>
> >>> Attila Sipos
> >>> Software Engineer
> >>> <http://www.vegastream.com>
> >>> VegaStream : A World of difference for your Integrated=20
> Communications
> >>>
> >>> (jo napot kiv=E1nok)
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Rizsanyi Zsolt [mailto:[e-mail]]
> >>>> Sent: 09 May 2003 13:41
> >>>> To: [e-mail]
> >>>> Subject: [Sip-implementors] dtmf digits using INFO
> >>>>
> >>>>
> >>>> Hi!
> >>>>
> >>>> Could somebody refer me to a current standard or draft, on
> >>>> how to send dtmf
> >>>> digits using the INFO method?
> >>>>
> >>>> Thanks
> >>>> Zsolt Rizsanyi
> >>>>
> >>>> _______________________________________________
> >>>> Sip-implementors mailing list
> >>>> [e-mail]
> >>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >>>>
> >>>
> >>> _______________________________________________
> >>> Sip-implementors mailing list
> >>> [e-mail]
> >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >>>
> >> _______________________________________________
> >> Sipping mailing list =20
> https://www1.ietf.org/mailman/listinfo/sipp> ing
> >> This list=20
> is for NEW development of the application=20
> of SIP
> >> Use [e-mail] for questions on current sip
> >> Use [e-mail] for new developments of core SIP
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [e-mail]
> > =20
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

------_=3D_NextPart_001_01C3197C.55FF4E20
[Enclosed text/html ]
-----Original Message-----</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; From: Rohan Mahy [ HREF=3D3D"mailto:[e-mail]">mailto:[e-mail]]</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; Sent: Tuesday, May 13, 2003 1:34 =
AM</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; To: SIP Developer</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; Cc: [e-mail]; Attila Sipos; =3D
</FONT>
<BR><FONT SIZE=3D3D2>&gt; [e-mail];&nbsp; =
</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; [e-mail]</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; Subject: Re: [Sipping] Re: =3D
[Sip-implementors] dtmf digits </FONT>
<BR><FONT SIZE=3D3D2>&gt; using INFO&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; ... SIPauthors ... Can you answer please =
=3D
?</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
Hi Rohan,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
The main reason to not carry DTMF in SIP INFOs is </FONT>
<BR><FONT SIZE=3D3D2>&gt; that there is&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; a very</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
good chance that you will get double-digits or otherwise&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; corrupted</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
digits because the signaling is not </FONT>
<BR><FONT SIZE=3D3D2>&gt; time-synchronized with the&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; audio</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
media.&nbsp; This issue is discussed in an expired draft which I&nbsp; =
=3D
</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; wrote a</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
long time ago, which I abandoned in favor of the </FONT>
<BR><FONT SIZE=3D3D2>&gt; work generated&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; by the</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
app-interaction design team. At this point my draft </FONT>
<BR><FONT SIZE=3D3D2>&gt; is useful&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; only in</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
that it explains how double digits tend to occur.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
my expired draft:</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =3D
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; HREF=3D3D"http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipp=
in=3D
g-" =3D
TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/morgue/draft=
-m=3D
ahy-sipping-</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
signaled-digits-01.html</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
the app-interaction design team drafts:</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =3D
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-burger-sipping-k=
pm=3D
l-" =3D
TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-burger=
-s=3D
ipping-kpml- </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; 01.txt</FONT>
<BR><FONT SIZE=3D3D2>&gt; =3D
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-culpepper-sippin=
g-=3D
app-" =3D
TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-culpep=
pe=3D
r-sipping-app-</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
interact-reqs-03.txt</FONT>
<BR><FONT SIZE=3D3D2>&gt; =3D
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app=
-i=3D
nfo-" =3D
TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-jennin=
gs=3D
-sip-app-info-</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
00.txt</FONT>
<BR><FONT SIZE=3D3D2>&gt; =3D
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt; HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-rosenberg-sippin=
g-=3D
app-" =3D
TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-rosenb=
er=3D
g-sipping-app-</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
interaction-framework-00.txt</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
thanks,</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
-rohan (Mahy)</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Hi All,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; I hate to say that but SIP community =
=3D
doesn't agree</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; or think that there are lots of use =
=3D
and requirement for carrying</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; DTMF Out-of-Band.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Every month, I can see that someone =
=3D
asks the same question </FONT>
<BR><FONT SIZE=3D3D2>&gt; again and</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; again</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; that how do we send DTMF via INFO =
and =3D
Out-Of-Band .</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; 3pcc needs it, lots of service =3D
creation environment needs it and</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; doesn't it looks promising to have a =
=3D
way in SIP to do OOB</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; DTMF just like h245-alphanumeric in =
=3D
H.323.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; If we think of applications,&nbsp; =
=3D
then there are lots of them </FONT>
<BR><FONT SIZE=3D3D2>&gt; that I can</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; count which doesn't care about the =
=3D
timing info carried by RFC2833.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; And if we really care about timing, =
=3D
then carrying RFC2833 via</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; notify (Again OOB) is =3D
promising.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; I really do not understand if this =
is =3D
a political issue to </FONT>
<BR><FONT SIZE=3D3D2>&gt; not promote</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; SIP INFO for carrying DTMF or if =3D
someone can justify it to me</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; that there is no use to carry DTMF =
=3D
OOB.</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; SIP authors, can you answer why SIP =
=3D
INFO for carrying simple</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; DTMF is not a standard solution =3D
?</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Thanks,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Rohan Kumar</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; From: &quot;Attila Sipos&quot; =3D
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; To: &lt;[e-mail]&gt;; =3D
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Sent: Friday, May 09, 2003 9:50 =3D
AM</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Subject: RE: [Sip-implementors] dtmf =
=3D
digits using INFO</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Hello Zsolt,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; I still don't think there is a =
=3D
fully-agreed</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; standard.&nbsp; However, as much =
=3D
as I hate to say it,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; CISCO have their own proposed =
=3D
standard which some</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; people (like us) interoperate =
=3D
with:</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; HREF=3D3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios12=
2/=3D
" =3D
TARGET=3D3D"_blank">http://www.cisco.com/univercd/cc/td/doc/product/soft=
wa=3D
re/ios122/</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; 122newft/122</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; t/122t11/ftinfo.htm</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Regards,</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Attila</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Attila Sipos</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Software Engineer</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; &lt; HREF=3D3D"http://www.vegastream.com" =3D
TARGET=3D3D"_blank">http://www.vegastream.com&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; VegaStream : A World of =
difference =3D
for your Integrated </FONT>
<BR><FONT SIZE=3D3D2>&gt; Communications</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; (jo napot kiv=3DE1nok)</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;&gt; -----Original =3D
Message-----</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;&gt; From: Rizsanyi Zsolt [ HREF=3D3D"mailto:[e-mail]">mailto:[e-mail] A>=3D
]

> >>>> Sent: 09 May 2003 =
13:41

> >>>> To: =3D
[e-mail]

> >>>> Subject: [Sip-implementors] =
=3D
dtmf digits using INFO

> >>>>

> >>>>

> >>>> Hi!

> >>>>

> >>>> Could somebody refer me to a =
=3D
current standard or draft, on

> >>>> how to send dtmf

> >>>> digits using the INFO =3D
method?

> >>>>

> >>>> Thanks

> >>>> Zsolt Rizsanyi

> >>>>

> >>>> =3D
_______________________________________________

> >>>> Sip-implementors mailing =3D
list

> >>>> =3D
[e-mail]

> >>>> HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors=
" =3D
TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im=
pl=3D
ementors</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; =3D
_______________________________________________</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; Sip-implementors mailing =3D
list</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; =3D
[e-mail]</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt; HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors=
" =3D
TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im=
pl=3D
ementors</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; =3D
_______________________________________________</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Sipping mailing list&nbsp; </FONT>
<BR><FONT SIZE=3D3D2>&gt; HREF=3D3D"https://www1.ietf.org/mailman/listinf=3D
o/sipp" =3D
TARGET=3D3D"_blank">https://www1.ietf.org/mailman/listinfo/sipp&gt; =
=3D
ing</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; This list </FONT>
<BR><FONT SIZE=3D3D2>&gt; is for NEW development of the application =3D
</FONT>
<BR><FONT SIZE=3D3D2>&gt; of SIP</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Use [e-mail] =
=3D
for questions on current sip</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;&gt; Use [e-mail] for new =
developments =3D
of core SIP</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
_______________________________________________</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
Sip-implementors mailing list</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
[e-mail]</FONT>
<BR><FONT SIZE=3D3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
</FONT>
<BR><FONT SIZE=3D3D2>&gt; HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors=
" =3D
TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im=
pl=3D
ementors</FONT>
</P>
<BR>

<P><FONT =3D
SIZE=3D3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D3D2>Sipping mailing list&nbsp; HREF=3D3D"https://www1.ietf.org/mailman/listinfo/sipping" =3D
TARGET=3D3D"_blank">https://www1.ietf.org/mailman/listinfo/sipping</=
FO=3D
NT>
<BR><FONT SIZE=3D3D2>This list is for NEW development of the =
application =3D
of SIP</FONT>
<BR><FONT SIZE=3D3D2>Use [e-mail] for questions =
=3D
on current sip</FONT>
<BR><FONT SIZE=3D3D2>Use [e-mail] for new developments of core =3D
SIP</FONT>
</P>

</BODY>
</HTML>
------_=3D_NextPart_001_01C3197C.55FF4E20--


--__--__--

Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

End of Sipping Digest
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 04:25:56 -0500,8877;000000000000-00000b1b
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
04:25:56 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Pn6n030048
                for <[e-mail]>; Fri, 16 May 2003 04:25:50 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a2B24207;
                Fri, 16 May 2003 04:36:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DFSxB03323
                for <[e-mail]>; Tue, 13 May 2003 11:28:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18199;
                Tue, 13 May 2003 12:02:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19FcGK-0005Qv-00; Tue, 13 May 2003 12:04:20 -0400
Received: from tssg.wit.ie ([193.1.185.11] helo=3Dmail.tssg.org)
                by ietf-mx with esmtp (Exim 4.12)
                id 19FcGI-0005Qq-00; Tue, 13 May 2003 12:04:18 -0400
Received: from boolard (unknown [10.37.1.56])
                by mail.tssg.org (Postfix) with SMTP
                id 0C3131809A; Tue, 13 May 2003 17:05:54 +0100 (IST)
From: "Shane McCormack" <[e-mail]>
To: "Sipping@Ietf. Org" <[e-mail]>, "Sip@Ietf. Org" =
<[e-mail]>
Date: Tue, 13 May 2003 17:09:48 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
                boundary=3D"----=3D_NextPart_000_001F_01C31972.75B44360"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sipping] PIDF format for spatial location
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-5.5 required=3D5.0
                tests=3DHTML_60_70,HTML_MESSAGE,MSGID_GOOD_EXCHANGE
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This is a multi-part message in MIME format.

------=3D_NextPart_000_001F_01C31972.75B44360
Hi,

I have mailed the list before on this subject but I am still looking =
for a
bit more clarification on this subject. I need to retreive spatial =
location
in pidf format for work I am doing on my thesis.
I know that work is being done in the Geopriv working group on a format =
for
sending such information. Just as a matter of doing things correctly =
could
somebody with any knowledge help me in
by telling me the additional headers necessary, and any other thoughts =
so i
can put the correct information in my implementation and my thesis.

Thank you

Shane McCormack

Research Assistant,
TSSG, Confederation House,
Waterford Business Park, Cork Road,
Waterford, Co. Waterford.

Phone: [phone] Fax: [phone]
Mobile: [phone]
http://www.tssg.org
MSN: [e-mail]





------=3D_NextPart_000_001F_01C31972.75B44360
[Enclosed text/html ]
------=3D_NextPart_000_001F_01C31972.75B44360--

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 04:26:56 -0500,3564;000000000000-00000b1c
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
04:26:56 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Qn6n030064
                for <[e-mail]>; Fri, 16 May 2003 04:26:50 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a8B24247;
                Fri, 16 May 2003 04:36:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FDmNB02422
                for <[e-mail]>; Thu, 15 May 2003 09:48:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10580
                for <[e-mail]>; Thu, 15 May 2003 10:20:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GJd7-0007Wj-00
                for [e-mail]; Thu, 15 May 2003 10:22:45 -0400
Received: from smtp2.dataconnection.com ([192.91.191.8] =
helo=3Dmiles.dataconnection.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19GJd6-0007Wg-00
                for [e-mail]; Thu, 15 May 2003 10:22:44 -0400
Received: by miles.datcon.co.uk with Internet Mail Service =
(5.5.2656.59)
                id <K6J02YC8>; Thu, 15 May 2003 15:23:22 +0100
Message-ID: <[e-mail]>
From: Nicole Johnson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Thu, 15 May 2003 15:23:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
                charset=3D"iso-8859-1"
Subject: [Sipping] [Sipping]Questions on =
draft-ietf-sipping-connect-reuse-reqs-00
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D0.8 required=3D5.0
                tests=3DSUBJ_HAS_UNIQ_ID
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

I have a couple of questions about =
draft-ietf-sipping-connect-reuse-reqs-00.

1. Intended scope of alias parameter. =20

Is the aim of this draft to enable connections to be reused within a =
single
dialog, or across multiple dialogs, i.e. can an alias learned within =
the
scope of one dialog be used in another? Is the alias parameter valid =
on
out-of-dialog requests?

2. Target address fails to authenticate.

If a server receives a request containing the alias parameter and the =
target
address of the request fails authentication, how should the server =
react?
It could drop the message, respond to the target address with a "not
authorized" response, or continue processing the request as if the =
"alias"
parameter was not present. Is there a recommended behaviour?=20

Thanks,
Nicole


_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 06:43:16 -0500,5772;000000000000-00000b1d
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
06:43:16 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GBh96n030837
                for <[e-mail]>; Fri, 16 May 2003 06:43:09 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GAs8B32749;
                Fri, 16 May 2003 06:54:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GAolB32572
                for <[e-mail]>; Fri, 16 May 2003 06:50:47 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19539;
                Fri, 16 May 2003 07:22:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=3D"NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Date: Fri, 16 May 2003 07:22:48 -0400
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D2.2 required=3D5.0
                tests=3DMIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED
                version=3D2.52
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Session Initiation Proposal =
Investigation Working Group of the IETF.

                Title : SIP Generic Request History Capability =FB Requirements
                Author(s) : M. Barnes et al.
                Filename : draft-ietf-sipping-req-history-03.txt
                Pages : 12
                Date : 2003-5-15
=09
Many services that SIP is anticipated to support require the ability=20
to determine why and how the call arrived at a specific application. =20
Examples of such services include (but are not limited to) sessions=20
initiated to call centers via 'click to talk' SIP URLs on a web page,=20
'call history/logging' style services within intelligent 'call=20
management' software for SIP UAs and calls to voicemail servers and=20
call centers. While SIP implicitly provides the redirect/retarget=20
capabilities that enable calls to be routed to chosen applications,=20
there is currently no standard mechanism within SIP for communicating=20
the history of such a request. This 'request history' information=20
allows the receiving application to determine hints about how and why=20
the call arrived at the application/user. =20
This draft discusses the motivations in support of a mechanism for=20
recording the 'request history', and proposes detailed requirements=20
for such a generic 'request history' capability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-03.tx=
t

To remove yourself from the IETF Announcement list, send a message to=20
ietf-announce-request with the word unsubscribe in the body of the =
message.

Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
                "get draft-ietf-sipping-req-history-03.txt".

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


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

Send a message to:
                [e-mail].
In the body type:
                "FILE /internet-drafts/draft-ietf-sipping-req-history-03.txt".
=09
NOTE: The mail server at ietf.org can return the document in
                MIME-encoded form by using the "mpack" utility. To use this
                feature, insert the command "ENCODING mime" before the "FILE"
                command. To decode the response(s), you will need "munpack" or
                a MIME-compliant mail reader. Different MIME-compliant mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been split
                up into multiple messages), so check your local documentation on
                how to manipulate these messages.
                =09
                =09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
--OtherAccess
[Enclosed Message/External-body ]
--OtherAccess
[Enclosed Message/External-body 3D]
--OtherAccess--

--NextPart--


_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 08:38:45 -0500,3724;000000000000-00000b1e
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
08:38:45 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GDcY6n031679
                for <[e-mail]>; Fri, 16 May 2003 08:38:36 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCj5B07772;
                Fri, 16 May 2003 08:45:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCi2B07668
                for <[e-mail]>; Fri, 16 May 2003 08:44:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22115
                for <[e-mail]>; Fri, 16 May 2003 09:16:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Gf5u-0006dQ-00
                for [e-mail]; Fri, 16 May 2003 09:17:54 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Gf5t-0006bN-00
                for [e-mail]; Fri, 16 May 2003 09:17:53 -0400
Received: from cannon.cisco.com (IDENT:[e-mail] =
[161.44.118.24])
                by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GDITkL022547
                for <[e-mail]>; Fri, 16 May 2003 09:18:29 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
                by cannon.cisco.com (Mirapoint)
                with ESMTP id ABJ23730;
                Fri, 16 May 2003 09:27:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 May 2003 09:18:30 -0400
From: Paul Kyzivat <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) =
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-12.4 required=3D5.0
                tests=3DREFERENCES,USER_AGENT_MOZILLA_UA
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

I would like to take some issue with the voicemail example 10.2:

For this to work in any meaningful way, UA-A and UA-B must both use=20
UA-VM as their voicemail server. While this may be a reasonable=20
assumption in cases where both get phone service from the same =
provider,=20
it certainly doesn't work in all useful cases. For instance it doesn't=20
work if a call is forwarded from a business phone to a home phone.

I think at a minimum the limitations of this approach should be=20
mentioned. (Better would be to simply decide this is a poor application =

of History and remove the example.)

                Paul

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 09:09:08 -0500,5188;000000000000-00000b1f
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
09:09:08 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GE906n031903
                for <[e-mail]>; Fri, 16 May 2003 09:09:00 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GDK4B10469;
                Fri, 16 May 2003 09:20:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GDJaB10412
                for <[e-mail]>; Fri, 16 May 2003 09:19:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24699
                for <[e-mail]>; Fri, 16 May 2003 09:51:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GfeK-0007QD-00
                for [e-mail]; Fri, 16 May 2003 09:53:28 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GfeJ-0007Pg-00
                for [e-mail]; Fri, 16 May 2003 09:53:27 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com =
[47.103.120.51])
                by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4GDrtf06312;
                Fri, 16 May 2003 08:53:56 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <KRLHT1N9>; Fri, 16 May 2003 08:53:56 -0500
Message-ID: <[e-mail]=
.com>
From: "Mary Barnes" <[e-mail]>
To: "'Paul Kyzivat'" <[e-mail]>, [e-mail]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt
Date: Fri, 16 May 2003 08:53:54 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.1 required=3D5.0
                tests=3DORIGINAL_MESSAGE
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Paul,

Your point is well taken. There is a statement upfront around the
limitations of the examples in the appendix, but I should probably
re-iterate that in section 10 and explicitly highlight the limitations =
of
the scenario in 10.2 as to under which situations it might work like =
this.
I would like to keep this example, as I do think it is illustrative of =
where
one could use the request history capability. It wasn't at all the
intention to be a prescriptive description of Voicemail services (which =
is
some of the wording I have in the last section of paragraph 1, which I =
will
re-emphasize in the appendix). Although, for the forwarding to home, I =
would
still think that it's a local policy decision at the proxy as to which =
VM it
would go to and that if you had forwarded to home that it would still =
go to
your office VM, which I think is consistent with the wording under the
example. However, I can see that some of the wording likely ought to be
changed as it is being too prescriptive around the service (and perhaps =
your
primary point), so I will also reword the text under the example flow. =
=20

Thanks for your input,
Mary. =20

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]]
Sent: Friday, May 16, 2003 8:19 AM
To: [e-mail]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt


I would like to take some issue with the voicemail example 10.2:

For this to work in any meaningful way, UA-A and UA-B must both use=20
UA-VM as their voicemail server. While this may be a reasonable=20
assumption in cases where both get phone service from the same =
provider,=20
it certainly doesn't work in all useful cases. For instance it doesn't=20
work if a call is forwarded from a business phone to a home phone.

I think at a minimum the limitations of this approach should be=20
mentioned. (Better would be to simply decide this is a poor application =

of History and remove the example.)

                Paul

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 12:32:06 -0500,4240;000000000000-00000b20
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
12:32:06 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GHVu6n004105
                for <[e-mail]>; Fri, 16 May 2003 12:31:57 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GGkTB27686;
                Fri, 16 May 2003 12:46:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GGjxB27667
                for <[e-mail]>; Fri, 16 May 2003 12:45:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03724
                for <[e-mail]>; Fri, 16 May 2003 13:17:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Giry-0001U9-00
                for [e-mail]; Fri, 16 May 2003 13:19:46 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Girx-0001U1-00
                for [e-mail]; Fri, 16 May 2003 13:19:46 -0400
Received: from cannon.cisco.com (IDENT:[e-mail] =
[161.44.118.24])
                by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4GHKQJh022652;
                Fri, 16 May 2003 13:20:26 -0400 (EDT)
Received: from cisco.com ([161.44.79.220])
                by cannon.cisco.com (Mirapoint)
                with ESMTP id ABJ25991;
                Fri, 16 May 2003 13:29:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 May 2003 13:20:25 -0400
From: Paul Kyzivat <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) =
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mary Barnes <[e-mail]>
CC: [e-mail]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt
References: =
<[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-28.6 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)



Mary Barnes wrote:
>=20
> Although, for the forwarding to home, I would
> still think that it's a local policy decision at the proxy as to =
which VM it
> would go to and that if you had forwarded to home that it would still =
go to
> your office VM, which I think is consistent with the wording under =
the
> example.=20

Just to make sure we are making exactly the same point:

the example has the forwardee sending the request to the particular=20
voicemail server it deals with. Then that server is using the history=20
info to decide which of its mailboxes to use. In the office to home=20
case, home and office phones probably use different voicemail servers.=20
The voicemail server used at home will likely not contain a mailbox for =

the office address.

History just doesn't enter into a solution to this problem. Instead, =
the=20
home phone must not go to voicemail. It must fail back to the proxy for =

the office phone, which can then choose its own voicemail server and=20
mailbox.

                Paul

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

16-May-2003 17:14:49 -0500,4974;000000000001-00000b21
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 =
17:14:49 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GMEe6n008950
                for <[e-mail]>; Fri, 16 May 2003 17:14:41 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GLUTB14778;
                Fri, 16 May 2003 17:30:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GLTPB14724
                for <[e-mail]>; Fri, 16 May 2003 17:29:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11899
                for <[e-mail]>; Fri, 16 May 2003 18:00:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GnHw-0003Dx-00
                for [e-mail]; Fri, 16 May 2003 18:02:52 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
                by ietf-mx with esmtp (Exim 4.12)
                id 19GnHq-0003DX-00
                for [e-mail]; Fri, 16 May 2003 18:02:46 -0400
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com =
[47.103.120.51])
                by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4GM2lf26601;
                Fri, 16 May 2003 17:02:47 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <KRLHTS5X>; Fri, 16 May 2003 17:02:48 -0500
Message-ID: =
<[e-mail]>
From: "Mary Barnes" <[e-mail]>
To: "'Paul Kyzivat'" <[e-mail]>
Cc: [e-mail]
Subject: Example 10.2 - should we remove it? (was RE: [Sipping] I-D =
ACTIO
                N:draft-ietf-sipping-req-history-03.txt
Date: Fri, 16 May 2003 17:02:47 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-12.8 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Paul,

I agree for the scenario whereby there is a VM server at home, you =
likely
wouldn't need History-Info. This example, with the current =
introductory
wording, is clearly restricted to a single VM server in an enterprise
environment. So, perhaps your original suggestion to remove the =
example
altogether is well-taken. =20

Are there any other views? Everytime we've discussed this particular
example, the discussion has ratholed, so I don't want to digress into =
that,
but rather would like feedback on whether anyone has any problems with
removing this particular example? (We do have more flows in the =
solutions
document, as well, making them not nearly as useful as they were
originally). =20

Mary.=20

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]]
Sent: Friday, May 16, 2003 12:20 PM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: [e-mail]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt




Mary Barnes wrote:
>=20
> Although, for the forwarding to home, I would
> still think that it's a local policy decision at the proxy as to =
which VM
it
> would go to and that if you had forwarded to home that it would still =
go
to
> your office VM, which I think is consistent with the wording under =
the
> example.=20

Just to make sure we are making exactly the same point:

the example has the forwardee sending the request to the particular=20
voicemail server it deals with. Then that server is using the history=20
info to decide which of its mailboxes to use. In the office to home=20
case, home and office phones probably use different voicemail servers.=20
The voicemail server used at home will likely not contain a mailbox for =

the office address.

History just doesn't enter into a solution to this problem. Instead, =
the=20
home phone must not go to voicemail. It must fail back to the proxy for =

the office phone, which can then choose its own voicemail server and=20
mailbox.

                Paul

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 00:01:33 -0500,7574;000000000000-00000b22
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
00:01:33 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J51Q6n005977
                for <[e-mail]>; Mon, 19 May 2003 00:01:26 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J4HjB00434;
                Mon, 19 May 2003 00:17:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J48TB32631
                for <[e-mail]>; Mon, 19 May 2003 00:08:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25213;
                Mon, 19 May 2003 00:39:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19HcSG-0007AU-00; Mon, 19 May 2003 00:40:56 -0400
Received: from f81.law12.hotmail.com ([64.4.19.81] helo=3Dhotmail.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19HcSF-00079v-00; Mon, 19 May 2003 00:40:56 -0400
Received: from mail pickup service by hotmail.com with Microsoft =
SMTPSVC;
                  Sun, 18 May 2003 21:41:42 -0700
Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP;
                Mon, 19 May 2003 04:41:41 GMT
X-Originating-IP: [193.220.224.9]
X-Originating-Email: [[e-mail]]
From: "Rajarshi Chakraborty" <[e-mail]>
To: [e-mail], [e-mail], =
[e-mail],
      [e-mail]
Cc: [e-mail]
Date: Mon, 19 May 2003 04:41:41 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=3Dflowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 19 May 2003 04:41:42.0365 (UTC) =
FILETIME=3D[F1C4F8D0:01C31DC0]
Subject: [Sipping] SIP mobility in WLAN
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D0.4 required=3D5.0
                tests=3DMAILTO_TO_SPAM_ADDR
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Hi,

Where can I get call-flows for SIP session management in a wireless LAN =

(802.11)? 3GPP only addresses the issues for cellular networks. Or are =
they=20
too trivial to be addressed specially? I am specially interested in=20
situations of handoffs (in this case, the IP changes as soon as the =
host=20
shifts from the zone around one hotspot to another). Should SIP bother =
at=20
all to detect IP changes or should the control be completely outside =
SIP? I=20
mean should it be some other module that has the responsibility of =
informing=20
the SIP stack in the mobile host about the IP changes, so that the host =
may=20
then send a re-INVITE with a new SDP but the call still remains active?

regards
Rajarshi


Rajarshi Chakraborty
B-196, IIT Campus,
Kharagpur,
West Bengal, India
PIN-721302





----Original Message Follows----
From: "Drage, Keith (Keith)" <[e-mail]>
To: "'Ashish Naik'" <[e-mail]>, "Santharam, Arun [CC]"=20
<[e-mail]>, "Sip@Ietf. Org" <[e-mail]>
Subject: RE: [Sip] Session Mobility in SIP
Date: Thu, 8 May 2003 14:42:24 +0100

Your best starting point to see the architecture is 3GPP TS 23.228, =
with=20
reference to 3GPP TS 23.002 to see how these entities fit together into =
the=20
entire 3GPP architecture.

The SIP protocol application is covered in 3GPP TS 24.229 with example =
flows=20
in 3GPP TS 24.228.

These documents may be found at:

ftp://ftp.3gpp.org/Specs/latest/Rel-5/=20
<ftp://ftp.3gpp.org/Specs/latest/Rel-5/>

3GPP uses these specifications over GPRS to provide mobility.

There is a parallel set of 3GPP2 specifications, substantially of =
common=20
text, that uses the same architecture over mobile IP, instead of GPRS. =
These=20
documents are currently in 3GPP2 comment and review.

regards

Keith




Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail]

-----Original Message-----
From: Ashish Naik [mailto:[e-mail]]
Sent: 08 May 2003 06:23
To: Santharam, Arun [CC]; Sip@Ietf. Org
Subject: RE: [Sip] Session Mobility in SIP


ok. Is there any specific document on IETF and 3GPP that can explain =
how it=20
is being addressed ?


Ragards,
Ashish Naik
CoE Mobile Computing
-----------------------------------
Phone [phone] Ext 3070


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of =
Santharam,=20
Arun [CC]
Sent: Wednesday, April 09, 2003 9:42 PM
To: Ashish Naik; Sip@Ietf. Org
Subject: RE: [Sip] Session Mobility in SIP



Ashish,



Please find comments inline.



Thank you

arun



-----Original Message-----
From: Ashish Naik [mailto:[e-mail]]
Sent: Wednesday, April 09, 2003 4:01 AM
To: Sip@Ietf. Org
Subject: [Sip] Session Mobility in SIP



How is SIP going to address session mobility ? Is there any initiative =
taken=20
up for this ?



  > This has been addressed in 3GPP standards. Please refer to the 3GPP =
All=20
IP architecture specifications.



SIP is said to be a better alternative than Mobile IP. Can I have some=20
latest development document references ?





  > SIP is not going to replace Mobile IP. It is going to leverage =
Mobile IP=20
for session management in 3G wireless networks.





Regards,
Ashish Naik
-------------------
CoE Mobile Computing
Phone: [phone] Ext 3070




*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com




*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

_________________________________________________________________
Mobile, masti, magic! Cool ringtones & logos. =
http://www.msn.co.in/mobile/=20
Get noticed

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 02:41:28 -0500,2687;000000000001-00000b23
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
02:41:28 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from mail3.dynamicsoft.com ([63.113.44.69])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7fH6n006823
                for <[e-mail]>; Mon, 19 May 2003 02:41:17 -0500
Received: from dynamicsoft.com ([63.113.46.68])
                by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J7eMdh014224;
                Mon, 19 May 2003 03:40:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 03:40:17 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) =
Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juha Heinanen <[e-mail]>
CC: "Peterson, Jon" <[e-mail]>,
      "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
References: =
<[e-mail]> =
<[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=3D-31.9 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)



Juha Heinanen wrote:
> Peterson, Jon writes:
>=20
> > I don't
> > think it is too much to ask that SIP applications utilizing ENUM =
be generous
> > in what they receive with regard to enumservices - it just =
doesn't seem
> > costly to be backwards compatible with the original iteration of =
the ENUM
> > standard.
>=20
> check, for example, with cisco and let me know when they accept enum
> replies with both formats. today they don't which is a very big
> problem.=20

Sounds like a good reason to document that you should be supporting=20
both. I think recommending that has only benefits and no drawbacks.

-Jonathan R.

--=20
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist Parsippany, NJ 07054-2711
dynamicsoft
[e-mail] FAX: [phone]
http://www.jdrosen.net PHONE: [phone]
http://www.dynamicsoft.com

19-May-2003 02:51:23 -0500,4445;000000000000-00000b24
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
02:51:23 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7pC6n006874
                for <[e-mail]>; Mon, 19 May 2003 02:51:13 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J789B23721;
                Mon, 19 May 2003 03:08:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J77GB23160
                for <[e-mail]>; Mon, 19 May 2003 03:07:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10877
                for <[e-mail]>; Mon, 19 May 2003 03:37:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19HfFI-0000mB-00
                for [e-mail]; Mon, 19 May 2003 03:39:44 -0400
Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19HfFI-0000lf-00
                for [e-mail]; Mon, 19 May 2003 03:39:44 -0400
Received: from dynamicsoft.com ([63.113.46.68])
                by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J7eMdh014224;
                Mon, 19 May 2003 03:40:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 03:40:17 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) =
Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juha Heinanen <[e-mail]>
CC: "Peterson, Jon" <[e-mail]>,
      "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
References: =
<[e-mail]> =
<[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-37.7 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE,
                            USER_AGENT_MOZILLA_UA
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)



Juha Heinanen wrote:
> Peterson, Jon writes:
>=20
> > I don't
> > think it is too much to ask that SIP applications utilizing ENUM =
be generous
> > in what they receive with regard to enumservices - it just =
doesn't seem
> > costly to be backwards compatible with the original iteration of =
the ENUM
> > standard.
>=20
> check, for example, with cisco and let me know when they accept enum
> replies with both formats. today they don't which is a very big
> problem.=20

Sounds like a good reason to document that you should be supporting=20
both. I think recommending that has only benefits and no drawbacks.

-Jonathan R.

--=20
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist Parsippany, NJ 07054-2711
dynamicsoft
[e-mail] FAX: [phone]
http://www.jdrosen.net PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 02:53:54 -0500,2027;000000000001-00000b25
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
02:53:54 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from harjus.eng.song.fi ([e-mail] =
[195.10.149.20])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7rl6n006891
                for <[e-mail]>; Mon, 19 May 2003 02:53:48 -0500
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 =
(Debian))
                id 19HfSR-0000ev-00; Mon, 19 May 2003 10:53:19 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 10:53:19 +0300
To: Jonathan Rosenberg <[e-mail]>
Cc: "Peterson, Jon" <[e-mail]>,
      "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: <[e-mail]>
References: =
<[e-mail]>
                <[e-mail]>
                <[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
X-Spam-Status: No, hits=3D-28.6 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Jonathan Rosenberg writes:

  > Sounds like a good reason to document that you should be supporting=20
  > both. I think recommending that has only benefits and no drawbacks.

yes, we have way passed the point where the "old" service field format
need not be supported. because the "old" format must be supported for
ever, the question raises: why does it make sense to define the new
format at all.

-- juha

19-May-2003 03:04:05 -0500,3738;000000000001-00000b26
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
03:04:05 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J83x6n006999
                for <[e-mail]>; Mon, 19 May 2003 03:03:59 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7L8B24350;
                Mon, 19 May 2003 03:21:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7K1B24308
                for <[e-mail]>; Mon, 19 May 2003 03:20:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11178
                for <[e-mail]>; Mon, 19 May 2003 03:50:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19HfRd-0000rZ-00
                for [e-mail]; Mon, 19 May 2003 03:52:29 -0400
Received: from harjus.eng.song.fi ([195.10.149.20] ident=3Dmail)
                by ietf-mx with esmtp (Exim 4.12)
                id 19HfRc-0000rW-00
                for [e-mail]; Mon, 19 May 2003 03:52:28 -0400
Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 =
(Debian))
                id 19HfSR-0000ev-00; Mon, 19 May 2003 10:53:19 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 10:53:19 +0300
To: Jonathan Rosenberg <[e-mail]>
Cc: "Peterson, Jon" <[e-mail]>,
      "'Conroy, Lawrence (SMTP)'" <[e-mail]>, Rohan Mahy =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>, [e-mail],
      "'Dean Willis'" <[e-mail]>, =
[e-mail]
Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt
In-Reply-To: <[e-mail]>
References: =
<[e-mail]>
                <[e-mail]>
                <[e-mail]>
X-Mailer: VM 7.14 under Emacs 21.2.1
From: Juha Heinanen <[e-mail]>
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-28.6 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES,
                            USER_AGENT_VM
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

Jonathan Rosenberg writes:

  > Sounds like a good reason to document that you should be supporting=20
  > both. I think recommending that has only benefits and no drawbacks.

yes, we have way passed the point where the "old" service field format
need not be supported. because the "old" format must be supported for
ever, the question raises: why does it make sense to define the new
format at all.

-- juha
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 03:25:25 -0500,4676;000000000000-00000b27
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
03:25:25 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J8PH6n007134
                for <[e-mail]>; Mon, 19 May 2003 03:25:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7g4B26179;
                Mon, 19 May 2003 03:42:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7fhB26155
                for <[e-mail]>; Mon, 19 May 2003 03:41:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11580
                for <[e-mail]>; Mon, 19 May 2003 04:12:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hfmd-0000xi-00
                for [e-mail]; Mon, 19 May 2003 04:14:11 -0400
Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hfmc-0000xc-00
                for [e-mail]; Mon, 19 May 2003 04:14:10 -0400
Received: from dynamicsoft.com ([63.113.46.68])
                by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J8F1dh014248;
                Mon, 19 May 2003 04:15:01 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 04:14:55 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) =
Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Marjou Xavier <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: [Sipping] conf: comments on =
draft-rosenberg-sipping-conferenc
    ing-framework-01
References: <5B788FC2CAFBD6118BAE0030848B025C416CFC@LNN201E>
In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C416CFC@LNN201E>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-37.7 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE,
                            USER_AGENT_MOZILLA_UA
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

response inline.

Marjou Xavier wrote:
>>> Something is not clear to me : is CPCP really mandatory to
>>> perform something as "simple" as calling many recipients via a
>>> focus (adhoc conference).
>=20
>=20
>> In an ad-hoc conference, the focus resides with one of the
>> endpoints. Therefore, an internal interface can be used to
>> instruct the focus to call out to additional users. So, in the
>> case of ad-hoc, something as "simple" as mass invitation does not
>> require CPCP.
>=20
>=20
>>> With a centralized conference server, a client can use a series
>>> of REFER requests to bring new users into the conference. This
>>> is described in the document as a SIP mecahnism for adding
>>> users. However, for a large number of invitations, this is
>>> really inefficient, and thus a real control protocol like CPCP
>>> is needed.
>=20
>=20
> Is a CPCP body inside a SIP INVITE acceptable ? (I would like to
> avoid an additional round-trip delay for a CPCP request before the
> SIP request)

What additional round trip delay? If you use CPCP it would mean you=20
dont use refer.

-Jonathan R.

--=20
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist Parsippany, NJ 07054-2711
dynamicsoft
[e-mail] FAX: [phone]
http://www.jdrosen.net PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 03:39:50 -0500,6462;000000000001-00000b28
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
03:39:50 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J8dg6n007217
                for <[e-mail]>; Mon, 19 May 2003 03:39:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7v4B27074;
                Mon, 19 May 2003 03:57:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7uUB27035
                for <[e-mail]>; Mon, 19 May 2003 03:56:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12241
                for <[e-mail]>; Mon, 19 May 2003 04:27:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hg0w-00018i-00
                for [e-mail]; Mon, 19 May 2003 04:28:58 -0400
Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hg0v-00017s-00
                for [e-mail]; Mon, 19 May 2003 04:28:57 -0400
Received: from dynamicsoft.com ([63.113.46.68])
                by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J8Tmdh014255;
                Mon, 19 May 2003 04:29:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 04:29:42 -0400
From: Jonathan Rosenberg <[e-mail]>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) =
Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Burger <[e-mail]>
CC: "Sipping (E-mail)" <[e-mail]>
Subject: Re: [Sipping] conf: comments on =
draft-rosenberg-sipping-conferencing-framework-01
References: =
<[e-mail]>
In-Reply-To: =
<[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-37.5 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
                            QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,
                            SIGNATURE_LONG_SPARSE,SUBJ_HAS_UNIQ_ID,
                            USER_AGENT_MOZILLA_UA
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)



Eric Burger wrote:

>> Having a URI with a mnemonic user part does not mean its no
>> longer opaque to the system, no longer unique, or that the intent
>> is for it to be guessed. For long lived conferences in
>> particular, where there is a likelihood that someone will need to
>> convey one over a phone, I see value in them being mnemonic.
>=20
>=20
> I think we agree here. That is: 1. There is value to having a
> mnemonic URI 2. The URI is opaque to the protocol.
>=20
> I was just pointing out that the text of the draft explicitly
> states the conference URI must not be a mnemonic (see quote above).

I think the new text in sipping-00 is OK.

>=20
>=20
> [snip]
>=20
>=20
>>> Section 5.2.1 Is it worth mentioning a stateful application
>>=20
>> server as
>>=20
>>> a mechanism for running a conference?
>>=20
>> I don't understand. 5.2.1 is talking about adding users to a=20
>> conference. What does that have to do with using an application
>> server?
>=20
>=20
> All INVITEs come from the application server. This means the
> application server is fully aware of the state of all call legs;
> can directly manipulate state, permissions, and media policy; and
> has the added bonus of making CPCP entirely unnecessary.
>=20
> Given that the largest conference service bureaux in the world are
> on the order of a few tens of thousands of ports, I don't think the
> "application server doesn't scale like a proxy server" argument
> really holds.

I still dont see what this has to do with section 5.2.1.

>=20
> [snip]
>=20
>=20
>>> Section 5.4.2 and 5.4.3 I don't really get the difference
>>> between these two examples.
>>=20
>> One of them uses CPCP to remove a user. This can be done by an
>> automata. The other uses a web application to remove a user. THis
>> can only be done by a user.
>=20
> [snip]
>=20
>> So, just because both SIP and CPCP can change the state of a=20
>> conference, does not mean that they are the same protocol.
>=20
> [snip]
>=20
>> CPCP, being a data transaction protocol, would also allow you to
>> directly query for the list. Just because there is this sliver
>> of overlap does not mean that they are the same protocol.
>=20
>=20
> A "sliver of overlap" is OK. A full set of overlap is not. Look
> at the draft, for just about every operation, the draft says, "Here
> is the way to do it with SIP, and here is the way to do it with
> CPCP." It may be my misreading, but it sounds like there is a lot
> of overlap.

Thats because the framework is not touching on the breadth of CPCP,=20
which would also set general conference policy (like who is allowed to=20
join, who can moderate, name of the conference, etc.). Those=20
conference operations which are of the flavor "create this dialog" can=20
be done with SIP, but only those operations.

-Jonathan R.


--=20
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Scientist Parsippany, NJ 07054-2711
dynamicsoft
[e-mail] FAX: [phone]
http://www.jdrosen.net PHONE: [phone]
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 08:52:13 -0500,4806;000000000000-00000b29
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
08:52:13 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JDq56n009655
                for <[e-mail]>; Mon, 19 May 2003 08:52:05 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JD89B17585;
                Mon, 19 May 2003 09:08:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JD74B16741
                for <[e-mail]>; Mon, 19 May 2003 09:07:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20516
                for <[e-mail]>; Mon, 19 May 2003 09:37:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hkr7-0003SQ-00
                for [e-mail]; Mon, 19 May 2003 09:39:09 -0400
Received: from relay2.clb.oleane.net ([213.56.31.22])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hkr1-0003RO-00
                for [e-mail]; Mon, 19 May 2003 09:39:03 -0400
Received: from oleane ([194.250.212.114])=20
                by relay2.clb.oleane.net with SMTP id h4JDdFl4003480
                for <[e-mail]>; Mon, 19 May 2003 15:39:15 +0200
Message-ID: <10a201c31e0c$95aeaf40$[e-mail]>
From: "Peter Lewis" <[e-mail]>
To: <[e-mail]>
Date: Mon, 19 May 2003 15:43:09 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
                boundary=3D"----=3D_NextPart_000_109F_01C31E1D.58ECBAA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [Sipping] International SIP 2004
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D1.6 required=3D5.0
                tests=3DHTML_30_40,HTML_MESSAGE,RCVD_IN_UNCONFIRMED_DSBL
                version=3D2.52
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This is a multi-part message in MIME format.

------=3D_NextPart_000_109F_01C31E1D.58ECBAA0
International SIP 2004, January 20-23, Paris France

After a setback in 2002 over 2001, explained by the difficult economic =
context plaguing the telecom industry, International SIP 2003 clearly =
recaptured the interest of the VoIP community.=20
Don't miss the 2004 edition.

The call for papers dead line has been extendeed to June 15.
Please get all details at:
http://www.upperside.fr/sip2004/sip2004cfp.htm



------=3D_NextPart_000_109F_01C31E1D.58ECBAA0
[Enclosed text/html ]
------=3D_NextPart_000_109F_01C31E1D.58ECBAA0--

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 16:16:30 -0500,4773;000000000001-00000b2a
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
16:16:30 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com =
[171.71.177.237])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLGL6n012695
                for <[e-mail]>; Mon, 19 May 2003 16:16:22 -0500
Received: from cisco.com (sjc-vpn3-438.cisco.com [10.21.65.182])
                by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JLFVeS023172;
                Mon, 19 May 2003 14:15:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 17:15:28 -0400
From: Flemming Andreasen <[e-mail]>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gonzalo Camarillo Gonzalez (LMF)" =
<[e-mail]>
CC: "'[e-mail]'" <[e-mail]>,
      "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)" <[e-mail]>
Subject: Re: [Sipping] Last Call for early media use cases
References: =
<[e-mail]>
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=3D-22.8 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

I believe it is useful to have a flag that indicates the "early media =
is coming", which would suggest to the UAC that it probably should not =
be
generating local ringback. Motivation for such a flag is to avoid the =
potential race between generating local ringback and having in-band =
media
turning such local ringback off. It applies equally well to the =
intelligent SIP endpoint and the decomposed gateway, although it may be =
more obvious
for the decomposed gateway. You may argue, that signaling should be =
faster than media, that you can have a small delay in applying the =
local
ringback, etc, however they all amount to heuristics. Also, consider =
that the far-end side may be using silence suppression, and the =
potential for
the race to occur becomes greater. By having (and using) this flag, the =
race is avoided.


This brings me to another issue. So far, the ringback/early media/media =
discussion has mainly focused on having media received turning local
ringback off. A great deal of concern has been expressed with the =
robustness of this principle and I agree with this concern. It turns =
out we
already have an example that breaks this model, namely comedia which =
specifies that:

"Endpoints that specify direction:active MUST be prepared to receive on =
the ports from which they send. Once they learn the IP address and =
port of
their peer from the peer's SDP, they SHOULD immediately send some kind =
of media (even if just comfort noise) to each of these ports."

In other words, use of comedia may turn off local ringback. In general, =
NAT/firewall traversal incurs this problem as it may need to refresh
bindings/pinholes (as described in STUN) before a call has been =
answered, and there will probably be other cases too. This strongly =
suggests that
the current "local ringaback turned off by early media" design is =
simply too fragile. We could for example:
1. Have a way of determining/indicating that some early media packets =
should not override local ringback or whatever else might be going on =
(this
could potentially just be by convention, e.g. silence suppression =
packets should not affect local ringback, which would then be a =
sanctioned way of
doing RTP connectivity things without affecting early media)
2. Have a way of turning local ringback back on after it has been =
turned off due to receipt of early media (consider the case where =
forking lead to
multiple early dialogs, but just one early media stream, and all of a =
sudden that early media stream disappers).

It would be good if the early media draft could address these issues as =
well.

-- Flemming


"Gonzalo Camarillo Gonzalez (LMF)" wrote:

> Folks,
>
> in the last IETF meeting, we requested early media use cases that =
show the need of a "media coming" flag. So far, we have not received =
anything.
>
> We intend to release a new version of the early media draft in a week =
or so. So, that is the time you have to send me your use cases.
>
> Thanks,
>
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

19-May-2003 16:38:52 -0500,6480;000000000000-00000b2b
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
16:38:52 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLcj6n012866
                for <[e-mail]>; Mon, 19 May 2003 16:38:46 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JKh7B17807;
                Mon, 19 May 2003 16:43:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JKgdB17785
                for <[e-mail]>; Mon, 19 May 2003 16:42:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05910
                for <[e-mail]>; Mon, 19 May 2003 17:13:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hry6-0006W1-00
                for [e-mail]; Mon, 19 May 2003 17:14:50 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
                by ietf-mx with esmtp (Exim 4.12)
                id 19Hry5-0006VG-00
                for [e-mail]; Mon, 19 May 2003 17:14:49 -0400
Received: from cisco.com (sjc-vpn3-438.cisco.com [10.21.65.182])
                by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JLFVeS023172;
                Mon, 19 May 2003 14:15:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 19 May 2003 17:15:28 -0400
From: Flemming Andreasen <[e-mail]>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gonzalo Camarillo Gonzalez (LMF)" =
<[e-mail]>
CC: "'[e-mail]'" <[e-mail]>,
      "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)" <[e-mail]>
Subject: Re: [Sipping] Last Call for early media use cases
References: <[e-mail]=
csson.se>
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-22.8 required=3D5.0
                tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,
                            REPLY_WITH_QUOTES
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

I believe it is useful to have a flag that indicates the "early media =
is coming", which would suggest to the UAC that it probably should not =
be
generating local ringback. Motivation for such a flag is to avoid the =
potential race between generating local ringback and having in-band =
media
turning such local ringback off. It applies equally well to the =
intelligent SIP endpoint and the decomposed gateway, although it may be =
more obvious
for the decomposed gateway. You may argue, that signaling should be =
faster than media, that you can have a small delay in applying the =
local
ringback, etc, however they all amount to heuristics. Also, consider =
that the far-end side may be using silence suppression, and the =
potential for
the race to occur becomes greater. By having (and using) this flag, the =
race is avoided.


This brings me to another issue. So far, the ringback/early media/media =
discussion has mainly focused on having media received turning local
ringback off. A great deal of concern has been expressed with the =
robustness of this principle and I agree with this concern. It turns =
out we
already have an example that breaks this model, namely comedia which =
specifies that:

"Endpoints that specify direction:active MUST be prepared to receive on =
the ports from which they send. Once they learn the IP address and =
port of
their peer from the peer's SDP, they SHOULD immediately send some kind =
of media (even if just comfort noise) to each of these ports."

In other words, use of comedia may turn off local ringback. In general, =
NAT/firewall traversal incurs this problem as it may need to refresh
bindings/pinholes (as described in STUN) before a call has been =
answered, and there will probably be other cases too. This strongly =
suggests that
the current "local ringaback turned off by early media" design is =
simply too fragile. We could for example:
1. Have a way of determining/indicating that some early media packets =
should not override local ringback or whatever else might be going on =
(this
could potentially just be by convention, e.g. silence suppression =
packets should not affect local ringback, which would then be a =
sanctioned way of
doing RTP connectivity things without affecting early media)
2. Have a way of turning local ringback back on after it has been =
turned off due to receipt of early media (consider the case where =
forking lead to
multiple early dialogs, but just one early media stream, and all of a =
sudden that early media stream disappers).

It would be good if the early media draft could address these issues as =
well.

-- Flemming


"Gonzalo Camarillo Gonzalez (LMF)" wrote:

> Folks,
>
> in the last IETF meeting, we requested early media use cases that =
show the need of a "media coming" flag. So far, we have not received =
anything.
>
> We intend to release a new version of the early media draft in a week =
or so. So, that is the time you have to send me your use cases.
>
> Thanks,
>
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

19-May-2003 16:45:29 -0500,17410;000000000000-00000b2c
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
16:45:29 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com =
[192.11.223.161])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLjI6o012913
                (version=3DTLSv1/SSLv3 cipher=3DEDH-RSA-DES-CBC3-SHA bits=3D168 =
verify=3DNO)
                for <[e-mail]>; Mon, 19 May 2003 16:45:19 -0500
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com =
[135.1.23.83])
                by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4JLjBN01351
                for <[e-mail]>; Mon, 19 May 2003 17:45:11 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service =
(5.5.2653.19)
                id <K73LWMQN>; Mon, 19 May 2003 16:45:11 -0500
Message-ID: =
<[e-mail]>
From: "Ejzak, Richard P (Richard)" <[e-mail]>
To: "'Gonzalo Camarillo Gonzalez (LMF)'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Mon, 19 May 2003 16:45:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
                boundary=3D"----_=3D_NextPart_000_01C31E4F.EA121D72"
X-Spam-Status: No, hits=3D-3.1 required=3D5.0
                tests=3DORIGINAL_MESSAGE
                autolearn=3Dham version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_000_01C31E4F.EA121D72
Gonzalo,
Please excuse my tardiness in responding to your request for early =
media use cases. I believe the attachment includes an example =
configuration and call flow that clearly illustrates some problems that =
need to be solved with the existing SIP early media procedures.

Thanks,

Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Gonzalo Camarillo Gonzalez (LMF)
[mailto:[e-mail]]
Sent: Wednesday, May 14, 2003 2:13 AM
To: '[e-mail]'
Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
Subject: [Sipping] Last Call for early media use cases


Folks,

in the last IETF meeting, we requested early media use cases that show =
the need of a "media coming" flag. So far, we have not received =
anything.

We intend to release a new version of the early media draft in a week =
or so. So, that is the time you have to send me your use cases.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP


------_=3D_NextPart_000_01C31E4F.EA121D72
Early Media Use Case

The following figure is an example call flow highlighting a range of =
issues associated with control of early media. In this scenario, A and =
D are gateway controllers performing interworking with other networks =
using in-band call progress information, B is a network feature server =
performing two call forwarding procedures (C to D and then D to E), and =
C and E are SIP endpoints providing only out-of-band call progress =
information. B is required to behave as a B2BUA since gateways are =
known to have difficulties with SIP forking procedures, which would =
otherwise be required in this forwarding scenario for B to behave as a =
SIP proxy. C and E are shown performing delayed SDP negotiation, which =
may occur due to resource reservation delays at a mobile endpoint or =
for other reasons. The scenario also assumes the use of a SIP profile =
including the use of reliable provisional responses and preconditions, =
although PRACK transactions without SDP and other details are not =
shown. 181 responses may occur during the scenario to report =
forwarding, but are not shown since they do not affect the processing =
of early media. Cleanup of dialogs with C and D after forwarding using =
CANCELs and/or final responses is also not shown to limit clutter in =
the figure.


A B C D =
        E
|(1) INVITE sdp1 |(2) INVITE sdp1 | | =
        |
|----------------->|----------------->| | =
        |
|(4) 180 |(3) 180 | | =
        |
|<-----------------|<-----------------| | =
        |
| | | | =
        |
|(6) 183 sdp2 |(5) 183 sdp2 | | =
        |
|<-----------------|<-----------------| | =
        |
| | | | =
        |
| | |(7) INVITE(no SDP)| =
        |
| |------------------------------------>| =
        |
|(9) 183 | |(8) 183 sdp3 | =
        |
|<-----------------|<------------------------------------| =
        |
|(10) UPDATE sdp3 | | | =
        |
|<-----------------| | | =
        |
|(11) 200 OK sdp4 | |(12) PRACK sdp4 | =
        |
|----------------->|------------------------------------>| =
        |
| | |(13) 200 OK | =
        |
| |<------------------------------------| =
        |
| | | | =
        |
|(15) 180 | |(14) 180 | =
        |
|<-----------------|<------------------------------------| =
        |
| | | | =
        |
| | | |(16) =
INVITE(noSDP)|
| =
|------------------------------------------------------->|
|(18) 180 | | |(17) 180 =
        |
|<-----------------|<---------------------------------------------------=
----|
| | | | =
=3D
        |
|(20) 183 | | |(19) 183 sdp5 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(21) UPDATE sdp5 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(22) 200 OK sdp6 | | |(23) PRACK =
=3D
sdp6 |
|----------------->|----------------------------------------------------=
=3D
--->|
| | | |(24) 200 OK =
=3D
        |
| =
|<---------------------------------------------------=3D
----|
| | | | =
=3D
        |
|(26) 200 OK (INV) | | |(25) 200 OK =
=3D
(INV) |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(27) ACK | | |(28) ACK =
=3D
        |
|----------------->|----------------------------------------------------=
=3D
--->|


At message (4), gateway controller A begins playing local ringing to =
=3D
the originating party (not shown) to represent alerting at C (which =3D
provides only out-of-band call progress information). Some time later, =
=3D
when C is able to respond to the media offer in (2), it sends a 183 =3D
response with SDP (5) to B, which sends another 183 response with SDP =
=3D
(6) to A, completing SDP negotiation between A and C. This is the =3D
first case in which an early media issue arises. A must be prepared to =
=3D
override local ringing in the presence of in-band media to avoid the =
=3D
potential for media clipping at called party answer. To avoid =3D
premature termination of local ringing after (6), C must avoid sending =
=3D
any media until called party answer occurs. There should be a =3D
documented convention covering precisely what triggers the transition =
=3D
to in-band media - whether it be the existence of any RTP packets or =
=3D
the existence of media content in RTP packets above some noise =3D
threshold. The use of a noise threshold would allow RTP playout =3D
adjustments to occur prior to the transmission of any content, and is =
=3D
preferred.

At some point after (6), B performs forwarding from C to gateway =3D
controller D. D establishes new media at (8) and provides indication =
=3D
of called party alerting at (14). Following SDP offer/answer rules for =
=3D
reliable provisional responses in RFC 3262, RFC 3264 and RFC 3311, B =
=3D
separates sdp3 from (8) and sends the 183 and sdp3 to A in messages (9) =
=3D
and (10), respectively. This is the second case in which an early =3D
media issue arises. A has no basis to treat the media established with =
=3D
D in (10) and (11) any differently from the media established with C in =
=3D
(6). So A must rely on the presence of media (however this is defined) =
=3D
from D for A to stop playing local ringing and pass in-band call =3D
progress information from D to the calling party. If a noise threshold =
=3D
is used to identify the presence of in-band media and in-band call =3D
progress information from D begins with a protracted period of silence =
=3D
(noise), due to various possible network conditions, then A will =3D
continue to play local ringing even though silence would provide a more =
=3D
accurate indication of call progress.

When called party alerting indication comes from D at (14) and (15), A =
=3D
would presumably not change early media handling. Either in-band media =
=3D
was detected after (11) and local ringing was turned off in preference =
=3D
to in-band media, or no in-band media was detected after (11) and local =
=3D
ringing continued.

But in this scenario sometime after (15), B performs forwarding from D =
=3D
to endpoint E (which provides only out-of-band call progress =3D
information). The 180 from E (18) should immediately trigger the =3D
playing of local ringing at A, but A has no basis to distinguish the =
=3D
condition at (18) from the condition at (15). This is the third early =
=3D
media issue. A may be able to deduce from the absence of media from D =
=3D
that it should start generating local ringing at (18), but there =3D
appears to be no way to do this reliably. There are seconds of silence =
=3D
even during active in-band call progress information, so it's not clear =
=3D
what would trigger A to begin local ringing. The early media issues =
=3D
associated with the remainder of the scenario have already been =3D
discussed for messages (5) and (6).

Early Media Issues

Summarizing the three early media issues described in the preceding =3D
section:

1) A gateway playing local ringing in response to receipt of 180 should =
=3D
be prepared to give priority to media from the network at answer to =3D
avoid clipping. In-band media detection should be based on the =3D
presence of media content rather than just the presence of RTP packets =
=3D
to avoid waiting for RTP playout adjustments.

2) A similar technique to 1) could handle a transition from local =3D
ringing to in-band call progress information. Unfortunately, this =3D
technique is not robust in detecting this transition when the intended =
=3D
in-band information is silence. A gateway may replace periods of =3D
intended silence with local ringing.

3) A gateway passing in-band call progress information has difficulty =
=3D
identifying when it should transition to playing local ringing. Using =
=3D
the absence of in-band call progress information as a trigger to =3D
initiate local ringing is unreliable and subject to significant delay.

Potential Solution

Problems 2) and 3) in the preceding section can be readily solved with =
=3D
the introduction of one minor change: a new piece of information =3D
associated with any 18x response to indicate when in-band call progress =
=3D
information is available. The following figure uses the same scenario =
=3D
in the preceding use case but includes the use of the in-band (IB) =3D
indication in the 18x responses as appropriate. This solution is =3D
presented for illustrative purposes only. Other solutions also exist =
=3D
but all require the addition of some new information to one or more 18x =
=3D
responses.


A B C D =
=3D
        E
|(1) INVITE sdp1 |(2) INVITE sdp1 | | =
=3D
        |
|----------------->|----------------->| | =
=3D
        |
|(4) 180 |(3) 180 | | =
=3D
        |
|<-----------------|<-----------------| | =
=3D
        |
| | | | =
=3D
        |
|(6) 183 sdp2 |(5) 183 sdp2 | | =
=3D
        |
|<-----------------|<-----------------| | =
=3D
        |
| | | | =
=3D
        |
| | |(7) INVITE(no SDP)| =
=3D
        |
| |------------------------------------>| =
=3D
        |
|(9) 183 IB | |(8) 183 IB sdp3 | =
=3D
        |
|<-----------------|<------------------------------------| =
=3D
        |
|(10) UPDATE sdp3 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(11) 200 OK sdp4 | |(12) PRACK sdp4 | =
=3D
        |
|----------------->|------------------------------------>| =
=3D
        |
| | |(13) 200 OK | =
=3D
        |
| |<------------------------------------| =
=3D
        |
| | | | =
=3D
        |
|(15) 180 IB | |(14) 180 IB | =
=3D
        |
|<-----------------|<------------------------------------| =
=3D
        |
| | | | =
=3D
        |
| | | |(16) =3D
INVITE(noSDP)|
| =3D
|------------------------------------------------------->|
|(18) 180 | | |(17) 180 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
| | | | =
=3D
        |
|(20) 183 | | |(19) 183 sdp5 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(21) UPDATE sdp5 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(22) 200 OK sdp6 | | |(23) PRACK =
=3D
sdp6 |
|----------------->|----------------------------------------------------=
=3D
--->|
| | | |(24) 200 OK =
=3D
        |
| =3D
|<-------------------------------------------------------|
| | | | =
=3D
        |
|(26) 200 OK (INV) | | |(25) 200 OK =
=3D
(INV) |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(27) ACK | | |(28) ACK =
=3D
        |
|----------------->|----------------------------------------------------=
=3D
--->|


A interprets 183 (6) as an indication that local ringing should =3D
continue until called party media is detected since there is no IB =3D
indication. 183 IB (8) and 183 IB (9) cause A to stop local ringing in =
=3D
preference to in-band media. There is no possibility of missing =3D
intended periods of in-band silence. 180 IB (14) and 180 IB (15) =3D
clearly indicate to A that there is called party alerting but the =3D
in-band information should be passed to the calling party rather than =
=3D
local ringing. Finally, 180 (18) and 183 (20) clearly indicate that A =
=3D
should generate local ringing until called party answer or some other =
=3D
change in early media handling. This flow is identical to the original =
=3D
flow except for the addition of the IB indication to four of the =3D
provisional responses in (8), (9), (14) and (15).
------_=3D_NextPart_000_01C31E4F.EA121D72--

19-May-2003 16:57:07 -0500,19029;000000000001-00000b2d
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 =
16:57:07 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLuw6n012980
                for <[e-mail]>; Mon, 19 May 2003 16:56:59 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLDDB20826;
                Mon, 19 May 2003 17:13:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLCGB20775
                for <[e-mail]>; Mon, 19 May 2003 17:12:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06868
                for <[e-mail]>; Mon, 19 May 2003 17:42:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19HsQl-0006nj-00
                for [e-mail]; Mon, 19 May 2003 17:44:27 -0400
Received: from auemail1.lucent.com ([192.11.223.161] =
helo=3Dauemail1.firewall.lucent.com)
                by ietf-mx with esmtp (Exim 4.12)
                id 19HsQk-0006nU-00
                for [e-mail]; Mon, 19 May 2003 17:44:26 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com =
[135.1.23.83])
                by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4JLjBN01356
                for <[e-mail]>; Mon, 19 May 2003 17:45:11 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service =
(5.5.2653.19)
                id <K73LWMQN>; Mon, 19 May 2003 16:45:11 -0500
Message-ID: =
<[e-mail]>
From: "Ejzak, Richard P (Richard)" <[e-mail]>
To: "'Gonzalo Camarillo Gonzalez (LMF)'"
                  <[e-mail]>,
      "'[e-mail]'"
                  <[e-mail]>
Cc: "Jon Peterson (E-mail)" <[e-mail]>,
      "Rohan Mahy (E-mail)" <[e-mail]>,
      "Dean Willis (E-mail)"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Mon, 19 May 2003 16:45:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
                boundary=3D"----_=3D_NextPart_000_01C31E4F.EA121D72"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-3.1 required=3D5.0
                tests=3DORIGINAL_MESSAGE
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_000_01C31E4F.EA121D72
Gonzalo,
Please excuse my tardiness in responding to your request for early =
media use cases. I believe the attachment includes an example =
configuration and call flow that clearly illustrates some problems that =
need to be solved with the existing SIP early media procedures.

Thanks,

Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Gonzalo Camarillo Gonzalez (LMF)
[mailto:[e-mail]]
Sent: Wednesday, May 14, 2003 2:13 AM
To: '[e-mail]'
Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
Subject: [Sipping] Last Call for early media use cases


Folks,

in the last IETF meeting, we requested early media use cases that show =
the need of a "media coming" flag. So far, we have not received =
anything.

We intend to release a new version of the early media draft in a week =
or so. So, that is the time you have to send me your use cases.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP


------_=3D_NextPart_000_01C31E4F.EA121D72
Early Media Use Case

The following figure is an example call flow highlighting a range of =
issues associated with control of early media. In this scenario, A and =
D are gateway controllers performing interworking with other networks =
using in-band call progress information, B is a network feature server =
performing two call forwarding procedures (C to D and then D to E), and =
C and E are SIP endpoints providing only out-of-band call progress =
information. B is required to behave as a B2BUA since gateways are =
known to have difficulties with SIP forking procedures, which would =
otherwise be required in this forwarding scenario for B to behave as a =
SIP proxy. C and E are shown performing delayed SDP negotiation, which =
may occur due to resource reservation delays at a mobile endpoint or =
for other reasons. The scenario also assumes the use of a SIP profile =
including the use of reliable provisional responses and preconditions, =
although PRACK transactions without SDP and other details are not =
shown. 181 responses may occur during the scenario to report =
forwarding, but are not shown since they do not affect the processing =
of early media. Cleanup of dialogs with C and D after forwarding using =
CANCELs and/or final responses is also not shown to limit clutter in =
the figure.


A B C D =
        E
|(1) INVITE sdp1 |(2) INVITE sdp1 | | =
        |
|----------------->|----------------->| | =
        |
|(4) 180 |(3) 180 | | =
        |
|<-----------------|<-----------------| | =
        |
| | | | =
        |
|(6) 183 sdp2 |(5) 183 sdp2 | | =
        |
|<-----------------|<-----------------| | =
        |
| | | | =
        |
| | |(7) INVITE(no SDP)| =
        |
| |------------------------------------>| =
        |
|(9) 183 | |(8) 183 sdp3 | =
        |
|<-----------------|<------------------------------------| =
        |
|(10) UPDATE sdp3 | | | =
        |
|<-----------------| | | =
        |
|(11) 200 OK sdp4 | |(12) PRACK sdp4 | =
        |
|----------------->|------------------------------------>| =
        |
| | |(13) 200 OK | =
        |
| |<------------------------------------| =
        |
| | | | =
        |
|(15) 180 | |(14) 180 | =
        |
|<-----------------|<------------------------------------| =
        |
| | | | =
        |
| | | |(16) =
INVITE(noSDP)|
| =
|------------------------------------------------------->|
|(18) 180 | | |(17) 180 =
        |
|<-----------------|<---------------------------------------------------=
----|
| | | | =
=3D
        |
|(20) 183 | | |(19) 183 sdp5 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(21) UPDATE sdp5 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(22) 200 OK sdp6 | | |(23) PRACK =
=3D
sdp6 |
|----------------->|----------------------------------------------------=
=3D
--->|
| | | |(24) 200 OK =
=3D
        |
| =
|<---------------------------------------------------=3D
----|
| | | | =
=3D
        |
|(26) 200 OK (INV) | | |(25) 200 OK =
=3D
(INV) |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(27) ACK | | |(28) ACK =
=3D
        |
|----------------->|----------------------------------------------------=
=3D
--->|


At message (4), gateway controller A begins playing local ringing to =
=3D
the originating party (not shown) to represent alerting at C (which =3D
provides only out-of-band call progress information). Some time later, =
=3D
when C is able to respond to the media offer in (2), it sends a 183 =3D
response with SDP (5) to B, which sends another 183 response with SDP =
=3D
(6) to A, completing SDP negotiation between A and C. This is the =3D
first case in which an early media issue arises. A must be prepared to =
=3D
override local ringing in the presence of in-band media to avoid the =
=3D
potential for media clipping at called party answer. To avoid =3D
premature termination of local ringing after (6), C must avoid sending =
=3D
any media until called party answer occurs. There should be a =3D
documented convention covering precisely what triggers the transition =
=3D
to in-band media - whether it be the existence of any RTP packets or =
=3D
the existence of media content in RTP packets above some noise =3D
threshold. The use of a noise threshold would allow RTP playout =3D
adjustments to occur prior to the transmission of any content, and is =
=3D
preferred.

At some point after (6), B performs forwarding from C to gateway =3D
controller D. D establishes new media at (8) and provides indication =
=3D
of called party alerting at (14). Following SDP offer/answer rules for =
=3D
reliable provisional responses in RFC 3262, RFC 3264 and RFC 3311, B =
=3D
separates sdp3 from (8) and sends the 183 and sdp3 to A in messages (9) =
=3D
and (10), respectively. This is the second case in which an early =3D
media issue arises. A has no basis to treat the media established with =
=3D
D in (10) and (11) any differently from the media established with C in =
=3D
(6). So A must rely on the presence of media (however this is defined) =
=3D
from D for A to stop playing local ringing and pass in-band call =3D
progress information from D to the calling party. If a noise threshold =
=3D
is used to identify the presence of in-band media and in-band call =3D
progress information from D begins with a protracted period of silence =
=3D
(noise), due to various possible network conditions, then A will =3D
continue to play local ringing even though silence would provide a more =
=3D
accurate indication of call progress.

When called party alerting indication comes from D at (14) and (15), A =
=3D
would presumably not change early media handling. Either in-band media =
=3D
was detected after (11) and local ringing was turned off in preference =
=3D
to in-band media, or no in-band media was detected after (11) and local =
=3D
ringing continued.

But in this scenario sometime after (15), B performs forwarding from D =
=3D
to endpoint E (which provides only out-of-band call progress =3D
information). The 180 from E (18) should immediately trigger the =3D
playing of local ringing at A, but A has no basis to distinguish the =
=3D
condition at (18) from the condition at (15). This is the third early =
=3D
media issue. A may be able to deduce from the absence of media from D =
=3D
that it should start generating local ringing at (18), but there =3D
appears to be no way to do this reliably. There are seconds of silence =
=3D
even during active in-band call progress information, so it's not clear =
=3D
what would trigger A to begin local ringing. The early media issues =
=3D
associated with the remainder of the scenario have already been =3D
discussed for messages (5) and (6).

Early Media Issues

Summarizing the three early media issues described in the preceding =3D
section:

1) A gateway playing local ringing in response to receipt of 180 should =
=3D
be prepared to give priority to media from the network at answer to =3D
avoid clipping. In-band media detection should be based on the =3D
presence of media content rather than just the presence of RTP packets =
=3D
to avoid waiting for RTP playout adjustments.

2) A similar technique to 1) could handle a transition from local =3D
ringing to in-band call progress information. Unfortunately, this =3D
technique is not robust in detecting this transition when the intended =
=3D
in-band information is silence. A gateway may replace periods of =3D
intended silence with local ringing.

3) A gateway passing in-band call progress information has difficulty =
=3D
identifying when it should transition to playing local ringing. Using =
=3D
the absence of in-band call progress information as a trigger to =3D
initiate local ringing is unreliable and subject to significant delay.

Potential Solution

Problems 2) and 3) in the preceding section can be readily solved with =
=3D
the introduction of one minor change: a new piece of information =3D
associated with any 18x response to indicate when in-band call progress =
=3D
information is available. The following figure uses the same scenario =
=3D
in the preceding use case but includes the use of the in-band (IB) =3D
indication in the 18x responses as appropriate. This solution is =3D
presented for illustrative purposes only. Other solutions also exist =
=3D
but all require the addition of some new information to one or more 18x =
=3D
responses.


A B C D =
=3D
        E
|(1) INVITE sdp1 |(2) INVITE sdp1 | | =
=3D
        |
|----------------->|----------------->| | =
=3D
        |
|(4) 180 |(3) 180 | | =
=3D
        |
|<-----------------|<-----------------| | =
=3D
        |
| | | | =
=3D
        |
|(6) 183 sdp2 |(5) 183 sdp2 | | =
=3D
        |
|<-----------------|<-----------------| | =
=3D
        |
| | | | =
=3D
        |
| | |(7) INVITE(no SDP)| =
=3D
        |
| |------------------------------------>| =
=3D
        |
|(9) 183 IB | |(8) 183 IB sdp3 | =
=3D
        |
|<-----------------|<------------------------------------| =
=3D
        |
|(10) UPDATE sdp3 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(11) 200 OK sdp4 | |(12) PRACK sdp4 | =
=3D
        |
|----------------->|------------------------------------>| =
=3D
        |
| | |(13) 200 OK | =
=3D
        |
| |<------------------------------------| =
=3D
        |
| | | | =
=3D
        |
|(15) 180 IB | |(14) 180 IB | =
=3D
        |
|<-----------------|<------------------------------------| =
=3D
        |
| | | | =
=3D
        |
| | | |(16) =3D
INVITE(noSDP)|
| =3D
|------------------------------------------------------->|
|(18) 180 | | |(17) 180 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
| | | | =
=3D
        |
|(20) 183 | | |(19) 183 sdp5 =
=3D
        |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(21) UPDATE sdp5 | | | =
=3D
        |
|<-----------------| | | =
=3D
        |
|(22) 200 OK sdp6 | | |(23) PRACK =
=3D
sdp6 |
|----------------->|----------------------------------------------------=
=3D
--->|
| | | |(24) 200 OK =
=3D
        |
| =3D
|<-------------------------------------------------------|
| | | | =
=3D
        |
|(26) 200 OK (INV) | | |(25) 200 OK =
=3D
(INV) |
|<-----------------|<---------------------------------------------------=
=3D
----|
|(27) ACK | | |(28) ACK =
=3D
        |
|----------------->|----------------------------------------------------=
=3D
--->|


A interprets 183 (6) as an indication that local ringing should =3D
continue until called party media is detected since there is no IB =3D
indication. 183 IB (8) and 183 IB (9) cause A to stop local ringing in =
=3D
preference to in-band media. There is no possibility of missing =3D
intended periods of in-band silence. 180 IB (14) and 180 IB (15) =3D
clearly indicate to A that there is called party alerting but the =3D
in-band information should be passed to the calling party rather than =
=3D
local ringing. Finally, 180 (18) and 183 (20) clearly indicate that A =
=3D
should generate local ringing until called party answer or some other =
=3D
change in early media handling. This flow is identical to the original =
=3D
flow except for the addition of the IB indication to four of the =3D
provisional responses in (8), (9), (14) and (15).
------_=3D_NextPart_000_01C31E4F.EA121D72--
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP

20-May-2003 12:33:45 -0500,13291;000000000000-00000000
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 20 May 2003 =
12:33:45 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com =
[47.103.122.112])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4KHXb6n020978
                for <[e-mail]>; Tue, 20 May 2003 12:33:38 -0500
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com =
[47.81.138.28])
                by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4KHWSB10417;
                Tue, 20 May 2003 12:32:28 -0500 (CDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <LGT1L9NV>; Tue, 20 May 2003 10:32:28 -0700
Message-ID: =
<[e-mail]>
From: "Francois Audet" <[e-mail]>
To: "'Ejzak, Richard P (Richard)'" <[e-mail]>,
      "'Gonzalo Camarillo Gonzalez (LMF)'" =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Cc: "'Jon Peterson (E-mail)'" <[e-mail]>,
      "'Rohan Mahy (E-mail)'" <[e-mail]>,
      "'Dean Willis (E-mail)'"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Tue, 20 May 2003 10:32:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
                boundary=3D"----_=3D_NextPart_001_01C31EF5.C4F625B4"
X-Spam-Status: No, hits=3D-1.0 required=3D5.0
                tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C31EF5.C4F625B4
Thanks Richard, this is exactly one of the scenario I had in mind.

Now let's look at a different but very similar scenario (which is the
one that worries me most).

Assume the same exact call flows, but where the calls to C, D and
E are not done in sequence, but in parrallel (i.e., parallel forking).

From A's perspective, the scenario is exactly the same except that it
will receive the provisional responses from B, C, D and E in random
order, and much closer together. Let's assume that they arrive in the
following order (E, C, D), milliseconds apart.

It wouldn't make sense to change the ringing patterns "sequentially"
because they are not sequenced, but parallel. With the current proposal
(and no means to distinguish between parrallel forked calls and=20
sequential calls), we would end-up with D's ringing (out-of-band) and=20
E's answer. If D was busy (in-band), the user would hear "busy" tone=20
followed by an answer, which is not acceptable.

Two solutions exist for that problem:
- That ALL forking entities be B2BUAs and shield this problem from the =
UAs.
    If there is even just one forking proxy out there (making calls in=20
    parallel), we will get the problem. I'm sceptical that we can =
convince
    the whole world NOT to use forking proxies to make parallel calls.
- That forking proxies tag along a "parrallel forking" indication that=20
    will be provided to the called UAs. This indication will tell the UA =
that=20
    in-band ringing (or other tones) in early media shall NOT be used
    because it is useless (early media for answer of course would still =
be
    valid). (It may make sense also to let the UA sending the original =
invite
    know about the forking so it can provide appropriate treatment for =
the
    user: a tone, or display indication).

The second solution is in my opinion the best. And it would be =
compatible
with your proposal for sequential forwarding. Proxies (or B2BUAs) doing
sequential forwarding would NOT put this "parallel forking" indication.
Your proposed in-band call progress indication would solve the problem=20
nicely.

Proxies (or B2BUAs) doing parralel forking would put the "parallel =
forking"
indication. This would prohibit the UAs receiving the INVITE to=20
do in-band call progress tones (i.e., they wouldn't be allowed to =
include
your in-band call progress indication).=20

In combination, the "in-band call progress indication" and the =
"parralel
forking indiction" would solve all the scenarios that were worrying me.

> -----Original Message-----
> From: Ejzak, Richard P (Richard) [mailto:[e-mail]]=20
> Sent: Monday, May 19, 2003 14:45
> To: 'Gonzalo Camarillo Gonzalez (LMF)'; '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: RE: [Sipping] Last Call for early media use cases
>=20
>=20
> Gonzalo,
> Please excuse my tardiness in responding to your request for=20
> early media use cases. I believe the attachment includes an=20
> example configuration and call flow that clearly illustrates=20
> some problems that need to be solved with the existing SIP=20
> early media procedures.
>=20
> Thanks,
>=20
> Richard Ejzak
> Lucent Technologies
>=20
> -----Original Message-----
> From: Gonzalo Camarillo Gonzalez (LMF)=20
> [mailto:[e-mail]]
> Sent: Wednesday,=20
> May 14, 2003 2:13 AM
> To: '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: [Sipping] Last Call for early media use cases
>=20
>=20
> Folks,
>=20
> in the last IETF meeting, we requested early media use cases=20
> that show the need of a "media coming" flag. So far, we have=20
> not received anything.
>=20
> We intend to release a new version of the early media draft=20
> in a week or so. So, that is the time you have to send me=20
> your use cases.
>=20
> Thanks,
>=20
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current=20
> sip Use [e-mail] for new developments of core SIP
>=20
>=20

------_=3D_NextPart_001_01C31EF5.C4F625B4
[Enclosed text/html ]
------_=3D_NextPart_001_01C31EF5.C4F625B4--

20-May-2003 12:55:38 -0500,14963;000000000000-00000000
Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 20 May 2003 =
12:55:38 -0500 (CDT)
Return-Path: <[e-mail]>
Received: from www1.ietf.org (ietf.org [132.151.1.19])
                by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4KHtS6n021124
                for <[e-mail]>; Tue, 20 May 2003 12:55:29 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KH1GB18099;
                Tue, 20 May 2003 13:01:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
                by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KH05B18037
                for <[e-mail]>; Tue, 20 May 2003 13:00:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
                by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22314
                for <[e-mail]>; Tue, 20 May 2003 13:33:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
                by ietf-mx with esmtp (Exim 4.12)
                id 19IAxq-000764-00
                for [e-mail]; Tue, 20 May 2003 13:31:50 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
                by ietf-mx with esmtp (Exim 4.12)
                id 19IAxq-000760-00
                for [e-mail]; Tue, 20 May 2003 13:31:50 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com =
[47.81.138.28])
                by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP =
id h4KHWSB10417;
                Tue, 20 May 2003 12:32:28 -0500 (CDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service =
(5.5.2653.19)
                id <LGT1L9NV>; Tue, 20 May 2003 10:32:28 -0700
Message-ID: =
<[e-mail]>
From: "Francois Audet" <[e-mail]>
To: "'Ejzak, Richard P (Richard)'" <[e-mail]>,
      "'Gonzalo Camarillo Gonzalez (LMF)'" =
<[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Cc: "'Jon Peterson (E-mail)'" <[e-mail]>,
      "'Rohan Mahy (E-mail)'" <[e-mail]>,
      "'Dean Willis (E-mail)'"
                  <[e-mail]>
Subject: RE: [Sipping] Last Call for early media use cases
Date: Tue, 20 May 2003 10:32:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
                boundary=3D"----_=3D_NextPart_001_01C31EF5.C4F625B4"
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dunsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=3Dhelp>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
                <mailto:[e-mail]?subject=3Dsubscribe>
X-Spam-Status: No, hits=3D-1.0 required=3D5.0
                tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT
                version=3D2.52
X-Spam-Level:=20
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C31EF5.C4F625B4
Thanks Richard, this is exactly one of the scenario I had in mind.

Now let's look at a different but very similar scenario (which is the
one that worries me most).

Assume the same exact call flows, but where the calls to C, D and
E are not done in sequence, but in parrallel (i.e., parallel forking).

From A's perspective, the scenario is exactly the same except that it
will receive the provisional responses from B, C, D and E in random
order, and much closer together. Let's assume that they arrive in the
following order (E, C, D), milliseconds apart.

It wouldn't make sense to change the ringing patterns "sequentially"
because they are not sequenced, but parallel. With the current proposal
(and no means to distinguish between parrallel forked calls and=20
sequential calls), we would end-up with D's ringing (out-of-band) and=20
E's answer. If D was busy (in-band), the user would hear "busy" tone=20
followed by an answer, which is not acceptable.

Two solutions exist for that problem:
- That ALL forking entities be B2BUAs and shield this problem from the =
UAs.
    If there is even just one forking proxy out there (making calls in=20
    parallel), we will get the problem. I'm sceptical that we can =
convince
    the whole world NOT to use forking proxies to make parallel calls.
- That forking proxies tag along a "parrallel forking" indication that=20
    will be provided to the called UAs. This indication will tell the UA =
that=20
    in-band ringing (or other tones) in early media shall NOT be used
    because it is useless (early media for answer of course would still =
be
    valid). (It may make sense also to let the UA sending the original =
invite
    know about the forking so it can provide appropriate treatment for =
the
    user: a tone, or display indication).

The second solution is in my opinion the best. And it would be =
compatible
with your proposal for sequential forwarding. Proxies (or B2BUAs) doing
sequential forwarding would NOT put this "parallel forking" indication.
Your proposed in-band call progress indication would solve the problem=20
nicely.

Proxies (or B2BUAs) doing parralel forking would put the "parallel =
forking"
indication. This would prohibit the UAs receiving the INVITE to=20
do in-band call progress tones (i.e., they wouldn't be allowed to =
include
your in-band call progress indication).=20

In combination, the "in-band call progress indication" and the =
"parralel
forking indiction" would solve all the scenarios that were worrying me.

> -----Original Message-----
> From: Ejzak, Richard P (Richard) [mailto:[e-mail]]=20
> Sent: Monday, May 19, 2003 14:45
> To: 'Gonzalo Camarillo Gonzalez (LMF)'; '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: RE: [Sipping] Last Call for early media use cases
>=20
>=20
> Gonzalo,
> Please excuse my tardiness in responding to your request for=20
> early media use cases. I believe the attachment includes an=20
> example configuration and call flow that clearly illustrates=20
> some problems that need to be solved with the existing SIP=20
> early media procedures.
>=20
> Thanks,
>=20
> Richard Ejzak
> Lucent Technologies
>=20
> -----Original Message-----
> From: Gonzalo Camarillo Gonzalez (LMF)=20
> [mailto:[e-mail]]
> Sent: Wednesday,=20
> May 14, 2003 2:13 AM
> To: '[e-mail]'
> Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail)
> Subject: [Sipping] Last Call for early media use cases
>=20
>=20
> Folks,
>=20
> in the last IETF meeting, we requested early media use cases=20
> that show the need of a "media coming" flag. So far, we have=20
> not received anything.
>=20
> We intend to release a new version of the early media draft=20
> in a week or so. So, that is the time you have to send me=20
> your use cases.
>=20
> Thanks,
>=20
> Gonzalo
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current=20
> sip Use [e-mail] for new developments of core SIP
>=20
>=20

------_=3D_NextPart_001_01C31EF5.C4F625B4
[Enclosed text/html ]
------_=3D_NextPart_001_01C31EF5.C4F625B4--
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP


------_=_NextPart_000_01C32350.9CD8ECA6--