* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
Change-Id: I8532bb237221ce78b47bb488de2a2e493966c96b
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
Change-Id: I60ae36bf3f94fab057792450179a07e7860edee1
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
Change-Id: Ic25733585186c6f97f4978de7da7e879262de185
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
Change-Id: Ib3b7463add144789e1c30b24726d6f703586eb5e
* Contact with <> format
* tests:
- add received Contact parameter as optional
* soundsets.yml: use unique name
Change-Id: I18fa24635f93a40a5b50580ab73a8a06561ce933
* Contact with <> format
* tests:
- add received Contact parameter as optional
- use server_id value
* soundsets.yml: unique name
Change-Id: Iad8bba5f1117e6645b07017d3e13d8d8bdd37808
* Contact with <> format
* tests:
- add received Contact parameter as optional
scenarios/invite_allowedcli_match/scenarios/invite_allowedcli_match0005_test.yml.tt2
Change-Id: I3cae99ceecf6cac5be68ec1a21a2d4361cb80dbd
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
* trusted: add domain to from_pattern
so it doesn't affect other scenarios
Change-Id: I6e81034f9eba393164c82293f6cbb9c4cd406496
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
* trusted: add domain to from_pattern
so it doesn't affect other scenarios
Change-Id: I070ed048309b5ec8d4d801e5084d9c3dd5c35971
* use server_ip from scenario_ids.yml
* Contact with <> format
* tests:
- add received Contact parameter as optional
Change-Id: Ida9b2e06e8de5e042967f08c39ec6f82a7865f60
New kct scenario under scenarios/directory
featuring a whitelist sdp scenario with
PCMA,PCMU,GSM,telephone-event name codes in place.
Change-Id: Iebfe9c19abc6536b50bbdecbdc7a45cb09703c7a
Create a few scenarios which would check work of lock mechanism for cases when:
- (patchset 1) A has a lock for outgoing (type 2); A calls B; Call is declined with 403;
- (patchset 2) B has a lock for outgoing (type 2); B has a CFU towards C;
A calls B, A gets forwarded to C due to CFU. But the call is locked with 403, since B has lock type 2.
- (patchset 4) B has a lock for outgoing (type 2); B has a CFNA towards C;
A calls B, 480 Temporarily Unavailable is sent back from B,
A gets forwarded to C. But the call is locked with 403, since B has lock type 2.
Change-Id: Ib532cbeefd36dac3dea6271ba7daa9dd4bf5c8a7
The main designation of this scenario is to check out, whether calling side
which uses tel scheme for From/To/Diversion/PAI headers, gets them fixed properly to SIP URI.
Particularity of this scenario is, that A side gets redirected with 302 Temporarily Moved.
Other than that we check out, whether Proxy doesn't admit usage of double Diversion headers present at the same message,
when a new INVITE has been generated by Proxy after receiving the 302.
Change-Id: I0bc82c8ea29915e9a2a3f13b90458b0b89dbc861
Victor Seva
Alessio Garzi
donat zenichev
Marco Capetta