[cisco-voip] Gatewaying between SIP and H.323

[Steven E. Ames]

Hey. I'm hitting a bit of a snag. The solution should be fairly obvious but I'm not seeing it. I'm running a little test using a Cisco 2651XM (IOS 12.2.13(T8)). Here's the scenario.

A lot of SIP calls come into this box. All of the calls are prefixed 001 and are seen by the following incoming dial-peer:

dial-peer voice 50 voip
application session
incoming called-number 001.T
session protocol sipv2
session target sip-server
fax rate disable
no vad

So far so good. Normally I terminate these calls onto our TDM network via:

dial-peer voice 5 pots
application session
destination-pattern 001.T
port 1/0:23

And all is good with the world... now we have an H.323 gatekeeper and I use this same Cisco box as a PSTN gateway for the H.323 phones. That also works just fine. I have no problem at all calling from SIP<->TDM or H.323<->TDM. However... what I'd like to do is have incoming SIP calls delivered directly to H.323 phones (via gatekeeper and RAS).

My first thought was fairly obvious:

dial-peer voice 5 voip
application session
destination-pattern 001.T
session target ras

But that fails quite miserably. The dial-peer is matched but that's the end of it. Now I have two theories on why this fails:

1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad but if someone can say its so and maybe point out options?

2. ras is attempting to match 001T instead of just T (e.g. 0012125551212 instead of 2125551212)? I'm under the, potentially mistaken, impression that a destination-patter of 001.T will strip the 001. So maybe RAS just isn't matching.

Those are my two best guesses. I'm unclear on #2 because a statement such as:

num-exp 0012125551212 2125551212

and changing destination-pattern to '2125551212' doesn't help at all.

The closest I've come to getting this to work is routing the SIP call to my TDM network and then bouncing it back to the Cisco and then to the H.323:

SIP -> CISCO -> TDM -> CISCO -> H.323 works
SIP -> CISCO -> H.323 doesn't work

Help?

-Steve

[Klaus Darilion]

ASFAIK this is not supported. The feaure is called "hairpin of media"
and means that the call leaves the GW on the "same side" it is received
eg: PSTN - PSTN or VoIP - VoIP.

hairpin of media is supported on the POTS side, but not on the VoIP
side. Therefore SIP-H323 is not possible.

Klaus

PS: This information is from the Cisco website - maybe its out-dated.

Post by Steven E. Ames
Hey. I'm hitting a bit of a snag. The solution should be fairly obvious but I'm not seeing it. I'm running a little test using a Cisco 2651XM (IOS 12.2.13(T8)). Here's the scenario.
dial-peer voice 50 voip
application session
incoming called-number 001.T
session protocol sipv2
session target sip-server
fax rate disable
no vad
dial-peer voice 5 pots
application session
destination-pattern 001.T
port 1/0:23
And all is good with the world... now we have an H.323 gatekeeper and I use this same Cisco box as a PSTN gateway for the H.323 phones. That also works just fine. I have no problem at all calling from SIP<->TDM or H.323<->TDM. However... what I'd like to do is have incoming SIP calls delivered directly to H.323 phones (via gatekeeper and RAS).
dial-peer voice 5 voip
application session
destination-pattern 001.T
session target ras
1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad but if someone can say its so and maybe point out options?
2. ras is attempting to match 001T instead of just T (e.g. 0012125551212 instead of 2125551212)? I'm under the, potentially mistaken, impression that a destination-patter of 001.T will strip the 001. So maybe RAS just isn't matching.
num-exp 0012125551212 2125551212
and changing destination-pattern to '2125551212' doesn't help at all.
SIP -> CISCO -> TDM -> CISCO -> H.323 works
SIP -> CISCO -> H.323 doesn't work
Help?
-Steve
------------------------------------------------------------------------
_______________________________________________
cisco-voip mailing list
https://puck.nether.net/mailman/listinfo/cisco-voip

[Walenta, Phil]

