Subject: [Sipping] Multi-media messaging and SIP

From: "Jesus Javier Arauz \(E2/EEM\)" <[email-masked]>
Date: Mon, 22 May 2006 12:04:03 +0200

Hi,

In the SIP messaging specifications, the usage of MESSAGE is limited to
small, short messages while for longer messages like e.g. multi-media
messages including video, pictures etc. MSRP must be used instead.

MESSAGE has been retro-fitted with a capability that enables a user to
specify multiple destinations for a short message (see
draft-ietf-sipping-uri-list-message-07). This capabilty needs a
messaging server that explodes the list of destinations and sends the
short message to each destination. However, SIP-based MSRP does not
define that capability. The INVITE that initiates the MSRP session
cannot be targeted to mutiple invitees by the inviting user. The UA must
initiate the sessions individually to each destination and then send the
message to all the destinations. This may lead to either more complex
messaging client implementations in UA or cumbersome usage in comparison
to the short messaging client.

One case where this lack of capability is notorious is in SMS/MMS/IMPS
interworking with IMS. When a GSM user sends an SMS to multiple
destinations this can be directly mapped by the interworking function to
a MESSAGE request including all the destinations in the request.
However, when a GPRS user sends an MMS to multiple destinations, the
interworking function must take care of initiating the SIP and MSRP
sessions, send the message over all sessions and then releasing those
sessions. The same goes for IMPS.

I think it would be advantageous to retro-fit session-based messaging
with the same capability as short messaging. One possible alternative
would be to allow the same MIME body defined in
draft-ietf-sipping-uri-list-message-07 in INVITE requests for MSRP
sessions. However this may not seem appropriate since it impacts a
rather basic message of the SIP specification. Any other alternative
would require defining a new mechanism specific for long, multi-media
messages, like e.g. content indirection.

I wonder if there've been some discussions on this issue already? What's
the oppinion of the sipping community on it?

Best regards,
/Javier Arauz

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 22 May 2006 09:34:56 -0400

On Mon, 2006-05-22 at 12:04 +0200, Jesus Javier Arauz (E2/EEM) wrote:
> specify multiple destinations for a short message (see draft-ietf-
> sipping-uri-list-message-07). This capabilty needs a messaging server
> that explodes the list of destinations and sends the short message to
> each destination. However, SIP-based MSRP does not define that
> capability. The INVITE that initiates the MSRP session cannot be
> targeted to mutiple invitees by the inviting user. The UA must
> initiate the sessions individually to each destination and then send
> the message to all the destinations. This may lead to either more
> complex messaging client implementations in UA or cumbersome usage in
> comparison to the short messaging client.

I'm not familiar with the details of MSRP, but I do not see why a forked
INVITE cannot carry an MSRP set-up offer to more than one destination,
each of which will reply with an MSRP set-up answer, thus setting up a
set of MSRP sessions.  (In exactly the same way that a single INVITE can
establish multiple SDP sessions.)

Oops, well, yes, you have to make sure the proxies that do the forking
do not attempt to cancel all-but-one successful branch of the fork.  But
that's a known problem that applies to a lot more situations than
setting up MSRP sessions.  See, e.g., draft-worley-sipping-forking-00
for a discussion, especially section 3.6.

Dale

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 May 2006 11:23:47 -0400

> sessions. The same goes for IMPS.

Beacuse MSRP is inherently session-oriented, I don't think you're going 
to get around having to initiate and release SIP/MSRP sessions.

To simplify the internetworking function, perhaps what needs to be done 
is to define a way for MSRP relays to act as URI-list services.  That 
way, the internetworking function could:
1. Send a forked INVITE to all recipients
2. Gather responses and construct URI-list
3. Send message and URI-list to URI-list Service
The URI-list Service could then forward the message to all the 
recipients and relay MSRP REPORTs back to the internetworking function, 
who could then send BYE requests to close the SIP sessions.  Given the 
constraints that MSRP is session-oriented (hence requires 
initiation/release), I think that's about as simple as it can get.

(Actually, adding such a URI-list capability to MSRP relays seems like a 
good idea in general, since it would simplify the implementation of 
multi-party chat.)

Hope this helps,
--Richard

> ------------------------------------------------------------------------
>