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

From: Adam Roach <[email-masked]>
Date: Fri, 15 Aug 2003 18:58:25 -0500

Jonathan Rosenberg [mailto:[email-masked]] writes:

> > 2) Explicit Subscriptions (with GRUU)
>
> This was one of the solutions I outlined in my initial email, yes. 
> GRUU is not the only problem. There is also the correlation problem - 
> how does the UA know that the SUBSCRIBE comes from an entity 
> along the 
> call path? AUthorizing the subscribe as above would be really hard.

The SUBSCRIBE itself will need to contain information about the
dialog for which it is requesting information anyway, right?
Getting this information requires you to be in a position that
would allow you to intercept the digits themselves.

If you want to keep this information even more securely under
wraps, use sips: to set up the call; the dialog information
is revealed only to people in the call path, and only they would
be able to subscribe to keypad events.

/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 11:02:38 -0700

> be able to subscribe to keypad events.

I wanted to clarify something about dialog usage in this example.

A long running assumption that many seem to be making (not necessarily 
Jonathan or Adam) is that the stimulus from UA1 running the KPML script 
needs to travel over the same dialog that UA1 has with UA2, even though 
nobody wants the stimulus to go to UA2, it needs to go to some 
intermediary, or another UA somewhere. We no longer have a dialog, we 
have a "trialog".   This trialog thing is an abomination which 
fortunately does not exist.  Handling multiple dialogs resulting in the 
same set of dialogs (resulting from a forked request), and reference 
counting invites and subscriptions to determine when a dialog is 
finally terminated is already a huge pain.
Trialogs simply don't work because each side of a dialog needs to 
manage their own CSeq space.

thanks,
-rohan