Call Timer ?

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

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

**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;
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)

**voxabox** · 08-21-2008 08:52 PM

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"

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

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