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

[Olle E Johansson]

> On Sept. 6, 2013, 8: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.

As a summary, this is NOT ready for a SHIP IT nor a commit.


- Olle E


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


On Sept. 5, 2013, 9: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, 9: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/03ed8c65/attachment.htm>