Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-isup-00.txt (WGLC rem inder)

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Nov 2001 13:48:10 -0600

This is just a reminder for those interested in the ISUP to SIP work that
this draft (formerly known as draft-ietf-sip-isup-03.txt) is currently in a
Working Group last call that concludes November 22nd. 

If you have any final comments on this draft, please get them to the authors
before WGLC expires. Thanks.

Jon Peterson
NeuStar, Inc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 5:33 AM
> Cc: [email-masked]
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-isup-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Proposal 
> Investigation Working Group of the IETF.
> 
> 	Title		: ISUP to SIP Mapping
> 	Author(s)	: G. Camarillo et al.
> 	Filename	: draft-ietf-sipping-isup-00.txt
> 	Pages		: 55
> 	Date		: 16-Nov-01
> 	
> This document describes a way to perform the mapping between two
> signaling protocols: the Session Initiation Protocol (SIP) and the
> ISDN User Part (ISUP) of SS7. This mechanism might be implemented
> when using SIP in an environment where part of the call involves
> interworking with the Public Switched Telephone Network (PSTN).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-isup-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-sipping-isup-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sipping-isup-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
Sipping mailing list  http://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: "Peterson, Jon" <[email-masked]>
Date: Wed, 21 Nov 2001 15:41:25 -0600

In response to (1), I believe that some fairly precise guidelines are given
for the use of SIP INFO as opposed to re-INVITE, although as you suspect it
does ultimately boil down to local policy. However, I don't see how a
situation could arise in which there would be an 'intermediary' MGC or proxy
that would receive an INFO method and, for whatever reason, choose to send a
re-INVITE 'downstream' (presumably to the terminating MGC/endpoint?). This
doesn't sound like conventional proxy behavior to me, and nor do I expect
MGCs to be involved in these sorts of transactions as intermediaries rather
than endpoints. That much said, even if some sort of B2BUA were devised that
acted as an intermediary specifically for bridging between systems using
INFO and systems using re-INVITE to represent SUS/RES, I don't think that
would necessarily break the mechanism described in section 8.1 - but I don't
think we should recommend for or against this practice since it is
contingent on an architecture that we currently have no motivation to
explore.

As for (2), the SIP to ISUP draft deals, appropriately enough, with things
above the MTP3 layer in SS7. I agree that characterizing data about trunk
groups is probably within the scope of SIP-T, but only in so far as SIP-T
should reflect the contents of PSTN protocols when possible. The sorts of
attributes of trunk groups I believe you are enumerating (i.e. whether a
trunk is a meet point trunk, a co-carrier trunk, etc) are however not
actually a part of inter-switch PSTN signaling today - they are
administrative concepts used internally to networks and switches to make
policy decisions. As such I'm not aware of any protocol elements in the PSTN
that accordingly specify the 'nature' of inter-switch calls, and thus I'm
not sure that we need to build anything in to SIP-T that does so. I do
concede however that a more detailed analysis of the usage of trunk groups
in SIP-T is most likely warranted.

Jon Peterson
NeuStar, Inc.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 12:27 PM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-isup-00.txt (WGLC
> reminder)
> 
> 
> 
> Hi,
> 
> I have two questions on this draft, sipping-isup-00.
> 
> (1) In Section 8.1, it now provides an option regarding 
> whether to carry
> ISUP SUS/RES in SIP INFO or Re-INVITE.
> Is the determination on which SIP message to use based on 
> local policy of
> the MGC receiving SUS?
> In SIP bridging situations where there may be multiple MGCs/proxies
> involved passing the SUS message, what happens if the local 
> policy on this
> at each MGC/Proxy differs? For example, is the following case 
> allowed where
> a MGC/proxy receiving INFO with SUS payload determines to use 
> Re-INVITE
> instead to carry SUS downstream?
> 
> (2) In PSTN, trunk group concept is used to identify the 
> nature of the call
> (e.g., local call, exchange access call or toll call) for 
> communications
> between switches (e.g., end office, access tandem, toll 
> tandem). When not
> using the trunk group concept, is there any support in SIP-T 
> to specify
> such nature of the inter-switch calls?
> 
> Thanks,
> YoungSun
> 
> 
> 
> 
> "Peterson, Jon" <[email-masked]> on 11/19/2001 02:48:10 PM
> 
> To:   "[email-masked]'" <[email-masked]>
> cc:    (bcc: Youngsun Song/Telcordia)
> Subject:  RE: [Sipping] I-D 
> ACTION:draft-ietf-sipping-isup-00.txt (WGLC rem
>       inder)
> 
> 
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 29 Nov 2001 17:56:04 -0600

The early media draft

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-early-media-00.tx
t

contains an example of the interplay between SIP-ISUP mapping and the
proposed early media extension. While support for the 'em' extension is not
required for SIP-ISUP mapping, it does allow for some more sophisticated
ways of creating and rejecting early media sessions (essentially the use of
different SDPs for early media than are used for the main session) that
handle some of the difficult cases arising from gateway behavior. You might
want to take a look at that draft.

That much said, as far as SIP-ISUP is concerned,

(1) Yes, it will play any audio it receives from the UAS if the 'em'
extension is not supported.

(2) No. Nothing can stop the UAC from sending media, it's true, but that
does not mean the UAS will play it. Note that in 6.1.1 of SIP-ISUP
bidirectional media is not established until step 11. 

(3) Yes.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, November 29, 2001 3:04 PM
> To: Peterson, Jon
> Cc: [email-masked]'
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-isup-00.txt (WGLC
> reminder)
> 
> 
> 
> Hi,
> 
> I have few early media related questions on the Sipping-isup 
> document as
> follows.
> 
> (1) In the SIP to ISUP flow in Section 6.1.1, at Step 3, when 
> the PSTN is
> sending audio stream and the MGC/MG allows it, will the UAC 
> play media to
> the caller without receiving the 18x containing remote SDP? 
> What is the
> expected behaviour of the UAC in this case?
> 
> (2) In the same flow at Step 4, when the UAC receives a 18x containing
> remote SDP, the early media path in the IP network is practically cut
> through in both directions because nothing will stop the UAC 
> from sending
> media. Is this right?
> 
> (3) In Section 6.2.6, ACM received, there is a paragraph 
> stating, "Usually
> on receipt of an ACM, a `180 Ringing' is sent to the SIP network.  It
> should generally contain a session description in order to 
> allow SIP UAs to
> prevent clipping of initial callee media." Also in Section 7.2.3, 18x
> received, there is a paragraph stating, "If the reception of a `180
> Ringing' response without media description, the MG generates 
> the ringback
> tone to be heard by the caller."
> 
> Does the above mean the following for an ISUP to SIP flow?
> -- If 180 Ringing without SDP is received, the MGC/MG should 
> generate local
> ringback tone towards the PSTN caller.
> -- If 180 Ringing with SDP is received, the MGC/MG should NOT generate
> local ringback tone but relay media received from SIP UAS to the PSTN.
> 
> Thanks,
> YoungSun
> 
>