Enable ICE on account basis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hitesh,

logan wrote:
> Hi Alain,
> 
> Thanks for the response.
> 
;o)

> You are correct, it's more of a UA behaviour. We are thinking that instead
> of creating media transports (pjsua_var.calls.med_tp) during startup time,
> we create it on per call basis, i.e. create it in pjsua_media_channel_init. 
> The
> pjsua_acc_config structure will have a boolean value to tell whether ICE is
> to be used or not. Then instead of checking for the global
> media_cfg.enable_ice flag in various pjmedia API's we check for the flag
> from the account config. Not sure if this will work on out, but I'm trying
> it out.
> 
You are already on the right path...

It will certainly work that way, but the drawback is you lost the cool future 
pjsua has will preallocated and ready to use media transport etc and you 
increase your call setup time. Your UA will also be less configurable if you 
think of a feature like personal firewall with preset-ports for your application...
But that is another issue and certainly not a rocket science issue ;o)


> I would love to listen how you implemented this :).
> 
Our UA doesn't use the pjsua API.
A quick and easy way with less changes to pjsua would be a second pjsua_call 
array. There are also changes to be made to the OPTIONS module, since your UA 
MUST reply to OPTIONS request with the correct per account media transport type 
(with/without ICE)

Cheers
Alain



> 
> ----- Original Message ----- 
> From: "Alain Totouom" <alain.totouom@xxxxxx>
> To: "pjsip list" <pjsip at lists.pjsip.org>
> Sent: Tuesday, January 29, 2008 12:06 AM
> Subject: Re: Enable ICE on account basis
> 
> 
>> Hi,
>>
>> we've implement that behavior in our UA but i think it's rather an UA
>> issue than
>> a library feature. I mean it depends on the way the UA handles its
>> underlaying
>> media transport.
>>
>> If you want to implement that functionality within your pjsua derivate,
>> don't
>> forget to update the behavior of the OPTIONS module, since it WOULD/MUST
>> also be
>> account based ;o)
>>
>> Cheers
>> Alain
>>
>>
>>
>> Michael Bradley Jr wrote:
>>> logan wrote:
>>>> Hi Benny,
>>>>
>>>> We need this feature in our application ASAP. So, is there *any* way to
>>>> get
>>>> it done or it's not possible at all?
>>>>
>>> Yes, do it yourself and provide the result to the community...
>>>
>>>> Thanks.
>>>>
>>> np
>>>
>>> Michael
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>> -- 
>>                             ""
>>                           (o)(o)
>>                   ___o00o__(__)__o00o_____
>> 1024D/A9F85A52 2000-01-18 Dipl.-Ing. Alain Totouom <totouom at gmx.de>
>> PGP Fingerprint   DA18 0DF2 FBD2 5F67 0656 452D E3A2 7531 A9F8 5A52
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> 
> 
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
> 
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> 

-- 
                             ""
                           (o)(o)
                   ___o00o__(__)__o00o_____
1024D/A9F85A52 2000-01-18 Dipl.-Ing. Alain Totouom <totouom at gmx.de>
PGP Fingerprint   DA18 0DF2 FBD2 5F67 0656 452D E3A2 7531 A9F8 5A52



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux