H.323 연동에서 발생했던 문제점들

H.323 연동에서 발생했던 문제점들을 간략하게 적어봅니다. 개인적인 생각이므로 다른 의견이 있으면 댓글을 달아주시면 감사 ^^

 

 

H.323 연동의 문제점

 

                                                                          by sunnyside81

1. 개요

H.323장비를 연동하는 과정에서 장비들은 호환에 어려움을 겪게된다.
연동에서 생기는 대부분의 문제는 earlyh245, fastconnect, tunneling과 codec negotiation, fax 에서 발생한다.

이는 초기 version에는 이를 지원하지 않아서 나중의 version과 호환에서 문제가 발생하고지원 방법에 대한 정의가 너무 느슨하게 되어 있어서 경우의 수가 너무 많이 발생한다는 것이다.

따라서 각각의 방법에 대한 절차를 좀 더 엄격하게 정의할 필요가 있다.

아래에서는 각각의 방법에 대한 문제점을 살펴보고 문제점을 피하기 위한 간단한 절차를 제안한다.

 

2. EarlyH245
H.323 v1은 H.245절차를 connect 후에 진행하는 것으로 되어 있다.
그러나 이러한 경우 상대방이 수화기를 든 후에(connect를 전송한 후에) h.245 절차가 진행되므로
TCS, MSD, OLC 의 H.245 절차가 끝나기 전에는 음성이 전달되지 못하여 초기에 1 ~ 2초 동안은
음성이 전달되지 않으며  컬러링 같은 서비스도 할 수가 없다.

이러한 문제점을 극복하기 위해 alerting이나 callproceeding 후에 h.245 절차를 시작하게 되었고
이것을 EarlyH245 라 부른다.

 

문제점.
H.245 절차를 위해서는 q.931에 사용되는 TCP 외에 별도의 TCP를 열어야 한다. v1에서는 일반적으로 발신측에서 H.245 TCP를 열었는데 EarlyH245가 도입되면서 alerting 을 전송한 후에 수신측에서 발신측으로 h.245 TCP 를 여는 경우가 생겼다. 그런데 발신측이 earlyh245를 지원하는 경우 alerting에 h.245 address가 있으면 발신측에서 TCP 를 열려고 할 것이다. 이러한 경우 충돌이 발생하는 경우가 생긴다. 

물론 각각의 경우에 처리 절차가 표준안에 명시되어 있지만(v4) 장비들이 동작오류를 일으키는 경우가  발생한다.

 

또한 EarlyH.245 를 지원하는 장비는 alerting 후에 h.245 절차를 진행하려 하지만 지원하지 않는 장비는 alerting후에 발생하는 h.245 절차를 무시하게 된다. 이러한 경우 음성통화는 되지만 DTMF 나 fax 는 실패하게 된다.

 

아래의 절차를 제안해 본다.

 

1) EarlyH245는 alerting후에 연다.
2) EarlyH245를 지원하는 수신단말은 alerting에 h.245 주소를 첨부하여 전달한다.
3) H.245 TCP는 발신측에서 연다.
4) H.245 start를 요구하는 facility message는 보내지 않는다.
5) alerting에 h.245 주소가 없으면 earlyh245를 하지 않는다.
6) connect 에는 반드시 h.245 주소가 포함되어 있어야 한다.
7) EarlyH245를 지원하지 않는 장비는 connect에만 h.245 adress를 첨부한다.

 

setup =>
              <= call proceeding
              <= alerting(+h245addr)

tcp connect =>
         <= MSD =>
         <= TCS =>
         <= OLC =>
               <= connect(+h245addr)

 

 

3.  fastconnect

fastconnect은 h.245 절차를 별도로 진행하지 않고 q.931 메시지 안에 추가하여 절차를 빠르게 하는 방법이다.
H.245 절차인 TCS, MSD, OLC 중에서 OLC 메시지 만을 Setup에 실어 보내고 그에 대한 응답을
callproceeding, alerting, connect 메시지에 실어 보내서 속도와 절차를 간소화한 방법이다.

 

예)
Setup 메시지에 codec1, 2, 3 에대한 OLC를 실어 보내면 수신단에서는 자신이 원하는 코덱2 로 응답한다.
setup(OLC1, OLC2, OLC3) =>
                        <= call proceeding
                        <= alerting(OLC2)
                        <= connect(OLC2)

 

alerting 에 fastconnect를 첨부하여 보내면 수신단에서 수화기를 들기 전에 통화로가 구성되므로 earlyh245 효과를 내게 된다.
컬러링 같은 서비스를 위해서는 alering에 OLC 정보를 반드시 실어보내야 한다.

 

문제점
fastconnect는 h.245 session이 없다. 그런데 DTMF를 전달하는 방법은 대부분의 장비가 h.245 UserInputIndication을 사용하고 있다.
DTMF를 전달하려고 할 때 h.245 session을 여는 방법이 있으나 그러면 h.245 tcp connection을 열고 MSD, TCS 절차 후에 UII메시지를 보내야 하므로 시간이 많이 걸려서 미리 열어 놓는다.

H.245를 사용하지 않기 위해서 fastconnect를 사용했으나 DTMF 때문에 다시 H.245를 열어야 하는 문제가 발생한 것이다. 이것은 cisco가 이 방법을 채택했고 다른 단말들이 거기에 맞추기 위해서 동일한 절차를 사용하여 굳어진 절차인데 처음부터 DTMF를 q.931 Info 메시지를 사용하여 전송했다면 h.245를 사용할 필요가 없었다.

아래의 절차를 제안해 본다.

 

OLC1 = include (G.723.1)
OLC2 = include (G.729)
OLC3 = include (fax)

 

착/발신 장비가 모두 fax를 지원하고 수신단말이 G.729를 원한다면

 

setup(OLC1, OLC2, OLC3) =>
                        <= call proceeding
                        <= alerting(OLC2, OLC3)

--------------------------------------------------------

tcp connect =>

                        <= MSD =>       

                        <= TCS  =>

--------------------------------------------------------
                        <= connect(OLC2, OLC3)

 

* fax를 지원하는 장비는 음성코덱 외에 fax 정보를 포함한 OLC 를 반드시 첨부해야 한다.

* alerting에 OLC를 첨부하지 않으면 컬러링을 들을 수 없다.

* Q.931 Info로 DTMF를 전달한다면 점선안의 과정이 필요없음.

 

 

5. codec negotiation

1) h.245 절차에 의한 codec negotiation
h.245 절차가 있다면 양 단말들은 자신의 TCS(TerminalCapabilitySet)을 서로 교환하여 상대방의 능력을 알게 된 후 우선순위에 의해 코덱을 선정한 후 OLC 를 보내서 통신을 하게 된다.

 

문제점)
그런데 발신단말의 우선 순위 코덱이 G.723.1 이고 수신단말의 코덱의 우선순위가 G.729 면 각각 자신이 원하는 코덱으로 OLC절차를 수행하게 되어 양쪽의 코덱이 다르게 된다.

version2에는 표준안에는 송/수신의 코덱이 다르더라도 수용하라고 되어 있으나 실제장비는 송/수신에 동일한 코덱을 사용하므로 통신이 불가능하게 된다.

TCS는 자신의 코덱의 우선순위대로 List를 작성하므로 발신자와 수신자의 공통코덱을 고른 뒤 발신자의 우선순위 코덱에 따라  코덱을 결정하는것이 가장 합리적인 방법으로 생각된다.

 

M 값(period)의 negotiation도 문제가 되는데, 예를 들어 발신자가 G.711 을 20msec으로 보내고 수신자는 10msec으로 보낸경우에는 서로 다른 주기로 RTP 패킷을 전송하게 된다.

불행하게도 H.245 절차에서는 이것을 해결할 방법이 없다. 왜냐 하면 TCS에서는 Max 값만을 서로 교환하므로 상대방이 원하는 값은 알지 못하며, OLC는 양방향에서 동시에 진행되므로 상대방의 Period를 알 방법이 없다.

이를 해결하기 위해서는 TCS에 Max 값을 교환하지 말고 자신이 원하는 period를 명시하면 된다. 발신단은 TCS에 20msec 수신단은 10msec 를 표시하여 교환하면 양쪽은 상대방의 선호 period를 알게 된다.

 

그럼 20msec과 10msec이 만나면 무엇으로 결정할까? 이런것에 대한 언급도 표준안에는 없다.
상식적으로 Negotiation은 낮은 사양에 맞추는게 원칙이므로 20msec으로 OLC를 열면 된다.

실제 이런 문제 때문에 H.245 표준 절차는 상용에서 잘 사용하지 않는다.

 

2) faststart에 위한 codec negotiation
faststart는 setup 메시지에 코덱의 우선순위별로 OLC 정보를 포함해서 보내므로 수신단에서는 setup에 명시된 코덱을 검토하여 자신의 지원 코덱과 일치하는 것으로 응답을 하면 발신측도 그 코덱으로 RTP를 전송하게 된다.

 

faststart에서 사용하는 m값은 max 값이 아닌 실제 사용값을 적는 것이 바람직하다. 그렇지 않고 발신단에서 max 값으로 G.711a 160msec을 적어 보낸다면 수신단에서는 얼마를 원하는지 알 수가 없으므로 negotiation을 할 수가 없다.

실제로 보면 period의 negotiation은 잘 이루어지지 않는다. 이것은 표준안이 명확하게 negotiation 절차를 명시하지 않아서 대부분의 단말들이 각기 자신의 설정 값으로 보내기 때문이다.

 

* SIP 에서도 period negotiation에 대해서는 두루뭉실하게 넘어가는데 이것도 명확히 정의되어야 할것이다.

 

6. fax
T.38에 의한 방법과 PCM aLaw 에 의한 bypass 방법이 있다. 그 중 T.38에 의한 것은 말도 많고 탈도 많다. 지금은 대역폭은 문제가 되지 않으니 PCM aLaw로 bypass 시키는 방법이 최상의 방법으로 생각된다.

 

T.38을 사용해야 한다면 반드시 TCS나 faststart에 t.38 capability를 명시해야 한다. 그래야만 t.38을 지원하지 않는 장비와 호환이 가능하다.

 

* 종종 발신단에서 fax 절차를 시작하는 경우가 있는데 반드시 수신단에서만 CED tone을 감지하면 Request Mode를 통해 모드를 fax mode로 전환해야 한다.

7. 결론

H.323 의 연동이 문제가 많은건 연동 방법에 대해 많은 경우의 수를 허용하기 때문이다.

하지만 걱정 마시라. 이제 H.323 시대는 가고 SIP 의 시대가 올테니까.

다음에는 SIP 의 연동 문제에 관해서 글을 올려 볼까 한다. 

 

[출처] H.323 연동의 문제점|작성자 sunnyside81