[asterisk-dev] Requiring session timers and call drop

[John Todd]

On Jan 15, 2010, at 4:09 PM, 김의경 wrote:

> Greetings,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Does any one know answers to these questions:
>
> 1. Why does Asterisk send Require: timer header for session timers?
>     https://issues.asterisk.org/file_download.php?file_id=15454&type=bug
>     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!
>
> 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.
>
> I'm not sure if this problem has already been fixed. Tested version  
> is 1.6.1.1.
>
> Thanks for any help.
>
> Eugene



Eugene -
   It sounds like there is a bug in what you describe in your case #1,  
or at least an unexpected condition.  Can you open a ticket on it,  
with a full SIP debug and clear explanation of what you think it  
should do, as compared to what it actually does.

   As far as Asterisk sending re-INVITEs instead of UPDATE: your  
patches are welcome to solve this problem.  Nobody has apparently  
considered it an issue important enough to fix until now; perhaps you  
can take a try - we're always interested in seeing new developers  
assist with the project.

JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/