Subject: RE: [Sipping] App-Interaction: Considering models

From: Adam Roach <[email-masked]>
Date: Wed, 20 Aug 2003 15:14:28 -0500

Rohan Mahy [mailto:[email-masked]] writes:

>> 1) Standard HTTP Handling
>
> this also potentially has the same dialog
> correlation problem that I described above.

You're right; it does. My enthusiasm for this solution
is consequently waning.

I will add that the "just use a new method" approach
suffers from precisely the same relic. In fact, the
only thing proposed to date which does not is...

>> 2) Explicit Subscriptions (with GRUU)
>>
>> UAC           App Server          UAS
>> 1|-----INVITE---->|                |
>> 2|                |-----INVITE---->|   AS extracts GRUU from INVITE
>> 3|                |<-----200-------|
>> 4|<-----200-------|                |
>> 5|<---SUBSCRIBE---|                |   AS SUBSCRIBEs with KPML script
>> 6|------200------>|                |
>> 7|-----NOTIFY---->|                |
>> 8|<-----200-------|                |
>> 9|-----NOTIFY---->|                |   UAC provides digits
>> A|<-----200-------|                |   AS acknowledges digits

> I don't see how Adam plans to correlate the SUBSCRIBE with the 
> INVITE-initiated dialog.  You can't send the SUBSCRIBE on the 
> existing dialog, because you will screw up the CSeq space.

Of *course* you don't re-use the dialog. Steps 1 through 4 are
in one dialog (between the UAC and the UAS); steps 5 through A
are in a second dialog (between the App Server and the UAC).

To answer the implied question about how to perform correlation,
I suggest wholesale copying of section 3.2 from
draft-ietf-sipping-dialog-package-02.

> > I'd be keener on GRUU solutions if GRUU was a solved problem.
> 
> we need to solve this problem anyway if you want transfer to work, so 
> I'm not especially concerned.

Yes, I forgot to address this. Given the relative maturity
of each, I imagine that App-Interaction will hit the finish
line about the same time as the GRUU work. If you additionally
consider complexity, GRUU should finish first.

/a

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 20 Aug 2003 14:11:59 -0700

On Wednesday, August 20, 2003, at 01:14 PM, Adam Roach wrote:

> suffers from precisely the same relic.

using a new method does not actually suffer from the dialog correlation 
problem.  You are sending a feedback or stimulus body in the new 
method, which just needs to contain a session-id or dialog-information 
to describe the dialog for which the feedback/stimulus is associated.  
You can use the same URI (as long as it has GRUU properties) for ALL 
your feedback for the same service/application if you'd like (imagine a 
prepaid application that can use the same URI for a T3 gateway worth of 
sessions).  I think this is a nice property.

> In fact, the

ok, that would work fine.  however, you require a subscription per 
dialog, unless you write a subscription filter body.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Aug 2003 15:02:57 -0700

>> correlation problem that I described above.
.. Snip ...
>>> 2|                |-----INVITE---->|   AS extracts GRUU from INVITE
.. Snip... 
> consider complexity, GRUU should finish first.

Yes, I agree with this logic. So are we coming to the conclusion that the
GRUU/SUB/NOT is the right way to go? I can try and flesh out some details on
this if we are.