JEP-0xxx:Zoep

This JEP defines a transport for initiating and negotiating sessions using SIP/SDP over XMPP.


WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.


JEP Information

Status: Experimental
Type: Standards Track
Number: 0XXX
Version: 0.5
Last Updated: 2006-03-16
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2327, RFC 3261
Supersedes: None
Superseded By: None
Short Name: zoep
Wiki Page: www.openzoep.org

Author Information

Dirk Griffioen

Email: dgriffioen@voipster.com
JID: dirk4@jabber.voipster.com

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

1. Introduction
2. Requirements
3. Protocol
4. Discovering Support
5. Examples
5.1. Negotiating a Voice Call
6. Security Considerations
7. IANA Considerations
8. Jabber Registrar Considerations
8.1. Protocol Namespaces
9. XML Schemas
9.1. zoep
Notes
Revision History


1. Introduction

A widely used protocol for negotiation of multimedia sessions over the internet is the 'Session Initiation Protocol' (SIP; see RFC 3261 [1]). The Session Description Protocol (SDP; see RFC 2327[2]) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet.

Two XMPP protocols concerned with session negotiation exist: TINS (jep-0111), which has been retracted in favor of Jingle Signalling (Jep-0166 )[3] - and related Jingle Audio (Jep-0167 )[4].

There is a certain overlap between TINS/Jingle and SIP (as they both address 'session negoatiation').This Jep proposes to use XMPP as a transport and send SIP messages over XMPP to negotiate multimedia sessions and their content. State will be handled by the used SIP stack.

In terms of Jep-0167  this solution is a dual-stack (or hybrid) solution, but without overhead as in translating elements (giving SIP/SDP elements an equivalent XML tag) or re-implementing protocols; and by doing so, it tries to reuse existing code and protocols - which might be beneficial in terms of interoperability [5].

Bridging the XMPP and SIP worlds by a gateway can be a achived as follows: the gateway can statelessly add a <zoep/> container for inbound calls and remove it for outbound. The entity in the Zoep network will handle all session related issues. Such a gateway can be implemented as a python script, in terms of a py-transport.

2. Requirements

This JEP addresses the following requirements:

  1. Enable an XMPP entity to negotiate an out-of-band multimedia session with another XMPP entity.
  2. Enable an XMPP entity to negotiate an out-of-band multimedia session with a non-XMPP entity through a gateway.
  3. Maximize interoperability with existing gateways and devices by using standard Internet protocols.
  4. Maximize code reuse by wrapping SIP messages in an XMPP transport layer.

3. Protocol

Zoep exchanges are completed by sending <message/> stanzas containing a child <zoep/> element, qualified by the 'http://jabber.openzoep.org/protocol/zoep'  namespace. [6]

The zoep payload inside <zoep/> elements is plain vanilla SIP as defined in RFC 3261.

The payload data itself is included as the XML character data of an <zoep/> child of the <message/> element. Any restricted XML characters in the SDP data (i.e., & ' < > ") MUST be properly escaped when contained in the XML character data of the <zoep/> element (for example, the ' character MUST be escaped to &apos;). It is the responsibility of the XMPP recipient or translating gateway to unescape these restricted characters for processing.

The message contains a 'to=', this determines the callee, a 'from=', this determines the caller and an 'id= ', the id of the message. All three attributes are in full conformance with RFC 3920 (XMPP Core) and RFC 3921 (XMPP IM). The id as shown in the examples is not related with the SIP payload.

At the moment, one additional element is embedded in the message, a so-called <socket_id/>. This is used by the application to address NAT-traversal issues; for a brief discussion, see chapter 6 ' Security Considerations'.

Other elements can be added to the messages to address issues alike.

4. Discovering Support

Before initiating a Zoep negotiation outside the Zoep network, an XMPP entity SHOULD determine that the target entity supports the 'http://jabber.openzoep.org/protocol/zoep' namespace. Such discovery SHOULD occur by means of Service Discovery [7], either directly by querying the target entity or indirectly by means of Entity Capabilities [8]. If the target entity is a non-XMPP entity that is contacted through a gateway, the gateway itself SHOULD reply to service discovery queries on behalf of the non-XMPP entity and SHOULD insert a client capabilities extension into the presence stanzas it generates on behalf of the non-XMPP entity.

