On Sat, Sep 6, 2008 at 6:00 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-09-06 at 15:34 -0400, M. Ranganathan wrote: >> 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? > > There can any number of arbitrary park orbits, so I don't think that > providing sipXbridge with information about them is the answer. More > likely the fix is to get the park server to recognize that it's got two > media sessions to one target. > > >
There seems to be something else the matter. I turned off Music On Hold for sipxbridge so there will only be a single dialog with the park server and yet the Park Server will not wake up after the timeout. Looking at a well behaved scenario ( ie. when the phone Parks the call ) versus what sipxbridge is generate ( i.e. send INVITE to Park Server extracting relevant information from the REFER as I cannot transfer the REFER to the ITSP ), I notice only one apparent difference: sipxbridge sees an Inbound Refer-To as follows: Refer-To: <sip:[EMAIL PROTECTED]> It extracts the X-sipx-auth-identity and sends it forth in the subsequent INVITE bound to the park server : x-sipx-authidentity: <sip:[EMAIL PROTECTED];signature=48C33E76%3A%3Ad433f73567f92a8e63347cab8bf8def8> Note here that the header has been decoded. I am not sure if this is the right thing to do. In contrast, I took a look at a successful park, unpark scenario and the corresponding header there looks like this: X-Sipx-Authidentity: <[EMAIL PROTECTED];signature=48C29A96%253A%253Ade81a79f34929caeaafabd84561f04f9> Note that the stuff in the <> is not fully decoded. sip%3Auser2 versus sip:user2 Not sure if this has any relevance to the problem at hand. Ranga -- 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
