Subject: Re: [Sipping] draft-ietf-sipping-service-identification-01.txt

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 2 Apr 2008 11:10:53 +0200

Hi,

I don't agree with Spencer's proposal.

Carriers normally define how/if services can be used together. Also, I
think it would be quite normal to e.g. indicate a service, and an
application using that service. I guess, in the context of the draft,
that would been seen as two services, since there is no separation
between service and application.

Also, this "effect on innovation" stuff I don't understand at all, so I
think that also needs to be clarified. How is innovation affected if the
network inserts application servers, and/or a forking proxy uses feature
tags in order to reach a terminal which has registered support of
certain capabilities?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: 31. maaliskuuta 2008 23:43
To: Mary Barnes
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-service-identification-01.txt

Hi, Mary,

I had actually looked at this version of the draft and posted comments
at http://www.ietf.org/mail-archive/web/sipping/current/msg15233.html,
but you may have missed this because I didn't change the Subject to
point to .01...

I had two comments,

- one asking for a reference to "Push-to-Talk".

Jonathan suggested just telling people to Google "Push-to-Talk", which
could be the right answer but seems strange, given the existence of
informative references sections in RFCs. My counterproposal was to ask
the OMA Liaison to suggest a reference, since I don't know what a stable
reference would be, either. Obviously, this is a nit.

- one raising a concern that was similar to a concern Jonathan raised in
the draft, but I thought it was different and worth mentioning - the
draft talks at some length about the effect that using opaque service
identifiers has on innovation BETWEEN carriers, but ISTM there's a
similar effect on innovation even WITHIN a single carrier.

If you define two service using Service Identifiers that are only used
within your network, it's not at all clear how to combine them for a
customer who wants to use both on the same call, and it's not clear how
to extend a single service, if signaling isn't sufficient to describe
services. 
I don't think this is worth more than two sentences, but if the message
of this draft is "using opaque service identifers breaks things for
everyone", it seemed appropriate to say "using opaque service identifers
even breaks things for YOU, within YOUR network".

So, obviously, ready to send to the AD from my perspective.

Thanks,

Spencer

----- Original Message -----
From: "Mary Barnes" <[email-masked]>
To: "sipping" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Gonzalo Camarillo" 
<[email-masked]>; "Asveren, Tolga"
<[email-masked]>; "Mahesh" <[email-masked]>; "Spencer
Dawkins" 
<[email-masked]>
Sent: Thursday, March 27, 2008 2:00 PM
Subject: WGLC: draft-ietf-sipping-service-identification-01.txt

Hi all,

Per the status of this document in the chair charts from IETF-71, we
were to start the WGLC on this document right after IETF-71:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identific
ation-01.txt

This two week WGLC ends on April 11th, 2008.

The expectation is for past reviewers (Tolga Asveren, Mahesh and Spencer
Dawkins (RAI area review)) to ensure their past concerns have been
adequately addressed.

As well, others in the WG are strongly encouraged to provide feedback as
to the readiness of progressing the document, along with any other
comments.

Thanks,
Mary
SIPPING co-chair 

_______________________________________________
Sipping mailing list  https://www.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://www.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: "Christer Holmberg" <[email-masked]>
Date: Wed, 2 Apr 2008 11:12:57 +0200

Hi,
 
In Philadelphia Jonathan said he was going to explain why the usage of
service URN in draft-audet-sipping-feature-ref is NOT "do-what-I-say",
and why it doesn't fit all the claimed problems with service id. I would
like to get that explanation, and maybe the service id draft should also
contain text about what it IS allowed.

Regards,

Christer

----- Original Message -----
From: "Mary Barnes" <[email-masked]>
To: "sipping" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Gonzalo Camarillo" 

Hi all,

Thanks,
Mary
SIPPING co-chair

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 2 Apr 2008 04:51:38 -0500

I agree with Christer here, in that service providers have been
addressing service interaction for decades. I do not see that changing
now. 

The INNOVATION is in how a carrier bundles their services and addresses
the interaction. Note that there are many architectures out there that
have a Service Broker/SCIM in them, but they never get into the detail
of the function. Why you say...INNOVATION

Cheers,

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: Wednesday, April 02, 2008 5:11 AM
To: Spencer Dawkins; Mary Barnes
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-service-identification-01.txt

Hi,

Regards,

Christer

-----Original Message-----

Hi, Mary,

I had two comments,

Thanks,

Spencer

----- Original Message -----
From: "Mary Barnes" <[email-masked]>
To: "sipping" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Gonzalo Camarillo" 

