Skip to content

Added the ability to pass :remote_sip_address to .invite #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lpradovera wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

Added the ability to pass :remote_sip_address to .invite #85

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
# develop
* Feature: added the ability to pass :remote_sip_address to #invite, a remote address to use in place of the SIPp constructed one

# [0.6.0](https://github.com/mojolingo/sippy_cup/compare/v0.5.0...v0.6.0)
* Change: Call limits (`number_of_calls`, `concurrent_max` and `calls_per_second`) no longer have default values for simplicity of UAS scenarios. The value of `to_user` now defaults to the SIPp default of `s`.
Expand Down
5 changes: 3 additions & 2 deletions lib/sippy_cup/scenario.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,13 +149,14 @@ def build(steps)
# @param [Hash] opts A set of options to modify the message
# @option opts [Integer] :retrans
# @option opts [String] :headers Extra headers to place into the INVITE
# @option opts [String] :remote_sip_address Remote address to use in place of the SIPp constructed one
Copy link
Copy Markdown
Member

@benlangfeld benlangfeld Jul 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this should only impact the To header, not the actual address to which packets are sent.

We also need to do the same for the rest of the dialog, so I guess this can't actually be an option to invite...

Copy link
Copy Markdown
Member Author

@lpradovera lpradovera Jul 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could split the two, if there is an option To header is changed, otherwise it uses the same setup as the rest.

Copy link
Copy Markdown
Member

@bklang bklang Jul 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are things that SippyCup should probably never try to do. The goal of SippyCup is to make SIPp manageable. If we go on to support every permutation of possibilites that SIPp allows, we're going to end up in a deep hole.

@benlangfeld can you tell me how often you anticipate running into this issue, where the remote SIP address differs from the address to which packets are sent? And if so, is this not already handled by having the invite instruction take an address which may be different from the address specified in the general test options?

Copy link
Copy Markdown
Member

@benlangfeld benlangfeld Jul 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fairly often with multi-tenant systems, and no, because later expectations/sent messages will revert to the wrong To header.

Copy link
Copy Markdown
Member

@bklang bklang Jul 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we using the name remote_sip_address instead of something like to?

#
def invite(opts = {})
opts[:retrans] ||= 500
# FIXME: The DTMF mapping (101) is hard-coded. It would be better if we could
# get this from the DTMF payload generator
from_addr = "#{@from_user}@#{@adv_ip}:[local_port]"
to_addr = "[service]@[remote_ip]:[remote_port]"
to_addr = opts.delete(:remote_sip_address) || "[service]@[remote_ip]:[remote_port]"
msg = <<-MSG

INVITE sip:#{to_addr} SIP/2.0
Expand Down Expand Up @@ -325,7 +326,7 @@ def send_answer(opts = {})
Content-Length: [len]

v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] #{@adv_ip}
o=user1 53655765 2353687637 IN IP[local_ip_type] #{@adv_ip}
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
Expand Down
7 changes: 7 additions & 0 deletions spec/sippy_cup/scenario_spec.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,13 @@
subject.to_xml.should match(%r{Contact: <sip:sipp@})
end
end

context "when specifiying a remote_sip_address" do
it 'uses that in place of coonstructing a remote address' do
subject.invite remote_sip_address: 'foo@baz.com:5061'
subject.to_xml.should match(%r{To: <sip:foo@baz.com:5061>})
end
end
end

describe "#register" do
Expand Down