I also agree with Paul's views. Can someone elaborate as to why it is not desirable for a UAC to retry automatically? This could be a check box in the setting menu.
Regards, Hisham On 27/07/07, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > Is the 480 intended to be *indistinguishable* from a 480 returned as a > result of no registrations at all? Or is it intended to be > distinguishable but more obscure than an explicit error response? > > I think it needs to be distinguishable, one way or another. > > The reason is that there are UIs where it makes sense to downgrade. For > instance: > > The input to the UI of the UA is just a dial string, not a URI. It is up > to the UA to decide what scheme to apply. It can do this based on > policy, or perhaps based on a "secure" button on the phone. Typically > the user won't know whether a particular number should be sip or sips. > (Or even what that means.) The phone may decide to try sips first and > downgrade to sip if the sips doesn't work. If sips works then it can > display some sort of indication that the call is more secure than if sip > is used. > > If the UA can't tell why the sips request failed then it will have to > retry the call in all cases. > > The bottom line is that whether to downgrade is a valid policy issue, > and we shouldn't arbitrarily block it from working. > > Paul > > Robert Sparks wrote: > > I think the 480 approach described below is the right thing to do. > > > > RjS > > > > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > > > >> In the meeting, the issue of the error code to be used when the wrong > >> URI is > >> used in a request-URI (i.e., sip instead of sips, or vice-versa) came > >> up. > >> > >> The status quo is 2 new error codes (418 and 419). Another proposal was > >> to use only one > >> (i.e., 418 with 2 new headers). > >> > >> That proposal did not seem to get much traction. And people were not > >> very with the > >> status quo either. > >> > >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to > use > >> an explicit > >> indication of the required/supported URIs (SIP, SIPS, etc.). Of course, > >> one can always > >> put text in the reason phrase to describe the error for displaying to > >> the end-use. > >> > >> After talking to all the individual who seemed to have strong opinions > >> on this topic, > >> it appears that the 480 approach is the preferred approach. > >> > >> Please let the list know if you are strongly opposed to this outcome, > >> along with the > >> reasons behind your opposition. > >> > >> This is the last remaining issue to be closed in the draft, as a result > >> of WGLC. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use [EMAIL PROTECTED] for questions on current sip > >> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
