Hi Jarod,

Thanks for the quick feedback. really appreciated...

In the current setup, the endpoint A (sofia) is not advertising 100rel in 
the INVITE which implies that the Proxy should not expect any PRACK. This 
means that the bullet 2 of your answer is more appropriate.

In the event that the Endpoint A is advertising 100rel and the proxy 
expecting PRACK, I am interested to understand why it would have any 
impact on the SDP of the 183/200. Can you share with me how PRACK can 
allow the SDP to change between 183 and 200 with respect of rules 
described in RFC 3261, Section 13.2.1. 

Thanks in advance,

Louis Guindon





Jarod Neuner <j.neu...@networkharbor.com> 
2011/10/12 12:34 PM

To
Louis Guindon <louisguin...@vtech.ca>, 
"sofia-sip-devel@lists.sourceforge.net" 
<sofia-sip-devel@lists.sourceforge.net>
cc

Subject
RE: [Sofia-sip-devel] 183 early media description different from 200Ok 
media desription






Three points of interest here.

1) By default, NUA supports the 100rel extension described in RFC3262. 
Since the proxy is sending a 183 response, it seems likely that it is 
requesting a PRACK.  Have those messages been omitted in the provided call 
flow?

2) If the proxy was not requesting a PRACK, Sofia-SIP is required to 
ignore the SDP in the 200 OK, in accordance with rules in RFC 3261, 
Section 13.2.1. 

3) If arguing with the vendor isn't an option, you should be able to pull 
the unparsed SDP from the sip_t structure.  From there, a session 
re-negotiation might sync up the stack.

Hope this helps.
-Jarod





From: Louis Guindon [mailto:louisguin...@vtech.ca] 
Sent: Wednesday, October 12, 2011 1:37 PM
To: sofia-sip-devel@lists.sourceforge.net
Subject: [Sofia-sip-devel] 183 early media description different from 
200Ok media desription


Dear All, 

I am experiencing a problem with the Sofia SIP stack with early media. 

Here the flow: 

A (Sofia)                   Proxy                      B 
|-----------INVITE----------->|                        | 
|                             |----- INVITE ---------->| 
|                             |                        | 
|                             |<------ 100 ------------| 
|<-----------100--------------|                        | 
|                             |                        | 
|<-----------183--------------|                        | 
|     (Media Source Proxy)    |                        | 
|<===========RTP=============>|                        | 
|                             |<------ 200 ------------| 
|<-----------200--------------|                        | 
|     (Media Source B)        |                        | 
|<===========================RTP=======================| 
|                             |                        | 
|------------ACK------------->|                        | 
|                             |------- ACK ----------->| 
|                             |                        | 

During the call setup, the Proxy sends early media so tones (ringback) is 
generated by the proxy. When the endpoint B answers the call, the SDP in 
the 200OK contains media description for the endpoint B. The RTP 

Problem: The stack seems to assume that the SDP payload received from a 
183 would be the same as the one received with the 200OK. Thereof, the 
stack ignore reporting the SDP from the 200OK and doesn't intialize the 
SDP structure pointer when the stack has previsously received SDP as part 
of the 183. The application cannot retrieve the SDP information to update 
the RTP stream direction which cause one-way audio. 

Question: How can we force the stack to populate the NUA SDP structure 
members in that case? Any idea would be welcomed... 

Regards, 

Louis Guindon 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Reply via email to