[Asterisk-Users] Asterisk behind LinkSys NAT Routing

[Rich Adamson]

> > I don't think that is what keeping the original poster's system from
> > working. The issue is "one" extension is configured for canreinvite=no
> > and the other is canreinvite=yes. One extension believes all RTP must
> > be passed through * while the other is attempting to negotiate a
> > phone-to-phone RTP session, thus dropping the audio. 
> 
> Are you sure this is 100% correct? I have some doubts since:

No, not sure at all as there isn't enough actual data in the original
posters message to qualify the root-cause.

> - you'd have to consider all possible connection permutations between all 
> clients and then set canreinvite= accordingly, which doesn't sound like 
> it makes much sense

Given the original data, the permutations is two extns, nothing more. One
inside and one outside.
 
> - sip.conf is for * only, the data are not seen or read by the SIP UA 
> themselves. Thus it would appear that it is up to * to permit/not permit 
> a reinvite between the two UAs
> 
> So bascially from my understanding things work like this: Once one of the 
> SIP call parties has a canreinvite=no it won't matter what the other 
> party's setting looks like, RTP traffic will travel through * anyway.

Don't believe that understanding is correct. Assuming no parameters within
the * sip.conf to suggest otherwise, when phone #1 calls phone #2 asterisk
initiates the call by communicating with the "caller" (phone #1). 
The caller starts the RTP-port-negotiation process with phone #2. If 
phone #2 calls phone #1 and fails (which was the case stated by the 
poster based only on my memory, which could be wrong), the problem is 
pointing directly to the differences within the extn definitions in 
sip.conf. One phone is told to negotiate directly with the second
phone (within asterisk), and the second phone is told not to negotitate
the rtp channel within asterisk. Since the nat device is "only one way"
communications, what fails? RTP.