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

Alain RICHARD (JIRA) noreply at issues.asterisk.org
Wed Sep 5 08:22:07 CDT 2012


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

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

Hi,

I have investigated a little bit more the problem and it seams it has nothing to do with Address incompletes or a bad usage of asterisk as a SIP router.

I have successfully reproduced the problem with the following scenario :

- asterisk is used as an IPBX
- phone1 is a SIP phone
- provider is a SIP provider

Process :

1 - phone1 calls 00444518779. The first 0 is for line access.
2 - asterisk send this to the SIP provider (Dial(SIP/${EXTEN:1}@provider)
3 - The provider tries to reach the called number, but this one is non existant and the provider return SIP 404 Not Found, q850 cause=1
4 - Asterisk returns to phone 1 a SIP/2.0 503 Service Unavailable; q850 cause=1

I think this is a perfect usage of asterisk as a PABX, and asterisk generates a SIP reply that is not compliant with RFC3398 :

SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 195.189.65.250:51023;branch=z9hG4bK-d8754z-b84080c4add209f5-1---d8754z-;received=192.168.240.34;rport=51023
From: "0000FFFF0002"<sip:0000FFFF0002 at 192.168.240.251;transport=UDP>;tag=eaa14d45
To: <sip:00444518779 at 192.168.240.251;transport=UDP>;tag=as10aad6d8
Call-ID: MTUzZjVlNGQ1YTNlNmU1OTU1ZGQ4YzE4Y2IxZWJlMTI.
CSeq: 2 INVITE
Server: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Reason: Q.850;cause=1
X-Asterisk-HangupCause: Unallocated (unassigned) number
X-Asterisk-HangupCauseCode: 1
Content-Length: 0
 

I am not accustomized with the asterisk developpment process, so please if this is not the right place to discuss this issue, on which list should i submit this ?

Regards,




> 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



More information about the asterisk-bugs mailing list