Is 100 Trying Mandatory? Can Asterisk Answer With 180 Without Prior 100 Trying?

Home » Asterisk Users » Is 100 Trying Mandatory? Can Asterisk Answer With 180 Without Prior 100 Trying?
Asterisk Users 3 Comments

Hey List

I sometimes use our asterisk server to do some debugging or other PBX
and SBC.

Now we have a case where a PBX is replying an incomming invite with 180
ringing immediately. It looks like the SBC does not accept this.

According to my understanding of the RFC 3261 any provisional (aka
1XX) reply should be good enough to make the sender stop re-sending invites and accept this as a reply from the destination.

So 100 trying would be option and a reply could also be directly 180
ringing.

So maybe some RFC specialist could tell me how this is exactly supposed to work of if I maybe missed some other RFC more clear about that topic.

To try to reproduce the problem with our SBC, is there a way to tell the asterisk, preferably PJSIP, to directly answer with 180 ringing without prior 100 trying?

Mit freundlichen Grüssen

-Benoît Panizzon-

I m p r o W a r e A G – Leiter Commerce Kunden

3 thoughts on - Is 100 Trying Mandatory? Can Asterisk Answer With 180 Without Prior 100 Trying?

  • Indeed. In practice though you want to stop the retransmission immediately and you usually don’t know of the appropriate response yet so 100 is sent.

    The PJSIP channel driver has no option or ability to do this. I do not recall if chan_sip does.

  • A (very) dirty workaround would be to drop these packets with iptables
    (assuming Linux as OS), something like:

    iptables -t raw -I OUTPUT -p udp -d ipaddrofpbx -m string –algo bm –from 0 –to 32 –string “SIP/2.0 100 ” -j DROP

    Don’t try it with TCP 🙂

  • Hi Tryba

    🙂

    Indeed, this is what I did with a Mikrotik Firewall that is in front of the * Server: Drop UDP packet with content starting with “SIP/2.0
    100 Trying”

    And this showed, that not the missing 100 Trying is tripping our SBC. So I contacted the Vendor who had a quick look at the 181 Ringing which is not being relayed and found that the issue was the Contact: Header containing two line= attributes.

    So I’m now trying to contact the vendor of that other PBX to figure out, why it is sending two line= attributes as part of the contact header.

    Mit freundlichen Grüssen

    -Benoît Panizzon-

    I m p r o W a r e A G – Leiter Commerce Kunden