Hi,
are you proposing that responses to the client (presumably behind a NAT)
be routed in some way other then the Via header?
Yes, that is one of the proposals and one of the comments that we
had queued waiting a response to my previous email.
Note that in my previous email I did not mention yet the 'Responses'
issue. I just want to be sure what is the authors opinions about
reusing the flow in a UAS ---> UAS 'Request' and then develop my
comments. But anyway, I mention below the main idea.
After knowing the authors opinion, and assuming that they agree with
the idea to re-use an outbound flow in the UAC---> UAS case, we were
thinking to propose the following:
1. Always use the flow-token in Requests: i.e. not only use the
flow-token in the UAS--->UAC case , but also, if a UAC supports
outbound, consider to reuse optionally or mandatory (to be discussed)
the flow in the the UAC--->UAS direction. In this case, the UAC must
keep a copy of the flow-token after successful registration (it can be
retrieved from the Path-header in the 200 OK).
2. Always use the flow-token in Responses : i.e. when a Request
crosses a proxy, and it founds the flow-token in the path header,
copy it as a URI into the Via-header. Then, when the Response comes
back to the proxy, use the flow token in the Via-header (if present)
to forward the response to the destination stated in the flow token
(instead to use the Via-header rport and received). (This will require
to store in the flow-token (algorithm 2) the destination IP and port
of the Registrar/UAS instead of the proxy IP and port. The proxy will
know how to forward the Response by checking its origin; if origin IP
and port in transport match origin IP and port in flow-token, then the
proxy knows that the response comes over the flow and the destination
is the destination IP and port in the token).
This behavior could be considered either mandatory or optional in outbound.
Advantages are:
-Security: the proxy could only consider valid flow-tokens before to
forward a Request (except REGISTER), thus, only authenticated and
authorized flows could be allowed to be forwarded.
- Could be used as an alternative to RFC 3581.
- Security (we need to considered if it is really possible): UAC
location could be anonymous: The registrar and other entities will
only know a flow-token (only the Edge proxy knows how to decrypt the
location of UAC).
Note that the presence of NAT is optional. This scheme will work
with or without NAT since the flow-token is composed using the origin
IP and port (and we understand that these are retrieved from the
transport layer).
Regards,
Sergio
Quoting Kevin Johns <[EMAIL PROTECTED]>:
Sergio,
Before I respond, I would like to make sure I understand your question,
are you proposing that responses to the client (presumably behind a NAT)
be routed in some way other then the Via header?
Kevin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 6:36 AM
To: Kevin Johns
Cc: [email protected]; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy
/Viavs.Flowtoken
Hi,
Thank you for your answer.
We are composing an email with comments about why this issue (to use
the information in the Via header to handle Responses for Requests
originated by a UAC) may be not a good approach and bring down several
good outbound features.
But before to send our comments, it is important for us to ask the
authors if they are considering to re-use the flow in a
non-outbound-required UAC-->UAS Request case. Details are explained
below.
Keep in mind that in the comments below we focus our thoughts mainly
to connection oriented protocols (TCP).
Let me introduce an example; in the following scenario the UAC
previously established a flow with the EdgeProxy
----flow----
UAC--------------EdgeProxy----UAS
Suppose now that the UAC wants to send a Request to the UAS.
We understand that the purpose of a flow is to reach UAC for a Request
in the 'opposite direction' (i.e. a request from a UAS to UAC). While
now we are sending a Request from UAC to UAS.
The question is:
What are the authors point of view about re-using the flow in a
non-outbound-required UAC-->UAS Request?
In other words, is an outbound UAC expected to reuse the
outbound-flow, or not? ('or not' means : to create another 'traditional'
SIP connection).
The advantages to re-use a flow in UAC-UAS direction can introduce
some additional features that can make of outbound a powerful mechanism
not only to just keep NAT/FW bindings alive to reach a UAC but also to :
a) increase security (proxying requests and responses at the Edge Proxy
could be always done using a flowtoken), b) be an alternative to RFC
3581.
We will add more details about the comments above and the advantages
that outbound can introduce by re-using a flow in any direction to/from
a UAC. But first we need to know what is the authors position about
using a flow in the (non-outbound-requiring) UAC-UAS direction.
Regards
Sergio
Quoting Kevin Johns <[EMAIL PROTECTED]>:
Sergio,
Thank you for clarifying your question.
Let me try and provide some more detail, responses are always sent
from the UAS to a UAC and are always routed based on the via header
never the flow token. The flow token is only used for routing of
initial requests from the edge proxy (UAC) to the client (UAS).
Section 4.3 defines the UAC procedures (it is titled sending requests)
and strongly recommends that the UA include the rport in the via
header.
When the Edge Proxy gets the INVITE, it will populate the rport
parameter in the UAC inserted via head with the source port in the UDP
header of the received packet. It will also insert the receive
parameter into the same via header entry which contains the source IP
address in the IP header of the received packet. The Edge Proxy then
adds its own via header entry and forwards this INVITE along.
When the edge proxy gets back the response, it will look at the top
most Via header which contains the rport and receive parameter. The
Edge Proxy will then forward the response to the UAC using these
parameters which are routable since they represent the WAN interface
of the NAT.
The flow token never comes into play in this case.
This is all defined in RFC 3581 (An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing)
I hope this helps clarify the situation.
Kevin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 8:59 AM
To: Kevin Johns
Cc: [email protected]; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
Viavs.Flowtoken
Hi,
Thank you for your answer.
Perhaps I should emphasize that I am always talking about Edge Proxy
behavior handling incoming Responses to be forwarded to a UAC over an
existing flow.
It seems that your answer is related to handling Responses in the
UAC, not in the Edge Proxy. Nevertheless I add my comments below:
Outbound expects that rport is used in the via header for routing of
responses (for UDP that is) see the note in section 4.3.
I understand that section 4.3 is for UA behavior.
Responses are
routed as defined in 3261 for TCP.
Yes, but in the case of forwarding Responses to a flow in an Edge
Proxy, I understand that the proxy uses the flowtoken information,
thus discarding any consideration of the Via-header parameters
(different to
3261 approach).
So.. shouldn't outbound-08 draft explain the case of Responses
handled by the Edge Proxy? By common sense I guess that the Response
should use the destination stated in the flowtoken, but, as
outbound-08 did not formally specify this case, why I could not avoid
considering the destination in the Via-header (although it wont work
with NAT)?
Regards,
Sergio
Quoting Kevin Johns <[EMAIL PROTECTED]>:
Sergio,
Outbound expects that rport is used in the via header for routing of
responses (for UDP that is) see the note in section 4.3. Responses
are
routed as defined in 3261 for TCP.
Kevin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 19, 2007 8:52 AM
To: [email protected]
Cc: Cullen Jennings; Rohan Mahy
Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
vs.Flowtoken
Hi,
I have a question related to handling Responses that are going to
be
sent over a flow in an Edge proxy.
In "5.3. Forwarding Requests (outbound08)" I read that a Request
is
forwarded to a flow using the information retrieved from the flow
token (and that it is found in the Route-header).
Now I am considering how is the case for Responses.
Should we consider the same behavior? i.e. forward a Response over
a
flow using the flowtoken found in the Path-header?
In 'non-outbound SIP', as far as I understand, Route Header forces
the routing in Requests, and Via-header forces routing in Responses.
So... should we avoid any consideration to the information stored
in
the topmost Via-header when proxying a Response? (And instead use the
information in the flowtoken ?)
I think that the answers is yes, since the Via could contain a
private address in the case of a NAT in the middle. Then, shouldn't
be
mentioned the response case in the draft?
Regards,
Sergio
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
