[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01
Hi Erkki,
Thanks for your comments. Please see my responses inline.
Erkki.Koivusalo at nokia.com wrote:
> Hi,
>
>> Introduction and the Overview of Operation sections and you will see
>> that this proposal does not add a lot of complexity to Outbound.
>
> I quite much disagree and still think it is too complex.
> The draft introduces the following pattern:
>
> 1. Proxy receives such a big SIP request that it can not pass it
> to the UA via the persistent UDP flow
> 2. Consequently the proxy will send ForceTCP message to the UA
> 3. The UA will open a temporary TCP connection towards the proxy
> 4. The UA will send a GetToken request to the proxy over the TCP
> connection
> 5. The proxy will respond GetToken with a new flow token assigned
> to the TCP flow
> 6. UA will store this new TCP flow token and associate it with the
> UDP flow
> 7. UA will respond to the ForceTCP message returning the flow token
> of the TCP flow to the proxy
> 8. Based on the response from the UA the proxy can now re-map the
> big SIP request from UDP flow to the new TCP flow and forward
> it to the UA
>
> That does not sound too easy to me. Especially when thinking about:
> - Various interactions between the SIP and STUN stacks required
> - Requirement for the UA to start opening TCP connections when
> there is no SIP request to sent (a change to the connection
> management architecture laid out in RFC 3261).
> - Usage of SigComp together with SIP and STUN muxed over a
> TCP connection, if the deployment requires using SigComp
>
> I believe the proposed mechanism does not clearly describe to
> which address and port the UA should set up its TCP connection.
> Usually UA resolves the SIP URI of the next hop when sending
> a request and opens the connection towards a resolved address-port
> pair. In the context of ForceTCP at least the port is not evident.
>
> If proxy has a TCP SIP port configured to the DNS, the UA might
> already have a TCP connection open towards the proxy even if the
> proxy does not recognize it. Instead of opening a new TCP connection
> the existing one could be used, see below. But if DNS does
> not have TCP SRV record for the proxy, then which port to use ?
> Always 5060 or should ForceTCP tell the port number ?
The remote UDP IP address and port are used to open the TCP connection.
This works because "[f]or any port and interface that a server listens
on for UDP, it MUST listen on that same port and interface for TCP."
(RFC 3261 Section 18.2.1).
I will add this to the draft.
>
>
> But if you anyway would like to continue with the draft, please
> consider an alternative pattern.
>
> I believe that the requirement for the UA to associate the UDP and
> TCP flows together does not make sense. The proxy should maintain
> this association as it is the proxy who really needs this info,
> in order to remap inbound requests between flows. Consequently
> the pattern could be like this:
>
> 1. Proxy receives such a big SIP request that it can not pass it
> to the UA via the persistent UDP flow
> 2. Consequently the proxy will send ForceTCP message to the UA.
> This message would contain the flow token of the UDP flow.
> 3. UA would immediately respond to the ForceTCP message
> 4. The UA will open a temporary TCP connection towards the proxy
> or skip this phase if it already has a persistent TCP connection
> 5. The UA will send a GiveToken request to the proxy over the TCP
> connection, giving the token of the associated UDP flow
> 6. The proxy will respond GiveToken request and store the mapping
> between the TCP and UDP flows
> 7. Based on the GiveToken from the UA the proxy can now re-map the
> big SIP request from UDP flow to the TCP flow and forward
> it to the UA
This is a nice improvement on my proposal, and I would suggest an
additional improvement by using Indications for ForceTCP and GiveToken.
The proxy can retransmit the ForceTCP Indication until the GiveToken is
received, and so reduce the number of STUN messages exchanged to two.
The only problem I see with this pattern is that it is not scalable.
The reason I proposed to store the association in the UA is that there
is no need for data locking in the proxy. With your pattern, the
structure that contains the mapping between UDP and TCP flows needs to
be locked during the access, and as this is a global structure that will
be under heavy use, this will reduce the scalability.
>
> This pattern would also avoid ForceTCP transaction to time out
> (or retransmissions of ForceTCP) while UA is opening the TCP
> connection and performing the GetToken exchange.
>
Yes, I knew about this problem. I thought about using a STUN 100 Error
response to stop the retransmission, but I discovered that it does not
work. I sent an email to the BEHAVE list about this issue:
http://www1.ietf.org/mail-archive/web/behave/current/msg01859.html
>
> P.S. I still have doubts whether this mechanism, introduced as a
> separate draft, would gain wide enough acceptance to be really
> useful for deployments. I also anticipate that when reviewed in
> detail, the complexity will grow as the problems and different
> error cases etc. pop up.
I do not expect to have this draft published as an RFC. I do not like
to complain about problems without proposing solutions, and an I-D is a
good way to present them.
UDP as it is in Outbound does not work and need to be fixed. My
proposal (or another proposal) can be added to the existing Outbound
draft, but I do not think that this is a good idea to delay even more
Outbound. Another solution would be to remove completely UDP from
Outbound and add a text saying that UDP is still mandatory, but Outbound
covers only TCP, and to start to work on a UDP-Outbound draft (based or
not on my draft).
--
Marc Petit-Huguenin
Home: marc at petit-huguenin.org
Work: marc at 8x8.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip