how many minutes after all instructions of twiml are executed, does an outbound call hangup?
is there a way to not make the outbound call hangup even if all instructions of twiml are executed and the twiml is not updating any longer?
I am only aware of update()
call = client.calls(call_sid).update(status='completed')
Related
"What will happen in SIP if both parties send INVITE to each other at same time"
What will be the behavior in the above case?
Which call will Process?
The received first INV may be proceed to establish the call by the SIP Proxy, whereas the received second INV maybe rejected by a 4xx response. But since SIP is session based it is also possible that the Proxy can establish both calls. But one call should be in hold state. Only one call will ve active.
The most likely behaviour is that the SIP user agents would display a new incoming call.
Since they would also both have an outgoing call in progress it would be up to the user as to whether they would answer the incoming call or ignore it and persist with their original outgoing call.
The crucial point is that the two INVITE requests are independent. It would be the same as if two people called each other on their mobile phones simultaneously.
RFC 3261 section 14.2 says
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
So, I think both the parties will generate 491 response to each other. But I am still not sure as both of these INVITE will be part of different dialogs and standard mentions on the same dialog.
RFC-3261 doesn't talk much about TimerC and when it fires.
I understand the importance of TimerC in forking scenarios.
Does TimerC have any role in regular SIP call?
Correct. Only Proxies use Timer C. Timer C is the proxy INVITE transaction timeout.
It is used to check if a proxied INVITE request never generates a final response. The Timer C MUST be set for each client transaction when an INVITE request is proxied ie each URI you forward the SIP INVITE to after receiving the initial INVITE.
Can anybody give me a possible reason why my QSSLSocket would stop sending and receiving data without firing a stateChanged or disconnected signal.
My app starts a thread which connects to Facebooks XMPP server, authenticates and then goes into a while loop calling waitForReadyReady(10000) and then if this returns true it will read the data. Sometimes, After a while this call to waitForReadyReady will never return true even though there should be something to read and if I try to send data at this point the server won't receive anything.
I am sending pings to the XMPP server and can detect when this has happened after not receiving a reply to my ping but it's not really usable as an app until I get to the bottom of why communication is sometimes just breaking down between client and server.
Can anybody offer any insights please?
Am Using Pjsip libraries for SIP implementation . Using Pjsip lib i can able to make IP calls perfectly . My problem is While I Make call if other End User Decline/not Reachable or No answer ,My call will connect with Voice mail and get 200k(call connected state) from sip server as same like other end user Answering call.
Not Reachable Case i can differentiate 200 ok By missing 183 Session Progress Message. But noanswer and decline case I couldn't get the actual State of call .
is any way to find call connected state and Voice mail connected state ?
There isn't any one way of a user agent knowing it has reached a voicemail server versus a person answering.
Usually what will happen is that your user agent will send an INVITE to a From URI, and some proxy responsible for that URI will fork the INVITE to the various user agents the remote party uses: her phone, her voicemail service, and so on. The first user agent to return a 2xx response sets up the call.
You will however always know to which user agent you have connected, in the Contact header of the 200 OK.
Presumably a voicemail server will indicate in its SDP offer/answer that while it accepts certain incoming media streams, it will not send anything, by marking the stream with an a=recvonly attribute (See RFC 3264).
Working on a SIP application that requires monitoring call activity/state on a phone. My app (UA) is registered with a proxy server, as is the phone being monitored. I am making use of SUBSCRIBE/NOTIFY messages to tell the phone that I want to know about its "dialog" events, and once subscribed, this works fine. I am running into two problems:
I am requesting a subscription length of 900 seconds and consistently getting some absurd amount of 4000+ seconds returned from the phone.
There is the possibility that the phone may be unplugged while the subscription is active (don't ask, but, yes, this is a possibility). When this happens, I am not getting any type of notification as to the phone no longer being available. Consequently, I have to wait for my subscription to time out, try and renew it, handle the failure, and create a new subscription.
I realize that I can renew my subscription sooner than its expiration time, but is there a better way to go about it? For example, would I be able to get "presence" events and use them to know when the phone is there or not? Are those events always guaranteed to happen on phone start-up, and even so, since there is a proxy in the middle, would I even get the notifications, or would I still not know that the phone restarted and no longer recognizes my subscription(s)? Are these "presence" updates something that I can request from the proxy?
Any insight would be great; for the moment, I'm going to simply try and refresh my subscription on a much smaller interval, but I would love to know if there is a better way to go about it. Thanks in advance.
I don't know about a SIP agnostic way other than perhaps somehow pinging the phone but there is definitely a SIP way to do presence and that's using the same subscribe/notify model you are using for dialogs but in this case for presence. The relevant standard is RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP).
Typically the presence notifications would be generated by a SIP registrar, and since you say your phone is registering with your proxy it must also have a registrar built in. The registrar would notify your UA when the other phone's registration status changes such as when it first came online or when it failed to re-register. As far as the delay between a phone "disappearing" and the registrar server detecting it there's no prescribed way to do it. You can either wait for the registration period to expire and mark the phone as offline when it fails to register or alternatively the server could actively send a packet or even a SIP request such as an OPTIONS request to the phone and mark it as offline if it got a failure response, Asterisk uses te latter approach.
When a SIP UAC client registers with a SIP UAS Registrar, the SIP client provides a Expiry Header, which indicates that maximum amount of time after which a SIP client needs to re-register itself. If the SIP client does not re-register itself in this time period, then Sip UAS proxy/registrar server will mark the client as disconnected.
Proprietary SIP packages like FreePBX and Asterisk, proactively, send SIP OPTIONS to the client, continuously, at some interval, wherein the client responds with OK. This is a more proactive way of validating if SIP clients are online; however, this technique is proprietary and not part of the actual SIP specification.