On Sun, 2008-09-28 at 23:58 -0400, M. Ranganathan wrote: > 1. why does sipx proxy sending the call to voice mail in frame 59. > 2. Why is it sending an INVITE to ~vm~~~vm~user3 ( what is that?) in Frame 65 > 3. Why is sipxbridge seeing a 404 Not found in Frame 76 ( which it > ignores since the OK has been sent to the ITSP already)
There are a lot of things going on here that could be improved. In regard to the UA at 192.168.5.236: It registers with a URI without a transport parameter, but it appears to only receive UDP; it should thus use "transport=udp". It does not put a User-Agent header in responses. When it receives a BYE to an early dialog (which is valid), it responds 200 to the BYE but doesn't respond to the INVITE. The INVITE still needs a response. See section 15 of RFC 32761; section 15.1.2 recommends a 487 response to an INVITE that is aborted by a BYE. Using BYE to terminate an INVITE that has not terminated is probably not what you want. The BYE can only be sent in regard to a particular early dialog, and it will cause the INVITE to continue forking. The usual technique is to send a CANCEL, and then clean up any dialogs that got established anyway with immediate BYEs. Because the UAS hasn't provided a final response to the INVITE at frame 18, the proxy cancels it 20 seconds later at frame 54. The proxy then continues forking the call starting at frame 59. The bizarre URI sip:[EMAIL PROTECTED] comes from the redirector incorrectly constructing a voicemail URI for a voicemail URI (compare frames 59 and 61). Diagnosing this will require a proper sipx-snapshot, to see how the redirectors are configured. The 404 at frame 76 is the final response to the INVITE at frame 2. The 404 is the chosen final response, ultimately from frame 67. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
