Kamailio:Contact validation during INVITE
Hi, We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri. is_registered(struct sip_msg* _m, udomain_t* _d){ getContactP(_m,_d); } pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {); //Getting pcontact from source IP and port if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) { LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto); } if (c == NULL) { //Getting pcontact from contact uri. if (ul.get_pcontact(_d, &ct->uri, &c) == 0) { } } We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success. We would like to know reason behind comparing the source IP and port to fetch the pcontact? Regards, Prashant
Hello, updated the subject of the email to reflect it refers to IMS extensions, which are different than the standard IETF registrars. That makes it easier to be spotted by the people using IMS and the dev guys can shed some light on why the implemented that way. Cheers, Daniel On 24/11/15 11:59, Prashant Desai wrote:
Hi,
We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri.
is_registered(struct sip_msg* _m, udomain_t* _d){
getContactP(_m,_d);
}
pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {);
//Getting pcontact from source IP and port
if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) {
LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto);
}
if (c == NULL) {
//Getting pcontact from contact uri.
if (ul.get_pcontact(_d, &ct->uri, &c) == 0) {
}
}
We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success.
We would like to know reason behind comparing the source IP and port to fetch the pcontact?
Regards,
Prashant
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
Hi Prashant, Often the P-CSCF has to know about the contact (for example for Rx QoS, security (asserting identity, etc). It is also possible that a contact header is not provided by the UE so you have no alternative but to search src info, via info, etc. So that is the main reason. So let me understand your problem a little more. You are saying the contact with the wrong state is being 'found'? If this is the case, there is a reslution we have in our code base that will get into master later this week? If not, please can you explain the problem you are having in more detail. Cheers Jason On Tue, Nov 24, 2015 at 1:22 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
updated the subject of the email to reflect it refers to IMS extensions, which are different than the standard IETF registrars.
That makes it easier to be spotted by the people using IMS and the dev guys can shed some light on why the implemented that way.
Cheers, Daniel
On 24/11/15 11:59, Prashant Desai wrote:
Hi,
We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri.
is_registered(struct sip_msg* _m, udomain_t* _d){
getContactP(_m,_d);
}
pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {);
//Getting pcontact from source IP and port
if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) {
LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto);
}
if (c == NULL) {
//Getting pcontact from contact uri.
if (ul.get_pcontact(_d, &ct->uri, &c) == 0) {
}
}
We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success.
We would like to know reason behind comparing the source IP and port to fetch the pcontact?
Regards,
Prashant
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- *Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.penton@smilecoms.com <name.surname@smilecoms.com> www.smilecoms.com -- This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
Hi Jason, Thanks for your reply, we are facing an issue in following usecase. UE -------------------------------------------------------------------------------->PCSCF REGISTER [src ip:127.0.0.1:8008] Contact:sip:user@127.0.0.1:8008 On Tue, Nov 24, 2015 at 5:41 PM, Jason Penton <jason.penton@smilecoms.com> wrote:
Hi Prashant,
Often the P-CSCF has to know about the contact (for example for Rx QoS, security (asserting identity, etc). It is also possible that a contact header is not provided by the UE so you have no alternative but to search src info, via info, etc. So that is the main reason.
So let me understand your problem a little more. You are saying the contact with the wrong state is being 'found'? If this is the case, there is a reslution we have in our code base that will get into master later this week? If not, please can you explain the problem you are having in more detail.
Cheers Jason
On Tue, Nov 24, 2015 at 1:22 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
updated the subject of the email to reflect it refers to IMS extensions, which are different than the standard IETF registrars.
That makes it easier to be spotted by the people using IMS and the dev guys can shed some light on why the implemented that way.
Cheers, Daniel
On 24/11/15 11:59, Prashant Desai wrote:
Hi,
We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri.
is_registered(struct sip_msg* _m, udomain_t* _d){
getContactP(_m,_d);
}
pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {);
//Getting pcontact from source IP and port
if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) {
LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto);
}
if (c == NULL) {
//Getting pcontact from contact uri.
if (ul.get_pcontact(_d, &ct->uri, &c) == 0) {
}
}
We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success.
We would like to know reason behind comparing the source IP and port to fetch the pcontact?
Regards,
Prashant
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.penton@smilecoms.com <name.surname@smilecoms.com> www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Jason, Please ignore the last mail. Thanks for your reply, we are facing an issue in following usecase where UE will use a different contact as shown below in INVITE. UE ---------------------------------------REGISTER----------------------------------------->PCSCF [src ip:127.0.0.1:8008] Contact:sip:userA@127.0.0.1:8008 <http://Contact:sip:user@127.0.0.1:8008> UE ---------------------------------------INVITE----------------------------------------->PCSCF [src ip:127.0.0.1:8008] Contact:sip:userB@127.0.0.1:9000 <http://Contact:sip:user@127.0.0.1:8008> In the above scenario kamailio PCSCF is treating the UE as registered,even though the contact is different in INVITE and call will be successful. why are we not validating the contact URI in the INVITE?is it not a mandatory to validate?if yes,any spec references? Regards, Prashant On Wed, Nov 25, 2015 at 3:26 PM, Prashant Desai <pdesai05@gmail.com> wrote:
Hi Jason,
Thanks for your reply, we are facing an issue in following usecase.
UE -------------------------------------------------------------------------------->PCSCF REGISTER [src ip:127.0.0.1:8008] Contact:sip:user@127.0.0.1:8008
On Tue, Nov 24, 2015 at 5:41 PM, Jason Penton <jason.penton@smilecoms.com> wrote:
Hi Prashant,
Often the P-CSCF has to know about the contact (for example for Rx QoS, security (asserting identity, etc). It is also possible that a contact header is not provided by the UE so you have no alternative but to search src info, via info, etc. So that is the main reason.
So let me understand your problem a little more. You are saying the contact with the wrong state is being 'found'? If this is the case, there is a reslution we have in our code base that will get into master later this week? If not, please can you explain the problem you are having in more detail.
Cheers Jason
On Tue, Nov 24, 2015 at 1:22 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
updated the subject of the email to reflect it refers to IMS extensions, which are different than the standard IETF registrars.
That makes it easier to be spotted by the people using IMS and the dev guys can shed some light on why the implemented that way.
Cheers, Daniel
On 24/11/15 11:59, Prashant Desai wrote:
Hi,
We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri.
is_registered(struct sip_msg* _m, udomain_t* _d){
getContactP(_m,_d);
}
pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {);
//Getting pcontact from source IP and port
if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) {
LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto);
}
if (c == NULL) {
//Getting pcontact from contact uri.
if (ul.get_pcontact(_d, &ct->uri, &c) == 0) {
}
}
We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success.
We would like to know reason behind comparing the source IP and port to fetch the pcontact?
Regards,
Prashant
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.penton@smilecoms.com <name.surname@smilecoms.com> www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Prashant, The P-CSCF errs on the side of finding a contact. So, if you send me the logs I am pretty sure that because the contact is not found (it's impossible to be found), then P-CSCF tries to find the contact based on src IP and Port. What we can do however, is put in a limitation that if the contact header does exist (will always be in INVITE), then the P-CSCF must not fallback to use other methods to find the contact.... Does this make sense? Cheers Jason On Wed, Nov 25, 2015 at 12:06 PM, Prashant Desai <pdesai05@gmail.com> wrote:
Hi Jason,
Please ignore the last mail.
Thanks for your reply, we are facing an issue in following usecase where UE will use a different contact as shown below in INVITE.
UE ---------------------------------------REGISTER----------------------------------------->PCSCF [src ip:127.0.0.1:8008] Contact:sip:userA@127.0.0.1:8008 <http://Contact:sip:user@127.0.0.1:8008>
UE ---------------------------------------INVITE----------------------------------------->PCSCF [src ip:127.0.0.1:8008] Contact:sip:userB@127.0.0.1:9000 <http://Contact:sip:user@127.0.0.1:8008>
In the above scenario kamailio PCSCF is treating the UE as registered,even though the contact is different in INVITE and call will be successful.
why are we not validating the contact URI in the INVITE?is it not a mandatory to validate?if yes,any spec references?
Regards, Prashant
On Wed, Nov 25, 2015 at 3:26 PM, Prashant Desai <pdesai05@gmail.com> wrote:
Hi Jason,
Thanks for your reply, we are facing an issue in following usecase.
UE -------------------------------------------------------------------------------->PCSCF REGISTER [src ip:127.0.0.1:8008] Contact:sip:user@127.0.0.1:8008
On Tue, Nov 24, 2015 at 5:41 PM, Jason Penton <jason.penton@smilecoms.com
wrote:
Hi Prashant,
Often the P-CSCF has to know about the contact (for example for Rx QoS, security (asserting identity, etc). It is also possible that a contact header is not provided by the UE so you have no alternative but to search src info, via info, etc. So that is the main reason.
So let me understand your problem a little more. You are saying the contact with the wrong state is being 'found'? If this is the case, there is a reslution we have in our code base that will get into master later this week? If not, please can you explain the problem you are having in more detail.
Cheers Jason
On Tue, Nov 24, 2015 at 1:22 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
updated the subject of the email to reflect it refers to IMS extensions, which are different than the standard IETF registrars.
That makes it easier to be spotted by the people using IMS and the dev guys can shed some light on why the implemented that way.
Cheers, Daniel
On 24/11/15 11:59, Prashant Desai wrote:
Hi,
We observe that the following kamailio API is trying to find out user registration by comparing source IP and port with stored contact, if it fails, then it compares based on incoming SIP msg contact uri.
is_registered(struct sip_msg* _m, udomain_t* _d){
getContactP(_m,_d);
}
pcontact_t * getContactP(struct sip_msg* _m, udomain_t* _d) {);
//Getting pcontact from source IP and port
if (ul.get_pcontact_by_src(_d, &received_host, _m->rcv.src_port, _m->rcv.proto, &c) == 1) {
LM_DBG("No entry in usrloc for %.*s:%i (Proto %i) found!\n", received_host.len, received_host.s, _m->rcv.src_port, _m->rcv.proto);
}
if (c == NULL) {
//Getting pcontact from contact uri.
if (ul.get_pcontact(_d, &ct->uri, &c) == 0) {
}
}
We have use case where INVITE message is from same source IP and port but having unregistered contact.With this scenario,is_registered() will return success.
We would like to know reason behind comparing the source IP and port to fetch the pcontact?
Regards,
Prashant
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com Kamailio Advanced Training, Nov 30-Dec 2, Berlin - http://asipto.com/kat
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.penton@smilecoms.com <name.surname@smilecoms.com>www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- *Jason Penton**Senior Manager: Applications and Services**Smile Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:* jason.barry.pentonjason.penton@smilecoms.com <name.surname@smilecoms.com> www.smilecoms.com -- This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>
participants (3)
-
Daniel-Constantin Mierla -
Jason Penton -
Prashant Desai