Wanted to provide a quick update on this since I wanted to clarify that it wasn't a problem with either sipx or bandwidth.com. This past week XO communications had come back out to repair our ethernet circuit and in the process of doing so had changed our external IP. Previously, I had set this statically with on the NAT screen instead of using STUN and after this last episode with XO I changed it to STUN. Unfortunately, it still used our old external IP address.
Not sure why bandwidth.com was able to establish the call in the first place and why this would manifest as a 481 but we have been having success since we changed it to the new external IP. So far so good! Related issue: http://track.sipfoundry.org/browse/XX-6012 Thanks, Jarrod On Fri, Apr 6, 2012 at 10:05 AM, Tony Graziano <[email protected] > wrote: > the session interval timer is set for 30 minutes by default (1800 > seconds). > > I posted vigorously about bandwidth.com and their problems with dtmf and > then not honoring ptime of 20ms and playing media services at 30ms over the > two past shipping versions of sipx. > > I actually think all of this is due to interop issues with freeswitch > (media server) and bandwidth.com rather than the trunk settings. > > I am going to assume because of this past research that the issue is that > bandwidth.com is killing the connection because they are not getting the > ack back from the media server instead of from the trunk. > > We used to like bandwidth.com at my place a lot, but we have since moved > every customer off them for these and other reasons (some of them long > outages). The rest were actually due to media server issues and not general > trunking problems though. > > > > On Fri, Apr 6, 2012 at 12:49 PM, Michael Picher <[email protected]> wrote: > >> try playing with keepalive settings on the trunk... >> >> also, may be a firewall issue, not even related to SIP... >> >> but start with keepalive... >> >> On Fri, Apr 6, 2012 at 12:32 PM, Jarrod Cuzens <[email protected]> wrote: >> >>> We are having an issue where Bandwidth.com drops our conference call >>> after about 15 minutes. Attached is the sipxtrace. I know a lot of people >>> use Bandwidth.com so I'm wondering if someone can provide insight. >>> >>> Basically, the call goes along fine and then a REINVITE occurs and >>> Bandwidth.com returns a 481. >>> >>> INVITE sip:[email protected]:5060 SIP/2.0^M >>> Via: SIP/2.0/UDP 216.55.27.54:5080 >>> ;branch=z9hG4bK004f2e385f3b8153396a7e0d3e17526f313833^M >>> CSeq: 2 INVITE^M >>> From: "sipxbridge" <sip:[email protected] >>> >;tag=7663711578417146310^M >>> To: <sip:[email protected];user=phone>;tag=gK0db35f58^M >>> Call-ID: [email protected]^M >>> Content-Disposition: session;handling=required^M >>> Max-Forwards: 70^M >>> Route: <sip:216.82.224.202:5060;lr;ftag=7663711578417146310>^M >>> User-Agent: sipXecs/4.4.0 sipXecs/sipxbridge (Linux)^M >>> Allow: INVITE,BYE,ACK,CANCEL,OPTIONS^M >>> Accept: application/sdp^M >>> Content-Type: application/sdp^M >>> Contact: <sip:216.55.27.54:5080>^M >>> Session-Expires: 1800;refresher=uac^M >>> Min-SE: 90^M >>> Content-Length: 198^M >>> ^M >>> v=0^M >>> o=sipxbridge 7423237425625656682 1 IN IP4 216.55.27.66^M >>> s=SIP Call^M >>> c=IN IP4 216.55.27.66^M >>> t=0 0^M >>> m=audio 30280 RTP/AVP 0 8^M >>> a=sendrecv^M >>> a=rtpmap:0 PCMU/8000^M >>> a=ptime:20^M >>> a=rtpmap:8 PCMA/8000^ >>> >>> SIP/2.0 100 Giving a try^M >>> Via: SIP/2.0/UDP 216.55.27.54:5080 >>> ;branch=z9hG4bK004f2e385f3b8153396a7e0d3e17526f313833;received=216.55.27.66^M >>> CSeq: 2 INVITE^M >>> From: "sipxbridge" <sip:[email protected] >>> >;tag=7663711578417146310^M >>> To: <sip:[email protected];user=phone>;tag=gK0db35f58^M >>> Call-ID: [email protected]^M >>> Server: Bandwidth.com TRM (bw7.gold.13)^M >>> Content-Length: 0 >>> >>> SIP/2.0 481 Call Leg/Transaction Does Not Exist^M >>> Via: SIP/2.0/UDP 216.55.27.54:5080 >>> ;received=216.55.27.66;branch=z9hG4bK004f2e385f3b8153396a7e0d3e17526f313833^M >>> From: "sipxbridge" <sip:[email protected] >>> >;tag=7663711578417146310^M >>> To: <sip:[email protected];user=phone>;tag=gK0db35f58^M >>> Call-ID: [email protected]^M >>> CSeq: 2 INVITE^M >>> Content-Length: 0 >>> >>> Thanks, >>> Jarrod >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> Michael Picher, Director of Technical Services >> eZuce, Inc. >> >> 300 Brickstone Square**** >> >> Suite 201**** >> >> Andover, MA. 01810 >> O.978-296-1005 X2015 >> M.207-956-0262 >> @mpicher <http://twitter.com/mpicher> >> www.ezuce.com >> >> >> ------------------------------------------------------------------------------------------------------------ >> There are 10 kinds of people in the world, those who understand binary >> and those who don't. >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.465.6833 > ~~~~~~~~~~~~~~~~~~ > Linked-In Profile: > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > ~~~~~~~~~~~~~~~~~~ > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> > Blog: http://blog.myitdepartment.net > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
