Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Subject Topic: 302 Moved Temporarily & Forwarding Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
juice
Vetran
Vetran


Joined: December 05 2006
Location: United States
Posts: 139
Posted: June 14 2007 at 4:32am | IP Logged Quote juice

Hi there,

we have faced following problems

1) Media Engine does not handle Moved Temporarily Messages (302). There are no events generated from this message. If media engine receives this, the invite simply times out with SipInviteAckNotRecieved

2) Media Engine does not provide us with SIP Request URI from Invite message

e.g.:

INVITE sip:something@somewhere.com .....

In cases of forwards, the "To" address and the real SIP Destination URI may differ (as is the case with the X-Lite Phone).
As far as we read on web the "To" should not be used for routing, but instead the Request URI should be used - which we do not have access to.
Although, some sip devices alter both the To and SIP Uri fields to a new forwarded number.

But,wqe suppose correct behavior should be that we would use the Request URI for destination.

Forward scenario which causes problems:
[Xlite] to [SOMEWHERE]

>>
INVITE sip:somewhere
To: sip:somewhere

<<
302 Moved to nowhere

>>
[Xlite] to [LanScape]
INVITE sip:nowhere
To: sip:somewhere

Notice, that we will try again to call the To address, but what we would really want to call is the Request URI.

please advice,

Andrew
Back to Top View juice's Profile Search for other posts by juice
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: June 15 2007 at 9:13am | IP Logged Quote support

Hi Andrew,

We are going to keep reminding you to get your support contract started. When in place, we will be able to directly help you with this and add the needed functionality to the media engine. By the way, please make sure you update us with the results of your testing using the updated media engine you downloaded from your support FTP account. We are interested in (and need) your test results as related to the following posts:

Outgoing calls fails

Internal Crash/Break inside DLL


Now let’s get to your current questions….


Item 1:
Media Engine does not handle Moved Temporarily Messages (302). There are no events generated from this message. If media engine receives this, the invite simply times out with SipInviteAckNotRecieved.


Yes, this is correct. Then media engine currently ignores 3XX redirect responses to INVITE. The ability to support 3xx responses to INVITEs is on our development list of things to do.

Here is how we would probably handle 3xx INVITE responses:

Media Engine makes a call:

Code:

INVITE ------->
<----------------- 100 Trying
<----------------- 183 Session Progress, etc…
<----------------- 3xx Redirect or Temporarily Unavailable etc…
ACK ---------->



At the time the media receives the 3xx response to the INVITE, the media engine will parse out all the alternate contact locations in the 3xx response. These are the other possible URI locations that the end use may be reached.

After the media engine terminates the call by sending the final ACK, the media engine would then send an event to the user’s VOIP application – Lets say it’s the new SipCallRedirected “immediate” event.

Part of the new SipCallRedirected immediate event will be a list of other possible contact locations. The user’s VOIP app can then determine if it wants to try calling the other possible call locations as required using the standard MakeCall() or MakeCallUri() API procedures.


Because the above mentioned functionality currently does not exist, you will have to trap the 3xx response yourself by handling the SipModifySipMessage immediate event. The event handler will tell you the phone line the 3XX response is related to. You will need to parse the relocation data out of the 3xx response, send out your own final ACK, terminate the call and then filter the call CANCEL the media engine will try to transmit. It may not be pretty, but you have everything you need to do it.

Then you can start new calls to the alternate locations given by the 3xx response.




Item 2:
Media Engine does not provide us with SIP Request URI from Invite message.


You are correct. We probably need to add generic GetInviteMessage() and GetInviteMessageResponse() API procedures. The GetInviteMessage() could be called to obtains the entire INVITE after the INVITE is mapped to a phone line. The GetInviteMessageResponse() API procedure could also be called after successful session establishment (2xx responses to the INVITE).

You will have to figure out a way to get the REQUEST URI from the INVITE using the SipModifySipMessage event.


Repost as needed,


Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
juice
Vetran
Vetran


Joined: December 05 2006
Location: United States
Posts: 139
Posted: June 20 2007 at 5:31pm | IP Logged Quote juice

The thing with Item 1 is that the call should still fall under the same call id, for tracking sessions for sip proxy/record keeping purposes. Since the redirect would still be part of the same call session, if we simply did another makeCall, then the call id would be different.

This also prevents us from parsing the SipModifySipMessage at this time since we could not make a call with the same call id ourselves.

For item 2, if there was a way to get alternative contact information from the Invite, then this would likely solve our issue, as we could always use the SIP Uri as primary destination for routing.

Thanks
Back to Top View juice's Profile Search for other posts by juice
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: June 21 2007 at 9:45am | IP Logged Quote support

Andrew,

Your points are well taken. You are brilliant.

Hopefully soon we can work together under a full blown support agreement. This will totally untie our hands. Then we can plan out this new functionality, get it implemented and then get you updated product. The thing is this: No matter how hard we try, you and other customers keep thinking of new ways these products are being used and deployed. When we work together, we all move forward.

just some thoughts….

Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 

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

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
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






Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights