Subject: [Simple] Subscription refreshment (2)

From: [email-masked]
Date: Mon, 15 Aug 2005 09:09:49 +0200

Hello again,

There is one more thing which is still not clear to me. According to RFC 3261, dialog is described as follows:

(page 69, sec. 12 Dialogs)
...
A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA. The
tags are opaque tokens that facilitate the generation of unique
dialog IDs.
 ...

========================================================================
=======================
As I understand it, the URIs in From and To header are not part of the
dialog id. If I am not correct, could you please clarify it ?

Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail [email-masked]

Technologicka 372/2
CZ-708 00 Ostrava

www.tietoenator.com

--- previous message ---

[email-masked] wrote:
> Hello,
> 
> I am currently testing some SIP SUBSCRIBE functionality, and there is
one thing i am not 100% sure of - mechanism of refreshing a
subscription.
> 
> Our software implements functionality described in
draft-ietf-sipping-config-framework (Framework for Session Initiation
Protocol User Agent Profile Delivery) but there is nothing about
refreshes - it references RFC 3265.
> 
> 
> RFC 3265:
> 
> 3.1.4.2. Refreshing of Subscriptions
> At any time before a subscription expires, the subscriber may refresh
> the timer on such a subscription by sending another SUBSCRIBE request
> on the same dialog as the existing subscription, and with the same
> "Event" header "id" parameter (if one was present in the initial
> subscription). The handling for such a request is the same as for the
> initial creation of a subscription except as described below.
> 
> So lets say, i'll send these messages:
> 
> SUBSCRIBE sip:[email-masked] SIP/2.0            // initial subscribe
which creates a subscription to document 'index' which belongs to 'user'
> To: sip:[email-masked]
> From: sip:[email-masked];tag=a2b3c1
> Event:sip-profile;profile-type=application;app-id=resource-lists;docum
> ent=index
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 1 SUBSCRIBE
> ...
> 
> SIP/2.0 200 OK
> To: sip:[email-masked];tag=12345
   Expires: 3600
> ...

The expires value in the response is important. It specifies when the
subscription will expire if not refreshed first.

> SUBSCRIBE sip:[email-masked] SIP/2.0        // subscribe to
another user - but it is sent on the same dialog, with the same Event
header
> To: sip:[email-masked];tag=12345
> From: sip:[email-masked];tag=a2b3c1
> Event:sip-profile;profile-type=application;app-id=resource-lists;docum
> ent=index
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 2 SUBSCRIBE
> ...

The above is not valid. All the requests in the dialog must have the
same To and From. (Swapped if the request is sent in the reverse
direction.) If you want to send a subscription for another user then you
must create a new dialog.

To refresh the original subscription, before it expires, send another
subscription in the same dialog, such as:

SUBSCRIBE sip:[email-masked] SIP/2.0  // refresh
To: sip:[email-masked];tag=12345
From: sip:[email-masked];tag=a2b3c1
Event:sip-profile;profile-type=application;app-id=resource-lists;documen
t=index
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 2 SUBSCRIBE

> Will the second subscribe just refresh the initial one, even if it has
different sip uri in To header ?

No. It is just wrong.

        Paul

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Aug 2005 09:10:18 -0400

> tags are opaque tokens that facilitate the generation of unique

Martin,

What you say is true. The reason to keep the From and To unchanged is 
for consistency with RFC2543. Once you discard 2543 compatibility it is 
theoretically permissible to change the From and To addresses. This 
however would *not* change the resource subscribed to.

Initially, the resource of the source is specified by the Contact in the 
initial subscribe, and the desired resource of the target is specified 
by the R-URI. When the dialog is established, the target of the 
destination is specified by the Contact address returned in the response 
to the subscribe.

Subsequent subscribes for the same event type and event id in the same 
dialog are updating the state of the same subscription, and not 
establishing a new subscription. Technically it is only the subscription 
state that has an expiration time and that is being updated. The dialog 
itself is not directly updated at all - it merely remains until all the 
usages (e.g. subscriptions) associated with it go away.

You can in principle establish multiple subscriptions within the same 
dialog. However you cannot establish two subscriptions over the dialog 
in the same direction with the same event type and event id. (But note 
that establishing multiple usages of the same dialog is widely 
discouraged - viewed as a feature that should never have been permitted.)

There is great reluctance to change the To and/or From in a dialog. The 
kind of situation where it has been suggested are:
- when a call (because of forwarding) is delivered to a party other than
   the one described by To, some would like to change the To to reflect
   who was reached.

- When the target of the call is a gateway or B2BUA, it is possible to
   switch the party on the far side while retaining the dialog on the
   near side. Some would like to change the corresponding To/From in
   this case.

This is sometimes called the Connected Party ID problem, and there have 
been suggestions for how to address it, though none yet has concensus.

Your original example implied that you were trying to multiplex 
subscriptions to the same event type, but for different resources, 
through the same dialog. Even if this were permissible (and I think it 
is not), then one subscription would not refresh any of the other 
subscriptions. The dialog would remain until the last subscription 
expired, but without refreshing, all the subscriptions would eventually 
expire.

	Paul