[Asterisk-Dev] Changes to SIP

[Mark Spencer]

> (o)  The From header needs to be set to the account that performs the
> REGISTER. I currently have a small hack that allows me to specify what the
> >From header should be in the sip.conf file for that peer.

Can you provide an example?  I believe you can use "callerid=" in the
"general" section to set the default callerid.  I am not sure this is the
problem you are trying to solve though.

> (o)  When a BYE is sent the authorization digest is not sent, cisco replies
> with Proxy auth required but by then Asterisk has already destroyed the
> channel. From a glance it looks like the cisco phones send the same auth
> digest as what was sent for the INVITE. The phone does not go through the
> whole transaction of trying without auth, then receiving a proxy-auth
> required error, then finally sending the auth digest.

Are we permitted to send the same authorization digest as we sent on the
first call?  It would still be possible for us to hang around and handle
authentication on the BYE, but this will take a little work to do.  As of
CVS this morning, the SIP channel has been modified somewhat to be sure we
hang around when transmitting "final" messages until they've been ACK'd.

> (o)  While an INVITE is "Trying" a CANCEL request sent by asterisk results
> in a "487 Request Cancelled". Cisco equipment ACKs this response. It seems
> that if the proxy does not receive this ACK it does not hang up the other
> end until a time out period is reached. Should Asterisk be modified to not
> clean up after a CANCEL and only after sending an ACK to a 487? Does
> everything always send a 487 or should perhaps a channel timeout if non is
> received?

I believe this should have been somewhat incidently fixed by CVS this
morning and is related to the above behavior.  The basic problem is that
we shouldn't destroy the SIP channel until all outstanding messages have
been handled, including waiting for the 487 response to our "CANCEL" which
should be dumped just before it's destroyed.

> (o)  The ACK sent on the INVITE's 200 OK are not recognized for some reason.
> This may be due to my from header hack I'm not sure. After each ACK sent the
> proxy sends another 200 OK. Eventually the proxy drops the connection.

I believe this is a result of improper handling of the record-route
header.  Someone sent a patch that I plan to review before applying.
Please contact me off list or on IRC if the first items are not resolved
and I'll be happy to work with you on it.

Mark