[asterisk-bugs] [JIRA] (ASTERISK-24915) Missing Contact: header in 200 OK

[Etienne Allovon (JIRA)]

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

Etienne Allovon commented on ASTERISK-24915:
--------------------------------------------

Hi,

Many thanks to my homonym for this little patch :)

I tested it and it works great. At least it fixes the above scenario. 

Any news from your side, Rusty ? Any chance you may test this patch ?

> Missing Contact: header in 200 OK
> ---------------------------------
>
>                 Key: ASTERISK-24915
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24915
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.32.2, 11.16.0
>            Reporter: Etienne Allovon
>         Attachments: AST-24915.diff, ASTERISK-24915-asterisk-extensions.conf, ASTERISK-24915-asterisk-full.log, ASTERISK-24915-asterisk-sip.conf, ASTERISK-24915.pcapng, REGISTER_INVITE_client.csv, REGISTER_INVITE_client.xml
>
>
> *Summary*
> In some cases asterisk answers a call (SIP 200 OK) without the {{Contact:}} header.
> It results, for the receiving peer, to terminate the call (SIP BYE) because he can't answer.
> For example, if the receiving peer is an asterisk, you get the following WARNING in the CLI :
> {code}
> WARNING[32089] chan_sip.c: Invalid contact uri  (missing sip: or sips:), attempting to use anyway
> {code}
> More precisely this happens when asterisk receives a SIP message with a bad CSeq (for example with CSeq-1). Then the next 200 OK doesn't contain the Contact: header.
> *When does it happen in real life ?*
> In real life I saw it with two asterisk interconnected with a SIP trunk via a WAN.
> When there is some asymetric latency it results in retransmissions.
> {code}
> < INVITE            (CSeq 1)
> > 401 Unauthorized  (CSeq 1)
> > 401 Unauthorized  (CSeq 1) .... retransmission because ACK is not received on time
> < ACK               (CSeq 1) .... ACK of the first 401 Unauthorized
> < INVITE            (CSeq 2)
> > 100 Trying        (CSeq 2)  
> > 180 Ringing       (CSeq 2)
> < ACK               (Cseq *1*) .. ACK of the retransmitted 401 Unauthorized
> > 200 OK            (Cseq 2) .... /!\ which does not contain the Contact: header
> {code}
> *How to reproduce*
> Below is a SIP exchange forged with SIPp which reproduce the problem :
> {code}
> < INVITE            (CSeq 1)
> > 401 Unauthorized  (CSeq 1)
> < ACK               (CSeq 1)
> < INVITE            (CSeq 2)
> > 100 Trying        (CSeq 2) ..... contains Contact: header
> > 180 Ringing       (CSeq 2) ..... contains Contact: header
> < ACK               (Cseq *1*)
> > 200 OK            (Cseq 2) ..... /!\ does not contain Contact: header
> {code}
> The bug appears at step #7.
> Asterisk seems to handle the spurious ACK correctly since you find the following DEBUG message :
> {code}
> DEBUG[26739] chan_sip.c: **** Received ACK (6) - Command in SIP ACK
> DEBUG[26739] chan_sip.c: Ignoring too old SIP packet packet 1 (expecting >= 2)
> DEBUG[26739] chan_sip.c: SIP message could not be handled, bad request: 261113e445fb3f8777068f5513a8d61f at 10.14.12.1:5060
> {code}
> Here's the SIPp command to launch the scenario :
> {code}
> /usr/src/sipp-3.3/sipp 192.168.18.55 -sf REGISTER_INVITE_client.xml -inf REGISTER_INVITE_client.csv -i 192.168.18.11 -m 1 -l 1 -r 1
> {code}
> You need to :
> * replace 192.168.18.65 asterisk IP,
> * replace 192.168.18.11 with SIPp client IP
> * get the REGISTER_INVITE_client.xml file,
> * get the REGISTER_INVITE_client.csv file and change the authentication information
> *References*
> SIPp scenarios based on examples found here : http://tomeko.net/other/sipp/sipp_cheatsheet.php?lang



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