Subject: Re: [Sip] outbound08 - Handling Responses in Edge proxy / Viavs.Flowtoken

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Jun 2007 09:52:20 -0700

Hi Sergio,

Changing response routing is out of scope of the outbound spec.

thanks,
-rohan

On Apr 27, 2007, at 5:36 AM, [email-masked] wrote:
>
> 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-masked]>:
>
>> 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-masked] [mailto:[email-masked]]
>> Sent: Friday, April 20, 2007 8:59 AM
>> To: Kevin Johns
>> Cc: [email-masked]; 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-masked]>:
>>
>>> 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-masked] [mailto:[email-masked]]
>>> Sent: Thursday, April 19, 2007 8:52 AM
>>> To: [email-masked]
>>> 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-masked] for questions on current sip Use
>>> [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip