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

[Matthew Boehm]

Would there be a way to patch "canreinvite" so that if it detects that your
phone is on RFCXXXX address space (I forget the actual RFC number, but it
defines the 10.*, 192.168.* and 2 others i believe) then it will not send
the reinvite; unless the other end is also in same address space?

And when I say "would there be a way", I actually mean "would this be
something worthwhile to add"?

Thanks Kevin,
Matthew

----- Original Message ----- 
From: "Kevin P. Fleming" <kpfleming at starnetworks.us>
To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users at lists.digium.com>
Sent: Thursday, February 17, 2005 8:24 PM
Subject: Re: [Asterisk-Users] functional difference: canreinvite=yes, no,or
update


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