[Home]

Summary:ASTERISK-07484: incorrect 488 response contact header
Reporter:Alexander Tull (alex-911)Labels:
Date Opened:2006-08-08 10:20:05Date Closed:2006-09-18 15:09:04
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 488-invalid-contactheader-20060809.TXT
Description:I have a problem with the interworking of asterisk with acmepacket's session border controller. that box acts as a B2BUA between asterisk and the Call Agent (Cisco class4 softswitch).

due to a T.38 INVITE for fax, the asterisk responds correctly with a 488. the problem is it sends a contact header which seems to be against section 20.1 of RFC 3261.

normally, the B2BUA replaces the contact header field with another URI. but as it is invalid for the 488 response, it is ignored completely and passed originally to the softswitch. the softswitch afterwards tries to reinvite for fax relay with G.711 but is using the riginal URI which is not reachable for it as the asterisk is behind the B2BUA.

so the contact header would need to be removed to be compliant to RFC3261 and to make interoperability possible with acme packet's session border controller and Cisco softswitches.

a working T.38 support in asterisk would solve that problem as well as the softswitch tries to reinvite after a failing T.38 INVITE for fax.

this issue (along with no T.38 support) unfortunately blocks me recommending asterisk to our customers



****** ADDITIONAL INFORMATION ******

here an example 488:

Session Initiation Protocol
   Status-Line: SIP/2.0 488 Not acceptable here
       Status-Code: 488
       Resent Packet: False
   Message Header
       Via: SIP/2.0/UDP 2.2.2.20:5060;branch=z9hG4bK000e1520b83hga8oh5o1sb0000g00.1;received=2.2.2.20
       From: <sip:601@2.2.2.20>;tag=1194107340
           SIP from address: sip:601@2.2.2.20
           SIP tag: 1194107340
       To: "bla" <sip:6003@1.1.26.26>;tag=as21fcb722
           SIP Display info: "bla"
           SIP to address: sip:6003@1.1.26.26
           SIP tag: as21fcb722
       Call-ID: 152ec89f5d4d26b50549f57759fbaf7c@1.1.26.26
       CSeq: 1 INVITE
       User-Agent: blabla.ch PBX
       Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
       Contact: <sip:6003@1.1.26.26>
           Contact Binding: <sip:6003@1.1.26.26>
               URI: <sip:6003@1.1.26.26>
                   SIP contact address: sip:6003@1.1.26.26
       Content-Length: 0
       X-Asterisk-HangupCause: Normal Clearing
Comments:By: Serge Vecher (serge-v) 2006-08-08 10:44:42

I) As per bug guidelines, could you please attach a SIP debug trace illustrating the problem. Please do the following:
1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.

II) T.38 pass-through support has been added in trunk, which will soon be released as 1.4.beta; something you may want to look into. However, please do provide the log as per instructions above so that we can remove the RFC violation in chan_sip code. Thanks.

By: Alexander Tull (alex-911) 2006-08-09 02:40:07

I) attached as requested.

II) how to keep track when 1.4beta is released and where to get it? will call diversion header support (levy-draft) be included as well?

rgds
/alex



By: Serge Vecher (serge-v) 2006-08-09 09:37:30

I) thanks, a developer will look into that next.
II)
 a. you can subscribe to asterisk-announce mailing list to get a notification (or monitor postings on asterisk-dev for more details)
 b. visit http://bugs.digium.com/view.php?id=5484. It has not been merged into trunk, so whether it will be in 1.4 beta or not remains to be seen. You can always type up a note there to offer your help with testing -- positive testing results usually lead to code being merged into trunk ;)

By: Alexander Tull (alex-911) 2006-08-09 10:14:01

II)
b. I know that case and I have unsuccessfully tested the patch, but maybe I did something wrong when patching. I'd be glad to help out testing in our environment where the levy draft is supported by the CA. I will post a note over there, hoping it will make it into the trunk.
thanks
/alex :]

By: Serge Vecher (serge-v) 2006-09-18 11:08:28

alex-911: did you have a chance to see if this is handled differently in 1.2.12.1?

By: Olle Johansson (oej) 2006-09-18 15:07:12

I've added a quick-fix to 1.2 and will look into doing something better for trunk.

By: Olle Johansson (oej) 2006-09-18 15:08:47

Fix committed to rev 43220, svn 1.2 trunk