[asterisk-dev] [Code Review] 2827: chan_sip: Reject call on 200 OK response to invite that lacks SDP

[Mark Michelson]

> On Sept. 6, 2013, 6:07 a.m., Olle E Johansson wrote:
> > This doesn't work well with PRACK or UPDATES. Asterisk could already have gotten an SDP in another message. (I have a branch with PRACK support that is in production). We need to check if we already have gotten an SDP before we decide to hang up the call. I also need to check the RFCs for this situation.
> 
> wdoekes wrote:
>     .. or re-INVITES.
>     
>     I could imagine that some lazy clients skip the SDP in session refreshers.
> 
> Olle E Johansson wrote:
>     Yes, but if this is a 200 OK it would mean that we would have sent an INVITE without SDP. Will that ever happen? Curious.
> 
> Olle E Johansson wrote:
>     As a summary, this is NOT ready for a SHIP IT nor a commit.
> 
> jrose wrote:
>     I'm not sure about PRACK or UPDATE for now, but in the case of a reinvite, it's not going to hang up the call, it's just going to issue a log message and execute ast_rtp_instance_activate() with whatever it's RTP was already doing, so that much should be fine. If it's a concern, we can always make this an effective NO-OP on reinvite as well.
>     
>     I'll wait on this for the time being.

UPDATE and PRACK are irrelevant as far as chan_sip is concerned. chan_sip doesn't support those and it never will. As far as chan_sip is concerned, the only reliable response that may contain an SDP offer or answer is a 200 OK.

I'd be willing to compromise and say that if Asterisk receives a 200 OK with no SDP but the RTP remote address is non-NULL (meaning we've negotiated an SDP on this dialog, possibly due to an incoming 183), then we could just roll with what we have and hope for the best. Of course, the UAS that sent that 200 OK is totally broken in that case for relying on an unreliable response to provide an SDP answer.

Be aware, of course, that this can lead to its own set of issues as well. Our INVITE could be forked by a proxy to multiple UASs. If multiple destinations send 183 responses with SDP answers, then it becomes important not only that we negotiated an SDP but that we received an SDP on the particular branch that the 200 OK is received on. And as you know, chan_sip's transaction and forking awareness is pretty dismal.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2827/#review9615
-----------------------------------------------------------


On Sept. 5, 2013, 7:31 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2827/
> -----------------------------------------------------------
> 
> (Updated Sept. 5, 2013, 7:31 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, and Mark Michelson.
> 
> 
> Bugs: ASTERISK-22424
>     https://issues.asterisk.org/jira/browse/ASTERISK-22424
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> One of our SIP tests was previously pushing 200 OKs without SDP and Asterisk would accept these calls without question. According to Mark this should not be accepted because there will be no way to know where to send media to or receive media from in these circumstances. The approach this patch takes is to forcibly hang up the call at this point if there is no SDP on the response provided that it's not a response to a reinvite (in which case the behavior is the same as if there were an SDP that couldn't be parsed properly).
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 398378 
> 
> Diff: https://reviewboard.asterisk.org/r/2827/diff/
> 
> 
> Testing
> -------
> 
> Tested it against SIP_hold before and after
> Tested it against a number of testsuite tests against SIP (any of the ones I could run before the patch)
> Tested regular SIP phone calls (they didn't hit the modified code path though).
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130906/f0390f12/attachment.htm>