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

From: Dean Willis <[email-masked]>
Date: Wed, 31 May 2006 23:25:26 -0500

On May 31, 2006, at 1:51 PM, Juha Heinanen wrote:

> Dean Willis writes:
>
>> If your gateway is doing an authentication check, who gets
>> 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.

Ok, so the gateway is just trusting the proxy. Yes, this technically  
works.

Now, when you expand it into a scenario where the gateway is in a  
different trust domain, and it (or a trusted proxy in front of it)  
needs to authenticate the call, you're back to where we were, needing  
a B2BUA or a new "charging-to identity" model.

Like I said, the current technique doesn't solve the general problem.  
But if the constrained problem (gateway within trust domain of  
forwarding proxy) is all you need solved, that's great. I've been  
running into broader versions of the problem in some environments,  
and I'm afraid it's made a bit cranky (or crankier).

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 02 Jun 2006 00:08:01 -0400

IMHO, much of this discussion about call diversion and charging is not
particularly useful, either because it neglects unavoidable aspects of
SIP, or because it assumes that the billing environment will resemble
the PSTN very closely (especially in that charges to any particular
destination are computable in advance).

More specifically, my peeves are:

- Let us not consider 3xx responses special, because any atrocity that a
SIP agent can commit by returning a 3xx response, it can commit by
acting as a proxy and forwarding the response itself to what would
otherwise be the Contact in a 3xx response.  Thus, restricting,
modifying, or even eliminating 3xx responses *will not* eliminate any of
the problems we've been discussing.  Fixating on 3xx responses can only
happen when one assumes that the user's instrument is confined to only
terminating dialogs, but in SIP, an agent can decide to terminate or
proxy an INVITE on a case-by-case basis.

- Let us not hope that restricting "redirection" will solve the problem,
as there is no general way to distinguish the redirections that are
needed to make the SIP infrastructure work from those that are
potentially abusive.  From a SIP point of view, the redirection of
sip:[email-masked] to sip:[email-masked] is no different from the
redirection of sip:[email-masked] to sip:[email-masked].

- Let us give up on the idea that simply identifying the "party to be
billed" will work very well, either, as the actual destination of the
call isn't known to the agent that provides a destination address,
either of the original INVITE or any "diverted" forwarding of the
INVITE.

We need to take a bit more generalized view, and realize that:

- As a call passes through various SIP agents, various legal entities
may want to charge the call, and the actual charges will be a
complicated function (possibly time-dependent) of the endpoints and
sometimes the intermediate agents.

- Because of this, authorization-to-bill may need to be dynamically
negotiated between the agent that is accepting billing and the agents
that wish to bill, as the charges may not be predicable in advance.

In a narrow case, charges may be predictable enough that a blanket
policy can work.  E.g., the common US corporate gateway policy of "If
the call comes from one of our phones, and it is for any ordinary
destination in the US, allow it" is workable in many organizations, but
mostly because US long-distance charges are small enough that an
employee's time is worth considerably more than any charges he could
incur.  But as people have noted, adding extra-cost pay-per-call
destinations breaks this situation.

To construct a mechanism that won't be stymied by the more complicated
situations, we need to view INVITEs as carrying authorization-to-bill
indicators, which may be added and replaced by UAs and proxies, and we
must define suitable request-authorization-to-bill responses to enable
dynamic negotiation of billing.

Consider a fairly normal US corporate situation, with a gateway to the
PSTN that can make calls to any US destination, either at ordinary PSTN
rates, or at higher pay-per-call rates for certain (identifiable)
numbers.  But there are also "SIP trunk" lines that bring SIP
connections into the organization, as well as a gateway for accepting
calls from the PSTN and forwarding them to the corporate proxy.

- We want to allow all calls to reach all corporate phones.

- We want to allow corporate users (except for a few lobby phones) to
make any outgoing calls, but extra-charge calls need an additional
manual authorization to be activated on the originating phone.

- We want to allow non-lobby phones to divert incoming calls to
arbitrary destinations, including PSTN numbers, but excluding extra-
charge numbers.  (Or equivalently, the proxy can perform the diversion
on behalf of the phones.)

To implement this:

- We set up the outgoing gateway to negotiate for and accept two types
of authorization-to-bill, one for ordinary PSTN rates and one for pay-
per-call rates.  (Or equivalently, the proxy can perform this function,
and notify the gateway when a call is allowed.)

- Corporate phones (except the lobby phones) attach to all INVITEs an
authorization-to-bill that the gateway will accept for ordinary PSTN
calls.

- If a corporate phone is challenged for an authorization-to-bill that
is acceptable for extra-cost calls, it will notify its user and wait for
user acceptance before retrying the INVITE with the enhanced
authorization-to-bill.

- If an INVITE is diverted, the diverting phone will attach to it an
authorization-to-bill for ordinary PSTN calls.  To prevent callers from
having unexpected charges, it will either strip any previous
authorizations-to-bill, or place its authorization-to-bill at a higher
precedence.

- The incoming PSTN gateway attaches no authorization-to-bill to INVITEs
it generates.

- Calls coming in through the "SIP trunks" retain whatever
authorizations-to-bill they have (because this organization has no
reason to care about them).

It's possible that a simpler infrastructure would work in this
situation, but in any more complex situation, it will break down into a
muddle.  We've really got to tackle the general case.

Dale

---

From: "Nataraju A B" <[email-masked]>
Date: Thu, 29 Jun 2006 17:36:56 +0530

I am not sure this is already captured in the earlier comments or not :(

Here is a minor change required... 

In the diagram its been mentioned as Bill whereas the description
mention it as carol. 
// from draft - starts 
2.17.  Call Pickup

            Alice          Bob                Bill
             |              |                   |

   Also note that the subscription between Bob and Carol could have been
							^^^^^
   established prior to Alice's call.
// from draft - ends

Thanks & Regards,
Nataraju A.B.