Asterisk rejects packet with "i=" Field in SDP Part


#1

Hello,

I have a problem with the connection initialisation (initial INVITE) in my Asterisk 1:1.6.2.9-2ubuntu2.1 when setting the “i=” Flag. According to the (RFC 4566, p. 11) the “i=” flag can be used for:

For example the packet without the i= information looks like:

v=0 o=user1 1682420165 643979666 IN IP4 192.168.11.2 s=- c=IN IP4 192.168.11.2 t=0 0 m=audio 8000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv

The SDP part of the packet with “i=” looks like:

v=0 o=user1 1396633799 2096570444 IN IP4 192.168.11.2 s=- i=111.111.111.111 c=IN IP4 192.168.11.2 t=0 0 m=audio 8000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv

For sure I took care of the order of the flags as well as the new length of the content-length field. In addition I have to say that, when sending the same packet with the I= flag to my sip provider (sipgate) the packet is accepted. Just the asterisk server in my lab environment rejects the packets. In the debugging and verbose information the packet with the “i=” does not occur. I can see the packet arriving at the interface in wireshark but not in the asterisk itself. However as aforementioned the same packet without the i= fiel is accepted by the asterisk.

Edit:
Updated to Asterisk Version 1.8 still the same issue…


#2

I believe sip set debug on output is generated before the SDP is parsed, so I find it diffcult to believe that Asterisk is receiving but not seeing the packet. However, if you are sure of your facts, you should submit this on issues.asterisk.org, in which case you must included the actual sip debug traces (and if they are empty, the other traces showing the packet arriving. Simply describing the output is not enough.


#3

Thank you for your advise.
Before I am going to post an issue I want to know if there is a debug/verbose function which shows more than the asterisk “core set verbose/debug” option. If it is an asterisk problem, I guess asterisk will throw a parsing error or something like that?!


#4

For any SIP problem, you need to have issued the command

sip set debug on

To strictly follow the reporting guidelines, you should also have used

sip set history on

and arranged to capture the SIP history trace for every call.

See asterisk.org/developers/bug-guidelines - in particular item 6.


#5

I tried a few things (according to your and the Bug Tracking suggestions (e.g. debug/verbose to 4) ) but Asterisk does not spit out anything about the misinterpretation of the SIP packet. Asterisk debug/verbose does not see the INVITE packet which has the “i=” flag. I am a little bit confused about this problem. I cant believe that there is no way to debug this issue.
Does it make sense to test it with AsteriskNOW or Asterisk 10? Are there any internal changes made related to sip/sdp?

Sorry for bothering but I am not that guy who is posting a bug until every effort has been made.


#6

If you have “sip set debug on” and you are not seeing anything, I’d again suggest that Asterisk is not receiving the packets.


#7

I checked everything again in my setup and code. At least I took a look at the “chan_sip.c” source code where sdp parsing is enforced. Everything in concern to m=, o=, v=, t= and a= looks quite good. So i guess there is no implementation for the i= flag. As you can see in the enum for the sdp fields in chan_sip.c i= (session information) is missing:

/* SDP fields */ char *version = "v=0\r\n"; /* Protocol version */ char subject[256]; /* Subject of the session */ char owner[256]; /* Session owner/creator */ char connection[256]; /* Connection data */ char *session_time = "t=0 0\r\n"; /* Time the session is active */ char bandwidth[256] = ""; /* Max bitrate */ char *hold = ""; struct ast_str *m_audio = ast_str_alloca(256); /* Media declaration line for audio */ struct ast_str *m_video = ast_str_alloca(256); /* Media declaration line for video */ struct ast_str *m_text = ast_str_alloca(256); /* Media declaration line for text */ struct ast_str *m_modem = ast_str_alloca(256); /* Media declaration line for modem */ struct ast_str *a_audio = ast_str_alloca(1024); /* Attributes for audio */ struct ast_str *a_video = ast_str_alloca(1024); /* Attributes for video */ struct ast_str *a_text = ast_str_alloca(1024); /* Attributes for text */ struct ast_str *a_modem = ast_str_alloca(1024); /* Attributes for modem */ const char *a_crypto = NULL; const char *v_a_crypto = NULL; const char *t_a_crypto = NULL;


#8

At least in older versions, it searches the SDP for specific records, so an unknown one would just be ignored. Also, if it got this far, it would have printed the contents of the incoming packet, if sip set debug is on.