<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Brian J. Murrell wrote:
<blockquote cite="mid:1207848133.3303.138.camel@pc.ilinx" type="cite">
<pre wrap="">On Thu, 2008-04-10 at 11:13 -0500, Brent Davidson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">You might also try "canreinvite=no" for both your phone and the sip
peer.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">If I'm not mistaken this
is also useful for making calls between two system that have no common
codecs.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
Let us all know how the tests go with the other phone.<br>
<br>
-Brent<br>
</body>
</html>