[SR-Users] Kamailio IMS: Contact validation during INVITE
Jason Penton
jason.penton at smilecoms.com
Wed Nov 25 11:17:13 CET 2015
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 at 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 at 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 at 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 at 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 at 127.0.0.1:8008
>>
>>
>> On Tue, Nov 24, 2015 at 5:41 PM, Jason Penton <jason.penton at 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 at 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 at 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 at 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 at smilecoms.com
>>> <name.surname at 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 at 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 at 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 at smilecoms.com <name.surname at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151125/b10725d7/attachment.html>
More information about the sr-users
mailing list