Subject: RE: [Sipping] "Services"

From: <[email-masked]>
Date: Fri, 19 May 2006 08:49:30 +0200

Dean,

I started this response before but never finished it. The conversation
has gotten stale, but maybe it is time to revive it.

I agree with you that "forking" (and other retargeting) is not useful in
a Proxy (serving the AOR). Given that the AOR routes to 1 UA, the UA is
far more capable of deciding what needs to be done.

Colin Pons

-----Oorspronkelijk bericht-----
Van: Dean Willis [mailto:[email-masked]] 
Verzonden: vrijdag 24 maart 2006 17:02
Aan: Dale R. Worley
CC: Sipping
Onderwerp: Re: [Sipping] "Services"

On Mar 22, 2006, at 9:16 AM, Dale R. Worley wrote:

> The discussion of event throttling suggests this to me:
>
> As far as I can make out, there is a significant practical difference
> from "IETF SIP" environments and IMS/3GPP environments.  In IETF
> environments, an AOR routes to (usually) one UA, which is an  
> application
> that runs on one host.  So if another UA wishes to make a request  
> of the
> AOR, the request is routed to that application, which decides what (if
> anything) it can do to fulfill the request.  In this situation,  
> request
> processing is largely end-to-end, because there is no useful  
> processing
> that intermediate systems can perform -- the UA application knows  
> better
> than any intermediate system what can be done.

AThis begs the question of whether "forking" and other retargeting  
(forward to VM on no-answer) are useful processing executed in the  
proxy serving the AOR. I'm beginning to think not, but I'm sure many  
people think otherwise.

--
Dean

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Fri, 19 May 2006 10:09:08 +0300

> far more capable of deciding what needs to be done.

are you really saying that it is not useful to have more than one
contact registered for an AoR?  if so, then that is not my users are
telling me.  they want proxy to fork requests so that their phones ring
according to the order specified by q value.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 May 2006 10:25:20 -0500

> according to the order specified by q value.

Of course, this can be done by having the proxy respond with a q- 
value ordered 302 instead of forking.

The problem comes into play when we start trying to fork based on the  
"service being requested" instead of on the "capabilities needed in  
the endpoints to which we might fork".

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 22 May 2006 18:30:07 +0300

> value ordered 302 instead of forking.

and who would pay the bill, then proxy returns 302 to PSTN gateway?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 22 May 2006 18:43:27 +0300

> value ordered 302 instead of forking.

also, can you tell me which SIP phones (in addition to kphone) confirm
if caller wants his phone to make a new call based on 302 response?
would you pay callers' blind calls to 700 numbers?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 22 May 2006 18:35:38 +0300

> value ordered 302 instead of forking.

also, some of the contacts may not be directly reachable outside of the
domain at all.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 May 2006 14:53:08 -0500

> and who would pay the bill, then proxy returns 302 to PSTN gateway?
The caller, unless the 302 indicates a "bill to called party"  
indicator understood by the gateway. There's a few tricks to work  
out, but no reason it couldn't be done. and it requires no support  
from the originating SIP UA beyond what's in the usual RFC mess.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 May 2006 14:53:42 -0500

> also, some of the contacts may not be directly reachable outside of  

Redirect to GRUU.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 May 2006 15:01:09 -0500

> would you pay callers' blind calls to 700 numbers?

How do you know the proxy doesn't just retarget your call to a 700- 
number at a gateway set up to bill you anyhow?

use case: Alice and Bob use the same service provider. Bob forwards  
his number to an expensive Caribbean dialaporn number. Alice calls  
Bob. The terminating proxy retargets the request to a gateway in the  
service provider network. The gateway recognizes Alice's credentials,  
connects the call, and submits a billing record for euros 25 for  
connect, plus euros 5 per minute.

Alice wonders about Bob's voice mail greeting for a while, and is  
then SHOCKED by her phone bill.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 May 2006 23:01:42 +0300

> from the originating SIP UA beyond what's in the usual RFC mess.

you must be joking.  are you saying that is is ok that a pstn caller
from the u.s. who called a number in japan gets redirected back to
u.s. at caller's expense via a pstn gw in japan without the caller
having no clue about what is going on?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 May 2006 23:09:57 +0300

> number at a gateway set up to bill you anyhow?

i don't get it.  if someone FORWARDS calls to his number to any number,
the forwarder will pay the forwarded leg of the call.  if someone
REDIRECTS calls to his number, then it is up to the caller do decide if
he wants to follow up provided that he's sip phone asks confirmation
about the redirect.  i don't know what you mean by retargeting.  that
word does not appear in rfc3261.

i tried at some point to make asking of confirmation of 302 mandatory,
but lost the battle.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 May 2006 17:01:11 -0400

Juha Heinanen wrote:
> about the redirect. 

There is no guarantee that such a convention is followed by all 
applications of SIP. Its all about the billing model, for which there is 
no single standard.

And when you think about it, that model doesn't make a whole lot of 
sense unless you anchor the media at the transfer point. If I call Bob 
in Japan, and he has his proxy in Japan forward all his calls back to a 
GW in the USA, and the media isn't anchored in Japan, then the media 
path of the transferred call is most likely much shorter than a path 
from me to Japan, much less a round trip to Japan. Of course the 
operators will be happy to bill me for a call from the US to Japan, and 
bill Bob for a call back from Japan to the US (even though the media 
only went from Boston to NY), but I would rather they didn't.

So what is the "fair" way to apportion the cost for the two call legs 
between the calling and called parties? These days, it seems that a 
likely model is that each end pays an "access charge" for the path from 
the UA into the network. Then the path between the new access networks 
is just considered overhead and isn't charged directly. And the access 
network cost is probably fixed per month rather than per-call.

The big problem comes when connecting between the sip network and the 
PSTN, because then you must coexist with the PSTN billing model. But 
that can be minimized if the sip network always choosed a hop off point 
local to the UAS.

	Paul

> i don't know what you mean by retargeting.  that

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 26 May 2006 00:14:46 +0300

> that can be minimized if the sip network always choosed a hop off point 

my example problem related to 302 was specifically related to pstn
gateways and current pstn billing model.

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 26 May 2006 10:32:12 +0200

>i tried at some point to make asking of confirmation of 302 mandatory,

I think getting caller's consent on 3xx (and REFER to) would be a good UAC BCP 
given the existing PSTN charging implications (unlike in web where redirection 
to an expensive site doesn't cost you until you actively engage with the site).

That may be however easier said than done: obtaining 3xx consent from a caller 
behind originating PSTN gateway may be tricky (possibly implementable as 
a 3xx-to-IVR service but that does not really sound pleasent to me).

I think it is too late to put a consent requirement in the spec and I am 
not sure that is sufficient traction for a UAC BCP. 

In the field, I would presumably end up with some hacks such as dropping 
redirected INVITEs to a list of undesirable destinations (PSTN, 900, whatever 
your policy is) at outbound proxy. That's however a different conversation.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 26 May 2006 13:46:59 -0400

> gateways and current pstn billing model.

In the *current* situation, the problem is solved because we *don't*
have a sensible billing model for SIP -- there's no way for a 700 number
to charge back to the originator of a SIP call, because the SIP
infrastructure is outside of the network of billing agreements that is
overlayed on the PSTN.

If we want to introduce a billing system, then it becomes possible to
bill, and there will be problems with forwarding numbers or services
that involve billing.  But figuring out how to hand that is part-and-
parcel of the work "creating a billing system for SIP environments".

I suspect that any effective solution will involve something like an
"Authorization-To-Bill" header on INVITEs, triggered by 402 Payment
Required.  But a forwarding agent can always add those by doing a 302
with "Contact: xxx@xxx?Authorization-To-Bill=xxxxxxxxxxxxxxxx".

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 22:11:17 -0500

> having no clue about what is going on?

I'm saying nothing in the existing model necessarily prevents it.

I could call a number in Japan, reach a proxy, and get proxied to a US 
phone number and billed for it both ways if the service provider 
agreements were set up that way. And it would have happened without me 
(or my UA) having a clue.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 22:16:59 -0500

> word does not appear in rfc3261.

Retargeting occurs when a proxy rewrites the request-URI of a request it 
is processing. Contact-routing, where the AOR is replaced by the 
Contact: registered against that AOR, is an example. Forking is ALWAYS 
retargeting. I used to think it was forking _ hated -- eventually, I 
realized it was the retargeting that was really the problem, and I just 
noticed the symptoms more during forking.

Personally, I think retargeting is one of the more egregious design 
flaws of RFC 3261. But 3261 is much better than 2543, which retargeted 
at every proxy hop instead of "just" at the proxy serving the AOR.

Of course, one could retarget to another AOR, which would retarget to 
anotehr AOR, and so on many times before reaching an actual device 
contact. If the billing were backward chaining, you could end up with a 
very interesting monthly satetement.

I would find the whole situation more tenable if the proxy serving the 
AOR merely appended the registered Contact: value (and it's "Path") to 
the route set instead of obfuscating the request URI.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 28 May 2006 10:42:30 +0200

> I would find the whole situation more tenable if the proxy serving the AOR 
> merely appended the registered Contact: value (and it's "Path") to the 
> route set instead of obfuscating the request URI.

With the introduction of GRUU we have an opportunity to add this - why don't 
we?

Jeroen

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 May 2006 03:26:34 -0500

On Sunday 28 May 2006 03:42, Jeroen van Bemmel wrote:
> With the introduction of GRUU we have an opportunity to add this - why
> don't we?
>

That has been discussed within the context of GRUU, then moved to the separate 
route-construction draft, and as last I understood Jonathan's intent, may be 
deferred to a future document.  Then again, I may misunderstand.

Of course, we don't have a final consensus on this yet, so it is open to 
debate. Please do so.

--
Dean