Subject: Re: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes

From: [email-masked]
Date: Wed, 1 Aug 2007 22:06:24 -0400

From: Aki Niemi <[email-masked]>

   Currently, subnot-etags offers two modes of operation. In the first, the
   body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other,
   the entire NOTIFY is suppressed, and a new response 204 (No
   Notification) is generated instead.

   The latter is a considerable change to how SIP events works, and might
   cause a middlebox that tracks the SIP dialog to basically barf, thinking
   the dialog expires when it in fact gets refreshed.

I'm tempted to put all the responsibility on the SBC, since the
fundamental "deal" for an SBC is that in return for not being a proxy,
it takes on the responsibility of keeping up with evolving standards
and behaviors.

But looking at RFC 3265, I see that all 2xx responses to SUBSCRIBEs
are required to contain an Expires header for the subscription.  And
draft-ietf-sip-subnot-etags-00, section 4.5, item 2 reiterates that
rule.  So SBCs can track subscription lifetime without seeing NOTIFYs,
and for robustness should already be doing so.

Dale

_______________________________________________
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: "Hisham Khartabil" <[email-masked]>
Date: Fri, 3 Aug 2007 15:38:44 +1000

Aki,

That's hardly a show stopper.

Hisham

On 31/07/07, Aki Niemi <[email-masked]> wrote:
>
> Hi all,
>
> This is a potential show-stopper issue that Rohan brought up in the SIP
> WG session last week.
>
> Do folks think this is a problem? It would be great if some SBC vendors
> could check what their implementation does with SUBSCRIBE dialogs.
>
> Personally, I'd hate to hack around boxes that people claim are doing
> something fishy. But if this is a real problem, then subnot-etags would
> basically need to be reduced to just suppressing bodies of NOTIFYs.
>
> Cheers,
> Aki
>
>