As i understand it the UAC is defined as the entity that creates a new request, and UAS as the entity that repsonds to that request.
In the event of a UAS creating and sending a re-invite for an existing session, does it then take over the role of UAC?
TL;DR, Yes, a SIP endpoint can be a User Agent Client/Server, the role is assumed during the INVITE transaction (i-e request-response).
About your example, (re-)INVITE is just an INVITE invoked inside an existing dialog created by a out-of-dialog/initial INVITE ; both are INVITE methods by the way and thus the client is the emiter of INVITE and the receiver is then the server.
Another common example is a SIP phone ; A telephone is a UAC when it sends an INVITE creating a new dialog but also a UAS because it accepts INVITE requests in order to ring the telephone. One can say a SIP phone is by nature a User Agent Client Server - UACS.
The general and more abstract definition is around those lines, if a user-agent has dual roles UAS and UAC then the role is switch from one to the other during the coresponding transaction. In term of SIP protocol, UAC and UAS roles are logical only and an entity role is relevant during current transaction.
However, it is possible to have SIP entities which are only UAC or UAS, one use-case is notification where an entity is sending NOTIFY (UAC) and another is only receiving NOTIFY (UAS).
At that point we may conclude that client/server roles are valid only during a transaction.
Perfectly true from a Protocol perspective but not in the pratical case of B2BUA where two UAC/UAS are acting at the same time for the same invoked method but on two separated transactions. To be fair, B2BUA was not part of SIP RFCs.
Related
When my system is doing an invite, in the request line I have "sip:nnnnn#domain;user=phone" but when it does a re-invite it drops the user=phone and looks like "sip:nnnnn#domain".
My question is this normal behaviour? I have a supplier complaining but from what I gather from RFC 3261 as its in the same dialog this is fine. Is this correct?
Thanks
The meaning of 'user=phone' is to specify that the user-part of the URI should be interpreted as a telephone number (tel-URI). This information can be useful when establishing a connection. For re-invites it has no added value since the connection between the endpoints is already in place.
Furthermore is it normal that the Request-URI for an invite differs from the Request-URI for a re-invite. The Request-URI used for an invite usually is an address-of-record, e.g. from a phone book. The invite will establish a connection with a specific SIP instance (endpoint). This SIP endpoint returns its contact address in the (final) response, and sometimes a route-set. The contact address is the remote target for the dialog. The remote target and route-set must be used to build the Request-URI for subsequent re-invites (see RFC3261).
I think (without message examples) your system is handling this the right way. If your supplier insists on re-invites having a Request-URI containing 'user=phone' it should include this parameter in the contact addresses for its phones.
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.
Sorry, if this is a repeated question.
I am using FreeSwitch which uses Nokia Sofia SIP stack.
It allows me to register multiple endpoints using one user credentials.
e.g. I can log in using user id 1000 with multiple devices.
I want to know whether SIP RFC 3261 allows multiple endpoints registered to one account or not?
Update me about this.
RFC 3261 States - 10.2.1 Adding Bindings
Once a client has established bindings at a registrar, it MAY send
subsequent registrations containing new bindings or modifications to
existing bindings as necessary. The 2xx response to the REGISTER
request will contain, in a Contact header field, a complete list of
bindings that have been registered for this address-of-record at this
registrar.
These additional bindings allow users to register as many endpoints to their registration with the REGISTRAR.
Not sure about that specific RFC, but most VoIP providers allow to log in with the same account from multiple devices
Yes, RFC 3261 allows multiple endpoints registered to one account.
For instance, you can have three SIP phones, one running at work, one at home, and one on your smartphone.
Then you register all SIP phones using the same account, but with different Contact header addresses.
Each Contact can have a "q" parameter, which indicates a preference level.
So when a call arrives in PBX, it can send the INVITE to the most preferable contact (highest "q" parameter), and if this contact does not answer, the PBX can try the contact with the second highest "q" parameter, and so on.
RFC 3261: 10.2.1.2 Preferences among Contact Addresses
If more than one Contact is sent in a REGISTER request, the
registering UA intends to associate all of the URIs in these Contact
header field values with the address-of-record present in the To
field. This list can be prioritized with the "q" parameter in the
Contact header field. The "q" parameter indicates a relative
preference for the particular Contact header field value compared to
other bindings for this address-of-record.
"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.
I am just curious, what is the fundamental reason to have 200 OK responses from a remote end point to be ACKed by the local end point? RFC 3261 states that it is needed for stability purposes but does not go into details. The only reason that comes to my head is the case with call forking. So, if an AOR is registered at multiple end points and these end points respond simultaneously with a 200 OK message, then an ACK will actually indicate which of the remote parties will participate in a peer-to-peer connection. Is there any other reason to end and INVITE hand shake with an ACK?
It's because SIP needs some responses (only INVITE responses in practise) to be reliably transmitted in situations where the underlying transport is unreliable, such as with UDP.
The ACK request is the way for the (UAC User Agent Client) to let the UAS (User Agent Server) know that it received the final response to an INVITE request. Without employing something like the ACK request there would always be the risk that the UAS response would not get through to the UAC and the call would be left sitting in an incorrect state.
The ACK request doesn't have any specific role in call forking. In the case you've described in a call with multiple end points BYE requests will be sent to any call legs that are not required. ACK requests still need to be sent to any UAS that responds irrespective of whether the UAC wants that call leg to proceed or not.