Subject: RE: [Sipping] additional optional parameters for translation {ISU P to SIP}

From: Adam Roach <[email-masked]>
Date: Mon, 15 Jul 2002 00:37:34 -0500

These cannot be mapped. There are no equivalents in the SIP protocol.

/a

> -----Original Message-----
> From: a c [mailto:[email-masked]]
> Sent: Wednesday, July 10, 2002 20:44
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] additional optional parameters for
> translation {ISUP
> to SIP}
>
>
> hello,
>
>  Could you please include the following the following
> parameters for translation as they are essential for
> voice mail:
>
> - Redirecting Number {for multiple redirected calls}
>   IE 00001011
>
> - Redirection Information {reason for forward -
> Original reason and redirect reason}- IE 00010011
>
> - Redirection Counter - number of redirections
> undergone - IE 00010011
>
> thank you..alex
>
> "There are also quite a few optional parameters that
> can appear in an
>    IAM message; Q.763 [15] lists 29 in all.  However,
> each of these
>    parameters need not to be translated in order to
> achieve the goals of
>    SIP-ISUP mapping.  As is stated above, translation
> allows SIP network
>    elements to understand the PSTN context of the
> session if they are
>    not capable of deciphering any encapsulated ISUP.
> Parameters that
>    are only meaningful to the PSTN will be carried
> through PSTN-SIP-
>    PSTN networks via encapsulation - translation is
> not necessary for
>    these parameters.  Of the aforementioned 29
> optional parameters, only
>    the following are immediately useful for
> translation: the Calling
>
>
>
> Camarillo, et al.       Expires December 30, 2002
>         [Page 20]
>
> Internet-Draft             ISUP to SIP Mapping
>         July 2002
>
>
>    Party's Number (CIN, which is commonly present),
> Transit Network
>    Selection (TNS), Carrier Identification Parameter
> (CIP, present in
>    ANSI networks), Original Called Number (OCN), and
> the Generic Digits
>    (known in some variants as the Generic Address
> Parameter (GAP)).
> "
>
>
>
>
> --------------------------------------------------------------
> ------------------
> [Date Prev][Date Next][Thread Prev][Thread Next][Date
> Index][Thread Index]
> Last Call: ISUP to SIP Mapping to Proposed Standard
>
> --------------------------------------------------------------
> ------------------
>
> To: IETF-Announce: ;
> SUBJECT: Last Call: ISUP to SIP Mapping to Proposed
> Standard
> From: The IESG <[email-masked]>
> Date: Mon, 08 Jul 2002 17:45:01 -0400
> Cc: [email-masked]
> Reply-to: [email-masked]
> Sender: [email-masked]
>
> --------------------------------------------------------------
> ------------------
>
>
>
> The IESG has received a request from the Session
> Initiation Proposal
> Investigation Working Group to consider publishing
> each of the
> following internet drafts as as Proposed Standards.
>
> o 'ISUP to SIP Mapping'
> 	<draft-ietf-sipping-isup-03.txt>
> o Mapping of ISUP Overlap Signalling to the Session
> Initiation
>   Protocol
> 	<draft-ietf-sipping-overlap-01.txt>
>
> The IESG plans to make a decision in the next few
> weeks, and
> solicits final comments on this action.  Please send
> any comments to
> the [email-masked] or [email-masked] mailing lists by
> August 05, 2002.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-01.txt
>
>
>
>
>
>
> --------------------------------------------------------------
> ------------------
>
> Prev by Date: RFC 3268 on Advanced Encryption Standard
> (AES) Ciphersuites for Transport Layer Security (TLS)
> Next by Date: RFC 3287 on Remote Monitoring MIB
> Extensions for Differentiated Services
> Prev by thread: RFC 3287 on Remote Monitoring MIB
> Extensions for Differentiated Services
> Next by thread: RFC 3268 on Advanced Encryption
> Standard (AES) Ciphersuites for Transport Layer
> Security (TLS)
> Index(es):
> Date
> Thread
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
>
> _______________________________________________
> 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: a c <[email-masked]>
Date: Mon, 15 Jul 2002 11:32:08 -0700 (PDT)

hello Adam,

 So basically the endpoints have to decode the
information out of the encapsulated information. Won't
this cause some extra processing?

For example on a multiple redirect call:

OCN - received by normal sip signaling. There is
no way to find out (other than looking at the
encapsulated information) if the call is directed
multiple times. So a terminating endpoint (vm
application) has to look at the sip headers as well as
the encapsulated information for *every* call.

Or the other solution is for the originating endpoint
to do some translation. You have to put logic on this
system to map RDN to OCN for multiple redirected
calls. The same applies for the redirect reason (not
translated now).

thank you
alex

> > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com