Subject: [Insipid] Scoping of the insipid work and impact on use cases

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 27 Sep 2012 18:59:36 +0200

The chairs and the AD went through the slides presented to the Vancouver meeting that can be found here

http://www.ietf.org/proceedings/84/slides/slides-84-insipid-0.pptx 

James Polk also posted the contents of these slides to the list in various messages on 28th August.

I have now also tried to correlate that review to the current -01 version of the requirements document.

Obviously if this is followed, and out AD will insist that it is, it removes the justification for some on the requirements, and we will need to work through that on the virtual interim.

Slide 4: Session-ID old Use-cases (1/2)
--------------------------------------

No issues

Slide 5: Session-ID old Use-cases (2/2)
---------------------------------------

No issues

Slide 6: Session-ID retained Use-cases (1/2)
--------------------------------------------

Out of scope because conferencing is out of scope.

3.2 in in -01 version of requirements i-d.

Note, no formal SIPREC requirements have been identified.

Slide 7: Session-ID retained Use-cases (1/2)
--------------------------------------------

No issues identified

Slide 8: Session-ID new Use-cases (1/8): 3.X   End-to-end identification of a communication session
---------------------------------------------------------------------------

Now section 3.1 in -01 version of requirements i-d.

One in, one out.

No issues identified.

This may be the source of some of the confusion about 3PCC. I think the one in, one out configuration is 3PCC, but it is not one of the scenarions identified in RFC 3725.

Slide 9: Session-ID new Use-cases (2/8): 3.X   Identification of devices taking part in the same multipoint Conference
---------------------------------------------------------------------------

Now section 3.5 in -01 version of requirements i-d.

Out of scope, conferences not covered.

Slide 10: Session-ID new Use-cases (3/8): 3.X   Tracking sessions transferred from one endpoint to another
---------------------------------------------------------------------------

Now section 3.6 in -01 version of requirements i-d.

Formally REFER etc, is out of scope, however...

Explore the issues - cannot avoid someone putting an INSIPID identifier in a REFER contents, so need to say what occurs when it happens.

Slide 11: Session-ID new Use-cases (4/8): 3.X   Session Signal Logging
----------------------------------------------------------------------

Now section 3.7 in -01 version of requirements i-d.

Slim down only to debugging. Accounting and billing are out of scope.

Slide 12: Session-ID new Use-cases (5/8): 3.X   Identifier Porting to Other Protocols - RSVP
---------------------------------------------------------------------------

While such interworking is not in scope, obviously, if an implementor wants to subsequently do this, it is not precluded.

Slide 13: Session-ID new Use-cases (6/8): 3.X   Identifier Porting to Other Protocols - RTCP
---------------------------------------------------------------------------

Keep use case based on discussion in Vancouver meeting.

Now section 3.8 in -01 version of requirements i-d.

Slide 14: Session-ID new Use-cases (7/8): 3.X Traffic Monitoring
----------------------------------------------------------------

Section 3.4 in -01 version of requirements i-d

As slide 8

Slide 15: Session-ID new Use-cases (8/8): 3.X  3PCC Use Case.
-------------------------------------------------------------

Now section 3.9 in -01 version of requirements i-d.

All RFC 3725 use cases are out of scope.

Regards

Keith

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 27 Sep 2012 19:33:48 -0400

Keith,

I can understand the argument that conferencing is out.  I viewed that 
as a "freebie" given the way we had constructed the Session-ID.  Also, 
it was not perfect, since one could not tell if two devices shared a 
half-key value because they are in a conference together or because one 
call leg is being transferred or joined with another.  What it did, 
though, was clearly indicate that two sessions were somehow related.  I 
think that is what was most important.  I didn't care to know with 100% 
certainty that two sessions are in a conference together, but I did want 
to know that the was some relationship.  Thus, the reason for 
recommending that MCUs use the same Session-ID-UUID.

Call transfer can come in multiple forms, including a REFER and a local 
"join" on a PBX.  This one is vital.  If Alice calls Bob and Carol call 
Bob, there are two session-IDs.  Then if Bob does something such that 
Alice and Carol are now communicating and Bob drops out, what is the 
Session-ID between Alice and Carol?  What we proposed would answer that 
question consistently.

I'm rather concerned that the transfer / "call join" use cases might be 
declared out of scope.  Cullen assured us this was not the case before.  
Can you clarify?

Paul

On 9/27/2012 12:59 PM, DRAGE, Keith (Keith) wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid