Hello! I'm *sometimes* facing dropped calls after 900s on outbound calls. I analyzed the traces and could see the following point:
1. Asterisk sends Invite to provider / CSeq 26379 INVITE 2. Provider sends 180 Ringing / require: 100rel RSeq: 2 / CSeq 26379 INVITE 3. Asterisk sends PRACK / CSeq 26380 PRACK / RAck 2 26379 4. Provider sends 200 OK / CSeq 26380 PRACK 5. Provider sends 200 OK / CSeq 26379 INVITE 6. Asterisk sends ACK / CSeq 26379 ACK 900s later 7. Provider sends Update / CSeq 26380 UPDATE 8. Asterisk sends 200 OK / CSeq 26380 UPDATE 9. Provider sends ReInvite / CSeq 26381 INVITE 10. Asterisk sends 200 OK / CSeq 26381 INVITE 11. Provider sends ACK / CSeq 26381 ACK (without any *supported* headers) 12. Provider sends BYE => call is unexpectedly ended by the provider. If it's working as expected, all steps are the same as above, but step 11 contains the supported headers and call proceeds. Strange: There are two outgoing calls to exactly the same destination. The first call drops after 900s - the second call (restarted directly after the first call has been dropped) works as expected. My question (because always if a call was dropped, PRACK has been in use): Is it a good idea to use a subsequent CSeq for the PRACK on Asterisk side, which is reused later on by the provider for the update (in this example)? Probably it shouldn't harm - but could this for some devices be nevertheless a problem? For now, I disabled 100rel support on Asterisk trunk side (it was on by default). Let's wait and see what happens ... . Thanks Michael -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
