Subject: RE: [Sipping] Service Identification in SIP

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 5 Mar 2007 11:06:29 +0100

Hi,

Inline 

BR,

Steve.

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

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

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.

<Steve>
Since we link in ASs in the network anyway, the above "issue" exists
even without the existance of identified services.  I don not see how
identifying the service can make it worse, but I see that it can make it
better.  It leaves the possibility that the downstream SIP elements can
now to behave in accordance with the service. As a worste case - it is
usually possible to perform "interworking" between service definitions.
</Steve>

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.

<Steve>
This is the situation we have today without a means to identify the
service.  Now, if we start with an overlapping media (noting that the
media is *not* the service), which service will be followed.  I will
again here clarify that messaging (as defined by OMA) and Telephony are
seperate service with separate supplemenatary services.
</Steve>

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

<Steve>
Disagree - see above.   
</Steve>

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.

<Steve>
It is true that this requires global agreement on what the services are
- this has been a successful model for global communication so far.
There are two ways that this is usually achieved - one is that there is
one vendor providing all (e.g. skype example) the other is that a number
of players in the industry have the same understanding of the service.
I see that what is being argued for with the support of the
identification of the services, is to allow multiple services on SIP,
where as alternatively it is one big service supporting many "features".

There is still plenty of room for innovation.  The basic communication
service can be used to access other services that are reached by a SIP
URN.  Further, the 3GPP requirements describe a two layer archtecture -
the communication service, an applications that use the communication
service.  The area in the applications leaves plenty of room for
inovation.

Returning to the topic of the Require header.  If I understood correctly
earlier, this implies a RFC - I don't think that is acceptable.  Is this
still on the table?  Is there a way around that?

While I am writting this email, although not on the topic I just wanted
to say I liked the rant from Eric.

</Steve>

-Jonathan R.

-- 
Jonathan D. RosFrom [email-masked] Mon Mar 05 05:07:38 2007
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Service Identification in SIP
Date: Mon, 5 Mar 2007 11:06:29 +0100
From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
To: <[email-masked]>

Hi,

Inline 

BR,

Steve.

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

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

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2007 08:21:18 -0500

> seperate service with separate supplemenatary services.

I guess I just don't "get it". What does the above mean? *Why* are they 
separate services, rather than just separate features? It sounds like 
just a way to artificially restrict some forms of usage.

This seems to say that if I have a device that can concurrently support 
audio and IM, and I call someone who uses IMS and has a device 
supporting both audio and IM, I just on one service or the other at the 
time I make a call. If I don't, perhpas because I have no idea of these 
services, then something in the network will make that choice for me. 
How is this a good thing?

	Paul

	Paul

---

From: [email-masked]
Date: Mon, 5 Mar 2007 11:03:11 -0500

But there is a third way that his has been achieved, and it is the one
used on the Internet -- there are zillions (in practice, a few
thousand) writers of end-point software developing as many
implementations, each of which implements some subset of the features
that are standardized.  Any two end-points can communicate, and
automatically they correctly use the set of features they have in
common.  The features and their user experiences are designed so that
there is no loss of user experience due to feature incompatibility
beyond what is intrinsic to the unsupported feature.

To make an example, if the IETF had defined push-to-talk, a central
requirement would be to establish what to do when a user attempts a
PTT call to a phone that is not PTT-capable, and how to ensure that
the call falls back to an acceptable user experience.

   where as alternatively it is one big service supporting many
   "features".

You say that like it's a bad thing.

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 06 Mar 2007 00:56:28 -0600

> just a way to artificially restrict some forms of usage.

That's it exactly, or at least I think it is.

Let's say you buy your phone service from Carrier A.

But you want to use an answering service from Company B.

Carrier A thinks that "service identification" will let them know by 
inspection that you're accessing an answering service from Coompany B, 
so that they can either 1) Charge you extra, 2) Block the service 
invocation, or 3) Substitute their own service for Company B's thereby 
keeping all the profit themselves.

It's all about controlling the user, preserving the billing model, and 
blocking innovative competition.

It's also about making sure that the "KidTalk" version of POC doesn't 
accidentally interoperate with the higher-priced "CorpTalk" version 
unless you subscribe to a highly-priced "gateway service".

That's right -- two phones, running effectively identical functionality, 
would not be able to talk to each other because they are invoking 
different named "services". The services might not actually be 
incompatible with each other -- or even different in any way other than 
their service name, which is probably protected "by trademark" by each 
operator, making it a criminal matter if you actually get the two phones 
to talk to each other.

Now, will they use it this way in practice, or only exercise the more 
innocuous applications of the mechanism? I'd say you have to let 
experience be the judge here.

--
Dean

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 6 Mar 2007 08:55:14 +0100

Hi Dale,

Please see inline.

Regards

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 5:03 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

   It is true that this requires global agreement on what the services
are
   - this has been a successful model for global communication so far.
   There are two ways that this is usually achieved - one is that there
is
   one vendor providing all (e.g. skype example) the other is that a
number
   of players in the industry have the same understanding of the
service.
   I see that what is being argued for with the support of the
   identification of the services, is to allow multiple services on SIP,
   where as alternatively it is one big service supporting many
"features".

<Steve>
Are these different communication services; or are they different user
interfaces on the same communication service?
</Steve>

To make an example, if the IETF had defined push-to-talk, a central
requirement would be to establish what to do when a user attempts a PTT
call to a phone that is not PTT-capable, and how to ensure that the call
falls back to an acceptable user experience.

<Steve>
Well ... I thought it was restrictive.  It starts to move towards one
huge monolithic machine in the network, and one monolithic UA in the
terminal, instead of allowing for best of breed of network support and
client support ...
</Steve>

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2007 09:04:22 -0500

> interfaces on the same communication service?

I don't care, as long as it lets me do what I want to do and interact 
with the other parties I am interested in.

> terminal, instead of allowing for best of breed of network support and

The whole point is that it is *not* a huge monolithic machine in the 
network. Instead the network gets out of the way and lets the UAs do 
what they want.

And there are plenty of opportunities for best of breed here - more than 
stovepiping everything with service ids allows.

Is anyone complaining that web browsers result in one monolithic 
application on the PC rather than allowing best of breed? No, because 
most browsers allow plugins to support extensions - including those not 
anticipated by the manufacturer of the browser or the service provider. 
And because many different browsers can and have been created that can 
interoperate.

And in the case of sip, it is also quite feasible to have multiple 
applications register with their own contact addresses, and even AORs if 
they wish.

	Paul

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 6 Mar 2007 15:43:09 +0100

Hi Paul,

Below you state the point is not to have monolythic machine in the
network, however you state that you don't see the need to differentiate
services as well.  This leads to that the network support that is
required needs to understand all the "communication services" in the
end.

It is hard to compare HTTP and SIP here I think, however the plug-in
concept could be a good parrallel to the applications that could run
over the communication services.

Regarding the multiple AoR approach, I thought that track had already
been discarded or ?

Regards,

Steve.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 3:04 PM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 6 Mar 2007 09:38:46 -0800

Paul,

You are making good points here. More specific to the "wireless
networks" (should read wires into the Internet IMHO), have you seen the
paper by Tim Wu from Columbia University?

http://www.newamerica.net/files/WorkingPaper17_WirelessNetNeutrality_Wu.
pdf 

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 8:04 AM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

> requirement would be to establish what to do when a user attempts a
PTT

they wish.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2007 14:16:52 -0500

> http://www.newamerica.net/files/WorkingPaper17_WirelessNetNeutrality_Wu.

Yes. It is good.

But what is all this about wires? I hear that the internet "is a series 
of tubes." :-)

	Paul

---

From: Eric Burger <[email-masked]>
Date: Fri, 09 Mar 2007 09:49:32 -0400

I would offer that this is precisely the way ITU-T operates.  Perhaps that
is the proper venue for such work?

HOWEVER, I would be petrified that ITU-T would do exactly what 3GPP did and
create a non-interoperable SIP variant.

------ Forwarded Message
From: "Stephen Terrill (MI/EEM)" <[email-masked]>
Date: Mon, 5 Mar 2007 11:06:29 +0100
To: <[email-masked]>
Conversation: [Sipping] Service Identification in SIP
Subject: RE: [Sipping] Service Identification in SIP

[snip]

<Steve>

