[prev in list] [next in list] [prev in thread] [next in thread]
List: sip-implementors
Subject: RE: [Sip-implementors] PSTN to SIP
From: <sayan.chowdhury () wipro ! com>
Date: 2005-06-29 6:31:53
Message-ID: 3843282A55DB1A49BD0197F819AA7E927BD16C () kol-slk-msg01 ! wipro ! com
[Download RAW message or body]
Oh Ok , I see that now , you are right ..
I thought for inband tones/patterns it is more reliable if you depend on
the OBCI. That contains an explicit indication regarding in band tones.
The basic stuff still remains the same , u don't have a bi directional
speech path till answer ..
Cheers ,
Sayan
-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Shikhar
Sarkar
Sent: Tuesday, June 28, 2005 9:00 PM
To: sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] PSTN to SIP
Sayan,
Excerpts from RCC 3398 section 7.2.6:
"If the Backward Call Indicators (BCI) parameter of the ACM indicates
that interworking has been encountered (generally designating that
the ISUP network sending the ACM is interworking with a less
sophisticated network which cannot report its status via out-of-band
signaling), then there may be in-band announcements of call status
such as an audible busy tone or caller intercept message, and if
possible a backwards media transmission SHOULD be initiated."
"After early media transmission has been initiated, the gateway SHOULD
send a 183 Session Progress response code."
I guess we all are on the same page. These are just the details that are
often devilish :-)
Shikhar
-----Original Message-----
From: sayan.chowdhury@wipro.com [mailto:sayan.chowdhury@wipro.com]
Sent: Tuesday, June 28, 2005 8:19 AM
To: sip-implementors@cs.columbia.edu; srivastava.vivek@wipro.com
Cc: shikhar@utstar.com
Subject: RE: [Sip-implementors] PSTN to SIP
Hello, I think we are a bit confused here , the BCI contains two fields
1>Interworking Indicator 2>Called party Status
Called party status has two permissible values subscriber free and no
indication. In an early ACM case , it will be set to No Indication and
we send out an 183 on the SIP side. As far as I remember , neither
Q.1912 or RFC3398 describes a a 18x procedure on the SIP side based on
interworking indicator field, I may be wrong of course.
IMHO , the answer to Vivek's question lies in the way the PSTN circuits
behave , by default without any feature interaction , the two way speech
path is enabled on a circuit only after answer . The reason being ,
fraud prevention and billing. ANM being the start point of the billing
duration on the CDRS. That is why I think the RFC shows a 1 way speech
path , although it is technically possible to have a 2 way speech path
as Vivek says.
My two bits, Regards , Sayan
-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Shikhar
Sarkar
Sent: Monday, June 27, 2005 9:22 PM
To: sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] PSTN to SIP
Bani,
Pay attention to what the spec is saying: The "called party status" code
in
the ACM message is mapped to a SIP provisional response.
The ACM message alone is not enough to decide whether the backward voice
path should be established. The Backward Call Indicator bits determine
it.
That is why SIP spec is open in saying 18x. If BCI bits indicate, for
example, "interworking encountered", then certainly backward path will
be
connected and 183 will be sent to the calling party. On the other hand,
if
BCI bits indicate "subscriber free", then 180 will be sent.
Thanks,
Shikhar
-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Banibrata
Dutta
Sent: Monday, June 27, 2005 10:13 AM
To: 'Amith Nambiar'; srivastava.vivek@wipro.com;
sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] PSTN to SIP
I am not exactly sure why the call-flow shows 18x, because I believe
that
"183 Session Progress" was specifically meant for this purpose ! This is
especially true for playing back announcements (before the called party
went
off-hook), s.a. "all trunks in this route are busy", while interacting
with
PSTN.
- banibrata.
-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Amith
Nambiar
Sent: Monday, June 27, 2005 5:04 PM
To: srivastava.vivek@wipro.com; sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] PSTN to SIP
-----Original Message-----
From: srivastava.vivek@wipro.com [mailto:srivastava.vivek@wipro.com]
Sent: Monday, June 27, 2005 3:55 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] PSTN to SIP
Hi All,
7.1.1 En-bloc Call Setup (no auto-answer)
SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
RFC 3398 says:
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP to establish an early media stream (as shown in the
diagram). If no SDP is present, the audio will be established in
both directions after step 8.
Question: After step 2, pstn to sip audio connectivity is possible
because IAM provides sufficient information about media channel and one
side channel is acquired at that time. But on step 4, when 18x is
carrying sdp for PSTN, why only one way(PSTN to SIP) Audio path is
established. At this point of time SIP also knows about the media
capabilities of PSTN so it should be both way (same as step 8)
Cheers,
Vivek
Hi Vivek,
Why do u have to set up an audio stream in the SIP -> PSTN
side ? PSTN->SIP is acceptable , since the the PSTN side is the callee
and might be planning to play audio from that side ? SIP -> PSTN should
"logically" happen only when 200 OK is received to the SIP endpoint as
shown in the RFC.
Of course , the 18x response might carry the SDP, but the PSTN side
hasn't gone off-hook yet, for the SIP endpoint to play audio to the
other side.
~Amith.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
The information contained in this electronic message and any attachments
to
this message are intended
for the exclusive use of the addressee(s) and may contain confidential
or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic