On Sat, Sep 6, 2008 at 1:37 PM, M. Ranganathan <[EMAIL PROTECTED]> wrote: > Hello, > > I am testing the interaction of inbound calling via the ITSP and the > park server. > > sipxbridge is currently configurable to play Music On Hold when the > user puts an inbound ITSP call on hold. This works very well when the > transfer target is *not* the park server. > > However, bad things happen when an inbound ITSP call is transferred to > the Park Server. Note that under these conditions, the Park Server is > already playing MOH as part of the call transfer process ( this is > initiated by sipxbridge) when the call is parked. Here is what I > observe: > > 1. Call comes in from ITSP and is picked up at extension 201. > Extension 201 wants to park the call so starts a blind transfer. MOH > starts to play on the PSTN side. This involves sending an INVITE to > the Park Server to play the MOH ( this INVITE is sent by sipxbridge). > > 2. Extension 201 parks the call by sending a second INVITE to the park > server. The park server does not send a RE-INVITE to the ITSP as it > would for a local call. This is good because MOH is already in > progress for the call. > > 3. Timeout expires. The park server refuses to issue a REFER after > the timeout period. > > > Would it be possible to make the Park Server cognizant of the fact > that it is already playing music for a given call (for example by > looking at the call ID) and hence should not play a second stream for > the same call? > > Thanks. > > > Ranga > > >
I decided to attach a trace for the scenario above: On frame 34, notice a RE-INVITE to put the call on hold. At this point, sipxbridge will solicit an offer from the ITSP (frame 35) and forward the offer in an INVITE bound to the park server so the user can hear Music on Hold ( frame 38 ) , finally completing the three way handshake on frame 64. Then along comes the REFER when the transfer agent wants to park the call on frame 68. Note that the park server extension in this case is 402. Note too that when I initially invited the park server, on frame 38 I had no idea that its extension was 402 (I send off an INVITE to ~mh~~). Perhaps the issue is that the park server is only able to handle a single dialog per call. Perhaps a solution would be to provide the park server extension to sipxbridge as a configuration parameter and avoid using the special id ~mh~~. Then I can tear down the original dialog with the park server for the given call ID and re-establish it when I see the REFER. In this case, it would take a little additional configuration information i.e. you MUST have the park server enabled and provide its extension. What is the best way to proceed on this? Thank you for your help. Ranga > > > -- > M. Ranganathan > -- M. Ranganathan
merged.xml.gz
Description: GNU Zip compressed data
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