If an XMPP entity receives, or a gateway handles, a <message/> stanza containing a <zoep/> element qualified by the 'http://jabber.org/protocol/zoep' namespace but it does not understand the ZOEP protocol, it SHOULD either silently ignore it or return a <service-unavailable/> error (see Error Condition Mappings [9] for error syntax).

5. Examples

5.1 Negotiating a Voice Call

The following XMPP stanzas could be used to initiate a voice call.The 'from' addresses will usually be added by the XMPP server or relevant gateway, but are shown here for the sake of clarity (caveat: with < etc. instead of &lt for example reasons in the zoep payload!) .   
   

Example 1. Step 1: A sends an invite to B

<message 
  from='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1' 
  to='b@jabber.voipster.com/Zoep'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    INVITE sip:b@jabber.voipster.com/Zoep SIP/2.0
    Via: SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BK66F6C3D2-E462-45B2-81A2-9B4B4232EEAB;rport
    From: <sip:a@sip.voipster.com>;tag=1319200270
    To: <sip:b@jabber.voipster.com/Zoep>
    CONTENT-TYPE: APPLICATION/SDP
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Max-forwards: 70
    User-agent: Voipster SIP
    Contact: <sip:d@0.0.0.0:0>
    Cseq: 1137238302 INVITE
    Content-length: 348
    
    v=0
    o=a 1137238302 1137238302 IN IP4 0.0.0.0
    s=voipster SIP
    c=x-socket_id 2018435356
    b=CT:1000
    t=0 0
    m=audio 8100 RTP/AVP 98 9 97 3 0 8 11
    a=rtpmap:98 speex/16000
    a=rtpmap:9 G722/16000
    a=rtpmap:97 iLBC/8000
    a=fmtp:97 mode=20
    a=rtpmap:3 gsm/8000
    a=rtpmap:0 pcmu/8000
    a=rtpmap:8 pcma/8000
    a=rtpmap:11 l16_mono/44100
    a=ptime:20
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
			

Example 2. Step 2: B tells A that it is trying

<message 
  from='b@jabber.voipster.com/Zoep' 
  to='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    SIP/2.0 100 Trying
    Via:  SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BK66F6C3D2-E462-45B2-81A2-9B4B4232EEAB;rport
    From: <sip:a@sip.voipster.com>;tag=1319200270
    To: <sip:b@jabber.voipster.com/Zoep>
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238302 INVITE
    Content-length: 0
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
    

  Example 3. Step 3: B tells A that it is ringing

<message 
  from='b@jabber.voipster.com/Zoep' 
  to='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    SIP/2.0 180 Ringing
    Via:  SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BK66F6C3D2-E462-45B2-81A2-9B4B4232EEAB;rport
    From: <sip:a@sip.voipster.com>;tag=1319200270
    To: <sip:b@jabber.voipster.com/Zoep>
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238302 INVITE
    Content-length: 0
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
    

 Example 4. Step 5: A sends an acknowledgement to B

<message 
  from='b@jabber.voipster.com/Zoep' 
  to='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    SIP/2.0 200 OK
    CONTENT-TYPE: APPLICATION/SDP
    Via:  SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BK66F6C3D2-E462-45B2-81A2-9B4B4232EEAB;rport
    From: <sip:a@sip.voipster.com>;tag=1319200270
    To: <sip:b@jabber.voipster.com/Zoep>
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238302 INVITE
    Content-length: 322
    
    v=0
    o=d 1137238308 1137238308 IN IP4 0.0.0.0
    s=voipster SIP
    c=x-socket_id 2018435356
    t=0 0
    m=audio 8100 RTP/AVP 98 9 97 3 0 8 11
    a=rtpmap:98 speex/16000
    a=rtpmap:9 G722/16000
    a=rtpmap:97 iLBC/8000
    a=fmtp:97 mode=20
    a=rtpmap:3 gsm/8000
    a=rtpmap:0 pcmu/8000
    a=rtpmap:8 pcma/8000
    a=rtpmap:11 l16_mono/44100
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
    

 Example 6. Step 6: A sends an acknowledgement

