[Asterisk-Users] functional difference: canreinvite=yes, no, or update

[Kevin P. Fleming]

Matthew Boehm wrote:
> Can anyone give an example of the difference between the following:
> 
> canreinvite=no
> canreinvite=yes
> canreinvite=update

I'll try, but this particular option gets my vote as the worst-named 
configuration option in all of asterisk.

First, this option does absolutely nothing to stop the SIP peer from 
sending re-INVITE if it should decide it wants to. In addition, it does 
not stop Asterisk from sending re-INVITE for any purpose _other than_ 
media path redirection. Finally, it does _not_ control whether _this_ 
peer will be asked to re-INVITE For media path redirection.

Isn't that great?

Now, on to the choices:

- canreinvite=no

This means that this SIP peer is not able to receive direct RTP media 
from any other peer, regardless of IP address or network route.

- canreinvite=yes

This means that this SIP is _always_ able to receive direct RTP media 
from any other peer, regardless of IP address or network route.

- canreinvite=update

This is identical to "yes", except that the SIP UPDATE method is used to 
update the existing dialog, rather than INVITE. This is not commonly 
supported (I don't think Asterisk even supports incoming UPDATE), but is 
less resource intensive. This choice should not even exist; Asterisk 
should choose to use INVITE or UPDATE based on the Allow header 
presented by the peer, but that's the way it is right now (Olle has 
already said he doesn't like it being this way).

> My phone rings and I answer it. Asterisk tries to re-invite the call
> (because I have this phone set to canreinvite=yes). The reinvite succedes
> but it invites with the internal IP of my phone. So I can't hear the other
> person. They can hear me fine.

Yes, this is a common problem. With your phone set to "canreinvite=yes", 
Asterisk is sending a re-INVITE to the provider's SIP server, asking it 
to send the RTP media directly to your phone. It invites with the 
internal IP of your phone because that is all that Asterisk has ever 
seen from that phone during that dialog (and all it should be expected 
to see). Even if Asterisk could somehow determine what the external IP 
address and port number of your phone might be (which is impossible), a 
re-INVITE to that IP/port would still fail, because whatever firewall 
you are using would not allow the incoming traffic.

In other words, canreinvite=yes (or =update) can only be used in very 
well controlled environments, where you know what paths the RTP media 
may want to take. It cannot be used across firewalls or NATs except in 
very rare cases (primarily the ones that actually monitor the SIP 
traffic, since they can open up the ports needed).

I have a patch in my local system that allows the canreinvite setting 
(which I renamed) to actually be based on IP address masking, so that 
Asterisk can make a more intelligent decision, but even that has 
problems, because we don't actually _know_ that any given IP route is 
available.