Dan Pascu wrote: > It depends on what you do. If you process the redirect in the proxy's failure > routes, then indeed you have a problem. If you just relay the 30x to the > phone > and let it do the redirection, that it will generate a new INVITE which you > handle the normal way as it generates a new dialog. In fact this would be > recommended, as the caller should be the one deciding if he accepts the > redirect, not the proxy.
That was not the question ;-) If your customers are paying for their calls to PSTN they would not be amused if someone would be able to force them into calling special service numbers or whatever. You either want to forbid redirects at all or bill the call to the user issuing the "call forward". >> - is there a known workaround for this issue, that I can apply >> to my config script? > > See above. Sincerely, even it the above statement might be correct I don't care ;-) Therefore this part of your response doesn't really help me - but it allows me to read between the lines that there will be no quick fix, so I guess the answer is simply "NO". >> - is it planned to change engage_media_proxy to make it "branch- >> aware"? > > It cannot be called in a branch route as engage_media_proxy must be called > before the transaction/dialog is created. As far as I understand the branch > routes are called by t_relay after creating the transaction/dialog. > ... > engage_media_proxy (sets dialog flag) -> t_relay -> create transaction/dialog > -> call mediaproxy and modify the request -> branch it -> call branch routes > to apply branch changes -> send out requests on each branch. Thank you very much for this detailled explanation! Now I really understand, why what I want to achieve is not possible using engage_media_proxy. This combined with... > But even if you would be able to call it from the branch route, it would > still > not solve your b case above if that is be handled by a failure route. ...this part leads me to the question, how such edge cases could be automagically solved in the future. Some time ago Bogdan raised a brainstorm request regarding new route types - as for example right now it is not possible to have different reply routes for different branches, who needs such thing needs to hack something with his config file, using rr-params or whatever. We are dialog stateful, transaction stateful - but it seems there is nothing allowing script/module writers to easily distinct between different branches, still being dialog aware. Wouldn't it be worth the effort to provide such thing, as especially in this specific case (engage_media_proxy) I would consider it to be really useful. NAT issues are handled per branch, and so should RTP issues in case of NAT problems. Functions like nat_keepalive and engage_media_proxy take away a lot of pain from the script writer - and should therefore be designed to behave flawlessly in most/all cases. And, something else: SDP does not need to be negotiated with INVITE/200, if there is no SDP in your initial INVITE you'll get your offer from 200 Ok and you'll respond in your ACK packet. Even if I have never seen such thing in the wild, I assume this is not possible to be handled with engage_media_proxy. >> - if you can acknowledge neither of the above: do I really need >> to tear down/re-use Mediaproxy session on each ReINVITE? What >> is the current best practice in this case? > > You cannot do that with engage_media_proxy. When you want to use that, you > have to decide before hand if you are going to use mediaproxy or not. Once > started it will only be ended when the dialog ends. If you want to be able to > have a fine-grained control when to start/stop mediaproxy, you have to use > use_mediaproxy/end_media_session explicitly. That's pretty clear. My intention (by asking for "best practice") was to figure out how this could be done as efficient as possible. As of session timers there are a lot of ReINVITES in a single phone call. Do I really need to call end_media_session() and use_mediaproxy() for each In-Dialog INVITE with SDP? Probably this is what also engage_media_proxy does, so the answer would be "yes". Is it enough to call use_mediaproxy() for all: - initial INVITEs with SDP - In-Dialog INVITEs with SDP - ACKs with SDP - Replies > 100 and < 300 with SDP - or just 180|183|200 I'll manually "tag" branches using Mediaproxy to be also prepared for the 200/ACK variant and to avoid useless end_media_session calls for branches not using it. Regardless of the above thoughts - will I be fine with this approach? Best regards, Thomas Gelf _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
