[Asterisk-Dev] SIP - asterisk does not handle re-INVITEs correctly

[Alex Zeffertt]

Hi all,

I've got a problem with the way asterisk behaves following the
reception of a  re-INVITE. Although it correctly responds to the
SIP/SDP message, there appears to be something wrong with the handling
of the RTP data after the codec has been changed.

For example.  I have a SIP UA which I am using to call the
EchoTest demo (sip:600 at asterisk).  I can verify using a packet sniffer
that a GSM session is created and that the RTP payloads coming back from
asterisk match the RTP payloads being sent to asterisk.  The SIP UA then
sends asterisk a re-INVITE and using the packet sniffer I can verify
that the codec changes to ULAW in both directions.  However, now the
data being sent by asterisk does not match the data being sent to
asterisk.  In fact, if the SIP UA sends asterisk a continuous stream of
0xAAs, then asterisk sends back roughly 30 0xABs, followed by roughly 30
0xACs, then 0xADs, until it gets to 0xFD at which point it just keeps
sending 0xFDs.

Does anybody know what is happening here?

For the record, the reason I need asterisk to be able to handle
re-INVITEs is that I am implementing a fax-upspeed scheme.  The idea is
that when the SIP-UA recognises a fax tone it attempts to renegotiate
the codec used for talking to asterisk to G711, which is low compression
enough to allow fax pass-through.

TIA,

Alex


-- 
Alex Zeffertt
Software Engineer
Cambridge Broadband Ltd.
http://www.cambridgebroadband.com