Re: [OpenSIPS-Users] B2B bye method handling
Many thanks to Alex (offlist) for pointing out a spurious record_route statement on my side was the real culprit to my issue. Ahh the joys of sip routing. R. On 09/02/16 05:00 PM, Ross wrote: Grabbing it now, I'll send it directly/off-list. R. On 09/02/16 04:37 PM, Alex Balashov wrote: Ross, Could you provide a libpcap-formatted capture of this scenario, either on-list or privately? -- Alex On 02/09/2016 04:35 PM, Ross wrote: (I'm new to opensips, so bare with me if I'm off track). I setup a very simple configuration using b2bua for a quick top hiding setup/proxy, and it works correctly, except for handling BYE messages coming from the upstream connection. Note, db_mode is set to 0 for both b2b_logic + entities. setup: source client (aka invite initiator) -> os/b2b -> upstream Quick Issue description: Call sessions is established, and works fine, and when the client disconnects (initiates the bye message), the call disconnects cleanly with all parties as expected. (this is good/normal) But when the server side disconnects first (sends the initial bye message), opensips improperly handles the bye message by believing it to be from the client side. Therefore doesn't properly send the corresponding responses to the remote parties. In more detail: Delving into the code, and looking at some packet sniffs/debugs, I've come to the idea that the b2b code (notably starting dlg.c:706) doesn't take into account that the new BYE message will have the To/From Fields reversed when from the server as it's not technically a response. Because of this, the b2b_parse_key on 708 fails as it's only looking at the "to" field tag for it's index key. Then the request falls through and is then incorrectly parsed as a client sourced packet, as that lookup uses a different index key (callid), which is correct for the session. I've tested this using metaswitch and asterisk in both the client and server positions and they both return the same data (to/from), but would like anyone else's thoughts on this. Apologies, while I can read code, I'm not a proper programmer to make a real patch. Thanks, Ross. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2B bye method handling
Ross, Could you provide a libpcap-formatted capture of this scenario, either on-list or privately? -- Alex On 02/09/2016 04:35 PM, Ross wrote: (I'm new to opensips, so bare with me if I'm off track). I setup a very simple configuration using b2bua for a quick top hiding setup/proxy, and it works correctly, except for handling BYE messages coming from the upstream connection. Note, db_mode is set to 0 for both b2b_logic + entities. setup: source client (aka invite initiator) -> os/b2b -> upstream Quick Issue description: Call sessions is established, and works fine, and when the client disconnects (initiates the bye message), the call disconnects cleanly with all parties as expected. (this is good/normal) But when the server side disconnects first (sends the initial bye message), opensips improperly handles the bye message by believing it to be from the client side. Therefore doesn't properly send the corresponding responses to the remote parties. In more detail: Delving into the code, and looking at some packet sniffs/debugs, I've come to the idea that the b2b code (notably starting dlg.c:706) doesn't take into account that the new BYE message will have the To/From Fields reversed when from the server as it's not technically a response. Because of this, the b2b_parse_key on 708 fails as it's only looking at the "to" field tag for it's index key. Then the request falls through and is then incorrectly parsed as a client sourced packet, as that lookup uses a different index key (callid), which is correct for the session. I've tested this using metaswitch and asterisk in both the client and server positions and they both return the same data (to/from), but would like anyone else's thoughts on this. Apologies, while I can read code, I'm not a proper programmer to make a real patch. Thanks, Ross. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2B bye method handling
Grabbing it now, I'll send it directly/off-list. R. On 09/02/16 04:37 PM, Alex Balashov wrote: Ross, Could you provide a libpcap-formatted capture of this scenario, either on-list or privately? -- Alex On 02/09/2016 04:35 PM, Ross wrote: (I'm new to opensips, so bare with me if I'm off track). I setup a very simple configuration using b2bua for a quick top hiding setup/proxy, and it works correctly, except for handling BYE messages coming from the upstream connection. Note, db_mode is set to 0 for both b2b_logic + entities. setup: source client (aka invite initiator) -> os/b2b -> upstream Quick Issue description: Call sessions is established, and works fine, and when the client disconnects (initiates the bye message), the call disconnects cleanly with all parties as expected. (this is good/normal) But when the server side disconnects first (sends the initial bye message), opensips improperly handles the bye message by believing it to be from the client side. Therefore doesn't properly send the corresponding responses to the remote parties. In more detail: Delving into the code, and looking at some packet sniffs/debugs, I've come to the idea that the b2b code (notably starting dlg.c:706) doesn't take into account that the new BYE message will have the To/From Fields reversed when from the server as it's not technically a response. Because of this, the b2b_parse_key on 708 fails as it's only looking at the "to" field tag for it's index key. Then the request falls through and is then incorrectly parsed as a client sourced packet, as that lookup uses a different index key (callid), which is correct for the session. I've tested this using metaswitch and asterisk in both the client and server positions and they both return the same data (to/from), but would like anyone else's thoughts on this. Apologies, while I can read code, I'm not a proper programmer to make a real patch. Thanks, Ross. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] B2B bye method handling
(I'm new to opensips, so bare with me if I'm off track). I setup a very simple configuration using b2bua for a quick top hiding setup/proxy, and it works correctly, except for handling BYE messages coming from the upstream connection. Note, db_mode is set to 0 for both b2b_logic + entities. setup: source client (aka invite initiator) -> os/b2b -> upstream Quick Issue description: Call sessions is established, and works fine, and when the client disconnects (initiates the bye message), the call disconnects cleanly with all parties as expected. (this is good/normal) But when the server side disconnects first (sends the initial bye message), opensips improperly handles the bye message by believing it to be from the client side. Therefore doesn't properly send the corresponding responses to the remote parties. In more detail: Delving into the code, and looking at some packet sniffs/debugs, I've come to the idea that the b2b code (notably starting dlg.c:706) doesn't take into account that the new BYE message will have the To/From Fields reversed when from the server as it's not technically a response. Because of this, the b2b_parse_key on 708 fails as it's only looking at the "to" field tag for it's index key. Then the request falls through and is then incorrectly parsed as a client sourced packet, as that lookup uses a different index key (callid), which is correct for the session. I've tested this using metaswitch and asterisk in both the client and server positions and they both return the same data (to/from), but would like anyone else's thoughts on this. Apologies, while I can read code, I'm not a proper programmer to make a real patch. Thanks, Ross. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users