Hi all,

Thanks,
Mary
SIPPING co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Apr 2008 08:14:21 -0400

I'm not certain I understand this argument. But it seems to me this is 
predicated on an assumption that all services are managed and 
coordinated centrally. That almost by definition limits innovation.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 18 Apr 2008 12:52:02 +0200

Hi,

There is another issue which I think the draft should cover.

It is related to the "the service can be derived from the SDP"
discussion.

When we introduce extensions like SDPCapabilityNegotiation and
SDPMediaCapabilityNegotiation etc, the initial offer may contain lots of
options, and it is not known which ones will be chosen, so it MAY NOT be
possible to derive the service from the initial offer.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mary Barnes
Sent: 27. maaliskuuta 2008 21:00
To: sipping
Cc: Gonzalo Camarillo
Subject: [Sipping] WGLC:
draft-ietf-sipping-service-identification-01.txt

Hi all,

Thanks,
Mary
SIPPING co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Apr 2008 08:39:42 -0400

> possible to derive the service from the initial offer.

If there are lots of options, and its not known which will be chosen, 
then it seems that the service itself isn't known.

(I'm calling you, and I have the capability to speak, or IM, or PTT, or 
play Doom. I'm giving you the option of deciding which we will do.)

I realize this is inconvenient for IMS because it wants to put different 
middleboxes in the path depending on which service is to be used. But 
that is simply an indication of how broken the IMS architecture is.

	Paul

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 18 Apr 2008 15:08:36 +0200

These middle boxes are called SIP proxies, which are chained using Route
headers.
It has nothing to do with the omissions of pure SIP that IMS tries to
fix.

I agree with Christer that the SDP does not give you the information you
need if you want to do something more then only indicating which media
you want to negotiate end to end. If you do that then you give the SDP
more meaning then that it has.

/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Friday, April 18, 2008 2:40 PM
To: Christer Holmberg
Cc: sipping; Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] WGLC:
draft-ietf-sipping-service-identification-01.txt

Christer Holmberg wrote:
> SDPMediaCapabilityNegotiation etc, the initial offer may contain lots 
> of options, and it is not known which ones will be chosen, so it MAY 
> NOT be possible to derive the service from the initial offer.

	Paul

> The expectation is for past reviewers (Tolga Asveren, Mahesh and 
> Spencer Dawkins (RAI area review)) to ensure their past concerns have 
> been adequately addressed.
> 
> As well, others in the WG are strongly encouraged to provide feedback 
> as to the readiness of progressing the document, along with any other 
> comments.
> 
> Thanks,
> Mary
> SIPPING co-chair
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 11:51:59 -0400

I didn't think this draft was suggesting that SDP be used for such service derivation. (did I misread it?)  Clearly there are offerless INVITEs, so that wouldn't be possible anyway.

I thought it was recommending using RFC 3840, 3841, and Jonathan's app-media-tag draft instead.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Friday, April 18, 2008 6:52 AM
> To: Mary Barnes; sipping
> Cc: Gonzalo Camarillo
> Subject: Re: [Sipping] WGLC: draft-ietf-sipping-service-identification-
> 01.txt
>
>
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Apr 2008 12:46:03 -0400

> It has nothing to do with the omissions of pure SIP that IMS tries to

The middleboxes are *sometimes* proxies. But there isn't a lot that a 
proxy can do once the call is established. The things that a proxy can 
do, like fork the call to VM, don't require it to stay in the session, 
and aren't very service-specific.

Other middleboxes are B2BUAs, like the PTT servers. The fact that the 
architecture requires them (if at all) to be inserted into the call 
initially is contrary to the design of sip that allows the type of media 
in the call to be negotiated, and renegotiated, in the course of the 
call rather than being predetermined.

> more meaning then that it has.

Callerprefs can be used to select a target with certain desired 
*capabilities*, but doesn't, and shouldn't, imply that you necessarily 
intend to use them all, or all at the same time, etc.

The media descriptions allow you to negotiate what you intend to use. 
And with cap negotiation you can get into more detail of capabilities 
than callerprefs can deal with.

I still don't understand when this is not enough. I think it must only 
be when you are trying to select a B2BUA middlebox to assist and no one 
middlebox has all the capabilities of the endpoints. IMO the problem 
with this is expecting to select such a box before the call is 
established. It would be better if the UAC and UAS were each negotiating 
what they want to do, and bringing in resources to help after they 
figure that out.

	Paul