Now, assume that case where the UA assumes (either via configuration or
an indicator from the edge proxy) that the outbound proxy supports
STUN,
starts sending STUN requests but doesn't receive anything back. Of
course it should stop sending STUN requests in that case.
It's the same with SIP. If you send your request towards a proxy, but
don't get anything back, sooner or later I assume you will stop sending
your SIP request - even if you have been told (by configuration or
something else) that the receiver supports SIP...
Regards,
Christer
-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil at telio.no]
Sent: 11. elokuuta 2006 15:42
To: Fredrik Thulin
Cc: sip at ietf.org; rohan at ekabal.com
Subject: Re: [Sip] Outbound Issues: slides 3 and 4
I also want to ask the people concerned why they are concerned. I can
DoS your proxy with other things than STUN. Any binary junk will do.
Worried about the extra unnecessary round trip for STUN? Thats not a
good argument. Rohan's proposal requires the extra SIP roundtrip where
the outboound proxy rejects the SIP request. A round trip of STUN is
much cheaper than a roundtrip of SIP.
Hisham
On Aug 11, 2006, at 12:11 PM, Fredrik Thulin wrote:
On Friday 11 August 2006 10:48, Erkki.Koivusalo at nokia.com wrote:
...
4. Can UA rely on the response from the proxy ?
Fredrik Thulin
The argument that a response containing something saying "I claim I
can handle STUN requests you send me" is to be trusted, but
configuration saying ";keepalive=stun" is not is flawed.
Hadriel Kaplan
I would argue fairly vehemently that a server explicitly indicating
it supports something is far more reliable than a UA believing the
server supports something based on a local config setting.
Conclusion:
- As this is hardcoded information in the proxy
implementation, it is very probably reliable
- It works in a similar way for Sec-Agree too
I feel kind of misinterpreted here. My point was that no matter how
strong of an indication the UA receives that the first-hop proxy
supports STUN-in-SIP, it must still _verify_ that it does, and stop
sending STUN requests if the proxy in fact doesn't, even if it claims
it does.
The proxy explicitly saying it supports STUN-in-SIP (through the
Proxy-Require scheme, or some other) is doubtlessly a strong indicator
but it doesn't _prove_ that the proxy supports STUN-in-SIP.
This leads me to my opinion that just about any indicator at all the
UAC has that the first-hop proxy supports STUN-in-SIP is a good enough
reason for the UAC to try and see if it actually does. I don't care
what the indicator looks like, but I don't want the Outbound draft to
be tied up in what I consider pointless discussions, and complex
solutions.
I agree with those that wants to have _some_ kind of indicator of
support, but I think most people are overstating the importance of not
sending a few STUN-in-SIP packet to a proxy that doesn't support it.
Local configuration in the UAC is a good enough indicator for me. I
believe the blacklist argument to be FUD.
/Fredrik
_______________________________________________
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
_______________________________________________
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