I am also fighting the same problem as Gabriel -i.e., I can't get a call from 
outside to forward back to the outside on Speakeasy's SIP trunks.

I wrote to Speakeasy asking them if they support P-Asserted-Identity. Here is 
the answer I got:

****
We do not support P-Asserted Identity at this time. We are currently using 
Remote Party ID for privacy.

The FROM field of the SIP INVITE must be a registered phone number or provide 
Remote Party ID. This also applies for any call forwarding, blind xfrs, etc. 
Many IP-PBXs may not support Remote Party ID, in which case it's suggested you 
use a Caller ID override.
****

Any ideas on what we could do to get our forwards to work?

Thanks

On Jan 25, 2010, at 7:54 AM, M. Ranganathan wrote:

> 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/

Reply via email to