-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4345/
-----------------------------------------------------------
(Updated Jan. 29, 2015, 2:58 p.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
-------
Committed in revision 431426
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
