[Simple] Subscription refreshment (2)

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 martin.hynar@tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava

www.tietoenator.com

--- previous message ---

Martin.Hynar@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@example.com SIP/2.0            // initial subscribe
which creates a subscription to document 'index' which belongs to 'user'
> To: sip:user@example.com
> From: sip:user@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@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@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@example.com;tag=12345
> From: sip:user@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@example.com SIP/2.0  // refresh
To: sip:user@example.com;tag=12345
From: sip:user@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@ietf.org
https://www1.ietf.org/mailman/listinfo/simple