1 / 20

MSRP Core

MSRP Core. draft-ietf-simple-message-sessions-06. New in 06. Changed To and From to To-Path and From-Path Semantics different than traditional To and From. Confusion insued. Framing: Use boundary instead of length field. SDP: Transport and TLS indicated in URL, rather than M-Line.

katen
Download Presentation

MSRP Core

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MSRP Core draft-ietf-simple-message-sessions-06

  2. New in 06 • Changed To and From to To-Path and From-Path • Semantics different than traditional To and From. Confusion insued. • Framing: Use boundary instead of length field. • SDP: Transport and TLS indicated in URL, rather than M-Line. • Inviter always opens the connections • Updated DSN section

  3. Relationship to Relay Draft • Core specification talks about route path handling • Makes minimum necessary assumptions about relay behavior to allow relays. • Does not talk about how relays work, or how endpoints select relays.

  4. Path handling in SDP • Each client puts a URL into a path attribute. • Can put more than one URL in the path attribute. • The path given by peer indicates the “path to the peer.” • Path applies to all messages in session.

  5. Path handling in MSRP requests • To-Path holds a list of URLs. • Path to destination • First URL is first hop. • Last URL is destination. • From-URL also takes a list • “Where it’s been” • Initial request has one entry pointing to client. • When request arrives at destination, it will contain URLs for all hops.

  6. Request Framing • Length Field goes away. • Add Boundary header. • Random String (different for each message) • Matching closing field • 7 hyphens • Boundary string • Continuation char. ($ if content complete, + if more to come.)

  7. Request Framing • MSRP Boundary unrelated to any MIME boundary in the payload. • Full MIME body between headers and closing. May have its own MIME boundaries. • Presence of MIME boundaries does not change use of MSRP boundary. • Boundary must not collide with payload. • Cannot use same boundary string for MSRP boundary and any MIME boundaries.

  8. Other SDP Changes • msrp://host/asf;transport=tcp,protection=yes • msrps://host/asdf3; transport=tcp • msrps://host/tcp/asfed • Transport and TLS determined by URL scheme, rather than M-line. • msrp: - TCP • msrps: - TLS over TCP • smsrp: - SCTP • smsrps: - TLS over SCTP • SCTP related schema are “reserved” for whenever we specify the SCTP binding.

  9. Connection Handling • Defaults to TCP connection opened by client that sends the INVITE. • No COMEDIA • Active client MUST send an immediate MSRP request, so the peer can tell who opened the connection. • May be SEND if there is a message to send right away. • Otherwise use VISIT • Inviter must wait for answer before connecting.

  10. Delivery Status Notification • Only specifies enough to let an endpoint without relay support talk to peers that use relays. • RFC1894 format • DSN requested on per request basis. • Receipt-Request header field • Negative – only report on failures • None – never report • All – report failures and delivery success. • Default is “negative” • Sent using REPORT method • Never REPORT on a REPORT

  11. Message Fragmentation • May break content into “parcels” using message/byteranges • Only message/byteranges content can be interrupted and resumed. • SHOULD fragment anything over 2k. • Final parcel uses “$” in the continuation flag field. Non-final parcels use “+”

  12. Open Issues and To Do’s • Responses • Proposal to make transaction responses optional or remove them entirely. • Orit will present details.

  13. SDP Issues • How will SIP delayed offers work? • Can we expect the answerer to propose MSRP rather than voice? • Should we specify what a client that supports MSRP should do if it gets an INVITE with no offer? • Do we want this much SIP specificity in this document?

  14. SDP Issues • Old text on updated offers obsolete with new approach to connection direction. • Section needs a re-write. • SDP offer/answer arcana experts _please_ help.

  15. Connection Direction • Number of non-relay scenarios reduced • Offerer must choose whether to use relay prior to making offer. If the answerer is not firewalled, the offerer cannot learn of this until too late. • Thus, a firwalled answerer will always propose a relay, even if the answerer is reachable. • A firewalled answerer must use a relay, even if the offerer is reachable.

  16. Connection Direction • Do we want to allow for more sophisticated direction selection in the future? • What if COMEDIA becomes an option? • Can we say that arbitrary signaling protocols can have their own method of determining direction?

  17. Fragmentation • How much of the RFC2616 language concerning message/byteranges do we need to reproduce here? • Currently only refers to RFC, and add text that specifically constrains the use in MSRP. Does not explain message/byteranges in general.

  18. SEND vs VISIT • VISIT has become less important • VISIT only serves to identify the active party to the passive party, in the context of a particular session. • Active party may jump straight to SEND if it has content to send. • Since the active party initiated communication in the first place, it probably has content. • Can we remove VISIT entirely? • Should we require VISIT all the time, and not overload SEND?

  19. DSN Issues • Do we need them at all? • What about DSN reports after session is over? • Should we default to no DSN for peer-peer session? • DSN is redundant with transaction responses for p2p. • DSN section needs to be updated to use new handling of To-Path and From-Path.

  20. Other To Do items • Still need to add support for all appropriate MIME headers. • Does not seem controversial, just stuck in line behind the harder stuff. • More text needed on TLS certificate handling.

More Related