Re: [Ecrit] [Fwd: New Version Notification for draft-kim-ecrit-text-00]

["DRAGE, Keith (Keith)" <[e-mail]>]

SMS to IM interworking has two mechanisms, full interworking (3GPP TS 24.341), and encapsulation of the SMS in an IM (3GPP TS 29.311).

That makes 4 scenarios:

1)	SMS user communicating to IM connected PSAP using interworking. The SMS has no mechanisms of ensuring that it is always delivered to the same interworking gateway and therefore no pseudo session can be created in the IM. At the moment it would also not be possible to tie location services to a particular short message.

2)	SMS user communicating to IM connected PSAP using encapsulation. Similar considerations to 1 apply.

3)	IM user connected to PSAP using SMS via interworking gateway. If the IMS user uses the mechanism in the document, presumably it will reach the short message gateway, but the gateway has no means of ensuring these are all delivered to the same SMS endpoint except the value that appears in the request-URI.

4)	IM user sending SMS encapsulated in IM message via gateway. Similar issues to 3).

regards

Keith

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]] 
> Sent: Tuesday, November 24, 2009 3:11 PM
> To: DRAGE, Keith (Keith); Richard Barnes
> Cc: ecrit
> Subject: Re: [Ecrit] [Fwd: New Version Notification for 
> draft-kim-ecrit-text-00]
> 
> I think that it¹s probably better to do it this way.
> 
> It¹s not clear to me that we can always create a session.  
> It¹s desirable to do so, but I¹m not sure we can always do 
> that.  If we can¹t always do it, then we need to use a timer 
> to create a pseudo session, which is exactly what this draft 
> does.  The NENA requirements currently say that we accept 
> pager mode IM, and the intention was to do it the way this 
> draft describes.
> 
> Can you explain how the existing SMS to SIP interworking 
> standards would be in conflict with this idea?
> 
> Brian
> 
> 
> On 11/24/09 9:45 AM, "DRAGE, Keith (Keith)" <[e-mail]>
> wrote:
> 
> > But...
> >  
> > The use case under discussion here is an end entity running 
> LOST (and 
> > therefore presumably an IP terminal) communicating with an IP 
> > connected PSAP, and therefore not involving any SMS at all. 
> Therefore 
> > for this use case, the endpoints presumably have the full range of 
> > choice of standardised messaging mechanisms as defined by IETF.
> >  
> > If you did want to extend the use case to SMS, I would also content 
> > that the current standardised SMS to SIP based IM mechanisms would 
> > break the solution suggested here as well.
> >  
> > (Also ignoring the fact as well that current SMS is by default 
> > deferred delivery (i.e. delivered in the operator's own 
> time and when 
> > the recipient is available, and therefore not suitable for 
> emergency 
> > calls in the first place.)
> >  
> > Keith
> > 
> >>  
> >>  
> >> 
> >>  From: Richard Barnes [mailto:[e-mail]]
> >> Sent: Tuesday, November 24, 2009 2:35 PM
> >> To: DRAGE, Keith  (Keith)
> >> Cc: ecrit
> >> Subject: Re: [Ecrit] [Fwd: New Version  Notification for 
> >> draft-kim-ecrit-text-00]
> >> 
> >>  
> >> The problem here is that SMS is a page-mode medium that's used for
> >> session-mode-style conversations (see, e.g., the iPhone 
> SMS interface).   So
> >> if you're going to gateway SMS into SIP and preserve these  
> >> pseudo-sessions, you either have to do something like what 
> this draft 
> >> does, or  you have to somehow have the gateway create 
> sessions and map SMS messages into  them.
> >> I'm not immediately sure which would be a better solution, 
> but  using 
> >> MESSAGE seems marginally more light-weight.
> >> 
> >>  
> >> --Richard
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >> 
> >>  
> >>  
> >> On Nov 23, 2009, at 8:34 PM, DRAGE, Keith (Keith) wrote:
> >> 
> >>  
> >>>  
> >>>  
> >>> So did I read this correctly.
> >>>  
> >>>  
> >>>  
> >>> You are essentially saying you want to use page mode  
> messaging to 
> >>> do session mode messaging?
> >>>  
> >>>  
> >>>  
> >>> Didn't SIMPLE investigate that path and reject it and  go 
> for MSRP 
> >>> as the solution to session mode messaging?
> >>>  
> >>>  
> >>>  
> >>> Why does emergency calling suddenly make the original  decision 
> >>> making process in SIMPLE redundant?
> >>>  
> >>>  
> >>>  
> >>> regards
> >>>  
> >>>  
> >>>  
> >>> Keith
> >>> 
> >>>  
> >>>>  
> >>>>  
> >>>> 
> >>>>  From: [e-mail] 
> [mailto:[e-mail]]  On 
> >>>> Behalf Of Wonsang Song
> >>>> Sent: Monday, November 23, 2009  8:53 PM
> >>>> To: [e-mail]
> >>>> Subject: [Ecrit]  [Fwd: New Version Notification for 
> >>>> draft-kim-ecrit-text-00]
> >>>> 
> >>>>  
> >>>> Hi,
> >>>> 
> >>>> Just wanted to send a note about a new draft on  using 
> SIP MESSAGE 
> >>>> for emergency texting.
> >>>> 
> >>>> The draft is an outcome of  the collaboration between Columbia 
> >>>> University and Verizon to build an  emergency texting prototype 
> >>>> system which allows people to use IM and SMS  to "call" 
> for emergency help.
> >>>> 
> >>>> If you have comments or questions,  please let me know.
> >>>> 
> >>>> Thank you,
> >>>> Wonsang Song
> >>>> 
> >>>> 
> >>>> --------  Original Message --------
> >>>> Subject: New Version Notification for  draft-kim-ecrit-text-00
> >>>> Date: Tue, 17 Nov 2009 11:55:17 -0800  (PST)
> >>>> From: IETF I-D Submission Tool <[e-mail]> 
> >>>> <mailto:[e-mail]>
> >>>> To: [e-mail]
> >>>> CC: [e-mail], [e-mail], 
> >>>> [e-mail], [e-mail]
> >>>> 
> >>>> 
> >>>> A  new version of I-D, draft-kim-ecrit-text-00.txt has been 
> >>>> successfuly submitted by Jong Yul Kim and posted to the 
> IETF  repository.
> >>>> 
> >>>> Filename:   draft-kim-ecrit-text
> >>>> Revision:  00
> >>>> Title:  Emergency Text  Messaging using SIP MESSAGE
> >>>> Creation_date:  2009-11-16
> >>>> WG ID:  Independent  Submission
> >>>> Number_of_pages: 11
> >>>> 
> >>>> Abstract:
> >>>> This memo describes  best current practices on how to 
> use the SIP 
> >>>> MESSAGE method for  emergency text messaging from citizen and 
> >>>> visitors to  authorities.
> >>>> 
> >>>> Status of this Memo
> >>>> 
> >>>> This Internet-Draft is  submitted to IETF in full 
> conformance with 
> >>>> the provisions of BCP 78 and  BCP 79.
> >>>> 
> >>>> Internet-Drafts are working documents of the Internet  
> Engineering
> >>>> Task Force (IETF), its areas, and its working groups.   Note that
> >>>> other groups may also distribute working documents as  Internet- 
> >>>> Drafts.
> >>>> 
> >>>> Internet-Drafts are draft documents valid for  a maximum of six 
> >>>> months and may be updated, replaced, or obsoleted by  other 
> >>>> documents at any time.  It is inappropriate to use  
> Internet-Drafts 
> >>>> as reference material or to cite them other than as  
> "work in progress."
> >>>> 
> >>>> The list of current Internet-Drafts can be  accessed at 
> >>>> http://www.ietf.org/ietf/1id-abstracts.txt.
> >>>> 
> >>>> The  list of Internet-Draft Shadow Directories can be 
> accessed at 
> >>>> http://www.ietf.org/shadow.html.
> >>>> 
> >>>> This  Internet-Draft will expire on May 20, 2010.
> >>>> 
> >>>> Copyright  Notice
> >>>> 
> >>>> Copyright (c) 2009 IETF Trust and the persons identified as  the 
> >>>> document authors.  All rights reserved.
> >>>> 
> >>>> This document  is subject to BCP 78 and the IETF Trust's Legal 
> >>>> Provisions Relating to  IETF Documents
> >>>> (http://trustee.ietf.org/license-info)  in effect on the date of 
> >>>> publication of this document.  Please  review these documents 
> >>>> carefully, as they describe your rights and  restrictions with 
> >>>> respect to this document.  Code Components  extracted from this 
> >>>> document must include Simplified BSD License text  as 
> described in 
> >>>> Section 4.e of the Trust Legal Provisions and are  
> provided without 
> >>>> warranty as described in the BSD  License.
> >>>> 
> >>>> 
> >>>> 
> >>>> The IETF Secretariat.
> >>>>  
> >>>>  
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> _______________________________________________
> >>> Ecrit  mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> 
> > 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
>