It was certainly my intention, when writing the CPL RFC, that <otherwise>
should match whenever any previous condition did not -- i.e., it would be
the equivalent of a default: rule in a C switch statement.  In a switch rule
with an <otherwise> output, the processor's default action should never be
invoked.

In other words, yes, I agree with your analysis; the behavior you've
documented in OpenSER is a bug.

On Tuesday, January 29 2008, "Iñaki Baz Castillo" wrote to 
"[email protected]" saying:

> Hi, I have a doubt related to CPL <otherwise> and <not-present>. Take a look 
> to this simple CPL:
> 
> <cpl>
>     <incoming>
>         <string-switch field="subject">
>             <string contains="hello">
>                 <reject status="reject" reason="Subject is hello" />
>             </string>
>             <otherwise>
>                 <location url="sip:[EMAIL PROTECTED]" />
>                     <proxy />
>                 </location>
>             </otherwise>
>         </string-switch>
>     </incoming>
> </cpl>
>  
> 
> Now imagine an INVITE arriving to the proxy in those 3 cases:
>  
> 
> a)
>   -----------------------------
>   INVITE 
>   Subject: hello user
>   -----------------------------
> The call is rejected since:
>     <string contains="hello">
> OK 
> 
> 
>  b)
>   -----------------------------
>   INVITE 
>   Subject: bye bye
>   -----------------------------
> There is a Subject but it doesn't contain "hello" so <otherwise> is runned:
>     <location url="sip:[EMAIL PROTECTED]" />
>  OK
> 
> 
>  c)
>   -----------------------------
>   INVITE       (no Subject header)
>   -----------------------------
> No "Subject" header. Note that there is not <not-present> section in the 
> above 
> CPL. So, what should occur in this case?
> 
> In my opinion, <otherwise> should be runned but OpenSer proxy doesn't do it 
> so 
> default action is triggered (OpenSer logic continues out of CPL)
> 
> Because of it I open a bug in OpenSer:
>   
> https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1857636&group_id=139143
> 
> 
>  
> RFC 3880 says:
>  
> ------------------------------------------------------
>  4. Switches
>  
>  [...]
>  
>  The output "otherwise", which MUST be the last
>  output specified if it is present, matches if no
>  other condition matched.
>  
>  If no condition matches and no "otherwise" output
>  was present in the script, the default script
>  behavior is taken.
>  ------------------------------------------------------
> 
>  
> So I consider the OpenSer actual behaviour a bug since "otherwise" should be
> matched when "Subject" header doesn't exist because **no other condition
> matched**.
>  
> Default script should not be taken since **no condition matches 
> and "otherwise" output DOES be present**.
>  
>  
> This issue causes a problem in case of matching a "Subject" header, since I 
> must clone <not-present> and <otherwise> contents.
> 
> 
> 
> So I'd need to know which should be the correct behaviour in this case in 
> order to report to OpenSer developers.
> 
> Thanks for any explanation. Regards.

-- 
Jonathan Lennox
[EMAIL PROTECTED]


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to