[asterisk-users] insecure=invite - not working for different dial plan

[uzzi]

Order of configurations does make a difference so you may want to try with
the same order as the one that works. Saw it on the voip-info.org wiki
somewhere, but can't get you the link at the moment.

In general, if you will be authenticating based on IP, you should leave
username/secret out.

Some more advanced users can correct me if I'm wrong.




On Sun, Feb 14, 2010 at 7:35 PM, Joseph <syscon780 at gmail.com> wrote:

> I'm using  "insecure=invite" with two different dial plans, it it working
> with one dial plan but not with the other.
> What other parameters could influence "insecure=invite"
>
> In sip.conf below "insecure=invite" is working OK
> [pstn-1270]
> type=friend
> secret=spa3k
> username=voice-1270
> mailbox=369
> host=dynamic
> insecure=invite
> canreinvite=no
> disallow=all
> allow=ulaw
> allow=alaw
> nat=no
> context=incoming
> callgroup=1
> pickupgroup=1
>
>
> In sip.conf below "insecure=invite" is NOT WORKING
>
> [pstn-4444]
> type=friend
> secret=256
> insecure=invite
> username=voice-4444
> mailbox=622
> context=incoming
> host=dynamic
> canreinvite=no
> disallow=all
> allow=ulaw
> allow=alaw
> nat=no
> callgroup=1
> pickupgroup=1
>
> Both dial plan loaded on the same asterisk using the same Audiocodes MP-114
> What other variable would influence operation of  "insecure=invite" ?
>
> With the dial plan that  "insecure=invite" is not working, asterisk logs
> show:
> "... username mismatch, have <4>, digest has <pstn-4444>
> handle_request_invite: Failed to authenticate user "KMIEC J"
>
> --
> Joseph
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100216/66f1b1a4/attachment.htm