[Home]

Summary:ASTERISK-03728: [patch 1.0] SIP accepts re-INVITE for T.38, thus terminating call
Reporter:bladerunner (bladerunner)Labels:
Date Opened:2005-03-21 06:26:27.000-0600Date Closed:2008-01-15 15:30:22.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) deny-t38.txt
( 1) sip-debug.txt
( 2) sip-debug-patch1.txt
( 3) sip-debug-patch2.txt
Description:In chan_sip, when receiving an re-INVITE from sip-trunk-provider for T.38 on a fax, Asterisk should answer with "415 Unsupported Media Type", but answers with his own codec capabilities. So the fallback at my provider to G.711 is never requested and the fax-call fails.

Find attached the sip debug peer - output.
Comments:By: Olle Johansson (oej) 2005-03-21 06:36:46.000-0600

Thank you! I've been waiting for a SIP debug with a T.38 in it. Obviously, we need to react properly to this.

This is the interesting packet:
-------------------
INVITE sip:0316890841@81.223.57.205 SIP/2.0
Record-Route: <sip:62.99.171.27;ftag=5fb30d478bbf4d6;lr=on>
Via: SIP/2.0/UDP 62.99.171.27;branch=z9hG4bKc2f5.c4daf2f2.0
Via: SIP/2.0/UDP 62.99.171.52:5060;branch=z9hG4bKc3de726c3
Max-Forwards: 16
Content-Length: 122
To: "70" <sip:0316890841@81.223.57.205>;tag=as100f59dc
From: <sip:695199@voip.inode.at>;tag=5fb30d478bbf4d6
Call-ID: 00885e1b762721104c04a8af1716703b@81.223.57.205
CSeq: 873503457 INVITE
Supported: timer
Content-Type: application/sdp
Contact: sip:020316695199@62.99.171.52:5060
Supported: replaces
User-Agent: SN2400 MxSF v3.2.7.36

v=0
o=MxSIP 0 128526 IN IP4 62.99.171.52
s=SIP Call
c=IN IP4 62.99.171.27
t=0 0
m=image 57570 udptl t38
a=sendrecv
By: Olle Johansson (oej) 2005-03-21 06:44:37.000-0600

BTW, 415 is the wrong error code. We do support SDP attachments. Let's find a proper one.
By: bladerunner (bladerunner) 2005-03-21 06:48:30.000-0600

Always at your service ;-)

I tried to resolve this myself in chan_sip.c for nearly a week now, but to no avail. IMHO the problem lies in the add_sdp(...) - part near line 3640, when the channel tries to map the codecs, and never checks for the m= - part of the re-INVITE, but i could (very possible) be horribly wrong.
By: bladerunner (bladerunner) 2005-03-21 06:49:36.000-0600

It could be error code 488, but i'm not sure about that one... I got my infos about the error codes from my SIP-trunk provider.
By: Olle Johansson (oej) 2005-03-21 07:22:38.000-0600

From RFC 3264 Section 6:
------------------------
An offered stream MAY be rejected in the answer, for any reason.  If
  a stream is rejected, the offerer and answerer MUST NOT generate
  media (or RTCP packets) for that stream.  To reject an offered
  stream, the port number in the corresponding stream in the answer
  MUST be set to zero.  Any media formats listed are ignored.  At least
  one MUST be present, as specified by SDP.
[..]
6.1 Unicast Streams

  If a stream is offered with a unicast address, the answer for that
  stream MUST contain a unicast address.  The media type of the stream
  in the answer MUST match that of the offer.

[..]
 If the answerer has no media formats in common for a particular
  offered stream, the answerer MUST reject that media stream by setting
  the port to zero.

  If there are no media formats in common for all streams, the entire
  offered session is rejected.

RFC 3261 13.3.1
"A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response.
Such a response SHOULD include a Warning header field value explaining why the offer was rejected."

Heureka, I think we found the proper error code!

edited on: 03-21-05 07:37
By: Olle Johansson (oej) 2005-03-21 07:29:40.000-0600

IN function process_sdp, we check for audio and video, but do not react if we get another SDP media type that we do not understand. We propably should handle that as well.
By: Olle Johansson (oej) 2005-03-21 07:59:54.000-0600

See if this patch helps you. I have no way of testing this, so I really need your help. Thank you!
By: Olle Johansson (oej) 2005-03-21 08:03:34.000-0600

Tell your provider that 415 indicates that the message body MIME media type is not supported, well, we support SDP so that is wrong ;-)
By: bladerunner (bladerunner) 2005-03-21 08:16:11.000-0600

It seems that asterisk is now answering correctly with 488, but call gets cancelled anyways. so the patch works (sort of), i will try to verify if the call fails because of asterisk or on behalf of my provider.

thanks for your hard work!
By: Olle Johansson (oej) 2005-03-21 08:20:31.000-0600

I would be happy to look at a new SIP debug in order to see if the patch worked as I guess it would! Set verbose to 4, debug to 4 and capture one transaction. THank you!
By: bladerunner (bladerunner) 2005-03-21 08:29:58.000-0600

Works! Had to activate "canreinvite=yes" in my sip.conf for the sip-trunk. Now everything is as it should be.

find the new sip debug output in attachement "sip-debug-patch2.txt"
By: Mark Spencer (markster) 2005-03-21 09:14:23.000-0600

Added to CVS head, thanks!
By: Olle Johansson (oej) 2005-04-01 00:29:00.000-0600

Needs to be fixed for 1.0.
By: Brian West (bkw918) 2005-04-01 01:41:57.000-0600

as long as the bug is in resolved state drumkilla will pick it up and add it if needed.  

So i'll mark this as resolved... then over this weekends bug bash we can fix it in 1.0 (since drumkilla is the one that toggles bugs from resolved to closed once he adds them to stable.)

/b
PS: This weather SUCKS!!!!!
By: Brian West (bkw918) 2005-04-01 01:42:25.000-0600

Drumkilla will add to stable when he toggles from resolved to closed.

Thanks,
/b
By: Russell Bryant (russell) 2005-04-02 02:11:35.000-0600

I realize this needs to be fixed, however, the patch is going to take a little bit of work.  So, it won't be fixed until I can find the time to do it.  I still have 50 bugs waiting on me, so any help would be appreciated.

Porting this patch would be a good job for anyone looking for an easy karma point.

Thanks
By: Russell Bryant (russell) 2005-04-04 02:15:35

fixed in 1.0

... sorry it took a little while
By: Digium Subversion (svnbot) 2008-01-15 15:28:11.000-0600

Repository: asterisk
Revision: 5224

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r5224 | markster | 2008-01-15 15:28:10 -0600 (Tue, 15 Jan 2008) | 2 lines

Make sure we don't accept streams we can't handle (bug ASTERISK-3728)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5224
By: Digium Subversion (svnbot) 2008-01-15 15:30:22.000-0600

Repository: asterisk
Revision: 5378

U   branches/v1-0/channels/chan_sip.c

------------------------------------------------------------------------
r5378 | russell | 2008-01-15 15:30:21 -0600 (Tue, 15 Jan 2008) | 2 lines

correctly respond to an INVITE with T.38 (bug ASTERISK-3728)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5378