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.
Related
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.
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.
in RFC6314, section 5.2.1.2, it mentions that after Client_L collected its candidate list, it sends INVITE to Client_R with the list, and then both ends can start connectivity check.
I have a question is that why Client_L can send INVITE to Client_R? or why Client_R can receive those data (candidate list)? I think in this time Client_L should have no address info of Client_R. Thanks your answer in advanced.
https://www.rfc-editor.org/rfc/rfc6314#section-5.2.1
In order for clients to establish a P2P ICE session, they have to rendezvous through a reliable signaling server. The signaling server exists for clients to exchange address candidates in order for ICE negotiation to actually begin. This is typically a SIP server. Although ICE allows for almost anything to be used for exchanging addresses.
When the INVITE is sent out, it gets sent to a server that knows how to forward that message to the other client. When the remote client gets the INVITE, it responds back with a series of SIP messages - one of which is the "180 RINGING" or "200 OK" message that contains the address candidates from the client that received the INVITE.
Usually, the Contact header field in the Invite request is useless. For example, the UAC and the UAS are in different LANs. The Contact field may be:
INVITE sip:bob#sipprovider SIP/2.0
Contact: Alice<alice#192.168.1.10>
.....
There is no use of the Contact field while we can still build a dialog. Then, why the Contact header field is mandatory？
The Contact header says where you are (or rather, where your User Agent is), while the From header says who you are.
You might have several SIP devices all registered to the same Address of Record (the URI you put in the From header).
Further, REGISTER requests use Contact headers to maintain SIP's location service: they let a user agent update a registrar's location information.
(As an aside, if Alice calls Bob, the Contact header needs to be in a 2xx response so that Alice can route the 2xx's ACK to Bob. This points to DarkDust's comment about some SIP proxies mangling Contact headers: if it doesn't, you find yourself in the uncomfortable position of having a call that's only half established: Alice thinks the call's set up because she sent her ACK, but Bob never receives it. An alternative to a Contact-mangling Proxy is using a B2BUA as a network gateway; it wouldn't need to mangle the Contact header because the header would point to the B2BUA itself.)
In response to Phoenix Luo's comments, because of the shortcomings of using LAN IPs in a Contact header, RFC 5627 describes a solution - using globally routable user agent URIs
(GRUUs) in the Contact header/s.
The contact field contains the address at which the callee can reach the caller for future requests. For example, it's necessary so that the callee can send a BYE or a re-INVITE to the caller.