I have read the thread:

https://puck.nether.net/pipermail/c...rch/003509.html

And was curious as to the outcome.  I have PRI's coming in from a 5ESS, and 
the carrier is sending the ID in the facility IE (inbound calls to us), and 
of course CM appears to want it in the display IE.  I have read of ways CM w
ould take it via the Facili
ty ID if using MGCP AND NI2/3 or MGCP AND QSIG.  Does any solution at all ex
ist for H.323?  I have tried to set my switch type for NI and QSIG, both wor
k as far as placing/receiving calls, but I still cannot get inbound name id.
  I have tried to set "isdn
supp-service name calling" on the gateway as well but it doesn't seem to fix
 it.  Gateways are running late 12.3T code, CM is 4.1(3)SR2.

Sure I can try to battle it out with Bellsouth and ask them to change to dis
play IE, but I am sure they will not do it for me, I'll try though.  But I a
m hoping there is a solution for those of us with H.323 links.  I could poss
ibly get them to switch the
circuit to NI2 or QSIG.  Like I said switching the switch type on the gatewa
y works, without having the carrier do anything probably because its just co
mpatible, but not sure if formally having them change the switch emulation w
ould do anything.  The q.9
31 output is definitely more "friendly" with QSIG/NI, as it decodes the faci
lity IE.  With 5ESS it doesn't like to receive the name id facility ie stuff
, it errors on it (but of course call completes).

Brian

[ Post a follow-up to this message ]

Brian,

