mån 2007-07-02 klockan 11:55 -0700 skrev Dan Wing:
> I just submitted a draft, "SIP Identity using Media Path", which
> describes a mechanism that allows RFC4474-like signatures and also
> allows SBCs and B2BUAs to modify the message's SDP. Links to HTML
> and plain text versions of the Internet Draft are below.
It's nice to see work like this that tries to handle the reality of
installed networks instead of pretending that SBCs don't exist.
I'm not sure that I grasp this completely yet, but I'll let it simmer
for a while and give it another read later.
=== Comments ===
Section 3, figure 1:
This figure is a simplification, since many enterprises will have their
own SBCs on their borders:
<--- Enterprise-A ---->
clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+
|
+------------------------------------------------------+
|
| <--- Enterprise-B ---->
+--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients
Section 3, "mailto URLs" para:
sp1.net and sp2.net (and, later in the document, sp3.net) are (or at
least could be) real domains that shouldn't be used.
Section 4.1, item about Contact:
How can the Contact header usefully be used in the signing process? An
SBC along the message path will happily replace it.
=== Editorial nits ===
In the text, RFC references are sometimes written "RFCxxxx" and
sometimes "RFC xxxx". Decide on one alternative.
Section 3, figure 1:
> +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+
SP1 has two SBC1. One of them should be SBC2.
Section 3, first para after figure 1:
> using a mailto URL (e.g., 'sip:[EMAIL PROTECTED]')
Both here and a couple of paragraphs below (under "Mailto URLs:"), sip:
URLs are refered to as mailto URLs which sounds very strange.
Section 3, "mailto URLs" para:
> SP1 would validate the RFC4474 signature modify the SDP.
I can't make sense of this sentence. What should it mean?
> So that a
> new RFC4474 signature can be created using its own public/private
> key pair, SP1 needs to modify the From: field.
Rewrite this sentence to
>> SP1 needs to modify the From: field so that a new RFC4474 signature
>> can be created using its own public/private key pair.
> Unlike with E.164
> numbers which are globally unique, the SP1 isn't able to
Remove the "the" in front of "SP1".
Section 4, second list item:
> o This new header is signed in addition to the same set of SIP
> headers signed by RFC4474 (detailed in )
Detailed in what?
Section 4, para before figure 2:
> In practice, if the
The rest of this sentence has gotten lost somewhere. Please contact the
information desk.
Section 4, step 1:
> Step 1: Originating endpoint prepares to send an Invite and chooses
"INVITE"
> then sends the Invite to its local SIP proxy.
"INVITE"
Section 4, step 2:
> into the new Identity-Media header. The invite is forwarded
"INVITE"
Section 4, step 4:
> the Invite. It validates the Identity-Media signature is
> valid and was validates it was generated by the originating
"INVITE"
Insert "that" after "It validates". Change "was validates" to "validates
that".
Section 4, step 5:
> authentication service forwards the Invite to the endpoint.
"INVITE"
Section 4, step 6:
> challenge technique from the Invite, and performs that
"INVITE"
Section 4, step 7:
> public key. The terminating endpoint validates the
Insert "that" after "validates".
Section 4, step 8:
> Step 8: You can reliably and honestly indicate calling party
> information ("caller-id") to the terminating endpoint, and
> ring their phone.
Rewrite to
>> Step 8: The terminating endpoint can reliably and honestly indicate
>> calling party information ("caller-id") and ring the phone.
Section 4.1, first para:
> "fingerprint"). The specific SDP attribute that are signed depends
"attributes"
Section 4.1, second para:
> The SIP headers that are signed are signed the same as done by
Remove the second "signed".
> the body is not signed. They signed headers are:
"They" -> "The"
Section 4.1, item about Date:
> the weekday and month items case set as shown in BNF in RFC 3261.
Insert "the" before "BNF".
Section 4.2:
> The authentication service examines the SIP message body for the
> application/sdp Content-Type. For all such content-types found, the
"all such content-types" -> "all such message bodies"
Section 5, para 3:
> or HIP session and validates the certificate fingerprint presented in
> SIP signaling matches the certificate presented in the TLS, DTLS,
Insert "that" after "validates" and insert "the" before "SIP".
Section 5.2:
Newline missing after SDP example.
Section 5.3.1:
> subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP. The syntax is a
"CHALLENGE"
Section 5.3.2.1:
> 5.3.2.1. PK-CHALLANGE
"CHALLENGE"
Section 7.1:
Write the list items as complete sentences, i.e. start with capitals and
remove ", or" from the end of the first item.
> the device to manufacture a new self-signed certificate (or public
Insert "needs" after "the device".
Section 10.1:
> This example shows how two a=fingerprint lines in SDP would populate
> a the Media-Fingerprints SIP header field. The following is an
> example of an Invite created by the endpoint.
"a the" -> "the"
"INVITE"
Hans
--
Hans Persson <[EMAIL PROTECTED]> Ingate - Firewalls with SIP & NAT
Ingate Systems AB +46 13 210857 http://www.ingate.com/
Private: <[EMAIL PROTECTED]> http://www.lysator.liu.se/~unicorn/
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
