Tag Archives: RFC 3261

SIP SIMPLE – Instant Messaging with SIP

Kamailio, RFCs & Standards, VoIP, , , , , , , ,

People think SIP they think VoIP & phone calls, but SIP it’s the Phone Call Initiation Protocol it’s the Session Initiation Protocol – Sure VoIP guys like me love SIP, but it’s not just about VoIP.

Have you sent an SMS on a modern mobile phone recently? Chances are you sent a SMS over SIP using SIP MESSAGE method.

So let’s look a bit at SIP SIMPLE, the catchily titled acronym translates to Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (Admittedly less catchy in it’s full form).

There’s two way SIP SIMPLE can be used to implement Instant Messaging, Paging Mode with each message sent as a single transaction, and Session Mode where a session is setup between users and IMs exchanged with the same Call ID / transaction.

I’m going to cover the Paging Mode implementation because it’s simpler easier to understand.

Before we get too far this is another example of confusing terminology, let’s just clear this up; According to the RFC any SIP request is a SIP Message, like a SIP OPTIONS message, a SIP INVITE message. But the method of a SIP INVITE message is INVITE, the method of a SIP OPTIONS message is OPTIONS. There’s a SIP MESSAGE method, meaning you can send a SIP MESSAGE message using the MESSAGE method. Clear as mud? I’ll always refer to the SIP Method in Capitals, like MESSAGE, INVITE, UPDATE, etc.

The SIP MESSAGE Method

The basis of using SIP for instant messaging relies on the MESSAGE method, laid out in RFC 3428.

The SIP MESSAGE method looks / acts very similar to a SIP INVITE, in that it’s got all the standard SIP headers, but also a Message Body, in which our message body lives (funny about that), typically we’ll send messages using the Content-Type: text/plain to denote we’re sending a plaintext message.

Example MESSAGE Message Flow

Like a SIP OPTIONS Method, the MESSAGE method is simply answered with a 200 OK (No Ack).

Let’s have a look at how the MESSAGE message looks:

MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18

Hello world.

After receiving the SIP MESSAGE message, the recipient simply sends back a 200 OK with the same Call-ID.

Simple as that.

You can read more about the SIP MESSAGE method in RFC 3428.

I used the SIP MESSAGE method in a Kamailio Bytes example recently where I sent a MESSAGE to an IP phone when a HTTP GET was run against Kamailio, and again to send an alert when an emergency services destination was called.

SIP Extensions – Path

RFCs & Standards, VoIP, , ,

In vanilla RFC3261 SIP, a UA can only send a REGISTER request to a SIP Registrar.

It can’t go via any intermediary proxies.

That’s obviously a bit of a problem, as we build out our network we might have a series of load balancers that send traffic to a pool of Registrars, but according to RFC3261 this can’t be done, the SIP REGISTER request would need to go direct to one of these Registrars.

To get around this the SIP Path extensions, officially called “Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts” (catchy title) was defined under RFC 3327.

An additional header is introduced called “Path:” for each proxy between the UA and the Registrar,

As the SIP REGISTER request passes through each proxy, each proxy appends the Path header with the value of it’s own SIP URI.

Let’s take a look at an example call flow from [email protected] who sends his REGISTER to atlanta.com, which is proxied by atlanta.com to registrar1.atlanta.com:

Bob to atlanta.com:

[email protected] > atlanta.com
      REGISTER sip:atlanta.com SIP/2.0
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Bob <sip:[email protected]>
      From: Bob <sip:[email protected]>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <Bob <sip:[email protected]>>
      Supported: path

The REGISTER request is received by atlanta.com, which forwards it to registrar1.atlanta.com after adding it’s own URI as a Path header.

atlanta.com > registrar1.atlanta.com
      REGISTER sip:atlanta.com SIP/2.0
      Via: SIP/2.0/UDP atlanta.com;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Bob <sip:[email protected]>
      From: Bob <sip:[email protected]>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <Bob <sip:[email protected]>>
      Supported: path
      Path: <sip:atlanta.com;lr>

The response is sent back in the same way, relying on the via headers and Path headers.

SIP REGISTER status & why it’s not what you think it is.

RFCs & Standards, VoIP, , ,

I can see it’s registered, but when I call it it’s not ringing, what’s wrong?

Support team

It’s a question I get every so often, and it generally comes down to a misunderstanding in the way the SIP Register mechanism works.

When a UA registers to a SIP server it includes an “Expires:” header, which means it’s registration will expire after that time.

It doesn’t mean it’ll be active that whole time, just that for the time specified it intends to be at that address, but life, and networks, often have other plans.

Let’s jump out of SIP for a minute and imagine you’re going to give me a package, I leave you a note saying:

I’ll be waiting outside the station in a trench-coat under the lamp post between 7:00 and 7:15

You get there at 7:12 but you can’t deliver the package. I’m nowhere to be seen.

The note I left says I’ll be there during that time, but I’ve disappeared, and no you can’t hand the package to me.

Just because you have a note saying I’ll be there, doesn’t mean I still will be. It was my intention to be there, but I’m obviously not.

The SIP register is the same as the note left on the desk. I intended to be there, but I’m now obviously not, and I haven’t had a way to reach you to let you know this has changed, or I myself don’t know.

You see this in SIP from time to time, generally it’s due to the connection the UA is coming from dropping or it’s public IP changing.

For example, a REGISTER is sent with an Expires of 3600 seconds (An hour) to a SIP switch from IP address 1.2.3.4.

Half an hour later your connection drops.

As far as the SIP switch is concerned it’s going to send any incoming messages to 1.2.3.4, as 1.2.3.4 said it’d be there for the next hour.

So even though the connection is dropped to 1.2.3.4 the SIP Switch has no way of knowing this and continues to forward any traffic for that user to 1.2.3.4 until the 3600 seconds is up since it last tried to REGISTER.

Same thing could happen if our UA is behind a NAT and the external IP changes or the connection is changed. The UA doesn’t know anything has changed, so no REGISTER is sent to refresh, and messages from the SIP server are sent to the old address.

A lot of SIP switching platforms allow you to view register status, but just keep in mind it doesn’t mean the device is still answerable at that address, only that it intended to be.

Further reading:

https://tools.ietf.org/html/rfc3261#section-10

https://tools.ietf.org/html/rfc3665#section-2.1