Subject: [Sip] A problem of refresh SUBSCRIBE request between servers

From: Xiao Wang <[email-masked]>
Date: Wed, 22 Feb 2006 15:55:43 +0800

Hi, all
  In some cases, there may exist a lot of subscriptions between servers. In
other words, a server act as subscriber to subscribe resource from another
server which act as notifier, and the subscriber can build a lot of
subscriptions with the notifier. 
   My question is a lot of subscriptions between servers can bring a lot of
refresh SUBSCRIBE request for each subscription, I think the mechanism of
refresh subscription of RFC3265 is low efficiency in this case. Is my view
right?

Xiao

_______________________________________________
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: Manish Joshi <[email-masked]>
Date: Wed, 22 Feb 2006 11:02:04 -0800 (PST)

Hi Xiao,
   
  I havent tried it but a glance at RFC 3265 suggested that ID parameter in event header in Subscribe request can be used to have multiple subcription and refreshes in the same dialog.
   
  From RFC 3265 section 
  "A SUBSCRIBE request MAY include an "id" parameter in its "Event"
header to allow differentiation between multiple subscriptions in the
same dialog."
   
  Thanks,
  Manish

Xiao Wang <[email-masked]> wrote:
  Hi, all

Xiao

		
---------------------------------
 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2006 14:37:29 -0500

While you can have a bunch of subscriptions share the same dialog, that 
doesn't eliminate the need to refresh each of them. It is the usage that 
expires, not the dialog.

	Paul

Manish Joshi wrote:
> Hi Xiao,
>  
> I havent tried it but a glance at RFC 3265 suggested that ID parameter 
> in event header in Subscribe request can be used to have multiple 
> subcription and refreshes in the same dialog.
>  
>  From RFC 3265 section
> */Xiao Wang <[email-masked]>/* wrote:
> 
>     Hi, all
> ------------------------------------------------------------------------
> Yahoo! Autos <http://us.rd.yahoo.com/evt=38381/ 
> ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html 
>  >. Looking for a sweet ride? Get pricing, reviews, & more on new and 
> used cars.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Manish Joshi <[email-masked]>
Date: Wed, 22 Feb 2006 12:07:45 -0800 (PST)

Oh yes, off-course. We still need to 'refresh' each of them but guess 
  we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests.
   
  -Manish

Paul Kyzivat <[email-masked]> wrote:
  While you can have a bunch of subscriptions share the same dialog, that 
doesn't eliminate the need to refresh each of them. It is the usage that 
expires, not the dialog.

Paul

Manish Joshi wrote:
> */Xiao Wang /* wrote:
> Yahoo! Autos > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html

---

From: Manish Joshi <[email-masked]>
Date: Wed, 22 Feb 2006 12:22:44 -0800 (PST)

Ok I think I got little confused with the RFC.
  Guess RFC doesnt really suggests having multiple IDs in the same SUBSCRIBE Requests.
  It just suggests that with "id" parameter in a event header it can be avoided to have a new dialog for each Subscription. The number of Subscribe / 200 OK request/response flowing over the network remains same.
  Am I right in my understanding?
   
  Thanks,
  Manish
   
  Manish Joshi <[email-masked]> wrote:
    Oh yes, off-course. We still need to 'refresh' each of them but guess 
  we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests.
   
  -Manish

Paul

  Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars._______________________________________________

 What are the most popular cars? Find out at Yahoo! Autos

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2006 16:36:04 -0500

Manish Joshi wrote:
> we can do all the refreshes again in a single dialog with all "id"s in 
> EVent Header same as IDs in initial Subscription requests.

Yes. But it will still require a subscribe transaction for each one, and 
also a notify transaction for each one unless we define a way to avoid that.

	Paul

> -Manish
> 
> */Paul Kyzivat <[email-masked]>/* wrote:
> 
>      > Yahoo! Autos

---

From: Xiao Wang <[email-masked]>
Date: Thu, 23 Feb 2006 09:13:38 +0800

Manish,

       My understanding is RFC3265 allowed multiple subscriptions can be
associated with a dialog, differentiating 

the refresh SUBSCRIBE request and NOTIFY request in each different
subscriptions of a same dialog by the "id" parameter in its "Event" header
field.

Xiao

  _____  

From: Manish Joshi [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 3:02 AM
To: Xiao Wang; [email-masked]
Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers

Hi Xiao,

I havent tried it but a glance at RFC 3265 suggested that ID parameter in
event header in Subscribe request can be used to have multiple subcription
and refreshes in the same dialog.

Thanks,

Manish

Hi, all

Xiao

  _____  

Yahoo!
<http://us.rd.yahoo.com/evt=38381/%20ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHN
lYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http:/autos.yahoo.com/index.html%20>  Autos.
Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

---

From: Xiao Wang <[email-masked]>
Date: Thu, 23 Feb 2006 09:39:49 +0800

Paul,
Inline, 
Xiao
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, February 23, 2006 3:37 AM
> To: Manish Joshi
> Cc: Xiao Wang; [email-masked]
[Xiao]My view is the server act as subscriber which use a SIP message(called
BSRM: Batch Subscriptions Refreshment Message) to include multiple refreshed
subscriptions' id in the body , the subscriber send BSRM to notifier and
notifier get all ids from BSRM body, so notifier can refresh the
subscriptions which the ids indicate.
The benefit is use BSRM to refresh multiple subscriptions and reduce refresh
SUBCRIBE request in net, also reduce the transactions of refresh
subscription.

> >     My question is a lot of subscriptions between servers can bring a
lot
> of

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2006 22:02:58 -0500

> SUBCRIBE request in net, also reduce the transactions of refresh

I was talking about what is currently legal. You are free to propose 
your idea for BSRM. There are a lot of details you need to work out for 
that. If the subscriptions are not part of the same dialog, then you 
will need to figure out how to specify a request that applies to a 
number of different dialogs, and deals properly with the CSeqs of each 
of them.

	Paul