On Mon, Jan 25, 2010 at 4:34 AM, gabriel <g...@bayintegrated.net> wrote: > > I have the following problem with the call fwd. > > If I set up a user so that the calls to his extension gets fwded to his > cell, that feature works only when dialing from other extensions. In that > case it works as designed and the cid received is the correct one (the cid > assigned to the internal user that originally called) > > After reading the very good doc it appears that it has to do with > P-Asserted-Identity, (sipx tries to fwd the incoming caller ID out to the > sip trunk and the ITSP doesn't accept/doesn't know how to handle it) > > so the q is if I uncheck "Use default asserted identity " then I am not > sure what am I supposed to use in the "Asserted identity" field (having > speakeasy as ITSP) > > is there another way to fix this ? I should say that I have a default > caller ID enabled for the SIP trunk to be used in the case that an > internal user calling out doesn't have one assigned > > is it really that they don't support this or am I doing something wrong ? > > -gabriel
You can try leaving P-Asserted-Identity blank and deselect "use default asserted identity". In that case the P-A-I header will not be used. Ranga > > > > On Sun, 24 Jan 2010, Pizza Napoletana wrote: > >> On Jan 24, 2010, at 6:52 PM, M. Ranganathan wrote: >>>> But Speakeasy gave me a whole bunch of parameters when they provisioned >>>> the trunks. Here is what they gave (which I think is for asterisk): >>>> ... >>>> insecure=very >>> No idea what "insecure=very" means but that does sound frightening. :-) >> >> Per * doc, "insecure=very" means "To allow registered hosts to call without >> re-authenticating". >> >>>> qualify=no >> >> Per * doc, qualify=yes means * will send a SIP OPTIONS command every few >> seconds to check that the device is still online. >> >>>> type=peer >> >> Per * doc, "type=peer" means a SIP entity to which Asterisk sends calls >> (versus a "user" who receives calls, or a "friend" that does both). >> Confusing to me! >> >>> Try a few call flows. I suspect these are not relevant. If in and >>> outbound calling are working then chances are that you are OK. >> >> Great. Thanks. I'll do some rigorous testing tomorrow. >> >> >> _______________________________________________ >> sipx-users mailing list sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> > _______________________________________________ > sipx-users mailing list sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > -- M. Ranganathan _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
