Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Fri, 16 Feb 2007 01:14:46 -0500

Some comments on Stephen's comments on the draft:

-Moving onto the proposed solution draft itself, in addition for
providing for the identification of the "application" and the
"communication service", I have a few additional thoughts.

The draft seems to have the implication that all services (communication
services in other terminology) that are to be identified have to be
standardised within the IETF.  This is clearly an restriction that will
not be acceptable to the industry as a whole.  My guess is that if such
a statement is mandated by the IETF, it will just be words on paper
which would likely be ignored in practice by other standardisation
organisations.

[AA] This I think is an incorrect interpretation of the draft. My
understanding is that the only services according to the draft that
require some standardisation in IETF are those that by their very nature
cannot interoperate unless there is some common additional understanding
between the endpoints outside of what is currently specified in SIP. The
use of SIP option tags with Require header is proposed by the draft for
this purpose as such services create interoperability issues with SIP.

The draft also only recognises the case where all explicitly knowledge
of the service is required.  I think it would also be good to allow the
case where knowledge of the service would be helpful, but not explicitly
required.  This could be a case where the service to the end-user would
not be degraded if this was not supported.  This functionality seems to
be missing.

[AA] Service URIs are defined in the draft for these services where the
support by the other endpoint is not required for the session to be
sucessfully established.

The draft seems to indicate that that application servers in the network
are involved only at the request of the originating terminal.  This
seems a strange restriction.  For some network support that supports the
originating user, such as the one provided in the example "I would like
this call recorded for later retrieval", such mechanisms may make sense,
however as a general approach it seems a bit limited.  For example, in
3GPP networks there is the need to invoke application logic in the
originating side and terminating side, not only at the request of the
originating terminal, but as a consequence of the requested service.  If
there is an SIP message contains indication of the requested service, a
proxy can do this (or loose route to an AS that contains the necessary
service logic). 

[AA] The draft supports both possibilities using the Route header for
originating network servers that need to be involved in the route and
based on the terminating networks routing policy for the Service URI in
the Request URI.

 I note here that the proposed service URN does not contain the address
of a specific server containing the application logic.  An AS can look
at that, and loose route to an application server that does contain such
logic (If it is separated from the proxy), however I fail to see the
difference for that proxy if it looks at a feature tag, or it looks at
the service URN for this.  In both cases, it has to parse the message
for the data, and modify the routing information.  

[AA]Route headers are the SIP mechanism for requesting intermediaries to
be includede on the route of the request. There is nothing in RFC
3840/RFC 3841 that addresses using feature tags in Accept-Contact header
for any routing decisions prior to determining which of the registered
contacts the request should be forked to. Accept-Contact is not a Route
header it is merely a filter that is applied to the set of valid
contacts. Using a parameter in the filter as a service identifier has a
potential significant impact on the use of Accept-Contact for its
original purpose. 

Further, the route header could be removed in the originating network;
and it is still required to identify the service in the terminating
network.  As proxies may remove the route, it can't be used to transport
the requested service.  

[AA] Proxies arbitarily removing Route headers is a BAD thing akin to a
bull in a china shop - almost certainly going to break something. RFC
3261 summarises what proxies should be doing with Route headers:
16.12 Summary of Proxy Route Processing

   In the absence of local policy to the contrary, the processing a
   proxy performs on a request containing a Route header field can be
   summarized in the following steps.

      1.  The proxy will inspect the Request-URI.  If it indicates a
          resource owned by this proxy, the proxy will replace it with
          the results of running a location service.  Otherwise, the
          proxy will not change the Request-URI.

      2.  The proxy will inspect the URI in the topmost Route header
          field value.  If it indicates this proxy, the proxy removes it
          from the Route header field (this route node has been
          reached).

      3.  The proxy will forward the request to the resource indicated
          by the URI in the topmost Route header field value or in the
          Request-URI if no Route header field is present.  The proxy
          determines the address, port and transport to use when
          forwarding the request by applying the procedures in [4] to
          that URI.

   If no strict-routing elements are encountered on the path of the
   request, the Request-URI will always indicate the target of the
   request.

[AA] Generally a UA wouldn't know the appropriate service identifiers
used in the terminating network or whether a Route header is appropriate
to be used in the terminating network. The draft defines the Service URI
for the purpose of identifying services in the terminating network and
service URIs can be obtained using Presence.

>From this perspective it is not clear to me the advantage of using a
service URN in a route header compared to the use of a feature tag.

[AA] I hope the above responses clarify that somewhat. Also the Service
URN and Service URIs allow different service identifiers to be used in
the originating and terminating network for session compatiable services
instead of forcing everyone to deploy and understand the same service
and service identifier.

The draft seems to mandate GRUU - is this really so, is that really
necessary.  It seems strange to place such a dependency, it also starts
to move the GRUU as being the primary means of which to contact a user.

[AA] My understanding is that GRUU in the draft is used to address how a
request addressed to Service URI is forked only to those contacts that
support the service identified by the that Service URI. A contact would
seem to be fine so long as it had GRUU properties - no need to obtain a
GRUU if you already have one.

This implies that the originating user decides which terminal I should
receive my requested service on, even if I have two devices for that.
As such, I don't believe that there should be a dependency on GRUU.

[AA] If you have obtained a Service URI (probably through presence) for
that user then you can address the request to the Service URI which
represents all the terminals that support that service. However GRUU and
the Service Instance URIs created from GRUUs provide another mechanism
through which a user can obtain a URI to reach that user for the
required service.

Parts of the draft seems to rely on the use of presence.  While presence
could be a supportive mechanism, I doubt that we can mandate that the
number you want to dial has be available in presence as I assume not all
entities are available in presence (diallable network services, users in
the PSTN).  This would be strange to mandated.

[AA] PSTN gateways are presumably in the same domain as the terminating
proxy and therefore these PSTN gateways can be configured with the
appropriate service identifiers for telephony services and can include
this in either a Route header to route to the right application server
or can construct a valid Service URI. The real problem is how do users
in other networks know what the service identifier that's is used in the
terminating network is. The use of Service URIs and Presence provides a
solution to that problem.

Moving on from the draft I have seen the questioned raised about "why
can't we expand the power of SDP".  Such an approach would mandate that
SIP methods use SDP, I don't think that is appropriate. 

[AA] I agree with you here

I hear the appeals that the mechanisms should not be abused, and that we
should not have 1000s of separate "communication services", and I fully
agree with this. I see a smaller number of communication services, not a
larger number; where those communication services are used to access
other end-user-services.

*flame away*

Regards,

Steve

---

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, February 11, 2007 5:50 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

I've attempted to re-read the threads that Gonzalo referred to, and the
major limitation that I see is the lack of any concrete example of why
these identifiers are needed.  Probably the IMS people have discussed
this so many times that they've forgotten the detailed rationale behind
the requirement.  But I'm a net-head, (and most of the people here are
net-heads) and the SIP systems that I've dealt with show no evidence of
needing "service identification", they're pure proxies, and requests are
passed transparently end-to-end.

Could somebody please lay out an example showing the utility of service
identification?

   From: "Salvatore Loreto (JO/LMF)" <[email-masked]>

   I think that everyone here agree that there is the possibility to use
a
   media in different ways, and that we need a distinction about what
the
   capabilities are and how they are used, whatever will be the
mechanism
   that at the end we will identify to do that.

Respectfully, I disagree.  We do need ways of identifying the
capabilities of SIP agents and transports, but I see no necessity of
creating specified bundles of capabailities, and then constraining
dialogs to require an initial agreement as to which bundle of
capabilities will be used.

One of the central features of Internet architecture is that agents
negotiate compatibility on a feature-by-feature basis; there are no
"profiles" which must be known on a network-wide basis.  (And I have
observed that this feature is of significant commercial value.)

In regard to identifying an "application" to process the dialog (and I
use "application" in a standard computing way), I see no reason that a
user cannot select URI-parameters to append to his AOR, and arrange for
his UA to route invites with those URI-parameters to the appropriate
application.  (And given the rich mechanisms for redirection in SIP, the
application need not even reside at a UA which is registered for the
AOR.)  These URI-parameters can be formally or informally standardized,
or established ad-hoc by each user.

In regard to PoC (as someone said, "a specialized floor-control
protocol") and similar features, SIP currently has mechanisms for
indicating support of features and requiring that a recipient support a
feature before accepting a call (the Supported and Requires headers, and
simply using the feature).  The only limitation I can see that might
need to be addressed is that there is no way to create an option tag for
a new feature that one has invented that is not yet thoroughly
standardized.

But I now discover RFC 3261 section 8.1.1.9:

   The option tags listed MUST only refer to extensions defined in
   standards-track RFCs.  This is to prevent servers from insisting that
   clients implement non-standard, vendor-defined features in order to
   receive service.  Extensions defined by experimental and
   informational RFCs are explicitly excluded from usage with the
   Supported header field in a request, since they too are often used to
   document vendor-defined extensions.

So I see that as a fundamental architectural decision, SIP does not
permit sending INVITEs that require specialized recipients, excepting if
the specialization is standards-track.

Dale

_______________________________________________
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

_______________________________________________
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

---------------------------------------------------------------------
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.

_______________________________________________
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: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Fri, 16 Feb 2007 09:51:00 +0100

Hello Andrew,

Thanks for your comments.  I have a couple of brief responses below.

Best Regards,

..//Steve 

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 7:15 AM
To: Stephen Terrill (MI/EEM); [email-masked]
Cc: Andrew Allen
Subject: RE: [Sipping] Service Identification in SIP

<Steve>
My comment applies even for these services
</Steve>
----------------------------------------------------

<Steve>
I don't see the advantage of having different solutions for the
originating network and the terminating network.  I don't think that the
originating logic is invoked only at the request of the originating
terminal.
</Steve>
--------------------------------------

<Steve>
I don't believe there is anthing that states a Proxy CAN NOT route to
applications or application logic based upon elements in the SIP
message, including what is in the Accept-Contact header (some people
have even proposed SDP ...).
</Steve>

<Steve>
The first sentance is interesting "In absence of local policy to the
contrary", indicating that there can be different policies.  I
understand that some proxies do remove this.  While I am on this - I
have lead to believe that R-URI parameters may also be removed by
intermediate proxies - is this correct?
</Steve>

<Steve>
I don't get the above paragraph.  It suggest that the "appropriate
service identifier" used in the terminating network is not known by the
originating UE, but the Service URI is.  I thought that the service URI
is an encoding of the "appropriate service identifier".
</Steve>
-----------------------------------

<Steve>
Nope, don't get it, but are information that is carried end-to-end ....
And as far as I see, could be used by intermediate proxies to impact
local routing policy ... Or ?
</Steve>

<Steve>
Again, presence could be a useful mechanism, but I think it would be a
problem for the draft to rely it.  A user making a call to the PSTN may
not find that user in the presence archicture (and similar to services
like the 800 or 900 services).  (I should note, that you shouldn't make
any assumptions about the location of the PSTN gateway ... But I don't
think that changes anything).  
</Steve>

*flame away*

Regards,

Steve

---

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, February 11, 2007 5:50 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Dale

---------------------------------------------------------------------
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.