[asterisk-dev] [svn-commits] mmichelson: branch 12 r399083 - in /branches/12: include/asterisk/ res/

[Matthew Jordan]

On Fri, Sep 13, 2013 at 2:57 PM, Olle E. Johansson <oej at edvina.net> wrote:

> Mark,
> I'm sorry to have disturbed your process by pointing at your errors.
>

I don't think it was a disturbance to anyone's process to have useful input
provided. As an aside, to us, "your process" is the Asterisk project's
process. Like anyone, we make mistakes from time to time. But we do our
best to follow what we ask others to follow. Commenting on a commit after a
review has always been viewed as perfectly acceptable and a normal part of
development. No one minds that.

After reading your e-mail and the RFCs, I don't have a clear understanding
either of all of the issues surrounding usage of a SIPS URI instead of a
SIP URI with TLS as transport. The fact that SIPS does not equate to
"best-effort" TLS obviously has implications if hops in the middle don't
support TLS (you either think you're secure but aren't, or your calls fail,
or... something else perhaps?). What I don't have a clear understanding of
is why we should prefer SIP with TLS as the transport over SIPS. Couldn't a
user make the argument that they really don't want "best-effort" - that is,
if they asked for secure communication, they want secure communication
along the entire path? What explicit pitfalls are we running into by using
SIPS in the URI in the contact header?

Or I could be misreading what section 3.1.3 is referring to; but that's why
Mark asked for some clarification.

And I'm sorry, but I agree with Mark: "it's much more and pretty bad"
doesn't tell me what all we've just fallen into.


> Please ignore my remarks and go on - I'm sure you'll sort it out yourself
> or that PJsip will fix it somehow.
>
>
Mark did not imply that PJSIP will fix our problems for us. He stated that "The
fact that other headers are impacted is actually outside of our concern and
should be handled by PJSIP." PJSIP will already construct certain headers -
such as Via or Record-Route - based on the information you provide it -
unlike the Contact header in this commit, which has to be constructed
before you pass it down to the PJSIP layer for processing. It is, however,
our decision as to what gets fed into PJSIP to choose the correct options -
things like what transport is attempted; whether or not we use SIP or SIPS;
and other kinds of information. If we pass it the correct information, it
should "do the right thing". But no one is stating that we're punting on
responsibility. If PJSIP didn't handle the Contact header passed to it
correctly and - for example, didn't update the Via header appropriately -
then that's a bug we'll fix and push upstream.

Your input is welcome in the process at any point. Like all good citizens
in an open source community, we all have to communicate. This applies to
anyone participating in the Asterisk project - be they at Digium or outside
it. While that certainly means raising issues when things are wrong, it
also means providing explanations when someone asks for it, and preferably
not criticizing the work someone has done without explaining the errors
they've made.

Hope you have a good weekend as well -

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130913/ceb18dad/attachment.htm>