asterisk users - Feb 2005 - functional difference: canreinvite=yes, no, or update

Can anyone give an example of the difference between the following:

canreinvite=no
canreinvite=yes
canreinvite=update

Here is the problem: I have an 800 number sent to me via SIP from a national
carrier. Asterisk gets the number and rings my desk phone. Asterisk has 2
NICs, one with public IP and private IP. My phone is on private IP, the
inbound call is on public.

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.

Is there no way for asterisk to check this before hand? I have no problems
making outbound calls. Even outbound calls to other SIP UAs both in and
outside private networks work fine. The only problem is on this inbound
call.

Thanks,
Matthew

Have you tried canreinvite=no?  I have a like config and my phones on
the private lan work fine in both directions.  i don't even have the
canreinvite directive in my config...


On Thu, 17 Feb 2005 16:54:49 -0600, Matthew Boehm <mboehm@cytelcom.com>
wrote:
> Can anyone give an example of the difference between the following:
> 
> canreinvite=no
> canreinvite=yes
> canreinvite=update
> 
> Here is the problem: I have an 800 number sent to me via SIP from a
national
> carrier. Asterisk gets the number and rings my desk phone. Asterisk has 2
> NICs, one with public IP and private IP. My phone is on private IP, the
> inbound call is on public.
> 
> 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.
> 
> Is there no way for asterisk to check this before hand? I have no problems
> making outbound calls. Even outbound calls to other SIP UAs both in and
> outside private networks work fine. The only problem is on this inbound
> call.
> 
> Thanks,
> Matthew
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@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
>

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.

>
> From:
> "Kevin P. Fleming" <kpfleming@starnetworks.us>
> Date:
> Fri, 18 Feb 2005 09:04:35 -0700
>
> To:
> Asterisk Users Mailing List - Non-Commercial Discussion 
> <asterisk-users@lists.digium.com>
> Olle E. Johansson wrote:
>
>> Actually, we could solve Matthew's problem by checking the IP
addresses
>> against the localnet setting and checking if both phones are on the 
>> same side. If both are within the localnet, we can reinvite. If both 
>> are on public side, we can reinvite. But if one is localnet and one 
>> is public, we could automagitically disable reinvite.
>
>
> Yes, that is a start. As long as you are comparing the
"perceived"
> addresses (which I know you would be, I'm just clarifying for others 
> who are reading this thread), that will work, because it won't matter 
> what private addresses the remote peers may be using behind their NATs.
>
> It will still break in bizarre routing scenarios, but people who build 
> those networks are used to dealing with stuff like that.
>
>> This should really be the default behaviour if canreinvite=yes and
>> localnet is set to something.
>
>
> Agreed.
Kevin,
what about letting this logic be followed by a dialplan macro that gets 
called to make the decision. May sound weird but we have a 'network-id' 
attached to each sip-user.  That network-id contains the public fixed-ip 
of the users network plus a unique name. If the network id's is matching 
and both users are on their 'home-network' then we do re-invite. This 
allows us to deal with special cases where people are behind 
double/triple nat a.s.o. . In other words it allows the Asterisk user to 
overrule the default behavier.  It's allows us (as an  ITSP) todo a safe 
re-invites on known networks to save on customers (and our) bandwith. 
Our hack is really ugly and it would be a like a dream to have this 
stuff in CVS.
Freddi    




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 14-02-2005

<snip>
> I don't think it would be logical (or efficient) have this run in a 
> dialplan macro at all; that would require creating a channel, copying 
> variables into it, etc.
>
> I have been thinking about extending the Asterisk expression evaluator 
> to allow it to call out to res modules to do the evaluation (passing 
> in the channel variables as entities or something)... this would allow 
> you to use res_perl or a future res_python or something to do more 
> complex data manipulation.
>
> However, even that is only a small part of the solution, since 
> chan_sip treats all this information as static right now, and 
> extending it to support a dynamic result would take some work.
Kevin,
You're right about the dialplan macro, being able to use res_perl would 
be a much better solution. I think that one the most important thing 
here is to realize that we can't build (hardcode) a safe logic into 
asterisk that automagically handles all nat/re-invite issues, so there 
should be some way that users under some script control dynamically can 
decide if its safe to re-invite. If you look at this list over the that 
year then there has been an almost countless number of attempts to 
describe a safe scenario to use re-invite (like: if both users behind 
same public ip then allow reinvite), and then someone else is pointing 
out that it won't work in this or that scenario. So I think that it show 
that this logic should be controllable by users who might have 
additional knowledge about their network and therefore being able to 
decisions that might not work in other scenarios. We could have some 
'default rules' which experienced user can modify (without going to the 
c-code).
Freddi



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 14-02-2005