[Home]

Summary:ASTERISK-02896: [patch] compact sip headers
Reporter:Brian West (bkw918)Labels:
Date Opened:2004-11-27 01:54:46.000-0600Date Closed:2008-01-15 15:15:10.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) compact_sip.diff.txt
Description:The lookup table is already there in chan_sip for inbound compact header support this patch allows asterisk to send compact headers...

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

disclaimer on file.

Reliably Transmitting (no NAT):
SIP/2.0 200 OK
v: SIP/2.0/UDP 65.38.28.147:5060;branch=z9hG4bK-1359a52f
f: Brian West <sip:16@65.38.28.146>;tag=7e6fd92eb199253o0
t: <sip:996@65.38.28.146>;tag=as42b91765
i: f671e1be-32ea1c17@65.38.28.147
CSeq: 102 INVITE
User-Agent: bkw.org/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
m: <sip:996@65.38.28.146>
c: application/sdp
l: 219

v=0
o=root 21849 21849 IN IP4 65.38.28.146
s=session
c=IN IP4 65.38.28.146
t=0 0
m=audio 22778 RTP/AVP 2 101
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

to 65.38.28.147:5060
Comments:By: Olle Johansson (oej) 2004-11-27 22:43:08.000-0600

This should be settable by peer.

Also if a device sends us compact headers in an invite, we should propably reply with compact headers, so we need a channel setting.

Also, remember to reset the variable in the sipreload function.
By: Brian West (bkw918) 2004-11-28 00:13:32.000-0600

reset val on reload is there now.  I honestly dont think doing per peer or per request on the fly compact sip headers is something that we should even think about right now.  Our MAX TNT's don't distinguish them apart do any other sip proxies out there do this?
By: khb (khb) 2004-11-28 01:28:37.000-0600

There should be no distinction between long and short header names. They can be mixed even in a single message, and there is no requirement to transmit or respond in any one way.  Any RFC compliant device has to support both.
The way I see it, there are only two possible benefits:
(I) If the packet size runs close to the MTU, use short headers for small gain.
(II)Use short headers for much more efficient parsing if that becomes critical (string comparison vs. byte comparison) but before that becomes an issue in Asterisk SIP there are many collosal performance improvements to be made first.
To be able to send short headers is nice, if only for testing purposes, other than that I don't see the point of one over the other, unless point (I) become into play.

edited on: 11-28-04 01:42
By: Brian West (bkw918) 2004-11-28 01:42:59.000-0600

the option is nice ;)

bkw
By: khb (khb) 2004-11-28 13:56:06.000-0600

yes, the option would be nice.
BTW, the parsing of headers, particularly the short ones, in incoming messages in our sip is so bad and inefficient that we can hardly recommend sending out short messages and would want them back in short notation.  I think we should actually discourage people from using short headers until this is improved.
It's not a knock against your patch. I think we should have it available.

edited on: 11-28-04 13:58
By: Mark Spencer (markster) 2004-11-28 16:50:14.000-0600

Added to CVS with slight modifications.
By: Russell Bryant (russell) 2004-11-29 18:17:13.000-0600

not in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:15:10.000-0600

Repository: asterisk
Revision: 4350

U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

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

Add option for small headers (bug ASTERISK-2896)

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

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