[snip]
------ End of Forwarded Message

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: Eric Burger <[email-masked]>
Date: Fri, 09 Mar 2007 09:49:32 -0400

------ Forwarded Message

[snip]

<Steve>

[snip]

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 12 Mar 2007 09:21:50 +0100

Hi Eric,

This raises one question that I have.  When is SIP considered to be
broken or non-interoperable?  Is it when a new extention doesn't work
with all UAs, Is it when it won't go through a proxy, is it when the
other entity needs to understand the extention in order to fulful the
functionality.  Take GRUU for example, if a peer UA/proxy doesn't
implement GRUU, then the GRUU functionality is not provided - is that
broken?  If a peer UA doesn't understand the replaces header, is that
broken?

I don't by this statement of "non-interopable" SIP variant due to the
introduction of the identification of SIP. 

BR,

..//Steve

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 2:50 PM
To: sipping
Subject: RE: [Sipping] Service Identification in SIP

I would offer that this is precisely the way ITU-T operates.  Perhaps
that is the proper venue for such work?

HOWEVER, I would be petrified that ITU-T would do exactly what 3GPP did
and create a non-interoperable SIP variant.

------ Forwarded Message

[snip]

<Steve>

[snip]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 09:32:15 -0400

Stephen Terrill (MI/EEM) wrote:
> functionality. 

Its too early in the morning for me to try to answer the general 
question above. But I'll try the example below.

> Take GRUU for example, if a peer UA/proxy doesn't

There is no requirement that a peer understand gruu. The primary benefit 
gruu brings is to help a UA adhere to the 3261 requirement that it use a 
globally routable contact address. It has been found that many UAs 
haven't been able to do so, and gruu support (between the UA and its 
registrar) provides one.

The only reason a peer might need to understand gruu and note that its 
peer's contact is a gruu is if the peer has been using work-around 
algorithms for working with peers that violate 3261 and *don't* provide 
a globally routable contact.

So, this isn't a good example.

> If a peer UA doesn't understand the replaces header, is that
> broken?

There is an option tag that goes with Replaces. If a UAC uses Replaces, 
it can also include a Requires header if it wants the request to fail 
for UASs that don't support it. If it doesn't do so, then it must be 
prepared to accept the fact that the Replaces header may be ignored, and 
the results that follow.

Depending on the circumstance, it may be useful to use the Requires or 
not, and then trigger fallback mechanisms if the request fails.

Its only "broken" if the UAC depends on support and has no fallback if 
it isn't present. The worst case then is probably that a particular 
feature within a call doesn't work, rather than preventing the entire 
call from working. (And if the caller really doesn't want the call to be 
established unless the support is present, that is still possible by 
using Requres:replaces in the initial INVITE.

> introduction of the identification of SIP. 

One big issue, different from what is currently done in sip, is the 
siloing of all sorts of behavior, and forcing every call into one or the 
other of these silos.

	Paul

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 12 Mar 2007 14:46:59 +0100

Hi Paul,

Thanks.  Then it sounds like this is more a matter of opionion and
circumstance as to whether or not is something is brokenwhen
communicating with another entity that doesn't support something.

BR,

Steve

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 2:32 PM
To: Stephen Terrill (MI/EEM)
Cc: sipping
Subject: Re: [Sipping] Service Identification in SIP

> Take GRUU for example, if a peer UA/proxy doesn't implement GRUU, then

> the GRUU functionality is not provided - is that broken?

> If a peer UA doesn't understand the replaces header, is that broken?

	Paul

> HOWEVER, I would be petrified that ITU-T would do exactly what 3GPP 
> did and create a non-interoperable SIP variant.
> 
> ------ Forwarded Message
> 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 
> is one vendor providing all (e.g. skype example) the other is that a 
> number of players in the industry have the same understanding of the
service.
"features".
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated entities,  that may be confidential,  proprietary,  
> copyrighted  and/or legally privileged, and is intended solely for the

> use of the individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in error, 
> please immediately return this by email and then delete it.
>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 12 Mar 2007 18:19:16 +0100

I believe this is covered in RFC 4485 section 4.1.

I suspect this section should have also have said something about
Accept-Contact, but it doesn't.

Regards

Keith 

> From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 8:22 AM
> To: sipping
> This raises one question that I have.  When is SIP considered 
> to be broken or non-interoperable?  Is it when a new 
> extention doesn't work with all UAs, Is it when it won't go 
> through a proxy, is it when the other entity needs to 
> understand the extention in order to fulful the 
> functionality.  Take GRUU for example, if a peer UA/proxy 
> doesn't implement GRUU, then the GRUU functionality is not 
> provided - is that broken?  If a peer UA doesn't understand 
> the replaces header, is that broken?
> 
> I don't by this statement of "non-interopable" SIP variant 
> due to the introduction of the identification of SIP. 
> 
> BR,
> 
> ..//Steve
> 
> I would offer that this is precisely the way ITU-T operates.  
> Perhaps that is the proper venue for such work?
> 
> HOWEVER, I would be petrified that ITU-T would do exactly 
> what 3GPP did and create a non-interoperable SIP variant.
> 
> ------ Forwarded Message
> 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.
> 
> <Steve>
> There are two ways that this is usually achieved - one is 
> that there is one vendor providing all (e.g. skype example) 
> the other is that a number of players in the industry have 
> the same understanding of the service.
> identification of the services, is to allow multiple services 
> on SIP, where as alternatively it is one big service 
> supporting many "features".
> 
> [snip]
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Mar 2007 11:24:07 -0600

> broken?  If a peer UA doesn't understand the replaces header, is that

There are several questions lurking in here.

Applications are, in general, "broken" if they can't traverse normal 
proxies, or introduce abnormal proxies that break other applications. We 
have design rules for proxy transparency, and every SIP extension 
passing through IETF is vetted against these rules. Sure, it's possible 
to design a B2BUA that isn't a proxy and usually works like a proxy, but 
every one of these is a special case, and we don't consider all those 
special cases in the development of SIP extensions. See the SIPPING 
discussion on draft-marjou-sipping-b2bua-00 for examples of just what 
sort of stuff this can lead to. OMA POC has been in some danger of 
developing a problem along those lines, which is part of why we've 
started having an "option tag vs callerpref" discussion around POC.

Another sort of "brokenness" can happen when applications rely on 
capabilities that are outside the capability negotiation built into SIP. 
For example, if POC were to just rely on magically knowing that the 
terminals are POC terminals, then POC wouldn't mix with regular SIP 
because POC calls would keep ending up on SIP terminals that wouldn't 
know how to execute the application would would try and respond anyhow.

Yet another sort of brokeness occurs when two nodes that should be able 
to communicate (they're reachable, share appropriate capabilities like 
codec and communications modality, etc.) can't because they THINK 
they've been altered-from-the-norm for different mutant apps. For 
example, one might be configured to run only the "BLISS" profile where 
another is running only the "3GPP IMS Basic VoIP" profile. If the nodes 
assume that they can't communicate, simply because they have different 
profiles (without stopping to look and say "Hey, we both speak AMR, 
maybe we CAN talk"), then we have a problem. It is this latter case we 
are trying to avoid in the discussion of service identification.

So, three sorts of "broken" SIP extensions come to mind:

1) Proxy transparency defects: Extensions that break proxies or 
introduce new forwarding elements that don't meet the transparency 
requirements of proxies.

2) Non-Negotiation defects: Extensions that don't use a standard 
negotiation mechanism, but require that the extension be present, 
thereby confusing nodes that don't support the extension.

3) Feature-silo defects: Extensions that inappropriately require the 
extension to be present, thereby preventing nodes from communicating 
when the nodes would be able to communicate just fine if they ignored 
the extension.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 14:53:31 -0400

> communicating with another entity that doesn't support something.

I don't think I would agree with that.

At this point I think most people assume that 3261 will be supported. 
(We can discuss issues of 2543 compatibility if anybody thinks that is 
important.)

Beyond that, everything in SIP is driven off options. There are 
provisions to use optional things conditionally, with failover if the 
other side doesn't support them. (In that case nothing is broken if the 
peer doesn't support the option.) And there are ways (Requires) of 
forcing a request to fail if the peer doesn't support certain options. 
Nothing is *broken* in that case either, though the particular request 
doesn't succeed. However we strongly discourage designing things so that 
Requires is needed. Its considered much better to provide some kind of 
failover.

An important point here is that these options are defined via standards 
track. That gives an opportunity to discover the best way to achieve 
something, so that interoperation is maximized between those UAs that 
support an option and those that don't. And considerable effort is given 
to making options orthogonal to one another.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 15:23:03 -0400

> I believe this is covered in RFC 4485 section 4.1.

Ah, I forgot about that. Yes, that is a very good reference for this 
discussion.

> Accept-Contact, but it doesn't.

Since Accept-Contact is itself an extension, I don't know why it would 
be explicitly called out in 4485.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 15:26:52 -0400

Dean - this is an excellent categorization of the issues.

	Thanks,
	Paul

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 12 Mar 2007 20:27:42 +0100

Paul wrote:

> Since Accept-Contact is itself an extension, I don't know why 
> it would be explicitly called out in 4485. 

I regard to the use of the mechanism to deal with compatibility issues when media feature tags are used (if appropriate) versus the problems the usage itself creates.

Keith

> Sent: Monday, March 12, 2007 7:23 PM
> To: Drage, Keith (Keith)
> Cc: Stephen Terrill (MI/EEM); sipping
> Ah, I forgot about that. Yes, that is a very good reference 
> for this discussion.
> 
> Since Accept-Contact is itself an extension, I don't know why 
> it would be explicitly called out in 4485.
> 
> 	Paul
> 
> > Regards
> > 
> > Keith
> > 
> due to the 
> what 3GPP 
> identifiers, 
> that there 
> >> copyrighted  and/or legally privileged, and is intended solely for 
> >> the use of the individual or entity named in this message. 
> If you are 
> >> not the intended recipient, and have received this message 
> in error, 
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2007 15:35:38 -0400

> I regard to the use of the mechanism to deal with compatibility issues when media feature tags are used (if appropriate) versus the problems the usage itself creates.

It seems that doing so with any confidence of success would require use 
of Proxy-Require:pref, which is a big SHOULD NOT in 4485. And even if 
the proxy supports it, it isn't required to honor the request.

So it really should only be considered an optimization or a 
nice-to-have, rather than a solution to any real problem.
	
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Mar 2007 23:01:44 -0500

I've just blown through this entire thread in one sitting. I had many 
things to say along the way -- and I'll go back and touch on a small 
handful of them -- but most of the things I wanted to say can be 
summarized as:

I agree 100% and without reservation with everything Paul Kyzivat has 
said on this thread.

/a

---

From: [email-masked]
Date: Fri, 16 Mar 2007 08:52:32 -0500

Let me take a stab at it:

The basic idea is that when one introduces a new UA, one considers
using that UA to communicate with each existing UA  on the Internet.
When UA 1 attempts to communicate with UA 2, then they provide the
users use of all features/options/services that both UA 1 and UA 2
support.  Or even better, the fact that UA 1 supports it is enough for
the user of UA 2 to enjoy the benefits of the feature anyway.

(Consider music-on-hold:  When user 1 places his end of the call on
hold, UA 1 sends music to UA 2.  Thus user 2 has the "benefit" of
music-on-hold, even though UA 2 doesn't support the feature.)

If the new feature requires proxy support, it's almost impossible to
fulfill this criterion, because the feature works only if all proxies
between the new UA and all desired destinations support the feature.
So features "SHOULD NOT" require support from intermediate proxies.

Of course, there is vagueness around the edges.  Consider
push-to-talk:  To my mind, if UA 1 wants to use push-to-talk and UA 2
cannot, the "natural" fallback is ordinary bidirectional audio.  But
people in the PSTN world seem to think that PoC is as different from
bidirectional audio as text messaging is.

   Take GRUU for example, if a peer UA/proxy doesn't implement GRUU,
   then the GRUU functionality is not provided - is that broken?

GRUU isn't a user-visible feature, it's a technique to make
user-visible things work better.  But the same concepts apply:  If a
GRUU-capable UA registers with a non-GRUU registrar, it falls back to
the behavior a non-GRUU-capable UA has.

In that case, it's not jot possible to carry out the
INVITE-with-Replaces operation.  So that feature is broken, but
everything else still works.

   I don't by this statement of "non-interopable" SIP variant due to the
   introduction of [service] identification [into] SIP. 

OK.  Can you give us an example of how, using service identification,
two UAs negotiate to use their common feature set?

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 17 Mar 2007 13:11:45 +0200

Hi Dean,

that is an interesting and IMO perfect categorization of the problem.

I think point 3 is especially interesting, 
the fact an user insert in the call an extension (a communication
service identifier) should not prevent nodes from communicating,
especially when communication service identifier are used to better
identify the context of a communication.

Moreover media sometime are not enough to identify or to specify the
context of a communication, and I think it should be better insert
something that identify uniquely the context instead of let the terminal
or the network just trying to guess the right one.

Sal

On Mon, 2007-03-12 at 11:24 -0600, Dean Willis wrote:
...

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Mar 2007 15:49:00 -0400

> identify the context of a communication.

I don't think there is any issue with a UAC causing the inclusion of a 
server that provides some service. The problem I am concerned about, and 
that I think Dean is saying, is that at the termination side the call 
fails because a proxy or the UAS doesn't understand what the service 
identifier means.

> or the network just trying to guess the right one.

Well, we have seen some rather forced examples of this. But am still 
waiting to see some good real world examples that can't be done better 
some other way.

	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 19 Mar 2007 08:28:24 +0200

> fails because a proxy or the UAS doesn't understand what the service 

IMO if a UAS receive for example MMTEL service identifier, and it
doesn't understand what the service identifier means, it should not fail
but try to setup a "standard" sip call in the "classic" way.
The UAC insert the MMTEL service identifier, the originating network
understand the service identifier and set the context in accord, the
terminating network and the UAS if don t understand the service identify
simply start the call within the standard context.

> waiting to see some good real world examples that can't be done better 

here a possible rough example
two games (e.g., doom and quake) or in general two different
applications using the same protocol between them to exchange 
the position of the players. 
The UAs need to know what game or application they should use.

---

From: [email-masked]
Date: Wed, 21 Mar 2007 21:39:00 -0500

This leads to that the network support that is required needs to
   understand all the "communication services" in the end.

All we need from the network is to get IP packets from point A to
point B.  The endpoints may need to understand "communication
services", but that's their problem.

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2007 10:47:40 +0200

> services", but that's their problem.

You are correct, and I agree, for some services only up to the endpoints
understand the "communication services", and that is especially true for
services that are entirely implemented in the terminals.

However there are services that are not entirely implemented in the
terminal and that can not be implemented entirely there, but that
require a network support... 
you can like or not, but this is the reality.

so I think we can agree there are a lot of difference kind of services;
and what should be useful IMO it is trying to accept this reality and
trying to find an agreement on requirements that cover all of them, and
only after start to discuss the technical solution.

Sal

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 22 Mar 2007 02:22:52 -0700

>services", but that's their problem.

Amen.

People who may not agree with this can contribute to other organizations
than the IETF. Please read the IAB RFCs and I-Ds on Internet
Transparency in case of doubt, such as RFC2775 and 

 http://tools.ietf.org/group/iab/draft-iab-net-transparent-04.txt  

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 3:39 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Dale

---

From: David R Oran <[email-masked]>
Date: Thu, 22 Mar 2007 09:45:33 -0400

> services that are entirely implemented in the terminals.
Are you using the terms "terminal" and "UA" and "endpoint" synonymously?
If not, could you elaborate, and map what you are trying to say into  
the SIP abstract elements of "UA" and "proxy"?

I suspect much of the confusion here, especially when people talk  
about things being done "by the network" is confusing the issues hugely.

> you can like or not, but this is the reality.
please elaborate on what you mean by "network support". Clearly  
you're not talking about doing this via DPI in routers. At least I  
hope not! If by "the network" you mean by "a proxy under the policy  
control of neither the UAC or the UAS" for any given dialog then we  
might be able to stop talking past each other.

What I suspect is that most of this turns on whether you believe UAs  
should be required to put expose things that are only of interest to  
the UAs to proxies they neither know nor care about.

> only after start to discuss the technical solution.
It should be obvious by now that we are very far away from agreeing  
to what you posit above.

Cheers, Dave Oran
(individual hat on - not IAB hat)

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Mar 2007 16:38:52 +0200

> about things being done "by the network" is confusing the issues hugely.

sorry for the confusion, I meant UA

> hope not! 
> If by "the network" you mean by "a proxy under the policy  

no no, that is not my belief at all.
As I said also in the past, the idea (but this is my personal opinion)
is to specify better the context, and with context I mean the
communication environment in term not only of media, but also QoS,
delay, type of access network etc.etc.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2007 11:11:30 -0400

> sorry for the confusion, I meant UA

So "terminal" means UA, and so includes UAs that reside in application 
servers operated by the SP?

> delay, type of access network etc.etc.  

So, are you saying that a single service id implies a whole profile of 
values, such as what media might be used, what QoS parameters apply to 
each and every medium, and which access networks are permitted to be 
used?  Does this apply only to the originating side? Or to both 
origination and termination?

Since what is intended to be used for each of those things is encoded 
elsewhere in the message, is the use here strictly as a summary? Or is 
it a filter? (Overriding values to the contrary in the message.)

This seems pretty scary to me.

	Paul

---

From: [email-masked]
Date: Thu, 29 Mar 2007 13:50:42 -0500

From: Salvatore Loreto <[email-masked]>

Maybe that is my confusion, I can't think of a single such service.

If you mean by "service" a "QoS category", OK, I'll grant you that,
and there has to be some element in the messages to indiate that.  But
in none of the other examples people have quoted does it seem that
they cannot be implemented in the UA.

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 14:27:23 -0500

> they cannot be implemented in the UA.

I think you're both right, but using different vocabularies to  
describe the elephant.

Salvatore says "in the  terminal" and "in the network".

Dale says "in the UA" or "not in the UA".

The problem is that there are UAs "in the network" -- that is, hosted  
by service providers. Such include voice mail systems, call  
recorders, autoattendants, VRUs, anonymizers, transcoders, conference  
bridges, push-to-talk controllers, etc.

However, I maintain that proper use of request-URI and parameters can  
eliminate the need for "service identification" headers in every one  
of the in-network-UA cases that I know about. This is unchanged by  
the fact that some current designs for such "services" did not take  
this into account.

Take for example "push to talk", aka POC.

Two models exist (with some potential hybridization)

1) Alice's UA sends a SIP INVITE to Bob's AOR that, thru "magic",  
gets recognized as a POC request and therefore causes her POC  
controller and Bob's POC controller to be invoked.

2) Alice's UA sends a SIP REFER to her POC controller, asking it to  
send an INVITE to Bob's AOR, with that AOR modified to carry a  
parameter that will cause Bob's proxy to route the request via his  
POC controller.

Option 1 requires some sort of standardized "magic" to help identify  
the services invoked. Option 2 requires only a a URI parameter known  
to the POC service.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Mar 2007 14:24:23 -0400

Dean Willis wrote:

> eliminate the need for "service identification" headers in every one of 
> the in-network-UA cases that I know about. This is unchanged by the fact 
> that some current designs for such "services" did not take this into 
> account.
> 
> 1) Alice's UA sends a SIP INVITE to Bob's AOR that, thru "magic", gets 
> recognized as a POC request and therefore causes her POC controller and 
> Bob's POC controller to be invoked.
> 
> 2) Alice's UA sends a SIP REFER to her POC controller, asking it to send 
> an INVITE to Bob's AOR, with that AOR modified to carry a parameter that 
> will cause Bob's proxy to route the request via his POC controller.
> 
> 
> Option 1 requires some sort of standardized "magic" to help identify the 
> services invoked. Option 2 requires only a a URI parameter known to the 
> POC service.

I generally agree with Dean, but would spin the implementation a little 
bit differently:

Alice's UA, because it wants to support POC, recruits a network POC 
server as an assistant. It "enrolls" with that server indicating its 
potential willingness to accept POC calls - providing an address (gruu) 
where it can be reached. It gets a URI (gruu) in return from the POC 
server. (I haven't worked out details of this enrollment. There are many 
ways it could work.) The POC server REGISTERs with the UA's AOR, 
including a callee capability for POC.

Bob's UA does the same.

