SIP is similar to HTTP in structure and a lot of protocol concepts are borrowed from HTTP (and SMTP) work.  A SIP request has a URI followed by a number of SIP headers and then an optional content. This is similar to a HTTP request in structure. However, the goals of SIP are quite different from that of HTTP, while HTTP is basically a protocol for content access and management; SIP is a protocol for two or multiparty session establishment where various type of media can be exchanged. In simple terms SIP is a protocol used to establish IP calls between two end points for voice and other rich multimedia exchange, SIP can also be used for other purposes like exchange of call related information, subscription and notification of state between two user agents, content and capability negotiation etc. In essence SIP is peer to peer while HTTP is essentially client server.
The quest for new and powerful applications have brought the telecom world closer to the web world and has led to opening up of new interfaces to these applications.  For now let me talk about converged applications.

Converged applications

A converged application is one that speaks several protocols and enables a powerful application traversing these disparate protocol interfaces. As an example consider a click to call application, here the application receives an HTTP request and sends out a SIP request (or two SIP request in 3rd party call control situation), when the call connects it may send the result back to HTTP browser in response or even send periodic updates using Ajax. Or as another example on getting a SIP request the application issues a Diameter Sh get request to access some data on the HSS in IMS use case and then on receipt of the data completes the call accordingly. The core idea is that the application itself is capable of managing these different protocol interactions. A good example would be a JSR 289 capable SIP Servlet application that can receive both HTTP and SIP requests in the context of same application session. The application session maintains state on a protocol session basis and allows application to use the information across.
Typically these converged applications are useful within the provider network to talk to various network elements that speak these different protocols. When it comes to exposing a telecom application to outside applications some more safeguards are required and typically would be accomplished in a different framework. However, converged application and converged container would play a key role in these situations as well. This leads us to our next topic mashups.

Mashups

Mashups have been around for a while and are basically enabling exciting new applications on the web. The Web2.0 is finally delivering the promise of webservices where one application behind the scenes aggregates information and data from various other webservices and overlays the data with interesting intersection and association to present a new facet to the user. If you search for the location of your favorite departmental store on their website and see the stores on a Google map then you are seeing an example of a simple mashup where location information is overlaid on Google maps.
The essential constituent of a Web2.0 mashup is a webservices (most likely REST style) API that allows the client (in the above example your departmental store website) to access content (Google map in this example).  The common trend of these APIs is simplicity and ease of use and most of these APIs have chosen REST based interfaces. So it is a simple HTTP request with URL defining the target resource and request method defining the action.
I previously mentioned that mashups typically involve something more than just converged applications and that is because of the security considerations.
If you are exposing your telecom application to be used in a mashup then you will expose it as a webservices  interface (most like RESTful) where the request first comes to an authentication proxy that manages these webservices interactions and after authenticating the user, applies any kind of policy to the request, only then the request may be forwarded to your application. The webservices request may not be sent over as is but may be converted into a simpler HTTP request or even something else like a message posted to a queue towards your application. The way in which these requests are handled internally by the application is opaque to the external client who only uses the webservices API to create a mashup.

What can SIPr do?

Well SIPr as you know is a converged SIP testing framework and it enables you to on one hand manage SIP and HTTP interaction from the same session, on the other hand it is also capable of generating webservices requests. This makes SIPr an ideal choice for testing complex applications that involve mashups.
So if I were to test or simulate an application that involves a webservices exposure layer to a telecom application – say the much used click to call then -

1. I would use SIPr test script to create a couple of SIP UAs that register with the provider registrar
2.  From the same script I would generate a HTTP based REST request using SIPr HTTP APIs for Click to call
3.  I would then receive SIP INVITEs to both my UAs which I will then accept completing 200/ACK SIP flow and thus verify the completion of the call.
4. I could then write another test that checks out other APIs like call forwarding, do not disturb etc
5. I could also access a database from the same script and validate the call flow based on some database interactions.

Bottom-line is that with SIPr it is extremely easy to write converged test cases and exercise mashups with simple scripting and write them fast.