|
Q.931 |
H.225.0 |
SIP |
SDP |
Comments |
|
Protocol discriminator |
Should be hard coded in SIP-H323 gateway as ‘Q.931/I.451 user-network call control message’ which is 08(h) |
|||
|
Call Reference Length |
4 bits are allocated for the length of the Call Reference Value. The gateway should create this value. |
|||
|
Call Reference Value |
Call-ID, CSeq |
session id |
H.323: The default maximum Call Reference Value is 3 octets. Since 4 bits are allocated for the length of the Call Reference Value the theoretical max value is 15 octets. Different Call Reference Values are assigned for the message from a caller to a callee and the message from callee to caller. The Call Reference Values remain fixed for the lifecycle of the call. SIP: The Call-ID is same in the request and the response message. The local-id part of the Call-ID in SIP should be all digits to map to Call Reference Value. The value of CSeq is not same for different request methods. The gateway might need to create this value. |
|
|
Message Type |
05(h) for setup in Q.931 maps to INVITE method in SIP |
|||
|
Information Element |
??? |
03(h) for ‘Bearer Capability’ 08(h) for ‘Cause’, 28(h) for ‘Display’, 56(h) for ‘User-user’ in Q.931 This field should be handled in gateway. |
||
|
IE: Bearer Capability |
||||
|
Coding Standard |
00(b) for ‘CCITT standardized coding’. |
|||
|
Information Transfer Capability |
01000(b) for ‘Unrestricted digital information’ in Q.931. |
|||
|
Transfer Mode |
10(b) for ‘packet mode’ in Q.931 |
|||
|
Information Transfer Rate |
00000(b) for ‘packet mode call’ in Q.931 |
|||
|
User Layer 1 Protocol |
00101(b) for ‘Rec. 221 and H.242’ in Q.931 |
|||
|
IE: Display |
||||
|
Length of Display |
||||
|
Display Info |
From |
Display Info is the name of the caller (IA5 char) usually. The display-name part of the From in SIP maps to it. |
||
|
IE: User-user |
||||
|
Length of user-user |
This is the length of the H.225.0 part. |
|||
|
Protocol Discriminator |
05(h) for ‘X.208 and X.209 coded user information’ in Q.931 |
|||
|
h323-message-body: setup |
Method: INVITE |
Mapping the choices in h323-message-body. setup (H323): INVITE (SIP) callProceeding (H323): 100 (SIP) alerting (H323): 180 (SIP) connect (H323): 200 (SIP) userInformation (H323): ?? (SIP) releaseComplete (H323): BYE, 200 (SIP) facility (H323) : INVITE, 181 (SIP) (facility is to request or acknowledge a supplementary service. In SIP INVITE can handle more than one-to-one phone call. 181 is used to indicate that the call is forwarded. |
||
|
Setup-UUIE :ProtocolIdentifier: 0 0 8 2250 0 1 |
The gateway has to generate the protocolIdentifier. |
|||
|
sourceAddress:
|
From |
The choices for the sourceAddress are e164, h323-ID, url-ID, transportID, email-ID, and partyNumber. The email-ID is rfc822 compliant email address. |
||
|
sourceInfo: vendorIdentifier: |
User Agent, User Server |
Look at User Agent, User Server |
||
|
destinationCallSignalAddress: ipAddress & port |
To (host and port) |
|||
|
activeMC: Boolean |
This will be False for SIP for now. |
|||
|
conferenceId |
CallID |
The conferenceId meant to be a glabally unique identifier. It is 16 octets and there is a rule to make this 16 octets. Consult section 7.4 of h.2250. The gateway should generate the conferenceId and map to CallID of SIP. |
||
|
conferenceGoal: create |
conferenceGoal: create - start a new conferenceinvite - invite a party into an existing conference join - join an existing conference capability-negotiation - negotiate capabilities for a later loosely-coupled conference callIndependentSupplementaryService - transport of supplementary services APDUs in a non-call related manner There is no difference between create and invite in SIP. The gateway should see whether the INVITE in SIP is for starting a new conference or for inviting a party into an existing conference. |
|||
|
callType: pointToPoint |
SIP doesn’t define callType since it can add a party later. |
|||
|
SourceCallSignalAddress: ipAddress & port |
From |
|
Q.931 |
H.225.0 |
SIP |
SDP |
Comments |
|
Protocol discriminator |
Should be hard coded in SIP-H323 gateway as ‘Q.931/I.451 user-network call control message’ which is 08(h) |
|||
|
Call Reference Length |
4 bits are allocated for the length of the Call Reference Value. The gateway should create this value. |
|||
|
Call Reference Value |
Call-ID, CSeq |
session id |
H.323: The default maximum Call Reference Value is 3 octets. Since 4 bits are allocated for the length of the Call Reference Value the theoretical max value is 15 octets. Different Call Reference Values are assigned for the message from a caller to a callee and the message from callee to caller. The Call Reference Values remain fixed for the lifecycle of the call. SIP: The Call-ID is same in the request and the response message. The local-id part of the Call-ID in SIP should be all digits to map to Call Reference Value. The value of CSeq is not same for different request methods. The gateway might need to create this value. |
|
|
Message Type |
01(h) for alerting in Q.931 maps to response 180 in SIP |
|||
|
Information Element |
??? |
03(h) for ‘Bearer Capability’ 08(h) for ‘Cause’, 28(h) for ‘Display’, 56(h) for ‘User-user’ in Q.931 |
||
|
IE: User-user |
||||
|
Length of user-user |
This is the length of the H.225.0 part. |
|||
|
Protocol Discriminator |
05(h) for ‘X.208 and X.209 coded user information’ in Q.931 |
|||
|
h323-message-body: alerting |
Response 180 |
Mapping the choices in h323-message-body. setup (H323): INVITE (SIP) callProceeding (H323): 100 (SIP) alerting (H323): 180 (SIP) connect (H323): 200 (SIP) userInformation (H323): ?? (SIP) releaseComplete (H323): BYE, 200 (SIP) facility (H323) : INVITE, 181 (SIP) (facility is to request or acknowledge a supplementary service. In SIP INVITE can handle more than one-to-one phone call. 181 is used to indicate that the call is forwarded. |
||
|
Alerting-UUIE :ProtocolIdentifier: 0 0 8 2250 0 1 |
The gateway has to generate the protocolIdentifier. |
|||
|
destinationInfo: EndpointType ::= Sequence{ nonStandardData (o) vendor (o) gatekeeper (o) gateway (o) mcu (o) terminal (o) mc: False (m) undefinedNode: False (m) } |
destinationInfo contains an EndpointType to allow the caller to determine whether the call involves a gateway or not.
* In the sampled data, terminal, mc and undefinedNode were detected since there wasn’t any gateway nor gatekeeper involved. |
|
Q.931 |
H.225 |
SIP |
SDP |
Comment |
|
Protocol discriminator |
Should be hard coded in SIP-H323 gateway as ‘Q.931/I.451 user-network call control message’ which is 08(h) |
|||
|
Call Reference Length |
4 bits are allocated for the length of the Call Reference Value. The gateway should create this value. |
|||
|
Call Reference Value |
Call-ID, CSeq |
session id |
H.323: The default maximum Call Reference Value is 3 octets. Since 4 bits are allocated for the length of the Call Reference Value the theoretical max value is 15 octets. Different Call Reference Values are assigned for the message from a caller to a callee and the message from callee to caller. The Call Reference Values remain fixed for the lifecycle of the call. SIP: The Call-ID is same in the request and the response message. The local-id part of the Call-ID in SIP should be all digits to map to Call Reference Value. The value of CSeq is not same for different request methods. The gateway might need to create this value. |
|
|
Message Type |
07(h) for Connect in Q.931 maps to response 200 in SIP |
|||
|
IE: Bearer Capability |
||||
|
Coding Standard |
00(b) for ‘CCITT standardized coding’. |
|||
|
Information Transfer Capability |
01000(b) for ‘Unrestricted digital information’ in Q.931. |
|||
|
Transfer Mode |
10(b) for ‘packet mode’ in Q.931 |
|||
|
Information Transfer Rate |
00000(b) for ‘packet mode call’ in Q.931 |
|||
|
User Layer 1 Protocol |
00101(b) for ‘Rec. 221 and H.242’ in Q.931 |
|||
|
IE: Display |
||||
|
Length of Display |
||||
|
Display Info |
To |
Display Info is the name of the callee (IA5 char) usually. The display-name part of the To in SIP maps to it. |
||
|
IE: User-user |
||||
|
Length of user-user |
This is the length of the H.225.0 part. |
|||
|
Protocol Discriminator |
05(h) for ‘X.208 and X.209 coded user information’ in Q.931 |
|||
|
h323-message-body: connect |
200 |
Mapping the choices in h323-message-body. setup (H323): INVITE (SIP) callProceeding (H323): 100 (SIP) alerting (H323): 180 (SIP) connect (H323): 200 (SIP) userInformation (H323): ?? (SIP) releaseComplete (H323): BYE, 200 (SIP) facility (H323) : INVITE, 181 (SIP) (facility is to request or acknowledge a supplementary service. In SIP INVITE can handle more than one-to-one phone call. 181 is used to indicate that the call is forwarded. |
||
|
Connect-UUIE :ProtocolIdentifier: 0 0 8 2250 0 1 |
The gateway has to generate the protocolIdentifier. |
|||
|
h245Address ipAddress & port |
??? |
Can the address for H.245 message be conveyed in the message body (SDP) ? The H.245 request messages will be sent to this new address. How this can be mapped to SIP operation ? The Release H.225 message though still will use the H.225 address. |
||
|
destinationInfo: vendorIdentifier: |
Haven’t found the matching one in SIP. (vendor, productId, and versionId) |
|||
|
conferenceId |
CallID |
The conferenceId meant to be a glabally unique identifier. It is 16 octets and there is a rule to make this 16 octets. Consult section 7.4 of h.2250. The gateway should create a conferenceId for the CallID of SIP. |
|
Q.931 |
H.225 |
SIP |
SDP |
Comments |
|
Protocol discriminator |
Should be hard coded in SIP-H323 gateway as ‘Q.931/I.451 user-network call control message’ which is 08(h) |
|||
|
Call Reference Length |
4 bits are allocated for the length of the Call Reference Value. The gateway should create this value. |
|||
|
Call Reference Value |
Call-ID, CSeq |
session id |
H.323: The default maximum Call Reference Value is 3 octets. Since 4 bits are allocated for the length of the Call Reference Value the theoretical max value is 15 octets. Different Call Reference Values are assigned for the message from a caller to a callee and the message from callee to caller. The Call Reference Values remain fixed for the lifecycle of the call. SIP: The Call-ID is same in the request and the response message. The local-id part of the Call-ID in SIP should be all digits to map to Call Reference Value. The value of CSeq is not same for different request methods. The gateway might need to create this value. |
|
|
Message Type |
ReleaseComplete |
BYE |
5A (h) for Release Complete in Q.931 maps to request BYE in SIP. In Q.931, there is a difference between Release and ReleaseComplete, H.323 only uses release complete, I think. Release message is sent by the user or network to indicate that the equipment sending the message has disconnected the channel, and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COMPLETE. Release complete message is sent by the user or network to indicate that the equipment sending the message has released the channel and call reference. This channel is available for reuse, and the receiving equipment shall release the call reference. BYE in SIP, A party to a call should issue a BYE request before releasing a call.
|
|
|
IE: Cause |
||||
|
Length of Cause |
||||
|
Coding Standard |
00(b) for ‘CCITT standardized coding’. |
|||
|
Location: user or network. |
For the normal release, it should be user. |
|||
|
Recommendation: Q.931 |
||||
|
Cause Value: Normal Call Clearing. |
Normal Call Clearing , Please consult H.2250 7.2.2.8 for the list of Cause value. |
|||
|
IE: User-user |
||||
|
Length of user-user |
This is the length of the H.225.0 part. |
|||
|
Protocol Discriminator |
05(h) for ‘X.208 and X.209 coded user information’ in Q.931 |
|||
|
h323-message-body: releaseComplete |
BYE |
Mapping the choices in h323-message-body. setup (H323): INVITE (SIP) callProceeding (H323): 100 (SIP) alerting (H323): 180 (SIP) connect (H323): 200 (SIP) userInformation (H323): ?? (SIP) releaseComplete (H323): BYE, 200 (SIP) facility (H323) : INVITE, 181 (SIP) (facility is to request or acknowledge a supplementary service. In SIP INVITE can handle more than one-to-one phone call. 181 is used to indicate that the call is forwarded. |
||
|
ReleaseComplete-UUIE :ProtocolIdentifier: 0 0 8 2250 0 1 |
The gateway has to generate the protocolIdentifier. In ReleaseComplete-UUIE, the releaseCompleteReason is optional. The callIdentifier is added in H225.0v2, but not implemented in NetMeeting yet. |
|
Q.931 |
H.225 |
SIP |
SDP |
Comments |
|
Protocol discriminator |
Should be hard coded in SIP-H323 gateway as ‘Q.931/I.451 user-network call control message’ which is 08(h) |
|||
|
Call Reference Length |
4 bits are allocated for the length of the Call Reference Value. The gateway should create this value. |
|||
|
Call Reference Value |
Call-ID, CSeq |
session id |
H.323: The default maximum Call Reference Value is 3 octets. Since 4 bits are allocated for the length of the Call Reference Value the theoretical max value is 15 octets. Different Call Reference Values are assigned for the message from a caller to a callee and the message from callee to caller. The Call Reference Values remain fixed for the lifecycle of the call. SIP: The Call-ID is same in the request and the response message. The local-id part of the Call-ID in SIP should be all digits to map to Call Reference Value. The value of CSeq is not same for different request methods. The gateway might need to create this value. |
|
|
Message Type |
ReleaseComplete |
200 |
5A (h) for Release Complete in Q.931 maps to response 200 in SIP if this party is responding to BYE request. In Q.931, there is a difference between Release and ReleaseComplete, H.323 only uses release complete, I think. Release message is sent by the user or network to indicate that the equipment sending the message has disconnected the channel, and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COMPLETE. Release complete message is sent by the user or network to indicate that the equipment sending the message has released the channel and call reference. This channel is available for reuse, and the receiving equipment shall release the call reference. BYE in SIP, A party to a call should issue a BYE request before releasing a call.
|
|
|
IE: Cause |
||||
|
Length of Cause |
||||
|
Coding Standard |
00(b) for ‘CCITT standardized coding’. |
|||
|
Location: user or network. |
For the normal release, it should be user. |
|||
|
Recommendation: Q.931 |
||||
|
Cause Value: Normal Call Clearing. |
Normal Call Clearing , Please consult H.2250 7.2.2.8 for the list of Cause value. |
|||
|
IE: User-user |
||||
|
Length of user-user |
This is the length of the H.225.0 part. |
|||
|
Protocol Discriminator |
05(h) for ‘X.208 and X.209 coded user information’ in Q.931 |
|||
|
h323-message-body: releaseComplete |
BYE |
Mapping the choices in h323-message-body. setup (H323): INVITE (SIP) callProceeding (H323): 100 (SIP) alerting (H323): 180 (SIP) connect (H323): 200 (SIP) userInformation (H323): ?? (SIP) releaseComplete (H323): BYE, 200 (SIP) facility (H323) : INVITE, 181 (SIP) (facility is to request or acknowledge a supplementary service. In SIP INVITE can handle more than one-to-one phone call. 181 is used to indicate that the call is forwarded. |
||
|
ReleaseComplete-UUIE :ProtocolIdentifier: 0 0 8 2250 0 1 |
The gateway has to generate the protocolIdentifier. In ReleaseComplete-UUIE, the releaseCompleteReason is optional. The callIdentifier is added in H225.0v2, but not implemented in NetMeeting yet. |