[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] Subscription refreshment (2)



Martin.Hynar at tietoenator.com wrote: 
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,

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

Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail martin.hynar at tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava

www.tietoenator.com





--- previous message ---

Martin.Hynar at tietoenator.com 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:user at example.com SIP/2.0 // initial subscribe 

which creates a subscription to document 'index' which belongs to 'user'

To: sip:user at example.com
From: sip:user at example.com;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:user1 at example.com;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:anotheruser at example.com SIP/2.0 // subscribe to 

another user - but it is sent on the same dialog, with the same Event
header

To: sip:anotheruser at example.com;tag=12345
From: sip:user at example.com;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:user at example.com SIP/2.0  // refresh
To: sip:user at example.com;tag=12345
From: sip:user at example.com;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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple