Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Wed, 21 Feb 2007 22:04:51 -0500

Hi Steve

In my view this is one of the interoperability issues with your
proposal. I think the assumption that all networks will deploy exactly
the same services with the same service identifiers is unrealistic and
also undesirable. Are corporate PBX vendors going to implement the same
services as defined by 3GPP or OMA? The possibility to have the
flexibility to have different service identifiers for session equivalent
services is in my view essential to any IETF standard and to do
otherwise is to create a situation where basic services like telephony
or messaging cannot interoperate between users in different networks and
users in the internet without the use of inter working gateway. SIP and
SIMPLE were setup specifically to create protocols that would enable
interoperability with IP networks without the need for gateways. 

If 3GPP network operators choose to deploy the same services and use
common identifiers that is fine but there are whole other worlds out
there as well and service identifiers should not stand in the way of
interoperability between all these different SIP users. If the IETF
solution supports the ability for different networks to use different
identifiers that doesn't violate 3GPP requirements and doesn't prevent
3GPP using the same identifiers in different networks. I don't see how
that is against TS 23.228.

Andrew

-----Original Message-----
From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 6:00 AM
To: Andrew Allen; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

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,

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.

---------------------------------------------------------------------
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: Thu, 22 Feb 2007 09:22:18 +0100

Hi Andrew,

I have the opposite view.  I think that if the originating network and
the terminating network are going to interoperate, then they will have
the same understanding of the service, hence in my view the same
"identifier".  To have otherwise is problematic and complicated (the
operators will have to have a higher admininstrative effort in order to
understand how they should interconnect).

The PBX case is more complicated than can be responded to in a single
sentence - as there are many ways in which the PBXs are connected
together.  In one case - the PBXs are just treated as a terminal with
many users; and the service that the operator provides is really the
same basic service as is provided to other users (with maybe more
subscriber specific logic).  In other cases, the operator just provides
routing and connecting support, and here the service provided by the
operator is different; but I would assume that the peer PBXs had better
have a common understanding of the service (which they would if it was
the same vendor), or again there will be inter-operatability issues.

Regarding the URI parameter proposal, don't we have proxies that remove
additional R-URIs - it seems a natural thing to remove it also in e.g.
fowarding services etc ...

Regards,

Steve.

-----Original Message-----
From: Andrew Allen [mailto:[email-masked] 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: Thu, 22 Feb 2007 09:22:18 +0100

Hi Andrew,

Regards,

Steve.

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

Hi Steve

Andrew

-----Original Message-----
From: Stephen Terrill (MI/EEM) [mailto:[email-masked]]
Sent: Monday, February 19, 2007 6:00 AM
To: Andrew Allen; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

Hi Andrew,

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

[AA] This I thi] 
Sent: Thursday, February 22, 2007 4:05 AM
To: Stephen Terrill (MI/EEM); [email-masked]
Cc: Andrew Allen
Subject: RE: [Sipping] Service Identification in SIP

Hi Steve

Andrew

-----Original Message-----
From: Stephen Terrill (MI/EEM) [mailto:[email-masked]]
Sent: Monday, February 19, 2007 6:00 AM
To: Andrew Allen; [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

Hi Andrew,

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>

<AA>

<Steve>

<AA>

think it is invoked? How does the use of Accept-Contact hank is an incorrect interpretation of the draft. My

<Steve>

<AA>

<Steve>

<AA>

<Steve>

<AA>

<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 ve advantages
in this case?
<AA> 

<Steve>

<AA>

<Steve>

<AA>

<Steve>

<AA> 

<Steve>

<AA> 

[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 telthe loose routing
procedures is liable to break things and is not part of RFC 3261 routing
(loose routing).
<AA> 

<Steve>

<AA> 

<Steve>

<AA> 

<Steve>

<AA> 

*flame away*

Regards,

Steve

---

ephony services and can include

<Steve>

<AA> 

*flame away*

Regards,

Steve

---

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 22 Feb 2007 17:43:27 -0500

I would hope that if they are hell-bent on doing this, that they at
least also define a service identifier that means "IETF = service
intentionally left unspecified", but not in so many characters.  Then
make sure that compatibility is specified when such an identifier is
encountered, such as when an INVITE were to come from a non-3GPP system
with no service identity provided.

Mike

> Sent: Wednesday, February 21, 2007 10:05 PM
> In my view this is one of the interoperability issues with 
> your proposal. I think the assumption that all networks will 
> deploy exactly the same services with the same service 
> identifiers is unrealistic and also undesirable. Are 
> corporate PBX vendors going to implement the same services as 
> defined by 3GPP or OMA? The possibility to have the 
> flexibility to have different service identifiers for session 
> equivalent services is in my view essential to any IETF 
> standard and to do otherwise is to create a situation where 
> basic services like telephony or messaging cannot 
> interoperate between users in different networks and users in 
> the internet without the use of inter working gateway. SIP 
> and SIMPLE were setup specifically to create protocols that 
> would enable interoperability with IP networks without the 
> need for gateways. 
> 
> If 3GPP network operators choose to deploy the same services 
> and use common identifiers that is fine but there are whole 
> other worlds out there as well and service identifiers should 
> not stand in the way of interoperability between all these 
> different SIP users. If the IETF solution supports the 
> ability for different networks to use different identifiers 
> that doesn't violate 3GPP requirements and doesn't prevent 
> 3GPP using the same identifiers in different networks. I 
> don't see how that is against TS 23.228.
> 
> 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.
> 
> 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: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Feb 2007 18:28:59 -0500

> the same vendor), or again there will be inter-operatability issues.

What will happen here if the pbx calls an address on a 3gpp network that 
is using some set of service definitions? Or visa versa.

Will the PBX, that specifies no service but that includes audio and 
video, be able to establish an audio/video call? Or will it somehow have 
to know the service id that the IMS system expects for audio/video calls?

	Paul

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Fri, 23 Feb 2007 13:22:10 +0100

Hi Paul,

The specification would be open on this (i.e. I cannot see the
specifications saying that this is rejected) as such, the situation when
a PBX (or any terminal) doesn't use a service identifer would be a
matter for operator policy (and maybe internconnect policy).  I would
assume the operator would make a guess at what the requested
communication service was ... E.g. SDP=voice (without something
indicating PoC) would be a stronge hint to assume this is multimedia
telephony.

BR,

..//Steve

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 12:29 AM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

> operators will have to have a higher admininstrative effort in order 
> to understand how they should interconnect).
> 
> subscriber specific logic).  In other cases, the operator just 
> provides routing and connecting support, and here the service provided

> by the operator is different; but I would assume that the peer PBXs 
> had better have a common understanding of the service (which they 
> would if it was the same vendor), or again there will be
inter-operatability issues.

Will the PBX, that specifies no service but that includes audio and
video, be able to establish an audio/video call? Or will it somehow have
to know the service id that the IMS system expects for audio/video
calls?

	Paul

> Regarding the URI parameter proposal, don't we have proxies that 
> remove additional R-URIs - it seems a natural thing to remove it also
in e.g.

> also undesirable. Are corporate PBX vendors going to implement the 
> same services as defined by 3GPP or OMA? The possibility to have the 
> equivalent services is in my view essential to any IETF standard and 
> to do otherwise is to create a situation where basic services like 
> telephony or messaging cannot interoperate between users in different 
> networks and users in the internet without the use of inter working 
> gateway. SIP and SIMPLE were setup specifically to create protocols 
> that would enable interoperability with IP networks without the need
for gateways.

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

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

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

> 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).
> 
> based on the terminating networks routing policy for the Service URI 
> in the Request URI.
> 
> <Steve>
> 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:
> 

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

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

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

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

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

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

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

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

> 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.
> 
> 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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 09:39:10 -0500

> understand how they should interconnect).

This is exactly what will lead to total balkanization and siloization of 
IP-based communications systems.

We achieve interoperability by defining standards around how SIP works. 
What you are basically saying above is that IETF standards are not 
sufficient for operators to interwork and interconnect, and instead they 
will need to all get together and discuss what services run on their 
network, define identifiers for them, and agree on how those match up. 
In what way is that not a recipe for complete balkanization and 
interoperability failures? In what way is such a view not anathema to 
the entire purpose of standardization?

If we have done our jobs right, all you need to interwork is to look at 
the SIP message, and based on the standards we have defined, you will 
know exactly what is being requested. If SDP contains audio and video, 
you know that a phone is asking for an audio/video call. If it contains 
MSRP then you know its asking for a text chat session. We go through a 
lot of effort to standardize these things so that we have 
interoperability between vendors and networks. We carefully design 
fallbacks and backwards compatibility schemes so that we get 
least-common-denominator service when heterogeneous devices 
interconnect. I believe it is critical that we not bypass all of that 
machinery by requiring that providers define and agree upon services for 
interworking.

This is why I suggest that, if you have in fact defined a 'service' 
which cannot interoperate at all unless the other side has understood 
it, then you have in fact introduced a non-backwards compatible 
extension to SIP. You signal that with Require. Does this make it hard 
to go and standardize lots of these? ABSOLUTELY! That is what we want. 
The bar should be quite high for defining non-backwards compatible 
extensions, so that we preserve interoperability across heterogeneous 
networks. I hope that there are as few of these as possible, not lots. 
If PoC is already there, then so be it - let us define a tag for it, put 
it in Require, and be done. I hope that is the first and last such 
service tag we need to standardize.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 09:46:21 -0500

My fear is that the overall experience will be exceptionally poor, even 
if the endpoints interoperate.

As the 3gpp requirements indicate, they want to drive lots of different 
things from this service identifier. For example, QoS treatment, billing 
and charging, invocation of network applications, features, and so on. 
My worry is that, if 3gpp defines a service for, say, "messaging", and 
it makes use of a service tag, and a non-3gpp endpoint calls a 3gpp 
endpoint with MSRP and without such a service tag, even if you get the 
two endpoints to connect, the overall experience for both users will be 
bad because the network QoS treatment will be inadequte, the 3gpp user 
won't be billed correctly, supplementary features won't work (say, 
message logging or chat history), and so on.

The notion that I need to have, for each and every call, some kind of 
"service identifier" in the message, in order to successfully process a 
call (where successfully includes everything that needs to be done for 
correct user experience), is anathema to the very notion of SIP, IP, and 
internetworking. It is nothing short of complete balkanization and 
segmentation of communications systems into non-interoperable islands 
that will substantially and permanantly raise the cost and complexity of 
IP communications.

Despite my dire warnings about the end of civilization as we know it, if 
you really want to go off and build totally isolated communications 
networks, then we have a mechanism for it - its called Require. Use it. 
Sparingly.

-Jonathan R.

Michael Hammer (mhammer) wrote:

>>(communication
>>extensions
>>advantages
>>appropriate
>>terminating
>>and delete

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 26 Feb 2007 18:32:07 +0100

Hi,

I don't think that being able to identify services leads to any of the
mentioned "-sation"s of SIP [well maybe industralisation ;-)], except to
recognise that there are different services on SIP and that the media
does not give the service (we can also start the session without media
...).  At what point can it be said that SIP is "-ised" - or at what
point to the SIP police say that this is breaking SIP?  If it doesn't
get to all UAs?  If it doesn't go to all UAs that could do something
useful with it?, If it doesn't go through a SIP proxy? ... Sometimes
trying to deliver a service instead of rejecting the service due to
incomptabilities can lead to a bad user experience - is that the best
thing to do, or is that OK because the SIP protocol still connected? [I
think that Jeroen captured this quite well in one of his emails]. I note
that the second point raised, does handle this, leaving the question of
a middle ground as well (i.e an indication of the service without it
being "REQUIRED").

I think that it is better that the industry provides a common way to do
this, instead of "looking into the SDP in one case, looking into the
accept contact in another case" etc, that seems more complicated than
necessary ....  

I noticed that in the BLISS group there was discussions on what
assumptions could be made - i.e. the particular example being discussed
was DND and whether it should be in the terminal or in the network.  If
something comes out of that - won't that be, by default, a service
definition or some sort.  It would be strange if that was the only
service definition allowed ...

Regards,

Steve

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 3:39 PM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 14:23:48 -0500

inline.

Stephen Terrill (MI/EEM) wrote:

> ...).

And I don't see how you can argue that point. Merely stating it does not 
make it so.

To me, its really simple. If 3gpp goes and defines a service parameter 
for "conversational telephony" and gives it some name, and puts it into 
Accept-Contact, then the ability to receive a call from a non-3gpp 
entity is ruined, since such a call will not include this parameter. 
Thus, the right QoS treatment, billing, call processing, etc. will not 
happen.

In what way is this NOT balkanization? Please be specific.

>  At what point can it be said that SIP is "-ised" - or at what

We have a mechanism for you to cause a call to fail if compatible 
extensions are not supported (Require). If business requirements say 
that this is the desired result, then use the tool. I certainly don't 
hope that this is what you want for the common case. I can see how it is 
the right thing for PoC, but thats about it.

> accept contact in another case" etc, that seems more complicated than

I disagree completely.

THis is like saying that we should put everything that a SIP message 
might indicate into a single "indicate" header, rather than invent new 
headers, methods, put stuff in bodies, and so on. The 'service' is 
nothing more or less than a summarization of the functionality that 
results from the message being sent, and that functionality includes 
everything from the method to the body.

> service definition allowed ...

I sent another note on sipping on this topic. These are related problems 
but differ quite fundamentally, since in those cases I am not requiring 
the other party to know anything about this; its a matter of control 
between a UA and its own domain. Even in that case, we are agreeing that 
we want to be as flexible as possible to what constitutes these 
services, and not standardize what it is.

-Jonathan R.

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 27 Feb 2007 07:51:36 +0100

Inline. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 8:24 PM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

inline.

> mentioned "-sation"s of SIP [well maybe industralisation ;-)], except 
> to recognise that there are different services on SIP and that the 
> media does not give the service (we can also start the session without

> media ...).

<Steve>
... Finally some motivation as to why it is said that the service
identifier is balkanization (uptill now has been "Merely stating it"),
however I don't see this in the same way.    The "balkanization effect"
will come from whether or not an operator wants to interconnect to the
general internet or not, which has nothing to do with being able to
identify the requested service.  An operator supporting the services,
will also be ability to make a "guess" at what the incoming requested
communication is.  Having made that guess, it will assume the rest of
the communication to follow according (and reject attempts to the
opposite).  Such interworking is nothing new.  As such, I do not see
that this reduces interworking at all.
</Steve>

>  At what point can it be said that SIP is "-ised" - or at what point 
> to the SIP police say that this is breaking SIP?  If it doesn't get to

> all UAs?  If it doesn't go to all UAs that could do something useful 
> with it?, If it doesn't go through a SIP proxy? ... Sometimes trying 
> to deliver a service instead of rejecting the service due to 
> thing to do, or is that OK because the SIP protocol still connected? 
> [I think that Jeroen captured this quite well in one of his emails]. I

> note that the second point raised, does handle this, leaving the 
> question of a middle ground as well (i.e an indication of the service 
> without it being "REQUIRED").

> 
> I think that it is better that the industry provides a common way to 
> do this, instead of "looking into the SDP in one case, looking into 
> the accept contact in another case" etc, that seems more complicated 
> than necessary ....

I disagree completely.

<Steve>
I see this differently - I think that using different means in different
cases to identify the requested services is more parrallel to indicate
redirection of "moved perminatly" with a 301 response, by "moved
temporarily" through a completely different means, like introducing a
new response header ... Than it is to saying that we put all indications
into an "indicate" header.

Of course the full capabilities of SIP should remain - such as using SDP
to identify the requested media.
 
</Steve>

> assumptions could be made - i.e. the particular example being 
> discussed was DND and whether it should be in the terminal or in the 
> network.  If something comes out of that - won't that be, by default, 
> a service definition or some sort.  It would be strange if that was 
> the only service definition allowed ...

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 27 Feb 2007 09:34:10 +0200

Jonathan Rosenberg writes:

 > It is nothing short of complete balkanization and 

this is no new news.  everyone should have known from very start of IMS
project that is nothing more that a walled garden effort where stupid
customers are made to pay more for no added value.  it should be a high
time to stop dealing with IMS or 3GPP problems on this mailing list and
put a spam filter on IMS related messages.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Feb 2007 10:15:27 -0500

inline.

> that this reduces interworking at all.

Lets talk about how one goes about doing this 'guessing'.

It would do guessing by looking at the SDP, SIP headers, option tags in 
Require and so on, and figure out what service was intended. Now, there 
are two cases. In one case, the information in the SIP/SDP is sufficient 
to match exactly to the operator definition of services, and the overall 
user experience remains good. In the other case, the information is not 
sufficient, and the user experience of calls inter-provider will 
fundamentally and forever be worse than intra-provider. I assert, we 
don't want to go down the latter route. That means that you must always 
be able to accurately determine the service from inspection of the SIP/SDP.

And this is my point.

Let me also add that this balkanization comes from sevearl specific 
problems which have been explicitly stated, despite your claim above 
that they have not. They are:

1. if caller and called party support services which overlap but are not 
the same (for example, both endpoints do video but one does IM too and 
the other doesn't), you will not be able to properly deal with this, 
since you are deriving service definitions from this one header, rather 
than inspecting the individual SDP and SIP headers that are negotiated 
to determine the actual session contents.

2. it will not work with non-3gpp providers that have no notion of what 
these services are - this is the discussion above

3. for providers that do have a notion of these service identifiers, it 
will require global agreement on what the services are and what they 
mean in order to properly interoperate. THis stifles innovation by 
moving us back to the old model where everyone had to agree on the 
services in every network before they could be deployed. One of the 
stated goals of IMS is to enable feature velocity and innovation. You 
are going to kill that.

-Jonathan R.