On Mon, Sep 29, 2008 at 9:58 AM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-09-28 at 23:58 -0400, M. Ranganathan wrote: >> Hello, >> >> I am checking out call pickup for an inbound call via an ITSP ( >> through sipxbridge ). >> >> The scenario is : >> >> 1. Inbound call comes into sipxbridge and is sent to extension 203. >> >> 2. Extension 204 tries to pick up with *78203 while the phone is >> ringing. The pickup is successful. The inbound call is handled by >> extension 204 and externally all looks like it did succeed. However, >> the trace shows strange behavior. >> >> 3. At the end, I see a NOT found that is issued by the Registrar for >> a strange user ~vm~~~vm~user3 , which presumably is the voice mail of >> user 3. >> >> Questions : >> >> 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) >> >> >> Is sipxbridge doing something wrong with the signaling it is >> constructing to trigger this strange behavior or is this expected >> behavior. > > The first thing I see that doesn't look right is that sipXbridge sends a > BYE in frame 43 to the ringing phone. Since all you have at that point > is an early dialog, a CANCEL would be more appropriate. Personally, I > wouldn't do that until the pickup succeeds, but that is perhaps a matter > of taste. > > The problem may be that sipXproxy does send a CANCEL on that dialog in > frame 54 - it appears not to have noticed that the BYE has terminated it > already. It also proceeds with forking that call by generating an > INVITE (frame 55) to the voicemail for that user, but something is wrong > with the routing of that, because in frame 61 the redirect server > returns the invalid ~~vm~~~vm... contact rather than the correct > redirection to the mediaserver. > > One other thing... the Call-Id values being used by sipXbridge are the > same on both sides (compare frames 1 & 2). As has been noted on this > list before, this is probably not a good idea, and likely leads to > confusion. > >
Actually, I did change the call ID. The call ID in frame 2 is the caller ID in frame 1 with a ".0" appended to the end of it. > > -- 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
