Hi Peter, I think, if your application or sip stack is not allowing you to issue simultaneous INVITE, then it's an implementation problem. Your application should provide a workaround for this issue. Like putting a state in your app : "user has cancelled the call". And then don't render this call's state changes to user and automatically try to tear the call or just remove it after timer expires.
Regards, Sumit Jindal On Fri, Jan 21, 2011 at 7:08 PM, Brett Tate <br...@broadsoft.com> wrote: >> I have a question regarding the termination of a call >> establishment by the UAC, when no response has been >> received for an ongoing UAC INVITE transaction, i. e. >> the transaction is still in state "Calling" and no dialog >> has been created. It seems to me, that this situation >> is not considered at all in RFC 3261 but it is simply >> assumed that the user who initiated the call has the >> patience to wait for termination of Timer B until a new >> call can be attempted (suppose only one call establishment >> is possible at the same time). > > RFC 3261 section 17.2.1 handles it by requiring a 100 response: "The server > transaction MUST generate a 100 (Trying) response unless it knows that the TU > will generate a provisional or final response within 200 ms, in which case it > MAY generate a 100 (Trying) response." > > >> Is there a rule(best practice for this "early call >> abortion" or is this simply a constraint for a given UI >> (to wait until the UAC INVITE transaction times out)? > > Unless there is a real reason to do otherwise, the client should be able to > locally release a call and place a new call prior to first call attempt > completely being released. > > >> My guess would be to send a CANCEL to the UAS (although >> this is prohibited in sec, 9.1) and hope that it arrives >> after the Invite, which should usually happen. > > I don't recommend violating rfc3261's requiring a 1xx before sending CANCEL > (i.e. acting like rfc2543) unless something abnormal is occurring with your > client which would subsequently prevent it sending CANCEL later per rfc3261's > rules. > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Regards, Sumit Jindal _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
