[Home]

Summary:ASTERISK-03908: Content-Type header in "OK" response confuses asterisk
Reporter:marvy (marvy)Labels:
Date Opened:2005-04-11 04:36:52Date Closed:2011-06-07 14:10:41
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bad
( 1) chan_sip.c.diff.txt
Description:If a peer sends asterisk a SDP reinvite packet during an already established session, asterisk responds correctly with an "ACK" packet. The peer then sends an "OK" packet. Asterisk does not expect this packet to have a "Content-Type: application/sdp" header. If it does, it passes the packet to the SDP engine incorrectly. As there is no body, the SDP engine produces a

WARNING[34979]: chan_sip.c:2645 process_sdp: Insufficient information for SDP (m = '', c = '')

To fix the problem on my machine I made a change to chan_sip.c line ~7730 to add a test from Content-Length. A real SDP packet would have a non-zero Content-Length.

  __sip_ack(p, seqno, FLAG_RESPONSE, NULL);
  if (!ast_strlen_zero(get_header(req, "Content-Type"))
++   && strcasecmp(get_header(req, "Content-Length"), "0")){
    if (process_sdp(p, req))
        return -1;
  }
  check_pendings(p);


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

Attached is a tcpdump file with 3 packets - "INVITE", "ACK" and "OK" showing the problem.
Comments:By: Clod Patry (junky) 2005-04-11 05:50:19

Please attach the patch as a diff -u format.
Like the bugs guidelines suggested it.
By: marvy (marvy) 2005-04-11 06:09:42

The diff has been uploaded as requested.
By: Mark Spencer (markster) 2005-04-12 01:03:41

You cannot transmit an empty SDP.  Asterisk is right to complain that the SDP is missing critical components.
By: Olle Johansson (oej) 2005-04-19 00:25:09

What type of device is on the other end of the dialogue?
By: marvy (marvy) 2005-04-19 00:33:38

I believe this issue is still unresolved. I need to re-open the bug to add further comments as requested.
By: marvy (marvy) 2005-04-19 00:44:08

I am unsure what device is at the other end. The provider is astratel.com.au.

In the asterisk code, the incoming packet is first checked to see if its an ACK packet fair enough, then we check to see if it is from an invite we know about also fair enough. Then for some reason we check to see if there is a content-type message in the ACK, if there is we pretend the packet isn't an ACK? Is there a facility to put another SDP request into an ACK packet?

In the case if this service provider, the ACK comes back with a content-type header with "application/sdp". I don't know if this is illegal or not. I can't find anything in the RFC to say that you can't do this.

My patch was a simple check to make sure if we are going to process the SDP that it much have a payload, the process_sdp does this check a little later and spits out an error anyway.

It would be good if someone could see if this makes sense and if we are returning the right values back to the calling routing etc. Also, is the use of a strcasecmp going to introduce any security problems.

case SIP_ACK:
       /* Make sure we don't ignore this */
       if (seqno == p->pendinginvite) {
           p->pendinginvite = 0;
           __sip_ack(p, seqno, FLAG_RESPONSE, -1);
           if (!ast_strlen_zero(get_header(req, "Content-Type"))
               && strcasecmp(get_header(req, "Content-Length"), "0")) {
               if (process_sdp(p, req))
                   return -1;
           }
           check_pendings(p);
       }


This is related to bug number 4004.
By: Olle Johansson (oej) 2005-04-19 11:34:58

I guess we need to read the MIME rfcs to see if it is correct to add a Content-type header without adding any message body at all. I do not think so, so our message is correct.

But what is the real problem? Does the call go through all right?
By: marvy (marvy) 2005-04-19 15:49:30

I found this while working on 4004. The problem isn't that it generates a warning, the problem is that asterisk processes an ACK packet as an INVITE packet if this header is present. If you want to punch out a warning about a weird ACK packet thats fine, but it seems strange to pass an ACK packet to the process_sdp routine.
By: Kevin P. Fleming (kpfleming) 2005-04-20 10:02:38

It is _never_ valid to include a Content-Type header and not supply the associated content. Asterisk rightly assumes that if the peer send it a header specifying there is an SDP body, then it should process that SDP body.

In addition, ACK does not support _any_ body being included, so Asterisk could conceivably ignore it in this case. However, this points to the provider's SIP implementation being seriously RFC non-compliant.
By: Olle Johansson (oej) 2005-04-21 13:38:32

It is valid to process an SDP in an ACK. In some cases, we send an INVITE without an SDP, return OK with SDP and then ACK with SDP. This is a broken user agent.

Again - does this break a call, stop anything or are we discussing cosmetics?
By: Kevin P. Fleming (kpfleming) 2005-04-21 21:21:52

There are two issues being discussed here:

First, I was wrong: it is valid to have a message body in an ACK, but the only time that Asterisk should ever receive that is when the initial INVITE from the SIP UAC did not include a message body. In that case, it's doubtful that Asterisk would respond properly anyway, given that it assumes incoming INVITEs will always have media streams identified in them. Regardless, that is not the bug submitter's problem.

The real problem here is that the SIP provider is sending "Content-Type: application/sdp" but not actually including any message body. I don't believe the proposed fix is correct, because the Content-Length header is not mandatory.

Honestly, I don't think we should be catering to broken SIP implementations... if the provider cannot fix their implementation to be RFC compliant, they will have difficulty with more than just Asterisk peers.
By: Olle Johansson (oej) 2005-04-22 18:46:08

I do not believe the fix is correct and still want to know what the problem really is - are we dropping calls?
By: Kevin P. Fleming (kpfleming) 2005-04-26 23:22:53

One more try: does this problem only generate unnecessary warnings, or does it actually affect call handling?
By: marvy (marvy) 2005-04-27 05:09:45

I don't think it affects the call however I believe that the ACK doesn't get processed by asterisk as its passed off as an SDP event rather then an ACK. As the SDP processing produces an error, I think it stops processing the rest of the OK as well.
By: Olle Johansson (oej) 2005-04-27 07:35:01

Well, it is a buggy device. Please report the bug to the manufacturer.

If there is no problem with the call, I see no reason spending time on working on this any more since the bug is really with the other end.
By: Kevin P. Fleming (kpfleming) 2005-04-27 12:18:44

I agree; if this is not affecting the call, then this is only a cosmetic issue caused by a non-conformant SIP peer. We will not change Asterisk's behavior for that :-)