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

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 Oct 2005 08:24:39 +0100

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.

John

_______________________________________________
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: Fri, 28 Oct 2005 16:12:35 -0500

> [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