PDA

View Full Version : Call Timer ?



Montano
08-07-2008, 05:13 AM
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 ?

dswartz
08-07-2008, 07:07 AM
I doubt it. I've been on 60 min calls.

voxabox
08-07-2008, 08:23 AM
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 ?
was it an outbound call?
FWIW, I've been experiencing this several times with my SPA1001 on sip.voipwelcom.com lately

NY Tel Guy
08-07-2008, 09:13 AM
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 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.

dswartz
08-07-2008, 10:06 AM
Dunno if this is related, but I am now unable to make outbound calls. I get CONGESTION.

p.s. I opened a ticket...

burris
08-07-2008, 11:06 AM
No problems in my area..

quattrohead
08-07-2008, 11:32 AM
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.

Montano
08-07-2008, 01:18 PM
was it an outbound call?
FWIW, I've been experiencing this several times with my SPA1001 on sip.voipwelcom.com lately

Yes it was. I'm using a PAP2T.

voxabox
08-07-2008, 01:54 PM
Yes it was. I'm using a PAP2T.
do some more outbound calls to see if it's still a problem
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

VOIPoNorm
08-08-2008, 09:02 AM
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

chpalmer
08-08-2008, 09:48 AM
My wife had this happen to her yesterday also.

Ill do some testing later to verify.

voxabox
08-08-2008, 11:48 AM
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
unless something was really wrong with AT&T/SBC 2wire 27001HG-B
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

voxabox
08-19-2008, 08:02 PM
Montano,
please check your pm

voxabox
08-21-2008, 08:01 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 (http://www.ietf.org/rfc/rfc4028.txt);
however, the dropped calls were due to the missing?!? session refresh from the UAS

here's the SIP convo:


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;b ranch=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,SUBSCRIB E,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:

Supported: timer

nor specified:


Min-SE
Session-Expires: 1800;refresher=uas


notice server resp to the INVITE includes:

Supported: timer
Session-Expires: 1800;refresher=uas
Content-Length: 194
Content-Disposition: session; handling=required

row 1 in Table 2: UAS Behavior in section 9. UAS Behavior in the RFC 4028 Session Timer (http://www.ietf.org/rfc/rfc4028.txt) 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 timer

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


now very looks good as far as the UAS resp concerns, but there was no refreshing seen in the log...
the UAS dropped the session just right before 1800sec session expire time - it did what it was called for by the RFC



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=z9hG4bK0eB936466b db6b101ce

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


could someone confirm my finding?
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)

voxabox
08-21-2008, 08:52 PM
while analyzing the log, I ran into the use of SIP PING method


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

AFAIK, The SIP PING Method (http://ftp.ist.utl.pt/pub/drafts/draft-fwmiller-ping-03.txt) never became a Standards Track

Could someone comment on the effect of the SPA1001's resp.? specifically the "404 Not Found"

VOIPoNorm
08-22-2008, 05:18 AM
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

dswartz
08-22-2008, 06:16 AM
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.

VOIPoNorm
08-22-2008, 06:48 AM
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

voxabox
08-22-2008, 07:41 AM
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 right
besides OPTIONS NOTIFY/PING ICE is (probably) the best way to deal with NAT issues