Subject: RE: Review of Section 2.12. Single Line Extension (was RE: [Sipping] WGLCof draft-ietf-sipping-service-examples-10.txt)

From: "Michael Procter" <[email-masked]>
Date: Tue, 13 Jun 2006 14:19:09 +0100

Eric Burger wrote:
> My main concern, and one which may spill into other service examples,
is
> the example is NOT INTEROPERABLE.  This service example is not
> interoperable because it makes service assumptions that cannot be made
> in a multi-vendor environment.

I share Eric's concerns in this matter.

> I would suggest either:
>    (1) Put in explicit subscriptions.  Mention in passing
>        that one could create a system with devices that use
>        implicit subscriptions if they know the proxy server
>        will impose implicit subscriptions on them anyway.
>    (2) Keep the call flows as is, but put in a big, bold
>        Notice that the call flow is NOT interoperable.
> 
> My personal preference is (1) for an IETF publication.  Otherwise, you
> can bet some implementers will point to this draft and say, "All User
> Agents MUST accept dialog package notifications, whether they
subscribe
> or not."

And I agree with his suggestion of (1), especially in the light of his
last sentence.

In addition, I have the following comments.

I think that the following paragraph suggests a slightly dubious
approach:

   This flow requires reliable transport such as TCP since the forking
   proxy only guarantees that one UA receives each NOTIFY, not every UA.
   (This is because it only waits for one final response, not N, before
   completing the transaction.

Firstly, I don't believe that using TCP alone guarantees the desired
behaviour since this still assumes that a proxy will generate all forked
messages atomically.  RFC3261 does not require this behaviour, and
indeed section 16.6 points out a number of possible alternative
strategies.
 
Secondly, not only does it require a specific transport for the messages
to be delivered, it also precludes the use of 401 challenges to validate
the message.  Any 401 response (except for the first final response)
will be dropped by the forking proxy.

One solution to part of the problem would be follow the approach
outlined in Dale Worley's recent draft
'draft-worley-sipping-forking-00'.  Section 3.2, which discusses the
problems of forking PUBLISH messages, is probably the closest match to
forking NOTIFYs for implicit subscriptions.

An alternative approach would be to avoid forking, and use a State Agent
to manage the subscriptions.  This ensures that the N(N-1) scaling
problem is kept under control (limiting to 2N instead), and that all UAs
will receive the expected traffic regardless of the underlying transport
mechanism.  This approach is explored in more detail in the (currently
expired) draft 'draft-anil-sipping-bla-02'.  This draft also handles
(amongst other things) consistency of presentation of multiple calls
across the UAs, and outbound calls from the line group.  I believe that
there are also multiple interoperable implementations already.

Regards,

Michael Procter

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 15 Jun 2006 08:38:26 -0500

Eric and Michael,

Thanks for the review and the comments.

This flow is definitely the ugliest in the document and does have the 
issues you have pointed out.  At one time I had planned to rework the 
flow along the lines of draft-anil-sipping-bla-02 using a state agent.  
I think that will solve most of the issues raised here.

I will look at this again and probably redo this call flow.

Thanks,
Alan

---

From: [email-masked]
Date: Tue, 27 Jun 2006 14:54:47 -0400

From: "Michael Procter" <[email-masked]>

   > Otherwise, you can bet some implementers will point to this draft
   > and say, "All User Agents MUST accept dialog package
   > notifications, whether they subscribe or not."

Even if the implementer fixes things once his mistake is pointed out,
many implementers "code to example" and then clean up their
implementations.  This causes endless trouble and delay.

I think the problem is even worse -- When NOTIFY was designed, it was
assumed that the NOTIFY was within the context of a subscription
between two UAs.  The potential issues of sending a NOTIFY to a URI
that forks have never been considered.  (When a NOTIFY is lost, how
does the recipient ask for a full state refresh?  What about serial
forking and call screening?)  If we want a forking delivery of
information, we should use PUBLISH, which was designed for that.  (Not
that it doesn't have problems, too.)

OTOH, if we assume that *individual* implicit subscriptions are
established, those problems go away.  But I suggest that the normative
example use explicit subscriptions, and leave implicit subscriptions
as an extension.

Dale