Summary: | ASTERISK-02896: [patch] compact sip headers | ||
Reporter: | Brian West (bkw918) | Labels: | |
Date Opened: | 2004-11-27 01:54:46.000-0600 | Date Closed: | 2008-01-15 15:15:10.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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 |