asterisk users - Mar 2018 - Is 100 trying mandatory? Can asterisk answer with 180 without prior 100 trying?

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
______________________________________________________

Zurlindenstrasse 29             Tel  +41 61 826 93 00
CH-4133 Pratteln                Fax  +41 61 826 93 01
Schweiz                         Web  http://www.imp.ch
______________________________________________________

On Mon, Mar 19, 2018, at 12:53 PM, Benoit Panizzon
wrote:
> 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.
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.
> 
> 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?
The PJSIP channel driver has no option or ability to do this. I do not recall if
chan_sip does.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

On Mon, Mar 19, 2018 at 12:59:47PM -0300, Joshua Colp
wrote:
> > 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?
> 
> 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 :)