[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] SUBSCRIBE and From
We're revising draft-ietf-bliss-call-completion-02 in the
Call-Completion committee of BLISS. It turns out that our design can
be simplified and made more robust toward various difficulties in the
Real World if the the recipient of a SUBSCRIBE request could take the
>From header of the request into consideration when determining the
entity/events that are to be sent in NOTIFYs.
But it does look like having a subscription affected by the From value
has not done before, so we're extending the practice of SIP, if not
the letter of the law. Use of the From value is not described in RFC
3265, but as one member pointed out, "It doesn't say you can't,
either."
What do people think of this?
The use case: We want to be able to correlate an incoming SUBSCRIBE
with a previous incoming INVITE from the same UA. The original idea
was that the SUBSCRIBE should specify in some manner the Call-Id of
the INVITE, but it turns out that in real SIP networks, SBCs often
change the Call-Id, so the caller doesn't know the Call-Id that the
callee sees. However, it's rather reliable that the From headers of
the two requests will match, as SBCs are likely to change both of them
in the same way.
Dale
_______________________________________________
Sip mailing list hFrom sip-bounces at ietf.org Wed Jul 9 16:02:17 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 97F833A67FE;
Wed, 9 Jul 2008 16:02:17 -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 BF0E828C267
for <sip at core3.amsl.com>; Wed, 9 Jul 2008 11:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
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 CZ99yluotDCG for <sip at core3.amsl.com>;
Wed, 9 Jul 2008 11:54:10 -0700 (PDT)
Received: from QMTA02.westchester.pa.mail.comcast.net
(qmta02.westchester.pa.mail.comcast.net [76.96.62.24])
by core3.amsl.com (Postfix) with ESMTP id B033328C261
for <sip at ietf.org>; Wed, 9 Jul 2008 11:54:09 -0700 (PDT)
Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60])
by QMTA02.westchester.pa.mail.comcast.net with comcast
id ntLK1Z00d1HzFnQ52uuMp3; Wed, 09 Jul 2008 18:54:21 +0000
Received: from dragon.ariadne.com ([98.217.109.85])
by OMTA14.westchester.pa.mail.comcast.net with comcast
id nuuM1Z00D1qbUTE3auuMJs; Wed, 09 Jul 2008 18:54:21 +0000
X-Authority-Analysis: v=1.0 c=1 a=ifS7fWS8xwqTO17lW3QA:9
a=XnlWD4wD4FbjHLLOC7IA:7 a=F3CQQInLnxIE2w3hVlMRaRQ1mz4A:4
a=5FtdkfQUxfIA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m69IsL4e031053
for <sip at ietf.org>; Wed, 9 Jul 2008 14:54:21 -0400
Received: (from worley at localhost)
by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m69IsLsM031049;
Wed, 9 Jul 2008 14:54:21 -0400
Date: Wed, 9 Jul 2008 14:54:21 -0400
Message-Id: <200807091854.m69IsLsM031049 at dragon.ariadne.com>
To: sip at ietf.org
From: Dale.Worley at comcast.net
X-Mailman-Approved-At: Wed, 09 Jul 2008 16:02:16 -0700
Subject: [Sip] SUBSCRIBE and From
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
We're revising draft-ietf-bliss-call-completion-02 in the
Call-Completion committee of BLISS. It turns out that our design can
be simplified and made more robust toward various difficulties in the
Real World if the the recipient of a SUBSCRIBE request could take the
>From header of the request into consideration when determining the
entity/events that are to be sent in NOTIFYs.
But it does look like having a subscription affected by the From value
has not done before, so we're extending the practice of SIP, if not
the letter of the law. Use of the From value is not described in RFC
3265, but as one member pointed out, "It doesn't say you can't,
either."
What do people think of this?
The use case: We want to be able to correlate an incoming SUBSCRIBE
with a previous incoming INVITE from the same UA. The original idea
was that the SUBSCRIBE should specify in some manner the Call-Id of
the INVITE, but it turns out that in real SIP networks, SBCs often
change the Call-Id, so the caller doesn't know the Call-Id that the
callee sees. However, it's rather reliable that the From headers of
the two requests will match, as SBCs are likely to change both of them
in the same way.
Dale
_______________________________________________
Sip mailing list https://wttps://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
ww.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