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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:13:08 -0400

This is why I think the principle problem is inter-provider. The draft 
says there is nothing wrong with a service provider examining the 
signaling, determining the service, and then taking the appropriate 
actions, including managing interactions. So, I am agreeing with you and 
Christer on this one.

What the draft is saying IS bad, is when there is a dependency on an 
inserted service identifier to determine how to process the request. It 
must be possible to determine what to do with a request entirely from 
the rest of the signaling.

-Jonathan R.

DOLLY, MARTIN C, ATTLABS wrote:
> 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,
> 
> 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
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:24:30 -0400

Christer Holmberg wrote:
> 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",

I think you mean, "do-what-I-mean".

What the service-ID draft is trying to say, is that the service should 
be defined ENTIRELY by the signaling, and you should not rely on an 
ill-defined *additional* identifier to decide on processing the request. 
Usage of these additional identifiers is what introduces the problems of 
fraud, interop failures between domains, and so on.

A good litmus test for this is the following. If a client sent a request 
with this service identitifer to a domain/provider that didn't utilize 
service identifiers at all, would the request end up being processed, 
but incorrectly in some way? i.e., would the 'wrong thing' happen?

So, here is an example. Lets take our 'game with associated audio' 
example. Lets say, as you propose, game moves are exchanged with DTMF, 
and audio is using a regular audio stream via g711. So the INVITE looks 
just like a voice call. If the client inserts a service identifier that 
says, "hey, this is for a game!" and sends that into its provider, and 
the provider just ignores that identifier, the wrong thing happens. The 
phone rings on the called party and they get all this annoying DTMF in 
their ear as game moves are pushed. Thats bad, and thus this approach 
fits the litmus test of 'explicit service identifiers' which the draft 
warns against.

Now, take the feature-ref approach. That approach uses new URIs in the 
Refer-To header field. If a phone launches such a REFER into its 
provider, and it doesn't support or understand these URN, the call fails 
completely. Thats exactly what SHOULD happen. The signaling is being 
explicit about what is desired, and that function is not supported, so 
the request fails. Of course the call can proceed without this feature. 
Thats exactly the way SIP works with all of its extensions - we proceed 
with what works.

And thus feature-ref does not meet the litmus test of 'explicit service 
identifiers' which the draft warns against.

I would be happy to clarify this distinction in the draft and indeed 
include this litmus test.

Thanks,
Jonathan R.

The feature-ref draft
> 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
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:26:38 -0400

The draft is recommending that the service be derived from the entirety 
of the signaling. The main argument made in the draft is that, you 
should never need the client to include some new, additional, service 
identifier like "this is PTT", since somewhere in the SIP/SDP should be 
everything you need to say that this is PTT.

-Jonathan R.

Hadriel Kaplan wrote:
> 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,
>>
>> 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
>>
>>
>>
>> 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,
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 11:37:02 -0400

Once again, Christer, please provide concrete exmaples, since it is very 
hard to have a useful discussion on this topic without them.

So let me provide an example. Lets say we are doing a game and that game 
uses audio to chat along with MSRP for exchanging game moves. The 
calling party uses their mobile phone, goes to their game application, 
selects a buddy, and selects 'play'. The desired goal is that this 
should only ring the devices associated with the called party which have 
this game, and furthermore, a game b2bua gets invoked  by the 
terminating provider to record the moves for an offline replay feature.

Now, I think your argument is that, if we use the existence of the MSRP 
session in the SDP with the game move type as an indication that this is 
the desired service, it doesn't work in delayed offer situations where 
the INVITE doesn't contain the SDP. Yes?

I'd assert that, in this case, the caller shouldn't be sending a delayed 
offer. The whole idea with a delayed offer is that the calling party is 
giving the called party the opportunity to choose the media for this 
session. It is entirely inappropriate to use it in cases where the call 
should fail if a specific set of media are not returned. The caller 
should just insert their SDP if they know their media. If they were 
doing delayed offer because they didn't have the IP addresses and ports 
yet, they should send dummy IP with a=inactive and do a reinvite after 
the initial exchange.

A common case for delayed offer are things like 3pcc where the session 
is being set up by a third party. So, for example, lets say I want to 
set up this game between my phone and my friend's phone, but I do it by 
using a web portal from my PC. Here, I'd argue, the current 3pcc specs 
are inadequate since they don't provide a way to force an SDP offer from 
a party with a particular set of media types. If you want that problem 
solved we can readily develop a SIP extension which allows an offerless 
INVITE to contain an indication of specific session types which must be 
provided in the offer, else the call should be failed.

If this answers your question I would be happy to add text along the 
above lines to the draft.

-Jonathan R.