OK Joegen...So when does it really come to handy? because always 200OK will always return same tag from Invite isn't it?

Regards,
Kumaran T

On 10/3/2012 6:17 PM, Joegen Baclor wrote:
Format for crypto parameter in sdp is

a=crypto:<tag>  <crypto-suite>  <key-params>  [<session-params>]

Example:
a=crypto:1 AES_CM_128_HMAC_SHA1_80
       inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32

In the above example, tag is 1.



On 10/03/2012 08:31 PM, Kumaran wrote:
In below mentioned scenario in our testing scenario call established even though both the phones are having different Crypto attributes(32 and 80)

Regards,
Kumaran T

On 10/3/2012 5:42 PM, Kumaran wrote:
In 2 polycom phones One phone(200) enabled with crypto 32 with Required matching tag enabled ,other phone(203) with crypto 80 without Required matching tag....So call should be established or not?

Regards,
Kumaran T
On 10/3/2012 5:31 PM, Joegen Baclor wrote:
http://supportdocs.polycom.com/PolycomService/support/global/documents/support/setup_maintenance/products/voice/spip_ssip_vvx_Admin_Guide_SIP_3_2_2_eng.pdf


sec.srtp.requireMatchingTag

A flag to determine whether or not to check the tag
value in the crypto attribute in an SDP answer.
If set to 1 or Null, the tag values must match.
If set to 0, the tag value is ignored.


So I think it's just a sanity check for crypto attribute content.


On 10/03/2012 06:38 PM, Kumaran wrote:
Any update regarding mail mentioned below.....

Regards,
Kumaran T

On 9/28/2012 6:25 PM, Kumaran wrote:
Hi All,
     What should be the behavior if we enable the option "Require Matching
Tag" in Phone->Security->SRTP? Because I have 3 polycom phones..
       One phone(200) enabled with crypto 32 with Required matching tag
enabled ,other phone(203) with crypto 80 without Required matching tag
and another phone(205) enabled with crypto 32 without Required matching tag
      Calls going through between these phones in secure connection(lock
symbol) without any issue...So what purpose Require Matching Tag option
is required?

Regards,
Kumaran T

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive:http://list.sipfoundry.org/archive/sipx-dev/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive:http://list.sipfoundry.org/archive/sipx-dev/






_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

Reply via email to