My wife was on a call yesterday and the phone just died at the 30 minute mark. She heard a fast busy signal in the middle of her conversation. Is this just a one time event, or are calls set to cut off after 30 minutes ?
Printable View
My wife was on a call yesterday and the phone just died at the 30 minute mark. She heard a fast busy signal in the middle of her conversation. Is this just a one time event, or are calls set to cut off after 30 minutes ?
I doubt it. I've been on 60 min calls.
was it an outbound call?Quote:
Originally Posted by Montano
FWIW, I've been experiencing this several times with my SPA1001 on sip.voipwelcom.com lately
I made a call yesterday for 1:39 minutes and did not get cut off. What I had experienced yesterday is fast busies when dialing another number right after hanging up from a call. Also, I cannot get 3 way calling to work.Quote:
Originally Posted by Montano
Dunno if this is related, but I am now unable to make outbound calls. I get CONGESTION.
p.s. I opened a ticket...
No problems in my area..
All OK here, although I did have to reboot the ATA the other day as I could not make out going calls then but incoming was OK.
Yes it was. I'm using a PAP2T.Quote:
Originally Posted by voxabox
do some more outbound calls to see if it's still a problemQuote:
Originally Posted by Montano
My outbound call lost incoming audio 30 minutes later this morning (the other party still heard me fine)
I suspect that 2wire 2701HG-B NAT handling is the culprit, but I cannot prove it yet as the ATA is out of state
FWIW, inbound calls are fine
One way audio problems can most of the time be traced to NAT (I agree with what you suspect). The loss of inbound RTP (audio) sometime after the call started might indicate the router (performing NAT) has closed the RTP port.
Can you try to correlate the time before the loss of audio happens with one the NAT router timeout settings ? If you can find a match, it would help to get a little closer to the source of the problem.
Regards,
Norm
My wife had this happen to her yesterday also.
Ill do some testing later to verify.
unless something was really wrong with AT&T/SBC 2wire 27001HG-BQuote:
Originally Posted by VOIPoNorm
UDP timeout was set to 720 minutes, and the NAT timeout was set to the same value. ATA NAT keep-alive, 15 secs
The setup was stable until recently
Montano,
please check your pm
ok,
I think I've found what caused the 30 minutes dropped calls
it seems that the linksys/sipura ATA does not support RFC 4028 Session Timer;
however, the dropped calls were due to the missing?!? session refresh from the UAS
here's the SIP convo:
Code:Jan 4 11:51:10 000E08BBB0E8 [0:5062]->74.52.58.50:5060
Jan 4 11:51:10 000E08BBB0E8 [0:5062]->74.52.58.50:5060
Jan 4 11:51:10 000E08BBB0E8 INVITE sip:PROTECTED@sip.voipwelcome.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.205:5062;branch=z9hG4bK-f5babb26
From: PROTECTED <sip:PROTECTED@sip.voipwelcome.com>;tag=20475daff076053eo0
To: <sip:PROTECTED@sip.voipwelcome.com>
Remote-Party-ID: PROTECTED <sip:PROTECTED@sip.voipwelcome.com>;screen=yes;party=calling
Call-ID: be9cc743-deab88ba@192.168.1.205
CSeq: 101 INVITE
Max-Forwards: 70
Contact: PROTECTED <sip:PROTECTED@PROTECTED:5062>
Expires: 240
User-Agent: Linksys/SPA1001-3.1.19(SE)
Content-Length: 384
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura, replaces
Content-Type: application/sdp
--------------(SDP not shown)--------------
Jan 4 11:51:16 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 11:51:16 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 11:51:16 000E08BBB0E8 SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.205:5062;rport=5062;received=PROTECTED;branch=z9hG4bK-fa29c5ee
From: PROTECTED <sip:PROTECTED@sip.voipwelcome.com>;tag=20475daff076053eo0
To: <sip:PROTECTED@sip.voipwelcome.com>;tag=gK0ecbcd2f
Call-ID: be9cc743-deab88ba@192.168.1.205
CSeq: 102 INVITE
Record-Route: <sip:74.52.58.50:5060;lr=on;ftag=20475daff076053eo0>
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:PROTECTED@PROTECTED:5060;nat=yes>
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Supported: timer
Session-Expires: 1800;refresher=uas
Content-Length: 194
Content-Disposition: session; handling=required
Content-Type: application/sdp
--------------(SDP not shown)--------------
even though the UAC (ATA)'s INVITE did not include:
nor specified:Code:Supported: timer
notice server resp to the INVITE includes:Code:Min-SE
Session-Expires: 1800;refresher=uas
row 1 in Table 2: UAS Behavior in section 9. UAS Behavior in the RFC 4028 Session Timer says: (my interpretation) in the case where UAC's INVITE does not include session timer, nor refresher in its header; the UAS is responsible for refreshing/resetting the session timerCode:Supported: timer
Session-Expires: 1800;refresher=uas
Content-Length: 194
Content-Disposition: session; handling=required
now very looks good as far as the UAS resp concerns, but there was no refreshing seen in the log...Code:UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
Table 2: UAS Behavior
the UAS dropped the session just right before 1800sec session expire time - it did what it was called for by the RFC
could someone confirm my finding?Code:Jan 4 12:21:16 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 12:21:16 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 12:21:16 000E08BBB0E8 BYE sip:PROTECTED@75.75.82.60:5062;nat=yes SIP/2.0
Record-Route: <sip:74.52.58.50;lr=on;ftag=gK0ecbcd2f>
Via: SIP/2.0/UDP 74.52.58.50;branch=z9hG4bK1abc.47433cc2.0
Via: SIP/2.0/UDP PROTECTED:5060;rport=5060;branch=z9hG4bK0eB936466bdb6b101ce
From: <sip:PROTECTED@sip.voipwelcome.com>;tag=gK0ecbcd2f
To: "PROTECTED" <sip:PROTECTED@sip.voipwelcome.com>;tag=20475daff076053eo0
Call-ID: be9cc743-deab88ba@192.168.1.205
CSeq: 2622 BYE
Max-Forwards: 69
Content-Length: 0
the easiest way is to sniff the SIP convo (VOIPo GS ATA) and look for the refresh(es) (UPDATE/re-INVITE) - should take place at 1/2 the "Session-Expires"'s value (RFC 4028 recommendation)
while analyzing the log, I ran into the use of SIP PING method
AFAIK, The SIP PING Method never became a Standards TrackCode:Jan 4 11:51:52 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 11:51:52 000E08BBB0E8 [0:5062]<<74.52.58.50:5060
Jan 4 11:51:52 000E08BBB0E8 OPTIONS sip:75.75.82.60:5062 SIP/2.0
Via: SIP/2.0/UDP 74.52.58.50:5060;branch=0
From: sip:ping@voipo.com;tag=ab2e4064
To: sip:75.75.82.60:5062
Call-ID: 64b715d4-660a73f5-a2123@74.52.58.50
CSeq: 1 OPTIONS
Content-Length: 0
Jan 4 11:51:52 000E08BBB0E8 [0:5062]->74.52.58.50:5060
Jan 4 11:51:52 000E08BBB0E8 [0:5062]->74.52.58.50:5060
Jan 4 11:51:52 000E08BBB0E8 SIP/2.0 404 Not Found
To: sip:75.75.82.60:5062;tag=d3e55bca2d4d79dfi0
From: sip:ping@voipo.com;tag=ab2e4064
Call-ID: 64b715d4-660a73f5-a2123@74.52.58.50
CSeq: 1 OPTIONS
Via: SIP/2.0/UDP 74.52.58.50:5060;branch=0
Server: Linksys/SPA1001-3.1.19(SE)
Content-Length: 0
Could someone comment on the effect of the SPA1001's resp.? specifically the "404 Not Found"
Hi,
The SIP Method is "OPTIONS". "PING" is just as used in the SIP From header.
The OPTIONS method you are tracing is used to assist in keeping NAT ports open. There have been discussions as to the best way to keep NAT ports open, and most people have their own opinion on the matter. This use of the OPTIONS method is common and it would be nice if the standards formalized a mechanism to help with this problem.
Regards,
Norm
Good point, Norm. This is one reason a couple of years back that I moved asterisk to my gateway (to eliminate NAT) as I was having a very similar issue (with a different provider). It was something NAT related and I came up dry trying to resolve it.
ICE was developed to address the NAT problem.
Problem is that the UAC (ATA's or IP Phones) have to support the protocol. Going to have to wait on the vendors and their timeframes for this.
Norm
you're absolute rightQuote:
Originally Posted by VOIPoNorm
besides OPTIONS NOTIFY/PING ICE is (probably) the best way to deal with NAT issues