On Tue, Jun 3, 2008 at 12:28 PM, Hegner, Travis <[EMAIL PROTECTED]> wrote: > My provider is bandwidth.com. Unfortunately my environment also requires the > use of a SBC, which is adding even more with record-route and via headers. > > My first plan of attack is to set up a trixbox server to proxy through as a > b2bua. If it re-originates the call, then I think it may work as a temporary > solution. But I am still facing the direct media issue. My past experience > with trixbox is that it does not handle direct media very well. > > My next plan of attack is to do some custom work to strip the via headers in > my SBC, but keep track of each call and re-insert them on the packets return. > This is potentially a long-shot, but if it solves my issue than it will be > worth it. > > Direct media is an absolute requirement for my environment, and nothing I > have dealt with yet, including a couple of big names in the commercial phone > industry, has been able to fulfill our exact requirements. I will say as > kudos to sipx, it is the closest thing to exactly what we need, but with this > small inconvenience, it is still unusable.
At present sipxrbidge always relays media for communication with the phones that are registered with the ITSP. It assumes no NAT support for the phones on the pbx. Are your phones NAT-traversal enabled ( can you connect to the ITSP directly from behind a NAT?) Ranga > > My provider says that sip over tcp is still in 'alpha' testing, and they > won't release it to customers. They also refuse to do any work on fragmented > udp invites. Everything in my environment handles them without issue, but > their call traces show corruption on the re-assembly of the packet. The > corruption results in a failed call. > > Thanks again, > > Travis > > -----Original Message----- > From: Scott Lawrence [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 11:21 AM > To: Hegner, Travis > Cc: sipx-users@list.sipfoundry.org > Subject: Re: [sipx-users] Via Headers... > > > On Tue, 2008-06-03 at 09:46 -0400, Hegner, Travis wrote: >> Hello All, >> >> >> >> I am having an issue with sipx where my udp invite packet is too >> large. While everything locally appears to be handled correctly with a >> fragmented udp packet, my provider is refusing to support it. They >> also are not ready for sip over tcp yet. Upon examination of my invite >> packets, I have realized that for some reason sipx is adding itself >> into the Via headers three times, each with what seems to be >> unreasonably large branch id's. My goal is to get the invite packet >> size down to a level that my provider can accept without issue. >> >> >> >> My provider is set up as a sip trunk in sipx. I also have my provider >> set up through "internet calling" and I can complete calls from my >> soft phone with direct internet dialing (i.e. sip: >> [EMAIL PROTECTED]). In that scenario, sipx only adds itself to >> the Via Header list once, thereby reducing the initial invit by nearly >> 250 bytes, which is quite a bit with around a 1300 byte limit. >> Unfortunately, in order to use sipx as a true pbx, I need to be able >> to dial something like '918885551212' as an internal extension, and >> transform it and send it out on the sip trunk. Internet dialing is >> very difficult (i.e. impossible for my users) to do from a hard phone. >> >> >> >> I don't know yet what all the sipXbridge is supposed to offer in ver >> 4.0, but I know that I don't need a full b2bua, and I definitely do >> not want to route media, I need a direct media path. I am basically >> looking for some advice on reducing my invite packet size, if that is >> at all possible. > > There's no way to significantly reduce the INVITE request sizes you're > seeing now. > > Who is the provider? > > Realistically, running through a proxy is going to add some headers - > admittedly, it would be good if there weren't so many, but there's no > easy way to change that at the moment. > > There are many features of SIP that add to message sizes, and it is now > fairly widely recognized that a 1300 byte "limit" is not enough for real > use over the internet. > > The sipXbridge will indeed substantially reduce what gets sent. I don't > know whether or not its current incarnation can allow media bypass when > media NAT compensation isn't needed (Ranga?) > > -- > Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] > sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs > CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ > http://www.pingtel.com/ > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users -- M. Ranganathan _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
