[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-info-events-00 using RFC 3265 instead
I will try to summarize the essence of the arguments:
Establishing the subscription requires more messages to be exchanged.
The subscription then requires staFrom sip-bounces at ietf.org Wed Oct 29 10:56:56 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id BC9BF3A6C73;
Wed, 29 Oct 2008 10:56:56 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 71A533A6C6E
for <sip at core3.amsl.com>; Wed, 29 Oct 2008 10:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.339
X-Spam-Level:
X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id MbMbYwVe1BAM for <sip at core3.amsl.com>;
Wed, 29 Oct 2008 10:56:54 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148])
by core3.amsl.com (Postfix) with ESMTP id 112743A68C1
for <sip at ietf.org>; Wed, 29 Oct 2008 10:56:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,507,1220227200"; d="scan'208";a="26083033"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2008 17:56:46 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9THukCw023499;
Wed, 29 Oct 2008 13:56:46 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9THuk0s026387;
Wed, 29 Oct 2008 17:56:46 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 29 Oct 2008 13:56:45 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by
xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 29 Oct 2008 13:56:45 -0400
Message-ID: <4908A3D8.6020104 at cisco.com>
Date: Wed, 29 Oct 2008 13:56:40 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Nasir Khan <nkhan.sip at gmail.com>
References: <21964a950810291006i6940f9fdi1f5fcf05a28a307d at mail.gmail.com>
In-Reply-To: <21964a950810291006i6940f9fdi1f5fcf05a28a307d at mail.gmail.com>
X-OriginalArrivalTime: 29 Oct 2008 17:56:45.0725 (UTC)
FILETIME=[B53A8CD0:01C939EF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3283; t=1225303006;
x=1226167006; c=relaxed/simple; s=rtpdkim1001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pkyzivat at cisco.com;
z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com>
|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-info-events-00=2
0using=20RFC=203265=20instead |Sender:=20
|To:=20Nasir=20Khan=20<nkhan.sip at gmail.com>;
bh=FneUuC/3z2N+JiGuf3MTWgM1/YGCAPKjoPAItPtG3X0=;
b=oolEfMm3j3sJ9hLhJKfp1W4f55vAs3lLCDhiH24AQDi+SBL1oTOtOZvQhg
eoDzawKU5PhREpk/I8QXK2HdAkCWxSDugA98YEbcTacN71Fcr+K4bDOxkZqS
hkoi2uzLr/;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/rtpdkim1001 verified; );
Cc: SIP IETF <sip at ietf.org>
Subject: Re: [Sip] draft-ietf-sip-info-events-00 using RFC 3265 instead
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
I will try to summarize the essence of the arguments:
Establishing the subscription requires more messages to be exchanged.
The subscription then requte to be maintained, and it must be
refreshed periodically.
The desired uses of info are often things that *might* be exchanged on
any call, but often (usually?) are not. So paying a lot of cost for the
possibility is thought to be a bad deal.
Thanks,
Paul
Nasir Khan wrote:
[Per Keith's suggestion starting a new thread, copied from last one]
Yes Paul, that is what I was trying to get at.
Sorry if all this was already discussed and closed.
Do we have a comaparitive between the two approaches from past?
The reason I brought it out was that there are several similarities in
where we are going with info events and 3265.
I hope we do not undermine the usage of SIP events.
As an example if one comes up with a brand new application that has some
small data to be transferred between UAs and the session is INVITE based
then which approach should one take? Will we have clear guidelines or
leave it open?
IMHO overlapping semantics is also not very good for interoperability.
Is the legacy (mis)use of INFO the most compelling reason for this
approach of bringing it into proper framework?
again apologies for repetition.
regards
nasir
-------------------------------
I'm not certain I understand the point you are making.
Is it that we don't need info events because we could accomplish the
same thing using subscriptions to suitable event packages?
If that is your point, we have been down that path already. Many of us
have taken that position in the past (and may still believe it today),
but there were many arguments that that approach is to heavy weight.
Evidence of that is the continued use of info for DTMF even though we
have an event package for that.
Paul
Nasir Khan wrote:
Maybe it warrants a separate thread but I would like to discuss section
7.1.3 of this draft where 3265 is talked about as an alternative.
Since we are talking about the notion of well defined info packages and
the INFO messages
will carry information as a result of an event like an ISUP event or
DTMF event (the name of the draft itself has "event" in it), then the
two User Agents can very well subscribe to these events and use the
notifications for the information exchange.
This will automatically inherit all the good work done around
notification framework and will lay to rest lot of questions and perhaps
save some re-invention.
Regards
Nasir
--
Get the most comprehensive open source SIP application testing framework
at http://sipper.agnity.com <http://sipper.agnity.com/>
------------------------------------------------------------------------
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
ires state to be maintained, and it must be
refreshed periodically.
The desired uses of info are often things that *might* be exchanged on
any call, but often (usually?) are not. So paying a lot of cost for the
possibility is thought to be a bad deal.
Thanks,
Paul
Nasir Khan wrote:
[Per Keith's suggestion starting a new thread, copied from last one]
Yes Paul, that is what I was trying to get at.
Sorry if all this was already discussed and closed.
Do we have a comaparitive between the two approaches from past?
The reason I brought it out was that there are several similarities in
where we are going with info events and 3265.
I hope we do not undermine the usage of SIP events.
As an example if one comes up with a brand new application that has some
small data to be transferred between UAs and the session is INVITE based
then which approach should one take? Will we have clear guidelines or
leave it open?
IMHO overlapping semantics is also not very good for interoperability.
Is the legacy (mis)use of INFO the most compelling reason for this
approach of bringing it into proper framework?
again apologies for repetition.
regards
nasir
-------------------------------
I'm not certain I understand the point you are making.
Is it that we don't need info events because we could accomplish the
same thing using subscriptions to suitable event packages?
If that is your point, we have been down that path already. Many of us
have taken that position in the past (and may still believe it today),
but there were many arguments that that approach is to heavy weight.
Evidence of that is the continued use of info for DTMF even though we
have an event package for that.
Paul
Nasir Khan wrote:
Maybe it warrants a separate thread but I would like to discuss section
7.1.3 of this draft where 3265 is talked about as an alternative.
Since we are talking about the notion of well defined info packages and
the INFO messages
will carry information as a result of an event like an ISUP event or
DTMF event (the name of the draft itself has "event" in it), then the
two User Agents can very well subscribe to these events and use the
notifications for the information exchange.
This will automatically inherit all the good work done around
notification framework and will lay to rest lot of questions and perhaps
save some re-invention.
Regards
Nasir
--
Get the most comprehensive open source SIP application testing framework
at http://sipper.agnity.com <http://sipper.agnity.com/>
------------------------------------------------------------------------
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip