To make calls through voip user need to register first. So registration is mandatory one. I have some basic knowledge of registration process. User sends REGISTER request to server with expires header value 30 seconds. Server upon receiving request from user it sends responses with expires header value 120 seconds. User need to register again before expires header time period ends or before 60 seconds. Once registration is done registrar server will sends the user's uri and location in location server. So user's location will be present in location server. If location server has user's location, then why user need to register again before time period ends. And user needs to re-register only once before the time period or multiple times?? how long the users ip will be present in location server??
When a valid REGISTER is sent the SIP Registrar creates a binding for that user and stores it as an "Address of Record",
At a minimum this typically contains the SIP URI, the public IP and the time at which it expires, which is equal to the current time + the time in the SIP Expires header. This is referred to as "Adding a Binding" in the RFC.
After the time it expires has been reached the Address of Record is no longer valid and is generally dropped / deleted. Registrations are soft state and expire unless refreshed.
If another valid REGISTER is received before the expiry time is reached the Address of Record on the SIP Registrar is refreshed to reflect the new expiry time. This is called "Refreshing a Binding" in the RFC.
So in answer to your question:
how long the users ip will be present in location server??
Until the time the last valid REGISTER was received + the expiry time of the REGISTER is reached.
And user needs to re-register only once before the time period or multiple times??
A user only needs to send another valid REGISTER once before the binding expires to keep the binding in there as an Address of Record.
Further reading:
SIP: Session Initiation Protocol - RFC3261
Session Initiation Protocol (SIP) Basic Call Flow Examples - RFC 3665
What is a SIP
Registrar?
Related
When I have a FIX session between acceptor and initiator which side in general should be sending logout message first?
Also, is it fine to set session times on acceptor and initiator side to the same hours? Or maybe initiator should be configured for the shorter period to keep the communication safe and clear from errors?
Based on real project experience,
The connection was post trade feed, where our post trade gateways
used to connect with ECN (Electronic communication networks) like
Bloomberg, Tradeweb etc.
The ECN used to act as Acceptor and our gateways used to act as
initiator.
As initiator, its our gateways responsibility to initiate the
connection with ECN by sending LOGON message.
The gateways used to send LOGON and LOGOUT half an hour before/After
the markets open & closes respectively.
But in case there is some problem/error, even ECN used to send a LOGOUT message.
So, there is no hard and fast rule, who should send LOGOUT message.
I am currently working on a project that collect a users login and extension information through parsing SIP header messages after capturing packets. I am currently using PCAP.net and SIPSorcery libraries to accomplish this. The project is written in C#
How it works:
By using filters in PCAP.net I can zone in on the SIP related traffic. Each time a packet is captured an event is fired and I check for the packet type e.g. whether it is SIP or something else UDP related such as DNS. If this is a SIP message I parse the header pulling out the information I am interested in
The problem:
Some SIP endpoints generates multiple registration packets which contains the same UID. It is hard to keep track of a single session and when the endpoint is actually finally registered (i.e. receives the 200OK from the SIP Server). I tried using Dictionary with CallID and then checking when a packet is received if it is already in the Dictionary.
The question:
How do I keep track the session so I know when I receive the 200OK for that particular session, it is registered and stream is complete
A SIP endpoint sends a REGISTER request to bind its contact address(es) to an address-of-record. Such a registration is identified by the Call-ID header field.
Keep in mind that multiple REGISTER requests with the same Call-ID value can occur because:
the endpoint will periodically update its registration, since every registration has an expiration interval
a REGISTER request is challenged for authentication and the SIP endpoint sends a new request with authentication information.
retransmissions
Furthermore, a 200 response doesn't mean that the endpoint is registered. You should check the 'expires' header and/or contact parameter to know how long the registration will remain valid.
Call-ID field in the SIP message is used to track a SIP session. Check RFC 3261 to get more details about Call-ID.
Call-IDs act as unique identifier for a SIP session. In your case you can try searching the Call-ID from the SIP-REGISTER message to track the subsequent messages.
Scenario is regarding SIP register on LTE network.
Device latch with the network and sends SIP register with call id 4EdqB3YwpQHIYGPtj9c and CSeq no. 1
Network responded back with 401 unauthorized.
Device sends the register message with nonce value with call id 4EdqB3YwpQHIYGPtj9c and CSeq no. 2. and registration get successful.
Device reattach with the network. like switch off and on.
Device again sends REGISTER message with same call id 4EdqB3YwpQHIYGPtj9c and Cseq no. 1, for which receives 500 server internal error - 63 from the network.
After a while device again sends REGISTER message, this time call id is different 3Qp8ssj7hpKpspDn0mELU1v and cseq no. 1. after getting 401 response from n/w, resend REGISTER again which get successful as well.
My query is that:
Does after reattach cseq no. reset to 1?
Does after reattach, device should use different call id to initiate the REGISTER message?
What is the error code 63 means in 500 internal server error?
Thanks in advance
Does after reattach Cseq no. reset to 1?
A new SIP registration can start with any new random number. It can start with Cseq: 1 also. In the User equipment you are checking, it might be starting all new registrations with Cseq 1.
When a new registration is received at Sip-Registrar (i.e., S-CSCF in case of IP Multimedia Subsystem); a binding is created with Call-ID value. This brings us to the next question.
Does after reattach, device should use different call id to initiate the REGISTER message?
Registrations are time-bound and will expire after some time. Before that expiry, a Re-registration should be sent. This subsequent Register request should bind to that old registration at Sip-Registrar. For that we will maintain same call-Id. (and also same Contact, To, From, and From tag : which all headers and parameters used for binding is a different topic altogether; we will skip this for now.). According to RFC3261, A UA should use the same Call-ID for all registrations during a single boot cycle.
Coming to your case, It is not possible to guess why 500 Internal server error is sent for the new Register request having the same call-Id as the older register.
There is a possibility that the older binding is still be lingering at the Sip-Registrar and during detach, resource cleaning might not have taken place. This new registration might be be attaching to the older binding because of same call Id. (mind you this is just speculation, I am not sure what is happening at your Sip-Registrar)
What is the error code 63 means in 500 internal server error?
This number 63 is a proprietary implementation. In response, after 500, the text can be manipulated to add anything that creates a meaningful reason.
For further info on how registration is handled at SIP-Registrar you can go through the following RFC link:
https://www.rfc-editor.org/rfc/rfc3261#section-10.3
Regards,
KNP
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.