AVAYA IP OFFICE AND RESPONSE TO SIP INFO PING

[chrissymer1]

We are trying to implement avaya ip office and although we can get it to register with the service provider, it stays up for 2o seconds then the link is disabled . Looking at the trace the service provider send a SIP OPTIONS INFO ping to the AVAYA and it has to respond and send back a reply in order to keep the link up. From the logs we see the INFO message recieved on the AVAYA but it responds with the below syntax how do we get the IP OFFICE to respond back to the service provider instead of the below response
Sip: Unsupported sip incoming method on trunk interface <INFO> - ignoring
1262875mS Sip: Cannot accept call: reason=405 (Method Not Allowed)

 

[Westi]

Who is the SIP provide ?
Maybe someone here has done it and can provide settings or check if there is a tech bulletin for that provider on the knowledgebase


Joe W.

FHandw, ACSS

 

[chrissymer1]

It is a Genband A2E

 

[Westi]

Now let's see if anybody knows how to set them up.

Joe W.

FHandw, ACSS

 

[kholladay]

I wouldn't imagine you'll get much response. You didn't list the version of IP Office and you didn't post the entire SIP message.

http://www.ipofficehelp.com/HOWTO_ConfigureMonitorComprehensive.aspx#SIPTroubleshoot

Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[chrissymer1]

I am looking for the load version, but why would I need to paste the entire message. The A2 is sending a SIP INFO message and the IP OFFICE is not responding, the end result is a failure on the keep alive back to the Genband product.How do I get the IP OFFICE to respond with what I imagine is the 200ok . Someone out there must have encountered this issue when integrating the Avaya product with SIP PBX A2E .

 

[kholladay]

Because what was in the message would help to determine why it is being listed as unsupported. And to clarify your statement because you mention OPTIONS and INFO but these are two different things. Using INFO to probe for status would be strange because INFO is used to carry session control information (as stated in RFC 2976). The use of OPTIONS is used to allow two user agents to discover one another (as described in RFC 3261). It would then make perfect sense that the IP Office would reject an INFO message outside of a session because it has no place outside of a session as it is specifically a "mid-session" message..

If it is truly an OPTIONS message then as you can see below a properly formatted OPTIONS message is handled just fine by the IP Office so again it is helpful to see the information contained within the message to assist you. Then again if you prefer to simply argue about it when people are attempting to assist then I'll drop it and you can hope for support elsewhere.

306926192mS SIP Rx: UDP XXX.XXX.XXX.XXX:5060 -> XXX.XXX.XXX.XXX:5060
OPTIONS sip:XXX.XXX.XXX.XXX:5060 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:XXX.XXX.XXX.XXX;lr>
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX;branch=z9dfzhG4bK5bd2.ca81d458306eb02495e2c7f79263858c.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=0
Route: <sip:XXX.XXX.XXX.XXX;lr;received="sip:XXX.XXX.XXX.XXX:5060">
From: siping@invalid;tag=539733461
To: sip:XXX.XXX.XXX.XXX:5060
Call-ID: 3bed14f2-040ced4055-8f90395@70.167.153.136
CSeq: 1 OPTIONS
Content-Length: 0

306926196mS SIP Tx: UDP XXX.XXX.XXX.XXX:5060 -> XXX.XXX.XXX.XXX:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX;branch=z9hddfG4bK5bd2.ca81d458306eb02495e2c7f79263858c.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=0
Record-Route: <sip:XXX.XXX.XXX.XXX;lr>
From: <siping@invalid>;tag=53973461
To: <sip:XXX.XXX.XXX.XXX:5060>;tag=c308a433e85ddf23
Call-ID: 3bed14f2-04d0ce055-8f90395@70.167.153.136
CSeq: 1 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Server: IP Office 8.1 (4)
Content-Type: application/sdp
Content-Length: 189

v=0
o=UserA 29091242345 18366209299 IN IP4 XXX.XXX.XXX.XXX
s=Session SDP
c=IN IP4 0.0.0.0
t=0 0
m=audio 8000 RTP/AVP 18 0
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000

Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[zols]

upgrade to 8.1.22

 

[chrissymer1]

1261373mS SIP Rx: UDP XX.XX.XX.XX:5060 -> XX.XX.XX.XX:5060
INFO sip:XXXXX1@XX.XX.XX.XX:5060 SIP/2.0
Max-Forwards: 19
To: "XXXXXX1" <sip:XXXXXX@XX.XX.XX.XX:5060>
From: "XXXXXX1" <sip:XXXXXX1@XX.XX.XX.XX>;tag=123456788-453678
Call-ID: 1064552-3545747980-492889@XX-XX-XX-XX-XX-XX.com
CSeq: 1 INFO
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Via: SIP/2.0/UDP XX.XX.XX.XX:5060;branch=z45566677766777788999000090000urtfgyhujikolp
Contact: <sip:XX.XX.XX.XX.:5060>
Content-Length: 0

1261375mS SIP Call Rx: 18
INFO sip:XXXXXX1@XX.XX.XX.XX:5060 SIP/2.0
Max-Forwards: 19
To: "XXXXX1" <sip:XXXXXX1@XX.XX.XX.XX:5060>
From: "XXXXX1" <sip:XXXXX1@XX.XX.XX.XX>;tag=123456788-453678
Call-ID: 1064552-3545747980-492889@XX-XX-XX-XX-XX-XX.com
CSeq: 1 INFO
Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Via: SIP/2.0/UDP XX.XX.XX.XX:5060;branch=z45566677766777788999000090000urtfgyhujikolp
Contact: <sip:XX.XX.XX.XX:5060>
Content-Length: 0

1261375mS Sip: Unsupported sip incoming method on trunk interface <INFO> - ignoring
1261375mS Sip: Cannot accept call: reason=405 (Method Not Allowed)

 

[hairlessupportmonkey]

Id be interested to see your config.

ACSS - SME
General Geek

 

[kholladay]

No need to look at the config, look at the message. It is indeed an INFO message and not an OPTIONS message.

If you read RFC 2976 that defines INFO it will tell you
The purpose of the INFO message is to carry mid-session information between SIP user agents.

Section 2.2 will also go on to tell you that if the INFO is received where no associated processing rules for the INFO body then the message is rejected with either a 415 Unsupported or other 4XX, 5XX or 6XX failure responses.

OPTIONS is a keep alive mechanism, INFO is not.

This is no different that if I were to unilaterally redefine the word toenail to mean a refreshing fizzy beverage. If nobody else accepts this as the definition or is not aware of my misguided attempt to use the word incorrectly then when I say "it's a warm summer day, perfect for a tall glass of toenails" I'm likely to get back a human equivalent of 405 method not allowed.

Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[amriddle01]

Indeed, this is an example of what we repeat over and over. SIP is just a protocol not a standard, just because a provider sells a SIP trunk does not mean it is following a fixed set of rules that guarantee compatability, they can implement it any way they like. And in this case they have not implemented it very well

 

[hairlessupportmonkey]

Im sure Ive also seen this when there is no ICR for the number dialed.

ACSS - SME
General Geek

 

[amriddle01]

Is it not normally 404 not found for that HSM ?

 

[chrissymer1]

Thank you for your response I will take a closer look at theses RFC's