This Question is Possibly Answered

1 "correct" answer available (5 pts) 2 "helpful" answers available (1 pts)
1 Replies Last post: Jan 29, 2010 11:16 PM by joegen  
Click to view austincao's profile   16 posts since
Nov 11, 2009

Jan 21, 2010 11:23 PM

About m_IsExpectingSDPInACK


Hi all,


I found that if "m_IsExpectingSDPInACK" has been set to false, then OSBC will send ACK as soon as it receives 200 OK, it will not waiting for the ACK sent by initiating party.

However, there are two issues:

1. "m_IsExpectingSDPInACK" is set in following line:

#SetExpectingSDPInACK( !invite.*HasSDP*() );

But, the function of HasSDP() just check that if the SIP message contains SDP body OR is the content-type equals "application/sdp". I think it should check if the "c=" equals "0.0.0.0".

2. I have simply set m_IsExpectingSDPInACK with SetExpectingSDPInACK(*true* ); and OSBC will NOT send ACK as soon as it receives 200 OK.

However, when it recieves the ACK with SDP body, it does not forward (let's simply say it forward) it to the terminating party.


I wo austincao

Click to view joegen's profile   519 posts since
Apr 28, 2007
1. Jan 29, 2010 11:16 PM in response to: austincao
Re: About m_IsExpectingSDPInACK
I apologize, I totally missed this post till now. My answer inline ...

{quote:title=austincao wrote:}{quote}

Hi all,

I found that if "m_IsExpectingSDPInACK" has been set to false, then OSBC will send ACK as soon as it receives 200 OK, it will not waiting for the ACK sent by initiating party.
Your observation is true

However, there are two issues:

1. "m_IsExpectingSDPInACK" is set in following line:

#SetExpectingSDPInACK( !invite.*HasSDP*() );
Yes that is correct.

But, the function of HasSDP() just check that if the SIP message contains SDP body OR is the content-type equals "application/sdp". I think it should check if the "c=" equals "0.0.0.0".
Not quite! An INVITE that already sent an OFFER (even with 0.0.0.0 in c line) can no longer send SDP in ACK. This will violate offer answer model where only one offer and one answer can exist in a transaction. So the code is correct. If you feel this is wrong behavior, then explain why you think it is wrong and quote the supporting RFC sections.
2. I have simply set m_IsExpectingSDPInACK with SetExpectingSDPInACK(*true* ); and OSBC will NOT send ACK as soon as it receives 200 OK.

However, when it recieves the ACK with SDP body, it does not forward (let's simply say it forward) it to the terminating party.
I am quite unsure what you are trying to achieve by manually setting the value of m_IsExpectingSDPInACK. Perhaps a call flow diagram would help and send the corresponding logs that demonstrate your call-flow.