[asterisk-dev] [Code Review] 4345: Use SIPS Contact headers as prescribed by RFC 3261 (res_pjsip)

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On Jan. 15, 2015, 8:07 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4345/
> -----------------------------------------------------------
> 
> (Updated Jan. 15, 2015, 8:07 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24646
>     https://issues.asterisk.org/jira/browse/ASTERISK-24646
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> PJSIP introduced a change prior to the 2.3 release that made their INVITE-handling code RFC compliant with regards to checking for SIPS URIs in Contact headers of received requests/responses. Specifically, they added checks for languaged outlined in RFC 3261 section 8.1.1.8 and 12.1.1. A simplified version of what PJSIP does is the following:
> 
> * On incoming INVITE and UPDATE requests, if the request URI is SIPS but the Contact header is not, then the request receives a 480 response
> * On an incoming 200 OK response to an INVITE or UPDATE, if the request URI is SIPS but the Contact header is not, then PJSIP issues an immediate BYE to end the session.
> 
> For softphones that use PJSIP, this means they have trouble interoperating with Asterisk. This is because Asterisk never places a SIPS URI in a contact header. So if a client using PJSIP sends an INVITE to a SIPS URI in Asterisk, we were responding with a non-SIPS Contact header. The PJSIP client would then immediately send a BYE terminating the call.
> 
> This patch aims to fix this issue by implementing requirements of RFC 3261 sections 8.1.1.8 and 12.1.1
> * There is a new module that registers a service that operates on all outgoing requests. If the request is to a SIPS URI, or if the topmost Route header is a SIPS URI, then we set our Contact header to a SIPS URI.
> * The code that creates a UAS dialog will create the local Contact header based on whether the Request-URI or the topmost Record-Route URI is a SIPS URI.
> 
> For this patch, I have elected to keep the ;transport=tls parameter in the Contact header since I have a feeling removing it will cause more trouble than it actually fixes.
> 
> A similar patch against chan_sip for the 11 branch is posted at /r/4346
> 
> 
> Diffs
> -----
> 
>   /branches/13/res/res_pjsip_sips_contact.c PRE-CREATION 
>   /branches/13/res/res_pjsip.c 430625 
> 
> Diff: https://reviewboard.asterisk.org/r/4345/diff/
> 
> 
> Testing
> -------
> 
> Honestly, not much. It compiles. I attempted to set up a TLS client (Jitsi, to be specific), but failed. I got no help from either Asterisk or Jitsi to explain what was going wrong. In the end, I gave that up.
> 
> What I was able to do, oddly, was use SIPp to send a SIP INVITE to Asterisk over UDP using a SIPS Request URI. I then was able to make sure that Asterisk sent a SIPS contact header back in the 200 OK. I'm not making a testsuite test out of this though because it feels like a bug that I can send a request to a SIPS URI over UDP and that Asterisk will accept the request.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150123/28129578/attachment.html>