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

[Kristian Kielhofner]

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