Subject: Re: [sipcore] Forking and draft-ietf-sipcore-subnot-etags

From: wang xiangjun <[email-masked]>
Date: Sun, 31 May 2009 09:26:04 +0800

Hello Adam,
   I have read the draft and your clarification about the forking situation which is a good job, but I still have a problem about it as below:
   If a subscriber sends a SUBSCRIBE request and the request is forked to two notifiers by a proxy which establishes two dialogs. The subscriber will receive two SIP-Etag from the two notifiers respectively, is it right? Then the subscription terminates and after a while the subscriber wants to resume a subscription, the problem is how does the subscriber deals with the Suppress-If-Match header field? Does it include one of the SIP-Etag value or both of them?

Best Regards,

wangxiangjun
华为技术有限公司  

地址：深圳市龙岗区坂田华为基地 邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

  ----- Original Message ----- 
  From: Adam Roach 
  To: SIPCORE 
  Sent: Thursday, April 23, 2009 12:13 AM
  Subject: [sipcore] Forking and draft-ietf-sipcore-subnot-etags

  [as an individual participant]

  You've probably noticed a new version of the subnot-etags document just 
  came out. This version incorporates some changes to resolve a 
  last-minute technical issue with the way this document interacts with 
  request forking. (There's also an ABNF change, but there's a separate 
  thread going on that topic).

  In previous versions of the document, the language allowed complete 
  suppression of NOTIFY messages except when there were "reportable 
  changes in the NOTIFY header". This criteria was somewhat ambiguous in 
  the general case of establishing a new subscription (the transition of 
  subscription state to "active" technically qualifies as a "reportable 
  change in the NOTIFY header", but implementors were left to figure this 
  out independently). To complicate matters, there were at least two 
  passages in the document that strongly suggested that there may be 
  circumstances in which the first NOTIFY in a subscription would be 
  completely suppressed, which causes some serious issues with forking.

  The complete suppression of NOTIFY messages was also explicit for 
  resource state polling, which gives rise to similar issues.

  The issue with suppressing the first NOTIFY message in a dialog is that 
  a forked SUBSCRIBE message can land on several notifiers, each of whom 
  may well accept the subscription. However, due to SIP forking 
  processing, only one final response to the SUBSCRIBE will arrive at the 
  subscriber.

  Under the 3265 model, this is resolved by the use of an immediate NOTIFY 
  in the reverse direction -- the subscriber learns about all the 
  resulting subscriptions because it receives a NOTIFY message for each 
  one. Removing this aspect of subscription establishment basically 
  re-creates a variant of the HERFP problem, except much worse: instead of 
  failing to learn about various request failures, the subscriber fails to 
  learn about various successful dialog establishments.

  The most recent version of the document addresses this by:

     1. Cleaning up the passages that implied suppression of the initial
        NOTIFY message in a dialog

     2. Making explicit the previously implicit behavior of not
        suppressing initial NOTIFY message in a dialog

     3. Changing poll behavior to require empty NOTIFY messages instead of
        completely suppressed NOTIFY messages

  Only the third change is an actual change in behavior. The first two are 
  simply making previously implied behavior explicit.

  I realize that this is a bit of deep RFC 3265 arcana, but please weigh 
  in on the changes so we can move the document over the finish line soon. 
  Thanks!

  /a
  _______________________________________________
  sipcore mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/sipcore

---

From: Adam Roach <[email-masked]>
Date: Sat, 30 May 2009 20:44:44 -0500

[as an individual]

As with normal RFC 3265 processing, after the initial SUBSCRIBE, the 
subscriber is responsible for maintaining the multiple subscriptions 
separately, including the handling of etags.

I don't think we cover the exact case you're talking about. I suspect 
you're pretty much stuck with getting the body for all but one of the 
forks, and suppressing the subsequent NOTIFY messages. If this is a 
problem for a specific network, there are a host of solutions that can 
be engineered through the use of GRUUs.

/a

wang xiangjun wrote:
> Hello Adam,
>    I have read the draft and your clarification about the forking 
> situation which is a good job, but I still have a problem about it as 
> below:
>    If a subscriber sends a SUBSCRIBE request and the request is forked 
> to two notifiers by a proxy which establishes two dialogs. The 
> subscriber will receive two SIP-Etag from the two notifiers 
> respectively, is it right? Then the subscription terminates and after 
> a while the subscriber wants to resume a subscription, the problem 
> is how does the subscriber deals with the Suppress-If-Match header 
> field? Does it include one of the SIP-Etag value or both of them?
>  
> Best Regards,
> wangxiangjun
> 华为技术有限公司 huawei_logo
>     *From:* Adam Roach <mailto:[email-masked]>
>     *To:* SIPCORE <mailto:[email-masked]>
>     *Sent:* Thursday, April 23, 2009 12:13 AM
>     *Subject:* [sipcore] Forking and draft-ietf-sipcore-subnot-etags
>
>     [email-masked] <mailto:[email-masked]>