Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

400 Bad Request (No body in polling notify)

fondog2

Systems Engineer
Jan 19, 2006
338
US
I've been searching everything here and on the Avaya support site and can't find anything to point to this SIP message. Has anyone seen this?
Here is the scenario:
Remote 10.2 standalone CM with SIP trunk to our 10.2 ASM. Verified the SIP calls back and forth and our centralized voicemail identifies the far end numbers using an adaptation. We were trying to add Workplace to the mix for a few users who need to travel. Our core 10.2 switch is domain/location based routing but this site is standalone. TN 1, network region 1, IP mapping and so on. The work place phone registers and can be dialed but calls go straight to VM. SIP traces show the ASM sending the 400 message to the remote CM. This is TCP also so no certs at this time.

Thanks in advance.
 
Do you have working SIP with ASM and CM for endpoints? There is a bit more to it than there with SIP trunking.

The error you got -- double check your numbering tables have an entry for your user.
 
Here's some notes I took from an Avaya solution about ten years ago.
===========

Doc ID: SOLN226283

Sequence
  1. Extension sends SUBSCRIBE Ev: avaya-cm-feature-status request to ASM then to CM
  2. ASM responds with 202 Accepted
  3. CM responds with 200 OK
  4. CM sends NOTIFY request
  5. ASM responds with 400 Bad Request (no body in polling NOTIFY)

Result
Phone has successfully subscribed to feature status, but CM cannot deliver the status.

Cause
CM does not know how to build the Message Body which describes the status of Avaya features.

In the customer environment, CM builds the body in the NOTIFY message using the extension in the Private-numbering table.

Solution

The Private-numbering (or sometimes the public-unknown-numbering table) must be populated with all SIP extensions and the trunks/sig groups belonging to both Session Managers connected to CM.
 
The PUB was there but they missed the private. They stated the AST was not on which I should have caught. Outbound calls to other CM internally work but it doesn't ring to the Workplace station. OneX works in H.323. I don't think this standalone needs it's own ASM because we have this connected to our core ASM, but I could be wrong. I'm still digging through the traces though.
 

Part and Inventory Search

Sponsor

Back
Top