Unless someone knows any pfm, there is no way to accomplish caller-id on
a PRI with H.323 unless your provider switches the data into Display IE
(good luck with that).  Recently (using 12.4(4T), I opened a TAC case
about this issue to see if there was any way to accomplish this or if it
had been addressed in the new 12.4 train.  TAC sent me a clear answer
saying H.323 and caller-id are unsupported and in order to get it, I
needed to go to MGCP.

Joe Bell

-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Feeny
Sent: Thursday, December 15, 2005 11:23 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Caller Name ID possible via Facility IE with
H.323?


I have read the thread:

https://puck.nether.net/pipermail/c...rch/003509.html

And was curious as to the outcome.  I have PRI's coming in from a 5ESS,
and the carrier is sending the ID in the facility IE (inbound calls to
us), and of course CM appears to want it in the display IE.  I have read
of ways CM would take it via the Facility ID if using MGCP AND NI2/3 or
MGCP AND QSIG.  Does any solution at all exist for H.323?  I have tried
to set my switch type for NI and QSIG, both work as far as
placing/receiving calls, but I still cannot get inbound name id.  I have
tried to set "isdn supp-service name calling" on the gateway as well but
it doesn't seem to fix it.  Gateways are running late 12.3T code, CM is
4.1(3)SR2.

Sure I can try to battle it out with Bellsouth and ask them to change to
display IE, but I am sure they will not do it for me, I'll try though.
But I am hoping there is a solution for those of us with H.323 links.  I
could possibly get them to switch the circuit to NI2 or QSIG.  Like I
said switching the switch type on the gateway works, without having the
carrier do anything probably because its just compatible, but not sure
if formally having them change the switch emulation would do anything.
The q.931 output is definitely more "friendly" with QSIG/NI, as it
decodes the facility IE.  With 5ESS it doesn't like to receive the name
id facility ie stuff, it errors on it (but of course call completes).

Brian
 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


This message and any attachments are intended only for the use of the addres
see and may contain information that is privileged and confidential. If the 
reader of the message is not the intended recipient or an authorized represe
ntative of the intended rec
ipient, you are hereby notified that any dissemination of this communication
 is strictly prohibited. If you have received this communication in error, p
lease notify us immediately by e-mail and delete the message and any attachm
ents from your system.

[ Post a follow-up to this message ]

Thanks, I have a case open, but I am wanting a clear explanation of the "isd
n supp-service name calling", and how it applies, if at all to H.323.

I am going to try to get Hellsouth to switch to Display IE, but I am not hol
ding my breath.

Brian

On Thursday, December 15, 2005, at 07:22PM, Bell, Joe <Joe_Bell@adp.com> wro
te:

>Brian,
>
>Unless someone knows any pfm, there is no way to accomplish caller-id on
>a PRI with H.323 unless your provider switches the data into Display IE
>(good luck with that).  Recently (using 12.4(4T), I opened a TAC case
>about this issue to see if there was any way to accomplish this or if it
>had been addressed in the new 12.4 train.  TAC sent me a clear answer
>saying H.323 and caller-id are unsupported and in order to get it, I
>needed to go to MGCP.
>
>Joe Bell
>
>-----Original Message-----
>From: cisco-voip-bounces@puck.nether.net
>[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Feeny
>Sent: Thursday, December 15, 2005 11:23 AM
>To: cisco-voip@puck.nether.net
>Subject: [cisco-voip] Caller Name ID possible via Facility IE with
>H.323?
>
>
>I have read the thread:
>
>https://puck.nether.net/pipermail/c...rch/003509.html
>
>And was curious as to the outcome.  I have PRI's coming in from a 5ESS,
>and the carrier is sending the ID in the facility IE (inbound calls to
>us), and of course CM appears to want it in the display IE.  I have read
>of ways CM would take it via the Facility ID if using MGCP AND NI2/3 or
>MGCP AND QSIG.  Does any solution at all exist for H.323?  I have tried
>to set my switch type for NI and QSIG, both work as far as
>placing/receiving calls, but I still cannot get inbound name id.  I have
>tried to set "isdn supp-service name calling" on the gateway as well but
>it doesn't seem to fix it.  Gateways are running late 12.3T code, CM is
>4.1(3)SR2.
>
>Sure I can try to battle it out with Bellsouth and ask them to change to
>display IE, but I am sure they will not do it for me, I'll try though.
>But I am hoping there is a solution for those of us with H.323 links.  I
>could possibly get them to switch the circuit to NI2 or QSIG.  Like I
>said switching the switch type on the gateway works, without having the
>carrier do anything probably because its just compatible, but not sure
>if formally having them change the switch emulation would do anything.
>The q.931 output is definitely more "friendly" with QSIG/NI, as it
>decodes the facility IE.  With 5ESS it doesn't like to receive the name
>id facility ie stuff, it errors on it (but of course call completes).
>
>Brian
> ________________________________________
_______
>cisco-voip mailing list
>cisco-voip@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>This message and any attachments are intended only for the use of the addressee and
 may contain information that is privileged and confidential. If the reader of the m
essage is not the intended recipient or an authorized representative of the intended
 re
cipient, you are hereby notified that any dissemination of this communication is strictly pr
ohibited. If you have received this communication in error, please notify us immediately by 
e-mail and delete the message and any attachments from your system.
>
> ________________________________________
_______
>cisco-voip mailing list
>cisco-voip@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

[ Post a follow-up to this message ]

I think I recall some discussion on this list or in
the cisco forums about this being changed in a future
release of CME (and thus IOS hopefully). I'll have to
do some digging to see if I can find that again.

--- Brian Feeny <bfeeny@mac.com> wrote:

> Thanks, I have a case open, but I am wanting a clear
> explanation of the "isdn supp-service name calling",
> and how it applies, if at all to H.323.
>
> I am going to try to get Hellsouth to switch to
> Display IE, but I am not holding my breath.
>
> Brian
>
> On Thursday, December 15, 2005, at 07:22PM, Bell,
> Joe <Joe_Bell@adp.com> wrote:
> 
> accomplish caller-id on 
> data into Display IE 
> opened a TAC case 
> accomplish this or if it 
> me a clear answer 
> order to get it, I 
> Behalf Of Brian Feeny 
> Facility IE with 
>
>https://puck.nether.net/pipermail/c...rch/003509.html 
> coming in from a 5ESS, 
> IE (inbound calls to 
> display IE.  I have read 
> using MGCP AND NI2/3 or 
> H.323?  I have tried 
> far as 
> inbound name id.  I have 
> the gateway as well but 
> late 12.3T code, CM is 
> ask them to change to 
> me, I'll try though. 
> with H.323 links.  I 
> NI2 or QSIG.  Like I 
> works, without having the 
> compatible, but not sure 
> would do anything. 
> QSIG/NI, as it 
> to receive the name 
> course call completes). 
> for the use of the addressee and may contain
> information that is privileged and confidential. If
> the reader of the message is not the intended
> recipient or an authorized representative of the
> intended recipient, you are hereby notified that any
> dissemination of this communication is strictly
> prohibited. If you have received this communication
> in error, please notify us immediately by e-mail and
> delete the message and any attachments from your
> system. 
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


 ________________________________________
__________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[ Post a follow-up to this message ]

Here's what I found from previous discussion on this
topic on this list and at forums.

http://forum.cisco.com/eforum/servl...n%3D.1dd93785/2

The cisco forum has someone from cisco indicating
support for facility IE will be there next year, but
no way to confirm or if it'll be a CME-only feature.
If it were in IOS, then it would need to be passed to
CCM in messages CCM could understand also.

The following is a snippet from a previous post here I
had saved, not sure who it was from but was regarding
the isdn supp-service command. Maybe is only effective
with SIP? I have not had need to use this command
myself yet. (Sorry for formatting below).

> [...] 
> doesn't appear to get 
> least not in any 
> _number_ works fine.
>
> So, for everybody following along at home, it
> appears as though one
> must configure "isdn supp-service calling name"
> under the sX/Y:23
> interface config in order for the Access Server to
> recognize caller ID
> name in the ISDN facility messages.  This feature is
> available in
> 12.3(14)T and 12.3(11)T (and likely earlier builds),
> but not in
> 12.3(13) mainline.
>
> Problem is, when running T train code, the cisco has
> developed a habit
> of continuing to ring a SIP channel, even when a
> PSTN caller has
> disconnected.  This appears to be a result of
> something having changed
> in how the box sends out SIP BYE/CANCEL messages,
> though I'm a bit
> confused as to the particulars.



--- Erick Bergquist <erickbe@yahoo.com> wrote:
[vbcol=seagreen]
> I think I recall some discussion on this list or in
> the cisco forums about this being changed in a
> future
> release of CME (and thus IOS hopefully). I'll have
> to
> do some digging to see if I can find that again.
>
> --- Brian Feeny <bfeeny@mac.com> wrote:
> 
> clear 
> calling", 
> the 
> I 
> sent 
>
>https://puck.nether.net/pipermail/c...rch/003509.html 
> for 
> as 
> and 
> us 
> emulation 
> with 
> like 
> only 
> If 
> any 
> communication 
> and 


 ________________________________________
__________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[ Post a follow-up to this message ]

CSCdu81533 is in a closed state and no mention of any work to add the
feature.  TAC's only suggestion was to move to MGCP.

CSCdu81533 - Caller name display in q931 facility msg is not processed
and passed Release-note: Name display received in Q931 facility msgs is
not processed and passed onto h225 by IOS gateways. There is no
workaround.




On Dec 15, 2005, at 11:55 PM, Erick Bergquist wrote:

> Here's what I found from previous discussion on this
> topic on this list and at forums.
>
> http://forum.cisco.com/eforum/servlet/NetProf?
> page=netprof&forum=IP%20Communications%20and%20Video&topic=IP%20Telepho
> ny& CommCmd=MB%3Fcmd%3Ddisplay_location%26lo
cation%3D.1dd93785/2
>
> The cisco forum has someone from cisco indicating
> support for facility IE will be there next year, but
> no way to confirm or if it'll be a CME-only feature.
> If it were in IOS, then it would need to be passed to
> CCM in messages CCM could understand also.
>
> The following is a snippet from a previous post here I
> had saved, not sure who it was from but was regarding
> the isdn supp-service command. Maybe is only effective
> with SIP? I have not had need to use this command
> myself yet. (Sorry for formatting below).
>
>
>
Georgia Institute of Technology     Atlanta, Georgia
Georgia Tech Research Institute
Electronic Systems Laboratory

Public Key ID: 0x894F4419
[7338 D848 8BEE FF6D 23D1  4355 2F6C DE0C 894F 4419]

[ Post a follow-up to this message ]

Unfortunately this is correct.

The bug mentioned below references CSCdt03385 which is where the
support for this was built into MGCP (as of CM 3.3.3).  Currently
there is no support for H.323 with CallManager.   I can't speak to CME.

-Ryan

On Dec 16, 2005, at 12:34 AM, Trey Howland wrote:

CSCdu81533 is in a closed state and no mention of any work to add the
feature.  TAC's only suggestion was to move to MGCP.

CSCdu81533 - Caller name display in q931 facility msg is not processed
and passed Release-note: Name display received in Q931 facility msgs is
not processed and passed onto h225 by IOS gateways. There is no
workaround.




On Dec 15, 2005, at 11:55 PM, Erick Bergquist wrote:

> Here's what I found from previous discussion on this
> topic on this list and at forums.
>
> http://forum.cisco.com/eforum/servlet/NetProf?
> page=netprof&forum=IP%20Communications%20and%20Video&topic=IP%
> 20Telepho
> ny& CommCmd=MB%3Fcmd%3Ddisplay_location%26lo
cation%3D.1dd93785/2
>
> The cisco forum has someone from cisco indicating
> support for facility IE will be there next year, but
> no way to confirm or if it'll be a CME-only feature.
> If it were in IOS, then it would need to be passed to
> CCM in messages CCM could understand also.
>
> The following is a snippet from a previous post here I
> had saved, not sure who it was from but was regarding
> the isdn supp-service command. Maybe is only effective
> with SIP? I have not had need to use this command
> myself yet. (Sorry for formatting below).
>
>
>
Georgia Institute of Technology     Atlanta, Georgia
Georgia Tech Research Institute
Electronic Systems Laboratory

Public Key ID: 0x894F4419
[7338 D848 8BEE FF6D 23D1  4355 2F6C DE0C 894F 4419]

 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[ Post a follow-up to this message ]

it was implemented for SIP, but not for h323 because of some
interesting challenges with the way h323 calls are set up.

/Wes
On Dec 15, 2005, at 9:07 PM, Brian Feeny wrote:

Thanks, I have a case open, but I am wanting a clear explanation of
the "isdn supp-service name calling", and how it applies, if at all
to H.323.

I am going to try to get Hellsouth to switch to Display IE, but I am
not holding my breath.

Brian

On Thursday, December 15, 2005, at 07:22PM, Bell, Joe
<Joe_Bell@adp.com> wrote:

> Brian,
>
> Unless someone knows any pfm, there is no way to accomplish caller-
> id on
> a PRI with H.323 unless your provider switches the data into
> Display IE
> (good luck with that).  Recently (using 12.4(4T), I opened a TAC case
> about this issue to see if there was any way to accomplish this or
> if it
> had been addressed in the new 12.4 train.  TAC sent me a clear answer
> saying H.323 and caller-id are unsupported and in order to get it, I
> needed to go to MGCP.
>
> Joe Bell
>
> -----Original Message-----
> From: cisco-voip-bounces@puck.nether.net
> [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Feeny
> Sent: Thursday, December 15, 2005 11:23 AM
> To: cisco-voip@puck.nether.net
> Subject: [cisco-voip] Caller Name ID possible via Facility IE with
> H.323?
>
>
> I have read the thread:
>
> https://puck.nether.net/pipermail/c...rch/003509.html
>
> And was curious as to the outcome.  I have PRI's coming in from a
> 5ESS,
> and the carrier is sending the ID in the facility IE (inbound calls to
> us), and of course CM appears to want it in the display IE.  I have
> read
> of ways CM would take it via the Facility ID if using MGCP AND
> NI2/3 or
> MGCP AND QSIG.  Does any solution at all exist for H.323?  I have
> tried
> to set my switch type for NI and QSIG, both work as far as
> placing/receiving calls, but I still cannot get inbound name id.  I
> have
> tried to set "isdn supp-service name calling" on the gateway as
> well but
> it doesn't seem to fix it.  Gateways are running late 12.3T code,
> CM is
> 4.1(3)SR2.
>
> Sure I can try to battle it out with Bellsouth and ask them to
> change to
> display IE, but I am sure they will not do it for me, I'll try though.
> But I am hoping there is a solution for those of us with H.323
> links.  I
> could possibly get them to switch the circuit to NI2 or QSIG.  Like I
> said switching the switch type on the gateway works, without having
> the
> carrier do anything probably because its just compatible, but not sure
> if formally having them change the switch emulation would do anything.
> The q.931 output is definitely more "friendly" with QSIG/NI, as it
> decodes the facility IE.  With 5ESS it doesn't like to receive the
> name
> id facility ie stuff, it errors on it (but of course call completes).
>
> Brian
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> This message and any attachments are intended only for the use of
> the addressee and may contain information that is privileged and
> confidential. If the reader of the message is not the intended
> recipient or an authorized representative of the intended
> recipient, you are hereby notified that any dissemination of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by e-mail and
> delete the message and any attachments from your system.
>
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
 ________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[ Post a follow-up to this message ]