[OpenSIPS-Users] Have one registration contact per device in usrloc

Yuming Zheng zhengyumingnanjing at gmail.com
Fri Oct 10 03:46:38 CEST 2014


Yes ,GRUU can solve this situation.
So, is there any similar mechanism with presence info to only keep the
latest presence status of the same register.

BR,

Frank.zheng

2014-10-09 18:32 GMT+08:00 Bogdan-Andrei Iancu <bogdan at opensips.org>:

>  Hi Jayesh,
>
> Maybe you should look into GRUU stuff ;).
>
> On the TCP error - even if you set the TCP persistence flag, the UAC may
> close the TCP conn -> you end up in the same situation. What you can do is
> to prevent OpenSIPS to open TCP conns when routing to end-users - the idea
> is to have end-users connecting to OpenSIPS and not the other way around.
> See "tcp_no_new_conn_bflag" :
>     http://www.opensips.org/Documentation/Script-CoreParameters-1-11#toc96
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 08.10.2014 17:31, Jayesh Nambiar wrote:
>
>   Hi Bogdan,
>  So I thought of doing this and I have another problem. Say if a device
> registered from IP 1.2.3.4, and then moved out to different network and
> re-registered from IP 4.3.2.1, there is a stale registration lying in
> opensips for the same device from 1.2.3.4.
>  Now when I use TCP as transport, opensips waits till connect timed out on
> unreachable IPs before sending the call to registered contact and the
> following messages are logged in syslog:
> ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
>  ERROR:core:tcpconn_connect: tcp_blocking_connect failed
>  ERROR:core:tcp_send: connect failed
>  ERROR:tm:msg_send: tcp_send failed
>
>  Looks like opensips tries to do a TCP connect first with all registered
> contacts before actually routing the call.
>  I do,
> modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT")
>
> if(is_method("REGISTER")) {
> setflag(TCP_PERSISTENT);
>         setbflag(30);
>         if(!save("location", "fc1")) {
>                 t_reply("500", "Error while saving AOR");
>         }
> }
>
>  --- Jayesh
>
>
>
>
>
>
> On Wed, Oct 8, 2014 at 3:10 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>>  Hi Jayesh,
>>
>> Basically you do not what to have more registrations from the same IP,
>> right ?
>>
>> Exactly the opposit of the is_other_contact() function :
>>
>> http://www.opensips.org/html/docs/modules/1.11.x/registrar.html#id294660
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>  On 01.10.2014 18:15, Jayesh Nambiar wrote:
>>
>>     Hi,
>>  I am trying to solve a problem of having one registration per AOR per
>> device. So user 1234 can register from device A, device B and device C. But
>> the user 1234 should not have multiple contacts from device A alone.
>>  At times when the device loses network, proxy doesn't receive
>> de-register and the contact stays in opensips till its expiry time. So the
>> same device is thus capable of creating multiple contacts. I could solve
>> this by using "fc1" flag while doing a save("location") but I need multiple
>> registrations to be allowed from different devices !!
>>  So is there a way where while doing a save("location"), I set some sort
>> of device id along with it such that I identify and overwrite the existing
>> contact only if the registration comes from same device-id or else add it
>> up for parallel forking.
>>  Do let me know if I make sense here and there's a solution to this.
>> Thanks for any suggestions and directions.
>>
>> Thanks,
>>
>>  --- Jayesh
>>
>>
>>  _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20141010/dfb2b1eb/attachment-0001.htm>


More information about the Users mailing list