Some general questions about H.323 and SIP

[Stefan]

Hi Paul

today we discoverd some weird behavior of our WLAN-VoIP problem.
The mobile device does a registration request. After some time with no answer it does the registration request again. Shortly after this there are two registration confirm messages to the device. But the device answers with a deregistration request and then is deregistrated.
I think the problem is that the device gets this two registration confirms and then says: Hey I don't want to be registered to two of you. So it sends a deregistration request.

I hope you understand what I mean
Do you have any clou why this happens? Is it a WLAN problem or is the problem within the communication with the gatekeeper?


Another behavior we have seen is that the mobile device often sends disengage requests and gets disengage confirm messages. Every two minutes. I thought disengage requests are send if a telephone wants to end a call?

Let's now have a look at what happens when the call is over:

1. The two endpoints stop sending the RTP streams. They announce the closing of logical channels (H.245 Request CloseLogicalChannel).
2. The H.245 signalling channel is closed (H.245 command message EndSessionCommand followed by closing of the TCP connection).
3. The main signalling connection is also closed — the endpoints exchange Q.931/H.225.0 messages ReleaseComplete and the TCP connection is closed.
4. Each of the two endpoints informs the gatekeeper about the completed call with the H.225.0-RAS message Disengage Request (DRQ) and the gatekeeper confirms with Disengage Confirm (DCF).
5. And now the call is really over!

[paulej]

Stefan,

If a device sends an RRQ to the GK and then sends another RRQ, it's OK if it gets two RCF messages, because they should essentially be the same thing. The two RRQs should be re-tries and the GK should recognize those as such. In the RRQ, do you see the same or different request sequence numbers? In the RCF messages, do you see the same or different endpoint identifier values?

Is signaling getting mangled by a NAT/FW device in any way?

The steps you describe for disconnecting the call seem right. One can do it that way, or one can just send a Release Complete. In later versions of H.323, we simplified the call termination procedures, since that's what many vendors were doing, anyway. (Standards sometimes dictate behavior, but implementation should also weigh in on standards.)

As for why there is a DRQ every two minutes, that makes no sense. Does it place and drop calls every two minutes? Or is it just sending DRQs every two minutes with no impact on the call? That sounds like the endpoint is in error, in any case.

[Stefan]

Hi Paul,

If a device sends an RRQ to the GK and then sends another RRQ, it's OK if it gets two RCF messages, because they should essentially be the same thing. The two RRQs should be re-tries and the GK should recognize those as such. In the RRQ, do you see the same or different request sequence numbers? In the RCF messages, do you see the same or different endpoint identifier values?

my colleague has got the traces so I have to ask him tomorrow about the register requests. But if I remember right, they have the same sequence numbers.
about the RCF messages I give you feedback tommorow morning.

Is signaling getting mangled by a NAT/FW device in any way?

It's all within our corporate network, same subnet, no firewall or NAT between the devices. Only the connection to the internet is protected by a firewall.

The steps you describe for disconnecting the call seem right. One can do it that way, or one can just send a Release Complete. In later versions of H.323, we simplified the call termination procedures, since that's what many vendors were doing, anyway. (Standards sometimes dictate behavior, but implementation should also weigh in on standards.)

As for why there is a DRQ every two minutes, that makes no sense. Does it place and drop calls every two minutes? Or is it just sending DRQs every two minutes with no impact on the call? That sounds like the endpoint is in error, in any case.

There is no call sign because the phones can only be called from phones inside the network. I have a screenshot of a trace from last night. You can see 0:38 ; 0:40 ; 0:48 are different Disengage Requests
http://img685.imageshack.us/f/neuesbild2d.png

[paulej]

In the screen shot, I also see ARQs. It appears that calls are starting and stopping. It also appears that packets are getting dropped. Note that a few times, Wireshark reported that a TCP packet was a re-transmission. If TCP is being re-transmitted, I'd bet a few UDP packets are getting lost. Packet 636924 seems odd. I see an ACF, but I don't see the ARQ. Are there overlapping calls here?

Paul

[plong]

Hi Paul,
<snip>
There is no call sign because the phones can only be called from phones inside the network. I have a screenshot of a trace from last night. You can see 0:38 ; 0:40 ; 0:48 are different Disengage Requests
http://img685.imageshack.us/f/neuesbild2d.png

Send us the capture file. You can upload it to the forum as an attachment.

[Stefan]

Hi

Send us the capture file. You can upload it to the forum as an attachment.

this could be difficult because the file is about 138 MB.

But I looked at the file and saw that there is only one registration Confirm after two registration Requests. So there should be no problem. The Confirm is a reponse on both of the Requests
I also saw that the device deregister itself because the Keep-Alive Failed. Maybe the keep-alive timer isn't working well.

[Aurelia]

H.323 and SIP are both communication protocolsYouTube ReVanced used for voice and video over IP networks. H.323, older but robust, offers features like firewall traversal and support for multimedia applications. SIP, more lightweight and flexible, is widely adopted for its simplicity and compatibility with other internet services. While H.323 requires more configuration and has a steeper learning curve, SIP is easier to set up and integrate. Choosing between them often depends on specific network requirements and the complexity of the communication system you aim to deploy.

[paulej]

H.323 really isn't much older. Maybe a year, but both are very old protocols at this point.

Both have mechanisms for firewall traversal.

The learning curve depends on whether you're building code or deploying hardware. Deploying hardware, it's about the same. If you want to quickly hack something together in code, SIP is easier. If you want to build a robust, complete multimedia signaling system, both require about the same complexity.