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

[Alain RICHARD (JIRA)]

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.1, 1.8.15.0
         Environment: Linux with asterisk 1.8.15.0
SIP provider trunk
SIP consummer trunk
            Reporter: Alain RICHARD


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