Ok. Thank you for the clarification on the xml and the responses to my other questions. I have quite a few other call flows where the b2bua is going to take care of things for me but I reckon this one is going to need a different solution.
I have been holding on to the MediaDispatcher for far end NAT support because I really like the elegance of using the Kernel tracking rules to handle media forwarding. In this case though, it looks like being able to use MediaRelay to "whisper in" a prompt on one side wins. Richard On Dec 8, 2010, at 12:40 PM, Anca Vamanu wrote: > Hi Richard, > > On 12/04/2010 08:35 PM, Richard Revels wrote: >> It's possible that the b2bua doesn't yet support what I'm trying to do with >> it but I find I have some basic questions about the XML layout as a result >> of trying. If I want to handle two different types of request within a >> scenario does it require two <request> blocks or a single <request> block >> containing the two methods? >> >> <rules> >> <request> >> <invite> >> <rule> >> <condition/> >> <action/> >> </rule> >> </invite> >> <bye> >> <rule> >> <condition/> >> <action/> >> </rule> >> </bye> >> </request> >> </rules> >> >> or >> >> <rules> >> <request> >> <invite> >> <rule> >> <condition/> >> <action/> >> </rule> >> </invite> >> </request> >> <request> >> <bye> >> <rule> >> <condition/> >> <action/> >> </rule> >> </bye> >> </request> >> </rules> >> > The first one is the correct way: > <rules> > <request> #and under this all the requests > <invite> # and under it all the rules for Invite > <rule> > <condition/> > <action/> > </rule> > </invite> > > <bye> > <rule> > <condition/> > <action/> > </rule> > </bye> > </request> > </rules> > > >> Next, request blocks defined as invite seem to handle reinvite ok but I'm >> having trouble getting two <bridge> sections to work in the same re<invite> >> block. I can see where that would get complicated pretty quick if it was >> allowed. Just wondering if it's possible to send both legs of a call to a >> new location. > No, it is not possible now to have 2 bridging actions in the same leg.. I can > see also why this could be useful, but this is not supported. > >> I've also tried having the b2bua send a 200 to the side that originated the >> reinvite and bridging the other side to a media prompt. That works fine >> (although I'm wondering how many clients will ACK a 200 with no SDP) > 200Ok is not without sdp, only the reInvite sent to the party that was > already in a call is without sdp. > >> but when the far side comes back from the media prompt (BYE) I am unable to >> bridge the two original legs back together with my current layout. > > It's a bit complicated what you are trying to do - you want to leave the > dialog to client1 open and when BYE comes from media server to reconnect > server1 with client1. The B2BUA was not designed for this case.. it won't > work.. you can only bridge one entity that was in a call and an external > entity now. > > >> The BYE gets passed all the way back to the media peer and the original side >> is left hanging. >> >> Finally, is it possible to compare the contents of a message X-header as >> part of the <condition> for a block? >> > No, it is not possible to check the content of a header in a condition. > > Regards, > > -- > Anca Vamanu > www.voice-system.ro > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