Before initiating a POC call, Alice's UA establishes a dialog with its 
POC server. (This can be any time, not just at call establishment time.)

When initiating a POC call to Bob, Alice's UA sends a REFER to the 
contact address of the dialog, with a Refer-To of Bob's AOR. It also 
contains an embedded Accept-Contact header indicating it only wants a 
contact that is capable of POC. (Alternately, the server can insert the 
Accept-Contact header. Another alternative is that Alice's UA has 
learned the GRUU of Bob's POC server, perhaps via presence, and has 
referenced it directly.)

The call eventually reaches Bob's POC server, based on its having 
*registered* with Bob's AOR. Actions from there are straightforward.

Note that it isn't necessary for the POC servers to be from the same 
provider as the AORs. In fact, Alice can have a POC server appliance in 
her home if desired.

Also, assuming Alice and Bob's UA also register directly with their 
AORs, they can exchange *regular* calls, which will bypass the POC servers.

This is quite analogous to having UAs recruit their own transcoders when 
needed, rather than expecting some middle box to do it for them.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 30 Mar 2007 22:03:14 +0200

> *registered* with Bob's AOR. Actions from there are straightforward.

Is this really so different from IFC? Having servers register on behalf of 
each user doubles the amount of dynamic registration state (and refreshes, 
etc.), whereas IFC can be provisioned statically and globally for all users 
(or a subset)

Regards,
Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 30 Mar 2007 22:03:14 +0200

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Mar 2007 17:56:31 -0400

Jeroen van Bemmel wrote:
> Is this really so different from IFC? Having servers register on behalf 
> of each user doubles the amount of dynamic registration state (and 
> refreshes, etc.), whereas IFC can be provisioned statically and globally 
> for all users (or a subset)

The difference is that the semantics are well defined. All the 
registrations are there to be considered in parallel.

IMS says nothing about applying callerprefs to ASs selected by IFC.

	Paul

---

From: [email-masked]
Date: Fri, 30 Mar 2007 17:21:42 -0500

From: Dean Willis <[email-masked]>

Let me expand on that a bit...

If we're going to achieve interoperability, option 2's URI parameter
does need to be standardized.  Indeed, the level of specification and
standardization needed is about the same as setting up a "service
identifier".  The significant difference is that this service
identifier would be within the existing SIP framework, rather than a
parallel, new invention.

However, comparing these ideas with Dean's and Paul's outlines of ways
to implement recruiting POC servers (and one can easily invent other
ones that are transparently interoperable over the wire with these)
shows that the logical concept of "service identification" is
independent of the matter of recruiting application servers, and that
neither intrinsically requires intervenation of the wide-area network.

Dale

---

From: [email-masked]
Date: Fri, 30 Mar 2007 17:31:19 -0500

I was being sloppy with the terminology, but I was looking at a
different aspect, namely services that "require network support".  As
far as I can tell, some services require support from a UA that is not
the "terminal", but in all cases the supporting UA (or application
server) can interface to *the network* as "just another UA"; the
terminal UA and the app server UA can coordinate without much support
from the network.

What I'm looking for is a service where application support must
necessarily be integral to the network, and cannot be provided by a
service that accesses the network "like any other UA".

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 31 Mar 2007 13:46:33 -0500

> service that accesses the network "like any other UA".

There have been services defined to work this way ("in the network").  
However, I think that they could all be transformed without loss of  
function into "like any other UA" operation.

However, the old-school network operators (carriers, whatever you  
want to call them) come from a background of doing things inside TDM  
circuit switches. They just don't get the INternet model. They don't  
WANT to get it. They don't want to recognize that their much-vaunted  
"in the network" services are not inherently "better" than "in the  
UA" services. The entire concept offends their world view and is as  
alien to their perspective as service-muddling "network elements" is  
to the Internet perspective. They were happy with broadband ISDN and  
BICC, they don't know why they switched to IP and SIP, and they have  
a hunch that if they can make the way IP works change to work like  
switched systems did then they'll magically be put back in control of  
all electronic communications, and that's where they want to be.

This makes for very difficult negotiations.

How many therapists does it take to change a light bulb?

Only one, but the light bulb has to really WANT to change.

Fortunately, unchanged light bulbs eventually burn out.

--
Dean