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

[Alain RICHARD (JIRA)]

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

Alain RICHARD commented on ASTERISK-20352:
------------------------------------------

Here asterisk is just used as a SIP router, and just forwards the reply from the customer PABX (in fact a patton gateway) to the provider trunk.

It is not supposed to interpret the numbers.

In fact the PABX generates a 484 reply because the SDA is not implemented on the PABX, but this is not the subject.

The patton gateway generate an RFC3398 compliant result :

<--- SIP read from UDP:3.3.3.251:5060 --->
SIP/2.0 484 Address Incomplete
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK4acf49d4;rport=5060;received=2.2.2.2
From: "987654" <sip:987654 at 2.2.2.2>;tag=as2eff6979
To: <sip:123456 at 3.3.3.251>;tag=3169669864
Call-ID: 27f7d0e862a52b933eeaf4c357b041bd at 2.2.2.2:5060
CSeq: 102 INVITE
Server: Patton SN4638 5BIS 00A0BA06BAEF R6.1 2012-05-09 H323 SIP BRI M5T SIP Stack/4.0.30.30
Content-Length: 0


and asterisk change it to a non RFC3398 compliant result :

<--- Reliably Transmitting (NAT) to 1.1.1.104:5060 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 1.1.1.104;branch=z9hG4bK1166.4a4d19f6.1;received=1.1.1.104;rport=5060
Via: SIP/2.0/UDP 1.1.1.116:5060;rport=5060;branch=z9hG4bK-77ef-1346673299-2623-361
From: "987654"<sip:987654 at 1.1.1.116>;tag=95ffcd055e0f78f7d5d397020e89288d9808247e
To: <sip:123456 at 1.1.1.104:5060>;tag=as4447fef1
Call-ID: 2c00-4b2-832012115459-ACKBAR-0-1.1.1.116
CSeq: 1 INVITE
Server: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Reason: Q.850;cause=28
X-Asterisk-HangupCause: Invalid number format
X-Asterisk-HangupCauseCode: 28
Content-Length: 0


You'll find enclosed the full log of the exchange.


> 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