[asterisk-users] Linksys SPA-942 + Asterisk 1.2.10 = Inability
to transfer calls
Alberto Sagredo
asagredo at peoplecall.com
Wed Sep 6 13:53:07 MST 2006
I use canreinvite=yes in my config files, and it does work, so maybe its
a spa 941 misconfiguration.
I think if nat=no sometime it has problems if you are behind NAT, but
under same network it must not fail.
Which firmware are you running on spas?
Dan Serban escribió:
> Alberto Sagredo wrote:
>
>> I have 30 SPA 941 phones with Asterisk 1.2.7.1 and 1.2.9 and it works
>> fine. Are you canreinvite=yes ?.
>>
>> I have not been notice any problem related to transferring calls (blind
>> and attended)
>>
>>
>
> Thank you for your response, it gave me a nudge to check the
> configuration in the sip.conf file. It seems that if I set
> canreinvite=no for every SIP peer, it works!
>
> And I have found no other adverse effects. Strange issue...
>
>
>> Regards
>>
>> Dan Serban escribió:
>>
>>> I have a system running Asterisk 1.2.10 (Debian packaging) and about 50
>>> Linksys SPA-942 phones, after the initial config and mass deployment of
>>> the phones everything looks like it's configured well.
>>>
>>> When an incoming call is answered and then attempted to be "xfer'ed" via
>>> the soft button on the phone itself, it seems that if you hit the button
>>> twice in quick succession, there is no problem (effectively a blind
>>> transfer), if then I try to tell the other extension that "Joe is
>>> calling to sell you a fridge" and hit xfer, the calling party cannot
>>> hear what that person at the extension is saying. Sometimes the tables
>>> are fully turned, the caller can hear, but the operator can't hear a
>>> thing.
>>>
>>> One thing's for sure, if you hit the button quickly (blind transfer) it
>>> works no problem at all.
>>>
>>> This is what I see asterisk saying when I transfer the call
>>> unsuccessfully.
>>>
>>> == Spawn extension (macro-stdexten, s, 1) exited non-zero on
>>> 'SIP/82-006d42a0<ZOMBIE>' in macro 'stdexten'
>>> == Spawn extension (macro-stdexten, s, 1) exited non-zero on
>>> 'SIP/82-006d42a0<ZOMBIE>'
>>>
>>> I've looked at the macro with a fine tooth comb, I cannot see any
>>> problems with it whatsoever, (though that doesn't mean that my ignorance
>>> isn't getting in the way).
>>>
>>> I found some mention on the digium mantis bug tracker, here's the link:
>>>
>>> http://bugs.digium.com/view.php?id=7421
>>>
>>> Before I try and patch the source (which I'm hesitant to do since I run
>>> the debian packages), is there another solution or maybe an unidentified
>>> issue that I haven't been able to decipher?
>>>
>>> If there's more information that I can provide to solve this problem,
>>> I'd be happy to do so.
>>>
>>> Thank you.
>>> _______________________________________________
>>> --Bandwidth and Colocation provided by Easynews.com --
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>>
>>>
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
More information about the asterisk-users
mailing list