Steve All looks very mysterious. The packet Clearwater is complaining about has 589 bytes of rubbish at the beginning, before the actual INVITE starts. If you look at both the Clearwater and Perimeta packet captures and isolate just the TCP stream that is showing the error, there is a 589 byte gap in the TCP sequence numbers. So it looks like Perimeta is sending the 589 bytes of rubbish, but for some reason it isn’t passing the tcpdump filters you’re using so we can’t see the content on the wire.
Can you re-run the test with no filters on tcpdump so we can see everything that is being sent/received. Mike From: Steve Yeoman [mailto:[email protected]] Sent: 20 October 2014 00:36 To: Mike Evans Cc: [email protected] Subject: Re: [Clearwater] PJSIP syntax errors Hi Mike, Attached are the Clearwater log, Perimeta log, UA packets, Perimeta packets and Clearwater packets showing another example of the malformed ACK. The broken message starts in the UA as an INVITE (packet #9) but becomes an ACK by the time it gets to the sprout log. In this case the ACK contains an extra line of just "ead2" (see line 3478 of sprout log) . If you examine the preceding Via header you'll see that the last 4 characters are the same "ead2". So it does look like an issue with the TCP buffer not being handled correctly. cheers Steve On 17 October 2014 22:57, Mike Evans <[email protected]<mailto:[email protected]>> wrote: Steve It looks like Clearwater is getting out of sync with the SIP message boundaries on the incoming TCP stream - it seems to think the INVITE starts with an SDP body, so is rejecting the INVITE because it starts with the "v=0" line of the SDP. The ACK problem does look like a genuine issue with the incoming message, as there is an extra line containing "9f9" after the first Via header. Did this ACK message log occur before the INVITE log, or after. I'm wondering if there is a bug in the way we are handling badly formed messages which means we get out of sync for later messages on the same TCP connection. (SIP inherited HTTPs way of delimiting message boundaries - something I'm sure everyone who has every written a SIP parse will agree was a very bad decision!) Can you send us the full sprout log and incoming sprout packet capture for the problem so we can see what is happening before the rejected INVITE. Thanks, Mike -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Steve Yeoman Sent: 13 October 2014 01:18 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] PJSIP syntax errors Hi, INVITE messages that are passed from Perimeta to Sprout are sometimes failing with PJSIP syntax errors like this: 12-10-2014 23:51:34.590 UTC Error pjsip: sip_transport. Error processing 1935 bytes packet from TCP 172.31.12.131:16187<http://172.31.12.131:16187> : PJSIP syntax error exception when parsing 'Request Line' header on line 1 col 2: v=0 It seems that the usual first line of an INVITE message - "INVITE sip:[email protected]<mailto:sip%[email protected]> SIP/2.0" - is being dropped or lost from the incoming message. I started noticing this in Omar Sharif Bridge and noticed it again today after I upgraded to Pacman. Although I can't say for sure if it did or didn't happen in previous releases. Attached is a Perimeta log, packets captures and Sprout log. It shows the outbound INVITE from Perimeta looking ok, the incoming packet in Clearwater looking ok, but the INVITE is mangled by the time it gets to Sprout. I also see a similar problem with some ACK messages: 12-10-2014 23:51:14.976 UTC Error pjsip: sip_transport. Error processing 1873 bytes packet from TCP 172.31.12.131:16187<http://172.31.12.131:16187> : PJSIP syntax error exception when parsing '9f9' header on line 3 col 0: ACK sip:[email protected]<mailto:sip%[email protected]> SIP/2.0 Via: SIP/2.0/TCP 172.31.12.131:5054<http://172.31.12.131:5054> ;branch=z9hG4bK+026450efe9bd543d06cda901075ba5e71+sip+1+a64de9f9 9f9 From: <sip:[email protected]<mailto:sip%[email protected]>>;tag=172.31.12.131+1+f89a617c+fd93093c To: sip:[email protected]<mailto:sip%[email protected]> My Perimeta and Clearwater instances are in the same ec2 subnet. Is there anything I can do to configure this problem away? thanks Steve _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
