On Thu, Sep 25, 2008 at 3:50 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-09-25 at 13:11 -0400, M. Ranganathan wrote: >> Hello >> >> Attached is a trace depicting a successful blind transfer operation. >> >> Frame 36 shows sipxbridge soliciting an offer from the iTSP >> The ITSP responds in Frame 38 >> The answer from the phone is relayed back in frame 63. >> >> Between frame 38 and frame 63 the phone on the calling party side ( >> i.e. ITSP) would be expected to ring but I cannot send a RINGING >> because I got an OK already from that side. >> >> Question: How do we circumvent this problem? It would be nice if the >> caller heard a comforting ring. > > that interval is 0.34 seconds... who cares? You won't have time to play > even one ring. > >> Note that I cannot delay sending BYE on frame 75 until after the ACK >> which would allow the Park server to play music until pickup since >> this winds breaking when the target of the transfer is the park >> server. >> >> See the following thread for details on the situation above >> >> http://list.sipfoundry.org/archive/sipx-dev/msg13465.html >> >> So the only option I have is to send the BYE on frame 75, leaving the >> caller with a silence when the phone is ringing. > >> How can this problem be resolved to at least allow MOH to play until >> pickup (or preferably RINGING at the caller phone while the transfer >> target is ringing if that were possible)? I think the answer lies in >> the park server being able to handle the case above but I would like >> to solicit an opinion here. > > There are calls missing from your trace, so I can't tell if this is a > timeout or a retrieval, but in any event... > > Why not just not even do the reINVITE on the ITSP side until after > you've got the new call set up on the inside? > > Don't send the BYE to the MOH service until you've actually gotten a > successful call completion to the target.
I was doing that earlier and life was fine until somebody tried to do a blind transfer to the park server itself and then the music would not stop. Dale had suggested changing the call ID on each INVITE to the Park Server as it is apparently not able to distinguish call legs based on dialog iDs. I think I will try that one. I need to use a new call ID on each INVITE I send to the park server as Dale suggested earlier. That might avoid the situation I have of needing to send the BYE early You dont' really need to do > the reINVITE in frame 72 at all... it's going to have the same offer in > it that you got in frame 38 anyway. But you can just not do that > dialog at all until the inside dialog is set up. Presumably one can solicit an offer from the transfer target first and then replay the returned SDP an INVITE to the ITSP side. I don't think the outcome would be qualitatively any different from a user perspective. The transfer agent (i.e. phone on the ITSP side) will not hear RINGING anyway. Incidentally this flow is following the recommendations of Dale's draft. I will play with the call Ids and see if I can delay the BYE. I'll post some traces and outcomes later. > > > -- 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
