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.
_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
