Subject: RE: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01)

From: "Elwell, John" <[email-masked]>
Date: Mon, 31 Oct 2005 07:46:17 +0000

Dean,

While I accept this would be reasonable behaviour for alert-info case, I
still disagree with your statement that "SIP is actually very clear here --
accepting the request with a Requires: option tag says only that you
understand the extension, not that you are committing to doing what it says
for this call."

In section 3 of RFC 3262 it states: "The UAS MUST send any non-100
provisional response reliably if the initial request contained a Require
header field with the option tag 100rel. If the UAS is unwilling to do so,
it MUST reject the initial request with a 420 (Bad Extension) and include an
Unsupported header field containing the option tag 100rel." So in this
particular case you cannot accept the request but not honour the extension.

John

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 October 2005 22:13
> To: Elwell, John
> Cc: Paul Kyzivat; [email-masked]; MARJOU Xavier RD-MAPS-LAN; 
> [email-masked]
> Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on 
> draft-willis-sip-an sweralert-01)
> 
> 
> On Oct 28, 2005, at 2:24 AM, Elwell, John wrote:
> 
> > Dean,
> >
> >
> >>>
> >>> The question then is: if the OPTION tag is there, should the
> >>> request be rejected if the Alert-Info value isn't
> >>>
> >> understood, or if
> >>
> >>> it won't be honored?
> >>>
> >>>
> >>
> >> SIP is actually very clear here -- accepting the request with a
> >> Requires: option tag says only that you understand the
> >> extension, not
> >> that you are committing to doing what it says for this call.
> >>
> > [JRE] This is already broken with 100rel.
> >
> 
> Not at all. You could always fail the transaction.  There's a  
> difference between rejecting a request because you don't 
> understand a  
> specific extension and rejecting a request because your policy  
> disallows acting on that extension for this specific request -- in  
> one case you return a "bad extension" response, and in the other a  
> "forbidden" with reason text explaining why it was forbidden ("403 I  
> ain't doing preconditions with you, sucker!")
> 
> It's like the difference between not supporting digest  
> authentication, and not allowing a specific user to place a call.
> 
> 
> I suppose it would be fair to say that it is up to the specific  
> extension to say one of:
> 
> 1) If you accept a request but can't/won't honor the extension, the  
> transaction proceeds with a potentially diminished or altered user  
> experience.
> 2) If you accept a request but can't/wont honor the extension, then  
> an error condition results.
> 
> 
> This is one of the differentiators for P-class extensions: they have  
> to be in class 1 above.  There are other differentiators, such as  
> that P-headers are not allowed to have option tags, and they aren't  
> required to be standards-track.
> 
> 
> Alert-Info definitely falls into class 1. You might receive an Alert- 
> Info with the semantic "distinctive ring associated with your 
> primary  
> line service", but have a user-interface that recognizes that the  
> call is from your fiance's phone and instead plays Mendelsohn's  
> "Wedding March". This doesn't break the protocol. So the same phone  
> might receive an Alert-Info with the semantic "Emergency" and 
> instead  
> play your configured emergency tone. In both cases your phone  
> understands the Alert-Info header and would accept the request even  
> with a Require:.
> 
> 
> --
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 31 Oct 2005 11:56:22 -0600

> particular case you cannot accept the request but not honour the  

Specific extensions can indicate that the request should be failed  
with an error response (and specify he response) although I question  
the wisdom of rejecting a request with a 420 after having indicated  
support for that extension in a Supported header.

But I'm willing to concede that the documentation is unclear, given  
the wording in the example.

Thanks!

--
Dean