I'm trying to setup an extremely basic PRESENCE/BLF environment. However, when I call handle_subscribe(), the message gets sent to $si: 5060, *not* $si:$sp Any ideas? Should I be doing something with nat_traversal.co (don't see what, but worth asking...)
The relevant portion of kamailio.cfg is
if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
Cheers, and thanx for any help --- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com
El Jueves, 28 de Mayo de 2009, Mahesh Paolini-Subramanya escribió:
I'm trying to setup an extremely basic PRESENCE/BLF environment. However, when I call handle_subscribe(), the message gets sent to $si: 5060, *not* $si:$sp
I assume you mean "the response gets sent...", right?
Any ideas? Should I be doing something with nat_traversal.co (don't see what, but worth asking...)
The relevant portion of kamailio.cfg is
Add "force_rport()" here.
if (!t_newtran()) { sl_reply_error(); return(-1); }; if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
force_rport() doesnt do the trick - it was one of the first things i tried :-) All it seems to do is add 'rport=...' to the Via line on the returned message, not actually *send* to that port. Its clearly something ridiculously basic. Also, fix_nated_contact() doesnt work entirely either. What it *does* do is ensure that the NOTIFY (from the Sbc to the fone) goes to $sp: $si...
Incidentally, if i stick a t_newtran()/t_release around my REGISTER handling section, i get the same behavior, i.e., the responses go to 5060 instead of the source port (i *am* using force_rport() there). Is that a Clue?
cheers
p.s.
The difference i see is as follows
A) Using the following basic code, the response (i've omitted most of the message)
if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
U 2009/05/28 05:56:44.260579 1.2.3.4:2352 -> 5.6.7.8:5060 SUBSCRIBE sip:mm1@5.6.7.8 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK537dd37BF6A3AE6. Contact: sip:mm1@10.0.0.10:5060.
U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168:5060;branch=z9hG4bK537dd37BF6A3AE6;received=1.2.3.4.
B) If I use force_rport(), as follows, I get
if (is_method("SUBSCRIBE")) { force_rport(); handle_subscribe(); t_release(); };
U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168 :5060;branch=z9hG4bK537dd37BF6A3AE6;rport=2352;received=1.2.3.4.
--- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com
On May 27, 2009, at 6:29 PM, Mahesh Paolini-Subramanya wrote:
El Jueves, 28 de Mayo de 2009, Mahesh Paolini-Subramanya escribió:
I'm trying to setup an extremely basic PRESENCE/BLF environment. However, when I call handle_subscribe(), the message gets sent to $si: 5060, *not* $si:$sp
I assume you mean "the response gets sent...", right?
Any ideas? Should I be doing something with nat_traversal.co (don't see what, but worth asking...)
The relevant portion of kamailio.cfg is
Add "force_rport()" here.
if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/5/28 Mahesh Paolini-Subramanya mahesh@aptela.com:
force_rport() doesnt do the trick - it was one of the first things i tried :-) All it seems to do is add 'rport=...' to the Via line on the returned message, not actually *send* to that port. Its clearly something ridiculously basic.
Also, fix_nated_contact() doesnt work entirely either. What it *does* do is ensure that the NOTIFY (from the Sbc to the fone) goes to $sp:$si...
Yes, fixing the Contact is just valid for future in-dialog requests, not for replies.
Incidentally, if i stick a t_newtran()/t_release around my REGISTER handling section, i get the same behavior, i.e., the responses go to 5060 instead of the source port (i *am* using force_rport() there). Is that a Clue?
It seems really wrong... it whouldn't occur at all !
The difference i see is as follows A) Using the following basic code, the response (i've omitted most of the message) if (!t_newtran()) { sl_reply_error(); return(-1); }; if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); }; U 2009/05/28 05:56:44.260579 1.2.3.4:2352 -> 5.6.7.8:5060 SUBSCRIBE sip:mm1@5.6.7.8 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK537dd37BF6A3AE6. Contact: sip:mm1@10.0.0.10:5060.
U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168:5060;branch=z9hG4bK537dd37BF6A3AE6;received=1.2.3.4.
B) If I use force_rport(), as follows, I get
if (is_method("SUBSCRIBE")) { force_rport(); handle_subscribe(); t_release(); }; U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168:5060;branch=z9hG4bK537dd37BF6A3AE6;rport=2352;received=1.2.3.4.
Just a question, does it occur for retransmissions or for the initial requests? Could you add a xlog into "if (!t_newtran())" and "if (is_method("SUBSCRIBE"))" to ensure it?
Also, try to replace "t_release" with "exit" (it shouldn't affect however).
Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com
On May 27, 2009, at 6:29 PM, Mahesh Paolini-Subramanya wrote:
El Jueves, 28 de Mayo de 2009, Mahesh Paolini-Subramanya escribió:
I'm trying to setup an extremely basic PRESENCE/BLF environment.
However, when I call handle_subscribe(), the message gets sent to $si:
5060, *not* $si:$sp
I assume you mean "the response gets sent...", right?
Any ideas? Should I be doing something with nat_traversal.co (don't
see what, but worth asking...)
The relevant portion of kamailio.cfg is
Add "force_rport()" here.
if (!t_newtran()) {
sl_reply_error();
return(-1);
};
if (is_method("SUBSCRIBE")) {
handle_subscribe();
t_release();
};
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Well, the REGISTER Clue below seemed to work, the key is to do the force_rport() *before* t_newtran(). Which, now that I look at it, is exactly what Iñaki suggested. Thanx Iñaki!
force_rport(); if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
Cheers --- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com
On May 28, 2009, at 6:08 AM, Mahesh Paolini-Subramanya wrote:
force_rport() doesnt do the trick - it was one of the first things i tried :-) All it seems to do is add 'rport=...' to the Via line on the returned message, not actually *send* to that port. Its clearly something ridiculously basic. Also, fix_nated_contact() doesnt work entirely either. What it *does* do is ensure that the NOTIFY (from the Sbc to the fone) goes to $sp:$si...
Incidentally, if i stick a t_newtran()/t_release around my REGISTER handling section, i get the same behavior, i.e., the responses go to 5060 instead of the source port (i *am* using force_rport() there). Is that a Clue?
cheers
p.s.
The difference i see is as follows
A) Using the following basic code, the response (i've omitted most of the message)
if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };U 2009/05/28 05:56:44.260579 1.2.3.4:2352 -> 5.6.7.8:5060 SUBSCRIBE sip:mm1@5.6.7.8 SIP/2.0. Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK537dd37BF6A3AE6. Contact: sip:mm1@10.0.0.10:5060.
U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168:5060;branch=z9hG4bK537dd37BF6A3AE6;received=1.2.3.4.
B) If I use force_rport(), as follows, I get
if (is_method("SUBSCRIBE")) { force_rport(); handle_subscribe(); t_release(); };
U 2009/05/28 05:56:44.264687 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 202 OK. Via: SIP/2.0/UDP 10.16.0.168 :5060;branch=z9hG4bK537dd37BF6A3AE6;rport=2352;received=1.2.3.4.
Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com
On May 27, 2009, at 6:29 PM, Mahesh Paolini-Subramanya wrote:
El Jueves, 28 de Mayo de 2009, Mahesh Paolini-Subramanya escribió:
I'm trying to setup an extremely basic PRESENCE/BLF environment. However, when I call handle_subscribe(), the message gets sent to $si: 5060, *not* $si:$sp
I assume you mean "the response gets sent...", right?
Any ideas? Should I be doing something with nat_traversal.co (don't see what, but worth asking...)
The relevant portion of kamailio.cfg is
Add "force_rport()" here.
if (!t_newtran()) { sl_reply_error(); return(-1); };
if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/5/28 Mahesh Paolini-Subramanya mahesh@aptela.com:
Well, the REGISTER Clue below seemed to work, the key is to do the force_rport() *before* t_newtran(). Which, now that I look at it, is exactly what Iñaki suggested. Thanx Iñaki! force_rport(); if (!t_newtran()) { sl_reply_error(); return(-1); }; if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); };
oh yes, that makes sense :)
force_rport() adds the received port to the incoming top Via header. When the transaction is created (by doing "t_relay()", "t_newtran()"...) the Via content is inspected to know how to generate the responses. So yes, "rport" must be added before the transaction is created :) -
-
Iñaki Baz Castillo -
Mahesh Paolini-Subramanya