[EMAIL PROTECTED] wrote:
> As part of the design of the call-completion feature, we are running
> into a problem regarding data which needs to be carried from the UAC
> to UAS. So the call-completion design committee is circulating the
> question to the Bliss membership for opinions.
>
> Background:
>
> In the call completion design, there are three circumstances where we
> want the UAC to supply certain parameters which will certainly seen by
> the UAS. The question is how to best accomplish this in the face of
> complex forking scenarios and the current definitions of SIP.
>
> In the original call from the UAC to the UAS, the UAC may wish to
> apply a specifically constructed unique identifier to the call. The
> idea of using it as the Call-Id was rejected because of the ubiquitous
> assumption in SIP that Call-Ids can be constructed arbitrarily (as
> long as they are unique). The current choice is to attach it to the
>>From header as the 'id' header parameter. (The conceptually ideal
> choice would be to attach it as a parameter to the Call-Id header, but
> the grammar does not allow that.)
>
> Advantages: Attaching 'id' to the From header is almost certain to
> work in existing systems.
>
> Disadvantages: The 'id' is not conceptually an attribute of the
> caller, but of the call itself.
I'm confused by this part. The callid is already a unique identifier of
the call. What is the problem with them being constructed arbitrarily as
long as unique - all you want is unique.
If you are concerned that some UAs only make their callids unique *at
the moment* but recycle them, then that is just wrong. A UAC that wants
to avail itself of this feature can just as easily fix its use of callid
as it can add yet another id to the call. With what you are proposing,
this would just be yet another call identifier that would have to go in
*every* call.
> In the call completion request SUBSCRIBE, by which the UAC indicates
> that it wants to be notified when the UAS's user is available for
> another call, we wish to attach two parameters: 'id' is used to carry
> the Call-Id of the original call (or the 'id' paramater of the
> original INVITE, if there was one), and 'm' is used to carry the
> "mode" by which the original call failed. The current choice is to
> attach these to the request-URI.
Why the mode? In your draft you discounted providing this by the
subscriber. That analysis seemed appropriate to me.
> Advantages: This allows us to consider the SUBSCRIBE as identifying
> the record of a particular original call that is archived at the UAS,
> and so it is natural that when that original call is selected for
> re-call, the single subscription will receive that notice.
>
> Disadvantages: The above advantage is specious, as there can be
> multiple subscriptions regarding a single original call and we want to
> select only one subscription for re-call; thus different subscriptions
> to the same URI should receive different event information.
Why would there be multiple subscriptions to the same original call? The
only reason I can think of is if there are multiple UAs on the client
side owned by the same user. I doubt it would be done this way in that
case. And if it is, why would the target UA want to single one out?
Notifying them all seems fine in the rare case that this comes up.
This is very distinct from the multiple subscribers to different
original calls that are all queued up.
> Worse,
> any forking proxy is likely to discard the request-URI parameters.
This is a more serious problem.
> Another possibility is attaching these parameters to the event package
> name in the Event header.
>
> Advantages: Proxies are unlikely to alter the Event header.
>
> Disadvantages: Giving up the illusion that these subscriptions are
> passive observers of a data object that is not affected by which
> subscriptions exist.
I don't think this gives up the notion that the data object is
unaffected by the subscriptions that exist. It does give up the notion
that the R-URI is sufficient to identify the data object. Part of that
identification is here moved to the event header parameters. But it can
still be specified as selecting the particular resource among those
handled by this server.
> In the call completion re-call INVITE, by which the UAC contacts again
> the UAS, we also want to carry the 'id' value as an authenticator that
> this INVITE is an authorized call completion re-call, so that this
> INVITE can be given priority over other INVITEs. The current choice
> is to attach this parameter to the request-URI.
>
> Advantages: It might work, especially if the INVITE is sent directly
> to the UAS or a monitor that is responsible for handling call
> completion on behalf of the UAS.
>
> Disadvantages: Forking proxies are likely to discard the request-URI
> parameters.
>
> An alternative to all of the above is that we could define new
> header(s) to carry the required information.
>
> Advantage: It would work.
>
> Disadvantage: Defining a new header just for this one feature.
How about Call-Info?
It is however disheartening to find that the same information has to be
carried in different ways in the subscribe and the invite.
Paul
> Comments?
>
> Dale
> _______________________________________________
> BLISS mailing list
> [email protected]
> http://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss
