[Freeswitch-users] Relay Proxy-Authentication requests to the caller

[Dave Horton]

Hi Kristian - 

I'm not quite grasping the alternative solution you are describing, and I 
certainly would like to if there is an alternative.  In hopes of clarifying
my understanding, let me respond to some of your questions on the
architecture:

>>You said you have multiple remote FreeSWITCH PBXs deployed around
the globe.  I assume you have control over these PBXs?  

[DH] Yes, I have control over the configuration of these FS PBXs.  Of course, 
to minimize operational headaches, I want to simplify and standardize their
configuration as much as possible.  My current solution uses a very vanilla
configuration, with pretty much only two changes out of the box, 
which is the (a) addition of a gateway to point to the NA-based service provider, 
and (b) enabling speex in the list of supported codecs.

Why not deploy another system (FreeSWITCH and/or Kamailio) and configure it as an
outbound proxy to do your transcoding?  

[DH]  Hmm.  This is where I'm not clear.  I understand the use of an outbound proxy, 
but usually I am familiar with those being deployed at the customer premise, 
to funnel all traffic through to the internet and provide any associated features
(e.g., billing, limiting, and yes transcoding if needed).  However, the  transcoding 
that I need to do at the customer premise side is being done by the FS PBX natively, 
because FS already supports speex.  So there is no need for an additional transcoding
resource at the customer side. I am simply going to have the media stream encoded 
in speex by FS as leaves (no changes needed to FS config for this, other than those above), 
and the point of transcoding back to PCMU needs to happen on the other end, 
once it gets in the service provider network.  Any calls originating from the FS PBX that use
the gateway may offer multiple codecs in the INVITE (the list will include speex by virtue of
the config change mentioned above), but the 1xx/200 responses coming
back from the service provider gateway will only offer speex.  

....No code changes in FreeSWITCH (the remote PBX or otherwise) 

[DH] Right.  I definitely want no changes to FS code at remote PBXs, and
my current solution does achieve that.  The only thing I am doing
is plopping a transcoding server in the service provider core network.  The
PBXs are plain vanilla FS with simple configurations.

As far as the no transcoding option, G.729 *is* a possibility (the others
are not because they are not supported by the service provider
endpoints, though the service provider customer has some
gear that does not support G.729 and prefers PCMU within
his network.

So in the end, I'm mostly a pragmatic (read: lazy) kind of guy, 
and since I was able to solve my problem in about 4 hours
by building a simple transcoding server using FS (positioned
in the core service provider's network) I guess I'm pretty satisified at this point.

Dave

On Apr 15, 2011, at 9:58 AM, Kristian Kielhofner wrote:

Dave,

 With a project as large and complex as FreeSWITCH I highly recommend
you don't try to maintain a patch separately.  That's the double edge
sword of open source - it will bite you eventually.  I've found that
the best approach is to make your goals align with those of the
developers so your patches (if necessary at all) are accepted.

 When the only tool you have is a hammer every problem looks like a
nail...  You've already decided you need "a simple transcoding server"
and that's what you're looking for from FreeSWITCH even though the way
you've decided to implement it doesn't fit very well with FreeSWITCH.
Instead of forcing a square peg into a round hole perhaps this could
be viewed from 30,000 ft again and re-evaluated.  That's what I was
suggesting with my previous response.

 You said you have multiple remote FreeSWITCH PBXs deployed around
the globe.  I assume you have control over these PBXs?  Why not deploy
another system (FreeSWITCH and/or Kamailio) and configure it as an
outbound proxy to do your transcoding?  No code changes in FreeSWITCH
(the remote PBX or otherwise) and you maintain compatibility with
every system and piece of software out there.  FreeSWITCH, Asterisk,
dumb ATAs, phones, etc, etc - all can be configured to use an outbound
proxy and you even have more freedom over which software/hardware you
select for your "transcoding server".

 The selection of speex is curious too.  While certainly offering
bandwidth savings it's almost certainly not supported by your
endpoints on the PBX or your provider.  What codec do they use?  What
does your codec path currently look like? PCMU <-> Speex <-> PCMU?
Why not use G729, iLBC, GSM, or potentially some other low bandwidth
codec that may be supported by both your endpoints and your IP
provider (G729 being the most likely) thus eliminating the need for a
transcoding server at all?  Less media proxying, less delay/quality
issues due to transcoding, and you save some CPU cycles.

 While there is some debate over the role/definition of a B2BUA in
SIP most descriptions contain "splitting the call into two halves" and
the concept of the B2BUA being both the UAS and the UAC.  Passing
Proxy-Auth from one leg to the other is pretty clearly, in my opinion,
outside of these descriptors.

 More than anything (as you can probably tell by now) I enjoy
debating SIP architecture especially when there can be an especially
civil and respectful discourse.  This is unfortunately becoming
exceedingly rare on the internets these days (damn kids).

On Thu, Apr 14, 2011 at 3:23 PM, Dave Horton <dave at dchorton.com> wrote:
> Hi Kristian -
> 
> I appreciate your thoughts/feedback/guidance, as well as the manner in which they were delivered.
> At the risk of prolonging a thread that perhaps has reached the point of maximal usefulness, I'd like to
> respond briefly to a few points:
> 
> 1) I don't intend to submit a patch, because I agree it seems to go against what FS wants to do --
> at least, as best I can understand what FS wants to do since as a newbie I'm sort of puzzling that out as I go
> by means of this forum, reading the book, etc.
> However, FS seems to somewhat have the burden of success, in that "what it wants to do" and
> "what it can do" seem to be overlapping but not exactly equal sets (the second being larger) --
> due to its flexibility it seems that FS can do quite a bit, as in my case of needing to whip up
> a simple transcoding server.
> 
> 2) I don't think there is much to re-think about the overall design and architecture in my case,
> simply because I need a transcoding server to sit a certain point in a service provider's network
> and that's that.  In my case, I have multiple remote FS PBXs around the globe transmitting
> to a gateway in a service provider in the US for PSTN access, over a bandwidth constrained
> satellite link.  Therefore speex 8ks make sense over the satellite link, but then I need to
> transcode back to PCMU once in the service providers network.  Authentication is unfortunately
> inextricably tied up with establishing the media path since credentials are carried in the INVITE.
> 
> 3) I am personally mostly interested in building applications that run in a service provider core network, not out on the edge.
> I'd be interested to know if this is considered in the target of what FS wants to be?  Obviously,
> FS is first and foremost a PBX, but of course its not limited to such.  Asterisk, as an example, was
> adopted by some service providers for various "application server" types of applications,
> sometimes with success, sometimes without.
> 
> 4) In service provider networks, almost all "interesting" applications are B2BUA.
> And I would disagree that SIP has a well-defined set of constraints on what
> a B2BUA can and should be.  To the contrary, I think its pretty wide open
> (at least by comparison to specifications for proxies, e.g.)
> 
> 5) This question of handling (or not) SIP headers doesn't seem to be
> documented consistently.  In the FS book, there is a note that suggests
> you *should* only mess with X- headers, but implies you are not limited
> to doing so.  In fact, I see no way to get at the other headers (other than
> the obvious suspects -- to, from, contact, etc -- and one or two special cases
> -- alert-info -- that seemed to have been plucked out over time).  It
> just doesn't seem like it would be all that difficult to provide access
> to all the sip headers for developers that might need them).
> 
> Finally, as a newbie to FS, but with some experience building SIP platforms
> and applications for a bit, I would be remiss in not congratulating the developers
> on the great product they have created.  Well done!
> 

-- 
Kristian Kielhofner