[asterisk-dev] SIP race condition with directmedia and sendrpid?

[Henning Holtschneider]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everybody,

I was investigating JIRA issue 16912 <https://issues.asterisk.org/jira/browse/ASTERISK-16912> the other day. As a quick recap, this is the scenario:

1. Phone A calls Phone B

2. Phone A puts Phone B on hold

3. Phone A calls Phone C

4. Phone A REFERs Phone B to Phone C

"sendrpid" is set to "pai" in sip.conf.

When using directmedia=no, everything is in order after completing the transfer. When using directmedia=yes, Asterisk will send one re-INVITE to Phone B and Phone C to set up the SDP session and a second re-INVITE to Phone B and Phone C with an updated P-Asserted-Identity header.

The second INVITE will cause Aastra phones to reply with a 500 Internal Server Error because the second INVITE arrives before the first has been OK'd by the phone and ACK'd by Asterisk.

I had a look RFC 3261 and RFC 5407 to find out whether Asterisk and/or the phone are misbehaving. I also inspected the update_connectedline() function in chan_sip.c to find out under which circumstances the re-INVITE to update the PAI would be delayed. If I understand the code correctly, update_connectedline() will immediately send out the PAI update (INVITE) if the SIP dialog between Asterisk and Phone C is in an established state.

I wonder if

- - it's acceptable for Asterisk to send the second re-INVITE without waiting for the first to be OK'd be the phone,

- - it's acceptable for the phone to send a 500 Internal Server Error. From my understanding, a 491 Request Pending would be more appropriate *if* the second re-INVITE is valid.

Can anyone comment on this?

Thanks,
Henning Holtschneider
- --
LocaNet oHG - http://www.loca.net
Lindemannstrasse 81, D-44137 Dortmund
tel +49 231 91596-25, fax +49 231 91596-55
sip 25 at voip.loca.net

Registergericht Amtsgericht Dortmund HRA 14208
Geschäftsführer Sven Haufe, Henning Holtschneider

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAk49KEUACgkQP9goCV2uudfWxQCgkPZCbWQwFtnA4cMd8j7U20zJ
kAoAn1IUXD+VlJdxlVn5+ltJMgkXvKj5
=4kGY
-----END PGP SIGNATURE-----