Call Timer ?

Printable View

Show 40 post(s) from this thread on one page

08-08-2008, 09:48 AM
chpalmer

Re: Call Timer ?

My wife had this happen to her yesterday also.

Ill do some testing later to verify.
08-08-2008, 11:48 AM
voxabox

Re: Call Timer ?

Quote:

Originally Posted by VOIPoNorm

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
08-19-2008, 08:02 PM
voxabox

Re: Call Timer ?

Montano,
please check your pm
08-21-2008, 08:01 PM
voxabox

Re: Call Timer ?

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:

Code:

Supported: timer

nor specified:

Code:

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

notice server resp to the INVITE includes:

Code:

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 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

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

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

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

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)
08-21-2008, 08:52 PM
voxabox

Re: Call Timer ?

while analyzing the log, I ran into the use of SIP PING method

Code:

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 never became a Standards Track

Could someone comment on the effect of the SPA1001's resp.? specifically the "404 Not Found"
08-22-2008, 05:18 AM
VOIPoNorm

Re: Call Timer ?

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

Re: Call Timer ?

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

Re: Call Timer ?

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
08-22-2008, 07:41 AM
voxabox

Re: Call Timer ?

Quote:

Originally Posted by VOIPoNorm

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

Show 40 post(s) from this thread on one page