Subject: RE: [SIP] SIP-T Draft Feedback

From: [email-masked]
Date: Wed, 2 Aug 2000 05:00:24 -0600

Adam,
Thank you for your close reading of the document and your comments. Please
look at my notes on yours.
Aparna

Aparna V.
Level (3) Communications.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Monday, July 31, 2000 12:38 PM
To: Vemuri, Aparna; Peterson, Jon
Cc: [email-masked]; [email-masked]
Subject: [SIP] SIP-T Draft Feedback

Comments about draft-vemuri-sip-t-context-00.txt:

- On page 5, the point about "PSTN origination"
  should make mention that some ISUP modifications
  may occur to sync up with changes made by SIP
  proxies in the SIP network.

[AV]:
I think you refer to the changes that might be made to
bring the ISUP in line with the SIP messaging that 
encompasses it.  I believe that the SIP headers will be in 
tune with the ISUP at the ingress MGC that performs the 
translation between the two. The SIP headers could 
subsequently undergo modification  that would then 
result in a conflict between the SIP and ISUP. 

I am not sure if it is appropriate to explain this with the
'PSTN origination' point. We do touch upon this later (in 
section 6.2, to be precise) and I think we could re-phrase
or re-position this in order for this to be more suitable.

- In the call flows, you tend to map ACM messages
  to "183 Session Progress." In practice, ACMs
  typically have indication of "Subscriber
  free," which *should* map to "180 Ringing."
  Admittely, you don't have any ISUP parameters
  detailed in the call flows, but I think you
  shouldn't be using the exceptional cases to
  illustrate call flows.

 .....OK.

- On page 10, there's a minor cut and paste error
  where the final BYE response is listed as BYE.

[AV]:
 This will be corrected.

- Also in the call flow in page 10, note that
  the 200 response for BYE is used only for
  reliability; in ISUP, the RLC is used to
  indicate that a circuit is available for re-use.
  In most circumstances, it doesn't make sense
  to hold off the 200 response to the BYE
  until the RLC arrives.

[AV]:
Thanks for pointing this out. This will be rectified.

- On page 14: I just want to bring your attention
  to the fact that much of the header mapping
  is already present in Gonzalo's and my draft.

[AV]:
It would be nice if we could talk about this some more.

- Also on page 14: it should be mentioned that
  encryption should be used for ISUP bodies.

[AV]:
I think we should study the ramifications of doing 
this some more along with determining what the 
regulatory issues concerning ISUP are.

I do not think end-to-end encryption will work, 
essentially because the originating MGC may not
know where the call may terminate, and usage
of hop-by-hop encryption (and consequent removal
or modification of ISUP) could require the proxies to
examine the bodies. Another option, I think, would
be to have an error message generated when the call
hits a 'non-encrypted hop' and to have the originator
resend the INVITE with the appropriate 
modifications.....
I think a few  such options  were put forth in a 
discussion on the list before.

Our thoughts were that this kind of situation would be 
averted if a network managed the registration of 
end-points and enforced trust relationships and policy
with users. Network edges could employ means to strip 
off the ISUP where necessary...

All in all, this is something that needs some 
more work.

- Section 6.2: It seems a bit odd to have a special
  purpose application server "fixing" the ISUP
  before it goes to the egress gateway. Since this
  gateway is already having to unpack the ISUP and
  (to some degree) understand it, it makes the
  most sense to perform that function in the MGC.

[AV]:
Our intention was NOT to mandate that an AS (Appln. 
Server) be used to do this job. We were only trying to 
make a suggestion that an AS may be used for this purpose. 
There may be multiple ways to do this. The text may need 
to be re-phrased accordingly.

- On note 9: in Gonzalo's and My draft, we specify
  that any informationthat shouldn't be presented
  also shouldn't be mapped into SIP headers.
  I beleive this is a non-issue, as long as the
  ISUP bodies are encrypted.

[AV]:
 I think that will be the case as long as the 
information is not mandatory for SIP. Specifically, 
(as far as note 9 goes) I do not think that the 
'userinfo' part (of userinfo@host) is required in 
the SIP 'From'. This (the note) may need to be pulled 
out.

Comments, Adam, Jon, SIP WG?

Thanks for the good work!

[AV]:
Thank you!
Aparna

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip