Subject: [Sipping] Comments of draft-ietf-sipping-isup-02

From: Moter Du <[email-masked]>
Date: Wed, 12 Jun 2002 18:20:03 +0800

6.2.4 In the SIP bridging situation, the ISUP REL message may be included in
the body of SIP responses, or SIP requests such as CANCEL or BYE.  The
latter is applied when REL cause value is 16.

6.2.9 Reason phrase of 183 is "session" progress.

7.2.1.1 Just for your information.  Concerning number portability of the
ITU-T variant, translated number can be found in either
- The digits prepended to called party number of CPN, if Nature of Address
(NoA) is 8; the number of digits prepended are defined for national use, or
determinated by a delimiter which is also for national use only.
- The optional Network Routing Number (NRN) parameter; in this case CPN
would represent priorly called party number
- The Called Party Number (CPN) parameter, if an optional Called Directory
Number (CDN) representing priorly called party number is present

Moter

---

From: Moter Du <[email-masked]>
Date: Fri, 14 Jun 2002 19:54:23 +0800

trivia:

7.2.3 If no ACM..., "then" ISUP message...

8.2 The 200 in the figure should be right-to-left.  The ACK should be
left-to-right.

Moter

-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 6:20 PM
To: [email-masked]'
Subject: [Sipping] Comments of draft-ietf-sipping-isup-02

Moter

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2002 19:16:36 -0500

Thanks for both of these rounds of comments below. We'll make editorial
changes as appropriate.
 
Note that work on the Reason header will allow a CANCEL to carry the cause
code from an REL - effectively, the Reason header provides a way to preserve
the cause code with translation rather than encapsulation. A BYE, on the
other hand, is always normal clearing (16), as far as I know.
 
Thanks also for the tips on number portability mapping - capturing all of
the conceivable national variants for NP is very difficult.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 

Moter 

-----Original Message----- 
From: Moter Du [ mailto:[email-masked] <mailto:[email-masked]> ]

Moter

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Jun 2002 21:08:21 -0400

I'm a bit confused. In ISUP interworking, CANCEL will only ever occur
because of calling party abandon -- right? Why do we need to convey cause
codes in this situation? Won't it always be 16?
 
Also, the earlier versions of the ISUP draft actually included the concept
of encapsulating ISUP in the CANCEL requests. We were soundly taunted for
putting bodies in hop-by-hop messages (which are often generated anew at
each hop), and finally removed it. 2543bis has further made this all but
impossible by forbiding (in tables 2 & 3) the use of a "Content-Type" header
in CANCEL requests.
 
/a

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, June 17, 2002 19:17
To: 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

 
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 

Moter 

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

Moter

---

From: Moter Du <[email-masked]>
Date: Tue, 18 Jun 2002 12:12:34 +0800

Adam,
Not really.  In the configuration of IP origination and PSTN termination,
yes CANCEL occurs because of calling party abandon.  However in others,
CANCEL may also be generated by MGC at the receipt of ISUP REL message
containing various cause value.  The cause value can be
- 16 'normal call clearing', if it's a normal call release originating from
PSTN caller, callee, or networks
- others, if it's an abnormal call release, e.g., timer fires, call setup
failed, etc.
 
Jon,
However I do not understand why these ISUP cause values have to be conveyed
in the Reason header.  Does it imply some SIP user agents would have
appropriate ISUP functionality and like to react upon various ISUP causes?
Where would be that SIP user agents applied?
 
As the use of Content-Type header in CANCEL request is forbidden, some words
in 6.2.3 have to be removed "...In SIP briding situations, a REL might
arrive in the CANCEL...".
 
There would be nation-specific usage based on the ITU-T standard.  It would
be easier to follow if there's another draft to describe how to do
interworking between SIP and ITU-T ISUP.  But it seems not to be IETF's jobs
to define for each variant, does it?
 
Moter

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 9:08 AM
To: 'Peterson, Jon'; 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

 
/a

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, June 17, 2002 19:17
To: 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

 
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 

Moter 

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

Moter

---

From: Romel Khan <[email-masked]>
Date: Thu, 20 Jun 2002 14:52:51 -0400

Jon,
My practical experience with real live traffic has been that even after a
call is established once in a rare while we do get network generated drop in
call by a number of causes such as Rel with Temp Failure, Network Out of
Order. But at the SIP interworking this gets lost since BYE is sent, which
does not have a Reason Header that you envision for CANCEL. It would be very
good to have the Reason Header for the BYE msg also as an optional header
(this would be helpful not just for ISUP access to PSTN but also with Q.931,
etc). 

Thanks,
Romel Khan
Net2Phone

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, June 17, 2002 8:17 PM
To: 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

 
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 

Moter 

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

Moter

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Jun 2002 14:21:11 -0400

We took a design decision long ago not to replicate every ISUP header into
SIP. The problem you describe is addressed by using ISUP MIME bodies.

/a
-----Original Message-----
From: Romel Khan [mailto:[email-masked]]
Sent: Thursday, June 20, 2002 13:53
To: 'Peterson, Jon'; 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

Jon,

Thanks,
Romel Khan
Net2Phone

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, June 17, 2002 8:17 PM
To: 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 
-----Original Message----- 
From: Moter Du [mailto:[email-masked]] 
Sent: Wednesday, June 12, 2002 6:20 PM 
To: [email-masked]' 
Subject: [Sipping] Comments of draft-ietf-sipping-isup-02 

Moter 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Romel Khan <[email-masked]>
Date: Fri, 21 Jun 2002 14:34:11 -0400

Then why does CANCEL have to have the Reason header for? CANCEL can also
contain the ISUP body which will contain the release cause code.

Thanks,
Romel Khan 
Net2Phone
(732)923-2433

This e-mail and attachments, if any, may contain confidential and/or
proprietary information. Please be advised that the unauthorized use or
disclosure of the information is strictly prohibited. If you are not the
intended recipient, please notify the sender immediately by reply e-mail and
delete all copies of this message and attachments. Thank you.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Friday, June 21, 2002 2:21 PM
To: 'Romel Khan'; 'Peterson, Jon'; 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

/a
-----Original Message-----
From: Romel Khan [mailto:[email-masked]]
Sent: Thursday, June 20, 2002 13:53
To: 'Peterson, Jon'; 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

Jon,

Thanks,
Romel Khan
Net2Phone

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, June 17, 2002 8:17 PM
To: 'Moter Du'; [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Moter Du [mailto:[email-masked]]
Sent: Friday, June 14, 2002 4:54 AM
To: [email-masked]'
Subject: RE: [Sipping] Comments of draft-ietf-sipping-isup-02

trivia: 
-----Original Message----- 
From: Moter Du [mailto:[email-masked]] 
Sent: Wednesday, June 12, 2002 6:20 PM 
To: [email-masked]' 
Subject: [Sipping] Comments of draft-ietf-sipping-isup-02 

Moter

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Jun 2002 16:19:20 -0400

I think the discussion of CANCEL carrying bodies -- or, for that
matter, cause codes in any format -- is fundimentally flawed.
There are two reasons CANCEL cannot usefully contain bodies:

1) CANCEL requests are expressly forbidden from including "Content-Type"
   headers. This means that a body arriving in a CANCEL cannot necessarily
   be interpreted. Sure, it might be ISUP -- but, if bodies are allowed
   in CANCEL, someone else might define an extension that includes QSIG
   or text or audio as a CANCEL body. Without the means to distinguish
   what the body contains, it is fundimentally useless to include a
   body.

2) CANCEL bodies (and, for that matter, extension headers like "reason")
   cannot generally be expected to reach the other end of a proxy chain.
   Section 9.2 of bis-09 states:

    "The processing of a CANCEL request at a server depends on the type of
     server. A stateless proxy will forward it, a stateful proxy might
     respond to it and generate some CANCEL requests of its own, and a UAS
     will respond to it. See Section 16.10 for proxy treatment of CANCEL."

   This suggestion -- that a statful proxy might generate new CANCEL
   requests of its own -- fundimentally breaks the notion that a CANCEL
   could possibly contain any information beyond what is described in base
   SIP.

/a

> Sent: Friday, June 21, 2002 13:34
> To: 'Adam Roach'; 'Peterson, Jon'; 'Moter Du'; [email-masked]'