SIP Jean-Francois Mule & al. Internet Draft Clarent Corp Document: October 2000 Category: Informational SIP T.38 Call Flow Examples And Best Current Practice Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document gives examples of SIP call flows for T.38 Internet fax communications (SIP, the Session Initiation Protocol is defined in RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and Gateways to the PSTN (Public Switch Telephone Network). This document introduces best current practices for T.38 fax calls: a call starts with audio capabilities, and, upon fax tone detection, T.38 fax capabilities are negotiated. The T.38 fax call scenarios include the detection of T.38 fax transmission by the receiving side, or the emitting side, or both (in the latter case, a 'glare' effect may appear). The current version of this document only covers the case when the fax tone is detected by the receiving side (other cases were left for discussion and may be included in the future). Call flow diagrams and message details are shown. A list of IANA defined SDP attribute names for T.38 is summarized in section 5. Mule, et al. SIP WG 1 SIP T.38 Call Flows October 2000 2. Conventions used in this document 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 RFC-2119 [4]. 3. Overview The call flows shown in this document complements the overall SIP call flow Internet Draft [5]. It is the intent of the authors to merge these T.38 specific call flows into the main I-D. The current version of this document deals primarily with T.38 over UDPTL (T.38 fax calls over TCP using SIP may be added in the future; the call flows would use the same principles with different media descriptions). These T.38 call flows were developed in the design of carrier-class SIP Telephony products supporting voice and real-time fax traffic. It is the hope of the authors that this document will be useful for the SIP community, SIP implementors of T.38 fax products, designers. These call flows are based on the current version 2.0 of SIP in RFC2543[6], the ITU-T T.38 Amendment 2 [7] and a SG8 liaison to IANA. 3.1. General Assumptions T.38 fax gateways may detect various fax tones (CNG, CED, etc.) or flag sequence (like Preamble) and pass these in the audio RTP streams before they are detected. Once detected by the DSP, T.38 fax gateways switch from audio to fax mode and initiate a T.38 fax packet transmission. These best current practices apply with both "Network Gateway" and "Enterprise Gateway". 3.2 Legend for Message Flows The legend defined [5] also applies in this document. Dashed lines (---) represent control messages that are mandatory to the call scenario. These control messages can be SIP or PSTN signaling. Double dashed lines (===) represent media paths between network elements. Messages with parenthesis around name represent optional control messages. Messages are identified in the Figures as F1, F2, etc. This references the message details in the table that follows the Figure. Comments in the message details are shown in the following form: /* Comments. */ Mule, et al. 2 SIP T.38 Call Flows October 2000 3.3 Internet Fax gateways and fax handling assumptions The handling of fax transmission depends on the nature of the gateways. There are 2 distinct cases: . The Internet fax gateway supports fax communications only. The Internet fax gateway always initiates a SIP call with T.38 SDP capabilities (this is typically the case of Internet Fax Terminals, also called Internet-aware fax terminals or the case of gateways statically configured to support T.38 fax calls only) . The IP telephony gateway supports voice, fax and voice-band date communications. In this case, the IP telephony gateway initiates a voice call with audio SDP cap, and, upon fax detection, the switch-over to T.38 fax capabilities is triggered. In the rest of this document, we deal with the second case which is more general. Three possible ways exist for detecting a fax communication and modifying a SIP session to allow T.38 fax: 1. On the emitting gateway (the one sending the fax), a CNG tone is detected and triggers the fax channel initiation. However the CNG tone is optional. 2. On the receiving gateway (the one receiving the fax), a CED tone is generated and triggers the fax channel initiation. The CED tone is also optional. The authors of this document believe this second option is the preferred one and MUST be supported by SIP Internet Fax gateways. 3. On the receiving gateway, no CED tone is present, so the Preamble flag sequence triggers the fax channel initiation. The Preamble is always present and follows the CED tone when CED is present. The authors of this document believe this third option should be the method used in the absence of the CED tone. It MUST be supported by SIP implementations. In conclusion, several conditions can trigger fax detection. The authors of this document recommend detection of a fax transmission on the receiving side of the fax call by recognizing the CED tone if CED is present or the Preamble flag sequence if and only if CED is not present. Even if the emitting side detects a fax (CNG tone), it MUST not initiate the switch over. The receiving side MUST initiate the re-INVITE with proper SDP description to support fax communications. If a SIP session starts with audio capabilities, then ôswitchö to fax capabilities, it must switch back to audio mode after fax transmission or it must be terminated. 4 T.38 Fax Call (fax detection on receiving side) Mule, et al. 3 SIP T.38 Call Flows October 2000 4.1 Fax transmission This section represents the SIP call flow for a T.38 fax session between 2 Internet telephony gateways or Internet fax terminals. A call starts with audio capabilities, then the session is modified to t38 fax mode (t.38/udptl). The mechanism for supporting T.38 in SIP & SDP is detailed in T.38 Annex D [8], a temporary document that proposes an amendment to T.38 describing SIP call establishment procedures. Scenario: 1. A SIP INVITE is sent to the called party requesting a voice connection per RFC2543; our scenario involves 1 SIP proxy. An audio connection is established; 2. Upon detection of CED tone or Preamble by the terminating gateway, a second SIP INVITE request is sent to the emitting gateway to modify the parameters of the session to allow a T.38 fax connection. This INVITE request has the same CALL-ID as the existing voice call but a higher Cseq number and an SDP message body detailing T.38 capabilities; 3. It is suggested that the voice pipe be muted while the fax session is in progress. Upon successful acknowledgments, T.38 IFP fax packets are sent/received on different UDP ports than the one used for audio RTP; 4. Once the fax transmission is terminated, audio capabilities are ôrestoredö or the call is terminated. 4.2. Sequence Diagram In our example, we illustrate the fact that Internet telephony gateways may use multiple network interfaces for signaling and/or media streaming or one network interface with multiple IP addresses. Typically, our example shows: - one interface for SIP signaling (ingress gateway = ift.here.com, egress gateway = iftgw.there.com) - one or multiple interface(s) for media transport: (ingress gateway = iftmg.here.com, egress gateway = iftmg.there.com) A proxy is acting as a pure SIP signaling proxy (ss1.wcom.com). Mule, et al. 4 SIP T.38 Call Flows October 2000 IFT UA Proxy IFTGW UA | | | | F1 INVITE | | |------------------->| | | | F2 INVITE | | |------------------->| | F3 100 Trying | | |<-------------------| F4 100 Trying | | |<-------------------| | | | | | F5 180 Ringing | | F6 180 Ringing |<-------------------| |<-------------------| | | | F7 200 OK | | F8 200 OK |<-------------------| |<-------------------| | | | | | F9 ACK | | |------------------->| F10 ACK | | ------------------->| | | | Both Way RTP Media Established | Fax |<=======================================>| ------->| | emitted | | | CED or | | | Preamble | | |<--------- | | F11 INVITE | detected | |<-------------------| | F12 INVITE | | |<-------------------| | | | | | F13 200 OK | | |------------------->| | | | F14 200 OK | | |------------------->| | | | | | F15 ACK | | |<-------------------| | F16 ACK | | |<-------------------| | | | | T.38/UDPT Fax Flow Established | |<=======================================>| End of | | fax | | | detected| | | ------->| | | | | | | | | End of fax | | |<---------- | | F17 INVITE | detected Mule, et al. 5 SIP T.38 Call Flows October 2000 | |<-------------------| | F18 INVITE | | |<-------------------| | | | | | F19 200 OK | | |------------------->| | | | F20 200 OK | | |------------------->| | | | | | F21 ACK | | |<-------------------| | F22 ACK | | |<-------------------| | | F23 BYE | | |------------------->| | | | F24 BYE | | |------------------->| | | | | | F25 200 OK | | |<-------------------| | F26 200 OK | | |<-------------------| | Mule, et al. 6 SIP T.38 Call Flows October 2000 4.3. Message Details F1 INVITE IFT UA -> PROXY INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 17 INVITE Content-Type: application/sdp Content-Length: 146 v=0 o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 INVITE PROXY -> IFTGW UA INVITE sip:+1-650-555-2222@iftgw.there.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 55 INVITE Content-Type: application/sdp Content-Length: 146 v=0 o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F3 (100 Trying) PROXY -> IFT UA SIP/2.0 100 Trying Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 17 INVITE Mule, et al. 7 SIP T.38 Call Flows October 2000 Content-Length: 0 F4 100 Trying IFTGW UA -> PROXY SIP/2.0 100 Trying Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 55 INVITE Content-Length: 0 F5 180 Ringing IFTGW UA -> PROXY SIP/2.0 180 Ringing Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 55 INVITE Content-Length: 0 F6 180 Ringing PROXY -> IFT UA SIP/2.0 180 Ringing Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 17 INVITE Content-Length: 0 F7 200 OK IFTGW UA -> PROXY SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 55 INVITE Content-Type: application/sdp Content-Length: 150 v=0 o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP Mule, et al. 8 SIP T.38 Call Flows October 2000 c=IN IP4 iftmg.there.com t=0 0 m=audio 12323 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F8 200 OK PROXY -> IFT UA SIP/2.0 200 OK Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 17 INVITE Content-Type: application/sdp Content-Length: 150 v=0 o=IFAXTERMINAL01 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=audio 12323 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F9 ACK IFT UA -> PROXY ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 17 ACK Content-Length: 0 F10 ACK PROXY -> IFTGW UA ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 55 ACK Content-Length: 0 /* RTP streams are established. The CNG fax tone is sent in-band if it is present. The receiving side IFT gateway DSP detects the Preamble. A new UDP port is open on IFTGW for T.38 IFP packets and the IFTGW signals the switch over to fax mode by send a RE-INVITE Mule, et al. 9 SIP T.38 Call Flows October 2000 with the same call ID, higher Cseq number and with the new UDP port in the SDP Note: check the T.38-specific SDP extensions (i.e. session attributes a = à). */ F11 INVITE IFTGW UA -> PROXY INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 56 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=image 49172 udptl t38 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy F12 INVITE PROXY -> IFT UA INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d008.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 18 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=image 49172 udptl t38 Mule, et al. 10 SIP T.38 Call Flows October 2000 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy F13 200 OK IFT UA -> PROXY SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d008.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 18 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890846527 2890846527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=image 15002 udptl t38 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy F14 200 OK PROXY -> IFT UA SIP/2.0 200 OK Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 56 INVITE Content-Type: application/sdp Content-Length: 320 v=0 o=faxgw1 2890846527 2890846527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com Mule, et al. 11 SIP T.38 Call Flows October 2000 t=0 0 m=image 15002 udptl t38 a=T38FaxVersion:0 a=T38maxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:260 a=T38FaxUdpEC:t38UDPRedundancy F15 ACK IFTGW UA -> PROXY ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 56 ACK Content-Length: 0 F16 ACK PROXY -> IFT UA ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d008.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 18 ACK Content-Length: 0 /* T.38 fax transmission established both ways */ /* Then, the end of the fax transmission is detected on ingress side and sent to the egress side (IFTGW). IFTGW initiates the switch back to voice communication */ F17 INVITE IFTGW UA -> PROXY INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 57 INVITE Content-Type: application/sdp Content-Length: 181 Mule, et al. 12 SIP T.38 Call Flows October 2000 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=audio 12323 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F18 INVITE PROXY -> IFT UA INVITE sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d009.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 20 INVITE Content-Type: application/sdp Content-Length: 181 v=0 o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com s=Session SDP c=IN IP4 iftmg.there.com t=0 0 m=audio 12323 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F19 200 OK IFT UA -> PROXY SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d008.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 20 INVITE Content-Type: application/sdp Content-Length: 150 v=0 o=faxgw1 2890844527 2890844527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F20 200 OK PROXY -> IFTGW UA Mule, et al. 13 SIP T.38 Call Flows October 2000 SIP/2.0 200 OK Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 57 INVITE Content-Type: application/sdp Content-Length: 150 v=0 o=faxgw1 2890844527 2890844527 IN IP4 ift.here.com s=Session SDP c=IN IP4 iftmg.here.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F21 ACK IFTGW UA -> PROXY ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 57 ACK Content-Length: 0 F22 ACK PROXY -> IFT UA ACK sip:+1-650-555-2222@ss1.wcom.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d009.1 Via: SIP/2.0/UDP iftgw.there.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 20 ACK Content-Length: 0 F23 BYE IFT UA -> PROXY BYE sip:+1-650-555-2222@ss1.wcom.com SIP/2.0 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 22 BYE Content-Length: 0 Mule, et al. 14 SIP T.38 Call Flows October 2000 F24 BYE PROXY -> IFTGW UA BYE sip:+1-650-555-2222@ss1.wcom.com SIP/2.0 Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d009.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 60 BYE Content-Length: 0 F25 200 OK IFTGW UA -> PROXY SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.wcom.com:5060; branch=2d007.1 Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 60 BYE Content-Type: application/sdp Content-Length: 0 F26 200 OK PROXY -> IFT UA SIP/2.0 200 OK Via: SIP/2.0/UDP ift.here.com:5060 From: sip:+1-303-555-1111@ift.here.com;user=phone To: sip:+1-650-555-2222@ss1.wcom.com;user=phone Call-ID: 1717@ift.here.com CSeq: 22 BYE Content-Type: application/sdp Content-Length: 0 Mule, et al. 15 SIP T.38 Call Flows October 2000 5. SDP Attribute Table for T.38 sessions For a detailed description of these attributes, refer to IANA. The tables below are replicated here for reference only. +-----------------------+---------------------+--------------+ | SDP Attribute Name | Appropriate values | Example | | ("att-field") | | | +-----------------------+---------------------+--------------+ | | | | | T38FaxVersion | 1*DIGIT | 0 | | | | | | T38maxBitRate | 1*(DIGIT) | 14400 | | | | | | T38FaxFillBitRemoval | boolean | 0 | | | | | | T38FaxTranscodingMMR | boolean | 0 | | | | | | T38FaxTranscodingJBIG | boolean | 0 | | | | | | T38FaxRateManagement | localTCF | | localTCF | | | transferredTCF | | | | | | | T38FaxMaxBuffer | 1*(DIGIT); optional | 70 | | | | (bytes) | | | | | | T38FaxMaxDatagram | 1*(DIGIT); | Depends on | | | optional | redundancy; | | | | 316 (bytes)| | | | | | T38FaxUdpEC | t38UDPFEC | | T38UDPRedund | | | t38UDPRedundancy | ancy | +-----------------------+---------------------+--------------+ Registered SDP Protocol ôprotoö for T.38: +-----------------------+ | Name | | | +-----------------------+ | | | UDPTL | | | | TCP | | | +-----------------------+ Registered SDP Protocol ôfmtö, MIME media type image/t38: MIME media type name: image MIME subtype name: t38 Mule, et al. 16 SIP T.38 Call Flows October 2000 6. Considerations In this section, we log the open items for discussion: 6.1. Level of requirements: The fax detection on receiving side: SHOULD/MUST, are gateways allowed to trigger SIP session modifications on emitting fax side? The authors recommend that T.38 Internet fax gateways MUST trigger 6.2. Negotiation of UDP ports for T.38 transmission When switching to T.38 mode, Internet fax gateways specify a new set of parameters for the media connection in SDP. Some gateways may choose the UDP/RTP port used in audio mode for UDP/UDPTL/T.38 traffic. Some gateways may choose to open a new UDP port for UDPTL/T.38 fax (and keep the previous UDP/RTP port open for the switch back to audio). SDP provides the mechanism to precisely define in SIP all cases: - if an Internet Fax gateway desires to re-use the UDP/RTP port for UDP/UDPTL/T.38, put 1 ôm=ö line in the re-INVITE. m=image udptl t38 - if an Internet Fax gateway desires to release the RTP port and open a new UDP port for T.38: m=image udptl t38 - if an Internet Fax gateway desires to keep the RTP port for future use in the session and open a new UDP port for T.38, we need to repeat the RTP/AVP port: m=audio RTP/AVP 0 m=image udptl t38 6.3. To Do List: - Add more call flows based on mailing list discussions (glare effect when both sides initiate a switch over) 7. Security Considerations The security mechanisms provided in RFC2543 apply: message authentication can be performed on SIP INVITEs and BYE. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 3 ITU-T Recommendation T.38, ôProcedures for real-time Group 3 facsimile communication over IP networksö, June 1998 Mule, et al. 17 SIP T.38 Call Flows October 2000 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Johnston, et al, ôSIP Telephony Call Flow Examplesö, Internet- Draft draft-ietf-sip-call-flows-01.txt, July 2000 6 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 7 ITU-T Recommendation T.38 Amendment 2 8 ITU-T Recommendation T.38 Annex D, ôSIP/SDP Call Establishment Proceduresö, (a.k.a. ITU-TD0262Rev1 û to be removed once annex D is published) 9. Acknowledgments This document would not have been possible without the help of engineers and fax experts, in particular: o Stanley Khouw, Bill Michalek, and Jieying Li of Clarent Corporation. 10. Author's Addresses Jean-Francois Mul‰ Clarent Corporation 700 Chesapeake Drive MS 101 Redwood City, CA 94063 Email: jfm@clarent.com Stanley Khouw Clarent Corporation Email: stanley.khouw@clarent.com Jieying Li Clarent Corporation Email: jieying.li@clarent.com Mule, et al. 18 SIP T.38 Call Flows October 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Mule, et al. 19