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. On Apr 14, 2011, at 2:11 PM, Kristian Kielhofner wrote: These requests have baffled me... Are you trying to use FreeSWITCH as an outbound proxy (or something)? This type of low-level SIP mangling is usually more well suited to OpenSIPS, Kamailio, etc. Even then you'd have some work cut out for you... On Thu, Apr 14, 2011 at 1:36 PM, Dave Horton <dave@dchorton.com> wrote:

I had the same question/issue myself, and would be interested to know if there is a way. For myself, I had to do two things to get this to work: 1. Disable authentication so that FS would not itself generate a challenge. In vars.xml I added this: <X-PRE-PROCESS cmd="set" data="internal_auth_calls=false"/> and in my internal.xml (because calls were coming in on my internal profile): <param name="accept-blind-auth" value="true"/> 2. Then I had to hack mod_sofia to create a new channel variable containing the received Proxy-Authorization on the inbound leg, and also let me set it on the outbound leg. After that it worked, but I would still prefer a solution that didn't require changing mod_sofia, if one exists...

...

...

Hi All!

...

...

...

...

I would like to know if there is a param we could set in sofia profile to let freeswitch relay Proxy-Authentication requests to the caller instead of absorbing it.

...

...

...

...

Regards,

...

...

Hamid

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Kristian Kielhofner

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

Dave, Welcome to the FS community! Thanks for your input. We always appreciate it when experienced newbies come in and start using the software. Thanks for the feedback. I think you'll find that everyone here listens and responds to feedback respectfully, whether they agree or disagree. Oh, and if someone is blunt or rude please don't take it personally. Everybody has a bad day now and then. :) Now, on to your main issue: tweaking SIP headers and similar actions. I can hear Tony (main dev) cringe when he sees that phrase. If you've been doing SIP for 10 years then you know better than most just how crazy the RFCs are and how loosely some people interpret them. That's one of the core reasons why interop is such a challenge. We have a bit of a mantra around here, and I suppose it goes something like this: we don't pander to people who do stupid things with SIP just for the sake of interop. It's also been put this way: just say "no". (Tip 'o the hat to Nancy Reagan ;) The FS devs have no desire to dig one character deeper into the SIP stack than they absolutely have to. It may seem that you are asking for a simple feature. However, allowing FreeSWITCH (a B2BUA) to "tweak SIP headers" is ridiculously complicated. If you don't believe me then go look at mod_sofia.c and sofia.c and sofia_glue.c and sofia_reg.c and sofia_presence.c and sofia_sla.c. That's just so FreeSWITCH can talk to the SIP stack! libsofia is another monster. So the bottom line from the development viewpoint is that we have to say "no" to some things. I know that may seem arbitrary and maybe even capricious but I can assure you that it is not. One of the reasons that FreeSWITCH is so stable and efficient is that it doesn't not try to be "all things SIP" to everyone. I hope you can see our viewpoint. In your specific use case it sounds like you really do need a true proxy server in addition to a media server. Others may have some thoughts. Are there any other OSS communications software packages that can do all this, i.e. be a SIP proxy and media server? (And do it reliably?) -MC

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