On 17 Mar 2011, at 18:17, Jeff Pyle wrote:
> Dan, I understand what you're saying. engage_media_proxy() needs to
> create the dialog so it can get its bit in to facilitate the media
> relaying.
>
> In my case, on my functional machine, the routing logic is like this:
>
> if (is_method("INVITE")) {
> send_reply("100", "Trying");
>
> record_route();
> setflag(21); # non-missed calls
> setflag(22); # missed calls
>
> create_dialog();
> if (isflagset(24)) set_dlg_flag("24");
> if (isflagset(6)) {
> engage_media_proxy();
> }
> route(1);
> }
>
> As you can see it has a create_dialog() before the engage_media_proxy().
> And it seems to work okay. Any thoughts on why that might be?
I don't know why this works. I can only assume it's either the dialog gets
crated later, not when you call create_dialog(), or that someone modified the
code in the late versions to allow late comers to a dialog (like
engage_media_proxy) to be able to register their callbacks even when the dialog
was already started.
But then again, I can't tell why it works on a system but not another.
>
> Regarding the manual functions, does one need to use end_media_session()
> in loose_route to handle a reinvite scenario like T.38? Or is the old
> media session some how automatically torn down in this case?
No, it's not automatically ended and you do not need to manually end it either.
For each SDP offer/answer you need to call use_media_proxy() to update the list
of streams.
> Does one
> need to end_media_session() in onreply_route in the case of CANCEL/BYE?
No. You only need to call end_media_session() on CANCEL and BYE, not their
replies.
--
Dan
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
