Subject: RE: [Sip] SMS via VoIP

From: "vamsi" <[email-masked]>
Date: Mon, 1 Jan 2007 12:35:53 +0530

Yes, now I am clear with the MESSAGE concept of paging mode and session
mode.  Thank you for your information.  
Is there any specific restriction for how long a MESSAGE should be sent in
paging mode?  

-----Original Message-----
From: Charles Kristofek [mailto:[email-masked]] 
Sent: Sunday, December 31, 2006 11:35 PM
To: 'vamsi'; [email-masked]
Subject: RE: [Sip] SMS via VoIP

Yes, the UAC can send/convey information one way to the UAS.
This information flow feels like sending a message to a pager or sending an
sms to a mobile.

Previous discussion on instant message, SMS, MMS interworking:

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

Message: 1
Date: Thu, 25 May 2006 15:37:15 +0200
From: "Jesus Javier Arauz \(E2/EEM\)"
      <[email-masked]>
Subject: [Sipping] Re: Multi-media messaging and SIP
To: <[email-masked]>
Message-ID:
     <[email-masked]>
Content-Type: text/plain;     charset="us-ascii"

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

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

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
------------------------------
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: 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
> 
> 
> 
> 
> ----------------------------------------------------------------------
End of Sipping Digest, Vol 25, Issue 28

***************************************

-----Original Message-----
From: vamsi [mailto:[email-masked]]
Sent: Sunday, December 31, 2006 7:13 AM
To: 'Charles Kristofek'; [email-masked]
Subject: RE: [Sip] SMS via VoIP

In RFC 3428, section 3, " MESSAGE requests do not establish dialogs".

 Does "Paging mode" mean that with out establishing a actual/voice session,
UA client can send IM to UA server?  

-----Original Message-----
From: Charles Kristofek [mailto:[email-masked]]
Sent: Sunday, December 31, 2006 2:52 AM
To: [email-masked]'
Subject: RE: [Sip] SMS via VoIP

There are 2 models in SIP for sending IMs (paging and session).

Paging mode has the UA client sending the MESSAGE method to pass the
information. Please refer to RFC 3428.

Session mode has the UA client sending the INVITE method to establish a
session first.

For SMS via SIP, the MESSAGE method carrying the text within the body of the
method to the SMSC (or application server) mimics 2G.

The establishment of a session via INVITE mimics IM where peer information
can be relayed, such as "typing".

Chuck K.

------------------------------
Date: Fri, 29 Dec 2006 23:10:27 -0500
From: [email-masked]
Subject: Re: [Sip] SMS via VoIP
To: [email-masked]
Message-ID: <[email-masked]>

   From: "vamsi" <[email-masked]>

   Thanks for the message.  But for MESSAGE conversation, what kind of
   codec is used, that is audio codec or any other specified codec?
   As per RFC 3551 Audio and video codecs are specified.

A MESSAGE request contains the text content directly.  See RFC 3438 for
details.  (I don't think anyone has specified how to carry recorded audio
segments as messages.)

For extended interchange of messages, as Fenar says, you set up a dialog
(using INVITE) and specify the use of MSRP in the SDP.

As others have noted, if you want to interoperage with 3GPP, its
specificaitons are available.

Dale

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

THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED,  OR OTHER
LEGALLY PROTECTED INFORMATION.  IF YOU ARE NOT THE INTENDED RECIPIENT (EVEN
IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY OR RETRANSMIT
IT.  IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE REMOVED FROM A
MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT
[email-masked], THEN DELETE.  THANK YOU.

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

THIS E-MAIL MAY CONTAIN PRIVILEGED, CONFIDENTIAL, COPYRIGHTED,  OR OTHER  
LEGALLY PROTECTED INFORMATION.  IF YOU ARE NOT THE INTENDED RECIPIENT 
(EVEN IF THE E-MAIL ADDRESS ABOVE IS YOURS), YOU MAY NOT USE, COPY 
OR RETRANSMIT IT.  IF YOU HAVE RECEIVED THIS BY MISTAKE, OR WISH TO BE
REMOVED FROM A MAILING LIST, PLEASE NOTIFY US BY RETURN E-MAIL AT
 [email-masked], THEN DELETE.  THANK YOU.

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

---

From: Fatih Eyüp NAR <[email-masked]>
Date: Mon, 1 Jan 2007 03:41:35 -0800 (PST)

RFC 3261 18.1.1

If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.

-----Original Message-----
From: Charles Kristofek [mailto:[email-masked]] 
Sent: Sunday, December 31, 2006 11:35 PM
To: 'vamsi'; [email-masked]
Subject: RE: [Sip] SMS via VoIP

Message: 1

Message: 2

Hi,

Best regards,
/Javier Arauz

Dale

Hope this helps,
--Richard

-----Original Message-----
From: Charles Kristofek [mailto:[email-masked]]
Sent: Sunday, December 31, 2006 2:52 AM
To: [email-masked]'
Subject: RE: [Sip] SMS via VoIP

Chuck K.

Dale