|
|
Author |
Message |
roy.zhang Brekeke Junior Member
Joined: 28 Oct 2015 Posts: 8
Location: China, Shaanxi
|
Posted: Wed Oct 28, 2015 8:42 pm Post subject: Cannot CANCEL a re-INVITE request |
|
|
1. Brekeke Product Name and Version:
Brekeke SIP Server, Version 3.4.7.0, Evaluation
2. Java version:
java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.2) (Arch Linux build 7.u91_2.6.2-1-i686)
OpenJDK Client VM (build 24.91-b01, mixed mode)
3. OS type and the version:
Linux ArchServer 4.2.4-1-ARCH i686
4. UA (phone), gateway or other hardware/software involved:
PJSIP
5. Your problem:
I have set up a session and sent a re-INVITE to change the session, but SIP server dose not give a provisional response even I set "100 Trying " to "any requests". Then the other peer sent a provisional response, 180 Ringing.
At this time I want to cancel the re-INVITE and send a CANCEL request, but SIP server give a "481 Call Leg/Transaction Does Not Exist" response.
So my question is, how could I cancel the previous re-INVITE? |
|
Back to top |
|
taitan Brekeke Master Guru
Joined: 15 Mar 2008 Posts: 237
|
Posted: Mon Nov 02, 2015 6:09 pm Post subject: |
|
|
Since re-INVITE is not initial request, "100 Trying" will not be sent.
"any requests" means "any initial request".
Refer the Brekeke SIP Server's document about "100 Trying"
http://www.brekeke.com/doc/sip/sip_admin_v3.pdf#page=33
> So my question is, how could I cancel the previous re-INVITE?
Are there any provisional response (such as 180) to re-INVITE from another UA? If so, you can send CANCEL to the re-INVITE. |
|
Back to top |
|
roy.zhang Brekeke Junior Member
Joined: 28 Oct 2015 Posts: 8
Location: China, Shaanxi
|
Posted: Mon Nov 02, 2015 6:17 pm Post subject: |
|
|
Hi taitan, thank you for the reply.
> Are there any provisional response (such as 180) to re-INVITE from another UA? If so, you can send CANCEL to the re-INVITE.
Yes, I let the other peer send a "180 Ringing" to the re-INVITE request, and the SIP server just respond with a "481 Call Leg/Transaction Does Not Exist" to the "CANCEL" request and never pass the "CANCEL" to the other peer. Looks confusing. |
|
Back to top |
|
|
|
|
|