28 Sep
2006
28 Sep
'06
6:45 p.m.
> 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
28 Sep
28 Sep
7:01 p.m.
New subject: [Users] thought exercise
2006/9/28, Mark Kent <mark(a)noc.mainstreet.net>et>:
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.
> 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
7:21 p.m.
New subject: [Users] thought exercise
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
29 Sep
29 Sep
9:27 a.m.
New subject: [Users] thought exercise
inline...
2006/9/28, Mark Kent <mark(a)noc.mainstreet.net>et>:
Thanks, this is exactly the kind of answer I need...
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.
> 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?
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:
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.
> 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?
see above...
Thanks,
-mark
6638
days inactive
6639
days old
3 comments
2 participants
participants (2)
-
Mark Kent -
samuel