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

[Matt Jordan]

> 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.
> 
> Mark Michelson wrote:
>     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.
> 
> Olle E Johansson wrote:
>     What? Never will? I have all that code and hope to get it included at some point.
>
> 
> Mark Michelson wrote:
>     Strange, I can't seem to find the review request anywhere.
>     
>     There's a new player in town when it comes to SIP support in Asterisk. It happens to already have PRACK support, and it also is the target for new feature development for SIP. chan_sip is sticking around for legacy purposes, and bugs will certainly be fixed in it. Don't expect to see many new features added in, though, especially if the feature already exists in PJSIP.
>     
>     This is veering off-topic. Would the compromise I proposed in my previous comment with regards to handling a 200 OK with no SDP work?
> 
> Olle E Johansson wrote:
>     Mark - what you say here is not the project policy according to Matt. New features will be added to chan_sip. Just for the record.
>     
>     There are cases where the answer comes in the 183 and the 200 OK has no SDP too. The only way to be sure you are doing the right thing is to check the to-tag. If the to-tag is the same as a previous response and we have RTP remote address, we should be fine. If the to-tag is different, then we have an issue.

Just to chime in:

Olle is correct that new features that go through the standard new feature process will certainly be accepted in chan_sip, just as new features are accepted in any module in Asterisk. (Heck, I did commit monkey work on a new feature added to chan_mobile earlier this year, and that's hardly a hot bed of new feature development). Mark is correct that the folks here at Digium are going to be focused on chan_pjsip - and while we'll continue to support chan_sip in the existing branches of Asterisk, our focus is going to be on getting chan_pjsip feature complete, robust, and stable.

Obviously we'll need a lot of help on getting that done; I certainly hope that lots of people help out with the work in chan_pjsip :-)

And now I hope we're all clear on this issue!


- Matt


-----------------------------------------------------------
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/20130909/377d6eac/attachment-0001.htm>