Multiple INVITEs, different UDP Ports

Asterisk Asterisk Support
1

Hello,

I'm having a problem with my recent Asterisk 11.17 installation.  I have a couple Polycom phones, a couple ATAs, and softphones running on wifi tablets.  The problem is that some of the stations don't work.  Well, none of them work perfectly, but some better than others.

The one that work better miss a fraction of a second of the incoming audio, and then all is well.
The ones that work less well burp out that first fraction of a second, and then go silent, which is really limiting to their usefullness as phones.

The Asterisk is running on a Slackware Linux system which also serves as my Internet gateway/firewall machine. The telephones are all on the localnet, and the other port of the
server is directly on the real Internet.

Looking at a Wireshark trace of the external net, I see Asterisk issuing a couple of INVITE’s a tenth of a second apart - bangbang! These INVITEs specify media port 22454. The remote system then starts sending a stream of RTP packets from port 21972 to port 22454. This continues for about 30 packets. Then Asterisk issues another INVITE, specifying a different local port - this time, 16408.

The remote system then, without missing a beat, continues its RTP stream, only now to dest port 16408.

On the localnet side, RTP packets to my “good” ATA only start at 2.25 seconds into the trace. These
packets all have a sensible 164xx port numbers. It looks to me like Asterisk is eating those first
31 RTP packets ( with 22454 dest port ) and throwing them into the bit bucket.

Anybody seen similar? Mighty Google has come up dry…

            - Jerryk1234
2

When does the remote system send OK? Did the remote system send early media SDP?

Are you sure that the media destination is the same, as I can think of no reason why Asterisk would re-invite to a different port unless it was also switching to direct media.

Note: the initial double invite will be because the remote system isn’t responding fast enough, with a provisional response.

3

After the initial two INVITEs, the remote SIP server immediately sends four provisional statuses. 100, 101, 100, 101, in that order. Two seconds later, the RTP packets start from the remote telephone company, aimed at port 22454.

Just after the first RTP packet, the remote SIP system sends a status 183.

At RTP sequence #23, the remote SIP finally sends a status 200. About 200 microseconds later,
my asterisk box sends out an ACK, and 400 microseconds after the ACK, Asterisk sends an INVITE
with the new media UDP port ( in the case of the trace I’m reading now, 16408 ).

One interesting thing - on the initial INVITE on the internal net, the Polycom phone ( which only gets the initial burst of audio ), says it supports 100rel. The Linksys ATA ( which does NOT get the initial burst, but gets ALL the audio afterwards ) does NOT claim to support 100rel.

I have verified that on the INTERNAL net, the ATA ( Linksys SPA1001 ) is giving an initial INVITE with
media port 16410. So why is Asterisk then emitting an INVITE to the sip trunk with media port 22454? Is Asterisk trying to do some sort of NAT, and then thinking better of it?

The deeper I get into this, the more I think it’s a NAT issue. My thinking on NAT was fuzzy when I set this program up a few months ago - not because I don’t know NAT, but because I don’t know SIP.

I am interested in getting a precise understanding of how RTP ports are assigned and routed. Some of my devices have config settings for them - but not all. Miscellaneous questions include

  • Does Asterisk assign RTP ports to the stations, or do they “use what they want to use”?
  • Does Asterisk route the incoming RTP packets, or does it let the underlying OS forwarder do it?

In SIP.conf, I changed the NAT setting from “no” to “force_rport,comedia”. No difference.

In the meantime, I’m downloading Asterisk 13…

4

Each side assigns its own RTP port numbers, which in your terms is I think the remote station assigns them.

Asterisk relays RTP directed to it, but if direct media is enabled and various conditions are met, it will tell the remote system the address of the final destination, and the RTP may not even touch the machine running Asterisk.

nat= is various workarounds. The primary NAT settings are externhost, etc., stunaddr, and localnets.

5

The plot sickens…

Looking at a Wireshark trace on the localnet, there is:

A pair of INVITEs from the telephone to the Asterisk server. Bang-bang! You didn’t hear me, I try again!

A 100 trying from the server to the telephone
A 180 Ringing from the server to the telephone
A 200 OK from the server to the telephone
A few RTP packets from the server to the telephone
A SIP ACK from the telephone to the server.

All of this looks ordinary and understandable. Then the strangeness starts, at about
2.6 seconds into the trace…

An INVITE from the SERVER to the TELEPHONE.
Huh?

6

[quote=“jerryk1234”]An INVITE from the SERVER to the TELEPHONE.
Huh?[/quote]

A re-invite to direct media; or
connected party update; or
(less likely so soon) a session timers update.