hi guys, need a bit of help... have never touched an acme before so i'm not sure what to tell the people i am dealing with, and they seem incapable of resolving the problem themselves. trying to explain the difference between layer 3 and layer 7 is not working. setup: i have an ip pbx with a single interface at 10.0.1.80, and a netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg is off). my itsp has an acme at 2.2.2.2. this is what an inbound call looks like right now: 2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1 <sip%3Axxxxxx at 1.1.1.1> 10.0.1.80 -> 2.2.2.2 100 trying 10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80<sip%3Axxxxxx at 10.0.1.80> ) 2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80 <sip%3Axxxxxx at 10.0.1.80> so obviously it breaks at this point. according to them, they are unable to configure the acme to respond to the originating routable ip instead of the nonroutable ip in the sip contact. this is what someone at acme told them: It?s not a configuration issue, the endpoint at 1.1.1.1 has set it?s contact header address to 10.0.1.80 in it?s 200 OK response back to 2.2.2.2 (SBC). The SD will look at the Contact header in order to determine where to send future in-dialog requests such as ACK, BYE, Re-INVITEs etc (according to RFC3261). Please can you check why 1.1.1.1 would be doing so? this sounds irrelevant to me, since any sip endpoint will set its contact header address to its own ip. sounds like this guy is saying "well it's natted so that won't work, tell them to fix it." i certainly can't configure my pbx to respond with a modified contact header. can anyone provide some guidance here? or maybe i am just wrong and it is impossible to make this work. but it looks like a basic hnt situation to me. thanks, milosz
Have you tried turning ON the SIP ALG on the NS? This should fix the contact header as it gets NATed on the way out. The Acme should be able to handle the NAT, we do that every day, but everything on the Acme has to be set up for that, and they may not support NAT traversal by choice. To troubleshoot why theirs isn't would require seeing the configuration and looking at any manipulations they have in place on the relevant SIP Interfaces, realms, and local-policies. In my opinion, you are better off NOT depending on the provider's Acme to handle the traversal for you. It can work well with one phone at a remote site, but for a whole PBX you are probably better off using the ALG in your Netscreen or getting a SIP proxy for your end like a SIPerator or Edgemarc. Also what would you do if the provider told you flat out they don't support NAT traversal? If all that fails you could always put a public on the PBX, assuming the PBX vendor has the ability to secure itself. -Scott From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of milosz Sent: Friday, October 02, 2009 7:09 PM To: VoiceOps Subject: [VoiceOps] acme nat traversal clue hi guys, need a bit of help... have never touched an acme before so i'm not sure what to tell the people i am dealing with, and they seem incapable of resolving the problem themselves. trying to explain the difference between layer 3 and layer 7 is not working. setup: i have an ip pbx with a single interface at 10.0.1.80, and a netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg is off). my itsp has an acme at 2.2.2.2. this is what an inbound call looks like right now: 2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1 <mailto:sip%3Axxxxxx at 1.1.1.1> 10.0.1.80 -> 2.2.2.2 100 trying 10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80 <mailto:sip%3Axxxxxx at 10.0.1.80> ) 2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80 <mailto:sip%3Axxxxxx at 10.0.1.80> so obviously it breaks at this point. according to them, they are unable to configure the acme to respond to the originating routable ip instead of the nonroutable ip in the sip contact. this is what someone at acme told them: It's not a configuration issue, the endpoint at 1.1.1.1 has set it's contact header address to 10.0.1.80 in it's 200 OK response back to 2.2.2.2 (SBC). The SD will look at the Contact header in order to determine where to send future in-dialog requests such as ACK, BYE, Re-INVITEs etc (according to RFC3261). Please can you check why 1.1.1.1 would be doing so? this sounds irrelevant to me, since any sip endpoint will set its contact header address to its own ip. sounds like this guy is saying "well it's natted so that won't work, tell them to fix it." i certainly can't configure my pbx to respond with a modified contact header. can anyone provide some guidance here? or maybe i am just wrong and it is impossible to make this work. but it looks like a basic hnt situation to me. thanks, milosz
OpenSER + media proxy (not necessarily mandatory, depending on the situation) for far-end NAT traversal is also a viable option here, depending on the precise requirements. Scott Berkman wrote:
Have you tried turning ON the SIP ALG on the NS? This should fix the contact header as it gets NATed on the way out.
The Acme should be able to handle the NAT, we do that every day, but everything on the Acme has to be set up for that, and they may not support NAT traversal by choice. To troubleshoot why theirs isn?t would require seeing the configuration and looking at any manipulations they have in place on the relevant SIP Interfaces, realms, and local-policies.
In my opinion, you are better off NOT depending on the provider?s Acme to handle the traversal for you. It can work well with one phone at a remote site, but for a whole PBX you are probably better off using the ALG in your Netscreen or getting a SIP proxy for your end like a SIPerator or Edgemarc. Also what would you do if the provider told you flat out they don?t support NAT traversal? If all that fails you could always put a public on the PBX, assuming the PBX vendor has the ability to secure itself.
-Scott
*From:* voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *milosz *Sent:* Friday, October 02, 2009 7:09 PM *To:* VoiceOps *Subject:* [VoiceOps] acme nat traversal clue
hi guys,
need a bit of help... have never touched an acme before so i'm not sure what to tell the people i am dealing with, and they seem incapable of resolving the problem themselves. trying to explain the difference between layer 3 and layer 7 is not working.
setup: i have an ip pbx with a single interface at 10.0.1.80, and a netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg is off). my itsp has an acme at 2.2.2.2.
this is what an inbound call looks like right now:
2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1 <mailto:sip%3Axxxxxx at 1.1.1.1> 10.0.1.80 -> 2.2.2.2 100 trying 10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80 <mailto:sip%3Axxxxxx at 10.0.1.80>) 2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80 <mailto:sip%3Axxxxxx at 10.0.1.80>
so obviously it breaks at this point.
according to them, they are unable to configure the acme to respond to the originating routable ip instead of the nonroutable ip in the sip contact.
this is what someone at acme told them:
It?s not a configuration issue, the endpoint at 1.1.1.1 has set it?s contact header address to 10.0.1.80 in it?s 200 OK response back to 2.2.2.2 (SBC). The SD will look at the Contact header in order to determine where to send future in-dialog requests such as ACK, BYE, Re-INVITEs etc (according to RFC3261). Please can you check why 1.1.1.1 would be doing so?
this sounds irrelevant to me, since any sip endpoint will set its contact header address to its own ip. sounds like this guy is saying "well it's natted so that won't work, tell them to fix it." i certainly can't configure my pbx to respond with a modified contact header.
can anyone provide some guidance here? or maybe i am just wrong and it is impossible to make this work. but it looks like a basic hnt situation to me.
thanks,
milosz
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Have you tried turning ON the SIP ALG on the NS?? This should fix the contact header as it gets NATed on the way out.
the sip alg on the netscreen is weak and pretty much only ever breaks things. naturally i did try turning it on =)
The Acme should be able to handle the NAT, we do that every day, but everything on the Acme has to be set up for that, and they may not support NAT traversal by choice.
sure. according to them, though, they -do- support nat traversal and they have "many customers already using it."
In my opinion, you are better off NOT depending on the provider?s Acme to handle the traversal for you.? It can work well with one phone at a remote site, but for a whole PBX you are probably better off using the ALG in your Netscreen or? getting a SIP proxy for your end like a SIPerator or Edgemarc. Also what would you do if the provider told you flat out they don?t support NAT traversal? ?If all that fails you could always put a public on the PBX, assuming the PBX vendor has the ability to secure itself.
i am aware of these options, unfortunately they are cost-prohibitive at the moment. i have no problem throwing a public ip on the pbx, since it would be behind the netscreen anyhow, but adding another interface to this particular ippbx, or even changing the ip address, is a serious undertaking. fair enough about being better off not depending on their nat traversal. i have around 500 endpoints behind the pbx, and if people agree that it's generally better for me to handle my own traversal then, at least for production, that is what i'll do. so, for a general case, assuming that the engineers on the other end have a clue, is it somehow less reliable for me to depend on hosted nat traversal for an ippbx with several hundred endpoints? are there limitations i am not aware of? anyone have any insight on which of the openser forks is superior/superior for nat traversal use? milosz
Assuming the SD is configured to do NAT traversal, my guess would be that the ALG on the fire wall is not completely off. In such case ACME would think that some other device is addressing the NAT traversal issue and would register the user agent as a non HNT device. Checking the registration on the SD would confirm whether my guess is true or not. Run the command: "show registration sipd by-user <endpoint> detail If you see a line including "acme_nat=......." Under "User Agent Info:", it means that the endpoint registered as an HNT device. Good luck, Brad From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of milosz Sent: Friday, October 02, 2009 4:09 PM To: VoiceOps Subject: [VoiceOps] acme nat traversal clue hi guys, need a bit of help... have never touched an acme before so i'm not sure what to tell the people i am dealing with, and they seem incapable of resolving the problem themselves. trying to explain the difference between layer 3 and layer 7 is not working. setup: i have an ip pbx with a single interface at 10.0.1.80, and a netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg is off). my itsp has an acme at 2.2.2.2. this is what an inbound call looks like right now: 2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1<mailto:sip%3Axxxxxx at 1.1.1.1> 10.0.1.80 -> 2.2.2.2 100 trying 10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80<mailto:sip%3Axxxxxx at 10.0.1.80>) 2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80<mailto:sip%3Axxxxxx at 10.0.1.80> so obviously it breaks at this point. according to them, they are unable to configure the acme to respond to the originating routable ip instead of the nonroutable ip in the sip contact. this is what someone at acme told them: It's not a configuration issue, the endpoint at 1.1.1.1 has set it's contact header address to 10.0.1.80 in it's 200 OK response back to 2.2.2.2 (SBC). The SD will look at the Contact header in order to determine where to send future in-dialog requests such as ACK, BYE, Re-INVITEs etc (according to RFC3261). Please can you check why 1.1.1.1 would be doing so? this sounds irrelevant to me, since any sip endpoint will set its contact header address to its own ip. sounds like this guy is saying "well it's natted so that won't work, tell them to fix it." i certainly can't configure my pbx to respond with a modified contact header. can anyone provide some guidance here? or maybe i am just wrong and it is impossible to make this work. but it looks like a basic hnt situation to me. thanks, milosz
Acme HNT only applies when the endpoint is registered, does your PBX register to the ITSP? If not you will need to find another way around NAT on your end. Judging by what you are telling us with the invite being sent to sip:xxxxxx at 1.1.1.1 it sounds like you arent registered and instead it is a session agent configured in the SD to correspond to you. If this is indeed the case you will need to find a way around this on your end, As Alex suggested OpenSER + Media Proxy will work quite well, though a smaller and easier solution might be buying something like an Edgemarc from Edgewater networks for your end and put it in front of the netscreen in a proxy-arp config, so the edgemarc will take ownership of the WAN connection and provide a 100% working ALG. Hope this helps On Fri, 2009-10-02 at 19:08 -0400, milosz wrote:
hi guys,
need a bit of help... have never touched an acme before so i'm not sure what to tell the people i am dealing with, and they seem incapable of resolving the problem themselves. trying to explain the difference between layer 3 and layer 7 is not working.
setup: i have an ip pbx with a single interface at 10.0.1.80, and a netscreen 50 with a static routable ip natted to the pbx at 1.1.1.1 (sip alg is off). my itsp has an acme at 2.2.2.2.
this is what an inbound call looks like right now:
2.2.2.2 -> 1.1.1.1 invite sip:xxxxxx at 1.1.1.1 10.0.1.80 -> 2.2.2.2 100 trying 10.0.1.80 -> 2.2.2.2 200 ok (contact: sip:xxxxxx at 10.0.1.80) 2.2.2.2 -> 10.0.1.80 ack sip:xxxxxx at 10.0.1.80
so obviously it breaks at this point.
according to them, they are unable to configure the acme to respond to the originating routable ip instead of the nonroutable ip in the sip contact.
this is what someone at acme told them:
It?s not a configuration issue, the endpoint at 1.1.1.1 has set it?s contact header address to 10.0.1.80 in it?s 200 OK response back to 2.2.2.2 (SBC). The SD will look at the Contact header in order to determine where to send future in-dialog requests such as ACK, BYE, Re-INVITEs etc (according to RFC3261). Please can you check why 1.1.1.1 would be doing so?
this sounds irrelevant to me, since any sip endpoint will set its contact header address to its own ip. sounds like this guy is saying "well it's natted so that won't work, tell them to fix it." i certainly can't configure my pbx to respond with a modified contact header.
can anyone provide some guidance here? or maybe i am just wrong and it is impossible to make this work. but it looks like a basic hnt situation to me.
thanks,
milosz
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Hi, I am interested in taking the CCVP and was wondering in what order should the tests be taken? I am also taking all the 5 classes. I have an expired CCNA :-) CIPT1, CIPT2, QoS, CVOICE and TUC Any advise, recommendations will be very much appreciated. Thanks,
You have to pass CCENT before you can earn the CCNA Voice, and you must have the CCNA Voice before you can earn the CCVP. I would recommend the following order for the CCVP. QoS CVOICE CIPT1 CIPT2 Troubleshooting (TUC) On Oct 7, 2009, at 8:08 AM, <Rod.Dossouvi.CTR at dot.gov> <Rod.Dossouvi.CTR at dot.gov
wrote:
Hi, I am interested in taking the CCVP and was wondering in what order should the tests be taken?
I am also taking all the 5 classes. I have an expired CCNA :-)
CIPT1, CIPT2, QoS, CVOICE and TUC
Any advise, recommendations will be very much appreciated.
Thanks, _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Shouldn't I be able to just take 642-436 CVOICE 6.0 to start off? ________________________________ From: Mark Holloway [mailto:mh at markholloway.com] Sent: Wednesday, October 07, 2009 11:38 AM To: Dossouvi, Rod CTR (FHWA) Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] CCVP tests order You have to pass CCENT before you can earn the CCNA Voice, and you must have the CCNA Voice before you can earn the CCVP. I would recommend the following order for the CCVP. QoS CVOICE CIPT1 CIPT2 Troubleshooting (TUC) On Oct 7, 2009, at 8:08 AM, <Rod.Dossouvi.CTR at dot.gov> <Rod.Dossouvi.CTR at dot.gov> wrote: Hi, I am interested in taking the CCVP and was wondering in what order should the tests be taken? I am also taking all the 5 classes. I have an expired CCNA :-) CIPT1, CIPT2, QoS, CVOICE and TUC Any advise, recommendations will be very much appreciated. Thanks, _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Rod, The training classes are not the problem. In order to get your CCVP, you have to meet Cisco's prerequisites. Working backwards from where you want to get. For the CCVP, the prerequisite is a CCNA Voice (or a CCIE) as referenced below: http://www.cisco.com/web/learning/le3/le2/le37/le65/learning_certification_t... For the CCNA Voice, you must have a current CCNA (or a CCIE), as referenced in the CCNA Voice certification reference: http://www.cisco.com/web/learning/le3/le2/le0/le3/learning_certification_typ... So, yes you could take the training, but even after you have completed the training, you will still have to pass the certification exams for the levels below the CCVP. Tim Rod.Dossouvi.CTR at dot.gov wrote:
Shouldn?t I be able to just take 642-436 CVOICE 6.0 to start off?
------------------------------------------------------------------------
*From:* Mark Holloway [mailto:mh at markholloway.com] *Sent:* Wednesday, October 07, 2009 11:38 AM *To:* Dossouvi, Rod CTR (FHWA) *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] CCVP tests order
You have to pass CCENT before you can earn the CCNA Voice, and you must have the CCNA Voice before you can earn the CCVP.
I would recommend the following order for the CCVP.
QoS
CVOICE
CIPT1
CIPT2
Troubleshooting (TUC)
On Oct 7, 2009, at 8:08 AM, <Rod.Dossouvi.CTR at dot.gov <mailto:Rod.Dossouvi.CTR at dot.gov>> <Rod.Dossouvi.CTR at dot.gov <mailto:Rod.Dossouvi.CTR at dot.gov>> wrote:
Hi,
I am interested in taking the CCVP and was wondering in what order should the tests be taken?
I am also taking all the 5 classes. I have an expired CCNA :-)
CIPT1, CIPT2, QoS, CVOICE and TUC
Any advise, recommendations will be very much appreciated.
Thanks,
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thanks so something like this? 1) ICND2????????? CCNA 2) CVoice???????? CCNA-Voice 3) CIPT1 4) CIPT2 5) TUC 6) QOS??????????? CCVP -----Original Message----- From: Tim Donahue [mailto:tdonahue at theaeonsolution.com] Sent: Wednesday, October 07, 2009 12:39 PM To: Dossouvi, Rod CTR (FHWA) Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] CCVP tests order Rod, The training classes are not the problem. In order to get your CCVP, you have to meet Cisco's prerequisites. Working backwards from where you want to get. For the CCVP, the prerequisite is a CCNA Voice (or a CCIE) as referenced below: http://www.cisco.com/web/learning/le3/le2/le37/le65/learning_certification_t... For the CCNA Voice, you must have a current CCNA (or a CCIE), as referenced in the CCNA Voice certification reference: http://www.cisco.com/web/learning/le3/le2/le0/le3/learning_certification_typ... So, yes you could take the training, but even after you have completed the training, you will still have to pass the certification exams for the levels below the CCVP. Tim Rod.Dossouvi.CTR at dot.gov wrote:
Shouldn't I be able to just take 642-436 CVOICE 6.0 to start off?
------------------------------------------------------------------------
*From:* Mark Holloway [mailto:mh at markholloway.com] *Sent:* Wednesday, October 07, 2009 11:38 AM *To:* Dossouvi, Rod CTR (FHWA) *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] CCVP tests order
You have to pass CCENT before you can earn the CCNA Voice, and you must have the CCNA Voice before you can earn the CCVP.
I would recommend the following order for the CCVP.
QoS
CVOICE
CIPT1
CIPT2
Troubleshooting (TUC)
On Oct 7, 2009, at 8:08 AM, <Rod.Dossouvi.CTR at dot.gov <mailto:Rod.Dossouvi.CTR at dot.gov>> <Rod.Dossouvi.CTR at dot.gov <mailto:Rod.Dossouvi.CTR at dot.gov>> wrote:
Hi,
I am interested in taking the CCVP and was wondering in what order should the tests be taken?
I am also taking all the 5 classes. I have an expired CCNA :-)
CIPT1, CIPT2, QoS, CVOICE and TUC
Any advise, recommendations will be very much appreciated.
Thanks,
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (8)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
Brad＠broadcore.com -
mewash＠gmail.com -
mh＠markholloway.com -
Rod.Dossouvi.CTR＠dot.gov -
scott＠sberkman.net -
tdonahue＠theaeonsolution.com