[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Outbound Issues: slides 3 and 4
Hi,
I am sure that there are cases where messages (STUN, or whatever) will
be sent to destinations that don't support them, e.g. due to bad
configuration.
MY problem is that I don't like to standardize behavior which is based
on sending something somewhere just to find out if the reciever supports
the protocol in the first place. That is the reason I want to be able to
get the information from the proxy before sending anything.
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
_______________________________________________
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