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 <pdesa...@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 <pdesa...@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.pen...@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 < >>> mico...@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-us...@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.pen...@smilecoms.com >>> <name.surn...@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.pen...@smilecoms.com <name.surn...@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
