To re-INVITE or not to re-INVITE that's the question.

THE PROBLEM

1.- User Agents notify SIP signaling out of the Carrier's scope.

We're not interested in new “Sussie” end point. I'm the Carrier, I have no display nor I cannot guarantee displaying it in the other side too.

2.- SIP messages not attended by the Carrier hang up the phone call.

Most of them related to PBX Universe signaling: NOTIFY, SUBSCRIBE, MESSAGE, OPTIONS, UPDATE...

3.- Flooding the Carrier may ban your IP.

Is it necessary to be informed of new 10 paralell ring group endpoints on same milisecond?

1.- USER AGENTS NOTIFY SIP SIGNALING OUT OF THE CARRIER'S SCOPE

Carriers we suffer this issue when we're noticed about PBX's internal SIP signaling as:

• Call transfers, Call forward, Serial ring group new end points...

• These messages are implemented over re-INVITE SIP messages which are attended to be compliant to RFC3261 but which are unnecessary and overload our network and also our interconection carriers.

Where is the problem?

• Every time you re-INVITE you also send us a new audio/RTP endpoint, which has to pass over a NAT and probably an ALG. You open the possibility of a one way audio issue.

• Imagine you and 100 thousand User Agents do the same you open the possibility occasionally not to be attended and because of this you loose your audio/RTP.

• You can also change your new end point codec which could be no compliant.

Not worth it

2.- SIP MESSAGES NOT ATTENDED BY THE CARRIER HANG UP THE PHONE CALL

What do you expect from a Carrier?

• We're supposed to complete phone calls “from and to” PSTN network.

• We're supposed to do it with reliability, speed, scalability, interoperability and most important: cheap.

• There're lots of RFCs involved on VoIP. Carriers try to reduce this set to a minimun: RFC 3261 to guarantee interoperability between us.

• We cannot afford attending PBX messages because it constrains speed, if we try to attend everything we should have a enourmous and complex platform which brokes scalability and cheap prices.

• As we know in Telecomm and Systems world the bigger the infraestructure the higger the probability of having points of fail which brokes reliability.

• Your PBX tries to SUBSCRIBE to be NOTIFIED about services, but we're not your FREPBX nor WHATSAPP SERVICE.

• That's why we should not attend other traffic than: REGISTER, INVITE, and BYE.

• And that's why we discard PBX messages: NOTIFY, SUBSCRIBE, MESSAGE, OPTIONS, INFO, UPDATE....

• Should be necessary to attend UPDATE method? Only in some circunstances but not as most User Agents expect, “open bar”.

When we discard with “405 Method not Allowed”It depends on SIP method and final User Agent if it hang ups the phone call but it's a problem we're watching more and more.

3.- FLOODING THE CARRIER MAY BAN YOUR IP

We don't really kown the truth of flooding, we guess some:

• Maybe the kind of policy several manufactures implement: subsubsubsub-Imean-subcontracting, developing under drugs influence, every developer in love with Sussie...

• It's not OK to send your re-INVITEs about new Sussie end point, it's not OK to send us an UPDATE to do that, but what we finally don't understand is why you send us 10 times per second. Even if our SkylinePBX is also in love...

What happens then? We ban your IP.

• You cannot make more calls until you're unbanned, we can say 5',10'...

• 23 seconds after being banned you send us a REGISTER which fails, so now you cannot receive calls for next hour.

Please avoid re-INVITE nor UPDATE because you don't know if your PBX has been developed under uncertain conditions.

ASTERISK WITHOUT RE-INVITES

Because we think before we die we should do something for a better world (really I hope this changes my karma with Sussie) we've prepared a short guide to avoid re-INVITEs nor UPDATEs to Carriers on Asterisk PBXs.

• First of all, this has been possible with the help of Gorka Gorrotxategi from Irontec Company.

• Second, we avoid any security meassure, it's out of the scope of this document.

• Well, there is a keyword in Asterisk: “sendrpid”. Its purpose is to send or not to send the conventional “callerid”. You can find it on sip%.conf

• There're several RFCs involved on pointing “callerid” on SIP protocol. Possible headers are: From, Remote-Party-Id, P-Preferred-Id, P-Asserted-Id.

• In Asterisk you can point your callerid setting with “sendrpid”[yes|no|pai|rpid].

• If we set “sendrpid=no” Asterisk avoids re-INVITE the Carrier but also implies not send any callerid header. What to do?

• Gorka told me the answer, try to configure 2 trunks, one for inbound calls and the other one to outbound calls.

• Inbound trunk with sendrpid=no and directmedia=no

• Outbound trunk with sendrpid=pai and directmedia=no

• The other keyword in Asterisk is “directmedia” which configures RTP direct between end points on a trapezoidal scheme.

• “directmedia=no” avoids to connect directly both RTP endpoints.

Let's rock (see AsteriskWithoutReInvites.pdf)

SUMMARY

There are lots of RFCs on VoIP Universe but not a Orchestra Director who joins all of them and says when and how to use them. I mean: with common sense.

We're converging now, carriers, manufacturers and users, step by step.

On the road:

• You'll loose some phone calls.

• You'll change your Carrier a million times.

• You'll complete lots of phone calls on your mobile phone.

• You'll change your PBX and Telecomm staff a thousand times.

• You'll try to decipher the voice of your telephone call partner while you're watching a Netflix movie.

• Hope you'll trust our company to make this pain a little bit more light.