[OpenSIPS-Devel] [ opensips-Bugs-3599493 ] DNS Cache and SRV Records issue

[SourceForge . net]

Bugs item #3599493, was opened at 2013-01-04 08:11
Message generated for change (Tracker Item Submitted) made by pym67
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599493group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pierre-Yves (pym67)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS Cache and SRV Records issue

Initial Comment:
DNS Cache module does not seems to handle properly DNS SRV records.

Example:
Opensips dns cache perform a lookup on mydomain.com.
The DNS answers : SRV gw1.mydomain.com and gw2.mydomain.com
Then Opensips perform an A query to gw1.mydomain.com
The DNS answers 1.2.3.4 for gw1.mydomain.com.
Finaly opensips forward the SIP request to 1.2.3.4


After that, on a new SIP request, Opensips continue to forward request directly 
to 1.2.3.4 (gw1.mydomain.com) and never trie to use gw2.mydomain.com

In my point of view, there is an issue in the DNS Cache module. Opensips should 
try randomly both mydomain.com SRV records gw1.mydomain.com and gw2.mydomain.com



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599493group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

[OpenSIPS-Devel] [ opensips-Bugs-3599495 ] SIP Parallel forking and RTPProxy limitation

[SourceForge . net]

Bugs item #3599495, was opened at 2013-01-04 08:20
Message generated for change (Tracker Item Submitted) made by pym67
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599495group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pierre-Yves (pym67)
Assigned to: Nobody/Anonymous (nobody)
Summary:  SIP Parallel forking and RTPProxy limitation

Initial Comment:
Hello,

I have found a limitation using opensips and rtpproxy with Parallel forking.
Version: opensips (v1.8.2) + rtpproxy.
Opensips is used as a SIP proxy (+ NAT traversal).
Another component is handling the service logic (Application Server)

The call scenario is the following:
- 2 UAC are registered using the same identity (using the same opensips SIP 
Proxy). Those 2 UAC are behind NAT
- Incoming call with parallel forking (to those 2 UAC)  [forking is not handled 
on opensips itself]
- 2 dialogs are well created (one for each fork)
- Upon the first UAC has sent his 200OK, the other fork call is CANCELED.


The problem is :
- both calls ( fork.0 and fork.1) have the same FromTag, Call-ID).
- on each INVITE, rtpproxy provide the same media port for both calls fork .  
[RTPProxy consider both INVITE as being part of the same call]
- on CANCEL on fork.1, unforce_rtpproxy() is closing the call (and as there is 
only 1 media call ), no media can be established on fork.0

In my opinion, there is here a limitation of rtpproxy  rtpproxy module that 
handle calls based only on From Tag, Call-ID, To Tag information which is not 
enough in case of forking.

Might it be possible to enhance the rtpproxy module in order to provide to 
rtpproxy a dialog ID/hash instead of the real Call-ID of the Call ?
(trough a modparam to enable/disable this behavior). 

Do you think that this could be implemented ?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599495group_id=232389

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel