SIP Learning Part II - Generating SIP Request Essential Headers

From Header

From header indicates logical identify of the initiator of the request, possibly the user’s address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by the SIP elements to determine which processing rules to apply to a request for e.g. automatic call rejection. As such, the from uri should not contain the IP address or FQDN of the host on which the UA is running, since these are not logical names. 

If the identity of the client to be hidden, UA should use the “Anonymous” word for the display name and an invalid but yet syntactically correct sip address for e.g. thesis@anonymous.invalid 

The From header field MUST contain a new “tag” parameter, chosen by the UAC. 

Some of the examples of From header area below 

From : “Bob” ; tag=148s

From : sip+12312321@phone2net.com;tag=23432

From: Anonymous ; tag=hysa

Call - ID

Call ID header field acts as a unique identifier to group together a series of messages. It must be the same for all the requests and responses sent by either UA in a dialog. IT should be the same in each registration from a UA. 

In a new request created by a UAC of any dialog, the call-id header field must be selected by the UAC as a globally unique identifier over space and time unless overridden by the method specific behaviour. If suppose a 401 error is received by the UA and then a retry is done with correct authorisation, then the call id should not change. 

Use of cryptographycally random identifiers in the generation of Call-IDs is recommended. Implementation may use localid@host. Call ids are case sensitive and are just compared byte by byte. 

e.g. for Call ID is Call-ID : fasdas-sdasd-sd@foo.bar.com

references:

https://www.ietf.org/rfc/rfc3261.txt 

SIP Learning Part I - Essential Headers

For a valid SIP request, there are 6 header fields at least minimum required. They are To, From, CSeq, Call-ID, Max-Forwards, and Via. These headers are in addition to the Request line, which contains the method, Request-URI, and SIP version 

Request - URI 

The initial Request-URI should be set as the value of URI in the To Field. One notable exception is the REGISTER method. In some circumstances, the presence of pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly they are configured on a UA with the by user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is recommended that this be done by providing it with a pre-existing route set with a single URI, that of outbound proxy. 

When a pre-existing route set is present, the procedure for populating the request-URI and route header field detailed in section 12.2.1.1. must be followed using the desired Request-URI as the remote target URI. 

To Header

The To header field first and foremost specifies the desired “logical” recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header may contain SIP or SIPS URI, but it may also make use of other URI schemes. e.g. tel when appropriate. The To header field also allows display name. 

The UAC can form the To header in a number of ways. either via human interface perhaps inputting manually or from a contact lis. Using the string to form the user part of the SIPS URI implies tat the UA wishes to communicate securely and that name to be resolved in the domain to the RJS of the at sign. The RHS will be frequently be the home domain of the requester, which allows for the home domain to process the outgoing request. This is useful for features like speed dial that requrire interpretation of the user part in the home domain. The tel uri may be used when the UA does not wish to specify the domain that should interprest a telephone nu,her that has been input by the user. 

A use case would be a user in an airport might log in and send requests through an outbound proxy in the airport.If they enter 411 (local directory assistance in US) that needs to be interpreted and processed by the outbound proxy in the airport, not the user’s home domain. In this case, tel:411 would be right choice. 

A request outside of a dialog MUST not contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog established, no tag is present. 

References:

https://www.ietf.org/rfc/rfc3261.txt

WiFi Calling on iOS 8.x

From iOS 8.0 onwards Apple has introduced WiFi Calling on iOS 8.0 devices and that can be enabled via the below settings 

- Settings > Phone > Wi-Fi Calling 

- Toggle the Wi-Fi calling switch to ON

- If the carrier does not have the user’s registered emergency address, one will be asked to add it before the feature is activated. 

was browsing through the API additions in iOS 8.0 and finds that there are a few such as 

However, there did not seem to have a way to capture the QoS or packet rate on the device. 

On the Router, we could probably set the QoS like mentioned below 

https://support.t-mobile.com/message/424035

https://support.t-mobile.com/message/423951#423951

References: 

https://developer.apple.com/library/prerelease/ios/releasenotes/General/RN-iOSSDK-8.0/ => Instruction for enabling the wiFi calling. 

http://9to5mac.com/2014/06/02/t-mobile-confirms-wifi-calling-arriving-for-iphone-users-with-ios-8/ 

WiFi Signal Strength in iOS

As part of a project, had to investigate if we can get wifi signal strength. and it looks like for 3rd party developers no APIs are exposed to do this function. 

However, there are few apps out there which can detect the signal strength by other secondary factors, such as networkk throughput. such as speedtest.net

Another App is Network Multi meter uses the similar design but displays the information in real time as a user walking around the house. these apps does this by

