Blocked revisions 195589 via svnmerge

........
  r195589 | mmichelson | 2009-05-19 15:59:38 -0500 (Tue, 19 May 2009) | 61 lines
  
  Add basic support for handling connected line-related UPDATE requests.
  
  SIP purists may want to look the other way...
  
  When COLP/CONP support for SIP was committed, there was a condition under 
  which Asterisk may transmit a SIP UPDATE in order to communicate the change 
  in connected line information. The issue here is that while we could send a 
  SIP UPDATE message, we were not prepared to receive such an UPDATE and would 
  always responde with a 501 when we received an UPDATE.
  
  The situation was a bit rough. We really want to be able to receive UPDATEs 
  having to do with connected line changes, but the amount of effort involved 
  in properly supporting RFC 3311 was staggering. This commit represents a 
  compromise.
  
  First, it was decided that it is important to only send a SIP UPDATE to 
  an endpoint that is able to handle one. So, now we have added parsing of 
  the Allow header into SIP. We store the allowed methods on SIP peers so 
  that when we communicate with them, we already will know what we can and 
  cannot send to them. We will parse the peer's allowed methods when he registers
  with us. If the peer is not the type to register with us, but the qualify option 
  is enabled, then we will use the response to the OPTIONS request we send 
  the peer to determine the peer's allowed methods. When the peer's registration 
  expires, or when qualify deems the peer to be unreachable, we clear the allowed 
  methods from the peer.
  
  For an actual call, we will copy the peer's allowed methods to the sip_pvt 
  representing the call leg. If we are communicating with an endpoint which is 
  not a peer, then we will just parse the Allow header from the first message 
  we receive during the call and store the information in the sip_pvt.
  
  If, during communication with a peer, we receive a 501 response, then we will 
  make sure to save the fact that we cannot use that method when communicating 
  with that peer.
  
  Now, with all that infrastructure in place, the only actual place we use this 
  information currently is when attempting to send a connected line change using 
  an UPDATE request. If we cannot send the change immediately using an UPDATE, 
  we will set the SIP_NEEDREINVITE flag so that we can send a REINVITE as soon 
  as it is allowed.
  
  The second part of the changes here is for Asterisk to accept UPDATE requests 
  that have connected line changes. Since we are not fully supporting RFC 3311, 
  Asterisk will NOT place the UPDATE method in Allow headers it sends. Instead, 
  if you are communicating with what you know to be another Asterisk box, you may 
  set the rpid_update parameter in sip.conf so that we will send UPDATEs to that 
  Asterisk box. When we send a connected line update, we set a custom header 
  called "X-Asterisk-rpid-update."
  
  On the receiving end, if Asterisk receives an UPDATE that does not have the 
  "X-Asterisk-rpid-update" header present, then Asterisk will respond with a 501 
  since media-changing UPDATEs are not supported. We should never get such 
  UPDATEs, since as was stated earlier, Asterisk does not put UPDATE in its Allow
  header. If the custom header is present in the received UPDATE, though, then we 
  will check the incoming request for connected line updates and queue the update
  on the channel where the change occurred.
  
  ABE-1840
  ABE-1822
........


git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@195590 f38db490-d61c-443f-a65b-d21fe96a405b

0 files changed, 0 insertions, 0 deletions