6 jul 2011 kl. 22.54 skrev Brez Borland:
Okay, this all gets a little bit complicated and rather interesting. The
following is purely my own reasoning.
We should not forget that we are talking a TLS layer context here, _not_ TCP.
That is, the underlying TCP connection should not require
2011/7/6 Olle E. Johansson o...@edvina.net:
Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse
the same connection if available.
But SIP outbound says that this only applies when we have mutual TLS
identification - client and server certificate.
Correct me if I'm wrong,
7 jul 2011 kl. 10.34 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson o...@edvina.net:
Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse
the same connection if available.
But SIP outbound says that this only applies when we have mutual TLS
identification - client
2011/7/7 Olle E. Johansson o...@edvina.net:
But SIP outbound says that this only applies when we have mutual TLS
identification - client and server certificate.
Correct me if I'm wrong, but I don't think that SIP outbound requires
each UA/client to have an own certificate.
We're still
2011/7/7 Brez Borland brez...@gmail.com:
I think once TLS context is invalidated(i.e. rejected to be resumed by Proxy
A), Proxy B should either:
1) return an error to the downstream UAS (i.e. failure to send response
_permanently_), or
What does mean return an error to the downstream UAS?
7 jul 2011 kl. 14.11 skrev Brez Borland:
On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo i...@aliax.net wrote:
2011/7/7 Brez Borland brez...@gmail.com:
I think once TLS context is invalidated(i.e. rejected to be resumed by Proxy
A), Proxy B should either:
1) return an error to the
2011/7/7 Olle E. Johansson o...@edvina.net:
Proxy B should not discard data(certificates previously received) associated
with Proxy A when it tries to reconnect to it. I think Proxy B should retain
the certificate atlanta.com, and have it associated with myserver.org, at
least for the
On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson o...@edvina.net wrote:
2) not perform validation of the upstream element cert. Because by
forwarding a response, by definition, it acts as a server in this
particular
transaction(request, and any responses to it).
Why one would
On 07/07/2011 09:45 AM, Brez Borland wrote:
Why would Proxy B want to _validate_ the certificate of Proxy A if it have
not done so when Proxy A established a connection? Proxy B might want to
_verify_ that Proxy A presented the same certificate when Proxy B falls
back.
If connection is
2011/7/7 Brez Borland brez...@gmail.com:
Why would Proxy B want to _validate_ the certificate of Proxy A if it have
not done so when Proxy A established a connection? Proxy B might want to
_verify_ that Proxy A presented the same certificate when Proxy B falls
back.
Even if proxy-A has
7 jul 2011 kl. 16.45 skrev Brez Borland:
On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson o...@edvina.net wrote:
2) not perform validation of the upstream element cert. Because by
forwarding a response, by definition, it acts as a server in this
particular
transaction(request,
2011/7/7 Olle E. Johansson o...@edvina.net:
Why would Proxy B want to _validate_ the certificate of Proxy A if it have
not done so when Proxy A established a connection? Proxy B might want to
_verify_ that Proxy A presented the same certificate when Proxy B falls back.
Proxy A sets up a
7 jul 2011 kl. 16.50 skrev Iñaki Baz Castillo:
2011/7/7 Brez Borland brez...@gmail.com:
Why would Proxy B want to _validate_ the certificate of Proxy A if it have
not done so when Proxy A established a connection? Proxy B might want to
_verify_ that Proxy A presented the same certificate
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Saúl Ibarra
Corretgé [s...@ag-projects.com]
When doing a call transfer, the party sending the REFER communicates the URI
the recipient is
Hi,
On Jul 7, 2011, at 3:19 PM, Paul Kyzivat wrote:
AFAIK there is nothing written specifically about this subject.
Some thoughts:
- when in doubt, the obvious thing to do is to offer whatever
you would have if you received an invite without offer.
- more is better - offering as much
Hi,
On Jul 7, 2011, at 5:06 PM, Worley, Dale R (Dale) wrote:
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Saúl Ibarra
Corretgé [s...@ag-projects.com]
When doing a call
2011/7/7 Olle E. Johansson o...@edvina.net:
I really, really need to write this all down somewhere just to remember.
Yes, I will make a website with all this stuff. Just let me some time.
--
Iñaki Baz Castillo
i...@aliax.net
___
Sip-implementors
On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson o...@edvina.net wrote:
Why would Proxy B want to _validate_ the certificate of Proxy A if it
have not done so when Proxy A established a connection? Proxy B might want
to _verify_ that Proxy A presented the same certificate when Proxy B falls
7 jul 2011 kl. 16.28 skrev Iñaki Baz Castillo:
2011/7/7 Olle E. Johansson o...@edvina.net:
Proxy B should not discard data(certificates previously received)
associated with Proxy A when it tries to reconnect to it. I think Proxy B
should retain the certificate atlanta.com, and have it
7 jul 2011 kl. 17.15 skrev Brez Borland:
On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson o...@edvina.net wrote:
Why would Proxy B want to _validate_ the certificate of Proxy A if it have
not done so when Proxy A established a connection? Proxy B might want to
_verify_ that Proxy A
2011/7/7 Olle E. Johansson o...@edvina.net:
Well, the question is what to put in the Via header. You need something that
points back if you have transaction state in one of your proxys... The
received parameter helps with that.
You don't want to have IP addresses or host names in certs
2011/7/7 Olle E. Johansson o...@edvina.net:
Maybe the only solution here is just to drop the response and hope that the
UAC retransmits the request and keeps a useful connection open.
...and then it comes another question I asked in this maillst:
- The connection is terminated and let's
7 jul 2011 kl. 17.56 skrev Iñaki Baz Castillo:
2011/7/7 Olle E. Johansson o...@edvina.net:
Well, the question is what to put in the Via header. You need something that
points back if you have transaction state in one of your proxys... The
received parameter helps with that.
You don't want
2011/7/7 Olle E. Johansson o...@edvina.net:
Right so the question is if we can add a valid domain in the Via - one that
matches the cert.
The Via header is added (usually) by the transaction layer (who knows
which transport to use and so). But the core layer (the proxy) could
handle many
7 jul 2011 kl. 18.04 skrev Iñaki Baz Castillo:
2011/7/7 Olle E. Johansson o...@edvina.net:
Right so the question is if we can add a valid domain in the Via - one that
matches the cert.
The Via header is added (usually) by the transaction layer (who knows
which transport to use and so).
2011/7/7 Olle E. Johansson o...@edvina.net:
Well, if the via was a dns name, it could resolve in both IPv4 and IPv6 :-)
Or in lot of them! :)
--
Iñaki Baz Castillo
i...@aliax.net
___
Sip-implementors mailing list
On 07/07/2011 10:59 AM, Iñaki Baz Castillo wrote:
2011/7/7 Olle E. Johanssono...@edvina.net:
Maybe the only solution here is just to drop the response and hope that the
UAC retransmits the request and keeps a useful connection open.
...and then it comes another question I asked in this
2011/7/7 Kevin P. Fleming kpflem...@digium.com:
If we're talking about TCP here (as I believe we are, since DTLS isn't
part of the discussion yet), then the server also knows that the
original connection has been lost. There is only one connection to use
to send the response back... the new
2011/7/7 Brez Borland brez...@gmail.com:
I think transport/transaction layers should work to prevent cases like this.
Personally I would look to close the previous connection associated with the
transaction, and use the new connection for any further associated
communications.
It could be a
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
2011/7/7 Brez Borland brez...@gmail.com:
I think transport/transaction layers should work to prevent cases like this.
Personally I would look to close the previous connection associated with the
transaction, and use the new connection for any further
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
Mmmm, danger, what about if the first connection is opened by a proxy
which currently mantains more than one transaction with the server?
why to close such connection just because a retransmission of some one
of those transactions has arrived via
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
2011/7/7 Brez Borland brez...@gmail.com:
I think transport/transaction layers should work to prevent cases like this.
Personally I would look to close the previous connection associated with the
On Thu, Jul 7, 2011 at 7:22 PM, Iñaki Baz Castillo i...@aliax.net wrote:
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
2011/7/7 Iñaki Baz Castillo i...@aliax.net:
2011/7/7 Brez Borland brez...@gmail.com:
I think transport/transaction layers should work to prevent cases like
this.
Inline
On 7/7/11 11:10 AM, Saúl Ibarra Corretgé wrote:
Hi,
On Jul 7, 2011, at 3:19 PM, Paul Kyzivat wrote:
AFAIK there is nothing written specifically about this subject.
Some thoughts:
- when in doubt, the obvious thing to do is to offer whatever
you would have if you received an
34 matches
Mail list logo
