On Fri, May 8, 2009 at 1:27 PM, Paul Mossman <[email protected]> wrote: > Hi all, > > I have two things to discuss about XX-517: Problem clearing down inbound > ITSP call through sipXbridge > > > 1. Polycoms send 603 Decline after a configurable period of time, when > an INVITE is not answered or cancelled. Scott, you state that the phone > "should _NOT_ send a 603 response _ever_." >
Ok people, to paraphrase Rodney King, " Why cant we all just return nice error codes and just get along? " > The problem I think is that the phone does not know that no other end > point will answer the request? > (http://tools.ietf.org/html/rfc3261#section-21.6.2) > > I can raise an issue with Polycom. We recommend sending 480 Temporarily > Unavailable instead? > > > 2. Chaitra noted three different observed behaviours: > http://track.sipfoundry.org/browse/XX-517?focusedCommentId=38999&page=co > m.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_ > 38999 > > Behaviour #2 is the Polycom's mysterious 400 Bad Request response to the > CANCEL. I've alerted Polycom to the new logs Chaitra has provided. > > Behaviour #1 seems to be the desired sipXbridge behaviour, where it is > able to detect and decline the unwanted second INVITE from the ITSP. > > Behaviour #3 seems to be a issue with sipXbridge, where it was not able > to detect that the third INVITE from the ITSP is also unwanted. > > Can I suggest that a separate JIRA issue be raised for Behaviour #3? sipXbridge cannot deal with anything if it happens after a certain time period. It cannot hold on to the call IDs for ever. For example, if the ITSP calls back after 10 minutes with the same call ID sipxbridge cannot detect it. It keeps the call ID around for a period of time in a table to try to compensate for this behavior. We can change that period of time but we cannot make it large without bound. If the ITSP is sending unwanted INVITEs, I suggest we try to solve that issue. However, I have had some correspondence which indicates it is a feature of the system. This will all go away if PolyComm did not send 603 but then we still have the odd gateway (Audiocodes in particular) that does send 603. It might be the case that nothing much can be done about it in the general case. > > > Thanks. > > > -Paul > [email protected] > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
