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

Fri Sep 13 13:34:52 CDT 2013

On 09/13/2013 11:31 AM, Olle E. Johansson wrote:
>
> 13 sep 2013 kl. 17:08 skrev Joshua Colp <jcolp at digium.com 
> <mailto:jcolp at digium.com>>:
>
>> Olle E. Johansson wrote:
>>>>> - When do you add ;transport ? - When do you use sips: ?
>>>> I assume you mean the code since this can't be set by the user.
>>>> Transports within pjsip have different properties about them -
>>>> whether they are secure, whether they are TCP, UDP, TLS, etc. The
>>>> code above uses these properties to know what to add and when. This
>>>> code is based on code that already existed within the pjsua library
>>>> itself.
>>>>
>>> Right. But you avoided to answer my questions, that are quite
>>> important to get right. Can you show some examples?
>>
>> If the transport is TLS (or otherwise marked as secure) then sips is 
>> added. If the transport is not UDP then transport is added.
> If you add sips: you are in a whole other division. You should no do 
> that, it will just cause trouble. It impacts a lot of other headers 
> and is in this case propably a big mistake. Read the RFCs on TLS to 
> get the full picture, RFC 3261 has an update and clarification on the 
> usage. Just assuming that you should use SIPS: in this case will lead 
> to broken communication. SIPS: is not an equivalent of HTTPS:, it's 
> much more and pretty bad.

I skimmed RFC 5630, which I can only assume is the update to RFC 3261 
you were talking about.

The gist of what I read is that using a SIPS URI requires that all hops 
over which the message travels use a secure transport, such as TLS. We 
can't necessarily always use a SIPS URI in the Contact header of a 200 
OK because we don't necessarily know that all involved hops (including 
the UAC that originated the request) support TLS. Is this what you were 
talking about when you said "It's much more and pretty bad"? Are there 
other more specific problems that you were thinking of? The fact that 
other headers are impacted is actually outside of our concern and should 
be handled by PJSIP. So if you were worried about Via headers or other 
headers that also need SIPS URIs, then that shouldn't arise as an issue.

Based on what I'm reading, as a UAS, we should only use a SIPS URI in 
the Contact header if the Request-URI in the dialog-initiating request 
was a SIPS URI. Otherwise, we should use a SIP URI in the Contact header 
of the 200 OK. Is this what you would suggest as at least a baseline 
determiner for whether to include a SIPS URI in the Contact header? Or 
are you instead suggesting that we simply *never* use a SIPS URI in the 
Contact header? If not, why?

>
> If you add a transport you will prevent upgrades from UDP to TCP, 
> which is not a good thing. UDP is always the fallback when someone 
> contacts you, we should encourage if someone prefers to contact us 
> over TLS or TCP to the contact we send.

I don't understand what you mean here. The two sentences seem to 
contradict each other. The first seems to imply that adding a transport 
parameter to the Contact header is bad, but the second seems to be 
encouraging us to add a transport parameter. Can you clarify what you 
were trying to say? For clarity, the current code will add a ;transport 
parameter to the Contact header if the transport to be used is not UDP.

Interestingly, the deprecation of ";transport=tls" is upgraded in RFC 
5630 to be "MUST NOT use the transport=tls parameter" (Sections 5.1.1, 
5.1.1.1, 5.1.2, 5.3, and 5.4). So what is the preferred method by which 
we indicate that we wish for the ACK, BYE, and session refreshes to 
arrive using TLS if we don't use a SIPS URI and can't use 
";transport=tls" in the Contact? Is there a different, more standardized 
way to encourage TLS usage when sending SIP traffic to us?

>
>>
>> This is the above logic in the code you mentioned. I don't know what 
>> else you are looking for...
> I just wanted to understand if you where doing this right or wrong, 
> but you confirmed that you did it wrong. Please fix.

We certainly want to get it right, but we also would like more 
constructive criticism on the matter. Saying that things are "bad" and 
"wrong" without providing clear suggestions or alternatives is not 
helpful. Nor is saying that something "will cause trouble" without 
stating what said trouble actually is. I'd rather have a clear idea of 
what it is we have done wrong instead of trying to guess.

Mark Michelson

>
> /O
>>
>> -- 
>> Joshua Colp
>> Digium, Inc. | Senior Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: www.digium.com <http://www.digium.com>  & 
>> www.asterisk.org <http://www.asterisk.org>
>>
>> --
>> _____________________________________________________________________
>> -- 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
>
> ---
> * Olle E Johansson - oej at edvina.net <mailto:oej at edvina.net>
> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
>
>
>
>
>
> --
> _____________________________________________________________________
> -- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130913/de73a65e/attachment.htm>