On Sat, Sep 6, 2008 at 11:03 PM, M. Ranganathan <[EMAIL PROTECTED]> wrote: > 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 > >
Problem resolved! The problem was that the INVITE that sipxbridge was generating as a result of the REFER did not have a Referred-By header and hence did not get placed in a park orbit. Ranga > > > > > > -- > M. Ranganathan > -- 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