actual data through put and network ping. 

REferences:

http://www.ilounge.com/index.php/articles/comments/measuring-wi-fi-signal-strength-from-ios 

http://stackoverflow.com/questions/21715690/measuring-signal-strength-from-wifi-to-iphone-ipad

REGISTER processing at the registrar end

There are mainly 8 steps in processing the REGISTER message at the registrar end. 

1. The registrar inspects the Request-URI to determine whether it has access to bindings for domain identified in the Request-URI. If not, and if the server also acts as proxy server, the server SHOULD forward the request to the addressed domain, following the general behaviour for proxying messages described in section 16 of https://www.ietf.org/rfc/rfc3261.txt 

2. To guarantee that the registrar supports any necessary extension, the registrar MUST process the Require header field value as described for UAS in section 8.2.2 of https://www.ietf.org/rfc/rfc3261.txt 

3. A Registrar SHOULD authenticate the UAC. Mechanism for the authentication of SIP user agents are described in section 22 of https://www.ietf.org/rfc/rfc3261.txt . The Registrar behaviour in no way overrides the generic authentication framework for SIP. IF no authentication mechanism available, the registrar MAY take the from address as the asserted identity of the originator of the request. 

4. The registar SHOULD determine if the authenticated user is authorised to modify registrations for this address-of-record. For e.g. a registrar might consult an authorisation database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorised to modify bindings, the registrar MUST return 403 (forbidden) and skip the remaining steps. 

In architectures that support third party registration, one entity may be responsible for updating the registrations associated with the multiple addresses-of-record. 

5. The registrar expected the address-of-record from the To header of the request. If the address-of-record is not valid for the domain in the request URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI must then be converted to canonical form. To do that, all URI parameters MUST be removed (including the user-param) and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. 

6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the contact header field is present, the registrar checks if there is one Contact field value that contains the special value “*” and an expires field. If the request has additional contact fields or an expiration time other than zero, the request is invalid and the server MUST send a 400 Invalid request and skip the remaining steps. If not, the registrar checks the Call-ID agrees wit the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise the update MUST be aborted and the request fails. 

7. The Registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows. 

- If the field value as an expires parameter, that value MUST be taken as the requested expiration 

- IF there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration. 

- IF there is neither, a locally-configured default value MUST be taken as the requested expiration. 

The registrar may choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero and smaller than one hour AND less than a registrar—configured minimum, the registrar MAY reject the registration with a response 423 (Interval too brief) This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honour. It then skips the remaining steps. 

Allowing the restorer to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreaging the likelyhood of registrations going stale. The expiration interval of registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore registrats should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance. 

For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the bindings does not exist, it is tentatively added. IF the binding does exist, the registrar checks the call - ID value. If the call - ID value in the existing binding differs  from the call - id value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compare the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not , the update MUST be aborted and the request fails. 

This algoritm ensures that out-of-order requests from the same UA are ignored. 

Each binding updates MUST be committed ( that is , made visible to the proxy or redirect server) if and only if all binding updates and the additions succeed. IF any one of them fails (for e.g. because the backend databse commit failed) the request MUST fail with 500 (Server error) response and all tentative bindings updates MUST be removed. 

8. The registrar returns 200 OK response. The response MUST contain contact header field values enumerating all current bindings. Each contact value must feature and expires parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. 

Refernces: 

https://www.ietf.org/rfc/rfc3261.txt

IMS Architectural components - Part II CSCF

CSCF - Call Session Control Function 

Several roles of SIP proxies are collectively called as CSCF which are used to process SIP signalling packets in IMS. 

Proxy-CSCF (P-CSCF) is a SIP pro that is the first point of contact for the IMS terminal. it can be located either in the visited network (in full IMS networks) or in the home network (when the visited network is not IMS Compliant yet) . Some networks may use SDB for this function. The P-CSCF is at the core a specialised SBC for the User-Netwrok interface which not only protected the network but also the IMS terminal. The use of an additional SBC between the IMS terminal and the P-CSCF is un-necessary and infeasible due to the signalling being encrypted on this leg. The terminal discovers its P-CSCF with either DHCP, or it may be configured (e.g. during initial provisioning or via 3PP IMS management Object (MO)) or in the ISIM or assigned in the PDP context (in GPRS) 

- It is assigned to an IMS terminal before registration, and does not change for the duration of registration. 

- It sits in the path for all the signalling and can inspect every signal; the IMS terminal must ignore must ignore any other unencrypted signalling. 

- It provides subscriber authentication and may establish IPSec or TLS security association with the IMS terminal. This prevents spoofing attacks and replay attacks and protects the privacy of the subscriber. 

