Added the ability to pass :remote_sip_address to .invite #85
Conversation
| @@ -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 | |||
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
We could split the two, if there is an option To header is changed, otherwise it uses the same setup as the rest.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Fairly often with multi-tenant systems, and no, because later expectations/sent messages will revert to the wrong To header.
There was a problem hiding this comment.
Why are we using the name remote_sip_address instead of something like to?
No description provided.