Hello Ellie, I did a bit more digging, I should of showed you the entire sip message, it is not an issue of a regular expression as I originally thought, i think it is more of an issue with multiple Content-Type’s in the boundary and the entire sip message. Please see the sip message below, No matter what I put in for Content-Type it does not appear to match any ifc. I even tried a group to match any of the 4 content-type’s and still failed to get a match. Im not sure if this is a limitation within clearwater or the ifc spec altogether. Either way, I am sending this as just information. I’ve changed my ifc to not match on content-type.
18-07-2014 19:05:56.374 Verbose stack.cpp:232: RX 2153 bytes Request msg INVITE/cseq=11931 (rdata0x7f8750325968) from TCP xxx.xx.xx.40:12693: --start msg-- INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TCP xxx.xx.xx.40:5060;branch=z9hG4bK+1a550a9d05568ae8b819294579cb27c91+sip+1+a64e6738 From: <sip:[email protected]>;tag=xxx.xx.xx.40+1+9f215fa2+44c56820 To: <sip:[email protected];user=phone> CSeq: 11931 INVITE Expires: 180 Route: <sip:sprout01.example.com:5054;transport=TCP;lr;orig> Content-Length: 831 Supported: replaces,timer,norefersub, 100rel P-Charging-Vector: icid-value=12365d0ff2a24a52ac4d8832e693663b;orig-ioi=example.com Contact: <sip:[email protected]:57716;transport=tcp;ob>;+g.oma.sip-im;+sip.instance="<urn:gsma:imei:35513605-331763-5>" Record-Route: <sip:xxx.xx.xx.40:5060;lr> Max-Forwards: 69 Call-ID: 0gqaac8waaacbaaalxyaaklbiugvddztfff+m3937ez7fockf6lwfkndwm5ek...@xxx.xx.xx.40 Allow: PRACK, INFO, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Session-Expires: 1800 Min-SE: 90 Accept-Contact: *;+g.oma.sip-im Contribution-ID: WRTjH3oD9ECkAAAEItHz00G0hkl1rmjFKlpz Subject: Test User-Agent: IM-client/OMA1.0 RCSAndrd/2.4.7 COMLib/3.3.8 P-Served-User: sip:[email protected] P-Asserted-Identity: sip:[email protected] P-Visited-Network-ID: example.com Content-Type: multipart/mixed; boundary=boundary22 --boundary22 Content-Type: application/sdp v=0 o=- 24035414516158 24035414516158 IN IP4 xxx.xx.xx.50 s=- c=IN IP4 xxx.xx.xx.50 t=0 0 m=message 17200 TCP/MSRP * a=sendrecv a=accept-types:application/im-iscomposing+xml message/cpim a=path:msrp://xxx.xx.xx.91:9/U7rvZRszdc;tcp a=accept-wrapped-types:message/imdn+xml text/plain application/vnd.gsma.rcspushlocation+xml application/vnd.gsma.rcs-ft-http+xml a=setup:actpass --boundary22 Content-Type: message/cpim From: <sip:[email protected]> To: <sip:[email protected]> DateTime: 2014-07-18T14:05:55.614-05:00 NS: imdn <urn:ietf:params:imdn> imdn.Message-ID: rKywig5k65hRPNR9TCkcVL9tEVCCQnQU imdn.Disposition-Notification: positive-delivery, display Content-Type: text/plain;charset=utf-8 Content-Length: 4 Test --boundary22-- --end msg— On Jul 18, 2014, at 12:31 PM, Eleanor Merry <[email protected]> wrote: > Hi Trey, > > I can't replicate this on my system; the ifchandler correctly matches against > the Content-Type header. > > The Content-Type header does get stripped in the bug you highlighted > (https://github.com/Metaswitch/sprout/issues/659), can you confirm that this > matching is being done on an INVITE that still has its Content-Type header? > If so, can you please send me the debug Sprout logs for the INVITE, and some > more details as to the scenario you're testing so that I can try and > reproduce it? > > Thanks, > > Ellie > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Ormsbee, > Trey > Sent: 18 July 2014 16:12 > To: [email protected] > Subject: [Clearwater] regular expressions in ifc's > > Im seeing that a simple .* in an ifc does not appear to be matching when it > should: > > example from a stripped log file: > > Content-Type: multipart/mixed; boundary=boundary22 > > ifc: > > <InitialFilterCriteria> > <Priority>0</Priority> > <TriggerPoint> > <ConditionTypeCNF>0</ConditionTypeCNF> > <SPT> > > <ConditionNegated>0</ConditionNegated> > <Group>0</Group> > <Method>INVITE</Method> > </SPT> > <SPT> > > <ConditionNegated>0</ConditionNegated> > <Group>1</Group> > <SIPHeader> > > <Header>Content-Type</Header> > > <Content>multipart/mixed;.*</Content> > </SIPHeader> > </SPT> > </TriggerPoint> > <ApplicationServer> > > <ServerName>sip:172.30.21.101:5510</ServerName> > <DefaultHandling>1</DefaultHandling> > </ApplicationServer> > </InitialFilterCriteria> > > > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:476: SPT class Method: result > true > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:583: Add to group 0 val true > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:476: SPT class SIPHeader: result > false > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:583: Add to group 1 val false > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:601: Result group 0 val true > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:601: Result group 1 val false > 18-07-2014 14:28:52.733 Debug ifchandler.cpp:605: iFC matches > 18-07-2014 14:28:52.733 Info ifchandler.cpp:735: Found (triggered) server > sip:xxx.xxx.xxx.101:5510 > > Group1 should be true? am I missing something about regular expressions in > sipheaders? or is there a reason this is marked as false? > _______________________________________________ > Clearwater mailing list > [email protected] > http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
