Azure Communication Services 직접 라우팅: SIP 프로토콜 세부 정보

이 문서에서는 직접 라우팅에서 SIP(세션 시작 프로토콜)를 구현하여 SBC(세션 경계 컨트롤러)와 SIP 프록시 간의 적절한 트래픽 경로를 보장하는 방법을 설명합니다. 또한 특정 값이 필요한 특정 SIP 매개 변수에 대한 중요성을 강조합니다. 이 문서는 SBC와 SIP 프록시 서비스 간의 연결 구성을 담당하는 음성 관리자를 위한 것입니다.

들어오는 요청 처리: Communication Services 리소스 찾기

들어오는 통화 또는 아웃바운드 통화를 처리하기 전에 OPTIONS 메시지가 SIP 프록시와 SBC 간에 교환됩니다. 이러한 OPTIONS 메시지를 사용하면 SIP 프록시에서 SBC에 허용되는 기능을 제공할 수 있습니다. 통화를 설정하기 위해 SBC와 SIP 프록시 간의 추가 통신을 허용하려면 OPTIONS 협상이 성공(200 정상 응답)하는 것이 중요합니다. SIP 프록시에 대한 OPTIONS 메시지의 SIP 헤더 예는 다음과 같습니다.

들어오는 통화에서 SIP 프록시는 통화 대상이 되는 Azure Communication 리소스를 찾아야 합니다. 이 섹션에서는 SIP 프록시에서 리소스를 찾고 들어오는 연결에서 SBC 인증을 수행하는 방법을 설명합니다.

들어오는 통화에 대한 SIP 초대 메시지의 예는 다음과 같습니다.

초대를 받으면 SIP 프록시에서 수행하는 단계는 다음과 같습니다.

1. 인증서를 확인합니다. 초기 연결에서 직접 라우팅 서비스는 Contact 헤더에 표시된 FQDN 이름을 사용하여 제공된 인증서의 일반 이름 또는 주체 대체 이름과 일치시킵니다. SBC 이름은 다음 옵션 중 하나와 일치해야 합니다.

   • 옵션 1. Contact 헤더에 표시된 전체 FQDN 이름은 제공된 인증서의 일반 이름/주체 대체 이름과 일치해야 합니다.

   • 옵션 2. Contact 헤더에 표시된 FQDN 이름의 도메인 부분(예: sbc1.contoso.com FQDN 이름의 contoso.com)은 일반 이름/주체 대체 이름(예: *.contoso.com)의 와일드카드 값과 일치해야 합니다.

2. Contact 헤더에 표시된 전체 FQDN 이름을 사용하여 Microsoft 365 테넌트를 찾아봅니다.

   Contact 헤더의 FQDN 이름(sbc1.contoso.com)이 Microsoft 365 또는 Office 365 조직에서 DNS 이름으로 등록되어 있는지 확인합니다. 검색되면 SBC FQDN이 도메인 이름으로 등록된 테넌트에서 사용자 조회가 수행됩니다. 검색되지 않으면 3단계가 적용됩니다.

3. Contact 헤더에 표시된 전체 FQDN 이름을 사용하여 Azure Communication 리소스를 찾아봅니다.

   Contact 헤더의 FQDN 이름(sbc1.contoso.com)이 Azure Communication 리소스에서 SBC FQDN으로 등록되어 있는지 확인합니다. 검색되면 통화가 해당 리소스로 보내집니다. 검색되지 않으면 4단계가 적용됩니다.

4. 4단계는 2단계와 3단계가 실패한 경우에만 적용됩니다.

   Contact 헤더(FQDN: sbc1.contoso.com, 호스트 부분 제거 후: contoso.com)에 표시된 FQDN에서 호스트 부분을 제거하고, 이 이름이 Microsoft 365 또는 Office 365 조직에서 DNS 이름으로 등록되어 있는지 확인합니다. 검색되면 이 테넌트에서 사용자 조회가 수행됩니다. 검색되지 않으면 통화가 실패합니다.

5. 5단계는 2, 3 및 4단계가 실패한 경우에만 적용됩니다.

   Contact 헤더(FQDN: sbc1.contoso.com, 호스트 부분 제거 후: contoso.com)에 표시된 FQDN에서 호스트 부분을 제거하고, 이 이름이 Azure Communication 리소스에서 SBC FQDN으로 등록되어 있는지 확인합니다. 검색되면 통화가 해당 리소스로 보내집니다. 검색되지 않으면 통화가 실패합니다.

6. 연결된 Dynamics Omnichannel 배포가 리소스에 있는 경우 Request-URI에 표시된 전화 번호 조회를 수행합니다. 제공된 전화 번호를 이전 단계에서 찾은 Omnichannel 사용자(큐)와 일치시킵니다.

7. 7단계는 6단계가 실패한 경우에만 적용됩니다.

   Communication 리소스에 대한 Omnichannel 배포가 없거나 Request-URI의 번호가 구성된 Omnichannel 번호와 일치하지 않는 경우 통화를 Event Grid에 보냅니다.

8. 8단계는 7단계가 실패한 경우에만 적용됩니다.

   Event Grid가 구성되지 않았거나 들어오는 통화를 관리하는 규칙이 없으면 해당 통화가 끊어집니다.

Contact 헤더 및 Request-URI에 대한 세부 요구 사항

Contact 헤더

Microsoft SIP 프록시로 들어오는 모든 SIP 메시지(OPTIONS, INVITE)의 경우 Contact 헤더에는 다음과 같이 쌍을 이루는 SBC FQDN이 URI 호스트 이름에 있어야 합니다.

구문: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

RFC 3261 섹션 11.1에 따라 Contact 헤더 필드가 OPTIONS 메시지에 있을 수 있습니다. 직접 라우팅에서는 Contact 헤더가 필요합니다. OPTIONS 메시지의 경우 SIP URI에서 userinfo를 제외하고 FQDN만 다음 형식으로 보낼 수 있습니다.

구문: Contact: <sip:FQDN of the SBC;transport=tls>

이 이름(FQDN)은 제공된 인증서의 일반 이름 또는 주체 대체 이름 필드에도 있어야 합니다. Microsoft는 인증서의 일반 이름 또는 주체 대체 이름 필드에서 이름의 와일드카드 값을 사용할 수 있도록 지원합니다. 와일드카드 지원은 RFC 2818 섹션 3.1에서 설명하고 있습니다. 특별한 사항

"이름에는 단일 도메인 이름 구성 요소 또는 구성 요소 조각과 일치하는 것으로 간주되는 * 와일드카드 문자가 포함될 수 있습니다. 예를 들어 *.a.com은 foo.a.com과 일치하지만 bar.foo.a.com과는 일치하지 않습니다. f*.com은 foo.com과 일치하지만 bar.com과는 일치하지 않습니다."

SBC의 SIP 메시지에 둘 이상의 Contact 헤더 값이 표시되는 경우 Contact 헤더의 첫 번째 값 중 FQDN 부분만 사용됩니다. 직접 라우팅에 대한 경험 법칙으로 FQDN을 사용하여 IP 대신 SIP URI를 채워야 합니다. 호스트 이름이 FQDN이 아닌 IP로 표시되는 Contact 헤더가 있는 SIP 프록시로 들어오는 INVITE 또는 OPTIONS 메시지는 403 금지로 인해 연결이 거부됩니다.

Request-URI

모든 들어오는 통화에 대해 Request-URI는 수신자를 식별하는 데 사용됩니다. 현재 전화 번호는 다음 예제와 같이 더하기 기호(+)를 포함해야 합니다.

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

From 헤더

모든 들어오는 통화에 대해 From 헤더는 발신자의 전화 번호를 일치시키는 데 사용됩니다.

전화 번호는 다음 예제와 같이 +를 포함해야 합니다.

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Contact 및 Record-Route 헤더 고려 사항

SIP 프록시는 새 대화 내 클라이언트 트랜잭션(예: Bye 또는 Re-Invite)에 대해 그리고 SIP OPTIONS에 회신할 때 다음 홉 FQDN을 계산해야 합니다. 이 작업은 Contact 또는 Record-Route를 사용하여 수행할 수 있습니다. RFC 3261 섹션 8.1.1.8에 따라 새 대화가 나타날 수 있는 모든 요청에는 Contact 헤더가 필요합니다. Record-Route는 프록시가 대화에서 향후 요청의 경로를 유지하려는 경우에만 필요합니다.

다음 홉을 계산하기 위해 SIP 프록시에서 다음을 사용합니다.

• 우선 순위 1. 최상위 Record-Route. 최상위 Record-Route에 FQDN 이름이 포함되어 있는 경우 FQDN 이름은 아웃바운드 대화 내 연결을 만드는 데 사용됩니다.

• 우선 순위 2. Contact 헤더. Record-Route가 없는 경우 SIP 프록시에서 Contact 헤더 값을 조회하여 아웃바운드 연결을 만듭니다. (권장 구성입니다.)

Contact와 Record-Route가 모두 사용되는 경우 SBC 관리자는 해당 값을 동일하게 유지해야 하므로 관리 오버헤드가 발생합니다.

Contact 또는 Record-Route에서 FQDN 이름 사용

Record-Route 또는 Contact에는 IP 주소를 사용할 수 없습니다. 지원되는 유일한 옵션은 SBC 인증서의 일반 이름 또는 주체 대체 이름과 일치해야 하는 FQDN입니다(인증서의 와일드카드 값은 지원됨).

• Record-Route 또는 Contact에 IP 주소가 표시되면 인증서 확인이 실패하고 통화가 실패합니다.

• FQDN이 제공된 인증서의 일반 이름 또는 주체 대체 이름 값과 일치하지 않으면 통화가 실패합니다.

Call 컨텍스트 헤더

Call 컨텍스트 헤더는 현재 통화 자동화 SDK에만 사용할 수 있습니다. 통화 자동화 SDK는 User-To-User 헤더와 최대 5개의 사용자 지정 SIP 헤더를 지원합니다. 이러한 헤더는 INVITE 및 REFER 메서드에서 지원됩니다.

User-To-User 헤더

SIP UUI(User-To-User) 헤더는 통화 설정 프로세스 중에 컨텍스트 정보를 전달하는 업계 표준입니다. UUI 헤더 키의 최대 길이는 64자입니다. UUI 헤더 값의 최대 길이는 256자입니다. UUI 헤더 값은 영숫자 문자와 =, ;, ., !, %, *, _, +, ~, -를 포함하여 몇 가지 선택한 기호로 구성할 수 있습니다.

Custom 헤더

Azure Communication Services는 최대 5개의 사용자 지정 SIP 헤더도 지원합니다. Custom SIP 헤더 키는 필수 X-MS-Custom- 접두사로 시작해야 합니다. SIP 헤더 키의 최대 길이는 X-MS-Custom- 접두사를 포함하여 64자입니다. SIP 헤더 키는 영숫자 문자와 ., !, %, *, _, +, ~, -를 포함하여 몇 가지 선택한 기호로 구성할 수 있습니다. SIP 헤더 값의 최대 길이는 256자입니다. SIP 헤더 값은 영숫자 문자와 =, ;, ., !, %, *, _, +, ~, -를 포함하여 몇 가지 선택한 기호로 구성할 수 있습니다.

구현 세부 정보는 통화 간에 컨텍스트 데이터를 전달하는 방법을 참조하세요.

인바운드 통화: SIP 대화 설명

SIP 프록시에서 인바운드 통화를 처리하는 방법에 대한 세부 정보는 다음과 같습니다.

Azure Communication Services ID는 여러 엔드포인트(애플리케이션)에서 동시에 사용할 수 있습니다. 예를 들어 웹앱, iPhone 앱, Android 앱입니다. 각 엔드포인트에서 다음과 같이 HTTP 나머지 신호를 보낼 수 있습니다.

• 통화 진행 – SIP 프록시에서 180 SIP 메시지로 변환됩니다. 180 메시지를 받으면 SBC는 로컬 벨소리를 생성해야 합니다.

• 미디어 응답 – SIP 프록시에서 SDP(세션 설명 프로토콜)의 미디어 후보가 포함된 183 메시지로 변환됩니다. 183 메시지를 받으면 SBC는 SDP 메시지에서 받은 미디어 후보에 연결해야 합니다.

  참고 항목

  경우에 따라 미디어 응답이 생성되지 않을 수 있으며 엔드포인트에서 "통화 수락됨" 메시지로 응답할 수 있습니다.

• 통화 수락됨 – SIP 프록시에서 SDP가 있는 200 SIP 메시지로 변환됩니다. 200 메시지를 받으면 SBC는 제공된 SDP 후보와 미디어를 보내고 받아야 합니다.

  참고 항목

  직접 라우팅은 지연된 제안 초대(SDP 없이 초대)를 지원하지 않습니다.

임시 응답을 포함하여 벨을 울리는 여러 엔드포인트

1. SBC로부터 첫 번째 초대를 받으면 SIP 프록시에서 "SIP SIP/2.0 100 시도 중" 메시지를 보내고 들어오는 통화에 대해 모든 최종 사용자 엔드포인트에 알립니다.

2. 알림을 받으면 각 엔드포인트에서 벨을 울리고 "통화 진행" 메시지를 SIP 프록시로 보내기 시작합니다. Azure Communication Services ID는 여러 엔드포인트에서 사용하므로 SIP 프록시에서 여러 통화 진행 메시지를 받을 수 있습니다.

3. 엔드포인트에서 받는 모든 통화 진행 메시지에 대해 SIP 프록시에서 통화 진행 메시지를 "SIP SIP/2.0 180 벨 울리는 중" SIP 메시지로 변환합니다. 이러한 메시지를 보내는 간격은 통화 컨트롤러에서 메시지를 받는 간격과 관련이 있습니다. 다음 다이어그램에는 SIP 프록시에서 생성된 두 개의 180 메시지가 있습니다. 이러한 메시지는 두 SDK 엔드포인트에서 나옵니다. 각 엔드포인트에는 고유한 태그 ID가 있습니다. 다른 엔드포인트에서 오는 모든 메시지는 별도의 세션입니다("To" 필드의 "tag" 매개 변수가 다름). 그러나 다음 다이어그램과 같이 엔드포인트에서 180 메시지를 생성하지 않고 메시지 183 메시지를 바로 보낼 수 있습니다.

4. 엔드포인트에서 엔드포인트의 미디어 후보에 대한 IP 주소를 사용하여 미디어 응답 메시지를 생성하면 SIP 프록시에서 받은 메시지를 미디어 프로세서의 SDP로 대체된 엔드포인트의 SDP를 사용하여 "SIP 183 세션 진행" 메시지로 변환합니다. 다음 다이어그램에서는 포크 2의 엔드포인트에서 통화에 응답했습니다. 183 SIP 메시지는 한 번만 생성됩니다. 183은 기존 포크에 오거나 새 포크를 시작할 수도 있습니다.

5. 통화 수락 메시지는 통화를 수락한 엔드포인트의 최종 후보와 함께 SIP 프록시로 보내집니다. 통화 수락 메시지는 200 SIP 메시지로 변환됩니다.

   

임시 응답을 포함하지 않고 벨을 울리는 여러 엔드포인트

1. SBC로부터 첫 번째 초대를 받으면 SIP 프록시에서 "SIP SIP/2.0 100 시도 중" 메시지를 보내고 들어오는 통화에 대해 모든 최종 사용자 엔드포인트에 알립니다.

2. 알림을 받으면 각 엔드포인트에서 벨을 울리고 "통화 진행" 메시지를 SIP 프록시로 보내기 시작합니다. 동일한 Azure Communication Services ID를 여러 애플리케이션에서 사용할 수 있으므로 SIP 프록시에서 여러 통화 진행 메시지를 받을 수 있습니다.

3. 엔드포인트에서 받는 모든 통화 진행 메시지에 대해 SIP 프록시에서 통화 진행 메시지를 "SIP SIP/2.0 180 벨 울리는 중" SIP 메시지로 변환합니다. 메시지를 보내는 간격은 통화 컨트롤러에서 메시지를 받는 간격과 관련이 있습니다. 그림에는 SIP 프록시에서 생성된 두 개의 180 메시지가 있습니다. 즉, 통화가 두 개의 서로 다른 클라이언트로 포크되고 각 클라이언트에서 통화 진행 메시지를 보냅니다. 모든 메시지는 별도의 세션입니다("To" 필드의 "tag" 매개 변수가 다름).

4. 통화 수락 메시지는 통화를 수락한 엔드포인트의 최종 후보와 함께 SIP 프록시로 보내집니다. 통화 수락 메시지는 200 SIP 메시지로 변환됩니다.

   

Replaces 옵션

SBC는 Replaces를 사용하여 INVITE를 지원해야 합니다.

SDP 크기 고려 사항

직접 라우팅 인터페이스는 1,500바이트를 초과하는 SIP 메시지를 보낼 수 있습니다. 이러한 동작은 주로 SDP 크기로 인해 발생합니다. 그러나 SBC 뒤에 UDP 트렁크가 있는 경우 메시지가 Microsoft SIP 프록시에서 수정되지 않은 트렁크로 전달되면 해당 메시지가 거부될 수 있습니다. Microsoft에서는 메시지를 UDP 트렁크에 보낼 때 SBC의 SDP에서 일부 값을 제거하도록 권장합니다. 예를 들어 ICE 후보 또는 사용되지 않는 코덱을 제거할 수 있습니다.

콜 전환

직접 라우팅은 다음 두 가지 콜 전환 방법을 지원합니다.

• 옵션 1. SIP 프록시는 클라이언트의 참조를 로컬로 처리하고 RFC 3892 섹션 7.1 섹션에서 설명한 대로 참조 대상(Referee) 역할을 합니다.

  이 옵션을 사용하면 SIP 프록시에서 전환을 종료하고 새 초대를 추가합니다.

• 옵션 2. SIP 프록시는 SBC에 대한 참조를 보내고 RFC 5589 섹션 6에서 설명한 대로 전환자(Transferor) 역할을 합니다.

  이 옵션을 사용하면 SIP 프록시에서 SBC에 대한 참조를 보내고 SBC에서 전환을 완전히 처리해야 합니다.

SIP 프록시는 SBC에서 보고한 기능에 따라 메서드를 선택합니다. SBC에서 "Refer" 메서드를 지원한다고 표시하면 SIP 프록시는 옵션 2를 콜 전환에 사용합니다. Refer 메서드가 지원된다는 메시지를 보내는 SBC의 예제는 다음과 같습니다.

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

SBC에서 지원되는 메서드로 Refer를 표시하지 않으면 직접 라우팅은 옵션 1(SIP 프록시가 참조 대상 역할을 함)을 사용합니다. 또한 SBC에서 Notify 메서드를 지원한다는 신호를 보내야 합니다. Refer 메서드가 지원되지 않음을 표시하는 SBC의 예제는 다음과 같습니다.

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

SIP 프록시는 클라이언트의 참조를 로컬로 처리하고 참조 대상 역할을 합니다.

SBC에서 Refer 메서드가 지원되지 않는다고 표시한 경우 SIP 프록시는 참조 대상 역할을 합니다. 클라이언트에서 오는 Refer 요청은 SIP 프록시에서 종료됩니다. 클라이언트의 Refer 요청은 다음 다이어그램에서 "Dave로 콜 전환"으로 표시됩니다. 자세한 내용은 RFC 3892 섹션 7.1을 참조하세요.

SIP 프록시는 SBC에 대한 참조를 보내고 전환자 역할을 함

전환자로서의 SIP 프록시는 콜 전환에 대한 기본 설정 방법입니다.

표준은 RFC 5589 섹션 6에서 설명하고 있습니다. 관련 RFC는 다음과 같습니다.

• SIP(세션 시작 프로토콜) 통화 제어 - Transfer

• SIP(세션 시작 프로토콜) "Replaces" 헤더

• SIP(세션 시작 프로토콜) "Referred-By" 메커니즘

이 옵션은 SIP 프록시가 전환자 역할을 하며 Refer 메시지를 SBC에 보낸다고 가정합니다. SBC는 전환 대상 역할을 하며 Refer를 처리하여 전환에 대한 새 제안을 생성합니다. 두 가지 가능한 경우가 있습니다.

• 통화가 외부 PSTN 참가자로 전환됩니다.
• 통화가 SBC를 통해 한 SDK 엔드포인트에서 동일한 리소스의 다른 SDK 엔드포인트로 전환됩니다.

통화가 SBC를 통해 한 SDK 엔드포인트에서 다른 SDK 엔드포인트로 전환되는 경우 SBC는 Refer 메시지에서 받은 정보를 사용하여 전환 대상에 대한 새 Invite(새 대화 시작)를 실행해야 합니다. 요청 트랜잭션에 대한 To/Transferor 필드를 내부적으로 채우려면 SIP 프록시에서 이 정보를 REFER-TO/REFERRED-BY 헤더 내에 전달해야 합니다. SIP 프록시는 REFER-TO를 호스트 이름의 SIP 프록시 FQDN과 다음 중 하나로 구성된 SIP URI로 구성합니다.

• URI의 사용자 이름 부분에 있는 E.164 전화 번호(전환 대상이 전화 번호인 경우) 또는

• x-m 및 x-t 매개 변수(각각 전체 전환 대상 MRI 및 Communication 리소스 ID를 인코딩)

REFERRED-BY 헤더에는 다음 표와 같이 전환자 MRI가 인코딩된 SIP URI, 전환자 리소스 ID 및 기타 전환 컨텍스트 매개 변수가 있습니다.

이 경우 Refer 헤더의 크기는 400개의 기호가 될 수 있습니다. SBC는 최대 400개 기호 크기의 Refer 메시지 처리를 지원해야 합니다.

통화 착신 전환

Azure Communication Services 통화 자동화 SDK는 들어오는 통화를 다른 번호 또는 SDK/Teams 엔드포인트로 리디렉션하거나, 다른 사용자에게 병렬로 전화를 걸거나(동시 링), 사용자 또는 번호 그룹에 전화를 걸 수 있습니다. 고려 사항은 다음과 같습니다.

• SIP 프록시에서 사용자 C로 보내는 INVITE 요청의 Request-URI는 cause 매개 변수를 포함합니다.

• History-Info 헤더를 채웁니다.

• 사용자 A가 다른 PSTN 사용자인 경우 SIP 프록시는 사용자 A에게 "SIP SIP/2.0 181 통화 착신 전환 중"이라는 임시 응답을 생성합니다.

• 사용자 A와 사용자 C가 PSTN 사용자인 경우 SIP 프록시는 "SIP SIP/2.0 181 통화 착신 전환 중"이라는 임시 응답을 유지합니다.

• History-Info 헤더는 루프 방지에 사용해야 합니다.

세션 타이머

SIP 프록시는 세션 타이머를 지원합니다(항상 제공). SBC의 세션 타이머 사용은 필수가 아닙니다.

user=phone Request-URI 매개 변수 사용

SIP 프록시는 Request-URI를 분석하고, user=phone 매개 변수가 있는 경우 서비스에서 Request-URI를 전화 번호로 처리하여 해당 번호를 사용자와 일치시킵니다. 매개 변수가 없는 경우 SIP 프록시는 추론을 적용하여 Request-URI 사용자 형식(전화 번호 또는 SIP 주소)을 결정합니다.

Microsoft에서는 항상 user=phone 매개 변수를 적용하여 통화 설정 프로세스를 간소화하도록 권장합니다.

History-Info 헤더

History-Info 헤더는 SIP 요청의 대상을 변경하는 데 사용되며, "다양한 서비스를 네트워크 및 최종 사용자에게 사용할 수 있도록 요청 기록 정보를 캡처하기 위한 표준 메커니즘을 제공합니다." 자세한 내용은 RFC 4244 – 1.1 섹션을 참조하세요. 직접 라우팅의 경우 이 헤더는 동시 링 및 통화 착신 전환 시나리오에서 사용됩니다.

History-Info는 다음과 같이 사용하도록 설정됩니다.

• SIP 프록시는 PSTN 컨트롤러로 보내는 History-Info 헤더를 구성하는 개별 History-Info 항목에 연결된 전화 번호가 포함된 매개 변수를 삽입합니다. 전화 번호 매개 변수가 있는 항목만 사용하여 PSTN 컨트롤러에서 새 History-Info 헤더를 다시 빌드하고 SIP 프록시를 통해 SIP 트렁크 공급자에 전달합니다.

• 동시 링 및 통화 착신 전환 사례에 대한 History-Info 헤더가 추가됩니다.

• 콜 전환 사례에 대한 History-Info 헤더가 추가되지 않습니다.

• 재구성된 History-Info 헤더의 개별 기록 항목에는 URI의 호스트 부분으로 설정된 직접 라우팅 FQDN(sip.pstnhub.microsoft.com)과 결합된 전화 번호 매개 변수가 제공됩니다. SIP URI의 일부로 'user=phone' 매개 변수가 추가됩니다. 전화 컨텍스트 매개 변수를 제외하고 원래 History-Info 헤더와 연결된 다른 매개 변수는 재구성된 History-Info 헤더를 통해 전달됩니다.

  참고 항목

  프라이빗 항목(RFC 4244 섹션 3.3에 정의된 메커니즘에 따라 결정됨)은 SIP 트렁크 공급자가 신뢰할 수 있는 피어이므로 있는 그대로 전달됩니다.

• 인바운드 History-Info는 루프 방지를 위해 유지됩니다.

SIP 프록시에서 보낸 History-info 헤더의 형식은 다음과 같습니다.

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

통화가 여러 번 리디렉션된 경우 모든 리디렉션에 대한 정보는 적절한 이유와 함께 시간순으로 쉼표로 구분된 목록에 포함됩니다.

헤더 예제:

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

History-Info 헤더의 SIP URI에 대한 형식은 RFC 3261 섹션 25에 따라 지정됩니다(addr-spec의 정의 참조). 이전 예제에서 Reason URI 헤더의 원래 텍스트는 SIP;cause=496;text="User Busy"이며, 해당 ;, " 및 = 문자는 각각 %3B, %22 및 3D ASCII 16진수 값으로 이스케이프됩니다.

History-Info는 필수 TLS 메커니즘으로 보호됩니다.

직접 라우팅 및 장애 조치(failover) 메커니즘에 대한 SBC 연결

직접 라우팅 인프라 요구 사항에서 SIP 신호에 대한 장애 조치(failover) 메커니즘 섹션을 참조하세요.

Retry-After

직접 라우팅 데이터 센터의 사용량이 많은 경우 서비스는 Retry-After 메시지를 1초 간격으로 SBC에 보낼 수 있습니다. SBC에서 INVITE에 대한 응답으로 Retry-After 헤더가 포함된 503 메시지를 받으면 SBC는 해당 연결을 종료하고 다음으로 사용 가능한 Microsoft 데이터 센터를 시도해야 합니다.

다시 시도 처리(603 응답)

최종 사용자가 들어오는 통화를 거부한 후 한 통화에 대해 여러 개의 부재 중 통화를 관찰하는 경우 이는 SBC 또는 PSTN 트렁크 공급자의 다시 시도 메커니즘이 잘못 구성되었음을 의미합니다. 603 응답에 대한 다시 시도 작업을 중지하도록 SBC를 재구성해야 합니다.