Subject: [Sip] PUBLISH question

From: Hisham Khartabil <[email-masked]>
Date: Fri, 3 Feb 2006 13:15:47 +0100

Apologies if this has been discussed earlier.

The scenario is that my UA send an initial PUBLISH request and I get a 
200 response with a SIP-Etag header with a value. Now the UA can 
refresh and modify the state. What if my UA crashes and reboots? It 
will create a new initial PUBLISH request which *will not* replace the 
old publication that has not expired yet. I now have 2 states at the 
server. How do I remove the first one? Waiting for it to expire is not 
an option. The only answer I can think of is storing the e-tag 
persistantly. Any other opinions?

Thanks,
Hisham

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Aki Niemi <[email-masked]>
Date: Fri, 03 Feb 2006 15:39:55 +0200

ext Hisham Khartabil wrote:
> 200 response with a SIP-Etag header with a value. Now the UA can refresh 
> and modify the state. What if my UA crashes and reboots? It will create 
> a new initial PUBLISH request which *will not* replace the old 
> publication that has not expired yet. I now have 2 states at the server. 
> How do I remove the first one? Waiting for it to expire is not an 
> option. The only answer I can think of is storing the e-tag 

Storing the entity-tag locally is the best option at the moment in the 
absence of a GET method (or an event package that notifies of 
publications specifically).

Cheers,
Aki

---

From: Dean Willis <[email-masked]>
Date: Sun, 5 Feb 2006 11:53:27 -0600

On Feb 3, 2006, at 6:15 AM, Hisham Khartabil wrote:

> The scenario is that my UA send an initial PUBLISH request and I  
> get a 200 response with a SIP-Etag header with a value. Now the UA  
> can refresh and modify the state. What if my UA crashes and  
> reboots? It will create a new initial PUBLISH request which *will  
> not* replace the old publication that has not expired yet. I now  
> have 2 states at the server. How do I remove the first one? Waiting  
> for it to expire is not an option. The only answer I can think of  
> is storing the e-tag persistantly. Any other opinions?

Your procedure should be "get before publish if you don't have an  
etag". Then if you crash and lose the etag, on recovery you get the  
document (and its etag) before publishing a new document.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Feb 2006 21:58:58 -0500

inline.

Dean Willis wrote:

>> The scenario is that my UA send an initial PUBLISH request and I  get 
>> a 200 response with a SIP-Etag header with a value. Now the UA  can 
>> will create a new initial PUBLISH request which *will  not* replace 
>> the old publication that has not expired yet. I now  have 2 states at 
>> the server. How do I remove the first one? Waiting  for it to expire 
>> is not an option. The only answer I can think of  is storing the e-tag 

The problem is, there is no 'get' mecahnism. You can subscribe the 
appropriate event state, but that isn't going to tell you the etags of 
the raw published event state.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Feb 2006 04:21:22 -0600

On Feb 5, 2006, at 8:58 PM, Jonathan Rosenberg wrote:

>>> get a 200 response with a SIP-Etag header with a value. Now the  
>>> UA  can refresh and modify the state. What if my UA crashes and   
>>> reboots? It will create a new initial PUBLISH request which  
>>> *will  not* replace the old publication that has not expired yet.  
>>> I now  have 2 states at the server. How do I remove the first  
>>> one? Waiting  for it to expire is not an option. The only answer  
>>> I can think of  is storing the e-tag persistantly. Any other  
>>> opinions?
>> etag". Then if you crash and lose the etag, on recovery you get  
>> the  document (and its etag) before publishing a new document.
>
> appropriate event state, but that isn't going to tell you the etags  
> of the raw published event state.

Doesn't that depend on  which "side" of the compositor you're  
subscribing to? I seem to recall some discussion of subscribing to  
"inputs" as well as composited "outputs".

Now, I do have to say I'm aware of an implementation that doesn't  
support this, although I seem to recall suggesting that it should.

--
Dean