- It inspects the signalling and and ensures that the IMS terminals do not misbehave (e.g. change the signalling routes, do not obey home networks routing policy) 

- It can also compress and de-cpmpress SIP messages using SigComp, which reduces the round trip over the slow radio links. 

- It may include a policy decision function (PDF) which authorises the media plane resources for e.g. QoS over the media plane. It is used for policy control, bandwidth management, etc. The PDF can also be a separate function. 

- It also generates charging records. 

References: 

http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

Trying out Quick start for IMSDroid

First of all, it required to have SIP account created. The site is recommending to use sip2sip.info website for creating an account. The registration page is given in the references.

After creating the account, it sent a mail with the details for accessing it. 

Next was SIP configuration 

The page for sip configuration for each of the server services were given separately, and for the sip2sip it was https://code.google.com/p/imsdroid/wiki/sip2sip_info 

The setup was quite straight forward, once after getting the sip credentials from sip2sip.info.,

wen into the Indentity tab and configured Display name, public identity, private Identity, password, realm, 

and in the network setting, Proxy-CSCF host, port, transport as UDP. 

a screenshot after it logged in given below

03-12 07:53:36.349    4769-5787/? I/tinyWRAP﹕ *INFO:

    RECV SIP Message:SIP/2.0 401 Unauthorized

    Via: SIP/2.0/UDP 192.168.1.2:55102;received=115.118.146.17;branch=z9hG4bK1661612924;rport=55102

    From: ;tag=1006014735

    To: ;tag=e7d4d6b46afb9bf88242924a8d869ebf.4922

    Call-ID: 323cff89-1b8f-7462-e9cd-c69cec5edebc

    CSeq: 1540698044 REGISTER

    WWW-Authenticate: Digest realm="sip2sip.info", nonce="5500f955101f5690fa5e3815cbe0de726e8a61d4"

    Server: SIP Thor on OpenSIPS XS 1.9.0

    Content-Length: 0

03-12 07:53:36.350    4769-5787/? I/tinyWRAP﹕ *INFO: State machine: tsip_dialog_register_InProgress_2_InProgress_X_401_407_421_494

03-12 07:53:36.351    4769-5787/? I/tinyWRAP﹕ *INFO:

    SEND SIP Message:REGISTER sip:sip2sip.info SIP/2.0

    Via: SIP/2.0/UDP 192.168.1.2:55102;branch=z9hG4bK1246479370;rport

    From: ;tag=1006014735

    To:

    Contact: ;expires=1700;+g.oma.sip-im;language="en,fr";+g.3gpp.smsip;+g.oma.sip-im.large-message;audio;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-vs";+g.3gpp.cs-voice

    Call-ID: 323cff89-1b8f-7462-e9cd-c69cec5edebc

    CSeq: 1540698045 REGISTER

    Content-Length: 0

    Max-Forwards: 70

    Authorization: Digest username="mrrathish",realm="sip2sip.info",nonce="5500f955101f5690fa5e3815cbe0de726e8a61d4",uri="sip:sip2sip.info",response="f114c73ee9b5eb724fd0c6b032c05674",algorithm=MD5

    Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFER

    Privacy: none

    P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000

    User-Agent: IM-client/OMA1.0 android-ngn-stack/v2.0.491 (doubango r701 - Spice Mi-498)

    P-Preferred-Identity:

    Supported: path

03-12 07:53:36.352    4769-5786/? D/org.doubango.ngn.services.impl.NgnSipService﹕ OnDialogEvent ((un)REGISTER request successfully sent.,1)

03-12 07:53:36.556    4769-5787/? I/tinyWRAP﹕ *INFO:

    RECV SIP Message:SIP/2.0 200 OK

    Via: SIP/2.0/UDP 192.168.1.2:55102;received=115.118.146.17;branch=z9hG4bK1246479370;rport=55102

    From: ;tag=1006014735

    To: ;tag=e7d4d6b46afb9bf88242924a8d869ebf.7c4f

    Call-ID: 323cff89-1b8f-7462-e9cd-c69cec5edebc

    CSeq: 1540698045 REGISTER

    Contact: ;expires=1700;received="sip:85.17.186.7:5060;target=%73%69%70:%31%31%35.%31%31%38.%31%34%36.%31%37:%35%35%31%30%32"

    Server: SIP Thor on OpenSIPS XS 1.9.0

    Content-Length: 0

    @x;T0

References

Sip2Sip Register: https://mdns.sipthor.net/register_sip_account.phtml

https://code.google.com/p/imsdroid/

https://code.google.com/p/imsdroid/wiki/Quick_Start