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/trunk@195589 f38db490-d61c-443f-a65b-d21fe96a405b

1 files changed, 7 insertions, 0 deletions

diff --git a/configs/sip.conf.sample b/configs/sip.conf.sample
index 37e3c47d4..ab771eda4 100644
--- a/configs/sip.conf.sample
+++ b/configs/sip.conf.sample
@@ -232,6 +232,13 @@ srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
                                 ; This is identical to sendrpid=yes
 ;sendrpid = pai                 ; Use the "P-Asserted-Identity" header
                                 ; to send the identity of the remote party
+;rpid_update = no               ; In certain cases, the only method by which a connected line
+                                ; change may be immediately transmitted is with a SIP UPDATE request.
+                                ; If communicating with another Asterisk server, and you wish to be able
+                                ; transmit such UPDATE messages to it, then you must enable this option.
+                                ; Otherwise, we will have to wait until we can send a reinvite to
+                                ; transmit the information.
+
 ;progressinband=never           ; If we should generate in-band ringing always
                                 ; use 'never' to never use in-band signalling, even in cases
                                 ; where some buggy devices might not render it