Probably OPENSER-ONE does not recognize the BYE as targeted to itself
Why would a BYE be targeted at a middle-man?
I acknowledge that I don't check for this in my BYE handler :-)
I did add this as a debug aid:
if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); }
in my stateful relay handler:
route[1] { if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); } t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); } sl_reply_error(); } }
but, obviously without understanding, I changed that to:
route[1] { if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); sl_send_reply("200", "OK"); } else { t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); } sl_reply_error(); } } }
and that seems to snuff this out, but I also have the feeling that I'm just covering up for a flaw elsewhere.
Thanks, -mark
2006/9/28, Mark Kent mark@noc.mainstreet.net:
Probably OPENSER-ONE does not recognize the BYE as targeted to itself
Why would a BYE be targeted at a middle-man?
Because OPENSER-ONE is not a middle-man, is the proxy responsible for the AoR present in the Route|Req-URI and therefore it must not relay it but recognize it as a request targeted to one of its users.
It must process Route Header And after that check the Req URI and send the BYE to the right user, probably using lookup and related...
It shouldn't be that way because the BYE should contain the Contact: header present in the session initiation INVITE and therefore not
sip:JoeUser@OPENSER-ONE:5060
BUT:
sip:JoeUser@JoesUAIP....
Luck!! Samuel.
I acknowledge that I don't check for this in my BYE handler :-)
I did add this as a debug aid:
if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); }
in my stateful relay handler:
route[1] { if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); } t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); } sl_reply_error(); } }
but, obviously without understanding, I changed that to:
route[1] { if (is_uri_host_local()) { xlog("L_ERR", "relay to myself? $rm $ru $si $fu\n"); sl_send_reply("200", "OK"); } else { t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); } sl_reply_error(); } } }
and that seems to snuff this out, but I also have the feeling that I'm just covering up for a flaw elsewhere.
Thanks, -mark
Thanks, this is exactly the kind of answer I need...
Because OPENSER-ONE is not a middle-man, is the proxy responsible for the AoR present in the Route|Req-URI and therefore it must not relay it but recognize it as a request targeted to one of its users.
It must process Route Header And after that check the Req URI and send the BYE to the right user, probably using lookup and related...
OK, but this Route Header processing you are talking about is done inside openser itself, and not driven by my openser.cfg, isn't it?
I know, I know, someone knowledgeable on this list likes to post something like "openser doesn't do anything without you telling it to do it" but that's not really 100% true, the tm module does do some things for you... doesn't it?
So, are you basically saying that my BYE handler is going to be about as complex as my INVITE and/or REGISTER handlers? And then the same for ACK?
I don't understand this:
It shouldn't be that way because the BYE should contain the Contact:
Are you saying that the BYE's I'm getting are flawed for some reason as they do not contain any Contact:
BTW, sort of a separate but related question: when would I get a BYE or ACK with loose_route() true, and when would I get one with loose_route() false?
Thanks, -mark
inline... 2006/9/28, Mark Kent mark@noc.mainstreet.net:
Thanks, this is exactly the kind of answer I need...
Because OPENSER-ONE is not a middle-man, is the proxy responsible for the AoR present in the Route|Req-URI and therefore it must not relay it but recognize it as a request targeted to one of its users.
It must process Route Header And after that check the Req URI and send the BYE to the right user, probably using lookup and related...
OK, but this Route Header processing you are talking about is done inside openser itself, and not driven by my openser.cfg, isn't it?
This routing is "exactly" what loose_route does...that's why you have if(loose_route){} as one of the first checks of your config file, to process in-dialog requests (~those having Route: headers). If the requests goes beyond the loose_route check, it means that there are no more Route headers (and therefore the in-dialog request is suposed to have reached the end-point) and then you have to check the Req-URI to forward the request to the right destination.
I know, I know, someone knowledgeable on this list likes to post something like "openser doesn't do anything without you telling it to do it" but that's not really 100% true, the tm module does do some things for you... doesn't it?
It does RFC 3261 (+RFC 3263) routing....
So, are you basically saying that my BYE handler is going to be about as complex as my INVITE and/or REGISTER handlers? And then the same for ACK?
Not at all!!! If you have record-routed the first INVITE then further messages will be processed by the loose_route...
I don't understand this:
It shouldn't be that way because the BYE should contain the Contact:
Are you saying that the BYE's I'm getting are flawed for some reason as they do not contain any Contact:
The entity responsible for the BYE req-URI is the UA that closed the session. It's the one that must place the Contact of the INVITE in the Req-URI of the following in-dialog requests.
BTW, sort of a separate but related question: when would I get a BYE or ACK with loose_route() true, and when would I get one with loose_route() false?
see above...
Thanks, -mark
-
Mark Kent -
samuel