Hi, Ok, thanks for the quick reply :). About the ip/port I also thought using the rdata transport info + the configured RTP local port for the account. It would be wrong information but at least something related to the app. If you'd like me to try to propose a patch just let me know : I have some time to play with that and will be an occasion for me to dive more in pjsip code. About the srtp_optional_dup_offer, <http://www.pjsip.org/docs/2.0-alpha2/pjsip/docs/html/structpjsua__acc__config.htm#a75580a63d22667a8911d218e39f104dc> I agree, I don't present it to user anyway, and was never asked for ;). It was just a remark I had while investigating. So probably not a problem for me if it's dropped. BTW, maybe the option can be marked as obsolete in 2.0 doc? Thanks R?gis On 29/06/2012 01:15, Benny Prijono wrote: > On Fri, Jun 29, 2012 at 4:20 AM, R?gis Montoya <r3gis.3r at gmail.com > <mailto:r3gis.3r at gmail.com>> wrote: > > Hi, > > As per ticket 1185 some parts of the code is disabled. As part of > that, the OPTIONS reply doesn't include SDP body anymore. > > > Right, I think we missed that! Let me fix it soon. > > I understand that the root cause is that no media transport are > present at the point an incoming OPTIONS request arrives. > The problem is that it seems to break the incoming calls for some > other sides. I've one report from user with an asterisk configured > with SRTP incoming. > I don't know yet what the remote side is, but it maybe comes from > their asterisk server. I guess there is some check to know first > if client is able to use SRTP? Would it make sense? If so, I think > that the app should 'try' to reply with a SDP body. > > So I've one question : > Would it be acceptable to reply with a SDP with fake ip/port in > OPTIONS reply (for example 0.0.0.0)? Is there any case where > OPTIONS reply would be used for media ip/port? > > > IMO it should be okay to use fake IP, but I'm not sure about 0.0.0.0 > as it conveys call hold state in old SIP spec. I don't think anyone > should/would use the IP/port in OPTIONS reply. > > I guess that if not a problem, it would be possible to generate a > SDP with just codecs / crypto / known information. I don't know if > it's possible in pjsip but I guess that at this point codec > manager is already up and most things will go fine. > > > Yes. > > Also side note, while investigating the issue, I noticed that > ticket 1185 also remove something about SRTP optional mode (in > pjsua_media.c:1980). I didn't get why this part of the code is > disabled. After a very first look it seems nothing is missing at > this point to have this part of code enabled. Did I miss something? > > > This is for another way to convey optional SRTP encryption for the > media, by duplicating each media in the offer: one with RTP/AVP and > another exact copy with RTP/SAVP. It was making things very very > complicated even with the 1.x already, and now in the 2.x with the > async media transport, video, and multiple media lines, it will be an > order of magnitude more complex. Frankly we gave up. But it was not so > popular anyway, so I don't think we're loosing much. > > Best regards > Benny > > Best regards, > R?gis > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120629/ed781ae1/attachment-0001.html>