Cisco gateways actually can allow re-termination of H.323 calls to another H.323 leg. It's the IP Gateway to IP Gateway feature.

________________________________

From: cisco-voip-***@puck.nether.net on behalf of Klaus Darilion
Sent: Wed 9/1/2004 5:36 PM
To: Steven E. Ames
Cc: cisco-***@puck.nether.net
Subject: Re: [cisco-voip] Gatewaying between SIP and H.323



ASFAIK this is not supported. The feaure is called "hairpin of media"
and means that the call leaves the GW on the "same side" it is received
eg: PSTN - PSTN or VoIP - VoIP.

hairpin of media is supported on the POTS side, but not on the VoIP
side. Therefore SIP-H323 is not possible.

Klaus

PS: This information is from the Cisco website - maybe its out-dated.

Post by Steven E. Ames
Hey. I'm hitting a bit of a snag. The solution should be fairly obvious but I'm not seeing it. I'm running a little test using a Cisco 2651XM (IOS 12.2.13(T8)). Here's the scenario.
dial-peer voice 50 voip
application session
incoming called-number 001.T
session protocol sipv2
session target sip-server
fax rate disable
no vad
dial-peer voice 5 pots
application session
destination-pattern 001.T
port 1/0:23
And all is good with the world... now we have an H.323 gatekeeper and I use this same Cisco box as a PSTN gateway for the H.323 phones. That also works just fine. I have no problem at all calling from SIP<->TDM or H.323<->TDM. However... what I'd like to do is have incoming SIP calls delivered directly to H.323 phones (via gatekeeper and RAS).
dial-peer voice 5 voip
application session
destination-pattern 001.T
session target ras
1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad but if someone can say its so and maybe point out options?
2. ras is attempting to match 001T instead of just T (e.g. 0012125551212 instead of 2125551212)? I'm under the, potentially mistaken, impression that a destination-patter of 001.T will strip the 001. So maybe RAS just isn't matching.
num-exp 0012125551212 2125551212
and changing destination-pattern to '2125551212' doesn't help at all.
SIP -> CISCO -> TDM -> CISCO -> H.323 works
SIP -> CISCO -> H.323 doesn't work
Help?
-Steve
------------------------------------------------------------------------
_______________________________________________
cisco-voip mailing list
https://puck.nether.net/mailman/listinfo/cisco-voip

[Steve Ames]

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

Post by Walenta, Phil
Cisco gateways actually can allow re-termination of H.323 calls to another

H.323 leg. It's the IP Gateway to IP Gateway feature.

