[asterisk-bugs] [JIRA] Commented: (ASTERISK-20352) Incorrect handling of SIP 484 Address incomplete

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196544#comment-196544 ] 

Matt Jordan commented on ASTERISK-20352:
----------------------------------------

Exactly what David said.

You can relay a 484 back to the original UA by inspecting the HANGUPCAUSE and by careful usage of the Incomplete application.

> Incorrect handling of SIP 484 Address incomplete
> ------------------------------------------------
>
>                 Key: ASTERISK-20352
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20352
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.15.0, 1.8.15.1
>         Environment: Linux with asterisk 1.8.15.0
> SIP provider trunk
> SIP consummer trunk
>            Reporter: Alain RICHARD
>         Attachments: ASTERISK-20352 log
>
>
> In my setup, asterisk is used only as a SIP router between a provider and a consummer.
> On an incoming call (from the provider to the consumer), if the consumer trunk return a SIP 484 Address incomplete (q.850 code 28), the error is forwarded by asterisk to the provider trunk as a SIP 503 Service unavail, although the included q.850 code is 28.
> This is a violation of RFC 3398 :
>    Response received                     Cause value in the REL
>    -----------------                     ----------------------
> ...
>    484 Address incomplete                28 Invalid Number Format (+)
> ...
> The problem is 100% reproductible. With the following code :
> sip.conf :
> [general]
> use_q850_reason=yes
> [provider]
> context=fromprovider
> [consumer]
> extensions.Conf :
> [fromprovider]
> exten => _123456,1,Nop(Call the consumer)
>     same => n,Dial(SIP/${EXTEN}@comsumer)
>     same => n,Verbose(2,DIALSTATUS = ${DIALSTATUS})
>     same => n,Verbose(2,HANGUPCAUSE = ${HANGUPCAUSE})
> When the call is coming, I get the following process :
> 1 Call is ringging from provider to consumer
> 2 Consumer returns a SIP 484 Address incomplete
> 3 The verbose output shows : DIALSTATUS=CHANUNAVAIL, HANGUPCAUSE=28
> 4 asterisk returns to the provider : 503 Service unavailable, q.850 code=28
> So here it seams to be at least two error :
> - On step 4, the returned code for HANGUPCAUSE 28 to the provider is SIP 503 instead of SIP 484 as requested by RFC 3398.
> - On step 3, the DIAL app should have returned DIALSTATUS=CONGESTION instead of CHANUNAVAIL
> I have succeed to implement a counter measure :
> exten => _123456,1,Nop(Call the consumer)
>     same => n,Dial(SIP/${EXTEN}@comsumer)
>     same => n,Verbose(2,DIALSTATUS = ${DIALSTATUS})
>     same => n,GotoIf($[${HANGUPCAUSE}=28] & $[${DIALSTATUS}!="CONGESTION"]?setcongestion:continue)
>     same => n(setcongestion),Set(DIALSTATUS="CONGESTION")
>     same => n,Verbose(2,DIALSTATUS = ${DIALSTATUS})
>     same => n(continue),Verbose(2,HANGUPCAUSE = ${HANGUPCAUSE})
> In that case, the provider will receive the correct SIP response (SIP 484 and q.850 code 28).
> I don't know if the problem is within dial_app, chan_sip or on the generic handling of HANGUP CAUSE 28, but this violate the RFCs.
> Regards,
> Alain RICHARD
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira