LanScape Support Forum: SendUdpDatagramUsingSipPort

		Active Topics Member List Search Help Register Login

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

Topic: SendUdpDatagramUsingSipPort

Author

Message

<< Prev Topic | Next Topic >>

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 23 2007 at 10:20am \| IP Logged

I bet you’ve been wondering when I’d pounce on this one

To business:
      I had previously built the REFER/NOTIFY SIP Message hack using HOLD/UNHOLD requests to generate the SIP Messages and modifying them.

      This method works flawlessly, when it works flawlessly. Heaven forbid someone should make a change in the PBX’s SIP Message flow and break my beautiful hack.

      But, thank goodness you have SendUdpDatagramUsingSipPort().

      I still have some more questions regarding this function and the resulting SIP Messages it will trigger.

As specified in the Developer’s Ref:

Code:

TELEPHONY_RETURN_VALUE VOIP_API SendUdpDatagramUsingSipPort(

SIPHANDLE hStateMachine,

void *pDataToTransmit,

int DataLength,

char *pDestHost,

int DestPort

);

Q1.
      Specifically the void pointer DataToTransmit. This could be ASCII string data or binary data. My assumption is all the unique identifiers and PBX/softphone handshake values will have to be manually formatted. Such that you can make ANY SIP message you desire w/o any re-formatting or removal of specific/custom SIP Headers in the message. No CSeq will be generated, the To and From lines must be formatted from scratch.
=================================================

      REFER sip:9995552474@10.2.2.75 SIP/2.0
      Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK0c2b446c
      From: <sip:4307@172.26.253.176>;tag=c2b1953
      To: <sip: 9995552474@10.2.2.75>
      Call-Id: 3B5AF11800001F30@somewhere.com
      CSeq: 2 REFER
      Refer-To: <sip:19995551234@172.26.253.176:5060;method=INVITE>
      Reffered-By: <sip:4307@172.26.253.176:5060>
      Max-Forwards: 70
      Contact: <sip:4307@172.26.253.176:5060>
      User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
      Content-Length: 0

=================================================

      I want to verify my assumption that the SIP Message will go out exactly as it is written w/ no modifications what so ever, including creation of identifiers. (Though building identifiers will be a bit of a pain.)

Q2.
      Is there some graceful solution to handling the resulting SIP Messages so LS doesn’t immediately start sending some 4xx messages in response? I could use the old method of converting it into something unrecognizable like I did in the first hack (“\r\n\r\n”).

Thanks.

You know… its funny looking over old postings and noticing all the typos.

support
Administrator

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

Posted: May 23 2007 at 11:21am \| IP Logged

Hi Fitz,

Regarding Q1:
Yes you are absolutely correct. The “data” you transmit using the SendUdpDatagramUsingSipPort() API procedure will not be changed by the media engine.

Regarding Q2:
Is there some graceful solution to handling the resulting SIP Messages so LS doesn’t immediately start sending some 4xx messages in response?

Yes. The best way to intercept all incoming SIP messages will be to handle the SipModifySipMessage immediate event. This event is sent to your VOIP application every time a SIP message is received.

By handling this event, you can inspect all received SIP messages. Your application can then tell the media engine to ignore any received SIP message simply by setting the IgnoreSipMessage member in the SIP_MESSAGE_IMMEDIATE_DATA structure that gets passed to your app. Once you set this value, the media engine will toss out the received SIP message.

It is important to send any user generated SIP messages using the SendUdpDatagramUsingSipPort() SPI procedure. This way you will still adhere to symmetrical SIP signaling requirements. This is important for NAT deployments.

I know, type-Os in forum posts are all over the place. :)

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 23 2007 at 10:41pm \| IP Logged

It appears SendUdpDatagramUsingSipPort() does not post to the SIP Logger.

I’ve ported out my SIP Message to a log file to see exactly what’s being formatted and what should be sent to the PBX. Is there some way to verify this is exactly what is being sent?

For some reason, (possibly tiredness) I don’t see a format issue as to why I’m receiving a 481 for what appears to be a standardized REFER message, though I’ll confer with the PBX provider in the morning.

support
Administrator

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

Posted: May 24 2007 at 6:36am \| IP Logged

Hi Fitz,

You are correct. The SendUdpDatagramUsingSipPort() API procedure only sends your data to the host:port you specify. If you also want to send your data to a remote SIP log server, call the SendUdpDatagramUsingSipPort() API procedure a second time specifying the host:port of the SIP log server.

<<< You
I’ve ported out my SIP Message to a log file to see exactly what’s being formatted and what should be sent to the PBX. Is there some way to verify this is exactly what is being sent?

Support >>>
Call the SendUdpDatagramUsingSipPort() API procedure a second time specifying the host:port of the SIP log server.

<<< You
For some reason, (possibly tiredness) I don’t see a format issue as to why I’m receiving a 481 for what appears to be a standardized REFER message, though I’ll confer with the PBX provider in the morning.

Support >>>
I bet you are just tired. We are tired too. :)

BTW: What PBX are you communicating with?

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 10:39am \| IP Logged

SIP Log Server:
That was straight forward & worked like a charm. --Thanks

PBX:
The PBX is an Entice Box by Stratus (formerly Emergent)

Question:
I did notice something I did not see/notice before; when I started intercepting incoming SIP Messages with this new LSME 5.12.3.30. The int PhoneLine seems to come into TelephonyEngineCallback() as -1.

Is this a bug, or was there something that needed to be changed/updated when upgrading from LSME 5.12.3.14 or 5.12.3.13?

Is there another way to get the correct PhoneLine the message is for.

EX
I’ve set up my new REFER/NOTIFY hack to be line specific, so I can handle attended transfers in the future. When I work on that little nightmare, I will need to know the correct phone line a message is coming in on.

support
Administrator

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

Posted: May 24 2007 at 12:11pm \| IP Logged

Hi Fitz,

Thanks for the updated info. The PhoneLine parameter that gets passed to your app in the TelephonyEngineCallback() proc always has the value of -1 when processing the “immediate event” SipModifySipMessage. This is not a bug – it has been this way all along.

Its funny that you mention this because we are currently working on v5.12.3.31 and in that version, the PhoneLine parameter has the proper value when a SIP message is mapped to a phone line by the media engine. If a SIP message is not related to any particular phone line, the PhoneLine parameter in the callback remains at a value of -1.

Regarding attended call transfer: It would be a good idea to wait until we update the Media Engine to handle this capability natively. It will save you a lot of work, headaches and confusion in the long run. Talk to Greg, we have been discussing this with him.

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 1:56pm \| IP Logged

As I recall, I have never used the PhoneLine in the “immediate event” SipModifySipMessage until now. I guess that explains why I had not noticed it before.

But this will be very important to have the correct PhoneLine when attempting to interface with the SIP messages coming in, especially when manually transmitting specific messages that LS should be told to ignore, for a specific PhoneLine.

I’m sure we would be very interested in this update if it can be made available.

Thanks.

BTW
The “IgnoreSipMessage” worked great. I just wish I had used that in my first transfer hack. (Oh so much more graceful)

Attended Transfer:
Greg has kept me in the know about this.
Who will get it done first or maybe the question is who has more aspirin?

New Transfer Hack Update
YES!!! I got my first 202 and Notify (100 Trying) from the PBX this morning!!!

support
Administrator

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

Posted: May 24 2007 at 2:54pm \| IP Logged

Fitz,

<<< You
But this will be very important to have the correct PhoneLine when attempting to interface with the SIP messages coming in…

Support >>>
You are exactly correct. We will make sure you get updated as soon as we can make the next revision available.

<<< You
New Transfer Hack Update…

Support >>>
Good job – that is good news. Go ahead and post your final working SIP logs for us and others to see. That would be good.

We have been told that your company will be entering into a support contract with us for unlimited updates and all the other good “stuff” that goes along with purchased support. That will make working together so much easier.

Thanks for all your feedback,

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 4:32pm \| IP Logged

What happens when a SIP message is coming in and the pSipMessageImmediateData->IgnoreSipMessage is set to TRUE, and a SendUdpDatagramUsingSipPort() is attempted.

Will LS ignore the SendUdpDatagramUsingSipPort()? As well as the incoming SIP Message?

support
Administrator

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

Posted: May 24 2007 at 4:42pm \| IP Logged

Hi Fitz,

Setting the IgnoreSipMessage member to non zero will cause the media engine to toss out the received Sip message when your callback proc returns control to the media engine.

The SendUdpDatagramUsingSipPort() API procedure is not affected at all by the above operation.

The SendUdpDatagramUsingSipPort() is immune from everything. It basically gives you a data pipe to send whatever you want (whenever you want) out the SIP port the media engine is using.

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 4:55pm \| IP Logged

If that’s the case, then why is it locking up?

Flow:

Code:

TelephonyEngineCallback

{

switch(TelephonyEvent)

     {

            case SipModifySipMessage:

            Incoming NOTIFY – 100 Trying message,

            SipMessageImmediateData->IgnoreSipMessage  = TRUE;

            Format responding 200 OK for the NOTIFY

            Send to log file “Got Here”

            SendUdpDatagramUsingSipPort()

            Send to log file “If you don’t see me, something went BANG”

            Break:

     }

}

When the SendUdpDatagramUsingSipPort() is enabled to send the new 200 OK for the incoming NOTIFY, the application becomes hung.
When it is commented out. The application runs fine, but of course you’d never send the 200 OK for the NOTIFY that way.
Note: I’ll see the first log output, but never the second, ONLY when SendUdpDatagramUsingSipPort() is enabled.

I’m looking at having to start a thread, to wait for a little while before executing the SendUdpDatagramUsingSipPort() for the 200 OK.

Any better suggestions?

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 5:31pm \| IP Logged

Well never mind…

I’ve reversed the order between:
     SendUdpDatagramUsingSipPort()
     SipMessageImmediateData->Ig noreSipMessage = TRUE;
And still ended up with the same results. I’ve tried commenting out:
     SipMessageImmediateData->Ig noreSipMessage = TRUE;
And still ended up with the same results.

The code ONLY continues to flow if SendUdpDatagramUsingSipPort() is commented out.

So maybe it’s not a problem of trying to both ignore the SIP message and SendUdpDatagramUsingSipPort(), maybe it has something to do with trying to SendUdpDatagramUsingSipPort() and being in the middle of:
(pSipMessageImmediateData->Received) state?

Though it looks like it’s still going to have to be a thread for a solution.

support
Administrator

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

Posted: May 24 2007 at 6:16pm \| IP Logged

Hi Fitz,

Then maybe I misspoke earlier when I said you can call it anywhere in your code.

We will verify what you have described. It probably is a typical deadlock problem we have to fix. We do want application software to be able to call this API proc from anywhere in application code.

We will check it out. Please hang on until we repost to this thread.

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 6:25pm \| IP Logged

I've already created the threaded work-around. The application’s not locking up, so that’s a good thing. It’s interesting, after putting the work-around in a thread; I didn’t even have to put in a Sleep() delay.

But now I’m having an argument with the PBX with the next issue. It’s probably something about formatting or SIP Message order.

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 24 2007 at 9:34pm \| IP Logged

Haha!!! YES!!!

Hack done… still have some clean up and timeouts to do… but beautiful… and it only took 2 LONG days instead of 2 weeks like last time!!!

Awesome support and as always very quick responses. Thanks LS Guys… or Y’All!!

support
Administrator

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

Posted: May 25 2007 at 12:33pm \| IP Logged

