Now I've had a chance to look at your trace. I think that there's more than one problem here (and they interact).
I think that the complaint in your original message is that the Park Server's "return to the parker" feature couldn't be activated. That isn't stated clearly in the message. In regard to that problem, the Referred-By header is essential, as you noted -- the parker that is returned to *is* the contents of the Referred-By field. At this point, let me insert another observation: In the trace you provided, there are 4 dialogs: - original call from ITSP to sipXbridge - original call from sipXbridge to 201 - MOH dialog from sipXbridge to Park Server - REFER-initiated dialog (replacing dialog 2) from sipXbridge to Park Server (402) It's debatable whether dialogs 1 and 2 can share the same call-id, but in standard SIP usage, dialogs 3 and 4 must have unique call-ids. (Having separate call-ids also makes the traces easier to read.) In regard to MOH, there are a couple of problems you might be reporting: One is that MOH is being provided to the incoming caller for two distinctly different reasons: 1) for a short interval, the caller gets MOH because the callee has put him on hold, prior to blind-transferring the call to the Park server, and 2) MOH is the audio resulting from the call to park orbit 402. As such, we expect that these two MOH streams will be set up in different ways, and there may be an audible transition between the two. A way to make what is going on clear is to suppose that the park orbit has a custom audio stream which is different from the standard MOH that sipXbridge sends to calls that are on hold. Then we *expect* the user to hear the transition between the two audio streams. The second problem is that the Park Server might not be handling dialog 4 correctly because it has the same call-id as dialog 3. I think strictly speaking that having the same call-id should work (or if not, dialog 4 will be rejected with 482 Merged Call). But I don't expect our sipXcallLib machinery to handle the situation correctly. This can be solved by giving dialog 4 a unique call-id, which will prevent the Park Server from confusing it with dialog 3. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