<message 
  from='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1' 
  to='b@jabber.voipster.com/Zoep'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    ACK sip:b@0.0.0.0:0 SIP/2.0
    Via: SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BK1302E3B7-06CC-4169-BB5D-7D9604EC6347;rport
    From: <sip:a@sip.voipster.com>;tag=1319200270
    To: <sip:b@jabber.voipster.com/Zoep>
    Max-forwards: 70
    User-agent: Voipster SIP
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238302 ACK
    Content-length: 0
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
    

 Example 6. Step 6: B hangs up

<message 
  from='b@jabber.voipster.com/Zoep' 
  to='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    BYE sip:d@0.0.0.0:0 SIP/2.0
    Via: SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BKBCE36C4F-BE79-49BC-9CCE-53F9C7E17A22;rport
    To: <sip:d@sip.voipster.com>;tag=1319200270
    From: <sip:b@jabber.voipster.com/Zoep>;tag=4167128455
    Max-forwards: 70
    User-agent: Voipster SIP
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238336 BYE
    Content-length: 0
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>					
    

 Example 7. Step 7: A acknowledges the hang up

<message 
  from='a@jabber.voipster.com/Zoep' 
  id='phonecall_1713c081-afe4-4488-9694-90d952e157b1' 
  to='b@jabber.voipster.com/Zoep'>
  <zoep xmlns='http://jabber.openzoep.org/protocol/zoep'>
    SIP/2.0 200 OK
    Via:  SIP/2.0/UDP 0.0.0.0:0;BRANCH=Z9HG4BKBCE36C4F-BE79-49BC-9CCE-53F9C7E17A22;rport
    From: <sip:b@jabber.voipster.com/Zoep>;tag=4167128455
    To: <sip:a@sip.voipster.com>;tag=1319200270
    Contact: <sip:a@0.0.0.0:0>
    Call-id: B0EE1372-2FF4-442B-9874-1D41E23BAE5C@0.0.0.0
    Cseq: 1137238336 BYE
    Content-length: 0
  </zoep>
  <socket_id xmlns='http://jabber.openzoep.org/protocol/zoep'>2018435356>/socket_id>
</message>			
    

6. Security Considerations

To follow.

7. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].

8. Jabber Registrar Considerations

8.1 Protocol Namespaces

The Jabber Registrar [11] shall include 'http://jabber.openzoep.org/protocol/zoep' in its registry of protocol namespaces.

9. XML Schemas

9.1 zoep   

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema 
  xmlns:xs= 'http://www.w3.org/2001/XMLSchema' 
  targetNamespace='http://jabber.openzoep.org/protocol/zoep'
  xmlns='http://jabber.openzoep.org/protocol/zoep'
  elementFormDefault='qualified'>
    
    <xs:element name='zoep' type= 'xs:string'/> 
		
</xs:schema>

   
			


Notes

1. RFC 3261: Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3261.txt>.

2. RFC 2327: SDP: Session Description Protocol<http://www.ietf.org/rfc/rfc2327.txt>.

3. Jep-0166: Jingle Signalling <http://www.jabber.org/jeps/jep-0166.html>.

4. Jep-0167: Jingle Audio <http://www.jabber.org/jeps/jep-0167.html>.

5. There has been some discussion on the Jabber mailing lists regarding this (SIP-XMPP relation): <http://mail.jabber.org/pipermail/jingle/2005-December/000042.html>.

6. Referral to the zoep protocol namespace has been included in preference of the 'urn:ietf:rfc:3261' namespace to facilitate discovering support (see chapter 4). However, it can be read as an alias for 'urn:ietf:rfc:3261', which is consistent with RFC 2648: A URN Namespace for IETF Documents <http://www.ietf.org/rfc/rfc2648.txt>.

7. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>

8. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.

9. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.

10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

11. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.


Revision History

Version 0.5 (2006-03-16)

Changed the introduction and removed 'security considerations', these will be redone (DAG)

Version 0.4 (2006-02-09)

Some small errors fixed (DAG)

Version 0.3 (2006-01-17)

Security (DAG)

Version 0.2 (2006-01-15)

Added namespaces, examples and general makeover (DAG)

Version 0.1 (2006-01-13)

Initial revision (DAG)


END