[asterisk-dev] canreinvite=no behaviour changed between 1.2.x and 1.4 ?

[Luigi Rizzo]

After upgrading to trunk from 1.2 i had a strange problem of
one-way audio on incoming calls from provider1 (but not from provider2)
to a local phone.

Quite a bit of investigations (full description below) made me think that on 1.4 the
"canreinvite=no" is honored only for calls coming from the device to asterisk,
whereas on 1.2.x it was used in both directions.
So i wonder, do i understand well, and is the change intentional ?
It doesn't make any sense to me to differentiate the behaviour basing
on the originator of the call, because you still have media
flowing in both directions in both cases.

	cheers
	luigi

--- problem description -----

An asterisk box has a local phone (SIP/552) on a 10.x address (the box is multihomed),
configured with nat=yes (should not be necessary) and canreinvite=no
(this is necessary). It is also connected to two providers using public
IP addresses. There is no "canreinvite" line on them so we follow
the default (yes).

        10.x     +-----------+  public IP       x.x.21.38
     [SIP/552]---|  asterisk |---------------[provider1]
                 |           |  public IP
                 |           |---------------[provider2]
                 +-----------+

The problem: using asterisk-trunk, calls from provider1 to the local phone give one way audio
(only going out). Using asterisk-1.2.x, same config, all works.
Everything works fine (both with trunk and 1.2.x) when the call is coming from provider2, or
when the call is originated by the local phone.

After wasting much time thinking of a bug in the media conversion, i figured out
that on Trunk, we have this sequence of messages

    [1] provider 1 calls asterisk
    <--- SIP read from x.x.21.38:5060 --->
        INVITE sip:21611 at x.x.9.236 SIP/2.0^M

    [2] call forwarded to the phone
    <--- Reliably Transmitting (NAT) to 10.216.1.88:12359: --->
        INVITE sip:552 at 10.216.1.88:12359;user=phone SIP/2.0
        ...
        o=root 66694 66694 IN IP4 10.216.1.1

    [3] the phone says ok
    <--- SIP read from 10.216.1.88:12359 ---> (this is the
        SIP/2.0 200 OK^M
        ...
        o=552 8000 8000 IN IP4 10.216.1.88

    [4] and in turn asterisk says ok to provider1
    <--- Reliably Transmitting (no NAT) to x.x.21.38:5060 --->
        SIP/2.0 200 OK
        ...
        o=root 66694 66694 IN IP4 10.216.1.88

Note the address in message [4] is still the original 10.x, which
confuses provider1 (an asterisk box, not sure which version)
and in fact i don't see data coming back.

With the same setting in 1.2, the first three messages are the same,
but the fourth one has

        o=root 66731 66731 IN IP4 x.x.9.236

i.e the address is correctly remapped to the one used to talk to provider1.

provider2 (still an asterisk box as far as i can tell, at least for
the SIP part) happens to work in this setting because it is probably
smarter and ignores the 10.x address in the o= line replacing it
with the source IP for the SIP message.

Note that calls originating from SIP/552 go out just fine, so
clearly the canreinvite=no is honored on that direction.

As a fix i put "canreinvite=no" also on the line connecting to provider1.

However, i am a bit surprised that the "canreinvite" setting
(on the phone's side) is not used for calls going to the phone.

------- end of problem description ------------------