[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Outbound Issues: slides 3 and 4 - the problem ...
Hi,
>I think we may have a general protocol design question whether to do
>some negotiation stuff or just try-and-error. I personally prefer the
>latter for sake of simplicity. That means I agree totally on three and
>I prefer not to do 1 or 2.
I have a comment not directly related to those arguments you gave
but anyway an extra reason for the Outbound draft to provide a safe
and deterministic check if the proxy is compliant to the draft or not.
This reason is not mentioned in this thread but I would like to point
it out now.
Before the Montreal meeting Jonathan Rosenberg outlined an idea how
an UA could automatically discover servers supporting Outbound within
a domain. He described his idea in this email:
http://www1.ietf.org/mail-archive/web/sip/current/msg15155.html
Shortly the idea was that the home proxy of the domain would
redirect the REGISTER request towards proxies supporting
Outbound, by sending a 305 response. Proxy would also use
Service-Route and Additional-Proxies headers to indicate
proxies that UA could use.
In my understanding, this solution would require the UA to
be able to find out if the contacted Proxy supports or does
not support Outbound, just in the case where the proxy did not
return 305, but instead 200 OK:
- Was it so that the contacted proxy supports outbound and
the network does not require the UA to contact any additional
proxy, so that everything is fine when receiving 200 OK that
does not contain Additional-Proxies header ? In this case
the UA can perfectly well start sending STUN keepalives
towards the proxy.
- Or was it so that the proxy supports neither outbound
nor this new optional draft and therefore did not return 305
or Additional-Proxies header ? In this case UA could
make a false assumption and continue using outbound even if
that would not work.
Thus to make this distinction the UA has to be able to do the
check, preferrably by using the Proxy-Required header as
described earlier in this thread.
Regards,
Erkki
>-----Original Message-----
>From: ext Jiri Kuthan [mailto:jiri at iptel.org]
>Sent: 10.August.2006 09:59
>To: Dean Willis; Cullen Jennings
>Cc: IETF SIP List; Rohan Mahy
>Subject: Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ...
>
>At 23:18 09/08/2006, Dean Willis wrote:
>>I'm more worried about the scenario where the UA doesn't get
>>blacklisted, but just throws a monkeywrench in performance, and it
>>sucks just enough that people don't fix it but complain anyhow.
>
>well, I think we will be receiving useless traffic anyhow so addressing
>one of endlessly many sources of useless traffic doesn't bring us much
>further. With public SIP sites, we experience about 80% of
>"silly traffic"
>(caused typically by client/server misconfigurations and/or broken
>implementations). Folks who run national DNS servers shared with me
>similar numbers for DNS. Implementations have to be ready to deal with
>unwanted silly traffic.
>
>
>>>For these reasons, I don't think this whole problem is not a huge
>>>deal. However, if people do think it is a big deal, the obvious
>>>solution to it is send and OPTIONS message to find out if the
>>>server supports this. Most people don't seem to think this is
>>>enough of a problem to warrant and additional RTT when a UA boots.
>>>We can come up with other possible solutions to this too (as there
>>>are at least three others on this same thread).
>>
>>To recap:
>>
>>Unacceptable: If you're configured to use STUN, just keep STUNning
>>whether it works or not. You may be dead, but you're right, and
>>that's the important part.
>>
>>
>>Alternatives:
>>
>>1) Use an OPTIONS transaction before stunning to find out if the
>>target supports STUN
>>2) Use any other SIP transaction (like REGISTER) to find out if the
>>target supports STUN
>> a) using a Proxy-Require
>> b) Using some sort of Path: tagging
>>3) Just go ahead and STUN, and if it doesn't work, stop sending STUN.
>>
>>I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3
>where 1 is a
>>"SHOULD" strength, but 3 needs to be a MUST. It may be common sense,
>>but it requires documentation, and people seem to need
>"common sense"
>>to have a MUST priority on it or they pretend it isn't important.
>>
>>If we go the 1-SHOULD+3-MUST route, we need to include the "Because
>>the proxy might think your STUN is an attack or error condition and
>>black-list you" as the explanation for the SHOULD.
>
>I think we may have a general protocol design question whether to do
>some negotiation stuff or just try-and-error. I personally prefer the
>latter for sake of simplicity. That means I agree totally on three and
>I prefer not to do 1 or 2.
>
>-jiri
>
>
>--
>Jiri Kuthan http://iptel.org/~jiri/
>
>
>_______________________________________________
>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