Subject: [Sipping] Re: Multi-media messaging and SIP

From: "Jesus Javier Arauz \(E2/EEM\)" <[email-masked]>
Date: Thu, 25 May 2006 15:37:15 +0200

OK, forget it. It's already done:
draft-ietf-sipping-uri-list-conferencing-05

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: lunes, 22 de mayo de 2006 18:00
To: [email-masked]
Subject: Sipping Digest, Vol 25, Issue 24

Send Sipping mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sipping
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Sipping digest..."

Today's Topics:

   1. Dialog usage and RFC 4488 (Christer Holmberg (JO/LMF))
   2. Multi-media messaging and SIP (Jesus Javier Arauz (E2/EEM))
   3. Re: Multi-media messaging and SIP (Dale R. Worley)
   4. RE: Dialog usage and RFC 4488 (Michael Hammer (mhammer))
   5. Re: Multi-media messaging and SIP (Richard Barnes)
   6. Re: "Services" (Dean Willis)
   7. Re: "Services" (Juha Heinanen)

----------------------------------------------------------------------

Message: 1
Date: Mon, 22 May 2006 09:23:37 +0200
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Subject: [Sipping] Dialog usage and RFC 4488
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="us-ascii"

Hi,

My understanding is that when RFC 4488 is used, the REFER does not
create a subscription dialog usage.

Would it be good to mention in the dialog usage document, or is it "too
obvious"?

Regards,

Christer

------------------------------

Message: 2
Date: Mon, 22 May 2006 12:04:03 +0200
From: "Jesus Javier Arauz \(E2/EEM\)"
	<[email-masked]>
Subject: [Sipping] Multi-media messaging and SIP
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sipping/attachments/20060522/b527d788/att
achment.html

------------------------------

Message: 3
Date: Mon, 22 May 2006 09:34:56 -0400
From: "Dale R. Worley" <[email-masked]>
Subject: Re: [Sipping] Multi-media messaging and SIP
To: Sipping <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain

On Mon, 2006-05-22 at 12:04 +0200, Jesus Javier Arauz (E2/EEM) wrote:
> 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.

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

------------------------------

Message: 4
Date: Mon, 22 May 2006 09:49:42 -0400
From: "Michael Hammer \(mhammer\)" <[email-masked]>
Subject: RE: [Sipping] Dialog usage and RFC 4488
To: "Christer Holmberg \(JO/LMF\)" <[email-masked]>,
	<[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Add it.  It is only obvious now because it is fresh in memory.

Be thorough now and avoid newbie questions later.

Mike

> -----Original Message-----
> From: Christer Holmberg (JO/LMF)
> [mailto:[email-masked]]
> Sent: Monday, May 22, 2006 3:24 AM
> To: [email-masked]
> Subject: [Sipping] Dialog usage and RFC 4488
> 
>  
> Hi,
> 
> My understanding is that when RFC 4488 is used, the REFER does not 
> create a subscription dialog usage.
> 
> Would it be good to mention in the dialog usage document, or is it 
> "too obvious"?
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> 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
> 

------------------------------

Message: 5
Date: Mon, 22 May 2006 11:23:47 -0400
From: Richard Barnes <[email-masked]>
Subject: Re: [Sipping] Multi-media messaging and SIP
To: "Jesus Javier Arauz (E2/EEM)" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> 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.

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

> 
> 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

------------------------------

Message: 6
Date: Mon, 22 May 2006 10:25:20 -0500
From: Dean Willis <[email-masked]>
Subject: Re: [Sipping] "Services"
To: Juha Heinanen <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On May 19, 2006, at 2:09 AM, Juha Heinanen wrote:

> [email-masked] writes:
>
>> I agree with you that "forking" (and other retargeting) is not useful

>> in a Proxy (serving the AOR). Given that the AOR routes to 1 UA, the 
>> UA is far more capable of deciding what needs to be done.
>
> are you really saying that it is not useful to have more than one 
> contact registered for an AoR?  if so, then that is not my users are 
> telling me.  they want proxy to fork requests so that their phones 
> ring according to the order specified by q value.
>

Of course, this can be done by having the proxy respond with a q- 
value ordered 302 instead of forking.

The problem comes into play when we start trying to fork based on the  
"service being requested" instead of on the "capabilities needed in  
the endpoints to which we might fork".

--
Dean

------------------------------

Message: 7
Date: Mon, 22 May 2006 18:30:07 +0300
From: Juha Heinanen <[email-masked]>
Subject: Re: [Sipping] "Services"
To: Dean Willis <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Dean Willis writes:

 > Of course, this can be done by having the proxy respond with a q- 
 > value ordered 302 instead of forking.

and who would pay the bill, then proxy returns 302 to PSTN gateway?

-- juha

------------------------------

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

End of Sipping Digest, Vol 25, Issue 24
***************************************

_______________________________________________
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