<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft DHTML Editing Control">
<TITLE></TITLE>
</HEAD>
<BODY
style="BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none; FONT-FAMILY: 굴림; BORDER-TOP-STYLE: none; FONT-SIZE: 13px; BORDER-LEFT-STYLE: none">
<DIV>Greetings,</DIV>
<DIV> </DIV>
<DIV>I was going through mail archive and found that some one has
experienced exactly the same problem as I have. The 420 bad extension
message and getting the call dropped.</DIV>
<DIV> </DIV>
<DIV>Here in Korea, I'm testing my Asterisk box with one of the biggest local
ITSP's which is run by Samsung and they have an array of SIP
servers from BroadWorks. One peer connecting to this ITSP is set up
and the other end is Linksys PAP2T.</DIV>
<DIV> </DIV>
<DIV>Session timer is set to 'accept'. I call my Asterisk box from PSTN and
the ITSP sends an INVITE with Supported: timer header. After a while
following the call set-up, Asterisk sends re-invite with 'timer' in the
'Require:' header. Then the BroadWorks, whatever that is, sends back 420 bad
extension and drops the call with a BYE.</DIV>
<DIV> </DIV>
<DIV>Here is what I think. This behavior is certainly a fault of that peer
(BroadWorks) since it can be just ignored instead of dropping the call. There is
no reason for this.</DIV>
<DIV> </DIV>
<DIV>To work around this, I can just turn off the session timer by setting it to
'refuse' or I can set session refresher to 'uac'. The problem is that I still
want to use session timers where I can use to protect my server from leaking
resource.</DIV>
<DIV> </DIV>
<DIV>Does any one know answers to these questions:</DIV>
<DIV> </DIV>
<DIV>1. Why does Asterisk send Require: timer header for session timers?</DIV>
<DIV> <A
href="https://issues.asterisk.org/file_download.php?file_id=15454&type=bug">https://issues.asterisk.org/file_download.php?file_id=15454&type=bug</A></DIV>
<DIV> In the above document, 2.8. Requiring Session-Timers, it
says Asterisk never requires session-timers support from the other end-point in
the interest of interoperability with maximum number of end-point
implementations. BUT IT DOES!</DIV>
<DIV> </DIV>
<DIV>2. Would this BroadWorks server behave this way (dropping calls), because
Asterisk is refreshing sessions with re-INVITE instead of UPDATE? I think
the RFC states it can be done with both methods though.</DIV>
<DIV> </DIV>
<DIV>I'm not sure if this problem has already been fixed. Tested version is
1.6.1.1.</DIV>
<DIV> </DIV>
<DIV>Thanks for any help.</DIV>
<DIV> </DIV>
<DIV>Eugene</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
</BODY>
</HTML>
<img src="http://pcmail3.nate.com/app/msg/confirm/?usn=4942864&email=ekim2@nate.com&key=b1528c97e410e21410b38cf27af8644f$8d3617c3@pcmail3.nate.com" height="0" width="0" />