[asterisk-bugs] [JIRA] Commented: (ASTERISK-19719) Asterisk doesn't add Contact field in 200 OK when ACK for 401 response is out of order

[Jan-Peter Koopmann (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197794#comment-197794 ] 

Jan-Peter Koopmann commented on ASTERISK-19719:
-----------------------------------------------

We see a similar behaviour and I second this being a bug. 

> Asterisk doesn't add Contact field in 200 OK when ACK for 401 response is out of order
> --------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-19719
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19719
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 1.8.11.0
>            Reporter: Andrey Solovyev
>            Severity: Minor
>         Attachments: pedantic_contact_bug.txt, pedantic_yes.txt, sip.conf, uac_auth_late_ack.xml, users.csv
>
>
> We have the Asterisk server which is used by many different SIP devices so we have to use pedantic=no because some devices can send some strange SIP packets.
> One of our users has asterisk server and noticed that some calls are hanged up after answer by his asterisk (also 1.8.11) with error:
> chan_sip.c: Invalid contact uri  (missing sip: or sips:), attempting to use anyway
> chan_sip.c: Invalid host name in Contact: (can't resolve in DNS) : ''
> I've started debugging and found out that our asterisk doesn't always send Contact field in the SIP 200 OK message! Actually about 15% calls were without Contact field in SIP Session progress and SIP OK messages which caused client's asterisk to hangup call because Contact field MUST be present (as per RFC).
> I have found out that asterisk doesn't send Contact due to wrong packet order in authorization process.
> Usually we have such sip dialog:
> client  asterisk
> 1. --> Invite
> 2. <- 401 Unauthorized
> 3. -> ACK
> 4. -> Invite with auth
> 5. <-100 Trying
> 6. <- 183 Session Progress (or 180 Ringing or both)
> 7. <- 200 OK
> ....
> In our particular issue due to some network latancy or maybe some unknown network issues 4th packet came earlier then 3rd and we've got this scenario (this is from our asterisk side, it always sends Trying before handling any other packet in the dialog)
> 1. -> Invite
> 2. <- 401 Unauthorized
> 4. -> Invite with auth
> 5. <- 100 Trying
> 3. -> ACK
> 6. <- 183 Session Progress (or 180 Ringing or both)
> 7. <- 200 OK
> ....
> This is UDP and such situation can happen to anyone because client's "ACK" (3rd packet) and "Invite with auth" can be sent just microseconds away from each other and "Invite with auth" can reach the destination earlier than ACK.
> So ACK comes after INVITE with auth. Then asterisk sends 183 and 200 OK packet without Contact field wich seems strange.
> The Contact field is there if we enable pedantic  (pedantic = yes) in sip.conf general section, although packets order is the same.
> I've managed to reproduce the situation above with SIPp scenario.
> I've attached sip.conf which I've used. Basically it contains one sip friend with context test11.
> test11 context simulates call with session progress and answer and contains:
> exten => _X.,1,Noop()
>        same => n,Wait(1)
>        same => n,Progress()
>        same => n,Wait(2)
>        same => n,Answer()
>        same => n,Playback(demo-congrats)
> I've created SIPp scenario uac_auth_late_ack.xml wich simulates ACK after Invite with auth situation. It uses users.csv with auth credentials. In order to simulate call you have to execute this command
> sipp 10.42.0.253 -sf uac_auth_late_ack.xml -s 11111 -aa -d 5s -i 10.210.12.209 -inf users.csv -r 1 -rp 1s -m 1
> 10.42.0.253 - is asterisk server
> 10.210.12.209 - client's side (SIPp)
> pedantic_contact_bug.txt contains asterisk DEBUG output with sip debug enabled. We can see that 200 OK from asterisk (line number 382) doesn't contain Contact field.
> pedantic_yes.txt is same scenario with pedantic=yes. We can see that OK field contains Contact field.
> The difference is that with pedantic=yes asterisk treats late ACK as "Invalid SIP message - rejected , no callid, len 309" (line 288 pedantic_yes.txt) and if we have pedantic=no asterisk ignores this packet "Ignoring too old SIP packet packet 1 (expecting >= 2) (pedantic_contact_bug.txt line 304).
> (I would like to add that I've also tested scenario with normal packet order to be sure that all packets are right).
> IMHO such scenario should work and this seems to be a bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira