LanScape Support Forum: Misbehavior while in LocalHold state

		Active Topics Member List Search Help Register Login

LanScape VOIP Media Engine™ - Technical Support
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support

Topic: Misbehavior while in LocalHold state

Author

Message

<< Prev Topic | Next Topic >>

Jalal
Vetran
Vetran

Joined: April 24 2006
Location: Iran
Posts: 188

Posted: March 15 2010 at 7:12am \| IP Logged

Hi,

A : our LMEVoip software which is registered to Asterisk
B : Asterisk
C : a Hardphone which is also registered to Asterisk

Both A and C's have canreinvite=yes parameter set in asterisk. Which allows direct RTP between A and C .

Here is scenario:

1) C invites A through B, then A goes to SipInCall state.
2) During Call A holds the line using HoldLine function.
3) B sends Hold Music RTP to C.
4) During hold C hangs up the call, and sends BYE to B.
5) B (asterisk) first tries to change the RTP path of A to himself using an SIP/invite which contains recvonly, but A replies only with a SIP 100 Trying message. A does not send anything else to B, and B tries to send invites again. This scenario continues. This is while we don't receive any notification from LMEVoip.

I replaced A with a Cisco Hardphone, and tested the same scenario. Cisco Hardphone replies B with SIP 200 OK, and then B sends SIP Bye, then call terminates as expected.

I think LMEVoip has misbehavior while a PhoneLine is in LocalHold state. Note that when the line is not in hold state, the behaviour of LMEVoip is the same as Cisco Hardphone, and everything is correct.

I tested above scnario with both v5.12.8.1, and v6.0.0.16, but this behaviour is the same in both of them.

BTW: I have done some customization to solve this problem myself, but I want you fix it for future. Maybe sometimes later our purchase limitation from USA is off so that we can trade again.

Thanks,
Jalal

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 17 2010 at 10:11am \| IP Logged

Jalal,

Thanks for your post.

We have made a note of this behavior and will add it to the bug fix and feature list we continually work through.

At this time the media engine does not support re-INVITE either for codec renegotiation or for direct peer to peer media exchange after the calls are initially set up. I can see the value in this capability and we will be sure to add it when time permits.

Thank you for taking the time to explain the situation accurately. I follow and understand your description completely.

For documentation purposes, please post the SIP logs for clients A and C if you can. That will be a benefit to me when we address this issue.

I appreciate your efforts…

Randal

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

Printable version

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum