[SIPForum-discussion] INFO method

Mon Sep 19 22:27:16 UTC 2005

You coul do another "offer/answer" exchange, with the new paramers. This
would mean another round of UPDATE or re-INVITE in the existing dialog.

-----Original Message-----
From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Darko Milic
Sent: Monday, September 19, 2005 13:54
To: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] INFO method

Thanks,

I took a briefly look to "draft-ietf-mmusic-sdescriptions-12.txt". If I
understand correctly this draft describes security establishment for
unicast stream between two points. Offerer says to answerer how to
interpret received media stream (which algorithm, key, etc. to use) and
this is in place when agreement (choice) already has been done.

The "draft-ietf-mmusic-kmgmt-ext-15.txt" deals with key management
protocol parameters within SDP and points on page 7 :

"   * At the current time, it MUST be possible to execute the key

      management protocol in at most one request-response message

      exchange. Future relaxation of this requirement is possible but

      would introduce significant complexity for implementations

      supporting multi-roundtrip mechanisms."

What happen if parties want to make agreement that takes more than one
round? For example, in my case conference session should be established
with key agreement protocol on the session level that takes two
broadcast rounds to the conference group. After initial SIP INVITE
carried first broadcast message and SDP media offer, all users have to
send second calculated according value of first one. Media communication
could not be started without completing key agreement protocol. My
dilemma is how to modeling such case; through which SIP message to send
this data. I think it is not appropriate to send SDP offer one more time
but with second broadcast message. My plan is to use XML along agreement
procedure through SIP INVITE and following SIP INFO.

I need advice about feasibility. Are there any works related with this
problem?

Regards,

Darko

Francois Audet wrote: 

And

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-15.txt.

Both of which should be RFCs very soon, and both of which will be

bread and butter.

-----Original Message-----

From: discussion-bounces at sipforum.org 

[mailto:discussion-bounces at sipforum.org] On Behalf Of 

Jonathan Rosenberg

Sent: Monday, September 19, 2005 06:21

To: darmil at neobee.net; An open list for discussion of 

SIP-related topics

Subject: Re: [SIPForum-discussion] INFO method

There are specifications that define mechanisms for key exchange for 

media sessions:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-12.t

xt

-Jonathan R.

darmil at neobee.net wrote:

Yes, something like that. But I want to set secure 

communication with 

my mechanism between them on the MSRP level. To do that, 

before start 

of media (MSRP) I need to exchange setting information (key 

agreement, 

authentication, etc.). I believe that signalization domain is right 

place for such thing.

Regards,

Darko    

Eric Burger  <mailto:eburger at brooktrout.com> <eburger at brooktrout.com>
wrote :

No. You probably want to connect the

endpoints directly (like through TCP) for your private 

communication. 

&nbsp;See the mechanism of MSRP or MRCPv2.

&nbsp;

From: discussion-bounces at sipforum.org 

[mailto:discussion-bounces at sipforum.org] On Behalf Of Darko Milic

Sent: Sunday, September 18, 2005

3:53 PM

To: An open list for discussion of

SIP-related topics

Subject: Re: [SIPForum-discussion]

INFO method

&nbsp;

Thanks to all,

I've get some idea of INFO usage. As I said my intention 

was to send 

some additional information after SIP dialog had been opened. This 

information includes some cryptographic parameters, in 

several rounds, 

before media communication, meaningful only for upper application 

(Call Control) on both side, but not for human user. I believe now 

that INFO is appropriate solution&nbsp; and that the 

MESSAGE request 

should be left for human user data. Isn&#8217;t it?

&nbsp;

Regards,

Darko

&nbsp;

Beith, Gordon wrote:

INFO method is used for various mid-call communication and also for 

SIP-T (i.e. ISUP transparency).

It has been used for, but is not

recommended, DTMF communication. RFC 2833 is the recommendation for 

that.

Further to this, and proprietary messages,

services, etc. use INFO method as well. This sounds like 

what you want 

to do here.

&nbsp;

From:

_______________________________________________

discussion mailing list

discussion at sipforum.org 

http://sipforum.org/mailman/listinfo/discussion

-- 

Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza

Director, Service Provider VoIP Architecture   Parsippany, NJ 

07054-2711

Cisco Systems

jdrosen at cisco.com                              FAX:   (973) 952-5050

http://www.jdrosen.net                         PHONE: (973) 952-5000

http://www.cisco.com _______________________________________________

discussion mailing list

discussion at sipforum.org 

http://sipforum.org/mailman/listinfo/discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20050919/4b395065/attachment-0001.html>