[asterisk-bugs] [JIRA] (ASTERISK-26234) chan_sip: CANCEL is not sent to device that responded with 422 Session Interval Too Small to original INVITE

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-26234:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

> chan_sip: CANCEL is not sent to device that responded with 422 Session Interval Too Small to original INVITE
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26234
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26234
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.17.1
>         Environment: 2.6.32-573.8.1.el6.x86_64
> AsteriskNOW
>            Reporter: Jim Beckner III
>            Assignee: Asterisk Team
>         Attachments: 26234.txt
>
>
> I can repeat this at will on 11.17.1.  I can also repeat on 1.8 so this has been around for a while.  ASTERISK-14731 seems similar.  This can likely be repeated easily, but I can provide a full SIP and Asterisk trace if needed.  
> To repeat the following conditions are being used by me:
> 1. Settings -> session-timers=originate, session-expires=600, session-minse=90, session-refresher=uas
> 2. SIP device has a minimum session timer of 1800 (It is an Avaya 1120) (note that the device min-se is 1800 whereas I have Asterisk set to use 600).
> Repeat steps:
> 1. Call the extension
> 2. Hang up after device rings
> 3. Device will continue to ring even though the originator hung up.
> What happens:
> 1. INVITE is sent to device with "session-expires: 600"
> 2. Device responds with "422 Session Interval Too Small" with the header "Min-SE: 1800"
> 3. Asterisk sends another INVITE with "Session-Expires: 1800"
> 4. The device rings
> 5. Originator hang up which triggers a CANCEL to Asterisk
> 6. Asterisk sends a 487 back to the originator.  (originating device now is idle)
> 7. Asterisk never sends a CANCEL to the device that was ringing.  This causes the device to just keep ringing until you attempt to "answer" the call.
> 8. When you "answer", Asterisk sends a BYE to the device even though the call should have ended in step 6.
> Through this process, Asterisk keeps the channel active ("sip show channels" shows the channel until the device is "answered").  At that point, the channel is terminated and the BYE is sent.



--
This message was sent by Atlassian JIRA
(v6.2#6252)