Subject: RE: [Sipping] Service Identification in SIP

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

Hi Steve,

My responses inline

Andrew 

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

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

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.

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

<AA> 
Well then we are in big trouble because what you are proposing is that
its OK for bodies outside of IETF to create non interoperable extensions
for the behavour of SIP entities. This will result in the fragmentation
of SIP into different flavors that don't interoperate. This is the
balkanization of SIP that Paul talks about.even
<AA> 

----------------------------------------------------

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.

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

<AA> 
Unless IETF is willing to standardise all services and mandate that all
SIP entities understand these (which will never happen) then we cannot
assume that all networks and all endpoints understand and use the same
identifiers. It is possible through configuration for an endpoint to
obtain the identifiers used by its own service provider but there is no
way to ensure that other networks use or understand the same identifiers
for the equivalent or similar service that is compatible at the session
layer. Therefore we need to support the possibility to have different
identifiers in different networks in order to not violate the TS 23.228
requirement:

12.	The usage of communication service identifiers shall not
adversely affect interoperability between IMS networks and
interoperability with external SIP networks and CS networks. The
behaviour of a network receiving the IMS requests without an IMS
communication service identifier is a matter of operator policy. Usage
of communication service identifiers shall not decrease the level of
interoperability with networks and UEs that are unaware of the
communication service identifier.

If the originating service logic isn't invoked based on an identifier
placed in the request by the originating terminal on what basis do you
think it is invoked? How does the use of Accept-Contact have advantages
in this case?
<AA> 

--------------------------------------

 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. 

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

<AA> 
As I had stated in an earlier email on this subject a proxy can do a lot
of things (including routing based on your favorite number appearing in
a call-Id) but that doesn't mean they are a good idea or a good design
decision. If you want to ensure you don't break things then you need to
be careful to use SIP headers with the semantics intended for them
otherwise problems can result if extra semantics are put upon existing
headers.
<AA> 

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.

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

<AA> 
My understanding is that local policy may determine that additional
nodes need to be routed to in addition to the Route contained in the
request. However deleting existing Route headers other than the Route
header containing the address of the proxy as part of the loose routing
procedures is liable to break things and is not part of RFC 3261 routing
(loose routing).
<AA> 

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

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

<AA> 
Yes but in the general case the UA doesn't need to know what the service
identifier is it obtains through Presence a Service URI that contains
the Service identifier as a URI parameter. The great thing about using
Presence to obtain a Service URI is that the originating UA doesn't even
need to know anything about service identifiers at all for this to work.
It just uses Presence to find the URI to use for the service which can
be indicated to the user via an indication such as a graphic icon (e,g a
phone for telephony, smiley face for IM, etc) in the presence document.
<AA> 

-----------------------------------

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

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

<AA> 
I don't understand this response either. The key point is that UAs in
corporate networks and in the internet are not going to deploy 3GPP
flavor services and use the same 3GPP service identifiers or even
possibly any service identifiers at all. The Accept-Contact based
proposal assumes that all endpoints understand the service identifiers
to be used for each service. This concept is not generally applicable
and create interoperability problems.
<AA> 

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.

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

<AA> 
How does a PSTN gateway in another domain from the terminating network
know the service identifier for telephony used in the terminating
network with the Accept-Contact header based proposal? 
<AA> 

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

---

---------------------------------------------------------------------
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: Mon, 19 Feb 2007 12:00:11 +0100

Hi Andrew,

I see that in your assumptions, the originating and terminating networks
use different service identifiers, and I presume that this is for the
same service.  In my understanding, it is the same service identifier
that is used end-to-end (if not it is interworked).  That is why I do
not see the reliance on Presence being necessary.  In my opionion this
totally within the requirements of TS 23.228 (I think that different
service identifiers in different networks for the same service is
against TS 23.228).

This comes to the isssue of the PSTN gateway - I presume that you want
to go to the PSTN gateway if the service is telephony, and within that,
voice.  If we know that, then the we go to any PSTN gateway, and we
can't presume a particular network for a PSTN gateway. 

Best Regards,

Steve.

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

Hi Steve,

My responses inline

Andrew 

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

Hello Andrew,

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>

<AA>
balkanization of SIP that Paul talks about.even <AA> 

<Steve>

<AA>

<Steve>

<AA>

<Steve>

<AA>

<Steve>

<AA> 

<Steve>

<AA> 

<Steve>

<AA> 

*flame away*

Regards,

Steve

---

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

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Feb 2007 07:33:25 -0600

Hi, Steve,

The distinction you're making here seems to capture the the biggest 
question - are we expecting service identifiers to be end-to-end, if not 
interworked, or are we expecting them to be different for the same service 
in originating and terminating networks.

Thanks,

Spencer

From: "Stephen Terrill (MI/EEM)" <[email-masked]>

Hi Andrew,

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 20 Feb 2007 14:48:43 +0100

Hi Spencer,

I was a little suprised to understand that this was a difference of view
on this point.  Maybe it is confusing a little the User interface from
the "communication service" being identified.  In my understanding,
however, it is the same service identifer that should be used in the
originating network and terminating network - and indeed there was a
liaison from an operator community that see that want to use this for
identifiying the requested service between operators as well.  Of
course, nothing can prevent an operator from
inteworking/upgrading/downgrading in their own network ...

Best Regards,

Steve.

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 2:33 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Hi, Steve,

The distinction you're making here seems to capture the the biggest
question - are we expecting service identifiers to be end-to-end, if not
interworked, or are we expecting them to be different for the same
service in originating and terminating networks.

Thanks,

Spencer

Hi Andrew,

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2007 09:59:49 -0500

Stephen Terrill (MI/EEM) wrote:
> same service. 

What do you mean by "same service"?

If two organizations independently develop comparable functionality, is 
it the same service? If so, then having a common name for it cannot be 
expected.

Or is it only the same service if everyone who is going to interoperate 
has agreed to a common definition of the service? In that case, what 
forum is used to establish the agreement? And is the definition 
available to all who might want to support it? Or is the definition 
itself restricted?

IMO many of the most useful "services" are simply combinations of 
standard pieces, and don't require any agreement on a name, or any 
explicit agreement between interoperating parties. I would hate to see 
services that *can* be achieved this way being moved into the other 
category.

We already have things that do require agreements among the 
interoperating parties. Naturally sip itself is one, as is SDP. We have 
made those public standards. Codecs are another example, and they are 
mostly standard too, though I guess proprietary codecs are possible. 
MIME types are something else like this - that might be applicable to 
"services" using MESSAGE or MSRP.

Where something else must be standardized between the interoperating 
parties, then I hope it will follow the same kind of pattern. And I hope 
it won't be used if one of the other techniques can be used.

	Paul

> In my understanding, it is the same service identifier