__Yah. Saw that on their site. Also saw reference to SIP support for
IP-IP Gateway in 2004 (and its 8 months through 2004 already). Is
this the only way to gateway between SIP and H.323? I'm bummed that
the obvious solution didn't just work... Thoughts? Will happily
take product recommendations as well. I'd really like to get this
going with something more scalable than HDV/PRI cards (not to
mention the voice quality is pretty ugly when you do that many
conversions (PSTN->SIP->PSTN->H323). Ick.

-Steve
______________________________

From: cisco-voip-***@puck.nether.net on behalf of Klaus Darilion
Sent: Wed 9/1/2004 5:36 PM
To: Steven E. Ames
Cc: cisco-***@puck.nether.net
Subject: Re: [cisco-voip] Gatewaying between SIP and H.323



ASFAIK this is not supported. The feaure is called "hairpin of media"
and means that the call leaves the GW on the "same side" it is received
eg: PSTN - PSTN or VoIP - VoIP.

hairpin of media is supported on the POTS side, but not on the VoIP
side. Therefore SIP-H323 is not possible.

Klaus

PS: This information is from the Cisco website - maybe its out-dated.

Post by Walenta, Phil
Hey. I'm hitting a bit of a snag. The solution should be fairly obvious

but I'm not seeing it. I'm running a little test using a Cisco 2651XM (IOS
12.2.13(T8)). Here's the scenario.

Post by Walenta, Phil
A lot of SIP calls come into this box. All of the calls are prefixed 001
dial-peer voice 50 voip
application session
incoming called-number 001.T
session protocol sipv2
session target sip-server
fax rate disable
no vad
dial-peer voice 5 pots
application session
destination-pattern 001.T
port 1/0:23
And all is good with the world... now we have an H.323 gatekeeper and I

use this same Cisco box as a PSTN gateway for the H.323 phones. That also
works just fine. I have no problem at all calling from SIP<->TDM or
H.323<->TDM. However... what I'd like to do is have incoming SIP calls
delivered directly to H.323 phones (via gatekeeper and RAS).

Post by Walenta, Phil
dial-peer voice 5 voip
application session
destination-pattern 001.T
session target ras
But that fails quite miserably. The dial-peer is matched but that's the
1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad

but if someone can say its so and maybe point out options?

Post by Walenta, Phil
2. ras is attempting to match 001T instead of just T (e.g. 0012125551212

instead of 2125551212)? I'm under the, potentially mistaken, impression that
a destination-patter of 001.T will strip the 001. So maybe RAS just isn't
matching.

Post by Walenta, Phil
num-exp 0012125551212 2125551212
and changing destination-pattern to '2125551212' doesn't help at all.
The closest I've come to getting this to work is routing the SIP call to
SIP -> CISCO -> TDM -> CISCO -> H.323 works
SIP -> CISCO -> H.323 doesn't work
Help?
-Steve
------------------------------------------------------------------------
_______________________________________________
cisco-voip mailing list
https://puck.nether.net/mailman/listinfo/cisco-voip

[Anthony Baxter]

Post by Walenta, Phil
Cisco gateways actually can allow re-termination of H.323 calls to another H.323 leg.
It's the IP Gateway to IP Gateway feature.

There's a few things to be aware of, though:

- H.323 to SIP doesn't pass on out-of-band DTMF correctly
- in a Tcl app, you can't use an inbound voip leg in a leg setup
that creates an outbound voip leg (you'll get an ls_009). You
can create the outbound voip leg without an inbound leg, then
manually do a "connection create" to join the legs, but in that
case, the outbound leg will have a different GUID/h323-conf-id
than the inbound leg - most annoying.

[Blaz Zupan]

Post by Steven E. Ames
1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad but if someone can say its so and maybe point out options?

Your first assumption is correct. Most IOS versions can not bridge a VoIP call
to a VoIP call, they can only bridge a VoIP call to a TDM call.

Some versions allow the following setup:

voice service voip
allow-connections h323 to h323

I'm not sure it's possible to bridge SIP to H.323 (and vice versa) at all. The
feature above is present in 12.3T (enterprise feature set only unfortunately).
For example the following image does have it: c2600-js2-mz.123-8.T.bin. I
believe the feature is called "Multiservice IP-to-IP Gateway with media
flow-around". The Feature Navigator at http://www.cisco.com/go/fn/ should be
able to find it. Other than that, I don't think IOS can do what you want
(bridge a H.323 call to a SIP call).

[Anthony Baxter]

Post by Blaz Zupan

Post by Steven E. Ames
1. I can't gateway SIP to H.323 with my hardware/IOS. This would be sad but if someone can say its so and maybe point out options?

Your first assumption is correct. Most IOS versions can not bridge a VoIP call
to a VoIP call, they can only bridge a VoIP call to a TDM call.

See my previous email - it _is_ possible using a Tcl script, with the
caveats that I listed in that email. This works in 12.3(9a) at least
(the IP PLUS version), on AS5300 and AS5400s.

Anthony

[Nicolas RUIZ]

Hi,



I have a problem with a softphone XPRO(Xten).



With a Cisco IP phone 7940, when I make a call by the gateway CISCO AS5300
to the PSTN I have no error.

But when I make a call with a softphone, a ack is not send, why ????



That's the debug ccsip on the AS5300 of the IP PHONE : OK



*Sep 2 11:17:25.655: Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 80.118.128.5;branch=z9hG4bK8e2f.a6ab8803.0,SIP/2.0/UDP
62.39.70.245:20105;branch=z9hG4bK31371211

From: "ip.phone"
<sip:***@sip.vivaction.net>;tag=000f8f58915f00290135943b-29b8dfce

To: <sip:***@sip.vivaction.net>;tag=E3A5A78-9A6

Date: Thu, 02 Sep 2004 11:17:23 GMT

Call-ID: 000f8f58-915f0022-7185bdb3-***@192.168.254.12

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 102 INVITE

Allow-Events: telephone-event

Contact: <sip:***@80.118.128.1:5060>

Record-Route:
<sip:***@80.118.128.5;ftag=000f8f58915f00290135943b-29b8dfce;lr=on>

Content-Length: 0





*Sep 2 11:17:33.811: Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 80.118.128.5;branch=z9hG4bK8e2f.a6ab8803.0,SIP/2.0/UDP
62.39.70.245:20105;branch=z9hG4bK31371211

From: "ip.phone"
<sip:***@sip.vivaction.net>;tag=000f8f58915f00290135943b-29b8dfce

To: <sip:***@sip.vivaction.net>;tag=E3A5A78-9A6

Date: Thu, 02 Sep 2004 11:17:23 GMT

Call-ID: 000f8f58-915f0022-7185bdb3-***@192.168.254.12

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 102 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, INFO

Allow-Events: telephone-event

Contact: <sip:***@80.118.128.1:5060>

Record-Route:
<sip:***@80.118.128.5;ftag=000f8f58915f00290135943b-29b8dfce;lr=on>

Content-Type: application/sdp

Content-Length: 256



v=0

o=CiscoSystemsSIP-GW-UserAgent 4767 74 IN IP4 80.118.128.1

s=SIP Call

c=IN IP4 80.118.128.1

t=0 0

m=audio 19090 RTP/AVP 18 101

c=IN IP4 80.118.128.1

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15



*Sep 2 11:17:34.007: Received:

ACK sip:***@80.118.128.1:5060 SIP/2.0

Max-Forwards: 10

Record-Route:
<sip:***@80.118.128.5;ftag=000f8f58915f00290135943b-29b8dfce;lr=on>

Via: SIP/2.0/UDP 80.118.128.5;branch=0

Via: SIP/2.0/UDP 62.39.70.245:20105;branch=z9hG4bK740c6ffc

From: "ip.phone"
<sip:***@sip.vivaction.net>;tag=000f8f58915f00290135943b-29b8dfce

To: <sip:***@sip.vivaction.net>;tag=E3A5A78-9A6

Call-ID: 000f8f58-915f0022-7185bdb3-***@192.168.254.12

CSeq: 102 ACK

User-Agent: CSCO/6

Content-Length: 0





That's the debug ccsip on the AS5300 of the SOFT PHONE: NOT OK



*Sep 2 11:18:45.223: Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 80.118.128.5;branch=z9hG4bK6ba.fcdca5f4.0,SIP/2.0/UDP
62.39.69.2:46

From: Nicolas RUIZ <sip:***@sip.vivaction.net>;tag=1067362397

To: <sip:***@sip.vivaction.net>;tag=E3B9238-318

Date: Thu, 02 Sep 2004 11:18:43 GMT

Call-ID: 057CD701-2D04-4139-A09B-***@192.168.18.21

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 44500 INVITE

Allow-Events: telephone-event

Contact: <sip:***@80.118.128.1:5060>

Record-Route: <sip:***@80.118.128.5;ftag=1067362397;lr=on>

Content-Length: 0





*Sep 2 11:18:49.547: Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 80.118.128.5;branch=z9hG4bK6ba.fcdca5f4.0,SIP/2.0/UDP
62.39.69.2:46

From: Nicolas RUIZ <sip:***@sip.vivaction.net>;tag=1067362397

To: <sip:***@sip.vivaction.net>;tag=E3B9238-318

Date: Thu, 02 Sep 2004 11:18:43 GMT

Call-ID: 057CD701-2D04-4139-A09B-***@192.168.18.21

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 44500 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, IN

Allow-Events: telephone-event

Contact: <sip:***@80.118.128.1:5060>

Record-Route: <sip:***@80.118.128.5;ftag=1067362397;lr=on>

Content-Type: application/sdp

Content-Length: 258



v=0

o=CiscoSystemsSIP-GW-UserAgent 5184 6584 IN IP4 80.118.128.1

s=SIP Call

c=IN IP4 80.118.128.1

t=0 0

m=audio 19414 RTP/AVP 18 101

c=IN IP4 80.118.128.1

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15



*Sep 2 11:18:50.047: Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 80.118.128.5;branch=z9hG4bK6ba.fcdca5f4.0,SIP/2.0/UDP
62.39.69.2:46

From: Nicolas RUIZ <sip:***@sip.vivaction.net>;tag=1067362397

To: <sip:***@sip.vivaction.net>;tag=E3B9238-318

Date: Thu, 02 Sep 2004 11:18:43 GMT

Call-ID: 057CD701-2D04-4139-A09B-***@192.168.18.21

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 44500 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, IN

Allow-Events: telephone-event

Contact: <sip:***@80.118.128.1:5060>

Record-Route: <sip:***@80.118.128.5;ftag=1067362397;lr=on>

Content-Type: application/sdp

Content-Length: 258



v=0

o=CiscoSystemsSIP-GW-UserAgent 5184 6584 IN IP4 80.118.128.1

s=SIP Call

c=IN IP4 80.118.128.1

t=0 0

m=audio 19414 RTP/AVP 18 101

c=IN IP4 80.118.128.1

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

[Nicolas RUIZ]

HI,

I progress in my problem, I see the error, I think my IP-phone work in
StateFull proxy and the soft phone work in StateLess Proxy.

I explain:

That's the debug of the ip-phone and the softphone on my proxy-registrar SIP
iptel open source project.

When the ip-phone reply the ACK to the proxy, he put the IP of the proxy and
when the soft phone reply the ACK, he put the IP of the GATEWAY CISCO!!!!
WHY????

Thanks for your help

Nicolas RUIZ

-----Message d'origine-----
De : Anthony Baxter [mailto:***@interlink.com.au]
Envoyé : jeudi 2 septembre 2004 13:29
À : Nicolas RUIZ
Objet : Re: [cisco-voip] AS5300 : problem with a softphone

Look at the debugging on the XTen softphone, find out why it didn't like
the cisco's response. At the very least, you need to get _both_ sides of
the SIP, not just the cisco's side.

[Klaus Darilion]

xten uses "loose-routing" (RFC3261) whereas the ip-phone uses
"strict-routing". You have to have a loose_route(); block in your
ser.cfg to proper route the messages from strict routers.

klaus

Post by Nicolas RUIZ
HI,
I progress in my problem, I see the error, I think my IP-phone work in
StateFull proxy and the soft phone work in StateLess Proxy.
That's the debug of the ip-phone and the softphone on my proxy-registrar SIP
iptel open source project.
When the ip-phone reply the ACK to the proxy, he put the IP of the proxy and
when the soft phone reply the ACK, he put the IP of the GATEWAY CISCO!!!!
WHY????
Thanks for your help
Nicolas RUIZ
-----Message d'origine-----
Envoyé : jeudi 2 septembre 2004 13:29
À : Nicolas RUIZ
Objet : Re: [cisco-voip] AS5300 : problem with a softphone
Look at the debugging on the XTen softphone, find out why it didn't like
the cisco's response. At the very least, you need to get _both_ sides of
the SIP, not just the cisco's side.
------------------------------------------------------------------------
_______________________________________________
cisco-voip mailing list
https://puck.nether.net/mailman/listinfo/cisco-voip