Subject: [Sip] SIP Recommended Call Flows for an MVNO?

From: "McFarland, Keith A." <[email-masked]>
Date: Tue, 21 Aug 2007 16:33:46 -0700

All,

I have been reviewing SIP documents at IETF and have come to the
conclusion that there is not an exact recommended procedure to cover my
desired use of the SIP implementation. As you can tell from my email
address I am the voice architect at Virgin Mobile USA, LLC. I am
currently, considering future implementations to interface with our
prepaid rating engine. As part of this consideration I am evaluating
leapfrog to IP call control versus an evolution within SS7. My
preference is to move to SIP if possible. However, in an MVNO the use of
SIP would vary slightly from the current best practices. I would
envision the SIP proxy to be replaced with a SIP 3rd Party Call
Authorization and Control Server.

This 3rd Party server does not sit in the middle of the SIP call flow
(as does a proxy or 3pcc) but sits off to the side and other proxies
(MSC or PSTN switches, in this case they act as SIP gateways) would call
out to this 3rd party SIP server to get direction on voice call
treatment. This call treatment could include just simple authorization
to proceed, denial, redirection with or without special treatment etc.
What I am trying to find is a best practices to cover this scenario.
Perhaps it exists and you could just help me out by pointing me to the
best practices document. If it doesn't, what are our options to go down
the path to develop one? We are willing to move forward with an
implementation of this but would prefer to do so with the support of a
best practices or recommended practices from IETF. Having this would
obviously benefit our efforts as we would have to work with multiple
switch vendors for any modifications. Obviously, it would be more
advantageous to these vendors to implement this if it is based off of
recommended practices as the resale potential goes up.

Appreciate your time,

Keith A. McFarland

Voice Architecture Manager

Virgin Mobile USA, LLC

925-457-6536   

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Sun, 26 Aug 2007 21:18:00 -0400

From: "McFarland, Keith A." <[email-masked]>

SIP allows a great many ways to process calls; I don't believe that
there are many "best practices" because SIP is very flexible, and as
long as system components follow the SIP rules, they can be truly
mix-and-matched.

One architecture you may want to consider is the one that the sipX
open-source proxy uses (see http://www.sipfoundry.org):  A call to
sip:[email-masked] is routed (via RFC 3263 mechanisms) to a "forking
proxy".  The forking proxy, through a small number of configured
rules, sends the call to the "redirector" (which also functions as the
registrar for the domain).  The redirector decides how the call should
be processed, and effects that decision by sending a 302 redirection
response back to the forking proxy.  The forking proxy acts on the 302
to send the call to the various allowed destinations.  The redirector
is modularized, and produces responses which incorporate registered
telephones for the URI, call forwarding, call park and pick-up, voice
mail fallback, etc.  The forking proxy is just a forking engine, and
need have no understanding of the policy or routing logic, it just
obeys the 302 that it is given.

In sipX, all outgoing requests from the forking proxy are then sent
to the "authorization proxy", which applies authorization rules, and
then sends the requests to their destinations.   This allows a
separation of function:

	forking proxy - the forking logic
	redirector - routing decisions
	authorization proxy - authorization decisions

The authorization proxy could be combined with the redirector without
complicating the structure much.  Only the authorization proxy
participates in a call after it is set up (the redirector is not
involved because it has given a 302 response and the forking proxy has
sent the call elsewhere, the forking proxy does not Record-Route
itself).

Dale

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Aug 2007 11:18:57 -0400

Why do you want to turn SIP into an authorization service?  Why wouldn't the
actual proxy use something like a web service or other data query/response
mechanism to ask your server what to do with the call?

Are you anticipating deploying this in an IMS environment?  If so, an
application server can do what you want.  In an non-IMS environment, every
server implementation I've seen has some way to access an external
authorization mechanism of one kind or another.  That would be proprietary,
but probably still the most appropriate response.

If you WANT to be on the call path, then you have a real proxy server, and
your proxy server would just respond with a redirect.  I presume that
"denial" is actually redirect to some announcement generator, so it's always
a redirect one way or another.

Brian

  _____  

From: McFarland, Keith A. [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 7:34 PM
To: [email-masked]
Subject: [Sip] SIP Recommended Call Flows for an MVNO?

All,

I have been reviewing SIP documents at IETF and have come to the conclusion
that there is not an exact recommended procedure to cover my desired use of
the SIP implementation. As you can tell from my email address I am the voice
architect at Virgin Mobile USA, LLC. I am currently, considering future
implementations to interface with our prepaid rating engine. As part of this
consideration I am evaluating leapfrog to IP call control versus an
evolution within SS7. My preference is to move to SIP if possible. However,
in an MVNO the use of SIP would vary slightly from the current best
practices. I would envision the SIP proxy to be replaced with a SIP 3rd
Party Call Authorization and Control Server.

This 3rd Party server does not sit in the middle of the SIP call flow (as
does a proxy or 3pcc) but sits off to the side and other proxies (MSC or
PSTN switches, in this case they act as SIP gateways) would call out to this
3rd party SIP server to get direction on voice call treatment. This call
treatment could include just simple authorization to proceed, denial,
redirection with or without special treatment etc. What I am trying to find
is a best practices to cover this scenario. Perhaps it exists and you could
just help me out by pointing me to the best practices document. If it
doesn't, what are our options to go down the path to develop one? We are
willing to move forward with an implementation of this but would prefer to
do so with the support of a best practices or recommended practices from
IETF. Having this would obviously benefit our efforts as we would have to
work with multiple switch vendors for any modifications. Obviously, it would
be more advantageous to these vendors to implement this if it is based off
of recommended practices as the resale potential goes up.

Appreciate your time,

Keith A. McFarland

Virgin Mobile USA, LLC

925-457-6536

---

From: "McFarland, Keith A." <[email-masked]>
Date: Mon, 27 Aug 2007 12:38:46 -0700

To answer your question, yes I am considering the implementation in an
IMS environment. I have theorized that an AS in that model would support
this. However, I was looking for some best practices flows that define
this. This would be of great benefit to have this when integrating with
various MSC (from multiple vendors) or other points. Additionally, I
don't envision a need to be on the call path necessary for setting up
the two call legs but rather just queried and passed call information
related to the call (one call leg per query) to perform real time
authorization billing etc from those messages. It seemed to me that the
natural evolution of the market place and that of SIP in general would
include this call flow more commonly in the future and I was seeking out
options of best recommended implementations.

The benefit to me of doing this via SIP is the natural evolution of this
implementation to VoIP later. Additionally, all the existing messages
and parameters necessary are defined in the SIP standard.

Thanks,

Keith A. McFarland

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 8:19 AM
To: McFarland, Keith A.; [email-masked]
Subject: RE: [Sip] SIP Recommended Call Flows for an MVNO?

Why do you want to turn SIP into an authorization service?  Why wouldn't
the actual proxy use something like a web service or other data
query/response mechanism to ask your server what to do with the call?

Are you anticipating deploying this in an IMS environment?  If so, an
application server can do what you want.  In an non-IMS environment,
every server implementation I've seen has some way to access an external
authorization mechanism of one kind or another.  That would be
proprietary, but probably still the most appropriate response.

If you WANT to be on the call path, then you have a real proxy server,
and your proxy server would just respond with a redirect.  I presume
that "denial" is actually redirect to some announcement generator, so
it's always a redirect one way or another.

Brian

________________________________

All,

 

Appreciate your time,

Keith A. McFarland

Virgin Mobile USA, LLC

925-457-6536