Brian J. Murrell wrote:
On Thu, 2008-04-10 at 11:13 -0500, Brent Davidson wrote:
You might also try "canreinvite=no" for both your phone and the sip
peer.
Yeah, there is definitely no re-inviting going on. Both Asterisk and
the local handset are in a local network behind NAT with reference to
the SIP server that requires INFO.
I think it's normal procedure for Asterisk to drop out of the
call path once the call is established between two peers. The
canreinvite directive forces asterisk to remain as an intermediary, and
it will probably do the transcoding that way.
Indeed, this is my understanding as well, but I am definitely not
getting a bridging of the sipphone and sip provider through a re-invite.
The NAT would not facilitate it.
If I'm not mistaken this
is also useful for making calls between two system that have no common
codecs.
Right.
I need to use ekiga or one of the ATAs here that I know support rfc2833
so that I can eliminate this possible need to transcode inband to
info/rfc2833 in order to narrow down the field.
b.
One more tidbit I just ran across in the upgrade.txt file, since you
mention NAT: In 1.4, you need to set canreinvite=nonat to disable
re-invites when NAT=yes. This is propably what you want. The settings
are now: "yes", "no", "nonat", "update". Please consult sip.conf.sample
for detailed information.
Let us all know how the tests go with the other phone.
-Brent
_______________________________________________
-- 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
