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

[Dave Horton]

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!

On Apr 14, 2011, at 2:47 PM, Kristian Kielhofner wrote:

Kamailio is making strides in handling media and transcoding but
practically speaking that's still some ways away.

It is true that "tweaking SIP headers" for interop is very much a fact
of life.  URI formats, URI parameters, caller id presentation types,
etc, etc.  However, at the point you're asking a B2BUA to pass a
Proxy-Auth header from one leg to the next I think you should rethink
your overall design and architecture...

Of course all of these projects are open source and you're free to
tweak/modify/mangle/break them any way you see fit and that's the
beauty of open source.  You just can't expect the developers that have
to support this code for eternity to accept a patch that so clearly
goes against the fundamental design of the software.

FreeSWITCH is a lot of things but when it comes to bridging calls it's
*always* a SIP B2BUA and that comes along with a fairly well (for SIP)
defined definition for how multiple legs are handled.  This is exactly
why the descriptive term for Kamailio has moved from "sip proxy" to
"sip server" over the years.

On Thu, Apr 14, 2011 at 2:18 PM, Dave Horton <dave at dchorton.com> wrote:
> 
> In my case, I am trying to use it as a simple transcoding server.  And the rich media support of codecs, and the ease of managing multiple sip profiles and setting up a back-to-back user agent scenario lend themselves quite well to the task IMO.  I don't think the other solutions handle media or transcoding at all (correct me if I'm wrong) so trying to build the solution using those platforms would actually leave quite a lot of heavy lifting to do.
> 
> I have built a lot of SIP apps over the past 10 years, on a lot of different networks, and I have found that it is critical to be able to tweak SIP headers to make these interop.  I wish it weren't the case, but it has been and still remains so.  FS seems to only allow true custom headers (e.g., X- headers) to be manipulated at this level, and I find it to be a shortcoming.
> 

-- 
Kristian Kielhofner