Hi,
do you get the following log output (NUA debug logging is necessary):
LOG3("ignoring duplicate");
If this is the case, I have maybe a patch for you which does solve the problem,
that sofia-sip does ignores the duplicate SDP and does not push the SDP change
to your application.
Best regards,
Bernhard Suttner
________________________________________
Von: Jarod Neuner [[email protected]]
Gesendet: Donnerstag, 13. Oktober 2011 23:23
An: Louis Guindon
Cc: [email protected]
Betreff: Re: [Sofia-sip-devel] 183 early media description different from 200Ok
media desription
> Can you share with me how PRACK can allow the SDP to change between 183 and
> 200?
I was a bit too specific with the wording of bullet 2.
As far as I know, PRACK allows the caller to modify a session before the INVITE
transaction has been accepted and acknowledged, but I know of no implementation
which actually does this. The best practices method for modifying such a
session is with the UPDATE request.
I don't think any of this will help in your current predicament - you should
probably contact the proxy vendor and work from there.
-Jarod
----------------------------------------------------------
From: Louis Guindon [mailto:[email protected]]
Sent: Thursday, October 13, 2011 1:23 PM
To: Jarod Neuner
Cc: [email protected]
Subject: RE: [Sofia-sip-devel] 183 early media description different from 200Ok
media desription
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
----------------------------------------------------------
From: Jarod Neuner <[email protected]>
Sent: 2011/10/12 12:34 PM
To: Louis Guindon <[email protected]>
Cc: "[email protected]"
<[email protected]>
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:[email protected]]
Sent: Wednesday, October 12, 2011 1:37 PM
To: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