Hi Fitz,

We must be missing something in your description regarding the SendUdpDatagramUsingSipPort() API procedure locking up when calling it during the processing of immediate message SipModifySipMessage.

We tested it and it works as we originally stated. You should be able to call it from anywhere. As a matter of fact, the proc will only block if another thread is in the process of transmitting something else out the media engine SIP port. If it does block, it would be for an incredibly short period of time.

If you can, do us a favor and post your SIP log showing what SIP messages your app processes/receives. The actual handler code fragment in where you process the SipModifySipMessage event would be good too.

Let us know what SIP message in the chain you process that is causing this “dead lock”. We are a bit dubious but we have missed things before.

Support

mfitzgerald
Vetran
Vetran

Joined: June 14 2006
Location: United States
Posts: 142

Posted: May 25 2007 at 1:40pm \| IP Logged

I apologize I don’t have the SIP logs from that issue anymore. The logs I have now reflect a successful transfer of SIP Messages.

Notice though:
The break did occur when the NOTIFY – 100 Trying (I call it ‘NOTIFY 1’ for short) would come in from the PBX and I needed to construct a ‘200 OK’ message in response to it, but that may not have caused the break.

Maybe this will explain things as I see it a bit more clearly:
P1 calls P2, P2 tells P1 to transfer via INVITE to P3

Code:

     REFER == >

     < == 202 OK

     BYE (noted as BYE 1) == >

     < == NOTIFY – 100 Trying (noted as NOTIFY 1)

     200 OK/NOTIFY 1 == >

     < == NOTIFY – 200 OK (noted as NOTIFY 2)

     200 OK/NOTIFY 2 == >

     < == 200 OK/BYE 1

Just to be complete. In my first transfer hack the PBX would also send a BYE to P2 (noted as BYE 2) but this PBX does not.

You may have inadvertently hit what was causing the issue.

Quote:

As a matter of fact, the proc will only block if another thread is in the process of transmitting something else out the media engine SIP port.

Question:
Is this to say that a simultaneous out message and an incoming message would not interfere with each other? I’m guessing these are independent threads, so the answer would be no.

Just out of curiosity; were the tests you ran designed to send a message during an incoming SIP Message?
i.e. attempting to use SendUdpDatagramUsingSipPort() while LS was in a SipModifySipMessage TelephonyEvent

My guess is that there was a bit of an issue with the timing of LSME and the PBX. The SIP Message flow had unexpectedly altered and may have caused a bit of a race condition.

Code:

     REFER == >

     < == 202 OK

     < == NOTIFY – 100 Trying (noted as NOTIFY 1)

     BYE (noted as BYE 1) == >

     200 OK/NOTIFY 1 == >

     < == NOTIFY – 200 OK (noted as NOTIFY 2)

     200 OK/NOTIFY 2 == >

     < == 200 OK/BYE 1

Right after issuing a successful REFER, I would receive both a 202 OK and a NOTIFY 1. I would respond to the 202 OK by issuing a standard LS BYE (there was a slight modification that was needed to get this BYE to work in a REFER/NOTIFY flow <-- that took a while to figure out). After the modification and a quick ModifySipMessage() later the BYE would be sent.

But at about the same time, a response was made to NOTIFY 1, which was a custom built ‘200 OK/NOTIFY 1’ SIP Message using SendUdpDatagramUsingSipPort() and that is where the lock-up occurred.

My guess (and purely a guess) is that ‘BYE 1’ and the ‘200 OK/NOTIFY 1’ were somehow trying to run at the same time.

Placing the responding SIP Message for ‘NOTIFY 1’ into a thread (and subsequently ‘NOTIFY 2’ – just to be safe) seemed to solve this issue right away.

Hope that helps.

I think the only reason any issues are found is that I keep trying to do things with your engine it was not necessary designed to do? That is to say you build a great application, I just keep trying to void the warranty.

Cheers!

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