Odd disconnect?

[dswartz]

Made a call to a nearby town around 9:30PM EST. Almost exactly 30 minutes into the call, it was dropped and I heard fast busy. Redial went right through. Has anyone else had this happen?

[voxabox]

Made a call to a nearby town around 9:30PM EST. Almost exactly 30 minutes into the call, it was dropped and I heard fast busy. Redial went right through. Has anyone else had this happen?

by any chance you're using your own ATA, if you do see this thread
especially my post
BTW, I asked for a VOIPo approved ATA and it has been working OK

[dswartz]

Hmm, interesting. I could swear I've had calls longer than 30 minutes before. Also, NAT is not an issue for me (I re-read that thread), and if you scan back in it, you'll see I mentioned that my gateway runs asterisk, so NAT is not involved.

[voxabox]

Hmm, interesting. I could swear I've had calls longer than 30 minutes before. Also, NAT is not an issue for me (I re-read that thread), and if you scan back in it, you'll see I mentioned that my gateway runs asterisk, so NAT is not involved.

for me, NAT was not an issue, it seemed to be the fact that the SIP server did not see my ATA (SPA1001) as a non RFC 4028 compliant one; furthermore, the SIP server did not refresh the session timer (send the re-INVITE) as called for by the RFC

you could verify this by sniffing the SIP convo

BTW, is your ATA a linksys/sipura one?

the grandstream HT286 and its variants are the only few ATAs out there that support RFC 4028

[dswartz]

Uh, I don't have an ATA (I'm running asterisk, remember?)

[voxabox]

Uh, I don't have an ATA (I'm running asterisk, remember?)

oops, sorry, I did not have enough cafein

I still have my doubt that it is a NAT problem

anyways, do sip trace to see if asterisk supports session timer and who's responsible for the refresh

if you want, you can post the trace here (after some editing to protect the identity of the innocent)

[dswartz]

I doubt it too, since NAT isn't involved for me. I will be making a 30+ minute call tomorrow, so I will fire up a sniffer first.

Update: I tried calling my cellphone from the voipo number and after 30:16, it disconnected. Looking at ethereal trace now...

Update2: I don't see the update request either, and can confirm a BYE sent from the other end around 1800 seconds into the call. Bad news: asterisk 1.4 (what I am running) does NOT support RFC-4028. Possibly good news: asterisk 1.6 does (and that is much more stable now, as well as being (mostly) supported by freepbx 2.5. I will give a try to 1.6 and report back.

[dswartz]

Got asterisk 1.6 working (mostly, still a few minor issues), and made a 1-hour call from my cellphone to the voipo line. Analysis of the wireshark trace doesn't show any Session-Expires (unless I just wasn't looking in the right place.) If it isn't right, I don't know why I can make a 1-hour call and couldn't before

Update: maybe wireshark just wasn't decoding the packets right? Dunno. I did find a reference for 1.6 that said to set the sip options to 'session-timeout=originate', which will flag my end (the UAC) as the refresher and will reply if the UAS sends the refresh. All seems well, but I have to concur, it seems the openser implementation voipo is using is not complying with the RFC...

[voxabox]

Got asterisk 1.6 working (mostly, still a few minor issues), and made a 1-hour call from my cellphone to the voipo line. Analysis of the wireshark trace doesn't show any Session-Expires (unless I just wasn't looking in the right place.) If it isn't right, I don't know why I can make a 1-hour call and couldn't before

Update: maybe wireshark just wasn't decoding the packets right? Dunno. I did find a reference for 1.6 that said to set the sip options to 'session-timeout=originate', which will flag my end (the UAC) as the refresher and will reply if the UAS sends the refresh. All seems well, but I have to concur, it seems the openser implementation voipo is using is not complying with the RFC...

it's good to hear that it's working ok for you
IMHO, it's openser config/handling of non-RFC4028 compliant UACs
Cheers,
-v

[Brian]

So have we determined that the PAP2's can't do this successfully?