This appears to be a bug (or maybe a feature) w/ sipxbridge stripping info from the ACK.
When the invite comes from the ITSP to sipxbridge the from address looks like this From: <sip:[email protected]:5060;transport=udp>;tag=1185915028;isup-oli=62 Notice the last isup-oli=62 part. Sipxbridge sends this invite to the phone with the isup-oli=62 intact. After the phone responds with a 200 OK, the ITSP sends an ACK and the From still contains this isup-oli=62 when its received by sipxbrdige. However, when sipxbridge sends this ACK to the phone, the isup-oli=62 is stripped. Prior to Polycom firmware 3.2.3 it will reject any ACK where the FROM is not identical to the INVITE. Updating to firmware 3.2.3 works around this. Polycom bug# 55052 seems to have relaxed this constraint. But it seems like Sipxbridge should either leave the filed alone or possibly always strip it from the invite. If I'm reading RFC3261, it requires the ACK to equal the header fields from the original request. Normally, I'd say this is an ITSP issue, but in this case it's sipxbridge stripping out the isup-oil-62 from the ACK. Should this be filed in the tracker? -Matt >>> On 11/23/2010 at 03:22 PM, in message >>> <[email protected]>, "Matt White" >>> <[email protected]> wrote: I have a polycom 6000 that is unable to pick up a call that comes in through sipxbridge. The 6000 is running 3.1.3c. Calls from other internal extensions. Spxbridge logs look clean but the trace shows the pory send the "200 ok" to the bridge 6 times. The bridge does not forward these out to the ISP. But with logging set at debug I see it recieved the messages but does not show anything being rejected. It only shows: 6558-"2010-11-23T17:24:11.078000Z":594838:JAVA:INFO:pfcpbx01:PipelineThread-20:00000000:sipXbridge:"[SIPDialog.java:2635][DialogFilter.java:1452][TCPMessageChannel.java:570][PipelinedMsgParser.java:361][Thread.java:619]" 6559-"2010-11-23T17:24:11.078000Z":594839:JAVA:INFO:pfcpbx01:PipelineThread-20:00000000:sipXbridge:"[SipProviderImpl.java:182][DialogFilter.java:1464][TCPMessageChannel.java:570][PipelinedMsgParser.java:361][Thread.java:619]" Then the proxy sends another 200OK and repeats until the call is disconnected. The only log that shows an error during this time period is sipxrelay. It shows this: sipxrelay:"Unexpected mixing of odd and even parityEVEN" Any clues? -M
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
