[cisco-voip] router to router (SCCP/h323 to SIP) calls don't work in SRST
Lelio Fulgenzi
lelio at uoguelph.ca
Sat Mar 27 20:07:48 EDT 2010
Thanks again Nick. This is great information. I'm gonna have to read and digest.
---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
- LFJ (with apologies to Mr. Popeil)
----- Original Message -----
From: "Nick Matthews" <matthnick at gmail.com>
To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
Cc: "cisco-voip voyp list" <cisco-voip at puck.nether.net>
Sent: Saturday, March 27, 2010 5:18:43 PM GMT -05:00 US/Canada Eastern
Subject: Re: [cisco-voip] router to router (SCCP/h323 to SIP) calls don't work in SRST
You could do it two different ways:
Pass everything to the other router, let it deal with the details.
This would require for you to use g711 for all calls, or configure a
transcoder on the remote router since CUE doesn't support g729. DTMF
relay is fairly inconsequential as long as it matches on both ends.
Under ccn subsystem sip on the CUE you can change the DTMF method, and
I usually feel better about the config if the trunking side DTMF
matches the CUE DTMF.
Make a specific dial peer for CUE directly from router A. You could
use g729 for all voice calls if its a concern, and just g711 for CUE
without the necessity of a transcoder - unless calls are transferred
between router A/B to CUE (likely). You can configure the DTMF
setting directly from the router A dial peer to CUE, and it would be
SIP. I believe there may be problems with SRST A sending calls to CUE
B because CUE B will assume that SRST A is SRST B. Not 100% on that,
but I seem to remember some problems from doing that (especially if
there are overlapping extensions).
I would say best practices are:
-Configure SIP between the two routers. This simplifies the transfer to CUE.
-Configure a transcoder on both routers (if they both have CUE,
otherwise just the router with CUE) if you're going to use g729.
-If you don't configure a transcoder, use g711.
-Try to have dtmf methods match between your SRST trunk and CUE. For
h323-sip your option is rtp-nte.
-Point your dial peer for SRST A to CUE B to SRST B and make sure the
correct allow-connections is configured.
In general, yes you will agree on a dtmf and codec type, just like
with SIP trunks. The alternative is to configure a voice-class codec
with all the options you could expect, and to do debugging to
determine the DTMF method in use.
-nick
On Sat, Mar 27, 2010 at 4:40 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
> Thanks Nick. There were four things I needed to do to make things work (got
> some help from the forums):
>
> allow h323 to sip connections
> add the codec on the inbound call leg
> add the codec on the outbound call leg
> add the dtmf-relay on the outbound call leg
>
> I'm totally on-board for making any changes on the terminating router, but I
> am curious about making the changes on the originating router.
>
> Let's say the two routers belonged to different organizations...is it normal
> for this type of information to be passed pre-configuration, i.e. what codec
> and dtmf relay is needed?
>
> I'm also wondering what I might be breaking with the "dtmf-relay" command.
> And what I might break if I add other commands. For example, modem
> passthrough.
>
> I'm guessing I might have to make a more specific outbound dial-peer for
> just those 3 unity express ports on the other router.
>
> ________________________________
> on the terminating router:
>
> !
> voice service voip
> allow-connections h323 to sip
> !
> dial-peer voice 11112 voip
> codec g711ulaw
> plus normal stuff
> !
>
> ________________________________
> on the originating router:
>
> !
> dial-peer voice 11111 voip
> plus normal stuff
> dtmf-relay h245-alphanumeric
> codec g711ulaw
> !
> ________________________________
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it.
> - LFJ (with apologies to Mr. Popeil)
>
>
> ----- Original Message -----
> From: "Nick Matthews" <matthnick at gmail.com>
> To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
> Cc: "cisco-voip voyp list" <cisco-voip at puck.nether.net>
> Sent: Saturday, March 27, 2010 4:15:10 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [cisco-voip] router to router (SCCP/h323 to SIP) calls don't
> work in SRST
>
> Technically you should be able to point it at the other CME, and that
> is what I would do. Make sure on router B you have the proper
> incoming dial peer, outgoing dial peer, and that you have
> allow-connections for h323-to-sip, etc.
>
> -nick
>
> On Fri, Mar 26, 2010 at 10:16 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>> ok, after some more reading, it looks like the default inbound dial peer
>> won't work with SIP calls.
>>
>> which makes more sense, the configuration should really happen on the
>> terminating router, not the originating router.
>>
>> thanks to Ed for some pointers.
>>
>> ---
>> Lelio Fulgenzi, B.A.
>> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
>> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Cooking with unix is easy. You just sed it and forget it.
>> - LFJ (with apologies to Mr. Popeil)
>>
>>
>> ----- Original Message -----
>> From: "Lelio Fulgenzi" <lelio at uoguelph.ca>
>> To: "cisco-voip voyp list" <cisco-voip at puck.nether.net>
>> Sent: Friday, March 26, 2010 7:59:55 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: [cisco-voip] router to router (SCCP/h323 to SIP) calls don't
>> work in SRST
>>
>> ya know, I think I just answered my own question after sending this
>> off....
>>
>> i'm guessing I need a more specific dial-peer on the far end router which
>> more closely matches the dial-peer on local router.
>>
>> so, something like this? the question is, can i use the router address or
>> should i use the CUE ip address?
>>
>> hmmm, something to try later
>>
>> ________________________________
>> Router A:
>> !
>> dial-peer voice 37063 voip
>> description Cisco Unity Express AutoAttendant (Default)
>> destination-pattern 37063
>> session protocol sipv2
>> session target ipv4:10.104.13.66
>> dtmf-relay sip-notify
>> codec g711ulaw
>> no vad
>> !
>> dial-peer voice 11111 voip
>> description Wild Card to vgw-jnhn-b
>> destination-pattern [1234567]....
>> session target ipv4:10.104.13.202
>> !
>> dial-peer voice 37000 voip
>> description SIP Wild Card to vgw-jnhn-b
>> destination-pattern 37...
>> session protocol sipv2
>> session target ipv4:10.104.13.202 (OR CUE IP address?)
>> dtmf-relay sip-notify
>> codec g711ulaw
>> no vad
>> !
>> ________________________________
>>
>>
>> ----- Original Message -----
>> From: "Lelio Fulgenzi" <lelio at uoguelph.ca>
>> To: "cisco-voip voyp list" <cisco-voip at puck.nether.net>
>> Sent: Friday, March 26, 2010 7:53:10 PM GMT -05:00 US/Canada Eastern
>> Subject: [cisco-voip] router to router (SCCP/h323 to SIP) calls don't work
>> in SRST
>>
>> Does anyone know if there is anything special you have to do to make calls
>> from an SCCP phone on one SRST router to a SIP endpoint on another SRST
>> router work?
>>
>> Here's what I have and can do:
>>
>> two routers in SRST mode
>> all phones register properly, some to one router, some to another
>> I can make a call from phone A on router A to phone B on router B (and
>> vice
>> versa)
>> I can make a call from phone A on router A to Unity Express A on router A
>> and be transferred to phone B on router B
>>
>> I can NOT place a call from phone A on router A to Unity Express B on
>> router
>> B.
>>
>> I'm pretty sure Router B is getting the call, because a "debug voice
>> dialpeer all" started spewing out stuff on Router B like it was going out
>> of
>> style. It even showed matches. I can post the full debug next week, but
>> just
>> thought there would be a quick(?) answer.
>>
>> I think these are the relevant configs, but will post more if needed:
>>
>> ________________________________
>> Router A:
>> !
>> dial-peer voice 37063 voip
>> description Cisco Unity Express AutoAttendant (Default)
>> destination-pattern 37063
>> session protocol sipv2
>> session target ipv4:10.104.13.66
>> dtmf-relay sip-notify
>> codec g711ulaw
>> no vad
>> !
>> dial-peer voice 11111 voip
>> description Wild Card to vgw-jnhn-b
>> destination-pattern [1234567]....
>> session target ipv4:10.104.13.202
>> !
>> ________________________________
>> Router B:
>> !
>> dial-peer voice 37073 voip
>> description Cisco Unity Express AutoAttendant (Default)
>> destination-pattern 37073
>> session protocol sipv2
>> session target ipv4:10.104.13.70
>> dtmf-relay sip-notify
>> codec g711ulaw
>> no vad
>> !
>> dial-peer voice 11111 voip
>> description Wild Card to vgw-jnhn-a
>> destination-pattern [1234567]....
>> session target ipv4:10.104.13.201
>> !
>> ________________________________
>>
>>
>>
>>
>> ---
>> Lelio Fulgenzi, B.A.
>> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
>> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Cooking with unix is easy. You just sed it and forget it.
>> - LFJ (with apologies to Mr. Popeil)
>>
>>
>> _______________________________________________ cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> _______________________________________________ cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100327/fddc2dae/attachment.html>
More information about the cisco-voip
mailing list