Support
2004-Oct-15 06:05 UTC
[Asterisk-Users] Transmit re-INVITE before BYE is sent - why?
I have a question concerning re-INVITEs and how/why Asterisks sends
them. On SIP to SIP calls with asterisk set up with canreinvite=yes,
after a call is setup, media ip address:ports are renegotiated, 2 way
rtp is established, and then one of the parties hangs up by sending a
BYE, Asterisk goes through a re-INVITE process before forwarding on the
BYE to the other party. I've shown the last part of the call flow
(after the first re-INVITE to renegotiate the media stream) below where
party A calls party B and after 2 way rtp has been established.
Party A Asterisk Party B
5551200 5551212
| | |
|<-----2 way RTP Peer to Peer-----|
| | |
| |<-----BYE-------|
| |-----200 OK---->|
|<--INVITE-------| |
|---TRYING------>| |
|---200 OK------>| |
|<----ACK--------| |
|<----BYE--------| |
|----200 OK----->| |
In looking through the documentation, chan_sip.c file, associated web
sites, configuration files, mailing lists, I have not been successful in
finding out why it does this last re-INVITE but it appears that this may
be performed as a clean up process allowing asterisk to possibly play a
goodbye message or some other recording prior to hangup (rtp is
transferred back to *). Is there something in the extensions.conf file
that either turns on or turns off this activity. I have found that if
you set canreinvite=no, this does not occur, but then * won't release
rtp. My entry in extensions.conf is very simple:
exten => _5551212,1,Dial(SIP/${EXTEN}@mydomain,,)
exten => _5551212,2,Hangup
...and I've even tried taking out the Hangup step, but have not seen a
difference. I was looking for a way to allow re-INIVITEs to renegotiate
the rtp address:ports but not perform this last re-INVITE before a BYE.
Any suggestions? Thanks.
Tom Schroer