Author |
|
juice Vetran
Joined: December 05 2006 Location: United States Posts: 139
|
Posted: June 14 2007 at 4:32am | IP Logged
|
|
|
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 |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: June 15 2007 at 9:13am | IP Logged
|
|
|
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 |
|
|
juice Vetran
Joined: December 05 2006 Location: United States Posts: 139
|
Posted: June 20 2007 at 5:31pm | IP Logged
|
|
|
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 |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: June 21 2007 at 9:45am | IP Logged
|
|
|
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 |
|
|
|
|