[제한 공개]{class="badge informative"}
SMS 채널 특성 sms-channel
SMS 유형 sms-types
SMS 공급자를 통해 SMS를 전송하는 경우 3가지 유형의 SMS가 발생합니다.
- SMS MT(모바일 착신): Adobe Campaign에서 SMPP 공급자를 통해 휴대폰으로 보내는 SMS입니다.
- SMS MO(모바일 원본): 모바일에서 SMPP 공급자를 통해 Adobe Campaign으로 전송하는 SMS입니다.
- SMS SR(상태 보고서) 또는 DR 또는 DLR(배달 확인): SMPP 공급자를 통해 모바일이 Adobe Campaign으로 보낸 SMS가 성공적으로 수신되었음을 나타내는 반환 확인 메일입니다. Adobe Campaign은 종종 오류에 대한 설명과 함께 메시지가 전달되지 않았음을 나타내는 SR을 수신할 수도 있습니다.
승인(RESP PDU, SMPP 프로토콜의 일부)과 SR을 구분해야 합니다. SR은 네트워크를 통해 엔드 투 엔드 방식으로 전송되는 SMS의 일종이지만, 확인은 하나의 전송이 성공했다는 확인일 뿐입니다.
승인과 SR 모두 오류를 트리거할 수 있으므로 두 가지를 구별하면 문제 해결에 도움이 됩니다.
SMS에서 전송한 정보 sms-info
SMS는 텍스트보다 더 많은 정보를 전달합니다. 다음은 SMS에서 찾을 수 있는 항목 목록입니다.
- 텍스트는 140바이트로 제한되며, 인코딩에 따라 70~160자 사이를 의미합니다. 자세한 내용 및 제한 사항에 대해서는 아래의 SMS 텍스트 인코딩을 참조하십시오.
- ADC 또는 MSISDN("전화 번호"의 기술 이름)이라고도 하는 수신자 주소입니다. SMS를 수신할 모바일 번호입니다.
- oADC 또는 경우에 따라 발신자 ID라고 할 수 있는 발신자 주소입니다. 전화번호(일별 사용), 짧은 코드(공급자를 통해 전송된 경우) 또는 이름(SMS에 회신할 수 없는 경우 선택적 기능)일 수 있습니다.
- 메시지가 플래시 메시지인지 여부를 나타내는 플래그(플래시 메시지는 메모리에 저장되지 않은 팝업임)
- SR 예상 여부를 나타내는 플래그입니다.
- 네트워크 장비를 재시도할 수 없는 유효 날짜입니다(항상 존재하거나 적용되지 않음).
- 텍스트 인코딩을 나타내는 data_coding 필드.
SMS 텍스트 인코딩 sms-text-encoding
첫 번째 규칙은 인코딩 문제가 발생하면 항상 SMPP 공급자에게 문의 하는 것입니다. 해당 사용자만 지원하는 인코딩에 대한 정확한 지식과 기술 플랫폼의 제약으로 인해 적용할 수 있는 특수 규칙을 가지고 있습니다. SMS 파트너는 전송한 내용과 수신한 내용을 확인합니다. 성공적이고 안정적인 상호 연결을 위한 유일한 경로입니다.
SMS 메시지는 GSM7 인코딩이라고도 하는 특수 7비트 인코딩을 사용합니다. Wikipedia에는 좋은 기사가 있습니다(영어 GSM 03.38).
SMPP 프로토콜에서 GSM7 텍스트를 문자당 8비트로 확장하면 보다 간편하게 문제를 해결할 수 있습니다. SMSC는 모바일로 전송하기 전에 문자당 7비트로 압축합니다. 즉, SMPP 프레임에서 SMS의 짧은 메시지 필드 길이는 최대 160바이트일 수 있지만, 모바일 네트워크에서 전송하는 경우에는 140바이트로 제한됩니다(가장 중요한 비트는 간단히 삭제됨).
인코딩 문제가 발생하면 몇 가지 중요한 사항을 확인해야 합니다.
- 먼저 인코딩에 속한 문자를 알아야 합니다. GSM7은 발음 구별 기호(액센트)를 부분적으로 지원하는 것으로 유명합니다. 특히 프랑스어에서 é와 è는 GSM7의 일부이지만 ê, â 또는 ï은 일부가 아닙니다. 스페인어도 마찬가지다.
- cedilla(ç)가 있는 C는 GSM7 알파벳에서 대문자로만 표시되지만 통화 시 소문자 또는 "스마트" 문자로 렌더링됩니다. 일반적으로 이를 피하고 cedilla(프랑스어로 읽기가 매우 쉬움)를 없애거나 UCS-2로 전환하는 것이 좋습니다.
- SMS에서 ASCII를 사용하지 마십시오!SMPP 공급자가 명시적으로 요청하지 않는 한: 8비트 문자가 있고 GSM7보다 적용 범위가 적으므로 이 인코딩은 공간을 낭비합니다. 이러한 인코딩은 CDMA 네트워크(북아메리카에서 사용됨)에 필요할 수 있다.
- Latin-1이 항상 지원되는 것은 아닙니다. Latin-1을 사용하기 전에 SMPP 공급자와의 호환성을 확인하십시오.
- Adobe Campaign 커넥터에서는 자국어 시프트 테이블을 지원하지 않습니다. 대신 UCS-2 또는 기타 data_coding을 사용해야 합니다.
- UCS-2와 UTF-16은 종종 전화기에서 혼합됩니다. 사람들이 이모지와 UCS-2에서 거의 사용되지 않는 문자를 전송하는 경우 문제가 발생합니다.
- 이전 휴대폰에는 모든 UCS-2 문자에 대한 글꼴 글리프가 없습니다. 최신 스마트폰은 희귀 문자를 다소 쉽게 표시할 수 있는 경향이 있으며, 오래된 스마트폰은 종종 많은 이모지가 부족하고, 매우 오래된 기능 휴대폰은 일반적으로 그들이 구입했던 나라의 모국어로 유용한 것으로 제한된 지원을 받습니다. 이모지나 ASCII-art를 사용하려면 보내기 전에 다양한 휴대폰에서 테스트하십시오. 캠페인 미리 보기는 누락된 글리프를 시뮬레이트하지 않으며 미리 보기를 표시하는 웹 브라우저에서 사용할 수 있는 모든 기호를 표시합니다.
data_coding 필드에 사용된 인코딩이 표시됩니다. 중요한 문제는 사양에서 값 0이 기본 SMSC 인코딩 을 의미하며 일반적으로 GSM7을 의미하지만 항상 그런 것은 아니라는 것입니다. data_coding = 0과 연결된 인코딩을 SMPP 공급자에게 확인합니다. 다른 data_coding 값은 사양을 따르는 경향이 있지만 이를 확인하는 유일한 방법은 SMPP 공급자에게 확인하는 것입니다.
메시지의 최대 크기는 인코딩에 따라 다릅니다. 이 표에는 관련 모든 정보가 요약되어 있습니다.
다중 파트 SMS(긴 SMS) multipart-sms
다중 부분 SMS(긴 SMS라고도 함)는 여러 부분으로 전송되는 SMS입니다. 모바일 네트워크 프로토콜의 기술적 제한으로 인해 SMS는 140바이트를 초과할 수 없으므로(SMS에 사용할 수 있는 문자 수는 아래 SMS 텍스트 인코딩 섹션 참조) 더 긴 메시지를 분할해야 합니다.
긴 메시지의 각 부분은 개별 SMS입니다. 이러한 부품은 네트워크 상에서 독립적으로 이동하며 수신 휴대 전화에 의해 조립됩니다. 다시 시도 및 연결 문제를 적절하게 처리하기 위해 Campaign은 부품을 역순으로 보내고 메시지의 첫 부분(마지막으로 보낸 부분)에만 SR을 요청합니다. 휴대폰은 첫 부분을 받을 때만 메시지를 표시하므로 추가 부품의 다시 시도는 휴대폰에서 중복을 생성하지 않습니다.
게재 템플릿의 메시지당 최대 SMS 수 설정을 사용하여 메시지당 최대 SMS 수를 게재당 설정할 수 있습니다. 이 제한을 초과하는 메시지는 SMS를 보내는 동안 실패 이유가 너무 깁니다.
긴 SMS를 보내는 방법에는 두 가지가 있습니다.
- UDH
- message_payload
UDH는 긴 메시지를 보내는 기본적이고 권장되는 방법입니다. 이 모드에서 커넥터는 UDH 정보가 포함된 여러 SUBMIT_SM PDU에서 메시지를 분할합니다. 이 프로토콜은 휴대폰에서 자체적으로 사용하는 프로토콜입니다. 즉, Campaign이 메시지 생성을 가장 잘 제어하므로 보낸 부분의 수와 분할된 방식을 정확하게 계산할 수 있습니다.
message_payload 은(는) 하나의 SUBMIT_SM PDU에 전체 긴 메시지를 보내는 방법입니다. 공급자가 이를 분할해야 하므로 Campaign에서 보낸 부품의 정확한 수를 알 수 없습니다. 일부 공급자는 이 모드가 필요하지만 UDH를 지원하지 않는 경우에만 이 모드를 사용합니다.
프로토콜 및 형식에 대한 자세한 내용은 위의 SUBMIT_SM PDU의 esm_class, short_message 및 message_payload 필드에 대한 설명을 참조하십시오.