----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4345/#review14226 -----------------------------------------------------------
I may have broken your patch slightly but anyway! I'll ask this: Why can we not construct a proper URI from the beginning, why is a module required to alter it afterwards? - 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
