Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

[Christer Holmberg <[e-mail]>]

Hi John, 

>Well, if everyone says they won't perform a feature because 
>somebody else is going to do it, that seems like a recipe for 
>not having the feature performed at all. There would need to 
>be some rules on which entity performs the feature and which 
>entities do not perform the feature.

Absolutely. The feature tag definition needs to contain/refer these kind of rules.

>I am not sure this was clear from the draft.

It is intended to be covered in section 6, but we for sure can add more text to make it clearer.

Regards,

Christer




> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Christer Holmberg
> > Sent: 22 January 2011 09:32
> > To: Paul Kyzivat; [e-mail]
> > Subject: Re: [sipcore] Draft new version: 
> > draft-holmberg-sipcore-proxy-feature
> > 
> > 
> > Hi Paul,
> > 
> > The idea is that each feature specification defines what indicating 
> > support of a feature means - in the same way it is done for UAs.
> > 
> > For example, just because a proxy indicate support of a feature, it 
> > doesn't automatically mean that others will address 
> requests towards 
> > that proxy. It may for example mean that another entity, 
> when it sees 
> > the feature tag, does not trigger some action.
> > 
> > I am sure there are things in the draft than can be clarified, 
> > including the 3GPP use-cases, but I think it would be 
> useful to know 
> > (for me personally, and for 3GPP that wants to use the mechanism) 
> > whether the WG is willing to start this work. Nobody has 
> objected to 
> > the work as such (you even say yourself that it might be useful :), 
> > and all questions and issues that have been raised will of 
> course have 
> > to be solved (like we always do).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > ________________________________________
> > From: [e-mail] [[e-mail]] 
> On Behalf Of 
> > Paul Kyzivat [[e-mail]]
> > Sent: Saturday, January 22, 2011 3:00 AM
> > To: [e-mail]
> > Subject: Re: [sipcore] Draft new        version:        
> > draft-holmberg-sipcore-proxy-feature
> > 
> > (speaking as an individual)
> > 
> > Inline...
> > 
> > 
> > 
> > On 1/21/2011 5:25 PM, Andrew Allen wrote:
> > > I have reviewed this draft and basically I am supportive of the 
> > > objective of this work.
> > >
> > > I think the current use cases are very specific and the
> > problem itself
> > > is even more general.
> > >
> > > I think the general requirement is that it is useful for
> > UAs and other
> > > intermediaries to be able to detect the presence of an
> > intermediary on
> > > the path of a registration or the route of a dialog when that 
> > > intermediary provides some feature or service and be able
> > to identify
> > > the URI of that intermediary in order to be able to address
> > requests to
> > > it . In addition to the 3GPP specific use cases currently
> > in the draft I
> > > think there are others including:
> > 
> > A major thing that is lacking here is any explanation of what it 
> > *means* for an intermediary to "offer a feature" - what sorts of 
> > features those are, and how one might avail oneself of them.
> > 
> > In the case of callerprefs/callee caps and currently defined, the 
> > intermediary is a proxy that does address translation based on a 
> > registrar. One knows that the way to avail themselves of 
> the features 
> > is to send a request to an AOR with registrations and use 
> callerprefs 
> > to request routing to a device with those features.
> > 
> > Or, one might learn about capabilities because they are returned 
> > attached to a contact in a dialog, and then one avails 
> oneself of the 
> > capabilities by sending a subsequent request to that contact.
> > 
> > Now maybe this draft implies no more - that the 
> capabilities are ones 
> > that I can get access to by sending a request to the 
> address I find in 
> > the Route header. But of course its not normal to send a 
> request with 
> > the R-URI being an address taken from a Route header.
> > 
> > I think this is the usual thing - there is a framework within which 
> > this makes sense, but its defined in IMS. And as usual, the 
> > inclination is to
> > say: please say more than that you want this to use in some 
> > unspecified way with IMS.
> > 
> >         Thanks,
> >         Paul
> > 
> > > Dealing with call feature interactions
> > >
> > > In a deployment where different intermediaries provide
> > different call
> > > features it is sometimes necessary to be able to detect 
> that another 
> > > intermediary has invoked a particular feature as that may
> > mean that a
> > > particular feature should not be invoked or should be
> > invoked in a way
> > > that takes account of the invocation of the feature by the other 
> > > intermediary in order to prevent conflicts between
> > different call features.
> > 
> > So in this case it is not about detecting *capabilities* 
> that might be 
> > used, but rather about detecting behavior that is already being 
> > applied?
> > 
> > > Detecting the presence of a SIP PBX
> > >
> > > SIP PBXs may be present in a network and may provide call
> > features and
> > > other services on behalf of the UA. In some cases the UA 
> may need to 
> > > address requests to the PBX to invoke some features or services.
> > 
> > This is more what I was getting at. But its not clear to me 
> what the 
> > model is for "addressing requests to the PBX to invoke some 
> features 
> > or services".
> > 
> > > Although presence of the PBX could be indicated using
> > configuration this
> > > isn't really effective when there are mobile UAs moving between 
> > > enterprise networks that have PBXs and public networks that don't.
> > >
> > > Detecting the presence of a telephony application server.
> > >
> > > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a
> > Telephony
> > > Application Server (TAS) that provides call features on
> > behalf of the
> > > UA. However not all 3GPP networks will necessarily deploy
> > MMTel so it is
> > > necessary that a UA be able to identify that a TAS is
> > involved in the
> > > call and be able to send requests such as REFER to the TAS
> > in order to
> > > perform functions like call transfer. Having the TAS 
> always act as a 
> > > full B2BUA and overwrite the Contact is not a good solution
> > as this will
> > > cause the loss of the GRUUs of the far end UAs.
> > 
> > This begs some higher level model of the possible components in a 
> > system and their potential relationships to one another. I 
> realize IMS 
> > has this, that doesn't help in defining this in the ietf 
> context. We 
> > are starting to have such things in the work that was done 
> in BLISS. 
> > But I don't know if that is similar. And of course a bunch of ietf 
> > folk believe that IMS has it all wrong.
> > 
> > > In addition since the same intermediary may perform
> > multiple features or
> > > services it is useful for the URI that is provided to 
> identify the 
> > > related call feature or service so that when the UA
> > addresses a request
> > > to the intermediary the intermediary knows what feature or
> > service the
> > > request is related to.
> > >
> > > Some detailed comments:
> > >
> > > Section 6
> > >
> > > NOTE: If a route set is built using Path, Record-Route or Service-
> > >
> > > Route header fields, any inserted feature tag will be
> > copied into the
> > >
> > > associated Route header fields, together with other header field
> > >
> > > parameters. This specification does not define any 
> specific meaning
> > >
> > > of the feature tags present in Route header fields in such cases.
> > >
> > > I think the meaning of the feature tag in the Route header
> > is the same
> > > it means that the entity whose URI is on the Route supports
> > the feature
> > 
> > Yes. Those other headers only exist to form Routes. I would 
> think that 
> > it is presence on the Route that would matter, except in 
> cases where 
> > presence on Record-Route leads something along the way to block the 
> > call.
> > 
> > > Section 7
> > >
> > > I think the direction issue may need more work. It would 
> I think be 
> > > useful to indicate the directionality.
> > >
> > > I believe that SIPCORE should adopt this and work on a solution.
> > 
> > I hear you. Lets see what others have to say.
> > 
> >         Thanks,
> >         Paul
> > 
> > > Andrew
> > >
> > > *From:*[e-mail]
> > [mailto:[e-mail]] *On
> > > Behalf Of *Christer Holmberg
> > > *Sent:* Tuesday, December 07, 2010 7:38 AM
> > > *To:* [e-mail]
> > > *Subject:* [sipcore] Draft new version: 
> > draft-holmberg-sipcore-proxy-feature
> > >
> > > Hi,
> > >
> > > I've submitted a new version of the proxy-feature draft.
> > >
> > > It now contains more use-cases, for which the usage of the
> > draft have
> > > been discussed in 3GPP.
> > >
> > > In the examples there is also some wording about why the
> > usage of the
> > > Contact header field is not seen as appropriate.
> > >
> > > I have added some text about the "direction" of capabilities.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > > 
> > 
> ---------------------------------------------------------------------
> > > This transmission (including any attachments) may contain
> > confidential
> > > information, privileged material (including material
> > protected by the
> > > solicitor-client or other applicable privileges), or constitute 
> > > non-public information. Any use of this information by
> > anyone other than
> > > the intended recipient is prohibited. If you have received this 
> > > transmission in error, please immediately reply to the
> > sender and delete
> > > this information from your system. Use, dissemination,
> > distribution, or
> > > reproduction of this transmission by unintended recipients is not 
> > > authorized and may be unlawful.
> > >
> > >
> > >
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >