[OpenSIPS-Users] b2bua xml files

[Richard Revels]

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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users