On Wed, 2009-10-28 at 14:49 -0400, M. Ranganathan wrote: > Hello, > > This question is about the following trace file: > > > > http://track.sipfoundry.org/secure/attachment/22336/latest-merged.xml > > Scenario: > > (reproduced from JIRA ) > > Precondition: > ------------------ > 1. User 375 is registered to an AudioCodes MP118 FXS phone (Analog > phone) > 2. Add a SIP trunking role and leave the incoming call destination > BLANK. Add a "Bandwidth.com" SIP trunk. > 3. The Bandwidth account number is assigned as alias to user 375. > 4. "System behind NAT" is enabled. > 5. MOH is 'disabled' on the sipXBridge. > > User and Phone details: > --------------------------------- > User 375 --> AudioCodes MP118 FXS -->IP address: 176.25.2.42 > > Steps to reproduce: > --------------------------- > 1. From a PSTN phone(1) call the Bandwidth DID number -->User 375 > starts ringing. Answer the call. > 2. From 375 do a "blind transfer" to PSTN phone(2) > --since this is a analog phone, press the hook, This puts the PSTN > phone(1) on hold. > --next dial the PSTN phone(2) in this case 00-91-9886216883 > --once PSTN phone(2) starts ringing, hangup the call from the > analog phone(user 375) > > 3. Answer the call from PSTN phone(2) > > > What I see from the trace is that the Audiocodes is sending a REFER > before the call is answered. > > This happens on Frame 74. i.e. before the OK is received, it sends out > a REFER. > > Subsequently sipxbridge needs to send a RE-INVITE when the dialog is > in early state and hence refuses to do so. This happens on Frame 89 > and 90. > > So to conclude this saga, the question is - is this an Audiocodes bug. > If so I can file an XTRN issue.
No, I don't think it's an Audiocodes bug. This is a Consultative-turned-Blind transfer. The Refer has a Replaces header parameter that matches the early dialog on the consultative leg. The sipXbridge now has all it needs, I think, to connect the outside ringing leg (started by the INVITE in frame 55) with the existing inbound call leg (started by the INVITE in frame 1). Obnoxious case, but one that needs to be solved. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
