Subject: Re: [Sipping] WGLC of draft-ietf-sipping-service-examples-10.txt

From: Juha Heinanen <[email-masked]>
Date: Sat, 27 May 2006 22:04:00 +0300

gonzalo,

i don't volunteer to formally review the draft, but i have gone through
it cursorily:

1) 2.5 uses GRUU, which has not been defined in any RFC and i don't know
   if GRUU i-d is even close to become an RFC.  if i remember correctly,
   there were some major issues still open (for example, can gruu be
   used to implement mobility of SIP UAs.

2) in 2.10, should here "Bob first sends a re-INVITE to Alice
   changing Contact URIs to one that indicates Alice's mixer and acts
   like a focus." Alice's be Bob's, because Bob is the one who is
   capable of mixing.

3) 2.12 reminds me about a problem that my users have noticed with
   forking: what would happen if B2 instead of not being logged in and
   returning 480, had setup his phone to return 302.  according to
   rfc3261 proxy has to wait for B3.  in the example, B3 answers, but if
   B3 would not answer, the caller would need to wait until 408 timeout
   before proxy acts on 302, which is very bad.  what i'm trying to say,
   that in case of forking, proxy should act on 302 immediately, i.e.,
   consider 302 as a positive final reply.

-- juha

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 11:59:37 -0400

>    consider 302 as a positive final reply.

Ouch.  It's worse than that.  The effect you really want is that the
contacts listed in the 302 are replacements for the fork to B2.  So once
the proxy has gotten to sending the parallel forks to B2 and B3, the
contacts listed in the 302 should be acted on immediately (as it is past
time to send the fork to B2), while allowing the fork to B3 to
proceed.  

After the forks to the contacts have failed and the fork to B3 has
failed, the proxy may proceed to fork to contacts in the original set
with q-values lower than B2 and B3.

Unfortunately, RFC 3261 doesn't really allow for that, I don't think.

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 28 May 2006 20:19:29 +0300

> time to send the fork to B2), while allowing the fork to B3 to

i don't agree with that.  302 has to go all the way to sending party,
which can then decide if it wants to make new request to 302 target and
thus also pay for it.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 28 May 2006 21:04:34 +0200

> which can then decide if it wants to make new request to 302 target and

Both are defendable. The UAC could use RFC3841 'Request-Disposition' to 
force a decision here, i.e. Request-Disposition: recurse or 
Request-Disposition: no-recurse. I would argue that the default should be 
'recurse', since the UAC ought to be aware of any payments required and 
could therefore prevent this if needed

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 28 May 2006 22:39:42 +0300

> could therefore prevent this if needed

how can my UAC be aware when i call you that you have 302 to a 700
number?  the default should definitely be "no-recurse".

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 18:38:13 -0400

> which can then decide if it wants to make new request to 302 target and

The difficulty with forbidding a proxy to act on a 302 that it receives
is that it doesn't really solve the problem that the 302 causes, and any
effective solution the the real problem makes it harmless for a proxy to
act on a 302.

Yes, a UA could maliciously return a 302 redirecting a call to a service
that demands payment.  But the same device could proxy the call onward
to that same service, so preventing proxies from acting on 302s does not
solve the problem.

It seems to me that there are only two effective solutions to the
problem.  (Both of which render proxies acting on 302s harmless.)  The
first is an over-arching trust/billing system that administratively
restricts what destinations agents can forward calls to.  (But that is
outside the scope of this WG.)

The second is a convention that a UAS may not bill a UAC without an
explicit authorization-to-bill indication on the INVITE.  How such
indications are formulated (and how a UAS generates a 402 Payment
Required response to prompt the UAC to generate such an indication)
might be areas for further standardization.

(Conveniently, the legal default for the current Internet already is the
second solution.)

Dale

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 29 May 2006 08:20:00 +0300

> to that same service, so preventing proxies from acting on 302s does not

if callee has instructed his proxy of PSTN switch to forward calls to
700 numbers, then callee is paying for that extra leg.  this is how PSTN
works today and i can't imagine that consumer protection authorities
would allow you to change the behavior when SIP is used for signaling.

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 29 May 2006 15:12:17 -0400

On Mon, 2006-05-29 at 08:20 +0300, Juha Heinanen wrote:
> 700 numbers, then callee is paying for that extra leg.

What does that sentence mean?

> this is how PSTN

We're already using SIP for signaling, and the behavior is different, in
that there is no mechanism for billing a caller in the Internet SIP
system.

Nonetheless, restricting 302s will not solve the problem you're
concerned with.

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 May 2006 16:52:15 -0500

> Nonetheless, restricting 302s will not solve the problem you're

Right.

The fundamental problem is that the call could be retargeted by the  
callee's proxy to a 700-club number at a gateway serving the callee.  
If the callee and caller are in the same authorization domain, the  
gateway could send back a WWW-authenticate, which the caller's UA  
would then have to respond to via an INVITE with new credentials. At  
least in this case, the caller gets the same chance to verify the  
retargeting as a 302 would have given them. But in a domain where we  
use an asserted-identity model of authentication, the gateway would  
just route the call onto the PSTN without bothering to check with the  
original caller, but the call-detail-record it sends would show the  
call as having originated (and being billable to) the caller, not the  
callee.

Now, if the callee's proxy changed the asserted-identity credentials  
when retargeting, the gateway might actually bill the callee instead  
of the caller, but if we do that, then the "caller ID" functions  
aren't going to work, and on the PSTN, the calls is going to show as  
having come from the callee. And if instead of asserted-identity the  
gateway returns a WWW-Authenticate, it's going to go back to the  
caller (not callee) for response, and the gateway is going to write  
the CDR against the caller, not the callee.

Given the current mechanisms, I believe that retargeting to a gateway  
and billing the callee requires that the callee's service element act  
as a B2BUA for it to assure the billing model you seem to want, in  
the general case. If the gateway returns a WWW-Authenticate, the  
B2BUA would be responsible for responding with the callee's credentials.

Have I mentioned lately that retargeting is evil?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 May 2006 18:26:03 -0400

Dean Willis wrote:
> callee's proxy to a 700-club number at a gateway serving the callee. If 
> the callee and caller are in the same authorization domain, the gateway 
> could send back a WWW-authenticate, which the caller's UA would then 
> have to respond to via an INVITE with new credentials. At least in this 
> case, the caller gets the same chance to verify the retargeting as a 302 
> would have given them. But in a domain where we use an asserted-identity 
> model of authentication, the gateway would just route the call onto the 
> PSTN without bothering to check with the original caller, but the 
> call-detail-record it sends would show the call as having originated 
> (and being billable to) the caller, not the callee.
> 
> when retargeting, the gateway might actually bill the callee instead of 
> the caller, but if we do that, then the "caller ID" functions aren't 
> going to work, and on the PSTN, the calls is going to show as having 
> come from the callee. And if instead of asserted-identity the gateway 
> returns a WWW-Authenticate, it's going to go back to the caller (not 
> callee) for response, and the gateway is going to write the CDR against 
> the caller, not the callee.
> 
> and billing the callee requires that the callee's service element act as 
> a B2BUA for it to assure the billing model you seem to want, in the 
> general case.

This suffers from the same "problem" as just replacing the 
P-Asserted-ID: namely the forwarded-to party sees the forwarding party 
as the caller.

This may be no problem at all - it may be viewed as a feature. Its all 
in the eye of the beholder.

	Paul

> If the gateway returns a WWW-Authenticate, the B2BUA would 
> be responsible for responding with the callee's credentials.
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 May 2006 20:45:42 -0500

On May 30, 2006, at 5:26 PM, Paul Kyzivat wrote:

>> The fundamental problem is that the call could be retargeted by  
>> the callee's proxy to a 700-club number at a gateway serving the  
>> callee. If the callee and caller are in the same authorization  
>> domain, the gateway could send back a WWW-authenticate, which the  
>> caller's UA would then have to respond to via an INVITE with new  
>> credentials. At least in this case, the caller gets the same  
>> chance to verify the retargeting as a 302 would have given them.  
>> But in a domain where we use an asserted-identity model of  
>> authentication, the gateway would just route the call onto the  
>> call-detail-record it sends would show the call as having  
>> originated (and being billable to) the caller, not the callee.
>> Now, if the callee's proxy changed the asserted-identity  
>> credentials when retargeting, the gateway might actually bill the  
>> callee instead of the caller, but if we do that, then the "caller  
>> ID" functions aren't going to work, and on the PSTN, the calls is  
>> going to show as having come from the callee. And if instead of  
>> asserted-identity the gateway returns a WWW-Authenticate, it's  
>> going to go back to the caller (not callee) for response, and the  
>> gateway is going to write the CDR against the caller, not the callee.
>> Given the current mechanisms, I believe that retargeting to a  
>> gateway and billing the callee requires that the callee's service  
>> element act as a B2BUA for it to assure the billing model you seem  
>> to want, in the general case.
>
> This suffers from the same "problem" as just replacing the P- 
> Asserted-ID: namely the forwarded-to party sees the forwarding  
> party as the caller.
>
> This may be no problem at all - it may be viewed as a feature. Its  
> all in the eye of the beholder.

in the asserted-identity case, the B2BUA, since it is within the  
domain of trust, can assert any identity it wants to.

Few gateways actually populate their calling-party-ID information  
using the digest credentials, so if we're using digest, the B2BUA can  
authenticate to the gateway using credentials that direct charges to  
the callee.

However, if we're doing both CDRs and caller-id in the gateway based  
on p-asserted-identity, we do have a problem with the range of  
expression -- we need to express two different identities. Yay,  
another half-thought-out extension comes into play.

But you are quite right in that fulling meeting the requirements as  
raised by Tom, even using a B2BUA, is not a completely trivial task.  
But I think the point that "just using a proxy doesn't meet the  
requirements" is well-established.

The easiest way to meet Tom's requirements is probably to use a 302  
that includes a new target that encodes, in the target, both the  
information needed to bill the original callee AND a reassurance to  
the caller that they aren't being billed for the PSTN termination.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 30 May 2006 23:13:59 +0300

> What does that sentence mean?

same as if you forward calls to your cell phone number to some other
number.  original caller pays the leg from him to your number and you
pay the leg from your number to this other number.

 > that there is no mechanism for billing a caller in the Internet SIP

i never said that anybody would get billed for sip-sip calls.  all my
example have been dealing with calls forwarded by sip callee to pstn.

 > Nonetheless, restricting 302s will not solve the problem you're

i have not proposed to restrict 302s but pass them back to the original
caller as the idea of 302 has always been.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 31 May 2006 15:13:10 +0300

> B2BUA would be responsible for responding with the callee's

i don't understand what you try to say.  you don't need a b2bua.  there
are 3 numbers that proxy passes in INVITE to pstn gw: calling party
number, called party number AND diverter number.  in europe, the latter
is carried in idsn facility ie diversion leg2 parameter and i'm quite
sure there is something similar in n.a.  de facto way of carrying
diverter number is Diversion header, and there may be also some IETF
header for the same purpose.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 May 2006 13:44:38 -0500

> header for the same purpose.

If your gateway is doing an authentication check, who gets  
authenticated? The calling party or the diverting party?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 31 May 2006 21:51:41 +0300

> authenticated? The calling party or the diverting party?

gateway doesn't authenticate anybody, it is the proxy that does
authentication of calling party if calling party is local.  if called
local party has forwarded his calls, proxy adds called party's sip uri
in diversion header and rewrites r-uri with the new uri that called
party wants the call to be forwarded to.  this has been standard
practice with many voip providers for years.

-- juha