단문 메시지 피어 투 피어

이 문서에는 일반적인 참조 목록이 포함되어 있지만 대응하는 충분한 인라인 인용이 없습니다. 좀 더 정밀한 인용문을 도입하여 이 글의 개선에 도움을 주시기 바랍니다.(2018년 11월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

통신업계의 Short Message Peer-to-Peer(SMPP; 단문메시지 피어 투 피어)는 외부단문메시지 엔티티(ESME), 라우팅 엔티티(RE) 및 ^[2]SMSC 간의 단문메시지^[1] 데이터 전송을 위한 유연한 데이터 통신 인터페이스를 제공하도록 설계된 개방형 업계 표준 프로토콜입니다.

SMPP는 종종 제3자(예: 뉴스 기관 등 부가가치 서비스 제공업체)가 메시지를 대량으로 제출할 수 있도록 하기 위해 사용되지만 SMS 피어링에도 사용될 수 있습니다.SMPP는 EMS, 보이스 메일 알림, 셀브로드캐스트, WAP 푸시 메시지(MMS 알림 전송에 사용), USSD 메시지 등의 짧은 메시지를 전송할 수 있습니다.SMPP는 범용성과 UMTS, IS-95(CDMA), CDMA2000, ANSI-136(TDMA), iDEN 등의 비GSM SMS 프로토콜에 대한 지원으로 SS7 네트워크 외부에서 가장 일반적으로 사용되는 프로토콜입니다.

역사

SMPP(Short Message Peer-to-Peer)는 로지카에 인수된 아일랜드의 작은 회사 알디스콘이 설계한 것이다(2016년부터 수많은 변경 끝에).이 프로토콜은 원래 SS7 테스트 장비를 사용하여 메시지를 제출하지 않고 SMSC의 기능을 테스트하기 위해 개발자인 Ian J Chambers에 의해 만들어졌습니다.1999년 Logica는 SMPP를 SMPP Developers Forum에 정식으로 넘기고 나중에 The SMS Forum으로 개명하여 현재는 해체되었습니다.원래 인도 조건의 일부로서 SMS 포럼의 해체로 인해 SMPP의 소유권은 Mavenir로 반환되었습니다.

현재까지 SMPP 개발은 중단되고 SMS 포럼은 해체되었습니다.SMS 포럼 웹사이트:

2007년 7월 31일 - SMS(단문메시지 서비스)의 개발, 육성, 홍보를 글로벌 무선산업에 기여하는 사명을 가진 비영리단체인 SMS 포럼은 2007년 7월 27일까지 해산됩니다.

뉴스에 첨부된 보도 자료는 그 사이트가 곧 폐쇄될 것이라고 경고하는 데 사용되었다.그럼에도 불구하고, 사이트는 대부분 작동하고 있었고 사양서는 다운로드 할 수 있었다(2012년 1월 31일 현재).2021년 4월 12일부로 웹사이트 소유자가 변경되어 미러 사이트에서만 다운로드가 가능합니다.

1995년에 ETSI는 SMPP 프로토콜을 기술 보고서 TR 03.^[3]39에 포함시켰습니다.

작동

이름과는 달리 SMPP는 클라이언트-서버 모델의 동작을 사용합니다.Short Message Service Center(SMSC; 단문 메시지서비스 센터)는 보통 서버로서 기능하며 ESME로부터의 접속을 기다립니다.SMPP 가 SMS 피어링에 사용되는 경우, 통상, 송신측 MC 는 클라이언트로서 동작합니다.

이 프로토콜은 OSI 레이어 4(^[4]TCP 세션 또는 X.25 SVC3) 연결을 통해 교환되는 요청/응답 PDU(프로토콜 데이터 유닛 또는 패킷) 쌍을 기반으로 합니다.IANA가 TCP 경유로 동작할 때 SMPP용으로 할당하는 기존의 포트는 2775이지만 메시징 환경에서는 여러 개의 임의의 포트 번호가 사용되는 경우가 많습니다.

메시지를 교환하기 전에 bind 명령어를 전송하고 확인을 해야 합니다.bind 명령어는 메시지를 보낼 수 있는 방향을 결정합니다.bind_transmitter는 클라이언트의 서버로의 메시지 전송만 허용하고 bind_receiver는 클라이언트의 메시지 수신만 허용하며 bind_transceiver(SMPP 3.4에서 도입)는 양방향 ^[5]메시지 전송을 허용합니다.bind 명령에서는 ESME는 system_id, system_type 및 비밀번호를 사용하여 자신을 식별합니다.일반적으로 ESME 주소를 포함하도록 설계된 address_range 필드는 비워 둡니다.bind 명령어에는 사용할 SMPP 프로토콜 버전을 지정하기 위한 interface_version 파라미터가 포함되어 있습니다.

메시지 교환은 각 피어가 전송되는 각 PDU에 대한 응답을 기다리는 동기식 또는 비동기식으로 여러 요구를 대기하지 않고 발행하여 다른 피어에 의해 스큐 순서로 확인 응답할 수 있습니다.확인되지 않은 요구의 수를 창이라고 부릅니다.최적의 퍼포먼스를 얻으려면 , 양쪽의 통신측을 설정할 필요가 있습니다.같은 창 크기입니다.

버전

SMPP 표준은 그동안 발전해 왔습니다.가장 일반적으로 사용되는 SMPP 버전은 다음과 같습니다.

• SMPP 3.3은 가장 오래된 사용 버전(제한사항에도 불구하고 여전히 널리 사용됨)으로 GSM만을 지원합니다.전송되는 각 메시지에 대해 즉시 응답을 생성합니다.
• SMPP 3.4에는 옵션의 Tag-Length-Value(TLV; 태그 길이 값) 파라미터, 비 GSM SMS 테크놀로지 지원 및 트랜시버 지원(메시지를 송수신할 수 있는 단일 연결)이 추가되었습니다.ESME 송신기와 SMSC 사이의 SMPP 요구 및 응답 PDU 교환은 동기 또는 비동기적으로 이루어질 수 있습니다.
• SMPP 5.0은 SMPP의 최신 버전으로 셀브로드캐스트, 스마트플로우 제어 지원이 추가되었습니다.2019년 현재 널리 사용되고 있지 않다.

해당 버전은 bind 명령어의 interface_version 파라미터로 전달됩니다.

PDU 형식(버전 3.4 이후)

SMPP PDU는 효율성을 위해 바이너리로 인코딩됩니다.선두에는 머리글이 붙고, 그 뒤에 본문이 붙을 수 있습니다.

SMPP PDU
PDU 헤더(필수)				PDU 본체(옵션)
명령어 길이	명령어 Id	명령어 상황	순서 번호	PDU 본체
4 옥텟	길이 = (명령 길이 값 - 4) 옥텟

PDU 헤더

각 PDU는 헤더로 시작합니다.헤더는 4개의 필드로 구성되어 있으며 각 필드는 4개의 옥텟 길이입니다.

command_length

PDU의 전체 길이(command_length 필드 자체 포함)입니다.각 PDU에는 16 옥텟헤더가 포함되어 있어야 하기 때문에 16 이하여야 합니다.

command_id

SMPP 동작(또는 명령어)을 식별합니다.최상위 비트가 클리어 되었을 경우, 이것은 요구 조작입니다.그렇지 않으면 응답입니다.

command_status

요청에는 항상 0의 값이 지정되며 응답에는 작업 결과에 대한 정보가 포함됩니다.

sequence_number

SMPP 세션 내의 요구와 응답의 상관관계에 사용됩니다.비동기 통신을 가능하게 합니다(슬라이딩 윈도우 방식 사용).

SMPP의 모든 수치 필드는 빅엔디안 순서를 사용합니다.즉, 첫 번째 옥텟은 Most Significant Byte(MSB; 최상위 바이트)입니다.

예

60 옥텟의 submit_sm PDU의 바이너리 부호화의 예를 다음에 나타냅니다.데이터는 단일 덤프로 16진수 옥텟 값으로 표시되고 그 다음에 그 PDU의 헤더와 본문의 구분이 표시됩니다.

이것은 SMPP 사양의 submit_sm PDU 정의와 비교하여 부호화가 필드 정의와 어떻게 일치하는지 이해하는 것이 가장 좋습니다.

값 구분은 괄호 안에 10진수, 그 뒤에 16진수 값으로 표시됩니다.1개 또는 여러 개의 16진수 옥텟이 부가되어 있는 경우, 이는 지정된 필드 크기에서1개 이상의 옥텟 부호화가 사용되고 있기 때문입니다.

다시 submit_sm PDU의 정의를 스펙에서 읽으면 이 모든 것이 명확해집니다.

PDU 헤더

'command_length', (60)...00 00 00 3C 'command_id', (4)...00 00 00 04 'command_status', (0)...00 00 00 00 'sequence_number', (5) ...00 00 00 05

PDU 본체

'service_type', ()... 00 'source_addr_ton', (2)...02 'source_addr_npi', (8) ... 08 'source_addr', (555) ... 35 35 00 'dest_addr_npi', (1) ... 01 'dest_addr', (5555555) ... 35 35 35 00 'm_class'00 'syslog_id', (0)...00 'priority_priority', (0)...00 'delivery_time', (0)...00 'module_period', (0)...00 'registered_delivery', (0)...00 'replace_if_present_files', (0)...00 'data_data', (3)...03 'sm_default_msg_id', (0)...00 'sm_length', (15)... 0F 'short_message', (안녕하세요 위키백과)... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

short_message 필드의 텍스트는 data_coding과 일치해야 합니다.data_coding이 8(UCS2)인 경우 텍스트는 UCS-2BE(또는 그 내선번호 UTF-16BE)여야 합니다.data_coding이 7비트 부호화를 나타내는 경우 각 sept는 short_message 필드의 개별 옥텟에 저장됩니다(가장 유효한 비트는 0으로 설정됩니다).SMPP 3.3 data_coding은 GSM 03.38의 TP-DCS 값을 정확하게 복사하여 GSM 7비트의 디폴트알파벳, UCS2 또는 바이너리메시지에만 적합합니다.SMP 3.4에서는 data_coding 값의 새로운 목록이 도입되었습니다.

data_coding	의미.
0	SMSC 디폴트알파벳(SMPP 3.4)/MC 고유(SMPP 5.0)
1	IA5(CCITT T.50)/ASCII(ANSI X3.4)
2	옥텟 미지정(8비트 바이너리)
3	라틴어 1(ISO-8859-1)
4	옥텟 미지정(8비트 바이너리)
5	JIS (X 0208-1990)
6	키릴 문자(ISO-8859-5)
7	라틴어/헤브루어(ISO-8859-8)
8	UCS2(ISO/IEC-10646)
9	픽토그램 부호화
10	ISO-2022-JP(음악 코드)
11	예약필
12	예약필
13	확장 한자 JIS (X 0212-1990)
14	KS C 5601
15-191	예약되어 있다
192-207	GSM MWI 제어 - "GSM 03.38" 참조
208-223	GSM MWI 제어 - "GSM 03.38" 참조
224-239	예약되어 있다
240-255	GSM 메시지 클래스 제어 - GSM 03.38 참조

의 의미data_coding=4또는8SMPP 3.3과 동일합니다.1~15 범위의 다른 값은 SMPP 3.3으로 예약되어 있습니다.불행하게도, data_bit=0이 명백하게 GSM 7비트 기본 알파벳이었던 SMPP 3.3과는 달리, SMPP 3.4 이상의 경우 GSM 7비트 기본 알파벳은 이 목록에서 누락되었습니다.data_coding=0는 쇼트 메시지서비스 센터에 따라 다를 수 있습니다.ISO-8859-1, ASCII, GSM 7비트의 디폴트알파벳, UTF-8, 또는 ESME 단위로 설정 가능한 경우가 있습니다.사용하는 경우data_coding=0양쪽(ESME 및 SMSC)이 같은 인코딩으로 간주하고 있는 것을 확인할 필요가 있습니다.그렇지 않으면 사용하지 않는 것이 좋습니다.data_coding=0GSM 7비트의 디폴트알파벳을 사용하는 것은 까다로울 수 있습니다.단문 메시지서비스 센터에 따라서는data_coding=0, 기타.data_coding=241.

별난 일람

널리 받아들여지고 있지만 SMPP에는 다음과 같은 문제가 있는 기능이 있습니다.

• 아니요.data_codingGSM 7비트 디폴트알파벳의 경우
• 의 표준화된 의미가 없음data_coding=0
• Shift-J에 대한 지원이 불분명함IS 부호화
• 비호환성submit_sm_respSMPP 버전 간
• SMPP 3.3 SMSC Delivery Receipt(특히 메시지 ID 형식) 사용

GSM 7비트 디폴트알파벳용 data_coding 없음

SMPP 3.3의 data_coding 값은 GSM 03.38에 근거하고 있습니다만, SMPP 3.4에서는 GSM 7비트알파벳(GSM 03.38)에는 data_coding 값이 없습니다.그러나, DCS=0은 GSM 7비트 알파벳을 표시하는 것이 일반적입니다. 특히 GSM 모바일 네트워크에서 SMSC에 대한 SMPP 연결을 위해 더욱 그렇습니다.GSM과 같이7비트 알파벳이 패킹되어 140 옥텟으로 160 문자를 송신할 수 있는지, 또는 각7비트 문자가 옥텟 전체를 차지하는지(ASCII와 같이 높은 비트가0 으로 설정되어 있는 경우)는, 한층 더 불명확합니다.

data_signals=0의 표준화된 의미가 없습니다.

SMPP 3.4 및 5.0에 따르면data_coding=0는 "SMSC Default Alphabet"을 의미합니다.실제로 어떤 인코딩인지 여부는 SMSC의 유형과 설정에 따라 달라집니다.

Shift-J에 대한 지원이 불분명함IS 부호화

CDMA 표준 C의 부호화 중 하나.R1001은 Shift-JIS는 일본어를 사용합니다.SMPP 3.4 및 5.0 에서는 일본어(JIS, ISO-2022-JP 및 확장한자 JIS)의 3개의 인코딩이 지정되어 있습니다만, CDMA MSG_ENCHODING 00101과 같은 인코딩은 없습니다.SMPP 에서는, Shift-JIS 로 메시지를 반송하기 위해서, 픽토그램 부호화(data_pictogram =9)가 사용되고 있는 것 같습니다.

SMPP 버전 간의 submit_sm_resp 비호환성

submit_sm이 실패하면 SMSC는 다음을 반환합니다.submit_sm_resp값이 0이 아닌 command_status 및 "empty" message_id를 지정합니다.

• SMPP 3.3은, 에 대해서 명시적으로 기술하고 있습니다.message_id field이 필드가 존재하지 않는 경우 1개의 NULL 바이트를 포함해야 합니다.PDU의 길이는 17 옥텟 이상입니다.
• SMPP 3.4에는, 다음의 URL 에 유감의 내용이 포함되어 있습니다.SUBMIT_SM_RESP섹션 §submit_sm_respPDU 본문은 다음 경우 반환되지 않습니다.command_status필드에 0이 아닌 값이 포함되어 있습니다.§ PDU의 길이는 16 옥텟입니다.
• SMPP 5.0 에서는, 다음과 같이 지정되어 있습니다.message_idC-Octet 스트링 타입의 필수 파라미터입니다.submit_sm_resp메세지.섹션 3.1.1 NULL Settings에 따르면 'A NULL string'은 0x00으로 인코딩됩니다.PDU의 길이는 17 옥텟 이상입니다.

최적의 호환성을 위해 SMPP 구현은 양쪽 네거티브를 모두 수용해야 합니다.submit_sm_resp통신에 사용되는SMPP 표준의 버전에 관계없이,

에러 시나리오의 원래 의도는 PDU 응답으로 본문이 반환되지 않는 것이었습니다.이는 모든 Aldiscon/Logica SMSC 및 기타 대부분의 벤더에서 나타나는 표준 동작입니다.SMPP 3.4가 WAP 포럼에 의해 채택되었을 때 NACKed 응답에 본부를 포함시킬지 여부에 대한 몇 가지 명확화가 요구되었고, 이를 명세서의 여러 곳에서 명확히 하기 위한 조치가 취해졌다.submit_sm섹션 및 에 있습니다.bind_transceiver부분.V5.0에서 최종적으로 추가한 설명에 따르면 본문은 오류 응답에 포함되지 않습니다.일부 벤더는 거부된 바디를 포함하여 구현에 있어 매우 어리석었습니다.bind_transmitter응답이 없습니다.bind_transceiver응답 등벤더에 대한 권장사항..상기와 같이..두 가지 변형을 모두 수용합니다.하지만 스스로 NACKED를 발행하는 것도 현명하다.submit_sm_resp그리고.deliver_sm_resp빈 본체가 있는 PDU와 없는 PDU이들 2개의 PDU의 경우 빈 바디는 스트림의 끝에 있는 단일 NULL 옥텟처럼 보입니다.NACKed 요구에 더미 바디라고 불리는 것을 포함할 수 있는 이 기능이 필요한 이유는 방정식의 다른 쪽이 바디 결실을 허용하기 위해 구현을 변경할 수 없거나 변경할 의사가 없기 때문입니다.(Aldiscon/Logica에서 3가지 버전의 SMPP 사양에 대해 작업했으며 Openmind Networks용 ESME 솔루션을 설계했습니다.

--

SMPP 3.3 SMSC 배달 확인 메시지 ID

SMPP 3.3에서 전달 영수증을 전달하려면 텍스트 형식의 정보를 다음 주소로 전송하는 방법밖에 없습니다.short_message필드; 단, 텍스트 형식은 SMPP 3.4의 부록 B에 설명되어 있습니다.단, SMPP 3.4에서는receipted_message_id그리고.message_state목적의 TLVSMPP 3.3에서는 메시지 ID가 최대 8글자의 C-Octet String(Hex; 16진수)이라고 기술되어 있는데 반해, SMPP 3.4 사양에서는 Delivery Receipt Format의 id 필드가 최대 10글자의 C-Octet String(10진수)이라고 기술되어 있습니다.이것에 의해, SMPP 실장은 다음의 2개의 그룹으로 분할됩니다.

• Delivery Receipt 본문의 id 필드에서 정수 메시지 ID의 10진수 표현 및 에서 정수 메시지 ID의 16진수 표현을 사용한 구현message_id그리고.receipted_message_id필드
• 같은 16진수 숫자(또는 같은 임의의 문자열)를 사용하는 실장.message_id매개 변수 및 Delivery Receipt 본문의 id 필드

다만, SMPP 3.4 사양에서는, 배송 확인 형식은 SMSC 벤더 고유의 것이므로, 사양에 포함되는 형식은, 단지 하나의 가능성일 뿐입니다.위에서 설명한 바와 같이 SMPP 3.4를 사용하는 경우receipted_message_id그리고.message_state메시지 결과를 전달하려면 TLV를 사용해야 합니다.

확장성, 호환성 및 상호 운용성

버전 3.4에서 TLV 파라미터가 도입된 이후 SMPP는 확장 가능한 프로토콜로 간주될 수 있습니다.가능한 한 높은 수준의 호환성과 상호 운용성을 실현하기 위해서는, 어떠한 실장에서도, 「보내는 것은 보수적으로, 받아들이는 것은 자유롭게」라고 하는 인터넷의 견고성 원칙을 적용할 필요가 있습니다.작업을 수행하는 데 필요한 최소한의 기능 세트를 사용해야 합니다.또한 교묘한 대화가 목적이 아닌 경우, 각 구현은 다음과 같은 기준에 따라 사소한 부적합 사항을 극복해야 합니다.

• 로 응답합니다.generic_nack와 함께command_status=3인식되지 않은SMPP 명령어에 접속합니다만, 통신을 정지하지 말아 주세요.
• 인식되지 않거나 예기치 않거나 지원되지 않는 TLV 파라미터는 무시하십시오.
• PDU의 경계는 항상 PDU에 의해 지정됩니다.command_length필드. 메시지필드는 PDU의 끝을 초과할 수 없습니다.필드가 올바르게 종료되지 않은 경우 PDU의 끝에서 잘린 것으로 간주되며 이후 PDU에는 영향을 주지 않습니다.

SMPP 의 1 개의 버전에 적용되는 정보는, 예를 들면, 상기의 SMPP 3.3 의 전달 확인의 유일한 메카니즘을 기술하고 있는 SMPP 3.4 의 경우 등, 다른 버전의 SMPP 에 있는 경우가 많습니다.

보안.

SMPP 프로토콜은 SMS를 통한 원타임 패스워드 등 잠재적으로 민감한 정보에 사용할 경우 고려해야 하는 클리어 텍스트 바이너리 프로토콜로 설계되어 있습니다.단,^[6] 필요한 경우 보안 SSL/TLS를 통한 SMPP 구현이 있습니다.

「 」를 참조해 주세요.

• Universal Computer Protocol/External Machine Interface(UCP/EMI)
• 메시지 전달을 위한 컴퓨터 인터페이스(CIMD)
• 풍부한 커뮤니케이션 서비스

레퍼런스

외부 링크

• Java에서 구현된 SMPP
• SMPP 와이어샤크