Internet DRAFT - draft-partha-rtcweb-jsep-sip
draft-partha-rtcweb-jsep-sip
RTCWeb Parthasarathi. Ravindran
Internet-Draft Uwe. Rauschenbach
Intended status: Standards Track Elangovan. Manickam
Expires: April 24, 2014 Nokia Solutions and Networks
October 21, 2013
Offer & Answer interworking between JSEP & SIP
draft-partha-rtcweb-jsep-sip-01
Abstract
Real time communcation Web (RTCWeb) workgroup defines the real time
commmunication using JavaScript Session establishment protocol (JSEP)
as an offer/answer mechanism. Session Initiation protocol (SIP) is
IETF defined and well deployed protocol for real time communication.
This document provides offer & answer interworking between JSEP and
SIP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 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
Ravindran, et al. Expires April 24, 2014 [Page 1]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP and JSEP offer/answer mapping architecture . . . . . . . . 4
5. JSEP offer/answer to SIP offer/answer mapping . . . . . . . . 4
5.1. Basic JSEP session mapping . . . . . . . . . . . . . . . . 4
5.2. Early media mapping . . . . . . . . . . . . . . . . . . . 5
5.3. Re-INVITE mapping . . . . . . . . . . . . . . . . . . . . 6
5.4. Offer JSEP- SIP Offer Race condition handling . . . . . . 6
5.5. JSEP to SIP serial forking . . . . . . . . . . . . . . . . 7
5.6. JSEP to SIP Parallel forking . . . . . . . . . . . . . . . 8
6. SIP offer/answer to JSEP offer/answer mapping . . . . . . . . 9
6.1. Basic SIP-JSEP session mapping . . . . . . . . . . . . . . 10
6.2. INVITE without SDP Offer to JSEP session mapping . . . . . 10
6.3. SIP Non-ICE to JSEP ICE handling . . . . . . . . . . . . . 10
6.4. JSEP to SIP Trickle-ICE handling . . . . . . . . . . . . . 10
6.5. JSEP ICE to SIP Non-ICE handling . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Ravindran, et al. Expires April 24, 2014 [Page 2]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
1. Introduction
Real time communcation Web (RTCWeb) workgroup defines JavaScript
Session establishment protocol (JSEP) [I-D.ietf-rtcweb-jsep] as an
offer/answer mechanism. The transport to carry JSEP information
shall be HTTP long polling [RFC6202] �or WebSockets over TLS/
TCP [RFC6455]. JSEP Offer/answer details shall be carried based on
the application choice and some of the possible mechanism are REST or
SIP or XMPP. HTTP based transport mechanism has the advantages of
travering through all NAT and firewall. JSEP offer/answer focuses on
the offer/answer between two browsers wherein the offer/answer
related feature like parallel forking in SIP is not provided.
Session Initiation protocol (SIP) [RFC3261] is IETF defined and well
deployed protocol for real time communication. SIP offer/answer
mechanism is based on [RFC3264] and few enhancements are done in the
SIP layer.
RTCWeb clients (browser) and SIP UA supports Session Description
protocol (SDP)[RFC4566] as the media description protocol. In case
of mapping between these two protocols, SDP shall be reused.
SIP offer/answer supports the different RTP models [RFC3550] like RTP
endpoint, RTP Mixer, RTP translator whereas JSEP supports RTP
endpoint only.
As there are difference betweeen SIP offer/answer and JSEP, there is
a need of explicit mapping. This document provides the mapping
between JSEP and SIP offer/answer mechanism. This mapping happens
between SIP UA and RTCWeb entity which handles JSEP. RTCWeb entity
in this document refers to the RTCWeb compliant browser or RTCWeb
Server.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. This
document only uses these key words when referencing normative
statements in existing RFCs."
3. Definitions
o RTCWeb entity : RTCWeb compliant browser or RTCWeb Server.
o 18x response: 180 (ringing) or 183 (session progress) or any other
response in the range of 180-189
Ravindran, et al. Expires April 24, 2014 [Page 3]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
4. SIP and JSEP offer/answer mapping architecture
The mapping between SIP and JSEP offer/answer is the building block
described in this document. This mapping happens between SIP UA and
RTCWeb entity which handles JSEP. RTCWeb entity in this document
refers to the RTCWeb compliant browser or RTCWeb Server. The
following diagrams illustrate the possible JSEP-SIP mapping
architecture.
JSEP SIP
RTCWeb Browser <------->RTCWeb Server + SIP UA <------> SIP UA
Fig 1: JSEP-SIP mapping in RTCWeb Server
In the above figure 1, JSEP-SIP mapping is done at RTCWeb server.
JSEP shall be transported from RTCWeb browser to RTCWeb Server by any
signaling mechanism
SIP
RTCWeb Browser + SIP UA<----------->RTCWeb Server + SIP UA/Proxy
Fig 2: JSEP-SIP mapping in RTCWeb browser
JSEP-SIP mapping shall be done at RTCWeb browser as shown in the
above diagram. SIP shall be transported from RTCWeb browser to
RTCWeb Server by SIP over WebSocket or any other signaling mechanism
5. JSEP offer/answer to SIP offer/answer mapping
5.1. Basic JSEP session mapping
In RTCWeb browser, ICE is mandatorily supported. ICE calls for two
offer/answer exchange wherein the initial offer indicates the set of
ICE candidate pairs and the second offer/answer confirms the
candidate pair which is used for the session. JSEP OFFER SHALL be
mapped to INVITE with SDP and 200 OK with SDP SHALL be mapped to JSEP
ANSWER.
Ravindran, et al. Expires April 24, 2014 [Page 4]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|------OFFER--------->|--INVITE(OFFER)----->|
| | |
| |<-------100----------|
| |<-------18x----------|
| | |
|<-----ANSWER---------|<----200 ANSWER------|
| | |
| |------ ACK---------->|
| | |
|-----OFFER2--------->|--RE-INVITE(OFFER2)->|
| | |
|<----ANSWER2---------|<---200 ANSWER-------|
| | |
| |----ACK------------->|
Fig 3: Basic JSEP to SIP session mapping
5.2. Early media mapping
In SIP, early dialog is established using PRACK [RFC3262] method.
ICE negotiation leads to OFFER2 from RTCWeb browser and it is
triggered using UPDATE method [RFC3311] towards SIP UA. 18x (18x/183)
response with SDP triggers the early media. SDP 200 for INVITE with
Answer2 SHALLL be ignored towards JSEP side as the answer2 is
forwarded as part of 200 for UPDATE with Answer2.
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|------OFFER--------->|--INVITE(OFFER)----->|
| | |
| |<-------100----------|
| | |
|<-----ANSWER---------|<----18x ANSWER------|
| | |
| |-------PRACK-------->|
| | |
|-----OFFER2--------->|--UPDATE(OFFER2)---->|
| | |
|<----ANSWER2---------|<-200 UPDATE ANSWER2-|
| | |
| |<-200 INVITE ANSWER2-|
| | |
| |------ ACK---------->|
Ravindran, et al. Expires April 24, 2014 [Page 5]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
| | |
Fig 4: Early media JSEP to SIP session mapping
PRANSWER state in JSEP is not used during ANSWER in the above
callflow as OFFER2 is not allowed as per PRANSWER state in JSEP.
OFFER in PRANSWER is an open item in JSEP.
5.3. Re-INVITE mapping
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|<--Dialog is established with INV/200/ACK--|
| | |
|<-----OFFER----------|<--RE-INVITE(OFFER)--|
| | |
| |--------100--------->|
| | |
|------ANSWER-------->|-----200 ANSWER----->|
| | |
| |<----- ACK-----------|
Fig 5: RE-INVITE mapping
5.4. Offer JSEP- SIP Offer Race condition handling
It is possible for offer to be send by RTCWeb browser and SIP UA
during the middle of the session. In [RFC3262], these race
conditions are resolved using 491 response as shown below.
Ravindran, et al. Expires April 24, 2014 [Page 6]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|<--Dialog is established with INV/200/ACK--|
| | |
|-----OFFER---------->|<--RE-INVITE(OFFER2)-|
| | |
| |--------491--------->|
| | |
| |<----- ACK-----------|
| | |
| |--RE-INVITE(OFFER1)->|
| | |
|<-----ANSWER---------|<-----200 ANSWER1----|
| | |
| |<----- ACK-----------|
| | |
|<-----OFFER2---------|<--RE-INVITE(OFFER2)-|
| | |
| |--------100--------->|
| | |
|------ANSWER2------->|-----200 ANSWER2---->|
| | |
| |<----- ACK-----------|
Fig 6: RE-INVITE-JSEP OFFER race condition mapping
5.5. JSEP to SIP serial forking
In case of SIP serial forking with ICE exchange, second offer MAY be
required in case the candidate pair is changing from the default
during the early dialog and such earlier dialog offer/answer exchange
has to happen in dialog1 using UPDATE mechanism. When the second
INVITE is forked from proxy towards the UA3, the final response 200
OK from UA3 is received with different SDP as Answer3. Answer3 has
to be mapped as Offer 3 towards JSEP in JSEP-SIP gateway as JSEP
completed offer-answer exchange already. Also, PRANSWER state in
JSEP is not used as OFFER2 with ICE update is not possible within
PRANSWER state and it is an open item in JSEP. ANSWER4 SDP is same
as ANSWER2, RE-INVITE towards UA shall be optimized or else RE-INVITE
MUST be exchanged between JSEP-SIP GW to SIP-UA.
Ravindran, et al. Expires April 24, 2014 [Page 7]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIPGW SIP Proxy SIP UA2 SIP UA3
| | | | |
|--OFFER--->|--INVITE(OFFER)->|---INVITE1--->| |
| | | OFFER | |
| |<-----100--------| | |
| | | | |
|<-ANSWER---|<----18x ANSWER--|<-18x ANSWER--| |
| | | | |
| |--PRACK--------->|-----PRACK--->| |
| | | | |
|-OFFER2--->|--UPDATE OFFER2->|---> UDPATE-->| |
| | | OFFER2 | |
|<-ANSWER2--|<-200 UPDATE | | |
| | ANSWER2----|<--- 200 | |
| | | ANSWER2--| |
| | | | |
| | |-----INVITE2---------->|
| | | OFFER | |
|<-OFFER3---|<-200 INVITE-----|<---- 200 INVITE-------|
| | ANSWER3 | ANSWER3 | |
|-ANSWER4-->| |---- ACK-------------->|
| |----BYE1-------->|---- BYE1---->| |
| | | | |
| |---ACK---------->| | |
Fig 7: Serial Forking JSEP to SIP session mapping
The assumption in Fig 5 is that ANSWER2 and ANSWER4 are same. In
case they are different, there is a need of extra offer-answer
between JSEP-SIP GW and SIP UA3
5.6. JSEP to SIP Parallel forking
JSEP does not support SIP parallel forking currently and it is the
responsibility of the application to achieve the same. As JSEP-SIPGW
is the application in this document, SIP parallel forking can be
achieved as shown below. The point to be noted is that only one
active RTP stream is possible in JSEP side for a given single m-line
from JSEP offer and so, the other active RTP stream is updated as
inactive using UPDATE offer/answer as shown in offer4. The rest of
the callflow for parallel forking is same as SIP serial forking
handling.
Ravindran, et al. Expires April 24, 2014 [Page 8]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIPGW SIP Proxy SIP UA2 SIP UA3
| | | | |
|--OFFER--->|--INVITE(OFFER)->|---INVITE1--->| |
| | | OFFER | |
| |<-----100--------| | |
| | |-----INVITE2---------->|
| | | OFFER | |
| | | | |
|<-ANSWER---|<----18x ANSWER--|<-18x ANSWER--| |
| | | | |
| |--PRACK--------->|-----PRACK--->| |
| | | | |
|-OFFER2--->|--UPDATE OFFER2->|---> UDPATE-->| |
| | | OFFER2 | |
|<-ANSWER2--|<-200 UPDATE |<--- 200------| |
| | ANSWER2----| ANSWER2 | |
| | | | |
|<-OFFER3---|<--18x ANSWER3---|<-18x ANSWER3----------|
| | | | |
| |--UPDATE OFFER4->|---> UDPATE-->| |
| | | OFFER4 | |
| |--PRACK--------->|-----PRACK------------>|
| | | | |
| |<-200 UPDATE |<--- 200------| |
| | ANSWER4----| ANSWER4 | |
|-ANSWER5-->| | | |
| | | | |
| |<-200 ANSWER3----|<---- 200--------------|
| | | ANSWER3 | |
| | |---- ACK-------------->|
| | |---- BYE1---->| |
| | | | |
| |---ACK---------->| | |
Fig 8: Parallel Forking JSEP to SIP session mapping
The assumption in Fig 8 is that ANSWER2 and ANSWER5 are same. In
case they are different, there is a need of extra offer-answer
between JSEP-SIP GW and SIP UA3
6. SIP offer/answer to JSEP offer/answer mapping
SIP specific offer/answer mechanism is defined in [RFC3261].
Ravindran, et al. Expires April 24, 2014 [Page 9]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
6.1. Basic SIP-JSEP session mapping
INVITE with SDP offer is the first message in SIP which maps to JSEP
Offer. The user alert information is not part of JSEP, HTTP
application specific extension shall indicate the user alert status
to the interworking entity which shall be later mapped to 18x mapping
without SDP. When RTCWeb user accepts the session, JSEP send ANSWER
towards interworking entity and ANSWER will be mapped to 200 OK
message in SIP.
6.2. INVITE without SDP Offer to JSEP session mapping
It is possible in SIP that INVITE without SDP offer is the first
message in SIP which has to initiate JSEP Offer from the client side.
The mechanism by which JSEP offer initiate request between
interworking entity and JSEP entity is outside the scope of the
document. Once the JSEP offer is received in the interworking
entity, it will be to 183 with offer towards UAC. PRACK with SDP
answer is received,
6.3. SIP Non-ICE to JSEP ICE handling
SIP does not mandate for ICE [RFC5245] whereas JSEP in RTCWeb has to
have mandatorily ICE handling. So, SIP-JSEP interworking entity has
to make sure ICE to non-ICE handling as well as SDP specific changes
for these interworking.
6.4. JSEP to SIP Trickle-ICE handling
Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is a ICE extension
mechanism wherein the candidates can be exchanged incrementally.
This would allow ICE agents to exchange host candidates as soon as a
session has been initiated. Connectivity checks for a media stream
would also start as soon as the first candidates for that stream have
become available.
Ravindran, et al. Expires April 24, 2014 [Page 10]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|-OFFER with | |
| Candidate info-->|--INVITE(OFFER with |
| | Candidate info)---->|
| | |
| |<-------100----------|
| | |
|<----ANSWER with-----|<--18x with initial |
| initial candidate | candidate info-----|
| info | |
| |--PRACK------------->|
| | |
|<---OFFER2 with------|<---UPDATE with------|
| complete candidate | complete candidate |
| info | info OFFER2 |
| | |
|----ANSWER2 with---->|-----200 with------->|
| updated candidate |updated candidate |
| info | info ANSWER2 |
| | |
| |<----200 INVITE------|
| | |
| |------ ACK---------->|
| | |
Fig 9: Basic JSEP to SIP Trickle-ICE session mapping
In case 200 OK with INVITE has different OFFER, the extra offer/
answer will be exchanged.
This draft does not use "INFO" mechanism mentioned in
[I-D.ivov-mmusic-trickle-ice-sip] as it leads to the race condition
between INFO and UPDATE from JSEP side
6.5. JSEP ICE to SIP Non-ICE handling
Most of the deployed SIP devices does not support ICE whereas JSEP in
RTCWeb always requires ICE. So, the interworking JSEP ICE to SIP
Non-ICE has to be handled in case JSEP-SIP gateway. This document
does not mandates the mechanism for this interworking but provides
one of the possible solution wherein ICE exchange is handled by JSEP-
SIP GW and here how JSEP-SIP Gateway identify SIP UA does not support
ICE is outside the scope of this document.
Ravindran, et al. Expires April 24, 2014 [Page 11]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
RTCWeb Browser JSEP-SIP GW SIP UA
| | |
|-OFFER with | |
| Candidate info-->|--INVITE(OFFER w/o |
| | Candidate info)---->|
| | |
| |<-------100----------|
| | |
| |<-------18x----------|
| | |
|<----ANSWER with | |
| candidate info-----|<----200 ANSWER------|
| | |
| |------ ACK---------->|
| | |
|-OFFER2 with | |
| candidate info----->| |
| | |
|<-ANSWER2 with | |
| candidate info-----| |
| | |
| | |
Fig 10: Basic JSEP ICE to SIP Non-ICE session mapping
Here, RE-INVITE is not triggered for OFFER2 as the update is related
to the selected candidate pair only and there is no other SDP change
7. Security Considerations
The security consideration of SIP UA and JSEP MUST be considered for
the interworking functionality. There is no need of any other extra
security considerations for this document.
8. IANA Considerations
There is no IANA considerations for this draft.
9. Acknowledgement
Thanks a lot to Thomas Belling, Mohamed Ibrahim Elias, Ramakrishnan
PA, Janne K Suotula, Markus Isomaki, Ranjit Avasarala, Paul Kyzivat
for their review comments
Ravindran, et al. Expires April 24, 2014 [Page 12]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-04 (work
in progress), September 2013.
[I-D.rescorla-mmusic-ice-trickle]
Rescorla, E., Uberti, J., and E. Ivov, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol",
draft-rescorla-mmusic-ice-trickle-01 (work in progress),
October 2012.
Ravindran, et al. Expires April 24, 2014 [Page 13]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
10.2. Informative References
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011.
[RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session
Initiation Protocol (SIP) Usage of the Offer/Answer
Model", RFC 6337, August 2011.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011.
[I-D.ietf-sipcore-sip-websocket]
Castillo, I., Millan, J., and V. Pascual, "The WebSocket
Protocol as a Transport for the Session Initiation
Protocol (SIP)", draft-ietf-sipcore-sip-websocket-09 (work
in progress), June 2013.
[I-D.ivov-mmusic-trickle-ice-sip]
Ivov, E., Marocco, E., and C. Holmberg, "A Session
Initiation Protocol (SIP) usage for Trickle ICE",
draft-ivov-mmusic-trickle-ice-sip-01 (work in progress),
October 2013.
Authors' Addresses
Parthasarathi Ravindran
Nokia Solutions and Networks
Bangalore, Karnataka
India
Email: partha@parthasarathi.co.in
Uwe Rauschenbach
Nokia Solutions and Networks
St Martin Strasse 76
Munich
Germany
Email: uwe.rauschenbach@nsn.com
Ravindran, et al. Expires April 24, 2014 [Page 14]
Internet-Draft O/A Interworking between JSEP & SIP October 2013
Elangovan Manickam
Nokia Solutions and Networks
Bangalore, Karnataka
India
Email: elangovan.manickam@nsn.com
Ravindran, et al. Expires April 24, 2014 [Page 15]
