pjsua_call_make_call acc_id late setting bug?

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

 



On my device I configured max_calls to be 1.
I set the PJSUA_DEFAULT_USE_SRTP to be 0.
I created UDP transport, and added it local.
I them added an acount with cfg.use_srtp set to be mandatory (2).

When I make the first call, the call->acc_id selected for me is set to
0, which is the UDP account, and his use_srtp value is set to 0.
Later in the function call->acc_id is set to the correct id value, and
from the second call this value will pickup the correct account.

As mentioned before I moved the setting line to an upper place in the
function, and it looks it solves the problem.
Can anyone confirm?

> ?I worked with similar fn.And it did work, just for testing purpose I worked
> with example.com. I'm not very sure in windows mobile, accoridng to my
> script I called the fn after UDP transport and registration thing.
>
> I hope you need to call the pjsua_call_make_call after your registeration or
> media channel.
> Hope this helps!
> Rachel
>
>
> On Mon, Sep 14, 2009 at 11:28 AM, Tal Fromm <tal.fromm at gmail.com> wrote:
>
> > I'm using pjsip running with windows mobile device.
> > I've activated the SRTP feature with no SIP protection (just for testing),
> > and I found out that the first call is not set as encrypted call.
> > While going into the code it look like the line call->acc_id = acc_id
> > appears after the use of pjsua_media_channel_init which uses acc_id value.
> > I moved this line up in the code just after the call pointer gets his
> > value.
> > Is it realy a bug, or am I missing something?
> >
> > Tal



[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